(57)【特許請求の範囲】
【請求項１】
ネットワークのノードであって、
１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサと通信するメモリと、
前記メモリに定義された複数のアプリケーションと、
前記メモリに定義され、および、前記１つまたは複数のプロセッサによって実行可能なトラフィック負荷マネージャであって、前記トラフィック負荷マネージャは、
前記複数のアプリケーションの各々の優先度を判定し、ならびに、
前記ノードの前記メモリに定義された前記複数のアプリケーションの各々を、複数のコンテンションウィンドウの１つに関連付け、前記関連付けることは、各々のアプリケーションの優先度にしたがって実行され、異なる優先度を有する前記複数のアプリケーションの間で異なるアプリケーションは、異なるサイズのコンテンションウィンドウを有している、ように構成されたトラフィック負荷マネージャと、
前記メモリに定義され、および、前記１つまたは複数のプロセッサによって、品質基準、および前記ネットワークの一部の上でのトラフィック密度を含む入力にしたがって、コンテンションウィンドウ、前記複数のコンテンションウィンドウ間からの前記コンテンションウィンドウ、および前記複数のアプリケーション間からのアプリケーションに関連付けられた前記コンテンションウィンドウをリサイジングするように実行可能な送信再試行マネージャであって、前記コンテンションウィンドウをリサイジングすることは、
トラフィックコリジョンおよびリンク品質に起因した送信障害を区別することと、
送信障害がトラフィックコリジョンに起因している場合、前記コンテンションウィンドウをリサイジングすることと、
前記品質基準が第１の閾値を下回り、および、前記トラフィック密度が第２の閾値を上回る場合、ショート再試行カウント最大値およびロング再試行カウント最大値を減少させることと、
送信プロトコルの上位レイヤに、前記品質基準を通知することと、
を含む、送信再試行マネージャと、
前記メモリに定義され、および、前記１つまたは複数のプロセッサによって、パケットを第２のノードに送信するように実行可能なパケット送信機と
を備えたことを特徴とするノード。
【請求項２】
ネットワークのノードを動作させる方法であって、
前記ノード上の１つまたは複数のプロセッサが、第１のサイズを有する第１のコンテンションウィンドウを、前記ノード上で動作している第１のアプリケーションに関連付けるステップと、
前記プロセッサが、第２のサイズを有する第２のコンテンションウィンドウを、前記ノード上で動作している第２のアプリケーションに関連付けるステップであって、前記第１のサイズは前記第２のサイズと異なり、前記第１および第２のコンテンションウィンドウは、前記第１および第２のアプリケーションの優先度に基づいている、ステップと、
前記プロセッサが、前記ノードと、前記第１のアプリケーションにより送信されることになるパケットおよび前記第２のアプリケーションにより送信されることになるパケットの宛先ノードとの間のリンクの品質基準を取得するステップと、
前記プロセッサが、前記リンクを含む前記ネットワークの一部のトラフィック密度のレベルをチェックするステップと、
前記プロセッサが、前記リンクの前記品質基準、および前記トラフィック密度のレベルを含む入力に基づいて、前記第１および／または第２のコンテンションウィンドウをリサイジングするステップであって、前記リサイジングすることは、
前記トラフィック密度のレベルおよび前記品質基準に起因した送信障害を区別することと、
送信障害が前記トラフィック密度のレベルに起因している場合、前記第１のコンテンションウィンドウをリサイジングすることと、
前記品質基準が第１の閾値を下回り、および、前記トラフィック密度のレベルが第２の閾値を上回る場合、ショート再試行カウント最大値およびロング再試行カウント最大値を減少させることと、
送信プロトコルの上位レイヤに、前記品質基準を通知することと
を含む、ステップと、
前記プロセッサが、前記リサイジングされた第１および／または第２のコンテンションウィンドウの経過後に、前記第１のアプリケーションから前記パケット、および前記第２のアプリケーションから前記パケットをそれぞれ送信するステップと
を備えたことを特徴とする方法。
【請求項３】
前記プロセッサが、前記第１および第２のアプリケーションを含む、前記ノード上で動作している複数のアプリケーションのいずれかが、送信されることになるデータを作成したかを判定するステップと、
前記プロセッサが、前記判定の少なくとも部分的に基づいて、前記第１および／または第２のコンテンションウィンドウを選択するステップと
をさらに備えたことを特徴とする請求項２に記載の方法。
【請求項４】
前記プロセッサが、前記ノード上で稼動している複数のアプリケーションを優先付けるステップと、
前記プロセッサが、前記第１および第２のアプリケーションを含む前記複数のアプリケーションの各々を、前記アプリケーションの優先付けに少なくとも部分的に基づいてサイジングされたコンテンションウィンドウに関連付けるステップと
をさらに備えたことを特徴とする請求項２に記載の方法。
【請求項５】
前記プロセッサが、前記ノード上で動作している複数の異なるアプリケーションに関連して、複数の異なってサイジングされたコンテンションウィンドウをそれぞれ利用するステップをさらに備え、前記複数の異なるアプリケーションは、前記第１および第２のアプリケーションを含み、前記複数の異なるアプリケーションは、複数の異なる優先度をそれぞれ有していることを特徴とする請求項２に記載の方法。
【請求項６】
前記コンテンションウィンドウをサイジングするステップは、
複数の異なるアプリケーションによって作成されたデータの送信に対して、複数のコンテンションウィンドウを異なってそれぞれサイジングするステップを含み、前記複数の異なるアプリケーションは、前記第１および第２のアプリケーションを含むことを特徴とする請求項２に記載の方法。
【請求項７】
前記リンクの前記品質基準を取得するステップは、
前記ノード上で予想送信時間アルゴリズムを動作させるステップと、
前記予想送信時間アルゴリズムに基づいて、前記品質基準を算出するステップと
を備えていることを特徴とする請求項２に記載の方法。
【請求項８】
前記トラフィック密度のレベルをチェックするステップは、
前記リンクが定義された媒体がビジーである時間を測定するステップと、
前記媒体がビジーである前記測定された時間の割合として、前記トラフィック密度のレベルを表すステップと
を備えていることを特徴とする請求項２に記載の方法。
【請求項９】
第１のコンテンションウィンドウをリサイジングするステップは、第１の送信の再試行上ではなく、第２の、および後続の送信の再試行上でのみ、前記第１のコンテンションウィンドウの長さを２倍にするステップを備えていることを特徴とする請求項２に記載の方法。
【請求項１０】
前記プロセッサが、前記第１および第２のアプリケーションを含む、前記ノード上の複数のアプリケーションの各々の優先度を判定するステップと、
前記プロセッサが、前記複数のアプリケーションの各々の前記優先度に基づいて、コンテンションウィンドウのサイズを前記複数のアプリケーションの各々に関連付けるステップと
をさらに備え、
前記第１のコンテンションウィンドウの前記第１のサイズは、前記アプリケーションの１つに関連付けられた前記コンテンションウィンドウの１つである
ことを特徴とする請求項２に記載の方法。
【請求項１１】
前記プロセッサが、前記ノード上の複数のアプリケーションのそれぞれに対して複数の帯域幅制約を実施する計算に基づいて、前記第１のコンテンションウィンドウを前記第１のサイズにサイジングするステップをさらに備えたことを特徴とする請求項２に記載の方法。
【請求項１２】
前記プロセッサが、前記第２のアプリケーションよりも前記第１のアプリケーションにさらなる帯域幅を付与する計算に基づいて、前記第１のコンテンションウィンドウを前記第１のサイズにサイジングするステップをさらに備えたことを特徴とする請求項２に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、無線通信に関する。
【０００２】
本出願は、２０１２年３月６日に出願され、「トラフィック負荷および送信再試行管理」と題する欧州特許出願第１２１５８３２０．７号の優先権を主張するものであり、その内容が参照により本出願に組み込まれる。
【背景技術】
【０００３】
メッシュネットワークは、多くが送信に対してデータを作成および／または収集する１つまたは複数のソフトウェアアプリケーションを含むことができる、複数のノードを含むことがある。ソフトウェアアプリケーションの一部は、データを収集することができるセンサ、メータなどを含むデバイスと通信していることがある。総じて、ノードは、中央オフィスへの送信に対して、ルートノードに上流へ送信されることになる多量のデータを生成することがある。
【０００４】
既存のネットワークおよびシステムは、一部のアプリケーションが、ネットワークの一部を圧倒（overwhelm）すること、特に、特定の上流ノードにおいてボトルネックを作り出すことを許容することがある。一部の状況では、このことは、送信遅延およびサービス品質の問題をもたらすことがある。
【０００５】
従来のコンテンションウィンドウ管理は、この問題に対処することができない。さらに、現在の技術は、トラフィックのコリジョン（collisions）に起因した送信障害を、無線干渉により生じるなどのプア（poor）なリンク接続に起因した障害と区別することができない。このような状況下で、一部のアルゴリズムにより示されるようなコンテンションウィンドウを２倍にする（doubling）方法は、逆効果を生じすることがあり、実際に、ネットワーク性能を低下させることがある。
【図面の簡単な説明】
【０００６】
添付図面を参照して、発明の詳細な説明が示される。図面においては、参照符号の一番左の数字が、参照符号が最初に現れる図面を識別する。同一の番号が同一の特徴およびコンポーネントを称するものとして図面全体で使用される。さらに、図面は、一般的な概念を例示することを意図しており、要求される、および／または、必須の要素を示すことを意図するものではない。
【図１】複数のノードを有している例示的なネットワーク、１つの例示的なノードの一部の詳細、インターネットなどのさらなるネットワークおよび中央オフィスへの接続を示している図である。
【図２】個々のノードのプロセシングユニットの例示的な詳細を示している図である。
【図３】複数のアプリケーション、複数のアプリケーションに割り当てられた元のコンテンションウィンドウ、および送信エラーのときにセットすることができるリサイジング（resized）されたコンテンションウィンドウの例を示しているテーブルである。
【図４】リンク品質、トラフィック密度（traffic density）、およびコンテンションウィンドウのリサイジング（resizing）に関する決定を示しているテーブルである。
【図５】ネットワーク負荷管理および再試行（例えば、ＲＦメッセージの再送信）管理を実行することができる例示的な方法を示しているフローチャートである。
【図６】コンテンションウィンドウをサイジング（size）し、および、ネットワーク負荷管理を実行することができる複数の例示的なオペレーションを示しているフローチャートである。
【図７】再試行管理の一部としてコンテンションウィンドウをリサイジングする際の使用に対してなどの品質基準を取得することができる例示的な方法を示しているフローチャートである。
【図８】再試行管理の一部としてコンテンションウィンドウをリサイジングする際の使用に対してなどのネットワークトラフィック密度を測定することができる例示的な方法を示しているフローチャートである。
【図９】再試行管理における技術としてコンテンションウィンドウをリサイジングすることを実行することができる例示的な方法を示しているフローチャートである。
【発明を実施するための形態】
【０００７】
＜概要＞
上述したように、既存のネットワークは、アプリケーションによりデータ送信レートを管理する効果的な方法を提供せず、および、特定のノードまたは特定のアプリケーションによる過度なデータ送信がネットワークの一部をスローダウンさせることを許容することがある。加えて、送信障害の場合には、既存の送信再試行アルゴリズムは、非効率的な方法でコンテンションウィンドウを管理することがある。特に、既存のネットワークは、トラフィックのコリジョンに起因した送信障害と、無線干渉により生じるなどのプアなリンク接続に起因した送信障害とを区別することができない。このような場合に、既存のルーティング（routing）基準に応答したコンテンションウィンドウの調整は、これらの問題を悪化させ、および、ネットワーク性能を低下させることがある。
【０００８】
本開示は、ネットワーク負荷管理およびＲＦ送信再試行アルゴリズムを提供する技術を示している。ネットワーク負荷管理は、１つまたは複数のアプリケーションによるデータの送信に対する帯域幅制約を実施する計算の一部に基づいて、１つまたは複数のアプリケーションに関連付けられたコンテンションウィンドウをサイジングする技術を含んでもよい。ＲＦ送信再試行管理は、リンク品質（例えば、ＲＦ干渉のレベル）およびトラフィック密度（例えば、ローカルＲＦ送信のレベル）の表示（representations）を含む入力の一部に基づいて、コンテンションウィンドウをリサイジングするアルゴリズムおよび／または技術を含んでもよい。
【０００９】
本明細書で示される技術は、任意のタイプのネットワーク上での使用に適用されてもよい。例示的かつ非限定的な方法によって、ネットワークは、スマートユーティリティメータ（例えば、電気、ガス、および／または水道メータ）、センサ（例えば、温度センサ、ウェザーステーション、周波数センサなど）、制御デバイス、変圧器、ルータ、サーバ、中継器（例えば、セルラ中継器）、スイッチ、バルブ、および他のネットワークデバイスとして実装されたノード、ならびに、前述したいずれかから生成および／または送信されるデータを含んでもよい。ルートノードは、ユーティリティスマートメータの自立ルーティングエリア（ＡＲＡ：autonomous routing area）のコンテキスト内で識別されてもよく、および、中央オフィスへの反動に対してさらなるネットワーク上でのデータの送信に対して構成されてもよい。例えば、ルートノードは、ユーティリティスマートメータの自立ルーティングエリア（ＡＲＡ）のコンテキスト内で、セルラルータとして構成されてもよく、メッシュネットワークからデータを受信してもよく、ならびに、そのデータを、中央オフィス、サーバ、または他の所望のロケーションへの転送に対して、インターネット内のサーバに送信してもよい。
【００１０】
例示的かつ非限定的な方法によって、ネットワーク負荷は、１つもしくは複数のノード、または、１つもしくは複数のノード上で動作している１つもしくは複数のアプリケーションに利用可能なネットワーク帯域幅の量を制限することによって、部分的に管理されてもよい。例えば、帯域幅の量は、各ノードおよび／またはアプリケーションの相対的優先度に従って、各ノードまたはいくつかのアプリケーションの各々に対するコンテンションウィンドウをサイジングおよび制御することによって、部分的に制御されてもよい。用語「コンテンションウィンドウ」は、チャネル上の送信が別のノードによって終了した後、および、ノードがその自身の送信を開始する前に、ノードが待機しなければならない期間を称してもよい。ノードのコンテンションウィンドウの終了に先行して別のノードが送信を開始する場合に、ノードは、その自身のコンテンションウィンドウに関連付けられたカウントダウンを一時停止させなければならず、および、他のノードにチャネルを使用させなければならない。各アプリケーションに関連付けられたコンテンションウィンドウの管理は、アプリケーションに割り当てられたネットワーク帯域幅を制限する効率的な手段である。例えば、チャネル上の送信が停止するときに（すなわち、無線周波数（ＲＦ）信号が現在、ヒア（hear）されないとき）、送信を開始することを要求しているアプリケーションは、それぞれ自身のコンテンションウィンドウの満了まで待機しなければならない。最短のコンテンションウィンドウを有しているアプリケーションは、最初に送信を開始することが可能であり、それによって、他のアプリケーションおよび／またはノードが送信することを回避することができる。したがって、コンテンションウィンドウの長さは、例えば、ユーティリティスマートメータのＡＲＡとして構成することができる複数のノードを備えているメッシュネットワークなどの、ＲＦネットワーク上のトラフィックを統制（govern）する要因となる。
【００１１】
別の例として、および、再び非限定的なものとして、ＲＦ送信再試行管理は、リンク品質の測定（例えば、ノード間のＲＦ送信の明瞭性（clarity））およびトラフィック密度の測定（例えば、ＲＦ送信でのビジーとなっているチャネルの時間の割合）を含んでいる入力の一部に基づいて、コンテンションウィンドウをリサイジングするアルゴリズムおよび／または技術を含んでもよい。特に、再試行管理は、前の送信が失敗した後のデータおよび／またはパケットの再送信のための技術を提供する。加えて、技術は、トラフィックのコリジョンに起因した送信障害とリンク品質問題とを区別することを支援することができる。１つの例では、リンク品質が良好な場合、コンテンションウィンドウ（例えば、ノードおよび／またはノード上で稼動しているアプリケーションに関連付けられた）は、トラフィック密度が高いが、コンテンションウィンドウが低い場合に、２倍にされてもよい。したがって、再試行管理技術は、不得策な（inadvisable）および／または保証されていない（unwarranted）コンテンションウィンドウを２倍にすることをもたらす、不良なリンク品質が高トラフィック密度として解釈される状況を区別する。
【００１２】
本明細書における議論は、いくつかのセクションを含む。各セクションは、非限定的なものと意図される。特に、この全体的な説明は、ネットワークおよび／もしくはトラフィック負荷管理（例えば、特定のアプリケーションおよび／または特定のノードによって使用されるネットワーク帯域幅を制限する技術）、ならびに、送信再試行管理（送信障害の後にコンテンションウィンドウのサイジングを制限する技術）において利用することができるコンポーネントを示すことを意図されているが、当該コンポーネントは必ずしも必要とされない。議論は、本明細書で示される技術を実装することができる代表的な環境としてスマートユーティリティメータおよび他のデバイスを含んでいるＡＲＡを示している、「例示的なネットワークアーキテクチャ」と題するセクションで開始する。次に、「例示的なノード構成」と題するセクションは、ＡＲＡなどのネットワークにおいて使用可能であり、および、送信障害の場合にネットワーク／トラフィック負荷管理および送信再試行管理を提供するノードにおけるプロセシングユニットの例示的な構成を示し、および、説明する。さらに、「例示的な方法」と題するセクションは、１つまたは複数のノード上で動作しているいくつかのアプリケーションの各々に利用可能なネットワーク帯域幅の量を制限するのに使用することができる技術、ならびに、リンク品質およびトラフィック密度を含んでいる入力の一部に基づいて、コンテンションウィンドウをリサイジングすることを含んでいる再試行管理のための技術を示し、および、説明する。最後に、議論は簡潔な結論で終了する。
【００１３】
セクションのタイトルおよび対応する要約を含んでいる、この簡潔な導入が読み手の便宜のために提供され、特許請求の範囲またはこの開示のいかなるセクションを示し、および／または、限定することを意図しているものではない。
【００１４】
＜例示的なネットワークアーキテクチャ＞
図１は、複数のノードを有している例示的なネットワークアーキテクチャ１００、１つのノードの例示的な詳細、インターネットなどのさらなるネットワークおよび中央オフィスへの接続を示している概略図である。ネットワークは、本明細書で示される上述した技術にしたがって、ネットワーク／トラフィック負荷管理およびＲＦ送信再試行管理に対して構成される。特に、ネットワークは、コンテンションウィンドウ管理を利用して、１つまたは複数のアプリケーションの各々に対するコンテンションウィンドウをサイジングすることによって、１つまたは複数のアプリケーションが使用することが許可される帯域幅の量を制限することができる、ネットワーク負荷管理に対して構成された１つまたは複数のノードを含む。加えて、ネットワークは、ノードおよび／またはアプリケーションの１つまたは複数のコンテンションウィンドウをリサイジングすることができるＲＦ送信再試行アルゴリズムで構成された１つまたはノードを含んでもよい。リサイジングは、トラフィックコリジョンをＲＦリンク品質に起因した送信障害と区別する入力の一部に基づいてもよい。
【００１５】
アーキテクチャ１００は、直接通信無線周波数（ＲＦ）信号、送信またはリンクを介して、互いに通信可能に結合された複数のノード１０２Ａ、１０２Ｂ、１０２Ｃ、１０２Ｄ．．．１０２Ｎ（総じて、ノード１０２と称される）を含んでもよい。この例では、Ｎは、ワイドエリアネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、ネイバーフッドエリアネットワーク（ＮＡＮ）、またはパーソナルエリアネットワーク（ＰＡＮ）などとして構成することができる、自立ルーティングエリア（ＡＲＡ）におけるノードの例示的な数を表している。
【００１６】
マルチチャネル環境では、複数のチャネルの各々は、複数のチャネルの各々に対して同一または異なる周波数範囲によって定義されてもよく、ならびに、各チャネルは、異なる周波数に関して中心にあってもよい。一部のインスタンスでは、複数のチャネルは、主として、予想される変調および環境条件に適合している周波数幅を有しているＲＦチャネルを備えている。複数のチャネルは、制御チャネルおよび複数のデータチャネルを備えてもよい。一部のインスタンスでは、制御チャネルは、ノード間で１つまたは複数のショートメッセージを通信するのに利用されて、データを転送するのに利用されることになるデータチャネルの１つを特定する。加えて、制御チャネルは、複数のノードによって利用されて、それらのコンテンションウィンドウの長さを示す情報を送信してもよい。コンテンションウィンドウの長さは、期間、「スロット」の数、または任意の他の同意された技術として表されてもよい。一般的には、制御チャネル上の送信は、データチャネル上の送信と比較して短い。
【００１７】
図１の例では、ノード１０２はまた、インターネットまたはイントラネットなどのバックホールネットワーク１０６に、ＡＲＡの接続ポイントを提供する、エッジデバイス（例えば、セルラリレー、セルラルータ、エッジルータ、ＤＯＤＡＧルートなど）などのルートノードを介して、中央オフィス１０４を通信するように構成される。中央オフィス１０４は、サーバ、パーソナルコンピュータ、ラップトップコンピュータなどの１つまたは複数のコンピューティングデバイスによって実装されてもよい。１つまたは複数のコンピューティングデバイスは、メモリと通信可能に結合された１つまたは複数のプロセッサを備えてもよい。一部の例では、中央オフィス１０４は、１つまたは複数のノードから受信されたデータの処理、分析、記憶および／または管理を実行する、集中化メータデータ管理システムを含む。例えば、中央オフィス１０４は、スマートユーティリティメータ、センサ、制御デバイス、ルータ、レギュレータ、サーバ、リレー、スイッチ、バルブ、および／または他のノードから取得されたデータを処理、分析、記憶、および／または管理してもよい。図１の例は、単一のロケーションにおいて中央オフィス１０４を示しているが、一部の例では、中央オフィスは、複数のロケーション間で分散されてもよく、ならびに、完全に除外されてもよい（例えば、高度に非集中化されたコンピューティングプラットフォームのケースでは）。
【００１８】
ネットワーク１０６は、無線もしくは有線ネットワーク、またはそれらの組合せを備えてもよく、ならびに、互いに相互接続され、および、単一の大規模ネットワークとして機能している個々のネットワークの集合であってもよい。示された例では、ノード１０２Ａは、セルラリレーとして構成されたルートノードとしてサービスして、ネットワーク１０６を介して、ＡＲＡの他のノード１０２Ｂ−１０２Ｎ、または、中央オフィス１０４に通信を中継し、または、それらから通信を中継する。
【００１９】
ノード１０２Ｄは、ノード１０２の各々の代表であってもよく、ならびに、ＲＦ信号１１０の手段による通信に対して構成された無線１０８、および、プロセシングユニット１１２を含んでもよい。無線１０８は、１つまたは複数のチャネル／周波数を介して、無線周波数（ＲＦ）信号を送信および／または受信するように構成されたＲＦ送受信機を備えている。一部の実装では、ノードの各々は、有線または無線通信に対して構成されてもよい。例示的であり、および、非限定的な方法によって、有線通信は、電力線通信（ＰＣＬ）、または、イーサネット（登録商標）などの他の有線通信ネットワーク技術を含んでもよい。無線の実装の１つの例では、ノード１０２は、各通信リンク１１０の制御チャネルおよび複数のデータチャネルなどの、複数の異なるチャネル上でデータを送信および受信するように構成された単一無線１０８を含んでもよい。無線１０８はまた、複数の異なる変調技術、データレート、プロトコル、信号強度、および／または電力レベルを実装するように構成されてもよい。加えて、無線は、「周波数ホッピング」スキームにおいて、複数の異なる周波数のそれぞれが、短期間の間に連続して同調するように構成されてもよい。アーキテクチャ１００は、ノード１０２が、異なるタイプのノード（例えば、スマートメータ、セルラリレー、センサなど）、異なる世代もしくはモデルのノード、ならびに／または、異なるチャネル上で送信することが可能であり、および、異なる変調技術、データレート、プロトコル、信号強度、および／もしくは電力レベルを使用することが可能なノードを含んでもよいという点で、ノードの異種（heterogeneous）ネットワークを表してもよい。
【００２０】
プロセシングユニット１１２は、メモリ１１６と通信可能に結合された１つまたは複数のプロセッサ１１４を含んでもよい。プロセッサ１１４は、種々のモジュール、マネージャ、アルゴリズムなどを実行してもよく、メモリ１１６はそれらを含んでもよい。モジュールは、ソフトウェアおよび／またはファームウェアで構成されてもよく、ならびに、プロセッサ１１４によって実行可能であってもよい。代替的な実施形態では、モジュールの一部またはすべては、ハードウェアによって全体的にまたは部分的に実装されてもよい。ハードウェアの例は、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）などの他のデジタルデバイス、または上記機能を実行するように構成された他のデバイスを含む。
【００２１】
メモリ１１６は、モノシリック（monolithic）エンティティとして示されているが、リードオンリメモリ、書き込み可能メモリ、永続もしくは非永続メモリなどの、類似してもしくは異なって構成された複数のデバイスとして構成されてもよい。メモリ１１６は、プロセッサ１１４によって、種々の機能を実装するように実行可能な１つまたは複数のソフトウェアおよび／またはファームウェアモジュールを記憶するように構成されてもよい。
【００２２】
メモリ１１６は、コンピュータ可読媒体を備えてもよく、ならびに、ランダムアクセスメモリ（ＲＡＭ）などの揮発性メモリ、および／または、リードオンリメモリ（ＲＯＭ）もしくはフラッシュＲＡＭなどの不揮発性メモリの形式をとってもよい。コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールもしくはコンピューティングデバイスの１つもしくは複数のプロセッサによる実行のための他のデータなどの情報を記憶するための任意の技術にしたがって実装される、揮発性および不揮発性、着脱可能および着脱不能媒体を含む。コンピュータ可読媒体の例は、相変化メモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去可能リードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、もしくは他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、もしくは他の磁気記憶デバイス、または、コンピューティングデバイスによるアクセスのために情報を記憶するのに使用することができる非送信媒体を含むが、これらに限定されない。上述したように、コンピュータ可読媒体は、変調データ信号および搬送波などの通信媒体は含まない。
【００２３】
トラフィック負荷マネージャ１１８は、メモリ１１６において定義されたプロセッサ実行可能命令を含んでもよく、ならびに、プロセッサ１１４の動作によって操作されてもよい。一態様では、トラフィック負荷マネージャ１１８は、各々に割り当てられることになるネットワーク帯域幅の相対量にしたがって、ノード上で動作しているアプリケーションを優先付けるように構成されてもよい。１つの任意の例では、３つのアプリケーション（例えば、ソフトウェアプログラム）がノード上で動作している場合（例えば、プロセッサによって実行されている）、トラフィック負荷マネージャ１１８は、３つのアプリケーションがそれぞれ、利用可能な帯域幅の５０％、２０％、および３０％の共有を受けることになるように、当該アプリケーションを優先付けてもよい。他の例では、各アプリケーションは、ノードの相帯域幅のすべてもしくは一部を割り当てられてもよく、または、まったく割り当てられなくてもよい。
【００２４】
トラフィック負荷マネージャ１１８は、ノード上の１つまたは複数のアプリケーションの各々によって使用されることになるコンテンションウィンドウの初期サイズを割り当てることによって、複数のアプリケーションの各々に利用可能なネットワーク帯域幅の相対量を制限し、および／または、実施してもよい（送信エラーに続いてなど、一定の時間経過後に定期的に、ノードまたはアプリケーションが一定の時間内に送信する機会を有していない場合などの一部の例では、初期コンテンションウィンドウサイズは、変更されてもよい）。したがって、高優先のネットワーク帯域幅を有しているアプリケーションは、ネットワークアクセスを取得する際にそれらにアドバンテージを付与する、より短いコンテンションウィンドウが割り当てられ、低優先度を有しているアプリケーションは、高優先のアプリケーションを、ネットワークがビジー（busy）のときの時間の間にデータおよび／またはパケットの送信を完了するまで、待機させることができる、より長いコンテンションウィンドウが割り当てられる。したがって、トラフィック負荷マネージャ１１８は、高優先アプリケーションへのネットワークリソースの可用性を保証することが可能となり、ならびに、低優先アプリケーションが、ネットワークの帯域幅を過度に高い割合で利用することを回避することが可能となる。
【００２５】
送信再試行マネージャ１２０は、送信障害の場合に動作することができる、ＲＦ送信再試行を統括するように構成されたＲＦ送信再試行アルゴリズムを含んでもよい。１つの例では、送信再試行マネージャ１２０は、ＲＦ送信再試行アルゴリズムにおける使用のためのデータ（例えば、ノード間のＲＦリンク品質に関するデータ、および、ネットワークの一部におけるトラフィック密度データ）を収集してもよい。ＲＦ送信再試行アルゴリズムは、収集されたデータを使用して、コンテンションウィンドウが変更されるべきか（例えば、２倍にする）、および／または、ショート（short）もしくはロング（long）再試行カウント（例えば、許可された再試行の試みの数）が調節されるべきか（例えば、減少させる）を判定してもよい。
【００２６】
＜例示的なノード構成＞
図２は、個々のノードのプロセシングユニット１１２の例示的な詳細を示している図である。上述したように、プロセシングユニット１１２は、プロセッサ１１４およびメモリ１１６を含んでもよい。上述したように、トラフィック負荷マネージャ１１８は、ノードおよび／またはノード上の個々のアプリケーションによって送信されたデータおよび／またはパケットのタイミングおよび／または量を管理し、および／または、制限するように構成されてもよい。特に、トラフィック負荷マネージャ１１８は、ノード上で動作しているアプリケーション２０６、２０８、２１０の優先度を含んでいる情報を使用して、ノード上で動作している複数のアプリケーションの各々による使用に対して適切なネットワーク帯域幅の量（例えば、相対量）を判定してもよい。１つの例では、ノード上で稼動している１つまたは複数のアプリケーションは、スタンドアロン（stand-alone）アプリケーションであってもよい。第２の例では、ノード上で稼動している１つまたは複数のアプリケーションは、１つまたは複数の分散されたアプリケーション、すなわち、複数のノード上で実行しているコードを有しているアプリケーションの一部であってもよい。
【００２７】
１つの例では、トラフィック負荷マネージャ１１８は、ノード上で動作している各アプリケーション（例えば、アプリケーション２０６、２０８、２１０）に対するコンテンションウィンドウのサイズを算出するように構成されてもよい。したがって、異なるコンテンションウィンドウは、データの特定の送信に適用されてもよく、および、コンテンションウィンドウは、送信されることになるデータに含まれる、複数のアプリケーションが作成したデータの少なくとも一部に基づいてもよい。第２の例では、トラフィック負荷マネージャ１１８は、ノードによってなされるすべての送信を統括するコンテンションウィンドウサイズを算出するように構成されてもよい。第３の例では、トラフィック負荷マネージャ１１８は、送信されることになるデータを作成したアプリケーションの現在の優先度、そのデータ（データの世代（age）、データの量、および／もしくはネットワーク上のデータに対する要求の一部に基づいてもよい）の優先度を含んでいる複数の要因に基づいて、ならびに／または、ネットワークトラフィックレベルに基づいて、コンテンションウィンドウを算出するように構成されてもよい。
【００２８】
アプリケーション優先付けモジュール２０２は、ノード、ネットワークおよび／もしくは中央オフィスなどへの相対的な優先度を含んでいる、ノード上で動作しているアプリケーションの静的および／または動的レポートを、トラフィック負荷マネージャ１１８に提供してもよい。アプリケーションの優先度は、いずれのアプリケーションがより高い優先度を有してデータを送信するかを判定するように、トラフィック負荷マネージャ１１８を支援する。優先度は、各々によって作成されるデータの重要度、そのデータの時間依存性（time-sensitivity）、そのデータの量、および／または、他の要因に基づいてもよい。したがって、アプリケーション優先付けモジュール２０２は、ノードのメモリ１１６に記憶され、および／または、動作しているアプリケーション２０６、２０８、２１０を優先付けするように構成されてもよい。
【００２９】
コンテンションウィンドウサイジングアルゴリズム２０４は、ノード上のアプリケーション（例えば、アプリケーション２０６、２０８、２１０）の各々に対するコンテンションウィンドウのサイズ（すなわち、長さおよび／または継続時間（duration of time））を算出するように構成されてもよい。加えて、および／または、それに代えて、コンテンションウィンドウサイジングアルゴリズム２０４は、ノード上のアプリケーションによって作成されるデータもしくは命令の送信に適用することができる、ノードに対するコンテンションウィンドウのサイズを算出するように構成されてもよい。上述したように、アプリケーション２０６、２０８、２１０は、ノード上で動作しているスタンドアロンアプリケーションであってもよく、または、複数のノード上で展開される実行可能コードを有している分散アプリケーションの一部とすることができるアプリケーションであってもよい。
【００３０】
送信再試行マネージャ１２０は、送信ノード上の送信再試行の状況（aspects）を統括してもよい。特に、送信再試行マネージャ１２０は、受信されることになる送信されたデータの障害、および／または、送信ノードの、送信に応答した確認応答を受信することの障害に応答して、送信再試行を要求または実行してもよい。
【００３１】
一態様では、送信再試行マネージャ１２０は、トラフィック負荷マネージャ１１８によって設定された元のサイズから、コンテンションウィンドウ（例えば、アプリケーションに関連付けられたコンテンションウィンドウ）をリサイジングしてもよい。リサイジングされたコンテンションウィンドウは、元のコンテンションウィンドウよりも長くてもよい。１つの例では、コンテンションウィンドウは、１つまたは複数のリンク１１０（例えば、ネットワークの一部）上の高いトラフィック密度に起因してリサイジングされてもよい。
【００３２】
送信再試行マネージャ１２０は、隣接ノード間のＲＦリンク品質を示しているデータ、および、ネットワークのローカルエリアにおけるトラフィック密度（例えば、ＲＦ送信の周波数／時間／継続時間など）を示しているデータを利用してもよい。データは、ＲＦ送信再試行アルゴリズムにおいて送信再試行マネージャ１２０によって使用されてもよい。ＲＦ送信再試行アルゴリズムは、収集されたデータを使用して、コンテンションウィンドウが変更されるべきか（例えば、２倍にする）、および／または、ショートもしくはロング再試行カウント（例えば、許可された再試行の試みの数）が減少されるべきかを判定してもよい。１つの例では、コンテンションウィンドウは、第１の再試行に関する使用に対して２倍にされてもよいが、別の例では、コンテンションウィンドウは、第２のおよび後続の再試行に関してのみ２倍にされてもよい。
【００３３】
リンク品質評価モジュール２１２は、１つまたは複数のネットワークリンク（例えば、図１のリンク１１０）上のリンク品質に関する情報を、送信再試行マネージャ１２０に提供してもよい。リンク品質は、データおよび／またはパケットをルーティングする目的で利用可能であるような既存のリンク品質基準を使用して測定されてもよい。測定されると、リンク品質は、基準を割り当てられてもよい。基準は、良好または不良、ゼロまたは１などの２値（binary）であってもよい。代わりに、基準は、より複合的であってもよく、ならびに、より詳細なおよび／または正確な測定を反映することができるリンク品質の目盛り（graduations）を示してもよい。そのような割り当ては、干渉または他の問題に起因したＲＦ送信障害の可能性を示してもよい。
【００３４】
トラフィック密度評価モジュール２１４は、ネットワークにおける１つまたは複数の無線ＲＦリンク上のトラフィック密度のレベルに関する情報を、送信再試行マネージャ１２０に提供してもよい。トラフィック密度は、ノードがチャネル上でアクティブに送信している時間を測定することなどによって、時間の変動したウインドウ（sliding window of time）上で判定されてもよい。１つの例では、送信再試行マネージャ１２０は、１つまたは複数のネットワークリンク上でのＲＦ送信のトラフィック密度に、高いもしくは低いとして基準を割り当ててもよい。基準は、高トラフィックまたは低トラフィック、ゼロまたは１などの２値であってもよい。代わりに、基準は、より複合的であってもよく、ならびに、より詳細な、および／または、正確な測定を反映することができる、ネットワークトラフィックの目盛りを示してもよい。そのような割り当ては、他の送信とのコリジョンに起因したＲＦ送信障害の可能性を示してもよい。
【００３５】
送信再試行マネージャ１２０は、品質評価モジュール２１２からのリンク品質基準、および、トラフィック密度モジュール２１４からのトラフィック密度もしくはネットワークアクティビティレベル測定を、算出への入力として使用してもよい。送信再試行マネージャ１２０によって実行される算出は、１つまたは複数のコンテンションウィンドウのサイズを確立してもよい。このようなコンテンションウィンドウは、１つまたは複数のアプリケーションにそれぞれ関連付けられてもよく、または、コンテンションウィンドウは、ノード自体に関連付けられてもよい。例えば、リンク品質が良好である場合は、コンテンションウィンドウは、トラフィック密度が高いがコンテンションウィンドウが短い場合に、２倍とされてもよい。さらなる例として、リンク品質が不良である場合は、コンテンションウィンドウは、トラフィック密度が高いがコンテンションウィンドウが短い場合に、２倍とされてもよい。
【００３６】
動作では、トラフィック負荷マネージャ１１８は、複数のアプリケーション２０６、２０８、２１０の送信を優先付けることを含む、ネットワークトラフィック管理を支援してもよい。トラフィック負荷マネージャ１１８は、アプリケーション優先付けモジュール２０２からの入力を利用して、どのアプリケーションが送信するのにより高いもしくはより低い優先度を有するべきかを判定してもよい。トラフィック負荷マネージャ１１８は、コンテンションウィンドウサイジングアルゴリズム２０４からの入力を利用して、初期もしくは元のコンテンションウィンドウサイズを作成して、アプリケーション優先付けモジュール２０２によって判定される送信の優先度を実施してもよい。したがって、データおよび／またはパケット２２０は、コンテンションウィンドウ２１８によって示される期間を待機した後に、データ送信機２１６によって送信されてもよい。
【００３７】
一部の環境では、送信が失敗し、および／または、送信の確認応答が受信されないことになる。このような環境下では、送信再試行マネージャ１２０は、データ２２０の再送信の状況を制限するように動作してもよい。再試行マネージャ１２０は、リンク品質評価モジュール２１２およびトラフィック密度評価モジュール２１４から入力を受信してもよく、ならびに、その情報を使用して、コンテンションウィンドウ２１８が調節されるべきか、および／または、最大再試行カウントが調節されるべきかを判定してもよい。再試行マネージャ１２０による判定にしたがって、データ２２０は、送信機２１６によって再送信されてもよい。
【００３８】
図３は、アプリケーション２０８、２１０、２１２に割り当てられた元のおよびリサイジングされたコンテンションウィンドウの例を示しているブロック図である。例えば、アプリケーション２０８は、元のコンテンションウィンドウ３０２が割り当てられる。元のコンテンションウィンドウ３０２の長さは、他のアプリケーションと比較して、その優先度が適切であるアプリケーション２０８に利用可能なネットワーク帯域幅の最大量を提供、制限および／または実施するようにサイジングされてもよい。１つの例では、元のコンテンションウィンドウ３０２および／またはその長さは、アプリケーション優先付けアルゴリズム２０２および／またはコンテンションウィンドウサイジングアルゴリズム２０４からの入力を使用して、図１および２に関して示されたトラフィック負荷マネージャ１１８によって割り当てられてもよい。同様に、他のアプリケーション２１０および２１２は、元のコンテンションウィンドウ３０４、３０６を割り当てられてもよく、ならびに、それらのアプリケーションの優先度に適切な長さ、および、各々に利用可能なことが意図される帯域幅を有してもよい。
【００３９】
一部のケースでは、送信は成功することとなり、リサイジングされたコンテンションウィンドウが利用されてもよい。このことは、特に、ノードがネットワーク上での高トラフィック状況を識別するときである。それはまた、ノードが、高トラフィック状況を、プアなリンク品質（例えば、プアな送信環境）に起因した送信障害から区別するときに当てはまる。したがって、リサイジングされたコンテンションウィンドウは、ノードおよび／またはノード上で動作しているアプリケーションに適用されてもよい。１つの例では、アプリケーション２０８に関連付けられた元のコンテンションウィンドウ３０２は、リサイジングされて、リサイジングされたコンテンションウィンドウ３０８になってもよい。通常は、リサイジングされたコンテンションウィンドウは、任意の所与のアプリケーションに対する元のコンテンションウィンドウよりも大きくなる。１つの例では、リサイジングされたコンテンションウィンドウ３０８および／またはその長さは、リンク品質評価モジュール２１２および／またはトラフィック密度評価モジュール２１４からの入力を使用して、図１および２に関して示された送信再試行マネージャ１２０によって割り当てられてもよい。同様に、他のアプリケーション２１０および２１２の元のコンテンションウィンドウ３０４、３０６は、送信エラーが検出された場合に、リサイジングされたコンテンションウィンドウ３１０になってもよい。
【００４０】
図４は、リンク品質、トラフィック密度、およびコンテンションウィンドウのリサイジングに関する決定の間の関係の例を示しているテーブルである。１つの例では、関係は、図１および／または２の送信再試行マネージャ１２０によって利用される。図４は、「良好」および「不良」なリンク品質、ならびに、「低」および「高」トラフィック密度を示す２値を示している。さらなる例では、１つ／双方の要因のさらなる目盛りが利用され（例えば、良好、中位、不良）、ならびに／または、例示的な数が使用される（例えば、品質＝０．１、品質＝０．２など）。図４で示される例では、リンク品質が良好であると判定され、および、トラフィック密度が低いと判定される場合、ノードおよび／またはノード上で動作しているアプリケーションに関連付けられたコンテンションウィンドウが変更されないままであるとの決定がされてもよい。リンク品質は、リンク品質評価モジュール２１２によって評価されてもよく、ならびに、トラフィック密度は、トラフィック密度評価モジュール２１４によって評価されてもよい。決定は、送信再試行マネージャ１２０によってなされてもよい。また、図４の例によって示されるように、良好なリンク品質および高トラフィック密度は、コンテンションウィンドウを２倍にすることになり、ならびに、低トラフィック密度は、コンテンションウィンドウを変更しないことになる。さらに、不良なリンク品質および高トラフィック密度は、コンテンションウィンドウを２倍にすることになることに加え、ロングおよび／またはショートの許容可能な再試行カウント、すなわち、送信されたデータの許可された再送信の数を、減少させる可能性がある。
【００４１】
＜例示的な方法＞
図５乃至９の例示的な方法を、図１乃至４の構成を部分的に参照することによって理解することができる。しかしながら、図５乃至９は、一般的な適用性を含んでおり、ならびに、他の図面および／または上述した内容によっては限定されない。さらに、本明細書で上記示された各方法は、ハードウェア、ソフトウェアもしくはそれらの組合せで実装することができる動作のシーケンスを表している、論理フローチャートにおける振舞い、ブロックもしくは動作の集合として示される。方法は、プロセッサに通信可能に結合されたメモリに、トラフィック負荷管理および／または送信再試行管理の方法などの方法を実行するコンピュータ実行可能命令を記憶すること、ならびに、プロセッサ上で命令を実行することを含んでもよい。
【００４２】
ソフトウェアのコンテキストでは、オペレーションは、１つまたは複数のプロセッサによって実行されると、定義されたオペレーションを実行する、１つまたは複数のコンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令を表している。このような記憶媒体、プロセッサ、およびコンピュータ可読命令を、所望の設計または実装にしたがって、システム内に位置付けることができる（例えば、図１のノード１０２Ｄまたは図２のプロセシングユニット１１２）。図１および２に示される記憶媒体は、通常、着脱可能および着脱不能の両方の記憶媒体、ならびに、任意の技術を表している。したがって、定義されたオペレーションは、図５乃至９で示されるような動作を表しており、ならびに、示された動作を実行する実行可能命令で構成された１つまたは複数のプロセッサの制御の下にあってもよい。通常、コンピュータ実行可能命令は、特定の機能を実行し、または、特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などを含む。オペレーションが示される順序は、限定的なものと意図されず、ならびに、示されたオペレーションは、異なる順序で、および／または、実装する方法と並行して組み合わされてもよい。上記議論は、本明細書で示された他の方法に適用してもよい。
【００４３】
コンピュータ可読媒体、コンピュータ記憶媒体および／またはメモリは、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報の記憶のための任意の技術にしたがって実装される、揮発性および不揮発性、着脱可能および着脱不能媒体を含む。コンピュータ可読媒体は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去可能リードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスクリードオンリメモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または、コンピューティングデバイスによるアクセスのために情報を記憶するのに使用することができる他の非送信媒体を含むが、それらに限定されない。このような任意のコンピュータ可読媒体は、システムの一部であってもよい。さらに、コンピュータ可読媒体は、プロセッサにより実行されると、本明細書で示される種々の機能および／またはオペレーションを実行する、コンピュータ実行可能命令を含んでもよい。
【００４４】
加えて、本明細書の目的のために、コンピュータ可読媒体は、特定用途向け集積回路（ＡＳＩＣ）または他のハードウェアデバイスのすべてまたは一部を含んでもよい。このようなハードウェアデバイスは、トラフィック負荷および再試行管理を実行する機能を含む、他の機能を含むように構成されてもよい。したがって、このような集積回路内で、１つまたは複数のプロセッサは、論理、トランジスタ、もしくは他のコンポーネント、または、オンボードメモリによって定義することができる実行可能命令で構成される。
【００４５】
一方、通信媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波もしくは他の送信機構などの変調データ信号における他のデータを具体化してもよい。本明細書で定義されるように、コンピュータ可読媒体は通信媒体を含まない。
【００４６】
図５は、ネットワーク負荷管理および送信再試行管理を実行することができる、例示的な方法５００を示すフローチャートである。オペレーション５０２においては、コンテンションウィンドウがサイジングされる。コンテンションウィンドウは、多くの要因にしたがって、元のおよび／もしくは開始サイズにセットされて、コンテンションウィンドウが割り当てられるアプリケーションおよび／もしくはノードで許容されることになる最大共有もしくは最大帯域幅を提供および／もしくは実施するなどしてもよい。図１および２の例では、コンテンションウィンドウは、ネットワーク上のトラフィック負荷を管理するツールとしてコンテンションウィンドウの選択を管理する、トラフィック負荷マネージャ１１８にしたがって設定されてもよい。図６は、コンテンションウィンドウをサイジングするのに使用することができる技術の例を含む。
【００４７】
オペレーション５０４においては、コンテンションウィンドウが経過した後にデータおよび／またはパケットがネットワークにおけるノードから送信される、すなわち、コンテンションウィンドウの完了もしくは満了に続いて、パケットが送信される。オペレーション５０６においては、パケット送信障害の場合に、送信ノードは、送信されたパケットの確認応答の受信をせずに、タイムアウト期間を待機してもよい。障害を考慮して、再試行アルゴリズムが入力（enter）される。図１および２の例では、送信再試行は、リンク品質およびトラフィック密度情報を使用して、送信再試行を管理し、ならびに、第１の試行で送信に成功しなかった情報を送信する、送信再試行マネージャ１２０にしたがって実行されてもよい。
【００４８】
オペレーション５０８においては、ノードと、先にデータが送信された宛先ノードとの間のリンクの品質基準が取得される。品質基準は、送信再試行マネージャ１２０によって実行されるなどの再試行アルゴリズムへの入力として使用されてもよい。図２の例では、品質基準は、ＲＦ送信品質、明瞭性（clarity）、干渉などを評価するリンク品質評価モジュール２１２によって取得されてもよい。
【００４９】
オペレーション５１０においては、トラフィック密度（例えば、ネットワークまたはネットワークにおけるリンクの一部のアクティビティのレベル）がチェックされる。トラフィック密度はまた、送信再試行マネージャ１２０によって実行されるなどの再試行アルゴリズムへの入力として使用されてもよい。図２の例では、ネットワークアクティビティのレベルは、ネットワークの示された一部における隣接したネットワーク上のトラフィック密度を評価する、トラフィック密度評価モジュール２１４によって取得されてもよい。
【００５０】
オペレーション５１２においては、コンテンションウィンドウは、元のサイズから、再試行アルゴリズムによって示されるサイズにリサイジングされてもよい。図１および２の例では、送信再試行マネージャ１２０は、このようなアルゴリズムを提供してもよい。このようなアルゴリズムは、リンクの品質基準およびネットワークのアクティビティのレベルもしくはトラフィック密度の１つもしくは両方を利用してもよく、何もせずもしくはコンテンションウィンドウを２倍にしてもよい。１つの例では、リンクの品質基準およびネットワークのトラフィック密度は、良好もしくは不良の品質基準、ならびに、トラフィック密度の高もしくは低レベルなどの２値であってもよい。代わりに、品質基準および／またはトラフィック密度は、とり得るトラフィック密度の範囲の割合などの、より詳細に段階付けられた方法で表示されてもよい。
【００５１】
オペレーション５１４においては、リンクの品質基準が不良であり、および、トラフィック密度のレベル（ネットワークアクティビティ）が高い場合に、コンテンションウィンドウの長さは、第２のおよび後続の再試行で２倍にされる。さらなる例では、図４で表示されるアルゴリズムは、図２の送信再試行マネージャ１２０によって採用されて、失敗したパケットの送信前に待機することを示すことを支援してもよい。オペレーション５１６においては、確認応答が受信されなかった（オペレーション５０６においてなど）パケットは、リサイジングされたコンテンションウィンドウの満了後に再送信される。
【００５２】
図６は、コンテンションウィンドウをサイジングすることができ、および、ネットワーク負荷管理を実行することができる複数の例示的なオペレーションを示すフローチャート６００である。例示的なオペレーションの各々は、単一で、または、他の例示的なオペレーションと組み合わせて使用されてもよい。オペレーション６０２においては、ノード上の複数のアプリケーションの各々に対し、またはそれらの間で優先度および／または相対的優先度が判定されてもよい。図２の例では、アプリケーション優先付けモジュール２０２は、ノード上で動作している複数のアプリケーションの相対的優先度を判定してもよい。どの程度のネットワーク帯域幅が、絶対的期間で、もしくは、他のアプリケーションに対して相対的に、のいずれかで、各アプリケーションに与えられるべきかを判定するために、優先度を使用することができる。特に、優先度は、ネットワーク帯域幅が、ネットワーク帯域幅の一部割り当てが要求および／または予想されるポイントに制限されるときに使用されてもよい。
【００５３】
オペレーション６０４において、コンテンションウィンドウは、ノード上の複数のアプリケーションへの複数の帯域幅制約を実施するのにサイジングされてもよい。複数のアプリケーションの相対的優先度を使用することによって、複数のコンテンションウィンドウは、複数のアプリケーションに対する適切な相対的帯域幅割り当てを実施するためにサイジングされてもよい。
【００５４】
オペレーション６０６において、コンテンションウィンドウは、アプリケーションがパケットにおいてデータを作成したことの少なくとも一部に基づいてサイジングされてもよい。ノードがパケットを送信している環境では、ノードは、アプリケーションがパケットを作成したことに基づいて、送信における使用に対してコンテンションウィンドウを算出してもよい。
【００５５】
オペレーション６０８において、コンテンションウィンドウは、アプリケーションに対して帯域幅制約を実施する計算に基づいてサイジングされてもよい。したがって、複数のコンテンションウィンドウは、複数のアプリケーション、ノード、またはオブジェクトもしくはデバイスにより生成される他のデータおよび／もしくはパケットに対して複数の同様のおよび／もしくは異なる帯域幅制約を実施するのに使用されてもよい。
【００５６】
オペレーション６１０において、コンテンションウィンドウサイズは、相対的優先度に基づいて、少なくとも２つのアプリケーションの各々に関連付けられてもよい。
【００５７】
オペレーション６１２において、コンテンションウィンドウサイズは、相対的優先度に基づいて、少なくとも２つのアプリケーションの各々に関連付けられる。図２の例では、コンテンションウィンドウサイジングアルゴリズム２０４は、ノード上で動作している複数のアプリケーションのそれぞれに関連付けられた複数のコンテンションウィンドウの各々のサイズをそれぞれ判定してもよい。さらなる例では、複数のアプリケーションが複数のコンテンションウィンドウに関連付けられるときに、異なるアプリケーションにそれぞれが関連付けられた異なるパケットのシーケンスが、異なってサイジングされたコンテンションウィンドウのシーケンスの後にノードによって送信されてもよい。
【００５８】
図７は、再試行管理の一部としてコンテンションウィンドウをリサイジングするのに使用されるなどの、品質基準を取得することができる例示的な方法７００を示すフローチャートである。例示的な方法のすべてまたは一部は、失敗したパケットの再送信の過程で、図２の送信再試行マネージャ１２０によって実行されてもよい。オペレーション７０２において、予想送信時間アルゴリズムは、ノード上で動作してもよい。図２の例では、リンク品質評価モジュール２１２は、予想送信時間アルゴリズムを使用して、実際の送信時間を比較するベースラインを作成してもよい。オペレーション７０４において、品質基準は、予想送信時間と送信の実際の測定時間との比較に基づいて算出されてもよい。図２の例では、リンク品質評価モジュール２１２は、比較に基づいて、品質基準を算出してもよい。
【００５９】
図８は、再試行（例えば、ＲＦメッセージの再送信）管理の一部としてコンテンションウィンドウをリサイジングするのに使用されるなどの、トラフィック密度および／またはネットワークアクティビティを測定することができる例示的な方法８００を示すフローチャートである。図２の例では、トラフィック密度測定および評価は、アルゴリズム８００またはそれと同等のものを採用することができるトラフィック密度評価モジュール２１４によって実行される。オペレーション８０２においては、リンクが定義される媒体がビジーである間に時間が測定される。オペレーション８０４においては、アクティビティのレベル（例えば、トラフィック密度）は、変動する（sliding）ウインドウに関する測定された時間の割合として表示されてもよい。したがって、ネットワークまたはその一部がビジーである時間の割合が測定されてもよい。
【００６０】
図９は、送信再試行管理における技術として、コンテンションウィンドウのリサイジングを実行することができる例示的な方法９００を示すフローチャートである。図２の例では、送信再試行マネージャ１２０は、方法９００を実行してもよい。オペレーション９０２においては、リンク品質が評価される。評価は、ＲＦ「リンク」上の２つのノード間のＲＦ送信品質の評価（assessment）を含んでもよい。評価（assessment）は、ＲＦ干渉、ＲＦ障害などの評価を含んでもよい。図２の例では、評価は、リンク品質評価モジュール２１２によって実行されてもよい。上記示したように、リンク品質の評価は、粒度が細かい（granular）方法でなされてもよく、および、割合などによって表されてもよい。図９の例では、リンク品質は、２値の方式で評価されてもよく、および、「良好」もしくは「不良」、すなわち良好のリンク品質もしくは不良のリンク品質のいずれかとして表されてもよい。オペレーション９０４においては、リンク品質が「良好」として評価される（rated）場合、トラフィック密度が評価される。図２の例では、これは、トラフィック密度評価モジュール２１４によって実行されてもよい。上記示したように、トラフィック密度の評価は、粒度が細かい方法でなされてもよく、および、割合などによって表されてもよい。図９の例では、トラフィック密度は、２値の方式で評価されてもよく、および、「低」もしくは「高」、すなわち、１つもしくは複数のリンクまたはネットワークの一部の上での低トラフィック密度もしくは高トラフィック密度のいずれかとして表されてもよい。オペレーション９０６においては、リンクの品質基準が良好であり、および、トラフィック密度のレベルが低い場合は、コンテンションウィンドウは、元のサイズ（トラフィック負荷マネージャ１１８および／またはコンテンションウィンドウサイジングアルゴリズム２０４によって判定されるような、図２を参照）のままとなる（left at an original size）。オペレーション９０８において、リンクの品質基準が良好であり、および、トラフィック密度のレベルが高い場合は、コンテンションウィンドウの長さは、２倍とされてもよい。
【００６１】
オペレーション９１０において、リンク品質が「不良」として評価された場合、トラフィック密度はオペレーション９０４と類似の方法で評価される。オペレーション９１２において、リンクの品質基準が不良であり、および、トラフィック密度のレベルが低い場合は、コンテンションウィンドウは元のサイズのままとされてもよい。オペレーション９１４において、リンクの品質基準が不良であり、および、トラフィック密度のレベルが高い場合は、コンテンションウィンドウの長さは、２倍とされてもよい。オペレーション９１６において、オペレーション９１４のそれらと類似の条件下で、リンクの品質基準が不良であり、および、トラフィック密度のレベルが高い場合は、ショート再試行カウント最大値（short retry count maximum）およびロング再試行カウント最大値（long retry count maximum）が減少されてもよい。このことは、一般的に、送信再試行が成功する可能性が低いときに、送信再試行の数を減少させる。
【００６２】
オペレーション９１８においては、リンクの品質基準が不良の場合に、送信プロトコルにおける上位レイヤに通知されてもよい。
【００６３】
＜結論＞
本発明が構造的な特徴および／または方法的な動作に特有な言語で示されてきたが、添付の特許請求の範囲で定義された本発明は、必ずしも、示された特有の特徴または動作に限定されないむしろ、特有の特徴および動作は、特許請求の範囲を実装する例示的な形式として開示される。
【図１】
0005993962.tif 000002
【図２】
0005993962.tif 000003
【図３】
0005993962.tif 000004
【図４】
0005993962.tif 000005
【図５】
0005993962.tif 000006
【図６】
0005993962.tif 000007
【図７】
0005993962.tif 000008
【図８】
0005993962.tif 000009
【図９】
0005993962.tif 000010