(57)【要約】  アドホック無線コンピュータネットワーク内での節電の方法は、最適ＡＴＩＭメッセージ交換ウィンドウを判定する。この方法は、（ａ）ＡＴＩＭウィンドウ中にＡＴＩＭメッセージの交換に参加するノードの有効個数を判定し、（ｂ）ノードの有効個数を使用して、データフレーム送信ウィンドウの長さを計算し、（ｃ）計算されたデータフレーム送信ウィンドウを使用してＡＴＩＭウィンドウの長さを計算する。１つの例で、この方法は、ＡＴＩＭメッセージの送信側の個数に基づいてノードの有効個数を判定する。もう１つの例で、ノードの有効個数は、ＡＴＩＭメッセージの送信側と受信側との両方に基づいて判定される。この方法は、所与の時間期間内の正常なＡＴＩＭメッセージ送信の回数からノードの有効個数を判定することができる。計算されたＡＴＩＭウィンドウサイズを、ＡＴＩＭウィンドウサイズを動的に調整する他の方法に初期値として提供することができる。【選択図】  図１０
2009518967.tif 000002
【特許請求の範囲】
【請求項１】
ＡＴＩＭウィンドウ中にＡＴＩＭメッセージの交換に参加するノードの有効個数を判定するステップと、
ノードの前記有効個数を使用して、データフレーム送信ウィンドウの長さを計算するステップと、
前記計算されたデータフレーム送信ウィンドウを使用して前記ＡＴＩＭウィンドウの長さを計算するステップと
を含む、アドホック無線コンピュータネットワーク内での節電の方法。
【請求項２】
ノードの前記有効個数が、ＡＴＩＭメッセージの送信側の個数によって与えられる、請求項１に記載の方法。
【請求項３】
ノードの前記有効個数が、前記ＡＴＩＭメッセージの送信側及び受信側の個数によって与えられる、請求項１に記載の方法。
【請求項４】
所与の時間期間が、前記ＡＴＩＭウィンドウのうちでビーコン送信及び残余データフレーム送信の外の部分である、請求項１に記載の方法。
【請求項５】
ノードの前記有効個数が、所与の時間期間内の正常なＡＴＩＭメッセージ送信の回数から導出される、請求項１に記載の方法。
【請求項６】
正常なＡＴＩＭメッセージ送信の回数が、チャネル衝突頻度及び送信の試みのレートに基づいて推定される、請求項１に記載の方法。
【請求項７】
前記チャネル衝突頻度及び送信の試みの前記レートが、平均コンテンションウィンドウサイズに対する反復手順を使用して導出される、請求項６に記載の方法。
【請求項８】
前記平均コンテンションウィンドウサイズの初期値が、バックオフインターバルの長さである、請求項７に記載の方法。
【請求項９】
各ノードの前記バックオフインターバルが、幾何学的に分布する、請求項８に記載の方法。
【請求項１０】
送信の試みの前記レートが、指数関数的に分布する、請求項６に記載の方法。
【請求項１１】
無線モバイルコンピュータネットワークのＡＴＩＭウィンドウサイズを判定するメディアアクセス層を備え、前記ＡＴＩＭウィンドウサイズが、無線モバイルコンピュータネットワークからの構成データ及びトラフィックデータを使用して計算される、無線モバイルコンピュータネットワーク内のモバイルノード。
【請求項１２】
前記判定されたＡＴＩＭウィンドウサイズに基づいて前記ＡＴＩＭウィンドウサイズを動的に調整する手段をさらに備える、請求項１１に記載のモバイルノード。
【請求項１３】
前記メディアアクセス層が、（ａ）ＡＴＩＭウィンドウ中にＡＴＩＭメッセージの交換に参加するノードの有効個数を判定し、（ｂ）ノードの前記有効個数を使用して、データフレーム送信ウィンドウの長さを計算し、（ｃ）前記計算されたデータフレーム送信ウィンドウを使用して、前記ＡＴＩＭウィンドウの長さを計算する、請求項１１に記載のモバイルノード。
【請求項１４】
ノードの前記有効個数が、ＡＴＩＭメッセージの送信側の個数によって与えられる、請求項１３に記載のモバイルノード。
【請求項１５】
ノードの前記有効個数が、前記ＡＴＩＭメッセージの送信側及び受信側の個数によって与えられる、請求項１３に記載のモバイルノード。
【請求項１６】
所与の時間期間が、前記ＡＴＩＭウィンドウのうちでビーコン送信及び残余データフレーム送信の外の部分である、請求項１３に記載のモバイルノード。
【請求項１７】
ノードの前記有効個数が、所与の時間期間内の正常なＡＴＩＭメッセージ送信の回数から導出される、請求項１３に記載のモバイルノード。
【請求項１８】
正常なＡＴＩＭメッセージ送信の回数が、チャネル衝突頻度及び送信の試みのレートに基づいて推定される、請求項１３に記載のモバイルノード。
【請求項１９】
前記チャネル衝突頻度及び送信の試みの前記レートが、平均コンテンションウィンドウサイズに対する反復手順を使用して導出される、請求項１８に記載のモバイルノード。
【請求項２０】
前記平均コンテンションウィンドウサイズの初期値が、バックオフインターバルの長さである、請求項１９に記載のモバイルノード。
【請求項２１】
各ノードの前記バックオフインターバルが、幾何学的に分布する、請求項２０に記載のモバイル。
【請求項２２】
送信の試みの前記レートが、指数関数的に分布する、請求項１８に記載のモバイルノード。
【請求項２３】
前記無線コンピュータネットワーク内の隣接ノードに関する情報を前記メディアアクセス層に提供するインターネットプロトコル層をさらに備える、請求項１１に記載のモバイルノード。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
[0001]本願は、（１）２００５年１２月９日に出願した米国仮出願第６０／７４９１４１号、名称「Ｍｅｔｈｏｄｓ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｏｐｔｉｍａｌ  ＡＴＭ  Ｓｉｚｅ  Ｓｅｔｕｐ  ｆｏｒ  ８０２．１１  Ｎｅｔｗｏｒｋｓ  ｉｎ  Ａｄ  Ｈｏｃ  Ｍｏｄｅ」、及び（２）２００６年１１月２８日に出願した米国非仮出願第１１／５６４１３８号、名称「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｏｐｔｉｍａｌ  ＡＴＩＭ  Ｓｉｚｅ  Ｓｅｔｕｐ  ｆｏｒ  ８０２．１１  Ｎｅｔｗｏｒｋｓ  ｉｎ  ａｎ  Ａｄ  Ｈｏｃ  Ｍｏｄｅ」に関連し、その優先権を主張するものである。これらの特許出願は、参照によってその全体が本明細書に組み込まれている。米国での指定に関して、本願は、前述の米国特許出願第１１／５６４１３８号の継続出願である。
【発明の分野】
【０００２】
本発明は、無線コンピュータネットワークに関する。具体的に言うと、本発明は、アドホック無線コンピュータネットワークでの動作に関する。
【関連技術の説明】
【０００３】
無線コンピュータネットワークは、モバイルユーザが動きまわる時に、連続的ネットワークアクセスをモバイルユーザに与える。このモビリティを提供するために、モバイルデバイスは、電力について電池に頼る。電池電力は、少ない資源であり、電池寿命改善は、モバイルデバイスの計算能力及び通信機能の改善に対して相対的に遅れをとってきた。したがって、エネルギー効率が、ネットワーク設計における重要なメトリックである。
【０００４】
インフラストラクチャネットワークでのパワーマネジメントと比較して、アドホック無線ネットワーク（例えば、８０２．１１ｂのもとの独立基本サービスセット（ｉｎｄｅｐｅｎｄｅｎｔ  ｂａｓｉｃ  ｓｅｒｖｉｃｅ  ｓｅｔ）すなわち「ＩＢＳＳ」を使用するアドホック無線ネットワーク）のリンク層でのパワーマネジメントは、十分に理解されておらず、効率的ではない。例えば、無線ローカルエリアネットワーク（ＷＬＡＮ）では、アクセスポイント（「ＡＰ」）は、それに関連するすべてのステーション（「ＳＴＡ」）の節電状態の大域的な知識を有する。そのようなネットワークでは、モバイルノードとのすべての通信が、ＡＰを通過し、その結果、ＡＰは、節電（「ＰＳ」）モードのＳＴＡ宛のデータパケットをバッファリングすることができる。事前に指定された時間間隔中に、ＡＰは、これらのＳＴＡにバッファリングされたパケットを取り出すように通知する。しかし、対照的に、アドホック無線ネットワークでは、すべてのノードの節電状態の大域的な知識を有するＡＰに似たＩＢＳＳ内の独立的なものがない。そうではなく、各ＳＴＡが、パケットをローカルに格納し、パケット配送をスケジューリングするためにそのピアと個別に通信する。
【０００５】
ＩＢＳＳの分散された性質に起因して、多数の節電の問題が、８０２．１１下のＩＢＳＳに存在する。
【０００６】
８０２．１１のもとで動作するＷＬＡＮでは、分散協調機能（「ＤＣＦ」）は、衝突回避機能付きキャリアセンス多重アクセス方式（ＣＳＭＡ／ＣＡ）プロトコルを使用して、無線ネットワーク内で動作するステーションがフレームを送信し、受信することを許可される時を、分散された形で判定する。ＣＳＭＡ／ＣＡのもとでは、送信の前に、ＳＴＡは、媒体が「ビジー」（すなわち、別のＳＴＡが送信しつつある）かどうかを判定するために媒体を感知する。媒体がビジーではない場合には、ＳＴＡは、送信することができる。ＣＳＭＡ／ＣＡは、連続するフレームシーケンスの間の、「フレーム間スペース」（ＩＦＳ）と呼ばれる、時間における最小の指定された分離を必要とする。送信器は、送信の前に少なくともＩＦＳの間だけ、媒体がアイドルになるのを待つ。ＩＦＳの値は、送信されるフレームの優先順位に従って変化する。ＩＦＳ値の例は、短フレーム間スペース（ＳＩＦＳ）、ポイントフレーム間スペース（ＰＩＦＳ）、分散フレーム間スペース（ＤＩＦＳ）、及び拡張フレーム間スペース（ＥＩＦＳ）を含む。
【０００７】
ＳＩＦＳは、最短のフレーム間スペースであり、ＳＴＡのグループが、実行されるフレーム交換シーケンスの持続時間だけ媒体をつかんだ時に使用される。ＳＩＦＳは、他のＳＴＡが媒体にアクセスできる前のフレーム交換シーケンスの完了を保証する。というのは、他のＳＴＡが、媒体への送信を試みる前に、ＳＩＦＳより長い時間期間の間、媒体がアイドルになるのを待つことを要求されるからである。例えば、肯定応答（ＡＣＫ）フレームが、ＳＩＦＳを使用する。
【０００８】
ＰＩＦＳは、ポイント協調機能（ＰＣＦ）のもとで動作するＳＴＡによって、コンテンションがない期間の始めに媒体への優先アクセスを得るのに使用される。ＰＩＦＳは、ＳＩＦＳより長いが、ＤＩＦＳより短い。
【０００９】
ＤＩＦＳは、ＤＣＦのもとで動作するステーションによって、データフレーム及び管理フレーム（例えば、プローブ要求及びプローブ応答）を送信するのに使用される。
【００１０】
ＥＩＦＳ  （拡張ＩＦＳ）は、フレーム送信が開始されたが、正しいフレームチェックシーケンス（ＦＣＳ）値を有する完全なメディアアクセス制御（ＭＡＣ）フレームが受信されていないことを物理層（ＰＨＹ）がＭＡＣ層に示す時に示す時に、必ずＤＣＦによって使用される。ＥＩＦＳインターバルは、仮想キャリアセンス機構にかかわりなく、誤ったフレームを検出した後に媒体がアイドルであることをＰＨＹが示した後に始まる。
【００１１】
ＤＣＦのもとで、媒体がビジーであることがわかる場合に、ＳＴＡは、現在の送信が完了した後まで送信を延期する。延期の後に、又は正常な送信の直後にもう一度送信を試みる前に、ステーションは、その間に送信しないランダムな「バックオフ」インターバルを選択する。バックオフインターバルカウンタが、このインターバルを追跡する。
【００１２】
制御パケットのいくつかの例のフォーマットを、図１（「データフレーム」）及び３（「肯定応答（ＡＣＫ）フレーム」）に示す。制御パケットは、図４に包括的に示されたフォーマット（すなわち、「管理フレーム」）を有する。図４に示されているように、このフォーマットは、メディアアクセス制御（ＭＡＣ）ヘッダ、フレーム本体、及びフレームチェックシーケンス（ＦＣＳ）を含む。ＦＣＳは、送信されたフレームの完全性に関する判定を可能にする。８０２．１１  ＷＬＡＮでは、ＳＴＡは、パケットのＭＡＣヘッダ内の宛先アドレス（ＤＡ）フィールドを使用して、そのパケットに関する受信判断を行う。例えば、ＤＡフィールドが、グループアドレス（例えば、ブロードキャストアドレス）を含む場合があり、そのフレームがビーコンフレームではない場合に、基本サービスセット識別子（ＢＳＳＩＤ）が、妥当性検査されなければならない（すなわち、フレームのＢＳＳＩＤフィールドは、受信側のＢＳＳＩＤと同一である）（ＢＳＳＩＤフィールドは、プローブ要求フレームではブロードキャストＢＳＳＩＤとすることができる）。もう１つの例で、ＡＰを含むＳＴＡは、ＤＡフィールドでグループアドレスを指定しないデータフレーム又は管理フレームの受信時に、ＳＩＦＳ延期内でＡＣＫフレームを応答することができる。ＡＣＫフレームは、ＤＡフィールド内でグループアドレスを指定するパケットについては送信されない。
【００１３】
媒体の状態は、物理キャリアセンス機能及び仮想キャリアセンス機能から決定される。物理層は、無線媒体内のエネルギー検出に基づく物理キャリアセンス機構を提供する。ＭＡＣ層は、ネットワーク割り当てベクター（ＮＡＶ）と称する仮想キャリアセンス機構を提供する。ＮＡＶは、実際のデータの交換の前に、フレーム内でアナウンスされる持続時間情報に基づいて、媒体内の将来のトラフィックを予測する。少数の例外を伴って、そのような持続時間情報は、ＭＡＣヘッダ内に見られる。
【００１４】
ＩＥＥＥ  ８０２．１１下の４タイプのフレームが、本発明に関連する。「データフレーム」は、フレーム本体内でより高水準のプロトコルデータを搬送する。図１に、一般的なデータフレームのフィールドを示す。データフレームの特定のタイプに応じて、図１のフィールドの一部が、存在しない場合がある。図２に、データフレーム内のフレーム制御フィールドを示す。図２に示されているように、フィールド制御フィールドは、一緒にフレームタイプを識別する、タイプビット（Ｂ２、Ｂ３）及びサブタイプビット（Ｂ４〜Ｂ７）を含む。１つのデータフレーム内のタイプビット及びサブタイプビットのさまざまな値を、下の表１に示す。
【００１５】
「ＡＣＫ」フレームは、受信されたフレームに応答して、肯定の肯定応答を送信する。図３に、「ＡＣＫ」フレームの諸フィールドを示す。
【００１６】
「トラフィック表示メッセージ（ａｎｎｏｕｎｃｅｍｅｎｔ  ｔｒａｆｆｉｃ  ｉｎｄｉｃａｔｉｏｎ  ｍｅｓｓａｇｅ、ＡＴＩＭ）」フレームは、ＡＴＩＭ期間中に送信される管理フレームである。図４に、管理フレームの諸フィールドを示す。ＩＢＳＳのもとのアドホック無線ネットワークでは、ＡＰでのデータバッファリングサービスは、提供されない。ＩＢＳＳネットワーク内のＳＴＡが、低電力モードの受信器に関するバッファリングされたフレームを有する時に、そのＳＴＡは、バッファリングされたデータの受信側に通知するために、ＡＴＩＭ期間中にＡＴＩＭフレームを送信する。ＡＴＩＭフレームのフレーム本体は、空値（ヌル値）である。
【００１７】
もう１つの管理フレームである「ビーコン」フレームは、ネットワークの存在及び識別情報（アイデンティティ）をアナウンスし、多数のネットワーク保守タスクで重要な役割を果たす。ビーコンフレームは、ネットワークの存在をモバイルＳＴＡにアナウンスし、ネットワークに参加するための適合（マッチ）パラメータをアナウンスするために規則的なインターバルで送信される。ビーコンフレームは、タイムスタンプフィールド、ビーコンインターバルフィールド、機能フィールド、サービスセット識別子（ＳＳＩＤ）フィールド、ＩＢＳＳパラメータセットフィールド、及びトラフィック表示マップ（ＴＩＭ）フィールドを含む。ＩＢＳＳパラメータセットフィールドは、ＩＢＳＳネットワークをサポートするのに必要なパラメータのセットを指定する。図５に、ＩＢＳＳパラメータセットフィールドの諸フィールドを示す。
【表１】
2009518967.tif 000003
【００１８】
インフラストラクチャネットワークでは、ＡＰが、ビーコンフレームを送信する責任を負う。ＡＰのサービスエリアは、そのビーコンフレームの到達範囲によって定義される。ＢＳＳのタイミングは、ビーコンフレームで指定されるビーコンインターバルによって決定される。ビーコンフレームの連続する送信の間の時間間隔を、ターゲットビーコン遷移時間（「ｔａｒｇｅｔ  ｂｅａｃｏｎ  ｔｒａｎｓｉｔｉｏｎ  ｔｉｍｅ」）すなわちＴＢＴＴと呼ぶ。
【００１９】
ＩＢＳＳネットワークでは、ビーコンフレームが、分散された形で生成される。ビーコンインターバルは、ビーコンフレームとプローブ応答フレームとの両方に含まれる。ＳＴＡは、各ＳＴＡがアドホックネットワークに参加する時にビーコンインターバルを採用する。ＩＢＳＳネットワークでは、すべてのメンバが、ビーコン生成に参加する。各ＳＴＡは、ビーコンインターバルタイミング用のタイミング同期機能（ＴＳＦ）タイマを維持する。ＩＢＳＳネットワークは、アクセスポイントを有しないので、あるＳＴＡが、低電力モードである受信側のフレームをバッファリングした時に、そのＳＴＡは、それが受信側のためにデータをバッファリングしたことを受信側に通知するために、ＡＴＩＭウィンドウ中にトラフィック表示メッセージ（ＡＴＩＭ）フレームを送信する。ＡＴＩＭフレームは、空値のフレーム本体を有する。
【００２０】
図６に、ＩＢＳＳでのビーコンフレーム生成の処理を示す。各ＴＢＴＴに、各ステーションは、（ａ）チャネル内で現在送信されつつあるパケットが完了するのを待ち、（ｂ）すべての保留中の非ビーコン又は非ＡＴＩＭ送信のためにバックオフタイマを一時停止し、（ｃ）０と２＊ＣＷｍｉｎ＊ＴＵとの間の範囲内で均一に分布するランダム遅延を計算し、ここで、ＣＷｍｉｎは、最小コンテンションウィンドウのサイズであり、ＴＵは、タイミング単位である。次に、ＳＴＡは、このランダム遅延を使用してタイマをセットし、このタイマが満了するのを待つ。ビーコンフレームが、ランダム遅延タイマが満了する前に到着する場合には、待機がキャンセルされ、バックオフタイマが再開される。しかし、ＳＴＡがビーコンフレームを受信することなく、ランダム遅延タイマが満了する場合には、ＳＴＡは、ビーコンフレームを送信する。ＡＴＩＭメッセージが、ビーコンフレームに続いて、ソースステーションから宛先ステーションへ、通常のデータパケットと同一の分散協調機能（ＤＣＦ）アルゴリズムを使用して送信される。ＡＴＩＭウィンドウの長さは、パケット送信がビーコンインターバル中にあるか否かにかかわりなく、固定されており、必ず理論的ＴＢＴＴ時刻から開始される。
【００２１】
ビーコンフレームのタイムスタンプフィールドは、フレームのソースでのＴＳＦタイマの値を表す。ＩＢＳＳネットワークに参加するステーションは、そのＴＳＦタイマを０に初期化し、ＩＢＳＳネットワーク内の正しい同期化を保証するために、そのＩＢＳＳの別のメンバから一致するＳＳＩＤを有するビーコンフレーム又はプローブ応答フレームを受信する後まで、ビーコンフレーム又はプローブ応答フレームの送信を控える。
【００２２】
ＩＢＳＳネットワーク内では、ＳＴＡは、ＳＴＡが完全に電力を供給される「アウェイク」状態、又はＳＴＡが電力をほとんど消費せず、送信又は受信を行うことができない「ドーズ」状態であることができる。ＳＴＡに関する用語「パワーマネジメント」は、ＳＴＡがアウェイク状態とドーズ状態との間で遷移する形を指す。
【００２３】
インフラストラクチャネットワークでは、そのパワーマネジメントモードをドーズ又はＰＳ状態に変更するＳＴＡは、送信されるフレームのフレーム制御フィールド内のパワーマネジメントビットを使用してＡＰに知らせる。その後、ＡＰは、そのＳＴＡにＭＡＣサービスデータユニット（ＭＳＤＵ）を任意に送信はしない。ＭＳＤＵは、バッファリングされ、指定された時刻に送信される。ＳＴＡのためにＭＳＤＵをバッファリングしたＡＰに関連するＳＴＡは、そのＡＰによって生成されるすべてのビーコンフレームに含まれるＴＩＭで識別される。ＴＩＭを解釈することによって、ＳＴＡは、ＭＳＤＵがそのＳＴＡのためにバッファリングされていることを知らされる。ＰＳモードで動作するＳＴＡは、そのリスンインターバルに従ってビーコンフレームを周期的にリスンし（ビーコンフレームの入力を周期的に待機し）、配信トラフィック表示メッセージ（ＤＴＩＭ）パラメータを受信する。ＭＳＤＵが現在ＡＰ内でバッファリングされていることを知った時に、ＳＴＡは、短ＰＳポールフレームをＡＰに送信し、このＡＰは、対応するバッファリングされたＭＳＤＵを即座に応答し、或いは、ＰＳポールを肯定応答し、対応するＭＳＤＵを後に応答する。そのＢＳＳ内のＳＴＡがＰＳモードである場合に、ＡＰは、すべてのブロードキャストＭＳＤＵ及びマルチキャストＭＳＤＵをバッファリングし、ＤＴＩＭ送信を含む次のビーコンフレームの直後にこれらをＳＴＡに配信する。
【００２４】
図７に、ＩＢＳＳでのパワーマネジメントの基本動作を示す。図７に示されているように、各ＴＢＴＴの後に、ＡＴＩＭウィンドウが定義される。ＡＴＩＭウィンドウ中に、ＰＳモードで動作するＳＴＡは、ビーコンフレーム又はＡＴＩＭフレームの受信を待機するためにアウェイクされる（ＰＳモードを解除する）。ＰＳモードの受信側ＳＴＡにＭＳＤＵを送信するために、送信するＳＴＡは、まず、ＡＴＩＭウィンドウ中にＡＴＩＭフレームを送信する。異なるＳＴＡからのＡＴＩＭ送信は、共通のＤＣＦバックオフ手順を使用してランダム化される。向けられたＡＴＩＭは、肯定応答される。ＡＣＫフレームが、向けられたＡＴＩＭに応答して受信されない場合に、送信するＳＴＡは、バックオフ手順を実行して、再送信を試みる。マルチキャストＡＴＩＭは、肯定応答されない。ＡＴＩＭインターバルの後に、肯定応答されたＭＳＤＵ及びアナウンスされたブロードキャスト／マルチキャストＭＳＤＵが、通常のＤＣＦアクセス手順を使用して、ＰＳモードのＳＴＡに送信される。ＳＴＡが、ＭＳＤＵがアナウンスされるビーコンインターバル中に、バッファリングされたＭＳＤＵを送信できない場合には、そのＳＴＡは、バッファリングされたＭＳＤＵを保持し、次のＡＴＩＭウィンドウ中のＡＴＩＭでそのＭＳＤＵをもう一度アナウンスする。すべてのバッファリングされたＭＳＤＵが送信された後に、ＭＳＤＵが、アウェイク状態のＳＴＡにアナウンスされずに送信される。
【００２５】
ＰＳモードで動作するＳＴＡは、各ＴＢＴＴの前にアウェイク状態に入る。そのＳＴＡが、ＡＴＩＭウィンドウ中に、それに向けられたＡＴＩＭ管理フレーム又はマルチキャストＡＴＩＭ管理フレームを受信する場合に、そのＳＴＡは、次のＡＴＩＭウィンドウの終りまでアウェイク状態のままになる。ビーコンフレーム又はＡＴＩＭ管理フレームを送信したＳＴＡは、肯定応答がそのＡＴＩＭについて受信されるか否かにかかわりなく、次のＡＴＩＭウィンドウの終りまでアウェイク状態のままになる。ＳＴＡが、ＡＴＩＭを送信せず、ＡＴＩＭウィンドウ中にそれに向けられたＡＴＩＭ管理フレーム又はマルチキャストＡＴＩＭ管理フレームのいずれをも受信しない場合に、そのＳＴＡは、現在のＡＴＩＭウィンドウの終りの後にドーズ状態に戻ることができる。
【００２６】
ＡＴＩＭウィンドウサイズは、パワーマネジメント及び性能に対する密接な関係を有する。大きいＡＴＩＭウィンドウは、望ましくない。というのは、すべてのＳＴＡが、ＡＴＩＭウィンドウの持続時間の間にアウェイクしている必要があり、その結果、大きいＡＴＩＭウィンドウが、着信トラフィック及び発信トラフィックを有しないＳＴＡの不必要な電力消費をもたらすからである。同一のビーコンインターバル内のＡＴＩＭ期間の後のデータ送信期間も、小さくなり過ぎる可能性があり、ＡＴＩＭウィンドウ内で正常なＡＴＩＭ／ＡＣＫメッセージ交換を有するすべてのＳＴＡが、データ送信期間にデータを送信できるとは限らなくなる可能性がある。したがって、短いデータフレーム送信は、送信遅延を増やすだけではなく、未完了のデータ送信を有する、ビーコン期間全体の持続時間にわたってアウェイクしていなければならないＳＴＡのエネルギーをも浪費する。
【００２７】
逆に、短過ぎるＡＴＩＭウィンドウも望ましくない。ＡＴＩＭウィンドウサイズが小さ過ぎる場合には、ＳＴＡが、そのＡＴＩＭメッセージのすべてをそのピア（相手側）にＡＴＩウィンドウ内に送出することができない可能性がある。そのようなＳＴＡは、次のビーコンインターバルを待たなければならず、送信の遅延がもたらされる。データ送信期間は、ＡＴＩＭウィンドウ中に決定される、送信されるべきパケットの数に対して長くなり過ぎる。したがって、一部の帯域幅が浪費される。
【００２８】
２００４年９月に出願されたＺ．ＺｈｏｎｇのＰＣＴ特許出願公告ＷＯ２００４／０７７７６２Ａ１、名称「Ｐｏｗｅｒ  ｍａｎａｇｅｍｅｎｔ  ｉｎ  ａｎ  ＩＥＥＥ  ８０２．１１  ＩＢＳＳ  ＷＬＡＮ  ｕｓｉｎｇ  ａｎ  ａｄａｐｔｉｖｅ  ＡＴＩＭ  ｗｉｎｄｏｗ」は、ＡＴＩＭウィンドウのサイズを動的に調整する方式を提案する。この方式のもとでは、各ＳＴＡは、最後のオーバーヘッドＡＴＩＭフレーム送信とＡＴＩＭウィンドウの終りとの間のギャップを使用して、そのＡＴＩＭウィンドウのサイズを増減するか否かを決定する。各ＳＴＡは、その提案されるＡＴＩＭウィンドウサイズを含むビーコンを送信するために競争（参加）する。その後、勝者の提案されたウィンドウサイズが、ＩＢＳＳのすべてのＳＴＡによって採用される。より具体的には、各ステーションは、事前に決定された値ＭＡＸ＿ＧＡＰ、ＤＡ＿ＭＩＮ、及びＤＡ＿ＤＥＣＲを保ち、ここで、ＭＡＸ＿ＧＡＰは、最大限の未使用ＡＴＩＭウィンドウサイズであり、ＤＡ＿ＭＩＮは、割り振られる最小ＡＴＩＭウィンドウサイズであり、ＤＡ＿ＤＥＣＲは、ＡＴＩＭウィンドウのサイズを減分する事前にセットされる量である。ＡＴＩＭウィンドウを減らすアルゴリズムは、次の通りである。
Ｉｆ  ＧＡＰ≧ＭＡＸ＿ＧＡＰ  ｔｈｅｎ  ＡＴＩＭ＿Ｓｉｚｅ＝ｍａｘ［ＤＡ＿ＭＩＮ，ＡＴＩＭ＿Ｓｉｚｅ−ＤＡ＿ＤＥＣＲ］
【００２９】
同様に、各ステーションは、事前に決定されたＭＡＸ＿ＮＯ＿ＤＡ、ＤＡ＿ＭＡＸ、及びＤＡ＿ＩＮＣＲを保ち、ここで、ＭＡＸ＿ＮＯ＿ＤＡは、最長の未送信のＡＴＩＭメッセージであり、ＤＡ＿ＭＡＸは、最大のＡＴＩＭウィンドウサイズであり、ＤＡ＿ＩＮＣＲは、ＡＴＩＭウィンドウのサイズを増やす事前にセットされる量である。ＡＴＩＭウィンドウを増やすアルゴリズムは、次の通りである。
Ｉｆ  Ｕｎｔｒａｎｓｍｉｔｔｅｄ＿ｄａｔａ≧ＭＡＸ＿ＮＯ＿ＤＡ  ｔｈｅｎ  ＡＴＩＭ＿Ｓｉｚｅ＝ｍｉｎ［ＤＡ＿ＭＡＸ，ＡＴＩＭ＿Ｓｉｚｅ＋ＤＡ＿ＩＮＣＲ］
【００３０】
上で述べたように、既存の努力は、初期ＡＴＩＭウィンドウサイズをセットアップするメカニズムを提供するのではなく、完全に動的適応方式に頼ってＡＴＩＭウィンドウサイズを調整する。動的適応方式は、時間がかかるだけではなく、トラフィック変動が劇的に変化する、いくつかの場合に、不安定でもある。
【００３１】
したがって、ＩＢＳＳ内のノードの個数だけに基づいて最適ＡＴＩＭウィンドウサイズを計算することが望ましい。そのような方式は、ノードがシステムに参加するか離脱する時に、最適初期ＡＴＩＭウィンドウを判定する。そのような方式を、他の動的適応方式と組み合わせて、よりよい性能を達成することができる。
【発明の概要】
【００３２】
本発明の一実施形態によれば、ある方法が、ＩＢＳＳ  ＷＬＡＮ内の最適ＡＴＩＭウィンドウサイズを、そのネットワーク内の移動ステーションの個数に基づいて計算する。この方法は、現在の８０２．１１標準規格で使用される節電技法と互換であり、ビーコン送信、ＡＴＩＭ送信、及びデータ送信を含む異なる時間期間の長さを提供する。他の動的適応方式と一緒に働くことによって、本発明の方式は、よい性能及び減らされた電力消費を達成することができる。
【００３３】
一実施形態によれば、アドホック無線コンピュータネットワーク内での節電の方法は、最適ＡＴＩＭメッセージ交換ウィンドウを判定する。この方法は、（ａ）ＡＴＩＭウィンドウ中にＡＴＩＭメッセージの交換に参加するノードの有効個数を判定し、（ｂ）ノードの有効個数を使用して、データフレーム送信ウィンドウの長さを計算し、（ｃ）計算されたデータフレーム送信ウィンドウを使用してＡＴＩＭウィンドウの長さを計算する。１つの例で、この方法は、ＡＴＩＭメッセージの送信側の個数に基づいてノードの有効個数を判定する。もう１つの例で、ノードの有効個数は、ＡＴＩＭメッセージの送信側と受信側との両方に基づいて判定される。この方法は、所与の時間期間内の正常なＡＴＩＭメッセージ送信の回数からノードの有効個数を判定することができる。計算されたＡＴＩＭウィンドウサイズを、ＡＴＩＭウィンドウサイズを動的に調整する他の方法に初期値として提供することができる。
【００３４】
本発明は、詳細な説明及び添付図面を検討する時によりよく理解される。
【好ましい実施形態の詳細な説明】
【００３５】
本発明の一実施形態によれば、あるアルゴリズムが、所与のＩＢＳＳネットワークのＡＴＩＭウィンドウサイズを、そのネットワーク内のＳＴＡの個数に基づいて最適化する。この実施形態では、（ａ）ＡＴＩＭウィンドウ内でＡＴＩＭメッセージを送出するか受信するＳＴＡは、８０２．１１標準規格によって要求される通り、次のＡＴＩＭウィンドウの終りまで「アウェイク」状態のままになり、（ｂ）すべてのＳＴＡが、節電モードで動作し（すなわち、常時オンの局はない）、（ｃ）ＩＢＳＳネットワーク内のすべてのノードが、お互いを聞き、その結果、クリーク（ｃｌｉｑｕｅ）を形成し、（ｄ）すべてのＳＴＡが、等しい優先順位を有し、（ｅ）ＡＴＩＭウィンドウ中に正常なＡＴＩＭ／ＡＣＫメッセージ交換を有するＳＴＡだけが、データ送信ウィンドウ中に送信することができる。図８に、ＡＴＩＭ／ＡＣＫウィンドウ（ＴＡＴＩＭ）及びデータ送信ウィンドウ（ＴＤ）からなるビーコンインターバルを示す。しかし、ＳＴＡ内で、直接のＡＴＩＭ／ＡＣＫ交換を有しないノードは、互いの節電状態を推論することができる。
【００３６】
一実施形態で、２つの隣接する送信の試みの間の時間間隔は、指数関数的に分布すると仮定される。そのようなモデルでは、チャネル試行レート（ｃｈａｎｎｅｌ  ａｔｔｅｍｐｔ  ｒａｔｅ）λは、ポアソン分布によって与えられ、チャネル衝突頻度ｐは、定数であり、現在の競合するトラフィック負荷だけに関係する。お互いの送信範囲内にＮ個のノードを有するネットワークについて、現在の平均チャネル試行レートλは、
【数１】
2009518967.tif 000004
によって与えられ、ここで、Ｌｉは、ノードｉのコンテンションウィンドウであり、Ｌは、平均コンテンションウィンドウサイズである。試行される送信の平均到着時間は、１／λである。
【００３７】
ｋ回の送信のタイムスロット内の確率質量関数は、
【数２】
2009518967.tif 000005
によって与えられる。したがって、チャネル衝突頻度ｐは、
ｐ＝Ｐｒ［ｋ≧２］＝１−Ｐｒ［０］−Ｐｒ［１］＝１−ｅ−λ−λｅ−λ
によって与えられる。
【００３８】
ｍが、最大バックオフウィンドウサイズに達する再送信の回数であるものとする（例えば、指数関数的バックオフ方式について、ｍは、２ｍ＊ＣＷｍｉｎ≧ＣＷｍａｘを満足する値である）。指数関数的バックオフ方式について、ｊ番目の衝突ウィンドウサイズが発生する確率は、
【数３】
2009518967.tif 000006
によって与えられる。
【００３９】
なので、
【数４】
2009518967.tif 000007
である。ｂｊが、ｊ番目のコンテンションウィンドウサイズである場合に、平均コンテンションウィンドウサイズＬは、
【数５】
2009518967.tif 000008
によって与えられる。
【００４０】
したがって、平均コンテンションウィンドウサイズＬは、ＣＷｊ＝２ｊ・ＣＷｍｉｎ及びＣＷｍａｘ＝２ｍ・ＣＷｍｉｎならば、平均衝突比ｐ及び平均チャネル試行レートλに依存する。
【００４１】
したがって、最大バックオフウィンドウサイズを表すＬ（０）を使用すると、λ（０）及びｐ（０）の値の最初の推定を、上のλ及びｐの式を使用して行うことができる。次に、上のＬを計算する式を適用することによって、平均コンテンションウィンドウサイズの洗練された推定値Ｌ（１）を計算することができ、この値から、λ（１）及びｐ（１）の第２の推定を行うことができる。この反復は、平均コンテンションサイズの２つの連続する推定値の間の差が、所定の値未満になるまで、すなわち、｜Ｌ（ｊ＋１）−Ｌ（ｊ）｜＜εになるまで繰り返され、ここで、εは、事前定義の小さい値を表す。その時の平均チャネル試行レートλ及びチャネル衝突頻度ｐの推定値が、採用される。
【００４２】
次の議論では、ＡＴＩＭメッセージ送信に使用される平均時間をＴＡと表し、ＴＡ以内に達成される正常な送信の回数をＮｆ−ｓｕｃと表し、ＴＡ以内の正常なＡＴＩＭ／ＡＣＫ交換の当事者であるＳＴＡの平均個数をＮｎ−ｓｕｃと表す。これらのＳＴＡは、ビーコンインターバルのデータ送信期間中にアウェイク状態のままになる。各ＳＴＡが複数のＡＴＩＭ／ＡＣＫメッセージを送信できるので、Ｎｆ−ｓｕｃが、Ｎｎ−ｓｕｃ未満ではないことに留意されたい。
【００４３】
少なくとも１つのＡＴＩＭ送信があるものとして、衝突の確率ｐｆは、
【数６】
2009518967.tif 000009
である。
【００４４】
したがって、正常なＡＴＩＭ送信の確率ｐｓは、
【数７】
2009518967.tif 000010
であり、ｋ番目の試みでの正常な送信の確率は、ｐｋ＝ｐｓ（１−ｐｓ）ｋ−１である。したがって、正常なＡＴＩＭ送信が達成されるの前の期待される試みの回数は、
【数８】
2009518967.tif 000011
である。図９に、ＡＴＩＭフレームの送信に関して、それぞれ、衝突が発生する時及びＡＴＩＭ／ＡＣＫメッセージの正常な交換が達成される時に発生するイベントのシーケンスを示す。図９に示されているように、コンテンションウィンドウの後に、衝突が発生する場合に、ＥＩＦＳインターバルが、衝突の検出に続く。逆に、ＡＴＩＭメッセージが正常に送信される場合には、ＡＣＫメッセージが、ＳＩＦＳインターバルの後にＡＴＩＭメッセージの受信側から返される。このＡＣＫメッセージに、もう１つのＳＩＦＳインターバルが続き、これにＤＩＦＳインターバルが続く。したがって、正常な送信を完了するための期待される時間ｔｔｏｔａｌ−ｏｎｅは、
【数９】
2009518967.tif 000012
によって与えられ、ここで、ＥＩＦＳ、ＳＩＦＳ、及びＤＩＦＳは、事前定義のシステムパラメータであり、ｔｆａｉｌ−ｏｎｅ及びｔｓｕｃ−ｏｎｅは、それぞれ衝突及び正常な送信の時間であり、ｔｗａｉｔは、コンテンションウィンドウであり、ｔＡＴＩＭ及びｔＡＣＫは、それぞれＡＴＩＭフレーム及びＡＣＫフレームを送信するのに必要な時間である。ＦＡＴＩＭが、データフレームの全長であり、ＦＡＣＫが、ＡＣＫフレームの全長であり、Ｒｔｒａｎｓが、チャネル伝送速度であるものとする。
【数１０】
2009518967.tif 000013
【００４５】
したがって、ＴＡ内では、正常な送信の平均回数Ｎｆ−ｓｕｃは、Ｎｆ−ｓｕｃ＝ＴＡ／ｔｔｏｔａｌ−ｏｎｅによって与えられる。一部のノードが、複数のＡＴＩＭメッセージを送信する場合がある。ＡＴＩＭ／ＡＣＫメッセージを正常に送出する個々のノードの個数Ｎｎ−ｓｕｃが、次に導出される。
【００４６】
ＡＴＩＭメッセージは、送信側が、ビーコンインターバルのデータ送信期間中にデータフレームを送信するつもりであることを示す。ＡＴＩＭメッセージの受信側は、ＡＴＩＭウィンドウ内にそのＡＴＩＭメッセージに対する肯定応答を返す。ＡＴＩＭメッセージの受信側は、同一のデータ送信期間中にＡＴＩＭメッセージの送信側に送信すべきデータフレームを有しても有しなくてもよい（すなわち、ＡＴＩＭメッセージの受信側は、それ自体が別々に正常に送信側にＡＴＩＭメッセージを送信せずに、ＡＴＩＭメッセージの送信側にデータフレームを送信することができる）。したがって、２つの可能性があり、第１の可能性では、正常なＡＴＩＭ交換の送信側だけが、データ送信期間中にデータフレームを送信し、第２の可能性では、正常なＡＴＩＭメッセージの送信側と受信側との両方が、データ送信期間中にデータフレームを送信する。Ｎｆ＿ｓｕｃ個のフレームのすべてが、同等に、任意の２つのノードの間にある可能性が高い。
【００４７】
したがって、ノードｉごとに、一様に分布するランダム変数Ｘｉは、次の値をとる。
【数１１】
2009518967.tif 000014
次に、Ｅ［Ｘｉ］は、ノードｉがＮｆ−ｓｕｃ個のフローのうちの１つ又は複数によって含まれる確率である。Ｎは、システム内のノードの総数である。すると、Ｎｆ−ｓｕｃ個のフローに含まれる個々のノードの期待される個数は、Ｎｎ−ｓｕｃ＝Ｅ［Ｘ１＋Ｘ２＋．．．＋ＸＮ］＝Ｎ・Ｅ［Ｘ］によって与えられる。ＡＴＩＭメッセージの送信側だけがデータフレームを送信する場合には、
【数１２】
2009518967.tif 000015
且つ
【数１３】
2009518967.tif 000016
である。しかし、ＡＴＩＭメッセージの送信側とそのＡＴＩＭメッセージの受信側との両方がデータフレームを送信する場合には、ノードｉは、フローの送信側でも受信側でもないならばそのフローに含まれない。したがって、
【数１４】
2009518967.tif 000017
且つ
【数１５】
2009518967.tif 000018
である。
【００４８】
ＡＴＩＭウィンドウに続いて、Ｎｎ−ｓｕｃ個のノードは、データ送信期間中にアウェイク状態のままになり、データフレームを送出するために参加する。すべてのノードが、必ず送信すべきパケットを有すると仮定すると、データ送信期間の最適長さは、すべてのノードが少なくとも１つのパケットを正常に送信するのに必要な時間になる。Ｙｉが、ｉ番目のノードがその最初のパケットを正常に送信するのに必要な時間であるならば、Ｎｎ−ｓｕｃ個のノードのすべてが送信を終了するのに必要な総時間は、ＴＤ＝Ｅ［Ｙ１＋Ｙ２＋．．．Ｙｎ−ｓｕｃ］＝Ｅ［Ｙ１］＋Ｅ［Ｙ２］＋．．．Ｅ［Ｙｎ−ｓｕｃ］である。ｉ番目のノードがあるスロット内にデータフレームを送出できる確率は、（ｉ−１）番目のノードが既にデータフレームを送信しているならば、
【数１６】
2009518967.tif 000019
によって与えられる。
【００４９】
必要な時間は、幾何学的に分布するので、
【数１７】
2009518967.tif 000020
である。したがって、Ｎｎ−ｓｕｃ個のフレームを送信するための総時間は、
【数１８】
2009518967.tif 000021
によって与えられる。
【００５０】
すべてのＴＢＴＴに、前のビーコンインターバルからの最後のデータフレームがその送信を完了した後に、クリーク（小集団）内のすべてのＳＴＡが、ビーコンフレームの送出を完了する。ビーコンメッセージを正常に送出する最初のＳＴＡが、現在のビーコンインターバルのビーコンステーションになる。あるＳＴＡが、ビーコンメッセージを受信する時に、そのＳＴＡは、それ自体のビーコン送信を終了し、そのＡＴＩＭメッセージの送信を準備する。衝突及び最後の正常な送信を含む平均総ビーコン送信時間は、次のように計算される。ビーコンメッセージを送信する前に、各ＳＴＡは、バックオフウィンドウサイズをセットし、このサイズは、［０，２・ＣＷｍｉｎ］の間で均一に分布する。バックオフタイマは、各アイドルスロットに１つだけ減分される。あるＳＴＡのタイマが満了したならば、そのＳＴＡは、そのビーコンメッセージを送出する。ビーコンメッセージは肯定応答されないので、ＳＴＡは、そのビーコンメッセージが受信されるか否かにかかわりなく、ＡＴＩＭメッセージの送信を準備する。衝突又は干渉のゆえに正常に送信されないビーコンメッセージは、別のＳＴＡが、そのビーコンメッセージを送信する時にビーコン局になることを可能にする。
【００５１】
各ＳＴＡの初期コンテンションウィンドウサイズは、２・ＣＷｍｉｎなので、ビーコン送信の平均チャネル試行レートλＢは、ポアソン分布を仮定すると、
【数１９】
2009518967.tif 000022
によって与えられる。上のＡＴＩＭウィンドウに関する類似する議論から、インターバル到着時間は、１／λＢの平均値を伴って指数関数的に分布する。衝突の確率ｐｆ−Ｂは、少なくとも１つのビーコンフレーム送信があるならば、
【数２０】
2009518967.tif 000023
である。したがって、ビーコンフレームの正常な送信の確率ｐｓ−Ｂは、
【数２１】
2009518967.tif 000024
である。ｋ番目の試みでの正常な送信の確率は、ｐｋ−Ｂ＝ｐｓ−Ｂ（１−ｐｓ−Ｂ）ｋ−１であり、正常なビーコン送信に関する試みの期待される回数は、
【数２２】
2009518967.tif 000025
である。コンテンションウィンドウの後に、ビーコンフレームが送信される。ビーコンフレーム送信が不成功である場合には、その送信に、ＥＩＦＳインターバルが続く。そうではない場合には、ビーコンフレームの正常な送信の後に、ＤＩＦＳインターバルが発生する。したがって、ビーコンの正常な送信の期待される総時間ＴＢは、
【数２３】
2009518967.tif 000026
であり、ここで、ＥＩＦＳ、ＳＩＦＳ、及びＤＩＦＳは、事前定義のシステムパラメータであり、ｔｆａｉｌ−Ｂ及びｔｓｕｃ−Ｂは、それぞれ、ビーコンフレームの衝突及び正常な送信の時間であり、ｔｗａｉｔは、コンテンションウィンドウであり、ｔｂｅａｃｏｎは、ビーコンを送信するのに必要な時間である。Ｆｂｅａｃｏｎが、ビーコンフレームの全長であり、Ｒｔｒａｎｓが、チャネル伝送速度であるものとすると、
ｔｂｅａｃｏｎ＝Ｆｂｅａｃｏｎ／Ｒｔｒａｎｓ
である。
【００５２】
要約すると、上では、説明は、ビーコンを送信する平均時間ＴＢ、長さＴＡのＡＴＩＭ交換期間内にＡＴＩＭ／ＡＣＫメッセージを送信するノードの平均個数Ｎｎ−ｓｕｃ、及びＮｎ−ｓｕｃ個のノードのすべてが少なくとも１つのフレームをそれぞれ送信するデータ送信期間の平均時間ＴＤの導出を示す。あるノードがＴＢＴＴ時間境界にまたがってパケット送信を完了する平均時間ＴＲは、ｔｄａｔａ／２と仮定され、ここで、ｔｄａｔａは、１つのデータフレームを送信するのに必要な時間である。時間ｔｄａｔａは、ｔｄａｔａ＝Ｆｄａｔａ／Ｒｔｒａｎｓによって与えられ、ここで、Ｆｄａｔａは、データフレームの平均長であり、したがって、平均時間ＴＲは、
【数２４】
2009518967.tif 000027
によって与えられる。
【００５３】
戻って図８を参照すると、総ビーコンインターバルＴＴｏｔａｌは、
ＴＴｏｔａｌ＝ＴＲ＋ＴＢ＋ＴＡ＋ＴＤによって与えられ、最適ＡＴＩＭウィンドウサイズＡＡＴＩＭは、ＴＡＴＩＭ＝ＴＲ＋ＴＢ＋ＴＡである。
【００５４】
図１０は、本発明のノードがＡＴＩＭウィンドウサイズを改善できる全体的なシステムアーキテクチャのブロック図である。図１０に示されているように、ブロック１００１は、広域ネットワーク（ＷＬＡＮ）構成パラメータ及びトラフィック情報から受け取られた入力に基づいて最適ＡＴＩＭサイズ計算を実行する。１つの入力パラメータは、近傍のノードの個数である。近傍のノードの個数は、ＷＬＡＮネットワークが特定の組織によって運営され若しくは管理される場合に、ネットワーク管理者によって事前に構成されるか推定されるものとすることができる（例えば、ブロック１００２及び１００５）。代替案では、近傍のノードの個数は、ルーティング交換又は動的なノード参加／離脱処理を介して収集され（例えば、ブロック１００３、１００７、１００５）、その場合に、ノードの平均個数を計算に使用することができる。さらに、ＳＩＦＳ時間、ＤＩＳＦ時間、ＥＩＦＳ時間、コンテンションウィンドウサイズ、データフレームサイズ、及びビーコンインターバルなどのシステム固有パラメータ値が、システム管理者又はノード自体によって指定される。トラフィック変動は、上の現在の分析が飽和した事例に基づくので、チャネルについて競争するノードの有効個数を変更する。これらのパラメータ値を使用して、「最適ＡＴＩＭサイズ」を、上でＴＡＴＩＭについて提供した議論に従って計算することができる。そのような計算された値を直接に使用して、システムのＡＴＩＭウィンドウサイズをセットすることができる。適応ＡＴＩＭサイズ方式も、リアルタイムでＡＴＩＭサイズを変更するのに使用される（ブロック１００６）場合には、ブロック１００１からの出力ＴＡＴＩＭ値を、任意の適応方式の出発点として使用することができる。
【００５５】
図１１に、最適ＡＴＩＭウィンドウサイズＡＡＴＩＭを計算する全般的な手順を示す。ステップ１１０１で、ＳＩＦＳ、ＤＩＦＳ、ＥＩＦＳ、チャネル伝送速度Ｒｔｒａｎｓ、最小コンテンションウィンドウサイズＣＷｍｉｎ、及び最大コンテンションウィンドウサイズＣＷｍａｘなどのシステム依存パラメータを収集する。ステップ１１０２で、ＡＴＩＭフレームサイズＦＡＴＩＭ、ＡＣＫフレームサイズＦＡＣＫ、ビーコンフレームサイズＦｂｅａｃｏｎ、平均データフレームサイズＦｄａｔａ、及びビーコンインターバルＴＴｏｔａｌなど、選択されたパラメータを、多数のシステムによって採用される値を使用して計算する。
【００５６】
ステップ１１０３及び１１０４で、残余データ送信時間ＴＲ及びビーコン送信時間ＴＢを計算する。ＡＴＩＭ送信時間ＴＡ及びデータ送信時間ＴＤが、ＡＴＩＭ／ＡＣＫメッセージを正常に送信するノードの個数Ｎｎ−ｓｕｃを介して相関される。ステップ１１０５及び１１０６は、それぞれ、ＡＴＩＭメッセージの送信側だけがデータフレームを送信する場合及びＡＴＩＭメッセージの送信側とＡＴＩＭメッセージの受信側との両方がデータフレームを送信する場合について、ＡＴＩＭメッセージを送信する総時間ｔｔｏｔａｌ−ｏｎｅ、ＴＡ内の総フレーム送信の平均回数Ｎｆ−ｓｕｃ、ノードの平均個数Ｎｎ−ｓｕｃをＮｆ−ｓｕｃから計算する。データ送信期間ＴＤは、Ｎｎ−ｓｕｃから計算される。ＴＢＴＴ（Ｔｔｏｔａｌ）すなわちＴＲ、ＴＢ、及びＴＤから導出される値を与えられて、最適ＡＴＩＭウィンドウＴＡが計算される。ＴＲ、ＴＢ、及びＴＡの値から、最適ＡＴＩＭサイズＴＡＴＩＭが計算される。
【００５７】
上の詳細な説明は、特定の実施形態を示すために提供され、限定的であることは意図されていない。本発明の範囲内の多数の変形形態及び修正形態が可能である。本発明は、添付の特許請求の範囲で示される。
【図面の簡単な説明】
【００５８】
【図１】包括的なデータフレームの諸フィールドを示す図である。
【図２】データフレームのフレーム制御フィールド内の諸フィールドを示す図である。
【図３】ＡＣＫフレームの諸フィールドを示す図である。
【図４】ＡＴＩＭフレームなどの管理フレームの諸フィールドを示す図である。
【図６】ＩＢＳＳでのビーコンフレーム生成の処理を示す図である。
【図７】ＩＢＳＳでのパワーマネジメントの基本動作を示す図である。
【図８】ＡＴＩＭ／ＡＣＫ交換インターバル及びデータ送信インターバルによって構成されるビーコンインターバルを示す図である。
【図９】ＡＴＩＭフレームの送信が試みられる時に衝突が発生する時とＡＴＩＭ／ＡＣＫメッセージの正常な交換の時とに発生するイベントのシーケンスを示す図である。
【図１０】本発明のノードがＡＴＩＭウィンドウサイズを改善できる全体的なシステムアーキテクチャを示すブロック図である。
【図１１】本発明の一実施形態による、最適ＡＴＩＭウィンドウサイズＡＡＴＩＭを計算する全般的な手順を示す図である。
【図１】
2009518967.tif 000028
【図２】
2009518967.tif 000029
【図３】
2009518967.tif 000030
【図４】
2009518967.tif 000031
【図５】
2009518967.tif 000032
【図６】
2009518967.tif 000033
【図７】
2009518967.tif 000034
【図８】
2009518967.tif 000035
【図９】
2009518967.tif 000036
【図１０】
2009518967.tif 000037
【図１１】
2009518967.tif 000038
【国際調査報告】
2009518967.tif 000039