JP5963689B2 - 無線ネットワークにおいてネットワークリソースを管理する方法およびクライアント - Google Patents

Description

この発明は、包括的には、無線通信に関し、より詳細には、アドホック無線ネットワークにおけるチャネルアクセスおよび送信スケジューリングに関する。

衝突検出付きキャリア検知多元接続（ＣＳＭＡ／ＣＤ：Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ）および時分割多元接続（ＴＤＭＡ：Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）の双方を可能にする無線ネットワークにおけるチャネルアクセスおよびネットワークリソース管理は、媒体アクセス制御（ＭＡＣ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）スーパーフレームを用いることができる。

ＴＤＭＡ部におけるトラフィックは、割り当てられたタイムスロットにおいてノードによってフレームが送信されることによるものである。ＣＳＭＡ部におけるネットワークトラフィックは、非同期通信の需要を満たす。非同期通信は、管理フレーム、タイムスロット割当ての要求、データフレームの送信、および失敗したデータフレームの再送信によって生成される。

スーパーフレームは、ノードが他のノードに対しデータフレームを送受信するべきときを指定する。スーパーフレームは、ノードが同じチャネル上で互いに干渉する可能性がある場合、ノードが同時に送信しないようにリソースを割り当てる。

アドホックネットワークにおいて、クライアントは、任意にネットワークに加入し、ネットワークから離脱することができる。これによってネットワークリソース管理は、困難で時間のかかるものとなっている。そのような無線通信ネットワークにおける多くの用途は、サーバーノード（サーバー）と１つまたは複数のクライアントノード（クライアント）とが存在するクライアント−サーバーモデルを用いている。サーバーは、スーパーフレーム内で全てのクライアントによって用いられるリソースを定義する。サーバーは、ビーコンフレーム（ビーコン）において情報を周期的に送信する。ビーコンは、ネットワーク動作を同期させるのに用いられる。

次に、クライアントは、ビーコンフレームにおいて定義された特定の時点において、サーバーからダウンリンクトラフィックデータフレームを受信するか、またはアップリンクトラフィックデータフレームをサーバーに送信することができる。

無線ネットワークのタイプに応じて、サーバーは、各クライアントに対し、そのクライアントのアップリンクトラフィックおよびダウンリンクトラフィックのためにタイムスロットを割り当てることができる。幾つかの場合、サーバーは、複数のクライアントからのアップリンクトラフィックのための共有間隔を指定することができる。この場合、１つまたは複数のクライアントが、ランダムに、またはＣＳＭＡ／ＣＤ等のプロトコルを用いることによって、チャネルへのアクセスを試行し、データフレームの送信を開始する場合がある。この結果、複数のクライアントが同じチャネルで同時にデータフレームを送信し、衝突を引き起こす可能性があり、これによってデータが喪失し、帯域幅が無駄になることになる。

複数のクライアントがサーバーと定期的に通信しているとき、クライアント−サーバーモデルを用いることができる。従来技術では、サーバーは、ビーコンを用いてタイミングおよび周波数の割当てを完全に制御する。サーバーは、必要に応じてクライアントに時間リソースおよびチャネルリソースを割り当てる。

クライアント−サーバーモデルによる通信は、密結合であるので、１つまたは複数のクライアントがビーコンの喪失に起因してサーバーとの同期がずれた場合に１つの問題が生じる。これは、例えば、クライアントが重大で持続的な干渉に遭遇し、これによってビーコンを受信することが不可能となるときに起こり得る。

干渉問題に対処する１つの方法は、周波数ホッピングを用いることである。周波数ホッピングでは、サーバーおよびクライアントが周期的に、異なる周波数を有するチャネルを用いる。クライアントのうちの幾つかが過度な干渉を受けているときにチャネルを変更することは、有用であるが、新たなチャネルも干渉を受ける可能性が非常に高い。

対処する必要がある別の問題は、異なるチャネルにわたってサーバーとクライアントとの間の同期を維持することである。従来技術では、サーバーは、定期的な間隔でチャネルの所定のホッピングシーケンスを用いる。

サーバーとのリンクを喪失したクライアントは、シーケンス内の次のチャネルに切り替え、次のビーコンを待つことができる。このクライアントは、ビーコンを受信した後、サーバーに同期する。

クライアントは、何らかの理由でビーコンの受信に失敗した場合、サーバーとの通信を長期間失う可能性がある。これは、長期間の通信遅延が受入れ不可能な、工場自動化、商業ビル制御等のような多くの時間制約が厳しい用途において生じる可能性がある。更に悪いことに、ビル内の産業環境は、無線通信にあまり適していない。

Ｄｕｓｔ Ｎｅｔｓにおけるような従来のＴＤＭＡに基づくホッピングでは、サーバーは、ホッピングシーケンスを完全に制御し、クライアントは、サーバーと通信するために同じシーケンスに従わなくてはならない。他の場合、例えば、ＺｉｇＢｅｅ（登録商標）における周波数アジリティメカニズムでは、現在のチャネルに雑音が多くなった後、パーソナルエリアネットワーク（ＰＡＮ：Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）コーディネーターが別のチャネルに移動することができ、全ての他のノードは、それに従わなくてはならない。

したがって、無線ネットワークにおいてタイムスロットおよびチャネルの割当てを改善することが所望されている。

この発明の実施の形態は、サーバーと一組のクライアントとの間で共有されるチャネルおよび送信時間の多重アクセス制御（ＭＡＣ：Ｍｕｌｔｉｐｌｅ−Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）およびキャリア（周波数帯域）割当てのための方法を提供する。この発明は、サーバーとクライアントとの間の信頼性のある通信のためのチャネルホッピング方法を説明する。

サーバーがタイムスロットおよびチャネルの配分シーケンスを排他的に管理し、全てのクライアントがそのシーケンスに従う従来技術とは対照的に、この実施の形態は、クライアントが、これらのクライアントによって選択された最適なシーケンスを選択することを可能にする。

さらに、クライアントは、成功するまで、またはチャネルが干渉、シャドーイング、もしくは任意の他の理由により使用不可能になるまで、ホップすることなくチャネル上にとどまることができる。次に、クライアントは、サーバーとの以前の通信に基づいて別のチャネルを選択し、選択されたチャネルにホップする。クライアントは、満足のいくチャネルが選択されるまでホップを続けることができる。

換言すれば、サーバーは、クライアントが用いることができるタイムスロットおよび周波数チャネルの定義のみを行う。一方、クライントは、全て現在のスーパーフレーム内で、自身の目的に最も適したスロットおよび周波数を完全に自律的に選択し割り当てる。クライアントは、バックアップタイムスロットおよびバックアップ周波数、またはサーバーに知られていないスペアタイムスロットを、これらのリソースの割当てがサーバーにシグナリングされるまで選択し割り当てることができる。

従来技術では、クライアントは、異なるチャネルに移る前に、サーバーから指示または同意を得なくてはならない。代替的に、クライアントは、新たなタイムスロットおよびチャネルの割当てを得るためにネットワークから完全に切断し、ネットワークに再加入しなくてはならない。これは、不要な遅延を許容することができない用途において受入れ不可能である。

この発明は、クライアントのみがチャネルの状態を真に評価することができるという認識に基づいている。低レイテンシが用途の要件であることにより、通信が失われる度にサーバー−クライアント同期を再始動するのに十分な時間がない場合があるので、この発明は、クライアントが自律的にかつ迅速にチャネルを変更することを可能にする。

この発明によれば、無線ネットワークにおいてタイムスロットおよびチャネルの割当てを改善することができる。

この発明の実施の形態を用いる無線ネットワークの概略図である。 図１のネットワークによって用いられるスーパーフレームのブロック図である。 図２のスーパーフレーム内のビーコンフレームのブロック図である。 サーバーが全ての割り当てられた周波数チャネルを監視するサイクルの概略図である。 クライアントが、アップリンク送信中の失敗の後に、別のチャネルにホップするサイクルの概略図である。 クライアントが失敗し、別のチャネルにホップするサイクルの概略図である。 クライアントが他の周波数およびタイムスロットを選択するサイクルの概略図である。

図１は、サーバー１０１が一組の周波数チャネル（ＦＣ：Ｆｒｅｑｕｅｎｃｙ Ｃｈａｎｎｅｌｓ）とスーパーフレームとを用いて６つのクライアント（１〜６）１０２と周期的に通信する無線ネットワークを示している。ＦＣは、ネットワークのトポロジおよびチャネル状態が動的に変化することに起因して経時的に変化することができる。

この発明の実施の形態は、ネットワークの動力学に適合するようにタイムスロットおよびチャネル周波数を割り当てる方法を提供する。１つには、この実施の形態は、従来技術におけるように専らサーバーのみがタイムスロットおよび周波数の割当てを行うのではなく、クライアントがタイムスロットおよび周波数の割当てを行うことを可能にする。

本明細書において定義されるように、サーバーは、クライアントによって割り当てることができるネットワークリソースを定義する。リソースは、時間および周波数を含む。リソースは、全てのクライアントによって共有することができるか、または特定のクライアントに専用である。一方、これらのリソースを割り当てるのは、クライアントのみである。本明細書において用いられるとき、割り当ては、クライアントによる、特定のリソースを排他的に用いることの明確なコミットメント（ｅｘｐｒｅｓｓ ｃｏｍｍｉｔｍｅｎｔ）である。本明細書において説明されるようなネットワーク同期並びに定義および割当ては、スーパーフレーム内のビーコンに従って実行される。

加えて、クライアントは、リソースを動的に配分することができる。これは、クライアントが追加データを送信する必要があり、サーバーによって定義されたリソースが追加データを送信するのに十分でない場合である。この場合、クライアントは、サーバーによって必ずしも定義されていないリソースを割り当てる。

本明細書において、変更されたビーコンフレームが説明される。

図２は、この発明の実施の形態によるスーパーフレーム２００の構造を示している。各サイクル４００中、サーバーは、少なくともチャネルごとに１回スーパーフレームを送信する。サイクルは、通常、スーパーフレームの持続時間よりもはるかに長い。スーパーフレームは、ビーコンフレーム（ビーコン）２０１と、ダウンリンク（ＤＬ：Ｄｏｗｎｌｉｎｋ）２０２およびアップリンク（ＵＬ：Ｕｐｌｉｎｋ）２０３トラフィックに割り当てられたタイムスロット数と、再試行タイムスロット２０４のリストと、スペアタイムスロット２０５と、グループＡＣＫ（すなわちＧＡＣＫ：Ｇｒｏｕｐｅ ＡＣＫ）フレーム２０６とを定義する。

図３は、この発明の実施の形態によるビーコンを示している。ビーコンは、フレーム制御（ＣＴＲＬ：Ｃｏｎｔｒｏｌ）、シーケンス番号（ＳＮ：Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）、ソース識別情報（ＩＤ：Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、パーソナルエリアネットワーク（ＰＡＮ）ＩＤ、ビーコン間隔、スーパーフレーム（ＳＦ：Ｓｕｐｅｒｆｒａｍｅ）間隔、ＤＬスロット数、予約済みＵＬスロット、ＲＴ（バックアップ）スロット、再試行ＦＣ、およびスペアスロットをそれぞれ含むフィールド３０１〜３１１を定義する。

予約済み（ＲＳ：Ｒｅｓｅｒｖｅｄ）ＵＬ送信（Ｔｘ）タイムスロット３０８は、スロットカウント３２１と、クライアントＩＤ３２２とを含む。再試行（ＲＴ：Ｒｅｔｒｙ）Ｔｘタイムスロットは、再試行スロットカウントとクライアントＩＤ３３２とを含む。再試行ＦＣは、クライアントＩＤ３４１を含む。サーバーは、例えばデータトラフィックが大きいことがわかっているとき、特定のチャネル上で動作しているクライアントのために、スーパーフレーム内の同じサイズのタイムスロットの幾つかの組を定義することができる。

スーパーフレーム内のゼロ個以上のＤＬタイムスロット３０７の第１の組Ｓ_ｄｌがダウンリンク通信のために定義される。サーバーは、ＤＬタイムスロット中にデータフレームを送信（ユニキャスト、マルチキャスト、またはブロードキャスト）する。

ゼロ個以上の予約済みＵＬタイムスロット３０８の組Ｓ_ｕｌが、データフレームをサーバーに送信するクライアントに対し定義される。

スーパーフレームは、再試行ＵＬスロット３０９の組Ｓ_ｒｔを有することができる。この組は、以前に異なる周波数チャネル上で動作している間にＵＬ送信が成功しなかったクライアントによって割り当てることができ、今は再送信のために割当て可能である。

ＲＴチャネル３１０のリストＬ_ｂｃ（０〜Ｓ_ｕｌまたはＳ_ｒｔ）が、このスーパーフレーム中にＵＬ通信が失敗したときの再送信のために、クライアントのために定義される。サーバーは、手順またはサーバーとクライアントとの間の通信履歴に基づいてこれらのチャネルを定義する。一方、実際の割当てを行うのは、クライアントである。

現在のスーパーフレームにおいて自身に割り当てられたタイムスロット中のＵＬ送信に失敗した任意のクライアントは、リスト３１０内で指定されたチャネルにホップし、次のビーコンを待つことができる。

サーバーは、スペアタイムスロット３１１の組Ｓ_ｘｔも定義することができる。これらのスロットは、新たなクライアントがネットワークに加入し、このクライアントの第１のアップリンクフレームをサーバーに送信することを望むとき、非同期アップリンク通信のために用いられる。サーバーは、その第１のフレームの受信に成功した後、次のスーパーフレームで開始する、そのクライアントのための追加のＵＬタイムスロットを定義することができる。スペアスロットは、再試行のために別の周波数チャネルにホップし、サーバーにこの別のチャネルを取得してもらうことを望むクライアントによって割り当てることもできる。

動作中、サーバーおよびクライアントは、協調的に機能する。サーバーは、以前のサイクル（複数の場合もある）においていずれのクライアントがいずれのチャネル上で動作していたかを知っている。サーバーは、それに従って各クライアントに対しタイムスロットを定義する。サーバーは、クライアントがサーバーによって定義されたチャネル／スロットを用いて送信することができない（または送信することを望まない）場合、異なる周波数チャネル上のバックアップタイムスロットも定義する。クライアントは、バックアップチャネル／スロットを無視し、更に別のチャネルまたはタイムスロットを用いるように試みることを決定することもできる。したがって、サーバーは、定義されたタイムスロット中、全ての定義されたチャネルを監視して、サーバーが各サイクル中に各クライアントと通信することを確実にする。

ＧＡＣＫフレーム２０６は、スーパーフレームの最後にサーバーによって送信される。ＧＡＣＫフレームは、このスーパーフレーム中にサーバーによって受信に成功したアップリンク送信に確認応答する。ＧＡＣＫフレームは、ビットマップを含み、各ビットは、１つのＵＬタイムスロットに対応する。ビットは、成功または失敗を示す。

各クライアントは、最初に、サーバーによって割り当てられたチャネル上のビーコンを待つ。クライアントは、ビーコンを受信した後、サーバーと同期し、ビーコンにおいて指定されたタイムスロットにおいて、サーバーからのＤＬ送信があれば受信する。

クライアントは、自身のアップリンク送信に割り当てられるタイムスロットを確定することもできる。各クライアントは、配分されたタイムスロットにおいてデータフレームを送信する。より多くのデータが通信されることになる場合、例えば、クライアントが通信する大量のデータを有しているとき、クライアントが複数のタイムスロットを割り当てることが可能である。

クライアントは、データフレームを送信した後、ＧＡＣＫフレームを待つ。このフレームは、サーバーが割り当てられたＵＬタイムスロット（複数の場合もある）においてクライアントからアップリンクデータフレームを受信することに成功したか否かを示す。

クライアントが、受信したＧＡＣＫフレームから示されるようにデータフレームの送信に失敗した場合、クライアントは、以下の２つのオプションのうちの一方をとることができる。

第１のオプションにおいて、リストＬ_ｂｃ３１０内にクライアントのために指定された再試行（バックアップ）チャネルが存在しない場合、クライアントは、同じチャネル上で再送信を待つ。

サイクルの持続時間は、スーパーフレームよりもはるかに大きいので、サーバーは、「失敗した」クライアントからデータを受信するためにＦＣＳ（）内の全てのチャネルを監視することができる。この場合、サーバーは、以前にアップリンク送信に失敗したクライアントと通信することのみを試みる。

図４は、サイクル４００中の失敗の例を示している。スーパーフレーム４０１において、ＢおよびＧは、ビーコンおよびＧＡＣＫを示す。クライアント＃１、＃３、および＃５は、ＦＣ ｆ_１を用い、クライアント＃２は、ｆ_２を用い、クライアント＃４および＃６は、ＦＣ ｆ_３を用いる。

クライアント＃６は、ＧＡＣＫフレームを受信した後、失敗した（４１０）と判断する。クライアント＃４は、自身のデータフレームの送信に成功した。

ビーコンフレームによって定義された、クライアント＃６のためにスーパーフレームにおいて割り当てられたバックアップチャネルが存在しない場合、クライアント＃６は、同じチャネルｆ_３に留まり、サーバーがホップしてそのチャネルに戻り、次のスーパーフレームおよびビーコンを送信するまで待つことができる（４２０）。次に、クライアント＃６は、データフレームを再送信することができる。

図４は、スペアタイムスロットのみを監視する（４３０）サーバーも示している。

図５は、クライアント＃６が失敗し（５１０）、次にＦＣ ｆ_１にホップする例を示している。クライアントは、チャネルｆ_１上でビーコンフレームを受信した後、そのスーパーフレーム内で定義されたアップリンクスロットを用いる。チャネルｆ_１上のＵＬ送信に成功した場合、サーバーは、チャネルｆ_１上でそのクライアントへの将来のタイムスロットを割り当てる。サーバーは、スーパーフレーム内でそのクライアントのために別のバックアップ（再試行）チャネルを割り当てることもできる。このとき、そのクライアントは、別のチャネルにホップするオプションを有する。

サーバーは、クライアントごとにチャネル利用履歴を維持する。履歴は、サーバーによって、クライアントのためのバックアップチャネルを定義するために用いられる。特定のクライアントについて履歴が存在しない場合、サーバーは、リソース割当て手順を用いて適切なバックアップチャネルを選択することができる。

クライアントは、ビーコンを受信した後、スーパーフレーム内のスペアタイムスロットの数およびタイミングを求めることができる。次に、クライアントは、スペアスロットを選択し、そのスペアタイムスロット中にデータフレームを再送信し、アップリンク送信が成功したか否かを判断するためにＧＡＣＫフレームを待つ。次に、サーバーは、クライアントによって選択されたチャネルについて履歴を更新する。クライアントによって判断される最適な性能が達成されるまで、クライアントは、チャネルを変更し続けることができる。

クライアントは、サーバーによって定義されたチャネル上での所定の数の失敗の後、そのチャネルを放棄することを決定することができる。そのような場合、クライアントは、ＦＣＳ内の別のチャネルにホップし、ビーコンを待つ。

図６は、クライアント＃６が失敗し（６１０）、別の周波数を選択する（６２０）一方、サーバーがスペアタイムスロットのみを監視する（６３０）例を示している。この場合、サーバーは、全てのクライアントがサービス提供されるまで、全てのチャネルを監視する。次に、サーバーは、スペアスロットのみの監視を続け、クライアントは、周波数チャネルを選択し、スペアスロットを自身の使用のために割り当てる。

図７は、新たなクライアントのための加入プロセスの例を示している。この実施の形態では、サーバーは、新たなクライアントがネットワークに加入することを容易にするプロセスを有しない。最初に、クライアントが存在せず（７１０）、予約済みスロットが存在せず、スペアスロットのみが存在する。

新たなクライアント＃１および＃６は、ビーコンを受信した後、ＦＣ（ｆ_２）および（ｆ_３）並びにスペアタイムスロットを選択する（７２０）。これらのクライアントは、成功した場合、このとき予約済みスロットおよびＦＣを有している（７４０）。そうでない場合、クライアントは、サーバーがＦＣ上にないか、または干渉が多すぎるのかを判断するために複数の（３つの）サイクルを待ち、次に別のＦＣを選択する。次のＦＣは、衝突を回避するように選択される。

複数のクライアントがサーバーとのコンタクトを失い、２つ以上のクライアントが同じＦＣを選択しようと試み、かつそのＦＣに上に１つのスペアスロットしか存在しない場合、問題となる可能性がある。この場合、衝突が生じる可能性があり、いずれのクライアントも新たなＦＣへの移動に成功しない。

この問題を解決するために、サーバーは、ビーコンにおいて、このＦＣ上の失敗したクライアントのためにサーバーがいずれの代替のＦＣを監視することになるかを示し、サーバーは、失敗したクライアント数に応じて、十分な数のスロット数を定義する。

各クライアントに、１つの代替のＦＣのスペアスロットを割り当てることができる。サーバーは、各クライアントの周波数ごとの履歴エラー記録に基づいてクライアントごとの単位で代替のＦＣを選択する。クライアントは、再試行スロットＦＣを無視し、代わりにスペアスロットおよび別のＦＣに移るオプションを有する。

発明の効果
この発明は、クライアントがタイムスロットおよびチャネル、すなわちネットワークリソースを自律的に選択することを可能にする。

クライアントは、成功するまで、またはチャネルが干渉、シャドーイング、もしくは任意の他の理由により使用不可能になるまで、ホップすることなくチャネル上にとどまることができる。後者の場合、クライアントは、サーバーとの以前の通信に基づいて別のチャネルを選択し、選択されたチャネルにホップすることができる。クライアントは、満足のいくチャネルが選択されるまでホップを続けることができる。

サーバーは、クライアントが用いることができるタイムスロットおよび周波数チャネルのみを定義する。一方、全て現在のスーパーフレーム内で、クライアントの目的に最も適したスロットおよび周波数を選択するのは、クライアントである。

これによって、クライアントが、干渉が問題となる低レイテンシ用途の無線用途、特に産業環境において動作することが可能になる。例えばレイテンシは、約数ミリ秒以下である。

この発明によって、クライアントがチャネル状態を評価し、遅延なく異なるチャネルに変更することが可能になる。

Claims (15)

1. サーバーおよびクライアントを含む無線ネットワークにおいてリソースを管理する方法であって、
   前記サーバーによって、スーパーフレームのビーコンにおいて前記リソースを定義するステップであって、前記リソースは、タイムスロットおよび周波数チャネルであるものと、
   前記クライアントによって前記リソースを割り当てるステップであって、前記タイムスロットは、スペアタイムスロットを含み、前記サーバーは、異なる周波数チャネル上の前記スペアタイムスロットを定義するものと、
   前記サーバーによって、前記各サイクル中に、前記サーバーによって定義された前記各リソースを監視して、前記サーバーが前記各サイクル中に前記各クライアントと通信することを確実にする、監視するステップと、
   を含む、サーバーおよびクライアントを含む無線ネットワークにおいてリソースを管理する方法。
2. 前記無線ネットワークは、アドホック無線ネットワークである、請求項１に記載の方法。
3. 前記クライアントは、リソースを動的に割り当てる、請求項１に記載の方法。
4. 前記クライアントは、前記クライアントによって選択された最適な周波数ホッピングシーケンスに従う、請求項１に記載の方法。
5. 前記クライアントは、データフレームの送信が成功している間は、ホップすることなくチャネル上に留まり、前記方法は、
   成功しなかった場合、前記クライアントによって別のチャネルを選択するステップ
   を更に含む、請求項１に記載の方法。
6. 前記クライントは、現在のスーパーフレーム内で、前記タイムスロットおよび前記周波数チャネルを完全に自律的に選択し割り当てる、請求項１に記載の方法。
7. 前記クライアントは、スペアタイムスロットおよびバックアップ周波数を選択し割り当てる、請求項１に記載の方法。
8. 前記リソースは、前記クライアントによって共有されるように定義される、請求項１に記載の方法。
9. 前記リソースは、特定のクライアントに専用であるように定義される、請求項１に記載の方法。
10. 前記サーバーによって、サイクル中にチャネルごとに少なくとも１回、前記スーパーフレームを送信するステップであって、前記サイクルの持続時間は、前記スーパーフレームの持続時間より長い、送信するステップ
    を更に含む、請求項１に記載の方法。
11. 前記定義するステップは、前記サーバーと前記クライアントとの間の通信履歴に従う、請求項１に記載の方法。
12. 前記クライアントは、複数のタイムスロットを割り当てる、請求項１に記載の方法。
13. 前記クライアントは、前記クライアントによって判断される最適な性能が達成されるまで前記周波数チャネルを変更し続ける、請求項１に記載の方法。
14. 特定のクライアントが、前記周波数チャネル上での所定の数の失敗の後、前記チャネルを放棄し、別の周波数チャネルにホップする、請求項１に記載の方法。
15. 請求項１から請求項１４までの何れか１項に記載のサーバーおよびクライアントを含む無線ネットワークにおいてリソースを管理する方法に適用されるクライアント。

Images