特許 6249310 端末装置及び通信方法

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

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

(11)【特許番号】6249310

(24)【登録日】2017年12月1日

(45)【発行日】2017年12月20日

(54)【発明の名称】端末装置及び通信方法

(51)【国際特許分類】

   H04W 74/08 20090101AFI20171211BHJP

   H04W 72/04 20090101ALI20171211BHJP

   H04W 72/06 20090101ALI20171211BHJP

【ＦＩ】

   H04W74/08

   H04W72/04 136

   H04W72/06

【請求項の数】14

【全頁数】29

(21)【出願番号】特願2016-162744(P2016-162744)

(22)【出願日】2016年8月23日

(62)【分割の表示】特願2013-527852(P2013-527852)の分割

【原出願日】2012年7月20日

(65)【公開番号】特開2016-208547(P2016-208547A)

(43)【公開日】2016年12月8日

【審査請求日】2016年8月23日

(31)【優先権主張番号】特願2011-171945(P2011-171945)

(32)【優先日】2011年8月5日

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

(73)【特許権者】

【識別番号】316002062

【氏名又は名称】サン パテント トラスト

(74)【代理人】

【識別番号】100105050

【弁理士】

【氏名又は名称】鷲田 公一

(72)【発明者】

【氏名】西尾 昭彦

(72)【発明者】

【氏名】星野 正幸

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】岩井 敬

【審査官】 相澤 祐介

(56)【参考文献】

【文献】 特開２０１１−１４２６２０（ＪＰ，Ａ）

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

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

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

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

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

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

【請求項1】

基地局より通知される第１のリソース群または第２のリソース群に関するリソース情報を含む報知信号を受信する、受信部と、
前記報知信号が前記第１のリソース群に含まれている場合、前記第１のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号が前記第１のリソース群に含まれていない場合、前記第２のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信する、送信部と、を備え、
前記受信部は、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号が含まれるリソース群に応じてＤＭＲＳまたはＣＲＳを用いて受信する、
端末装置。

【請求項2】

前記受信部は、前記ランダムアクセス応答信号を、
前記報知信号が前記第１のリソース群に含まれている場合、ＤＭＲＳを用いて受信し、
前記報知信号が前記第１のリソース群に含まれていない場合、ＣＲＳを用いて受信する、
請求項１に記載の端末装置。

【請求項3】

前記ランダムアクセス応答信号がマッピングされるデータリソースに関する情報を、制御チャネルにより受信する、
請求項１に記載の端末装置。

【請求項4】

前記基地局と前記端末装置との間の伝搬減衰値の閾値に対応して、前記第１のリソース群はさらに複数のリソース群に分割され、
前記受信部は、前記伝搬減衰値と対応づけられた前記複数のリソース群に関する情報を受信する、
請求項１に記載の端末装置。

【請求項5】

前記第１のリソース群と、前記第２のリソース群に対して、それぞれ異なる前記ランダムアクセス応答信号の待ち受け期間を設定される、
請求項１に記載の端末装置。

【請求項6】

前記第１のリソース群に対して設定される待ち受け期間は、前記第２のリソース群に対して設定される待ち受け期間よりも短い、
請求項５に記載の端末装置。

【請求項7】

前記ランダムアクセス応答信号は、ＤＭＲＳ受信に用いる制御チャネルにより受信する、
請求項１に記載の端末装置。

【請求項8】

基地局より通知される第１のリソース群または第２のリソース群に関するリソース情報を含む報知信号を受信し、
前記報知信号が前記第１のリソース群に含まれている場合、前記第１のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、
前記報知信号が前記第１のリソース群に含まれていない場合、前記第２のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、
前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号が含まれるリソース群に応じてＤＭＲＳまたはＣＲＳを用いて受信する、
通信方法。

【請求項9】

前記ランダムアクセス応答信号を、前記報知信号が前記第１のリソース群に含まれている場合、ＤＭＲＳを用いて受信し、
前記報知信号が前記第１のリソース群に含まれていない場合、ＣＲＳを用いて受信する、
請求項８に記載の通信方法。

【請求項10】

前記ランダムアクセス応答信号がマッピングされるデータリソースに関する情報を、制御チャネルにより送信する、
請求項８に記載の通信方法。

【請求項11】

前記基地局と前記基地局からの前記報知信号を受信する端末装置との間の伝搬減衰値の閾値に対応して、前記第１のリソース群はさらに複数のリソース群に分割され、
前記伝搬減衰値と対応づけられた前記複数のリソース群に関する情報を受信する、
請求項８に記載の通信方法。

【請求項12】

前記第１のリソース群と、前記第２のリソース群に対して、それぞれ異なる前記ランダムアクセス応答信号の待ち受け期間を設定される、
請求項８に記載の通信方法。

【請求項13】

前記第１のリソース群に対して設定される待ち受け期間は、前記第２のリソース群に対して設定される待ち受け期間よりも短い、
請求項１２に記載の通信方法。

【請求項14】

前記ランダムアクセス応答信号は、ＤＭＲＳ受信に用いる制御チャネルにより受信する、
請求項８に記載の通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、端末装置及び通信方法に関する。

【背景技術】

【0002】

３ＧＰＰ−ＬＴＥ(3rd Generation Partnership Project Radio Access Network Long Term Evolution)（以下では、単に、「ＬＴＥ」と呼ばれることがある)のRelease 8（Rel.8）では、下り回線の通信方式としてＯＦＤＭＡ（Orthogonal Frequency Division Multiple Access）が採用され、上り回線の通信方式としてＳＣ−ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が採用されている。

【0003】

Ｒｅｌ．８の下り回線では、データ信号(例えば、ＰＤＳＣＨによって送信される信号)を復調するために、ＣＲＳ（cell specific reference signal）が用いられる。すなわち、「ＣＲＳを用いたデータ送信」がサポートされている。「ＣＲＳを用いたデータ送信」とは、ＣＲＳをマッピングしたサブフレームにおいて、ＣＲＳと共にデータ信号を送信する送信方法であり、端末はデータ受信の際にＣＲＳにより伝搬路推定を行うことによりデータ復調を行う。ＣＲＳは、全てのサブフレームで全帯域に渡って送信され、任意のセル内で共通の参照信号（reference signal）である。また、ＣＲＳは、セルＩＤに依存した時間・周波数リソースにマッピングされて送信され、送信アンテナ数に応じてアンテナポート0〜3が使用される。また、ＣＲＳは、任意のセルのエリア全てをカバーするように送信される。また、ＣＲＳは、品質測定にも用いられ、この品質測定結果は、リンクアダプテーション又はスケジューリングに用いられる。

【0004】

一方、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、下り回線に対してＭＩＭＯ（Multi-Input Multi-Output）を適用するために、「ＤＭＲＳ（Demodulation Reference signal）を用いたデータ送信」がサポートされている。「ＤＭＲＳを用いたデータ送信」とは、ＤＭＲＳをマッピングしたサブフレームにおいて、ＤＭＲＳと共にデータ信号を送信する送信方法であり、端末はデータ受信の際にＤＭＲＳにより伝搬路推定を行うことによりデータ復調を行う。ＤＭＲＳは、UE specific Reference Signalと呼ばれることもある。また、ＤＭＲＳは、セル全体に向けて送信されるＣＲＳに対して、下り回線データ信号をマッピングするためのデータリソースを割り当てた端末向けに送信され、その端末向けのデータを割り当てたリソースブロック(つまり、周波数リソース)のみで送信される。所定の端末向けにデータ信号を送信する場合、Ｐｒｅｃｏｄｉｎｇによってビームを形成し、当該ビームを用いたデータ通信が可能となる。このビームを用いたデータ通信では、高いスループットを実現できる（例えば、非特許文献１、２、３、４参照）。また、ＤＭＲＳを用いたデータ送信は、送信モード９が設定された端末向けに用いることができる。また、送信アンテナ数に応じてアンテナポート７〜１４が使用される。また、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、ＣＳＩ−ＲＳが品質測定に用いられ、この品質測定結果がリンクアダプテーション又はスケジューリングに用いられる。

【0005】

また、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、送信モード９が設定された端末は、「ＭＢＳＦＮ（multi-broadcast single frequency network）サブフレーム」においてもデータ信号を送信できる。

【0006】

ここで、Ｒｅｌ．８では、「ＭＢＳＦＮサブフレーム」は、ＭＢＭＳデータ(MulticastまたはBroadcastデータ)を複数基地局からＳＦＮ(Single Frequency Network)送信するために用いられる。このため、ＰＤＣＣＨ信号及びＣＲＳがマッピングされるリソースは、サブフレームの先頭の２ＯＦＤＭシンボル内に限定される。そして、サブフレームの先頭から３ＯＦＤＭシンボル以降では、ＭＢＭＳデータのみをマッピングすることができる。すなわち、ＭＢＳＦＮサブフレームでは、サブフレームの先頭から３ＯＦＤＭシンボル目以降のＯＦＤＭシンボル（つまり、データ送信領域）には、ＣＲＳが含まれない。

【0007】

一方、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、ＭＢＳＦＮサブフレームにおいても、ＤＭＲＳを用いたデータ送信（Unicastデータの送信）を行うことができる。上記の通り、ＭＢＳＦＮサブフレームでは先頭から３ＯＦＤＭシンボル目以降のＯＦＤＭシンボル（つまり、データ送信領域）にはＣＲＳが含まれないので、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、より多くの時間周波数リソースをＰＤＳＣＨに用いることができる。

【0008】

また、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１１（Ｒｅｌ．１０の次のＲｅｌｅａｓｅである）では、複数ノードから協調送信するＣｏＭＰ送信が検討されている。また、このＣｏＭＰ送信をヘテロジニアスネットワーク環境において用いる場合に、マクロセル内の複数のＬＰＮに対してＨＰＮと同一のセルＩＤを用いる運用が検討されている（例えば、非特許文献６参照）。このような運用においては、同一セルＩＤを用いるＨＰＮ及びＬＰＮからは、共通のＣＲＳが送信される。ここで、ヘテロジニアスネットワーク環境とは、マクロ基地局(HPN(High Power Node))とピコ基地局(LPN(Low Power Node))とから構成されるネットワーク環境である。

【0009】

さらに、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１１では、下り回線向けのExtension carrier(non-backward compatible carrier)が検討されている。Extension carrierでは、ＤＭＲＳのみがサポートされ、オーバーヘッド低減のために、ＣＲＳは送信されない(例えば、非特許文献７参照)。このようにExtension carrierでは、ＤＭＲＳを用いたデータ送信のみがサポートされる運用により、高効率の伝送が可能である。

【0010】

また、ＬＴＥ及びＬＴＥ−Ａｄｖａｎｃｅｄにおいては、初期アクセス時、接続中において上り回線データが発生した時、又は、ハンドオーバー時に、端末は、基地局に対してＲＡＣＨ（Random Access Channel）を送信する。これにより、端末から基地局への接続、又は、再同期確立が、試行される。これらの、端末から基地局への接続、又は、再同期確立のために行われる一連の動作は、「Random access procedure」と呼ばれる。「Random access procedure」は、図１に示す４つのステップから構成される（例えば、非特許文献５参照）。

【0011】

Ｓｔｅｐ１（message 1の送信）：端末は、ＲＡＣＨ preambleリソース候補（時間リソース、周波数リソース、及び系列リソースの組み合わせにより規定される）群から、実際に用いられるＲＡＣＨ preambleリソースをランダムに選択する。そして、端末は、選択されたＲＡＣＨpreambleリソースを用いてＲＡＣＨ preambleを送信する。ここで、基地局と端末の間の伝搬ロス(Ｐａｔｈ ｌｏｓｓ)が所定閾値以上の場合と、閾値以下の場合とでは、選択可能なＲＡＣＨ preambleリソース候補が異なる。また、データサイズが所定閾値以上の場合と、所定閾値以下の場合とでも、選択可能なＲＡＣＨ preambleリソース候補が異なる。また、ＲＡＣＨ preambleは、「message 1」と呼ばれることがある。

【0012】

Ｓｔｅｐ２（message 2の送信）：基地局は、ＲＡＣＨ preambleを検出した場合、ＲＡＣＨ response(又は、random access response)を送信する。この時点では、基地局はＲＡＣＨpreambleを送信した端末を特定できない。このため、ＲＡＣＨ responseは、基地局がカバーするセルの全体に送信される。ＲＡＣＨ responseがマッピングされるデータリソース（つまり、ＰＤＳＣＨリソース）は、ＰＤＣＣＨによって基地局から端末へ通知される。また、ＲＡＣＨ responseには、端末が上り回線で使用するリソースに関する情報、又は、端末による上り回線の送信タイミングに関する情報が含まれている。ここで、ＲＡＣＨ preambleを送信した端末は、ＲＡＣＨ preambleの送信タイミングから所定期間（つまり、再送判定期間）内にＲＡＣＨ responseを受信しない場合、再度、ＲＡＣＨ preambleリソースの選択、及び、ＲＡＣＨ preambleの送信（ＲＡＣＨの再送）を行う。

【0013】

Ｓｔｅｐ３（message 3の送信）：端末は、ＲＡＣＨ responseによって基地局から指示された上り回線リソースを用いて、ＲＲＣ接続要求又はスケジューリング要求などのデータを送信する。

【0014】

Ｓｔｅｐ４（message 4の送信）：基地局は、端末に割り当てたＵＥ−ＩＤ（例えば、C-RNTI、又は、temporary C-RNTI）を含めたメッセージを端末へ送信することにより、複数の端末が競合していないことを確認する(contention resolution)。

【先行技術文献】

【非特許文献】

【0015】

【非特許文献1】3GPP TS 36.211 V10.1.0, “Physical Channels and Modulation (Release 10),” March 2011

【非特許文献2】3GPP TS 36.212 V10.1.0, “Multiplexing and channel coding (Release 10),” March 2011

【非特許文献3】3GPP TS 36.213 V10.1.0, “Physical layer procedures (Release 10),” March 2011

【非特許文献4】3GPP TS 36.321 V10.1.0, “Medium Access Control Protocol specification,(Release 10)” March 2011

【非特許文献5】“LTE -THE UMTS LONG TERM EVOLUTION”, Section 19, John Wiley&Sons Ltd, April 2009

【非特許文献6】3GPP TSG RAN WG1 meeting, R1-110649, Feb. 2011

【非特許文献7】3GPP TSG RAN WG1 meeting, R1-100359, Jan. 2010

【非特許文献8】3GPP TSG RAN WG1 meeting, R1-111716, May 2011

【発明の概要】

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

【0016】

ところで、上記の通り、ＬＴＥ−Ａｄｖａｎｃｅｄシステムに関しては、ＭＢＳＦＮサブフレーム及びExtension carrierにおいても、同一セルＩＤを用いたＣｏＭＰ送信においても、ＤＭＲＳを用いたデータ送信を行うことによって、高効率の伝送が実現される。

【0017】

しかしながら、「Random access procedure」においては、以下に示す課題がある。

【0018】

（１）ＭＢＳＦＮサブフレームに関する課題：
１フレーム（＝１０サブフレーム）内で、サブフレーム番号0,4,5,9以外のサブフレームを、ＭＢＳＦＮサブフレームとして設定することができる。すなわち、サブフレーム番号1,2,3,6,7,8のサブフレームをＭＢＳＦＮサブフレームとして設定することにより、高効率なシステム運用が可能となる。

【0019】

ここで、ｎｏｎ−ＭＢＳＦＮサブフレームでは、サブフレーム全体にＣＲＳがマッピングされるため、「ＣＲＳを用いたデータ送信」によって、ＲＡＣＨ responseを送信できる。すなわち、ｎｏｎ−ＭＢＳＦＮサブフレームでは、「ＣＲＳを用いたデータ送信」によってＲＡＣＨ responseを送信しても、端末は、十分に低い誤り率によって、下り回線のデータ信号を受信できる。

【0020】

一方、ＭＢＳＦＮサブフレームでは、ＣＲＳは、サブフレームの先頭から２シンボルまでのＯＦＤＭシンボルにしかマッピングされない。このため、ＭＢＳＦＮサブフレームでは、ＲＡＣＨ responseの受信誤り率が高くなってしまう。

【0021】

ここで、上記の通り、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０に対応する端末は、ＤＭＲＳを受信できる。このため、ＬＴＥ−ＡｄｖａｎｃｅｄであるＲｅｌ．１０では、ＲＡＣＨ responseがＭＢＳＦＮサブフレームにおいて送信されることも考えられる（例えば、非特許文献８参照）。

【0022】

しかしながら、「ＤＭＲＳを用いたデータ送信」によってＲＡＣＨ responseを送信した場合、Ｒｅｌ．１０に対応する端末は、ＲＡＣＨ responseを受信できる一方で、Ｒｅｌ．８に対応する端末は、ＤＭＲＳをサポートしていないので、ＲＡＣＨ responseを受信できない。このため、基地局がＲＡＣＨ preambleの送信元端末に対してＲＡＣＨ responseをＭＢＳＦＮサブフレームで送信したとしても、送信元端末がＲｅｌ．８に対応する端末である場合には、ＲＡＣＨ responseは、正しく受信されない。従って、送信元端末は、ＲＡＣＨpreambleを再送することになる。このため、「ＤＭＲＳを用いたデータ送信」によってＲＡＣＨresponseを送信することは、Ｒｅｌ．８に対応する端末にとっては、遅延の原因となる。このため、Ｒｅｌ．１０ではＲＡＣＨ responseはＣＲＳを用いて送信され、ＲＡＣＨ responseが送信されるサブフレームは、ｎｏｎ−ＭＢＳＦＮサブフレームに限定されることになる（図２参照）。しかしながら、ＲＡＣＨ responseが送信されるサブフレームをｎｏｎ−ＭＢＳＦＮサブフレームに限定すると、ＲＡＣＨ responseの送信に遅延が生じることになる。また、「ＣＲＳを用いたデータ送信」によって送信される必要のある、共通チャネル信号がｎｏｎ−ＭＢＳＦＮサブフレームに集中することになる。このため、共通チャネル信号をマッピングするリソースの通知に用いられるＰＤＣＣＨ領域（つまり、common search space）が混雑してしまう。なお、「ＣＲＳを用いたデータ送信」によって送信される必要のある、共通チャネル信号には、報知情報であるＳＩＢ（System information block）又はPaging情報などが含まれる。

【0023】

（２）Extension carrierに関する課題：
Extension carrierを設けることにより、リソースの容量を拡大することができる。しかしながら、Ｒｅｌ．８からＲｅｌ．１０のそれぞれに対応する端末は、Extension carrierを使用することができない。従って、RACH procedure中におけるＰＤＳＣＨを用いた送信では、通常のcomponent carrierが用いられる必要がある。このため、通常のcomponent carrierが混雑して、初期アクセス時又はハンドオーバー時の遅延を招く恐れがある。

【0024】

（３）同一セルＩＤを用いるＣｏＭＰ送信に関する課題：
同一セルＩＤを用いる全てのＨＰＮ及びＬＰＮから、共通のＣＲＳが送信される。このため、ＣＲＳを用いたデータ送信（つまり、ＰＤＳＣＨの送信）が行われる場合、ＰＤＳＣＨも、全ての送信ポイント（つまり、同一セルＩＤを用いる全てのＨＰＮ及びＬＰＮ）から送信される。従って、RACH procedure中におけるＰＤＳＣＨを用いたデータ送信に対してＣＲＳを用いたデータ送信が適用されると、或る送信ポイントの近傍に存在する端末に対するデータ送信であっても、全送信ポイントからデータが送信されることになり、非効率となる。

【0025】

本発明の目的は、応答信号を効率良く送信する端末装置及び通信方法を提供することである。

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

【0026】

本発明の一態様の端末装置は、基地局より通知される第１のリソース群または第２のリソース群に関するリソース情報を含む報知信号を受信する、受信部と、前記報知信号が前記第１のリソース群に含まれている場合、前記第１のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号が前記第１のリソース群に含まれていない場合、前記第２のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信する、送信部と、を備え、前記受信部は、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号が含まれるリソース群に応じてＤＭＲＳまたはＣＲＳを用いて受信する。

【0027】

本発明の一態様の通信方法は、基地局より通知される第１のリソース群または第２のリソース群に関するリソース情報を含む報知信号を受信し、前記報知信号が前記第１のリソース群に含まれている場合、前記第１のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号が前記第１のリソース群に含まれていない場合、前記第２のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号が含まれるリソース群に応じてＤＭＲＳまたはＣＲＳを用いて受信する。

【発明の効果】

【0028】

本発明によれば、プリアンブル送信装置から送信されたランダムアクセスプリアンブルに対する応答信号を効率良く送信する端末装置及び通信方法を提供できる。

【図面の簡単な説明】

【0029】

【図1】Random access procedureの説明に供する図

【図2】ＲＡＣＨresponseが送信されるサブフレームの説明に供する図

【図3】本発明の実施の形態１に係る通信システムの一例を示す図

【図4】本発明の実施の形態１に係る基地局の構成を示すブロック図

【図5】本発明に実施の形態１に係る端末の構成を示すブロック図

【図6】本発明に実施の形態１に係る基地局及び端末の動作説明に供する図

【図7】本発明の実施の形態３に係る送信方法決定テーブルの第１の例を示す図

【図8】本発明の実施の形態３に係る送信方法決定テーブルの第２の例を示す図

【図9】本発明に実施の形態３に係る基地局及び端末の動作説明に供する図

【図10】本発明の実施の形態４に係る基地局の構成を示すブロック図

【図11】本発明に実施の形態４に係る端末の構成を示すブロック

【図12】再送判定期間の他の例の説明に供する図

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

【0030】

以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、実施の形態において、同一の構成要素には同一の符号を付し、その説明は重複するので省略する。

【0031】

［実施の形態１］
［通信システムの概要］
本発明の実施の形態１に係る通信システムは、ランダムアクセスプリアンブルに対する応答信号の送信装置と、ランダムアクセスプリアンブルを送信する第１のプリアンブル送信装置及び第２のプリアンブル送信装置とを有する。

【0032】

図３は、本発明の実施の形態１に係る通信システムの一例を示す図である。図３において、本発明の実施の形態１に係る通信システムは、基地局１００と、端末２００，３００とを有する。図３においては、応答信号の送信装置は、基地局１００に対応し、第１のプリアンブル送信装置及び第２のプリアンブル送信装置は、端末２００，３００にそれぞれ対応する。基地局１００は、端末２００，３００から送信されたランダムアクセスプリアンブルを受信し、受信されたランダムアクセスプリアンブルに対する応答信号を端末２００，３００へ送信する。端末２００は、第１のリファレンス信号及び第２のリファレンス信号を受信できる一方、端末３００は、第１のリファレンス信号を受信できず且つ第２のリファレンス信号を受信できる。

【0033】

より具体的には、基地局１００において、後述する送信部１０４は、第１のリファレンス信号を第１のアンテナポートで送信し、第２のリファレンス信号を第２のアンテナポートで送信する。後述する設定部１０１は、第１のアンテナポートで送信される応答信号及び第２のアンテナポートで送信される応答信号を受信できる第１のプリアンブル送信装置が選択可能な第１のリソース群と、第１のアンテナポートで送信される応答信号を受信できず且つ第２のアンテナポートで送信される応答信号を受信できる第２のプリアンブル送信装置が選択可能な第２のリソース群とを設定する。後述する受信部１０２は、第１のリソース群又は第２のリソース群に含まれるリソースを用いて送信されたランダムアクセスプリアンブルを受信する。そして、後述する送信部１０４は、ランダムアクセスプリアンブルのリソースが第１のリソース群に含まれる場合、第１のアンテナポート又は第２のアンテナポートで応答信号を送信する。また、送信部１０４は、ランダムアクセスプリアンブルのリソースが第２のリソース群に含まれる場合、第２のアンテナポートで応答信号を送信する。ここで、後述する設定部１０１がランダムアクセスプリアンブルに対して、第１のアンテナポート及び第２のアンテナポートのいずれか一方で応答信号が送信される第１のリソース群と、ランダムアクセスプリアンブルに対して、第２のアンテナポートで前記応答信号が送信される第２のリソース群とを設定してもよい。

【0034】

また、端末２００において、後述する受信部２０１は、第１のアンテナポートで送信される第１のリファレンス信号、又は、第２のアンテナポートで送信される第２のリファレンス信号を受信する。後述する制御部２０２は、ランダムアクセスプリアンブルに対して、第１のアンテナポート及び第２のアンテナポートのいずれか一方で応答信号が送信される第１のリソース群と、ランダムアクセスプリアンブルに対して、第２のアンテナポートで応答信号が送信される第２のリソース群とのうち、一つを選択する。後述する送信部２０３は、選択された第１のリソース群又は第２のリソース群に含まれるリソースを用いてランダムアクセスプリアンブルを送信する。そして、後述する受信部２０１は、ランダムアクセスプリアンブルのリソースが第１のリソース群に含まれる場合、第１のアンテナポート又は第２のアンテナポートで送信された応答信号を受信する。また、受信部２０１は、ランダムアクセスプリアンブルのリソースが第２のリソース群に含まれる場合、第２のアンテナポートで送信された応答信号を受信する。

【0035】

以下では、基地局１００はＲｅｌ．１１に対応する基地局であり、端末２００は、Ｒｅｌ．１１に対応する端末であり、端末３００は、Ｒｅｌ．８からＲｅｌ．１０のいずれかに対応する端末であるものとして説明する。すなわち、基地局１００は、Ｒｅｌ．８からＲｅｌ．１１のそれぞれに対応する端末のすべてと通信可能である。また、端末２００は、Ｒｅｌ．８からＲｅｌ．１１のそれぞれに対応する基地局のすべてと通信可能である。また、端末３００は、Ｒｅｌ．８からＲｅｌ．１０のそれぞれに対応する基地局のすべてと通信可能であるが、Ｒｅｌ．１１に対応する基地局とは通信できない。また、第１のリファレンス信号は、ＤＭＲＳであり、第２のリファレンス信号は、ＣＲＳである。また、応答信号は、ＲＡＣＨ responseである。

【0036】

［基地局１００の構成］
図４は、本発明の実施の形態１に係る基地局１００の構成を示すブロック図である。図４において、基地局１００は、設定部１０１と、受信部１０２と、制御部１０３と、送信部１０４とを有する。

【0037】

設定部１０１は、ＤＭＲＳを用いたデータ送信（以下では、「ＤＭＲＳ送信」と呼ばれることがある）によって送信されたＲＡＣＨ responseを受信できる端末２００が選択可能な第１のＲＡＣＨ preambleリソース候補群（つまり、第１のリソースグループ）を設定する。また、設定部１０１は、ＤＭＲＳを用いたデータ送信によって送信されたＲＡＣＨ responseを受信できず且つＣＲＳを用いたデータ送信（以下では、「ＣＲＳ送信」と呼ばれることがある）によって送信されたＲＡＣＨ responseを受信できる端末３００が選択可能な第２のＲＡＣＨ preambleリソース候補群（つまり、第２のリソースグループ）を設定する。上述の通り、ＲＡＣＨ preambleリソース候補は、時間リソース、周波数リソース、及び系列リソースの組み合わせにより規定されるが、以下では、説明を簡単にするために、系列リソースによってのみ規定されるものとして説明する。

【0038】

設定された第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関する「リソース情報」は、報知信号に含められ（つまり、報知チャネルによって）、送信部１０４を介して端末２００又は端末３００へ報知される。なお、設定された第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関するリソース情報は、制御信号又はデータ信号に含められ（つまり、制御チャネル又はデータチャネルによって）、端末２００及び端末３００へ通知されてもよい。

【0039】

受信部１０２は、端末２００及び端末３００から送信されたＲＡＣＨ preambleを受信する。具体的には、受信部１０２は、受信信号と、ＲＡＣＨ preambleリソース候補に対応する系列レプリカとの相関を算出し、算出された相関値と所定の閾値とを比較する。そして、受信部１０２は、算出された相関値が所定の閾値より大きい場合、その相関値の算出に用いられた系列レプリカに対応するＲＡＣＨ preambleリソースにおいてＲＡＣＨ preambleが受信されたと判定する。ＲＡＣＨ preambleが検出されたＲＡＣＨ preambleリソースに関する情報は、制御部１０３へ出力される。

【0040】

また、受信部１０２は、基地局１００から、ＲＡＣＨ preambleの送信元端末である端末２００又は端末３００へ送信されたＲＡＣＨ responseによって送信元端末に対して指定された上り回線データリソースにおいて、送信元端末から送信された上り回線データ信号を受信する。

【0041】

制御部１０３は、ＲＡＣＨ responseの送信方法を選択する。すなわち、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信（つまり、第１の送信方法）を選択する。また、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信（つまり、第２の送信方法）を選択する。

【0042】

送信部１０４は、下り回線において、制御信号（例えば、ＰＤＣＣＨ信号）及びデータ信号（例えば、ＰＤＳＣＨ信号）を送信する。

【0043】

例えば、送信部１０４は、制御部１０３において選択された送信方法を用いてＲＡＣＨresponseを送信する。具体的には、送信部１０４は、制御部１０３においてＤＭＲＳ送信が選択された場合、ＲＡＣＨ responseと共にＤＭＲＳを送信する。このとき、ＲＡＣＨ responseとＤＭＲＳとは同一の位相関係によって送信される。つまり、送信されるＤＭＲＳと同一のアンテナポートを用いてＲＡＣＨ responseが送信される。また、例えば、アンテナ間において重み付けが施される場合には、ＲＡＣＨ responseとＤＭＲＳとは同一の重み付けが施された状態で送信される。ここで、ＤＭＲＳの送信アンテナポートは、予め決められている。例えば、Ｒｅｌ．１０では、ＤＭＲＳの送信アンテナポートは、ポート７〜１４を取りうるが、ＲＡＣＨ response向けのＤＭＲＳはポート７に決めておく。なお、他のデータ信号の送信又は受信品質測定のために、ＲＡＣＨ response及びＤＭＲＳと共に、ＣＲＳが同時に送信されてもよい。一方、送信部１０４は、制御部１０３においてＣＲＳ送信が選択された場合、ＲＡＣＨ responseと共にＣＲＳを送信する。このとき、ＲＡＣＨ responseとＣＲＳとは同一の位相関係によって送信される。つまり、送信されるＣＲＳと同一のアンテナポートを用いてＲＡＣＨ responseが送信される。ここで、ＣＲＳ送信の場合、ＲＡＣＨ responseが送信されるリソースブロックにおいてＤＭＲＳがＣＲＳと共に送信されることはない。

【0044】

また、送信部１０４は、ＲＡＣＨ responseがマッピングされるデータリソースに関する情報をＰＤＣＣＨによって送信する。このＰＤＣＣＨ信号は、ＲＡ−ＲＮＴＩと呼ばれる全端末に共通の識別子によってスクランブルされた状態で送信される。

【0045】

なお、送信部１０４は、RACH procedureにおけるＳｔｅｐ４（message 4送信)の際にも、ＲＡＣＨ responseの送信方法と同じ方法を用いる。

【0046】

また、アンテナポートとは、１本又は複数の物理アンテナから構成される、論理的なアンテナを指す。すなわち、アンテナポートは必ずしも１本の物理アンテナを指すとは限らず、複数のアンテナから構成されるアレイアンテナ等を指すことがある。例えば3GPP LTEにおいては、アンテナポートが何本の物理アンテナから構成されるかは規定されず、基地局が異なる参照信号（Reference signal）を送信できる最小単位として規定されている。さらに、アンテナポートはプリコーディングベクトル（Precoding vector）の重み付けを乗算する最小単位として規定されることもある。

【0047】

［端末２００の構成］
図５は、本発明に実施の形態１に係る端末２００の構成を示すブロック図である。図５において、端末２００は、受信部２０１と、制御部２０２と、送信部２０３とを有する。

【0048】

受信部２０１は、基地局１００から送信された報知信号を受信する。受信された報知信号には、第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関するリソース情報が含まれる。そして、受信部２０１は、受信された報知信号を制御部２０２へ出力する。

【0049】

また、受信部２０１は、基地局１００から送信された、ＰＤＣＣＨ信号及びＲＡＣＨresponseを受信する。具体的には、受信部２０１は、ＰＤＣＣＨ信号を受信し、受信されたＰＤＣＣＨ信号によって指定されているデータリソースにおいて、制御部２０２によって指定されるリファレンス信号（ＤＭＲＳ又はＣＲＳ）を用いて、ＲＡＣＨ responseを受信する。

【0050】

制御部２０２は、受信部２０１から受け取る報知信号に基づいて、送信部２０３において用いられる送信パラメータ、及び、受信部２０１において用いられる受信パラメータを設定する。

【0051】

具体的には、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、第１のＲＡＣＨ preambleリソース候補群の中からＲＡＣＨ preambleリソースを選択する。一方、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、報知信号に含まれているリソース情報が示す第２のＲＡＣＨ preambleリソース候補群からRACH preambleリソースを選択する。選択されたＲＡＣＨ preambleリソースに関する情報は、送信部２０３へ出力される。

【0052】

また、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＤＭＲＳを指定する。一方、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＣＲＳを指定する。

【0053】

また、制御部２０２は、受信部２０１において受信されたＰＤＣＣＨ信号によって指定されているデータリソースに関する情報を受信部２０１へ出力する。

【0054】

送信部２０３は、制御部２０２において選択されたＲＡＣＨ preambleリソースを用いて、ＲＡＣＨ preambleを送信する。

【0055】

［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００の動作について説明する。図６は、基地局１００及び端末２００の動作説明に供する図である。以下では、ＲＡＣＨ preambleリソースとして、６４個の系列が用意されている場合を例として説明する。

【0056】

＜基地局１００によるＲＡＣＨ preambleリソース候補群の設定＞
基地局１００において、設定部１０１は、ＤＭＲＳ送信によって送信されたＲＡＣＨresponseを受信できる端末２００が選択可能な第１のＲＡＣＨ preambleリソース候補群を設定する。また、設定部１０１は、ＤＭＲＳを用いたデータ送信によって送信されたＲＡＣＨ responseを受信できず且つＣＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末３００が選択可能な第２のＲＡＣＨ preambleリソース候補群を設定する。

【0057】

設定された第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関するリソース情報は、報知信号に含められ、送信部１０４を介して端末２００又は端末３００へ報知される。

【0058】

ここで、図６に示すように、基地局１００は、端末３００に対して第２のＲＡＣＨpreambleリソース候補群に関するリソース情報として、contention RACH（複数端末間の競合を伴うRACH）のリソース数であるＮｃＸを報知する。これにより、端末３００は、ＲＡＣＨpreambleリソース番号が１〜ＮｃＸ以外のＲＡＣＨ preambleリソースについては、non-contention RACHに用いられるＲＡＣＨ preambleリソースであると解釈する。

【0059】

また、基地局１００は、端末２００に対して第１のＲＡＣＨ preambleリソース候補群に関するリソース情報として、contention RACH（複数端末間の競合を伴うRACH）のリソース数であるＮｃＹを報知する。これにより、端末２００は、ＲＡＣＨ preambleリソース番号が１〜ＮｃＹ以外のＲＡＣＨ preambleリソースについては、non-contention RACHに用いられるＲＡＣＨ preambleリソースであると解釈する。また、端末２００は、ＲＡＣＨ preambleリソース番号がＮｃＸ＋１〜ＮｃＹのＲＡＣＨ preambleリソースを、第１のＲＡＣＨ preambleリソース候補群として解釈する。

【0060】

このように、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報としてＮｃＹを報知することにより、Ｒｅｌ．８〜Ｒｅｌ．１０において使用されているＮｃＸと同様の報知方法を再利用できると共に、Ｒｅｌ．８〜Ｒｅｌ．１０のバックワードコンパチビリティを維持できる。

【0061】

＜端末２００によるＲＡＣＨ preambleの送信＞
端末２００は、ＲＡＣＨ preambleリソース番号がＮｃＸ＋１〜ＮｃＹの第１のＲＡＣＨ preambleリソース候補群からＲＡＣＨ preambleリソースを選択し、選択されたＲＡＣＨ preambleリソースを用いてＲＡＣＨ preambleを送信する。

【0062】

＜端末３００によるＲＡＣＨ preambleの送信＞
端末３００は、ＲＡＣＨ preambleリソース番号がＮｃ１〜ＮｃＸの第２のＲＡＣＨ preambleリソース候補群からＲＡＣＨ preambleリソースを選択し、選択されたＲＡＣＨ preambleリソースを用いてＲＡＣＨ preambleを送信する。

【0063】

＜基地局１００によるＲＡＣＨ responseの送信方法の選択、及び、ＲＡＣＨ responseの送信＞
基地局１００において、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第１のリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信（つまり、第１の送信方法）を選択する。また、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第２のリソース候補群に含まれる場合、ＲＡＣＨresponseの送信方法として、ＣＲＳ送信（つまり、第２の送信方法）を選択する。

【0064】

送信部１０４は、制御部１０３においてＤＭＲＳ送信が選択された場合、ＲＡＣＨresponseと共にＤＭＲＳを送信する。一方、送信部１０４は、制御部１０３においてＣＲＳ送信が選択された場合、ＲＡＣＨ responseと共にＣＲＳを送信する。

【0065】

＜端末２００によるＰＤＣＣＨ信号及びＲＡＣＨ responseの受信＞
制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＤＭＲＳを指定する。一方、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＣＲＳを指定する。

【0066】

また、制御部２０２は、受信部２０１において受信されたＰＤＣＣＨ信号によって指定されているデータリソースに関する情報を受信部２０１へ出力する。ここで、ＰＤＣＣＨ信号は、ＲＡＣＨ preambleが送信されたサブフレームに依存したＲＡ−ＲＮＴＩによって基地局１００においてスクランブリングされている。このため、受信部２０１は、そのＲＡ−ＲＮＴＩによってデスクランブリングすることにより、ＰＤＣＣＨ信号を受信する。

【0067】

受信部２０１は、受信されたＰＤＣＣＨ信号によって指定されているデータリソースにおいて、制御部２０２によって指定されるリファレンス信号（ＤＭＲＳ又はＣＲＳ）を用いて、ＲＡＣＨ responseを受信する。

【0068】

ここで、端末２００に対してＮｃＹの情報が通知されていなければ、接続先の基地局が従来の基地局であると想定し、端末２００は、ＲＡＣＨ preambleリソース番号がＮｃ１〜ＮｃＸの第２のＲＡＣＨ preambleリソース候補群から選択されたＲＡＣＨ preambleリソースを用いてＲＡＣＨ preambleを送信する。また、この場合、端末２００は、ＲＡＣＨ responseをＣＲＳを用いて受信する。

【0069】

また、ＲＡＣＨ responseの送信よりも後の送信であって端末２００に対して送信モードが設定されるまでの送信（例えば、message 4の送信）においても、基地局１００は、端末２００に対してＤＭＲＳ送信によってＰＤＳＣＨを送信し、端末２００は、ＤＭＲＳを用いてＰＤＳＣＨを復調する。ここで、ＤＭＲＳの送信ポートは、例えばポート７に決められていてもよいし、ＰＤＣＣＨによって通知されてもよい。そして、端末２００に対して送信モードが設定された後は、送信モードに従ったＰＤＳＣＨの送信が行われる。

【0070】

以上のように本実施の形態によれば、基地局１００において、設定部１０１は、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末２００が選択可能な第１のＲＡＣＨ preambleリソース候補群を設定する。また、設定部１０１は、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できず且つＣＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末３００が選択可能な第２のＲＡＣＨ preambleリソース候補群を設定する。そして、制御部１０３は、ＲＡＣＨpreambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信を選択する。また、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信を選択する。

【0071】

こうすることにより、基地局１００は、ＲＡＣＨ preambleを検出したリソースに基づいて、ＲＡＣＨ preambleの送信元端末がＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末であるか否かを判断できる。このため、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末に対して、ＲＡＣＨ responseをDMRSによるRACH response受信をサポートする端末向けにＲＡＣＨ responseをＤＭＲＳ送信によって効率良く送信できる。

【0072】

そして、ＤＭＲＳ送信によればＭＢＳＦＮサブフレームにおいてもＲＡＣＨresponseを送信できるので、ｎｏｎ−ＭＢＳＦＮサブフレームにおけるリソース容量が圧迫されることが防止され、結果として、システム容量を増加できる。また、端末３００に対してＤＭＲＳ送信によってＲＡＣＨ responseが送信されることがないので、端末３００におけるＲＡＣＨpreambleの再送が増加することを防止できる。

【0073】

また、マクロセルにおける複数のＬＰＮに対してＨＰＮのセルＩＤと同じセルＩＤを用いるヘテロジニアスネットワーク環境においては、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末に対して、その端末が存在する位置に近い送信ポイントからのみ、ＲＡＣＨ responseを効率良く送信させることができる。例えば、基地局は、ＲＡＣＨpreambleの受信電力が高かった送信ポイントからのみ、ＲＡＣＨ responseを送信する。

【0074】

また、Extension carrierを用いたシステム運用においては、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末に対して、ＲＡＣＨ responseをExtension carrierにおいて効率良くＤＭＲＳ送信できる。また、backward compatible carrierの混雑を軽減することができる。

【0075】

なお、基地局１００において、制御部１０３は、第１のＲＡＣＨ preambleリソース候補群に含まれるＲＡＣＨ preambleリソースによって同じ処理期間に受信された複数のＲＡＣＨpreambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨ responseに含め、当該ＲＡＣＨ responseをＤＭＲＳ送信してもよい。また、制御部１０３は、第２のＲＡＣＨpreambleリソース候補群に含まれるＲＡＣＨ preambleリソースによって同じ処理期間に受信された複数のＲＡＣＨ preambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨresponseに含め、当該ＲＡＣＨ responseをＣＲＳ送信してもよい。

【0076】

［実施の形態２］
実施の形態２では、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseが送信されるサブフレームが「ＭＢＳＦＮサブフレーム」であるときにのみ、ＤＭＲＳ送信が選択される。一方、ＲＡＣＨ responseが送信されるサブフレームが「ｎｏｎ−ＭＢＳＦＮサブフレーム」であるときには、ＣＲＳ送信が選択される。ここで、「ＭＢＳＦＮサブフレーム」とは、先頭部を除くリソース領域においてＣＲＳをマッピングできず且つＤＭＲＳをマッピングできるサブフレームである。「ｎｏｎ−ＭＢＳＦＮサブフレーム」とは、先頭部を除くリソース領域にＤＭＲＳ及びＣＲＳをマッピングできるサブフレームである。なお、実施の形態２に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と同様であるので、図４，５を援用して説明する。

【0077】

実施の形態２の基地局１００において、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseが送信されるサブフレームが「ＭＢＳＦＮサブフレーム」であるときにのみ、ＤＭＲＳ送信を選択する。一方、制御部１０３は、ＲＡＣＨ responseが送信されるサブフレームが「ｎｏｎ−ＭＢＳＦＮサブフレーム」であるときには、ＣＲＳ送信を選択する。

【0078】

また、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、「ｎｏｎ−ＭＢＳＦＮサブフレーム」であるときにのみ、ＣＲＳ送信を選択する。すなわち、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、「ＭＢＳＦＮサブフレーム」であるときには、ＲＡＣＨ responseは送信されない。

【0079】

送信部１０４は、複数のＲＡＣＨ preambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨ responseに含め、当該ＲＡＣＨ responseを送信する。１つのＲＡＣＨ responseに含められる複数の応答メッセージは、同じ処理期間に受信された複数のＲＡＣＨ preambleに対応する。

【0080】

具体的には、制御部１０３は、ＲＡＣＨ responseが送信されるサブフレームが「ＭＢＳＦＮサブフレーム」であるときには、第１のＲＡＣＨ preambleリソース候補群に含まれるＲＡＣＨ preambleリソースによって送信された複数のＲＡＣＨ preambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨresponseに含める。そして、制御部１０３は、当該ＲＡＣＨ responseをＤＭＲＳ送信する。一方、制御部１０３は、ＲＡＣＨ responseが送信されるサブフレームが「ｎｏｎ−ＭＢＳＦＮサブフレーム」であるときには、送信に用いられたＲＡＣＨ preambleリソースが第１のＲＡＣＨ preambleリソース候補群に含まれるか第２のＲＡＣＨ preambleリソース候補群に含まれるかに拘わらず、複数のＲＡＣＨ preambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨ responseに含める。そして、制御部１０３は、当該ＲＡＣＨ responseをＣＲＳ送信する。

【0081】

端末２００の制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、ＲＡＣＨ responseを受信するサブフレームが「ＭＢＳＦＮサブフレーム」であるときには、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＤＭＲＳを指定する。一方、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、ＲＡＣＨ responseを受信するサブフレームが「ｎｏｎ−ＭＢＳＦＮサブフレーム」であるときには、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＣＲＳを指定する。

【0082】

以上のように本実施の形態によれば、基地局１００において、制御部１０３は、ＲＡＣＨpreambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、応答信号が送信されるサブフレームが先頭部を除くリソース領域にＣＲＳをマッピングできず且つＤＭＲＳをマッピングできる第１のサブフレーム（ＭＢＳＦＮサブフレーム）であるときにのみ、ＤＭＲＳ送信を選択する。また、制御部１０３は、応答信号が送信されるサブフレームが先頭部を除くリソース領域にＤＭＲＳ及びＣＲＳをマッピングできる第２のサブフレーム（ｎｏｎ−ＭＢＳＦＮサブフレーム）であるときには、ＣＲＳ送信を選択する。

【0083】

こうすることにより、ＭＢＳＦＮサブフレームにおいてＤＭＲＳ送信によってＲＡＣＨresponseを送信できるので、ｎｏｎ−ＭＢＳＦＮサブフレームにおけるリソース容量が圧迫されることが防止され、結果として、システム容量を増加できる。また、端末２００は、ｎｏｎ−ＭＢＳＦＮサブフレームにおいてはＣＲＳを用いた応答信号の受信のみを行えばよいので、制御を簡略化することができる。

【0084】

また、制御部１０３は、ＲＡＣＨ responseが送信されるサブフレームがｎｏｎ−ＭＢＳＦＮサブフレームであるときには、送信に用いられたＲＡＣＨ preambleリソースが第１のＲＡＣＨ preambleリソース候補群に含まれるか第２のＲＡＣＨ preambleリソース候補群に含まれるかに拘わらず、複数のＲＡＣＨ preambleにそれぞれ対応する複数の応答メッセージを１つのＲＡＣＨ responseに含める。そして、制御部１０３は、当該ＲＡＣＨ responseをＣＲＳ送信する。

【0085】

こうすることにより、特に、端末３００が多い場合には、ＰＤＣＣＨ及びＰＤＳＣＨの混雑を軽減できる。これは、端末３００が多い場合には、端末２００に対して端末３００とは別に、ＲＡＣＨ responseをＤＭＲＳ送信することにより得られる、伝送効率向上効果よりも、次のオーバーヘッド低減効果の方が上回るからである。すなわち、この場合、端末２００及び端末３００のそれぞれに対する複数の応答メッセージを１つのＲＡＣＨ responseに含めて送信することによる、ＰＤＣＣＨ又はＣＲＣのオーバーヘッド低減効果の方が、上記の伝送効率向上効果よりも上回る。

【0086】

なお、ｎｏｎ−ＭＢＳＦＮサブフレームにおいてＣＲＳ送信が選択されるかＤＭＲＳ送信が選択されるかについてＰＤＣＣＨによって基地局１００が端末２００に対して通知してもよい。この場合、端末２００は、その通知に従ってＲＡＣＨ responseを受信する。こうすることにより、基地局１００は、ｎｏｎ−ＭＢＳＦＮサブフレームにおいて、端末２００及び端末３００に対する応答メッセージを１つに纏めてＣＲＳ送信するか、又は、端末２００に対する応答メッセージを端末３００に対する応答メッセージと独立にＤＭＲＳ送信するかを、ＰＤＣＣＨ又はＰＤＳＣＨの混雑具合などに応じて選択できる。

【0087】

また、上記説明では、ＭＢＳＦＮサブフレーム及びｎｏｎ−ＭＢＳＦＮサブフレームを例にとり説明を行った。しかしながら、これに限定されるものではなく、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、他の２種類のサブフレームの一方ではＤＭＲＳ送信が選択され、他方ではＣＲＳ送信が選択されてもよい。

【0088】

［実施の形態３］
実施の形態３では、基地局と端末との間の伝搬減衰値（以下では、「パスロス」とも呼ばれることがある）が閾値より大きい第１のプリアンブル送信装置に対しては、第１のＲＡＣＨ preambleリソース候補群の内、第３のＲＡＣＨ preambleリソース候補群が設定される。また、実施の形態３では、基地局と端末との間の伝搬減衰値が閾値より小さい第１のプリアンブル送信装置に対しては、第１のＲＡＣＨ preambleリソース候補群の内、第３のＲＡＣＨ preambleリソース候補群に含まれない第４のＲＡＣＨ preambleリソース候補群が設定される。なお、実施の形態２に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と同様であるので、図４，５を援用して説明する。

【0089】

実施の形態３の基地局１００において、設定部１０１は、閾値（Ｔｈｐ）を設定する。閾値（Ｔｈｐ）は、ＲＡＣＨ preambleリソース候補群の選択基準として用いられる。

【0090】

また、設定部１０１は、自装置から送信されるＣＲＳの送信電力を設定する。

【0091】

送信方法決定テーブルに規定されている複数のＲＡＣＨ preambleリソース候補群に関するリソース情報、設定された閾値（Ｔｈｐ）に関する情報、及び、ＣＲＳ送信電力に関する情報は、報知信号に含められ（つまり、報知チャネルによって）、送信部１０４を介して端末２００又は端末３００へ報知される。なお、送信方法決定テーブルに規定されている複数のＲＡＣＨ preambleリソース候補群に関するリソース情報、設定された閾値（Ｔｈｐ）に関する情報、及び、送信電力に関する情報は、制御信号又はデータ信号に含められ（つまり、制御チャネル又はデータチャネルによって）、端末２００及び端末３００へ通知されてもよい。

【0092】

制御部１０３は、ＲＡＣＨ preambleが受信されたリソースと、送信方法決定テーブルとに基づいて、ＲＡＣＨ responseの送信方法を選択する。

【0093】

具体的には、送信方法決定テーブルでは、複数のＲＡＣＨ preambleリソース候補群が規定されており、各ＲＡＣＨ preambleリソース候補群に対して、ＤＭＲＳ送信又はＣＲＳ送信と、送信電力及び符号化率の少なくとも一方との組み合わせが対応付けられている。そして、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが含まれるＲＡＣＨ preambleリソース候補群に対応付けられた組み合わせを、送信方法として選択する。

【0094】

送信部１０４は、制御部１０３において選択された送信方法を用いてＲＡＣＨresponseを送信する。

【0095】

実施の形態３の端末２００において、受信部２０１は、基地局１００から送信された報知信号を受信する。受信された報知信号には、送信方法決定テーブルに規定されている複数のＲＡＣＨ preambleリソース候補群に関するリソース情報、閾値（Ｔｈｐ）に関する情報、及び、送信電力に関する情報が含まれている。そして、受信部２０１は、受信された報知信号を制御部２０２へ出力する。

【0096】

また、受信部２０１は、基地局１００から送信されたＣＲＳの受信電力を測定し、測定値を制御部２０２へ出力する。

【0097】

制御部２０２は、受信部２０１において測定されたＣＲＳ受信電力値と、基地局１００によるＣＲＳ送信電力値とに基づいて、基地局１００と端末２００との間の伝搬減衰量を算出する。

【0098】

そして、制御部２０２は、報知信号と、ＲＡＣＨ preambleリソース候補群の決定テーブルと、制御部２０２において算出された伝搬減衰量とに基づいて、送信部２０３において用いられる送信パラメータ、及び、受信部２０１において用いられる受信パラメータを設定する。

【0099】

例えば、制御部２０２は、報知信号と、ＲＡＣＨ preambleリソース候補群の決定テーブルと、制御部２０２において算出された伝搬減衰量とに基づいて、自装置が用いるＲＡＣＨ preambleリソース候補群を選択する。ＲＡＣＨ preambleリソース候補群の決定テーブルは、基地局１００の送信方法決定テーブルと同じである。

【0100】

具体的には、ＲＡＣＨ preambleリソース候補群の決定テーブルは、複数のＲＡＣＨ preambleリソース候補群が規定されており、各ＲＡＣＨ preambleリソース候補群に対して、ＤＭＲＳ送信又はＣＲＳ送信と、送信電力及び符号化率の少なくとも一方との組み合わせが対応付けられている。そして、各ＲＡＣＨ preambleリソース候補群は、伝搬減衰量と閾値（Ｔｈｐ）との大小関係が対応付けられている。

【0101】

以上の構成を有する基地局１００及び端末２００の動作について説明する。以下では、２つの送信方法決定テーブル（又は、ＲＡＣＨ preambleリソース候補群の決定テーブル）を例にとり説明する。

【0102】

［テーブル例１］
図７は、送信方法決定テーブルの第１の例を示す図である。図７に示すテーブルにおいて、第１のＲＡＣＨ preambleリソース候補群は２つに分割され、グループ１Ａ及びグループ１Ｂとされている。また、第２のＲＡＣＨ preambleリソース候補群も２つに分割され、グループ２Ａ及びグループ２Ｂとされている。

【0103】

＜基地局１００によるＲＡＣＨ preambleリソース候補群の設定＞
基地局１００において、設定部１０１は、グループ１Ａ、グループ１Ｂ、グループ２Ａ及びグループ２Ｂにそれぞれ対応する４つのＲＡＣＨ preambleリソース候補群を設定する。ここで、実施の形態１で報知されたＮｃＸ及びＮｃＹに加えて、グループ１Ａとグループ１Ｂとの境界を示すＮｃＹ_pl及びグループ２Ａとグループ２Ｂとの境界を示すＮｃＸ_plが報知される。これにより、端末２００は、グループ１Ａ、グループ１Ｂ、グループ２Ａ及びグループ２Ｂを特定できる。

【0104】

＜端末２００によるＲＡＣＨ preambleの送信＞
端末２００は、ＲＡＣＨ preambleリソース候補群の決定テーブルと、制御部２０２において算出された伝搬減衰量とに基づいて、自装置が用いるＲＡＣＨ preambleリソース候補群を選択する。

【0105】

具体的には、端末２００は、算出された伝搬減衰量が閾値Ｔｈｐ以上である場合、自装置が用いるＲＡＣＨ preambleリソース候補群として、グループ１Ａを選択する。一方、算出された伝搬減衰量が閾値Ｔｈｐより小さい場合、端末２００は、自装置が用いるＲＡＣＨ preambleリソース候補群として、グループ１Ｂを選択する。

【0106】

＜基地局１００によるＲＡＣＨ responseの送信方法の選択、及び、ＲＡＣＨ responseの送信＞
基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ１Ａに含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。これは、ＲＡＣＨ preambleが受信されたリソースがグループ１Ａに含まれる場合、ＲＡＣＨpreambleの送信元端末は、ＤＭＲＳ送信をサポートした端末であり、且つ、伝搬減衰量が大きい（つまり、通信品質が劣悪な）端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を多くしてもよい。

【0107】

また、基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ１Ｂに含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。これは、ＲＡＣＨ preambleが受信されたリソースがグループ１Ｂに含まれる場合、ＲＡＣＨpreambleの送信元端末は、ＤＭＲＳ送信をサポートした端末であり、且つ、伝搬減衰量が小さい（つまり、通信品質が良好な）端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を少なくしてもよい。

【0108】

また、基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ２Ａに含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。

【0109】

また、基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ２Ｂに含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。

【0110】

以上のように、第１のＲＡＣＨ preambleリソース候補群及び第２のＲＡＣＨ preambleリソース候補群のそれぞれを伝搬減衰量に基づいてさらにグループ分けすることにより、基地局１００は、ＲＡＣＨ preambleの送信元端末の伝搬路状態を知ることができる。これにより、基地局１００は、必要十分な送信電力によってＲＡＣＨ responseを送信できる。また、基地局１００が必要十分な上り回線リソースを割り当て可能であるので、端末２００が効率よく上り回線データを送信できる。

【0111】

［テーブル例２］
図８は、送信方法決定テーブルの第２の例を示す図である。図８に示すテーブルにおいて、第２のＲＡＣＨ preambleリソース候補群も２つに分割され、グループ２Ａ及びグループ２Ｂとされている。これに対して、第１のＲＡＣＨ preambleリソース候補群は分割されず、グループ１とされている。

【0112】

＜基地局１００によるＲＡＣＨ preambleリソース候補群の設定＞
基地局１００において、設定部１０１は、グループ１、グループ２Ａ及びグループ２Ｂにそれぞれ対応する３つのＲＡＣＨ preambleリソース候補群を設定する。ここで、図９に示すように、実施の形態１で報知されたＮｃＸ及びＮｃＹに加えて、グループ２Ａとグループ２Ｂとの境界を示すＮｃＸ_plが報知される。これにより、端末２００は、グループ１、グループ２Ａ及びグループ２Ｂを特定できる。すなわち、端末２００は、例えば、ＲＡＣＨ preambleリソース番号が１〜ＮｃＸ_plのＲＡＣＨ preambleリソースをグループ２Ａと解釈し、ＲＡＣＨ preambleリソース番号がＮｃＸ_pl＋１〜ＮｃＹのＲＡＣＨ preambleリソースをグループ２Ｂと解釈する。

【0113】

＜端末２００によるＲＡＣＨ preambleの送信＞
端末２００は、制御部２０２において算出された伝搬減衰量が閾値Ｔｈｐより小さい場合、ＲＡＣＨ preambleリソース番号がＮｃＸ＋１〜ＮｃＹのグループ１からＲＡＣＨpreambleリソースを選択し、選択されたＲＡＣＨ preambleリソースを用いてＲＡＣＨ preambleを送信する。

【0114】

一方、端末２００は、制御部２０２において算出された伝搬減衰量が閾値Ｔｈｐ以上である場合、ＲＡＣＨ preambleリソース番号が１〜ＮｃＸ_plのグループ２ＡからＲＡＣＨ preambleリソースを選択し、選択されたＲＡＣＨ preambleリソースを用いてＲＡＣＨ preambleを送信する。すなわち、制御部２０２において算出された伝搬減衰量が閾値Ｔｈｐ以上である場合に用いられるＲＡＣＨ preambleリソース候補群は、端末２００と端末３００との間で共通する。

【0115】

＜基地局１００によるＲＡＣＨ responseの送信方法の選択、及び、ＲＡＣＨ responseの送信＞
基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ１に含まれる場合、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。これは、ＲＡＣＨ preambleが受信されたリソースがグループ１に含まれる場合、ＲＡＣＨpreambleの送信元端末は、ＤＭＲＳ送信をサポートした端末であり、且つ、伝搬減衰量が大きい（つまり、通信品質が劣悪な）端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を多くしてもよい。

【0116】

また、基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ２Ａに含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。

【0117】

また、基地局１００は、ＲＡＣＨ preambleが受信されたリソースがグループ２Ｂに含まれる場合、ＲＡＣＨ responseの送信方法として、ＣＲＳ送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。

【0118】

ここで、テーブル例１では細かくグループ分けされる。このため、１グループあたりのリソース量が少なくなるので、ＲＡＣＨ preambleリソースが特定のグループに偏る確率が高くなり、この結果として、ＲＡＣＨpreamble同士が衝突する確率が高くなる。一方、テーブル例２では端末２００にのみ割り当てられるグループが１つであるのでＲＡＣＨ preamble同士が衝突する確率が低減できる。また、同一セルＩＤを用いたＣｏＭＰ運用においては、受信品質の劣悪な端末２００（例えば、セル境界付近に存在する端末２００）に対しては、ＲＡＣＨ responseが全送信ポイントからＣＲＳ送信されることが適切であり、ＤＭＲＳ送信されることによる高効率化のメリットは小さい。このため、伝搬減衰量が大きい端末２００向けには、ＲＡＣＨ responseがＣＲＳ送信されても非効率になることはない。

【0119】

なお、Ｒｅｌ．８〜Ｒｅｌ．１０では、上り回線における送信データ量に応じたＲＡＣＨpreambleリソースのグループが設定される。上記説明では、端末３００に対しても伝搬路減衰量によるグループ分けを行ったが、これに限定されるものではなく、さらに、送信データ量に応じたグループ分けを行ってもよい。こうすることにより、検出したＲＡＣＨ preambleのグループによって上り回線に割り当てるリソース量を適切に制御できるので、必要十分なリソースで効率良く上り回線データを伝送できる。

【0120】

また、上記説明では、伝搬減衰量を例に説明したが、これに限定されるものではなく、受信電力、ＳＩＲ、又は、ＳＩＮＲなどが用いられてもよい。

【0121】

［実施の形態４］
実施の形態１では、ＲＡＣＨ preambleが受信されたリソースが含まれるＲＡＣＨ preambleリソース候補群に応じて、ＲＡＣＨ responseの送信方法として、ＤＭＲＳ送信又はＣＲＳ送信を選択した。これに対して、実施の形態４では、第１の端末グループに割り当てられる第１のＲＡＣＨ preambleリソース候補群と、第２の端末グループに割り当てられる第２のＲＡＣＨpreambleリソース候補群とが設定される。また、実施の形態４では、第１の端末グループと第２の端末グループとに対して、互いに異なる再送判定期間が設定される。また、実施の形態４では、ＲＡＣＨ preambleが受信されたリソースが含まれるＲＡＣＨ preambleリソース候補群に応じて、ＲＡＣＨ responseの送信タイミングが調整される。

【0122】

［基地局４００の構成］
図１０は、本発明の実施の形態４に係る基地局４００の構成を示すブロック図である。図１０において、基地局４００は、設定部４０１と、受信部４０２と、制御部４０３と、送信部４０４とを有する。

【0123】

設定部４０１は、第１の端末グループが使用する第１のＲＡＣＨ preambleリソース候補群と、第２の端末グループが使用する第２のＲＡＣＨ preambleリソース候補群とを設定する。設定された第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関する「リソース情報」は、報知信号に含められ（つまり、報知チャネルによって）、送信部４０４を介して端末５００へ報知される。

【0124】

また、設定部４０１は、第１の端末グループが使用する第１の再送判定期間と、第２の端末グループが使用する第２の再送判定期間とを設定する。設定された第１の再送判定期間及び第２の再送判定期間に関する期間情報は、報知信号に含められ（つまり、報知チャネルによって）、送信部４０４を介して端末５００へ報知される。第１の再送判定期間は、第２の再送判定期間よりも短い。ここで、再送判定期間は、タイムウィンドウである。タイムウィンドウの大きさは、window size(RRCパラメータ：ra-ResponseWindowSize)と呼ばれることがある。

【0125】

受信部４０２は、端末５００から送信されたＲＡＣＨ preambleを受信する。

【0126】

制御部４０３は、ＲＡＣＨ responseの送信方法を選択する。すなわち、制御部４０３は、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第１の送信タイミングを選択する。また、制御部４０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第２の送信タイミングを選択する。ここで、第１の送信タイミングは、ＲＡＣＨ preambleが検出されたサブフレームの３サブフレーム後を始点とし且つ第１のwindow sizeの幅を持つ期間内に含まれる。また、第２の送信タイミングは、ＲＡＣＨ preambleが検出されたサブフレームの３サブフレーム後を始点とし且つ第２のwindow sizeの幅を持つ期間内に含まれる一方、ＲＡＣＨ preambleが検出されたサブフレームの３サブフレーム後を始点とし且つ第１のwindow sizeの幅を持つ期間内には含まれない。すなわち、第１の送信タイミングは、第１の再送判定期間に応じたタイミングであり、第２の送信タイミングは、第２の再送判定期間に応じたタイミングである。ここで、第１の再送判定期間は第２の再送判定期間よりも短い。

【0127】

送信部４０４は、制御部４０３において選択された送信方法（つまり、送信タイミング）を用いてＲＡＣＨ responseを送信する。また、送信部４０４は、ＲＡＣＨ responseがマッピングされるデータリソースに関する情報をＰＤＣＣＨによって送信する。

【0128】

［端末５００の構成］
図１１は、本発明に実施の形態４に係る端末５００の構成を示すブロック図である。図１１において、端末５００は、受信部５０１と、制御部５０２と、送信部５０３とを有する。

【0129】

受信部５０１は、基地局４００から送信された報知信号を受信する。受信された報知信号には、第１のＲＡＣＨ preambleリソース候補群又は第２のＲＡＣＨ preambleリソース候補群に関するリソース情報が含まれる。また、受信された報知信号には、設定された第１の再送判定期間及び第２の再送判定期間に関する期間情報が含まれる。そして、受信部５０１は、受信された報知信号を制御部５０２へ出力する。

【0130】

また、受信部５０１は、基地局１００から送信されたＲＡＣＨ responseを、制御部５０２によって指定される再送判定期間において受信する受信処理を実行する。

【0131】

制御部５０２は、自装置が第１の端末グループに属している場合、第１のＲＡＣＨpreambleリソース候補群の中からＲＡＣＨ preambleリソースを選択する。一方、制御部５０２は、自装置が第２の端末グループに属している場合、第２のＲＡＣＨ preambleリソース候補群の中からＲＡＣＨ preambleリソースを選択する。選択されたＲＡＣＨ preambleリソースに関する情報は、送信部５０３へ出力される。

【0132】

また、制御部５０２は、自装置が第１の端末グループに属している場合、受信部５０１に対して第１の再送判定期間を指定する。一方、制御部５０２は、自装置が第２の端末グループに属している場合、受信部５０１に対して第２の再送判定期間を指定する。ここで、第１の再送判定期間は、ＲＡＣＨ preambleが送信されたサブフレームの３サブフレーム後を始点とし且つ第１のwindow sizeの幅を持つ期間である。一方、第２の再送判定期間は、ＲＡＣＨ preambleが送信されたサブフレームの３サブフレーム後を始点とし且つ第２のwindow sizeの幅を持つ期間である。

【0133】

送信部５０３は、制御部５０２において選択されたＲＡＣＨ preambleリソースを用いて、ＲＡＣＨ preambleを送信する。

【0134】

以上のように本実施の形態によれば、基地局４００において、設定部４０１は、第１の端末グループが使用する第１のＲＡＣＨ preambleリソース候補群と、第２の端末グループが使用する第２のＲＡＣＨpreambleリソース候補群とを設定する。また、設定部４０１は、第１の端末グループが使用する第１の再送判定期間と、第２の端末グループが使用する第２の再送判定期間とを設定する。第１の再送判定期間は、第２の再送判定期間よりも短い。そして、制御部４０３は、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第１の送信タイミングを選択する。一方、制御部４０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第２の送信タイミングを選択する。ここで、第１の再送判定期間は第２の再送判定期間よりも短い。

【0135】

なお、上記説明では、再送判定期間がタイムウィンドウであるものとして説明を行ったが、これに限定されるものではなく、タイムウィンドウとバックオフタイムとの和であってもよい（図１２参照）。

【0136】

またなお、実施の形態４は、実施の形態１乃至３のいずれかと組み合わせることもできる。例えば、実施の形態１と実施の形態４とを組み合わせた場合には、基地局１００において、設定部１０１は、ＤＭＲＳを用いたデータ送信（以下では、「ＤＭＲＳ送信」と呼ばれることがある）によって送信されたＲＡＣＨ responseを受信できる端末２００が選択可能な第１のＲＡＣＨ preambleリソース候補群を設定する。加えて、設定部１０１は、ＤＭＲＳを用いたデータ送信によって送信されたＲＡＣＨ responseを受信できず且つＣＲＳを用いたデータ送信（以下では、「ＣＲＳ送信」と呼ばれることがある）によって送信されたＲＡＣＨ responseを受信できる端末３００が選択可能な第２のＲＡＣＨ preambleリソース候補群とを設定する。また、設定部１０１は、端末２００が使用する第１の再送判定期間と、端末３００が使用する第２の再送判定期間とを設定する。そして、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第１のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第１の送信タイミング及びＤＭＲＳ送信を選択する。加えて、制御部１０３は、ＲＡＣＨ preambleが受信されたリソースが第２のＲＡＣＨ preambleリソース候補群に含まれる場合、ＲＡＣＨ responseの送信方法として、第２の送信タイミング及びＣＲＳ送信を選択する。そして、端末２００において、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＤＭＲＳを指定し、第１の再送判定期間を指定する。一方、制御部２０２は、第１のＲＡＣＨ preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、ＲＡＣＨ responseの受信に使用するリファレンス信号として、受信部２０１に対してＣＲＳを指定し、第２の再送判定期間を指定する。

【0137】

このように基地局１００が端末２００に対して端末３００とはwindow sizeを設定することにより、以下の効果が得られる。フレーム内に多くのＭＢＳＦＮサブフレームを設定した場合（例えば、図２）には、端末３００は、ＲＡＣＨ responseをＭＢＳＦＮサブフレームで受信できないため、長いwindow sizeが必要となる。一方、端末２００はＭＢＳＦＮサブフレームにおいてＲＡＣＨ responseを受信できる。このため、端末２００に対して端末３００とは別に短いwindow sizeを設定することにより、ＲＡＣＨ再送までの時間を短縮できる。従って、ＲＡＣＨ procedureを完了させるまでの遅延を低減できる。なお、window内にＲＡＣＨ responseを検出しなかった場合に、再送までの遅延時間であるバックオフタイムが設定される場合もある。このとき、端末２００の第１のバックオフタイムと端末３００の第２のバックオフタイムとを異ならせてもよい。この場合、第１のバックオフタイムは、第２のバックオフタイムよりも短くしてもよい。これは、端末２００に対してＲＡＣＨ responseを送信できるリソース（サブフレーム，component carrier）は多いので、頻繁にＲＡＣＨが送信されても、ＲＡＣＨ responseの容量が十分に残されているためである。これとは反対に、第１のバックオフタイムは、第２のバックオフタイムよりも長くしてもよい。これは、第２のタイムウィンドウが第１のタイムウィンドウよりも長く設定されるので、第２のバックオフタイムを短く設定することにより、端末３００の遅延を低減できるためである。

【0138】

［他の実施の形態］
［１］上記実施の形態におけるＲＡＣＨ preambleリソース候補群を示すＮｃＸはＲｅｌ．１０におけるRRCパラメータであるnumberOfRA-Preamblesとしてもよい．

【0139】

［２］上記各実施の形態において、端末２００（又は端末５００）に対するＲＡＣＨresponseは、ＤＭＲＳ送信される制御チャネル（例えば、データリソースを用いて送信されるＥ−ＰＤＣＣＨ）によって送信されてもよい。この場合、制御チャネルもＤＭＲＳによって効率良く送信される。

【0140】

［３］上記各実施の形態ではＲＡＣＨを例に説明を行ったが、contention baseの送信方法であれば、ＰＵＳＣＨ（又はＰＵＣＣＨ）であってもよい。例えば、ＤＭＲＳ受信をサポートしていない端末は、ＲＡＣＨを用いる一方、ＤＭＲＳ受信をサポートしている端末は、contention PUSCH（又はPUCCH）を用いる。又は、ＰＵＳＣＨリソースにおいて、ＤＭＲＳ受信をサポートしていない端末向けのリソース群と、ＤＭＲＳ受信をサポートしている端末向けのリソース群とを分けてもよい。

【0141】

［４］上記各実施の形態において、ＲＡＣＨ responseメッセージをＤＭＲＳ送信する場合には、例えば、１つのアンテナポート（例えば、アンテナポート７）に固定してもよいし、複数のアンテナポートが用いられてもよい（例えば、送信ダイバーシチなどでもよい）。また、使用されるアンテナポートが、端末に対して、予め通知（又は報知）されてもよい。

【0142】

［５］ＲＡＣＨ preambleの第１のリソースグループと第２のリソースグループは、以下のように使い分けられてもよい。
（１）Idle状態からConnected状態への遷移のためのＲＡＣＨ preamble送信のときには、第２のリソースグループが用いられ、それ以外のときには、第１のリソースグループが用いられる。これにより、Idle状態からの遷移の場合には、端末の能力によらずユーザの接続機会を公平に扱うことができる。
（２）Extension carrierにおいてＲＡＣＨ responseを受信できる端末は、第１のリソースグループを用いる。これにより、基地局がExtension carrierにＲＡＣＨ responseを送信できるので、通常のcomponent carrierの混雑を回避できる。
（３）ＣｏＭＰにおいて送信ポイント（RRH(Remote Radio Head)など）の近傍に存在する場合には、端末は、第１のリソースグループを用い、それ以外の場合には、第２のリソースグループを用いる。端末は、送信ポイントの近傍にいるか否かを、各送信ポイントからのＣＳＩ−ＲＳの受信電力に関する測定結果等に基づいて、判断する。これにより、送信ポイントから離れた端末に対してはマクロ基地局を含めた全ＲＲＨから、ＲＡＣＨ responseをＣＲＳ送信し、送信ポイントの近傍にいる端末に対してのみ、ＲＡＣＨresponseをＤＭＲＳ送信できる。この結果として、よりロバスト且つ効率的な運用が可能となる。

【0143】

また、送信ポイント毎に異なるＲＡＣＨ preambleリソース候補がグループ化されてもよい。この場合、端末は、どの送信ポイントの近傍に存在するかについての情報をネットワークに知らせることができる。この結果として、基地局による、各端末に使用する送信ポイントの選択が容易になる。

【0144】

［６］実施の形態４において、window sizeの他に、以下のパラメータが、ＤＭＲＳ送信されたＲＡＣＨ responseを受信できる端末に対して別途設定されてもよい。
（１）mac-ContentionResolutionTimer：
このパラメータは、message 3を送信してからmessage 4を待ち受けている時間である。Ｒｅｌ．１１向けにはmessage 4に使えるリソースが多いのでタイマーを短く設定する。
（２）maxHARQ-Msg3Tx：
このパラメータは、message 3の最大再送回数(1〜8)である。ＤＭＲＳ向けのＲＡＣＨpreambleリソースはＲＲＨ近傍の端末によって用いられるので、このＲＡＣＨ preambleリソースに対しては少ない再送回数を設定する。
（３）powerRampingStep：
このパラメータは、ＲＡＣＨ preamble再送ごとの電力増加量(0,2,4,6dB)である。ＤＭＲＳ向けのＲＡＣＨリソースは、ＲＲＨ近傍の端末によって用いられるので、他セルへの干渉が小さい。このため、より早く基地局でＲＡＣＨ preambleが受信されるように、大きいステップを設定する。
（４）preambleInitialReceivedTargetPower：
このパラメータは、ＲＡＣＨ preamble受信電力のターゲット値(-120〜-90dBm)である。ＤＭＲＳＤＭＲＳ向けのＲＡＣＨリソースは、ＲＲＨ近傍の端末によって用いられるので、他セルへの干渉が小さい。このため、より早く基地局でＲＡＣＨ preambleが受信されるように高いターゲット値を設定する。
（５）preambleTransMax：
このパラメータは、ＲＡＣＨ preambleの最大再送回数(3〜200)である。ＤＭＲＳはＭＢＳＦＮサブフレーム、extension carrierで使用されるので、ＤＭＲＳ向けのＲＡＣＨresponse用のリソースが多い。このため、ＲＡＣＨ preambleが頻繁に送信されても問題ないので、多い最大再送回数を設定する。

【0145】

［７］上記各実施の形態において、ＤＭＲＳ送信によって送信されたＲＡＣＨresponseを受信できる端末と、それ以外の端末とで、異なるＲＡ−ＲＮＴＩが用いられてもよい。また、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末と、それ以外の端末とで、異なるＥ−ＰＤＣＣＨが用いられてもよい。これにより、ＤＭＲＳ送信によって送信されたＲＡＣＨ responseを受信できる端末と、それ以外の端末とで、ＲＡＣＨ responseメッセージが送信されるＰＤＳＣＨを割り当てるためのＰＤＣＣＨを区別できる。

【0146】

［８］実施の形態１では、端末２００において、ＲＡＣＨ preambleリソース番号がＮｃＸ＋１〜ＮｃＹのＲＡＣＨ preambleリソースが第１のＲＡＣＨ preambleリソース候補群として解釈されたが、ＲＡＣＨ preambleリソース番号が１〜ＮｃＸのＲＡＣＨ preambleリソースが第１のＲＡＣＨ preambleリソース候補群として解釈されてもよい。この場合、ＮｃＸ＋１〜ＮｃＹのＲＡＣＨ preambleリソースと、１〜ＮｃＸのＲＡＣＨ preambleリソースとに対して、異なる選択確率を設定することにより、端末２００のみが選択可能なＮｃＸ＋１〜ＮｃＹのリソースを高い確率で選択するようにしてもよい。

【0147】

また、ハンドオーバー時など端末がRRC connected状態（あるいはActive状態）のときには、基地局１００がＲＡＣＨ preambleリソースを明示的に指定できるが、このときに、１〜ＮｃＸのＲＡＣＨ preambleリソース及びＮｃＸ＋１〜ＮｃＹのリソースのいずれを、基地局１００が指定するかによって、ＲＡＣＨ responseの送信に用いるＲＳを変更できる。例えば、Ｒｅｌ．８〜Ｒｅｌ．１０の端末が多い場合には、１〜ＮｃＸのリソースを指定し且つＲＡＣＨ responseをＣＲＳ送信することにより、複数の端末にそれぞれ対応する複数のＲＡＣＨresponseを纏めて送信する。又は、同一セルＩＤを用いたＣｏＭＰ運用時に、特定の送信ポイントの近傍に存在する端末に対しては、ＮｃＸ＋１〜ＮｃＹのリソースを指定し且つＲＡＣＨ responseをその特定の送信ポイントからのみＤＭＲＳ送信できる。

【0148】

[９]上記実施の形態において、Extension carrierはNew carrier typeと呼ばれることもある。また、Extension carrierは、下り制御チャネル送信領域がなく、PDCCH、PHICH(Physical Hybrid-ARQ Indicator Channel：下りリンクのACK/NACKチャネル)、PCFICH（Physical Control Format Indicator Channel）が送信されないキャリアとして規定される場合もある。

【0149】

［１０］上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。

【0150】

また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部または全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

【0151】

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続または設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。

【0152】

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

【0153】

２０１１年８月５日出願の特願２０１１−１７１９４５の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

【産業上の利用可能性】

【0154】

本発明の端末装置及び通信方法は、プリアンブル送信装置から送信されたランダムアクセスプリアンブルに対する応答信号を効率良く送信するものとして有用である。

【符号の説明】

【0155】

１００，４００ 基地局
１０１，４０１ 設定部
１０２，２０１，４０２，５０１ 受信部
１０３，２０２，４０３，５０２ 制御部
１０４，２０３，４０４，５０３ 送信部
２００，３００，５００ 端末

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】