(57)【特許請求の範囲】
【請求項１】
デバイスツーデバイス通信を実行するように構成され、第３の無線通信デバイスとのデバイスツーデバイス通信に関係した第１の無線通信デバイスの方法であって、
前記第１の無線通信デバイスが前記第３の無線通信デバイスとのデバイスツーデバイス通信に関係している間、前記デバイスツーデバイス通信において干渉が検出されると、当該デバイスツーデバイス通信に干渉を起こす第２の無線通信デバイスと関連した干渉判定基準を決定すること（４４０）と、
前記干渉判定基準と関連した干渉管理要請メッセージをネットワークノードに送信すること（４５０）と、
前記第２の無線通信デバイスにおいて又は前記第３の無線通信デバイスにおいて成された通信の調整に関する情報を受信することと
を含むことを特徴とする方法。
【請求項２】
前記ネットワークノードからの干渉制御メッセージを受信すること（４６０）をさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記干渉制御メッセージは、
前記第１の無線通信デバイスの送信電力を調整する命令と、
前記第１の無線通信デバイスの送信パターンを調整する命令と、
前記第１の無線通信デバイスの送信周波数を調整する命令と、
前記第１の無線通信デバイスの送信リソースを調整する命令と、
前記第１の無線通信デバイスの送信データ速度を調整する命令と
のうちの１または複数を含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記調整は、
前記第２の無線通信デバイスまたは前記第３の無線通信デバイスの送信電力の調整と、
前記第２の無線通信デバイスまたは前記第３の無線通信デバイスの送信パターンの調整と、
前記第２の無線通信デバイスまたは前記第３の無線通信デバイスの送信周波数の調整と、
前記第２の無線通信デバイスまたは前記第３の無線通信デバイスの送信リソースの調整と、
前記第２の無線通信デバイスまたは前記第３の無線通信デバイスの送信データ速度の調整と
のうちの１または複数を含むことを特徴とする請求項１乃至３のいずれか一項に記載の方法。
【請求項５】
第２のデバイステストシグナリングの要求を前記ネットワークノードに送信すること（４１０）と、
第２のデバイステストシグナリング情報を前記ネットワークノードから受信すること（４３０）と、
前記第２のデバイステストシグナリングの受信に基づいて前記干渉判定基準を決定すること（４４０）と
をさらに含むことを特徴とする請求項１乃至４のいずれか一項に記載の方法。
【請求項６】
デバイスツーデバイス通信に補助を提供するように構成されたネットワークノードの方法であって、
デバイスツーデバイス通信を実行するように構成され、第１の無線通信デバイスが第３の無線通信デバイスとのデバイスツーデバイス通信に関係している間、前記デバイスツーデバイス通信において干渉が検出されると干渉判定基準を決定するように構成された前記第１の無線通信デバイスから、前記デバイスツーデバイス通信に干渉を起こす第２の無線通信デバイスと関連した前記干渉判定基準と関連した干渉管理要請メッセージを受信すること（３５０）と、
通信の調整のための干渉制御メッセージを、前記第２の無線通信デバイスと前記第３の無線通信デバイスとのうちの少なくとも１つに送信すること（３６０）と、
前記第１の無線通信デバイスに、前記第２の無線通信デバイスにおいて又は前記第３の無線通信デバイスにおいて成された前記通信の調整に関する情報を送信することと
を含むことを特徴とする方法。
【請求項７】
第２のデバイステストシグナリングの要求を前記第１の無線通信デバイスから受信すること（３１０）と、
テストシグナリングのリソースを前記第２の無線通信デバイスに割り当てること（３２０）と、
第２のデバイステストシグナリング情報を前記第１の無線通信デバイスに送信すること（３３０）と、
テストシグナリングコマンドを前記第２の無線通信デバイスに送信することと
をさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記第１の無線通信デバイスと前記第２の無線通信デバイスと前記第３の無線通信デバイスとのうちの少なくとも１つへの干渉制御メッセージが、
前記それぞれの無線通信デバイスの送信電力を調整する命令と、
前記それぞれの無線通信デバイスの送信パターンを調整する命令を含むことのある命令と、
前記それぞれの無線通信デバイスの送信周波数を調整する命令と、
前記それぞれの無線通信デバイスの送信リソースを調整する命令と、
前記それぞれの無線通信デバイスの送信データ速度を調整する命令と
のうち少なくとも１つを含むことを特徴とする請求項６または７に記載の方法。
【請求項９】
前記干渉判定基準が、
前記第２の無線通信デバイスのための最大送信電力と、
前記第２の無線通信デバイスからの送信の受信のための前記第１の無線通信デバイスの最大受信電力と、
要求された電力調整と
のうち少なくとも１つを含むことを特徴とする請求項１乃至７のいずれか一項に記載の方法。
【請求項１０】
コンピュータに、請求項１乃至９のいずれか一項に記載の方法を実行させるためのプログラム。
【請求項１１】
デバイスツーデバイス通信を実行するように構成された第１の無線通信デバイス（４９０、４９０ｂ）であって、
前記第１の無線通信デバイスが第３の無線通信デバイスとのデバイスツーデバイス通信に関係している間、前記デバイスツーデバイス通信において干渉が検出されると、当該デバイスツーデバイス通信に干渉を起こす第２の無線通信デバイスと関連付けられた干渉判定基準を決定するように構成された干渉判定部（５４０）と、
前記干渉判定基準と関連づけられた干渉管理要請メッセージをネットワークノードに送信するように構成された送信機（５２０）と、
前記第２の無線通信デバイスにおいて又は前記第３の無線通信デバイスにおいて成された通信の調整に関する情報を受信する受信機（５１０）と
を有することを特徴とする第１の無線通信デバイス。
【請求項１２】
前記送信機はさらに、第２のデバイステストシグナリングの要求を前記ネットワークノードに送信するように構成され、
前記受信機はさらに、前記ネットワークノードから第２のデバイステストシグナリング情報を受信するように構成され、
前記干渉判定部は、前記第２のデバイステストシグナリングの受信に基づいて前記干渉判定基準を決定するように構成されたことを特徴とする請求項１１に記載の第１の無線通信デバイス。
【請求項１３】
デバイスツーデバイス通信に補助を提供するように構成されたネットワークノード（３９０、３９０ｂ）であって、
デバイスツーデバイス通信を実行するように構成され、第１の無線通信デバイスが第３の無線通信デバイスとのデバイスツーデバイス通信に関係している間、前記デバイスツーデバイス通信において干渉が検出されると干渉判定基準を決定するよう構成された前記第１の無線通信デバイスから、前記デバイスツーデバイス通信に干渉を起こす第２の無線通信デバイスと関連した前記干渉判定基準と関連した干渉管理要請メッセージを受信するように構成された受信機（６１０）と、
通信の調整のための干渉制御メッセージを、前記第２の無線通信デバイスと第３の無線通信デバイスとのうちの少なくとも１つに送信し、前記第１の無線通信デバイスに、前記第２の無線通信デバイスにおいて又は前記第３の無線通信デバイスにおいて成された前記通信の調整に関する情報を送信するように構成された送信機（６２０）と
を有することを特徴とするネットワークノード。
【請求項１４】
テストシグナリングのリソースを前記第２の無線通信デバイスに割り当てるように構成された割り当て部（６３０）をさらに含むことを特徴とする請求項１３に記載のネットワークノード。
【請求項１５】
前記受信機はさらに、前記第１の無線通信デバイスからの第２のデバイステストシグナリングの要求を受信するように構成され、
前記送信機は、第２のデバイステストシグナリング情報を前記第１の無線通信デバイスに送信し、テストシグナリングコマンドを前記第２の無線通信デバイスに送信するようにさらに構成されることを特徴とする請求項１３または１４に記載のネットワークノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にネットワーク補助型デバイスツーデバイス通信に関する。より詳細には、それはそのような通信の干渉管理と関連する。
【背景技術】
【０００２】
デバイスツーデバイス（Ｄ２Ｄ）通信はデバイスの間の直接的な通信を指している。Ｄ２Ｄにおいて、第１のデバイスから第２のデバイスに送信される通信データは、一般にどのようなセルラネットワーク経由でも中継されることはない。従来技術のＤ２Ｄ通信のいくつかの例はブルートゥース通信、ＦｌａｓｈｌｉｎＱ通信、およびＷＬＡＮ（例えばＩＥＥＥ８０２．１１）通信（例えばＷＩＦＩダイレクト）である。
【０００３】
デバイスツーデバイス通信は様々なシナリオにおいて適用できる可能性がある。１つのシナリオが、セルラ式無線アクセスネットワークが存在し、かつ、２つのデバイスの間のセルラ接続をセットアップすることができる場合である。Ｄ２Ｄ通信はそのようなシナリオにおいてはセルラ通信の補完物であり得る。
【０００４】
Ｄ２Ｄ通信がセルラ通信よりよい性能（よりよい信号品質、より高いビットレート、短い待ち時間など）を提供する状況があり得る。これはデバイス間の近さ、およびＤ２Ｄプロトコルの特定のシグナリング利得（例えばホップ利得）、またはそのいずれかによる可能性がある。
【０００５】
いくつかの状況においては、ネットワークは、（例えば重い負荷がかかっているため）ネットワーク接続を使ってサービスを全く提供できないという結果を生じる制約を持つ可能性がある。そのとき、Ｄ２Ｄ通信は代替手段となるであろう。
【０００６】
また、（例えばビリングコストのため）Ｄ２Ｄ通信がデバイスのユーザによって好まれるかもしれない状況もあり得る。
【０００７】
特にＤ２Ｄ接続が、セルラネットワーク（一般にライセンスされた帯域）とは異なる帯域の範囲（例えばライセンスされていない帯域）を使う場合には、Ｄ２Ｄ通信は帯域効率を改善し、かつセルラネットワークのネットワーク負荷を減らすことができる。さらに、セルラ通信が２つのデバイスのそれぞれのためにアップリンクとダウンリンクのペアを使い、その一方、Ｄ２Ｄ接続は１つのリンクペアを使うだけであろうから、Ｄ２Ｄ接続がセルの帯域リソースを使っても帯域効率は改善される。データのほとんどがＤ２Ｄ接続上で送信され、少ない情報量だけがネットワークリンク上で送信されるであろうネットワーク補助型Ｄ２Ｄ通信であってもこれは真であるであろう。
【０００８】
Ｄ２Ｄ通信はその場限り（ａｄ  ｈｏｃ）であってもよいし、ネットワーク補助型であってもよい。例えば、セルラネットワークは、Ｄ２Ｄリンクのセキュリティを設立するか、または、Ｄ２Ｄ接続のセットアップ（例えばデバイス／ピアの発見とリソース割り当て）を部分的あるいは全体的に制御するか、または、その両方を行うことによってＤ２Ｄ接続を補助することができる。セルラネットワークは、干渉環境を制御することによってもＤ２Ｄ通信を補助することができる。例えば、ライセンスされた事業者帯域をＤ２Ｄ通信のために用いるならば、ライセンスされていない帯域で動作する場合より高い信頼性を提供し得る。Ｄ２Ｄ接続を補助するために、ネットワークはまた同期、または、部分的あるいは全体的な無線リソース管理（ＲＲＭ）、またはその両方を提供することができる。
【０００９】
Ｄ２Ｄ通信におけるデバイス／ピアの発見は、一般にビーコンを送信している（例えばブロードキャストしている）か、または、ビーコンを検出しているか、またはその両方を行っているデバイスそれぞれに基づく。ネットワーク補助型Ｄ２Ｄデバイス発見において、ネットワークは、ビーコンのリソースを割り当てること、および発見のために使われるビーコン信号をデバイスが構成および検出するために使うことができる情報を提供することによってデバイスを補助することができる。
【００１０】
一般に、デバイスのためのビーコン信号はデバイスのＩＤに基づいて良いし、あるいはビーコン信号のセットから無作為に引き出してもよい。これは、ネットワークがビーコンを割り当てる場合と、ビーコンがネットワークによって提供されない場合（例えば、発見フェーズの後で（接続済／接続状態において）、デバイスは無作為にビーコン情報を引き出し、他のデバイスに伝達することができる）の両方にあてはまる。
【００１１】
ビーコン信号はそれからそれぞれの（マスタ）デバイスによって（一般に一定の時間間隔で）送信される。リッスンする（スレーブ）デバイスはそのとき、ビーコンを走査する必要がある。デバイスがマスタのみの役割、スレーブのみの役割、または両方の役割の組み合わせを果たすことができることは注目されるべきである。ビーコンが検出される際に、対応するスレーブは一般に肯定応答を対応するマスタに送信し、それからＤ２Ｄ接続が開始できる。
【００１２】
ビーコンのシグナリングをネットワークによって割り当て、調整させることはビーコン衝突のリスクを減らす。さらに、スレーブにマスタのビーコン情報を持たせることは走査性能を改善するかもしれない（例えば発見までの時間短縮、電力消費量の低減）。
【００１３】
ネットワーク補助型Ｄ２Ｄ通信において、ネットワークは、通信リソースを割り当てること、および、デバイスが通信を最適化するために使うことができる情報を提供することによってもデバイスを補助することができる。
【００１４】
Ｄ２Ｄ通信シナリオにおいて、例えば特定のネットワークノードによってカバーされたエリア内、またはより小さな領域内で、互いに近接した大量のＤ２Ｄ能力を持つデバイスがあり得ることが想像される。これはＤ２Ｄリンク設定のための多くの可能性を持たせるけれども、この状況はまたＤ２Ｄシグナリング（例えばピア発見と他のシグナリング）によって発生させられたかなり多くの干渉を起こす可能性がある。そのようなシナリオにおいて例えばリンク性能とシステム性能を最適化することは複雑な課題である。
【００１５】
ネットワークの関与なしでは、システムは、一般に、干渉で制限されることになる高いリスクを我慢する可能性がある。従って、Ｄ２Ｄ通信を使ってエリアあたりの総トラヒックを著しく増大させる可能性は予期されるほど全く高くないかもしれない。さらに、あまりにも多くのデバイスが同じエリアの中にあり過ぎる場合には、激しい輻輳があり得、その結果、受入れ可能なサービスの質を提供するために能力を制限することがあり得る。
【００１６】
"Design Aspects of Network Assisted Device-to-Device Communications", IEEE Communications Magazine, March 2012, pp. 170-177 by Fodor et alは、ピア発見方法、セルのインフラストラクチャを基層とするデバイスツーデバイス通信のための物理層手順および無線リソース管理アルゴリズムを開示する。ネットワークは、Ｄ２Ｄ候補を認識すること、ビーコンのための送信／走査に対する時間および周波数割当を調整すること、それによりエネルギー効率がより良好で、より時間のかからないペアリングを行うことにより、発見プロセスを調停することができる。さらに、ｅＮＢは、二つのＵＥが両方ともチャンネル品質推定のために既知の復調基準シグナル（ＤＭＲＳ）を送信し、また受信する場合を含めて、クライアント−サーバの役割をそれらＵＥに割り当てることができる。Ｄ２ＤのＤＭＲＳパラメータは、Ｄ２Ｄペアの両方のＵＥに伝達されて、ＤＭＲＳ測定は、それから、モード選択、電源制御、およびｅＮＢによって制御された他のＲＲＭ機能を容易にするためにｅＮＢに報告されることができる。
【００１７】
ネットワーク補助型デバイスツーデバイス通信に対する代替アプローチについての必要性がある。特に、ネットワーク補助型デバイスツーデバイス通信における効率的な干渉管理アプローチの必要性がある。
【発明の概要】
【００１８】
用語「含む／含んでいる」は、この明細書の中で使われる場合には、述べられた機能、整数、ステップ、または構成要素の存在を特定するために用いられるけれども、１つ以上の他の機能、整数、ステップ、構成品、またはそれらのグループの存在または追加を妨げないことは強調されるべきである。
【００１９】
ネットワーク補助型デバイスツーデバイス通信のための干渉管理アプローチを提供することが目的のひとつである。特に、ネットワーク補助型デバイスツーデバイス通信のための効率的な干渉管理アプローチを提供することがひとつの目的である。
【００２０】
ここに説明されるような実施形態は、様々なシナリオにおいて使うことができる。例えば、いくつかの実施形態は、Ｄ２Ｄのピア発見フェーズにおいて、Ｄ２Ｄ接続のセットアップフェーズにおいて、または、進行中のＤ２Ｄ通信フェーズにおいて、あるいはそれらの組み合わせにおいて使用できる。
【００２１】
実施形態は、Ｄ２Ｄ通信のシナリオにおける干渉管理の問題に対処する。ここに説明されるように、ネットワークは、干渉制御が、いくつかの実施形態に従って異なるデバイスからの正確な情報に基づくことを保証する。これは、Ｄ２Ｄ通信上の不必要に厳しい制限が避けられる可能性があるか、または、制御されていない干渉状況（例えば、増大する干渉による）が避けられる可能性があるという利点がある。
【００２２】
いくつかの実施形態は、デバイスツーデバイス通信を実行するように構成された第１の無線通信デバイスの方法を含む。その方法は、第２の無線通信デバイスと関連づけられた干渉判定基準または干渉状況、あるいはその両方を決定し、干渉判定基準または干渉状況と関連した干渉管理要請メッセージをネットワークノードに送信することを含む。
【００２３】
いくつかの実施形態は、デバイスツーデバイス通信の補助を提供するように構成されたネットワークノードの方法を含む。この方法は、干渉判定基準または干渉状況あるいはその両方と関連した干渉管理要請メッセージを、デバイスツーデバイス通信を実行するように構成した第１の無線通信デバイスから受信し、第１の無線通信デバイスと第２の無線通信デバイスと第３の無線通信デバイスとのうちの少なくとも１つに干渉制御メッセージを送信することを含む。
【００２４】
第１のデバイスは第３のデバイスとのＤ２Ｄ通信に関係（またはセットアップ）している可能性があり、第２のデバイスはその通信に干渉を起こす可能性がある。
【００２５】
干渉判定基準または干渉状況またはその両方は、例えば、第２のデバイスのための最大の送信電力と、第２のデバイスの送信信号の受信のための第１のデバイスの最大の受信電力と、所望の電力調整（例えば、数ｄＢ下げる、１つの電力制御装置を下げるなどすること）とのうちの１つ以上を含んでよい。これは、干渉された一番目のデバイスによって自律的に決定される（例えば、それがどれほど高い干渉電力を許容できるかを決定することによって）か、干渉している第２のデバイスまたはネットワークノードまたはその両方によって補助されてもよい。
【００２６】
例えば、第１のデバイスの方法は、ネットワークノードに対する、第２のデバイステストシグナリング（例えば、好ましくは既知の送信電力での、ビーコンシグナリングまたは他の適切な調査（sounding）信号）の要求の送信と、第２のデバイステストシグナリングの受信に基づいた干渉状況または干渉判定基準またはその両方の決定とを含んでよい。この方法は、ネットワークノードからの第２のデバイステストシグナリング情報の受信をさらに含んでよい。従って、干渉管理は第１のデバイスによって開始されることができる。
【００２７】
このネットワークノードの方法は、第１のデバイスからの第２のデバイステストシグナリングの要求を受信することと、第２のデバイスに対するテストシングナリングコマンドを送信することとを含んでよい。この方法はまた、第２のデバイスに対するテストシグナリングリソースの割り当てることと、第２のデバイステストシグナリング情報（割り当て情報を含む）を第１のデバイスに送信することとを含んでよい。第２のデバイスに対するテストシグナリングコマンドは割り当て情報を含んでもよい。
【００２８】
いくつかの実施形態において、干渉管理はネットワークノードによって開始できる。例えば、ネットワークノードの方法は、テストシグナリングコマンドを第２のデバイスに送信することと、第２のデバイステストシグナリング情報を第１のデバイスに送信することとを含んでよい。この方法はまた、第２のデバイスにテストシングナリングリソースを割り当てることを含んでよい。第２のデバイスへのテストシグナリングコマンドと第１のデバイスへの第２のデバイステストシグナリング情報とは、割り当て情報を含んでよい。
【００２９】
第１のデバイスの方法は、ネットワークノードから第２のデバイステストシグナリング情報を受け取ることと、第２のデバイステストシグナリングの受信に基づいて干渉状況または判定基準またはその両方を決定することとを含むことができる。
【００３０】
ネットワークノードによって送信された干渉制御メッセージは、第１、第２、および第３のデバイスの少なくとも１つに対する送信調整命令を含むことができる。送信調整命令は、送信電力を調整する命令を含んでよい。送信調整命令は、送信パターン（すなわちどんな時間リソースが送信のために使われるか）を調整する命令を含むことができる。送信調整命令は、送信周波数（例えばどの搬送波周波数が使われるべきであるか）を調整する命令を含むことができる。送信調整命令は、送信リソース（例えばＯＦＤＭシグナリングのための時間／周波数割当）を調整する命令を含むことがある。送信調整命令は、送信データ送信速度を調整する命令を含むことができる。
【００３１】
いくつかの実施形態において、ネットワークノードによって送信された干渉制御メッセージは、第１、第２、および第３のデバイスの少なくとも１つに対する受信調整命令をもまた含むことができる。例えば、ネットワークが第３のデバイスにその送信周波数を変更することを指示するならば、それに応じてその受信周波数を調整することができるように、第１のデバイスはそれを知らせられなければならない。
【００３２】
従って、いくつかの実施形態は、第２のデバイスによって引き起こされた、第１のデバイスにおいて経験した干渉レベルを判定するための方法を含む。経験した干渉レベルが高すぎる（例えばしきい値を越える）と判定されているならば、この方法は、それを減少させることを試みることを含む。この方法は、（干渉レベルを判定した）第１のデバイスが、ネットワーク（例えばネットワークノード）に対して、干渉を減らすために行動をとるよう要求する情報を送信することを含む。ネットワークは１つ以上の様々な方法でそれに応じて反応することができる。
【００３３】
ネットワークは、第２のデバイス（すなわち干渉デバイス）がその送信電力を減らすことが可能であるかどうかを決定することができえる。ネットワークは、第１のデバイスからの情報に基づいてその送信電力を減らすよう干渉デバイスに要求することができる。
【００３４】
ネットワークは、ＴＸ／ＲＸ（送信／受信）パターンを修正するよう第１のデバイスに要求することができる。これは、他のＤ２Ｄリンクからの干渉の影響を減らすためにされてよい。ネットワークはどのようにＴＸ／ＲＸパターンを修正するかについての情報を提供することができる。
【００３５】
ネットワークは、ＴＸ／ＲＸパターンを修正するよう第２のデバイスに要求することができる。これは、他のＤ２Ｄリンクに対する干渉の影響を減らすためにされてよい。ネットワークはどのようにＴＸ／ＲＸパターンを修正するかについての情報を提供することができる。
【００３６】
いくつかの実施形態において、干渉判定は第１のデバイスによって開始される。いくつかの実施形態において、干渉判定はネットワークによって開始される。例えば、方法は、ネットワークが、第２のデバイスに対して信号を送信するよう要求し、第１のデバイスに対してその同じ信号をリッスンするよう要求することを含むことができる。これは、第２のデバイスによって引き起こされた干渉のレベルを判定するためにされてもよい。
【００３７】
いくつかの実施形態は、デバイスツーデバイス通信を実行するように構成された第１の無線通信デバイスの配置を含む。この配置は、第２の無線通信デバイスと関連づけられた干渉判定基準または干渉状況またはその両方を判定するように構成された干渉判定部と、干渉判定基準または干渉状況またはその両方と関連した干渉管理要請メッセージをネットワークノードに送信するように構成された送信機とを含む。この配置はまた、上で例示した信号および情報を受信するように構成された受信機を含むことができる。
【００３８】
いくつかの実施形態は、デバイスツーデバイス通信を実行するように構成され、上記の配置を含む無線通信デバイスを含んでいる。
【００３９】
いくつかの実施形態は、デバイスツーデバイス通信の補助を提供するように構成されたネットワークノードの配置を含む。この配置は、デバイスツーデバイス通信を実行するために適した第１の無線通信デバイスから、干渉判定基準と関連した干渉管理要請メッセージを受信するように構成された受信機を含む。この配置はまた、干渉制御メッセージを第１の無線通信デバイス、第２の無線通信デバイス、および第３の無線通信デバイスの少なくとも１つに送信するように構成された送信機を含んでいる。この配置はまた、テスト信号リソースを第２のデバイスに割り当てるように構成された割り当て部を含んでもよい。
【００４０】
いくつかの実施形態は、デバイスツーデバイス通信の補助を提供するように構成され、上記の配置を含むネットワークノードを含んでいる。
【００４１】
いくつかの実施形態は、データ処理ユニットにロード可能であり、そのデータ処理ユニットによって実行される際にはここのどの例にでも従った方法を実行させるように構成されたプログラム命令を含むコンピュータプログラムを有するコンピュータ読取り可能媒体を含むコンピュータプログラム製品を含んでいる。
【００４２】
いくつかの実施形態の利点は、Ｄ２Ｄ通信において干渉管理を実行する有効な方法が提供されることである。例えば、干渉されたデバイスによって干渉管理が開始される際に、どのリソースも、どのような干渉にも悪影響を受けないデバイスのための干渉計測によって浪費されない。干渉管理が１つ以上のデバイスからの信号品質情報に基づいてネットワークノードによって開始される際にも、同じことがその状況にあてはまる。
【００４３】
いくつかの実施形態の別の利点は、干渉が、Ｄ２Ｄ通信のための送信可能性を不必要に制限せずに抑圧される（例えば十分に低い水準で）ことができることである。例えば、干渉されたデバイスによって干渉判定基準が決定されるので、干渉デバイスの通信の対応する適応は、干渉判定基準に合うように調整され得る。従って、適応が、送信電力を下げることであるならば、送信電力は、多くではなく、干渉することを避けるのに必要なだけ低減され得る（それゆえ被干渉デバイスによって与えられた条件の下で干渉デバイスのＤ２Ｄ通信品質を最大化する）。
【００４４】
さらに、いくつかの実施形態のさらなる利点は、Ｄ２Ｄ通信のために適用可能な無線条件が効率的な方法で推定され得ることである。
【００４５】
いくつかの実施形態の別の利点は、ネットワーク補助型Ｄ２Ｄ通信のための干渉を判定する帯域の効率的な方法が提供されることである。
【図面の簡単な説明】
【００４６】
さらなる目的、機能、および利点は、添付図面を参照して、実施形態の以下の詳細な説明から現れるであろう。
【図１ａ】、
【図１ｂ】いくつかの実施形態に従ってネットワークにおいてデバイスを説明している概略図である。
【図２】いくつかの実施形態に従って例である方法とシグナリングを説明している結合されたフローチャートとシグナリング図である。
【図３ａ】いくつかの実施形態に従って例である方法とシグナリングを説明している結合されたフローチャートとシグナリング図である。
【図３ｂ】いくつかの実施形態に従って例であるシグナリングを示しているシグナリング図である。
【図４】いくつかの実施形態に従って例である送信パターン調整を説明している概略図である。
【図５】いくつかの実施形態に従って例である配置を説明しているブロック図である。
【図６】いくつかの実施形態に従って例である配置を説明しているブロック図である。
【図７】いくつかの実施形態に従ってコンピュータの読取り可能の中間を説明している概略図である。
【発明を実施するための形態】
【００４７】
ここに使われるＤ２Ｄプロトコル／通信／接続がどのような既知の、または将来の適当なＤ２Ｄアプリケーションとでも関連していることは注目される。例は、セルの帯域を使っているブルートゥース、ＷＬＡＮ（ＷＩＦＩダイレクト）、ＦｌａｓｈｌｉｎＱ、およびＤ２Ｄを含むけれども、それらに制限されない。例えば、ネットワークノードによって割り当てられるように、ネットワーク補助型Ｄ２Ｄ通信はセルの帯域のアップリンクまたはダウンリンクまたはその両方のリソースを使うことができる。代わりに、ネットワーク補助型Ｄ２Ｄ通信は、２．４５ＧＨｚのＩＳＭバンドなどのライセンスされていない帯域を使うことができる。Ｄ２Ｄ通信はＴＤＤまたはＦＤＤであってもよい。ネットワークノードは、Ｄ２Ｄ通信（特に、セルの帯域またはライセンスされた帯域が使われる場合に）、例えば最大の許容送信電力または電源制御コマンドまたはその両方などの電源制御に制限を課すことがある。
【００４８】
同様に、ここに使われるセルのプロトコル／通信／接続が、どのような既知の、または将来の適当なセルのアプリケーションとも関連していることは注目される。例は、３ＧＰＰセルラ標準（例えばＧＳＭ、ＷＣＤＭＡ、ＴＤ−ＳＣＤＭＡ、ＬＴＥ）、ＷＬＡＮ、およびデバイスツーデバイスネットワークさえ含むが、それに限定されない。
【００４９】
ネットワークノードは例えば基地局、ＮｏｄｅＢ、ｅＮｏｄｅＢ、またはＷＬＡＮアクセスポイントを含むことができ、ネットワークはネットワークノードと他のネットワーク部分の対応する集まりを含むことができる。
【００５０】
ネットワークノードは、例えばセルの基地局、リレーノード、無線アクセスポイント、またはコアネットワークノードなど、ネットワークのどの適当な部分（例えば、在圏ノードまたは制御ノード）であってもよい。
【００５１】
ネットワーク補助型Ｄ２Ｄ通信の導入により干渉協調が可能となる。これは、一般に、ネットワークとおそらくはＤ２Ｄ通信に従事しているデバイスも干渉状況に関する知識を持っていることを必要とする可能性がある。信号対干渉比（取得するための複雑なタスクであるそれさえ）に関する知識は一般に、干渉が特定の状況において問題であるかどうかを判定するために十分でない。干渉がまた一般に問題であるかどうかは、例えばＤ２Ｄリンクにおいて現在サポートされたデータ送信速度と干渉の確率などの他の面に依存する。従って、干渉推定と干渉制御に効率的で、正確なアプローチを提供することはここに提出された実施形態の目的である。
【００５２】
以下において、ネットワーク補助型デバイスツーデバイス通信における干渉管理へのアプローチをとる実施形態が説明されるであろう。
【００５３】
例えば、ネットワーク補助型Ｄ２Ｄリンク推定はいくつかのアプローチに従って提供することができる。これは例えば集中化した干渉協調のために有益であり得る。Ｄ２Ｄ通信の集中化した（すなわちネットワークで補助された）干渉協調は一般に、ネットワークノードが（そしてことによるとデバイスも）少なくとも部分的には当てはまる干渉状況（またはより一般に当てはまる無線条件）に気づいていることを必要としている。
【００５４】
いくつかの実施形態は、Ｄ２Ｄ通信のために使われる異なるリンクの異なる送信パラメータを制御することにネットワークを取り込むことを提案する。送信パラメータは、例えばデータ送信速度、送信電力、時間および周波数、或いはそれらの少なくともいずれかを含んでよい。干渉制御はＤ２Ｄ能力を有するデバイスの１以上によって実行された測定に（少なくとも部分的に）基づいてもよい。この測定は、デバイスの１つ以上によって要求されてネットワークによって補助されてもよいし、この測定はネットワークによって開始されてもよい。両方の場合に、ネットワークは実行された測定に基づいた一定の行動をとることができる。いくつかの実施形態において、測定は自律的にＤ２Ｄ能力を有するデバイスの１つ以上によって開始され、実行されて、それから、ネットワークは実行された測定に基づいた一定の行動をとることができる。
【００５５】
図１ａは、基地局（ネットワークノード）４０を伴う基地局サイト５０を含むネットワークの中のデバイス１０、２０、３０、６０、７０、８０を説明している概略図である。ネットワークノード４０は、それぞれのワイアレスリンク１５、２５、３５、６５（すべてのリンクが図示されてはいない）経由でデバイス１０、２０、３０、６０、７０、８０のそれぞれに接続している。デバイスはＤ２Ｄ能力を持っている。さらに、Ｄ２Ｄ能力を持たないデバイス（示されない）があってもよい。
【００５６】
デバイス１０と２０が地理的に互いに近いので、それらの間の直接的な通信のための無線条件はこの例では非常に良好である。そのため、ネットワークノードは、それらがＤ２Ｄ無線リンク１２を（リンク１５と２５を経て）セットアップすることを補助した。同様に、デバイス３０と６０はＤ２Ｄリンク６２経由で接続され、デバイス７０と８０はＤ２Ｄリンク７２経由で接続される。
【００５７】
また、７１によって説明されたデバイス６０と７０との間の潜在的な干渉状況が示される。デバイス１０と２０は、（この場合リンク１２経由の潜在的Ｄ２Ｄ接続について）デバイスが互いに関連する１つのグループ９１とみなすことができ、デバイス３０、６０、７０および８０は、（この場合リンク６２または７２またはその両方経由での潜在的Ｄ２Ｄ接続についてであるが、また干渉７１についても）デバイスが互いに関連するもう１つのグループ９２とみなすことができる。
【００５８】
通信はＦＤＤまたはＴＤＤのどちらかに基づいてもよい。さらに、ネットワークノード（またはネットワークの中の別のユニット）は、潜在的なＤ２Ｄ通信のためのリソース（それは、セルラシステムが３ＧＰＰ  ＬＴＥ標準に従って動作している場合には、例えばリソースブロックやそれと同様のものであってよい）と同様に、ＵＬ／ＤＬ通信のために時間／周波数リソースを端末に割り当てることを制御している可能性がある。ネットワークノードは、Ｄ２Ｄ通信における送信電力も、それが通常の（セルの）トラフィック（例えばデバイスとネットワークノードの間の）を妨げないように制御できる。
【００５９】
図１ｂは、基地局（ネットワークノード）４０を伴う基地局サイト５０を含むネットワークの中のデバイス１０、２０、３０、６０、７０、８０を説明している概略図である。図１ｂは、図１ａに比べて後の時点の状況を説明する。図１ｂにおいて、デバイス７０は移動し、今、別の位置にある。デバイス７０と８０はまだＤ２Ｄリンク７２経由で接続されている。しかし、デバイス７０は現在デバイス６０から遠く、図１ａで経験した干渉状況は変わった。代わりに、デバイス２０と７０との間に、７３によって説明された潜在的な干渉状況が現在ある。従って、デバイス１０、２０、７０および８０はデバイスが互いに関連する１つのグループ９３と現在みなすことができ、デバイス３０と６０はデバイスが互いに関連するもう１つのグループ９４とみなすことができる。
【００６０】
それゆえ、４つのＤ２Ｄ能力を有するデバイス（３０、６０、７０、８０）が、図１ａに示すように基地局（４０）と接続されると想定する。さらに、デバイス６０と７０とが互いに干渉を起こす可能性があると想定する。
【００６１】
いくつかの実施形態によると、図１ａのデバイス６０と７０（および対応して図１ｂのデバイス７０と２０）は、経験した干渉のための判定基準を決定し、その後、決定された干渉判定基準に基づいて干渉管理要請メッセージをネットワークノード４０に送信する。そして、ネットワークノードは、干渉デバイスに、それに応じて適応するよう命令できる。
【００６２】
例えば、判定基準は、それぞれのデバイスの受信機に最大の受入れ可能な干渉電力の指示を含んでよく、干渉管理要請メッセージは、受信した干渉電力が最大の受入れ可能な干渉電力を越えているならば干渉デバイスの送信電力を下げるための指示を含んでもよい。
【００６３】
干渉が疑われているか、検出される場合に、このプロセスはネットワークノードによってまたはそれぞれのデバイスによって開始することができる。
【００６４】
いくつかの実施形態において、ネットワークノードはテスト信号リソースを干渉デバイスに割り当て、割り当てについての情報を干渉デバイスおよび被干渉デバイスに送信することができる。そして、干渉デバイスはそれに応じてテスト信号を送信する。被干渉デバイスはテスト信号を監視し、受信されたテスト信号上の測定に基づいて干渉判定基準を決定する。
【００６５】
干渉が疑われているか、検出される場合に、ネットワークノードにおけるこのプロセスはネットワークノードによってまたはそれぞれのデバイスによって開始することができる。
【００６６】
いくつかの実施形態において、デバイス６０と７０の間のパス損失は、決定された判定基準から干渉デバイスの調整を決定するために必要である可能性がある。例えば、決定された判定基準が、被干渉デバイスの受信機で受入れ可能な最大の干渉電力を含むならば、パス損失は、干渉デバイスの最大の受入れ可能な送信電力を決定するために必要である。
【００６７】
異なるデバイスの間のパス損失は、（ネットワークまたはそれぞれのデバイスまたはその両方に）知られていてもよいし、そうでなくともよい。例えば、図２において説明されるように、パス損失は、（一般にＤ２Ｄ接続セットアップの前に）以下の方法を（少なくとも部分に）実行することによって推定することができる。
【００６８】
図２は、いくつかの実施形態に従って、ネットワークノード１０１（例えば図１ａと図１ｂのネットワークノード４０）とＤ２Ｄ能力を有するデバイス（ＵＥ）２０１（例えば図１ａのデバイス６０と７０の少なくとも１つ、または、図１ｂのデバイス７０と２０の少なくとも１つ、またはその両方）とによってそれぞれ実行される方法の例１００と２００、およびそれらの間のシグナリングを説明している、結合されたフローチャートおよびシグナリング図である。
【００６９】
ネットワーク補助型Ｄ２Ｄ通信において、ネットワークはデバイス（ピア）発見のプロセスについてデバイスを補助することができる。デバイス発見は、一般に、ビーコン信号を送信すること（例えばブロードキャストすること）と、検出することとに基づく。ネットワーク補助型デバイス発見において、ネットワークは、リソースを割り当て、デバイスが、発見のために使われるビーコン信号を構成すること、および検出することのために使うことができる情報を提供することによってデバイスを補助することができる。
【００７０】
従って、ビーコンまたはビーコン信号は、他のデバイスが或るデバイスの存在に注目することを可能にしている、そのデバイス（例えば無線通信デバイス）からブロードキャストされたシグナルであってよい。それは固定か、可変の送信電力を持ってよい。上述したように、それは一般にＤ２Ｄ通信シナリオの中のピア発見のために使われることができるけれども、また他のシナリオ（例えば干渉計測）中で適用可能であり得る。いくつかのアプリケーションにおいて、ビーコンは基準信号または同期信号のタイプと称されるかもしれない。
【００７１】
ビーコン送信はライセンスされなかった帯域においてまたはライセンスされた帯域において行うことができる。同様に、Ｄ２Ｄ通信は、必ずしもどの帯域がビーコン送信のために使われたかに依存せず、ライセンスされなかった帯域においてまたはライセンスされた帯域において行うことができる。
【００７２】
図２は、ピア発見のプロセスに応用され得る１回の可能性のあるアプローチを説明する。それはビーコンの構造化された割り当てに関係していて、１つの測定結果としてパス損失情報を生み出すことができる。
【００７３】
ネットワークノードに登録された他のＤ２Ｄ能力を有するデバイスがすでにあるならば、ネットワークノードは図２に例示するように１１０においてビーコンリソースをそれらに割り当てる。１１０と１２５（後で説明される）の割り当て（または再割り当てまたはその両方）は、リソースが効率的な方法で実行され得る。リソースが効率的な割り当てを提供しているいくつかの実施形態は現在、図２の説明を続ける前に説明されるであろう。
【００７４】
いくつかの実施形態において、ビーコン送信の総数を最小化することは有益であり得る。例えば、ビーコン送信は１度に１つのデバイスによってだけ許されることができ、他のデバイスはリッスンするように要求される。従って、ビーコン送信割り当ては、最初に、送信する第１のデバイス、その次に第２のデバイス、その次に第３のデバイスなどに割り当ててよい。
【００７５】
このアプローチは、ネットワークノードで登録されたすべてのＤ２Ｄ能力を有するデバイスに対して、またはネットワークノードで登録されたＤ２Ｄ能力を有するデバイスのグループ（例えば同じ地理的な領域において互いに近接しているか、さもなければＤ２Ｄ通信の設定が可能そうなデバイスのグループ）に対して取ることができる。後者の場合には、ビーコン送信割り当ては、その結果、最初に第１のグループの第１のデバイス及び同時に送信する第２のグループの第１のデバイス、その次にそれぞれのグループの第２のデバイスなどに割り当てることができる。そのような例において、第１のグループのデバイスは、第１のグループに関連して送信されたビーコンだけをリッスンするように要求され、第２のグループのデバイスについても同様である。
【００７６】
このアプローチは、構造化されたビーコン送信計画を持つという利点をもたらす（それはセル／領域において送信されたビーコンの数を最小化する）。ビーコンの間の干渉のリスクは、セルの他のシグナリングに関してビーコンによる干渉の生成と同様に最小化される。ビーコンプロセス経由で抽出することが可能な情報量を損わない一方で、これは達成される。
【００７７】
いくつかの実施形態において、ビーコン送信の総数、またはビーコンモニタリングの総計またはその両方を最小化することは有益であり得る。そのような目的のために、第１のデバイスから第２のデバイスまでの信号パスの条件が、逆方向の信号パスの条件におそらく等しいか、少なくとも類似していることは注目される（少なくとも同様な周波数帯域が両方向の通信のために用いられる場合であり、例えばＴＤＤだが、平均のリンク減衰が一般にＦＤＤについても非常に相関しているので、ＦＤＤについてもおそらく実現可能）。従って、Ｄ２Ｄ通信の潜在的な相手を検出するために、または潜在的Ｄ２Ｄリンクのシグナリング条件を推定するために、またはその両方のためには、２つのデバイスのうちのただ１つにビーコンを送信させて、他にリッスンさせることで十分であり得る。
【００７８】
この原則に従って、デバイスがその割り当てられたビーコンを送信したら、（ネットワークノードで登録された全てのＤ２Ｄ能力を有するデバイスへの、またはデバイスのグループに向けた）ビーコンリソースの割り当ては、リッスンする目的のためにデバイスを起動させないことによって調整され得る。従って、ビーコン送信割り当ては、まず第１に、第１のデバイスが送信することを許可し、かつ他のデバイスにリッスンするように要求することができ、その次に、第２のデバイスが送信することを許可され、かつ（第１のデバイスを除いた）他のデバイスがリッスンするよう要求され、その次に、第３のデバイスが送信することを許可され、かつ（第１と第２のデバイスを除いた）他のデバイスはリッスンするよう要求される、などする。
【００７９】
このアプローチは、デバイスがビーコンをリッスンする平均時間を最小化し、それゆえに電力消費量を最小化するという利点をさらに有する。
【００８０】
いくつかの実施形態において、ビーコン送信リソースは、その位置を変更した１つ以上のデバイス（図１ａと図１ｂのデバイス７０に相当している）にだけ割り当ててもよい。そのような位置変化は、例えば、セルへの進入を含んでよいが、それはまたその代わりにセル中でのデバイスの移動（デバイスの例えばＧＰＳなどの位置決め装置によって検出される）を含んでもよい。従って、デバイスが移動した場合に、ネットワークノードはデバイスにビーコン送信リソースを割り当てることができ、ネットワークノードはまた、それに応じてリッスンするよう他のデバイスに要求することができる。ネットワークは、セル内のすべてのＤ２Ｄ能力を有するデバイスに、リッスンするように要求することができる。代わりに、上述したように、それはグループのデバイスだけにリッスンするよう要求してよい。そのグループは、デバイスが以前の位置に応じて属していたグループ、またはデバイスが現在の位置に応じて属しているグループであってよい。例えば、小さな移動が検出されるならば、デバイスが以前に付属していたグループだけが、リッスンするように要求されてよい一方、大きな移動またはセル変化が検出されるならば、新しいグループ（またはすべてのデバイス）が、リッスンするように要求されてよい。いくつかの実施形態において、移動しなかったデバイスはどのようなビーコン送信リソースも割り当てられない。
【００８１】
デバイスの位置変化は、ネットワークノードによって自律的に検出され得るか（例えばセル変化について）、デバイスからネットワークノードにシグナリングすることを経てネットワークノードによって検出され得る（例えばセル内の移動を検出しているデバイスのＧＰＳ）。可能性のある位置変化を検出する別の方法は、対応する無線リンクが変化したかどうかを評価することを含んでよい。
【００８２】
いくつかの実施形態はビーコン情報のベアラとして、短く、それゆえ効率的なローカルなデバイスＩＤ（ＬＤＩＤ）を用いる。このローカルなデバイスＩＤは、ネットワークノードにデバイスによって伝えられた対応するグローバルなデバイスＩＤ（ＧＤＩＤ）に対してネットワークノードの中で割り当てられる。
【００８３】
各ＧＤＩＤは本来デバイスと関連づけるか、デバイスによって使われた（ことによるといくつかの中のうちの）１つの参加者（サブスクリプション）に関連付けることができる。いっそうさらに、デバイス（または参加者）は、例えば、異なるサービス（デバイスによって提供されるか、要求される）のために異なるＧＤＩＤと関連づけられてもよい。１つの例は、ＧＤＩＤとしてＩＭＳＩを使うことである。１つのデバイスのためのいくつかのＧＤＩＤの例は、それ自身のＧＤＩＤをそれぞれ持ついくつかの飲料を売っているベンディングマシンであるかもしれない。ＧＤＩＤは、例えば参加者固有のＩＤとサービス固有のＩＤとのコンビネーションであってもよい。ＧＤＩＤは一般に、デバイスの位置または現在のトラッキングエリアまたはセルの接続と無関係にデバイスと関連づけられる。
【００８４】
ネットワークノードに保持された、可能性のあるＬＤＩＤのセットは、対応するビーコンの間で互いの相互相関を最小化するか、距離を最大化するように設計することができる。特定の時期に使われるＬＤＩＤのサブセットはまたそのような条件を考慮して選ぶことができる。特定の時期に使われるＬＤＩＤのサブセットのサイズは、例えばセルの中のＤ２Ｄ能力を有するデバイスの現在の数に、またはセルの中のＤ２Ｄを行っているデバイスの現在の数に依存してよい。従って、セルの中のＤ２Ｄ通信のためにネットワークノードによって使われるローカルなデバイスＩＤの数または特性またはその両方は、１つ以上の基準を使って決定されてよい。判定基準の例は、セル内で動作しているＤ２Ｄ能力を有するデバイスの現在の数、ＬＤＩＤの相関特性、使用可能なＬＤＩＤの総数、近隣のネットワークノードによって使われるＬＤＩＤなどを含むが、それらに限られない。
【００８５】
再び図２に変って、新しいデバイス（ＵＥ２０１）は２１５において、例えば登録要請メッセージ２１６の送信によってネットワークノード１０１への登録を開始し、ネットワークノード１０１は１１５において、例えば登録応答メッセージ２１７の送信によって新しいデバイス２０１を登録する。新しいデバイスがネットワークノードにすでに登録されていても、それに続く動作が起こるかもしれないので、この例においては新しいデバイスの登録はオプションであるように示される。
【００８６】
２２０において、デバイス２０１はＤ２Ｄ能力表示（例えばＤ２Ｄアクセス要求）を、１２０においてその表示を受信するネットワークノード１０１に送信する。図２において説明されるように、Ｄ２Ｄ能力表示はメッセージ２２１経由で送信することができる。代わりに、２２０と１２０とが、登録手順２１５、１１５の一部であってもよく、その場合、Ｄ２Ｄ能力表示は登録要請メッセージ２１６に含まれていて良い。Ｄ２Ｄ能力表示はデバイス２０１と関連づけられた１つ以上のグローバルなデバイスＩＤを含むことができる。
【００８７】
１２５において、１１０に関連して説明したのと同様の方法で、ネットワークノード１０１はビーコンリソースをデバイス２０１に割り当てる。適用可能ならば、ネットワークノード１０１はまた１２５における新しい条件に基づいて、既に他のデバイスの割り当てられたリソースを再割り当てすることができる。
【００８８】
ビーコン設定要請メッセージ２３１はオプションで２３０においてデバイス２０１によって送信し、１３０においてネットワークノード１０１によって受信することができる。
【００８９】
ビーコン設定要請メッセージ２３１への応答として、または自律的に、ネットワークノード１０１は、デバイス２０１のための割り当てたビーコンリソースについての情報を、メッセージ２３７を用いて、１３５で送信することができる。同様に、ビーコン設定要請メッセージ２３１への応答として、または自律的に、ネットワークノード１０１は、他のデバイスのための割り当てたビーコンリソースについての情報を、メッセージ２４２を用いて、１４０で送信することができる。いくつかの実施形態では、ネットワークノードは、近隣のネットワークノードのために割り当てられたビーコンリソースについての情報を受信することができる。
【００９０】
そのような実施形態において、１３５と１４０におけるビーコン情報の送信は、メッセージ２３７及び２４２、または別個のメッセージ（不図示）のうちの１以上を使っている近隣のネットワークノードへと、ネットワークノード１０１のセルの中のデバイスのために割り当てられたビーコンリソースについての情報を送信することをさらに含んでよい。
【００９１】
１４０におけるビーコン情報の送信はさらに、メッセージ２４２を使っている他の近隣デバイスのために割り当てられたビーコンリソースについての情報を送信することを含みさえしてもよい。
【００９２】
１３５と１４０における送信は、デバイス２０１と（例えば共有チャネルを使って情報をブロードキャストする）他のデバイスへの統合された送信であってよい。代わりにまたはさらに、１３５と１４０における送信は、デバイス２０１と他のデバイスそれぞれへの（例えば専用シグナリングを用いる）別個の送信を含んでもよい。
【００９３】
割り当てられたビーコンリソースについての情報は、どのようにビーコン信号を送信するか、または受信するか（すなわち検出すること）またはその両方を決定するために使うことができる。
【００９４】
送信２３７、２４２の割り当てられたビーコンリソースについての情報は、例えば、ローカルなデバイスＩＤ、ビーコン署名、ビーコン信号形態、ビーコン署名、ビーコン信号パターン（例えば、時間または周波数またはその両方において、ビーコン信号波形／署名が使われるべき場所のパターン、またはどのようにビーコン信号波形／署名が繰り返されるべきであるかの定義、またはその両方）、または（最小の／実際の／最大の）ビーコン送信電力、またはそれらの組み合わせを含んでよい。ビーコン送信電力は最大の許容送信電力、最小の許容送信電力、許容された送信電力範囲、および送信電力変化スキーム（例えば異なる時間／周波数のリソースのための異なる送信電力による）の１つ以上を含むことができる。
【００９５】
いくつかの実施形態では、１２５のアクションは登録手順２１５、１１５の一部であってよく、２３７および２４２の情報のうちの一部（例えばＬＤＩＤ）または全部が登録応答メッセージ２１７に含められてよい。
【００９６】
１４０における他のデバイスについての割り当て情報の送信は、どのデバイスが新しいデバイス２０１とのＤ２Ｄ通信の良好な可能性を持つかに基づくことができる（例えば、同様のＤ２Ｄ能力を持つ、地理的に近接している、潜在的Ｄ２Ｄリンクの良好な無線条件を持つ、など）。そのような情報は、ネットワークノード（またはネットワークのどのような他の適当なエンティティ）中に、ビーコン割り当て情報とともに各デバイスのために記憶されてよい。
【００９７】
２３５において、デバイス２０１はそれ自身の割り当てられたビーコンリソースについての情報を受信し、２４５においてそのビーコンを送信するためにその情報を使う。ビーコン送信は、どのような適当な既知の、または将来の方法でも使って行われてよい。例えば、ビーコン署名は、変調にマッピングされて（適用可能な標準に応じて）、送信されてよい。送信パターンは、署名の送信のために使われる時間／周波数のリソースであってよい。そのようなリソースは単一のインスタンスであるか、あるいは繰返しパターンに従ってよい。そのパターンは時間領域の中で規則的であるか、或いは不規則であってよく、また規則的な、或いは不規則な方法で周波数においてシフトすることができる。周波数シフトはパターンの２つの送信インスタンスの間においてであってよいけれども、特定のビーコン送信セッションの中でのリソースの周波数シフトであってもよい。送信パターンはさらに、パターンのための開始時間と停止時間とを含んでよい。停止条件が満たされる場合、送信パターンの末尾に達する場合、またはタイマがタイムアウトする場合、ビーコン送信は例えば停止してよい。
【００９８】
２４０において、デバイス２０１は他のデバイスの割り当てられたビーコンリソースについての情報を受信する。この情報は、関連するビーコンリソースだけを監視するために２５０において使われる。いくつかの実施形態においては、受信されたビーコン設定メッセージに従って、ビーコン信号が期待されている時間間隔で、デバイスはその受信機を可にするだけである。
【００９９】
この例においてオプションであると述べたアクションの１回以上が他の例においてオプションでなくともよいことは注目される。同様に、この例においてオプションでないと述べたアクションの１回以上が他の例においてオプションであってもよい。
【０１００】
この例において、１３５、２３５、２４５はオプションであると説明されている。それらはマスタとして作動しているデバイスにあてはまるだけである。
【０１０１】
前述したように、マスタデバイスはビーコン信号を送信し、スレーブデバイスはビーコンを走査する。デバイスが、マスタの役割のみ、スレーブの役割のみ、または両方の役割の組み合わせを果たすことができることは注目されるべきである。
【０１０２】
状況（例えば、ビーコンが送られるかどうか、無線条件など）によって、ビーコンは２５５で検出されることがあり、あるいはされないことがある。検出プロセスは、既知のあるいは将来のアルゴリズムのうち適当などれを含んでもよい。例えば検出は、信号検出、エネルギー検出、１つ以上の既知のシーケンスへの相関、およびコード化されたメッセージのデコーディングの１つ以上を含むことができる。１つのビーコン信号またはビーコン信号のサブセットが発見されたなら（発見された各ビーコン信号は一般に別個のＬＤＩＤまたは別個のデバイスまたはその両方と関連づけられる）、発見の手順２５０、２５５は終了してよい。特定の（前もって決定されるか、動的である）時間が経過したとき、例えば送信パターン情報または発見セッションと関連づけられたタイマがタイムアウトしたときに、それはまた終了することができる。
【０１０３】
ビーコン測定報告（またはビーコン検出報告）２６１は、２６０においてデバイス２０１によって送信される。それは１６０においてネットワークノード１０１によって受信される。これは、デバイスがビーコン監視装置（スレーブ）である場合の状況と関連している。報告は、予定時間／間隔（ビーコンが検出されているか否かを問わず）で、または２５５におけるビーコン検出の結果として、またはその両方で送信されることができる。
【０１０４】
いくつかの実施形態において、ビーコン測定報告２６２は１６０においてネットワークによって送信されて、２６０においてデバイスによって受信される。これは、デバイスがビーコンを送信しているデバイス（マスタ）である場合の状況と関連している。
【０１０５】
従って、ネットワークノード１０１は１６０において１回以上のビーコン測定報告を受信し、２６２により例示されるようにその中の情報（の少なくとも部分）を１つ以上のデバイスに送信できる。例えば、この情報は、ビーコン測定報告における情報に基づいて、他のデバイスがＤ２Ｄ接続のための潜在的な相手である各デバイスに送信されてよい。それぞれのネットワークノードへの、およびネットワークノードからのビーコン測定報告２６１および２６２はそれぞれ同じか、または異なるフォーマットを持ってよい。
【０１０６】
ビーコン測定報告２６１は、いくつのビーコン（もしあれば）が検出されているか、および、検出されたビーコンの詳細に関する情報を含む可能性がある（例えば、ビーコン署名、対応するＬＤＩＤ、セルＩＤ（すなわち、ビーコン送信デバイスが属しているセルの表示）、ビーコンの受信電力、ＲＳＳＩ、ＲＳＲＰ、干渉推定値、信号対雑音比（ＳＮＲ）、信号対干渉比（ＳＩＲ）、信号対雑音および干渉比（ＳＩＮＲ）、推定したパス損失または対応するデバイス間の無線チャネルまたはその両方などのうちの１つ以上）。検出された信号の他の詳細はまた報告されてもよい。例えば、検出された信号のタイミングは（例えばＯＦＤＭシステムのための巡回プレフィクスの中で）、別のタイミング（例えばネットワークノードとの接続のためのＤＬまたはＵＬタイミング）に関連して報告されてもよい。実際の検出の前の検出トライアルの数も報告されてよい。報告内容の別の例は、ビーコン信号がどの時間／周波数リソースで検出されたかに関する表示であってもよい。
【０１０７】
ビーコン測定報告２６２は報告２６１と同じか、または同様な情報を含んでよい。さらに、または代わりに、特定のデバイスへのビーコン測定報告２６２は、デバイスが、それらが確かに特定のデバイスのビーコンを検出したことを示した情報（例えばＩＤ、無線条件推定など）を含めてよい。さらにまたは代わりに、特定のデバイスへのビーコン測定報告２６２は、特定のデバイスに干渉を引き起こす可能性があるデバイス（もしあれば）に関する情報を含んでよい。
【０１０８】
ビーコン測定報告は、デバイス２０１と別の特定のデバイスとの間の接続のセットアップにおける補助１６５、１７０、１７５を行うためにネットワークノードによって使うことができる。例えば、ネットワークノードは、Ｄ２Ｄ接続を設定するために、またはＤ２Ｄ接続を設定するか全然しないかを決めるために、またはその両方のために、その情報（の少なくとも一部）を適切なデバイスに中継できる。
【０１０９】
別の例において、その報告は、１６５において、セルラ接続またはＤ２Ｄ接続のどちらを使うか（または接続を全然設定しないか）を決めるために用いることができる。デバイス２０１が特定のデバイスのビーコンを検出したならば、Ｄ２Ｄ接続を選択することができ、特定のデバイスのビーコンが検出されなかったならば、セルラ接続を選択することができる。他の条件はまた、例えば潜在的なＤ２Ｄリンク上の無線伝搬条件、ネットワークノードとデバイス２０１との間のリンクの上（またはネットワークノードと１つ以上の他のデバイス（例えば潜在的Ｄ２Ｄ通信の他方のデバイス）との間のリンク上、またはその両方）の無線伝搬条件、ネットワークノードの現在のトラフィック負荷、ネットワークノードの容量、またはそれらの組み合わせなどを適用することができる。例えば、現在のセルのトラフィック負荷が高ければ、または、ネットワークと潜在的Ｄ２Ｄ通信のデバイスとの間のそれぞれのリンクの無線条件が悪い一方でデバイス間の潜在的Ｄ２Ｄリンクの無線条件が良好であれば、または、その両方であれば、Ｄ２Ｄ接続を選択できる。また近隣セルのビーコンも走査プロセスおよびネットワークへの報告に含まれている実施形態において、そのような情報は、Ｄ２Ｄ接続のセットアップを開始する前にデバイスを近隣セルへハンドオーバ（またはより一般にそのデバイスのためのセルスイッチを実行）する（またはハンドオーバを近隣セルに要求する）か否かを決定するために使用できる。
【０１１０】
セルラ接続が選ばれるならば、ネットワークノードは１７５においてそれを設定する。Ｄ２Ｄ接続が選ばれるならば、ネットワークノードは１７０と２７０におけるセットアップを補助することができる。例えば、ネットワークノードは、使用するＤ２Ｄ接続のタイプ（未ライセンスまたはライセンス済み、適用可能なプロトコルなど）を決定し、リソースをＤ２Ｄ接続に割り当て（例えば帯域、時間、周波数）、電源制御（例えば受信されたビーコン信号電力に基づいた初期の送信電力の設定）を提供することができる。この補助はネットワークノードとデバイス２０１との間（およびネットワークノードと他の特定のデバイスとの間）のシグナリング２７１、２７２を利用することができる。例えば特定のデバイスのビーコンが検出されたときに、そのようなシグナリングにより、デバイス２０１からその特定のデバイスへと肯定応答メッセージを直接的に送信することが不要になる可能性がある。
【０１１１】
Ｄ２Ｄ接続が設定された場合に、２つのデバイスは２７５においてＤ２Ｄ通信プロトコルに従って直接互いと通信する。
【０１１２】
Ｄ２Ｄ通信（例えば、図２の２７５において説明されるような）中に、いくつかのまたはすべてのデバイスツーデバイスペアの間のパス損失は従ってネットワークノードに、またはデバイスの１つ以上に、またはその両方に知られている可能性がある。例えば、図２の２５５から、測定デバイスは、被測定デバイスとそれ自身との間のパス損失に関する知識を取得することができ、図２の２６１から、ネットワークはすべての推定されたパス損失の知識を与えられるか、またはすべての実行された測定についてパス損失を推定するための情報を要求することができ、図２の２６２から、デバイスが他のデバイスのすべてまたはいくつかのために推定されたパス損失の知識を与えられることができる。
【０１１３】
再び図１ａのデバイス６０または７０またはその両方（及び対応して図１ｂのデバイス７０または２０またはその両方）の状況を見て、デバイスのうちの１つ以上が経験した干渉のための判定基準を決定し、その後、決定された干渉判定基準に基づいて干渉管理要請メッセージをネットワークノードに送信する実施形態を説明する。
【０１１４】
いくつかの実施形態（例えばそこで、デバイス６０とデバイス７０は同じ周波数を使っていない）において、経験した干渉はとても強いかもしれないので、デバイス６０とデバイス７０は同じ周波数を使っていないけれども、それでも問題に直面する。デバイスが同じ周波数を使っていないことは、それらが、割り当てられたチャネルの異なる部分を利用することを暗示する可能性がある（システムが直交周波数分割多重（ＯＦＤＭ）を使っている場合に、異なる副搬送波を異なるＤ２Ｄリンクに割り当てることによってそれは容易に達成される）。それはまたデバイス６０とデバイス７０とが異なるチャネルを使っていることを意味することもあるが、干渉する信号と所望の信号との間の電力差が大きすぎるために、デバイス６０はそれでも問題に直面する可能性がある。
【０１１５】
１つの実施形態によると、ネットワークノード４０と同様に４つのＤ２Ｄ能力を有するデバイス（図１ａの３０、６０、７０、８０）は、他のＤ２Ｄ能力を有するデバイスのどれが範囲内にあるかに関する知識を持っている。特に、デバイス６０は、デバイス７０が干渉するかもしれないことに気づいていて、逆もまた同様である。デバイス６０に対して、デバイス７０から来る干渉がデバイス６０とデバイス３０との間の通信を著しく悪化させないであろうことを保証するために、デバイス６０は、デバイス６０に干渉しないためにデバイス７０により利用されるべき最大送信電力が何であるか決定でき、デバイス７０へ通知されるこの制限を保証することをネットワークノードへ要求できる。
【０１１６】
第１の数値例として、デバイス６０が、デバイス７０からの干渉はデバイス６０の受信機の中での熱雑音のレベルを越えないことを必要とすると想定する（それは、例えば−１０７ｄＢｍ／ＭＨｚであると決定されている）。さらに、デバイス６０とデバイス７０との間のパス損失が例えば９０ｄＢであることが知られていると想定する。そのとき、デバイス６０は、デバイス７０の送信（ＴＸ）電力が−１７ｄＢｍ／ＭＨｚに制限されるべきであるという要求をネットワークノードにすることができる。使用可能な帯域幅が例えば２０ＭＨｚである場合、このことは、総ＴＸ電力が−１７＋１３ｄＢｍ＝−４ｄＢｍに制限されるべきであることに対応する。この例は、干渉判定基準の決定がデバイスによって自律的にされ得る１つの実施形態を説明する。ネットワークノードは、デバイス６０によって要求されたように実際に行うことをデバイス７０に要求するか、或いはデバイス７０と交渉するとすぐに、デバイス７０がデバイス６０によって要求されたほど十分に出力を制限することができないことを決定することができる。後者の場合に、デバイス６０は通知を受け、適切な行動をとることができる。
【０１１７】
いくつかの状況において、デバイス６０は、デバイス７０からの干渉がどれほど悪いかを全く知らない。この場合に、デバイス７０はそのビーコンを送ることができ、デバイス６０はリッスンすることができる。デバイス６０はそのとき、デバイス７０から受信した信号の信号強度を評価し、それが強すぎて、重大な干渉を起こすかどうかを判定することができる。もしそうなら、前の例において説明されるように、或る要求がネットワークに対してできる。この例は、ネットワークノードからテスト信号情報（例えばデバイス７０のビーコン情報を含む）を受け取った後に干渉判定基準を決定できる１つの実施形態を説明する。
【０１１８】
いくつかの実施形態において、デバイス６０は、デバイス６０のための性能を低下させないために減少させる必要のあるデバイス７０からの干渉電力がどのくらいの量であるかを決定することができる。それから、干渉におけるこの減少を遂行するためにネットワークノードに要求をすることができる。ネットワークノードは、例えば、デバイス７０に、より小さい送信電力を用いさせるか、またはデバイス６０に、デバイス７０の周波数から離れた周波数を割り当てるか（または、これより先で理解できるであろうように、その逆も）、またはそれら両方の組み合わせにより続行する。この例においては、したがって減少量はデバイス６０によって決定される。これは、とられた対策が不必要に大きくないことを保証する。
【０１１９】
デバイス６０からネットワークへの要求の結果が、デバイス７０の送信電力を減少することも、別の周波数にデバイス７０を移動することも可能でないことがあり得る。ネットワークからの代替の対策は、それから、周波数においてデバイス６０を移動するか、デバイス３０のためにより大きな送信電力を許すこと（それはまたデバイス６０で干渉状況を改善するであろう）であってよい。別の対策は、デバイス３０とデバイス６０との間のリンクのデータ送信速度を減らすことであってもよい。そして、それは干渉に対してより頑強であろう。
【０１２０】
いくつかの状況において、ネットワークノードは、デバイス６０によって（及びことによるとその上デバイス７０によって）、状況（例えば、面倒な干渉がある）を知らされることがあり、送信電力を減らすことによって、または別の周波数にリンクの１つを移動することによって干渉レベルを下げることが可能でないと結論することができる。そのような（および他の）状況において、干渉管理は、２つのリンク（６２及び７２）のフレーム構成の適切な位置合わせによって処理され得る。特に、デバイス６０が、デバイス７０からの過大な干渉を経験することについての問題を報告したと想定する。ネットワークはそのとき、（できれば、図４において説明されるように、デバイス６０とデバイス７０とが同時に送信し、受信することを保証することにより）デバイス７０からの干渉が問題にならないように、デバイス３０との通信によって使われた送信／受信パターンをシフトするようデバイス６０に要求することができる。代わりに、同じ効果が得られるように、ネットワークは、そのＴＸ／ＲＸタイミングを調整するためにデバイス７０を要求するかもしれない。
【０１２１】
上に述べたように、図４は、デバイス６０及びデバイス７０の受信及び送信のためにタイムスケジュールをそれぞれ説明する。調整の前に、デバイス６０と７０の送信／受信パターンは位置合わせされていない（すなわち、デバイス６０が送信する時デバイス７０は受信し、逆もまた同様）。調整の後に、デバイス６０と７０の送信／受信パターンは位置合わせされ（すなわち、デバイス６０と７０が同時に送信し、受信する）、それによりデバイス７０の送信がデバイス６０の受信を妨害することが避けられ、逆もまた同様である。
【０１２２】
互いに干渉を起こしている異なるＤ２Ｄリンクが常時アクティブである必要がない状況において、リンク間の干渉は、時分割することによって管理することができる。特に、ネットワークは、非重複タイムスロットを異なるＤ２Ｄリンクに割り当てることができる。ＯＦＤＭが（例えば）使われるならば、異なる時間／周波数リソースを異なるＤ２Ｄリンクに割り当てることができる。これが必要であるか、あるいは十分でさえあるかを知るために、ネットワークはできれば可能な限り豊富な干渉状況の知識を持ってもよい。
【０１２３】
上に述べたように、実施形態はＤ２Ｄ通信における有効な干渉管理を可能にさせる（それは、異なるＤ２Ｄリンクに関して、必要以上に送信能力を制限することなく、干渉を十分に低いレベルに保持することを保証し得る）。実施形態は、ネットワーク補助型Ｄ２Ｄ通信において、異なるＤ２Ｄリンクを決定するための、帯域が効率的な方法を規定する。
【０１２４】
いくつかの実施形態において、デバイス６０が上述した手順そのものを開始するというよりも、その手順を開始するのはネットワークである（例えば、上で説明された行動をとるようデバイス６０またはデバイス７０またはその両方に要求することによって）。他の実施形態において、上で例示したように自律的に干渉判定基準を決定することによって、または図３ａとの関連において説明するようにネットワークノード経由でデバイス７０にテストシグナリングを要求することによって、デバイス６０はその手順を開始する。
【０１２５】
図３ａは、いくつかの実施形態に従って、ネットワークノード（例えば図１ａのネットワークノード４０）とＤ２Ｄ能力を有するデバイス（例えば図１ａのデバイス６０）とによってそれぞれ実行された方法の例と、それらの間のシグナリングとを説明する結合されたフローチャート及びシグナリング図である。方法３００はネットワークノード３９０によって実行され、方法４００はデバイス（ユーザ装置ＵＥ）４９０によって実行される。
【０１２６】
図３ｂは、いくつかの実施形態に従って、ネットワークノード３９０ｂ（例えば図１ａのネットワークノード４０）とＤ２Ｄ能力を有するデバイス（ＵＥ１、ＵＥ２、ＵＥ３）４９０３ｂ、４９２ｂおよび４９３ｂ（例えば図１ａのデバイス６０、７０、３０）それぞれとの間のシグナリングの例を示している関連したシグナリング図である。ネットワークノード３９０ｂは図３ａのネットワークノード３９０に対応してもよく、デバイス４９０ｂは図３ａのデバイス４９０と対応してもよい。図３ａと３ｂにおいて、いくつかのステップとシグナリングは破線で示されている。これは、これらが少なくともいくつかの実施形態のためのオプションのステップであることを示す。
【０１２７】
いくつかの実施形態に応じた状況はこれから図３ａと３ｂとをまとめて参照することによって説明されるであろう。４０３ｂにより示されるように、第１のデバイス４９０、４９０ｂは第３のデバイス４９３ｂとＤ２Ｄ通信をしている。４０２ｂにより示されるように、第２のデバイス４９２ｂは、第１のデバイス４９０、４９０ｂへの干渉を起こす。
【０１２８】
４５０と４５１と４５１ｂによって示されるように、方法４００は、４４０において干渉状況または判定基準またはその両方を決定し、干渉判定基準と関連した干渉管理要請メッセージをネットワークノードに送信することを含む。
【０１２９】
干渉管理要請メッセージ４５１、４５１ｂは３５０においてネットワークノードによって受信される。３５０の受信の後に、ネットワークは、第１の無線通信デバイス３６１、３６１ｂ、第２の無線通信デバイス（干渉デバイス）３６２ｂ、および第３の無線通信デバイス（第１のデバイスとＤ２Ｄ通信しているデバイス）３６３ｂのうちの少なくとも１つへ干渉制御メッセージを送信する（３６０）。干渉制御メッセージはそれぞれのデバイスで受信されて、デバイスはそれに応じてその通信を調整する。
【０１３０】
干渉判定基準はここに開示された例のどれでも含むことができる。例えば、干渉判定基準は、電源の表示（最大許容干渉受信電力、最大許容干渉送信電力、要求された干渉電力減少分を示している電力値の差分）を含むか、または特定のデバイスからの干渉が受入れ可能でない（すなわち対策決定はネットワークノードに任せられる）ことの表示を簡潔に含んでもよい。
【０１３１】
オプションで、方法４００は、第２の（干渉）デバイステストシグナリングの要求４１１、４１１ｂをネットワークノードに送信すること（４１０）を含み、方法３００は、ネットワークノードからその要求を受信すること（３１０）を含む。ネットワークノードは、３２０において説明されるようにテスト信号リソースを割り当て（例えば図２の１１０と１２５におけるリソース割り当てに類似するかまたは等しい）、３３０と３３１、３３１ｂによって説明されるように、被干渉デバイス４９０に割り当てに関する情報（第２のデバイステストシグナリング情報）を送信できる。デバイス４９０は４３０においてその情報を受信する。３３２ｂにより示されるように、ネットワークはまたテストシグナリングコマンドを第２のデバイスに送信することができる。
【０１３２】
いくつかの実施形態において、この方法は３２０（または３３０）と４３０とにおいてそれぞれ始まる。すなわち、干渉計測はネットワークノードによって開始される。
【０１３３】
第２のデバイス４９２ｂがテスト信号を送信するとき、被干渉デバイス４９０、４９０ｂは、干渉判定基準を決定するために、および例えば被干渉デバイスが、４４０において説明されるように第２の無線通信デバイスに関する干渉状況を判定した際には、その干渉判定基準（またはそれの表示）をネットワークノードに送信するためにテスト信号を使うことができる。代わりに、４４０における決定はテストシグナリングなしで実行することができる（例えばデバイス４９０、４９０ｂによって許容されている絶対受信信号電力レベルを参照して）。従って、いくつかの実施形態において、上で例示されるように、この方法は３５０と４４０とにおいてそれぞれ始まる。
【０１３４】
４４０における決定がされる場合、４５０と４５１、４５１ｂによって説明されるように、デバイスは、ネットワークノードに、干渉判定基準または干渉状況またはその両方と関連した干渉管理要請メッセージを送信する。干渉管理要請メッセージは３５０においてネットワークノードによって受信される。
【０１３５】
ネットワークは３６０において、３６１、３６１ｂにより示されたように第１の無線通信デバイスと、３６２ｂにより示されたように第２の無線通信デバイス（干渉デバイス）と、３６３ｂによって示されたように第３の無線通信デバイス（第１のデバイスとＤ２Ｄ通信をしているデバイス）とのうち少なくとも１つに干渉制御メッセージを送信する。
【０１３６】
干渉制御メッセージが被干渉デバイスに宛てられるならば、それは４６０において受信されて、デバイスは４７０においてそれに応じてその通信を調整する。
【０１３７】
干渉制御メッセージが第２または第３のデバイスに宛てられるならば、いくらかの関連情報（例えば、他のデバイスでどの変化が起こされているかついてのかの情報）が被干渉（第１の）デバイスによって３６１、３６１ｂで同様に受信されてよい。
【０１３８】
第１、第２、および第３のデバイスの少なくとも１つによる調整はここに開示されたどの例でも含むことができる。例えば、その調整は、電力調整、周波数調整、時間調整、またはデータ送信速度調整を含んでよい。従って、第１、第２および第３のデバイスのうちの少なくともいずれかの通信の調整は、例えばここに説明されたどの方法に従ってもよい。例えば、第２のデバイスが、その送信電力を（差分値分または絶対電力レベルまで）下げること、その時間送信パターンまたは周波数送信パターンまたはその両方を調整すること、および別の搬送周波数に移動することの少なくともいずれかをするように要求されてもよい。代わりにまたはさらに、第１のデバイスが、その時間送信パターンまたは周波数送信パターンまたはその両方を調整すること、そのデータ送信速度を調整すること、および別の搬送周波数に移動することの少なくとも何れかを行うように要求されてもよい。その上、代わりにまたはさらに、第３のデバイスが、その送信電力を（差分値の分または絶対電力レベルまで）増大させること、その時間送信パターンまたは周波数送信パターンまたはその両方を調整すること、そのデータ送信速度を調整すること、および別の搬送周波数に移動することのうち少なくともひとつを行うように要求されてもよい。別の例は、第１と第３のデバイスの間のリンク上の通信が、第２のデバイスによる通信と位置合わせされる（例えば時間的整合、リンク共有により）場合を含む。
【０１３９】
調整がされるとき、そのことはネットワークノードに、そして場合によると被干渉デバイスに（例えばネットワークノード経由で）報告されてもよい。
【０１４０】
１つのネットワークノードがネットワーク補助型デバイスツーデバイス通信に関係している場合に、ここの例が主に状況を参照することは注目されるべきである。このネットワークノードは、どのような適当なネットワークノード（例えば基地局または（ｅ）ＮｏｄｅＢ、ネットワーク制御装置ノード、リレーノードなど）ででもあってもよいことは注目される。ネットワークノードはひとつまたはいくつかの基地局と関連しているリソースを管理している可能性がある。例えば、ネットワーク制御装置は、異なる基地局の下で動作しているデバイスにリソースを割り当てることができる。
【０１４１】
いくつかの実施形態において、第１のネットワークノードはリソースの第１のセットを管理していて、第２のネットワークノードはリソースの第２のセットを管理している。第１と第２のセットは一致していてもよいし、オーバーラップしていてもよいし、非オーバーラップであってもよい。第１のネットワークノードは第２のネットワークノードの中で割り当てられたリソースについての情報を取得することができる。そのような情報は第１のネットワークノードの制御下にあるデバイスと共有されてもよい。第１のデバイスが第１のネットワークノードの制御下にあり、かつ、第２のデバイスが第２のネットワークノードの制御下にあるならば、Ｄ２Ｄ接続は、それらネットワークノードの一方が他方のネットワークノードを必要な場合にリレーとして使用することにより、または、ひとつのネットワークノードが第１と第２のネットワークノードの両方を制御することにより、またはその両方により補助することができる。
【０１４２】
図５はいくつかの実施形態に従う配置例５００を説明しているブロック図である。配置例は無線通信デバイス（例えば、図１ａと図１ｂのデバイス、または図３ａおよび図３ｂのデバイス４９０および４９０ｂそれぞれの１つ）に含まれてよい。
【０１４３】
この配置は、受信機５１０、送信機５２０、制御部５３０（オプションで）、および干渉判定部５４０を含んでよく、例えば図３ａの方法４００を実行するように構成できる。
【０１４４】
上に述べたように、干渉判定部５４０は、第２の無線通信デバイスと関連づけられた干渉判定基準を決定するように構成することができて、送信機５２０は、干渉判定基準と関連した干渉管理要請メッセージをネットワークノードに送信するように構成することができる。
【０１４５】
受信機５１０は、ネットワークノードから第２のデバイステストシグナリング情報を受信するように構成することができる。そのような実施形態において、干渉判定部は、受信した第２のデバイステストシグナリングに基づいた干渉判定基準を決定するように構成することができる。
【０１４６】
いくつかの実施形態において、送信機はさらに、干渉制御手順を開始するようにネットワークノードに第２のデバイステストシグナリングに関する要求を送信するように構成することができる。
【０１４７】
コントローラ５３０は、送信機または受信機またはその両方に、例えば判定部による判定に基づいて、説明した方法の動作を実行させるように構成することができる。コントローラは、また、判定部５４０を制御するように構成することができる。
【０１４８】
図６はいくつかの実施形態に従って配置例６００を説明しているブロック図である。配置例はネットワークノード（例えば図１ａ及び図１ｂの４０、または図３ａ及び図３ｂの３９０及び３９０ｂそれぞれ、またはその両方）に含まれてよい。
【０１４９】
この配置は受信機６１０、送信機６２０、および割り当て部６３０を含み、例えば図３ａの方法３００を実行するように構成できる。
【０１５０】
受信機６１０は、デバイスツーデバイス通信を実行するように構成した第１の無線通信デバイスから干渉判定基準と関連した干渉管理要請メッセージを受信するように構成でき、送信機６２０は、干渉制御メッセージを、第１の無線通信デバイス、第２の無線通信デバイス、および第３の無線通信デバイスの少なくとも１つに送信するように構成することができる。
【０１５１】
割り当て部６３０は、テスト信号リソースを第２のデバイスに割り当てるように構成することができる。
【０１５２】
いくつかの実施形態において、受信機６１０は、干渉制御手順を開始する第１のデバイスから、第２のデバイステストシグナリングの要求を受信するようにさらに構成することができる。
【０１５３】
送信機６２０は、ネットワークノードによって干渉制御手順を開始するために、または第１のデバイスからの第２のデバイステストシグナリングの要求の受信への応答として、第２のデバイステストシグナリング情報を第１のデバイスに、テストシングナリングコマンドを第２のデバイスに送信するようにさらに構成することができる。
【０１５４】
この配置は、割り当て部、送信機、および受信機の少なくともひとつに、説明された方法の動作を実行させるよう構成されたコントローラ（不図示）をまた含むことができる。
【０１５５】
本発明の説明した実施形態およびそれらの均等物は、ソフトウェアまたはハードウェアまたはそれの組み合わせにおいて実現することができる。それらは、信号処理プロセッサ（ＤＳＰ）、中央処理装置（ＣＰＵ）、コプロセッサユニット、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、または他のプログラマブルなハードウェアなど、通信装置に関連付けられた、あるいは通信装置に統合された汎用回路により、または、例えば特定用途向け集積回路（ＡＳＩＣ）などの専用回路により実現することができる。すべてのそのような形式は、発明の範囲の中にあるものとして意図されている。
【０１５６】
本発明は、発明の実施形態のどれかに従っている回路／ロジックを含むか、方法を実行している電子装置（例えば無線通信デバイス）において具現化することができる。電子装置は例えば、ポータブルな、またはハンドヘルドの移動無線通信装置、移動無線端末、自動車電話、基地局、基地局コントローラ、コミュニケータ、電子手帳、スマートフォン、コンピュータ、プリンタ、ノートブック、または移動型ゲーム装置であってよい。
【０１５７】
本発明のいくつかの実施形態によると、図７の７００によって説明されるように、コンピュータプログラム製品は例えばディスケットまたはＣＤ−ＲＯＭなどのコンピュータ読取り可能媒体を含む。コンピュータ読取り可能媒体７００は、プログラム命令を含むコンピュータプログラムをその上に記憶することができる。コンピュータプログラムはデータ処理ユニット７３０（それは例えばモバイル端末またはネットワークノード７１０に含まれてもよい）にロード可能であってよい。データ処理ユニット７３０中にロードされた際に、コンピュータプログラムは、データ処理ユニット７３０に関連付けられた、または統合されたメモリ７２０に保存されてよい。いくつかの実施形態によると、コンピュータプログラムは、データ処理ユニットにロードされ実行される際に、例えば図３ａに示したどの方法に従ってでも、データ処理ユニットに方法のステップを実行させることができる。
【０１５８】
本発明は様々な実施形態に関してここに説明されている。しかし、当業者は、まだ発明の範囲に入るであろう、説明された実施形態のたくさんのバリエーションを認めるであろう。例えば、ここに説明された方法の実施形態は一定の順序で実行されている方法のステップを通して方法の例を説明する。しかし、これらの連続イベントが、発明の範囲を逸脱せずに別の順序で起こってもよいことは認められている。さらに、いくつかの方法ステップは連続して実行されると説明されていても、それら方法ステップは平行に実行することができる。
【０１５９】
同じ要領で、発明の実施形態の説明において、機能ブロックの特定のユニットへの分割が本発明を決して制限していないことは注目されるべきである。反対にこれらの分割は例に過ぎない。ここに１つのユニットと説明された機能ブロックは、２つ以上のユニットに分割されてもよい。同じ要領で、２つ以上のユニットとして実施されるとここに説明される機能ブロックは、発明の範囲を逸脱せずに単一ユニットとして実施されてもよい。
【０１６０】
上に説明したように、説明した実施形態の制限が、単に説明に役立つ目的のためであり、決して制限していないことは理解されるべきである。
【図１ａ】
0006329532.tif 000002
【図１ｂ】
0006329532.tif 000003
【図２】
0006329532.tif 000004
【図３ａ】
0006329532.tif 000005
【図３ｂ】
0006329532.tif 000006
【図４】
0006329532.tif 000007
【図５】
0006329532.tif 000008
【図６】
0006329532.tif 000009
【図７】
0006329532.tif 000010