• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 訂正 ただし書き2号誤記又は誤訳の訂正 訂正する H04W
管理番号 1354378
審判番号 訂正2019-390055  
総通号数 238 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2019-10-25 
種別 訂正の審決 
審判請求日 2019-05-13 
確定日 2019-07-19 
訂正明細書 有 
事件の表示 特許第6249310号に関する訂正審判事件について、次のとおり審決する。 
結論 特許第6249310号の明細書,特許請求の範囲を本件審判請求書に添付された訂正明細書,特許請求の範囲のとおり訂正することを認める。 
理由 第1 手続の経緯

本件訂正審判の請求に係る特許第6249310号は,2012年(平成24年)7月20日(優先権主張 平成23年8月5日)を国際出願日とする特願2013-527852号の一部を,平成28年8月23日に新たな特許出願としたものであって,その請求項1-14に係る発明について平成29年12月1日に特許権の設定登録がされ,令和1年5月13日に本件訂正審判の請求がされたものである。

第2 請求の趣旨及び訂正の内容

本件訂正審判の請求の趣旨は,特許第6249310号の明細書及び特許請求の範囲を,本件審判請求書に添付した訂正明細書,特許請求の範囲のとおり訂正することを認める,との審決を求めるものであり,その訂正の内容は、次の訂正事項からなる。

1 訂正事項1

特許請求の範囲の請求項1に「前記報知信号が前記第1のリソース群に含まれて」と記載されているのを,「前記報知信号に,前記第1のリソース群に関するリソース情報が含まれて」に訂正する。
特許請求の範囲の請求項1に「前記報知信号が含まれるリソース群に応じて」と記載されているのを,「前記報知信号に含まれるリソース群に関するリソース情報に応じて」に訂正する。(請求項1の記載を引用する請求項2?7,請求項1のカテゴリ変更に相当する請求項8,及び,請求項8を引用する請求項9?14も同様に訂正する)。(下線は、訂正箇所を示す。以下同様。)

2 訂正事項2
願書に添付した明細書の段落【0026】に記載された「前記報知信号が前記第1のリソース群に含まれて」を,「前記報知信号に,前記第1のリソース群に関するリソース情報が含まれて」に訂正する。
願書に添付した明細書の段落【0026】に記載された「前記報知信号が含まれるリソース群に応じて」と記載されているのを,「前記報知信号に含まれるリソース群に関するリソース情報に応じて」に訂正する。(願書に添付した明細書の段落【0027】も同様に訂正する)。

第3 当審の判断

1 訂正事項1について

(1)訂正の目的について

訂正前の請求項1には,「前記報知信号が前記第1のリソース群に含まれて」,「前記報知信号が含まれるリソース群に応じて」との発明特定事項が記載されているところ,当該発明特定事項の前には「第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号」との記載がある。
「前記報知信号が前記第1のリソース群に含まれて」との記載,及び「前記報知信号が含まれるリソース群に応じて」との記載に対して,前記「第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号」との記載は,「報知信号」と「第1のリソース群」との包含関係に関して正反対の状態を表しており,どちらかの記載が誤記であることは明らかである。そして,例えば明細書の段落【0048】に「報知信号には・・・リソース情報が含まれる。」,及び段落【0051】,【0052】に「リソース情報が報知信号に含まれている」と記載されており,「リソース情報が報知信号に含まれる」ことは当該技術分野において技術常識であるから,「前記報知信号が前記第1のリソース群に含まれて」,「前記報知信号が含まれるリソース群に応じて」の記載は明らかに誤記であり,「第1のリソース群・・・に関するリソース情報を含む報知信号」との記載が正しい記載であることは明らかである。

上記を踏まえると,訂正前の請求項1の「前記報知信号が前記第1のリソース群に含まれて」,「前記報知信号が含まれるリソース群に応じて」を,「前記報知信号に,前記第1のリソース群に関するリソース情報が含まれて」,「前記報知信号に含まれるリソース群に関するリソース情報に応じて」に訂正することは,明細書、特許請求の範囲又は図面の記載などから明らかな字句・語句の誤りを,本来の正しい記載に訂正しようとするものである。

してみると,訂正事項1は,明らかに誤った記載を正すものと言えるから,特許法第126条第1項ただし書第2号に掲げる,誤記の訂正を目的とする訂正に該当する。

(2)新規事項の追加について

上記「(1)」で述べたとおり,訂正前の請求項1の「前記報知信号が前記第1のリソース群に含まれて」,「前記報知信号が含まれるリソース群に応じて」との記載は,「前記報知信号に,前記第1のリソース群に関するリソース情報が含まれて」,「前記報知信号に含まれるリソース群に関するリソース情報に応じて」の誤記である。そして,訂正事項1は,当該誤記を訂正するものであり,訂正前後の特許請求の範囲の記載が示す内容に変化がないから,新たな技術的事項を導入するものではない。

よって、訂正事項1は,願書に添付した明細書に記載した事項の範囲内の訂正であり,特許法第126条第5項の規定に適合するものである。

(3)訂正により実質上特許請求の範囲を拡張又は変更することについて

上記「(2)」で述べたとおり,訂正事項1は,誤記を訂正したものであるから、訂正事項1は,実質上特許請求の範囲を拡張し又は変更するものでない。

よって、訂正事項1は、特許法第126条第6項の規定に適合する。

(4)独立特許要件について

訂正後の特許請求の範囲の請求項1ないし14に記載されている事項により特定される発明には,特許出願の際独立して特許を受けることができないとする理由を発見しない。

したがって,訂正事項1は、特許法第126条第7項の規定に適合する。

2 訂正事項2について

(1)訂正の目的について

訂正事項2は,特許請求の範囲の請求項1,8に対応する明細書の段落【0026】,【0027】の記載について,前記訂正事項1と同様の訂正をするものであるから,特許法第126条第1項ただし書第2項に掲げる誤記の訂正を目的とする訂正に該当する。

(2)新規事項の追加について

訂正事項2は,特許請求の範囲の請求項1,8に対応する明細書の段落【0026】,【0027】について、訂正事項1と同様の誤記の訂正をしたものである。
したがって,訂正事項2は,願書に添付した明細書に記載した事項の範囲内の訂正であり,特許法第126条第5項の規定に適合するものである。

(3)訂正により実質上特許請求の範囲を拡張又は変更することについて

訂正事項2は,特許請求の範囲の請求項1,8に対応する明細書の段落【0026】,【0027】について,訂正事項1と同様の誤記の訂正をしたものであり,実質上特許請求の範囲を拡張し,又は変更するものには該当しないから,訂正事項2は特許法第126条第6項に適合するものである。

(4)独立特許要件について

訂正後の特許請求の範囲の請求項1ないし14に記載されている事項により特定される発明には、特許出願の際独立して特許を受けることができないとする理由を発見しない。

したがって,訂正事項2は、特許法第126条第7項の規定に適合する。

第4 むすび

以上のとおり,本件審判の請求に係る訂正は、訂正事項1及び2は、特許法第126条第1項ただし書第2号に掲げる事項を目的とするものであり、かつ同条第5項ないし第7項の規定に適合する。

よって,結論のとおり審決する。
 
発明の名称 (54)【発明の名称】
端末装置及び通信方法
【技術分野】
【0001】
本発明は、端末装置及び通信方法に関する。
【背景技術】
【0002】
3GPP-LTE(3rd Generation Partnership Project Radio Access Network Long Term Evolution)(以下では、単に、「LTE」と呼ばれることがある)のRelease 8(Rel.8)では、下り回線の通信方式としてOFDMA(Orthogonal Frequency Division Multiple Access)が採用され、上り回線の通信方式としてSC-FDMA(Single Carrier Frequency Division Multiple Access)が採用されている。
【0003】
Rel.8の下り回線では、データ信号(例えば、PDSCHによって送信される信号)を復調するために、CRS(cell specific reference signal)が用いられる。すなわち、「CRSを用いたデータ送信」がサポートされている。「CRSを用いたデータ送信」とは、CRSをマッピングしたサブフレームにおいて、CRSと共にデータ信号を送信する送信方法であり、端末はデータ受信の際にCRSにより伝搬路推定を行うことによりデータ復調を行う。CRSは、全てのサブフレームで全帯域に渡って送信され、任意のセル内で共通の参照信号(reference signal)である。また、CRSは、セルIDに依存した時間・周波数リソースにマッピングされて送信され、送信アンテナ数に応じてアンテナポート0?3が使用される。また、CRSは、任意のセルのエリア全てをカバーするように送信される。また、CRSは、品質測定にも用いられ、この品質測定結果は、リンクアダプテーション又はスケジューリングに用いられる。
【0004】
一方、LTE-AdvancedであるRel.10では、下り回線に対してMIMO(Multi-Input Multi-Output)を適用するために、「DMRS(Demodulation Reference signal)を用いたデータ送信」がサポートされている。「DMRSを用いたデータ送信」とは、DMRSをマッピングしたサブフレームにおいて、DMRSと共にデータ信号を送信する送信方法であり、端末はデータ受信の際にDMRSにより伝搬路推定を行うことによりデータ復調を行う。DMRSは、UE specific Reference Signalと呼ばれることもある。また、DMRSは、セル全体に向けて送信されるCRSに対して、下り回線データ信号をマッピングするためのデータリソースを割り当てた端末向けに送信され、その端末向けのデータを割り当てたリソースブロック(つまり、周波数リソース)のみで送信される。所定の端末向けにデータ信号を送信する場合、Precodingによってビームを形成し、当該ビームを用いたデータ通信が可能となる。このビームを用いたデータ通信では、高いスループットを実現できる(例えば、非特許文献1、2、3、4参照)。また、DMRSを用いたデータ送信は、送信モード9が設定された端末向けに用いることができる。また、送信アンテナ数に応じてアンテナポート7?14が使用される。また、LTE-AdvancedであるRel.10では、CSI-RSが品質測定に用いられ、この品質測定結果がリンクアダプテーション又はスケジューリングに用いられる。
【0005】
また、LTE-AdvancedであるRel.10では、送信モード9が設定された端末は、「MBSFN(multi-broadcast single frequency network)サブフレーム」においてもデータ信号を送信できる。
【0006】
ここで、Rel.8では、「MBSFNサブフレーム」は、MBMSデータ(MulticastまたはBroadcastデータ)を複数基地局からSFN(Single Frequency Network)送信するために用いられる。このため、PDCCH信号及びCRSがマッピングされるリソースは、サブフレームの先頭の2OFDMシンボル内に限定される。そして、サブフレームの先頭から3OFDMシンボル以降では、MBMSデータのみをマッピングすることができる。すなわち、MBSFNサブフレームでは、サブフレームの先頭から3OFDMシンボル目以降のOFDMシンボル(つまり、データ送信領域)には、CRSが含まれない。
【0007】
一方、LTE-AdvancedであるRel.10では、MBSFNサブフレームにおいても、DMRSを用いたデータ送信(Unicastデータの送信)を行うことができる。上記の通り、MBSFNサブフレームでは先頭から3OFDMシンボル目以降のOFDMシンボル(つまり、データ送信領域)にはCRSが含まれないので、LTE-AdvancedであるRel.10では、より多くの時間周波数リソースをPDSCHに用いることができる。
【0008】
また、LTE-AdvancedであるRel.11(Rel.10の次のReleaseである)では、複数ノードから協調送信するCoMP送信が検討されている。また、このCoMP送信をヘテロジニアスネットワーク環境において用いる場合に、マクロセル内の複数のLPNに対してHPNと同一のセルIDを用いる運用が検討されている(例えば、非特許文献6参照)。このような運用においては、同一セルIDを用いるHPN及びLPNからは、共通のCRSが送信される。ここで、ヘテロジニアスネットワーク環境とは、マクロ基地局(HPN(High Power Node))とピコ基地局(LPN(Low Power Node))とから構成されるネットワーク環境である。
【0009】
さらに、LTE-AdvancedであるRel.11では、下り回線向けのExtension carrier(non-backward compatible carrier)が検討されている。Extension carrierでは、DMRSのみがサポートされ、オーバーヘッド低減のために、CRSは送信されない(例えば、非特許文献7参照)。このようにExtension carrierでは、DMRSを用いたデータ送信のみがサポートされる運用により、高効率の伝送が可能である。
【0010】
また、LTE及びLTE-Advancedにおいては、初期アクセス時、接続中において上り回線データが発生した時、又は、ハンドオーバー時に、端末は、基地局に対してRACH(Random Access Channel)を送信する。これにより、端末から基地局への接続、又は、再同期確立が、試行される。これらの、端末から基地局への接続、又は、再同期確立のために行われる一連の動作は、「Random access procedure」と呼ばれる。「Random access procedure」は、図1に示す4つのステップから構成される(例えば、非特許文献5参照)。
【0011】
Step1(message 1の送信):端末は、RACH preambleリソース候補(時間リソース、周波数リソース、及び系列リソースの組み合わせにより規定される)群から、実際に用いられるRACH preambleリソースをランダムに選択する。そして、端末は、選択されたRACH preambleリソースを用いてRACH preambleを送信する。ここで、基地局と端末の間の伝搬ロス(Path loss)が所定閾値以上の場合と、閾値以下の場合とでは、選択可能なRACH preambleリソース候補が異なる。また、データサイズが所定閾値以上の場合と、所定閾値以下の場合とでも、選択可能なRACH preambleリソース候補が異なる。また、RACH preambleは、「message 1」と呼ばれることがある。
【0012】
Step2(message 2の送信):基地局は、RACH preambleを検出した場合、RACH response(又は、random access response)を送信する。この時点では、基地局はRACH preambleを送信した端末を特定できない。このため、RACH responseは、基地局がカバーするセルの全体に送信される。RACH responseがマッピングされるデータリソース(つまり、PDSCHリソース)は、PDCCHによって基地局から端末へ通知される。また、RACH responseには、端末が上り回線で使用するリソースに関する情報、又は、端末による上り回線の送信タイミングに関する情報が含まれている。ここで、RACH preambleを送信した端末は、RACH preambleの送信タイミングから所定期間(つまり、再送判定期間)内にRACH responseを受信しない場合、再度、RACH preambleリソースの選択、及び、RACH preambleの送信(RACHの再送)を行う。
【0013】
Step3(message 3の送信):端末は、RACH responseによって基地局から指示された上り回線リソースを用いて、RRC接続要求又はスケジューリング要求などのデータを送信する。
【0014】
Step4(message 4の送信):基地局は、端末に割り当てたUE-ID(例えば、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】
ところで、上記の通り、LTE-Advancedシステムに関しては、MBSFNサブフレーム及びExtension carrierにおいても、同一セルIDを用いたCoMP送信においても、DMRSを用いたデータ送信を行うことによって、高効率の伝送が実現される。
【0017】
しかしながら、「Random access procedure」においては、以下に示す課題がある。
【0018】
(1)MBSFNサブフレームに関する課題:
1フレーム(=10サブフレーム)内で、サブフレーム番号0,4,5,9以外のサブフレームを、MBSFNサブフレームとして設定することができる。すなわち、サブフレーム番号1,2,3,6,7,8のサブフレームをMBSFNサブフレームとして設定することにより、高効率なシステム運用が可能となる。
【0019】
ここで、non-MBSFNサブフレームでは、サブフレーム全体にCRSがマッピングされるため、「CRSを用いたデータ送信」によって、RACH responseを送信できる。すなわち、non-MBSFNサブフレームでは、「CRSを用いたデータ送信」によってRACH responseを送信しても、端末は、十分に低い誤り率によって、下り回線のデータ信号を受信できる。
【0020】
一方、MBSFNサブフレームでは、CRSは、サブフレームの先頭から2シンボルまでのOFDMシンボルにしかマッピングされない。このため、MBSFNサブフレームでは、RACH responseの受信誤り率が高くなってしまう。
【0021】
ここで、上記の通り、LTE-AdvancedであるRel.10に対応する端末は、DMRSを受信できる。このため、LTE-AdvancedであるRel.10では、RACH responseがMBSFNサブフレームにおいて送信されることも考えられる(例えば、非特許文献8参照)。
【0022】
しかしながら、「DMRSを用いたデータ送信」によってRACH responseを送信した場合、Rel.10に対応する端末は、RACH responseを受信できる一方で、Rel.8に対応する端末は、DMRSをサポートしていないので、RACH responseを受信できない。このため、基地局がRACH preambleの送信元端末に対してRACH responseをMBSFNサブフレームで送信したとしても、送信元端末がRel.8に対応する端末である場合には、RACH responseは、正しく受信されない。従って、送信元端末は、RACH preambleを再送することになる。このため、「DMRSを用いたデータ送信」によってRACH responseを送信することは、Rel.8に対応する端末にとっては、遅延の原因となる。このため、Rel.10ではRACH responseはCRSを用いて送信され、RACH responseが送信されるサブフレームは、non-MBSFNサブフレームに限定されることになる(図2参照)。しかしながら、RACH responseが送信されるサブフレームをnon-MBSFNサブフレームに限定すると、RACH responseの送信に遅延が生じることになる。また、「CRSを用いたデータ送信」によって送信される必要のある、共通チャネル信号がnon-MBSFNサブフレームに集中することになる。このため、共通チャネル信号をマッピングするリソースの通知に用いられるPDCCH領域(つまり、common search space)が混雑してしまう。なお、「CRSを用いたデータ送信」によって送信される必要のある、共通チャネル信号には、報知情報であるSIB(System information block)又はPaging情報などが含まれる。
【0023】
(2)Extension carrierに関する課題:
Extension carrierを設けることにより、リソースの容量を拡大することができる。しかしながら、Rel.8からRel.10のそれぞれに対応する端末は、Extension carrierを使用することができない。従って、RACH procedure中におけるPDSCHを用いた送信では、通常のcomponent carrierが用いられる必要がある。このため、通常のcomponent carrierが混雑して、初期アクセス時又はハンドオーバー時の遅延を招く恐れがある。
【0024】
(3)同一セルIDを用いるCoMP送信に関する課題:
同一セルIDを用いる全てのHPN及びLPNから、共通のCRSが送信される。このため、CRSを用いたデータ送信(つまり、PDSCHの送信)が行われる場合、PDSCHも、全ての送信ポイント(つまり、同一セルIDを用いる全てのHPN及びLPN)から送信される。従って、RACH procedure中におけるPDSCHを用いたデータ送信に対してCRSを用いたデータ送信が適用されると、或る送信ポイントの近傍に存在する端末に対するデータ送信であっても、全送信ポイントからデータが送信されることになり、非効率となる。
【0025】
本発明の目的は、応答信号を効率良く送信する端末装置及び通信方法を提供することである。
【課題を解決するための手段】
【0026】
本発明の一態様の端末装置は、基地局より通知される第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号を受信する、受信部と、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、前記第1のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、前記第2のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信する、送信部と、を備え、前記受信部は、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号に含まれるリソース群に関するリソース情報に応じてDMRSまたはCRSを用いて受信する。
【0027】
本発明の一態様の通信方法は、基地局より通知される第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号を受信し、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、前記第1のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、前記第2のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号に含まれるリソース群に関するリソース情報に応じてDMRSまたはCRSを用いて受信する。
【発明の効果】
【0028】
本発明によれば、プリアンブル送信装置から送信されたランダムアクセスプリアンブルに対する応答信号を効率良く送信する端末装置及び通信方法を提供できる。
【図面の簡単な説明】
【0029】
【図1】Random access procedureの説明に供する図
【図2】RACH responseが送信されるサブフレームの説明に供する図
【図3】本発明の実施の形態1に係る通信システムの一例を示す図
【図4】本発明の実施の形態1に係る基地局の構成を示すブロック図
【図5】本発明に実施の形態1に係る端末の構成を示すブロック図
【図6】本発明に実施の形態1に係る基地局及び端末の動作説明に供する図
【図7】本発明の実施の形態3に係る送信方法決定テーブルの第1の例を示す図
【図8】本発明の実施の形態3に係る送信方法決定テーブルの第2の例を示す図
【図9】本発明に実施の形態3に係る基地局及び端末の動作説明に供する図
【図10】本発明の実施の形態4に係る基地局の構成を示すブロック図
【図11】本発明に実施の形態4に係る端末の構成を示すブロック
【図12】再送判定期間の他の例の説明に供する図
【発明を実施するための形態】
【0030】
以下、本発明の実施の形態について図面を参照して詳細に説明する。なお、実施の形態において、同一の構成要素には同一の符号を付し、その説明は重複するので省略する。
【0031】
[実施の形態1]
[通信システムの概要]
本発明の実施の形態1に係る通信システムは、ランダムアクセスプリアンブルに対する応答信号の送信装置と、ランダムアクセスプリアンブルを送信する第1のプリアンブル送信装置及び第2のプリアンブル送信装置とを有する。
【0032】
図3は、本発明の実施の形態1に係る通信システムの一例を示す図である。図3において、本発明の実施の形態1に係る通信システムは、基地局100と、端末200,300とを有する。図3においては、応答信号の送信装置は、基地局100に対応し、第1のプリアンブル送信装置及び第2のプリアンブル送信装置は、端末200,300にそれぞれ対応する。基地局100は、端末200,300から送信されたランダムアクセスプリアンブルを受信し、受信されたランダムアクセスプリアンブルに対する応答信号を端末200,300へ送信する。端末200は、第1のリファレンス信号及び第2のリファレンス信号を受信できる一方、端末300は、第1のリファレンス信号を受信できず且つ第2のリファレンス信号を受信できる。
【0033】
より具体的には、基地局100において、後述する送信部104は、第1のリファレンス信号を第1のアンテナポートで送信し、第2のリファレンス信号を第2のアンテナポートで送信する。後述する設定部101は、第1のアンテナポートで送信される応答信号及び第2のアンテナポートで送信される応答信号を受信できる第1のプリアンブル送信装置が選択可能な第1のリソース群と、第1のアンテナポートで送信される応答信号を受信できず且つ第2のアンテナポートで送信される応答信号を受信できる第2のプリアンブル送信装置が選択可能な第2のリソース群とを設定する。後述する受信部102は、第1のリソース群又は第2のリソース群に含まれるリソースを用いて送信されたランダムアクセスプリアンブルを受信する。そして、後述する送信部104は、ランダムアクセスプリアンブルのリソースが第1のリソース群に含まれる場合、第1のアンテナポート又は第2のアンテナポートで応答信号を送信する。また、送信部104は、ランダムアクセスプリアンブルのリソースが第2のリソース群に含まれる場合、第2のアンテナポートで応答信号を送信する。ここで、後述する設定部101がランダムアクセスプリアンブルに対して、第1のアンテナポート及び第2のアンテナポートのいずれか一方で応答信号が送信される第1のリソース群と、ランダムアクセスプリアンブルに対して、第2のアンテナポートで前記応答信号が送信される第2のリソース群とを設定してもよい。
【0034】
また、端末200において、後述する受信部201は、第1のアンテナポートで送信される第1のリファレンス信号、又は、第2のアンテナポートで送信される第2のリファレンス信号を受信する。後述する制御部202は、ランダムアクセスプリアンブルに対して、第1のアンテナポート及び第2のアンテナポートのいずれか一方で応答信号が送信される第1のリソース群と、ランダムアクセスプリアンブルに対して、第2のアンテナポートで応答信号が送信される第2のリソース群とのうち、一つを選択する。後述する送信部203は、選択された第1のリソース群又は第2のリソース群に含まれるリソースを用いてランダムアクセスプリアンブルを送信する。そして、後述する受信部201は、ランダムアクセスプリアンブルのリソースが第1のリソース群に含まれる場合、第1のアンテナポート又は第2のアンテナポートで送信された応答信号を受信する。また、受信部201は、ランダムアクセスプリアンブルのリソースが第2のリソース群に含まれる場合、第2のアンテナポートで送信された応答信号を受信する。
【0035】
以下では、基地局100はRel.11に対応する基地局であり、端末200は、Rel.11に対応する端末であり、端末300は、Rel.8からRel.10のいずれかに対応する端末であるものとして説明する。すなわち、基地局100は、Rel.8からRel.11のそれぞれに対応する端末のすべてと通信可能である。また、端末200は、Rel.8からRel.11のそれぞれに対応する基地局のすべてと通信可能である。また、端末300は、Rel.8からRel.10のそれぞれに対応する基地局のすべてと通信可能であるが、Rel.11に対応する基地局とは通信できない。また、第1のリファレンス信号は、DMRSであり、第2のリファレンス信号は、CRSである。また、応答信号は、RACH responseである。
【0036】
[基地局100の構成]
図4は、本発明の実施の形態1に係る基地局100の構成を示すブロック図である。図4において、基地局100は、設定部101と、受信部102と、制御部103と、送信部104とを有する。
【0037】
設定部101は、DMRSを用いたデータ送信(以下では、「DMRS送信」と呼ばれることがある)によって送信されたRACH responseを受信できる端末200が選択可能な第1のRACH preambleリソース候補群(つまり、第1のリソースグループ)を設定する。また、設定部101は、DMRSを用いたデータ送信によって送信されたRACH responseを受信できず且つCRSを用いたデータ送信(以下では、「CRS送信」と呼ばれることがある)によって送信されたRACH responseを受信できる端末300が選択可能な第2のRACH preambleリソース候補群(つまり、第2のリソースグループ)を設定する。上述の通り、RACH preambleリソース候補は、時間リソース、周波数リソース、及び系列リソースの組み合わせにより規定されるが、以下では、説明を簡単にするために、系列リソースによってのみ規定されるものとして説明する。
【0038】
設定された第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関する「リソース情報」は、報知信号に含められ(つまり、報知チャネルによって)、送信部104を介して端末200又は端末300へ報知される。なお、設定された第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関するリソース情報は、制御信号又はデータ信号に含められ(つまり、制御チャネル又はデータチャネルによって)、端末200及び端末300へ通知されてもよい。
【0039】
受信部102は、端末200及び端末300から送信されたRACH preambleを受信する。具体的には、受信部102は、受信信号と、RACH preambleリソース候補に対応する系列レプリカとの相関を算出し、算出された相関値と所定の閾値とを比較する。そして、受信部102は、算出された相関値が所定の閾値より大きい場合、その相関値の算出に用いられた系列レプリカに対応するRACH preambleリソースにおいてRACH preambleが受信されたと判定する。RACH preambleが検出されたRACH preambleリソースに関する情報は、制御部103へ出力される。
【0040】
また、受信部102は、基地局100から、RACH preambleの送信元端末である端末200又は端末300へ送信されたRACH responseによって送信元端末に対して指定された上り回線データリソースにおいて、送信元端末から送信された上り回線データ信号を受信する。
【0041】
制御部103は、RACH responseの送信方法を選択する。すなわち、制御部103は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、DMRS送信(つまり、第1の送信方法)を選択する。また、制御部103は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、CRS送信(つまり、第2の送信方法)を選択する。
【0042】
送信部104は、下り回線において、制御信号(例えば、PDCCH信号)及びデータ信号(例えば、PDSCH信号)を送信する。
【0043】
例えば、送信部104は、制御部103において選択された送信方法を用いてRACH responseを送信する。具体的には、送信部104は、制御部103においてDMRS送信が選択された場合、RACH responseと共にDMRSを送信する。このとき、RACH responseとDMRSとは同一の位相関係によって送信される。つまり、送信されるDMRSと同一のアンテナポートを用いてRACH responseが送信される。また、例えば、アンテナ間において重み付けが施される場合には、RACH responseとDMRSとは同一の重み付けが施された状態で送信される。ここで、DMRSの送信アンテナポートは、予め決められている。例えば、Rel.10では、DMRSの送信アンテナポートは、ポート7?14を取りうるが、RACH response向けのDMRSはポート7に決めておく。なお、他のデータ信号の送信又は受信品質測定のために、RACH response及びDMRSと共に、CRSが同時に送信されてもよい。一方、送信部104は、制御部103においてCRS送信が選択された場合、RACH responseと共にCRSを送信する。このとき、RACH responseとCRSとは同一の位相関係によって送信される。つまり、送信されるCRSと同一のアンテナポートを用いてRACH responseが送信される。ここで、CRS送信の場合、RACH responseが送信されるリソースブロックにおいてDMRSがCRSと共に送信されることはない。
【0044】
また、送信部104は、RACH responseがマッピングされるデータリソースに関する情報をPDCCHによって送信する。このPDCCH信号は、RA-RNTIと呼ばれる全端末に共通の識別子によってスクランブルされた状態で送信される。
【0045】
なお、送信部104は、RACH procedureにおけるStep4(message 4送信)の際にも、RACH responseの送信方法と同じ方法を用いる。
【0046】
また、アンテナポートとは、1本又は複数の物理アンテナから構成される、論理的なアンテナを指す。すなわち、アンテナポートは必ずしも1本の物理アンテナを指すとは限らず、複数のアンテナから構成されるアレイアンテナ等を指すことがある。例えば3GPP LTEにおいては、アンテナポートが何本の物理アンテナから構成されるかは規定されず、基地局が異なる参照信号(Reference signal)を送信できる最小単位として規定されている。さらに、アンテナポートはプリコーディングベクトル(Precoding vector)の重み付けを乗算する最小単位として規定されることもある。
【0047】
[端末200の構成]
図5は、本発明に実施の形態1に係る端末200の構成を示すブロック図である。図5において、端末200は、受信部201と、制御部202と、送信部203とを有する。
【0048】
受信部201は、基地局100から送信された報知信号を受信する。受信された報知信号には、第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関するリソース情報が含まれる。そして、受信部201は、受信された報知信号を制御部202へ出力する。
【0049】
また、受信部201は、基地局100から送信された、PDCCH信号及びRACH responseを受信する。具体的には、受信部201は、PDCCH信号を受信し、受信されたPDCCH信号によって指定されているデータリソースにおいて、制御部202によって指定されるリファレンス信号(DMRS又はCRS)を用いて、RACH responseを受信する。
【0050】
制御部202は、受信部201から受け取る報知信号に基づいて、送信部203において用いられる送信パラメータ、及び、受信部201において用いられる受信パラメータを設定する。
【0051】
具体的には、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、第1のRACH preambleリソース候補群の中からRACH preambleリソースを選択する。一方、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、報知信号に含まれているリソース情報が示す第2のRACH preambleリソース候補群からRACH preambleリソースを選択する。選択されたRACH preambleリソースに関する情報は、送信部203へ出力される。
【0052】
また、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してDMRSを指定する。一方、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してCRSを指定する。
【0053】
また、制御部202は、受信部201において受信されたPDCCH信号によって指定されているデータリソースに関する情報を受信部201へ出力する。
【0054】
送信部203は、制御部202において選択されたRACH preambleリソースを用いて、RACH preambleを送信する。
【0055】
[基地局100及び端末200の動作]
以上の構成を有する基地局100及び端末200の動作について説明する。図6は、基地局100及び端末200の動作説明に供する図である。以下では、RACH preambleリソースとして、64個の系列が用意されている場合を例として説明する。
【0056】
<基地局100によるRACH preambleリソース候補群の設定>
基地局100において、設定部101は、DMRS送信によって送信されたRACH responseを受信できる端末200が選択可能な第1のRACH preambleリソース候補群を設定する。また、設定部101は、DMRSを用いたデータ送信によって送信されたRACH responseを受信できず且つCRS送信によって送信されたRACH responseを受信できる端末300が選択可能な第2のRACH preambleリソース候補群を設定する。
【0057】
設定された第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関するリソース情報は、報知信号に含められ、送信部104を介して端末200又は端末300へ報知される。
【0058】
ここで、図6に示すように、基地局100は、端末300に対して第2のRACH preambleリソース候補群に関するリソース情報として、contention RACH(複数端末間の競合を伴うRACH)のリソース数であるNcXを報知する。これにより、端末300は、RACH preambleリソース番号が1?NcX以外のRACH preambleリソースについては、non-contention RACHに用いられるRACH preambleリソースであると解釈する。
【0059】
また、基地局100は、端末200に対して第1のRACH preambleリソース候補群に関するリソース情報として、contention RACH(複数端末間の競合を伴うRACH)のリソース数であるNcYを報知する。これにより、端末200は、RACH preambleリソース番号が1?NcY以外のRACH preambleリソースについては、non-contention RACHに用いられるRACH preambleリソースであると解釈する。また、端末200は、RACH preambleリソース番号がNcX+1?NcYのRACH preambleリソースを、第1のRACH preambleリソース候補群として解釈する。
【0060】
このように、第1のRACH preambleリソース候補群に関するリソース情報としてNcYを報知することにより、Rel.8?Rel.10において使用されているNcXと同様の報知方法を再利用できると共に、Rel.8?Rel.10のバックワードコンパチビリティを維持できる。
【0061】
<端末200によるRACH preambleの送信>
端末200は、RACH preambleリソース番号がNcX+1?NcYの第1のRACH preambleリソース候補群からRACH preambleリソースを選択し、選択されたRACH preambleリソースを用いてRACH preambleを送信する。
【0062】
<端末300によるRACH preambleの送信>
端末300は、RACH preambleリソース番号がNc1?NcXの第2のRACH preambleリソース候補群からRACH preambleリソースを選択し、選択されたRACH preambleリソースを用いてRACH preambleを送信する。
【0063】
<基地局100によるRACH responseの送信方法の選択、及び、RACH responseの送信>
基地局100において、制御部103は、RACH preambleが受信されたリソースが第1のリソース候補群に含まれる場合、RACH responseの送信方法として、DMRS送信(つまり、第1の送信方法)を選択する。また、制御部103は、RACH preambleが受信されたリソースが第2のリソース候補群に含まれる場合、RACH responseの送信方法として、CRS送信(つまり、第2の送信方法)を選択する。
【0064】
送信部104は、制御部103においてDMRS送信が選択された場合、RACH responseと共にDMRSを送信する。一方、送信部104は、制御部103においてCRS送信が選択された場合、RACH responseと共にCRSを送信する。
【0065】
<端末200によるPDCCH信号及びRACH responseの受信>
制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してDMRSを指定する。一方、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してCRSを指定する。
【0066】
また、制御部202は、受信部201において受信されたPDCCH信号によって指定されているデータリソースに関する情報を受信部201へ出力する。ここで、PDCCH信号は、RACH preambleが送信されたサブフレームに依存したRA-RNTIによって基地局100においてスクランブリングされている。このため、受信部201は、そのRA-RNTIによってデスクランブリングすることにより、PDCCH信号を受信する。
【0067】
受信部201は、受信されたPDCCH信号によって指定されているデータリソースにおいて、制御部202によって指定されるリファレンス信号(DMRS又はCRS)を用いて、RACH responseを受信する。
【0068】
ここで、端末200に対してNcYの情報が通知されていなければ、接続先の基地局が従来の基地局であると想定し、端末200は、RACH preambleリソース番号がNc1?NcXの第2のRACH preambleリソース候補群から選択されたRACH preambleリソースを用いてRACH preambleを送信する。また、この場合、端末200は、RACH responseをCRSを用いて受信する。
【0069】
また、RACH responseの送信よりも後の送信であって端末200に対して送信モードが設定されるまでの送信(例えば、message 4の送信)においても、基地局100は、端末200に対してDMRS送信によってPDSCHを送信し、端末200は、DMRSを用いてPDSCHを復調する。ここで、DMRSの送信ポートは、例えばポート7に決められていてもよいし、PDCCHによって通知されてもよい。そして、端末200に対して送信モードが設定された後は、送信モードに従ったPDSCHの送信が行われる。
【0070】
以上のように本実施の形態によれば、基地局100において、設定部101は、DMRS送信によって送信されたRACH responseを受信できる端末200が選択可能な第1のRACH preambleリソース候補群を設定する。また、設定部101は、DMRS送信によって送信されたRACH responseを受信できず且つCRS送信によって送信されたRACH responseを受信できる端末300が選択可能な第2のRACH preambleリソース候補群を設定する。そして、制御部103は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、DMRS送信を選択する。また、制御部103は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、CRS送信を選択する。
【0071】
こうすることにより、基地局100は、RACH preambleを検出したリソースに基づいて、RACH preambleの送信元端末がDMRS送信によって送信されたRACH responseを受信できる端末であるか否かを判断できる。このため、DMRS送信によって送信されたRACH responseを受信できる端末に対して、RACH responseをDMRSによるRACH response受信をサポートする端末向けにRACH responseをDMRS送信によって効率良く送信できる。
【0072】
そして、DMRS送信によればMBSFNサブフレームにおいてもRACH responseを送信できるので、non-MBSFNサブフレームにおけるリソース容量が圧迫されることが防止され、結果として、システム容量を増加できる。また、端末300に対してDMRS送信によってRACH responseが送信されることがないので、端末300におけるRACH preambleの再送が増加することを防止できる。
【0073】
また、マクロセルにおける複数のLPNに対してHPNのセルIDと同じセルIDを用いるヘテロジニアスネットワーク環境においては、DMRS送信によって送信されたRACH responseを受信できる端末に対して、その端末が存在する位置に近い送信ポイントからのみ、RACH responseを効率良く送信させることができる。例えば、基地局は、RACH preambleの受信電力が高かった送信ポイントからのみ、RACH responseを送信する。
【0074】
また、Extension carrierを用いたシステム運用においては、DMRS送信によって送信されたRACH responseを受信できる端末に対して、RACH responseをExtension carrierにおいて効率良くDMRS送信できる。また、backward compatible carrierの混雑を軽減することができる。
【0075】
なお、基地局100において、制御部103は、第1のRACH preambleリソース候補群に含まれるRACH preambleリソースによって同じ処理期間に受信された複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含め、当該RACH responseをDMRS送信してもよい。また、制御部103は、第2のRACH preambleリソース候補群に含まれるRACH preambleリソースによって同じ処理期間に受信された複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含め、当該RACH responseをCRS送信してもよい。
【0076】
[実施の形態2]
実施の形態2では、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseが送信されるサブフレームが「MBSFNサブフレーム」であるときにのみ、DMRS送信が選択される。一方、RACH responseが送信されるサブフレームが「non-MBSFNサブフレーム」であるときには、CRS送信が選択される。ここで、「MBSFNサブフレーム」とは、先頭部を除くリソース領域においてCRSをマッピングできず且つDMRSをマッピングできるサブフレームである。「non-MBSFNサブフレーム」とは、先頭部を除くリソース領域にDMRS及びCRSをマッピングできるサブフレームである。なお、実施の形態2に係る基地局及び端末は、実施の形態1に係る基地局100及び端末200と同様であるので、図4,5を援用して説明する。
【0077】
実施の形態2の基地局100において、制御部103は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseが送信されるサブフレームが「MBSFNサブフレーム」であるときにのみ、DMRS送信を選択する。一方、制御部103は、RACH responseが送信されるサブフレームが「non-MBSFNサブフレーム」であるときには、CRS送信を選択する。
【0078】
また、制御部103は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、「non-MBSFNサブフレーム」であるときにのみ、CRS送信を選択する。すなわち、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、「MBSFNサブフレーム」であるときには、RACH responseは送信されない。
【0079】
送信部104は、複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含め、当該RACH responseを送信する。1つのRACH responseに含められる複数の応答メッセージは、同じ処理期間に受信された複数のRACH preambleに対応する。
【0080】
具体的には、制御部103は、RACH responseが送信されるサブフレームが「MBSFNサブフレーム」であるときには、第1のRACH preambleリソース候補群に含まれるRACH preambleリソースによって送信された複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含める。そして、制御部103は、当該RACH responseをDMRS送信する。一方、制御部103は、RACH responseが送信されるサブフレームが「non-MBSFNサブフレーム」であるときには、送信に用いられたRACH preambleリソースが第1のRACH preambleリソース候補群に含まれるか第2のRACH preambleリソース候補群に含まれるかに拘わらず、複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含める。そして、制御部103は、当該RACH responseをCRS送信する。
【0081】
端末200の制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、RACH responseを受信するサブフレームが「MBSFNサブフレーム」であるときには、RACH responseの受信に使用するリファレンス信号として、受信部201に対してDMRSを指定する。一方、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、RACH responseを受信するサブフレームが「non-MBSFNサブフレーム」であるときには、RACH responseの受信に使用するリファレンス信号として、受信部201に対してCRSを指定する。
【0082】
以上のように本実施の形態によれば、基地局100において、制御部103は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、応答信号が送信されるサブフレームが先頭部を除くリソース領域にCRSをマッピングできず且つDMRSをマッピングできる第1のサブフレーム(MBSFNサブフレーム)であるときにのみ、DMRS送信を選択する。また、制御部103は、応答信号が送信されるサブフレームが先頭部を除くリソース領域にDMRS及びCRSをマッピングできる第2のサブフレーム(non-MBSFNサブフレーム)であるときには、CRS送信を選択する。
【0083】
こうすることにより、MBSFNサブフレームにおいてDMRS送信によってRACH responseを送信できるので、non-MBSFNサブフレームにおけるリソース容量が圧迫されることが防止され、結果として、システム容量を増加できる。また、端末200は、non-MBSFNサブフレームにおいてはCRSを用いた応答信号の受信のみを行えばよいので、制御を簡略化することができる。
【0084】
また、制御部103は、RACH responseが送信されるサブフレームがnon-MBSFNサブフレームであるときには、送信に用いられたRACH preambleリソースが第1のRACH preambleリソース候補群に含まれるか第2のRACH preambleリソース候補群に含まれるかに拘わらず、複数のRACH preambleにそれぞれ対応する複数の応答メッセージを1つのRACH responseに含める。そして、制御部103は、当該RACH responseをCRS送信する。
【0085】
こうすることにより、特に、端末300が多い場合には、PDCCH及びPDSCHの混雑を軽減できる。これは、端末300が多い場合には、端末200に対して端末300とは別に、RACH responseをDMRS送信することにより得られる、伝送効率向上効果よりも、次のオーバーヘッド低減効果の方が上回るからである。すなわち、この場合、端末200及び端末300のそれぞれに対する複数の応答メッセージを1つのRACH responseに含めて送信することによる、PDCCH又はCRCのオーバーヘッド低減効果の方が、上記の伝送効率向上効果よりも上回る。
【0086】
なお、non-MBSFNサブフレームにおいてCRS送信が選択されるかDMRS送信が選択されるかについてPDCCHによって基地局100が端末200に対して通知してもよい。この場合、端末200は、その通知に従ってRACH responseを受信する。こうすることにより、基地局100は、non-MBSFNサブフレームにおいて、端末200及び端末300に対する応答メッセージを1つに纏めてCRS送信するか、又は、端末200に対する応答メッセージを端末300に対する応答メッセージと独立にDMRS送信するかを、PDCCH又はPDSCHの混雑具合などに応じて選択できる。
【0087】
また、上記説明では、MBSFNサブフレーム及びnon-MBSFNサブフレームを例にとり説明を行った。しかしながら、これに限定されるものではなく、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、他の2種類のサブフレームの一方ではDMRS送信が選択され、他方ではCRS送信が選択されてもよい。
【0088】
[実施の形態3]
実施の形態3では、基地局と端末との間の伝搬減衰値(以下では、「パスロス」とも呼ばれることがある)が閾値より大きい第1のプリアンブル送信装置に対しては、第1のRACH preambleリソース候補群の内、第3のRACH preambleリソース候補群が設定される。また、実施の形態3では、基地局と端末との間の伝搬減衰値が閾値より小さい第1のプリアンブル送信装置に対しては、第1のRACH preambleリソース候補群の内、第3のRACH preambleリソース候補群に含まれない第4のRACH preambleリソース候補群が設定される。なお、実施の形態2に係る基地局及び端末は、実施の形態1に係る基地局100及び端末200と同様であるので、図4,5を援用して説明する。
【0089】
実施の形態3の基地局100において、設定部101は、閾値(Thp)を設定する。閾値(Thp)は、RACH preambleリソース候補群の選択基準として用いられる。
【0090】
また、設定部101は、自装置から送信されるCRSの送信電力を設定する。
【0091】
送信方法決定テーブルに規定されている複数のRACH preambleリソース候補群に関するリソース情報、設定された閾値(Thp)に関する情報、及び、CRS送信電力に関する情報は、報知信号に含められ(つまり、報知チャネルによって)、送信部104を介して端末200又は端末300へ報知される。なお、送信方法決定テーブルに規定されている複数のRACH preambleリソース候補群に関するリソース情報、設定された閾値(Thp)に関する情報、及び、送信電力に関する情報は、制御信号又はデータ信号に含められ(つまり、制御チャネル又はデータチャネルによって)、端末200及び端末300へ通知されてもよい。
【0092】
制御部103は、RACH preambleが受信されたリソースと、送信方法決定テーブルとに基づいて、RACH responseの送信方法を選択する。
【0093】
具体的には、送信方法決定テーブルでは、複数のRACH preambleリソース候補群が規定されており、各RACH preambleリソース候補群に対して、DMRS送信又はCRS送信と、送信電力及び符号化率の少なくとも一方との組み合わせが対応付けられている。そして、制御部103は、RACH preambleが受信されたリソースが含まれるRACH preambleリソース候補群に対応付けられた組み合わせを、送信方法として選択する。
【0094】
送信部104は、制御部103において選択された送信方法を用いてRACH responseを送信する。
【0095】
実施の形態3の端末200において、受信部201は、基地局100から送信された報知信号を受信する。受信された報知信号には、送信方法決定テーブルに規定されている複数のRACH preambleリソース候補群に関するリソース情報、閾値(Thp)に関する情報、及び、送信電力に関する情報が含まれている。そして、受信部201は、受信された報知信号を制御部202へ出力する。
【0096】
また、受信部201は、基地局100から送信されたCRSの受信電力を測定し、測定値を制御部202へ出力する。
【0097】
制御部202は、受信部201において測定されたCRS受信電力値と、基地局100によるCRS送信電力値とに基づいて、基地局100と端末200との間の伝搬減衰量を算出する。
【0098】
そして、制御部202は、報知信号と、RACH preambleリソース候補群の決定テーブルと、制御部202において算出された伝搬減衰量とに基づいて、送信部203において用いられる送信パラメータ、及び、受信部201において用いられる受信パラメータを設定する。
【0099】
例えば、制御部202は、報知信号と、RACH preambleリソース候補群の決定テーブルと、制御部202において算出された伝搬減衰量とに基づいて、自装置が用いるRACH preambleリソース候補群を選択する。RACH preambleリソース候補群の決定テーブルは、基地局100の送信方法決定テーブルと同じである。
【0100】
具体的には、RACH preambleリソース候補群の決定テーブルは、複数のRACH preambleリソース候補群が規定されており、各RACH preambleリソース候補群に対して、DMRS送信又はCRS送信と、送信電力及び符号化率の少なくとも一方との組み合わせが対応付けられている。そして、各RACH preambleリソース候補群は、伝搬減衰量と閾値(Thp)との大小関係が対応付けられている。
【0101】
以上の構成を有する基地局100及び端末200の動作について説明する。以下では、2つの送信方法決定テーブル(又は、RACH preambleリソース候補群の決定テーブル)を例にとり説明する。
【0102】
[テーブル例1]
図7は、送信方法決定テーブルの第1の例を示す図である。図7に示すテーブルにおいて、第1のRACH preambleリソース候補群は2つに分割され、グループ1A及びグループ1Bとされている。また、第2のRACH preambleリソース候補群も2つに分割され、グループ2A及びグループ2Bとされている。
【0103】
<基地局100によるRACH preambleリソース候補群の設定>
基地局100において、設定部101は、グループ1A、グループ1B、グループ2A及びグループ2Bにそれぞれ対応する4つのRACH preambleリソース候補群を設定する。ここで、実施の形態1で報知されたNcX及びNcYに加えて、グループ1Aとグループ1Bとの境界を示すNcY_pl及びグループ2Aとグループ2Bとの境界を示すNcX_plが報知される。これにより、端末200は、グループ1A、グループ1B、グループ2A及びグループ2Bを特定できる。
【0104】
<端末200によるRACH preambleの送信>
端末200は、RACH preambleリソース候補群の決定テーブルと、制御部202において算出された伝搬減衰量とに基づいて、自装置が用いるRACH preambleリソース候補群を選択する。
【0105】
具体的には、端末200は、算出された伝搬減衰量が閾値Thp以上である場合、自装置が用いるRACH preambleリソース候補群として、グループ1Aを選択する。一方、算出された伝搬減衰量が閾値Thpより小さい場合、端末200は、自装置が用いるRACH preambleリソース候補群として、グループ1Bを選択する。
【0106】
<基地局100によるRACH responseの送信方法の選択、及び、RACH responseの送信>
基地局100は、RACH preambleが受信されたリソースがグループ1Aに含まれる場合、RACH responseの送信方法として、DMRS送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。これは、RACH preambleが受信されたリソースがグループ1Aに含まれる場合、RACH preambleの送信元端末は、DMRS送信をサポートした端末であり、且つ、伝搬減衰量が大きい(つまり、通信品質が劣悪な)端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を多くしてもよい。
【0107】
また、基地局100は、RACH preambleが受信されたリソースがグループ1Bに含まれる場合、RACH responseの送信方法として、DMRS送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。これは、RACH preambleが受信されたリソースがグループ1Bに含まれる場合、RACH preambleの送信元端末は、DMRS送信をサポートした端末であり、且つ、伝搬減衰量が小さい(つまり、通信品質が良好な)端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を少なくしてもよい。
【0108】
また、基地局100は、RACH preambleが受信されたリソースがグループ2Aに含まれる場合、RACH responseの送信方法として、CRS送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。
【0109】
また、基地局100は、RACH preambleが受信されたリソースがグループ2Bに含まれる場合、RACH responseの送信方法として、CRS送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。
【0110】
以上のように、第1のRACH preambleリソース候補群及び第2のRACH preambleリソース候補群のそれぞれを伝搬減衰量に基づいてさらにグループ分けすることにより、基地局100は、RACH preambleの送信元端末の伝搬路状態を知ることができる。これにより、基地局100は、必要十分な送信電力によってRACH responseを送信できる。また、基地局100が必要十分な上り回線リソースを割り当て可能であるので、端末200が効率よく上り回線データを送信できる。
【0111】
[テーブル例2]
図8は、送信方法決定テーブルの第2の例を示す図である。図8に示すテーブルにおいて、第2のRACH preambleリソース候補群も2つに分割され、グループ2A及びグループ2Bとされている。これに対して、第1のRACH preambleリソース候補群は分割されず、グループ1とされている。
【0112】
<基地局100によるRACH preambleリソース候補群の設定>
基地局100において、設定部101は、グループ1、グループ2A及びグループ2Bにそれぞれ対応する3つのRACH preambleリソース候補群を設定する。ここで、図9に示すように、実施の形態1で報知されたNcX及びNcYに加えて、グループ2Aとグループ2Bとの境界を示すNcX_plが報知される。これにより、端末200は、グループ1、グループ2A及びグループ2Bを特定できる。すなわち、端末200は、例えば、RACH preambleリソース番号が1?NcX_p1のRACH preambleリソースをグループ2Aと解釈し、RACH preambleリソース番号がNcX_pl+1?NcYのRACH preambleリソースをグループ2Bと解釈する。
【0113】
<端末200によるRACH preambleの送信>
端末200は、制御部202において算出された伝搬減衰量が閾値Thpより小さい場合、RACH preambleリソース番号がNcX+1?NcYのグループ1からRACH preambleリソースを選択し、選択されたRACH preambleリソースを用いてRACH preambleを送信する。
【0114】
一方、端末200は、制御部202において算出された伝搬減衰量が閾値Thp以上である場合、RACH preambleリソース番号が1?NcX_plのグループ2AからRACH preambleリソースを選択し、選択されたRACH preambleリソースを用いてRACH preambleを送信する。すなわち、制御部202において算出された伝搬減衰量が閾値Thp以上である場合に用いられるRACH preambleリソース候補群は、端末200と端末300との間で共通する。
【0115】
<基地局100によるRACH responseの送信方法の選択、及び、RACH responseの送信>
基地局100は、RACH preambleが受信されたリソースがグループ1に含まれる場合、RACH responseの送信方法として、DMRS送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。これは、RACH preambleが受信されたリソースがグループ1に含まれる場合、RACH preambleの送信元端末は、DMRS送信をサポートした端末であり、且つ、伝搬減衰量が大きい(つまり、通信品質が劣悪な)端末であると判断できるからである。また、上り回線におけるデータ送信に割り当てるリソース量を多くしてもよい。
【0116】
また、基地局100は、RACH preambleが受信されたリソースがグループ2Aに含まれる場合、RACH responseの送信方法として、CRS送信、大きい送信電力、及び、低い符号化率の組み合わせを選択する。
【0117】
また、基地局100は、RACH preambleが受信されたリソースがグループ2Bに含まれる場合、RACH responseの送信方法として、CRS送信、小さい送信電力、及び、高い符号化率の組み合わせを選択する。
【0118】
ここで、テーブル例1では細かくグループ分けされる。このため、1グループあたりのリソース量が少なくなるので、RACH preambleリソースが特定のグループに偏る確率が高くなり、この結果として、RACH preamble同士が衝突する確率が高くなる。一方、テーブル例2では端末200にのみ割り当てられるグループが1つであるのでRACH preamble同士が衝突する確率が低減できる。また、同一セルIDを用いたCoMP運用においては、受信品質の劣悪な端末200(例えば、セル境界付近に存在する端末200)に対しては、RACH responseが全送信ポイントからCRS送信されることが適切であり、DMRS送信されることによる高効率化のメリットは小さい。このため、伝搬減衰量が大きい端末200向けには、RACH responseがCRS送信されても非効率になることはない。
【0119】
なお、Rel.8?Rel.10では、上り回線における送信データ量に応じたRACH preambleリソースのグループが設定される。上記説明では、端末300に対しても伝搬路減衰量によるグループ分けを行ったが、これに限定されるものではなく、さらに、送信データ量に応じたグループ分けを行ってもよい。こうすることにより、検出したRACH preambleのグループによって上り回線に割り当てるリソース量を適切に制御できるので、必要十分なリソースで効率良く上り回線データを伝送できる。
【0120】
また、上記説明では、伝搬減衰量を例に説明したが、これに限定されるものではなく、受信電力、SIR、又は、SINRなどが用いられてもよい。
【0121】
[実施の形態4]
実施の形態1では、RACH preambleが受信されたリソースが含まれるRACH preambleリソース候補群に応じて、RACH responseの送信方法として、DMRS送信又はCRS送信を選択した。これに対して、実施の形態4では、第1の端末グループに割り当てられる第1のRACH preambleリソース候補群と、第2の端末グループに割り当てられる第2のRACH preambleリソース候補群とが設定される。また、実施の形態4では、第1の端末グループと第2の端末グループとに対して、互いに異なる再送判定期間が設定される。また、実施の形態4では、RACH preambleが受信されたリソースが含まれるRACH preambleリソース候補群に応じて、RACH responseの送信タイミングが調整される。
【0122】
[基地局400の構成]
図10は、本発明の実施の形態4に係る基地局400の構成を示すブロック図である。図10において、基地局400は、設定部401と、受信部402と、制御部403と、送信部404とを有する。
【0123】
設定部401は、第1の端末グループが使用する第1のRACH preambleリソース候補群と、第2の端末グループが使用する第2のRACH preambleリソース候補群とを設定する。設定された第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関する「リソース情報」は、報知信号に含められ(つまり、報知チャネルによって)、送信部404を介して端末500へ報知される。
【0124】
また、設定部401は、第1の端末グループが使用する第1の再送判定期間と、第2の端末グループが使用する第2の再送判定期間とを設定する。設定された第1の再送判定期間及び第2の再送判定期間に関する期間情報は、報知信号に含められ(つまり、報知チャネルによって)、送信部404を介して端末500へ報知される。第1の再送判定期間は、第2の再送判定期間よりも短い。ここで、再送判定期間は、タイムウィンドウである。タイムウィンドウの大きさは、window size(RRCパラメータ:ra-ResponseWindowSize)と呼ばれることがある。
【0125】
受信部402は、端末500から送信されたRACH preambleを受信する。
【0126】
制御部403は、RACH responseの送信方法を選択する。すなわち、制御部403は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第1の送信タイミングを選択する。また、制御部403は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第2の送信タイミングを選択する。ここで、第1の送信タイミングは、RACH preambleが検出されたサブフレームの3サブフレーム後を始点とし且つ第1のwindow sizeの幅を持つ期間内に含まれる。また、第2の送信タイミングは、RACH preambleが検出されたサブフレームの3サブフレーム後を始点とし且つ第2のwindow sizeの幅を持つ期間内に含まれる一方、RACH preambleが検出されたサブフレームの3サブフレーム後を始点とし且つ第1のwindow sizeの幅を持つ期間内には含まれない。すなわち、第1の送信タイミングは、第1の再送判定期間に応じたタイミングであり、第2の送信タイミングは、第2の再送判定期間に応じたタイミングである。ここで、第1の再送判定期間は第2の再送判定期間よりも短い。
【0127】
送信部404は、制御部403において選択された送信方法(つまり、送信タイミング)を用いてRACH responseを送信する。また、送信部404は、RACH responseがマッピングされるデータリソースに関する情報をPDCCHによって送信する。
【0128】
[端末500の構成]
図11は、本発明に実施の形態4に係る端末500の構成を示すブロック図である。図11において、端末500は、受信部501と、制御部502と、送信部503とを有する。
【0129】
受信部501は、基地局400から送信された報知信号を受信する。受信された報知信号には、第1のRACH preambleリソース候補群又は第2のRACH preambleリソース候補群に関するリソース情報が含まれる。また、受信された報知信号には、設定された第1の再送判定期間及び第2の再送判定期間に関する期間情報が含まれる。そして、受信部501は、受信された報知信号を制御部502へ出力する。
【0130】
また、受信部501は、基地局100から送信されたRACH responseを、制御部502によって指定される再送判定期間において受信する受信処理を実行する。
【0131】
制御部502は、自装置が第1の端末グループに属している場合、第1のRACH preambleリソース候補群の中からRACH preambleリソースを選択する。一方、制御部502は、自装置が第2の端末グループに属している場合、第2のRACH preambleリソース候補群の中からRACH preambleリソースを選択する。選択されたRACH preambleリソースに関する情報は、送信部503へ出力される。
【0132】
また、制御部502は、自装置が第1の端末グループに属している場合、受信部501に対して第1の再送判定期間を指定する。一方、制御部502は、自装置が第2の端末グループに属している場合、受信部501に対して第2の再送判定期間を指定する。ここで、第1の再送判定期間は、RACH preambleが送信されたサブフレームの3サブフレーム後を始点とし且つ第1のwindow sizeの幅を持つ期間である。一方、第2の再送判定期間は、RACH preambleが送信されたサブフレームの3サブフレーム後を始点とし且つ第2のwindow sizeの幅を持つ期間である。
【0133】
送信部503は、制御部502において選択されたRACH preambleリソースを用いて、RACH preambleを送信する。
【0134】
以上のように本実施の形態によれば、基地局400において、設定部401は、第1の端末グループが使用する第1のRACH preambleリソース候補群と、第2の端末グループが使用する第2のRACH preambleリソース候補群とを設定する。また、設定部401は、第1の端末グループが使用する第1の再送判定期間と、第2の端末グループが使用する第2の再送判定期間とを設定する。第1の再送判定期間は、第2の再送判定期間よりも短い。そして、制御部403は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第1の送信タイミングを選択する。一方、制御部403は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第2の送信タイミングを選択する。ここで、第1の再送判定期間は第2の再送判定期間よりも短い。
【0135】
なお、上記説明では、再送判定期間がタイムウィンドウであるものとして説明を行ったが、これに限定されるものではなく、タイムウィンドウとバックオフタイムとの和であってもよい(図12参照)。
【0136】
またなお、実施の形態4は、実施の形態1乃至3のいずれかと組み合わせることもできる。例えば、実施の形態1と実施の形態4とを組み合わせた場合には、基地局100において、設定部101は、DMRSを用いたデータ送信(以下では、「DMRS送信」と呼ばれることがある)によって送信されたRACH responseを受信できる端末200が選択可能な第1のRACH preambleリソース候補群を設定する。加えて、設定部101は、DMRSを用いたデータ送信によって送信されたRACH responseを受信できず且つCRSを用いたデータ送信(以下では、「CRS送信」と呼ばれることがある)によって送信されたRACH responseを受信できる端末300が選択可能な第2のRACH preambleリソース候補群とを設定する。また、設定部101は、端末200が使用する第1の再送判定期間と、端末300が使用する第2の再送判定期間とを設定する。そして、制御部103は、RACH preambleが受信されたリソースが第1のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第1の送信タイミング及びDMRS送信を選択する。加えて、制御部103は、RACH preambleが受信されたリソースが第2のRACH preambleリソース候補群に含まれる場合、RACH responseの送信方法として、第2の送信タイミング及びCRS送信を選択する。そして、端末200において、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれている場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してDMRSを指定し、第1の再送判定期間を指定する。一方、制御部202は、第1のRACH preambleリソース候補群に関するリソース情報が報知信号に含まれていない場合、RACH responseの受信に使用するリファレンス信号として、受信部201に対してCRSを指定し、第2の再送判定期間を指定する。
【0137】
このように基地局100が端末200に対して端末300とはwindow sizeを設定することにより、以下の効果が得られる。フレーム内に多くのMBSFNサブフレームを設定した場合(例えば、図2)には、端末300は、RACH responseをMBSFNサブフレームで受信できないため、長いwindow sizeが必要となる。一方、端末200はMBSFNサブフレームにおいてRACH responseを受信できる。このため、端末200に対して端末300とは別に短いwindow sizeを設定することにより、RACH再送までの時間を短縮できる。従って、RACH procedureを完了させるまでの遅延を低減できる。なお、window内にRACH responseを検出しなかった場合に、再送までの遅延時間であるバックオフタイムが設定される場合もある。このとき、端末200の第1のバックオフタイムと端末300の第2のバックオフタイムとを異ならせてもよい。この場合、第1のバックオフタイムは、第2のバックオフタイムよりも短くしてもよい。これは、端末200に対してRACH responseを送信できるリソース(サブフレーム,component carrier)は多いので、頻繁にRACHが送信されても、RACH responseの容量が十分に残されているためである。これとは反対に、第1のバックオフタイムは、第2のバックオフタイムよりも長くしてもよい。これは、第2のタイムウィンドウが第1のタイムウィンドウよりも長く設定されるので、第2のバックオフタイムを短く設定することにより、端末300の遅延を低減できるためである。
【0138】
[他の実施の形態]
[1]上記実施の形態におけるRACH preambleリソース候補群を示すNcXはRel.10におけるRRCパラメータであるnumberOfRA-Preamblesとしてもよい.
【0139】
[2]上記各実施の形態において、端末200(又は端末500)に対するRACH responseは、DMRS送信される制御チャネル(例えば、データリソースを用いて送信されるE-PDCCH)によって送信されてもよい。この場合、制御チャネルもDMRSによって効率良く送信される。
【0140】
[3]上記各実施の形態ではRACHを例に説明を行ったが、contention baseの送信方法であれば、PUSCH(又はPUCCH)であってもよい。例えば、DMRS受信をサポートしていない端末は、RACHを用いる一方、DMRS受信をサポートしている端末は、contention PUSCH(又はPUCCH)を用いる。又は、PUSCHリソースにおいて、DMRS受信をサポートしていない端末向けのリソース群と、DMRS受信をサポートしている端末向けのリソース群とを分けてもよい。
【0141】
[4]上記各実施の形態において、RACH responseメッセージをDMRS送信する場合には、例えば、1つのアンテナポート(例えば、アンテナポート7)に固定してもよいし、複数のアンテナポートが用いられてもよい(例えば、送信ダイバーシチなどでもよい)。また、使用されるアンテナポートが、端末に対して、予め通知(又は報知)されてもよい。
【0142】
[5] RACH preambleの第1のリソースグループと第2のリソースグループは、以下のように使い分けられてもよい。
(1)Idle状態からConnected状態への遷移のためのRACH preamble送信のときには、第2のリソースグループが用いられ、それ以外のときには、第1のリソースグループが用いられる。これにより、Idle状態からの遷移の場合には、端末の能力によらずユーザの接続機会を公平に扱うことができる。
(2)Extension carrierにおいてRACH responseを受信できる端末は、第1のリソースグループを用いる。これにより、基地局がExtension carrierにRACH responseを送信できるので、通常のcomponent carrierの混雑を回避できる。
(3)CoMPにおいて送信ポイント(RRH(Remote Radio Head)など)の近傍に存在する場合には、端末は、第1のリソースグループを用い、それ以外の場合には、第2のリソースグループを用いる。端末は、送信ポイントの近傍にいるか否かを、各送信ポイントからのCSI-RSの受信電力に関する測定結果等に基づいて、判断する。これにより、送信ポイントから離れた端末に対してはマクロ基地局を含めた全RRHから、RACH responseをCRS送信し、送信ポイントの近傍にいる端末に対してのみ、RACH responseをDMRS送信できる。この結果として、よりロバスト且つ効率的な運用が可能となる。
【0143】
また、送信ポイント毎に異なるRACH preambleリソース候補がグループ化されてもよい。この場合、端末は、どの送信ポイントの近傍に存在するかについての情報をネットワークに知らせることができる。この結果として、基地局による、各端末に使用する送信ポイントの選択が容易になる。
【0144】
[6]実施の形態4において、window sizeの他に、以下のパラメータが、DMRS送信されたRACH responseを受信できる端末に対して別途設定されてもよい。
(1)mac-ContentionResolutionTimer:
このパラメータは、message 3を送信してからmessage 4を待ち受けている時間である。Rel.11向けにはmessage 4に使えるリソースが多いのでタイマーを短く設定する。
(2)maxHARQ-Msg3Tx:
このパラメータは、message 3の最大再送回数(1?8)である。DMRS向けのRACH preambleリソースはRRH近傍の端末によって用いられるので、このRACH preambleリソースに対しては少ない再送回数を設定する。
(3)powerRampingStep:
このパラメータは、RACH preamble再送ごとの電力増加量(0,2,4,6dB)である。DMRS向けのRACHリソースは、RRH近傍の端末によって用いられるので、他セルへの干渉が小さい。このため、より早く基地局でRACH preambleが受信されるように、大きいステップを設定する。
(4)preambleInitialReceivedTargetPower:
このパラメータは、RACH preamble受信電力のターゲット値(-120?-90dBm)である。DMRSDMRS向けのRACHリソースは、RRH近傍の端末によって用いられるので、他セルへの干渉が小さい。このため、より早く基地局でRACH preambleが受信されるように高いターゲット値を設定する。
(5)preambleTransMax:
このパラメータは、RACH preambleの最大再送回数(3?200)である。DMRSはMBSFNサブフレーム、extension carrierで使用されるので、DMRS向けのRACHresponse用のリソースが多い。このため、RACH preambleが頻繁に送信されても問題ないので、多い最大再送回数を設定する。
【0145】
[7]上記各実施の形態において、DMRS送信によって送信されたRACH responseを受信できる端末と、それ以外の端末とで、異なるRA-RNTIが用いられてもよい。また、DMRS送信によって送信されたRACH responseを受信できる端末と、それ以外の端末とで、異なるE-PDCCHが用いられてもよい。これにより、DMRS送信によって送信されたRACH responseを受信できる端末と、それ以外の端末とで、RACH responseメッセージが送信されるPDSCHを割り当てるためのPDCCHを区別できる。
【0146】
[8]実施の形態1では、端末200において、RACH preambleリソース番号がNcX+1?NcYのRACH preambleリソースが第1のRACH preambleリソース候補群として解釈されたが、RACH preambleリソース番号が1?NcXのRACH preambleリソースが第1のRACH preambleリソース候補群として解釈されてもよい。この場合、NcX+1?NcYのRACH preambleリソースと、1?NcXのRACH preambleリソースとに対して、異なる選択確率を設定することにより、端末200のみが選択可能なNcX+1?NcYのリソースを高い確率で選択するようにしてもよい。
【0147】
また、ハンドオーバー時など端末がRRC connected状態(あるいはActive状態)のときには、基地局100がRACH preambleリソースを明示的に指定できるが、このときに、1?NcXのRACH preambleリソース及びNcX+1?NcYのリソースのいずれを、基地局100が指定するかによって、RACH responseの送信に用いるRSを変更できる。例えば、Rel.8?Rel.10の端末が多い場合には、1?NcXのリソースを指定し且つRACH responseをCRS送信することにより、複数の端末にそれぞれ対応する複数のRACH responseを纏めて送信する。又は、同一セルIDを用いたCoMP運用時に、特定の送信ポイントの近傍に存在する端末に対しては、NcX+1?NcYのリソースを指定し且つRACH responseをその特定の送信ポイントからのみDMRS送信できる。
【0148】
[9]上記実施の形態において、Extension carrierはNew carrier typeと呼ばれることもある。また、Extension carrierは、下り制御チャネル送信領域がなく、PDCCH、PHICH(Physical Hybrid-ARQ Indicator Channel:下りリンクのACK/NACKチャネル)、PCFICH(Physical Control Format Indicator Channel)が送信されないキャリアとして規定される場合もある。
【0149】
[10]上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はハードウェアとの連携においてソフトウェアでも実現することも可能である。
【0150】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
【0151】
また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)または、LSI内部の回路セルの接続または設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。
【0152】
さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0153】
2011年8月5日出願の特願2011-171945の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【0154】
本発明の端末装置及び通信方法は、プリアンブル送信装置から送信されたランダムアクセスプリアンブルに対する応答信号を効率良く送信するものとして有用である。
【符号の説明】
【0155】
100,400 基地局
101,401 設定部
102,201,402,501 受信部
103,202,403,502 制御部
104,203,404,503 送信部
200,300,500 端末
(57)【特許請求の範囲】
【請求項1】
基地局より通知される第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号を受信する、受信部と、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、前記第1のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、前記第2のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信する、送信部と、を備え、
前記受信部は、前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号に含まれるリソース群に関するリソース情報に応じてDMRSまたはCRSを用いて受信する、
端末装置。
【請求項2】
前記受信部は、前記ランダムアクセス応答信号を、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、DMRSを用いて受信し、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、CRSを用いて受信する、
請求項1に記載の端末装置。
【請求項3】
前記ランダムアクセス応答信号がマッピングされるデータリソースに関する情報を、制御チャネルにより受信する、
請求項1に記載の端末装置。
【請求項4】
前記基地局と前記端末装置との間の伝搬減衰値の閾値に対応して、前記第1のリソース群はさらに複数のリソース群に分割され、
前記受信部は、前記伝搬減衰値と対応づけられた前記複数のリソース群に関する情報を受信する、
請求項1に記載の端末装置。
【請求項5】
前記第1のリソース群と、前記第2のリソース群に対して、それぞれ異なる前記ランダムアクセス応答信号の待ち受け期間を設定される、
請求項1に記載の端末装置。
【請求項6】
前記第1のリソース群に対して設定される待ち受け期間は、前記第2のリソース群に対して設定される待ち受け期間よりも短い、
請求項5に記載の端末装置。
【請求項7】
前記ランダムアクセス応答信号は、DMRS受信に用いる制御チャネルにより受信する、
請求項1に記載の端末装置。
【請求項8】
基地局より通知される第1のリソース群または第2のリソース群に関するリソース情報を含む報知信号を受信し、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、前記第1のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、前記第2のリソース群に含まれるリソースを用いて、ランダムアクセスプリアンブルを送信し、
前記送信したランダムアクセスプリアンブルのリソースに対する、ランダムアクセス応答信号を、前記報知信号に含まれるリソース群に関するリソース情報に応じてDMRSまたはCRSを用いて受信する、
通信方法。
【請求項9】
前記ランダムアクセス応答信号を、前記報知信号に、前記第1のリソース群に関するリソース情報が含まれている場合、DMRSを用いて受信し、
前記報知信号に、前記第1のリソース群に関するリソース情報が含まれていない場合、CRSを用いて受信する、
請求項8に記載の通信方法。
【請求項10】
前記ランダムアクセス応答信号がマッピングされるデータリソースに関する情報を、制御チャネルにより送信する、
請求項8に記載の通信方法。
【請求項11】
前記基地局と前記基地局からの前記報知信号を受信する端末装置との間の伝搬減衰値の閾値に対応して、前記第1のリソース群はさらに複数のリソース群に分割され、
前記伝搬減衰値と対応づけられた前記複数のリソース群に関する情報を受信する、
請求項8に記載の通信方法。
【請求項12】
前記第1のリソース群と、前記第2のリソース群に対して、それぞれ異なる前記ランダムアクセス応答信号の待ち受け期間を設定される、
請求項8に記載の通信方法。
【請求項13】
前記第1のリソース群に対して設定される待ち受け期間は、前記第2のリソース群に対して設定される待ち受け期間よりも短い、
請求項12に記載の通信方法。
【請求項14】
前記ランダムアクセス応答信号は、DMRS受信に用いる制御チャネルにより受信する、
請求項8に記載の通信方法。
 
訂正の要旨 審決(決定)の【理由】欄参照。
審理終結日 2019-06-21 
結審通知日 2019-06-26 
審決日 2019-07-10 
出願番号 特願2016-162744(P2016-162744)
審決分類 P 1 41・ 852- Y (H04W)
最終処分 成立  
前審関与審査官 相澤 祐介  
特許庁審判長 中木 努
特許庁審判官 本郷 彰
井上 弘亘
登録日 2017-12-01 
登録番号 特許第6249310号(P6249310)
発明の名称 端末装置及び通信方法  
代理人 鷲田 公一  
代理人 鷲田 公一  
  • この表をプリントする

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ