JP5221769B2

JP5221769B2 - 送信機及び／又は受信機通信決定を行うための方法及び装置

Info

Publication number: JP5221769B2
Application number: JP2011535604A
Authority: JP
Inventors: リ、ジュンイ; ラロイア、ラジブ; タビルダー、サウラブー・アール．; ウ、シンジョウ
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2008-11-10
Filing date: 2009-10-30
Publication date: 2013-06-26
Anticipated expiration: 2029-10-30
Also published as: TW201106756A; KR101234727B1; KR20110086597A; CN102210187B; JP2012508504A; WO2010053849A3; EP2356778B1; US8520524B2; WO2010053849A2; US20100118701A1; CN102210187A; EP2356778A2

Description

様々な実施態様は、無線通信方法及び装置に関係し、より詳しくはサービス品質レベル情報を通信及び／又は使用するための無線通信方法及び装置に関係する。

通信システムにおいて、データは、例えば、送信されるデータのタイプ、データが送信されるデバイスに関連するプライオリティー・レベル、データを送信しようとしている通信デバイスのユーザに関連するプライオリティー・レベル及び／又は意図されたデータ受信者及び／又はデータを受信するデバイスに関連するプライオリティー・レベルについて、異なるレベルの送信プライオリティーを有することがある。

データが特定のプライオリティー・レベルを与えられ（entitle）得る理由は変化し得るが、同等の（comparable）データ・プライオリティー・レベルを提供するために、送信されるデータのプライオリティーは、送信されるデータに対してシステム中で受信するために与えられるサービス品質レベルの観点で表され得る。サービス品質レベルは、システム及び／又はサービス品質レベル情報の伝達に利用できるビット数に従って１又は複数のビット値として表され得る。

異なるレベルのサービス品質の実装を容易にするために、通信されるデータに対応するサービス品質レベルを通信システム中の１又は複数のデバイスが知っていることは有益である。

ピアツーピアの通信システムにおいて、個々のピア・デバイスが、データ送信を開始するべきであるか又はデータを送信するためのリクエストに応答するべきかどうかについての決定をし得る場合に、該決定をする個々のピア・デバイスが、送信に関係のある決定をするときに利用できるサービス品質情報を有するならば、それは有益であろう。

それゆえ、通信及び／又はサービス品質レベル情報の使用を可能にするであろうピア・デバイス間の通信を容易にする方法が必要であることは認識されるべきである。

無線通信ネットワーク（例えば、局所的な（regional）アドホックなピアツーピア・ネットワーク）で使用される方法及び装置が説明される。

いくつかの（ただし、すべてである必要はない）態様は、送信機イールディング及び／又は受信機イールディング決定をするための方法及び／又は装置に向けられる。送信機イールディング決定の場合は、送信することを望むデバイス（例えば、ピアツーピアのデバイス）は、例えば干渉及び／又はサービス品質に起因して、送信することを控えるという決定をしても良い。受信機イールディングの場合は、デバイスは、送信リクエスト・レスポンスを送信しないことに決定しても良く、それゆえ、該送信リクエスト・レスポンスを送信しないことに決定しているデバイスへの送信の機会をなしで済ませるようにしても良い。サービス品質の問題（issues）は、例えばデータ又は送信リクエスト・レスポンスを送信することを控えることに決定しているデバイスとの、プライオリティーの問題を含んでも良い。なぜならば、例えば、それが送信しなければならないデータは、他のコネクションに対応するデータよりも低いサービス品質レベルを与えられるので。

一つの例示的な実施態様に従って、例示的な第１の通信デバイスを操作する方法は、送信リクエスト・レスポンス信号からサービス品質レベルをリカバーすることと、前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をすることを含む。いくつかの（ただし、必ずしもすべてである必要はない）実施態様において、前記サービス品質レベルは、第１の送信リクエスト・レスポンス信号の位相からリカバーされる。第１の通信デバイスから受信されるパイロットは、第１の送信リクエスト・レスポンスの位相を解釈（interpret）するのに使用されても良く、そして、いくつかの実施態様ではそのように使用される。

いくつかの実施態様に従って、例示的な第１の通信デバイスは、送信リクエスト・レスポンス信号からサービス品質レベルをリカバーし、前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をするように構成された少なくとも一つのプロセッサを含む。前記第１のデバイスはまた、前記少なくとも一つのプロセッサに接続されたメモリを含んでも良い。

他の例示的な実施態様に従って、第１の通信デバイスを操作する他の例示的な方法は、第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーすることと、前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をすることを含む。

他の態様に従って実装される例示的な第１の通信デバイスは、第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーし、前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするように構成された少なくとも一つのプロセッサを含む。メモリは、前記少なくとも一つのプロセッサに接続されても良く、そして、いくつかの実施態様ではそのように接続される。

例えば、本明細書で説明される方法及び装置は、例えば他の信号（例えば、アクセス・ルータにより送信されるリクエスト・レスポンス信号）の位相の正確な解釈（accurate interpretation）を可能にする位相基準（phase reference）として使用されることができるパイロット信号を送信するアクセス・ルータをともなうシステムで使用するのに特に良く適している。

いくつかの態様に従って、アクセス・ルータにより送信される送信リクエスト・レスポンス信号の位相は、プライオリティー・レベルの情報を伝える。アクセス・ルータの送信リクエスト・レスポンス（例えば、アクセス・ルータに送信する許可を要求したピアツーピア通信デバイスによりなされるアップリンク送信リクエストに対するレスポンス）を受信するデバイスは、アクセス・ルータの送信リクエスト・レスポンスを検出して、受信信号から対応するサービス品質レベルを判定することができる。アクセス・ルータに送信されるべきデータに対応するサービス品質レベルは、例えばアクセス・ルータから受信されるパイロット信号に基づくリクエスト・レスポンス信号の位相の解釈によって、該リクエスト・レスポンス信号からリカバーされることが可能であり、そして、いくつか実施態様ではそのようにリカバーされる。そのような実施態様では、リクエスト・レスポンス信号の位相は、サービス品質レベルの情報を伝えるが、リクエスト・レスポンス信号のエネルギーは、送信リクエストに対する肯定的なレスポンスを伝えるために使用される。アクセス・ルータの送信リクエスト・レスポンスを受信するデバイスは、アクセス・ルータの送信リクエスト・レスポンスからリカバーされるサービス品質レベル情報に基づいて、他のデバイスへの送信を開始するか否かの決定をすることができ、そして、いくつか実施態様ではそのように決定をする。例えば、デバイスが、アクセス・ルータの送信リクエスト・レスポンスにより示されるプライオリティー・レベルより高いプライオリティー・レベルをもつデータを有するならば、該デバイスは、アクセス・ルータの送信リクエスト・レスポンスの後で起こると予期されるアクセス・ルータへの送信に干渉するか否かにかかわらず、その意図された送信を開始しても良い。しかし、デバイスが送信することを意図するデータが、アクセス・ルータの送信リクエスト・レスポンスにより示されるプライオリティー・レベルより低いプライオリティー・レベルを有するならば、デバイスは、送信することがアクセス・ルータへの送信に対してもたらし得る干渉の量に基づいて、送信するか否かの決定をしても良い。干渉の量は、コスト関数又は干渉コスト推定に関して表されても良い。ここで、より高いコストは、アクセス・ルータへの送信に対するより高い干渉の影響（interference impact）を示す。干渉コストが予め定められた閾値を越え、且つ、送信されるべきデータのプライオリティー・レベルがアクセス・ルータの送信リクエスト・レスポンスで示されるプライオリティー・レベルより低いならば、デバイスは、アクセス・ルータへの予期される送信に干渉を引き起こすことを回避するために送信することを控えることに決定しても良く、そして、いくつかの実施態様ではそのように決定する。

他の態様に従って、他のデバイスによりアクセス・ルータへ送信される送信リクエストに応答するアクセス・ルータから、送信リクエスト・レスポンスを受信するデバイスは、異なるデバイスにより前記デバイスへ送信された送信リクエストに対する送信リクエスト・レスポンスを送信するか否か決定する。いくつかの実施態様において、この受信機イールディング決定は、アクセス・ルータの送信リクエスト・レスポンスからリカバーされるサービス品質レベルに基づいてなされる。いくつかの（ただし、必ずしもすべてである必要はない）実施態様において、サービス品質レベル情報は、アクセス・ルータの送信リクエスト・レスポンスの位相からリカバーされる。アクセス・ルータからの１又は複数のパイロットの使用は、アクセス・ルータの送信リクエスト・レスポンス信号の位相が正確に解釈されることを可能にし、それゆえ、サービス品質レベルが送信リクエスト・レスポンス信号の位相を使用して伝えられることを可能にする。

本発明のいくつかの態様は、アクセス・ルータがリクエスト・レスポンスを送信するデバイスである場合にアプリケーションで使用するのに良く適しているが、本明細書で説明される方法及び実施態様は、アクセス・ルータがリクエスト・レスポンスを送信するデバイスである場合の実施態様に制限されないことは認識されるべきである。さらにまた、いくつかの実施態様では、サービス品質レベル情報を伝えるために位相が使用されるが、様々な方法でサービス品質（例えば、プライオリティー）情報を符号化することが可能であることは認識されるべきである。

上記の概要で様々な実施形態について述べたが、必ずしも、すべての実施形態が同じ特徴を含むわけではなく、上述の特徴のいくつかは、いくつかの実施形態においては必要ではない（ただし望ましい可能性がある）ことは認識されるべきである。多数の更なる特徴、実施形態及び様々な実施形態の利益が、以下の詳細な説明において述べられる。

図１は、一つの例示的な実施態様に従った例示的なピアツーピア通信ネットワーク（例えば、ローカル領域のアドホックなピアツーピア通信ネットワーク）の図である。図２（それは図２Ａ及び２Ｂの組み合せを含む）は、例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャートである。図２Ａは、一つの例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャートの第１の部分である。図２Ｂは、一つの例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャートの第２の部分である。図３は、一つの例示的な実施態様に従った例示的な通信デバイスの図である。図４は、図３の例示的な通信デバイスで使用されることができるモジュールのアセンブリを示す。図５は、一つの例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャートである。図６は、一つの例示的な実施態様に従った例示的な第１の通信デバイスの図である。図７は、図６の例示的な通信デバイスで使用されることができるモジュールのアセンブリを示す。図８は、一つの例示的な実施態様に従った例示的なピアツーピア通信ネットワーク（例えば、ローカル領域で実装されるアドホックなピアツーピア通信ネットワーク）を示す。図９は、一つの例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャート９００である。図１０は、一つの例示的な実施態様に従った例示的な通信デバイスの図である。図１１は、図１０の例示的な通信デバイスで使用されることができるモジュールのアセンブリを示す。図１２は、一つの例示的な実施態様に従った第１の通信デバイスを操作する例示的な方法のフローチャートである。図１３は、一つの例示的な実施態様に従った例示的な通信デバイスの図である。図１４は、図１３の例示的な通信デバイスで使用されることができるモジュールのアセンブリを示す。

詳細な説明

図１は、例示的な実施態様に従った例示的なピアツーピア通信ネットワーク１００（例えば、ローカル領域で実装されるアドホックなピアツーピア通信ネットワーク）の図である。例示的な通信ネットワーク１００は、複数のピアツーピア無線通信デバイス（通信デバイスＡ１０２，通信デバイスＢ１０４，通信デバイスＣ１０８，通信デバイス１１１０，．．．，通信デバイスＮ１１２）及びアクセス・ルータ１０６（例えば、基地局）を含む。通信ネットワーク１００では一つのアクセス・ルータが示されたが、通信ネットワークがいくつかのアクセス・ルータを含んでも良く、そして時々それらを含むことは、認識されるべきである。無線通信デバイス（１０２，１０４，１０８，１１０，．．．，１１２）は、ピア間の様々なシグナリング（例えば、ピア発見信号、送信リクエスト信号、送信リクエスト・レスポンス信号など）と、データ伝送（例えば、トラフィック信号）とをサポートする。ピアツーピア通信デバイスのいくつか（例えば、通信デバイス１１１０）はまた、無線通信インタフェースに加えて、他のノード及び／又はインターネットにピアツーピア通信デバイスを接続させる有線インタフェースを含む。ピアツーピア通信デバイスのいくつかは、モバイル通信デバイス（例えば、ハンドヘルド型モバイル通信デバイス）である。

一つの例示的な実施態様に従って、ピアツーピア通信デバイス（例えば、通信デバイスＣ１０８）は、アクセス・ルータ１０６に送信リクエスト信号１２０を送信する。アクセス・ルータ１０６は、リクエスト・レスポンス信号１２２を送信することによって、通信デバイスＣ１０８に応答しても良く、そして時々そのように応答する。いくつかの実施形態において、リクエスト・レスポンス信号１２２の送信は、アクセス・ルータ１０６が送信リクエスト信号１２０に同意（acquiesces）することを示す。いくつかの実施形態において、リクエスト・レスポンス信号１２２は、シングルトーン信号、すなわち、シングルＯＦＤＭトーンを使用して通信される信号である。例えば、いくつかのそのような実施態様において、シングルＯＦＤＭ送信タイムインターバル（例えば、シングルトーン信号）の間に通信されるそのようなシングルトーン信号は、一つのＯＦＤＭトーン − シンボルを使用して通信される。いくつかの実施形態において、タイミング／周波数構造における異なるセットのＯＦＤＭトーン − シンボルは、異なる信号（例えば、リクエスト信号、リクエスト・レスポンス信号、パイロット信号、ビーコン信号など）に関連する。いくつかの実施形態において、リクエスト・レスポンス信号１２２は、時々、シングルトーンを使用して通信される。いくつかのそのような実施態様では、リクエスト・レスポンス信号１２２の位相は、サービス品質（ＱｏＳ）レベル（例えば、送信プライオリティー）を伝える。例示的な実施態様に従って、無線通信デバイス（１０２，１０４，１０８，１１０，．．．，１１２）は、アクセス・ルータ１０６を含むシステム１００中のアクセス・ルータを知っている。いくつかのそのような実施形態において、通信デバイス（１０２，１０４，１０８，１１０，．．．，１１２）は、通信デバイス（１０２，１０４，１０８，１１０，．．．，１１２）が現在検出できるアクセス・ルータ１０６を含むネットワーク１００中のアクセス・ルータのうちの１又は複数へのチャネルをトラッキングする。例えば、通信デバイスＡ１０２がアクセス・ルータ１０６を検出でき、アクセス・ルータ１０６とそれ自身との間のチャネルをトラッキングしていると考える。更に、通信デバイスＢ１０４がアクセス・ルータ１０６を検出でき、アクセス・ルータ１０６とそのデバイス自身との間のチャネルをトラッキングしていると考える。更に、通信デバイスＡ１０２及び通信デバイスＢ１０４はまた、アクセス・ルータ１０６から通信デバイスＣ１０８へ送信されるリクエスト・レスポンス信号１２２を受信すると考える。チャネル状態（channel conditions）のトラッキングを使用して、通信デバイスＡ１０２及び通信デバイスＢ１０４は、リクエスト・レスポンス信号１２２で伝えられる情報、例えば、リクエスト・レスポンス信号１２２の位相で伝えられるＱｏＳレベル情報をリカバーすることができる。

図１で示されるように、ピアツーピア通信デバイスＢ１０４は、ピアツーピア通信デバイスＡ１０２に対して、データ（例えば、トラフィック・データ）を送信しようと試みる。それゆえ、通信デバイスＢ１０４は、通信デバイスＡ１０２に、送信リクエスト信号１２４を送信する。いくつかの実施形態において、通信デバイスＡ１０２が送信リクエスト信号１２４に同意するならば、通信デバイスＡ１０２は通信デバイスＢ１０４へリクエスト・レスポンス信号１２６を送信する。いくつかの実施形態において、リクエスト・レスポンス信号１２６は、通信デバイスＡ１０２がデバイスＢ１０４からトラフィック・データを受信することに同意できる（agreeable）ことを、デバイスＢ１０４に伝える。いくつかの実施態様において、通信デバイスＡ１０２は、１又は複数の条件が満たされるか否かに基づいて、送信リクエスト信号１２４に応答してリクエスト・レスポンス信号１２６を送信するか否かを決定する。例えば、一つの例示的な実施態様において、通信デバイスＡ１０２は、受信されたリクエスト・レスポンス信号１２２の位相から、ＱｏＳレベルをリカバーする。ＱｏＳレベルが、より高いプライオリティーのトラフィック・データが通信デバイスＣ１０８からアクセス・ルータ１０６へ送信されるべきことを示すならば、通信デバイスＡ１０２は、リクエスト・レスポンス信号１２６を送信しないことに決定しても良く、そして時々そのように決定する。いくつかの実施形態においては、リクエスト・レスポンス信号１２６を送信するか否かの決定は、他のコネクションの意図されたより高いプライオリティーのトラフィックの検出に基づく基準に加えて、更なる基準に基づく。例えば、いくつかの実施態様では、通信デバイスＡ１０２は、送信リクエスト信号１２４の受信電力及び送信リクエスト信号１２０の受信電力に基づいて、リクエスト・レスポンス信号１２６を送信するか否か決定する。

いくつかの実施形態において、リクエスト・レスポンス１２６が通信デバイスＢ１０４により受信される場合には、それは、例えば上で示されるように、１又は複数の条件が満たされるか否かに基づいて、通信デバイスＡ１０２にトラフィック・データを送信するか否かを決定する。一つの例示的な実施態様では、通信デバイスＢ１０４は、受信されたリクエスト・レスポンス信号１２２の位相から、ＱｏＳレベルをリカバーする。いくつかの実施形態においては、通信デバイスＢ１０４は、受信されたリクエスト・レスポンス信号１２２の位相を解釈する（例えば、位相からＱｏＳレベルをリカバーする）ために、通信デバイスＢ１０４とアクセス・ルータ１０６との間のチャネルについて生成されたチャネル推定を使用する。チャネル推定は、アクセス・ルータ１０６から受信されるパイロット信号１２１を使用して、通信デバイスＢ１０４により生成されても良く、そして時々そのように生成される。いくつかの実施形態においては、通信デバイスＢ１０４は、通信デバイスＢ１０４が通信デバイスＡ１０２に送信することを望むトラフィック・データの送信プライオリティー・レベルを知っている。いくつかの実施態様において、通信デバイスＣ１０８からアクセス・ルータ１０６へ通信されるべきトラフィック・データが、それ自身の意図されたトラフィック送信に関連するプライオリティーと比較して、より高いプライオリティー（リカバーされたＱｏＳレベルにより示される）を有することを、リカバーされたＱｏＳレベルが示すならば、通信デバイスＢ１０４は、イールディングすることに、すなわち、現在の送信スロットにおいて通信デバイスＡ１０２にそのトラフィック・データを送信しないことに決定しても良く、そして時々そのように決定する。いくつかの他の実施態様において、通信デバイスＢ１０４は、予め定められた基準に基づいて、通信デバイスＡ１０２にそのトラフィック・データを送信することに決定しても良い。いくつかの実施形態において、イールディングするという通信デバイスＢ１０４による送信機イールディング決定は、通信デバイスＣ１０８からアクセス・ルータ１０６へのより高いプライオリティーのトラフィック・データの通信を容易にするためになされる。それゆえ、通信デバイスＢ１０４の送信機イールディングは、通信デバイスＣ１０８からアクセス・ルータ１０６へのトラフィックが、同一のトラフィック・エアーリンク資源（例えば、同一のトラフィック・セグメント）における通信デバイスＢ１０４と通信デバイスＡ１０２との間のトラフィック送信からの干渉なしで起こることを可能にする。

図２（それは図２Ａ及び２Ｂの組み合せを含む）は、例示的な実施態様に従った第１の通信デバイス（例えば、図１の通信デバイスＢ１０４）を操作する例示的な方法のフローチャート２００である。例示的な方法のオペレーションは、ステップ２０２において開始する。そこでは、第１の通信デバイス（例えばデバイスＢ１０４）が、パワーオンされ初期化される。オペレーションは、開始ステップ２０２からステップ２０４へ進む。例示的な実施態様に従って、第１の通信（例えば、デバイスＢ１０４）が、そこにおいて第３の通信デバイス（例えば、デバイスＡ１０２）に送信しようと試みる各々のトラフィック・スロットごとに、以下に記すように、フローチャート２００における様々なステップが実行される。様々な実施態様において、第１の通信デバイス（例えば、Ｂ１０４）は、フローチャート２００の様々な他のステップと並行して、チャネル推定サブルーチン２０３を実行する。チャネル推定サブルーチン２０３は、第１の通信デバイス（例えば、デバイスＢ１０４）とアクセス・ルータ（例えば、アクセス・ルータ１０６）との間のチャネルに関するチャネル推定方法を実装する。サブルーチンは、フローチャート２００の他のステップが実行されるレートとは異なるレート（例えば、より遅いレート）で実行されるステップ２０５,２０７及び２０９を含む。例えば、サブルーチン２０３の実行は、第１の通信デバイス（例えば、デバイスＢ１０４）がそこにおいて第３のデバイス（例えば、デバイスＡ１０２）にトラフィック・データを送信しようと試みる複数のトラフィック・スロットを含む期間（time period）の後、繰り返されても良い。

ステップ２０４において、第１の通信デバイス（例えば、デバイスＢ１０４）は、第３の通信デバイス（例えば、通信デバイスＡ１０２）に、送信リクエスト信号（例えば、リクエスト信号１２４）を送信する。オペレーションは、ステップ２０４からステップ２０６へ進む。そこでは、第１の通信デバイスＢ１０４が第３の通信デバイスＡ１０２から送信リクエスト・レスポンス信号（例えば、リクエスト・レスポンス信号１２６）を受信する。送信リクエスト・レスポンス信号１２６は、第１の通信デバイス（例えば、デバイスＢ１０４）によって送信されるリクエスト信号１２４に応答するものである。オペレーションは、ステップ２０６からステップ２０８へ進む。

ステップ２０８において、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータ（例えば、アクセス・ルータ１０６）から、送信リクエスト・レスポンス信号（例えば、リクエスト・レスポンス信号１２２）を受信する。送信リクエスト・レスポンス１２２は、第２の通信デバイス（例えば、通信デバイスＣ１０８）からアクセス・ルータ１０６へ送信されるトラフィック送信リクエスト信号（例えば、リクエスト信号１２０）に応答するものである。いくつかの実施形態においては、送信リクエスト・レスポンス信号１２２は、シングルトーン信号である。様々な実施態様では、送信リクエスト・レスポンス信号１２２の位相は、ＱｏＳ情報を伝える。いくつかの実施形態においては、ＱｏＳ情報は、第２の通信（例えば、デバイスＣ１０８）によって送信リクエスト１２０がそのためになされたトラフィック・データの送信のためのトラフィック送信プライオリティーを伝達する。オペレーションは、ステップ２０８からステップ２１０へ進む。

これからサブルーチン２０３（それはステップ２０５,２０７及び２０９を含む）が説明される。ステップ２０５において、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータ１０６からパイロット信号（例えば、パイロット信号１２１）を受信する。オペレーションは、ステップ２０５からステップ２０７へ進む。そこでは、第１の通信デバイス（例えば、デバイスＢ１０４）が、アクセス・ルータ１０６と第１の通信デバイス（例えば、デバイスＢ１０４）との間のチャネルのチャネル推定を生成する。例示的な実施態様に従って、生成されたチャネル推定は、送信リクエスト・レスポンス信号１２２の位相を解釈するために、第１の通信デバイス（例えば、デバイスＢ１０４）によって、時々使用される。矢印線２１１は、生成されたチャネル推定が、デバイスＢ１０４に利用可能であり、ステップ２１０で使用され得ることを表す。オペレーションは、ステップ２０７からリターン２０９へ進む。そこから、該オペレーションは、ステップ２０５へ進む。前に述べたように、サブルーチン２０３は、例えば予め定められたスケジュールに従って、ある期間の後、繰り返されても良く、そして時々そのように繰り返される。

ステップ２１０を参照して、ステップ２１０では、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータから受信される送信リクエスト・レスポンス信号から（例えば、アクセス・ルータ１０６から受信される送信リクエスト・レスポンス信号１２２から）、ＱｏＳレベルをリカバーする。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＢ１０４）は、ステップ２１０におけるＱｏＳレベルのリカバーの一部として、サブステップ２１２及び２１３を実行する。サブステップ２１２において、第１の通信デバイスは、受信された送信リクエスト・レスポンス信号（例えば、信号１２２）の位相を解釈するために、生成されたチャネル推定（例えば、ステップ２０７で生成される）を使用する。例えば、ステップ２０７の生成されたチャネル推定なしで、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータ１０６と通信デバイスＣ１０８との間のコネクションに対応する受信されたリクエスト・レスポンス信号１２２の位相を正確に解読（decode）するために、参照点（reference point）を有しないかもしれないことが有り得る。それゆえ、信号１２２の位相を正しく解読して、伝えられているＱｏＳレベルを得るために、第１の通信デバイス（例えばデバイスＢ１０４）は、パイロット信号（例えば、パイロット信号１２１）を使用してチャネル推定を生成し、チャネル変化（channel variations）のために引き起こされる位相歪みを補償するためにチャネル補償オペレーションを実行する。第１の通信デバイス（例えば、デバイスＢ１０４）がそれ自身とアクセス・ルータ１０６との間のチャネル状態を調整することができ、それゆえ、信号１２２の位相を読み取って（read）、位相により伝えられている正しいＱｏＳレベルをリカバーすることができるるように、これが実行される。サブステップ２１３において、ＱｏＳレベルが、受信された送信リクエスト・レスポンス信号（例えば、信号１２２）の位相からリカバーされる。オペレーションは、接続ノード２０１を介して、ステップ２１０からステップ２１４へ進む。

ステップ２１４において、第１の通信デバイス（例えばデバイスＢ１０４）は、リカバーされたＱｏＳレベルに基づいて、トラフィック・データを送信するべきか否か決定する。いくつかの実施形態においては、ステップ２１４は、サブステップ２１６,２１８,２２０及び２２２を含む。サブステップ２１６において、第１の通信デバイス（例えば、デバイスＢ１０４）は、リカバーされたＱｏＳレベルを、送信されるべきトラフィック・データに対応するＱｏＳレベルと比較する。比較は、ステップ２１０のアクセス・ルータからのリクエスト・レスポンス信号からリカバーされたＱｏＳレベルと、第１の通信デバイス（デバイスＢ１０４）から第３の通信デバイス（例えば、デバイスＡ１０２）に送信されるべきトラフィック・データに関連するＱｏＳレベルとの間でなされる。いくつかの実施形態においては、ＱｏＳレベルの比較は、単に、リカバーされたＱｏＳレベルにより示される送信プライオリティーと、第１の通信デバイス（例えば、デバイスＢ１０４）から第２の通信デバイス（例えば、デバイスＡ１０２）に送信されるべきトラフィック・データの送信プライオリティーとの比較である。オペレーションは、サブステップ２１６からサブステップ２１８へ進む。

サブステップ２１８において、第１の通信デバイス（例えば、デバイスＢ１０４）は、ＱｏＳレベルの比較の結果に基づいて、どのように進むかの決定をする。送信されるべきトラフィック・データのＱｏＳレベルが、リカバーされたＱｏＳレベルより大きいならば、オペレーションはステップ２１８からサブステップ２２０へ進む。ステップ２２０において、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータから受信される送信リクエスト・レスポンス信号の電力レベルにかかわりなく（例えば、信号１２２の受信電力レベルにかかわりなく）、第３の通信デバイス（例えば、デバイスＡ１０２）にそのトラフィック・データを送信することに決定する。そのような場合には、オペレーションはステップ２２０からステップ２３２へ進む。

サブステップ２１８を参照して、ステップ２１８において、送信されるべきトラフィック・データのＱｏＳレベルが、リカバーされたＱｏＳレベルより低いならば、オペレーションはサブステップ２１８からサブステップ２２２へ進む。サブステップ２２２において、第１の通信デバイス（例えば、デバイスＢ１０４）は、アクセス・ルータからの送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するべきか否か決定する。例えば、いくつかの実施態様では、干渉コスト推定（例えば、ＳＩＲレベル）は、１又は複数のサブステップ２２４,２２６,２２８及び２３０を含み得る決定サブステップ２２２の一部として、第１の通信デバイス（例えば、デバイスＢ１０４）によって計算される。サブステップ２２４において、アクセス・ルータから受信された送信リクエスト・レスポンス信号（例えば、信号１２２）の電力レベルが測定される。ステップ２２４からのリクエスト・レスポンス信号の測定された電力レベルを使用して、アクセス・ルータ１０６に対する干渉コストが、サブステップ２２６で計算される。計算された干渉コストは、第１の通信デバイス（例えば、デバイスＢ１０４）がトラフィック・データを送信する場合に、第１の通信デバイス（例えば、デバイスＢ１０４）によってアクセス・ルータ（例えば、アクセス・ルータ１０６）に引き起こされる得る干渉の量のインジケーションを提供する。サブステップ２２８において、ステップ２２６の計算された干渉コストは、第１の通信デバイス（例えば、デバイスＢ１０４）が、閾値レベルを超える干渉をアクセス・ルータ（例えば、アクセス・ルータ１０６）に引き起こすことが予期されるかどうか判定するために、閾値レベルと比較される。我々は本明細書で例としてアクセス・ルータ１０６に対する干渉コストを検討したが、第１の通信デバイス（例えば、デバイスＢ１０４）は、該第１の通信デバイス（例えば、デバイスＢ１０４）がそのトラフィック・データを送信し得るか又はそのトラフィック・スロットでそのトラフィック・データを送信することを控えなければならないかを決定するために、該第１の通信デバイスの意図されたトラフィック・シグナリングから干渉を経験し得ることが予期される意図されたトラフィック通信が存在し得るネットワーク１００中の他の通信デバイスのうちの１又は複数に対する干渉コストを計算しても良く、そして時々そのように計算することは、認識されるべきである。例えば、第１の通信デバイス（例えば、デバイスＢ１０４）は、それが容認できないレベルの干渉を１又は複数の他の通信デバイスに引き起こすことが予期されるならば、そのトラフィック・スロットでトラフィック信号を送信することを控えるように制御されても良い。サブステップ２３０において、第１の通信デバイス（例えば、デバイスＢ１０４）により、ステップ２２８の比較の結果に基づいて、送信するか否かについて決定がなされる。

オペレーションは、サブステップ２２２においてなされる決定に基づいて、サブステップ２２４，２２６，２２８及び２３０を含むステップ２２２から、ステップ２３２又はステップ２３４のいずれかに進む。計算された干渉コストが閾値を下回るならば、肯定的な決定（positive decision）（すなわち、トラフィック・データを送信するという決定）がなされ、そして、オペレーションはステップ２３２へ進む。ステップ２３２において、第１の通信デバイス（例えば、デバイスＢ１０４）は、第３の通信デバイス（例えば、デバイスＡ１０２）にトラフィック・データを送信する。オペレーションは、ステップ２３２からステップ２３６へ進む。しかし、計算された干渉コストが閾値を超えるならば、トラフィック・データを送信しないという決定が第１の通信デバイス（例えば、デバイスＢ１０４）によってなされる。そのような場合には、オペレーションは、ステップ２２２からステップ２３４へ進む。そこでは、第１の通信デバイス（例えば、デバイスＢ１０４）がトラフィック・データを送信することを控える。オペレーションは、ステップ２３４から接続ノード２３６へ進む。接続ノード２３６から、オペレーションはステップ２０４へ進む。そこでは、第１の通信デバイス（例えば、デバイスＢ１０４）が第３の通信デバイス（例えば、デバイスＡ１０２）にトラフィック信号を送信しようと試みる後続するトラフィック・スロットに対応して、他の送信リクエスト信号が第３の通信デバイス（例えば、デバイスＡ１０２）に送信される。いくつかの実施形態においては、アクセスルータ・チャネル推定サブルーチン２０３の繰返しレート及びトラフィック・スロット構造は、接続ノード２３６を通したステップ２０４の複数の繰り返しがアクセス・ルータ１０６から他のパイロット信号を受信する前に繰り返されることができる（そして時々そのように繰り返される）ようにされるものである。それゆえ、いくつかの実施態様では、第１の通信デバイス（例えば、デバイスＢ１０４）は、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をすることができ、そして時々そのように決定する。

図３は、例示的な実施態様に従った例示的な通信デバイス３００の図である。通信デバイス３００は、例えば、ピアツーピアの通信をサポートしており、さらに、図２のフローチャート２００に従った方法を実装しているモバイル無線端末である。通信デバイス３００は、例えば、図１のシステム１００の通信デバイスＢ１０４である。通信デバイス３００は、その上で様々な要素（３０２,３０４）がデータ及び情報を交換し得るバス３０９を介して一緒に接続されるプロセッサ３０２及びメモリ３０４を含む。

通信デバイス３００は、図示されるように、プロセッサ３０２に接続され得る入力モジュール３０６及び出力モジュール３０８を更に含む。しかし、いくつかの実施態様では、入力モジュール３０６及び出力モジュール３０８は、プロセッサ３０２の内部に位置する。入力モジュール３０６は、入力信号を受信することができる。入力モジュール３０６は、入力を受信するために無線受信機及び／又は有線若しくは光入力インタフェースを含むことができ、そしていくつかの実施態様では該無線受信機及び／又は有線若しくは光入力インタフェース含む。出力モジュール３０８は、出力を送信するために無線送信機及び／又は有線若しくは光出力インタフェースを含んでも良く、そしていくつかの実施態様では無線送信機及び／又は有線若しくは光出力インタフェースを含む。プロセッサ３０２は、送信リクエスト・レスポンス信号からサービス品質レベルをリカバーし、前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をするように構成される。プロセッサ３０２は、更に、アクセス・ルータから前記送信リクエスト・レスポンス信号を受信し、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーするように構成される。前記送信リクエスト・レスポンス信号は、第２の通信デバイスから前記アクセス・ルータへ送信されるトラフィック送信リクエストに応答するものである。いくつかの実施形態においては、プロセッサ３０２は、更に、前記アクセス・ルータからパイロット信号を受信し、前記アクセス・ルータと前記通信デバイス３００との間のチャネルの推定を生成し、前記受信された送信リクエスト・レスポンス信号の前記位相を解釈するために、前記生成されたチャネル推定を使用するように構成される。

いくつかの実施形態においては、プロセッサ３０２は、更に、前記リカバーされたＱｏＳレベルを前記トラフィック・データに対応するＱｏＳレベルと比較するように構成される。いくつかの実施形態においては、プロセッサ３０２は、更に、送信リクエスト・レスポンスの前記受信電力レベルにかかわりなく、送信されるべき前記トラフィック・データのＱｏＳレベルが、前記リカバーされたＱｏＳレベルより高い場合に、送信すると決定するように構成される。少なくとも一つの実施態様では、プロセッサ３０２は、更に、送信されるべき前記トラフィック・データのＱｏＳレベルが、前記リカバーされたＱｏＳレベルより低い場合に、前記送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否かを決定するように構成される。少なくともいくつかの実施態様では、プロセッサ３０２は、更に、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をするように、通信デバイス３００を制御するように構成される。プロセッサ３０２は、例えば前記アクセス・ルータから他のパイロット信号を受信する前に、複数の決定をしても良い。

図４は、図３に示される通信デバイスにおいて使用されることができ（そしていくつかの実施態様で使用される）モジュール・アセンブリ４００である。アセンブリ４００中のモジュールは、図３のプロセッサ３０２内にハードウェアで（例えば個々の回路として）実装されることができる。あるいは、該モジュールは、ソフトウェアで実装されても良く、図３に示される通信デバイスのメモリ３０４に記憶されても良い。図３では、単一のプロセッサ（例えば、コンピュータ）として実施態様が示されるが、プロセッサ３０２が１又は複数のプロセッサ（例えば、コンピュータ）として実装され得ることは認識されるべきである。ソフトウェアで実装される場合には、該モジュールは、該プロセッサによって実行されるときに、該モジュールに対応する機能を実装するようにプロセッサ（例えば、コンピュータ）３０２を設定（configure）するコードを含む。モジュール・アセンブリ４００がメモリ３０４に記憶される実施態様では、メモリ３０４は、少なくとも一つのコンピュータ（例えば、プロセッサ３０２）に、該モジュールが対応する機能を実装させるためのコード（例えば、各々のモジュールごとの個々のコード）を含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品である。

完全にハードウェア・ベース又は完全にソフトウェア・ベースのモジュールが使用されても良い。しかし、ソフトウェア及びハードウェア（例えば、実装される回路）モジュールの任意の組み合せが該機能を実装するために使用されても良いことは認識されるべきである。認識されるべきであるように、図４に示されるモジュールは、図２の方法フローチャート２００中に示される対応するステップの機能を実行するように、通信デバイス３００又はその中の要素（例えば、プロセッサ３０２）を制御及び／又は設定する。

図４中に説明されるように、モジュール・アセンブリ４００は、第３の通信デバイスへ送信リクエスト信号を送信するためのモジュール４０２、第３の通信デバイスから送信リクエスト・レスポンスを受信するためのモジュール４０４、アクセス・ルータから送信リクエスト・レスポンス信号を受信するためのモジュール４０６、アクセス・ルータからパイロット信号を受信するためのモジュール４０８、アクセス・ルータと第１の通信デバイスとの間のチャネルの推定を生成するためのモジュール４１０、アクセス・ルータから受信された送信リクエスト・レスポンス信号からサービス品質（ＱｏＳ）レベルをリカバーするためのモジュール４１２、及び、リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定を行うためのモジュール４１６を含む。いくつかの実施形態においては、モジュール４１２はまた、アクセスルータからの送信リクエスト・レスポンス信号の位相からＱｏＳレベルをリカバーするためのモジュール４１３、及び、送信リクエスト・レスポンス信号の位相を解釈するために、生成された推定を使用するためのモジュール４１４を含む。

少なくとも一つの実施態様において、モジュール４１６は、リカバーされたサービス品質レベルを、トラフィック・データに対応するサービス品質レベルと比較するためのモジュール４１８、送信されるべきトラフィック・データのサービス品質レベルが、リカバーされたサービス品質レベルより高い場合に、アクセス・ルータからの送信リクエスト・レスポンス信号の受信電力レベルにかかわらずに、送信すると決定するためのモジュール４２０、及び、送信されるトラフィック・データのサービス品質レベルが、リカバーされたサービス品質レベルより低い場合に、アクセス・ルータからの送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否かを決定するためのモジュール４２２を含む。モジュール４１６はまた、アクセス・ルータからの送信リクエスト・レスポンスの電力レベルを測定するためのモジュール４２４、アクセス・ルータからのリクエスト・レスポンスの測定電力に基づいて、アクセス・ルータに対する干渉コストを計算するためのモジュール４２６、干渉コストを、送信イールディングを判定するための閾値と比較するためのモジュール４２８、及び、モジュール４２８によりなされる比較に基づいて、送信するか否かを決定するためのモジュール４３０とのうちの１又は複数を含んでも良い。

モジュール・アセンブリ４００は、更に、トラフィック・データを送信するためのモジュール４３２、及び、例えばアクセス・ルータから他のパイロット信号を受信する前に、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定を行うためのモジュール４３４を含む。

図５は、例示的な実施態様に従った第１の通信デバイス（例えば、図１の通信デバイスＡ１０２）を操作する例示的な方法のフローチャート５００である。例示的な方法のオペレーションは、ステップ５０２において開始する。そこでは、第１の通信デバイス（例えば、デバイスＡ１０２）が、パワーオンされ初期化される。オペレーションは、開始ステップ５０２からステップ５０４へ進む。いくつかの実施形態において、第１の通信デバイス（例えば、デバイスＡ１０２）はまた、フローチャート５００の様々な他のステップと並行して、チャネル推定サブルーチン５０３を実行する。

チャネル推定サブルーチン５０３は、第１の通信デバイス（例えば、デバイスＡ１０２）とアクセス・ルータ（例えば、アクセス・ルータ１０６）との間のチャネルに関するチャネル推定方法を実装する。サブルーチンは、フローチャート５００における他のステップが実行されるレートとは異なるレート（例えば、より遅いレート）で実行されるステップ５０５，５０７及び５０９を含む。例えば、サブルーチン５０３の実行は、第１の通信デバイス（例えば、デバイスＡ１０２）がそこにおいて送信リクエスト・レスポンスを（例えば、第３の通信デバイス（例えば、デバイスＢ１０４）に）送信するか否かの決定をし得る複数のトラフィック・スロットを含む期間の後、繰り返されても良い。

ステップ５０４において、第１の通信デバイス（例えば、デバイスＡ１０２）は、第３の通信デバイス（例えば、通信デバイスＢ１０４）から、第２の送信リクエスト信号（例えば、送信リクエスト信号１２４）を受信する。オペレーションは、ステップ５０４からステップ５０６へ進む。そこでは、第１の通信デバイス（例えば、デバイスＡ１０２）がアクセス・ルータ（例えば、アクセス・ルータ１０６）から第１の送信リクエスト・レスポンス信号（例えば、リクエスト・レスポンス信号１２２）を受信する。第１の送信リクエスト・レスポンス信号（例えば、信号１２２）は、第１のトラフィック送信リクエスト信号（例えば、送信リクエスト信号１２０）に応答するものであり、前記第１のトラフィック送信リクエスト信号は、第２の通信デバイス（例えば、通信デバイスＣ１０８）からアクセス・ルータ１０６へ送信される。いくつかの実施形態においては、送信リクエスト・レスポンス信号（例えば、信号１２２）は、シングルトーン信号である。図２の例の初めに述べたように、いくつかの実施態様では、送信リクエスト・レスポンス信号（例えば、信号１２２の位相）の位相は、ＱｏＳ情報を伝え得る。いくつかの実施形態においては、ＱｏＳ情報は、対応する送信リクエストがそのためになされたトラフィック・データの送信のためのトラフィック送信プライオリティーを伝達する（例えば、該対応する送信リクエストは、通信デバイスＣ１０８によってなされた送信リクエスト１２０である）。オペレーションは、ステップ５０６からステップ５０８へ進む。

これからサブルーチン５０３（それはステップ５０５，５０７及び５０９を含む）が説明される。ステップ５０５において、第１の通信デバイス（例えば、デバイスＡ１０２）は、アクセス・ルータ１０６からパイロット信号（例えば、パイロット信号１２１）を受信する。オペレーションは、ステップ５０５からステップ５０７へ進む。そこでは、第１の通信デバイス（例えば、デバイスＡ１０２）がアクセス・ルータ１０６と第１の通信デバイス（例えば、デバイスＡ１０２）との間のチャネルのチャネル推定を生成する。例示的な実施態様に従って、生成されたチャネル推定は、送信リクエスト・レスポンス信号１２２の位相を解釈するために、第１の通信デバイス（例えば、デバイスＡ１０２）によって、時々使用される。矢印線５１１は、生成されたチャネル推定が、第１の通信デバイス（例えば、デバイスＡ１０２）に利用可能であり、ステップ５１０で使用され得ることを表す。オペレーションは、ステップ５０７からリターン５０９へ進む。そこから、該オペレーションは、ステップ５０５へ進む。前に述べたように、サブルーチン５０３は、例えば予め定められたスケジュールに従って、特定の時間の後、繰り返されても良く、そして時々そのように繰り返される。

ステップ５０８において、第１の通信デバイス（例えば、デバイスＡ１０２）は、第１の送信リクエスト・レスポンス信号（例えば、信号１２２）から、第１のＱｏＳレベルをリカバーする。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＡ１０２）は、第１の送信リクエスト・レスポンス信号の位相から（例えば、信号１２２の位相から）、ＱｏＳレベルをリカバーする。いくつかの実施形態においては、ステップ５０８において、第１の通信デバイス（例えば、デバイスＡ１０２）はまた、ＱｏＳレベルをリカバーすることの一部として、サブステップ５１０を実行する。サブステップ５１０において、第１の通信デバイス（例えば、デバイスＡ１０２）は、受信された第１の送信リクエスト・レスポンス信号の位相（例えば、信号１２２の位相）を解釈するために、生成されたチャネル推定（例えば、ステップ５０７で生成された）を使用する。位相を解釈するための生成されたチャネル推定の使用は、図２の例の初めに詳しく述べたので、再度繰り返さないことにする。

オペレーションは、ステップ５０８からステップ５１２へ進む。ここでは、第１の通信デバイス（例えば、デバイスＡ１０２）は、リカバーされたＱｏＳレベルに基づき、第３の通信デバイス（例えば、デバイスＢ１０４）からの第２のトラフィック送信リクエスト１２４に応答して、送信リクエスト・レスポンス（例えば、リクエスト・レスポンス１２６）を送信するか否か決定する。いくつかの実施形態においては、決定ステップ５１２の一部としてステップ５１２の様々なサブステップ５１４，５１６，５１８，５２０及び５２２が実行される。サブステップ５１４において、第１のデバイス（例えば、デバイスＡ１０２）は、リカバーされた第１のＱｏＳレベルを、第１の通信デバイス（例えば、デバイスＡ１０２）と第３の通信デバイス（例えば、デバイスＢ１０４）との間のコネクションに対応する第２のＱｏＳレベルと比較する。例えば、第１の通信デバイス（例えば、デバイスＡ１０２）と第３の通信デバイス（例えば、デバイスＢ１０４）との間のコネクションに関連するコネクション識別子が存在し得る。いくつかの実施形態においては、そのようなコネクション識別子に関連するＱｏＳレベルが存在する。いくつかのそのような実施態様では、ＱｏＳレベルは、例えば、第３の通信デバイス（例えば、デバイスＢ１０４）から第１の通信デバイス（例えば、デバイスＡ１０２）へ送信されるべきトラフィックのためのトラフィック送信プライオリティー・レベルである。それゆえ、少なくとも一つの実施態様では、ステップ５１４において、比較は、リカバーされたＱｏＳレベルにより示されるトラフィック送信プライオリティーと、第３の通信デバイス（例えば、デバイスＢ１０４）から第１の通信デバイス（例えば、デバイスＡ１０２）へ送信されるトラフィック・データの送信プライオリティーとの間の比較である。オペレーションは、サブステップ５１４からサブステップ５１６へ進む。

サブステップ５１６において、第１の通信デバイス（例えば、デバイスＡ１０２）は、サブステップ５１４におけるＱｏＳレベルの比較の結果に基づいて、どのように進むかについて決定をする。第１の通信デバイス（例えば、デバイスＡ１０２）と第３の通信デバイス（例えば、デバイスＢ１０４）との間のコネクションに対応する第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより大きいならば、オペレーションは、サブステップ５１６からサブステップ５１８へ進む。サブステップ５１８において、第１の通信デバイス（例えば、デバイスＡ１０２）は、第３の通信デバイス（例えば、デバイスＢ１０４）に送信リクエスト・レスポンス信号（例えば、信号１２６）を送信することに決定する。そのような場合には、オペレーションはサブステップ５１８からステップ５２４へ進む。しかし、リカバーされた第１のＱｏＳレベルが、第１の通信デバイス（例えば、デバイスＡ１０２）と第３の通信デバイス（例えば、デバイスＢ１０４）との間のコネクションに対応する第２のＱｏＳレベルより大きいならば、オペレーションは、サブステップ５１６からサブステップ５２０へ進む。サブステップ５２０において、第１の通信デバイス（例えば、デバイスＡ１０２）は、例えば、第２の通信（例えば、デバイスＣ１０８）からアクセス・ルータ１０６への第１の送信リクエスト信号（例えば、信号１２０）の受信電力に基づいて及び第３の通信デバイス（例えば、デバイスＢ１０４）からの第２の送信リクエスト信号（例えば、信号１２４）の受信電力レベルに基づいて、チャネル品質推定（例えば、ＳＩＲ）を生成する。例えば、ＳＩＲレベルは、信号電力の値として、第２の送信リクエストの受信電力（例えば、デバイスＢ１０４からの信号１２４の測定された受信電力）を、そして、干渉信号電力の値として、第１の送信リクエスト信号の受信電力レベル（例えば、信号１２０の測定された受信電力）を使用して計算される。

いくつかの実施形態においては、サブステップ５２０において生成された閾値を上回るチャネル品質推定は、第２の通信デバイス（例えば、デバイスＣ１０８）からアクセス・ルータ１０６へ送信され得るより高いプライオリティーのトラフィック・データが、第３の通信デバイス（例えば、デバイスＢ１０４）からのトラフィック・データの受信時及び／又はリカバー時に、第１の通信デバイス（例えば、デバイスＡ１０２）に対して容認できないレベルの干渉を引き起こすと予期されるであろうことのインジケーションであり得る。第１の通信デバイス（例えば、デバイスＡ１０２）は、ステップ５１４から、第２の通信デバイス（例えば、デバイスＣ１０８）に対応するトラフィック・データが、それ自身のコネクションに対応するトラフィック・データより高い送信プライオリティーを有することを知っている。いくつかの実施形態において、これは、第２の通信デバイス（例えば、デバイスＣ）が、アクセス・ルータ１０６にトラフィック・データを送信する可能性が高い（more likely to）ことを意味する（implies）。いくつかのそのようなシナリオでは、第１の通信デバイス（例えば、デバイスＡ１０２）は、送信リクエスト・レスポンス（例えば、信号１２６）を送信することを控える。そして、それは、その送信リクエストの拒否（例えば、リクエスト信号１２４のリクエストの拒否）を伝える。いくつかの実施形態においては、そのようなシナリオにおいて、第１の通信デバイス（例えば、デバイスＡ１０２）は、それがリクエスト送信の開始を許可するならば、トラフィック・データのプアな受信及び／又はプアなリカバリーを有すると予期されるので、送信リクエスト・レスポンスを送信しないことに決定した。オペレーションは、サブステップ５２０からサブステップ５２２へ進む。

第２のＱｏＳレベルがリカバーされた第１のＱｏＳレベルより低い場合に、サブステップ５２２において、サブステップ５２０の生成されたチャネル品質推定に基づいて、第３の通信デバイス（例えば、デバイスＢ１０４）に送信リクエスト・レスポンス（例えば、信号１２６）を送信するか否かの決定がなされる。生成されたチャネル品質推定に基づいてなされた決定に応じて、オペレーションはステップ５２４又はステップ５２６へ進む。いくつかの実施形態において、決定ステップ５２２は、生成されたチャネル品質推定を閾値レベルと比較することと、そのような比較の結果に基づいて進行することを決定することを含む。第３の通信デバイス（例えば、デバイスＢ１０４）からトラフィック・データを受信する際に、第２の通信デバイス（例えば、デバイスＣ１０８）からアクセス・ルータ１０６へのトラフィックの送信が、第１の通信デバイス（例えば、デバイスＡ１０２）に重要な（substantial）干渉問題を引き起こすと予期されないことを示す閾値レベルを、生成されたチャネル品質が下回るならば、いくつかの実施態様において、第１の通信デバイス（例えば、デバイスＡ１０２）は、第３の通信デバイス（例えば、デバイスＢ１０４）にリクエスト・レスポンス信号（例えば、信号１２６）を送信することに決定する。そのような場合には、該オペレーションはステップ５２４へ進み、ここでは、第１の通信デバイス（例えば、デバイスＡ１０２）は、第３の通信デバイス（例えば、デバイスＢ１０４）に送信リクエスト・レスポンス信号（例えば、信号１２６）を送信する。オペレーションは、ステップ５２４からステップ５２８へ進む。

他方、生成されたチャネル品質推定が高い（例えば、閾値を上回る）ならば、第１の通信デバイス（例えば、デバイスＡ１０２）は、いくつかの実施態様において、第３の通信デバイス（例えば、デバイスＢ１０４）にリクエスト・レスポンス信号（例えば、信号１２６）を送信しないことに決定する。そのような場合には、オペレーションは、サブステップ５２２を含むステップ５１２から、ステップ５２６へ進む。ステップ５２６において、第１の通信デバイス（例えば、デバイスＡ１０２）は、第３の通信デバイス（例えば、デバイスＢ１０４）へリクエスト・レスポンス（例えば、信号１２６）を送信することを控える。オペレーションは、ステップ５２６からステップ５２８へ進む。ステップ５２８において、該オペレーションはステップ５０４に戻り、そして、ステップ５０４〜５１２が、例えばアクセス・ルータ１０６から他のパイロット信号を受信する前に、繰り返されても良く、また、時々そのように繰り返され、しかるべく、第１の通信デバイス（例えば、デバイスＡ１０２）は、他のトラフィック・スロットに対応するリクエスト・レスポンスを送信することを送信し又は送信することを控える。

図６は、例示的な実施態様に従った例示的な第１の通信デバイス６００の図である。第１の通信デバイス６００は、例えば、ピアツーピアの通信をサポートしており、さらに、図５のフローチャート５００に従った方法を実装しているモバイル無線端末である。第１の通信デバイス６００は、例えば、図１のシステム１００の通信デバイスＡ１０２である。通信デバイス６００は、その上で様々な要素（６０２,６０４）がデータ及び情報を交換し得るバス６０９を介して一緒に接続されるプロセッサ６０２及びメモリ６０４を含む。通信デバイス６００は、図示されるように、プロセッサ６０２に接続する得る入力モジュール６０６及び出力モジュール６０８を更に含む。しかし、いくつかの実施態様では、入力モジュール６０６及び出力モジュール６０８は、プロセッサ６０２の内部に位置する。入力モジュール６０６は、入力信号を受信することができる。入力モジュール６０６は、入力を受信するために無線受信機及び／又は有線若しくは光入力インタフェースを含むことができ、そしていくつかの実施態様では該無線受信機及び／又は有線若しくは光入力インタフェース含む。出力モジュール６０８は、出力を送信するために無線送信機及び／又は有線若しくは光出力インタフェースを含んでも良く、そしていくつかの実施態様では無線送信機及び／又は有線若しくは光出力インタフェースを含む。

プロセッサ６０２は、第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーし、前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して送信リクエスト・レスポンス信号を送信するか否かの決定をするように構成される。いくつかの実施形態においては、プロセッサ６０２は、更に、アクセス・ルータから前記第１の送信リクエスト・レスポンス信号を受信するように構成され、前記第１の送信リクエスト・レスポンス信号は、前記第１のトラフィック送信リクエスト信号に応答するものであり、前記第１のトラフィック送信リクエスト信号は、第２の通信デバイスから前記アクセス・ルータへ送信される。いくつかの実施形態においては、プロセッサ６０２は、更に、前記アクセス・ルータからパイロット信号を受信し、前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイス６００との間のチャネルの推定を生成し、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するように構成される。

いくつかの実施形態においては、プロセッサ６０２は、更に、前記リカバーされた第１のサービス品質レベルを、前記第１の通信デバイスと前記第３の通信デバイス６００との間のコネクションに対応する第２のサービス品質レベルと比較するように構成される。いくつかのそのような実施形態においては、プロセッサ６０２は、更に、前記第３の通信デバイスと前記第１の通信デバイスとの間の前記コネクションに対応する前記第２のＱｏＳレベルが、前記リカバーされた第１のＱｏＳレベルより高い場合に、送信すると決定する構成される。

少なくとも一つの実施態様では、プロセッサ６０２は、更に、前記第２のトラフィック送信リクエスト信号の受信電力に基づいて及び前記第１のトラフィック送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成し、前記第２のＱｏＳレベルが、前記リカバーされた第１のＱｏＳより低い場合に、前記生成されたチャネル品質推定に基づいて、送信するか否かを決定するように構成される。少なくともいくつかの実施態様において、プロセッサ６０２は、更に、例えばアクセス・ルータから他のパイロット信号を受信する前に、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をするように構成される。

図７は、図６に示される通信デバイスにおいて使用されることができ（そしていくつかの実施態様で使用される）モジュール・アセンブリ７００である。アセンブリ７００中のモジュールは、図６のプロセッサ６０２内にハードウェアで（例えば個々の回路として）実装されることができる。あるいは、該モジュールは、ソフトウェアで実装されても良く、図６に示される通信デバイスのメモリ６０４に記憶されても良い。図６では、単一のプロセッサ（例えば、コンピュータ）として実施態様が示されるが、プロセッサ６０２が１又は複数のプロセッサ（例えば、コンピュータ）として実装され得ることは認識されるべきである。ソフトウェアで実装される場合には、該モジュールは、該プロセッサによって実行されるときに、該モジュールに対応する機能を実装するようにプロセッサ（例えば、コンピュータ）６０２を設定するコードを含む。モジュール・アセンブリ７００がメモリ６０４に記憶される実施態様では、メモリ６０４は、少なくとも一つのコンピュータ（例えば、プロセッサ６０２）に、該モジュールが対応する機能を実装させるためのコード（例えば、各々のモジュールごとの個々のコード）を含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品である。

完全にハードウェア・ベース又は完全にソフトウェア・ベースのモジュールが使用されても良い。しかし、ソフトウェア及びハードウェア（例えば、実装される回路）モジュールの任意の組み合せが該機能を実装するために使用されても良いことは認識されるべきである。認識されるべきであるように、図７に示されるモジュールは、図５の方法フローチャート５００中に示される対応するステップの機能を実行するように、通信デバイス６００又はその中の要素（例えばプロセッサ６０２）を制御及び／又は設定する。

図７に示されるように、モジュール・アセンブリ７００は、第３の通信デバイスから第２のトラフィック送信リクエストを受信するためのモジュール７０２、アクセス・ルータから第１の送信リクエスト・レスポンス信号を受信するためのモジュール７０４（該第１の送信リクエスト・レスポンスは第１のトラフィック送信リクエスト信号に応答するものであり、該第１のトラフィック送信リクエスト信号は第２の通信デバイスから該アクセス・ルータへ送信される）、アクセス・ルータからパイロット信号を受信するためのモジュール７０６、パイロット信号に基づいて、アクセス・ルータと第１の通信デバイスとの間のチャネルの推定を生成するためのモジュール７０８、第１の送信リクエスト・レスポンス信号から第１のサービス品質（ＱｏＳ）レベルをリカバーするためのモジュール７１０を含み、それはまたいくつかの実施態様において、受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、生成されたチャネル推定を使用するためのモジュール７１２を含む。モジュール・アセンブリ７００は、更に、リカバーされた第１のＱｏＳレベルに基づいて、第３の通信デバイスからの第２の送信リクエスト信号に応答して送信リクエスト・レスポンス信号を送信するか否か決定するためのモジュール７１４を含む。

少なくとも一つの実施態様において、モジュール７１４は、リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較するためのモジュール７１６（該第２のサービス品質レベルは、該第１の通信デバイスと該第３の通信デバイスとの間のコネクションに対応する）、第１の通信デバイスと第３の通信デバイスとの間でのネクションに対応する第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより高い場合に、送信リクエスト・レスポンス信号を送信することに決定するためのモジュール７１８、第２のトラフィック送信リクエスト信号の受信電力に基づいて及び第１のトラフィック送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成するためのモジュール７２０、及び、第１の通信デバイスと第３の通信デバイスとの間のコネクションに対応する第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより低い場合に、生成されたチャネル品質推定に基づいて、送信するか否か決定するためのモジュール７２２を含む。

モジュール・アセンブリ７００は、更に、送信リクエスト・レスポンス信号を送信するためのモジュール７２４、及び、例えばアクセス・ルータから他のパイロット信号を受信する前に、複数の異なる送信タイム・スロットにおいて送信リクエスト・レスポンス信号を送信するか否かについて複数の決定を行うためのモジュール７２６を含む。

図８は、例示的な実施態様に従った例示的なピアツーピア通信ネットワーク８００（例えば、ローカル領域で実装されるアドホックなピアツーピア通信ネットワーク）を示す。図８は、アクセス・ルータ８０６と、例えばアクセス端末である通信デバイスＣ８０８との間のダウンリンク通信に関係する例示的な実施態様に従って、いくつかの特徴を示す。

例示的な通信ネットワーク８００は、複数のピアツーピアの無線通信デバイス（通信デバイスＡ８０２,通信デバイスＢ８０４,通信デバイスＣ８０８,通信デバイス１８１０，．．．，通信デバイスＮ８１２）及びアクセス・ルータ８０６（例えば、基地局）を含む。通信ネットワーク８００では一つのアクセス・ルータが示されたが、通信ネットワークがいくつかのアクセス・ルータを含んでも良く、そして時々含むことは、認識されるべきである。無線通信デバイス（８０２，８０４，８０８，８１０，．．．，８１２）は、ピア間の様々なシグナリング（例えば、ピア発見信号、送信リクエスト信号、送信リクエスト・レスポンス信号など）と、データ伝送とをサポートする。ピアツーピア通信デバイスのいくつか（例えば、通信デバイス１８１０）はまた、無線通信インタフェースに加えて、他のノード及び／又はインターネットにピアツーピア通信デバイスを接続させる有線インタフェースを含む。ピアツーピア通信デバイスのいくつかは、モバイル通信デバイス（例えば、ハンドヘルド型モバイル通信デバイス）である。

一つの例示的な実施態様に従って、アクセス・ルータ８０６は、ネットワーク中のピアツーピア・デバイス（例えば、通信デバイスＣ８０８）に送信リクエスト信号８４０を送信する。アクセス・ルータ８０６からの送信リクエスト信号８４０の位相は、ＱｏＳ情報（例えば、送信プライオリティーを伝えているＱｏＳレベル）を伝える。いくつかの実施形態において、送信リクエスト信号８４０は、シングルトーン信号、すなわち、シングルＯＦＤＭトーンを使用して通信される信号である。例えば、いくつかのそのような実施態様において、シングルＯＦＤＭ送信タイムインターバル（例えば、シングルトーン信号）の間に通信されるそのようなシングルトーン信号は、一つのＯＦＤＭトーン−シンボルを使用して通信される。いくつかの実施形態において、タイミング／周波数構造における異なるセットのＯＦＤＭトーン−シンボルは、異なる信号（例えば、リクエスト信号、リクエスト・レスポンス信号、パイロット信号、ビーコン信号など）に関連する。

いくつかの実施形態において、送信リクエスト信号８４０は、シングルトーンを使用して通信される。いくつかのそのような実施態様では、送信レスポンス信号８４０の位相は、サービス品質（ＱｏＳ）レベル（例えば、送信プライオリティー）を伝える。例示的な実施態様に従って、無線通信デバイス（８０２，８０４，８０８，８１０，．．．，８１２）は、アクセス・ルータ８０６を含むシステム８００中のアクセス・ルータを知っている。いくつかのそのような実施形態において、通信デバイス（８０２，８０４，８０８，８１０，．．．，８１２）は、通信デバイス（８０２，８０４，８０８，８１０，．．．，８１２）が現在検出（例えば、ヒア）できるアクセス・ルータ８０６を含むネットワーク８００中のアクセス・ルータのうちの１又は複数へのチャネルをトラッキングする。例えば、通信デバイスＡ８０２がアクセス・ルータ８０６を検出でき、アクセス・ルータ８０６とそれ自身との間のチャネルをトラッキングしていると考える。更に、通信デバイスＢ８０４がアクセス・ルータ８０６を検出でき、アクセス・ルータ８０６とそのデバイス自身との間のチャネルをトラッキングしていると考える。更に、通信デバイスＡ８０２及び通信デバイスＢ８０４はまた、アクセス・ルータ８０６から通信デバイスＣ８０８へ送信される送信リクエスト信号８４０を受信すると考える。チャネル状態のトラッキングを使用して、通信デバイスＡ８０２及び通信デバイスＢ８０４は、送信リクエスト信号８４０で伝えられる情報、例えば、送信リクエスト信号８４０の位相で伝えられるＱｏＳレベルの情報をリカバーすることができる。

いくつかの実施形態においては、通信デバイスＣ８０８が送信リクエスト８４０に同意（acquiesces）するならば、通信デバイスＣ８０８は、送信リクエスト・レスポンス信号８４２を送信することによって、アクセス・ルータ８０６に応答しても良く、そして時々そのように応答する。

図８で示すように、ピアツーピア通信デバイスＡ８０２は、ピアツーピア通信デバイスＢ８０４に対して、データ（例えば、トラフィック・データ）を送信しようと試みる。それゆえ、通信デバイスＡ８０２は、通信デバイスＢ８０４に、送信リクエスト信号８４４を送信する。いくつかの実施形態において、通信デバイスＢ８０４が信号８４４のリクエストに同意するならば、通信デバイスＢ８０４は通信デバイスＡ８０２へリクエスト・レスポンス信号８４６を送信する。いくつかの実施形態において、リクエスト・レスポンス信号８４６は、通信デバイスＢ８０４が通信デバイスＡ８０２からトラフィック・データを受信することに同意できる（agreeable）ことを、通信デバイスＡ８０２に伝える。いくつかの実施形態において、通信デバイスＢ８０４は、１又は複数の条件が満たされるか否かに基づいて、送信リクエスト信号８４４に応答して送信リクエスト信号８４６を送信するか否かを決定する。例えば、一つの例示的な実施態様において、通信デバイスＢ８０４は、受信された送信リクエスト信号８４０の位相から、ＱｏＳレベルをリカバーする。アクセス・ルータ８０６から通信デバイスＣ８０８へ通信されるべきトラフィック・データが、通信デバイスＡ８０２から通信デバイスＢ８０４へ通信されるべきトラフィックに関連するプライオリティーより高いプライオリティーを有することを、信号８４０からリカバーされたＱｏＳレベルが示すならば、通信デバイスＢ８０４は、リクエスト・レスポンス信号８４６を送信しないことに決定しても良く、そして時々そのように決定する。

いくつかの実施形態においては、リクエスト・レスポンス信号８４６を送信するか否かの決定、他のコネクションに対応する意図されたより高いプライオリティーのトラフィック送信の検出に基づく基準に加えて、更なる基準に基づく。例えば、通信デバイスＢ８０４が、それ自身のコネクション上のトラフィックに関連するＱｏＳレベルはアクセス・ルータ８０６からデバイスＣ８０８への意図されたトラフィックに関連するＱｏＳレベルより高いプライオリティーを示さないと判定すると考える。この判定に続いて、いくつかの実施態様では、通信デバイスＢ８０４は、チャネル品質推定（例えば、ＳＩＲ）に基づいて、リクエスト・レスポンス信号８４６を送信するか否かについて決定する。チャネル品質は、例えばアクセス・ルータ８０６からのリクエスト信号８４０の受信電力及び通信デバイスＡ８０２からのリクエスト信号８４４の受信電力を使用して、生成される。

いくつかの実施形態において、リクエスト・レスポンス８４６が、通信デバイスＢ８０４により送信され、かつ、通信デバイスＡ８０２により受信される場合には、通信デバイスＡ８０２は、１又は複数の条件が満たされるか否かに基づいて、通信デバイスＢ８０４にトラフィック・データを送信するか否かを決定する。一つの例示的な実施態様において、通信デバイスＡ８０２は、受信されたリクエスト信号８４０の位相から、ＱｏＳレベルをリカバーする。いくつかのそのような実施態様において、通信デバイスＡ８０２は、受信されたリクエスト信号８４０の位相を解釈するために（例えば、位相からＱｏＳレベルをリカバーする）、通信デバイスＡ８０２とアクセス・ルータ８０６との間のチャネルについて生成されたチャネル推定を使用する。チャネル推定は、時々、アクセス・ルータ８０６から受信されるパイロット信号８３０を使用して、通信デバイスＡ８０２により生成される。通信デバイスＡ８０２は、通信デバイスＡ８０２が通信デバイスＢ８０４に送信することを望むトラフィック・データの送信プライオリティー・レベルを知っている。いくつかの実施態様において、アクセス・ルータ８０６から通信デバイスＣ８０８へ通信されるべきトラフィック・データが、それ自身の意図されたトラフィック送信に関連するプライオリティーと比較して、より高いプライオリティー（リカバーされたＱｏＳレベルにより示される）を有することを、リカバーされたＱｏＳレベルが示すならば、通信デバイスＡ８０２は、イールディングすること、すなわち、現在の送信スロットにおいて通信デバイスＢ８０４にそのトラフィック・データを送信しないことに決定しても良く、そして時々そのように決定する。いくつかの実施形態において、通信デバイスＡ８０２は、予め定められた基準に基づいて、デバイスＢ８０４にそのトラフィック・データを送信するか否か決定する。いくつかの実施形態において、通信デバイスＡ８０２による送信機イールディング決定は、アクセス・ルータ８０６から通信デバイスＣ８０８へのより高いプライオリティーのトラフィック・データの通信を容易にするためになされる。それゆえ、通信デバイスＡ８０２の送信機イールディングは、アクセス・ルータ８０６から通信デバイスＣ８０８へのトラフィックが、同一のトラフィック・エアーリンク資源（例えば、同一のトラフィック・セグメント）における通信デバイスＡ８０２と通信デバイスＢ８０４との間のトラフィック送信からの干渉なしで起こることを可能にする。

図９は、例示的な実施態様に従った第１の通信デバイス（例えば、図８の通信デバイスＡ８０２）を操作する例示的な方法のフローチャート９００である。例示的な方法のオペレーションは、ステップ９０２において開始する。そこでは、第１の通信（例えば、デバイスＡ８０２）が、パワーオンされ初期化される。例示的な実施態様に従って、第１の通信デバイス（例えば、デバイスＡ８０２）が、そこにおいて第３の通信デバイス（例えば、通信デバイスＢ８０４）に送信しようと試みる各々のトラフィック・スロットごとに、以下に記すように、フローチャート９００における様々なステップが実行される。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＡ８０２）はまた、フローチャート９００の様々な他のステップと並行して、第１の通信デバイスＡ８０２とアクセス・ルータ８０６との間のチャネルに関するにチャネル推定を生成するために、チャネル推定サブルーチン９０３を実行する。

チャネル推定サブルーチン９０３は、例示的な方法を実装する通信デバイス（それはこの例で通信デバイスＡ８０２である）とアクセス・ルータ８０６との間のチャネルに関するチャネル推定方法を実装する。サブルーチンは、フローチャート９００における他のステップが実行されるレートとは異なるレート（例えば、より遅いレート）で実行されるステップ９０５，９０７及び９０９を含む。例えば、サブルーチン９０３の実行は、第１の通信デバイスＡ８０２がそこにおいてトラフィック・データを第３の通信デバイス（例えば、デバイスＢ８０４）に送信しようと試みる複数のトラフィック・スロットを含む期間の後、繰り返されても良い。

ステップ９０５において、通信デバイスＡ８０２は、アクセス・ルータ８０６から、パイロット信号（例えば、パイロット信号８３０）を受信する。オペレーションは、ステップ９０５からステップ９０７へ進む。そこでは、第１の通信デバイスＡ８０２がアクセス・ルータ８０６とデバイスＡ８０２との間のチャネルのチャネル推定を生成する。例示的な実施態様に従って、生成されたチャネル推定は、送信レスポンス信号８４０の位相を解釈するために、第１の通信デバイスＡ８０２によって、時々使用される。矢印線９１１は、生成されたチャネル推定が、デバイスＡ８０２に利用可能であり、ステップ９１０で使用され得ることを表す。オペレーションは、ステップ９０７からリターン９０９へ進む。そこから、該オペレーションは、ステップ９０５へ進む。前に述べたように、サブルーチン９０３は、例えば実装されたタイミング構造に従って、所定の時間の後、繰り返されても良く、そして時々そのように繰り返される。

オペレーションは、開始ステップ９０２からステップ９０４へ進む。ステップ９０４において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第３の通信デバイス（例えば、通信デバイスＢ８０４）に、送信リクエスト信号（例えば、送信リクエスト信号８４４）を送信する。オペレーションは、ステップ９０４からステップ９０６へ進む。そこでは、第１の通信デバイス（例えば、デバイスＡ８０２）が第３の通信デバイス（例えば、デバイスＢ８０４）から送信リクエスト・レスポンス信号（例えば、リクエスト・レスポンス信号８４６）を受信する。リクエスト・レスポンス信号８４６は、第１の通信デバイス（例えば、デバイスＡ８０２）から第３の通信デバイス（例えば、デバイスＢ８０４）へ送信される送信リクエスト信号８４４に応答するものである。オペレーションは、ステップ９０６からステップ９０８へ進む。

ステップ９０８において、第１の通信（例えば、デバイスＡ８０２）は、アクセス・ルータ（例えば、アクセス・ルータ８０６）から、第１の送信リクエスト信号（例えば、送信リクエスト信号８４０）を受信する。送信リクエスト信号８４０は、アクセス・ルータ８０６から第２の通信デバイス（例えば、図８の通信デバイスＣ８０８）へトラフィック・データを送信するためのリクエスト信号である。いくつかの実施形態においては、アクセス・ルータ８０６からの送信リクエスト信号８４０は、シングルトーン信号である。いくつかの実施形態において、送信リクエスト信号８４０の位相は、ＱｏＳ情報を伝える。いくつかの実施形態においては、ＱｏＳ情報は、アクセス・ルータ８０６から、例えばトラフィック・スロットに対応する第２の通信デバイス（例えば、デバイスＣ１０８）への意図されたトラフィック・データに対応するトラフィック送信プライオリティーを伝達する。オペレーションは、ステップ９０８からステップ９１０へ進む。

ステップ９１０において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第２の通信デバイス（例えば、デバイスＣ８０８）に向けられた第１の送信リクエスト信号（例えば、信号８４０）から、第１のＱｏＳレベルをリカバーする。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＡ８０２）はまた、ステップ９１０におけるＱｏＳレベルのリカバーの一部として、サブステップ９１１及び９１２を実行する。サブステップ９１１において、ＱｏＳレベルは、受信された第１の送信リクエスト信号（例えば、送信リクエスト信号８４０）の位相からリカバーされる。サブステップ９１２において、第１の通信デバイスは、受信された第１の送信リクエスト信号の位相（例えば、信号８４０の位相）を解釈するために、（例えば、ステップ２０７からの）生成されたチャネル推定を使用する。第１の通信デバイス（例えば、デバイスＡ８０２）は、いくつかの実施態様において、受信された第１の送信リクエスト信号（例えば、信号８４０）の位相を正確に解読（properly decode）するために、チャネルにより引き起こされる位相及び／又は振幅の歪みを補償する。それゆえ、いくつかの実施態様では、第１の通信デバイス（例えば、デバイスＡ８０２）は、チャネル推定を生成し、続いて、アクセス・ルータからの信号（例えば、送信リクエスト信号８４０）の位相を解読するときに、チャネル状態を調整するために、該生成されたチャネル推定を使用する。チャネル推定情報の使用は、送信リクエスト信号８４０の位相の効果的な読み取り（reading）及び信号８４０において伝えられる該ＱｏＳレベルの第１の通信デバイス（例えば、デバイスＡ８０２）による回復（retrieval）を容易にする。オペレーションは、ステップ９１０からステップ９１４へ進む。

ステップ９１４において、第１の通信デバイス（例えば、デバイスＡ８０２）は、リカバーされた第１のＱｏＳレベルに基づいて、そのトラフィック・データを第３の通信デバイス（例えば、デバイスＢ８０４）に送信する否か決定する。いくつかの実施形態においては、ステップ９１４は、１又は複数の様々なサブステップ９１６，９１８，９２０，９２２及び９２４を含む。サブステップ９１６において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第１の送信リクエスト信号（例えば、信号８４０）からリカバーされた第１のＱｏＳレベルを、第１の通信デバイス（例えば、デバイスＡ８０２）から第３の通信デバイス（例えば、デバイスＢ８０４）へ送信されるトラフィック・データに対応する第２のＱｏＳレベルと比較する。いくつかのそのような実施形態においては、ＱｏＳレベルは、例えば、一つの通信デバイスから他の通信デバイスへ送信されるトラフィックのためのトラフィック送信プライオリティー・レベルである。少なくとも一つの実施態様では、信号８４０からリカバーされた第１のＱｏＳレベルは、アクセス・ルータ８０６が第２の通信デバイス（例えば、デバイスＣ８０８）へ送信することを意図するトラフィック・データのためのトラフィック送信プライオリティーを表す。オペレーションは、サブステップ９１６からサブステップ９１８へ進む。

サブステップ９１８において、第１の通信デバイス（例えば、デバイスＡ８０２）は、サブステップ９１６におけるＱｏＳレベルの比較の結果に基づいて、どのように進むかの決定をする。第１の通信デバイス（例えば、デバイスＡ８０２）が送信することを意図するトラフィック・データに対応する第２のＱｏＳレベルが、アクセス・ルータ８０６が送信することを意図するトラフィック・データに対応するリカバーされた第１のＱｏＳレベルより大きいならば、オペレーションはサブステップ９２０へ進む。サブステップ９２０において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第１の送信リクエスト信号（例えば、アクセス・ルータ８０６からの信号８４０）の電力レベルにかかわりなく、トラフィック・データを送信することに決定する。そのような場合には、オペレーションはステップ９２０からステップ９２６へ進む。

しかし、第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより低いならば、オペレーションはステップ９１８からサブステップ９２２へ進む。サブステップ９２２において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第２の通信デバイス（例えば、デバイスＣ８０８）からの第１の送信リクエスト・レスポンス信号（例えば、信号８４２）の受信電力レベルに基づいて及び干渉コスト推定（該干渉コスト推定は、第１の送信リクエスト・レスポンス信号（例えば、信号８４２）の受信電力レベルに基づくものである）に基づいて、送信するべきか否か決定する。いくつかの実施形態においては、干渉コスト推定（例えば、ＳＩＲレベル）は、第１の通信デバイス（例えば、デバイスＡ８０２）によって、決定サブステップ９２２の一部として、計算される。受信された第１の送信リクエスト・レスポンス信号（例えば、信号８４２）の電力レベルは、いくつかの実施態様において、第１の通信デバイス（例えば、デバイスＡ８０２）に関して、第２の通信デバイス（例えば、デバイスＣ８０８）の近接のインジケーション（indication of proximity）を提供するのに使用される。第１の通信デバイス（例えば、デバイスＡ８０２）と第２のデバイス（例えば、デバイスＣ８０８）とが近接する場合に、両方のトラフィック・データ伝送が同一のエアーリンク・トラフィック資源（例えば、同一のトラフィック・セグメント）を使用するならば、デバイスＣ８０８がアクセス・ルータ８０６からのより高いプライオリティー・トラフィック・データを受信してリカバーしようと試みているとき、第３の通信デバイス（例えば、デバイスＢ８０４）へ向けられた第１の通信デバイス（例えば、デバイスＡ８０２）からのトラフィック・データ伝送が、デバイスＣ１０８に重大な干渉を引き起こす場合があるので、これは実際的な重要性をもつものである。

ピアツーピア通信ネットワーク１００における通信デバイス（８０２，８０４，８１０，．．．，８１２）が、それ自身の意図されたトラフィック送信に関連するプライオリティーに比べて、アクセス・ルータ１０６から第３の通信デバイス（例えば、デバイスＣ８０８）へのトラフィック・データのより高いプライオリティーを知っているならば、該通信デバイス（８０２，８０４，８１０，．．．，８１２）は、それらがより高いプライオリティーのトラフィック送信／受信デバイス・ペア（８０６，８０８）にもたらし得る干渉問題を考慮することによって、それらの送信決定をする。それゆえ、干渉コスト推定は、第１の通信デバイス（例えば、デバイスＡ８０２）によって受信される、第１の送信リクエスト・レスポンス信号（例えば、信号８４２）の電力レベルを使用して、該第１の通信デバイス（例えば、デバイスＡ８０２）によって計算される。いくつかの実施形態において、サブステップ９２２はまた、サブステップ９２４を含む。サブステップ９２４において、計算された干渉コスト推定は、例えば、第１の通信（例えば、デバイスＡ８０２）が、アクセス・ルータ８０６からより高いプライオリティー・トラフィックを受信していると予期される第２の通信デバイス（例えば、デバイスＣ８０８）に閾値レベルを上回る干渉を引き起こすと予期されるか判定するために、閾値と比較される。干渉コスト推定が閾値より小さいならば、第１の通信デバイス（例えば、デバイスＡ８０２）は、トラフィック・データを送信することに決定し、そして、オペレーションはサブステップ９２４からステップ９２６へ進む。ステップ９２６において、第１の通信デバイス（例えば、デバイスＡ８０２）は、第３の通信デバイス（例えば、デバイスＢ８０４）に、トラフィック・データを送信する。

しかし、計算された干渉コストが閾値レベルを超えるならば、トラフィック・データを送信しないという決定が第１の通信デバイス（例えば、デバイスＡ８０２）によってなされる。そのような状況では、オペレーションはサブステップ９２２からステップ９２８へ進む。そこでは、第１の通信デバイス（例えば、デバイスＡ８０２）は、このトラフィック・スロットにおいてトラフィック・データを送信することを控えるように制御される。第１の通信デバイス（例えば、デバイスＡ８０２）が送信するかどうかに応じて、オペレーションはステップ９２６又は９２８からステップ９３０へ進む。ステップ９３０において、該オペレーションはステップ９０４に戻り、そして、ステップ９０４〜９１４が、第１の通信デバイス（例えば、デバイスＡ８０２）により繰り返されても良く、そして時々そのように繰り返される。例えば、アクセス・ルータ８０６から他のパイロット信号を受信する前に、ステップ９０４〜９１４の他の繰り返しと、ステップ９２６及び９１８のうちの一つが実行される。それゆえ、いくつかの実施態様において、第１の通信デバイスとアクセス・ルータとの間の同一のチャネル推定は、複数のトラフィック・スロットに対応する複数の送信機イールディング決定をするために使用される情報をリカバーする際に使用される。

図１０は、例示的な実施態様に従った例示的な通信デバイス１０００の図である。通信デバイス１０００は、例えば、ピアツーピアの通信をサポートしており、さらに、図９のフローチャート９００に従った方法を実装しているモバイル無線端末である。第１の通信デバイス１０００は、例えば、図８のシステム８００の通信デバイスＡ８０２である。通信デバイス１０００は、その上で様々な要素（１００２,１００４）がデータ及び情報を交換し得るバス１００９を介して一緒に接続されるプロセッサ１００２及びメモリ１００４を含む。通信デバイス１０００は、図示されるように、プロセッサ１００２に接続する得る入力モジュール１００６及び出力モジュール１００８を更に含む。しかし、いくつかの実施態様では、入力モジュール１００６及び出力モジュール１００８は、プロセッサ１００２の内部に位置する。入力モジュール１００６は、入力信号を受信することができる。入力モジュール１００６は、入力を受信するために無線受信機及び／又は有線若しくは光入力インタフェースを含むことができ、そしていくつかの実施態様では該無線受信機及び／又は有線若しくは光入力インタフェース含む。出力モジュール１００８は、出力を送信するために無線送信機及び／又は有線若しくは光出力インタフェースを含んでも良く、そしていくつかの実施態様では無線送信機及び／又は有線若しくは光出力インタフェースを含む。プロセッサ１００２は、第２の通信デバイスに向けられた第１の送信リクエスト信号から第１のサービス品質（ＱｏＳ）レベルをリカバーし、前記リカバーされた第１のＱｏＳレベルに基づいて、第３の通信デバイスにトラフィック・データを送信するか否かについて決定をするように構成される。

プロセッサ１００２は、更に、アクセス・ルータから前記第１の送信リクエスト信号（該第１の送信リクエスト信号は、該アクセスから前記第２の通信デバイスへデータを送信するためのリクエストである）を受信するように構成される。いくつかの実施形態では、前記第１のＱｏＳレベルをリカバーすることは、前記第１の送信リクエスト信号の位相から前記ＱｏＳレベルをリカバーすることを含む。いくつかの実施形態においては、プロセッサ１００２は、更に、前記アクセス・ルータからパイロット信号を受信し、前記受信されたパイロット信号に基づいて、前記アクセス・ルータと前記通信デバイス１０００との間のチャネルのチャネル推定を生成し、前記第１の送信リクエスト信号の位相を解釈するために、前記生成されたチャネル推定を使用するように構成され、前記第１の送信リクエスト信号の前記位相は、前記第１のサービス品質レベルを示す。

いくつかの実施形態において、プロセッサ１００２は、更に、前記リカバーされた第１のＱｏＳレベルを、前記トラフィック・データに対応する第２のＱｏＳレベルと比較するように構成される。少なくともいくつかの実施態様は、更に、前記トラフィック・データを送信するか否かについて決定をすることは、前記第２のＱｏＳレベルが前記リカバーされた第１のＱｏＳレベルより高い場合に、前記第１の送信リクエスト信号の受信電力レベルにかかわりなく、送信すると決定する構成される。いくつかの実施態様では、プロセッサ１００２は、前記送信するか否かについて決定をすることは、前記第２のＱｏＳレベルが前記リカバーされた第１のＱｏＳレベルより低い場合に、前記第２の通信デバイスから受信される第１の送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否か決定することを含み、前記干渉コスト推定は、前記第１の送信リクエスト・レスポンス信号の前記受信電力レベルに基づく。

少なくともいくつかの実施態様では、更に、プロセッサ１００２は、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をするように構成される。いくつかの実施形態においては、プロセッサ１００２は、例えば、アクセス・ルータから他のパイロット信号を受信する前に、前記複数の決定をするように構成される。

図１１は、図１０に示される通信デバイス１０００において使用されることができ（そしていくつかの実施態様で使用される）モジュール・アセンブリ１１００である。アセンブリ１１００中のモジュールは、図１０のプロセッサ１００２内にハードウェアで（例えば個々の回路として）実装されることができる。あるいは、該モジュールは、ソフトウェアで実装されても良く、図１０に示される通信デバイス１０００のメモリ１００４に記憶されても良い。図１０では、単一のプロセッサ（例えば、コンピュータ）として実施態様が示されるが、プロセッサ１００２が１又は複数のプロセッサ（例えば、コンピュータ）として実装され得ることは認識されるべきである。ソフトウェアで実装される場合には、該モジュールは、該プロセッサによって実行されるときに、該モジュールに対応する機能を実装するようにプロセッサ（例えば、コンピュータ）１００２を設定するコードを含む。モジュール・アセンブリ１１００がメモリ１００４に記憶される実施態様では、メモリ１００４は、少なくとも一つのコンピュータ（例えば、プロセッサ１００２）に、該モジュールが対応する機能を実装させるためのコード（例えば、各々のモジュールごとの個々のコード）を含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品である。

完全にハードウェア・ベース又は完全にソフトウェア・ベースのモジュールが使用されても良い。しかし、ソフトウェア及びハードウェア（例えば、実装される回路）モジュールの任意の組み合せが該機能を実装するために使用されても良いことは認識されるべきである。認識されるべきであるように、図９に示されるモジュールは、図１１の方法フローチャート９００中に示される対応するステップの機能を実行するように、通信デバイス１０００又はその中の要素（例えばプロセッサ１００２）を制御及び／又は設定する。

図１１に示されるように、モジュール・アセンブリ１１００は、第３の通信デバイスへ送信リクエスト信号を送信するためのモジュール１１０２、第３の通信デバイスから送信リクエスト・レスポンスを受信するためのモジュール１１０４、アクセス・ルータから第１の送信リクエスト信号を受信するモジュール１１０６（第１の送信リクエスト信号はアクセス・ルータから第２の通信デバイスへデータを送信するためのリクエストである）、アクセス・ルータからパイロット信号を受信するためのモジュール１１０８、例えば受信されたパイロット信号に基づいて、アクセス・ルータと第１の通信デバイス１０００との間のチャネルのチャネル推定を生成することのためのモジュール１１１０、第１の送信リクエスト信号から第１のサービス品質（ＱｏＳ）レベルをリカバーするためのモジュール１１１２、及び、リカバーされた第１のサービス品質レベルに基づいて、第３の通信デバイスにトラフィック・データを送信するか否か決定するためのモジュール１１１６を含む。モジュール・アセンブリ１１００は、更に、トラフィック・データを送信するためのモジュール１１２６、及び、例えばアクセス・ルータから他のパイロット信号を受信する前に、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定を行うためのモジュール１１２８を含む。

少なくともいくつかの実施態様では、モジュール１１１２は、第１の送信リクエスト信号の位相から第１のＱｏＳレベルをリカバーするためのモジュール１１１３、及び、受信された第１の送信リクエスト信号の位相を解釈するために、生成されたチャネル推定を使用するためのモジュール１１１４を含む。いくつかの実施形態においては、決定するためのモジュール１１１６は、リカバーされた第１のＱｏＳレベルを、第２のＱｏＳレベルと比較するためのモジュール１１１８（該第２のサービス品質レベルは、送信されるトラフィック・データに対応する）、第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより高い場合に、第１の送信リクエスト信号の受信電力レベルにかかわらずに、トラフィック・データを送信することに決定するためのモジュール１１２０、第２のＱｏＳレベルがリカバーされた第１のＱｏＳレベルより低い場合に、第２の通信デバイスから受信される第１の送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否か決定するためのモジュール１１２２（該干渉コスト推定は、第１の送信リクエスト・レスポンス信号の受信電力レベルに基づくものである）を含む。いくつかの実施形態においては、モジュール１１２２は、干渉コスト推定を閾値と比較するためのモジュール１１２４を含む。

図１２は、例示的な実施態様に従った第１の通信デバイス（例えば、図８の通信デバイスＢ８０４）を操作する例示的な方法のフローチャート１２００である。例示的な方法のオペレーションは、ステップ１２０１において開始する。そこでは、第１の通信デバイス（例えば、デバイスＢ８０４）が、パワーオンされ初期化される。オペレーションは、開始ステップ１２０１からステップ１２０２へ、そして、いくつかの実施態様において、ステップ１２０３へ、進む。いくつかの実施形態において、第１の通信デバイス（例えば、デバイスＢ８０４）はまた、フローチャート１２００の様々な他のステップと並行して、チャネル推定サブルーチン１２０３を実行する。ステップ１２０５において、第１の通信デバイス（例えば、デバイスＢ８０４）は、アクセス・ルータ８０６からパイロット信号８３０を受信する。ステップ１２０７において、受信されたパイロット信号８３０を使用して、第１の通信デバイス（例えば、デバイスＢ８０４）は、第１の通信デバイス（例えば、デバイスＢ８０４）とアクセス・ルータ８０６との間のチャネルに関するチャネル推定を生成し、そして、本プロセスは、例えば予め定められたタイミング構造に従って、ある時間の期間（a time period of time）の後、繰り返す。例示的な実施態様に従って、生成されたチャネル推定は、送信リクエスト信号（例えば、信号８４０）の位相を解釈するために、第１の通信デバイス（例えば、デバイスＢ８０４）により使用されても良く、そして時々そのように使用される。矢印線１２１１は、生成されたチャネル推定が、第１の通信デバイス（例えば、デバイスＢ８０４）に利用可能であり、また、フローチャート１２００の方法を実装する際に、第１の通信デバイス（例えば、デバイスＢ８０４）により使用され得ることを表す。

ステップ１２０２において、第１の通信デバイス（例えば、デバイスＢ８０４）は、他のデバイスが第１の通信デバイスに（例えば、デバイスＢ８０４に）送信した可能性のある送信リクエスト信号をモニターする。少なくとも一つの例示的な実施態様において、ステップ１２０２は、サブステップ１２０４及び１２０６を含む。サブステップ１２０４において、第１の通信デバイス（例えば、デバイスＢ８０４）は、アクセス・ルータ（例えば、アクセス・ルータ８０６）から、第１の送信リクエスト信号（例えば、送信リクエスト信号８４０）を受信する。第１の送信リクエスト信号８４０は、アクセス・ルータ８０６から第２の通信デバイス（例えば、通信デバイスＣ８０８）へのトラフィック送信リクエストである。いくつかの実施形態においては、第１の送信リクエスト信号（例えば、信号８４０）は、シングルトーン信号である。いくつかの実施形態においては、第１の送信リクエスト信号の位相（例えば、信号８４０の位相）は、ＱｏＳ情報を伝える。いくつかの実施形態においては、ＱｏＳ情報は、送信リクエスト８４０がアクセス・ルータ８０６によってそのためになされたトラフィック・データの送信のためのトラフィック送信プライオリティーを伝達する。サブステップ１２０６において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第３の通信デバイス（例えば、通信デバイスＡ８０２）から、第２の送信リクエスト信号（例えば、送信リクエスト信号８４４）を受信する。オペレーションは、ステップ１２０２からステップ１２０８へ進む。

ステップ１２０８において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第１の送信リクエスト信号から（例えば、信号８４０から）、第１のＱｏＳレベルをリカバーする。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＢ８０４）は、第１の送信リクエスト信号の位相から（例えば、信号８４０の位相から）、第１のＱｏＳレベルをリカバーする。いくつかの実施形態においては、第１の通信デバイス（例えば、デバイスＢ８０４）は、ステップ１２０８における第１のＱｏＳレベルのリカバーの一部として、サブステップ１２１０を実行する。サブステップ１２１０において、第１の通信デバイス（例えば、デバイスＢ８０４）は、受信された第１の送信リクエスト信号８４０の位相を解釈するために、（例えばステップ１２０７から）生成されたチャネル推定を使用する。

オペレーションは、ステップ１２０８からステップ１２１２へ進む。ステップ１２１２において、第１の通信デバイス（例えば、デバイスＢ８０４）は、リカバーされた第１のＱｏＳレベルに基づいて、第３の通信デバイス（例えば、デバイスＡ８０２）からの第２の送信リクエスト信号（例えば、信号８４４）に応答して第１の送信リクエスト・レスポンス信号（例えば、リクエスト・レスポンス信号８４６）を送信するか否か決定する。いくつかの実施形態においては、ステップは、１又は複数のサブステップ１２１４，１２１６，１２１８，１２２０及び１２２２を含む。サブステップ１２１４において、第１の通信デバイス（例えば、デバイスＢ８０４）は、リカバーされた第１のＱｏＳレベルを、第１の通信デバイス（例えば、デバイスＢ８０４）と第３の通信デバイス（例えば、デバイスＡ８０２）との間のコネクションに対応する第２のＱｏＳレベルと比較する。いくつかの実施形態においては、第３の通信デバイス（例えば、デバイスＡ８０２）と第１の通信デバイスＢ（例えば、デバイス８０４）との間のコネクションに関連するコネクション識別子が存在する。いくつかのそのような実施態様では、そのようなコネクション識別子に関連するＱｏＳレベルが存在する。いくつかのそのような実施態様では、ＱｏＳレベルは、例えば、第３の通信デバイス（例えば、デバイスＡ８０２）から第１の通信デバイス（例えば、デバイスＢ８０４）へ送信されるトラフィックのためのトラフィック送信プライオリティー・レベルである。それゆえ、少なくとも一つの実施態様では、サブステップ１２１４において、比較は、リカバーされたＱｏＳレベルにより示されるトラフィック送信プライオリティーと、第３の通信デバイス（例えば、デバイスＡ８０２）から第１の通信デバイス（例えば、デバイスＢ８０４）へ送信されるトラフィック・データの送信プライオリティーとの間について実行される。オペレーションは、サブステップ１２１４からサブステップ１２１６へ進む。

サブステップ１２１６において、第１の通信デバイス（例えば、デバイスＢ８０４）は、サブステップ１２１４におけるＱｏＳレベルの比較の結果に基づいて、どのように進むかについて決定をする。第３の通信デバイス（例えば、デバイスＡ８０２）と第２の通信デバイス（例えば、デバイスＢ８０４）との間のコネクションに対応する第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベル（例えば、リクエスト信号８４０の位相からリカバーされたＱｏＳレベル）より大きいならば、オペレーションはサブステップ１２１６からサブステップ１２１８へ進む。サブステップ１２１８において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第３の通信デバイスに（例えば、デバイスＡ８０２に）、第１の送信リクエスト・レスポンス信号（例えば、信号８４６）を送信することに決定する。こうした状況では、オペレーションはステップ１２１８からステップ１２２４へ進む。しかし、リカバーされた第１のＱｏＳレベルが、第３のデバイス（例えば、デバイスＡ８０２）と第１の通信デバイス（例えば、デバイスＢ８０４）との間でコネクションに対応する第２のＱｏＳレベルより大きいならば、オペレーションはサブステップ１２１６からサブステップ１２２０へ進む。サブステップ１２２０において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第３の通信デバイス（例えば、デバイスＡ８０２）から受信された第２の送信リクエスト信号（例えば、信号８４４）の受信電力及びアクセス・ルータ８０６から第２の通信デバイス（例えば、デバイスＣ８０８）への第１の送信リクエスト信号（例えば、信号８４０）の受信電力レベルに基づいて、チャネル品質推定（例えば、ＳＩＲ）を生成する。例えば、いくつかの実施態様では、ＳＩＲレベルは、信号電力として、第２の送信リクエスト信号８４４の受信電力を、そして、干渉信号力として、アクセス・ルータ８０６からの第１の送信リクエスト信号８４０の受信電力レベルを使用して計算される。

サブステップ１２２０からの生成された閾値を超えるチャネル品質推定は、いくつかの実施態様において、アクセス・ルータ８０６からデバイスＣ８０８へ送信されることを意図されるより高いプライオリティー・トラフィック・データが、第３の通信デバイス（例えば、デバイスＡ８０２）からのトラフィック・データの受信時及び／又はリカバー時に、第１の通信デバイス（例えば、デバイスＢ８０４）に対して容認できないレベルの干渉を引き起こすと予期されることのインジケーションである。第１の通信デバイス（例えば、デバイスＢ８０４）は、アクセス・ルータ８０６に対応するトラフィック・データがそれ自身のプライオリティーより高い送信プライオリティーを有し、それゆえ、アクセス・ルータ８０６が第２の通信デバイス（例えば、デバイスＣ８０８）へトラフィック・データを送信する可能性が高い（more likely to）ことを知っているので、第１の通信デバイス（例えば、デバイスＢ８０４）は、いくつかの実施態様において、送信リクエスト・レスポンス８４６を送信することを控える。それゆえ、このような状況では、第１の通信デバイス（例えば、デバイスＢ８０４）は、それがリクエスト８４４の意図されたトラフィック送信に同意した（acquiesced）ならば、それが第３の通信デバイス（例えば、デバイスＡ８０２）からトラフィック・データのプアな受信を有したであろうと予期するので、該第１の通信デバイス（例えば、デバイスＢ８０４）は、受信機イールディングを実行して、このトラフィック・スロットのために送信リクエストを承認（approve）しない。オペレーションは、サブステップ１２２０からサブステップ１２２２へ進む。

サブステップ１２２２において、サブステップ１２２０で生成されたチャネル品質推定に基づいて、第３の通信デバイス（例えば、デバイスＡ８０２）に第１のリクエスト・レスポンス信号（例えば、信号８４６）を送信するか否かの決定がなされる。生成されたチャネル品質推定に基づく決定に応じて、オペレーションはステップ１２２４又はステップ１２２６へ進み得る。いくつかの実施形態においては、決定ステップ１２２２は、サブステップ１２２０の生成されたチャネル品質推定を閾値レベルと比較することと、そのような比較の結果に基づいて進行することに決定することを含む。第３の通信（例えば、デバイスＡ８０２）からトラフィック・データを受信する際に、アクセス・ルータ８０６から第２の通信デバイス（例えば、デバイスＣ８０８）へのトラフィックの送信が、第１の通信デバイス（例えば、デバイスＢ８０４）に重大な干渉問題を引き起こすと予期されないことを示す閾値レベルを、生成されたチャネル品質が下回るならば、第１の通信デバイス（例えば、デバイスＢ８０４）は、いくつかの実施態様において、第３の通信デバイス（例えば、デバイスＡ８０２）に第１の送信リクエスト・レスポンス信号（例えば、信号８４６）を送信することに決定する。そのような状況では、オペレーションはサブステップ１２２２からステップ１２２４へ進む。ステップ１２２４において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第３の通信デバイス（例えば、デバイスＡ８０２）に、第１の送信リクエスト・レスポンス信号（例えば、信号８４６）を送信する。他方、ステップ１２２０の生成されたチャネル品質推定が、閾値を越えるならば、第１の通信デバイス（例えば、デバイスＢ８０４）は、いくつかの実施態様において、第３の通信デバイス（例えば、デバイスＡ８０２）に第１の送信リクエスト・レスポンス信号（例えば、信号８４６）を送信しないことに決定する。そのような状況では、オペレーションは、サブステップ１２２２を含むステップ１２１２から、ステップ１２２６へ進む。ステップ１２２６において、第１の通信デバイス（例えば、デバイスＢ８０４）は、第３の通信デバイス（例えば、デバイスＡ８０２）へ第１の送信リクエスト・レスポンス信号（例えば、信号８４６）を送信することを控えるように制御される。第１の通信デバイス（例えば、デバイスＢ８０４）が送信するかどうかに応じて、オペレーションはステップ１２２４又は１２２６からステップ１２２８へ進む。ステップ１２２８において、オペレーションはステップ１２０２に戻り、そして、ステップ１２０３〜１２１２が、第１の通信デバイス（例えば、デバイスＢ８０４）によって繰り返されても良く、そして時々そのように繰り返される。一つの例において、アクセス・ルータ８０６から他のパイロット信号を受信する前に、他のトラフィック・スロットに対応して、ステップ１２０３〜１２１２が繰り返される。それゆえ、少なくともいくつかの実施態様にいて、（例えばステップ１２０７からの）アクセス・ルータと第１の通信デバイスとの間の同一のチャネル推定は、複数のトラフィック送信決定をする際に利用される情報をリカバーするために、複数のトラフィック・スロットで使用される。

図１３は、例示的な実施態様に従った例示的な通信デバイス１３００の図である。通信デバイス１３００は、例えば、ピアツーピアの通信をサポートしており、図１２のフローチャート１２００に従った方法を実装しているモバイル無線端末である。通信デバイス１３００は、例えば、図８のシステム８００の通信デバイスＢ８０４である。通信デバイス１３００は、その上で様々な要素（１３０２，１３０４）がデータ及び情報を交換し得るバス１３０９を介して一緒に接続されるプロセッサ１３０２及びメモリ１３０４を含む。通信デバイス１３００は、図示されるように、プロセッサ１３０２に接続する得る入力モジュール１３０６及び出力モジュール１３０８を更に含む。しかし、いくつかの実施態様では、入力モジュール１３０６及び出力モジュール１３０８は、プロセッサ１３０２の内部に位置する。入力モジュール１３０６は、入力信号を受信することができる。入力モジュール１３０６は、入力を受信するために無線受信機及び／又は有線若しくは光入力インタフェースを含むことができ、そしていくつかの実施態様では該無線受信機及び／又は有線若しくは光入力インタフェース含む。出力モジュール１３０８は、出力を送信するために無線送信機及び／又は有線若しくは光出力インタフェースを含んでも良く、そしていくつかの実施態様では無線送信機及び／又は有線若しくは光出力インタフェースを含む。

プロセッサ１３０２は、第１の送信リクエスト信号から第１のサービス品質レベル（ＱｏＳ）をリカバーし、前記リカバーされた第１のＱｏＳレベルに基づいて、第２の送信リクエスト信号に応答して第１の送信リクエスト・レスポンス信号を送信するか否かの決定をするように構成される。いくつかの実施形態においては、前記第２の送信リクエスト信号は、第３の通信デバイスからである。いくつかの実施形態においては、プロセッサ１３０２は、アクセス・ルータから第１の送信リクエスト信号を受信するように更に構成され、前記第１の送信リクエスト信号は、前記アクセス・ルータから第２の通信デバイスへのトラフィック送信リクエストである。

いくつかの実施形態においては、プロセッサ１３０２は、前記アクセス・ルータからパイロット信号を受信し、前記アクセス・ルータと前記通信デバイス１３００と間のチャネルのチャネル推定を生成し、前記受信された第１の送信リクエスト信号の位相を解釈するために、前記生成されたチャネル推定を使用するように更に構成される。

いくつかの実施形態においては、プロセッサ１３０２は、前記リカバーされた第１のＱｏＳレベルを第２のＱｏＳレベルと比較するように更に構成され、前記第２のＱｏＳレベルは、前記第３の通信デバイスと前記通信デバイス１３００との間のコネクションに対応する。少なくともいくつかの実施態様において、プロセッサ１３０２は、前記第３の通信デバイスと前記通信デバイス１３００との間の前記コネクションに対応する前記第２のＱｏＳレベルが、前記リカバーされた第１のＱｏＳレベルより高い場合に、前記第１の送信リクエスト・レスポンス信号を送信すると決定するように更に構成される。いくつかの実施形態においては、プロセッサ１３０２は、前記第３の通信デバイスからの前記第２の送信リクエスト信号の受信電力及び前記アクセス・ルータから前記第２の通信デバイスへ送信される前記第１の送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成し、前記第２のＱｏＳレベルが、前記リカバーされた第１のＱｏＳレベルより低い場合に、前記生成されたチャネル品質推定に基づいて、前記第１の送信リクエスト・レスポンス信号を送信するか否か決定するように更に構成される。

少なくいくつかの実施態様において、プロセッサ１３０２は、複数の異なる送信タイム・スロットにおいて送信リクエスト・レスポンス信号を送信するか否かについて複数の決定をするように更に構成される。いくつかの実施形態においては、プロセッサ１３０２は、例えばアクセス・ルータから他のパイロット信号を受信する前に、前記複数の決定をするように構成される。

図１４は、図１３に示される通信デバイス１３００において使用されることができ（そしていくつかの実施態様で使用される）モジュール・アセンブリ１４００である。アセンブリ１４００中のモジュールは、図１３のプロセッサ１３０２内にハードウェアで（例えば個々の回路として）実装されることができる。あるいは、該モジュールは、ソフトウェアで実装されても良く、図１３に示される通信デバイス１３００のメモリ１３０４に記憶されても良い。図１３では、単一のプロセッサ（例えば、コンピュータ）として実施態様が示されるが、プロセッサ１３０２が１又は複数のプロセッサ（例えば、コンピュータ）として実装され得ることは認識されるべきである。ソフトウェアで実装される場合には、該モジュールは、該プロセッサによって実行されるときに、該モジュールに対応する機能を実装するようにプロセッサ（例えば、コンピュータ）１３０２を設定するコードを含む。モジュール・アセンブリ１４００がメモリ１３０４に記憶される実施態様では、メモリ１３０４は、少なくとも一つのコンピュータ（例えば、プロセッサ１３０２）に、該モジュールが対応する機能を実装させるためのコード（例えば、各々のモジュールごとの個々のコード）を含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品である。

完全にハードウェア・ベース又は完全にソフトウェア・ベースのモジュールが使用されても良い。しかし、ソフトウェア及びハードウェア（例えば、実装される回路）モジュールの任意の組み合せが該機能を実装するために使用されても良いことは認識されるべきである。認識されるべきであるように、図１４に示されるモジュールは、図１２の方法フローチャート１２００中に示される対応するステップの機能を実行するように、通信デバイス１３００又はその中の要素（例えばプロセッサ１３０２）を制御及び／又は設定する。

図１４に示されるように、モジュール・アセンブリ１４００は、送信リクエスト信号をモニターするためのモジュール１４０２を含む。モジュール１４０２は、アクセス・ルータから第１の送信リクエスト信号を受信するためのモジュール１４０４（該第１の送信リクエスト信号は該アクセルルータから第２の通信デバイスへのトラフィック送信リクエストである）、及び、第３のデバイスから第２の送信リクエスト信号を受信するためのモジュール１４０６を含む。モジュール・アセンブリ１４００は、更に、アクセス・ルータからパイロット信号を受信するためのモジュール１４０８、アクセス・ルータと第１の通信デバイス１３００との間のチャネルのチャネル推定を生成するためのモジュール１４１０、第１の送信リクエスト信号から第１のＱｏＳレベルをリカバーするためのモジュール１４１２、リカバーされた第１のＱｏＳレベルに基づいて、第３の通信デバイスからの第２の送信リクエスト信号に応答して送信リクエスト・レスポンス信号を送信するか否か決定するためのモジュール１４１６、第１の送信リクエスト・レスポンス信号を送信するためのモジュール１４２６、及び、例えばアクセス・ルータから他のパイロット信号を受信する前に、複数の異なる送信タイム・スロットにおいて送信リクエスト・レスポンスを送信するか否かについて複数の決定を行うためのモジュール１４２８を含む。

少なくともいくつかの実施態様では、モジュール１４１２は、受信された第１の送信リクエスト信号の位相を解釈するために、アクセス・ルータと第１の通信デバイス１３００との間のチャネルの生成されたチャネル推定を使用するためのモジュール１４１４を含む。少なくともいくつかの実施態様において、モジュール１４１６は、リカバーされた第１のＱｏＳレベルを、第２のＱｏＳレベルと比較するためのモジュール１４１８（該第２のＱｏＳレベルは第１の通信デバイス１３００と第３の通信デバイスとの間でコネクションに対応する）、第１の通信デバイス１３００と第３の通信デバイスとの間のコネクションに対応する第２のＱｏＳレベルが、リカバーされた第１のＱｏＳレベルより高い場合に、第１の送信リクエスト・レスポンスを送信すると決定するためのモジュール１４２０、第３の通信デバイスからの第２の送信リクエスト信号の受信電力及びアクセス・ルータから第２の通信デバイスへの送信される第１の送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成するためのモジュール１４２２、及び、第２のＱｏＳレベルがリカバーされた第１のＱｏＳレベルより低い場合に、生成されたチャネル品質推定に基づいて、第１の送信リクエスト・レスポンス信号を送信するか否か決定するためのモジュール１４２４を含む。

様々な実施形態の技術は、ソフトウェア、ハードウェア、及び／又はソフトウェアとハードウェアの組み合せを使用して実装され得る。様々な実施形態は、装置（例えば、モバイル端末のようなモバイルノード、基地局、通信システム）に向けられる。様々な実施形態はまた、方法（例えば、モバイルノード、基地局、及び／又は通信システム（例えば、ホスト）を制御及び／又は操作する方法）に向けられる。様々な実施形態はまた、方法の１又は複数のステップを実行するように機械を制御するための機械読み取り可能な命令を含む、機械（例えば、コンピュータ）読み取り可能な媒体（例えば、ＲＯＭ、ＲＡＭ、ＣＤ、ハードディスクなど）に向けられる。

様々な実施形態では、１又は複数の方法に対応するステップ（例えば、信号処理、メッセージ生成及び／又は送信ステップ）を実行するための１又は複数のモジュールを使用して、本明細書で説明されるノードが実装される。したがって、いくつかの実施形態では、様々な機能がモジュールを使用して実装される。そのようなモジュールは、ソフトウェア、ハードウェア又はソフトウェアとハードウェアの組合せを使用して実装できる。上記の方法又は方法ステップの多くは、例えば１又は複数のノードにおいて、上記の方法の全部又は一部を実施するために、追加のハードウェアの有無にかかわらず、機械（例えば、汎用コンピュータ）を制御する、例えばメモリデバイス（例えば、ＲＡＭ、フロッピー（登録商標）ディスクなど）のような機械読み取り可能な媒体中に含まれる、ソフトウェアなどの機械実行可能命令を使用して実施できる。したがって、特に、様々な実施形態は、機械（例えば、プロセッサ及び関連するハードウェア）に、上述の（１又は複数の）方法のステップのうちの１つ又は複数を実行させるための機械実行可能命令を含む機械読み取り可能な媒体に向けられる。いくつかの実施形態は、本発明の１又は複数の方法のステップのうちの１つ、複数、又はすべてを実施するように構成されたプロセッサを含むデバイス（例えば、通信ノード）に向けられる。

いくつかの実施形態では、１又は複数のデバイス（例えば、アクセスノード及び／又は無線端末のような通信ノード）の１又は複数のプロセッサ（例えば、ＣＰＵ）は、通信ノードによって実行されるものとして説明した方法のステップを実行するように構成される。プロセッサの構成は、プロセッサ構成を制御するための１又は複数のモジュール（例えば、ソフトウェア・モジュール）を使用することによって及び／又は記載されたステップ及び／又は制御プロセッサ構成を実行するためのハードウェア（例えば、ハードウェア・モジュール）をプロセッサ中に含むことによって、達成されても良い。したがって、すべてではないが、いくつかの実施形態は、プロセッサが含まれるデバイスによって実行される様々な説明された方法のステップの各々に対応するモジュールを含むプロセッサをもつデバイス（例えば、通信ノード）に向けられる。すべてではないが、いくつかの実施形態では、デバイス（例えば、通信ノード）は、プロセッサが含まれるデバイスによって実行される様々な説明された方法のステップの各々に対応するモジュールを含む。モジュールは、ソフトウェア及び／又はハードウェアを使用して実装できる。

開示されたプロセスにおけるステップの特定の順序又は階層は例示的なアプローチの例であるものと理解される。デザイン選択（design preferences）に基づいて、本開示の範囲内で、該プロセスにおけるステップの特定の順序又は階層が再構成されても良いものと理解される。添付の方法クレームは、例示的な順序における様々なステップの要素を提示したものであり、提示される特定の順序又は階層に制限されることは意図されていない。

いくつかの実施形態は、１つのコンピュータ又は複数のコンピュータに、様々な機能、ステップ、行為、及び／又は動作、例えば、上述の１又は複数のステップを実施させるためのコードを含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品に向けられる。実施形態に応じて、コンピュータ・プログラム製品は、実行すべきステップごとに異なるコードを含むことが可能であり、そして時々それを含む。したがって、コンピュータ・プログラム製品は、方法、例えば、通信デバイス又はノードを制御する方法の個々のステップごとのコードを含むことが可能であり、そしてそれを時々含む。コードは、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（読取り専用メモリ）、他のタイプの記憶デバイスなどのコンピュータ読み取り可能な媒体上に記憶される、機械（例えば、コンピュータ）実行可能命令の形態とすることができる。コンピュータ・プログラム製品を対象とすることに加えて、いくつかの実施形態は、上述の１又は複数の方法の様々な機能、ステップ、行為、及び／又は動作のうちの１つ又は複数を実施するように構成されるプロセッサを対象とする。したがって、いくつかの実施形態は、本明細書で説明する方法のステップの一部又は全部を実施するように構成されたプロセッサ（例えば、ＣＰＵ）を対象とする。プロセッサは、例えば、本出願で説明する通信デバイス又は他のデバイス中で使用することができる。

ＯＦＤＭシステムに関して説明したが、様々な実施形態の方法及び装置のうちの少なくともいくつかは、多くの非ＯＦＤＭ及び／又は非セルラーシステムを含む広範囲の通信システムに適用可能である。

上記の説明に鑑みて、上述の様々な実施形態の方法及び装置に関する多数の追加の変形形態が当業者には明らかであろう。そのような変形形態は範囲内に入ると考えるべきである。本方法及び本装置は、ＣＤＭＡ、直交周波数分割多重（ＯＦＤＭ）、及び／又はアクセスノードとモバイルノードとの間の無線通信リンクを与えるために使用される様々な他のタイプの通信技法とともに使用でき、様々な実施形態において使用される。いくつかの実施形態では、アクセスノードは、ＯＦＤＭ及び／又はＣＤＭＡを使用してモバイルノードとの通信リンクを確立する基地局として実装される。様々な実施形態では、モバイルノードは、本方法を実施するための、受信機／送信機回路並びに論理及び／又はルーチンを含む、ノートブックコンピュータ、個人情報端末（ＰＤＡ）、又は他の携帯デバイスとして実装される。
以下に、本願出願の当初の特許請求の範囲に記載された各請求項に対応する発明を付記する。
［１］第１の通信デバイスを操作する方法において、
送信リクエスト・レスポンス信号からサービス品質レベルをリカバーすることと、
前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をすることを含む方法。
［２］アクセス・ルータから前記送信リクエスト・レスポンス信号を受信することを更に含み、
前記サービス品質レベルを前記リカバーすることは、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーする請求項１の方法。
［３］前記送信リクエスト・レスポンス信号は、第２の通信デバイスから前記アクセス・ルータへ送信されるトラフィック送信リクエストに応答するものである請求項２の方法。
［４］前記アクセス・ルータからパイロット信号を受信することと、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成することを更に含み、
前記サービス品質レベルを前記リカバーすることは、前記受信された送信リクエスト・レスポンス信号の前記位相を解釈するために、前記生成されたチャネル推定を使用することを含む請求項３の方法。
［５］前記送信するか否かの決定をすることは、前記リカバーされたサービス品質レベルを前記トラフィック・データに対応するサービス品質レベルと比較することを含む請求項１の方法。
［６］前記送信するか否かの決定をすることは、送信されるべき前記トラフィック・データの前記サービス品質レベルが、前記リカバーされたサービス品質レベルより高い場合に、前記送信リクエスト・レスポンス信号の前記受信電力レベルにかかわりなく、送信すると決定することを更に含む請求項５の方法。
［７］前記送信するか否かの決定をすることは、送信されるべき前記トラフィック・データの前記サービス品質レベルが、前記リカバーされたサービス品質レベルより低い場合に、前記送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否かを決定することを更に含む請求項５の方法。
［８］前記送信リクエスト・レスポンス信号は、シングルトーン信号であり、
前記方法は、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をすることを更に含む請求項１の方法。
［９］送信リクエスト・レスポンス信号からサービス品質レベルをリカバーし、
前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をするように構成された少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサに接続されたメモリとを含む第１の通信デバイス。
［１０］前記少なくとも一つのプロセッサは、
アクセス・ルータから前記送信リクエスト・レスポンス信号を受信し、
前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーするように更に構成される請求項９の第１の通信デバイス。
［１１］前記送信リクエスト・レスポンス信号は、第２の通信デバイスから前記アクセス・ルータへ送信されるトラフィック送信リクエストに応答するものである請求項１０の第１の通信デバイス。
［１２］前記少なくとも一つのプロセッサは、
前記アクセス・ルータからパイロット信号を受信し、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成し、
前記受信された送信リクエスト・レスポンス信号の前記位相を解釈するために、前記生成されたチャネル推定を使用するように更に構成される請求項１１の第１の通信デバイス。
［１３］前記少なくとも一つのプロセッサは、前記リカバーされたサービス品質レベルを前記トラフィック・データに対応するサービス品質レベルと比較するように更に構成される請求項９の第１の通信デバイス。
［１４］送信リクエスト・レスポンス信号からサービス品質レベルをリカバーするための手段と、
前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をするための手段とを含む第１の通信デバイス。
［１５］アクセス・ルータから前記送信リクエスト・レスポンス信号を受信するための手段を更に含み、
前記サービス品質レベルをリカバーするための前記手段は、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーするための手段を更に含む請求項１４の第１の通信デバイス。
［１６］前記送信リクエスト・レスポンス信号は、第２の通信デバイスから前記アクセス・ルータへ送信されるトラフィック送信リクエストに応答するものである請求項１５の第１の通信デバイス。
［１７］前記アクセス・ルータからパイロット信号を受信するための手段と、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成するための手段とを更に含み、
前記サービス品質レベルを前記リカバーするための前記手段は、前記受信された第１の送信リクエスト・レスポンス信号の前記位相を解釈するために、前記生成されたチャネル推定を使用するための手段を含む請求項１６の第１の通信デバイス。
［１８］第１の通信デバイスで使用されるコンピュータ・プログラム製品において、
少なくとも一つのコンピュータに、送信リクエスト・レスポンス信号からサービス品質レベルをリカバーさせるためのコードと、
前記少なくとも一つのコンピュータに、前記リカバーされたサービス品質レベルに基づいて、トラフィック・データを送信するか否かの決定をさせるためのコードとを含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品。
［１９］前記少なくとも一つのコンピュータに、アクセス・ルータから前記送信リクエスト・レスポンス信号を受信させるためのコードを更に含み、
前記少なくとも一つのコンピュータに前記サービス品質レベルをリカバーさせるための前記コードは、前記少なくとも一つのコンピュータに、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーさせるためのコードを含む請求項１８のコンピュータ・プログラム製品。
［２０］第１の通信デバイスを操作する方法において、
第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーすることと、
前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をすることを含む方法。
［２１］アクセス・ルータから前記第１の送信リクエスト・レスポンス信号を受信することを更に含み、
前記第１の送信リクエスト・レスポンス信号は、前記第１のトラフィック送信リクエスト信号に応答するものであり、
前記第１のトラフィック送信リクエスト信号は、第２の通信デバイスから前記アクセス・ルータへ送信される請求項２０の方法。
［２２］前記アクセス・ルータからパイロット信号を受信することと、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成することを更に含み、
前記第１のサービス品質レベルをリカバーすることは、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用することを含む請求項２１の方法。
［２３］前記第２のトラフィック送信リクエスト信号は、第３の通信デバイスからであり、
前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をすることは、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較することを含み、
前記第２のサービス品質レベルは、前記第１の通信デバイスと前記第３の通信デバイスとの間のコネクションに対応する請求項２０の方法。
［２４］前記送信するか否かの決定をすることは、前記第１の通信デバイスと前記第３の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質レベルより高い場合に、送信すると決定することを更に含む請求項２３の方法。
［２５］前記送信するか否かの決定をすることは、
前記第２のトラフィック送信リクエスト信号の受信電力に基づいて及び前記第１のトラフィック送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成することと、
前記第１の通信デバイスと前記第３の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質より低い場合に、前記生成されたチャネル品質推定に基づいて、送信するか否かを決定することを更に含む請求項２３の方法。
［２６］前記第１の送信リクエスト・レスポンス信号は、シングルトーン信号であり、
前記方法は、複数の異なる送信タイム・スロットにおいて送信リクエスト・レスポンス信号を送信するか否かについて複数の決定をすることを更に含む請求項２２の方法。
［２７］第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーし、
前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするように構成された少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサに接続されたメモリとを含む第１の通信デバイス。
［２８］前記少なくとも一つのプロセッサは、アクセス・ルータから前記第１の送信リクエスト・レスポンス信号を受信するように更に構成され、
前記第１の送信リクエスト・レスポンス信号は、前記第１のトラフィック送信リクエスト信号に応答するものであり、
前記第１のトラフィック送信リクエスト信号は、第２の通信デバイスから前記第１のアクセス・ルータへ送信される請求項２７の第１の通信デバイス。
［２９］前記少なくとも一つのプロセッサは、
前記アクセス・ルータからパイロット信号を受信し、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成し、
前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するように更に構成される請求項２８の第１の通信デバイス。
［３０］前記第２のトラフィック送信リクエストは、第３の通信デバイスからであり、
前記少なくとも一つのプロセッサは、前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をする場合に、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較するように更に構成され、
前記第２のサービス品質レベルは、前記第１の通信デバイスと前記第３の通信デバイスとの間のコネクションに対応する請求項２７の第１の通信デバイス。
［３１］前記少なくとも一つのプロセッサは、前記第３の通信デバイスと前記第１の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質レベルより高い場合に、送信すると決定するように更に構成される請求項３０の第１の通信デバイス。
［３２］第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーするための手段と、
前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするための手段とを含む第１の通信デバイス。
［３３］アクセス・ルータから前記第１の送信リクエスト・レスポンス信号を受信するための手段を更に含み、
前記第１の送信リクエスト・レスポンス信号は、前記第１のトラフィック送信リクエスト信号に応答するものであり、
前記第１のトラフィック送信リクエスト信号は、第２の通信デバイスから前記第１のアクセス・ルータへ送信される請求項３２の第１の通信デバイス。
［３４］前記アクセス・ルータからパイロット信号を受信するための手段と、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成するための手段とを更に含み、
前記第１のサービス品質レベルをリカバーするための前記手段は、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するための手段を含み、
前記受信された第１の送信リクエスト・レスポンス信号の前記位相は、前記第１のサービス品質レベルを通信するために使用されている請求項３３の第１の通信デバイス。
［３５］前記第２のトラフィック送信リクエストは、第３の通信デバイスからであり、
前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするための手段は、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較するための手段を含み、
前記第２のサービス品質レベルは、前記第１の通信デバイスと前記第３の通信デバイスとの間のコネクションに対応する請求項３２の第１の通信デバイス。
［３６］第１の通信デバイスで使用されるコンピュータ・プログラム製品において、
少なくとも一つのコンピュータに、第１のトラフィック送信リクエスト信号に応答する第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーさせるためのコードと、
前記少なくとも一つのコンピュータに、前記リカバーされた第１のサービス品質レベルに基づいて、第２のトラフィック送信リクエスト信号に応答して第２の送信リクエスト・レスポンス信号を送信するか否かの決定をさせるためのコードとを含むコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品。
［３７］前記コンピュータ読み取り可能な媒体は、前記少なくとも一つのコンピュータに、アクセス・ルータから前記第１の送信リクエスト・レスポンス信号を受信させるためのコードを更に含み、
前記第１の送信リクエスト・レスポンス信号は、前記第１のトラフィック送信リクエスト信号に応答するものであり、
前記第１のトラフィック送信リクエスト信号は、第２の通信デバイスから前記第１のアクセス・ルータへ送信される請求項３６のコンピュータ・プログラム製品。
［３８］前記コンピュータ読み取り可能な媒体は、
前記少なくとも一つのコンピュータに、前記アクセス・ルータからパイロット信号を受信させるためのコードと、
前記少なくとも一つのコンピュータに、前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成させるためのコードとを更に含み、
前記少なくとも一つのコンピュータに前記第１のサービス品質レベルをリカバーさせるためのコードは、前記少なくとも一つのコンピュータに、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用させるためのコードを含む請求項３７のコンピュータ・プログラム製品。
［３９］前記第２のトラフィック送信リクエストは、第３の通信デバイスからであり、
前記少なくとも一つのコンピュータに前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をさせるためのコードは、前記少なくとも一つのコンピュータに、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較させるためのコードを含み、
前記第２のサービス品質レベルは、前記第１の通信デバイスと前記第３の通信デバイスとの間のコネクションに対応する請求項３６のコンピュータ・プログラム製品。

Claims

第１の通信デバイスを操作する方法において、
アクセス・ルータから第２の通信デバイスへ送信された送信リクエスト・レスポンス信号からサービス品質レベルをリカバーすることと、ここで、前記送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信されたトラフィック送信リクエストに対する応答信号である、
前記リカバーされたサービス品質レベルと、第３の通信デバイスに送信しようとするトラフィック・データのサービス品質レベルとに基づいて、前記第３の通信デバイスに、前記トラフィック・データを送信するか否かの決定をすることを含む方法。
前記サービス品質レベルを前記リカバーすることは、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーする請求項１の方法。
前記アクセス・ルータからパイロット信号を受信することと、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成することを更に含み、
前記サービス品質レベルを前記リカバーすることは、前記受信された送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用することを含む請求項１の方法。
前記送信するか否かの決定をすることは、前記リカバーされたサービス品質レベルを前記トラフィック・データに対応する前記サービス品質レベルと比較することを含む請求項１の方法。
前記送信するか否かの決定をすることは、送信されるべき前記トラフィック・データの前記サービス品質レベルが、前記リカバーされたサービス品質レベルより高い場合に、前記送信リクエスト・レスポンス信号の前記受信電力レベルにかかわりなく、送信すると決定することを更に含む請求項４の方法。
前記送信するか否かの決定をすることは、送信されるべき前記トラフィック・データの前記サービス品質レベルが、前記リカバーされたサービス品質レベルより低い場合に、前記送信リクエスト・レスポンス信号の受信電力レベルに基づいて及び干渉コスト推定に基づいて、送信するか否かを決定することを更に含む請求項４の方法。
前記送信リクエスト・レスポンス信号は、シングルトーン信号であり、
前記方法は、複数の異なる送信タイム・スロットにおいてトラフィック・データを送信するか否かについて複数の決定をすることを更に含む請求項１の方法。
第１の通信デバイスにおいて、
アクセス・ルータから第２の通信デバイスへ送信された送信リクエスト・レスポンス信号からサービス品質レベルをリカバーし、ここで、前記送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信されたトラフィック送信リクエストに対する応答信号である、
前記リカバーされたサービス品質レベルと、第３の通信デバイスに送信しようとするトラフィック・データのサービス品質レベルとに基づいて、前記第３の通信デバイスに、前記トラフィック・データを送信するか否かの決定をするように構成された少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサに接続されたメモリとを含む第１の通信デバイス。
前記少なくとも一つのプロセッサは、
前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーするように更に構成される請求項８の第１の通信デバイス。
前記少なくとも一つのプロセッサは、
前記アクセス・ルータからパイロット信号を受信し、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成し、
前記受信された送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するように更に構成される請求項８の第１の通信デバイス。
前記少なくとも一つのプロセッサは、前記リカバーされたサービス品質レベルを前記トラフィック・データに対応するサービス品質レベルと比較するように更に構成される請求項８の第１の通信デバイス。
第１の通信デバイスにおいて、
アクセス・ルータから第２の通信デバイスへ送信された送信リクエスト・レスポンス信号からサービス品質レベルをリカバーするための手段と、ここで、前記送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信されたトラフィック送信リクエストに対する応答信号である、
前記リカバーされたサービス品質レベルと、第３の通信デバイスに送信しようとするトラフィック・データのサービス品質レベルとに基づいて、前記第３の通信デバイスに、前記トラフィック・データを送信するか否かの決定をするための手段とを含む第１の通信デバイス。
前記サービス品質レベルをリカバーするための前記手段は、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーするための手段を更に含む請求項１２の第１の通信デバイス。
前記アクセス・ルータからパイロット信号を受信するための手段と、
前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成するための手段とを更に含み、
前記サービス品質レベルを前記リカバーするための前記手段は、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するための手段を含む請求項１２の第１の通信デバイス。
第１の通信デバイスで使用される非一時的なコンピュータ・プログラム製品において、
少なくとも一つのコンピュータに、アクセス・ルータから第２の通信デバイスへ送信された送信リクエスト・レスポンス信号からサービス品質レベルをリカバーさせるためのコードと、ここで、前記送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信されたトラフィック送信リクエストに対する応答信号である、
前記少なくとも一つのコンピュータに、前記リカバーされたサービス品質レベルと、第３の通信デバイスに送信しようとするトラフィック・データのサービス品質レベルとに基づいて、前記第３の通信デバイスに、前記トラフィック・データを送信するか否かの決定をさせるためのコードとを含む非一時的なコンピュータ読み取り可能な媒体を含むコンピュータ・プログラム製品。
前記少なくとも一つのコンピュータに前記サービス品質レベルをリカバーさせるための前記コードは、前記少なくとも一つのコンピュータに、前記送信リクエスト・レスポンス信号の位相から前記サービス品質レベルをリカバーさせるためのコードを含む請求項１５の非一時的なコンピュータ・プログラム製品。
第１の通信デバイスを操作する方法において、
アクセス・ルータから第２の通信デバイスへ送信された第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーすることと、ここで、前記第１の送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信された第１のトラフィック送信リクエスト信号に対する応答信号である、
前記リカバーされた第１のサービス品質レベルと、前記第１の通信デバイスと第３の通信デバイスとの間のコネクションに対応するサービス品質レベルとに基づいて、前記第３の通信デバイスから受信された第２のトラフィック送信リクエスト信号に応答して前記第３の通信デバイスに第２の送信リクエスト・レスポンス信号を送信するか否かの決定をすることを含む方法。
前記アクセス・ルータからパイロット信号を受信することと、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間のチャネルの推定を生成することを更に含み、
前記第１のサービス品質レベルをリカバーすることは、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用することを含む請求項１７の方法。
前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をすることは、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較することを含む請求項１７の方法。
前記送信するか否かの決定をすることは、前記第１の通信デバイスと前記第３の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質レベルより高い場合に、送信すると決定することを更に含む請求項１９の方法。
前記送信するか否かの決定をすることは、
前記第２のトラフィック送信リクエスト信号の受信電力に基づいて及び前記第１のトラフィック送信リクエスト信号の受信電力に基づいて、チャネル品質推定を生成することと、
前記第１の通信デバイスと前記第３の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質より低い場合に、前記生成されたチャネル品質推定に基づいて、送信するか否かを決定することを更に含む請求項１９の方法。
前記第１の送信リクエスト・レスポンス信号は、シングルトーン信号であり、
前記方法は、複数の異なる送信タイム・スロットにおいて送信リクエスト・レスポンス信号を送信するか否かについて複数の決定をすることを更に含む請求項１８の方法。
第１の通信デバイスにおいて、
アクセス・ルータから第２の通信デバイスへ送信された第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーし、ここで、前記第１の送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信された第１のトラフィック送信リクエスト信号に対する応答信号である、
前記リカバーされた第１のサービス品質レベルと、前記第１の通信デバイスと第３の通信デバイスとの間のコネクションに対応するサービス品質レベルとに基づいて、前記第３の通信デバイスから受信された第２のトラフィック送信リクエスト信号に応答して前記第３の通信デバイスに第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするように構成された少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサに接続されたメモリとを含む第１の通信デバイス。
前記少なくとも一つのプロセッサは、
前記アクセス・ルータからパイロット信号を受信し、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成し、
前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するように更に構成される請求項２３の第１の通信デバイス。
前記少なくとも一つのプロセッサは、前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をする場合に、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較するように更に構成される請求項２３の第１の通信デバイス。
前記少なくとも一つのプロセッサは、前記第３の通信デバイスと前記第１の通信デバイスとの間の前記コネクションに対応する前記第２のサービス品質レベルが、前記リカバーされた第１のサービス品質レベルより高い場合に、送信すると決定するように更に構成される請求項２５の第１の通信デバイス。
第１の通信デバイスにおいて、
アクセス・ルータから第２の通信デバイスへ送信された第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーするための手段と、ここで、前記第１の送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信された第１のトラフィック送信リクエスト信号に対する応答信号である、
前記リカバーされた第１のサービス品質レベルと、前記第１の通信デバイスと第３の通信デバイスとの間のコネクションに対応するサービス品質レベルとに基づいて、前記第３の通信デバイスから受信された第２のトラフィック送信リクエスト信号に応答して前記第３の通信デバイスに第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするための手段とを含む第１の通信デバイス。
前記アクセス・ルータからパイロット信号を受信するための手段と、
前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成するための手段とを更に含み、
前記第１のサービス品質レベルをリカバーするための前記手段は、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用するための手段を含み、
前記受信された第１の送信リクエスト・レスポンス信号の前記位相は、前記第１のサービス品質レベルを通信するために使用されている請求項２７の第１の通信デバイス。
前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をするための手段は、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較するための手段を含む請求項２７の第１の通信デバイス。
第１の通信デバイスで使用される非一時的なコンピュータ・プログラム製品において、
少なくとも一つのコンピュータに、アクセス・ルータから第２の通信デバイスへ送信された第１の送信リクエスト・レスポンス信号から第１のサービス品質レベルをリカバーさせるためのコードと、ここで、前記第１の送信リクエスト・レスポンス信号は、前記第２の通信デバイスから前記アクセス・ルータへ送信された第１のトラフィック送信リクエスト信号に対する応答信号である、
前記少なくとも一つのコンピュータに、前記リカバーされた第１のサービス品質レベルと、前記第１の通信デバイスと第３の通信デバイスとの間のコネクションに対応するサービス品質レベルとに基づいて、前記第３の通信デバイスから受信された第２のトラフィック送信リクエスト信号に応答して前記第３の通信デバイスに第２の送信リクエスト・レスポンス信号を送信するか否かの決定をさせるためのコードとを含むコンピュータ読み取り可能な媒体を含む非一時的なコンピュータ・プログラム製品。
前記非一時的なコンピュータ読み取り可能な媒体は、
前記少なくとも一つのコンピュータに、前記アクセス・ルータからパイロット信号を受信させるためのコードと、
前記少なくとも一つのコンピュータに、前記パイロット信号に基づいて、前記アクセス・ルータと前記第１の通信デバイスとの間の前記チャネルの推定を生成させるためのコードとを更に含み、
前記少なくとも一つのコンピュータに前記第１のサービス品質レベルをリカバーさせるためのコードは、前記少なくとも一つのコンピュータに、前記受信された第１の送信リクエスト・レスポンス信号の位相を解釈するために、前記生成されたチャネル推定を使用させるためのコードを含む請求項３０の非一時的なコンピュータ・プログラム製品。
前記少なくとも一つのコンピュータに前記第２の送信リクエスト・レスポンス信号を送信するか否かの決定をさせるためのコードは、前記少なくとも一つのコンピュータに、前記リカバーされた第１のサービス品質レベルを、第２のサービス品質レベルと比較させるためのコードを含む請求項３０の非一時的なコンピュータ・プログラム製品。