(57)【特許請求の範囲】
【請求項１】
第１の通信デバイス（１００）による、第２の通信デバイス（１０２）とのデバイスツーデバイス（Ｄ２Ｄ）通信のための方法であって、
前記第１の通信デバイス（１００）による前記第２の通信デバイス（１０２）とのＤ２Ｄ通信のためのリソース割り当てに影響し得る無線ネットワークノード（１１０）の複信構成に関する情報を取得すること（３００）と、
前記情報に基づいて、リソースパターン（ＲＰＴ）のセットを導出すること（３０２）と、
スケジューラ情報に基づいて、前記ＲＰＴのセットのうちの１つのＲＰＴを選択すること（３０４）と、
前記第２の通信デバイス（１０２）へ、選択された前記ＲＰＴを識別するために使用されるインデックスをシグナリングすること（３０６）と、
を含む方法。
【請求項２】
選択される前記ＲＰＴに基づいて、前記第１の通信デバイス（１００）から前記第２の通信デバイス（１０２）へのＤ２Ｄ送信のために使用されるべきリソースを導出すること（８００）と、
Ｄ２Ｄ送信のために導出される前記リソースを用いて、前記第１の通信デバイス（１００）から前記第２の通信デバイス（１０２）へデータを送信すること（８０２）と、
をさらに含む、請求項１の方法。
【請求項３】
前記第１の通信デバイス（１００）による前記第２の通信デバイス（１０２）とのＤ２Ｄ通信のためのリソース割り当てに影響し得る無線ネットワークノード（１１０）の複信構成に関する情報を取得すること（３００）は、
前記無線ネットワークノード（１１０）の通信カバレッジ内に位置する場合に、前記無線ネットワークノード（１１０）から前記情報を受信すること、
を含む、請求項１〜２のいずれかの方法。
【請求項４】
前記第１の通信デバイス（１００）による前記第２の通信デバイス（１０２）とのＤ２Ｄ通信のためのリソース割り当てに影響し得る無線ネットワークノード（１１０）の複信構成に関する情報を取得すること（３００）は、
前記無線ネットワークノード（１１０）の通信カバレッジのエッジ近くに位置する場合に制御プレーン中継機から、又は、前記無線ネットワークノード（１１０）の通信カバレッジ外に位置する場合に第３の通信デバイスから、前記情報を受信すること、
を含む、請求項１〜３のいずれかの方法。
【請求項５】
前記ＲＰＴのセットは、前記情報により示される定義済みキャリアについての周波数分割複信（ＦＤＤ）／時間分割複信（ＴＤＤ）方式に基づいて導出される、請求項１〜４のいずれかの方法。
【請求項６】
スケジューラ情報に基づいて前記ＲＰＴのセットのうちの１つのＲＰＴを前記選択すること（３０４）は、
前記スケジューラ情報がＦＤＤ複信方式用か又はＴＤＤ複信方式用かに基づいて、前記ＲＰＴのセットのうちの前記１つのＲＰＴを選択すること、
を含む、請求項５の方法。
【請求項７】
前記ＲＰＴのセットは、前記情報により示されるＴＤＤ構成に基づいて導出される、請求項１〜６のいずれかの方法。
【請求項８】
前記ＲＰＴのセットは、前記情報により示される、ＰＲＡＣＨ構成、ＨＡＲＱパラメータ、及びＰＵＣＣＨ又はＳＲＳ構成、のうちのいずれか１つ以上に基づいて導出される、請求項１〜７のいずれかの方法。
【請求項９】
前記ＲＰＴのセットは、ＰＲＡＣＨについて使用されるリソースへデータリソースをマッピングすることを回避するように前記ＰＲＡＣＨ構成に基づいて導出される、請求項８の方法。
【請求項１０】
前記ＲＰＴのセットは、前記無線ネットワークノード（１１０）によるアップリンク再送のために使用されるリソースを回避するように、前記ＨＡＲＱパラメータに基づいて導出される、請求項８の方法。
【請求項１１】
前記ＲＰＴのセットは、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避するように、前記ＰＵＣＣＨ又はＳＲＳ構成に基づいて導出される、請求項８の方法。
【請求項１２】
前記ＲＰＴのセットは、前記情報により示される、周期性、時間オフセット及び／又はリソース割り当てのうちのいずれか１つ以上に基づいて導出される、請求項１〜１１のいずれかの方法。
【請求項１３】
前記ＲＰＴのセットは、前記第２の通信デバイス（１０２）へＤ２Ｄ通信されるべきトラフィックのタイプに基づいて導出される、請求項１〜１２のいずれかの方法。
【請求項１４】
前記ＲＰＴのセットは、前記第２の通信デバイス（１０２）へ前記Ｄ２Ｄ通信を通じて送信されることになるトラフィックの関連付けられるタイプについてのデータパターンにおける、データサブフレームの定義された密度を提供するように導出される、請求項１３の方法。
【請求項１５】
第１の通信デバイス（１０２）による、第２の通信デバイス（１００）とのデバイスツーデバイス（Ｄ２Ｄ）通信のための方法であって、
前記第１の通信デバイス（１０２）による前記第２の通信デバイス（１００）からのＤ２Ｄ通信を受信するためのＤ２Ｄリソース使用に影響し得る無線ネットワークノード（１１０）の複信構成に関する情報を取得すること（５００）と、
前記情報に基づいて、リソースパターン（ＲＰＴ）のセットを導出すること（５０２）と、
前記第２の通信デバイス（１００）によりシグナリングされるインデックスを受信すること（５０４）と、
前記インデックスに基づいて、前記ＲＰＴのセットのうちの１つのＲＰＴを選択すること（５０６）と、
選択される前記ＲＰＴに基づいて、前記第２の通信デバイス（１００）からのＤ２Ｄ受信のために使用されるべきリソースを導出すること（５０８）と、
を含む方法。
【請求項１６】
前記第１の通信デバイス（１０２）において、Ｄ２Ｄ受信のために導出される前記リソースを用いて、前記第２の通信デバイス（１００）からデータを受信すること（９００）、
をさらに含む、請求項１５の方法。
【請求項１７】
前記第１の通信デバイス（１０２）による前記第２の通信デバイス（１００）とのＤ２Ｄ通信のためのリソース割り当てに影響し得る無線ネットワークノード（１１０）の複信構成に関する情報を取得すること（５００）は、
前記無線ネットワークノード（１１０）の通信カバレッジ内に位置する場合に、前記無線ネットワークノード（１１０）から前記情報を受信すること、
を含む、請求項１５〜１６のいずれかの方法。
【請求項１８】
前記無線ネットワークノード（１１０）から前記情報を受信することは、
前記無線ネットワークノード（１１０）の通信カバレッジのエッジ近くに位置する場合に制御プレーン中継機から、又は、前記無線ネットワークノード（１１０）の通信カバレッジ外に位置する場合に第３の通信デバイスから、前記情報を受信すること、
を含む、請求項１５〜１７のいずれかの方法。
【請求項１９】
前記ＲＰＴのセットは、前記情報により示される定義済みキャリアについての周波数分割複信（ＦＤＤ）／時間分割複信（ＴＤＤ）方式に基づいて導出される、請求項１５〜１８のいずれかの方法。
【請求項２０】
前記ＲＰＴのセットは、前記情報により示されるＴＤＤ構成に基づいて導出される、請求項１５〜１９のいずれかの方法。
【請求項２１】
前記ＲＰＴのセットは、前記情報により示される、ＰＲＡＣＨ構成、ＨＡＲＱパラメータ、ＰＵＣＣＨ／ＳＲＳ構成、周期性、時間オフセット及び／又はリソース割り当てのうちのいずれか１つ以上に基づいて導出される、請求項１５〜２０のいずれかの方法。
【請求項２２】
前記ＲＰＴのセットは、ＰＲＡＣＨについて使用されるリソースへデータリソースをマッピングすることを回避するように前記ＰＲＡＣＨ構成に基づいて導出される、請求項２１の方法。
【請求項２３】
前記ＲＰＴのセットは、前記無線ネットワークノード（１１０）によるアップリンク再送のために使用されるリソースを回避するように、前記ＨＡＲＱパラメータに基づいて導出される、請求項２１の方法。
【請求項２４】
前記ＲＰＴのセットは、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避するように、前記ＰＵＣＣＨ又はＳＲＳ構成に基づいて導出される、請求項２１の方法。
【請求項２５】
前記ＲＰＴのセットは、前記情報により示される、周期性、時間オフセット及び／又はリソース割り当てのうちのいずれか１つ以上に基づいて導出される、請求項１５〜２４のいずれかの方法。
【請求項２６】
前記ＲＰＴのセットは、前記第２の通信デバイス（１００）からＤ２Ｄ通信によって受信されるべきトラフィックのタイプに基づいて導出される、請求項１５〜２５のいずれかの方法。
【請求項２７】
前記ＲＰＴのセットは、前記Ｄ２Ｄ通信を通じて受信されることになるトラフィックの関連付けられるタイプについてのデータパターンにおける、データサブフレームの定義された密度を提供するように導出される、請求項２６の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信を対象とし、より具体的には、ワイヤレス通信方法、ネットワーク及びネットワークノードを対象とする。
【背景技術】
【０００２】
近年の３ＧＰＰ  ＬＴＥ（Long  Term  Evolution）の開発は、家庭、オフィス若しくはパブリックホットスポットにおいて、又は屋外環境においてさえ、ローカルのＩＰベースのサービスへアクセスすることを容易にする。ローカルＩＰアクセス及びローカル接続性についての重要なユースケースの１つは、互いに（典型的には２〜３０メートル未満、但し時には２〜３００メートル程度まで）近接している例えばユーザ機器デバイス（ＵＥ）といったワイヤレス通信デバイスの間のダイレクト通信に関与する。例えば、通信デバイス（略してデバイスという）は、互いに近接して位置している場合、デバイスツーデバイス（Ｄ２Ｄ）通信モードで動作するように構成されてよく、Ｄ２Ｄ通信モードにおいて、それらは、何らかの他のデバイス又は無線ネットワークノード（例えば、ｅＮＢ）を通じた通信のルーティングの無いリンクを通じて相互に直接的に通信する。図１に示したシステムにおいて、一組の電子通信デバイス（略して通信デバイス及びデバイスともいう）１００及び１０２は、それらの間のリンクを通じて直接的に通信するＤ２Ｄモードで動作することができ、又は代替的に、無線ネットワークノード１１０を通じて互いに間接的に通信するように動作することができる。
【０００３】
このダイレクトモードあるいはデバイスツーデバイス（即ち、Ｄ２Ｄ）通信は、無線ネットワークノード（例えば、セルラー基地局（ｅＮＢ））を介して通信する間接通信デバイス（例えば、セルラーデバイス）の間の経路よりも、Ｄ２Ｄデバイスの間の経路をかなり短くし得ることから、無線ネットワークノード（例えば、セルラーネットワーク）を通じた通信のリレーに対して、いくつかの潜在的な改善を可能とする。Ｄ２Ｄ通信の利点は、次のうちの１つ以上を含み得る：
・キャパシティ利得：Ｄ２Ｄレイヤとセルラーレイヤとの間で無線リソース（例えば、ＯＦＤＭリソースブロック）を再利用することができる（再利用利得を提供する）。そのうえ、Ｄ２Ｄリンクは、例えばアクセスポイントなどのセルラー無線ネットワークノードを介する２ホップのリンクとは対照的に、送信機デバイスと受信機デバイスとの間で単一のホップを使用する（ホップ利得を提供する）。
・ピークレート利得：近接性及び潜在的に良好な伝播条件に起因して、より高いピークレートを達成することができる（近接性利得）。
・レイテンシ利得：デバイスがダイレクトリンク上で通信する場合、無線ネットワークノード（例えば、ｅＮＢ）による転送が回避され、エンドツーエンドのレイテンシを減少させることができる。
【０００４】
Ｄ２Ｄ通信のいくつかの魅力的な応用例は、ビデオストリーミング、オンラインゲーム、メディアダウンロード、ピアツーピア（Ｐ２Ｐ）、ファイル共有などである。
【０００５】
２０１４年２月のＲＡＮ  １＃７６のチェアマンズノートにおいて、スケジューリング割り当て（ＳＡ）のために以下の処理が開示された。Ｄ２Ｄブロードキャスト通信について、Ｄ２Ｄデータを搬送する関連付けられた物理チャネルの受信のためのリソースの位置を少なくとも指し示すスケジューリング割り当てが、ブロードキャスト元のデバイス（ユーザ機器（ＵＥ）ともいう）によって送信される。受信のためのリソースのその標識は、スケジューリング割り当てリソース又はコンテンツに基づいて、暗黙的であり及び／又は明示的であり得る。言い換えると、対応するＤ２Ｄデータが送信される時間リソースを少なくとも指し示すために、ＳＡがＤ２Ｄブロードキャスト通信について使用される。ＳＡの恩恵及び関連する手続が“On  scheduling  procedure  for  D2D”（R1-140778，Ericsson，２０１４年２月）に記述されている。
【０００６】
ＳＡは受信機デバイスへリソースの位置を指し示すために使用されることから、その１つの側面は、リソースパターン（ＲＰＴ）設計、即ち、Ｄ２Ｄブロードキャストデータ送信が発生することになるサブフレームの位置である。ＲＰＴ設計は、性能目標を考慮に入れる必要があり、例えば、受信電力リファレンスレベルが−１０７ｄＢｍよりも大きくあるべきであると定義されている。−１０７ｄＢｍに達するためには、次の処理が生じるであろう：
１）周波数ドメインでの衝突を回避するために、占有帯域が限定される。
２）近傍チャネル干渉を評価するために、帯域内放射のデバイス（例えば、ＵＥ）ハードウェア性能が考慮に入れられる。
３）（高い経路損失、フェージング、共チャネル干渉、及び／又は近傍チャネル干渉を含む）劣悪なチャネル品質を補償するために、再送といった何らかのＬ１拡張が必要とされ得る。
４）再送は時間ドメインにおいてＤ２Ｄ送信のために必要なリソースを一層増加させ、これがＦＤＤシステムよりもＵＬサブフレームの少ないＴＤＤシステムにとってより課題となる。
【０００７】
Ｄ２Ｄは、アップリンク（ＵＬ）リソース（時間分割複信（ＴＤＤ）システムにおけるＵＬサブフレーム、及び周波数分割複信（ＦＤＤ）システムにおけるＵＬ帯域）において送信されることができる。半二重（half  duplexing）のために、デバイス（例えば、ＵＥ）は同時には送信と受信とを行うことができない。半二重もまた、ＲＰＴ設計において考慮されるべき要因である。
【０００８】
“D2D  Physical  Channels  Design”（R1-141384，Ericsson，２０１４年４月）では、ＦＤＤシステム向けのリソースパターン設計を以下に説明し及び図２に示す通りにすることが提案されており、そこではＶｏＩＰ（voice-over-IP）が考慮されている。図２において、ｙ軸（垂直軸）は周波数ドメインを表し、ｘ軸（水平軸）は時間ドメインを表す。ＵＥ−Ａ（例えば、１００）はＵＥ−Ｂ（例えば、１０２）へ１つの周波数上でスケジューリング割り当てＳＡ２００ａを送信し、後者はスケジューリング割り当てＳＡ２００ｂを他の周波数上でＵＥ−Ｂへ再送して第１のデータパターンを定義し、その第１のデータパターンにおいて、音声パケット２０４が２つの異なる周波数の間でのホッピングを伴って送信されることになる。同様に、ＵＥ−Ｂ（例えば、１０２）はＵＥ−Ａ（例えば、１００）へスケジューリング割り当てＳＡ２０２ａを送信して第２のデータパターンを定義し、その第２のデータパターンにおいて、音声パケット２０６が２つの異なる周波数の間でのホッピングを伴って送信されることになる。
【０００９】
図２の例において、２０ｍｓごとにアプリケーションレイヤから生成される１つの音声パケットが存在し、それについて以下のことが言える：
１）１６０ｍｓのＳＡサイクルごとに１から４個のＳＡ送信を可能とする１つのＳＡプールが割り当てられ、即ち、１つのＳＡサイクルに続いて８個の音声パケットを送信するリソース位置が制御される。
２）２０ｍｓごとに４つのデータ送信（再送）が割り当てられ、データ送信ごとに２ＲＢの帯域幅が割り当てられる。
３）ＳＡサイクル及びデータ送信ピリオドの間に、即ちデータ送信ピリオドの期間中に、ＳＡのために予約されるいくつかのサブフレームが存在し、それらは後続のサブフレームにおいてデータパケットをスケジューリングするために使用される。
これらアプローチに伴う潜在的な問題は以下の通りである：
【００１０】
Ｒ１−１４１３８４に記述されたＲＰＴ設計はＦＤＤシステム向けであってＶｏＩＰトラフィック向けであることから、ＴＤＤシステムへ適用することは難しい。例えば、１６０ｍｓごとにＤ２Ｄブロードキャスト送信用に少なくとも４（ＳＡ用）＋８×４（データ用）＝３６を要し、これはリソースの約２２．５％をＤ２Ｄリソースへ割り当てさせることになり、セルラーシステムの少なくとも２２．５％のＵＬスループットの劣化に帰結し得る。ＴＤＤシステムについては、利用可能なＵＬサブフレーム数は１０％（コンフィグレーション５）から６０％（コンフィグレーション０）までの間であり、これは、ＴＤＤシステムにおいてＲＰＴ処理をＦＤＤシステムから再利用すると、より大きいＵＬ性能の劣化を引き起こし、又はＤ２Ｄブロードキャスト通信のためだけであっても残余リソースが不十分となることに帰結するはずである。
【００１１】
１つのあり得る解決策は、いくつかをＦＤＤ向けに最適化し、いくつかをＴＤＤ向けに最適化して多くのパターンを定義し、ＳＡに包含される異なるインデックスをそれら異なる全てのパターンに付与することである。しかしながら、ＳＡペイロードは許容可能なリンクバジェットを提供するために最小化されなければならず、ＦＤＤシステムよりもＵＬサブフレームの少ないＴＤＤシステムにおいてこれはなお一層困難である。そのうえ、相異なるトラフィックサービスについて、性能要件が異なるためにデータパターンは異なるはずである。
【００１２】
様々なトラフィックサービス及び様々なＴＤＤ構成シナリオを考慮すると、多数のデータパターンが存在し得る。すると、パターンインデックスの数が大規模になり過ぎ、よって限られたＳＡペイロード内に含めるにはパターンインデックス長が大き過ぎることになるであろう。
【００１３】
背景欄において説明したこれらアプローチは、追求され得たはずではあるが、必ず過去に想到され又は追求されたアプローチであるというわけではない。従って、ここで別段の示唆の無い限り、背景欄において説明したアプローチは、本出願の特許請求の範囲に対する従来技術ではなく、背景欄に含まれていることによって従来技術であると認められるわけではない。
【発明の概要】
【００１４】
本開示のいくつかの実施形態は、第１の通信デバイスによる、第２の通信デバイスとのデバイスツーデバイス（Ｄ２Ｄ）通信のための方法を対象とする。当該方法は、上記第１の通信デバイスによる上記第２の通信デバイスとのＤ２Ｄ通信のためのリソース割り当てに影響し得る無線ネットワークノードの複信構成に関する情報を取得すること、を含む。上記方法は、上記情報に基づいて、リソースパターン（ＲＰＴ）のセットを導出することと、スケジューラ情報に基づいて、上記ＲＰＴのセットのうちの１つのＲＰＴを選択することと、上記第２の通信デバイスへ、選択された上記ＲＰＴを識別するために使用されるインデックスをシグナリングすることと、をさらに含む。
【００１５】
このアプローチの潜在的な利点は、第１の通信デバイスによる第２の通信デバイスとのＤ２Ｄ通信のためのリソース割り当てに影響する無線ネットワークノードの複信構成を考慮して最適化されるＲＰＴのセットを導出することができることである。そのうえ、スケジューラ情報に基づくＲＰＴのセットからの１つのＲＰＴの選択と、それに次ぐ、選択されたＲＰＴを識別するために第２の通信デバイスにより使用されるインデックスのみの第２の通信デバイスへのシグナリングとによって、オーバヘッドシグナリングのための利用可能なリソースの使用が最小化される。そうした通信デバイス間のＤ２Ｄ通信について、通信リソースキャパシティ、ピークトラフィックレート、及び／又は通信レイテンシにおける改善が獲得され得る。
【００１６】
いくつかのさらなる実施形態において、上記方法は、選択される上記ＲＰＴに基づいて、上記第１の通信デバイスから上記第２の通信デバイスへのＤ２Ｄ送信のために使用されるべきリソースを導出することと、Ｄ２Ｄ送信のために導出される上記リソースを用いて、上記第１の通信デバイスから上記第２の通信デバイスへデータを送信することと、を含む。
【００１７】
上記情報は、上記第１の通信デバイスが上記無線ネットワークノードの通信カバレッジ内に位置する場合には、上記無線ネットワークノードから受信されてもよく、上記第１の通信デバイスが上記無線ネットワークノードの通信カバレッジのエッジ近くに位置する場合には、制御プレーン中継機（Control  Plane  relay）から受信されてもよく、又は、上記第１の通信デバイスが上記無線ネットワークノードの通信カバレッジ外に位置する場合には、第３の通信デバイスから受信されてもよい。
【００１８】
上記ＲＰＴのセットは、上記情報により示される定義済みキャリアについてのＦＤＤ／ＴＤＤ複信方式に基づいて導出されてもよく、上記１つのＲＰＴは、上記スケジューラ情報がＦＤＤ複信方式用か又はＴＤＤ複信方式用かに基づいて上記ＲＰＴのセットから選択されることができる。
【００１９】
上記ＲＰＴのセットは、ＰＲＡＣＨについて使用されるリソースへデータリソースをマッピングすることを回避するようにＰＲＡＣＨ構成に基づいて導出されるか、上記無線ネットワークノードによるアップリンク再送のために使用されるリソースを回避するように、ＨＡＲＱパラメータに基づいて導出されるか、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避するように、ＰＵＣＣＨ又はＳＲＳ構成に基づいて導出されるか、のいずれか１つ以上であってもよく、それらは上記情報により示される。
【００２０】
上記ＲＰＴのセットは、上記情報により示される、周期性、時間オフセット及び／又はリソース割り当てのうちのいずれか１つ以上に基づいて導出されてもよい。代替的に又は追加的に、上記ＲＰＴのセットは、上記第２の通信デバイスへＤ２Ｄ通信されるべきトラフィックのタイプに基づいて導出されてもよい。
【００２１】
本開示のいくつかの他の実施形態は、第１の通信デバイスによる、第２の通信デバイスとのＤ２Ｄ通信のための方法を対象とする。当該方法は、上記第１の通信デバイスによる上記第２の通信デバイスからのＤ２Ｄ通信を受信するためのＤ２Ｄリソース使用に影響し得る無線ネットワークノードの複信構成に関する情報を取得すること、を含む。上記方法は、上記情報に基づいて、リソースパターン（ＲＰＴ）のセットを導出することと、上記第２の通信デバイスによりシグナリングされるインデックスを受信することと、上記インデックスに基づいて、上記ＲＰＴのセットのうちの１つのＲＰＴを選択することと、選択される上記ＲＰＴに基づいて、上記第２の通信デバイスからのＤ２Ｄ受信のために使用されるべきリソースを導出することと、をさらに含む。
【００２２】
いくつかのさらなる実施形態において、上記方法は、上記第１の通信デバイスにおいて、Ｄ２Ｄ受信のために導出される上記リソースを用いて、上記第２の通信デバイスからデータを受信すること、を含む。
【００２３】
関連する通信デバイス及び無線ネットワークノードが開示される。以下の図面及び詳細な説明を考察すれば、当業者には本発明の実施形態に係る他の方法、通信デバイス及び無線ネットワークノードが明らかとなるであろう。そうした全ての追加的な方法、通信デバイス及び無線ネットワークノードは、この説明に含まれ、本発明の範囲内であり、添付の特許請求の範囲によって保護されるものと意図される。そのうえ、ここに開示される全ての実施形態は、いかなる手法及び／又は組み合わせで、別個に実装され又は組み合わせられることもできるものと意図される。
【図面の簡単な説明】
【００２４】
本開示のさらなる理解を提供し及び本出願に取り入れられてその一部を構成する添付図面は、発明概念の何らかの非限定的な実施形態を例示する。それら図面は次の通りである：
【００２５】
【図１】デバイスが互いに直接的に又は間接的に通信するように動作することのできるシステムを示している。
【図２】データ及びスケジューリング割り当て（ＳＡ）の双方を搬送する物理ブロードキャストチャネルを示している。
【図３】いくつかの実施形態に従って受信機（Ｒｘ）デバイスとＤ２Ｄによって通信する送信機（Ｔｘ）デバイスにより実行される動作及び方法のフローチャートを示している。
【図４】２つのＴＤＤ構成についてのリソースパターン（ＲＰＴ）を示している。
【図５】いくつかの実施形態に従ってＤ２Ｄ通信によって送信機（Ｔｘ）デバイスから情報を受信する受信機（Ｒｘ）デバイスにより実行される動作及び方法のフローチャートを示している。
【図６】いくつかの実施形態に従って構成される通信デバイスのブロック図である。
【図７】いくつかの実施形態に従って構成される無線ネットワークノードのブロック図である。
【図８】いくつかの実施形態に係る、受信機（Ｒｘ）デバイスへのデータのＤ２Ｄ送信のために送信機（Ｔｘ）デバイスにより実行される動作及び方法のフローチャートである。
【図９】Ｄ２Ｄ送信のために考案されるリソースを用いて送信機（Ｔｘ）デバイスからデータを受信するための、受信機（Ｒｘ）デバイスにより実行される動作及び方法のフローチャートである。
【図１０】いくつかの実施形態に従って送信機（Ｔｘ）デバイス内に実装され得る機能モジュールのブロック図である。
【図１１】いくつかの実施形態に従って受信機（Ｒｘ）デバイス内に実装され得る機能モジュールのブロック図である。
【発明を実施するための形態】
【００２６】
これ以降、発明概念の実施形態の例が示される添付図面を参照しながら、発明概念がより充分に説明されるであろう。しかしながら、発明概念は、多くの異なる形で具現化されてよく、ここで説明される実施形態に限定されるように解釈されるべきではない。むしろ、それら実施形態は、本開示を綿密かつ完結したものとするように、及び本開示がその発明概念の範囲を当業者へ十分に伝えることになるように提供される。それら実施形態が相互に排他的ではないこともまた留意されるべきである。１つの実施形態のうちのコンポーネントが他の実施形態において現れ／使用されることが暗黙的に想定されてよい。
【００２７】
ここで開示される多様な実施形態は、いくつかの過去に知られたアプローチに伴う上で説明した潜在的な問題のうちの１つ以上を克服し得る。
【００２８】
多様な実施形態が、Ｄ２Ｄを用いて互いに通信可能であって無線ネットワークノード（例えば、ｅＮＢ）と通信可能な電子通信デバイス（略してデバイスという）の文脈において開示される。非限定的な例としてのデバイスは、ユーザ機器（ＵＥ）、マシンツーマシン（Ｍ２Ｍ）通信可能なデバイス、ＰＤＡ、ｉＰＡＤ、タブレットコンピュータ、モバイル端末、スマートフォン、ＬＥＥ（laptop  embedded  equipped）、ＬＭＥ（laptop  mounted  equipment）、ＵＳＢドングルなどを含み得る。
【００２９】
ここで開示される多様な実施形態は、送信（Ｔｘ）デバイスによる受信（Ｒｘ）デバイスへのデバイスツーデバイス（Ｄ２Ｄ）送信のために実行される動作及び方法を対象とする。送信デバイス及び受信デバイスは、Ｄ２Ｄ送信のために使用されるであろうキャリアに関する情報を用いて、リソースパターン（ＲＰＴ）（例えば、データ時間パターン）のサブセットを導出する。そして、送信機デバイスから受信機デバイスへのデータパターンのシグナリングが、導出されたＲＰＴサブセット内の複数のパターンのうちの１つをシグナリングすることに基づく。
【００３０】
いくつかの実施形態において、ＳＡは、ＲＰＴインデックスを指し示す予め定義される（小さい）数のビットを含む。潜在的な受信機デバイス（Ｒｘ）は、周波数分割複信（ＦＤＤ）／時間分割複信（ＴＤＤ）及びＴＤＤ構成、並びに恐らくは他の関連パラメータを認識するようになされる。ＳＡ  ＲＰＴビットによってシグナリングされる全てのあり得るＲＰＴのサブセットは、予め定義されるマッピング及び／又は他の定義されるパラメータに基づくＦＤＤ／ＴＤＤ構成の関数であり得る。上記他の定義されるパラメータは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）位置、ハイブリッドＡＲＱ（ハイブリッド自動再送要求（ＨＡＲＱ））パラメータ、及び／又は物理アップリンク制御チャネル（ＰＵＣＣＨ）若しくはサウンディングリファレンス信号（ＳＲＳ）構成を含んでよい。
【００３１】
ＲＰＴは、時間リソースのみのパターン、周波数リソースのみのパターン、又は時間リソース及び周波数リソースの組み合わせのパターンを明示的に指し示してもよい。他のＲＰＴの特性が受信機（Ｒｘ）デバイスにおいて暗黙的に又は盲目的に導出されてもよい。
【００３２】
このアプローチの潜在的な利点は、柔軟性を維持しつつ他の場合よりもＳＡオーバヘッドをより低くし得ることである。
【００３３】
図３は、いくつかの実施形態に従って受信機（Ｒｘ）デバイス（例えば、図１におけるデバイス１０２）と通信する送信機（Ｔｘ）デバイス（例えば、図１におけるデバイス１００）により実行される動作及び方法のフローチャートを示している。図３のブロック３００を参照すると、データ送信前に、Ｔｘデバイスは、Ｔｘデバイスが通信することのできる無線ネットワークノード（例えば、図１におけるｅＮＢ１１０）の複信構成を含む情報を取得し、及び／又は、ＴｘデバイスによるＲｘデバイスとのＤ２Ｄ通信のためのリソー割り当てに影響し得る他のシグナリング構成を取得する。その情報は、定義済みのキャリアについてのＦＤＤ／ＴＤＤ複信方式、ＴＤＤ構成、及び／又はＤ２Ｄリソース割り当てに影響し得る他の情報、のうちの１つ以上を含んでよく、上記他の情報は、例えばＰＲＡＣＨ構成、ＨＡＲＱパラメータ、ＰＵＣＣＨ／ＳＲＳ構成、周期性、時間オフセット、及び／又はリソース割り当てを含む。
【００３４】
Ｔｘデバイスは、上記情報を、（無線ネットワークノードの通信カバレッジ内に位置する場合）無線ネットワークノードから受信し、（無線ネットワークノードの通信カバレッジのエッジ近くに位置する場合）制御プレーン（ＣＰ）中継機から受信し、及び／又は、無線ネットワークノードの通信カバレッジ外に位置する場合には例えばクラスタヘッド（ＣＨ）などのＵＥといった他のデバイスから受信することにより取得してもよい。Ｔｘデバイスは、追加的に又は代替的に、Ｔｘデバイスのメモリ内に記憶される予め構成されるデータに基づいて、上記情報を取得してもよい。
【００３５】
ブロック３０２を参照すると、Ｔｘデバイスは、上記情報（ブロック３００）を用いて、ＲＰＴを導出し、より具体的には、ＲＰＴのセットを導出し得る。従って、異なる情報が受信され又は取得されることで、ＴｘデバイスにＲＰＴの異なるセットを導出させることができる。ブロック３０４を参照すると、Ｔｘデバイスは、導出（ブロック３０２）された上記ＲＰＴのセットから、スケジューラ情報に基づいて１つのＲＰＴを選択する。
【００３６】
Ｔｘデバイスが情報を用いてＲＰＴのセットをいかにして導出することができるかを例示するために、以下に５つの例が提供される。その情報は、次のうちの１つ以上を含むことができる：
【００３７】
１）複信情報
上記情報がＦＤＤ／ＴＤＤ及び異なるＴＤＤ構成といった複信情報を含む場合、ＳＡ内のＲＰＴフィールドは、異なる解釈を有し得る。ＦＤＤシステムについてのＲＰＴの例が図２に示されており、２つのＴＤＤ構成（“ＴＤＤコンフィグレーション１”及び“ＴＤＤコンフィグレーション２）についてのＲＰＴの例が図４に示されている。
【００３８】
図４を参照すると、利用可能なＵＬサブフレーム番号が異なる構成の間で相違し、且つＵＬサブフレーム間の間隔が相違し、これがＳＡ及びデータリソースについてのＲＰＴパターン設計に異なる制約を課す。さらに、コンフィグレーション１と比較して、コンフィグレーション２は、より少ないＵＬサブフレームを有しており（４０％−＞２０％）、そのためにＤ２Ｄデータ送信へより少ないデータサブフレームが割り当てられる（２０ｍｓごとに３つから１つ）。
【００３９】
Ｔｘデバイスは、スケジューラ情報がＦＤＤ複信方式用であるか又はＴＤＤ複信方式用であるかに基づいて、導出されたＲＰＴのセットから１つのＲＰＴを選択することができる（ブロック３０４）。
【００４０】
２）ＰＲＡＣＨ情報
上記情報がＰＲＡＣＨ構成を含む場合、Ｄ２Ｄ通信が無線ネットワークノード（例えば、セルラーノード）のＰＲＡＣＨリソースを回避する形でＴｘデバイスがＲｘデバイスとのＳＡを実行するように、ＲＰＴのセットを導出することができる。ＰＲＡＣＨ及び類似のタイプの情報が、そのようにして、ＰＲＡＣＨのために使用されるリソースへデータリソースをマッピングすることを回避するように、Ｔｘデバイスにより導出されるＲＰＴへ影響し得る。より具体的には、Ｔｘデバイスは、ＰＲＡＣＨのために使用されるリソースへデータリソースをマッピングすることを回避するために、ＰＲＡＣＨ構成に基づいてＲＰＴのセットを導出してよい。
【００４１】
３）ＨＡＲＱ情報
上記情報がＨＡＲＱパラメータを含む場合、Ｄ２Ｄとして発生するデバイスツーデバイス通信と無線ネットワークノード（例えば、セルラーノード）による通信とが、それらのＵＬリソースにおいて多重化される。セルラー無線ネットワークノードによるＵＬ  ＨＡＲＱ送信（再送）は同期的である。Ｔｘデバイスは、無線ネットワークノード（１１０）によるアップリンク（ＵＬ）再送のために使用されるリソースを回避するように、Ｄ２Ｄデータの送信についてＨＡＲＱパラメータに基づいてＲＰＴのセットを導出することができる。
【００４２】
４）ＰＵＣＣＨ／ＳＲＳ情報
上記情報がＰＵＣＣＨ又はＳＲＳ構成を含む場合において、Ｄ２Ｄが無線ネットワークノード（例えば、セルラーノード）のＰＵＣＣＨ又はＳＲＳリソースを回避しなければならないときは、このタイプの情報がＲＰＴ方式に影響し得る。このとき、１つのアプローチは、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避することである。Ｔｘデバイスは、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避するために、ＰＵＣＣＨ又はＳＲＳ構成に基づいてＤ２Ｄデータの送信についてＲＰＴのセットを導出してよい。
【００４３】
５）Ｄ２Ｄについての様々なサポートされるトラフィックタイプ
様々なスループット、レイテンシ、信頼性及びカバレッジの制約によって、様々なトラフィックタイプ（例えば、ＶｏＩＰ、マルチメディア、ＦＴＰなど）が特徴付けられる。それら制約のうちの１つ以上を、Ｔｘデバイスによって取得して（既知であり又は判定して）、ＲＰＴのセットを導出するために部分的に使用することができる。Ｔｘデバイスによって、トラフィックタイプが判定され及び／又はその制約が判定されてもよく、それらは、パターン及びマッピングにおけるデータサブフレームの時間リソース密度、再送パターン、ＨＡＲＱ再送マッピング及び／又はＨＡＲＱプロセスの並列度に基づくＲＰＴの導出を制御するために使用され得る。例えば、マルチメディアトラフィックは、ファイル転送プロトコル（ＦＴＰ）トラフィックとは異なるスループット制約及びデータレイテンシ制約を有する。Ｔｘデバイスは、例えば、Ｄ２Ｄ通信を通じて搬送されることになるトラフィックの関連付けられるタイプのためのデータパターンにおけるデータサブフレームの定義された密度を提供するように、ＦＴＰトラフィック向けとは異なるマルチメディアトラフィック向けのＲＰＴのセットを導出することができる。
【００４４】
なお、全てのサポートされる情報シナリオのセットについての全てのあり得るＲＰＴがテーブル内に一覧化されてもよい。代替的に又は追加的に、ＲＰＴは、予め定義されるルールに基づいて実行時に生成されてもよい。
【００４５】
ＲＰＴのセットは、次のルールのうちの１つ以上に基づいて導出され得る：
・Ｄ２Ｄ通信のために使用されるべきＵＬサブフレームの定義された数又はＵＬサブフレームの割合を提供；
・無線ネットワークノード（例えば、セルラー）による通信とＤ２Ｄ通信との間の定義されたリソース分割を提供；
・データパターンにおけるＳＡ及びデータサブフレームの定義された数を提供；
・ＳＡとデータとの間の定義された最小サブフレーム距離を提供；
・データ再送の間の最小サブフレーム距離を提供；
・ＰＲＡＣＨ／ＳＲＳのために使用されるＵＬサブフレームの使用を回避又は防止；及び／又は
・無線ネットワークノード（例えば、セルラー）送信のＨＡＲＱ情報を考慮
【００４６】
ブロック３０６を参照すると、Ｔｘデバイスは、Ｒｘデバイスへ選択されたＲＰＴを識別するインデックスをシグナリングする。Ｔｘデバイスは、当該インデックスをＳＡ（又は等価的に何らかの他のＤ２Ｄ制御チャネル）のペイロード内のフィールドへマッピングし得る。同じインデックス値を、例えば、図４に示したＴＤＤコンフィグレーション１及び２について選択された異なるＲＰＴを示すために使用することができる。
【００４７】
図５は、いくつかの実施形態に従ってＤ２Ｄ通信を用いてＴｘデバイスから情報を受信する受信機（Ｒｘ）デバイスにより実行される動作及び方法のフローチャートを示している。ブロック５００において、データ検出の前に、Ｒｘデバイスは、ＴｘデバイスからＤ２Ｄ通信を受信するためのＲｘデバイスによるリソース使用に影響し得る、Ｒｘデバイスが通信することのできる無線ネットワークノード（例えば、図１におけるｅＮＢ１１０）の複信構成を指し示す情報を取得し、及び／又は、ＴｘデバイスからＤ２Ｄ通信を受信するためのＲｘデバイスによるリソース使用に影響し得る他のシグナリング構成を取得する。上記情報は、定義済みのキャリアについてのＦＤＤ／ＴＤＤ複信方式、ＴＤＤ構成、及び／又はＤ２Ｄリソース割り当てに影響し得る他の情報、のうちの１つ以上を含んでよく、他の情報とは、例えば、ＰＲＡＣＨ構成、ＨＡＲＱパラメータ、ＰＵＣＣＨ／ＳＲＳ構成、周期性、時間オフセット、及び／又はリソース割り当てを含む。
【００４８】
Ｒｘデバイスは、上記情報を、（無線ネットワークノードのカバレッジ内に位置する場合）無線ネットワークノード、例えばｅＮＢから受信し、（無線ネットワークノードのカバレッジのエッジ近くに位置する場合）制御プレーン（ＣＰ）中継機から受信し、及び／又は、無線ネットワークノードのカバレッジ外に位置する場合には例えばクラスタヘッド（ＣＨ）などのＵＥといった他のデバイスから受信することにより取得してもよい。Ｒｘデバイスは、追加的に又は代替的に、Ｒｘデバイスのメモリ内に記憶される予め構成されるデータに基づいて、上記情報を取得してもよい。
【００４９】
ブロック５０２を参照すると、Ｒｘデバイスは、上記情報（ブロック５００）を用いてＲＰＴを導出し、より具体的には、ＲＰＴのセットを導出し得る。従って、異なる情報が受信され又は取得されることで、ブロック３０２におけるＴｘデバイスによる上述した１つ以上の動作と同じ又は類似のやり方で、ＲｘデバイスにＲＰＴの異なるセットを導出させることができ、それらは簡明さのために参照によりここに取り入れられる。
【００５０】
ブロック５０４を参照すると、Ｒｘデバイスは、Ｔｘデバイスにより選択されたＲＰＴを識別するために使用される、Ｔｘデバイスによりシグナリングされるインデックスを受信する。
【００５１】
ブロック５０６を参照すると、Ｒｘデバイスは、上記インデックスに基づいて、（ブロック５０２において導出された）ＲＰＴのセットから１つのＲＰＴを選択する。
【００５２】
ブロック５０８を参照すると、Ｒｘデバイスは、選択されたＲＰＴに基づいて、ＴｘデバイスからのＤ２Ｄ受信のために使用されるべきリソースを導出する。導出されるリソースは、時間ドメイン、周波数ドメイン、又は時間ドメイン及び周波数ドメインの双方において、Ｔｘデバイスからデータを受信するためにＲｘデバイスにより使用されるべきリソースの位置を識別し得る。上記情報がＰＲＡＣＨ構成を含む場合、Ｒｘデバイスは、ＰＲＡＣＨのために使用されるリソースへデータリソースをマッピングすることを回避するように、ＰＲＡＣＨ構成に基づいてＲＰＴのセットを導出してもよい。上記情報がＨＡＲＱパラメータを含む場合、Ｒｘデバイスは、無線ネットワークノード（１１０）によるアップリンク（ＵＬ）再送のために使用されるリソースを回避するように、ＨＡＲＱパラメータに基づいてＲＰＴのセットを導出してもよい。上記情報がＰＵＣＣＨ又はＳＲＳ構成を含む場合、Ｒｘデバイスは、ＰＵＣＣＨ又はＳＲＳのために使用されるリソースへデータリソースをマッピングすることを回避するように、ＰＵＣＣＨ又はＳＲＳ構成に基づいてＲＰＴのセットを導出してもよい。
【００５３】
図８は、いくつかの実施形態に従ってＴｘデバイスにより実行され得るさらなる動作及び方法のフローチャートを示している。ブロック８００において、Ｔｘデバイスは、選択されたＲＰＴ（図３のブロック３０４）に基づいて、ＲｘデバイスへのＤ２Ｄ送信のために使用されるべきリソースを導出する。ブロック８０２において、Ｔｘデバイスは、Ｄ２Ｄ送信のために導出されたリソースを用いて、Ｒｘデバイスへデータを送信する。
【００５４】
図９は、いくつかの実施形態に従ってＲｘデバイスにより実行され得る対応する動作及び方法のフローチャートを示している。ブロック９００において、Ｒｘデバイスは、Ｄ２Ｄ受信のために導出された（図５のブロック５０８）リソースを用いて、Ｔｘデバイスからデータを受信する。
【００５５】
これらアプローチの潜在的な利点は、Ｔｘデバイス１００によるＲｘデバイス１０２とのＤ２Ｄ通信のためのリソース割り当てに影響する無線ネットワークノード１１０の複信構成を考慮して最適化されるＲＰＴのセットを導出することができることである。そのうえ、スケジューラ情報に基づくＲＰＴのセットからの１つのＲＰＴの選択と、それに次ぐ、選択されたＲＰＴを識別するためにＲｘデバイス１０２により使用されるインデックスのみのＴｘデバイス１００からＲｘデバイス１０２へのシグナリングとによって、オーバヘッドシグナリングのための利用可能なリソースの使用が最小化される。そうしたＴｘデバイス１００とＲｘデバイス１０２との間のＤ２Ｄ通信について、通信リソースキャパシティ、ピークトラフィックレート、及び／又は通信レイテンシにおける改善が獲得され得る。
【００５６】
［例示的な通信デバイス及び無線ネットワークノード］
図６は、Ｄ２Ｄを用いて他のデバイスと通信するように構成され、及び無線ネットワークノード（例えば、ｅＮＢ）と通信可能な、電子通信デバイス（デバイス）６００のブロック図である。デバイス６００は、ここで開示される１つ以上の実施形態に係る動作及び方法を実行するように、Ｔｘデバイス１００、Ｒｘデバイス１０２、及び／又は任意の他の通信デバイス（例えば、無線ネットワークノード）として構成されてよい。デバイス６００は、送受信機６１０、プロセッサ回路６０２、及び機能モジュール６２２を収容するメモリデバイス６２０を含む。デバイス６００は、ディスプレイ６３０、ユーザ入力インタフェース６３２及びスピーカ６３４をさらに含んでもよい。
【００５７】
送受信機６１０は、Ｄ２Ｄを用いて他のデバイスと直接的に通信するように、及び１つ以上の無線アクセス技術を用いて無線ネットワークノードと通信するように構成される。プロセッサ回路６０２は、汎用の及び／又は特殊用途のプロセッサ、例えばマイクロプロセッサ及び／又はデジタル信号プロセッサなどの１つ以上のデータ処理回路を含んでよい。プロセッサ回路６０２は、メモリデバイス６２０の複数の機能モジュール６２２からのコンピュータプログラム命令を実行して、通信デバイスにより実行されるものとしてここで開示された動作の少なくともいくつかを実行する、ように構成される。
【００５８】
図７は、無線ネットワークノード１１０（例えば、セルラー基地局、ｅＮＢ）のブロック図であり、無線ネットワークノード１１０は、送受信機７１０、プロセッサ回路７０２、及び、機能モジュール７２２を収容するメモリデバイス７２０を含む。無線ネットワークノード１１０は、ディスプレイ７３０、ユーザ入力インタフェース７３２及びスピーカ７３４をさらに含んでもよい。送受信機７１０は、１つ以上の無線アクセス技術を用いて、通信デバイス１００、１０２と通信するように構成される。プロセッサ回路７０２は、汎用の及び／又は特殊用途のプロセッサ、例えばマイクロプロセッサ及び／又はデジタル信号プロセッサなどの１つ以上のデータ処理回路を含んでよい。プロセッサ回路７０２は、メモリデバイス７２０の複数の機能モジュール７２２からのコンピュータプログラム命令を実行して、無線ネットワークノードにより実行されるものとしてここで開示された動作の少なくともいくつかを実行する、ように構成される。
【００５９】
図１０は、いくつかの実施形態に従ってＴｘデバイス１００内に実装され得る機能モジュールのブロック図である。それらモジュールは、ブロック３００について上で説明した通りの機能的手段を動作させ及び実行し得る取得モジュール１０００、ブロック３０２について上で説明した通りの機能的手段を動作させ及び実行し得る導出モジュール１００２、ブロック３０４について上で説明した通りの機能的手段を動作させ及び実行し得る選択モジュール１００４、及び、ブロック３０６について上で説明した通りの機能的手段を動作させ及び実行し得るシグナリングモジュール１００６、を含む。それらモジュール１０００、１００２、１００４及び１００６は、メモリ６２０内に所在し、Ｔｘデバイス１００として構成される通信デバイス６００のプロセッサ６０２により実行されるコンピュータソフトウェアの動作によって実装され得る。それらモジュール１０００、１００２、１００４及び１００６は、代替的に、Ｔｘデバイス１００内でデジタル論理回路及び／又はアナログ回路で実装されてもよい。
【００６０】
図１１は、いくつかの実施形態に従ってＲｘデバイス１０２内に実装され得る機能モジュールのブロック図である。それらモジュールは、ブロック５００について上で説明した通りの機能的手段を動作させ及び実行し得る取得モジュール１１００、ブロック５０２について上で説明した通りの機能的手段を動作させ及び実行し得るＲＰＴセット導出モジュール１１０２、ブロック５０４について上で説明した通りの機能的手段を動作させ及び実行し得る受信モジュール１１０４、ブロック５０６について上で説明した通りの機能的手段を動作させ及び実行し得る選択モジュール１１０６、及び、ブロック５０８について上で説明した通りの機能的手段を動作させ及び実行し得るリソース導出モジュール１１０８、を含む。それらモジュール１１００、１１０２、１１０４、１１０６及び１１０８は、メモリ６２０内に所在し、Ｒｘデバイス１０２として構成される通信デバイス６００のプロセッサ６０２により実行されるコンピュータソフトウェアの動作によって実装され得る。それらモジュール１１００、１１０２、１１０４、１１０６及び１１０８は、代替的に、Ｒｘデバイス１０２内でデジタル論理回路及び／又はアナログ回路で実装されてもよい。
【００６１】
［略語］
ＣＨ        Cluster  Head  
ＣＰ        Control  Plane  
Ｄ２Ｄ      Device  to  Device  
ＦＤＤ      Frequency  Division  Duplex  
ＨＡＲＱ    Hybrid  Automatic  Repeat  request  
ＨＷ        Hardware  
ＰＲＡＣＨ  Physical  Random  Access  Channel  
ＰＵＣＣＨ  Physical  Uplink  Control  Channel  
ＲＰＴ      Resource  Pattern  
ＲＸ        receiver  device  
ＳＡ        Scheduling  Assignment  
ＳＲＳ      Sounding  Reference  Signal  
ＴＤＤ      Time  Division  Duplex  
ＴＸ        transmitter  device  
ＵＥ        user  equipment  
ＵＬ        Uplink
【００６２】
［さらなる定義及び実施形態］
本発明概念の多様な実施形態の上の説明において、理解されるべきこととして、ここで使用されている専門用語は、具体的な実施形態を単に説明する目的のためのものであって、本発明概念を限定することを意図したものではない。別段の定義が無い限り、ここで使用されている（技術的用語及び学術的用語を含む）全ての用語は、本発明概念が属する分野における当業者によって通常理解されるものと同じ意味を有する。さらに理解されるであろうこととして、通常使用される辞書において定義されているような用語は、本明細書及び関連する分野の文脈におけるそれらの意味に整合する意味を有するものと解釈されるべきであり、ここで文字通り定義される理想化され又は過度に型通りの意味では解釈されない。
【００６３】
あるエレメントが別のエレメントに“接続され（connected）”、“連結され（coupled）”、“応じる（responsive）”又はその派生語として言及される場合、それは当該別のエレメントに直接接続され、連結され、若しくは応じることができ、又は介在するエレメントが存在してもよい。対照的に、あるエレメントが別のエレメントに“直接接続され（directly  connected）”、“直接連結され（directly  coupled）”、“直接応じる（directly  responsive）”又はその派生語として言及される場合、介在するエレメントは存在しない。同様の番号は、全体を通じて同様のエレメントを指す。さらに、ここで使用されるところでは、“連結される”、“接続される”、“応じる”又はその派生語は、無線で連結され、接続され、又は応じることを含み得る。ここで使用されるところでは、単数形の“a”、“an”及び“the”は、そうではないことを文脈が明確に示さない限り、複数形も同様に含むことが意図される。周知の機能又は構造は、簡潔さ及び／又は明確さのために詳細には説明されないことがあり得る。“及び／又は”という用語は、関連付けられる列挙された事項のうちの１つ以上のありとあらゆる組み合わせを含む。
【００６４】
種々のエレメント／動作を説明するためにここでは第１、第２、第３などの用語が使用されているかもしれないが、それらエレメント／動作はそれら用語により限定されるべきではないことが理解されるであろう。それら用語は、単にあるエレメント／動作と他のエレメント／動作とを区別するために使用されている。よって、いくつかの実施形態における第１のエレメント／動作を、本発明概念の教示から逸脱することなく、他の実施形態において第２のエレメント／動作と称することができる。同一の参照番号又は同一の参照指定子（designators）は、本明細書を通じて同一の又は類似のエレメントを表す。
【００６５】
ここで使用されるところでは、“備える／含む（comprise、comprising、comprises）”、“含む（include、including、includes）”、“有する（have、has、having）”又はそれらの派生語といった用語は、オープンエンド（open-ended）であり、１つ以上の記載された特徴、整数、エレメント、ステップ、コンポーネント又は機能を含むが、１つ以上の他の特徴、整数、エレメント、ステップ、コンポーネント、機能又はこれらの集合の存在又は追加を排除しない。さらに、ここで使用されるところでは、ラテン語のフレーズ“exempli  gratia”に由来する“e.g.（例えば）”という共通的な省略形は、その前に言及された事項の一般的な１つ又は複数の例を紹介し又は特定するために用いられ、そのような事項を限定することは意図されない。ラテン語のフレーズ“id  est”に由来する共通的な省略形“i.e.（即ち）”は、より一般的な記述から個別の事項を特定するために用いられ得る。
【００６６】
例示的な実施形態は、コンピュータにより実装される方法、装置（システム及び／若しくはデバイス）並びに／又はコンピュータプログラムプロダクトのブロック図及び／又はフローチャートによる例示を参照しつつ、ここで説明されている。ブロック図及び／又はフローチャートの説明のうちの１つのブロック、並びにブロック図及び／又はフローチャートの説明における複数のブロックの組み合わせは、１つ以上のコンピュータ回路によって実行されるコンピュータプログラム命令によって実装され得ることが理解される。これらのコンピュータプログラム命令は、汎用コンピュータ回路、特殊用途コンピュータ回路、及び／又はマシンを産み出すための他のプログラマブルデータ処理回路、のプロセッサ回路に提供されてもよく、それによって、コンピュータ及び／又は他のプログラマブルデータ処理装置のプロセッサを介して実行される当該命令は、そのような回路内のトランジスタ、メモリロケーションに記憶される値、及び他のハードウェアコンポーネントを変形し及び制御して、ブロック図及び／又はフローチャートの１つ又は複数のブロックにおいて特定される機能／動作を実装し、それによって、当該ブロック図及び／又はフローチャートのブロックにおいて特定される当該機能／動作を実装するための手段（機能性）及び／又は構造を生成し得る。
【００６７】
これらのコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理装置に特定の手法で機能するように指示することができる有形のコンピュータ読取可能な媒体に記憶されてもよく、それによって、当該コンピュータ読取可能な媒体に記憶される当該命令は、ブロック図及び／又はフローチャートの１つ又は複数のブロックにおいて特定される機能／動作を実装する命令を含む製品を産み出す。従って、本発明概念の実施形態は、ハードウェアで、及び／又はデジタル信号プロセッサなどのプロセッサ上で稼働する（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）ソフトウェアで具現化されてよく、それらは“回路”、“モジュール”又はそれらの派生語で総称され得る。
【００６８】
幾つかの代替的な実装において、ブロック内に記述される機能／動作はフローチャートにおいて記述される順序とは異なる順序で発生し得ることにも留意すべきである。例えば、連続して示される２つのブロックは、実際には、実質的に同時に実行されてもよく、又は、これらのブロックは、関与する機能／動作に依存して、逆の順序で実行されることがあってもよい。そのうえ、フローチャート及び／又はブロック図の所与のブロックの機能性は、複数のブロックに分けられてもよく、並びに／又は、フローチャート及び／若しくはブロック図の２つ以上のブロックの機能性は、少なくとも部分的に統合されてもよい。最後に、本発明概念の範囲から逸脱することなく、例示されるブロック間に他のブロックが追加され／挿入されてもよく、ブロック／動作が省略されてもよい。そのうえ、図のうちのいくつかは、通信の主な方向を示すために通信パス上に矢印を含むが、図示される矢印とは反対の方向において通信が生じてもよいことが理解されるべきである。
【図１】
0006302136.tif 000002
【図２】
0006302136.tif 000003
【図３】
0006302136.tif 000004
【図４】
0006302136.tif 000005
【図５】
0006302136.tif 000006
【図６】
0006302136.tif 000007
【図７】
0006302136.tif 000008
【図８】
0006302136.tif 000009
【図９】
0006302136.tif 000010
【図１０】
0006302136.tif 000011
【図１１】
0006302136.tif 000012