(57)【特許請求の範囲】
【請求項１】
複数のアクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）を備える通信ネットワークの端末（２００）から受信した信号を最適化する方法であって、前記端末（２００）はアクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）のうち第一のアクセス・ノード（１００−１）をサービング・アクセス・ノードとしており、
前記第一のアクセス・ノード（１００−１）により実行される、
前記端末（２００）からの第一の信号（１０−１）を受信するステップと、
前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）のうち第二のアクセス・ノード（１００−２、１００−３、１００−４）で前記端末（２００）から受信した第二の信号（１０−２、１０−３、１０−４）に関する情報を要求するため、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）にリクエスト（２２：２２'）を送信するステップと、
要求した情報（２４；２４'）を受信するステップと、
受信した前記第二の信号（１０−２、１０−３、１０−４）に関する情報と前記第一の信号（１０−１）に関する情報とに基づいて最適化した信号を決定するステップと
を含むことを特徴とする方法。
【請求項２】
前記決定するステップには、前記最適化した信号を生成するため、前記第一の信号（１０−１）に関する情報と前記第二の信号（１０−２、１０−３、１０−４）に関する情報とを合成するステップを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記決定するステップには、前記第一の信号（１０−１）に関する情報または前記第二の信号（１０−２、１０−３、１０−４）に関する情報を前記最適化した信号として選択するステップを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記リクエスト（２２；２２'）には要求された情報のタイプを特定する情報を含むことを特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
前記リクエスト（２２；２２'）には、前記第二の信号（１０−２、１０−３、１０−４）に関する専用の情報を特定するため、一つ以上のパラメータを含むことを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
更なる端末（２００'）からの信号（１０−２'）に関する情報を前記第二のアクセス・ノード（１００−２）から受信するステップを更に含み、
前記最適化した信号を決定するステップは、前記更なる端末（２００'）からの前記信号（１０−２'）に関する受信した前記情報に更に基づくことを特徴とする請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記リクエスト（２２'）には、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）において前記端末（２００）から前記第二の信号（１０−２、１０−３、１０−４）の後に受信した、少なくとも一つの更なる第二の信号（１０−２、１０−３、１０−４）に関する少なくとも一つの更なる情報を送るため、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）をトリガするための情報を含み、受信した少なくとも一つの更なる情報と、前記第一のアクセス・ノード（１００−１）において前記端末（２００）から前記第一の信号（１０−１）の後に受信した、少なくとも一つの更なる第一の信号（１０−１）に関する情報とに基づいて、前記第一のアクセス・ノード（１００−１）が少なくとも一つの更なる最適化した信号を決定することを特徴とする請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記第一のアクセス・ノード（１００−１）での前記第一の信号（１０−１）の受信の前に、前記リクエスト（２２；２２'）を送信することを特徴とする請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記第一のアクセス・ノード（１００−１）での前記第一の信号（１０−１）の受信の後に、前記リクエスト（２２；２２'）を送信することを特徴とする請求項１乃至７のいずれか一項に記載の方法。
【請求項１０】
前記第一のアクセス・ノード（１００−１）での信号を最適化するため、情報を獲得し、前記第一のアクセス・ノード（１００−１）に送るのに適する可能性のある一つ以上のアクセス・ノード（１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の集合（Ｅ２）を決定するステップを更に含み、前記集合（Ｅ２）には少なくとも前記第二のアクセス・ノード（１００−２、１００−３、１００−４）を含むことを特徴とする請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記端末（２００）から前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードへのリンクの特性と比較した、端末（２００）から前記第一のアクセス・ノード（１００−１）へのリンクの特性と、
前記第一のアクセス・ノード（１００−１）と、前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードとの間のリンクの特性と、
前記第一のアクセス・ノード（１００−１）の容量と、
前記端末（２００）および前記少なくとも一つの更なる端末（２００'）に対する前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードの関係と、
前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードの負荷と、
前記第一のアクセス・ノード（１００−１）の位置情報と関連した前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードの位置情報と、
前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセス・ノードに関する維持管理情報と、
前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）の中の少なくとも一つの更なるアクセスノードに関する事前の構成情報と
という選択基準の中の少なくとも一つに基いて、前記集合（Ｅ２）を決定することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記端末（２００）からの第二の信号（１０−２、１０−３、１０−４）に関する情報を獲得することおよび送ることまたはそのいずれかに関する一つ以上の条件を特定するための条件付き情報を獲得するステップと、
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）に前記条件付き情報を送信するステップとを更に含むことを特徴とする請求項１乃至１１のいずれか一項に記載の方法。
【請求項１３】
複数のアクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）を備える通信ネットワークの端末（２００）から受信した信号を最適化する方法であって、前記端末（２００）は前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）のうちの第一のアクセス・ノード（１００−１）をサービング・アクセス・ノードとしており、前記アクセス・ノード（１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０）のうちの第二のアクセス・ノード（１００−２、１００−３、１００−４）が実行する、
前記第一のアクセス・ノード（１００−１）からのリクエスト（２２；２２'）を受信するステップであって、前記リクエスト（２２；２２'）は前記第二のアクセス・ノード（１００−２、１００−３、１００−４）で前記端末から受信した信号（１０−２、１０−３、１０−４）に関する情報を要求するものであるステップと、
前記端末（２００）から信号（１０−２、１０−３、１０−４）を受信するステップと、
前記受信した信号（１０−２、１０−３、１０−４）から要求された情報を獲得するステップと、
前記要求された情報を前記第一のアクセス・ノード（１００−１）に送信するステップと
を含むことを特徴とする方法。
【請求項１４】
前記リクエスト（２２；２２'）には要求された情報のタイプを特定する情報を含み、前記要求された情報を前記タイプに応じて獲得することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記リクエスト（２２；２２'）には前記信号に関する専用の情報を特定するための一つ以上のパラメータを含み、前記専用の情報に従って前記要求された情報を獲得することを特徴とする請求項１３また１４に記載の方法。
【請求項１６】
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）で前記端末（２００）からの信号（１０−２、１０−３、１０−４）の後に受信した少なくとも一つの更なる信号（１０−２、１０−３、１０−４）に関する少なくとも一つの更なる情報を送信するため、当該リクエスト（２２'）には前記第二のアクセス・ノード（１００−２、１００−３、１００−４）をトリガする情報を含み、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）は少なくとも一つの更なる信号（１０−２、１０−３、１０−４）を受信し、要求された前記少なくとも一つの更なる情報を前記少なくとも一つの受信した更なる信号（１０−２、１０−３、１０−４）から獲得し、要求した前記少なくとも一つの更なる情報を前記第一のアクセス・ノード（１００−１）に送信することを特徴とする請求項１３乃至１５のいずれか一項に記載の方法。
【請求項１７】
更なる端末（２００'）からの信号（１０−２'）に関する情報を決定するステップと、
獲得した前記情報を前記第一のアクセス・ノード（１００−１）に送信するステップと
を更に含むことを特徴とする請求項１３乃至１６のいずれか一項に記載の方法。
【請求項１８】
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）での前記信号（１０−２、１０−３、１０−４）の受信の前に、前記リクエスト（２２；２２'）を受信することを特徴とする請求項１３乃至１７のいずれか一項に記載の方法。
【請求項１９】
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）での前記信号（１０−２、１０−３、１０−４）の受信の後に、前記リクエスト（２２；２２'）を受信し、
前記方法は、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）が受信した信号（１０−２、１０−３、１０−４）を記憶するステップを更に含むことを特徴とする請求項１３乃至１７のいずれか一項に記載の方法。
【請求項２０】
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）が、前記第一のアクセス・ノード（１００−１）で信号を最適化するため、情報を獲得し、前記第一のアクセス・ノード（１００−１）に送信することに適する可能性があるかどうかを、前記第一のアクセス・ノード（１００−１）が決定できるようにするのに適した情報を、前記第二のアクセス・ノード（１００−２、１００−３、１００−４）から前記第一のアクセス・ノードに送信するステップを更に含むことを特徴とする請求項１３乃至１９のいずれか一項に記載の方法。
【請求項２１】
前記第一のアクセス・ノード（１００−１）が決定できるようにするのに適した情報が、
前記端末（２００）から前記第二のアクセス・ノード（１００−２、１００−３、１００−４）へのリンクの特性と、
前記第一のアクセス・ノード（１００−１）と前記第二のアクセス・ノード（１００−２、１００−３、１００−４）との間のリンクの特性と、
前記端末（２００）への前記第二のアクセス・ノード（１００−２、１００−３、１００−４）と少なくとも一つの更なる端末（２００'）との関係と、
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）の負荷と、
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）の位置情報と、
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）に関する維持管理情報と、
前記第二のアクセス・ノード（１００−２、１００−３、１００−４）に関する事前の構成情報と
の中の少なくとも一つを示すことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記第二の信号（１０−２、１０−３、１０−４）に関する情報を獲得することおよび送信することまたはそのいずれかに関する一つ以上の条件を特定する条件付き情報を獲得するステップと、
前記特定した一つ以上の条件に基づいて獲得することおよび送信することを実行するステップとを更に含むことを特徴とする請求項１３乃至２１のいずれか一項に記載の方法。
【請求項２３】
請求項１乃至１２のいずれか一項に記載の方法のステップを実行する第一のアクセス・ノード。
【請求項２４】
請求項１３乃至２２のいずれか一項に記載の方法のステップを実行する第二のアクセス・ノード。
【請求項２５】
前記第一のアクセス・ノードの処理ユニットにロード可能なコンピュータ・プログラムであって、
請求項１乃至１２のいずれか一項に記載の方法のステップを実行するためのコードを含むことを特徴とするコンピュータ・プログラム。
【請求項２６】
前記第二のアクセス・ノードの処理ユニットにロード可能なコンピュータ・プログラムであって、
請求項１３乃至２２のいずれか一項に記載の方法のステップを実行するためのコードを含むことを特徴とするコンピュータ・プログラム。
【請求項２７】
請求項２５または請求項２６に記載のコンピュータ・プログラムを記録したコンピュータ可読媒体。
【請求項２８】
請求項１乃至１２のいずれか一項に記載の方法のステップを実行する第一のアクセス・ノードと、請求項１３乃至２２のいずれか一項に記載の方法のステップを実行する第二のアクセス・ノードとを備える通信ネットワーク。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば、移動通信ネットワークにおける基地局または基地局部分のようなアクセス・ノードの上りリンクの協力のための技法に関する。
【背景技術】
【０００２】
一般に、セルラ・システムは同一チャネル干渉に悩まされている。例えば、同時送信は、同じ物理リソースを使用する可能性があり、それ故相互干渉を発生する。この同一チャネル干渉は、信号対干渉雑音比（ＳＩＮＲ）として測定される可能性のある信号品質を低下させる。同時に、この低下した信号品質はシステム容量を削減する。
【０００３】
例えば、基地局（ＢＳ）のようなアクセス・ノードをもっと濃い密度で配備した、またはより高いユーザの密度を有する第３世代パートナーシップ・プロジェク・ロング・ターム・エボリューション（３ＧＰＰ  ＬＴＥ）および高度化３ＧＰＰ  ＬＴＥのような将来の無線ネットワークは、恐らく、干渉で制限を受ける状態が残るであろう。
【０００４】
ＥＰ１７１４５１８Ｂ１で説明している概念により、幾つかの受信ノードで受信した受信（Ｒｘ）信号を収集することが可能となる。本Ｒｘ信号は、ソフト複素ベースバンド信号、即ち、圧縮量子化同相／直角位相（ＩＱ）サンプルまたは、既検出ストリームを相殺した残留ソフト複素ベースバンド信号であってもよい。収集したＲｘ信号は、同一チャネル干渉を相殺するように合同で処理される。更に、幾つかの受信ノードでの合同受信は、キャリア信号の信号強度を増加させる可能性がある。
【０００５】
更に、例えば高度化３ＧＰＰ  ＬＴＥでは、ＢＳを協力させるという方法を使用すべきであるという提案が存在する。この方法では、複数のＢＳからＲｘ信号を収集する。しかしながら、ＢＳを協力させるグループをどれだけ多く確立し、協力ＢＳ間でどれだけの信号を交換する可能性があるか、全く詳細が与えられていない。例えば、同一チャネル干渉を相殺するため、干渉ストリームを復号化し、再符号化しなければならない。そうするためには、ある送信パラメータが必要とされる。ＥＰ１７１４５１８Ｂ１で説明されているメッセージ交換は、必要な送信パラメータを考慮していない。
【０００６】
加えて、ＢＳの協力には協調するＢＳを必要とし、その協調は、上りリンク（ＵＬ）データ・トラヒックのスケジューリングに統合される必要がある。更に、中央ノードでＲｘ信号を収集することは、本中央ノードが利用できない可能性があるか、重い負荷がある場合、問題があり得る。また、通信ネットワークの全てのＢＳ間でＲｘ信号を交換することは、それが本ＢＳ、同じく相互接続する任意のネットワーク・ノードまたはその他のネットワーク構成要素に重い負荷となるので、問題がある。
【０００７】
従って、前述の問題点を克服し、少なくとも第二のアクセス・ノードのサポートで第一のアクセス・ノードでの端末から信号を効率的に受信することを可能とする技法が必要である。
【発明の概要】
【課題を解決するための手段】
【０００８】
上記の必要性をかなえることが、本発明の目的である。独立の特許請求項による方法とデバイスにより、これを達成する。従属の特許請求項は本発明の更なる実施形態を定める。
【０００９】
本発明の一つの側面によれば、複数のアクセス・ノードを備える通信ネットワークの端末から受信した信号を最適化するための方法が提供される。本端末はアクセス・ノードのうちの第一のアクセス・ノードと関連する。本方法によれば、第一のアクセス・ノードは端末から第一の信号を受信する。更に、第一のアクセス・ノードは、第二のアクセス・ノードで本端末から受信した第二の信号に関する情報を要求するため、本アクセス・ノードの第二のアクセス・ノードにリクエストを送る。要求された情報は第一のアクセス・ノードが受信する。受信した情報と第一の信号に関する情報とに基づき、第一のアクセス・ノードは最適化された信号を決定する。
【００１０】
本発明の更なる側面によれば、複数のアクセス・ノードを備える通信ネットワークの端末から受信した信号を最適化するための方法が提供される。本端末はアクセス・ノードのうちの第一のアクセス・ノードと関連する。本方法によれば、アクセス・ノードのうちの第二のアクセス・ノードは、第一のアクセス・ノードからリクエストを受信する。本リクエストは第二のアクセス・ノードで端末から受信した信号に関する情報を要求する。第二のアクセス・ノードは端末から信号を受信し、受信した信号から要求された情報を獲得する。第二のアクセス・ノードは第一のアクセス・ノードに要求された情報を送る。
【００１１】
本発明の更なる側面によれば、上記で説明した方法における第二のアクセス・ノードとして動作するよう適応させたアクセス・ノードが提供される。
【００１２】
本発明の更なる側面によれば、複数のアクセス・ノードを備える通信ネットワークにおける第一のアクセス・ノードの処理ユニットに負荷を加えることのできる、コンピュータ・プログラムが提供される。第一のアクセス・ノードは端末と関連する。この側面によれば、コンピュータ・プログラムは次のステップを実行するよう適応した符号を備える。
−端末から第一の信号を受信するステップ、
−、第二のアクセス・ノードで本端末から受信した第二の信号に関する情報を要求するため、本アクセス・ノードの第二のアクセス・ノードにリクエストを送るステップ、
−要求された情報を受信するステップ、および
−受信した情報と第一の信号に関する情報とに基づき、最適化した信号を決定するステップ。
【００１３】
本発明の更なる側面によれば、複数のアクセス・ノードを備える通信ネットワークにおける第二のアクセス・ノードの処理ユニットに負荷を加えることのできる、コンピュータ・プログラムが提供される。複数のアクセス・ノードには、端末に関連する第一のアクセス・ノードを備える。この側面によれば、コンピュータ・プログラムには次のステップを実行するよう適応した符号を備える。
−第二のアクセス・ノードで端末から受信した信号に関する情報を要求するリクエストを第一のアクセス・ノードから受信するステップ、
−本端末から信号を受信するステップ、
−受信した信号から要求された情報を獲得するステップ、そして
−要求された情報を第一のアクセス・ノードに送るステップ。
【００１４】
本発明の更なる側面によれば、上記の実施形態のいずれか一つによるコンピュータ・プログラムを備える、コンピュータ読取可能な媒体が提供される。
【００１５】
本発明の更なる側面によれば、第一のアクセス・ノードと第二のアクセス・ノードとを備える、通信ネットワークが提供される。以下のステップを実行するよう、第一のアクセス・ノードを適応させる。
−端末から第一の信号を受信するステップ、
−第二のアクセス・ノードで本端末から受信した第二の信号に関する情報を要求するため、第二のアクセス・ノードにリクエストを送るステップ、
−本要求された情報を受信するステップ、そして
−受信した情報と第一の信号に関する情報とに基づき、最適化された信号を決定するステップ。
以下のステップを実行するよう、第二のアクセス・ノードを適応させる。
−第一のアクセス・ノードから本リクエストを受信するステップ、
−本端末から第二の信号を受信するステップ、
−第二の信号から要求された情報を獲得するステップ、そして
−要求された本情報を第一のアクセス・ノードにおくるステップ。
【００１６】
ここで、当然のことながら、上記で説明した順序または異なる順序でステップを実行してもよい。
【図面の簡単な説明】
【００１７】
【図１】本発明の実施形態による概念を適用できる通信ネットワーク環境を概略的に示す。
【図２】本発明の実施形態による通信ネットワークにおけるデバイスの実装を概略的に示す。
【図３】本発明の実施形態による通信ネットワークにおけるデバイスの更なる実装を概略的に示す。
【図４】本発明の実施形態によるアクセス・ノード間のＵＬ協力のための処理の第一の例を概略的に示す。
【図５】本発明の実施形態によるアクセス・ノード間のＵＬ協力のための処理の第二の例を概略的に示す。
【図６】本発明の実施形態によるアクセス・ノード間のＵＬ協力のための処理の第三の例を概略的に示す。
【図７】一つの端末と、本端末に関するＵＬ協力のためにアクセス・ノードの集合を選択した、アクセス・ノードの集合体とを概略的に示す。
【図８】図７の選択したアクセス・ノードの集合と、本集合のアクセス・ノードと本端末との間の通信とを概略的に示す。
【図９】本発明の実施形態による方法を示すフローチャートを示す。
【図１０】本発明の実施形態による更なる方法を示すフローチャートを示す。
【発明を実施するための形態】
【００１８】
以下で、分散型制御を有する、アクセス・ノード、特に基地局のオン・デマンド上りリンク協力のための方法、デバイスおよびコンピュータ・プログラムに関する典型的な実施形態を参照して、本発明について更に詳細に説明する。
【００１９】
ＢＳまたはＢＳの一部分でアクセス・ノードを具体化することができる。更に、またアクセス・ノードはｅ−Ｎｏｄｅ−Ｂ（ｅＮＢ）であってもよい。ＢＳの一部分は、セルラ無線周波数（ＲＦ）通信ネットワークのひとつのセル領域をカバーするユニットと見なしてもよい。そのようなユニットには、通常は、一つ以上のアンテナ、フィルタおよび電力増幅器または低雑音増幅器のようなＲＦ部分、および信号処理手段を備える。例えば、第一のＢＳと第二のＢＳや、第一のＢＳの第一の部分と第一のＢＳの第二の部分、または第一のＢＳの第一の部分と第二のＢＳの第二の部分のような、少なくとも二つのアクセス・ノードを介して、協力的信号通信を達成してもよい。また、ＢＳ対ＢＳ協力を基地局間協力またはｅＮＢ間協力と、そしてまた、同じ基地局の部分対部分協力を基地局内協力またはｅＮＢ内協力と呼称してもよい。
【００２０】
以下の実施形態の説明では、用語"アクセス・ノード"と"基地局"を同意語的方法で使用する。これは読み易さと図示的理由で行なうものであり、部分対部分協力を、それが同じ基地局どうしであっても、または異なる基地局間であっても、以下の実施形態に適用可能であるということから除外することを意味しない。
【００２１】
以下で説明する概念によれば、第一のアクセス・ノードがオン・デマンド・ベースでＲｘ信号に関する情報を一つ以上の更なるアクセス・ノードから集めることができる方式が提案される。アクセス・ノードは、ＢＳ、例えば、ＬＴＥ  ＢＳ、またはひとつのＢＳの部分または多数のＢＳの部分であってもよい。幾つかの実施形態によれば、選択した更なるアクセス・ノードの集合に向けて第一のアクセス・ノードが開始し、それによって更なるアクセス・ノードが受信したＲｘ信号に関する情報を要求する、リクエスト−レスポンス機構により、これを達成できる。その他の実施形態によれば、アクセス・ノードはＲｘ信号に関する情報をその他のアクセス・ノードに公表するよう提示する、サブスクライブ−パブリッシュ機構を使用してもよい。ここで、当然のことながら、リクエスト−レスポンス機構では、第一のアクセス・ノードは第二のアクセス・ノードにリクエスト・メッセージを発行し、第二のアクセス・ノードは第一のアクセス・ノードにレスポンス・メッセージを送って応答するであろう。サブスクライブ−パブリッシュ機構では、第一のアクセス・ノードが第二のアクセス・ノードにサブスクライブ・メッセージを送ると、第二のアクセス・ノードは第一のアクセス・ノードに公表する情報を送るであろうが、これは、第一のアクセス・ノードが第二のアクセス・ノードにサブスクライブ解除・メッセージを送るまで数回発生する可能性がある。上記の機能のため、レスポンス・メッセージとサブスクライブ・メッセージの両方を、第二のアクセス・ノードからの情報に対するリクエストと見なしてもよい。それ故、サブスクライブ−パブリッシュ機構を、リクエスト、即ち、サブスクライブ・メッセージの後に一つ以上の応答、即ち、パブリッシュ・メッセージが続く、リクエスト−レスポンス機構と見なしてもよい。Ｒｘ信号に関して要求された情報は、任意のタイプを持つことができ、そのタイプには例えば、ＩＱサンプル、例えば対数尤度比（ＬＬＲ）形式のソフト・ビットとも称される復調したビットのソフト値、例えばハード・ビット形式の復号化ビットなどがある。
【００２２】
第一のアクセス・ノードは、信号の協力送信および受信またはそのいずれかに参加するよう、最も有望な更なるアクセス・ノード、例えば、同一チャネルＢＳを選択できる。幾つかの実施形態では、第一のアクセス・ノードは、通信ネットワークと端末との通信を制御するサービングＢＳであってもよく、典型的には制御機能を全く持たない支援ＢＳとしてサービスするよう、同一チャネルＢＳから更なるアクセス・ノードを選択する。本方式は、ＢＳ間の動的な、要求に応じた協力を可能にし、干渉キャンセル（ＩＣ）のために要求される追加のパラメータを交換することを可能にし、そして、中央制御ノードを必要とせずに分散型制御のもとで動作可能とする。最終的には、３ＤＰＰ  ＬＴＥが定める定常的ＢＳ  ＵＬスケジューリングに情報交換を統合可能とする。協力および非協力送信および受信またはそのいずれかは同時に起こることができる。
【００２３】
例えば、端末からＲｘ信号を受信した後に、サービング・アクセス・ノードがサポーティング・アクセス・ノードからの情報を要求する反応的方法、および、端末からＲｘ信号を受信する前に、サービング・アクセス・ノードがサポーティング・アクセス・ノードからの情報を要求する先行的方法により、提示の方式は多数のモードの動作を可能にすることができる。
【００２４】
ある実施形態によれば、先行的方法は以下のように働いてもよい。ＢＳは、実際の送信に先立ってそのＢＳがサービスする特定のユーザ装置（ＵＥ）のために、協力の必要性を特定する。"サービングＢＳ"は、そのＵＳをサポートできる可能性のある一つ以上の候補ＢＳ（"サポーティングＢＳ"）を特定する。特定のリソース、例えば、ＬＴＥ物理リソース・ブロック（ＲＢ）でそのＵＥをスケジューリングした後、サービングＢＳは一つ以上の可能性のあるサポーティングＢＳから要求されたＲｘ信号を要求する。サポーティングＢＳは要求されたＲｘ信号で応答する。リクエストおよびレスポンスまたはそのいずれかには、例えば同一チャネルＩＣのための追加のパラメータを備えてもよい。
【００２５】
反応的方法を適用する場合、失敗した復号化試行（ｆａｉｌｅｄ  ｄｅｃｏｄｉｎｇ  ａｔｔｅｍｐｔ）に基づき、協力のための要求をトリガしてもよい。反応的方法におけるメッセージ交換は、先行的方法における交換と類似しているが、Ｒｘ信号の受信に関係する要求の送信タイミングは異なる。
【００２６】
もしサポーティングＢＳが、要求されたサポートを提供できないなら、それは要求を拒否できる。サービングＢＳがもはや協力を必要としないなら、それは同様に要求を拒否できる。
【００２７】
以下に、本発明の実施形態について、添付の図面を参照してもっと詳細に説明する。
【００２８】
図１は、本発明の実施形態による概念を適用してもよい、移動通信ネットワーク環境を示す。例えば、移動通信ネットワーク環境はＬＴＥネットワークであってもよい。移動通信ネットワーク環境には複数のアクセス・ノード１００−１、１００−２、１００−３および移動端末２００を備える。以下では、アクセス・ノード１００−１、１００−２、１００−３は通信ネットワークのＢＳであると仮定する。しかしながら、当然のことであるが、本アクセス・ノードはまた、同じＢＳまたは異なるＢＳの部分であってもよい。端末２００は移動電話機、携帯型コンピュータまたはその他の形式のユーザ装置（ＵＥ）であってもよい。それ故、以下では、本端末はまたＵＥとも参照されるであろう。
【００２９】
ＢＳ１００−１、１００−２、１００−３は、ＢＳ１００−１と端末２００間の第一の通信経路、ＢＳ１００−２と端末２００間の第二の通信経路、ＢＳ１００−３と端末２００間の第三の通信経路のような異なる通信経路で、通信信号１０を送信すること、即ち、送信することおよび受信することまたはそのいずれかにより、端末２００と協力的に通信してもよい。ＢＳの一つ、例えば、ＢＳ１００−１はサービングＢＳであってもよく、その他のＢＳ，例えば、ＢＳ１００−２、ＢＳ１００−３はサポーティングＢＳであってもよい。また、ＢＳ１００−１，１００−２、１００−３による通信信号１０の協力的受信をＵＬ協力を呼んでもよく、一方、また、ＢＳ１００−１，１００−２、１００−３からの通信信号の協力的送信をＤＬ協力と呼んでもよい。通信信号１０を協力的に受信するため、ＢＳ１００−１，１００−２、１００−３は端末２００からの個々のＲｘ信号に関する情報を交換する、例えば、サポーティングＢＳ１００−２は端末からのＲｘ信号に関する情報をサービングＢＳ１００−１に送信してもよく、そしてサポーティングＢＳ１００−３は端末２００からのＲｘ信号に関する情報をサービングＢＳ１００−１に送信してもよい。この目的のため、ＢＳ１００−１，１００−２、１００−３は協力信号２０を、例えば、トラスポート・ネットワークを介して交換する。
【００３０】
当然のことであるが、任意の数のＢＳが協力的受信に参加できる可能性がある。例えば、一個のみのサポーティングＢＳがあり得るであろうし、または二個、三個、四個またはもっと多くのサポーティングＢＳがあり得るであろう。
【００３１】
図２は、アクセス・ノードのＵＬ協力に関する本発明の実施形態による、デバイスの典型的実装を概略的に示す。更に図２はまた、これらデバイス間の通信を示す。図２で、図１のそれらと類似の要素は、同じ参照符号で指定されている。それ故、これらの要素に関する追加の情報は、図１に関連する上記の説明から獲得される。
【００３２】
図２に、例えばサービングＢＳのようなサービング・アクセス・ノード（ＢＳ１）１００−１、例えばサポーティングＢＳのようなサポーティング・アクセス・ノード（ＢＳ２）、および端末またはＵＥ２００を示す。当然のことであるが、アクセス・ノードはまた、同じＢＳまたは異なるＢＳの部分であってもよい。以下では、サービング・アクセス・ノード１００−１はまた第一のアクセス・ノードまたは第一のＢＳと呼称してもよく、サポーティング・アクセス・ノード１００−２はまた第二のアクセス・ノードまたは第二のＢＳと呼称してもよい。例えば、一つ以上の選択基準により、端末２００からの信号受信を最適化するために、サービング・アクセス・ノード１００−１との協力にサポーティング・アクセス・ノード１００−２を選択してしまってもよい。
【００３３】
図示的理由のため、例えば、サービング・アクセス・ノードとこれらの一つ以上の更なるアクセス・ノードとの間に全くリンクが存在しないので、選択される可能性があるかまたはないような、一つ以上の可能性のある更なるサポーティング・アクセス・ノード、またはサポートに全くふさわしくないような一つ以上の更なるアクセス・ノードは示されていない。アクセス・ノード１００−１、１００−２に、または任意の更なるアクセス・ノードに関連する可能性のある、可能性のある更なる端末も同様に示されていない。サポーティング・アクセス・ノード１００−２に関連することができ、端末２００からの信号と干渉する信号を送ることができる可能性のある更なる端末との状況について、図３と関連して、以下に説明する。そのような状況では、サービング・アクセス・ノード１００−１とサポーティング・アクセス・ノード１００−２との間で交換した選択的パラメータにより、例えば、リクエスト・メッセージおよびレスポンス・メッセージまたはそのいずれかにおいて、干渉信号を軽減するか、除去さえすることが可能であってもよい。
【００３４】
更に、注意すべきことであるが、例えばアクセス・ノード１００−１、１００−２のうちの一つのようなアクセス・ノードは、特定の端末のためのサービング・アクセス・ノードであることができ、一方、それはもう一つの端末のためのサポーティング・アクセス・ノードである。もし本端末が移動し、更なるアクセス・ノードが本サービング・アクセス・ノードの役割を肩代わりするなら、前のサービング・アクセス・ノードはサポーティング・ノードの役割を肩代わりしてもよく、またはもはや協力のために考慮されなくてもよい。
【００３５】
個々のデバイス１００−１、１００−２、１００−３各々には、送信ユニットまたは送信器を示すＴで始まるサブユニット、受信ユニットまたは受信器を示すＲで始まるサブユニット、処理ユニットまたはプロセッサを示すＰで始まるサブユニット、および記憶ユニットまたはメモリを示すＳで始まるサブユニットを有する一つ以上のサブユニットを備える。
【００３６】
端末２００には、サービング・アクセス・ノード１００−１に信号１０−１と、サポーティング・アクセス・ノード１００−２に信号１０−２とを送るための送信ユニットＴ３１を備える。実際には、信号１０−１と信号１０−２は、一つの送信（Ｔｘ）信号のみとして、端末２００、即ち、送信ユニットＴ３１により通常は送信される。端末２００の、通常は無指向的なアンテナとチャネル特性とにより、サービング・アクセス・ノード１００−１はＲｘ信号１０−１として、サポーティング・アクセス・ノード１００−２はＲｘ信号１０−２として、Ｔｘ信号を受信する。通常は、移動電話機または同様なものであってもよい端末２００には、図示のような更なるユニット、例えば、点線の矢印が示すように、サービング・アクセス・ノード１００−１からの、またはサポーティング・アクセス・ノード１００−２からのメッセージ１２を受信するための受信ユニットＲ３１と、情報とメッセージとを処理するための処理ユニットＰ３と、情報を記憶し、検索するために記憶ユニットＳ３とを備える。当然のことであるが、ここで説明する概念のためには、受信ユニットＲ３１はオプションである。しかしながら、移動電話機のような殆んどの端末にはそのような受信ユニットを備えるであろう。それにもかかわらず、端末２００は受信機能を持たない送信器であるが、送信ユニットＴ３１に加えて、処理ユニットＰ３および記憶ユニットＳ３またはその一方を、いまだオプションとして備える、ということはまたあり得ることである。
【００３７】
サービング・アクセス・ノード１００−１には、受信ユニットＲ１１を備え、サポーティング・アクセス・ノード１００−２には、端末２００からそれぞれ信号１０−１と１０−２を受信するため、受信ユニットＲ２１を備える。ここで当然のことであるが、ここに示されてはいないが、可能性のある更なる端末から信号を受信するため、受信ユニットＲ１１、Ｒ２１をまた使用してもよい。通常は、例えば、端末２００に、またはここに示されていないが更なる端末に、信号を送信するため、サービング・アクセス・ノード１００−１には送信ユニットＴ１１を更に備え、サポーティング・アクセス・ノード１００−２には送信ユニットＴ２１を更に備える。当然のことであるが、ここで説明する概念のためは、送信ユニットＴ１１とＴ２１はオプションである。しかしながら、ＬＴＥ  ＢＳのような殆んどのアクセス・ノードには、とにかく端末と双方向の通信のためにそのような送信ユニットを備えるであろう。それにもかかわらず、アクセス・ノード１００−１およびアクセス・ノード１００−２またはその一方は、端末２００に関して、送信機能を持たない受信器として実装されているが、一方、それらは、例えば、リクエス・メッセージ２２とサブスクライブ・メッセージ２２'とレスポンス・メッセージ２４／２４'のような信号を交換するため、お互いに向かって送信能力と受信能力を提供するものである。更に図示するように、アクセス・ノード１００−２には、処理ユニットＰ２と記憶ユニットＳ２とを備えてもよい。同様に、アクセス・ノード１００−２には、処理ユニットＰ１と記憶ユニットＳ１とを備えてもよい。それ故、アクセス・ノード１００−１には、交換し、受信した情報を処理するための処理能力およびデータを記憶するための記憶能力またはその一方もまた、提供してもよい。
【００３８】
加えて、サービング・アクセス・ノード１００−１には、例えばサポーティング・アクセス・ノード１００−２のようなその他のアクセス・ノードに信号を送信するため、送信ユニットＴ１２と、例えばサポーティング・アクセス・ノード１００−２のようなその他のアクセス・ノードから信号を受信するために、受信ユニットＲ１２とを備える。同様にサポーティング・アクセス・ノード１００−２には、例えばサービング・アクセス・ノード１００−１のようなその他のアクセス・ノードに信号を送信するため、送信ユニットＴ２２と、例えばサービング・アクセス・ノード１００−１のようなその他のアクセス・ノードから信号を受信するために、受信ユニットＲ２２とを備える。それ故、送信ユニットＴ１２と受信ユニットＲ１２は、例えばサポーティング・アクセス・ノード１００−２のようなその他のアクセス・ノードに関するサービング・アクセス・ノード１００−１のインタフェースを、そしてサービング・アクセス・ノード１００−１のようなその他のアクセス・ノードに関するサポーティング・アクセス・ノード１００−２のインタフェースを提供する。
【００３９】
その送信ユニットＴ１２を使用して、例えばリクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'をサポーティング・アクセス・ノード１００−２に送ることにより、端末２００からサポーティング・アクセス・ノード１００−２で受信した信号１０−２に関する情報を、サポーティング・アクセス・ノード１００−２から要求することができる。リクエスト・メッセージ２２とサブスクライブ・メッセージについては、以下で更に説明する。サポーティング・アクセス・ノード１００−２はその受信ユニットＲ２１を介して信号１０−２を受信する。受信した信号１０−２から要求された情報を獲得するよう、処理ユニットＰ２を適応させる。サポーティング・アクセス・ノード１００−２は、更に以下で説明するように、例えばレスポンス・メッセージ２４またはパブリッシュ・メッセージ２４'で、サービング・アクセス・ノード１００−１の受信ユニットＲ１２に、その送信ユニットＴ２２を介して要求された情報を送ることができる。サポーティング・アクセス・ノード１００−２から受信した要求された情報と、サービング・アクセス・ノード自身が受信した信号１０−１に関する対応する情報とに基づいて達成される、端末からの最適化されたＲｘ信号を決定するよう、サービング・アクセス・ノードの処理ユニットＰ１を適用させる。
【００４０】
送信ユニットＴ１２と受信ユニットＲ２２は、例えばケーブルと直接的に、または、例えば任意の無線または有線のトラスポート・ネットワークを通して中間スイッチングおよびルーティング・ノードまたはその一方と間接的に接続されていてもよい。同様に、送信ユニットＴ２２と受信ユニットＲ１２は、例えばケーブルと直接的に、または、例えば任意の無線または有線のトラスポート・ネットワークを通して中間スイッチングおよびルーティング・ノードまたはその一方と間接的に接続されていてもよい。
【００４１】
その結果、サービング・アクセス・ノード１００−１とサポーティング・アクセス・ノード１００−２は、例えばケーブルまたはファイバのような専用の物理接続を介して、サービング・アクセス・ノード１００−１とサポーティング・アクセス・ノード１００−２とを直接的に接続して通信してもよい。もう一つの例によれば、サポーティング・アクセス・ノード００−１とサポーティング・アクセス・ノード１００−２は、スイッチイングした、またはルーティングした通信ネットワークを介して、中間スイッチイングまたはルーティング・ノードと通信してもよい。ここで説明する概念を実装するために適切なアクセス・ノードの相互接続の例は、３ＧＰＰ  ＬＴＥ仕様書によるインタフェースＸ２であり、これは基本的なトラスポート・ネットワークと独立なＩＰベースのインタフェースである。
【００４２】
受信ユニットＲ１１とＲ１２は、異なる通信技術を使用してもよく、例えば、送信ユニットＴ３１を介して端末２００と通信するためには、ＬＴＥのような無線通信技術を使用してもよく、送信ユニットＴ２２を介してサポーティング・アクセス・ノード１００−２と通信するためには、イーサネット（登録商標）のような有線通信技術を使用してもよい。同じことが、送信ユニットＴ１１とＴ１２に、同様にサポーティング・アクセス・ノード１００−２の対応するユニットＲ２１とＲ２２またはＴ２１とＴ２２のために適用する。しかしながら、受信ユニットＲ１１とＲ１２が、例えば両方とも無線であるが、更に一つの受信ユニットの中に合成されている、同じ通信技術からできているというような実装はあり得る。同じことが、送信ユニットＴ１１とＴ１２に、同様にサポーティング・アクセス・ノード１００−２の対応するサブユニット、即ち、受信ユニットＲ２１とＲ２２または送信ユニットＴ２１とＴ２２に適用してもよい。受信ユニットＲ１１と送信ユニットＴ１１、受信ユニットＲ１２と送信ユニットＴ１２、受信ユニットＲ２１と送信ユニットＴ２１、受信ユニットＲ２２と送信ユニットＴ２２、または受信ユニットＲ３１と送信ユニットＴ３１のよに、同じデバイスにおいて受信ユニットと対応する送信ユニットとを、送受信ユニットまたはトランシーバに合成してもよい。
【００４３】
図３は、本発明の実施形態によるデバイスの更なる典型的な実装を概略的に示す。加えて、またこれらのデバイス間の通信をも示す。図３では、図１と２のそれらと類似の要素は同じ参照符号で示した。それ故、これらの要素に関する追加の情報は、図１と２に関連する上記の説明から獲得可能である。図２に比較して、端末２００に加えて、更に端末２００'があるような状況を示している。更なる端末２００'は、例えば図２に関連して示し、説明したように、端末２００と同様な構造と機能を持ってもよい。以下では、端末２００はまた第一の端末と呼称し、更なる端末２００'もまた第二の端末と呼称する。
【００４４】
図２の状況におけるように、第一のアクセス・ノード１００-１は第一の端末２００から信号１０−１を受信し、第二のアクセス・ノードは第一の端末２００から信号１０−２を受信する。更に、第一のアクセス・ノード１００-１は第二の端末２００'から信号１０−１'を受信し、第二のアクセス・ノード１００−２は第二の端末２００'から信号１０−２'を受信する。
【００４５】
第一の端末２００については、第一のアクセス・ノード１００−１はサービング・アクセス・ノードである。言い換えれば、端末２００は第一のアクセス・ノード１００−１と関連し、第二のアクセス・ノード１００−２はサポーティング・アクセス・ノードである。更に、第二のアクセス・ノード１００−２は第二の端末２００'のためのサービング・アクセス・ノードである。言い換えれば、もし第二のアクセス・ノード１００−２が第二の端末２００'のためのサービング・アクセス・ノードであるなら、第二の端末は第二のアクセス・ノード１００−２と関連する。その他のシナリオでは、第二のアクセス・ノード１００−２は第二の端末２００'のためのサポーティング・アクセス・ノードであってもよい。
【００４６】
第一のアクセス・ノード１００−１は、例えばリクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'を第二のアクセス・ノード１００−２に送ることにより、第二のアクセス・ノード１００−２から信号１０−２に関する情報を要求してもよい。信号１０−２を受信する第二のアクセス・ノードは、例えば第一のアクセス・ノード１００−１からのリクエストにおける一つ以上のパラメータおよびタイプ情報またはそのいずれかに従って、信号１０−２に関する情報を獲得する。更に、第二のアクセス・ノード１００−２は、第二の端末２００'から信号１０−２'に関する情報を獲得することができる。もし第二のアクセス・ノード１００−２が第二の端末２００'のためのサービング・アクセス・ノードであるならば、第二のアクセス・ノード１００−２は受信した信号１０−２'から要求された情報を獲得しなければならないということは必ずしもないが、第二の端末２００'と交換した信号の変調方式または符号速度のような通信パラメータが記憶されている、記憶装置またはメモリから本情報を決定してもよい。
【００４７】
次に、第二のアクセス・ノード１００−２は、信号１０−２に関する情報と信号１０−２'に関する情報とを含むレスポンスを、第一のアクセス・ノード１００−１に送ることができる。上記で述べたように、受信した信号１０−２'からかまたは、第二のアクセス・ノード１００−２が第二の端末２００'のためのサービング・アクセス・ノードである場合は、記憶装置またはメモリから、後者の情報を獲得してもよい。信号１０−２に関する情報と信号１０−２'に関する情報は、単一のレスポンス・メッセージ２４またはパブリッシュ・メッセージ２４'で、または分離したレスポンス・メッセージ２４または分離したパブリッシュ・メッセージ２４'で送られてもよい。リクエスト・メッセージ２２、サブスクライブ・メッセージ２２'、レスポンス・メッセージ２４、またはパブリッシュ・メッセージ２４'に関する詳細について、以下で説明する。
【００４８】
第二のアクセス・ノード２００'による更なる端末２００'からの信号１０−２'に関する情報の獲得と送信は、第一のアクセス・ノード１００−１からのリクエストによってトリガされてもよく、例えば、本リクエストには、更なる端末２００'からの信号１０−２'に関する専用の情報を特定するため、タイプ情報または一つ以上のパラメータを追加で含んでもよい。或いは、本リクエストには、そのような付加的リクエスト情報を含まなくてもよい。後者の代替案では、例えば、一般的に任意の更なる端末からの任意の信号のため、または、もし更なる端末からの信号が所定の閾値に合致するなら、または位置ベースの情報に基づくなら、例えば、信号干渉がより大きな影響を与える可能性のある、第一のアクセス・ノード１００−１と第二のアクセス・ノード１００−２のサービスエリアの各々の端に近接して位置する第一の端末２００と第二の端末２００'のために、更なる端末２００'からの信号１０−２'または更なる端末からの信号に関するそのような情報を獲得し、第一のアクセス・ノード１００−１に送るよう、第二のアクセス・ノード１００−２を構成してもよい。
【００４９】
次に第一のアクセス・ノード１００−１は、信号１０−１に関する情報、信号１０−２の関する受信した情報および信号１０−２'に関する受信した情報に基づいて、最適化した信号を決定できる。もし第一のアクセス・ノード１００−１で受信した信号が信号１０−１と１０−１'の重畳であるなら、これは役に立つことであり得る。実施形態によれば、例えば干渉除去（ＩＣ）機構により、信号１０−１から信号１０−１'を除去または軽減するため信号１０−２'に関する情報を使用して、最適化した信号を決定する。加えて、信号１０−１に関する情報と信号１０−２に関する情報とを合成すること、または信号１０−１に関する情報と信号１０−２に関する情報との中の一つを選択することは、更なる最適化をもたらすことができる。
【００５０】
図２と３に関する上記説明は、基地局間協力の視点で書かれたものである。部分対部分協力のためには、参照符号１００−１は第一の部分を、そして参照符号１００−２は第二の部分を意味してもよい。もしアクセス・ノード１００−１と１００−２は単一の基地局の部分であるなら、インタフェースＲ１２、Ｔ１２、Ｒ２２、Ｔ２２は、例えば同じ基地局ラックの二枚の処理ボード間の通信のための、基地局の内部的インタフェースであってもよい。この場合、送信および受信ユニットＲ１２、Ｔ１２と送信および受信ユニットＴ２２、Ｒ２２の（図示のような）結合は、基地局サーバ・ラックのバックプレーンを介して、または、もし二つの部分が同じ物理的場所に位置するなら、コンピュータ・バスを介してであってもよい。
【００５１】
以下で、上記で説明したデバイスと関連して使用される可能性のある、本発明の実施形態による処理について説明する。
【００５２】
図４は、ここではサービングＢＳと表現する第一のアクセス・ノード１００−１と、ここではサポーティングＢＳと表現するサポーティング・アクセス・ノードとの間のＵＬ協力の処理の第一の例を概略的に示す。当然のことであるが、第一のアクセス・ノード１００−１と第二のアクセス・ノード１００−２はまた、同じＢＳの異なる部分または異なるＢＳの部分である可能性がある。更に、当然のことであるが、一つ以上のサポーティング・アクセス・ノード００−２が提供される可能性がある。
【００５３】
ＵＥ２００はサービングＢＳ１００−１に関連する。サービングＢＳ１００−１はＵＥ２００を制御し、通信のためにリソースを配分する。これはスケジューリング・ステップ１１０の一部であってもよい。ＵＥ２００はすでにＵＬ協力の候補として確認されていた。ＵＥ２００にあるリソース・ブロック（ＲＢ）を配分したあと、サービングＢＳ１００−１は、リクエスト・メッセージ（ｒｅｑ）２２をサービングＢＳ１００−２に送ることにより、特定のＵＥ２００に関するサポーティングＢＳ１００−２からのサポートの要求を行なう。リクエスト・メッセージ２２は、例えば、Ｒｘ信号１０−２に関する情報が、例えばＩＱサンプル、ＬＬＲのような復調した符号化データ（ソフト・ビット）、ハード・ビットのような復号化したユーザ・データ等のどのタイプか示す。更に、リクエスト・メッセージ２２には要求されたＲｘ信号１０−２を届けるために要求される、例えばタイム・スロット、送信時間間隔（ＴＴＩ）および受信すべきＲＢ、またはサポーティングＢＳ１００−２での干渉除去（ＩＣ）のパラメータのような追加のパラメータを備えることができる。リクエスト・メッセージ２２におけるパラメータの更に詳細な例を以下に提供する。
【００５４】
示したＲＢで、受信ステップ１２０−２が示すように、サポーティングＢＳ１００−２はＵＥ２００からＲｘ信号１０−２を受信する。受信ステップ１２０−１におけるサービングＢＳ１００−１で、ＵＥ２００からのＲｘ信号１０−１を受信する。Ｒｘ信号に関する情報の要求されたタイプに依存して、サポーティングＢＳ１００−２は、ＢＳ別処理ステップ１３０−２が示すように、ＵＥ２００から受信するようにＲｘ信号１０−２を処理する必要があってもよい可能性がある。典型的には、サポーティングＢＳ１００−２におけるＢＳ別ベースでの処理は、例えばＢＳ別処理ステップ１３０−１で実行されるように、サービングＢＳ１００−１におけるＢＳ別ベースで処理することに類似であろう。例えばもし復号化ユーザ・データを要求するなら、サポーティングＢＳ１００−２は、ＵＥ２００から受信したようにＲｘ信号１０−２を復調し、復号する。ＢＳ別ベースでの処理の更に詳細な例を以下に与える。
【００５５】
ＢＳ別処理の後、サポーティングＢＳ１００−２は、要求された情報を有するレスポンス・メッセージ（ｒｓｐ）、即ち、リクエストで指定したようなタイプを持つＲｘ信号１０−２をサービングＢＳ１００−１に送ることにより応答する。或いは、サポーティングＢＳ１００−２はまた、関係するタイプの情報で応答してもよい。追加として、サポーティングＢＳ１００−２は、サービングＢＳ１００−２が使用するパラメータ、例えばサービングＢＳ１００−２でのＩＣに使用するパラメータを送信することができる。サービングＢＳ１００−１で合同処理に使用することができる、レスポンス・メッセージ２４における情報とパラメータのより詳細な例を以下に与える。
【００５６】
サポーティングＢＳ１００−２から要求された情報を受信した後、サービングＢＳ１００−１は自身およびサポーティングＢＳ１００−２が受信したＲｘ信号を合同で処理できる。これは、合同処理ステップ１３０で達成される。要求されたＲｘ信号１０−２のタイプに依存して、サービングＢＳ１００−１は、例えば、成功裏に符号化したビット・ストリーム（選択合成）を選択でき、符号化ソフト・ビットのソフト合成を行なうことができ、または、干渉排除合成か、ＩＱサンプル交換の場合はＩＣかを行なうことができる。結果として、サービスＢＳ１００−１は端末２００から受信した信号１０−１と１０−２のベースで、最適化した信号を決定する。
【００５７】
上記で、一つのみのサポーティングＢＳ１００−２に対して本協力方法を概説する。もしサービスＢＳ１００−１が多数のサポーティングＢＳを特定したなら、提示する方法は各々のサポーティングＢＳに対して個別に実行される。即ち、サービングＢＳ１００−１は各々のサポーティングＢＳに協力を要求する。ユニキャスト・メッセージとして、マルチキャスト・メッセージとして、または環境に依存して、ブロードキャスト・メッセージとしてさえ、リクエスト・メッセージ２２を送信することができる。各サポーティングＢＳは、例えばリクエスト中で特定されたタイプを持つＲｘ信号のような要求された情報で応答する。更に、各サポーティングＢＳは本リクエストを取り消すか無視できる。サポーティングＢＳ１００−２はまた、要求されたタイプの情報でなく、関連のタイプで応答する。例えば、サービングＢＳ１００−１は、復号化ビットを要求してもよいが、例えば低い受信品質のため、または復号化能力の欠如にため、サポーティングＢＳ１００−２はＲｘ信号１０−２を復号化できないので、復調化ビットのソフト値で応答してもよい。関連のタイプの情報はまだ、サービングＢＳ１００−１で信号を最適化する場合に助けとなる。最終的には、サービングＢＳ１００−１での合同処理は、それ自身のアンテナおよびサポーティング・ノードで受信Ｒｘ信号を合成し、処理する。
【００５８】
リクエスト・メッセージ２２またはレスポンス・メッセージ２４で交換する全てのパラメータまたは情報は、実際のメッセージ交換の前に圧縮され、実際のメッセージ交換の後に解凍されてもよい。ここでは、注意すべきことであるが、圧縮は、典型的には追加の時間遅延をもたらし、これは幾つかの場合には望ましくない可能性がある。
【００５９】
提示した方式は、手順を制御する中央ノードを必要としない。サービングＢＳがサポートを要求するときは何時でも、最適な同一チャネルＢＳからそれを要求する。以下で更に説明するように、一つ以上の適当なサポーティングＢＳを選択する方法が幾つかある。
【００６０】
図４の処理では、サービングＢＳ１００−１がＢＳ別ベースでそれ自身のＲｘ信号１０-１の処理を実行する前に、即ち、サービングＢＳ１００−１がＲｘ信号１０−１を受信する前に、協力を要求する。上記で述べたように、この方法は先行的方法と呼称してもよい。反応的方法と呼称してもよい、別の方法は、図５の処理によって使用される。図５では、図４のそれらに対応する要素は、同じ参照符号によって指定した。
【００６１】
反応的方法に対応する図５の処理において、サービングＢＳ１００−１でのＢＳ別処理の後に、即ち、サービングＢＳ１００−１でのＲｘ信号１０−１の実際の受信の後に、協力を要求する。これは、例えばもしサービングＢＳ１００−１自身の復号化試行が失敗した場合、役に立つことである。サポーティングＢＳ１００−２または多数のサポーティングＢＳから、例えばＩＱサンプルの形式のＲｘ信号１０−２のような要求された情報を受信した後、サービングＢＳ１００−１は、ＵＥ２００からのＲｘ信号１０−１を復号化する第二の試行を行なってもよい。この目的のため、サービングＢＳ１００−１に、ある時間の間Ｒｘ信号１０−２を記憶してもよい。同様に、サポーティングＢＳ１００−２に、ある時間の間Ｒｘ信号１０−２を記憶してもよい。例えば、要求された情報をＲｘ信号１０−１、１０−２から獲得してしまうまで、Ｒｘ信号の受信からある期間、Ｒｘ信号１０−１およびＲｘ信号１０−２またはそのいずれかを記憶してもよい。反応的方法により、サービングＢＳ１００−１とサポーティングＢＳ１００−２との間で交換するデータ量を削減することができる。
【００６２】
サポーティングＢＳ１００−１とサービングＢＳ１００−２の両方により、図４または図５で示す協力の処理を取り消してもよい。例えば、レスポンス２４を受信してしまう前にサービングＢＳ１００−１で復号化が成功した場合、サービングＢＳ１００−１はサポーティングＢＳ１００−２に取消メッセージを送ることができる可能性がある。
【００６３】
幾つかの理由で、サポーティングＢＳ１００−２はリクエストを無視することができる可能性がある。例えば、サポーティングＢＳ１００−２は本リクエストを単純に無視することができる可能性があるか、潜在的取消メッセージを送ることができる可能性がある。取消メッセージには取り消しの理由を含ませることが可能性がある。例えばサポーティングＢＳ１００−２での不成功なＢＳ別処理または、バックホール容量、即ち、サポーティングＢＳ１００−２からサービングＢＳ１００−１へデータを送信するために利用可能な容量が飽和した場合、サポーティングＢＳ１００−２は本リクエストを無視することができる可能性がある。
【００６４】
上記で説明したメッセージ交換のより、サービングＢＳ１００−１が、どのような環境で本リクエストを無視すべきかを明確に示すことがまさに可能である。そのような表示の幾つかの例が可能である。一つの例によれば、もしサポーティングＢＳ１００−２セルで進行する同時送信が全く無い場合、より高い品質でサポーティングＢＳ１００−２で信号を受信する。それ故、もし表示したＢＳで同時送信が全く無い場合のみ、サービングＢＳ１００−１は協力を要求できる可能性がある。リクエスト・メッセージ２２でこの例外を表示するか、または事前に構成してもよい。更なる例によれば、協力受信の処理がどれだけ重要か、または価値あることかを表示できる可能性がある。例えば、高価な会員権を有する"ゴールド・ユーザ"は、安価な会員権を有するベスト−エフォート・ユーザより高い優先度を得てもよい。サポーティングＢＳ１００−２が、処理できない多数のリクエストを受信する場合、サポーティングＢＳ１００−２は最低の優先度を有するリクエストを放棄してもよい。
【００６５】
それ故、上記の概念に従って、幾つかの実施形態では、サポーティングＢＳ１００−２は、ＵＥ２００からＲｘ信号１０−２に関する情報を獲得することおよび送ることまたはそのいずれかに関する、一つ以上の条件を特定する条件付き情報を獲得してもよい。次に、サポーティングＢＳは、本条件付き情報に基づいて、要求された情報を獲得するステップおよび送るステップまたはそのいずれかを実行してもよい。サポーティングＢＳ１００−２で、例えば、維持管理（Ｏ＆Ｍ）手段を介して、本条件付き情報を事前に構成してもよい。或いは、または追加して、条件となる本情報をサービングＢＳ１００−１から受信できる。一つの例によれば、本条件付き情報は、例えば、サポーティングＢＳ１００−２のセルにおける同時送信に依存して、本リクエストを無視してもよい上記の例におけるように、もっと一般的規模およびもっと長期で適用可能である。しかしながら、更なる例によれば、本条件付き情報は、例えば、高価な会員権を持つユーザおよび安価な会員権を持つユーザの上記の例におけるように、特定の信号または加入者または特定の端末を参照する。後者の例では、Ｒｘ信号に関する情報のためのリクエストを介して、条件付き情報を表示することは利点のある可能性があり、これを、サービングＢＳ１００−１からサポーティングＢＳ１００−２に送る。言い換えれば、リクエストに本条件となる情報を含めてもよい。
【００６６】
図４と図５で示す処理は、リクエスト−レスポンス機構に基づき、その中でサービングＢＳはリクエスト・メッセージを送り、サポーティングＢＳは要求された情報を含むレスポンス・メッセージで応答する。幾つかの実施形態では、サブスクライブ−パブリッシュ機構でリクエスト−レスポンス機構を置き換えてもよい。図６に対応する処理を示す。
【００６７】
サブスクライブ−パブリッシュ機構に基づく図６の処理では、ＢＳ１００−２は、その"サービス"に加入した全ての人々に受信したＲｘ信号１０−２を公表することを申し出る。例えば、実装した受信器アルゴリズム、バックホール制約、アンテナ数等のＢＳ１００−２の能力と一緒に、本申し出を、その他のＢＳに直接的に、または通信ネットワークのＯ＆Ｍシステムに公表してもよい。着目したサービングＢＳ１００−１は、例えば "ＩＱサンプル移動"のような提供したサービスに加入し、次に提供するＢＳ１００−２はサポーティングＢＳ１００−２になる。この目的のため、サービングＢＳ１００−１はサポーティングＢＳ１００−２にサブスクライブ・メッセージ（ｓｕｂ）２２'を送り、次にサポーティングＢＳは要求された情報を含む少なくとも一つのパブリッシュ・メッセージ（ｐｕｂ）２４'をサービングＢＳ１００−１に送る。Ｒｘ信号１０−２に関する、更に更新した情報を伴って、数回パブリッシュ・メッセージ２４'送ってもよい。サポーティングＢＳ１００−２に非サブスクライブ・メッセージ２６を送るサービングＢＳ１００−１に応答して、パブリッシュ・メッセージ２４' を送ることを停止してもよい。ここで注意すべきことであるが、本処理では、サブスクライブ・メッセージ２２'をＲｘ信号１０−２に関する情報に対するリクエストと見なしてもよい。
【００６８】
サブスクライブ・メッセージ２２'には、図４と図５に関連して説明したリクエスト・メッセージの一部でもある、全ての関連の情報またはパラメータを含めてもよい。パブリッシュ・メッセージ２４'には、例えばＩＱサンプルの形式で、Ｒｘ信号１０−２と、同じく、図４と５に関連して説明したレスポンス・メッセージの一部でもある、追加のパラメータとを含めてもよい。
【００６９】
サポーティングＢＳ１００−２が提供するサービスへのサービングＢＳ１００−１の加入は、その特別のサポーティングＢＳ１００−２の、例えばＩＱサンプルのようなＲｘ信号１０−２に関する情報がもはや必要とされない場合、取り消されてもよい。この目的のため、サービングＢＳ１００−１は非サブスクライブ・メッセージ２６を送ってもよい。代わりとして、または追加で、その他の取消し手順を使用してもよい。
【００７０】
サブスクライブ−パブリッシュ機構により、例えば、ＴＴＩのシーケンスでＲＢを配分する持続的スケジューリングのため、削減したオーバヘッドを有するＢＳ間の長期関係を確立することができる。
【００７１】
以下では、サポーティングＢＳ１００−２でＲｘ信号１０−２に関して要求された情報のタイプのいろいろな選択について説明する。
【００７２】
第一の選択によれば、ベースバンド信号を要求してもよい。この場合、サービングＢＳ１００−１は、サポーティングＢＳでＲｘ信号１０−２のベースバンド表現を要求してもよい。例えば、ベースバンド表現には、アンテナ要素当りの量子化ＩＱを備えてもよい。直交周波数分割多重（ＯＦＤＭ）信号またはシングルキャリア周波数分割多元接続（ＳＣ−ＦＤＭＡ）信号では、ベースバンド表現には、物理層で実行する高速フーリエ変換（ＦＦＴ）動作の出力を備えてもよい。
【００７３】
ＩＱサンプルを含むＲｘ信号１０−２のベースバンド表現を配信するため、サポーティングＢＳ１００−２は、ＩＱサンプルを要求するタイム・スロット（ＴＴＩ）とサブキャリア（ＲＢ）を知る必要がある。サービングＢＳ１００−１からのリクエストに、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'に、両方のパラメータを含めてもよい。ＢＳ別処理の一部として、サポーティングＢＳ１００−２はまた、サービングＢＳ１００−１に情報を転送する前に、そのＲｘ信号１０−２から任意の既知の、恐らく復号化された信号を除去してもよい。
【００７４】
例えばＩＱサンプルのようなＲｘ信号１０−２のベースバンド表現を受信した後、サービングＢＳ１００−１は、例えば干渉阻止合成（ＩＲＣ）技術により、Ｒｘ信号１０−１、１０−２を合同で処理でき、それによって、最適化した信号を決定する。幾つかの実施形態では、マルチーユーザ検出（ＭＵＤ）、特にＩＣを、更に性能を改善するため使用してもよい。また、サービングＢＳ１００−１からのリクエストには、サービングＢＳ１００−１で実行される、例えばＩＣのようなＭＵＤ形式の表示器を備えてもよい。
【００７５】
干渉キャンセル（ＩＣ）を行なうため、サービングＢＳ１００−１は、サポーティングＢＳ１００−２（図３の典型的な状況においては、信号１０−２'として）で受信されることを意図した、干渉する同一チャネル・ストリーム（例えば、図３の信号１０−１'）を復調し、復号化する必要がある。幾つかの場合では、同一チャネル・ストリームはまた、再符号化され、再変調される必要があってもよい。干渉する同一チャネル・ストリームを復調し、符号化するため、サービングＢＳ１００−１は、ＵＥ２００における送信器で使用するパラメータについての追加的情報を必要としてもよい。ＬＴＥ通信ネットワークの例では、これらのパラメータは、変調方式、符号速度、ＵＥ固有のスクランブリング、インターリービングおよびパンクチァリング方式、および再送信の場合の冗長バージョンである。復号化と再符号化のために、サービングＢＳ１００−１は、ＵＥ２００が送信する参照シンボルを通して集めることができる、チャネル状態情報を必要としてもよい。その結果、幾つかの実施形態では、特定の送信のために使用するＵＥ固有のＵＬ参照シンボルを交換する。サービングＢＳ１００−１とサポーティングＢＳ１００−２での部分的に重畳しているＲＢ配分の場合、サービングＢＳ１００−１は、干渉するストリームを送信した全てのＲＢのＩＱサンプルを必要としてもよい。この場合、サポーティングＢＳ１００−２は、同様にこれらのＲＢのためＩＱサンプルを送るであろう。図４−６で表示するように、サポーティングＢＳ１００−２からの応答に、即ち、レスポンス・メッセージ２４'またはパブリッシュ・メッセージ２４'に全ての追加のパラメータを挿入する。
【００７６】
第二の選択によれば、ソフト・ビットとも呼称される、復調したビットのソフト値を要求してもよい。ソフト値は、符号化ビットまたは復号化ビットと呼称してもよい。この場合、サービングＢＳ１００−１は、サポーティングＢＳ１００−２で受信するＵＥ２００からのＲｘ信号１０−２のソフト・ビットを要求してもよい。ソフト・ビットは、物理層における復調器からの出力である、典型的な量子化配置点である。更にまた、ソフト・ビットは、ターボ復号器内部の畳み込み復号器で利用可能である。これらのビットは、ターボ原理によりインターリーブされるが、しかしながら、これらのソフト・ビットはまた、その他のＢＳと交換され得る可能性がある。そのような復号器では、ビットの対数尤度比（ＬＬＲ）表現をしばしば使用する。しかしながら、ビットのその他の表現も同様に使用してもよい。
【００７７】
ソフト・ビットを配信するため、サポーティングＢＳ１００−２は、ソフト・ビットを要求するタイム・スロット（ＴＴＩ）と加入者（ＲＢ）を知る必要があってもよい。それ故、サービングＢＳ１００−１からのリクエスト、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'にこれらのパラメータを含めてもよい。
【００７８】
更に、Ｒｘ信号１０−２の復調を実行するため、ＵＥ２００に適用した変調方式がサポーティングＢＳ１００−２で必要である。復調の前に、等化は参照シンボルを通じて得られたチャネル知識を必要とする可能性がある。それ故に、例えばサービングＢＳ１００−１からサポーティングＢＳ１００−２へのリクエストにおいて、ＵＥ固有のＵＬ参照シンボルを交換してもよい。ターボ復号器ソフト・ビットの交換の場合、ＵＥ固有のスクランブリングに関するパラメータ、インターリービングとパンクチァリング方式（速度整合）および符号速度を、同様に交換してもよい。上記で説明したパラメータは、サービングＢＳ１００−１からのリクエスト、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'に含めてもよい。
【００７９】
サポーティングＢＳ１００−２からの要求された情報を受信した後、サービングＢＳ１００−１はサポーティングＢＳ１００−２の受信したソフト・ビットとそれ自身のソフト・ビットと合成し、それによって最適化した信号を決定する。
【００８０】
復号を改善するため、サポーティングＢＳ１００−２はそれ自身のＵＥ、即ち、復号の前に、サポーティングＢＳ１００−２がサービスしたＵＥのＲｘ信号（例えば、図３の信号１０−２'）を取り消すことができる可能性がある。このタイプのＩＣは追加のパラメータ交換を全く必要としない。
【００８１】
第三の選択によれば、復号化ビットを要求してもよい。ハード・ビットとして、そのような複合化ビットを要求してもよい。この場合、サービングＢＳ１００−１はＵＥ２００の復号化ビットを要求してもよい。物理層の復号器が復号化ハード・ビットを出力してもよい。交換した復号化ビットの有効性を保証するため、巡回冗長検査（ＣＲＣ）をサービングＢＳ１００−１で実行する。
【００８２】
復号化ビットを配信するため、サポーティングＢＳ１００−２は、復号化ビットを要求する、例えばＴＴＩのようなタイム・スロットと、例えばＲＢのようなサブキャリアとを知ることが必要であってもよい。それ故、サービングＢＳ１００−１からのリクエスト、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'にこれらのパラメータを含めてもよい。
【００８３】
ＵＥ２００からのＲｘ信号１０−２を復調し、復号化するため、サポーティングＢＳ１００−２は、ＵＥ２００で使用するパラメータに関する追加の情報を必要としてもよい。ＬＴＥ通信ネットワークの例では、これらのパラメータは次のものであってもよい。変調方式、符号速度、ＵＥ固有のスクランブリング、ＵＥ固有のＵＬ参照シンボル、インターリービングおよびパンクチァリング方式（速度整合）。ハイブリッド自動再送要求（ＨＡＲＱ）再送信では、同様に冗長バージョンを必要としてもよい。選択的には、サービングＢＳ１００−１は前に受信した冗長バージョンをサポーティングＢＳ１００−２に送信することができる可能性がある。サービングＢＳ１００−１からのリクエスト、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'に全てのパラメータを含めてもよい。
【００８４】
サポーティングＢＳ１００−２からの要求された情報を受信した後、サービングＢＳ１００−１は、それ自身の復号化ビットとサポーティングＢＳ１００−２の復号化ビットとの選択合成を実行でき、それによって最適化した信号を決定する。
【００８５】
復号化を改善するため、復調の前に、それ自身のＵＥ、即ち、サポーティングＢＳ１００−２がサービスするＵＥのＲｘ信号（例えば、図３の信号１０−２'）を取り消すことができる可能性がある。ＩＣのこのタイプは追加のパラメータ交換を全く必要としない。多数のリクエストの場合には、更なるＲｘ信号の復号化を改善するため、すでに復号化したストリームのＲｘ信号を成功裏に取り消すことができ可能性がある。このタイプのＩＣに必要なパラメータは、典型的には、サービングＢＳ１００−１からのリクエスト、即ち、リクエスト・メッセージ２２またはサブスクライブ・メッセージ２２'にすでに含まれるであろう。
【００８６】
以下に、本発明の実施形態によるサポーティングＢＳの選択のための処理について、更に説明する。
【００８７】
通信信号の協力的送信または受信のために、サポーティングＢＳとして、どのＢＳが参加すべきかを決定することは望ましいことである。典型的には、例えばＵＥ２００への無線リソース制御（ＲＲＣ）シグナリング接続、またはＵＥ２００へのその他の任意の種類の特別な関連を持つＢＳのようなサービングＢＳ１００−１で、この決定を行なう。
【００８８】
一つ以上のサポーティングＢＳを実際に選択する前に、サービングＢＳ１００−１は協力を必要とするＵＥ２００を特定する。そのようなＵＥ２００はセル端にあり、低いキャリア強度および高い同一チャネル干渉またはそのいずれかに悩まされている可能性がある。更に、そのようなＵＥ２００は、データを送信するのに緊急の必要性を持つことができ、例えば、スケジューリング・リクエストまたはバッファ状態報告等を、サービングＢＳ１００−１にすでに送信完了していてもよい。
【００８９】
協力を必要とする各々のＵＥ２００のために、サービングＢＳ１００−１は可能性のあるサポーティングＢＳの集合を集めることができる。この目的のために、それは、可能性のあるハンドオーバ候補のＢＳを特定するために、ＵＥ２００の確定した測定報告を使用することができる。それ故、典型的には、本測定報告は、可能性のあるハンドオーバ・ターゲットのＢＳであるＢＳを示すであろう。しかしながら、ここで、測定報告はまた、ＵＥ２００でその信号をあるレベルの品質内で受信するＢＳを特定する役目を果たしてもよい。典型的には、可能性のある協力ＢＳの集合をそれから決定できるサービングＢＳ１００−１に、正常な間隔でそのような測定報告を送る。
【００９０】
例えば、本測定報告は、所定のＵＥ２００に向かう最良の無線チャネルを持つＢＳを表示してもよい。その結果、可能性のあるハンドオーバ候補として資格のある、表示されたＢＳの全ては、時々アクティブな集合と呼称されるが、可能性のあるサポーティングＢＳのリストに含めてもよい。可能性のあるサポーティングＢＳのリストは、代わりにまたは追加して、ＢＳの位置情報に基いていてもよい可能性があり、それはＢＳの配置構造および物理的接続に基いていてもよい可能性があり、それはＯ＆Ｍシステムによって構成されていてもよい可能性があり、またはそれはシステム設置の間に事前に構成されていてもよい可能性がある。
【００９１】
更に、可能性のあるサポーティングＢＳのリストを削減することができる、即ち、以下のステップの一つ以上を適用し、以下の特性の一つ以上を評価して、事前の選択を実行できる。
【００９２】
−サポーティングＢＳへの無線リンク品質がサービングＢＳへのリンク品質に近い場合、協力受信は特に有益である。それ故、Ｒcで示す可能性のある同一チャネルＢＳと、Ｒsで示すサービングＢＳとの間の信号品質の差異（ΔＲＳＳ）が、サポーティングＢＳを選択する一つのパラメータとして役目を果たせる可能性がある。幾つかの実施形態によれば、そのΔＲＳＳが或る閾値ΔＲＳＳthresh以下、即ち、|Ｒs−Ｒc|＜ΔＲＳＳthreshの関係を満たすようなＢＳに候補のリストを削減する。
【００９３】
−ＢＳはそれらのバックホール・トラスポート・リンクに関する種々の制限を持っていてもよく、例えば、幾つかはファイバを介して、その他は有線接続を介して（例えば、Ｅ１を介して）、幾つかは、例えば自己バックホーリング（例えば、ＬＴＥリンクを介して）のような無線接続さえ介して、接続されていてもよい。それ故、可能性のあるサポーティングＢＳのバックホール制限は、サポーティングＢＳを選択するパラメータとして役目を果たしてもよい。それ故、幾つかの実施形態によれば、協力によりそのバックホールが追加の負荷に耐えるようなＢＳに、候補のリストを削減してもよい。例えば３ＧＰＰ仕様によるＢＳ間インタフェースＸ２のようなＢＳ−ＢＳインタフェースを介して、あるＢＳの現在利用可能なバックホール容量についての情報を交換できる可能性がある。例えば、ハンドオーバの間にこれを達成できる可能性があるか、Ｏ＆Ｍシステムがこれを提供できる可能性がある。ファイバでは数Ｇｂｐｓ、ＤＳＬでは数百Ｍｂｐｓ、マイクロ波では数十Ｍｂｐｓ、または専用線では数Ｍｂｐｓの可能性がある最大バックホール容量を、システム設定時に事前に構成さえできる可能性がある。
【００９４】
サービングＢＳ１００−１のバックホール容量は、同様に制限要因であってもよい可能性がある。もっと多くのサポーティングＢＳがサービングＢＳ１００−１と協力すれば、サービングＢＳ１００−１はもっと多くのデータを受信しなければならない。それ故、サービングＢＳ１００−１のバックホール制限は、サポーティングＢＳ数を制限するパラメータとしても役目を果たす可能性がある。その結果、サービングＢＳ１００−１のバックホール容量が処理できるＢＳの最大数に候補のリストを制限する。
【００９５】
−無線通信プロトコルには、典型的には、例えばＨＡＲＱおよび自動再送要求（ＡＲＱ）フィードバックまたは再送信、測定報告、ランダム・アクセスまたは同様なものに関する、多かれ少なかれ各種の厳密なタイミング制約を含む。協力通信は、基本的には、厳しい同じタイミング制約を満足させなければならない。それ故、バックホール情報交換の待ち時間は、サポーティングＢＳを選択するパラメータとして役目を果たすことができる。それ故、幾つかの実施形態によれば、その待ち時間（または協力のための接続を提供するトラスポート・ネットワークの待ち時間）がある制限値以下であるＢＳに、候補のリストを削減してもよい。厳密な制限は、所定のＢＳが直接的な物理リンクを持つ同一チャネルＢＳとのみ協力する状況をもたらしてもよい。待ち時間についての情報は、Ｏ＆Ｍシステムが提供できる可能性があり、またはシステム設定で事前に構成できる可能性がある。ＩＰネットワークでは、例えば、インターネット制御メッセージ・プロトコル（ＩＣＭＰ）エコ・リクエスト・パケットを可能性のあるサポーティングＢＳに送ることにより、そしてＩＣＭＰ"エコー応答"（"ping"としても知られる）に聞き耳を立てることにより、サービングＢＳ１００−１は往復時間を集めることができる。代わりにまたは追加して、サービングＢＳ１００−１は、例えば３ＧＰＰ仕様によるＢＳ間インタフェースＸ２のようなＢＳ−ＢＳインタフェースを介して、通信の間にその他のＢＳに関する応答時間を測定することができる。例えば、ハンドオーバの間にこれを達成してもよい。
【００９６】
−一つ以上のＵＥが協力を要求するなら、可能性のあるサポーティングＢＳの集合はお互いに影響しあう可能性がある。例えば、もし同一チャネルＢＳが異なる二個の集合の一部である場合、両方のＵＥのためにこのＢＳと協力することは有益であってもよい可能性がある。この場合、交換したリクエストとレスポンス、即ち、リクエスト・メッセージ２２とレスポンス・メッセージ２４、またはサブスクライブ・メッセージ２２'とパブリッシュ・メッセージ２４'は、両方のＵＥの情報を同時に運んでもよいので、シグナリング・オーバヘッドは減少してもよい。
【００９７】
−典型的には、例えばＲｘ信号、復調したビットまたは符号化ビットのような交換情報がより役立つならば、サポーティングＢＳで受信する間、信号品質はより高い。例えば、もしサポーティングＢＳのセル内で進行している同時送信がまったく無いなら、信号品質は高い可能性がある。同様に、もし、ＵＥからのＲｘ信号に対する干渉の原因となる同時送信がサポーティングＢＳのセル内であるなら、信号品質は低い可能性がある。サポーティングＢＳの負荷によって同時送信の確率を近似できる。それ故、幾つかの実施形態によれば、可能性のあるサポーティングＢＳの集合を削減する測定値として、ＢＳの負荷を使用してもよい。そのセル負荷が、あるスレッショウルド以上である候補ＢＳの全てを、候補集合から除去してもよい。ＢＳ−ＢＳインタフェースを介して、同一チャネル・セルのセル負荷を集めることができる可能性がある。３ＧＰＰが指定するセル間干渉協調（ＩＣＩＣ）方式により、可能性のあるサポーティングＢＳのリストを削減するために同様に使用してもよい、セル負荷表示器を交換できる。
【００９８】
当然のことであるが、ベンダ／通信事業者の優先度に基いて、または実装に基いて、上記に説明したステップの順序を変更することができ、または上記で説明したステップの幾つかのみを使用してもよい。
【００９９】
その結果、サービングＢＳ１００−１で信号を最適化するため、情報を獲得し、サービングＢＳ１００−１に送るのに適する可能性のある一つ以上のＢＳの集合を決定することは、以下の選択基準のうちの少なくとも一つに基づき達成されてもよい：
−端末２００から少なくとも一つの更なるＢＳへのリンクの特性と比較した、端末２００からサービングＢＳへのリンクの、例えば品質、負荷および待ち時間またはそのいずれかのような特性、
−サービングＢＳと少なくとも一つの更なるＢＳとの間の、例えば品質、負荷および待ち時間またはそのいずれかのような、リンクの特性、
−サービングＢＳの容量、
−端末２００および少なくとも一つの更なる端末に対する、少なくとも一つの更なるＢＳの関係、
−少なくとも一つの更なるＢＳの負荷、
−サービングＢＳの位置情報に関連して、少なくとも一つの更なるＢＳの位置情報、
−少なくとも一つの更なるＢＳに関連する、維持管理情報、
−少なくとも一つの更なるＢＳに関する事前構成情報。
【０１００】
サポーティングＢＳとして適する可能性のある、更なるＢＳからサービングＢＳ１００−１に、上記に説明した基準に関係する情報を送ってもよい。
【０１０１】
可能性のある協力ＢＳの最終的集合を集めた後、サービングＢＳ１００−１は、その集合のＢＳ全てからの協力を要求する。リクエスト−レスポンス機構により、または、パブリシュ−サブスクライブ機構により、サポーティングＢＳの各々に個別にメッセージ交換を実行する。しかしながら、当然のことであるが、ネットワーク容量を効率的に使用するため、ユニキャスト・メッセージ、マルチキャスト・メッセージおよびブロードキャスト・メッセージまたはそのいずれかを必要に応じて使用してもよい。
【０１０２】
協力ＢＳを選択するという上記の概念を、図７と８に更に示す。
【０１０３】
図７は、通信ネットワークのアクセス・ノード１００−１、１００−２、１００−３、１００−４、１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０またはＢＳ（ＢＳ１−ＢＳ１０）の集合Ｅ１を示す。アクセス・ノード１００−１は端末２００のためのサービング・アクセス・ノードである。端末２００のＴｘ信号は、アクセス・ノード１００−１、１００−２、１００−３、１００−４、１００−５および１００−８、即ち、ＢＳ１−ＢＳ５およびＢＳ８で受信される。サービング・アクセス・ノード１００−１は、サービング・アクセス・ノード１００−１をサポートするために適する可能性のある、集合Ｅ１の一つ以上のアクセス・ノードの集合Ｅ２を決定することができる。例によれば、サービング・アクセス・ノード１００−１は、集合Ｅ２のために、アクセス・ノード１００−２、１００−３および１００−４、即ち、ＢＳ２−ＢＳ４を選択し、残りのアクセス・ノード１００−５、１００−６、１００−７、１００−８、１００−９、１００−１０、即ち、ＢＳ５−ＢＳ１０を除外する。例えば、この決定は、全てで、または適当な品質で、端末２００から信号を受信するために残りのアクセス・ノードのどれかからも余りにも離れていてもよい可能性のある、端末２００の位置を知っていることに基づいていてもよい。図８に、サービング・アクセス・ノード１００−１と、集合Ｅ２の、各々のサービング・アクセス・ノード１００−２、１００−３および１００−４との間で交換した、交換メッセージＭ１２、Ｍ１３およびＭ１４を示す。上記で説明したように、本交換メッセージは、リクエスト・メッセージとレスポンス・メッセージ、またはサブスクライブ・メッセージとパブリッシュ・メッセージであってもよく、集合Ｅ２の各々のアクセス・ノード１００−２、１００−３および１００−４で、端末２００から受信した信号に関する情報を要求し、受信する目的を持っている。当然のことであるが、図７と８に示した状況は単に典型的である。集合Ｅ２が三つのアクセス・ノードからなる図示の状況に比較して、その他の状況は、集合Ｅ２で一つのみのアクセス・ノード、二つのアクセス・ノード、または三つ以上のアクセス・ノードを持ってもよい。また、当然のことであるが、通信ネットワークにおけるアクセス・ノードの合計数は異なっていてもよい。
【０１０４】
図９は、上記で説明した概念による方法を図示するためのフローチャートを示す。図９の方法には、サービング・アクセス・ノードが実行すべきステップを備える。
本方法はステップ５１０で開始する。
【０１０５】
ステップ５２０で、例えば第一のアクセス・ノード１００−１のような第一のアクセス・ノードで、例えば端末２００のような端末から、例えば信号１０−１のような第一の信号を受信する。次に、第一のアクセス・ノードで受信した第一の信号を、第一のアクセス・ノードにおけるアクセス・ノード別処理の支配下に置く。
【０１０６】
ステップ５３０で、第一のアクセス・ノードは、例えばアクセス・ノード１００−２のような第二のアクセス・ノードにリクエストを送る。上記で説明したように、本リクエストは、リクエスト・メッセージの形式またはサブスクライブ・メッセージの形式であってもよい。本リクエストでは、第二のアクセス・ノードで端末から受信した、例えば信号１０−２のような第二の信号に関する情報は、例えば、Ｒｘ信号のＩＱサンプル、Ｒｘ信号の復調したビットのソフト値、およびＲｘ信号の復号化ビット、またはそれらのすくなくとも一つを要求される。
【０１０７】
ステップ５４０で、第一のアクセス・ノードは、例えば、レスポンス・メッセージまたはパブリッシュ・メッセージで、第二のアクセス・ノードからの要求された情報を受信する。
【０１０８】
ステップ５５０で、第一のアクセス・ノードは、第二のアクセス・ノードからの受信情報に基づいて、および、第一のアクセス・ノードが受信した第一の信号に関する情報に基づいて、最適化した信号を決定する。上記で説明したように、これには、第一の信号に関する情報と、例えば選択合成、ＩＣまたは同様なもののような第二の信号に関する情報との合同処理を含む。
【０１０９】
本方法はステップ５６０で終了する。
【０１１０】
図１０は、上記で説明した概念による方法を図示するためのフローチャートを示す。図１０の方法には、サポーティング・アクセス・ノードが実行すべきステップを備える。
【０１１１】
本方法はステップ６１０で開始する。
【０１１２】
ステップ６２０で、例えば第二のアクセス・ノード１００−２のような第二のアクセス・ノードが、例えば第一のアクセス・ノード１００−１のような第一のアクセス・ノードからのリクエストを受信する。上記で説明したように、本リクエストは、リクエスト・メッセージの形式またはサブスクライブ・メッセージの形式であってもよい。本リクエストでは、第二のアクセス・ノードで端末から受信した、例えば信号１０−２のような信号に関する情報は、例えば、Ｒｘ信号のＩＱサンプル、Ｒｘ信号の復調したビットのソフト値、およびＲｘ信号の復号化ビットまたはそれらのすくなくともひとつを要求される。
【０１１３】
ステップ６３０で、第二のアクセス・ノードは端末から本信号を受信する。また、幾つかの実施形態では、本リクエストを受信する前に、本信号を受信してもよい。そのような場合、第二のアクセス・ノードが受信信号を記憶してもよい。
【０１１４】
ステップ６４０、第二のアクセス・ノードは、受信信号から要求された情報を獲得する。
【０１１５】
ステップ６５０で、第二のアクセス・ノードは、例えばレスポンス・メッセージまたはパブリッシュ・メッセージで要求された情報を第一のアクセス・ノードに送る。
【０１１６】
本方法はステップ６６０で終了する。
【０１１７】
上記で説明した概念により、例えばサービングＢＳのようなアクセス・ノードが、例えばサポーティングＢＳのような一つ以上の更なるアクセス・ノードからのＵＥのために、Ｒｘ信号を要求できるようになる。Ｒｘ信号は、例えば、ＩＱサンプル、非符号化ソフト・ビット、符号化ハード・ビットまたは同様なもののような任意の形式を持つことができる。
【０１１８】
本概念は、選択的方法で、協力するアクセス・ノードまたはＢＳの動的で、オン・デマンドのグループ化を可能とする。本概念は、リクエスト−レスポンス機構またはパブリック−サブスクライブ機構を使用して、選択したサポーティング・アクセス・ノードまたはＢＳから特定のＲｘ情報のオン・デマンド収集を提供する。ＩＣのために要求された追加のパラメータは、効率的な方法で交換されてもよい、更に、本概念により、中央制御ノードを必要とすること無しに、分散型制御の下で動作することが可能になる。
【０１１９】
本発明の幾つかの実施形態により、可能性のあるサポーティング・アクセス・ノードまたはＢＳを選択するアルゴリズムが提供されてもよい。上記に説明したアクセス・ノードまたはＢＳ選択アルゴリズムにより、送信インフラ、ネットワーク負荷、設置密度、チャネル条件またはそれらのような各種の要求条件と制約条件に関する協力の処理を最適化することが可能となる。
【０１２０】
上記の概念は、必要に応じて局部的情報を信頼してもよい分散型制御の方法を含む。従って、ＵＬ方向における高度な復号化性能のために転送し、使用する情報のシグナリング情報総量、同じくシグナリング距離を削減してもよい。
【０１２１】
最終的には、上記の概念により、３ＧＰＰ  ＬＴＥが定める定期的なＢＳ  ＵＬスケジューリングに、情報交換を統合することが可能になる。協力的および非協力的送信は同時に起こり得る。
【０１２２】
当然のことであるが、上記の概念、例および実施形態は単に図示的であり、各種の変更を受け入れる余地がある。例えば、上記で説明した方法および処理、ステップまたは手順は、説明した順序により、または異なる順序で実行してもよい。更にまた、本開示の範囲から離れること無しにあるステップまたは処理を省略することが可能である。更に、各種の例または実施形態の個々の特徴は、必要に応じて互いに合成してもよい。
【図１】
0005608656.tif 000002
【図２】
0005608656.tif 000003
【図３】
0005608656.tif 000004
【図４】
0005608656.tif 000005
【図５】
0005608656.tif 000006
【図６】
0005608656.tif 000007
【図７】
0005608656.tif 000008
【図８】
0005608656.tif 000009
【図９】
0005608656.tif 000010
【図１０】
0005608656.tif 000011