特許 6954977 端末、フィードバック制御方法、及びフィードバック方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6954977

(24)【登録日】2021年10月4日

(45)【発行日】2021年10月27日

(54)【発明の名称】端末、フィードバック制御方法、及びフィードバック方法

(51)【国際特許分類】

   H04W 28/04 20090101AFI20211018BHJP

   H04W 92/18 20090101ALI20211018BHJP

   H04W 72/04 20090101ALI20211018BHJP

【ＦＩ】

   H04W28/04 110

   H04W92/18

   H04W72/04

【請求項の数】16

【全頁数】39

(21)【出願番号】特願2019-209844(P2019-209844)

(22)【出願日】2019年11月20日

(62)【分割の表示】特願2016-559053(P2016-559053)の分割

【原出願日】2015年11月10日

(65)【公開番号】特開2020-25357(P2020-25357A)

(43)【公開日】2020年2月13日

【審査請求日】2019年11月20日

(31)【優先権主張番号】特願2014-232135(P2014-232135)

(32)【優先日】2014年11月14日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】安川 真平

(72)【発明者】

【氏名】武田 和晃

(72)【発明者】

【氏名】原田 浩樹

(72)【発明者】

【氏名】永田 聡

(72)【発明者】

【氏名】ジョウ チュン

【審査官】 松野 吉宏

(56)【参考文献】

【文献】 国際公開第２０１３／１２２３８４（ＷＯ，Ａ１）

【文献】 国際公開第２０１４／１６７８８３（ＷＯ，Ａ１）

【文献】 国際公開第２０１３／１８１８０７（ＷＯ，Ａ１）

【文献】 General Dynamics Broadband UK，ProSe device-to-device communication control channel design，3GPP TSG-RAN WG1#75 R1-135495，フランス，3GPP，2013年11月01日，Section 4

【文献】 RAN1，LS on TP for D2D for TS 36.300，3GPP TSG-RAN WG1#78 R1-143677，フランス，3GPP，2014年10月05日，Section 5.6

【文献】 CATR，On control information of D2D communication，3GPP TSG-RAN WG1♯76 R1-140662，フランス，3GPP，2014年01月31日，Sections 1, 3

【文献】 InterDigital，D2D Communication in LTE，3GPP TSG-RAN WG1 Meeting #73 R1-132188，2013年05月11日，pp.1-7

【文献】 Samsung，Control information needed for D2D broadcast communication，3GPP TSG RAN WG1 Meeting #78 R1-143076，3GPP，2014年08月10日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

サイドリンク制御情報とデータをサイドリンクで受信する受信部と、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで送信する送信部と、を備え、
前記送信部は、前記データのリソースとフィードバック用リソースとの対応関係に基づいて、前記フィードバック信号を送信するリソースを決定し、
前記送信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記フィードバック信号を送信する
端末。

【請求項2】

サイドリンク制御情報とデータをサイドリンクで受信する受信部と、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで送信する送信部と、を備え、
前記送信部は、前記サイドリンク制御情報とフィードバック用リソースとの対応関係に基づいて、前記フィードバック信号を送信するリソースを決定し、
前記送信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記フィードバック信号を送信する
端末。

【請求項3】

前記受信部が、ＣＳＩ要求を含む前記サイドリンク制御情報を受信した場合に、前記送信部は、サイドリンクでＣＳＩ報告を行う、
請求項１又は２に記載の端末。

【請求項4】

前記送信部が、前記ＣＳＩとして、ＣＱＩ又はＲＩを報告する
請求項３に記載の端末。

【請求項5】

前記受信部は、フィードバックの有無が設定されたリソースプールの設定情報を基地局から受信する
請求項１又は２に記載の端末。

【請求項6】

前記受信部は、ＲＲＣシグナリングにより、サイドリンクのフィードバック用のリソースの設定情報を受信する
請求項１又は２に記載の端末。

【請求項7】

複数のフィードバック送信リソース候補が決定され、前記送信部は、前記サイドリンク制御情報に含まれるコンテンツによって、フィードバック送信に利用するリソースを切り替える
請求項１又は２に記載の端末。

【請求項8】

前記サイドリンク制御情報とフィードバック用リソースとの対応関係は、前記端末において予め設定されている
請求項２に記載の端末。

【請求項9】

前記送信部は、前記フィードバック信号を多重した系列を送信する
請求項１又は２に記載の端末。

【請求項10】

サイドリンク制御情報とデータをサイドリンクで送信する送信部と、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで受信する受信部と、を備え、
前記受信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記データのリソースとフィードバック用リソースとの対応関係に基づいて決定されたリソースで前記フィードバック信号を受信する
端末。

【請求項11】

サイドリンク制御情報とデータをサイドリンクで送信する送信部と、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで受信する受信部と、を備え、
前記受信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記サイドリンク制御情報とフィードバック用リソースとの対応関係に基づいて決定されたリソースで前記フィードバック信号を受信する
端末。

【請求項12】

前記送信部は、前記受信部により受信した前記フィードバック信号に基づいて、フィードバック信号をＰＵＣＣＨで送信する
請求項１０又は１１に記載の端末。

【請求項13】

前記送信部が、基地局にスケジューリング要求を送信し、基地局により割り当てられたリソースを用いてサイドリンク送信を行う
請求項１０又は１１に記載の端末。

【請求項14】

前記受信部は、基地局からサイドリンクのスケジューリング用のＤＣＩを受信し、前記ＤＣＩは、再送インデックス、ＮＤＩ、及びフィードバック送信リソースインジケータを含む
請求項１０又は１１に記載の端末。

【請求項15】

サイドリンク制御情報とデータをサイドリンクで受信する受信ステップと、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで送信する送信ステップと、を備え、
前記送信ステップにおいて、前記データのリソースとフィードバック用リソースとの対応関係に基づいて、前記フィードバック信号を送信するリソースを決定し、
前記送信ステップにおいて、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記フィードバック信号を送信する
端末が実行するフィードバック制御方法。

【請求項16】

サイドリンク制御情報とデータをサイドリンクで送信する送信ステップと、
前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで受信する受信ステップと、を備え、
前記受信ステップにおいて、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記データのリソースとフィードバック用リソースとの対応関係に基づいて決定されたリソースで前記フィードバック信号を受信する
端末が実行するフィードバック方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、Ｄ２Ｄ通信（ユーザ装置間通信）に関するものであり、特に、Ｄ２Ｄ通信において、Ｄ２Ｄ信号を受信したユーザ装置ＵＥがフィードバック信号を送信する技術に関連するものである。なお、Ｄ２Ｄ通信のことをサイドリンク（Ｓｉｄｅｌｉｎｋ）通信と呼ぶこともある。

【背景技術】

【0002】

現状のＬＴＥ等の移動体通信システムでは、ユーザ装置ＵＥと基地局ｅＮＢが通信を行うことにより基地局ｅＮＢ等を介してユーザ装置ＵＥ間で通信を行うことが一般的であるが、近年、ユーザ装置ＵＥ間で直接に通信を行うＤ２Ｄ通信（以降、"Ｄ２Ｄ"と呼ぶ）についての種々の技術が提案されている。

【0003】

特に、ＬＴＥにおけるＤ２Ｄでは、ユーザ装置ＵＥ間でプッシュ通話等のデータ通信を行う「Ｃｏｍｍｕｎｉｃａｔｉｏｎ（コミュニケーション）」と、ユーザ装置ＵＥが、自身のＩＤやアプリケーションＩＤ等を含む発見信号（ｄｉｓｃｏｖｅｒｙ ｓｉｇｎａｌ）を送信することで、受信側のユーザ装置ＵＥに送信側のユーザ装置ＵＥの検出を行わせる「Ｄｉｓｃｏｖｅｒｙ（発見）」が提案されている（非特許文献１参照）。

【0004】

ＬＴＥで規定されるＤ２Ｄでは、各ユーザ装置ＵＥは、ユーザ装置ＵＥから基地局ｅＮＢへの上り信号送信のリソースとして既に規定されている上りリソースの一部を利用することが提案されている。また、Ｄ２Ｄで使用するリソースの割り当てにおいては、基地局ｅＮＢからのアシストがなされることも提案されている。以下、現状で提案されているＬＴＥのＤ２Ｄの送信のためのリソース割り当ての概要を説明する（非特許文献１参照）。

【0005】

「Ｄｉｓｃｏｖｅｒｙ」については、図１Ａに示すように、Ｄｉｓｃｏｖｅｒｙ ｐｅｒｉｏｄ毎に、Ｄｉｓｃｏｖｅｒｙ信号用のリソースプールが確保され、ユーザ装置ＵＥはそのリソースプール内でＤｉｓｃｏｖｅｒｙ信号を送信する。より詳細にはＴｙｐｅ１、Ｔｙｐｅ２ａ、Ｔｙｐｅ２ｂがある。Ｔｙｐｅ１では、ユーザ装置ＵＥが自律的にリソースプールから送信リソースを選択する。Ｔｙｐｅ２ａでは、（Ｅ）ＰＤＣＣＨによりダイナミックにリソースプール内の特定のリソースが割り当てられる。Ｔｙｐｅ２ｂでは、上位レイヤシグナリング（例えばＲＲＣ信号）により準静的なリソースが割り当てられる。

【0006】

「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」についても、図１Ｂに示すように、ＳＡ／Ｄａｔａ送信用リソースプールが周期的に確保されることが検討されている。ＳＡはＳｃｈｅｄｕｌｉｎｇ Ａｓｓｉｇｎｍｅｎｔの略であり、送信側のユーザ装置はＳＡリソースプールから選択されたリソースでＤａｔａ送信用リソースを受信側に通知し、当該Ｄａｔａ送信用リソースでＤａｔａを送信する。このリソース通知の信号のことをＳＡと呼んでもよい。「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」について、より詳細には、Ｍｏｄｅ１とＭｏｄｅ２がある。Ｍｏｄｅ１では、基地局ｅＮＢからユーザ装置ＵＥに送られる（Ｅ）ＰＤＣＣＨによりダイナミックにリソースが割り当てられる。また、（Ｅ）ＰＤＣＣＨの割り当てにおいては、準静的なリソース割り当て（ＳＰＳ： Ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ ｓｃｈｅｄｕｌｉｎｇ）も提案されている。Ｍｏｄｅ２では、ユーザ装置ＵＥはＳＡリソースプールから自律的に送信リソースを選択する。なお、リソースプールについては、ＳＩＢで通知されたり、予め定義されたものが使用される。

【0007】

図１Ｃは、Ｄ２ＤのリソースプールがＷＡＮのリソースとＦＤＭ／ＴＤＭにより多重される例をより具体的に示すものである。図１Ｃの信号構成に示すように、ＳＡ、Ｄａｔａには、いずれもＰＵＳＣＨベースの信号構成が採用されている。

【先行技術文献】

【非特許文献】

【0008】

【非特許文献1】３ＧＰＰ ＴＲ ３６．８４３ Ｖ１２．０．１ （２０１４−０３）

【発明の概要】

【発明が解決しようとする課題】

【0009】

ＬＴＥのＲｅｌ−１２におけるＤ２Ｄ ｃｏｍｍｕｎｉｃａｔｉｏｎでは、ブロードキャスト（Ｂｒｏａｄｃａｓｔ）がサポートされ、グループキャスト（Ｇｒｏｕｐ−ｃａｓｔ）、及びユニキャスト（Ｕｎｉｃａｓｔ）についてはＬ１ ＩＤ及びＭＡＣ送信元・送信先ＩＤのみが規定され、Ｒｅｌ−１３でＧｒｏｕｐ−ｃａｓｔ、及びＵｎｉｃａｓｔの詳細機能が規定されようとしている。

【0010】

また、Ｒｅｌ−１２のＤ２ＤではＳＡ／Ｄａｔａ等を繰り返して送信するＲｅｐｅｔｉｔｉｏｎのみサポートされ、ＨＡＲＱフィードバックに基づく再送及びＣＳＩフィードバックはサポートされていない。従って、Ｄａｔａが届かない等の場合の再送は例えば上位レイヤで行うことになる。

【0011】

一方で、特にＵｎｉｃａｓｔにおいて上位レイヤ再送に頼った制御では再送遅延・再送オーバーヘッドの観点で効率的とはいえず、フィードバックなしにはＬｉｎｋ ａｄａｐｔａｔｉｏｎによる周波数利用効率改善も適切に行われない可能性がある。そのため実現できるデータレートも低く、ブロードバンド通信には適さない。

【0012】

本発明は上記の点に鑑みてなされたものであり、Ｄ２Ｄ通信をサポートする移動通信システムにおいて、ユーザ装置間でのフィードバック及び再送を行うことを可能とする技術を提供することを目的とする。

【課題を解決するための手段】

【0013】

本発明の実施の形態によれば、サイドリンク制御情報とデータをサイドリンクで受信する受信部と、前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで送信する送信部と、を備え、前記送信部は、前記データのリソースとフィードバック用リソースとの対応関係に基づいて、前記フィードバック信号を送信するリソースを決定し、前記送信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記フィードバック信号を送信する端末が提供される。

【0014】

また、本発明の実施の形態によれば、サイドリンク制御情報とデータをサイドリンクで送信する送信部と、前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで受信する受信部と、を備え、前記受信部は、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記データのリソースとフィードバック用リソースとの対応関係に基づいて決定されたリソースで前記フィードバック信号を受信する端末が提供される

【0015】

また、本発明の実施の形態によれば、サイドリンク制御情報とデータをサイドリンクで受信する受信ステップと、前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで送信するステップと、を備え、前記送信ステップにおいて、前記データのリソースとフィードバック用リソースとの対応関係に基づいて、前記フィードバック信号を送信し、前記送信ステップにおいて、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記フィードバック信号を送信するリソースを決定する端末が実行するフィードバック制御方法が提供される。

【0016】

また、本発明の実施の形態によれば、サイドリンク制御情報とデータをサイドリンクで送信する送信ステップと、前記データに対するフィードバック信号を、サイドリンクフィードバックチャネルで受信する受信ステップと、を備え、前記受信ステップにおいて、前記フィードバック信号がＮＡＣＫのみを含む場合に、前記データのリソースとフィードバック用リソースとの対応関係に基づいて決定されたリソースで前記フィードバック信号を受信する端末が実行するフィードバック方法が提供される。

【発明の効果】

【0017】

本発明の実施の形態によれば、Ｄ２Ｄ通信をサポートする移動通信システムにおいて、ユーザ装置間でのフィードバック及び再送を行うことを可能とする技術が提供される。

【図面の簡単な説明】

【0018】

【図1A】Ｄ２Ｄ通信を説明するための図である。

【図1B】Ｄ２Ｄ通信を説明するための図である。

【図1C】Ｄ２Ｄ通信を説明するための図である。

【図2】本発明の実施の形態におけるシステムの構成図である。

【図3A】フィードバック用チャネルの例を示す図である。

【図3B】フィードバック用チャネルの例を示す図である。

【図4】フィードバックＳＣＩを説明するための図である。

【図5】Ｄａｔａによるフィードバックの例１を示す図である。

【図6】Ｄａｔａによるフィードバックの例２を示す図である。

【図7】Ｄａｔａによるフィードバックの例３を示す図である。

【図8】フィードバックリソース割り当ての例を説明するための図である。

【図9】ＰＵＣＣＨフォーマット１に基づくシンボルマッピング構成例を示す図である。

【図10】ＰＵＣＣＨフォーマット３に基づくシンボルマッピング構成例を示す図である。

【図11】ＰＵＣＣＨベースのチャネル構成におけるＤＭ−ＲＳの詳細を示す図である。

【図12A】ＡＣＫ／ＮＡＣＫフィードバックのバンドリングを説明するための図である。

【図12B】ＡＣＫ／ＮＡＣＫフィードバックのバンドリングを説明するための図である。

【図12C】ＡＣＫ／ＮＡＣＫフィードバックのバンドリングを説明するための図である。

【図13】フィードバック情報のチャネルへのマッピング例を示す図である。

【図14】スケジューリングＳＣＩの例を説明するための図である。

【図15】再送・新規送信の混合スケジューリングを説明するための図である。

【図16】第１の実施の形態におけるユーザ装置ＵＥの構成図である。

【図17】第２の実施の形態における処理手順例２−１を示す図である。

【図18】第２の実施の形態における処理手順例２−２を示す図である。

【図19】第２の実施の形態における処理手順例２−３を示す図である。

【図20】第２の実施の形態におけるユーザ装置ＵＥの構成図である。

【図21】第２の実施の形態における基地局ｅＮＢの構成図である。

【図22】第３の実施の形態における処理手順例３−１を示す図である。

【図23】第３の実施の形態における処理手順例３−２を示す図である。

【図24】第３の実施の形態におけるユーザ装置ＵＥの構成図である。

【図25】第３の実施の形態における基地局ｅＮＢの構成図である。

【図26】ユーザ装置ＵＥのＨＷ構成図である。

【図27】基地局ｅＮＢのＨＷ構成図である。

【発明を実施するための形態】

【0019】

以下、図面を参照して本発明の実施の形態を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。例えば、本実施の形態に係る移動通信システムはＬＴＥに準拠した方式のシステムを想定しているが、本発明はＬＴＥに限定されるわけではなく、他の方式にも適用可能である。また、以下では、主にＣｏｍｍｕｎｉｃａｔｉｏｎにおけるＤａｔａに対するフィードバックを説明しているが、本発明のフィードバック技術はＤａｔａに限らず、Ｄ２Ｄ信号全般に適用可能である。また、本明細書及び特許請求の範囲において、「ＬＴＥ」は、３ＧＰＰのＲｅｌ−１２、１３もしくはそれ以降に対応する通信方式も含み得る広い意味で使用する。

【0020】

以下の説明では、ＮＡＣＫ等のフィードバックに基づく再送を「再送」と記述し、送信の繰り返しを「Ｒｅｐｅｔｉｔｉｏｎ」と記述する。また、後述するように、ＳＡリソースプールで送信される制御情報をＳＣＩ（Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ぶことができるが、「ＳＣＩ」の用語については主に、「フィードバックＳＣＩ」と、新規なフォーマットを有するＳＡとして特別に説明される「スケジューリングＳＣＩ」について用いることとし、便宜上、ＳＡについては主に「ＳＡ」の用語を用いている。ただし、「ＳＡ」と記述されていても、既存のＳＡに限定されるわけではない。

【0021】

また、ＡＣＫ／ＮＡＣＫ、ＣＳＩ等を総称してフィードバック信号と呼ぶ。フィードバック信号の意味には、ＡＣＫ／ＮＡＣＫ、ＣＳＩ等をＤａｔａで送信する場合におけるＳＡも含まれる。

【0022】

（システム構成）
図２は、本発明の実施の形態（各実施の形態に共通）における移動通信システムの構成例を示す図である。図２に示すように、本実施の形態における通信システムは、基地局ｅＮＢの配下にユーザ装置ＵＥ１、ＵＥ２が存在するセルラー通信システムである。ユーザ装置ＵＥ１、ＵＥ２はそれぞれＤ２Ｄ通信機能を有しており、ユーザ装置ＵＥ１、ＵＥ２間でＤ２Ｄ通信を行うことが可能である。また、ユーザ装置ＵＥ１、ＵＥ２はそれぞれ基地局ｅＮＢとの間で通常のセルラー通信を行うことが可能であるとともに、基地局ｅＮＢからＤ２Ｄ通信用のリソース割り当てを受けることができる。

【0023】

図２は、ユーザ装置ＵＥ１、ＵＥ２が基地局ｅＮＢのカバレッジ内にあることを示しているが、これは一例であり、本発明は、ユーザ装置ＵＥが基地局ｅＮＢのカバレッジ外にあっても実施可能である。以下では、ユーザ装置ＵＥ１、ＵＥ２を総称してユーザ装置ＵＥ又はＵＥと記述する。また、ＳＡ／Ｄａｔａの送信側（フィードバックを受信する側）のユーザ装置ＵＥを送信側ＵＥ、受信側（フィードバックを送信する側）のユーザ装置ＵＥを受信側ＵＥと記述する。

【0024】

以下では、第１の実施の形態、第２の実施の形態、及び第３の実施の形態を説明する。第１の実施の形態では、送信Ｄａｔａに対するＡＣＫ／ＮＡＣＫ、及び／又は受信品質（ＣＳＩ：Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）のフィードバックを行うための技術を説明する。第２の実施の形態では、Ｍｏｄｅ１リソース割り当て時の再送の技術について説明する。第３の実施の形態では、フィードバック設定やフィードバックタイプの切り替え等について説明する。

【0025】

（第１の実施の形態）
まず、第１の実施の形態について説明する。以下では、フィードバック用のリソース構成例１〜３について説明する。

【0026】

＜フィードバック用のリソース構成例１＞
Ｄ２Ｄ通信において、受信側ＵＥが送信側ＵＥに対してフィードバック信号を送信するためのリソースとして、リソース構成例１では、フィードバック専用のリソース群（フィードバック用チャネルと呼ぶ）を定義し、当該フィードバック用チャネルを使用する。ファードバック用チャネルを使用することで、低遅延でのフィードバックが実現可能となる。

【0027】

図３Ａ、図３Ｂにフィードバック用チャネルのリソース構成の例を示す。図３Ａの例では、網掛けされたリソースプールがフィードバック用チャネルとして定義される。図３Ａでは、例として、フィードバック用チャネルの１つのリソースプールが「Ｒｅｓｐｏｎｓｅ」として示されている。

【0028】

図３Ａに示すように、本例では、フィードバック用チャネルのリソースプールがＤａｔａ送信のリソースプールの後（時間的に後）、かつ、ＳＡリソースプールの前（時間的に前）に配置されている。例えば、図３ＡのＡ、Ｂで示されるリソースプールの中のリソースを使用して、送信側ＵＥが受信側ＵＥに対してＳＡ／Ｄａｔａを送信した後、受信側ＵＥは、送信側ＵＥに対して、次のＳＡリソースプールまでの間のフィードバックリソースであるＣで示されるリソースプールの中のリソースを使用してフィードバック信号を送信する。

【0029】

なお、フィードバック用チャネル（フィードバック用のリソースプール）はＤＦＮ／ＳＦＮ（システムフレーム番号）の開始からＳＡ ｏｆｆｓｅｔ ｉｎｄｉｃａｔｏｒで示されるサブフレームまでの間に設定されるとしてもよい。このようにすることで、Ｒｅｌ−１２のＵＥと互換性のあるＳＡ／Ｄａｔａ送信リソースプールの定義が可能になる。

【0030】

また、フィードバック用チャネルのリソースを図３Ｂに示すように構成してもよい。図３Ｂの例では、ＳＡリソースプールを時分割し、前半をフィードバック用チャネルとして用い、後半をＳＡの送信に使用する。

【0031】

また、フィードバック用のリソースプールは、例えば、カバレッジ内においては、基地局ｅＮＢが各ＵＥに対してシステム情報（ＳＩＢ）を用いて設定することができ、その際の設定内容としては、例えば、当該リソースプールのリソースブロック（ＲＢｓ）の指定、サブフレーム、周期、等がある。また、ＳＡリソースプール／Ｄａｔａリソースプール／Ｃｏｍｍｕｎｉｃａｔｉｏｎ用フィードバックリソースプールが、１対１対１にマッピングされ、Ｄｉｓｃｏｖｅｒｙリソースプール／Ｄｉｓｃｏｖｅｒｙ用フィードバックリソースプールが１対１にマッピングされることとしてもよい。

【0032】

また、カバレッジ外用にフィードバックリソースプールを予めＵＥに設定しておき、カバレッジ外になったときに、ＵＥは、当該フィードバックリソースプールを使用することとしてもよい。

【0033】

なお、リソース構成例１において、受信側ＵＥによるフィードバック信号送信のためのリソース（時間／周波数位置等）については、例えば、基地局ｅＮＢが明示的にＵＥに対してＵＥ個別シグナリング（例：ＰＤＣＣＨ／ＳＣＨ、ＲＲＣシグナリング等）で割り当てることができる。特に、後述するように、基地局ｅＮＢがフィードバック信号をＵＥから受信する場合には、このように明示的にリソースを割り当てることが望ましい。

【0034】

また、受信側ＵＥによるフィードバック信号送信のためリソース（時間／周波数位置）を送信側ＵＥが受信側ＵＥに割り当てることとしてもよい。この割り当ては、例えばＳＡを用いて明示的に行ってもよいし、暗黙的に行ってもよい。

【0035】

暗黙的に割り当てる例として、ＳＡ／Ｄａｔａのリソース位置と、フィードバック用リソース位置との対応関係（マッピング）を予め定めておき、受信側ＵＥは、受信したＳＡ／Ｄａｔａのリソース位置に基づいてフィードバックリソースを決定し、当該フィードバックリソースでフィードバック信号を送信してもよい。また、Ｄｉｓｃｏｖｅｒｙのリソース位置と、フィードバック用リソース位置との対応関係（マッピング）を予め定めておき、受信側ＵＥは、受信したＤｉｓｃｏｖｅｒｙのリソース位置に基づいてフィードバックリソースを決定し、当該フィードバックリソースでフィードバック信号を送信してもよい。

【0036】

また、上記の他に、受信側ＵＥが、例えば任意に（例：ランダムに）、設定されたフィードバック用リソースプールの中からリソースを選択してフィードバック信号を送信することとしてもよい。

【0037】

＜フィードバック用のリソース構成例２＞
フィードバック用のリソース構成例２では、受信側ＵＥが送信側ＵＥに対してフィードバック信号を送信するためのリソースとしてＳＡリソースプール中のリソースを使用する。より具体的には、新たなＳＣＩを定義し、当該ＳＣＩをフィードバック信号として送信する。ここで、ＳＣＩは、Ｓｉｄｅｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎの略であり、ＳＡリソースプールにおける制御情報を意味する。背景技術のところで説明したＳＡの信号はＳＣＩの例であり、スケジューリングを行うことからスケジューリングＳＣＩと呼ぶことができる。なお、「Ｓｉｄｅｌｉｎｋ」とはＤ２Ｄ通信のことを意味する。

【0038】

フィードバック用に使用するＳＣＩをフィードバックＳＣＩ（Ｆｅｅｄｂａｃｋ ＳＣＩ）と呼ぶ。受信側ＵＥは、フィードバックＳＣＩを用いて、ＡＣＫ／ＮＡＣＫ／ＣＳＩ等のフィードバック信号だけを送信側ＵＥに通知してもよいし、当該フィードバック信号に加えて、フィードバックの対象となった初回送信Ｄａｔａ（再送でないＤａｔａ）との対応（どのＤａｔａに対するフィードバックであるか）を明示的に通知するＩｎｄｅｘ情報を通知してもよい。

【0039】

このように、ＳＡリソースプールの中のリソースを用いてフィードバック信号を送信することで、新たなリソースプールを定義することなしにＨＡＲＱ制御を実現可能であり、フィードバックによるオーバーヘッド増加を回避できる。

【0040】

図４に、フィードバックＳＣＩのマッピングの一例を示す。図４に示すように、この例では、Ａで示されるＳＡリソースプールで送信側ＵＥから送信されたＳＡに対応するＤａｔａに対するフィードバックＳＣＩ（フィードバックメッセージ）が、Ｂで示されるＳＡリソースプール中のリソースで受信側ＵＥから送信される。

【0041】

図４では、一例として、ＳＡリソースプールにおいて、ＳＡリソース位置と、フィードバックＳＣＩリソース位置とが所定の対応関係を持つことが示されている。すなわち、本例では、受信側ＵＥは、ＳＡを受信したリソース位置に基づいて、フィードバックＳＣＩのリソースを決定し、当該リソースを使用してフィードバックＳＣＩを送信することができる。

【0042】

リソース構成例２において、あるＳＡリソースプールでＳＡを送信した送信側ＵＥは、次のＳＡリソースプールでは新規スケジューリングを行わない（ＳＡを送信しない）という制御を行ってもよい。その理由は、Ｄ２Ｄにおいて、ＵＥは、送信と受信を同時に（同一サブフレームで）行うことができないというＨａｌｆ ｄｕｐｌｅｘ制限があり、仮に、次のＳＡリソースプールでＳＡ送信をあるサブフレームで行う場合に、当該サブフレームで受信する可能性のあるフィードバックＳＣＩをうまく受信できない可能性があるからである。

【0043】

また、あるＳＡリソースプールでＳＡを送信した送信側ＵＥは、次のＳＡリソースプールでは、フィードバックＳＣＩのみを検出することとしてもよい。このように、フィードバックＳＣＩの受信が期待される場合には、フィードバックＳＣＩのみの検出を行うことで、ＳＣＩブラインド検出回数（サーチ回数）を削減でき、効率的にフィードバックＳＣＩを検出することが可能となる。

【0044】

また、フィードバックＳＣＩとＳＡ（スケジューリングＳＣＩ）との衝突を回避するために、Ｍｏｄｅ２（自律的にリソース選択を行うモード）においては、フィードバックを要求するＳＡ（スケジューリングＳＣＩ）を検出した受信側ＵＥが、次のＳＡ周期でのフィードバックＳＣＩ送信リソースをＳＡ（スケジューリングＳＣＩ）の送信リソース候補から除外してもよい。

【0045】

ここで、ＵＥにおいて、ＳＡ（スケジューリングＳＣＩ）とフィードバックＳＣＩの送受サブフレームが衝突する場合、いずれかを優先することとしてもよい。例えば、優先度の大きい順に、「フィードバックＳＣＩ受信＞フィードバックＳＣＩ送信＞スケジューリングＳＣＩ送信＞スケジューリングＳＣＩ受信」で示される優先順位で、送受を行ってもよい。例えば、あるＵＥにおいて、フィードバックＳＣＩ受信とスケジューリングＳＣＩ送信とが同一サブフレームになる場合、当該サブフレームでは、フィードバックＳＣＩ受信を行う。上記の順序は、ＵＥ間で再送が近い時点で起こりやすいという観点での順序であり、一例である。このように、再送が生じ得る動作を優先することで、オーバーヘッド・遅延を削減することができる。

【0046】

＜フィードバック用のリソース構成例３＞
フィードバック用のリソース構成例３では、受信側ＵＥは、Ｄ２ＤのＤａｔａを使用してフィードバック信号を送信する。つまり、ＡＣＫ／ＮＡＣＫ、ＣＳＩをＤａｔａとして送信する。このようにＤａｔａをフィードバックに使用することで、多数のＡＣＫ／ＮＡＣＫビットをフィードバックすることが可能となる。

【0047】

より具体的な３つの例（例１〜例３）を図５〜図７を参照して説明する。

【0048】

例１（図５）では、受信側ＵＥは、フィードバック信号を通常のＤａｔａとして扱う。すなわち、図５において、Ａ、Ｂで示されるリソースにより送信側ＵＥからＳＡ／Ｄａｔａが送信される。そして、受信側ＵＥは、フィードバック信号をＤａｔａとして送信するためのＳＡ（フィードバック信号としてのＤａｔａのリソース位置を含む）をＣのリソースで送信し、フィードバック信号をＤのリソースで送信する。なお、図５（他の図も同様）において、ＳＡについて２回のＲｅｐｅｔｉｔｉｏｎが行われ、Ｄａｔａについて４回のＲｅｐｅｔｉｔｉｏｎが行われることが示されている。

【0049】

例２（図６）では、受信側ＵＥは、送信側ＵＥから送信されるＳＡ／Ｄａｔａと同一周期内で受信Ｄａｔａに対するフィードバック信号をＤａｔａとして（Ｄａｔａリソースで）送信側ＵＥに送信する。図６において、受信Ｄａｔａのリソースと、当該Ｄａｔａに対するフィードバック信号のリソースとが対応付けられることが示されている。

【0050】

すなわち、送信側ＵＥから送信されるＳＡにより示されるＤａｔａのリソースと、フィードバック送信に使用されるリソースとの対応関係（マッピング）が予め定められる。これは、基地局ｅＮＢからＵＥへのシグナリングでＵＥに設定されるものでもよいし、ＵＥに予め設定されているものであってもよい。また、対応関係（マッピング）が複数種類定義され、それらのうちの１つを使用することとしてもよい。受信側ＵＥは当該対応関係に基づいてフィードバック信号をＤａｔａとして送信することができる。

【0051】

なお、ＤａｔａのＲｅｐｅｔｉｔｉｏｎのパターン等を指定するＴ−ＲＰＴ（ＳＡに含まれる）に、フィードバック用のＤａｔａリソース位置を示す情報を含め、受信側ＵＥは当該情報によりフィードバック用のＤａｔａリソースを決定することとしてもよい。

【0052】

また、Ｋ（Ｋは１以上の整数）回のＤａｔａ送信（初回とＲｅｐｅｔｉｔｉｏｎ）のリソースに対して１つのフィードバックリソースを割り当て、当該Ｋを設定可能なように構成してもよい。図６の例はＫ＝１（Ｄａｔａとフィードバックが１対１）の例である。また、フィードバック信号の周波数領域リソースについては、送信側ＵＥからのＳＡによるリソース割り当てと同じでもよいし異なっていてもよい。

【0053】

例３（図７）では、送信側ＵＥは、フィードバック送信用のＤａｔａリソース位置をＳＡを用いて受信側ＵＥに通知する。図７の例では、送信側ＵＥは、送信側ＵＥからのＤａｔａ送信用のＳＡ（ＳＡ１）と同一のＳＡ周期にて、フィードバックリソース割り当て用のＳＡ（ＳＡ２）を送信する。

【0054】

すなわち、図７において、受信側ＵＥは、Ｄａｔａ用のＳＡ１（Ａで示す）に指定されるリソースでＤａｔａ（Ｂで示される）を受信するとともに、フィードバック用のＳＡ２（Ｃで示される）で指定されるリソースでフィードバック信号（Ｄで示される）を送信側ＵＥに送信する。

【0055】

上記フィードバック用のリソースを指定するＳＡ（スケジューリングＳＣＩ）に関しては、既存のＳＡに対して、フィードバック用のリソースを指定するための新たなフィールドが設けられてもよい。また、ＳＡ１とＳＡ２を送信するリソースについては、異なるサブフレームであってもよいし、同一サブフレーム内の連続する周波数位置であってもよい。

【0056】

また、ＳＡ１／ＳＡ２により指定されるＤａｔａ／フィードバック信号のリソースについては、関連付けがされていてもよいし、各々独立であってもよい。

【0057】

＜上記の例３に関しての詳細＞
通常のＳＡの送信では、Ｄａｔａ送信側がＳＡを送信するが、上記の例３では、送信側ＵＥはＳＡ（ＳＡ２）を送信しても当該ＳＡに対応するＤａｔａを送信せず、当該ＳＡ（ＳＡ２）に対応するＤａｔａ（フィードバック）が、ＳＡ（ＳＡ２）を受信した側により送信されている。通常の動作では、送信側ＵＥはＳＡにより、Ｄａｔａの送信タイミング（ＴＡ）を受信側ＵＥに通知するが、上記の例３の動作では、送信タイミングの通知がなされない。すなわち、受信側ＵＥは、フィードバックとして送信するＤａｔａの送信タイミングを送信側ＵＥに通知できない。

【0058】

上記の点に鑑みて、本実施の形態では、受信側ＵＥは、送信側ＵＥから送信されるＳＡ（図７でのＳＡ２）で通知される送信タイミング（ＴＡ）を、フィーバック信号として送信するＤａｔａの送信タイミングとして用いることとしている。

【0059】

このような方法を用いることで、送信側ＵＥにとって、フィードバック信号受信時のタイミング不確定性を最小限にできる。また、送信側ＵＥは、フィードバックを送信する受信側ＵＥの送信タイミングを知っているか否かをＴＡによって受信側ＵＥに通知することとしてもよい。

【0060】

また、受信側ＵＥは、送信側ＵＥから通知されたＴＡ用のビットを用いずに、受信側ＵＥ自身のタイミング情報に基づいてＤａｔａ（フィードバック信号）を送信してもよい。

【0061】

ここでのタイミング情報とは、例えば自身のＵＬ送信タイミング、ＤＬ受信タイミング等である。ＲＲＣの状態に応じて、例えばＲＲＣ ＣＯＮＮＥＣＴＥＤ状態ではＵＬタイミングを用い、ＩＤＬＥ状態ではＤＬタイミングを用いることとしてもよい。このように、ＴＡを用いずにＤａｔａ（フィードバック信号）を送信するようにすることで、ＴＡ通知用のオーバーヘッドを削減できる。また、該当ビットを他のフィードバック関連情報の通知に用いることができる。

【0062】

ここで、通常のＳＡ送信において、ＩＤとしてＤａｔａ受信側のＩＤを含めることが考えられる。この場合、例３のＳＡ２のケースでは、Ｄａｔａ（フィードバック信号）は、ＳＡ（ＳＡ２）を送信する送信側ＵＥが受信するから、ＳＡ２には、Ｌ１ ＩＤとして送信側ＵＥのＩＤが含められることが考えられる。この場合、自身のＩＤが含まれるＳＡを期待する受信側ＵＥにおいて、ＳＡ２が検出されないことが考えられる。

【0063】

このような点に鑑みて、例３のＳＡ２のような特別な用途のＳＡについては、通常のＳＡと異なるフォーマットを用いたり、特別な用途であることを示す情報（Ｃｏｎｔｅｎｔｓ）を含めることとし、受信側ＵＥは、特別なＳＡのフォーマットやＣｏｎｔｅｎｔｓを検知したら、Ｌ１ ＩＤにかかわらずＳＡ（ＳＡ２）を受信し、Ｄａｔａ（フィードバック信号）送信の必要有無を判定することとしてもよい。あるいは、Ｌ１ ＩＤとして、受信側ＵＥが検出するＵｎｉｃａｓｔ ＩＤを用いることとしてもよい。

【0064】

なお、これまでに説明したリソース構成例１、２、３を適宜切り替えて適用することとしてよい。切り替える方法としては、基地局ｅＮＢからＵＥに対して、上位レイヤシグナリングにより、どの方法を用いるかを指示することとしてもよいし、ＵＥが自律的に、カバレッジ内／カバレッジ外等のカバレッジ状態、もしくは、Ｄ２Ｄのモード（Ｍｏｄｅ１ｌ、Ｍｏｄｅ２）に応じて方法を切り替えることとしてもよい。このように切り替え可能なようにシステムを構成することで、リソース割り当ての自由度・確実性に応じたフィードバックの効率化を図ることができる。

【0065】

＜フィードバックリソースの割り当ての例＞
前述した、リソース構成例１、リソース構成例２、リソース構成例３の例１、例２等において適用できる、本実施の形態におけるフィードバックリソースの割り当て方法の例を図８を参照して説明する。

【0066】

本例では、ＳＡを送信（受信側ＵＥから見れば受信）するリソースとフィードバック信号（フィードバック情報を送るＤａｔａのためのＳＡを含む）送信用のリソースとの対応関係を定義しておき、送信側ＵＥからのＳＡ送信リソースにより、受信側ＵＥに対して暗黙的にフィードバック送信リソースを通知する。すなわち、受信側ＵＥは、送信側から受信したＳＡの受信リソースに基づいて、フィードバック送信リソースを決定し、フィードバック信号の送信に使用することができる。

【0067】

例えば、図８（ａ）に示すように、あるサブフレームで送信されたＳＡに対応するフィードバック信号が、当該サブフレームと同一番号のサブフレームで送信されるようにリソースが定められることとしてよい。また、例えば、サブフレームＸでＳＡ−Ａ、ＳＡ−Ｂ、ＳＡ−Ｃが１つ又は複数のＵＥから受信側ＵＥに対して送信された場合において、受信側ＵＥは、これらのＳＡに対応する各フィードバック信号をサブフレームＹで送信するようにしてもよい。すなわち、同じサブフレームのＳＡ送信に対して同じサブフレームでフィードバック送信が行われてもよい。このように、送信側ＵＥにとって、フィードバック信号を受信するサブフレームが限定されることにより、Ｈａｌｆ ｄｕｐｌｅｘの影響を回避できる。

【0068】

また、送信側ＵＥにおいて、ＳＡの送信リソース決定のために使用したパラメータ（例：ＳＡリソースインデクスとしてのパラメータＳ）をＳＡに含めて受信側ＵＥに送信し、受信側ＵＥが、当該パラメータを使用してフィードバック信号送信用のリソースを決定することとしてもよい。

【0069】

また、ＳＡ送信リソース毎に複数のフィードバック送信リソース候補を定義しておき、受信側ＵＥは、ＳＡに含まれるＣｏｎｔｅｎｔｓ（例：ＡＲＩ：ＡＣＫ／ＮＡＣＫ ｒｅｓｏｕｒｃｅ ｉｎｄｉｃａｔｏｒ）によって実際に利用するリソースを切り替えることとしてもよい。図８（ｂ）の例では、ＣＤＭ（コード多重）を行う例を示している。図８（ｂ）の例では、ＳＡ送信リソース毎に２つのフィードバック送信リソース候補が定められ、受信側ＵＥは、ＳＡのＣｏｎｔｅｎｔｓに応じて、１つのリソースを選択してフィードバック信号の送信を行う。

【0070】

上記のような方法を採用することで、Ｈａｌｆ ｄｕｐｌｅｘの影響を回避できる。また、Ｄａｔａとフィードバックをダイナミックに対応付けることができ、フィードバック用リソースのオーバーヘッド削減，フィードバックリソース衝突のランダマイズを実現できる。

【0071】

なお、上述したフィードバック送信リソース候補は、ＳＡの送信リソースに基づいて決定されるものでもよいし、基地局ｅＮＢから上位レイヤシグナリングにより決定されるものであってもよい。また、ＳＡのリソースとフィードバック信号リソースとの対応関係の情報については、各ＵＥにおいて予め設定されていてもよいし、基地局ｅＮＢから各ＵＥに上位レイヤシグナリングで通知することとしてもよいし、ＵＥ間のシグナリングで共有を図ることとしてもよい。

【0072】

また、受信側ＵＥは、送信側ＵＥから送信されるＤａｔａの送信サブフレーム数に応じてフィードバック信号送信のリソースサイズを決定してもよい。

【0073】

例えば、受信側ＵＥは、Ｄａｔａスケジューリング期間内（例：ＳＡリソースプールの終わりから次のＳＡリソースプールの開始まで）で利用可能なＤ２ＤのＤａｔａサブフレーム数に基づいてフィードバック信号のリソースサイズを決定することができる。また受信側ＵＥは、ＳＡに含まれるＴ−ＲＰＴ等により通知された実際にＤａｔａ送信に使用されるサブフレーム数に基づきフィードバック信号のリソースサイズを決定することとしてもよい。具体的な決定方法としては、例えば、上記Ｄａｔａのサブフレーム数が大きいほど、フィードバック信号のリソースサイズも大きくなるような関数を定め、当該関数を用いてフィードバック信号のリソースサイズを決定することができる。このようにしてフィードバック信号のリソースサイズを決定することにより、送信データ量に応じて適切なフィードバック量を選択することができる。

【0074】

また、再送遅延を小さくするために、Ｒｅｌ−１２よりも小さいＳＡ周期・ＳＡリソースプールサブフレーム数を設定できるようにしてもよい。これにより、例えば、ＳＡリソースプールの最終サブフレームよりも前にＤａｔａ送信可能なサブフレームが開始される場合があると考えられるが、この場合に、当該ＳＡリソースプールにおけるＳＡによるスケジューリングは次のＳＡ周期のＤａｔａをスケジュールするとしてもよい。

【0075】

＜フィードバック信号構成＞
前述した「フィードバック用のリソース構成例１」で説明したように、新たにフィードバック用のチャネル（リソース）を規定する場合において、当該チャネルにおける信号構成としては、ＳＡと同様のＰＵＳＣＨベースの構成としてもよいし、ＰＵＣＣＨフォーマットを用いてもよい。

【0076】

図９に、ＰＵＣＣＨフォーマット１に基づく信号構成の例（設計例１〜３）を示し、図１０に、ＰＵＣＣＨフォーマット３に基づく信号構成の例（設計例１〜４）を示す。なお、図９、図１０に示す信号構成は一例であり、これらに限定されるわけではない。図９、図１０において、Ｄａｔａ ｓｙｍｂｏｌにフィードバック情報がマッピングされる。

【0077】

Ｄ２ＤのＰＵＣＣＨフォーマットにおいては、１サブフレームの最終シンボルがパンクチャされる（無送信となる）。図９の設計例１、２、図１０の設計例１、２、３においては、パンクチャされるサブフレーム最終シンボルを考慮し、スロット間で異なるシンボルマッピングを用いている。このように、スロット間で異なる構成にした場合、第１スロットのシンボルを最大限利用することが可能となる。

【0078】

また、図９の設計例３、図１０の設計例４においては、第１スロットの最終シンボルもパンクチャすることで、スロット間で同一のシンボルマッピングを用いている。このように、スロット間で共通の構成にした場合、受信複雑性（Ｃｏｍｐｌｅｘｉｔｙ）を削減することができる。

【0079】

なお、図９、図１０の例では、スロット間で周波数ホッピングを行っているが、スロット間で周波数ホッピングを行わず、２スロット（１サブフレーム）を同一周波数リソースで送信することとしてもよい。

【0080】

本実施の形態では、複数フィードバック信号を同一時間・周波数リソースにおいてコード多重（ＣＤＭ）することが可能であり、これにより時間・周波数リソースを有効活用できる。そのために、本実施の形態では、図９、図１０において「ＲＳ ｓｙｍｂｏｌ」として示されるＤＭ−ＲＳを直交させることとしてもよい。

【0081】

図１１に、ＰＵＣＣＨベースのフィードバック信号におけるＤＭ−ＲＳの構成例を示す。図１１のＡの枠内に示される、ＤＭ−ＲＳベース系列（ＤＭ−ＲＳ ｂａｓｅ ｓｅｑｕｅｎｃｅ）生成に用いられるＧｒｏｕｐ ｈｏｐｐｉｎｇ、ｓｅｑｕｅｎｃｅ ｈｏｐｐｉｎｇ、ｄｅｌｔａ ｓｈｉｆｔについては、固定にしたり、あるいは、Ｄａｔａと同一にすることとしてもよい。

【0082】

また、例えば、系列生成に用いられるＣｅｌｌ ＩＤのフィールドに固定値、もしくは同一リソースに多重されるフィードバック信号間で共通となる値を用いることで、ＤＭ−ＲＳのＣＳ／ＯＣＣ（Ｃｙｃｌｉｃ ｓｈｉｆｔ／Ｏｒｔｈｏｇｏｎａｌ Ｃｏｖｅｒ Ｃｏｄｅ）（図１１のＢ）による直交多重を実現できる。

【0083】

また、フィードバック信号がコード多重される場合、ＣＳ／ＯＣＣにより、異なるＳＣＩに対応する、同一時間・周波数リソースに多重されたフィードバック信号間でのＤＭ−ＲＳ直交化を実現できる。

【0084】

ただし、図１１のＢに示す最初の例のように、ＣＳ／ＯＣＣをＬ１ ＩＤに基づいて決定した場合、フィードバック信号間で衝突が生じる可能性があるが、ＣＳ／ＯＣＣをＨＡＲＱに関連したＩＤ／Ｉｎｄｅｘ、及び／又は、ＳＣＩリソースインデックスに基づいて決定した場合、衝突を完全に回避することも可能である。なお、当該ＳＣＩリソースインデックスにおけるＳＣＩとは、送信側ＵＥから送信された、フィードバック対象となるＤａｔａのリソース割り当てのためのＳＣＩである。

【0085】

＜フィードバック内容＞
本実施の形態において、受信側ＵＥから送信側ＵＥに送信するフィードバック信号の内容としては、ＡＣＫ／ＮＡＣＫ、ＣＳＩがある。なお、これらは例であり、他の情報をフィードバック信号として送信することとしてもよい。以下、ＡＣＫ／ＮＡＣＫ、ＣＳＩの具体的送信方法の例を説明する。また、以下で説明する例は、特に断らない限り、全てのフィードバック送信方法（リソース構成例１、２、３等）に適用可能である。

【0086】

＜フィードバック内容例１：ＡＣＫ／ＮＡＣＫ＞
まず、ＡＣＫ／ＮＡＣＫについて説明する。本実施の形態において、受信側ＵＥは、送信側ＵＥから受信するＭＡＣ ＰＤＵ毎にＡＣＫ／ＮＡＣＫを判定し、ＡＣＫ／ＮＡＣＫをフィードバック信号として送信側ＵＥに通知する。ただし、後述するように、受信側ＵＥは、ＡＣＫ／ＮＡＣＫをグループ化して、バンドリング（Ｂｕｎｄｌｉｎｇ）し、より少ないリソースでＡＣＫ／ＮＡＣＫをフィードバックしてもよい。

【0087】

また、受信側ＵＥから送信側ＵＥに通知するフィードバック信号の中に、フィードバックするＭＡＣ ＰＤＵ数、及び／又は、ＡＣＫ／ＮＡＣＫ数を含めて通知してもよい。これにより、送信側ＵＥ（フィードバック受信側ＵＥ）は、フィードバックとして受信するべきＭＡＣ ＰＤＵ数、及び／又は、ＡＣＫ／ＮＡＣＫ数を把握できるため、フィードバックの受信誤りを回避できる。また、受信側ＵＥから送信側ＵＥに通知するフィードバック信号の中に、確認用ビット列を含めてもよい。当該確認用ビット列は、フィードバックとして送信するＭＡＣ ＰＤＵ（の列）との対応付けをとることが可能な列であり、例えば、ＳＡにおけるＴ−ＲＰＴ等から生成される。この方法によっても、フィードバックの受信誤りを回避できる。

【0088】

＜フィードバック内容例２：ＣＳＩ＞
受信側ＵＥは、フィードバック信号としてＣＳＩを送信することができる。ＣＳＩの内容としては、例えば、ＣＱＩ（受信データの受信品質を示すＣｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ）、ＲＩ（ランクインデックス）等がある。受信側ＵＥは、例えば、ＣＳＩを受信ＤＭ−ＲＳ（又は新たなＲＳ）を用いて算出する。

【0089】

なお、Ｄ２Ｄでは送信電力、Ｒｅｐｅｔｉｔｉｏｎ回数等を変更し得るため、従来のＣＱＩのダイナミックレンジよりも広いダイナミックレンジのＬｉｎｋ ａｄａｐｔａｔｉｏｎを行うことが可能である。従って、より多くの数値を取り得る新たなＣＱＩをＤ２Ｄ用に定義してもよい。

【0090】

これにより、既存のＣＱＩよりも広い範囲の受信品質（ＳＩＮＲ）のフィードバックを行うことができるが、ＣＳＩフィードバックのためのオーバーヘッドが大きくなることが考えられる。

【0091】

そこで、本実施の形態における受信側ＵＥは、ＣＳＩフィードバックとして、送信側ＵＥから送信されたＤａｔａに対する相対的な（ラフな）受信品質情報を報告することができる。

【0092】

ラフな受信品質とは、例えば、受信ＳＩＮＲのマージン（所要のＳＩＮＲとの差）、Ｄａｔａが何回の合成受信で受信できたか等であるが、これらに限られず、情報量を小さくした受信品質の情報であればどのような情報でもよい。また、ラフな受信品質を送信する例として、送信電力制御コマンドにより暗黙的に受信品質を通知してもよい。

【0093】

更に、ラフな受信品質を送信する例として、Ｄａｔａ Ｒｅｐｅｔｉｔｉｏｎ送信毎（初回送信含む）にＡＣＫ／ＮＡＣＫを通知してもよい。ＡＣＫ／ＮＡＣＫの受信側（送信側ＵＥ）は、複数Ｄａｔａ送信のうちのＡＣＫ／ＮＡＣＫの割合により、受信品質をラフに推定することができる。

【0094】

上記のようにＣＳＩをフィードバック信号で送信することで、ＡＣＫ／ＮＡＣＫのみに基づくＬｉｎｋ ａｄａｐｔａｔｉｏｎに比べ、ブロック誤りの発生確率を低く抑えたまま収束性の高いＬｉｎｋ ａｄａｐｔａｔｉｏｎを実現できる。また、既存のＣＱＩの報告よりも広いダイナミックレンジをサポートすることが可能である。

【0095】

ここで、受信側ＵＥは、上記の相対的な（ラフな）ＣＳＩをＡＣＫ／ＮＡＣＫとの同時報告でのみ用い、送信側ＵＥからＣＳＩを要求された場合に、別フォーマットで絶対的なＣＳＩを報告することとしてもよい。このように、絶対的なＣＳＩの報告も可能とすることで、Ｌｉｎｋ ａｄａｐｔａｔｉｏｎの収束を早めることができる。

【0096】

＜バンドリング（Ｂｕｎｄｌｉｎｇ）について＞
前述したように、受信側ＵＥは、送信側ＵＥから受信するＤａｔａの各ＭＡＣ ＰＤＵに対するＡＣＫ／ＮＡＣＫをバンドリングして送信側ＵＥに通知することができる。バンドリング自体には種々の手法があるが、例えば、ＡＣＫを送らずに、ＮＡＣＫのみを送信するバンドリング手法がある。

【0097】

受信側ＵＥは常にバンドリングを適用してもよいし、送信側ＵＥからのＳＡで通知されたＤａｔａ送信サブフレーム数が所定値以上の場合にバンドリングを適用することとしてもよい。当該所定値とは、Ｄａｔａ送信サブフレーム数が当該所定値を超える場合に、フィードバックリソース量が、フィードバック信号の送信に使用できるリソース量を超えることになる値である。

【0098】

図１２Ａ〜１２Ｃを参照してバンドリングの一例を示す。図１２Ａは、参考としてバンドリングをしない場合を示している。図１２Ｂは、ＡＣＫ／ＮＡＣＫ列が（ほぼ）均等にバンドリングされるよう、連続する数個（図１２Ｂでは２個の例を示す）のＡＣＫ／ＮＡＣＫをバンドリングする例である。図１２Ｃは、末尾ＡＣＫ／ＮＡＣＫ列に対してバンドリングを適用する例である。

【0099】

このようにバンドリングを適用することで、ＡＣＫ／ＮＡＣＫフィードバックのオーバーヘッドを削減することができる。Ｄ２Ｄ Ｄａｔａは低ＢＬＥＲでの運用が想定されるため、バンドリングによるスループット劣化は限定的であると考えられる。

【0100】

＜ＡＣＫ／ＮＡＣＫ、ＣＳＩマッピング例＞
次に、本実施の形態におけるフィードバック情報のマッピング例を説明する。フィードバック情報のマッピングはＢＰＳＫ等の信号点配置で行ってもよいし、コード多重（ＣＤＭ）して系列で通知してもよいし、フィードバック用リソース（チャネル）を複数定義してチャネル選択により通知してもよい。

【0101】

上記のチャネル選択の対象となるリソースとしては、時間・周波数リソースでもよいし、時間・周波数リソースとは別に、もしくは時間・周波数リソースに加えてＣｙｃｌｉｃ ｓｈｉｆｔ、ＯＣＣ系列を用いてもよい。

【0102】

例えば、チャネル１（チャネル１として定義したリソース）送信をＮＡＣＫ送信に対応付け、チャネル２（チャネル２として定義したリソース）送信をＡＣＫ送信に対応付け、各チャネルで受信品質情報（例：ラフなＣＳＩ）を送信することとしてよい。

【0103】

この場合の例を図１３に示す。図１３は、受信品質情報としてＳＩＮＲマージンを送信する例を示している。また、ＡＣＫ／ＮＡＣＫそれぞれに対して非対称な品質情報のマッピングを行なっている。ここでは、ＡＣＫ／ＮＡＣＫと受信品質を１つずつ多重しているが、ＡＣＫ／ＮＡＣＫを複数フィードバックする場合において、平均化した受信品質情報をＡＣＫ／ＮＡＣＫに多重してもよい。また、ＡＣＫ／ＮＡＣＫと受信品質情報を合成せずに、ＡＣＫ／ＮＡＣＫのみを送信することとしてもよい。

【0104】

上記のようにチャネル選択（リソース選択）でＡＣＫ／ＮＡＣＫを送信することで、例えば、Ｇｒｏｕｐ−ｃａｓｔにおいても、送信側ＵＥ（フィードバック受信側ＵＥ）は、複数の受信側ＵＥからのＡＣＫ／ＮＡＣＫが多重された場合でも、各ＵＥのＡＣＫ／ＮＡＣＫを電力判定で検出することができる。

【0105】

また、ＮＡＣＫを送信するＵＥはＳＩＮＲが低く、チャネル推定精度が悪いため、図１３に示すように非対称な品質情報のマッピングを行うことにより、ＮＡＣＫ送信時におけるラフな品質情報の報告をより確実に行うことができる。

【0106】

＜ＳＣＩを用いたフィードバックについて＞
ここでは特に、リソース構成例２で説明したように、フィードバックＳＣＩを使用する場合の詳細例を説明する。

【0107】

受信側ＵＥがフィードバック信号送信をフィードバックＳＣＩを使用して行う場合において、既存のＳＡと異なる新たなＳＣＩペイロード長を規定してフィードバック信号送信を行うこととしてよい。これにより、従来のＳＣＩ（ＳＡ）とは異なるペイロード長をサポートでき、効率的なフィードバックが可能となる。

【0108】

また、受信側ＵＥがフィードバック信号送信をフィードバックＳＣＩを使用して行う場合において、既存のＳＡと同一のペイロード長でフィードバックを行うこととしてもよい。この場合、受信側ＵＥ（フィードバック送信側ＵＥ）は、ＳＣＩ中の一部のビットにより、既存ＳＣＩ（ＳＡ）とフィードバックＳＣＩを区別する。一例として、フィードバックＳＣＩにおいて、一部のビットを所定の設定値（例：従来のＤ２Ｄで用いられない設定値）に設定する。送信側ＵＥ（フィードバック受信側ＵＥ）は、当該ビットの値により、フィードバックＳＣＩを識別できる。

【0109】

例えば、６４ＱＡＭはＤ２Ｄでは用いられないため、ＳＣＩ中のＭＣＳとして６４ＱＡＭが通知された場合はフィードバックＳＣＩとみなすこととする。また、ＣＲＣをフィードバックＳＣＩ用の所定のビット列でマスクし、送信側ＵＥ（フィードバック受信側）において所定のビット列でマスク解除ができたらフィードバックＳＣＩであると判定してもよい。また、フィードバックＳＣＩをＲＳ信号フォーマットにより識別する（ＤＭＲＳ ｃｙｃｌｉｃ ｓｈｉｆｔ等）こととしてもよい。このように、既存のＳＣＩと同一のペイロード長のフィードバックＳＣＩを用いることで、ブラインド検出数を増加させずにＳＣＩがフィードバック用か否かを識別することができる。

【0110】

＜スケジューリングＳＣＩについて＞
ここでは、ＳＡに相当するスケジューリングＳＣＩの詳細例について説明する。図１４に例示するように、フィードバックに起因する再送等をサポートするスケジューリングＳＣＩにおいては、再送するリソースと再送の対象とするＤａｔａとの関連付けを行うことが望ましい。以下、これを行うための仕組みを含む詳細例を説明する。

【0111】

本実施の形態では、一例として、既存のＳＡのフォーマットとは異なる新たなＳＣＩフォーマットを定義し、送信側ＵＥから受信側ＵＥに対して、以下の「」内に記載したＣｏｎｔｅｎｔｓの情報全部、又はこれらの情報のうちのいずれか複数の組み合わせを通知可能としている。また、以下に示されない情報を送信することとしてもよい。

【0112】

Ｃｏｎｔｅｎｔｓ：「既存のＳＣＩコンテンツ＋再送インデックス・識別子、ＮＤＩ、Ｄａｔａ Ｒｅｐｅｔｉｔｉｏｎ数、ＣＳＩの要求、フィードバック送信リソースＩｎｄｉｃａｔｏｒ、送信ＭＡＣ ＰＤＵ数、ＴＰＣコマンド」
既存のＳＣＩコンテンツは、ＴＡ、Ｌ１ ＩＤ、ＭＣＳ、周波数リソース、時間リソース（Ｔ−ＲＰＴ ｉｎｄｅｘ）等である。

【0113】

再送インデックス・識別子は、送信したいＤａｔａが再送Ｄａｔａである場合において、どのＤａｔａに対する再送かを示す情報である。この情報により、受信側ＵＥは、再送対象を同定することができる。

【0114】

ＮＤＩ（Ｎｅｗ Ｄａｔａ Ｉｎｄｉｃａｔｏｒ）は、Ｄａｔａが新規送信であることを示す情報であり、これにより、ＳＡ周期間での再送をサポートできる。Ｄａｔａ ｒｅｐｅｔｉｔｉｏｎ数は、該当ＤａｔａのＲｅｐｅｔｉｔｉｏｎの回数を示すものであり、この数を調整することで、実効スループットと受信品質のバランスを取ることができる。

【0115】

ＣＳＩの要求は、受信側ＵＥに対してＣＳＩ送信を指示する情報であり、これにより、送信側ＵＥは、ＣＳＩ情報をＡｐｅｒｉｏｄｉｃに取得することができる。また、ＣＳＩの要求を、ＣＳＩ測定に用いる信号の送信要求としてもよい。

【0116】

フィードバック送信リソースｉｎｄｉｃａｔｏｒ（例：ＡＲＩ：ＡＣＫ／ＮＡＣＫ ｒｅｓｏｕｒｃｅ ｉｎｄｉｃａｔｏｒ）は、受信側ＵＥに対してフィードバック送信リソースを割り当てる（指定する）情報であり、これにより、フィードバック送信リソースの衝突を回避することができる。

【0117】

なお、送信側ＵＥから受信側ＵＥへのフィードバックリソース割り当てに関しては、一例として、Ｃｌｕｓｔｅｒｅｄ ＰＵＳＣＨ送信もしくは全帯域送信を通知してもよい。

【0118】

送信ＭＡＣ ＰＤＵ数は、送信側ＵＥがＤａｔａ送信に使用するＭＡＣ ＰＤＵ数であり、これにより、受信側ＵＥは、Ｄａｔａを送信可能なＭＡＣ ＰＤＵ数が当該送信ＭＡＣ ＰＤＵ数よりも大きい場合、不要な受信試行を回避することができる。また、これにより、受信側ＵＥは、送信Ｄａｔａがなく未送信のサブフレームとＤａｔａ受信誤りのサブフレームとを識別できる。更に、後述する再送・新規送信の混合スケジューリングを実現できる。送信ＭＡＣ ＰＤＵ数をスケジューリングＳＣＩで通知しない場合、送信側ＵＥは、特別なフォーマットの信号を送信Ｄａｔａがないサブフレームで送信してもよい。これにより、受信側ＵＥは、送信Ｄａｔａがないことを判別できる。

【0119】

ＴＰＣコマンドは、受信側ＵＥ（フィードバック送信側）の送信電力を調整するためのコマンドであり、これにより、Ｕｎｉｃａｓｔフィードバックの送信電力を調整することで受信品質と与干渉レベルのバランスを取ることができる。

【0120】

一例として、新たなスケジューリングＳＣＩのフォーマットとして、２ＰＲＢを用いて送信してもよい。これは既存のＳＣＩ（ＳＡ）よりも大きな値である。これにより、ＳＣＩペイロード長が長くなっても、品質を担保することができる。また、周期的に到来するＳＡリソースプール毎に、送信可能なＳＣＩフォーマットを限定してもよい。例えば、新たなスケジューリングＳＣＩと、既存のＳＡを異なる周期で送信することが考えられる。これにより、ブラインド検出数を抑制したり、ＳＣＩフォーマット間の衝突を避けることができる。

【0121】

なお、Ｄａｔａ再送用のスケジューリングＳＣＩを、新規送信用スケジューリングＳＣＩとは別に定義し、送信側ＵＥが当該定義に従ったＳＣＩ送信を行うこととしてもよい。この場合、ＮＡＣＫを送信した受信側ＵＥは、ブラインド検出数の範囲内で再送用スケジューリングＳＣＩを優先的に検出することができ、ブラインド検出数の削減、ＳＣＩペイロード長の削減に効果がある。

【0122】

＜スケジューリングＳＣＩについて：再送インデックスの詳細例＞
次に、前述した再送インデックスの詳細例を説明する。送信側ＵＥは、例えば、再送インデックスとして、再送の対象となるＤａｔａのスケジューリングＳＣＩのインデックス、又は当該Ｄａｔａリソースインデックスを通知する。

【0123】

また、例えば、送信側ＵＥは、再送の対象となるＤａｔａのスケジューリングＳＣＩの送信リソース決定に用いたパラメータ全部、又は、その一部を通知したり、当該スケジューリングＳＣＩで受信側ＵＥに通知した識別子を通知することとしてよい。もしくは、上記スケジューリングＳＣＩの送信リソースインデックス、Ｄａｔａリソース割り当て情報、Ｔ−ＲＰＴ ｉｎｄｅｘのいずれか又は全部を通知することとしてもよい。更に、送信側ＵＥのＩＤを通知してもよい。上記のような情報を通知することで、受信側ＵＥは、複数ＵＥからのＤａｔａを受信している場合に送信元を識別して合成することが可能となる。

【0124】

また、送信側ＵＥは、再送インデックスとして再送対象となるＤａｔａのＳＡ周期（どの時点（周期単位の時点）でＤａｔａを送信したか）を通知し、当該時点から、所定の回数（Ｎ）の周期前までの再送を可能にしてもよい。つまり、送信側ＵＥは、最大で、Ｎ周期分の再送を行い、受信側ＵＥも最大でＮ周期分の再送を期待する。

【0125】

また、再送インデックスを送信せず、初回スケジューリングの送信リソースインデックスに基づいたリソースを用いて再送を行なってもよい。例えば、再送は初回送信と同一のリソースを用いて行なったり、ＳＡ周期間でＤｅｔｅｒｍｉｎｉｓｔｉｃなホッピングを行なって送信リソースを決定してもよい。つまり、初回送信Ｄａｔａのリソースから、再送Ｄａｔａのリソースを決定できるように、ホッピングを定義し、送信側ＵＥと受信側ＵＥは、当該ホッピングのルールに従って、再送Ｄａｔａの送受信を行う。このように、再送インデックスを使用しないことで、シグナリングオーバーヘッドを削減できる。

【0126】

＜スケジューリングＳＣＩについて：選択的再送の例＞
送信側ＵＥは、再送インデックスとして、再送されるＭＡＣ ＰＤＵ等のインデックスを受信側ＵＥに通知し、選択的なサブフレーム（もしくはＭＡＣ ＰＤＵ）のＤａｔａ再送を行なってもよい。具体的には、例えば、Ｕｎｉｃａｓｔの場合において、送信側ＵＥは、ＮＡＣＫを受信した場合に、当該ＮＡＣＫに対応する送信ＭＡＣ ＰＤＵのインデックスを含むスケジューリングＳＣＩを送信し、当該送信ＭＡＣ ＰＤＵに該当するＤａｔａを再送する。また、例えば、送信側ＵＥは、ＮＡＣＫを受信した場合に、当該ＮＡＣＫに対応する送信サブフレームのインデックスを含むスケジューリングＳＣＩを送信し、当該送信サブフレームに該当するＤａｔａを再送する。受信側ＵＥでは、当該インデックスにより、Ｄａｔａのどの部分の再送であるかを識別でき、Ｄａｔａを組み立てることができる。このような構成により、初回送信よりも少ないサブフレームで再送を実現できる。

【0127】

また、フィードバック受信誤りを防止するため、送信側ＵＥは、ＮＡＣＫ（またはＡＣＫ）が通知されたＭＡＣ ＰＤＵ数、もしくはＭＡＣ ＰＤＵ数に対応する確認用ビット列をスケジューリングＳＣＩで受信側ＵＥに通知し、受信側ＵＥは、当該数に対応するフィードバックを送信することとしてもよい。

【0128】

＜スケジューリングＳＣＩについて：再送と新規送信との混合スケジューリング＞
本実施の形態では、送信側ＵＥが受信側ＵＥに対して、再送と新規送信との混合スケジューリングを行なってもよい。

【0129】

例えば、送信側ＵＥは、スケジューリングＳＣＩで再送・新規送信のＭＡＣ ＰＤＵ数を受信側ＵＥに通知することで再送と新規送信との混合スケジューリングを行う。一例として、送信側ＵＥは、再送対象Ｄａｔａと新規送信Ｄａｔａがある場合において、再送対象のＭＡＣ ＰＤＵ数が、送信できるＭＡＣ ＰＤＵ数よりも小さい場合に、再送と新規送信のそれぞれのスケジューリング情報と、新規送信についてのＮＤＩをスケジューリングＳＣＩで受信側ＵＥに送信し、再送ＭＡＣ ＰＤＵと新規ＭＡＣ ＰＤＵを時間多重して送信する。この場合の例は、図１５において例１で示されている。この場合は、再送の後、新規ＭＡＣ ＰＤＵを送信することとしている。

【0130】

また、別の例（図１５の例２）として、送信側ＵＥは、再送用のスケジューリングＳＣＩと、新規送信用のスケジューリングＳＣＩを送信することで、混合スケジューリングを行なってもよい。より詳細には、例えば、再送用のスケジューリングＳＣＩと、新規送信用のスケジューリングＳＣＩとの間で、「ＴＡ、Ｌ１ ＩＤ、Ｔ−ＲＰＴ ｉｎｄｅｘ、周波数リソース」を同一とし、ＮＤＩを異ならせて、再送ＭＡＣ ＰＤＵの後に新規ＭＡＣ ＰＤＵを送信する。

【0131】

なお、フィードバックは再送・新規ＭＡＣ ＰＤＵに関わらず共通したフィードバック（図１５の例Ｘ）でもよいし、再送・新規について独立にフィードバックしてもよい（図１５の例Ｙ）。

【0132】

＜第１の実施の形態の装置構成：ユーザ装置＞
図１６に、本実施の形態に係るユーザ装置ＵＥの機能構成図を示す。図１６に示すＵＥは、第１の実施の形態で説明した送信側ＵＥと受信側ＵＥのどちらにでもなり得るＵＥである。図１６に示すように、ユーザ装置ＵＥは、信号送信部１０１、信号受信部１０２、Ｄ２Ｄ通信機能部１０３、スケジューリングＳＣＩ送信制御部１０４、フィードバック制御部１０５、再送制御部１０６を含む。なお、図１６は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図１６に示す機能構成は一例に過ぎない。本実施の形態に係るＵＥの動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

【0133】

信号送信部１０１は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部１０１は、Ｄ２Ｄ通信の送信機能とセルラー通信の送信機能を有する。

【0134】

信号受信部１０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。信号受信部１０２は、Ｄ２Ｄ通信の受信機能とセルラー通信の受信機能を有する。

【0135】

Ｄ２Ｄ通信機能部１０３は、Ｄ２Ｄアプリケーションの機能を含み、Ｄｉｓｃｏｖｅｒｙ信号送受信制御、ＳＡ／Ｄａｔａ送受信制御等を実行する。スケジューリングＳＣＩ送信制御部１０４は、第１の実施の形態で説明したスケジューリングＳＣＩ（ＳＡ）の送信のための処理を実行する。例として、スケジューリングＳＣＩ送信制御部１０４は、スケジューリングＳＣＩの信号を作成し、信号送信部１０１に対するスケジューリングＳＣＩのための信号マッピング等を行う。

【0136】

フィードバック制御部１０５は、第１の実施の形態で説明したフィードバックの送信のための処理（スケジューリングＳＣＩ送受信を含む）を実行する。また、再送制御部１０６は、第１の実施の形態で説明した再送のための処理を実行する。

【0137】

（第２の実施の形態）
次に、第２の実施の形態について説明する。前述したように、第２の実施の形態は、Ｍｏｄｅ１リソース割り当て時の再送の技術に関するものである。詳細な内容は以下のとおりである。なお、第２の実施の形態は第１の実施の形態を前提とするが、第２の実施の形態を単独で実施することも可能である。

【0138】

ＡＣＫ／ＮＡＣＫは受信側ＵＥから送信側ＵＥに送信されるが、Ｍｏｄｅ１リソース割り当てにおいては、Ｄ２Ｄ送信リソース割り当ては基地局ｅＮＢからＵＥに対するシグナリングで行われる。従って、送信側ＵＥがＮＡＣＫを受信したとしても、再送リソースが送信側ＵＥに基地局ｅＮＢからすぐに割り当てられるとは限らないため、リソース割り当てを待つことにより再送遅延が生じることが考えられる。

【0139】

そこで、本実施の形態では、以下のような処理手順を導入することで、上記の課題を解決している。以下、処理手順例として、処理手順例２−１〜２−３を説明する。

【0140】

＜処理手順例２−１＞
図１７を参照して処理手順例２−１を説明する。ステップ１０１において、送信側ＵＥは、基地局ｅＮＢに対してダイナミックなＤ２Ｄスケジューリング要求を行う。当該Ｄ２Ｄスケジューリング要求は、再送のための要求であってもよいし、新規送信のための要求であってもよい。ここでは、例えば、Ｌ１（ＰＵＣＣＨなど）シグナリングでスケジューリング要求を行うことで、新規送信・再送のためにダイナミックな送信リソースの要求を実現できる。また、Ｄ２Ｄスケジューリング要求の中に、割り当てを要求する対象となるＳＡリソースプールインデックス、再送対象Ｄａｔａのインデックス等を含めてもよい。

【0141】

Ｄ２Ｄスケジューリング要求を受信した基地局ｅＮＢは、リソース割り当てを行う（ステップ１０２）。そして、送信側ＵＥは、割り当てられたリソースを用いて、再送（もしくは新規送信）を実施する（ステップ１０３）。

【0142】

処理手順例２−１において、例えばスケジューリング要求の送信（ステップ１０１）を再送のためだけに限定することでオーバーヘッドを削減できる。

【0143】

＜処理手順例２−２＞
図１８を参照して処理手順例２−２を説明する。送信側ＵＥがＤａｔａを送信し、受信側ＵＥからＮＡＣＫを受信したとする（ステップ２０１、２０２）。送信側ＵＥは、当該ＮＡＣＫを基地局ｅＮＢに報告する（ステップ２０３）。なお、ＡＣＫを受信した場合はＡＣＫを報告してもよい。例えば、Ｌ１（ＰＵＣＣＨなど）でＮＡＣＫを報告することで、ダイナミックな送信リソースの割り当てが実現できる。

【0144】

ＮＡＣＫを受信した基地局ｅＮＢは、再送用リソース割り当てが必要であると判断し、再送用リソース割り当てを送信側ＵＥに対して実施して（ステップ２０４）、送信側ＵＥは、当該リソースを使用することで再送を実施する（ステップ２０５）。

【0145】

＜処理手順例２−３＞
図１９を参照して処理手順例２−３を説明する。処理手順例２−３では、受信側ＵＥから送信されたＮＡＣＫが、基地局ｅＮＢにより受信される（ステップ３０２）。送信側ＵＥは当該ＮＡＣＫを受信せず、基地局ｅＮＢに対してＮＡＣＫを送信しない。送信側ＵＥはステップ３０３でのリソース割り当てに基づいて再送Ｄａｔａを判定し、ステップ３０４で再送を行う。なお、送信側ＵＥがステップ３０２のＮＡＣＫを受信し、当該ＮＡＣＫに基づいて再送Ｄａｔａを判定してもよい。

【0146】

処理手順例２−３では、基地局ｅＮＢがＤ２Ｄのフィードバックを受信することで再送の必要性を判断するため、Ｍｏｄｅ１でのフィードバック動作を送受双方のＵＥがＲＲＣ＿ＣＯＮＮＥＣＴＥＤもしくはカバレッジ内の場合に限定してもよい。他のケースではＭｏｄｅ２リソース割り当てによる動作とする。

【0147】

処理手順例２−３では、ＮＡＣＫ等のフィードバックの送信タイミングを、ＵＥ間でＵＬ ｔｉｍｉｎｇ（上り送信タイミング）に揃えることで、基地局ｅＮＢによるフィードバックの受信を容易にすることができる。基地局ｅＮＢにおける受信を確実にするため、送信電力をＰＵＣＣＨ又はＰＵＳＣＨと同一又はオフセット値を適用した値にしてもよい。

【0148】

＜その他の詳細例＞
第２の実施の形態において、Ｍｏｄｅ１スケジューリングで基地局ｅＮＢからＵＥに対してスケジューリング（リソース割り当て）を行う場合、ＤＣＩで以下の「」内に記載したＣｏｎｔｅｎｔｓ情報又はそのいずれか複数の組み合わせを通知してもよい。

【0149】

Ｃｏｎｔｅｎｔｓ：「既存のＭｏｄｅ１スケジューリング用ｃｏｎｔｅｎｔｓ＋再送インデックス、ＮＤＩ、Ｄａｔａ ｒｅｐｅｔｉｔｉｏｎ数、ＣＳＩ報告の要求、フィードバック送信リソースＩｎｄｉｃａｔｏｒ」
上記の情報のうち、既存のＭｏｄｅ１スケジューリング用ｃｏｎｔｅｎｔｓは、Ｈｏｐｐｉｎｇ ｆｌａｇ、Ｄａｔａ ＲＢ ａｌｌｏｃａｔｉｏｎ、Ｔ−ＲＰＴ ｉｎｄｅｘ、ＳＡ ｒｅｓｏｕｒｃｅ ｉｎｄｅｘ等である。既存のＭｏｄｅ１スケジューリング用ｃｏｎｔｅｎｔｓ以外の情報は既に説明したとおりである。送信側ＵＥは、これらの情報を含むスケジューリングＳＣＩを受信側ＵＥに送信することで再送を実施することができる。

【0150】

第２の実施の形態において、送信側ＵＥは、受信側ＵＥからフィードバック信号として受信したＣＳＩを基地局ｅＮＢに報告することとしてもよい。報告は、上位レイヤシグナリングシグナリングで実施してもよいし、Ｌ１シグナリングで実施してもよい。基地局ｅＮＢは、受信側ＵＥのＣＳＩを把握することで、送信側ＵＥの送信バッファに対して割り当てるべきリソース量を当該ＣＳＩに基づいて決定することができる。例えば、受信品質が良ければ多くのリソース量を割り当てることができる。

【0151】

また、送信側ＵＥは、受信側ＵＥとの間のＬｉｎｋ ａｄａｐｔａｔｉｏｎの結果を基地局ｅＮＢに報告してもよい。Ｌｉｎｋ ａｄａｐｔａｔｉｏｎの結果とは、例えば、ＭＣＳ、Ｒｅｐｅｔｉｔｉｏｎ数、送信電力、送信帯域幅等である。報告は、上位レイヤシグナリングで実施してもよいし、Ｌ１シグナリングで実施してもよい。基地局ｅＮＢは、受信側ＵＥとの間のＬｉｎｋ ａｄａｐｔａｔｉｏｎの結果を把握することで、送信側ＵＥの送信バッファに対して、割り当てるべきリソース量を当該Ｌｉｎｋ ａｄａｐｔａｔｉｏｎの結果に基づいて決定することができる。例えば、高速送信が可能であれば多くのリソース量を割り当てることができる。

【0152】

＜第２の実施の形態の装置構成：ユーザ装置＞
図２０に、本実施の形態に係るユーザ装置ＵＥの機能構成図を示す。図２０に示すＵＥは、第２の実施の形態で説明した送信側ＵＥと受信側ＵＥのどちらにでもなり得るＵＥである。また、図２０に示すＵＥは、第１の実施の形態で説明したＵＥの動作を実施する機能、及び／又は、第３の実施の形態で説明するＵＥの動作を実施する機能を含むこととしてもよい。

【0153】

図２０に示すように、ユーザ装置ＵＥは、信号送信部２０１、信号受信部２０２、Ｄ２Ｄ通信機能部２０３、スケジューリングＳＣＩ送信制御部２０４、フィードバック制御部２０５、再送制御部２０６を含む。なお、図２０は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図２０に示す機能構成は一例に過ぎない。本実施の形態に係るＵＥの動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

【0154】

信号送信部２０１は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部２０１は、Ｄ２Ｄ通信の送信機能とセルラー通信の送信機能を有する。

【0155】

信号受信部２０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。信号受信部２０２は、Ｄ２Ｄ通信の受信機能とセルラー通信の受信機能を有する。

【0156】

Ｄ２Ｄ通信機能部２０３は、Ｄ２Ｄアプリケーションの機能を含み、Ｄｉｓｃｏｖｅｒｙ信号送受信制御、ＳＡ／Ｄａｔａ送受信制御等を実行する。スケジューリングＳＣＩ送信制御部２０４は、第２の実施の形態で再送等に使用されるスケジューリングＳＣＩ（ＳＡ）の送信のための処理（リソース割り当て受信を含む）を実行する。例として、スケジューリングＳＣＩ送信制御部２０４は、スケジューリングＳＣＩの信号を作成し、信号送信部２０１に対するスケジューリングＳＣＩのための信号マッピング等を行う。

【0157】

フィードバック制御部２０５は、第２の実施の形態で説明したフィードバックの送信のための処理（スケジューリングＳＣＩ送受信を含む）を実行する。また、再送制御部２０６は、第２の実施の形態で説明した再送のための処理を実行する。

【0158】

＜第２の実施の形態の装置構成：基地局＞
図２１に、本実施の形態に係る基地局ｅＮＢの機能構成図を示す。なお、図２１に示すｅＮＢは、第３の実施の形態で説明するｅＮＢの動作を実施する機能を含むこととしてもよい。図２１に示すように、基地局ｅＮＢは、信号送信部３０１、信号受信部３０２、ＵＥ情報格納部３０３、Ｄ２Ｄリソース情報格納部３０４、スケジューリング部３０５を含む。なお、図２１は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した移動通信システムにおける基地局として動作するための図示しない機能も有するものである。また、図２１に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

【0159】

信号送信部３０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部３０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。

【0160】

ＵＥ情報格納部３０３には、各ＵＥから受信するＵＥ能力の情報が格納されている。Ｄ２Ｄリソース情報格納部３０４には、ＵＥ毎に、割り当てられたＤ２Ｄリソースを示す情報が格納される。また、リソースが解放された場合は割り当て情報は削除される。スケジューリング部３０５は、図１７〜図１９等を参照して説明したようにして、要求やフィードバックに基づくリソース割り当てを行う機能を有する。

【0161】

（第３の実施の形態）
次に、第３の実施の形態を説明する。前述したように、第３の実施の形態は、フィードバック設定やフィードバックタイプ切り替えに関するものであり、詳細は以下のとおりである。なお、第３の実施の形態は第１の実施の形態及び／又は第２の実施の形態と組み合わせて実行可能である。

【0162】

ＬＴＥのＲｅｌ−１２のＵＥ（端末）を考慮すると、全てのＵＥがＤ２Ｄでのフィードバックをサポートしているとは限らない。また、Ｂｒｏａｄｃａｓｔ／ｇｒｏｕｐｃａｓｔ／ｕｎｉｃａｓｔ等によってもフィードバックの必要性が異なる。

【0163】

そこで、本実施の形態では、例えばリソースプール毎に、フィードバックの有無・フィードバックタイプ（第１の実施の形態のリソース構成例１〜３等、もしくは、バンドリングの有無等でもよい）を設定可能としている。また、通信タイプ（Ｂｒｏａｄｃａｓｔ／ｇｒｏｕｐｃａｓｔ／ｕｎｉｃａｓｔ）に対応するフィードバックタイプを予め規定しておき、各ＵＥは、使用する通信タイプによりフィードバックタイプを決定（設定）してもよい。なお、第３の実施の形態は第１の実施の形態（及び／又は第２の実施の形態）を前提とするが、第３の実施の形態を単独で実施することも可能である。

【0164】

＜処理手順例３−１＞
図２２に、Ｍｏｄｅ１における基地局ｅＮＢによるフィードバック設定（Ｆｅｅｄｂａｃｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ）の手順例を示す。

【0165】

この場合、送信側ＵＥが基地局ｅＮＢに対してフィードバック設定を要求する（ステップ４０１）。当該要求は、フィードバックリソース割り当ての要求であってもよい。当該要求に基づいて、基地局ｅＮＢはフィードバック設定をＵＥにシグナリングで通知する。フィードバック設定のシグナリング方法には図２２のＢ〜Ｄに示すように種々の方法がある。例えば、Ｂに示すように、基地局ｅＮＢから各ＵＥに対してフィードバック設定を通知してもよいし、Ｃ、Ｄに示すように、送信側ＵＥから受信側ＵＥに対してフィードバック設定を通知してもよい。

【0166】

送信側ＵＥから受信側ＵＥに対してフィードバック設定を通知する際には、ＳＣＩを利用することができる。当該ＳＣＩには、例えば、フィードバック設定の情報が含められる。

【0167】

ステップ４０７において、フィードバック動作可能になれば、例えば、Ｅ（ステップ４０８、４０９）、Ｆ（ステップ４１１）に示すように、フィードバック用のリソース割り当てが受信側ＵＥに対して実施され、フィードバックが実施される（ステップ４１０．４１２）。

【0168】

＜処理手順例３−２＞
図２３に、Ｍｏｄｅ２における基地局ｅＮＢによるフィードバック設定（Ｆｅｅｄｂａｃｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ）の手順例を示す。

【0169】

Ｍｏｄｅ２では、基地局ｅＮＢからシステム情報（ＳＩＢ）で各ＵＥにフィードバック設定を通知してもよいし（Ａのステップ５０１で示す処理）、送信側ＵＥから受信側ＵＥに対してフィードバック設定を通知してもよい（Ｂのステップ５０２で示す処理）。

【0170】

ステップ５０３において、フィードバック動作可能になれば、例えば、Ｃ（ステップ５０４）に示すように、フィードバック用のリソース割り当てが受信側ＵＥに対して実施され、フィードバックが実施される（ステップ５０５）。

【0171】

処理手順例３−１、３−２により、送受ＵＥ及びｅＮＢ間でフィードバック設定を共有することができ、適切なフィードバック動作を実現できる。

【0172】

なお、図２２のＦ、図２３のＤに例示するように、基地局ｅＮＢが受信側ＵＥに対してリソース割り当て、もしくはフィードバック要求を送信することで、受信側ＵＥに対してフィードバック信号（ＣＳＩ等）を送信させ、基地局ｅＮＢは当該フィードバック信号を受信してもよい。

【0173】

＜その他の詳細例＞
第３の実施の形態では、受信側ＵＥは、使用するリソースプールの構成、Ｄａｔａの送信サブフレーム数等に応じて、フィードバック信号のフィードバックフォーマット（フィードバックタイプと同義）を切り替えてもよい。一例として、受信側ＵＥは、受信側ＵＥから送信できるＤａｔａの最大送信サブフレーム数（送信可能サブフレーム数）に応じて、ＡＣＫ／ＮＡＣＫバンドリングの有無を切り替えることができる。例えば、受信側ＵＥ（フィードバックの送信側ＵＥ）は、最大送信サブフレーム数が所定数よりも小さい場合にＡＣＫ／ＮＡＣＫバンドリングを適用し、最大送信サブフレーム数が所定数以上である場合にＡＣＫ／ＮＡＣＫバンドリングを適用しないといった判断を行うことができる。これにより、Ｄａｔａの送信可能サブフレームに応じてフィードバックによるオーバーヘッドを最適化することができる。

【0174】

また、受信側ＵＥは、送信側ＵＥから受信するＣＳＩの要求に応じて、ＡＣＫ／ＮＡＣＫのみを報告するか、受信品質も含めて報告するかを決定してもよい。例えば、ＣＳＩの要求を受信した場合でも、ＣＳＩ報告が不要と判断される場合（例：前回のＣＳＩ送信から所定時間が経過していない場合等）には、ＡＣＫ／ＮＡＣＫのみを応答することとしてよい。これにより、ＣＳＩ報告が不要な場合に、送信側ＵＥ（フィードバック受信側ＵＥ）におけるＡＣＫ／ＮＡＣＫの検出精度を向上させることができる。

【0175】

また、受信側ＵＥは、送信側ＵＥから受信するＣＳＩの要求に応じて、ＡＣＫ／ＮＡＣＫフィードバックとＣＳＩフィードバックを独立して報告するかを決定してもよい。例えば、正確なＣＳＩをフィードバックする必要があると判断した場合（例：Ｌｉｎｋ ａｄａｐｔａｔｉｏｎが適切にできていない場合）に、ＡＣＫ／ＮＡＣＫフィードバックとＣＳＩフィードバックを独立して報告することとしてもよい。ＣＳＩを独立して報告した場合は高精度なＣＳＩ報告が可能になる。

【0176】

また、受信側ＵＥは、Ｕｎｉｃａｓｔ／ｇｒｏｕｐ−ｃａｓｔにおいて異なるフィードバックフォーマットを用いてもよい。例えば、ＧｒｏｕｐｃａｓｔではＰＵＣＣＨフォーマット１ベースでバンドリングしたＡＣＫ／ＮＡＣＫを送信し、ＵｎｉｃａｓｔではＰＵＣＣＨフォーマット３ベースで高精度なＡＣＫ／ＮＡＣＫを送信することとしてもよい。

【0177】

また、Ｇｒｏｕｐ−ｃａｓｔにおけるフィードバックに関して、送信側ＵＥ（フィードバック受信側ＵＥ）でＡＣＫ／ＮＡＣＫだけを判定できるよう、Ｇｒｏｕｐ−ｃａｓｔ時に応答可能なフィードバックのフォーマットを特定のフォーマット（例：フィードバックとしてＡＣＫ／ＮＡＣＫだけを送信可能なフォーマット）に限定してもよい。また、Ｇｒｏｕｐ−ｃａｓｔにおいては、受信側ＵＥは、ＮＡＣＫの場合だけフィードバックを返すこととしてもよい。このような工夫により、複数の受信側ＵＥからのフィードバック信号が多重された応答でも、Ｇｒｏｕｐ−ｃａｓｔの送信側ＵＥは、ＡＣＫが報告されているか、ＮＡＣＫが報告されているかを判定することができる。

【0178】

また、Ｇｒｏｕｐ−ｃａｓｔにおけるフィードバックに関して、多数のＵＥが同一リソースでフィードバックすることによる隣接周波数リソースへの干渉増大を回避してもよい。具体的には、例えば、フィードバックリソースを複数定義して受信側ＵＥ（フィードバック送信側ＵＥ）がランダムにリソースを選択してフィードバックの送信を行うこととしてよい。また、当該干渉増大を回避するために、受信側ＵＥに対して、干渉を検知した送信側ＵＥから、あるいは干渉を検知した基地局ｅＮＢからＧｒｏｕｐ−ｃａｓｔにおけるフィードバックを禁止することとしてもよい。また、受信側ＵＥが、自律的にＧｒｏｕｐ−ｃａｓｔにおけるフィードバックを行わないこととしてもよい。

【0179】

＜第３の実施の形態の装置構成：ユーザ装置＞
図２４に、本実施の形態に係るユーザ装置ＵＥの機能構成図を示す。図２４に示すＵＥは、第３の実施の形態で説明した送信側ＵＥと受信側ＵＥのどちらにでもなり得るＵＥである。また、図２４に示すＵＥは、第１の実施の形態で説明したＵＥの動作を実施する機能、及び／又は、第２の実施の形態で説明するＵＥの動作を実施する機能を含むこととしてもよい。

【0180】

図２４に示すように、ユーザ装置ＵＥは、信号送信部４０１、信号受信部４０２、Ｄ２Ｄ通信機能部４０３、スケジューリングＳＣＩ送信制御部４０４、フィードバック制御部４０５、再送制御部４０６を含む。なお、図２４は、ユーザ装置ＵＥにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した動作を行うための図示しない機能も有するものである。また、図２４に示す機能構成は一例に過ぎない。本実施の形態に係るＵＥの動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

【0181】

信号送信部４０１は、ユーザ装置ＵＥから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。また、信号送信部４０１は、Ｄ２Ｄ通信の送信機能とセルラー通信の送信機能を有する。

【0182】

信号受信部４０２は、他のユーザ装置ＵＥ又は基地局ｅＮＢから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。信号受信部２０２は、Ｄ２Ｄ通信の受信機能とセルラー通信の受信機能を有する。

【0183】

Ｄ２Ｄ通信機能部４０３は、Ｄ２Ｄアプリケーションの機能を含み、Ｄｉｓｃｏｖｅｒｙ信号送受信制御、ＳＡ／Ｄａｔａ送受信制御等を実行する。スケジューリングＳＣＩ送信制御部４０４は、第３の実施の形態で再送、リソース割り当て、フィードバック設定送信等に使用されるスケジューリングＳＣＩ（ＳＡ）の送信のための処理（リソース割り当て受信を含む）を実行する。例として、スケジューリングＳＣＩ送信制御部４０４は、スケジューリングＳＣＩの信号を作成し、信号送信部４０１に対するスケジューリングＳＣＩのための信号マッピング等を行う。

【0184】

フィードバック制御部４０５は、第３の実施の形態で説明したフィードバックの送信のための処理（スケジューリングＳＣＩ送受信を含む）を実行する。フィードバック制御部４０５は、フィードバック設定を受信し、当該設定の情報に基づいて、ＵＥを設定（ｃｏｎｆｉｇｕｒｅ）する機能を含む。再送制御部４０６は、再送のための処理を実行する。

【0185】

＜第３の実施の形態の装置構成：基地局＞
図２５に、本実施の形態に係る基地局ｅＮＢの機能構成図を示す。なお、図２５に示すｅＮＢは、第２の実施の形態で説明するｅＮＢの動作を実施する機能を含むこととしてもよい。図２５に示すように、基地局ｅＮＢは、信号送信部５０１、信号受信部５０２、ＵＥ情報格納部５０３、Ｄ２Ｄリソース情報格納部５０４、スケジューリング部５０５、フィードバック設定制御部５０６を含む。なお、図２５は、基地局ｅＮＢにおいて本発明の実施の形態に特に関連する機能部のみを示すものであり、少なくともＬＴＥに準拠した移動通信システムにおける基地局として動作するための図示しない機能も有するものである。また、図２５に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分や機能部の名称はどのようなものでもよい。

【0186】

信号送信部５０１は、基地局ｅＮＢから送信されるべき上位のレイヤの信号から、物理レイヤの各種信号を生成し、無線送信する機能を含む。信号受信部５０２は、ユーザ装置ＵＥから各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。

【0187】

ＵＥ情報格納部５０３には、各ＵＥから受信するＵＥ能力の情報が格納されている。Ｄ２Ｄリソース情報格納部５０４には、ＵＥ毎に、割り当てられたＤ２Ｄリソースを示す情報が格納される。また、リソースが解放された場合は割り当て情報は削除される。スケジューリング部５０５は、要求やフィードバックに基づくリソース割り当てを行う機能を有する。フィードバック設定制御部５０６は、本実施の形態におけるフィードバック設定を行う機能を含む。

【0188】

（第１〜第３の実施の形態におけるＨＷ構成例）
図１６、図２０、図２４に示した各ユーザ装置ＵＥの構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。

【0189】

図２６は、ユーザ装置ＵＥのハードウェア（ＨＷ）構成（第１〜第３の実施の形態に共通の構成）の例を示す図である。図２６は、図１６、図２０、図２４に示した構成よりも実装例に近い構成を示している。図２６に示すように、ＵＥは、無線信号に関する処理を行うＲＥ（Ｒａｄｉｏ Ｅｑｕｉｐｍｅｎｔ）モジュール６５１と、ベースバンド信号処理を行うＢＢ（Ｂａｓｅ Ｂａｎｄ）処理モジュール６５２と、上位レイヤ等の処理を行う装置制御モジュール６５３と、ＵＳＩＭカードにアクセスするインタフェースであるＵＳＩＭスロット６５４とを有する。

【0190】

ＲＥモジュール６５１は、ＢＢ処理モジュール６５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ（Ｄｉｇｉｔａｌ−ｔｏ−Ａｎａｌｏｇ）変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ（Ａｎａｌｏｇ ｔｏ Ｄｉｇｉｔａｌ）変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール６５２に渡す。ＲＥモジュール６５１は、例えば、信号送信部（１０１、２０１、４０１）、及び信号受信部（１０２、２０２、４０２）における物理レイヤ等の機能を含む。

【0191】

ＢＢ処理モジュール６５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）６６２は、ＢＢ処理モジュール６５２における信号処理を行うプロセッサである。メモリ６７２は、ＤＳＰ６６２のワークエリアとして使用される。ＢＢ処理モジュール６５２は、例えば、信号送信部（１０１、２０１、４０１）、及び信号受信部（１０２、２０２、４０２）におけるレイヤ２等の機能、Ｄ２Ｄ通信機能部（１０３、２０３、４０３）、スケジューリングＳＣＩ送信制御部（１０４、２０４、４０４）、フィードバック制御部（１０５、２０５、４０５）、及び再送制御部（１０６、２０６、４０６）を含む。なお、Ｄ２Ｄ通信機能部（１０３、２０３、４０３）、スケジューリングＳＣＩ送信制御部（１０４、２０４、４０４）、フィードバック制御部（１０５、２０５、４０５）、及び再送制御部（１０６、２０６、４０６）の全部又は一部を装置制御モジュール６５３に含めることとしてもよい。

【0192】

装置制御モジュール６５３は、ＩＰレイヤのプロトコル処理、各種アプリケーションの処理等を行う。プロセッサ６６３は、装置制御モジュール６５３が行う処理を行うプロセッサである。メモリ６７３は、プロセッサ６６３のワークエリアとして使用される。また、プロセッサ６６３は、ＵＳＩＭスロット１５４を介してＵＳＩＭとの間でデータの読出し及び書込みを行う。

【0193】

図２１、図２５に示した基地局ｅＮＢの構成は、全体をハードウェア回路（例：１つ又は複数のＩＣチップ）で実現してもよいし、一部をハードウェア回路で構成し、その他の部分をＣＰＵとプログラムとで実現してもよい。

【0194】

図２７は、基地局ｅＮＢのハードウェア（ＨＷ）構成（第１〜第３の実施の形態に共通の構成）の例を示す図である。図２７は、図２１、図２５に示した構成よりも実装例に近い構成を示している。図２７に示すように、基地局ｅＮＢは、無線信号に関する処理を行うＲＥモジュール７５１と、ベースバンド信号処理を行うＢＢ処理モジュール７５２と、上位レイヤ等の処理を行う装置制御モジュール７５３と、ネットワークと接続するためのインタフェースである通信ＩＦ７５４とを有する。

【0195】

ＲＥモジュール７５１は、ＢＢ処理モジュール７５２から受信したデジタルベースバンド信号に対して、Ｄ／Ａ変換、変調、周波数変換、及び電力増幅等を行うことでアンテナから送信すべき無線信号を生成する。また、受信した無線信号に対して、周波数変換、Ａ／Ｄ変換、復調等を行うことでデジタルベースバンド信号を生成し、ＢＢ処理モジュール７５２に渡す。ＲＥモジュール７５１は、例えば、信号送信部（３０１、５０１）、及び信号受信部（３０２、５０２）における物理レイヤ等の機能を含む。

【0196】

ＢＢ処理モジュール７５２は、ＩＰパケットとデジタルベースバンド信号とを相互に変換する処理を行う。ＤＳＰ７６２は、ＢＢ処理モジュール７５２における信号処理を行うプロセッサである。メモリ７７２は、ＤＳＰ７５２のワークエリアとして使用される。ＢＢ処理モジュール７５２は、例えば、信号送信部（３０１、５０１）、及び信号受信部（３０２、５０２）におけるレイヤ２等の機能、ＵＥ情報格納部（３０３、５０３）、Ｄ２Ｄリソース情報格納部（３０４、５０４）、スケジューリング部（３０５、５０５）、及び、フィードバック設定制御部５０６を含む。なお、ＵＥ情報格納部（３０３、５０３）、Ｄ２Ｄリソース情報格納部（３０４、５０４）、スケジューリング部（３０５、５０５）、及び、フィードバック設定制御部５０６の全部又は一部を装置制御モジュール７５３に含めることとしてもよい。

【0197】

装置制御モジュール７５３は、ＩＰレイヤのプロトコル処理、ＯＡＭ処理等を行う。プロセッサ７６３は、装置制御モジュール７５３が行う処理を行うプロセッサである。メモリ７７３は、プロセッサ７６３のワークエリアとして使用される。補助記憶装置７８３は、例えばＨＤＤ等であり、基地局ｅＮＢ自身が動作するための各種設定情報等が格納される。

【0198】

（実施の形態のまとめ）
以上、説明したように、本実施の形態（第１〜第３の実施の形態、以下同様）により、Ｄ２Ｄ通信をサポートする移動通信システムにおける受信側ユーザ装置として使用されるユーザ装置であって、送信側ユーザ装置からＤ２Ｄ信号を受信し、当該Ｄ２Ｄ信号に対するフィードバック信号を所定のリソースを用いて前記送信側ユーザ装置に送信するフィードバック手段と、前記フィードバック信号に基づいて前記送信側ユーザ装置から送信される再送Ｄ２Ｄ信号を受信する受信手段とを備えるユーザ装置が提供される。

【0199】

上記の構成により、Ｄ２Ｄ通信をサポートする移動通信システムにおいて、ユーザ装置間でのフィードバック及び再送を行うことを可能とする技術が提供される。

【0200】

前記フィードバック手段は、例えば、前記送信側ユーザ装置から明示的又は暗黙的に通知されるリソース情報に基づいて、前記所定のリソースを決定する。この構成により、フィードバック送信用のリソースを適切に決定することができる。

【0201】

前記フィードバック手段は、前記送信側ユーザ装置から受信する、前記Ｄ２Ｄ信号に対応するスケジューリング制御情報に基づいて、前記所定のリソースを決定することとしてもよい。この構成により、再送の対象となり得るＤ２Ｄ信号に対応するスケジューリング制御情報に基づいてフィードバック送信用のリソースを決定できるので、Ｄ２Ｄ信号に対応するフィードバック信号のリソースを迅速に決定することができる。

【0202】

前記フィードバック手段は、前記所定のリソースとして、ＳＡリソースプールにおけるリソース、又は、Ｄ２Ｄデータ送信用のリソースプールにおけるリソースを使用することとしてもよい。ＳＡリソースプールにおけるリソースを用いることで、制御情報としてフィードバック信号を送信でき、Ｄ２Ｄデータ送信用のリソースプールにおけるリソースを使用することでデータとしてフィードバック信号を送信できる。

【0203】

前記受信手段は、前記再送Ｄ２Ｄ信号を受信する前に、当該再送Ｄ２Ｄ信号の送信リソースを通知するスケジューリング制御情報を受信し、当該スケジューリング制御情報には、再送の対象となるＤ２Ｄ信号を示す情報が含まれることとしてもよい。この構成により、ユーザ装置は、どのＤ２Ｄ信号に対する再送がなされるかを把握できる。

【0204】

また、本実施の形態により、Ｄ２Ｄ通信をサポートする移動通信システムにおける送信側ユーザ装置として使用されるユーザ装置であって、受信側ユーザ装置に対して送信したＤ２Ｄ信号に対するフィードバック信号を当該受信側ユーザ装置から受信する受信手段と、前記フィードバック信号に基づいて、前記Ｄ２Ｄ信号に対する再送Ｄ２Ｄ信号を前記受信側ユーザ装置に送信する送信手段とを備えるユーザ装置が提供される。

【0205】

上記の構成により、Ｄ２Ｄ通信をサポートする移動通信システムにおいて、ユーザ装置間でのフィードバック及び再送を行うことを可能とする技術が提供される。

【0206】

前記ユーザ装置は、前記Ｄ２Ｄ信号の送信リソース情報を含むスケジューリング制御情報を前記受信側ユーザ装置に送信する制御情報送信手段を備え、前記スケジューリング制御情報は、前記受信側ユーザ装置において前記フィードバック信号を送信するためのリソースを決定するために使用されるリソース情報を含むこととしてもよい。この構成により、受信側ユーザ装置において適切にフィードバック信号を送信するためのリソースを決定することができる。

【0207】

また、前記制御情報送信手段は、前記再送Ｄ２Ｄ信号が送信される前に、再送の対象となるＤ２Ｄ信号を示す情報を含むスケジューリング制御情報を前記受信側ユーザ装置に送信することとしてもよい。この構成により、受信側ユーザ装置においてどのＤ２Ｄ信号に対する再送は行われるかを把握できる。

【0208】

また、本実施の形態では、上述した送信側ユーザ装置の各手段と、受信側ユーザ装置の各手段の両方を含むユーザ装置が提供される。

【0209】

なお、上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

【0210】

本実施の形態で説明したユーザ装置ＵＥは、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在した構成であってもよい。

【0211】

本実施の形態で説明した基地局ｅＮＢは、ＣＰＵとメモリを備え、プログラムがＣＰＵ（プロセッサ）により実行されることで実現される構成であってもよいし、本実施の形態で説明する処理のロジックを備えたハードウェア回路等のハードウェアで実現される構成であってもよいし、プログラムとハードウェアが混在した構成であってもよい。

【0212】

以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。説明の便宜上、ユーザ装置ＵＥ及び基地局ｅＮＢは機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置ＵＥが有するプロセッサにより動作するソフトウェア、及び本発明の実施の形態に従って基地局ｅＮＢが有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

【0213】

本発明は上記実施形態に限定されず、本発明の精神から逸脱することなく、様々な変形例、修正例、代替例、置換例等が本発明に包含される。

【0214】

本特許出願は２０１４年１１月１４日に出願した日本国特許出願第２０１４−２３２１３５号に基づきその優先権を主張するものであり、日本国特許出願第２０１４−２３２１３５号の全内容を本願に援用する。

【符号の説明】

【0215】

ｅＮＢ 基地局
ＵＥ ユーザ装置
１０１ 信号送信部
１０２ 信号受信部
１０３ Ｄ２Ｄ通信機能部
１０４ スケジューリングＳＣＩ送信制御部
１０５ フィードバック制御部
１０６ 再送制御部
２０１ 信号送信部
２０２ 信号受信部
２０３ Ｄ２Ｄ通信機能部
２０４ スケジューリングＳＣＩ送信制御部
２０５ フィードバック制御部
２０６ 再送制御部
３０１ 信号送信部
３０２ 信号受信部
３０３ ＵＥ情報格納部
３０４ Ｄ２Ｄリソース情報格納部
３０５ スケジューリング部
４０１ 信号送信部
４０２ 信号受信部
４０３ Ｄ２Ｄ通信機能部
４０４ スケジューリングＳＣＩ送信制御部
４０５ フィードバック制御部
４０６ 再送制御部
５０１ 信号送信部
５０２ 信号受信部
５０３ ＵＥ情報格納部
５０４ Ｄ２Ｄリソース情報格納部
５０５ スケジューリング部
５０６ フィードバック設定制御部
６５１ ＲＥモジュール
６５２ ＢＢ処理モジュール
６５３ 装置制御モジュール
６５４ ＵＳＩＭスロット
７５１ ＲＥモジュール
７５２ ＢＢ処理モジュール
７５３ 装置制御モジュール
７５４ 通信ＩＦ

【図1A】

【図1B】

【図1C】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12A】

【図12B】

【図12C】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】