特許 5698372 マシン間アプリケーションベース輻輳制御のシステム及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5698372

(24)【登録日】2015年2月20日

(45)【発行日】2015年4月8日

(54)【発明の名称】マシン間アプリケーションベース輻輳制御のシステム及び方法

(51)【国際特許分類】

   H04W 28/14 20090101AFI20150319BHJP

   H04L 12/801 20130101ALI20150319BHJP

   H04Q 9/00 20060101ALI20150319BHJP

【ＦＩ】

   H04W28/14

   H04L12/801

   H04Q9/00 311H

【請求項の数】14

【全頁数】13

(21)【出願番号】特願2013-535254(P2013-535254)

(86)(22)【出願日】2011年9月21日

(65)【公表番号】特表2014-504461(P2014-504461A)

(43)【公表日】2014年2月20日

(86)【国際出願番号】CN2011079923

(87)【国際公開番号】WO2012055307

(87)【国際公開日】20120503

【審査請求日】2013年5月24日

(73)【特許権者】

【識別番号】509105455

【氏名又は名称】ファーウェイ テクノロジーズ カンパニー リミテッド

(74)【代理人】

【識別番号】100079049

【弁理士】

【氏名又は名称】中島 淳

(74)【代理人】

【識別番号】100084995

【弁理士】

【氏名又は名称】加藤 和詳

(74)【代理人】

【識別番号】100085279

【弁理士】

【氏名又は名称】西元 勝一

(72)【発明者】

【氏名】アハメド ハナン

(72)【発明者】

【氏名】ジャルカ ビブホール

(72)【発明者】

【氏名】マオ ロナルド シュチョアン

(72)【発明者】

【氏名】ワン リメイ

(72)【発明者】

【氏名】コルバン エリック

【審査官】 石原 由晴

(56)【参考文献】

【文献】 国際公開第２０１０／１０２０８２（ＷＯ，Ａ１）

【文献】 特表２０１２−５２００２１（ＪＰ，Ａ）

【文献】 特開昭６２−１８５４２６（ＪＰ，Ａ）

【文献】 特開平０７−３２７０９０（ＪＰ，Ａ）

【文献】 特開２００５−２１０３６０（ＪＰ，Ａ）

【文献】 特開２００８−０９７６０３（ＪＰ，Ａ）

【文献】 特開２００７−３０４７０２（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００７／０２４２６８８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４−７／２６

Ｈ０４Ｗ ４／００−９９／００

Ｈ０４Ｌ １２／８０１

Ｈ０４Ｑ ９／００

(57)【特許請求の範囲】

【請求項1】

イベントを検出し、
前記イベントの報告をキューイングするかどうかを判定し、
前記イベントの報告をキューイングすると判定されたら、ある期間にわたって待機し、
判定を繰り返すこと
を含み、
前記イベントの報告をキューイングするかどうかを判定することは、
少なくとも部分的に前記イベントのタイプに基づいて前記イベントの報告をキューイングするかどうかを判定することを含み、前記イベントのタイプは、ローカルイベント及び共有イベントを含み、
前記少なくとも部分的に前記イベントのタイプに基づいて前記イベントの報告をキューイングするかどうかを判定することは、
前記イベントがローカルイベントである場合、前記イベントを、キューイングなしで報告することを含む、
方法。

【請求項2】

前記判定を繰り返す前に、更に、
前記イベントが報告されたことの通知を受信することを含み、
前記判定を繰り返すことは、
前記通知に従って前記イベントの報告のキャンセルを判定することを含む、
請求項１に記載の方法。

【請求項3】

前記判定を繰り返した後に、待機を繰り返すことを更に含む、
請求項１に記載の方法。

【請求項4】

前記少なくとも部分的に前記イベントのタイプに基づいて前記イベントの報告をキューイングするかどうかを判定することは、更に、
前記イベントが共有イベントである場合、乱数を生成し、前記乱数が前記イベントの報告をキューイングするよう指示するかどうかを判定することを含む、
請求項１に記載の方法。

【請求項5】

前記イベントの報告をキューイングしないと判定されたら、前記イベントを、キューイングなしで報告することを更に含む、
請求項１に記載の方法。

【請求項6】

無作為に前記期間を生成するか、又は、前記イベントの報告が何回遅延させられたかに基づいて前記期間を決定することを更に含む、
請求項１に記載の方法。

【請求項7】

イベントを検出し、
乱数を決定し、
ある期間待機し、前記期間は少なくとも部分的に前記乱数に基づき、
待機の後、イベント通知が受信されたかどうかを判定し、
前記イベント通知が受信されていないと判定されたら、前記イベントに対応するイベント報告を送信すること
を含む、方法。

【請求項8】

前記イベントがローカルイベントであるかどうかを判定し、そうである場合、待機なしで前記イベントを報告するか、又は、前記乱数を決定せずに前記イベントを報告することを更に含む、
請求項７に記載の方法。

【請求項9】

前記乱数は、少なくとも部分的に累積分布関数（ＣＤＦ）に基づく、
請求項７に記載の方法。

【請求項10】

前記乱数は、不均一分布を有する、
請求項７に記載の方法。

【請求項11】

前記乱数は、遅延させる時間単位の数を表し、前記時間単位は、フレームである、
請求項７に記載の方法。

【請求項12】

イベントの発生を検出するためのイベント検出器と、
前記イベント検出器と通信し、乱数を提供する乱数発生器と、
前記乱数発生器に結合され、前記乱数が閾値より大きいかどうかを判定する比較器と、
前記比較器に結合され、前記イベントのイベント報告を送信するイベント報告送信器と、
前記イベントの更なる処理を、少なくとも部分的に前記乱数に基づくある期間にわたって遅延させるために前記比較器に結合された遅延ユニットと、
別のシステムからの前記イベントに対応するイベント通知を受信するために前記遅延ユニットに結合された通知受信器と、
を備える、システム。

【請求項13】

前記乱数発生器は、前記イベントに対応する前記イベント通知が別のシステムから受信されていないことが、前記通知受信器によって通知されたら、前記乱数発生器が別の乱数を提供するように、前記通知受信器に結合される、
請求項１２に記載のシステム。

【請求項14】

前記比較器は、前記イベントのカテゴリに基づいて前記閾値を選択する、
請求項１２に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般に、通信システム及び方法に関し、特定の実施形態では、マシン間アプリケーションベース輻輳制御方式に関する。

【0002】

本出願は、２０１０年１０月２７日に出願された「Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ａｐｐｌｉｃａｔｉｏｎ Ｂａｓｅｄ Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｓｃｈｅｍｅ（マシン間アプリケーションベース輻輳制御方式）」と題された米国仮特許出願第６１／４０７，３０１号、及び、２０１１年８月１８日に出願された「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ Ａｐｐｌｉｃａｔｉｏｎ Ｂａｓｅｄ Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ（マシン間アプリケーションベース輻輳制御のシステム及び方法）」と題された米国非仮特許出願第１３／２１２，８６２号の利益を主張するものであり、当該出願は参照によって本明細書中に援用される。

【背景技術】

【0003】

マシン間（Ｍ２Ｍ）サービスは、人間とのいかなる相互作用もなしに実行されることが可能なアクセスネットワークを介した装置（有線又は無線）間の通信、又は、装置とサーバとの間の通信を可能にする技術を意味する。例えば、Ｍ２Ｍは、装置（センサ又はメータなど）を使用して、イベント（温度、在庫レベルなど）を捕捉し、このイベントは、ネットワーク（無線、有線、又は混合）を介してアプリケーション（ソフトウェアプログラム）に中継され、アプリケーションは、捕捉されたイベントを意味のある情報（例えば、在庫補充されるべき品目）に変換する。そのような通信は、まず、解析のために、情報を中央ハブに中継して遠隔ネットワークのマシンに戻させ、次に、その情報がパーソナルコンピュータのようなシステム内に再ルーティングされることによって達成されていた。

【0004】

今日のＭ２Ｍ通信は１対１接続を超えて拡大し、パーソナルアプライアンスにデータを伝送するネットワークのシステムに変化した。無線ネットワークの世界中への拡大はＭ２Ｍ通信が行われることをはるかに容易にし、マシン間で情報が通信されるために必要なパワー及び時間の量を減少させた。

【0005】

しかし、Ｍ２Ｍ装置のサポートに伴い、ネットワークによってサポートされる装置の数が桁違いに増加する可能性がある。大部分のＭ２Ｍ装置は少量のデータをたまに報告するのみである可能性があるが、多数のＭ２Ｍ装置（スマートメータ（ＳＭ）など）は共通のイベントに対して多数のＭ２Ｍ装置が報告又は反応した場合に発生する潜在的な「トラフィックバースト」シナリオを生じさせる（多数のＳＭが停電を報告する多数のセンサが地震を報告するなど）。きっかけとなるイベントに関係なく、そのようなシナリオは、多数のＭ２Ｍ装置が同じイベントを報告するために、同時に又はほぼ同時にシステムへのアクセスを試みることをもたらす可能性があり、これにより、ネットワーク性能が低下する可能性がある。

【発明の概要】

【発明が解決しようとする課題】

【0006】

本開示の実施形態は、マシン間アプリケーションベース輻輳制御方式のシステム及び方法を提供する。

【課題を解決するための手段】

【0007】

一実施形態では、イベントを検出し、イベントの報告をキューイングするかどうかを判定し、イベントをキューイングすると判定された場合、ある期間にわたって待機することを含む。その期間が満了した後、判定が繰り返されることを含む方法が提供される。

【0008】

別の実施形態では、イベントを検出し、乱数を決定することを含む方法が提供される。乱数は、遅延させる期間を決定するために使用される。遅延の後、イベント通知が受信されたかどうかの判定が行われ、受信されていない場合、イベントに対応するイベント報告が送信される。

【0009】

更に別の実施形態では、システムが提供される。このシステムは、イベントの発生を検出するためのイベント検出器と、イベント検出器に結合された乱数発生器と、を含み、乱数発生器は乱数を提供する。比較器は、提供された乱数が閾値より大きいかどうかを比較器が判定するように乱数発生器に結合される。イベント報告送信器が、イベントに対応するイベント報告をイベント報告送信器が送信するように比較器に結合され、イベントの更なる処理をある期間にわたって遅延させるために、遅延ユニットが比較器に結合される。別のシステムからのイベント通知を受信するために、通知受信器が遅延ユニットに結合され、イベント通知はそのイベントに対応する。

【図面の簡単な説明】

【0010】

本発明及びその利点のより完全な理解のために、ここで、以下の説明を、添付の図面と組み合わせて参照する。

【0011】

【図1】本開示の態様を利用することが可能なネットワークのモデルを示す。

【図2】第１の実施形態におけるステップを示すフローチャートである。

【図3】第１の実施形態におけるステップを示すフローチャートである。

【図4】本開示の実施形態のシステムのブロック図である。

【図5】本開示の実施形態を実施するための一例のブロック図である。

【発明を実施するための形態】

【0012】

実施形態の作製及び使用について、以下に詳細に説明する。但し、本開示は、様々な特定の状況において実施されることが可能な多くの適用可能な発明概念を提供するということを理解されたい。説明される特定の実施形態は、本発明を作製及び使用する特定のやり方を例示するものにすぎず、本発明の範囲を限定するものではない。

【0013】

一態様では、本開示は、新しいアプリケーションレイヤベースの輻輳制御手法を提供する。実施形態は、Ｍ２Ｍ装置によって伝送される情報のスタガリングによって、冗長な非重要情報の伝送を回避する又は減少させる。加えて、Ｍ２Ｍ装置は、キューイングされた情報を、その情報がもはや必要とされないと判定したら、廃棄してもよい。

【0014】

一実施形態では、システムは、アプリケーションレイヤベースの輻輳制御手法を提供する。この実施形態手法は、Ｍ２Ｍ装置によって生成された情報をスタガリングすることによって、冗長な非重要情報の伝送を予防的に回避してもよい。加えて、Ｍ２Ｍ装置は、キューイングされた情報を、その情報がもはや妥当ではないと判定したら（例えば、別のＭ２Ｍ装置がその情報をすでに伝送したことが検出された場合）、廃棄してもよい。

【0015】

図１は、本開示の態様を利用することが可能なネットワーク１００の単純化された例を示す。モバイル局（ＭＳ）１０２（これは、無線伝送プロトコルを介して通信しているＭ２Ｍ装置を表してもよい）は、基地局（ＢＳ）１０４と通信状態にある。１つのみのＭＳ１０２及びＢＳ１０４が示されているが、多数の装置が同時に通信状態にあってもよいということが理解される。基地局１０４は、更に、エッジゲートウェイ又はルータ１０６と、例えば、ＧＲＥ（汎用ルーティングカプセル化）トンネルを介して通信する。エッジゲートウェイ／ルータ１０６は、コアネットワーク１０８に結合される。通信は、このネットワークを介して、企業のバックオフィス１１０に又は如何なるその他の通信が意図される宛先に転送されてもよい。

【0016】

上述のように、多数のＭ２Ｍ装置（スマートメータ（ＳＭ）など）は、共通のイベントに対して多数の装置が報告又は反応した場合に発生する潜在的な「トラフィックバースト」シナリオを生じさせる。この輻輳に対処する（例えば、不必要なトラフィックをなくして、緊急関連のコールのみが進むことを許可する）ために、いくつかの無線技術では、アクセスクラス（ＡＣ）を指定することによる無線のアクセス優先順位付けのいくつかの手段を組み込んでいる。装置には、１つ以上のＡＣが割り当てられ、ネットワークは、禁止アクセスクラスリスト（ｂａｒｒｅｄ Ａｃｃｅｓｓ Ｃｌａｓｓ ｌｉｓｔ）をブロードキャストすることによって、アクセス試行を制限する。装置のＡＣが、禁止アクセスクラスリストのメンバである場合、装置は、ネットワークへのアクセスを試みてはならない。輻輳が又は潜在的なトラフィックバーストトリガの事前知識が検出されたら、ネットワークは、輻輳を軽減するために、禁止アクセスクラスリストを好適に更新してもよい。

【0017】

このＡＣアプローチの１つの欠点は、ネットワークが、ネットワーク輻輳を適時に認識しない可能性があり、又は、ネットワーク輻輳に適時に反応しない可能性があり、そして、禁止アクセスクラスリストを適時に更新できないということである。これは、多数のＭ２Ｍ装置が、引き続きネットワークへのアクセスを試みて、過負荷状態に寄与することを意味している。本明細書中で説明されるものなどの実施形態は、Ｍ２Ｍ装置（例えば、ＳＭ、ＭＳなど）による情報の伝送をスタガリングすることによって、この問題を減少させ又は防止し、これにより、冗長な非重要情報の伝送を減少させることが可能である。加えて、Ｍ２Ｍ装置は、キューイングされた情報を、その情報がもはや妥当ではないと判定した場合、廃棄してもよい。

【0018】

図１は、無線ネットワークシステムを、例示の目的のためにのみ示していることに留意されたい。他の実施形態では、Ｍ２Ｍ装置は、有線通信システムを介して通信する。更に、ネットワークは、無線Ｍ２Ｍ装置及び有線Ｍ２Ｍ装置の両方を含んでもよい。

【0019】

図２は、一実施形態によるイベントの報告を制御するプロセスを示す。一般に、このプロセスは、冗長な非重要情報の伝送を、Ｍ２Ｍ装置によるイベント報告の伝送をスタガリングすることによって回避する。加えて、Ｍ２Ｍ装置は、そのＭ２Ｍ装置によってまだ報告されていないイベント報告を、そのイベント報告がもはや妥当ではないと判断された場合（そのイベントが、ネットワーク内の別の装置によってすでに報告された場合などであってもよい）、廃棄してもよい。

【0020】

ステップ２０２を最初に参照すると、イベントが検出される。イベントは、例えば、停電、悪天候、地震、ハードウェア障害、ソフトウェア障害、又は、イベントの発生の知識が別のネットワーク装置にとって望ましい任意の数のその他のイベントであってもよい。これらの例は、例示の目的のためにのみ提供されており、特許請求の範囲を限定することを意図するものではないということに留意されたい。

【0021】

ステップ２０２においてイベントが検出されたら、処理はステップ２０４に進み、ここでは、イベントが共有イベントであるか、ローカルイベントであるかが判定される。共有イベントは、遠く離れて配置された２つ以上のＭ２Ｍ装置によって報告される可能性があるイベントである。例えば、停電、悪天候、又は地震は、広い地域に影響を及ぼす可能性があり、従って、広い地域にわたって、複数のＭ２Ｍ装置に影響を及ぼす可能性がある。その他のイベントは、特定のＭ２Ｍ装置に、又は、領域内に配置された比較的少数のＭ２Ｍ装置にイベントが影響を及ぼすという点で、ローカルであってもよい。例えば、ローカルイベントは、１つのＭ２Ｍ装置に影響を及ぼす可能性があるバッテリバックアップの故障（ｆａｕｌｔｙ ｂａｔｔｅｒｙ ｂａｃｋｕｐ）、ディスク記憶の不足（ｌｏｗ ｄｉｓｋ ｓｔｏｒａｇｅ）などを含んでもよい。別の例では、ローカルイベントは、住宅内に又は住宅の付近に配置され２つ以上のＭ２Ｍ装置によって報告される可能性がある、住宅火災であってもよい。

【0022】

ローカルイベントは、通常、その特定のＭ２Ｍ装置によってのみ報告され、従って、ネットワークに不必要に負担をかけることはない可能性があるため、ステップ２０４で、イベントがローカルイベントであると判定されたら、処理はステップ２０６に進み、ここでは、ローカルイベントに対応するイベント報告が伝送される（無線で、有線で、又は混合で）。イベントは、システムレベルイベント、領域固有、装置タイプ固有、アプリケーション固有、これらの組み合わせなどであってもよいということに留意されたい。

【0023】

他方、イベントが共有イベント（例えば、複数のＭ２Ｍ装置によって検出される可能性があるイベント）であるという判定がなされた場合、処理はステップ２０８〜２１６に進み、ここでは、影響を及ぼされた各Ｍ２Ｍ装置による共有イベントの報告の重複が、減少させられてもよく、又は防止されてもよい。最初に、ステップ２０８及び２１０において、（確率１−ｐで）イベントの報告を遅延させるか、（確率ｐで）イベントを遅延なしに報告するかの決定が行われる。図２に示されているものなどの実施形態では、決定は、乱数を閾値と比較することを含む。例えば、ステップ２０８は、例えば０と１との間の乱数を生成することを示す。乱数は、システムクロック、熱的特性、ノイズレベル、動きなどに基づくものなどの、任意の好適な技術によって決定されてもよい。乱数は、疑似乱数を含むことが理解される。

【0024】

ステップ２１０で、乱数は、閾値又は確率と比較される。この実施形態では、乱数が閾値より小さい場合、処理はステップ２０６に進み、ここでは、イベントに対応するイベント報告が、いかなる更なるバックオフ遅延もなしに伝送される。それ以外の場合、処理はステップ２１２に進み、ここでは、バックオフ遅延が実行される。この例示的実施形態では、乱数は、間隔［０，１］上に均一に分布した数を生成する。乱数は、理論的に又は実際的に、０と１との間の全ての値に等しいことの等しい確率を有するため、閾値は、乱数が閾値より小さい又は閾値より大きいことの確率を表す。例えば、閾値０．５は、イベントが報告されること、及び、イベントの報告が遅延させられることの等しい確率を表す。同様に、閾値０．３は、イベントが、いかなる更なるバックオフ遅延もなしに報告されることの３０％の確率、及び、この特定のＭ２Ｍ装置によるイベントの報告が遅延させられることの７０％の確率を表す。

【0025】

閾値又は確率は、全てのイベントについて同じであってもよく、又は、イベントに固有であってもよく、又は、イベントのタイプ又はカテゴリに固有であってもよい。閾値又は確率は、また、イベントを共有する装置の数に基づいてもよい。例えば、多くの装置によって共有されるイベントは、少数の装置のみによって共有されるイベントより低く設定された閾値を有してもよい。閾値又は確率は、また、イベントの重要度に基づいてもよい。例えば、イベントが重要イベントとみなされる場合、閾値は高く設定されてもよく、これにより、ネットワークトラフィックの増加がもたらされる可能性があるにもかかわらず、イベントがより早く報告されることの見込みが高くなる。逆に、非重要イベントは、より低い閾値を有してもよく、これにより、イベント報告が遅延させられる確率が増加する。更に、各イベント又はイベントのタイプについての確率が個々に制御されてもよく、各Ｍ２Ｍ装置についての確率が個々に制御されてもよい。更に、閾値又は確率は、伝送の結果（例えば、伝送が何回遅延させられたか）に基づいて調節されてもよい。一実施形態では、ネットワークインタフェースを介した確率の更新及び制御を許可し、これにより、遠隔装置（中央に位置しているシステム管理者など）から確率が設定されることを許可することが望ましい可能性がある。

【0026】

ステップ２１２で、システムは、バックオフ遅延期間にわたって待機する。確率と同様に、バックオフ遅延は、グローバル／デフォルト遅延期間であってもよく、又は、個々のイベント、又はイベントのタイプについて指定されてもよい。バックオフ遅延は、また、伝送の結果（例えば、伝送が何回遅延させられたか）に基づいて調節されてもよい。一般に、バックオフ遅延期間は、イベントの報告を遅延させて、イベントを別の装置（別のＭ２Ｍ装置など）が報告するかどうかを待機して見させる。従って、Ｍ２Ｍ装置は、引き続き、通信を監視して、報告されるべきイベントに対応するイベント通知をリスンする。バックオフ遅延の値は、所定の値、無作為に生成された値、ネットワークコマンドによって決定された値などであってもよい。これは、重要な共有イベント（外部セキュリティアラームが、近隣の車／強盗アラームを検出して、Ｅ−９１１をアラートすることなど）が、非重要な共有又はローカルイベントに比較して、より短いバックオフ遅延を与えられることを可能にする。

【0027】

ステップ２１４で、イベントに対応するイベント通知が、別の装置（別のＭ２Ｍ装置、基地局、サーバ、Ｍ２Ｍサーバなど）から受信されたかどうかの判定が行われる。イベント通知は、任意の好適なプロトコル（ユニキャスト、マルチキャスト、及びブロードキャストメッセージングを含む）を使用する他の装置によって送信されてもよい。イベントに対応するイベント通知が受信されたという判定がなされた場合、イベントを報告する必要はなく、ステップ２１６に示されているように、キューイングされたイベント報告は廃棄される。

【0028】

別の実施形態では、イベントの報告をＭ２Ｍ装置がキャンセルすることを引き起こすために、イベント通知の代わりに又はイベント通知に加えて、ネットワークコマンドが送信されてもよい。ネットワークコマンドは、例えば、閾値又は確率を０に設定するためのものであってもよく、これにより、イベント報告が送信されるべきではないことがＭ２Ｍ装置に報知される。その他のネットワークコマンド（報告をキャンセルするための明示的なメッセージなど）が使用されてもよい。一実施形態では、確率を０に設定するためのコマンドが、別の装置（別のＭ２Ｍ装置、基地局、サーバ、Ｍ２Ｍサーバなど）から受信されたイベント通知メッセージ内に含まれてもよく、そして、任意の好適なプロトコル（ユニキャスト、マルチキャスト、及びブロードキャストメッセージングを含む）を使用して送信されてもよい。

【0029】

イベント報告及び／又はイベント通知は、特定のメッセージ又はブロードキャストメッセージであってもよい。いくつかの通信システム（ＷｉＭＡＸなど）は、アプリケーションレイヤベースのブロードキャスティング／マルチキャスティングをサポートする。これらのようなシステムでは、イベント報告／通知メッセージ、及び、確率コマンド、バックオフ遅延コマンドなどは、Ｍ２Ｍ装置に、ユニキャスト、マルチキャスト、及び／又は、ブロードキャストメッセージを介して通信されてもよい。

【0030】

そうでない場合、イベントに対応するイベント通知が、バックオフ遅延期間の満了までに受信されていないという判定がなされた場合、処理は、ステップ２０８に戻る。

【0031】

上記で提供された方法は、概念を示すための例示の目的のための実施形態の一例にすぎず、その他の実施形態では、異なるプロセスを利用してもよいということに留意されたい。例えば、別の実施形態では、ステップ２０４におけるイベントが共有イベントであるかローカルイベントであるかの判定は、ステップ２０８及び２１０と組み合わせられてもよい。上述のように、各イベント又はイベントのカテゴリは、その独自の確率又は閾値を有してもよい。ローカルイベントは、確率又は閾値１が与えられてもよく、これにより、ローカルイベントは遅延なしに報告されるべきであることが示される。ローカル高優先度イベントの例は、住宅が火事になっており、システムは、近隣が検出して当局に通知するのを待機するべきではないということであってもよい。この場合、住宅火災のイベントに確率１が与えられるならば、そのイベントは、バックオフ遅延なしに直ちに報告される。

【0032】

図３は、別の実施形態によるイベントの報告を制御するプロセスを示す。このプロセスは、ステップ３０２で開始され、ここでは、イベントが検出される。イベントを検出したら、処理はステップ３０３に進み、ここでは、イベントが共有イベントであるかどうかの判定が行われる。上述のように、共有イベントは、遠く離れて配置された２つ以上のＭ２Ｍ装置によって報告される可能性があるイベントであり、ローカルイベントは、特定のＭ２Ｍ装置に又は領域内に配置された比較的少数のＭ２Ｍ装置に影響を及ぼすイベントである。ローカルイベントは、その特定のＭ２Ｍ装置又は比較的少数のＭ２Ｍ装置によってのみ報告され、従って、ネットワークに不必要に負担をかけることはないため、ステップ３０３で、イベントがローカルイベントであると判定されたら、処理はステップ３１２に進み、ここでは、ローカルイベントに対応するイベント報告が伝送される（無線で、有線で、又は混合で）。

【0033】

他方、イベントが共有イベント（例えば、複数のＭ２Ｍ装置によって検出される可能性があるイベント）であるという判定がなされた場合、処理はステップ３０４に進み、乱数が生成される。均一分布が乱数発生器のために使用される図２を参照して上述した実施形態とは対照的に、この実施形態では、不均一分布を利用する乱数発生器を利用することが望ましい可能性がある。例えば、一実施形態では、乱数は、累積分布関数（ＣＤＦ）（これは、前述の実施形態で使用された閾値などの所与のパラメータから構成されてもよく又は導き出されてもよい）に従って生成される。このようにして、０に近い確率が０から遠い確率より大きくなる。但し、この実施形態は、均一分布又はその他の分布を、乱数発生器のために利用してもよい。

【0034】

ステップ３０６で、システムは、バックオフ遅延の間、待機する。この実施形態では、バックオフ遅延は、ステップ３０４で生成された乱数に基づいて決定される。例えば、ステップ３０４で生成された乱数は、システムが待機すべき所定の時間単位の数を表してもよく、又は、そのような時間単位の数は乱数から計算されてもよい。所定の時間単位は、例えば、マイクロ秒、秒、フレーム、それらの倍数などであってもよい。例えば、一実施形態では、ＣＤＦが前述の実施形態で使用された閾値ｐから導き出されて、Ｆ（ｔ）＝１−（１−ｐ）^ｔ＋１が得られてもよく、ここで、ｔは、イベント報告をキューイングする遅延間隔の数である。この実施形態では、最初に、乱数ｘを、間隔［０，１）にわたって均一に分布した数を生成する乱数発生器を使用して生成してもよい。乱数ｘは、次に、

【数1】

を計算するために使用されてもよい。

【0035】

バックオフ遅延の満了の後、処理はステップ３０８に進み、ここでは、イベントに対応するイベント通知が受信されたかどうかの判定が行われる。イベントに対応するイベント通知が受信された場合、ステップ３１０に示されているように、対応するイベント報告は廃棄される。それ以外の場合、ステップ３１２に示されているように、イベント報告は伝送される。

【0036】

図４は、本開示の実施形態を組み込んでもよい装置４００の簡略ブロック図である。この図を参照すると、イベント検出器４０２が乱数発生器４０４と通信し、次に、乱数発生器４０４が比較器４０６と通信し、比較器４０６がキュー／遅延ユニット４０８と通信する。通知受信器４０１が、キュー／遅延ユニット４０８及び乱数発生器４０４と通信して、上述のように動作する。イベント指示送信器４１２が、イベント検出器４０２及び比較器４０６と通信する。

【0037】

このシステムは、図２及び図３に関して説明した方法を実行するために使用されてもよい。但し、特定の実施形態に応じて、構成要素間の接続は様々であってもよいということに留意されたい。例えば、図４内の破線によって示されているように、比較器４０６は使用されなくてもよく、乱数発生器４０４はキュー／遅延ユニット４０８と通信してもよい。これは、図３を参照して上述した実施形態に適用可能な場合があり、この実施形態では、バックオフ遅延が乱数に基づく。上述のように、この実施形態では、乱数を閾値又は確率と比較する必要はない。

【0038】

図５は、上述のものなどの本開示の方法を実施するために利用されることが可能な処理システムを示す。この場合、主要な処理はプロセッサ５０２内で実行され、プロセッサ５０２は、マイクロプロセッサ、デジタル信号プロセッサ、又は任意のその他の適切な処理装置であってもよい。プログラムコード（例えば、上述の方法を実施するコード）及びデータは、メモリ５０４、又は任意のその他の非一時的記憶媒体内に記憶されてもよい。メモリ５０４は、ローカルメモリ（ＤＲＡＭなど）、又は、大容量記憶装置（ハードドライブ、光ドライブなど）、又は、その他の記憶装置（ローカル又はリモートであってもよい）であってもよい。メモリ５０４は、単一のブロックを使用して機能的に示されているが、１つ以上のハードウェアブロックが、この機能を実施するために使用されてもよいということが理解される。

【0039】

一実施形態では、プロセッサ５０２は、図４に示すブロックを実施するために使用されてもよい。例えば、プロセッサ５０２は、実施形態の技術の実行に含まれるサブタスクを実行するために、異なる時において、特定の機能ユニットとして働いてもよい。あるいは、（例えば、プロセッサと同じ又は異なる）様々なハードウェアブロックが、異なる機能を実行するために使用されてもよい。他の実施形態では、いくつかのサブタスクが、プロセッサによって実行され、その他のサブタスクは、別個の回路を使用して実行される。

【0040】

図５は、Ｉ／Ｏポート５０６も示しており、これは、プロセッサ５０２にデータを、及び、プロセッサ５０２からのデータを提供するために使用されてもよい。無線（例えば、モバイル）装置の場合、Ｉ／Ｏポート５０６は、アンテナに結合されてもよい。有線装置の場合、Ｉ／Ｏポート５０６は、ネットワークインタフェースに接続されてもよい。

【0041】

センサ５０８も、図５に示されている。このブロックは、検出されたイベントの発生源を示すために提供される。これは、自動的に又は手動で又はその両方で動作させられる任意のタイプのセンサ又はその他の検出器であってもよい。

【0042】

上述のものなどの実施形態は、特に、高バーストレートのトラフィックを発生させる可能性がある特定のイベント（停電など）の間、ネットワークトラフィックを減少させる可能性がある。これは、とりわけ、装置のうちのいくつかにおいてイベントの報告を遅延させることによる予防的輻輳処理を提供することによって達成される。

【0043】

本明細書中で開示されたものなどの実施形態は、多くの異なる伝送技術に適用可能である。例えば、実施形態は、ＩＥＥＥ８０２．１１、ＺｉｇＢｅｅなどの無線／有線システムにおいて利用されてもよい。周知のように、ＩＥＥＥ８０２．１１は、２．４、３．６及び５ＧＨｚの周波数帯域において、無線ローカルエリアネットワーク（ＷＬＡＮ）コンピュータ通信を実行する標準の組であり、ＺｉｇＢｅｅは、低レート無線パーソナルエリアネットワーク（ＬＲ−ＷＰＡＮ）のためのＩＥＥＥ８０２．１５．４−２００３標準に基づく、小型の低電力デジタル無線機を使用する高レベル通信プロトコルのスイートの仕様である（無線光スイッチ及びランプ、宅内ディスプレイを有する電気メータ、短距離無線を介する家電機器など）。これらのシステムは、ＡＣ輻輳制御メカニズムを明示的には提供しない可能性があるが、本明細書中で開示されたものなどの実施形態は、それにもかかわらず、輻輳制御を提供することが可能である。但し、本明細書中で開示されたものなどの実施形態は、伝送技術のＡＣ輻輳制御メカニズムと組み合わせて使用されてもよいということに留意されたい。

【0044】

パラメータ（例えば、乱数、閾値、バックオフ遅延）選択の柔軟性が、特定の適用例、イベント、及び／又はネットワークに適合するように、ネットワークを「調整」することを可能にするということも理解されたい。更に、パラメータ選択の柔軟性は、アラーム／緊急トラフィックの優先順位付けのサポートを可能にする。パラメータは、システム又は装置によって、割り当て／変更されてもよい。

【0045】

本発明の実施形態の実施は、ホスト内でトラフィックを抑制することによって、ネットワーク内のトラフィックを減少させることが可能である。輻輳（又はネットワークによる検出）がない場合でも、本アルゴリズムは、無線インタフェース上の冗長なトラフィック伝送の減少を可能にする。実施形態は、輻輳に対するより敏感／迅速な反応を提供し、なぜなら、これらの実施形態では、ネットワークが輻輳を検出して、更新された禁止アクセスリストを送信するのを待つ必要がないからである。

【0046】

本発明について、例示的実施形態を参照して説明したが、この説明は、限定的な意味で解釈されることを意図するものではない。例示的実施形態の、様々な修正、及び組み合わせ、並びに、本発明の他の実施形態は、本説明を参照すれば、当業者にとって明白となるであろう。従って、添付の特許請求の範囲は、任意のそのような修正、又は実施形態を包含することが意図される。

【図1】

【図2】

【図3】

【図4】

【図5】