JP2015513826A

JP2015513826A - プロキシ装置を使用して無線ネットワーク内でプロキシテーブルを管理する方法

Info

Publication number: JP2015513826A
Application number: JP2014557138A
Authority: JP
Inventors: ボゼナエルドマン; コーエンヨハンナギョームホルトマン; アルマンドミッシェルマリエレルケンス; エスコオラヴィダイク; ルドヴィクスマリヌスジェラルダスマリアトルフィツェン; ウィットバスウィリブロードデ
Original assignee: Koninklijke Philips NV; Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2012-02-16
Filing date: 2013-02-07
Publication date: 2015-05-14
Also published as: US10405258B2; JP2018137794A; US9992727B2; WO2013121325A2; EP3193536A1; RU2014137331A; EP2815609A2; RU2639688C2; US20150043428A1; WO2013121325A3; EP3193536B1; CN104106288A; US20170257813A1; CN104106288B

Abstract

本発明は、プロキシテーブルを管理するための手段と、第１の資源制約装置からメッセージを受信するための受信機であって、前述のメッセージは少なくとも１つの対応する宛先装置を対象とする、受信機と、プロキシテーブルの１組のエントリ内に第１の資源制約装置のエントリが含まれているかどうかを確認するための制御手段であって、プロキシテーブルの１組のエントリはプロキシノードが担当する１組の資源制約装置を示す、制御手段と、プロキシテーブルの確認結果に応じてメッセージを転送するための送信機とを含むプロキシノードであって、プロキシテーブルを管理するための手段が、資源制約装置のメッセージを転送するための競合プロキシノードの使用に対する、資源制約装置のメッセージを転送するためのプロキシノードの相対的使用をモニタすることにより、資源制約装置に関連するエントリをプロキシテーブルから消去するように構成される、プロキシノードに関する。

Description

本発明は、複数のノードを含む通信ネットワークに関する。具体的には、一部のノードは資源が制約されており、他のノードと効率的に通信しなければならない場合がある。効率的な通信を行うために、プロキシノードが中継ノードとして動作し、資源制約ノードからかかるノードのターゲット又は宛先ノードにメッセージを転送する。

本発明は、例えばZigBee Green Powerノードを含むネットワークに関連する。

無線ネットワークでは、環境発電装置等の資源制約装置が使用され得る。かかる装置は使用可能なエネルギ量の点で非常に制約されており、従って提供される機能面で限られており、ネットワークの運用、コミッショニング、及び保守に影響を及ぼす。

かかる技術の一例は、進行中の規格ZigBee Green Powerである。

制約装置が制御するように構成される装置（ターゲットと呼ばれる）の範囲外に制約装置がある場合、中間装置（プロキシと呼ばれる）が転送を行う。プロキシと制約装置との間の無線リンクは、例えば伝搬や装置の相対的位置が変化することにより、ネットワーク寿命の間に出現したり消滅したりする場合がある。システムのセキュリティ及び性能上の理由から、プロキシは、例えば新しさ又はセキュリティの検査を行えるようにするためのテーブルエントリを自らが有する装置についてのみ転送を行う。通信の信頼性を得るために、好ましくは複数のプロキシが各制約装置の代わりに転送を行う。

かかるプロキシエントリを自動で、又は利用者の要求に応じて確立／拡張する様々な方法がある。しかしながら、現在使用可能なエントリ除去方法は、コミッショニングツールの使用及び／又は制約装置／コントローラ装置（天井に設置している可能性もある）との手作業の対話により利用者が関与することを必要とし、このことはビルディング自動化ネットワーク等の大規模ネットワークでは厄介である。

しかしながら、ネットワークの規模及びプロキシテーブルの自動的な作成が原因で、プロキシテーブルを自動的に消去することが求められている。但し、制約装置による予測できない伝送スケジュール（利用可能なエネルギ量及び／又はユーザ対話に依存し得る）、及び特に場合によってはＡＣＫ及びチャネルアクセス手続き（ＣＳＭＡ／ＣＡ等）を使用しない制約装置からの無線伝送の信頼できない性質により、単純なエージング（例えば最も早く失効するエントリを除去すること、最も早く作成されたエントリを除去すること、最も使用されていないエントリを除去すること）は制約装置については不適切である。

ＺＧＰ仕様では現在、何らかの消去ヒューリスティックスを選ぶこと、即ち新たなエントリが追加されなければならない場合に完全なプロキシテーブルから削除するエントリを選択するヒューリスティックスを選ぶことは、実装されているプロキシに委ねられている。劣ったヒューリスティックは、ネットワークの効率及び信頼性を低下させるが長期にわたるネットワーク障害は引き起こし得ないので、プロキシを実装する者にはある程度の自由があり得る。

本発明の目的は、プロキシ内のテーブル消去ヒューリスティックスを改善するために使用され得る（義務的な）プロトコル要素を追加することである。より効率的なヒューリスティックスは、より高速且つより高信頼のネットワークをもたらす。

現在のＺＧＰ仕様では、非常に一杯のプロキシテーブルを有するプロキシに関する性能上の不利益はなく、そのためプロキシ内の使用可能なメモリサイズをはるかに下回ってテーブルを小さくするために積極的に消去することには有益な効果がない。

現在のＺＧＰ仕様は、プロキシテーブルを保守するための以下のメカニズムを提供する。

プロキシテーブルのエントリの確立：
− （利用者が関与する可能性が高い）コミッショニングプロセス内で、制約装置及び対応するターゲットの識別情報を含む作成された新たな制御関係をプロキシに知らせる制御アナウンス（ＺＧＰ：AddSinkフラグが0b1に設定されたZGP Pairingコマンド）をターゲット又はコミッショニングツールが送信する場合、その制御アナウンスは（範囲が限定された）ブロードキャストで送信されても良く、プロキシは自らが制限装置の範囲内にある場合にのみ、とりわけ装置が固定位置を示す場合、テーブルを任意選択的に追加し、
− 動作中、
^＊プロキシにより、非請求制御アナウンスを受信すること、
^＊プロキシにより、未知の制約装置からの通信を受信し、他のプロキシがそれを転送するのを見ること、
^＊プロキシにより、未知の制約装置からの通信を受信し、制御関係のクエリを行うこと（ＺＧＰ：ZGP Pairing Searchコマンド又はブロードキャストZGP Notificationコマンド）。

プロキシテーブルのエントリの除去：
− コミッショニングモードにある制約ノードから、（制約ノード上で特別にトリガされた）Decommissioning GPDFを受信すること、
− ターゲット／コミッショニングツール上で特別にトリガされた制御除去コマンド（ＺＧＰ：AddSinkフラグが0b0に、又はRemoveZGPDが0b1に設定されたZGP Pairing）を受信すること。

以下のプロキシ動作が更に自動的に実行される：
− 転送された通信を受信すると、第一転送（first-to-forward）フラグがクリアされること、
− 別のプロキシが指定された状態で、制約装置に送信する要求（ＺＧＰ：ZGP Response）を受信すると、プロキシは第一転送フラグをクリアし、その制約装置に送るために待ち行列に入れられた一切のパケットを除去すること。

資源制約装置とは、例えば電池を有さず又は小さい記憶容量しか有さず、スケジュールされていない機会にしか受信できないZigBee Green Power装置（ＺＧＰＤ）等であり得る。例えば、ＺＧＰＤは、利用者によって始動され自らの信号を伝送すると短い間しか受信できない、無電池型スイッチとすることができる。ＺＧＰＤの別の例は、例えば光電池によって自らの環境からエネルギを採取する周期的報告センサである。

本発明の目的は、プロキシノードのプロキシテーブルを効率的に管理する方法を提案することである。

本発明のもう１つの目的は、以下の目標の１つ又は複数を実現することである：
１．古くなったプロキシテーブルエントリを除去すること。
２．プロキシテーブルのオーバーフローを回避すること。
３．（高密度ネットワーク内で）制約装置ごとの有効プロキシが多過ぎるのを回避すること。
４．（高密度ネットワーク内で）制約装置ごとに少なくとも単一のプロキシを有することを保証すること。
５．応用要件（例えば重要性及びｒｔ要件）に応じてプロキシの最適な信頼性を保証すること。

このために、添付の特許請求の範囲の中で定める方法及び装置を提案する。

本発明のこれらの及び他の態様が、以下に記載の実施形態に関して明らかになり説明される。

次に、本発明が添付図面に関して例としてより詳細に説明される。

本発明が実装されるネットワークのブロック図である。

以下を含む無線メッシュネットワークを検討されたい。
・多くの無線パケット又は長い無線パケットを送信する能力の面で制約され、パケットを長期間にわたってリスンする能力の面で制約され、又は全く受信しない点で制約された、１つ又は複数の制約装置Ｒ。例えばエネルギを発生させるメカニズム（energy scavenging mechanisms）によって給電される装置。制約装置は、メッセージをパケット内に入れて送ることにより、メッセージを送信することができる。
・制約装置Ｒからメッセージを受信すべき１つ又は複数のターゲット装置Ｔであって、メッセージは１つ又は複数のパケットに符号化されても良く、メッセージのパケットへの符号化はホップごとに変わり得る、１つ又は複数のターゲット装置Ｔ。
・制約装置からパケットを受信するときに特別なアクションを取ることにより、制約装置からのメッセージを制約装置の（無線）範囲を越えて送るのを助け、且つ／又はそれらのメッセージを所要のメッセージ形式で及び／又はより確実に送るのを助ける１つ又は複数のプロキシ装置Ｐ。かかる特別なアクションの一例は、ターゲットＴに向けてメッセージを送ることである。プロキシ装置は典型的には制約装置よりも強いパワーを有し、そのため更なるメッセージ処理を行い、より長いメッセージの様々なメッセージ形式を使用し、制約装置の代わりに再試行アクション又はルート発見アクション等を行うことができる。
・任意選択的に、プロキシ装置として機能することはできないが、プロキシ装置によって送られるメッセージをターゲット装置にルートできる１つ又は複数のルータ装置ＲＴ。

メッセージ用の中継器として機能することができる少なくとも１つの装置があることを示すために、本発明者らはこれを「メッシュ」ネットワークと呼ぶ。

単一の装置が、ターゲット装置及びプロキシ装置の両方として、更にルータ装置として機能することができる。

図１に典型的なネットワークトポロジが示されている。図面内の矢印は、Ｒ１からＴ１にメッセージを送るために送受信されるパケットを示す。点線矢印は、この例ではＲ１によって送信される元のパケットがＰ１によっても受信されるが、Ｐ１はそのパケットに従って動作しないことを示す。Ｐ１とＰ２とが連係し、その両方がパケットを転送する無駄なアクションを回避できる幾つかの（既知の）技術がある。かかる技術は、例えば近く公開されるZigBee Green Power規格に取り入れられる。

図１は、Ｐ１及びＰ２の両方が、Ｒ１の範囲内にあるプロキシであることを示す。複数の範囲内装置がＲ１のプロキシとして働き得るシステム設計を有することが有益であり得る理由が幾つかある。
１．信頼性。各メッセージＭ_ｉについて、Ｒ１はメッセージを含むパケットを送信するための限られたエネルギしか有しない場合がある。例えばＲ１は、（例えば採取されるエネルギの可用性によって定められる）非常に短い時間窓の中で、メッセージを符号化する２つのパケットしか送信できない場合があり、所要のチャネルアクセスメカニズムを実行できない及び／又は肯定応答フレームを受信するのを待てない場合もあり、その全てが通信の信頼性に悪影響を及ぼし得る。その場合、全てＲ１からのパケットをリスンし、Ｒ１からのパケットを転送することもできる更に多くのプロキシをＲ１の周りに有することは、少なくとも１つのプロキシが、Ｍ_ｉを有するパケットを受信する可能性を高める。
２．移動性。Ｒ１が動き回れる場合、Ｒ１は任意の単一のプロキシの範囲外に移動することがあり、プロキシが移動され／オフにされる可能性もあり、又は（例えば一時的又は永続的な空間再編成により）伝搬条件が変化することがある。
３．制約装置の構成の回避。単一のプロキシ装置のネットワークアドレスを保持するように制約装置Ｒ１を構成するのは不可能又は望ましくない場合がある。従って、Ｒ１によって送信される如何なるメッセージパケットも、自動的に全ての（範囲内にある）プロキシ対応装置にアドレス指定されるブロードキャスト／マルチキャストパケットになる。

我々の発明は、とりわけ制約装置Ｒ１ごとに複数のプロキシを有する能力を備えるシステムに適用される。

かかるシステムでは、プロキシが制約装置に関する「状態情報」を含むことができる場合、速度、効率、及び信頼性に関して有益である。単一の制約装置Ｒ１に適用され得る、かかる「状態情報」の例には以下のものがある。
１．Ｒ１からの特定のメッセージに関するターゲット装置のアドレス（識別情報）をＲ１が自らのメッセージパケット内に埋め込むことができない、又は埋め込まない場合、Ｒ１からの特定のメッセージに関するターゲット装置のアドレス（識別情報）。
２．Ｒ１との間の通信をより安全にする情報、例えばＲ１によって使用される暗号化キー、Ｒ１によって最近使用されたセキュリティフレームカウンタ（フレームカウンタはリプレーアタックを防ぐことができ、且つ／又はキーの初期設定ベクトルとして使用される）。
３．Ｒ１が自らの無線機を始動させ、Ｒ１に送信される必要があるメッセージを受信するように無線機を設定し次第、Ｒ１に送信される必要があるメッセージ（典型的にはエネルギを発生させるノードＲ１は、自らの無線機を始動させ、メッセージパケットを無線機が送信した後の短い間、無線機を受信モードに設定し得る）。

本発明の目的上、本発明者らは「プロキシテーブル」を、１つ又は複数の制約装置に関する情報又はかかる制約装置のための情報を保持する、プロキシ内のデータ構造として定義する。プロキシテーブルは、多くの異なる制約ノードＲｘのための情報を含むことができる。

従って、かかるシステムでは、制約装置の通信を転送するためにプロキシテーブルエントリが作成され、保守され、使用される必要があり、場合により除去される必要もある。

例えば図１では、Ｐ１及びＰ２の両方がＲ１に関する情報を自らのプロキシテーブル内に記憶すれば有益である。Ｒ１が動き回ることができる場合、Ｐ３がその情報を記憶すれば更に有益である。但し、想定される殆どのメッシュネットワークにおいてプロキシノード内のメモリは限られており、そのため全ての制約ノードＲｘに関する情報を全てのプロキシ（対応）ノードＰｘの全てのプロキシテーブル内に記憶することが必ずしも可能とは限らない。

制約ノードＲ１に関する如何なる情報も自らのプロキシテーブル内に現在有しないプロキシノードＰｘは、依然としてそのノードのプロキシとして働き始めることを選択することができる。従って、或るノードＲｘを取り囲む２種類のプロキシを区別することができる。
・Ｒｘに関する情報を自らのプロキシテーブル内に有する、早期アクション対応プロキシ。
・Ｒ１からメッセージを受信する時点でＲｘに関する情報を自らのプロキシテーブル内に（まだ）有しない、又はプロキシとして機能するには少なくとも十分な情報を有しない、後期アクション対応プロキシ。機能するには、後期アクションプロキシは、まず必要な情報をネットワーク内の他の場所から得る必要がある。

好ましくは、ネットワーク内の構成は、各制約ノードＲｘが自らの伝送範囲内に少なくとも幾つかの早期アクション対応プロキシを有するものである。しかしながら、かかる構成では、アクション可能な全てのプロキシが、自らの範囲内にあるＲｘからメッセージを受信するとき、あらゆる場合に機能することに決めることを防ぐためのメカニズムが好ましくは必要である。これが回避されない場合、対応プロキシが複数存在することが、メッセージ配信遅延時間の増加、又は配信の確実性の低下さえ引き起こし得る。想定されるかかる防止メカニズムの１つは、Ｒｘからの受信メッセージに従って或るプロキシＰｘが動作し、それを配信する場合、Ｐｘが動作したことをＲｘの範囲内にある他のプロキシが知るための手段があるものである。それらのプロキシが知った場合、それらのプロキシは自らが動作するのを控えることができる。かかる情報メカニズムは以下の形を取ることができる。プロキシＰ１がメッセージＭ_ｉをＲ１から受信し、動作するのかどうかを今決めなければならないと仮定する。次いでプロキシＰ１は、タイムアウトカウンタを開始し、ネットワークチャネルをリスンする。プロキシＰ１が、別のプロキシ、例えばＰ２からの、Ｐ２がＲ１の同一メッセージＭ_ｉに従って動作したことを示すペイロードを含むパケットを認める場合、Ｐ１は動作しないことに決め、カウンタを停止する。Ｒ１のメッセージＭ_ｉについて他のプロキシからパケットを受信することなしにカウンタがゼロになる場合、Ｐ１が動作する。ネットワークの送信範囲の違い、及び無線パケット配信の幾らかの固有の不信頼性のため、このようなメカニズムは、複数のプロキシがＲ１からの同一メッセージに従って動作することに決める全ての事例を阻止する訳ではない。従って、全て動作した複数のプロキシからの重複メッセージを除去するメカニズムも、例えばターゲットノード内にあることが想定される。

近く公開されるZigBee Green Power規格では、アクティブ及び有効なプロキシテーブルエントリに以下のメカニズムが使用される（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.1, page 120, line 6 - page 121, line 17を参照）。ユニキャスト転送の場合、特定の制約装置Ｒｘに関するプロキシテーブルエントリを有するプロキシは、制約装置からの受信信号の品質、ターゲット装置までのユニキャストルートの可用性、過去において最初に転送するという事実等の基準に基づき転送遅延を計算する。転送遅延の満了時に、プロキシは、どちらもＧＰＤＦ内の情報から得られるエイリアスネットワークソースアドレス及びエイリアスネットワークシーケンス番号と共に、ZGP Tunneling Stopメッセージを２ホップブロードキャストで送信し、自らがメッセージを転送することを他のプロキシに知らせ、その後ZGP Notificationメッセージをユニキャストで送信する。転送遅延内に同じＺＧＰＤコマンドに関するZGP Tunneling Stopメッセージを受信すると、プロキシは自らのスケジュールされた伝送をキャンセルする。受信機会を示すＧＰＤＦのグループキャスト通信の場合、特定の制約装置Ｒｘに関するプロキシテーブルエントリを有するプロキシが上記のように転送遅延を計算する。転送遅延の満了時に、プロキシはZGP NotificationメッセージをＡＰＳマルチキャストで送信し、自らのショートアドレス及び制約装置Ｒｘから受信される信号の品質の指標を含める。転送遅延内に同じＺＧＰＤコマンドに関するZGP Notificationメッセージを受信すると、ZGP Notificationがより良い品質指標を有し、又は等しい品質指標及び下位のショートアドレスを有する場合、プロキシは自らのスケジュールされた伝送をキャンセルする。受信機会を示さないＧＰＤＦのグループキャスト通信の場合、特定の制約装置Ｒｘに関するプロキシテーブルエントリを有するプロキシが、どちらもＧＰＤＦ内の情報から得られるエイリアスネットワークソースアドレス及びエイリアスネットワークシーケンス番号と共にZGP NotificationメッセージをＡＰＳマルチキャストで転送し、このことは独立に生成されたZGP NotificationパケットをZigBeeのブロードキャストトランザクションテーブルとそっくりに見せる。同じメカニズムが、シンクテーブルに基づくグループキャスト転送を行えるシンクによって使用される（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.4, page 128, line 25-29参照）。

プロキシがZGP Notificationの伝送に成功した場合、プロキシは自らのプロキシテーブルの第一転送フラグを真に設定し、ユニキャストシンクからZGP Notification Responseを受信したとき、第一転送フラグが偽に設定された状態でそれをクリアする（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.1, page 121, line 12-17参照）。シンクは、受信されるＺＧＰＤコマンドをＺＧＰＤ識別情報（SrcID）及びフレームカウンタ値に基づいてフィルタリングする（ZigBee Green Power specification, 09-5499-18, section A.3.6.1.2, page 132, line 2 - page 134, line 4参照）。

プロキシテーブルエントリが最初に作成される必要がある。プロキシテーブルエントリは、例えば利用者及び／又はツールを伴うコミッショニングプロセスの一部として作成され得る。プロキシテーブルエントリは、自動的に作成されても良い。制約ノードＲｘのために動作することに決める後期アクション対応プロキシは、アクションの終了時に、それ自体でＲｘに関するプロキシテーブルを作成するのに十分な情報を得るに至り、後期アクション対応プロキシがそのように情報を得れば有益である。追加のプロキシテーブルエントリを作成することを可能にする通信を漏れ聞く後期アクション対応ノードは、特に更に多くのエントリ用の使用可能な空きスペースを有する場合、追加のプロキシテーブルエントリを作成することにしても良い。

プロキシＰｘであって、とりわけＰｘがＲｘからのメッセージを（まだ）受信していない場合、即ちＰｘがＲｘの範囲内に（まだ）ない可能性のある場合に、ネットワーク中で送信される制約ノードＲｘに関する情報であって、プロキシＰｘが自らのプロキシテーブルにＲｘを追加すること、及びＲｘの早期アクション対応ノードになることを可能にする情報を（漏れ）聞く、プロキシＰｘを想像されたい。Ｐｘは、例えば関与する全てのノードに宛てられる、ノードＲｘについて知らせるブロードキャスト型又はマルチキャスト型メッセージを聞くことができる。プロキシテーブルにＲｘを追加することがテーブルから別のノードを削除しなければならないことを意味する場合、Ｒｘを自らのプロキシテーブルに追加すべきかどうかをプロキシＰｘはどのように決めるべきか。かかる決定のための支援方法も以下に開示されている。

近く公開されるZigBee Green Power規格では、プロキシテーブル内に情報を構成するために以下のメカニズムが使用される（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.1, page 118, line 32-39; section A.3.9, page 165 line 2参照）。成功裏のコミッショニング手続きの一部として、ＺＧＰＳ又はＺＧＰＣＴが、典型的にはとりわけSrcID、セキュリティ設定、及び所要の通信モードを運ぶネットワーク全体に広がるブロードキャストとして、AddSinkフラグが0b1に設定されたZGP Pairingメッセージを送信する。ZGP Pairingを受信すると、プロキシは供給された情報を用いてプロキシテーブルエントリを作成／拡張する。シンクテーブルに基づく転送を行えるシンクでは、別のＺＧＰＳ又はＺＧＰＣＴによって送信され得るConfigure Pairingコマンドの受信時にシンクテーブルエントリが作成される（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.4, page 127, line 35 - page 128, line 1参照）。

しかしながら、装置の機動性及び伝搬の変化、並びに装置がネットワークに後で追加されることにより、新たなプロキシは後の時点でも制約装置に関する「状態情報」を必要とし得る。

後期アクション対応プロキシがＲ１からメッセージを受信し、その後上記のような情報メカニズムによって、別のプロキシが既に動作したことを意味する情報を全く得ないと仮定されたい。その場合、プロキシは難しい決断をしなければならない。プロキシが動作を控えることに決める場合、メッセージは配信されないままであり得る。しかしながら、プロキシが動作することに決める場合、それはどのように動作するのかについての必要情報を得るためにネットワークと通信することを意味する。かかる通信は、典型的にはブロードキャスト又はマルチキャスト型のクエリ要求の形（「Ｒ１からのメッセージをどうするのか伝えることができるのは誰か」）を取らなければならず、その理由は、幾つかの専用情報ノードを有することは、潜在的にそれらのノードに対して高い資源（特にメモリ）要件を課し、それらのノードの位置がプロキシに知られていること／プロキシによって発見可能であることを必要とし、単一障害点も発生させる場合があるからである。かかるブロードキャスト又はマルチキャスト要求は、かなりの帯域幅を消費し得る。重要なことには、信頼性に対する不利益がある場合があり、つまり（特に大規模且つトラフィックの多いネットワーク内の）悪条件の下では、ブロードキャスト／マルチキャスト要求トラフィックが他の装置、具体的には他の制約ノードからのメッセージをかき消し、それらのメッセージを配信されないままにする可能性がある。しかしながら、ブロードキャスト／マルチキャストトラフィックがネットワークによって制約される場合、Ｒ１からＴ１へのメッセージ配信の想定される期限を過ぎることなしに、Ｐｘが動作するのに必要な必要情報を得ることができない可能性がある。Ｐｘが必要情報を全く得ることができない可能性さえある。

従って、動作するかどうかの判定について後期アクション対応ノードを何らかの方法で支援できれば有益であり、この支援は上記の情報メカニズムに勝るものである。かかる支援方法が以下に開示されている。

近く公開されるZigBee Green Power規格では、プロキシテーブル内の情報を保守するために以下のメカニズムが使用される。

ＺＧＰＤＲｘからＧＰＤＦを直接受信すると、プロキシＰｘはＲｘに関するプロキシテーブルエントリのInRangeフラグを真に設定する（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.1, page 119, line 44 - page 120, line 5参照）。ＰｘがトリガリングＧＰＤＦを認識しなかったZGP Notification又はZGP Tunneling Stopコマンドを受信すると、Ｐｘは第一転送フラグを偽に設定する（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.2.2, page 124, line 25-28参照）。プロキシフィールド内の別の装置のアドレスを運ぶZGP RESPONSEコマンドをＰｘが受信する場合、Ｐｘは第一転送フラグを偽に設定し、もしあれば、このＺＧＰＤに配信するために待ち行列に入れられたＧＰＤＦを除去する（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.1, page 118, line 43- page 119, line 6参照）。Ｒｘからの連続１０個のＧＰＤＦを逃した場合、ビルディング自動化の範囲内で動作するプロキシがInRangeフラグをクリアすることが推奨される（ZigBee Green Power best practices for ZBA, 11-0196-01, section 5.3.2.1, page 24, line 21-24参照）。

以下のメカニズムは、プロキシテーブル保守機能の一部である（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.2, page 124, line 2-6; section A.3.5.2.2.3, section A.3.5.2.2.4, section A.3.5.2.1, page 118, line 27-30参照）。プロキシＰｘが未知のＺＧＰＤＲｘからＧＰＤＦを受信する場合、プロキシは発見遅延タイマ（discovery delay timer）を開始する。次いでＰｘは、必要な情報を得るために、同じＺＧＰＤの代わりに他のプロキシによって転送されるZGP Notification／ZGP Tunneling Stopメッセージをリスンする。どちらのメッセージも、とりわけ使用される転送モードを示すフラグを運ぶ。発見遅延タイマが満了するとき、メッセージが受信されなかった場合、又は依然として情報（例えばユニキャストシンク又は事前にコミッショニングされたグループのアドレス）が欠落している場合、ＰｘはブロードキャストZGP Pairing Searchコマンドを送信し、指示された通信モード内でＺＧＰＤとペアにされたシンクがZGP Pairingで応答することを要求する。ZGP Pairingを受信すると、プロキシテーブルが更新される。Ｒｘに関するZGP Pairing Searchコマンド又はZGP Pairingコマンドが発見遅延内に受信される場合、Ｐｘは自らのZGP Pairing Searchの伝送をキャンセルする。アクティブでないプロキシテーブルエントリが除去されても良く、代わりにBlocked SrcIDリスト内にSrcIDが記憶される。

現在のＺＧＰ仕様では、シンクテーブルに基づく転送を行えるシンク内のシンクテーブルの保守について、対応するメカニズムが規定されていない。

古い／余分なプロキシテーブルエントリは、好ましくは自動的に除去されるべきである。しかしながら制約装置は、とりわけエネルギの可用性及び／又はユーザトリガに依存する、非常に不規則な伝送パターンを有する場合がある。

プロキシテーブルを管理する１つの方法は、「ＬＲＵ（least recently used（最も長く使われていない））」置換戦略を使用することである。「ＬＲＵ」戦略の下では、プロキシＰｘが既に一杯である自らのテーブルにＲｘノードを追加する必要がある場合、プロキシＰｘはＬＲＵのノードＲ_ｉを消し、例えば
ａ）テーブル内の全ノードの中で、Ｐｘが最も前に（最も遠い過去に）プロキシとして代わりに動作したノードとしてＲ_ｉが選択される
ｂ）テーブル内の全ノードの中で、Ｐｘが最も前に任意のメッセージを発していることを認めたノードとしてＲ_ｉが選択される。

かかる「ＬＲＵ」置換戦略には問題がある。プロキシテーブルが５個のエントリに限られ、ネットワークが、全て互いの受信範囲内にある１５個のプロキシ及び１５個の制約ノードを含むと仮定されたい。それらの制約ノードのうちの１０個が毎分データを報告する温度センサであり、５個が平均１日１回使用される照明スイッチボタンであると仮定されたい。この場合、「ＬＲＵ」置換戦略が厳密に如何なるものであろうと、毎朝、全ての照明スイッチがテーブルから消えている状態で、全てのプロキシ内の全てのプロキシテーブルが温度センサに関するデータで一杯にされる可能性が高い。ネットワークの他の態様の設計にもよるが、この状態は照明スイッチのメッセージ処理を遅くし、信頼できなくし、又は不可能にさえする。そのため、「ＬＲＵ」よりも優れた戦略が必要とされる。１５個のプロキシは、それらのうちで１５^＊５＝７５個のテーブルエントリを有し、そのため１５個の制約ノードの全てを少なくとも１つのプロキシのテーブル内に存在させることが可能なはずである。

プロキシテーブルを管理するもう１つの方法は、「先入れ先出し」置換戦略を使用することである。先入れ先出し置換戦略はノードの活動又は重要性を考慮しないので、先入れ先出し置換戦略を使用することも明らかに次善策である。

フォールバックの実施形態は、プロキシテーブルエントリを除去する際に利用者を関与させることである。

近く公開されるZigBee Green Power規格は、プロキシテーブルエントリを除去するための以下のメカニズムを提供する。

関係するプロキシテーブルエントリを除去することを含む、ネットワークからＺＧＰＤ装置を除去することは、ＺＧＰＤがZGPD Decommissioningコマンドを送信すること、及び／又はシンク／コミッショニングツールが、RemoveZGPDフラグが真に設定されたZGP Pairingコマンドを送信することによってトリガされ得る（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.5, page 129, line 10-15参照）。どちらのアクションも利用者によってトリガされることが予期される。プロキシテーブルから特定のペアリングを除去することは、シンク／コミッショニングツールが、AddSinkフラグが偽に設定されたZGP Pairingコマンドを送信することによってトリガされ得る。シンクは、NoPairingフラグが真に設定されたZGP Notification Responseを送信することにより、古くなったユニキャストペアリングを除去する（ZigBee Green Power specification, 09-5499-18, section A.3.5.2.5, page 130, line 32 - page 131, line 2参照）。ビルディング自動化の範囲内で動作するプロキシが、InRangeフラグが偽に設定されたプロキシテーブルエントリをクリアすることが推奨される（ZigBee Green Power best practices for ZBA, 11-0196-01, section 5.3.2.1, page 24, line 18-20参照）。

未知の装置のテーブルエントリは、例えばその装置を最初に認めたときに「ジャストインタイムに」発見されても良く、１回除去された／無効にされたテーブルエントリが再び発見／アクティブにされても良いが、不十分なヒューリスティックスが深刻なシステム障害を引き起こさないように注意が必要である。持っている人が支援を必要とする場合に動作されることを目的とする携帯型非常ボタンを想像されたい。そのボタンが資源制約装置、とりわけ環境発電装置として実現されることは、空の電池／電池交換に対処する必要がないことを保証するので有益であり得る。ターゲットとのペアリングが作成される。しかしながら、このボタンは、（持ち運び人は移動するので）毎回異なる場所で非常に稀に（例えば１年に数回）動作される可能性もあり、あったとしても保守作業さえ滅多にない（例えば２週間に１回）。ボタンをアクティブにしたときどのプロキシもテーブルエントリを有しない場合、想定される或るシステムの実装形態では、メッセージが転送されず、代わりにクエリが送信されても良く、クエリ結果は次のメッセージを転送するためにのみ使用され得る。しかしながら、目下の重要なアラームが転送されない可能性がある。

本発明は、プロキシテーブルのオーバーフローを防ぎながら上記の種類のネットワークの性能、待ち時間、及び信頼性を最適化する方法でプロキシテーブルのコンテンツを管理する幾つかの技術を含む。

本発明者らは、プロキシテーブルの無駄な増大を防ぐ以下の技術を開示する。
１．以下を含む、プロキシテーブルエントリクラス
ａ．プロキシテーブルの情報をよりコンパクトに記憶できるようにする、ワイルドカード技術
ｂ．作成されないテーブルエントリを含む、様々な保守ポリシを有するテーブルエントリクラス
ｃ．テーブルエントリクラスを判断するための決定基準、例えばプロキシに、特定の制約ノードについて、プロキシとして動作するアクション及び／又はテーブルにエントリを追加するアクションを省くことができることを決定させる。

本発明者らは、プロキシテーブルの消去を最適化する技術も開示する。テーブルの消去とは、１つ又は複数の制約ノードの情報を除去することを意味する。消去は、予期される将来の使用のための空きスペースを作るために何時行われても良く、又は新たなテーブルエントリが確実に追加されなければならないとプロキシが決定した瞬間に空きスペースを作るためにジャストインタイムで行われ得る。直ちに除去される代わりに、エントリは、制約装置に関する状態情報が別の制約装置のエントリで置換される必要があるまで保たれるように「除去可能」として印付けされても良く、そうすることは状態情報が再び関連する場合の再発見を回避できるようにする。テーブルの消去を最適化するとは、削除されるエントリを選択する際に、将来のネットワーク性能（信頼性、待ち時間、帯域幅の使用等）の幾つかの側面を最適化する選択基準を使用することを意味する。これらは２つのカテゴリに分類される。
２．性能の損失を一切引き起こすことなしに削除可能な古いエントリの識別
３．他のエントリに比べて、残りのどのエントリを保つのがより望ましいのかを判断するための手段
ａ．ネットワーク中で送信される状態情報の使用に依存する手段

本発明は、動作するかどうかの判断を下す際に後期アクション対応プロキシを支援する方法を更に開示する。

本発明の詳細な説明
（４’／５’）
プロキシテーブルの無駄な増大を防ぐための一実施形態は、プロキシが記憶しなければならない専用プロキシテーブルエントリの数を制約することである。

この方法の一実施形態では、プロキシに「ワイルドカード」エントリが与えられ、このエントリは専用プロキシテーブルエントリがない制約装置をプロキシが扱えるようにする。「ワイルドカード」エントリを含むプロキシテーブル内で制約装置Ｒｘを検索するとき、Ｒｘがどの通常エントリにもマッチしない場合、Ｒｘは依然として「ワイルドカード」エントリにマッチし得る。「ワイルドカード」エントリは、さもなければマッチしない全ての装置にマッチすること、又は特定の方法で定義される部分集合だけに、例えば「０１」の２ビットで終わるグローバル一意装置識別子を有する装置Ｒｘだけにマッチすると規定することができる。かかる「ワイルドカード」エントリは、ブロードキャスト、グループキャスト／マルチキャスト、又はユニキャストアドレス（のリスト）とすることができる、目的とされるターゲットを示すべきである。ユニキャスト又はグループキャスト／マルチキャストの場合、アドレスは、複数の制約装置及びそれぞれのシンクを扱うことができる１つの／幾つかの装置、例えばパケットを処理し、関与する装置を明らかにし、必要に応じてメッセージを適宜ルートすることができるビルディング管理システムを好ましくは示す。「ワイルドカード」テーブルエントリ内のターゲットアドレスは、プロキシが、自らがエントリを有しない制約装置の代わりに転送を行うべきでないことを示す無効なアドレスでも良い。最も単純な実装形態では、プロキシが制約装置のパケットを未処理で転送する。別の実装形態では、テーブルエントリが、何らかのフィルタリングを可能にし、転送を条件付にする情報を含むことができる。例えばテーブルエントリは、装置の種類、装置の機能、メッセージ又はプロトコルの種類を含むことができる。更に、プロキシが認証／暗号化の検証を行えるように、テーブルエントリは予期されるセキュリティレベル、予期されるキーの種類、予期されるキーの値を含む幾らかのセキュリティ情報を含むことができ、プロキシは制約装置のメッセージを転送することができる。装置の様々な特性を範囲に含む複数のワイルドカードエントリがあっても良い。ワイルドカードエントリは、全てのプロキシ内で、又は例えばワイルドカードトラフィック処理装置への通信量を最小限にするために入念に選択されたプロキシ内で作成されても良く、これは、専用エントリ及びワイルドカードフィルタリング基準を入念に選択することによって更に支援され得る。ワイルドカードエントリは、コミッショニング時に作成されても良く、追加設定なし（out-of-the-box）で使用可能な場合があり、又は未知の制約装置から第１のパケットを受信することによってトリガされる解決試行時に作成されても良い。ワイルドカードエントリは、受信される制約装置のメッセージから、転送に必要な全ての情報を得ることができる場合に使用されても良い。ワイルドカードエントリは、もしあればフィルタリング／処理に失敗した場合に何が起こるべきかも指定することができ、プロキシは、未処理で転送し、追加情報を提供し、又はフレームを削除するように命令され得る。ワイルドカードテーブルエントリは、専用テーブルエントリ内のデータに応じた処理がエラー、例えばセキュリティエラーを返す場合に使用されても良い。次いで、制約装置に関するブロードキャスト／マルチキャスト型クエリを送信することに加えて及び／又はその代わりに、制約装置のメッセージが未処理でワイルドカードトラフィックハンドラに転送され得る。ワイルドカードエントリが使用される場合、テーブルエントリの自動発見を完全に無効にすることを検討することができる。

この方法の別の実施形態では、制約ノードに関する情報が、その制約ノードに関する専用プロキシテーブルエントリを作成しない命令と共にプロキシに提供されても良い。それでもなお、この情報はプロキシによって有用に使用され得る。例えば、プロキシが未知の制約装置からのメッセージを聞き、クエリを送出する場合、ターゲット／ツールは、プロキシテーブルエントリを作成しない情報と共にプロキシテーブル情報で応答することができ、従ってプロキシは、元のトリガフレームを転送できるがエントリは作成しない。従って、プロキシは、とりわけ他のどのプロキシも制約装置のメッセージを転送していないことが認められる場合、自らのクエリに対する応答を受信したときに依然としてそのメッセージを転送できるように、制約装置のメッセージをしばらくの間バッファに入れることを要求され得る。ひいては、テーブルの正確な寿命が例えば時間又はパケット数の観点から指定されても良い。

上記の両方の実施形態が、幾つかの専用エントリ、装置の被選択クラスのための幾つかのワイルドカードエントリを有するプロキシ、及び残りの制約装置の発見と有益に組み合わせられても良い。

この方法の更に別の実施形態では、プロキシテーブルエントリが様々なエントリクラスに関する情報、例えばテーブルエントリがどのように作成されたのかを記憶する。そうすることは、自動的に発見されたエントリと明確に作成されたエントリとを区別すること、又は追加設定なしのエントリ、ツールによって作成されたエントリ、（例えばコミッショニング又は動作モードでのユニキャストメッセージによる）専用エントリ、及び（例えば動作モードのコミッショニングでのブロードキャスト／マルチキャストメッセージによる）冗長エントリを更に区別することを可能にし得る。エントリクラスは、例えば幾つかのフラグ又は列挙フィールドを用いて明確に符号化されても良く、それらは例えばリスト内のエントリの位置又は特定の情報があること若しくは無いことから得られても良い（例えば自動的に発見されるエントリでは、制約装置の種類を入手できない場合がある）。エントリクラスは、作成方法を示すことができ、又は意図されるエントリの保守挙動（例えば永続的なエントリフラグ、除去可能なエントリフラグ）を明確に示すことができる。異なるエントリクラスは異なる作成及び除去戦略を有することができ、例えばプロキシは「エントリ満杯」状態でツールの試行に応答してツールにそれを解決させることができ、又は例えばツールによって作成されるエントリはツールによってしか除去できず、自動的に発見されるエントリを置換の第一候補としても良い。

好ましくは、どの制約装置が専用プロキシテーブルエントリを必要とするのかに関する判断は、制約装置の特性に基づく。１つの基準は、報告頻度であり得る。非常に頻繁に通信する制約装置は、頻繁な発見／迂回ワイルドカードトラフィックを避けるために、専用のエントリを有することが好ましい。他の或る基準は、制約装置の遅延要件であり得る。そのメッセージが素早く処理される必要がある制約装置は、発見又はワイルドカード処理によって引き起こされる（予測不能な）遅延を回避するために、専用のエントリを有することが好ましい。典型的な例は、利用者によって制御される照明である。利用者は、自身のアクション後２００ミリ秒より遅くならずに照明コマンドが有効になること（又は感知できる他のフィードバックが与えられること）を予期する。他の或る基準は、信頼性要件であり得る。他の或る基準は、制約装置の機能、例えば受信も行う制約装置の機能であり得る。例えば制約装置が受信できない場合、プロキシがFirstToForward又はInRange状態を追跡するためでなく、パケット配信のために特定のプロキシを選び出す必要がない場合があり、そのため専用エントリが必要ないことがある。他の或る基準は、制約装置の移動パターンとすることができ、制約装置があまりに早く転々とする場合、専用プロキシテーブルエントリを作成し除去する意味が無い可能性がある。他の或る基準は、ペアにされたターゲットの数とすることができ、複数のターゲット群よりも単一のユニキャストターゲットを再発見することの方が良い場合がある。上記の基準の様々なものが有益に組み合わせられ得る。

判断は装置ごとに行われても良く、それには制約装置が、例えばコミッショニングプロセスにおける装置のドキュメンテーションの一部として、この情報を可読属性として又はそのパケットの一部として公開することを必要とし得る。この情報が最初に容易に入手できない場合、プロキシの既定（デフォルト）の挙動が指定される必要がある。制約装置の特性の一部は、制約装置の挙動をしばらくの間観測することによって得られても良い。或いは、例えば制約装置の種類／応用に基づく汎用規則があっても良い。例えば、全ての照明スイッチが専用エントリを必要とし得る一方で、温度センサについては専用エントリが決して作成されない場合がある。

どの制約装置の専用テーブルエントリを作成するのかの判断は、コミッショニング時に又は動作中にプロキシによって行われ得る。この判断は、シンク／ツールによって行われても良い。

ZigBee Green Power仕様における実装形態では、「ワイルドカード」プロキシテーブルエントリは、予約済みの／無効な／未指定の値（例えば0xffffffff）に設定されたZGPD SrcIDフィールド、及び／又はOptionsフィールドの現在予約されているサブフィールドのうちの「ワイルドカード」フラグとしての定義フィールド、を含む手段によって識別され得る。プロキシテーブルエントリの他の任意のフィールドが、検査及びフィルタリングに使用される特定値に、又はこの情報が受信時に無視されることを示す予約済みの／無効な／未指定の値に設定され得る。

とりわけ、OptionsフィールドのUnicast ZGPS、Derived Group ZGPS、及びCommissioned Group ZGPSサブフィールドは、設定される場合、ZGP Notificationが送信されるべき特定の種類のアドレスの可用性を示す。ユニキャストの場合、ZGP Tunneling Stop及び転送遅延を省くことが検討され得る。AssignedAliasサブフィールドが真に設定された状態で、ZGP Notification（及びZGP Tunneling Stop及び／又はZGP Commissioning Notification）コマンドの転送に使用されるためにAssignedAliasフィールドが提供されても良い。例えば偽に設定されたAssignedAliasサブフィールド、別のフラグ、又はZGPD SrcIDの異なる予約済みの値を利用することにより、得られたエイリアスを使用すること又はエイリアスを一切使用しないことを示す手段があり得る。SecurityUseサブフィールドは、偽に設定される場合、セキュリティ検査が行われないことを示し得る。SecurityUseサブフィールドは、真に設定される場合、Security Optionフィールド及び残りのセキュリティ関連フィールドのサブフィールドによって指定される範囲内でセキュリティ処理を行う要求を示し得る。セキュリティレベルは、0b00以外の値に設定される場合、最低限の又は所要のセキュリティレベルを示し得る。キータイプは、0b000以外の値に設定される場合、使用するための所要のキーの種類を示すことができ、キーフィールドが存在し得る。ＺＧＰＤセキュリティフレームカウンタは、全てのワイルドカードＺＧＰＤに関する最低許容値を示すために使用されても良く（及び例えばプロキシ内で定期的に更新されても良く）、その使用は0xffffffff又は0x00000000以外の値によって、及び／又はOptionsフィールドのシーケンス番号機能サブフィールドを真に設定することによって示され得る。

上記の内容は、シンクテーブルに基づく転送機能の能力があるシンクのシンクテーブルエントリにも等しく当てはまる。既定の場合又は構成される場合、ZGPD Command Translation Tableエントリがマッチングロジックを有することに、即ちワイルドカードエントリが既定の又は特定のエントリと混同されないように注意が払われなければならない。

ＺＧＰＤ情報を使用するが、プロキシテーブルエントリは作成しないようにプロキシに命令するために、シンク／ツールは、好ましくはZGP PairingコマンドのDeviceIDフィールドを無効な／予約済みの値、例えば0xffに設定でき、ZGP PairingコマンドのOptionsフィールドの最後の予約済みサブフィールドが、このＺＧＰＤのプロキシテーブルエントリの作成を要求／禁止するように定められても良く、将来更に修正できるようにするためにOptionsフィールドが１６ビット値に拡張されても良い。同じことが、シンクテーブルに基づく転送を行えるシンク内のシンクテーブルの作成に当てはまり、その後、ZGP Configure Pairingコマンドに変更が加えられなければならない。

更なる実施形態では、ワイルドカードエントリがＺＧＰＤコミッショニング動作に使用されても良く、例えばリセット時に及び構成データを失ったときにＺＧＰＤが最初に使用し又は頼ることができる、事前に設定された／フォールバック／既定のOOB ZGPDセキュリティキー、又は事前に設定された／フォールバック／既定のZGPD TC-LKを記憶することができる。ブロードキャストシンクアドレスと組み合わせられる場合、これは標準のＺＧＰプロキシに基づくコミッショニング手続きを支援し、但しセキュリティ保護され、平文でキーを交換する必要がない可能性がある。例えばZigBee Trust Centre、ZigBee Coordinator、ZigBee Network Manager、又は他の種類のコントローラ／マネージャノード等の集中保守装置のアドレスを保持するプロキシテーブル及び／又はシンクテーブル内のユニキャスト／グループキャストアドレスと組み合わせられる場合、ZigBee Smart Energy1.0仕様又はZigBee Home Automation1.2仕様の中で論じられているように、これはアクセス制御リストを使用すること及び／又はインストールコードを使用することを可能にし得る。同じことが、一時的エントリ又は非作成エントリに当てはまる。

エントリのクラスを示すために、プロキシテーブルは、Optionsフィールドの（ＺＧＰ内の）現在予約済みサブフィールドを利用することができる。自動化された保守手続きによって除去されるべきでないエントリを示すために、サブフィールドPermanentEntry／CTentryを追加することができる。加えて／代わりに、エントリが自動的に作成され、自動化された保守手続きによって除去されても良いことを示すためにサブフィールドAutoDiscoveredEntryが追加されても良い。

一部の実施形態、例えばIP/6lowpanベースネットワークでは、プロキシがワイルドカードテーブルエントリで初期設定される必要がない場合があり、かかるエントリは、任意の構成ツール又はシステムが適用される前に初期設定で全てのプロキシ内にあり得る。6lowpanネットワークでは、既定のエントリが境界ルータのアドレス、又は6lowpanサブネット内の別の明確なネットワークアドレスを示し得る。
（１’／２’／３’／６’）

プロキシが自らのテーブルを消去するための１つの解決策は、以下の通り、プロキシが直接受信し損なった制約装置からのパケット数に少なくとも部分的に基づく信頼性指標を考慮することである。

一実施形態では、現在のパケットカウンタと、Ｐｘが直接観測した制約装置からの最後のパケットのパケットカウンタとの差として、各プロキシＰｘが信頼性指標を自らのテーブル内の制約装置Ｒｘごとに計算する。その差が大きければ大きいほど、そのエントリを除去することがより望ましくなる。

別の実施形態では、率Ratio(Rx)=RL/RRとして、各プロキシＰｘが自らのテーブル内の制約装置Ｒｘごとにサービス率を計算し、ＲＬは時点Ｔ以降ＰｘがＲｘのプロキシとして動作した回数であり、ＲＲはＴ以降の期間Ｔ内でＲｘがメッセージを送信した回数である。この実施形態は、処理されたメッセージのカウンタＲＬをプロキシが保つことを必要とする。この実施形態の改変形態では、除去する装置を決定するために、ＬＲＵデータと率データとの組合せが使用される。正確な率を計算する必要がない場合、率を概算する様々な方法が使用され得る。

制約装置が単調な値（monotonous values）を維持することができる場合、値ＲＲは、制約装置のパケットに由来するシーケンス番号／フレームカウンタに等しく又はそこから得られても良い。或いは、制約装置が単調な値を維持できない場合、本発明は、システムがＲｘからメッセージを受信するたびに増やされるＲｘの「仮想」メッセージカウントを１つ又は複数の装置が維持することを要求する。ターゲットは能力がある全てのプロキシによって転送される制約装置のメッセージを受信するはずなので、好ましい実施形態では、ペアにされたターゲットの少なくとも１つの中でパケットカウントが保たれる。

サービス率を計算するためのアルゴリズムは以下のように実装され得る。
アルゴリズムＡ（プロキシの率を計算するために、そのプロキシ内で実行される）
Px Initalisation（プロキシテーブルエントリの作成時）
LAST_SEQx:=「プロキシテーブルエントリの作成時に提供される通り（さもなければ：none）」
COUNTx:=0; //制約装置と直接対話した結果プロキシテーブルエントリが作成された場合、制約装置のパケットが既にカウンタであり得る
（ＰｘがSEQiと共に制約装置ＲｘからメッセージＭｉを直接受信する）とき、
（制約装置が増分シーケンス番号を実装し、且つLAST_SEQx=noneである）場合、
LAST_SEQx:=SEQi;
COUNTx:=COUNTx+1;
（ＰｘがSEQiの値を含む状態メッセージを受信する）とき、
ＰｘはRatio(Rx):=COUNTx/(受信されたSEQi-LAST_SEQx)を計算し、
LAST_SEQx:=受信されたSEQi;
COUNTx:=0;

アルゴリズムＡ１
このアルゴリズムの改変形態では、変数Ratio(Rx)をまずゼロに初期設定し、次式
○Compute Ratio(Rx):=Ratio(Rx)/2+(COUNTx/(受信されたSEQx-LAST_SEQx))/2
を使用する。

この式には、率に関するより長い履歴「メモリ」を計算する利点がある。

アルゴリズムＢ（プロキシの率を計算するために、そのプロキシ内で実行される）
Px Initalisation:
FIRST_STATUS_SEQx=「プロキシテーブルエントリの作成時に提供される通り（さもなければ：none）」
COUNTx:=0;
（ＰｘがSEQiと共に制約装置ＲｘからメッセージＭｉを直接受信する）とき、
（制約装置が増分シーケンス番号を実装し、且つFIRST_SEQx=noneである）場合、
FIRST_SEQx=SEQi;
COUNTx:=COUNTx+1;
（ＰｘがSEQiの値を含む状態メッセージを受信する）とき、
Ratio(Rx):=COUNTx/(SEQi-FIRST_STATUS_SEQx);
（FIRST_STATUS_SEQx=='none'である）場合、
FIRST_STATUS_SEQx=SEQi;

アルゴリズムＣ：
Px Initalisation:
LAST_SEQx=「プロキシテーブルエントリの作成時に提供される通り（さもなければ：none）」
（ＰｘがSEQiの値と共に制約装置ＲｘからメッセージＭｉを直接受信する、又はＰｘがSEQiの値を含む状態メッセージを受信する）とき、
MISS=LAST_SEQx-SEQi;
LAST_SEQx=SEQi;

Ｐ１やＰ２等、Ｒ１の範囲内にあるプロキシ装置では、Ｒ１からのメッセージを単にリスンし、直接受信されるメッセージをカウントし続けて率の公式の右側ＲＲを概算することにより、率（Ｒ１）（の良好な近似値）を計算するのは簡単なことである。ＲＬは、プロキシがＲ１に対してどこに位置しても、どのプロキシについても容易に追跡できる。

Ｐ３等、Ｒ１の範囲外にあるプロキシ装置、範囲の縁のどこかにある装置、又はＲ１への非常に信頼できないリンクを有する装置では、現在のパケットカウンタ値／ＲＲを知ることは不可能又は簡単／確実ではない。

従って本発明者らは、以下の新規且つ独創的手段を提案する。Ｒｘの現在のパケットカウンタ／ＲＲの知識を有するネットワーク内の少なくとも１つの装置が状態メッセージを伝送し、この状態メッセージは、受信側プロキシが自らの率（Ｒｘ）を求めること、又は自らのプロキシテーブルの消去に関係する他の計算を行うことを可能にする。

この方法の一態様として、状態メッセージはプロキシテーブルの保守に充てられるメッセージであり、少なくともペアにされたターゲットによって送信され得る。状態メッセージは定期的に送信されても、特定の事象時に送信されても良い。更に、メッセージの伝送は、ネットワーク変化のダイナミクス（制約ノード、シンク、及び／又はプロキシの移動性を含む）、シンクとペアにされた制約装置の数、ネットワーク上の／シンク／プロキシの全体的なトラフィック負荷を含む他の基準に依存しても良い。この基準は、制約装置の通信頻度、制約装置の応用、及び／又は最後の更新以降に受信されたメッセージ数を更に含むことができ、制約装置がその後最低パケット数を送信しなかった場合はタイムトリガ型の更新を送信する意味が無い可能性があり、最低数はプロキシ閾値基準に対応することが好ましい。送信は１つ又は全てのペアにされたターゲットによって独立に若しくは連携して行われても良く、別のターゲットからのアナウンスが受信される場合、送信は削除／延期されても良い。

状態メッセージは、ターゲットに知られている場合、限られたホップカウント範囲でブロードキャスト、マルチキャストで送信されても良く、又はターゲットに知られている場合、被選択プロキシにユニキャストで送信されても良い。ここでのターゲットは、制約装置のメッセージを実行する装置（例えば制約された照明スイッチ又は人感センサのコマンドに反応するランプ）であり得る。ターゲットは、制約装置のメッセージを処理する装置、例えば（例えば傾向分析、データマイニング、又はクエリのためにメッセージを記憶するための）キャッシュ、ツール、ネットワーク中央装置、又はデータを別のシステム内に転送するブリッジ／ゲートウェイ／境界型の装置でも良い。有益には、この状態メッセージは、プロキシテーブルを初期設定（又はコミッショニング）するためにネットワークシステムによって使用されるメッセージと非常に似ており、又は同一である。従って、ネットワークノード内で必要なソフトウェアコードの量が減らされ、これらのノードがより安価に製造されることが可能になる。この方法の別の態様では、プロキシテーブルの保守に充てられる状態メッセージの送信が要求され得る。状態メッセージは、例えばプロキシテーブル情報を要求するプロキシによって要求されても良く、これは、この及び他のプロキシが自らのプロキシテーブルをしかるべく更新できるようにする。状態メッセージは、タイマ、例えばエントリ寿命タイマ（即ちエントリの作成／最後の検証からの時間）又は活動タイマ（即ちエントリが最後に使用されてからの時間）に基づいて要求されても良い。

ZigBee Green Power規格の実装形態では、本発明者らは、コードを再利用する利益を享受するために、SEQxを有する状態メッセージとして使用され得る、Security Frame Counterフィールドを既に含む既に規定されているZGP Pairingメッセージの使用を提案する。ZGP Pairingメッセージの送信は、ＺＧＰＳによって定期的に又は或る事象時に、例えばZGP Pairing Searchコマンドや、（潜在的に）期限切れのプロキシテーブルエントリを有するプロキシを示すブロードキャストZGP Notificationコマンドの受信時にトリガされても良い。

（SecurityLevel=0b00、及びMACcapabilities=0b0によって示されるように）セキュリティに対応しておらず、増分ＭＡＣシーケンス番号を送信できないＺＧＰＤのプロキシテーブルエントリの信頼性指標の計算を可能にするために、ＺＧＰＳは、自らのシンクテーブルエントリのSecurity Frame Counterのパラメータをインクリメントし、その値をZGP Pairingコマンド内に含めて提供することを要求される。同様に、プロキシは（SecurityLevel=0b00、及びMACcapabilities=0b0の場合）かかるSecurity Frame Counterを新しさの指標としてではなくプロキシテーブルを保守するための手段として扱い、即ちプロキシは受信されるＧＰＤＦのＭＡＣシーケンス番号の値をプロキシテーブル内に記憶される値と比較すべきでない。

ZGP Pairingメッセージを受信すると、プロキシはそのＲｘの信頼性指標を計算するものとする。信頼性指標が閾値を下回る場合、プロキシはプロキシテーブルエントリを除去しても良い。シンクテーブルに基づく転送を行えるＺＧＰＳでは、ZGP Configure Pairingメッセージがその目的で使用される。

例えば制約装置、ＺＧＰＤ及び／又はネイティブＩＰ制約装置、並びにＩＰ対応プロキシを含む、6LoWPANベースのＩＰネットワークにおけるＩＰベースの実装形態では、制約装置のメッセージを転送するためのＩＰベースのメッセージが装置であり得る。とりわけ、上記で定められた情報をＣｏＡＰペイロード内で運ぶために、ＣｏＡＰユニキャスト又はマルチキャストメッセージが使用されても良い。

この方法の更なる態様では、少なくとも１つのプロキシがパケットカウンタ値を状態メッセージ内で共有することができ、メッセージの形式は前の２つの態様の形式と同じでも異なっても良い。この共有は、好ましくはローカルブロードキャスト又はグループキャスト／マルチキャストとして行われる。この共有は、１つの被選択プロキシによって、一定の信頼率基準を満たすプロキシによって、又はＲｘのプロキシテーブルエントリを有する所与の範囲／セグメント内の全てのプロキシによって、定期的に又は或る事象時に行われても良い。その一部として、プロキシは、絶対的ではなく相対的なプロキシテーブル除去基準を確立するために自らの信頼性指標をやり取りすることができ、例えばプロキシは、より優れた信頼性を有するＮ個のプロキシがある場合にのみ自らのテーブルエントリを除去する。こうすることは、全てのプロキシが制約装置からの相当な数のパケットを失う非常に悪い通信環境でさえ、幾つかのプロキシが相変わらずアクティブのままであることを確実にする。

ZigBee Green Power規格の実装形態では、本発明者らは、プロキシがプロキシテーブルエントリをやり取りし、それによりコードを再利用する利益を享受することを提案する。プロキシは、完全なテーブルコンテンツを、又は好ましくは選択されたエントリだけをやり取りすることができる。プロキシは、エントリを定期的に又は好ましくは或る事象（例えば或るプロキシが低い／低下している信頼性指標を計算する）時にやり取りすることができる。テーブルのやり取りは、好ましくはZCL Read Attributesコマンド内で、エイリアスなしに２ホップブロードキャスト／グループキャストによってトリガされる。トリガリングプロキシを含むプロキシは、含まれる／全てのＺＧＰＤに関する自らのプロキシテーブルエントリと共に、ZCL Read Attributes Responseによって同じ方法（ブロードキャスト／グループキャスト）で応答する。或いは、プロキシは自らのテーブルを単一／２ホップブロードキャスト／グループキャストとしてZCL Attributes Report内で報告しても良い。シンクテーブルに基づく転送機能の能力があるシンクも、自らのシンクテーブルエントリを同じ方法でやり取りする。

或いは、媒体の使用量を減らすために、データ量が関連データだけに減らされる新たなテーブル保守コマンドが定義されても良い。例えばそのコマンドは、SrcID、（仮想）セキュリティフレームカウンタ、及び信頼性指標を含むことができる。そのコマンドは、例えばどのテーブルエントリが報告されるべきか（含まれているSrcIDだけ、全てのテーブルエントリ、不明瞭な状態の全てのテーブルエントリ）を示す幾つかのオプションフラグを更に含むことができる。そのコマンドは、シンクとプロキシとの間の信頼性データのやり取りも可能にすることができる。

ZGP Pairingメッセージを受信すると、プロキシはそのＲｘの信頼性指標を計算するものとする。自らの信頼性指標が閾値を下回る場合、プロキシはプロキシテーブルエントリを除去しても良い。閾値は、実装に固有であり、ＺＧＰ規格内で定められ、プロファイル固有のベストプラクティスである、又は設定可能なパラメータとすることができる。他の装置の信頼性指標が含まれる場合、特定のテーブルエントリを除去することを決定する前にその信頼性指標が考慮されても良い。

例えば制約装置、ＺＧＰＤ及び／又はネイティブＩＰ制約装置、並びにＩＰ対応プロキシを含む、6LoWPANベースのＩＰネットワークにおけるＩＰベースの実装形態では、本発明者らはプロキシがテーブルエントリをやり取りできることも提案し、エントリの形式はＩＰベースの実装形態では異なる。これらのテーブルエントリは、例えばＤＮＳクライアントとして動作するプロキシによってＤＮＳから、又は等価の発見メカニズム（例えばＲＤ）を使用して前に要求された制約装置のキャッシュ済み記録を含むことができる。テーブルのやり取りは、単一ホップ又は２ホップＩＰマルチキャスト、例えばペイロードを有するＣｏＡＰマルチキャストＰＯＳＴ要求によってトリガされ得る。プロキシは、ＩＰマルチキャストを使用して同じ方法で、例えばＰＯＳＴに対するＣｏＡＰマルチキャスト応答又は別個の（新たな）ＣｏＡＰＰＯＳＴ要求で応答する。或いは、たった今説明した方法のうちの１つでＩＰマルチキャストによって送信される、信頼性に関連する情報だけを好ましくは運ぶ、新たなテーブル保守コマンドが定義されても良い。ZigBee Green Powerの場合と同様に信頼性の計算が行われ得る。

この方法の更に別の態様では、状態メッセージが、現在のパケットカウンタ／ＲＬの値を依然として得ることを可能にするネットワーク内の通常の通信パケット、例えば同じ制約装置の代わりに他のプロキシによって転送されるパケットである。この実施形態には、専用通信を必要としない付加利益がある。

ZigBee Green Power規格の実装形態では、本発明者らは、プロキシが（例えばInRange及びFirstToForwardを設定する）信頼性及びプロキシテーブルの保守目的で既に受信しているZGP Tunneling Stopコマンド及びZGP Notificationコマンドを、プロキシテーブルエントリの除去にも利用することを提案する。プロキシが（仮想）セキュリティフレームカウンタを有するZGP Notificationを受信する場合、プロキシは信頼性指標を計算すべきであり、信頼性指標が閾値を下回る場合、プロキシは（FirstToForward／InRangeフラグを設定する代わりに／それに加えて）そのエントリを除去することを検討すべきである。

更に本発明者らは、プロキシが、他の転送プロキシによって送信されるZGP Notification内で受信されるDistanceフィールドの値を比較することを提案する。そのために、プロキシは例えば最後に受信されたフレームについての、又は好ましくは或る期間にわたって平均された、ＺＧＰＤに関する自らのDistance値をローカルに記憶する必要があり得る。プロキシが、より優れたDistance値を有する他の幾つかのプロキシを認める場合、とりわけ自らの信頼性指標が低い場合、そのプロキシは、転送を控え（ＧＰＤＦも直接受信された場合）、FirstToForwardを偽に設定する代わりに／それに加えて、プロキシテーブルエントリを除去することに決めることができる。ユニキャスト転送の場合にもそれを促進するために、ZGP Tunneling StopコマンドがDistanceフィールドで拡張されることが推奨される。ZGP Notification及びZGP Tunneling Stopのどちらも信頼性指標フィールドでも拡張され得る。

ユニキャストの場合にもプロキシがFirstToForwardプロキシの識別情報を求めることを可能にするために、ZGP Tunneling Stopはエイリアスなしに送信され得る。

或いは、ＮＷＫヘッダホップカウントフィールドがその初期値（例えばZGP Tunneling Stopでは２）を有する場合、プロキシはＭＡＣソースアドレスから、ZGP Tunneling Stop／ZGP Notification／ZGP Commissioning Notificationの元の送信者を突き止めることができる場合がある。

シンクテーブルに基づく転送を行えるシンクにも同じことが当てはまり得る。

更に、プロキシＰｘが未知のZGPD SrcIDからＧＰＤＦを直接受信し、ZGP Tunneling Stopコマンド及び／又はZGP Notificationコマンドを１つ若しくは複数の他のプロキシから受信する場合、とりわけそれらのプロキシが良い／より優れた信頼性指標及び／又はDistanceフィールドの値を有する場合、ＰｘはZGP Pairing Searchコマンドの送信及びプロキシテーブルエントリの作成を控えることができる。

上記の様々な方法が有利に組み合わせられても良い。

上記の全ての方法について、テーブルを除去するための閾値は、実装に固有であり、ＺＧＰ規格内で定められ、プロファイル固有のベストプラクティスである、又は設定可能なパラメータとすることができる。

上記の全ての方法について、その後の再発見を防ぐために、プロキシは、プロキシテーブルエントリを除去しながらZGPD SrcIDを別のリスト内に記憶することができる。リストは、zgppBlockedSrcIDs属性とすることができる。リストは、好ましくは、ネットワークの一部であるが、このプロキシが転送すべきでないＺＧＰＤを記憶する別個の属性でも良い。

例えば制約装置、ＺＧＰＤ及び／又はネイティブＩＰ制約装置、並びにＩＰ対応プロキシを含む、6LoWPANベースのＩＰネットワークにおけるＩＰベースの実装形態では、制約装置のメッセージが、プロキシ間の通信だけを目的とする場合は例えば限られたＴＴＬ／ホップカウントを有するＩＰｖ６マルチキャストＣｏＡＰＰＯＳＴ要求として、又は例えばObserveオプションを有するＩＰｖ６ユニキャストＣｏＡＰＧＥＴ応答として転送され得る。これらは、他のプロキシによって受信される場合、上記のようにプロキシテーブルエントリを除去するために使用され得る。

好ましくは、状態メッセージは、専用である場合、通常のシステム動作に最も影響しないときにやり取りされる。例えばオフィスビルでは、更新が就業時間外／就業日以外にスケジュールされ得る。

特許請求の範囲に記載の本発明を実施する際、図面、本開示、及び添付の特許請求の範囲を検討することにより、開示された実施形態に対する他の改変形態が当業者によって理解され、もたらされ得る。特許請求の範囲では、「含む」という語は、他の要素又はステップを排除せず、不定冠詞「a」又は「an」は複数形を排除しない。特許請求の範囲の中で列挙される幾つかのアイテムの機能を単一のプロセッサ又は他のユニットが果たしても良い。或る手段が互いに異なる従属請求項の中で列挙されているという単なる事実は、これらの手段の組合せが有利に使用されてはならないことを示すものではない。

上記の説明は、本発明の特定の実施形態を詳述している。但し、上記の内容が本文内で如何に詳しく説明されていても、本発明は多くの方法で実施されても良く、従って開示された実施形態に限定されないことが理解されよう。本発明の或る特徴又は態様を説明するときに特定の用語を使用することは、その用語が関連する本発明の特徴又は態様の任意の具体的特性を含むべく制約されるように、その用語が本明細書で再定義されることを含意すると解釈されるべきではないことに留意すべきである。

Claims

プロキシノードにおいてプロキシテーブルを管理する方法であって、
（ａ）前記プロキシノードが、第１の資源制約装置からメッセージを受信し、前記メッセージは少なくとも１つの対応する宛先装置を対象とし、
（ｂ）前記プロキシノードが、プロキシテーブルの１組のプロキシテーブルエントリを含む前記プロキシテーブルに基づいて前記メッセージを前記宛先装置に転送し、前記プロキシテーブルの前記１組のプロキシテーブルエントリは、前記プロキシノードが前記対応する宛先装置にメッセージの転送を行う１組の資源制約装置を示し、前記１組のプロキシテーブルエントリの少なくとも１つのプロキシテーブルエントリがエントリクラスの指標を含み、
前記エントリクラスが、
前記プロキシテーブルエントリの作成を引き起こした作成方法、
前記プロキシ若しくは前記プロキシ内のプロキシテーブルエントリを管理する別の装置が前記プロキシテーブルエントリに適用しなければならないエントリの保守挙動、又は
前記資源制約装置の特性
のうちの少なくとも１つを示し、
（ｃ）前記プロキシノードが、前記エントリクラスに基づいて前記１組のプロキシテーブルエントリを管理する、
方法。
前記プロキシノードが、前記エントリクラスに対応する作成及び除去戦略に基づいて前記１組のプロキシテーブルエントリを管理する、請求項１に記載の方法。
前記プロキシテーブルエントリの位置が、前記エントリクラスの前記指標である、請求項１又は２に記載の方法。
プロキシノードにおいてプロキシテーブルを管理する方法であって、
（ａ）前記プロキシノードが、第１の資源制約装置からメッセージを受信し、前記メッセージは少なくとも１つの対応する宛先装置を対象とし、
（ｂ）前記プロキシノードが、前記プロキシテーブルの１組のエントリ内に前記第１の資源制約装置のエントリが含まれているかどうかを確認し、前記プロキシテーブルの前記１組のエントリは、前記プロキシノードが前記対応する宛先装置にメッセージの転送を行う１組の資源制約装置を示し、
（ｃ）ステップ（ｂ）における前記プロキシテーブルの確認結果に応じて、前記プロキシノードは、前記プロキシテーブルが１組の制約装置に対応する「ワイルドカード」エントリを有するかどうかを確認し、
（ｄ）ステップ（ｂ）又は（ｃ）における前記プロキシテーブルの確認結果に応じて、前記プロキシノードが前記メッセージを転送する、
方法。
プロキシノードにおいてプロキシテーブルを管理する方法であって、
（ａ）前記プロキシノードが、第１の資源制約装置からメッセージを受信し、前記メッセージは少なくとも１つの対応する宛先装置を対象とし、
（ｂ）前記プロキシノードが、前記プロキシテーブルの１組のエントリ内に前記第１の資源制約装置のエントリが含まれているかどうかを確認し、前記プロキシテーブルの前記１組のエントリは、前記プロキシノードが前記対応する宛先装置にメッセージの転送を行う１組の資源制約装置を示し、
（ｃ）ステップ（ｂ）における前記プロキシテーブルの確認結果に応じて、前記プロキシノードが前記メッセージを転送し、
（ｄ）前記プロキシノードが、少なくとも前記資源制約装置に関係するエントリについて、前記資源制約装置のメッセージを転送するための競合プロキシノードの使用に対する、前記資源制約装置のメッセージを転送するための前記エントリの相対的使用をモニタし、前記エントリを保ち、修正し、又は除去することに決める、
方法。
ステップ（ｄ）は、前記プロキシノードが、前記プロキシノードによって転送される前記第１の資源制約装置からのメッセージ数を、競合プロキシノードによって転送される前記第１の資源制約装置からのメッセージ数と比較するステップを含む、請求項５に記載の方法。
ステップ（ｃ）において、前記プロキシノードが、前記プロキシテーブルの第１の資源制約ノードに対応する前記エントリにおいて前記メッセージのシーケンス番号を記憶し、ステップ（ｄ）が、
前記宛先装置において最後に受信され、前記資源制約装置から生じた前記メッセージの前記シーケンス番号を示すメッセージを前記宛先装置から受信するステップと、
前記宛先装置において最後に受信された前記メッセージの前記シーケンス番号を、前記プロキシテーブル内に記憶された前記シーケンス番号と比較するステップと、
前記比較の結果に基づいて前記エントリを消去するステップと
を含む、請求項６に記載の方法。
ステップ（ｃ）において、前記プロキシノードが、前記プロキシテーブルの第１の資源制約ノードに対応する前記エントリにおいてカウンタをインクリメントし、ステップ（ｄ）が、
（ｄ１）前記宛先装置において受信され、前記資源制約装置から生じたメッセージの総数を示すメッセージを前記宛先装置から受信するステップと、
（ｄ２）前記宛先装置において受信された前記メッセージの総数を、前記プロキシテーブル内の前記カウンタと比較するステップと、
（ｄ３）前記比較の結果に基づいて前記エントリを消去するステップと
を含む、請求項６に記載の方法。
（ｄ２）の後、前記第１の資源制約ノードに対応する前記エントリにおいて前記カウンタが現在の状態にありながら、前記プロキシノードが再開するステップを更に含む、請求項８に記載の方法。
ステップ（ｃ）において、前記プロキシノードが、前記プロキシテーブルの第１の資源制約ノードに対応する前記エントリにおいて、前記資源制約装置と前記プロキシノードとの間の通信リンク品質を示す第１の品質指標を記憶し、ステップ（ｄ）が、
前記資源制約装置と前記競合プロキシノードとの間の前記通信リンク品質を示す第２の品質指標を含むメッセージを少なくとも１つの競合プロキシノードから受信するステップと、
前記第１の品質指標を、前記第２の品質指標と比較するステップと、
前記比較の結果に基づいて前記エントリを消去するステップと
を含む、請求項５に記載の方法。
前記第１の品質指標及び前記第２の品質指標が、前記プロキシノード及び前記競合プロキシノードのそれぞれにおける受信信号強度から得られる、請求項１０に記載の方法。
前記第１の品質指標及び前記第２の品質指標が、前記資源制約装置から生じるメッセージ数に対する、前記資源制約装置の代わりに前記第１の及び前記第２のプロキシによって転送されるメッセージの数及び／又は時間分布から得られる、請求項１０に記載の方法。
前記エントリを消去する前記ステップは、前記第１の品質指標よりも優れた品質指標を有する競合プロキシノードの数が少なくとも閾値に等しいことを前記プロキシノードが見出した後に実行される、請求項１０乃至１２の何れか一項に記載の方法。
ステップ（ｄ）は、前記プロキシノードが少なくとも１つの競合プロキシノードからメッセージを受信するステップと、前記プロキシノードが競合プロキシノードの数を数えるステップとを含み、前記プロキシノードは前記競合プロキシノードの数に少なくとも部分的に基づいて前記プロキシテーブルを消去する、請求項５乃至１３の何れか一項に記載の方法。
前記プロキシノードの消去ステップ（ｄ）が、
− 前記第１の資源制約装置の前記エントリを前記プロキシテーブルから除去するステップ、
− 前記プロキシテーブルからの前記第１の資源制約装置に関する前記エントリが使用されていないことを前記プロキシテーブル内で示すステップ、又は
− 存在しない場合、前記プロキシテーブルからの前記第１の資源制約装置の新たなエントリの作成を控えるステップ
のうちの少なくとも１つを実行するステップを含む、請求項５乃至１４の何れか一項に記載の方法。
第１の資源制約装置からメッセージを受信するための受信機であって、前記メッセージは少なくとも１つの対応する宛先装置を対象とする、受信機と、
プロキシテーブルの１組のプロキシテーブルエントリを含む前記プロキシテーブルを記憶するための記憶手段であって、前記プロキシテーブルの前記１組のプロキシテーブルエントリは、前記プロキシノードが前記対応する宛先装置にメッセージの転送を行う１組の資源制約装置を示し、前記１組のプロキシテーブルエントリの少なくとも１つのプロキシテーブルエントリがエントリクラスの指標を含む、記憶手段と、
前記プロキシテーブルに基づいて前記メッセージを前記宛先装置に転送するための送信機と、
前記エントリクラスに基づいて前記１組のプロキシテーブルエントリを管理するための管理手段と
を含むプロキシノードであって、
前記エントリクラスが、
前記プロキシテーブルエントリの作成を引き起こした作成方法、
前記プロキシ若しくは前記プロキシ内のプロキシテーブルエントリを管理する別の装置が前記プロキシテーブルエントリに適用しなければならないエントリの保守挙動、又は
前記資源制約装置の特性
のうちの少なくとも１つを示す、プロキシノード。
プロキシテーブルを管理するための手段と、
第１の資源制約装置からメッセージを受信するための受信機であって、前記メッセージは少なくとも１つの対応する宛先装置を対象とする、受信機と、
前記プロキシテーブルの１組のエントリ内に前記第１の資源制約装置のエントリが含まれているかどうかを確認するための制御手段であって、前記プロキシテーブルの前記１組のエントリは前記プロキシノードが担当する１組の資源制約装置を示す、制御手段と、
前記プロキシテーブルの確認結果に応じて前記メッセージを転送するための送信機と
を含むプロキシノードであって、
前記プロキシテーブルを管理するための前記手段が、前記資源制約装置のメッセージを転送するための競合プロキシノードの使用に対する、前記資源制約装置のメッセージを転送するための前記プロキシノードの相対的使用をモニタすることにより、前記資源制約装置に関連する前記エントリを前記プロキシテーブルから消去する、
プロキシノード。
プロキシノードにおいてプロキシテーブルを管理する方法であって、
（ａ）前記プロキシノードが、第１の資源制約装置からメッセージを受信し、
前記メッセージは少なくとも１つの対応する宛先装置を対象とし、
（ｂ）前記プロキシノードが、前記プロキシテーブルの１組のエントリ内に含まれる前記第１の資源制約装置のエントリで、前記プロキシテーブルが更新される必要があるという指示を前記メッセージが含むかどうかを確認し、
（ｃ）前記プロキシノードが前記メッセージを転送し、
前記プロキシノードが、ステップ（ｂ）に基づいて前記プロキシテーブル内に新たなエントリを作成するのを控える、
方法。
プロキシノードにおいてプロキシテーブルを管理する方法であって、
（ａ）前記プロキシノードが、第１の資源制約装置からメッセージを受信し、前記メッセージは少なくとも１つの対応する宛先装置を対象とし、
（ｂ）前記プロキシノードが、前記プロキシテーブルの１組のエントリ内に前記第１の資源制約装置のエントリが含まれているかどうかを確認し、前記プロキシテーブルの前記１組のエントリは、前記プロキシノードが前記対応する宛先装置にメッセージの転送を行う１組の資源制約装置を示し、
（ｃ）ステップ（ｂ）における前記プロキシテーブルの確認結果として存在しないと判定すると、前記メッセージをバッファに入れてクエリパケットを送信し、
（ｄ）前記プロキシテーブルのエントリが更新される必要があるかどうかの指示を含む応答メッセージを受信し、前記プロキシテーブルの前記エントリは前記プロキシノードが転送を行う１組の資源制約装置を示し、
（ｅ）前記応答メッセージ内の前記指示の内容に応じて、前記プロキシノードが前記プロキシテーブル内に新たなエントリを作成する、
方法。