特許 7535144 無線通信システムにおいてＰＵＣＣＨ送受信方法及び装置

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

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

(11)【特許番号】

(24)【登録日】2024-08-06

(45)【発行日】2024-08-15

(54)【発明の名称】無線通信システムにおいてＰＵＣＣＨ送受信方法及び装置

(51)【国際特許分類】

   H04W 72/0453 20230101AFI20240807BHJP

   H04W 72/232 20230101ALI20240807BHJP

   H04W 28/04 20090101ALI20240807BHJP

   H04W 72/0457 20230101ALI20240807BHJP

【ＦＩ】

H04W72/0453 110

H04W72/232

H04W28/04 110

H04W72/0457

【請求項の数】 9

(21)【出願番号】P 2023018116

(22)【出願日】2023-02-09

(65)【公開番号】P2023118094

(43)【公開日】2023-08-24

【審査請求日】2023-02-09

(31)【優先権主張番号】63/309,488

(32)【優先日】2022-02-11

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

【氏名又は名称原語表記】ＬＧ ＥＬＥＣＴＲＯＮＩＣＳ ＩＮＣ．

【住所又は居所原語表記】１２８， Ｙｅｏｕｉ－ｄａｅｒｏ， Ｙｅｏｎｇｄｅｕｎｇｐｏ－ｇｕ， ０７３３６ Ｓｅｏｕｌ，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本 実

(72)【発明者】

【氏名】キム チェヒョン

(72)【発明者】

【氏名】ヤン ソクチェル

(72)【発明者】

【氏名】イ ヨンデ

(72)【発明者】

【氏名】ファン ソンケ

【審査官】青木 健

(56)【参考文献】

【文献】特表２０１７－５２８９７９（ＪＰ，Ａ）

【文献】Xiaomi，Discussion on the remaining issues of reduced UE bandwidth for RedCap，3GPP TSG RAN WG1 #107-e R1-2111578，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_107-e/Docs/R1-2111578.zip>，2021年11月05日

【文献】Sharp，Discussion on reduced maximum UE bandwidth，3GPP TSG RAN WG1 #107-e R1-2112015，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_107-e/Docs/R1-2112015.zip>，2020年11月06日

【文献】vivo，Clarification on PUCCH-ConfigCommon，3GPP TSG RAN WG2 #103bis R2-1814184，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_103bis/Docs/R2-1814184.zip>，2018年09月28日

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

Ｈ０４Ｗ ４／００ － ９９／００

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

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

【請求項1】

無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を送信する方法であって、減少した能力（ｒｅｄｃａｐ：ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末によって行われる前記方法は、
基地局からシステム情報を受信する段階であって、前記システム情報は、ＰＵＣＣＨリソースに対する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングにおいて追加のＰＲＢオフセットに対する第１情報、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに対する第２情報、及びセル特定ＰＵＣＣＨリソースのセットを設定するための第３情報を含む、段階と、
前記基地局から、ＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）をスケジュールする下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を受信する段階と、
前記基地局から前記ＰＤＳＣＨを受信する段階と、
前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）情報を前記ＰＵＣＣＨで前記基地局に送信する段階と、を含み、
前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）されることに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第３情報によって決定されたＰＲＢオフセットと前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定される、方法。

【請求項2】

前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンクＢＷＰの下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされることを指示することに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを正（ｐｏｓｉｔｉｖｅ）の値で適用して決定される、請求項１に記載の方法。

【請求項3】

前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンクＢＷＰの上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされることを指示することに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを負（ｎｅｇａｔｉｖｅ）の値で適用して決定される、請求項１に記載の方法。

【請求項4】

前記ｒｅｄｃａｐ端末が専用ＰＵＣＣＨリソース設定を受信しないことに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスが、前記第２情報に基づいて前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定される、請求項１に記載の方法。

【請求項5】

前記ＰＵＣＣＨの送信に対する周波数ホッピングが活性（ｅｎａｂｌｅｄ）されるか又は非活性（ｄｉｓａｂｌｅｄ）されるかは、前記基地局による設定に基づいて決定される、請求項１に記載の方法。

【請求項6】

前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされることを指示することに基づいて、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮して、ＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが増加する、請求項１に記載の方法。

【請求項7】

前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされることを指示することに基づいて、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮して、ＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが減少する、請求項１に記載の方法。

【請求項8】

無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を送信する減少した能力（ｒｅｄｃａｐ：ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末であって、前記ｒｅｄｃａｐ端末は、
無線信号を送受信するための少なくとも一つの送受信部（ｔｒａｎｓｃｅｉｖｅｒ）と、
前記少なくとも一つの送受信部を制御する少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
基地局からシステム情報を受信し、前記システム情報は、ＰＵＣＣＨリソースに対する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングにおいて追加のＰＲＢオフセットに対する第１情報、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに対する第２情報、及びセル特定ＰＵＣＣＨリソースのセットを設定するための第３情報を含み、
前記基地局から、ＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）をスケジュールする下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を受信し、
前記基地局から前記ＰＤＳＣＨを受信し、
前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）情報を前記ＰＵＣＣＨで前記基地局に送信するように設定され、
前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）されることに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第３情報によって決定されたＰＲＢオフセットと前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定される、端末。

【請求項9】

無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を受信する基地局であって、前記基地局は、
無線信号を送受信するための少なくとも一つの送受信部（ｔｒａｎｓｃｅｉｖｅｒ）と、
前記少なくとも一つの送受信部を制御する少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
減少した能力（ｒｅｄｃａｐ：ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末にシステム情報を送信し、前記システム情報は、ＰＵＣＣＨリソースに対する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングにおいて追加のＰＲＢオフセットに対する第１情報、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに対する第２情報、及びセル特定ＰＵＣＣＨリソースのセットを設定するための第３情報を含み、
前記ｒｅｄｃａｐ端末に、ＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）をスケジュールする下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を送信し、
前記ｒｅｄｃａｐ端末に前記ＰＤＳＣＨを送信し、
前記ｒｅｄｃａｐ端末から、前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）情報を前記ＰＵＣＣＨで受信するように設定され、
前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）されることに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第３情報によって決定されたＰＲＢオフセットと前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定される、基地局。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、無線通信システムに関し、より詳細には、無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を送受信する方法及び装置に関する。

【背景技術】

【0002】

移動通信システムは、ユーザの活動性を保障しながら音声サービスを提供するために開発された。しかしながら、移動通信システムは音声に留まらずデータサービスまで領域を拡張し、現在、爆発的なトラフィックの増加によってリソースの不足現象が発生しており、ユーザもより高速のサービスを要求していることから、より発展した移動通信システムが望まれている。

【0003】

次世代移動通信システムの要求条件は、大きく、爆発的なデータトラフィックの受容、ユーザ当たり送信率の画期的な増加、大幅に増加した連結デバイス個数の受容、非常に低い端対端遅延（Ｅｎｄ－ｔｏ－Ｅｎｄ Ｌａｔｅｎｃｙ）、高エネルギー効率の支援である。そのために、二重接続性（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）、大規模多重入出力（Ｍａｓｓｉｖｅ ＭＩＭＯ：Ｍａｓｓｉｖｅ Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）、全二重（Ｉｎ－ｂａｎｄ Ｆｕｌｌ Ｄｕｐｌｅｘ）、非直交多重接続（ＮＯＭＡ：Ｎｏｎ－Ｏｒｔｈｏｇｏｎａｌ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、超広帯域（Ｓｕｐｅｒ ｗｉｄｅｂａｎｄ）支援、端末ネットワーキング（Ｄｅｖｉｃｅ Ｎｅｔｗｏｒｋｉｎｇ）などの様々な技術が研究されている。

【発明の概要】

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

【0004】

本開示の技術的課題は、特定タイプの端末（例えば、減少した能力（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末）に対するＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を送受信する方法及び装置を提供することである。

【0005】

また、本開示の技術的課題は、特定タイプの端末（例えば、減少した能力（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末）がランダムアクセス手続を行うためのメッセージを送受信する方法及び装置を提供することである。

【0006】

本開示で遂げようとする技術的課題は、以上で言及した技術的課題に制限されず、言及していない別の技術的課題は、以下の記載から、本開示の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

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

【0007】

本開示の一態様に係る無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を送信する方法は：基地局からシステム情報を受信する段階であって、前記システム情報はＰＵＣＣＨリソースに対する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングにおいて追加のＰＲＢオフセットに対する第１情報、及び前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに対する第２情報を含む、段階、前記基地局から、ＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）をスケジュールする下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を受信する段階、前記基地局から前記ＰＤＳＣＨを受信する段階、及び、前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）情報を前記ＰＵＣＣＨで前記基地局に送信する段階を含むことができる。前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）されることに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0008】

本開示の他の態様に係る無線通信システムにおいてＰＵＣＣＨ（ｐｈｙｓｉｃａｌ ｕｐｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）を受信する方法は：減少した能力（ｒｅｄｃａｐ：ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末にシステム情報を送信する段階であって、前記システム情報は、ＰＵＣＣＨリソースに対する物理リソースブロック（ＰＲＢ：ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングにおいて追加のＰＲＢオフセットに対する第１情報、及び前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに対する第２情報を含む、段階、前記ｒｅｄｃａｐ端末にＰＤＳＣＨ（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）をスケジュールする下りリンク制御情報（ＤＣＩ：ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｉｎｆｏｒｍａｔｉｏｎ）を送信する段階、前記ｒｅｄｃａｐ端末に前記ＰＤＳＣＨを送信する段階、及び、前記ｒｅｄｃａｐ端末から前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ（ｈｙｂｒｉｄ ａｕｔｏｍａｔｉｃ ｒｅｐｅａｔ ｒｅｑｕｅｓｔ－ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）情報を前記ＰＵＣＣＨで受信する段階を含むことができる。前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）されることに基づいて、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【発明の効果】

【0009】

本開示の実施例によれば、一般端末の初期上りリンク帯域幅部分と特定タイプの端末（例えば、減少した能力（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末）の初期上りリンク帯域幅部分が重なり合っても、一般端末の上りリンク送信のためのリソースが断片化（ｆｒａｇｍｅｎｔａｔｉｏｎ）する問題を防止することができる。

【0010】

また、本開示の実施例によれば、一般端末の初期上りリンク帯域幅部分と特定タイプの端末（例えば、減少した能力（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末）の初期上りリンク帯域幅部分が重なり合っても、一般端末の上りリンク送信と特定タイプの端末の上りリンク送信との衝突を防止でき、これによって干渉及び性能低下を防止することができる。

【0011】

また、本開示の実施例によれば、特定タイプの端末（例えば、減少した能力（ｒｅｄｕｃｅｄ ｃａｐａｂｉｌｉｔｙ）端末）のランダムアクセス手続などの動作を円滑に支援することができる。

【0012】

本開示から得られる効果は、以上で言及した効果に制限されず、言及していない別の効果は、以下の記載から、本開示の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

【図面の簡単な説明】

【0013】

本開示に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本開示に関する実施例を提供し、詳細な説明と共に本開示の技術的特徴を説明する。

【図1】本開示が適用可能な無線通信システムの構造を例示する。

【図2】本開示が適用可能な無線通信システムにおいてフレーム構造を例示する。

【図3】本開示が適用可能な無線通信システムにおいてリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）を例示する。

【図4】本開示が適用可能な無線通信システムにおいて物理リソースブロック（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）を例示する。

【図5】本開示が適用可能な無線通信システムにおいてスロット構造を例示する。

【図6】本開示が適用可能な無線通信システムにおいて用いられる物理チャネル及びそれらを用いた一般の信号送受信方法を例示する。

【図7】システム情報取得過程を例示する。

【図8】本開示が適用可能な無線通信システムにおいてランダム接続過程を示す。

【図9】本開示が適用可能な無線通信システムにおいて２－段階ランダム接続過程を示す。

【図10】本開示が適用可能な無線通信システムにおいてｒｅｄｃａｐ装置の装置タイプを報告する手続を例示する。

【図11】本開示の一実施例に係る周波数ホッピングがないＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図12】本開示の一実施例に係る周波数ホッピングを考慮したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図13】本開示の一実施例に係る周波数ホッピングを考慮したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図14】本開示の一実施例に係る周波数ホッピングを考慮したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図15】本開示の一実施例に係るＭＯＤ演算を適用したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図16】本開示の一実施例に係るミラーリングを適用したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【図17】本開示の一実施例に係る一般ＵＥの初期ＵＬ ＢＷＰとｒｅｄｃａｐ ＵＥの初期ＢＷＰの設定を例示する図である。

【図18】本開示の一実施例に係る周波数ホッピングを用いたｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図19】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図20】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図21】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図22】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図23】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図24】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図25】本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【図26】本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する基地局と端末間のシグナリング手続を例示する図である。

【図27】本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する端末の動作を例示する図である。

【図28】本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する基地局の動作を例示する図である。

【図29】本開示の一実施例に係る無線通信装置を例示するブロック構成図である。

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

【0014】

以下、本開示に係る好ましい実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本開示の例示的な実施形態を説明するためのもので、本開示の実施が可能な唯一の実施形態を示すためのものではない。以下の詳細な説明は、本開示の完全な理解を提供するために具体的細部事項を含む。ただし、当業者には、このような具体的細部事項無しにも本開示が実施可能であることが理解される。

【0015】

場合によって、本開示の概念が曖昧になることを避けるために、公知の構造及び装置が省略されてもよく、各構造及び装置の核心機能を中心にしたブロック図の形式で示されてもよい。

【0016】

本開示において、ある構成要素が他の構成要素と“連結”、“結合”又は“接続”されているとき、これは直接の連結関係の他、それらの間にさらに他の構成要素が存在する間接の連結関係も含むことができる。また、本開示において用語“含む”又は“有する”とは、言及された特徴、段階、動作、要素及び／又は構成要素の存在を特定するものの、一つ以上の他の特徴、段階、動作、要素、構成要素及び／又はそれらのグループの存在又は追加を排除しない。

【0017】

本開示において、“第１”、“第２”などの用語は、一つの構成要素を他の構成要素から区別する目的に使われるだけで、構成要素を制限するために使われることはなく、特に言及されない限り、構成要素間の順序又は重要度などを限定しない。したがって、本開示の範囲内で、一実施例における第１構成要素は他の実施例において第２構成要素と称することもでき、同様に、一実施例における第２構成要素を他の実施例において第１構成要素と称することもできる。

【0018】

本開示で使われる用語は、特定実施例に関する説明のためのもので、特許請求の範囲を制限するためのものではない。実施例の説明及び添付する特許請求の範囲で使用される通り、単数形態は、文脈において特に断らない限り、複数形態も含むように意図したものである。本開示に使われる用語“及び／又は”は、関連した列挙項目のうちの一つを指してもよく、又はそれらのうち２つ以上の任意の及び全ての可能な組合せを指して含むことを意味する。また、本開示において、単語の間における“／”は、別に断らない限り、“及び／又は”と同じ意味を有する。

【0019】

本開示は、無線通信ネットワーク又は無線通信システムを対象にして説明し、無線通信ネットワークにおいてなされる動作は、当該無線通信ネットワークを管轄する装置（例えば、基地局）がネットワークを制御し、信号を送信（ｔｒａｎｓｍｉｔ）又は受信（ｒｅｃｅｉｖｅ）する過程においてなされるか、当該無線ネットワークに結合した端末がネットワークとの又は端末間の信号を送信又は受信する過程においてなされてよい。

【0020】

本開示において、チャネルを送信又は受信するということは、当該チャネルで情報又は信号を送信又は受信するという意味を含む。例えば、制御チャネルを送信するということは、制御チャネルで制御情報又は信号を送信するということを意味する。類似に、データチャネルを送信するということは、データチャネルでデータ情報又は信号を送信するということを意味する。

【0021】

以下において、下りリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）は、基地局から端末への通信を意味し、上りリンク（ＵＬ：ｕｐｌｉｎｋ）は、端末から基地局への通信を意味する。下りリンクにおいて、送信機は基地局の一部であり、受信機は端末の一部であってよい。上りリンクにおいて、送信機は端末の一部であり、受信機は基地局の一部であってよい。基地局は第１通信装置と、端末は第２通信装置と表現されてよい。基地局（ＢＳ：Ｂａｓｅ Ｓｔａｔｉｏｎ）は、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）、Ｎｏｄｅ Ｂ、ｅＮＢ（ｅｖｏｌｖｅｄ－ＮｏｄｅＢ）、ｇＮＢ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ ＮｏｄｅＢ）、ＢＴＳ（ｂａｓｅ ｔｒａｎｓｃｅｉｖｅｒ ｓｙｓｔｅｍ）、アクセスポイント（ＡＰ：Ａｃｃｅｓｓ Ｐｏｉｎｔ）、ネットワーク（５Ｇネットワーク）、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）システム／モジュール、ＲＳＵ（ｒｏａｄ ｓｉｄｅ ｕｎｉｔ）、ロボット（ｒｏｂｏｔ）、ドローン（ＵＡＶ：Ｕｎｍａｎｎｅｄ Ａｅｒｉａｌ Ｖｅｈｉｃｌｅ）、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）装置、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）装置などの用語に代替されてよい。また、端末（Ｔｅｒｍｉｎａｌ）は、固定されるか移動性を有してよく、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＷＴ（Ｗｉｒｅｌｅｓｓ ｔｅｒｍｉｎａｌ）、ＭＴＣ（Ｍａｃｈｉｎｅ－Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）装置、Ｍ２Ｍ（Ｍａｃｈｉｎｅ－ｔｏ－Ｍａｃｈｉｎｅ）装置、Ｄ２Ｄ（Ｄｅｖｉｃｅ－ｔｏ－Ｄｅｖｉｃｅ）装置、車両（ｖｅｈｉｃｌｅ）、ＲＳＵ（ｒｏａｄ ｓｉｄｅ ｕｎｉｔ）、ロボット（ｒｏｂｏｔ）、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）モジュール、ドローン（ＵＡＶ：Ｕｎｍａｎｎｅｄ Ａｅｒｉａｌ Ｖｅｈｉｃｌｅ）、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）装置、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）装置などの用語に代替されてよい。

【0022】

以下の技術は、ＣＤＭＡ、ＦＤＭＡ、ＴＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどのような様々な無線接続システムに用いられてよい。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術によって具現されてよい。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって具現されてよい。ＯＦＤＭＡは、ＩＥＥＥ ８０２．１１（Ｗｉ－Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２－２０、Ｅ－ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＴＲＡ）などのような無線技術によって具現されてよい。ＵＴＲＡは、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標）ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）は、Ｅ－ＵＴＲＡを用いるＥ－ＵＭＴＳ（Ｅｖｏｌｖｅｄ ＵＭＴＳ）の一部であり、ＬＴＥ－Ａ（Ａｄｖａｎｃｅｄ）／ＬＴＥ－Ａ ｐｒｏは、３ＧＰＰ ＬＴＥの進化したバージョンである。３ＧＰＰ ＮＲ（Ｎｅｗ Ｒａｄｉｏ ｏｒ Ｎｅｗ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）は、３ＧＰＰ ＬＴＥ／ＬＴＥ－Ａ／ＬＴＥ－Ａ ｐｒｏの進化したバージョンである。

【0023】

説明を明確にするために、３ＧＰＰ通信システム（例えば、ＬＴＥ－Ａ、ＮＲ）に基づいて説明するが、本開示の技術的思想がそれに制限されるものではない。ＬＴＥは、３ＧＰＰ ＴＳ（Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ） ３６．ｘｘｘ Ｒｅｌｅａｓｅ ８以後の技術を意味する。細部的に、３ＧＰＰ ＴＳ ３６．ｘｘｘ Ｒｅｌｅａｓｅ １０以後のＬＴＥ技術はＬＴＥ－Ａと呼ばれ、３ＧＰＰ ＴＳ ３６．ｘｘｘ Ｒｅｌｅａｓｅ １３以後のＬＴＥ技術はＬＴＥ－Ａ ｐｒｏと呼ばれる。３ＧＰＰ ＮＲは、ＴＳ ３８．ｘｘｘ Ｒｅｌｅａｓｅ １５以後の技術を意味する。ＬＴＥ／ＮＲは３ＧＰＰシステムと呼ばれてよい。“ｘｘｘ”は、標準文書細部番号を意味する。ＬＴＥ／ＮＲは３ＧＰＰシステムと呼ばれてよい。本開示の説明に用いられる背景技術、用語、略語などに関しては、本開示の前に公開された標準文書に記載の事項を参照できる。例えば、次の文書を参照できる。

【0024】

３ＧＰＰ ＬＴＥでは、ＴＳ ３６．２１１（物理チャネル及び変調）、ＴＳ ３６．２１２（多重化及びチャネルコーディング）、ＴＳ ３６．２１３（物理層手続）、ＴＳ ３６．３００（説明全般）、ＴＳ ３６．３３１（無線リソース制御）を参照できる。

【0025】

３ＧＰＰ ＮＲでは、ＴＳ ３８．２１１（物理チャネル及び変調）、ＴＳ ３８．２１２（多重化及びチャネルコーディング）、ＴＳ ３８．２１３（制御のための物理層手続）、ＴＳ ３８．２１４（データのための物理層手続）、ＴＳ ３８．３００（ＮＲ及びＮＧ－ＲＡＮ（Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ－Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）説明全般）、ＴＳ ３８．３３１（無線リソース制御プロトコル規格）を参照できる。

【0026】

本開示で使用可能な用語の略字は次のように定義される。

【0027】

－ ＢＭ：ビーム管理（ｂｅａｍ ｍａｎａｇｅｍｅｎｔ）
－ ＣＱＩ：チャネル品質指示子（ｃｈａｎｎｅｌ ｑｕａｌｉｔｙ ｉｎｄｉｃａｔｏｒ）
－ ＣＲＩ：チャネル状態情報－参照信号リソース指示子（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ－ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｓｏｕｒｃｅ ｉｎｄｉｃａｔｏｒ）
－ ＣＳＩ：チャネル状態情報（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ）
－ ＣＳＩ－ＩＭ：チャネル状態情報－干渉測定（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ－ｉｎｔｅｒｆｅｒｅｎｃｅ ｍｅａｓｕｒｅｍｅｎｔ）
－ ＣＳＩ－ＲＳ：チャネル状態情報－参照信号（ｃｈａｎｎｅｌ ｓｔａｔｅ ｉｎｆｏｒｍａｔｉｏｎ－ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）
－ ＤＭＲＳ：復調参照信号（ｄｅｍｏｄｕｌａｔｉｏｎ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）
－ ＦＤＭ：周波数分割多重化（ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）
－ ＦＦＴ：高速フーリエ変換（ｆａｓｔ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ）
－ ＩＦＤＭＡ：インターリーブされた周波数分割多重アクセス（ｉｎｔｅｒｌｅａｖｅｄ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ）
－ ＩＦＦＴ：逆高速フーリエ変換（ｉｎｖｅｒｓｅ ｆａｓｔ Ｆｏｕｒｉｅｒ ｔｒａｎｓｆｏｒｍ）
－ Ｌ１－ＲＳＲＰ：第１レイヤ参照信号受信電力（Ｌａｙｅｒ １ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）
－ Ｌ１－ＲＳＲＱ：第１レイヤ参照信号受信品質（Ｌａｙｅｒ １ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｑｕａｌｉｔｙ）
－ ＭＡＣ：媒体アクセス制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）
－ ＮＺＰ：ノンゼロパワー（ｎｏｎ－ｚｅｒｏ ｐｏｗｅｒ）
－ ＯＦＤＭ：直交周波数分割多重化（ｏｒｔｈｏｇｏｎａｌ ｆｒｅｑｕｅｎｃｙ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）
－ ＰＤＣＣＨ：物理下りリンク制御チャネル（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｃｏｎｔｒｏｌ ｃｈａｎｎｅｌ）
－ ＰＤＳＣＨ：物理下りリンク共有チャネル（ｐｈｙｓｉｃａｌ ｄｏｗｎｌｉｎｋ ｓｈａｒｅｄ ｃｈａｎｎｅｌ）
－ ＰＭＩ：プリコーディング行列指示子（ｐｒｅｃｏｄｉｎｇ ｍａｔｒｉｘ ｉｎｄｉｃａｔｏｒ）
－ ＲＥ：リソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）
－ ＲＩ：ランク指示子（Ｒａｎｋ ｉｎｄｉｃａｔｏｒ）
－ ＲＲＣ：無線リソース制御（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）
－ ＲＳＳＩ：受信信号強度指示子（ｒｅｃｅｉｖｅｄ ｓｉｇｎａｌ ｓｔｒｅｎｇｔｈ ｉｎｄｉｃａｔｏｒ）
－ Ｒｘ：受信（Ｒｅｃｅｐｔｉｏｎ）
－ ＱＣＬ：準同一位置（ｑｕａｓｉ ｃｏ－ｌｏｃａｔｉｏｎ）
－ ＳＩＮＲ：信号対干渉及び雑音比（ｓｉｇｎａｌ ｔｏ ｉｎｔｅｒｆｅｒｅｎｃｅ ａｎｄ ｎｏｉｓｅ ｒａｔｉｏ）
－ ＳＳＢ（又は、ＳＳ／ＰＢＣＨブロック）：同期信号ブロック（プライマリ同期信号（ＰＳＳ：ｐｒｉｍａｒｙ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｉｇｎａｌ）、セカンダリ同期信号（ＳＳＳ：ｓｅｃｏｎｄａｒｙ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｉｇｎａｌ）及び物理放送チャネル（ＰＢＣＨ：ｐｈｙｓｉｃａｌ ｂｒｏａｄｃａｓｔ ｃｈａｎｎｅｌ）を含む）
－ ＴＤＭ：時間分割多重化（ｔｉｍｅ ｄｉｖｉｓｉｏｎ ｍｕｌｔｉｐｌｅｘｉｎｇ）
－ ＴＲＰ：送信及び受信ポイント（ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ ｒｅｃｅｐｔｉｏｎ ｐｏｉｎｔ）
－ ＴＲＳ：トラッキング参照信号（ｔｒａｃｋｉｎｇ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）
－ Ｔｘ：送信（ｔｒａｎｓｍｉｓｓｉｏｎ）
－ ＵＥ：ユーザ装置（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）
－ ＺＰ：ゼロパワー（ｚｅｒｏ ｐｏｗｅｒ）

【0028】

システム一般
より多い通信機器がより大きい通信容量を要求するにつれ、既存の無線アクセス技術（ＲＡＴ：ｒａｄｉｏ ａｃｃｅｓｓ ｔｅｃｈｎｏｌｏｇｙ）に比べて向上したモバイルブロードバンド（ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ）通信への必要性が台頭している。また、多数の機器及びモノを連結していつどこででも様々なサービスを提供するマッシブ（ｍａｓｓｉｖｅ）ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）も次世代通信において考慮される主要課題の一つである。これに加え、信頼度（ｒｅｌｉａｂｉｌｉｔｙ）及び遅延（ｌａｔｅｎｃｙ）に敏感なサービス／端末を考慮した通信システムデザインも議論されている。このようにｅＭＢＢ（ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｍｍｔｃ（ｍａｓｓｉｖｅ ＭＴＣ）、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などを考慮した次世代ＲＡＴの導入が議論されており、本開示では便宜上、当該技術をＮＲと呼ぶ。ＮＲは、５Ｇ ＲＡＴの一例を表す表現である。

【0029】

ＮＲを含む新しいＲＡＴシステムは、ＯＦＤＭ送信方式又はこれと類似の送信方式を用いる。新しいＲＡＴシステムは、ＬＴＥのＯＦＤＭパラメータとは異なるＯＦＤＭパラメータに従い得る。又は、新しいＲＡＴシステムは、既存のＬＴＥ／ＬＴＥ－Ａのヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）にそのまま従うが、より大きいシステム帯域幅（例えば、１００ＭＨｚ）を支援できる。又は、一つのセルが複数個のヌメロロジーを支援することもできる。すなわち、互いに異なるヌメロロジーで動作する端末が一つのセル内に共存してもよい。

【0030】

ヌメロロジーは、周波数領域において一つのサブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）に対応する。参照サブキャリア間隔（Ｒｅｆｅｒｅｎｃｅ ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）を整数Ｎでスケーリング（ｓｃａｌｉｎｇ）することにより、互いに異なるヌメロロジーを定義できる。

【0031】

図１には、本開示が適用可能な無線通信システムの構造を例示する。

【0032】

図１を参照すると、ＮＧ－ＲＡＮは、ＮＧ－ＲＡ（ＮＧ－Ｒａｄｉｏ Ａｃｃｅｓｓ）ユーザ平面（すなわち、新しいＡＳ（ａｃｃｅｓｓ ｓｔｒａｔｕｍ）サブ層／ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）／ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）／ＭＡＣ／ＰＨＹ）及びＵＥに対する制御平面（ＲＲＣ）プロトコル終端を提供するｇＮＢで構成される。前記ｇＮＢはＸｎインターフェースを介して相互連結される。前記ｇＮＢは、また、ＮＧインターフェースを介してＮＧＣ（Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）に連結される。より具体的には、前記ｇＮＢは、Ｎ２インターフェースを介してＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）に、Ｎ３インターフェースを介してＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）に連結される。

【0033】

図２には、本開示が適用可能な無線通信システムにおいてフレーム構造を例示する。

【0034】

ＮＲシステムは、多数のヌメロロジー（ｎｕｍｅｒｏｌｏｇｙ）を支援できる。ここで、ヌメロロジーは、サブキャリア間隔（ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）と循環前置（ＣＰ：Ｃｙｃｌｉｃ Ｐｒｅｆｉｘ）オーバーヘッドによって定義されてよい。このとき、多数のサブキャリア間隔は、基本（参照）サブキャリア間隔を整数Ｎ（又は、μ）でスケーリング（ｓｃａｌｉｎｇ）することによって誘導されてよい。また、非常に高い搬送波周波数において非常に低いサブキャリア間隔を利用しないと仮定されても、用いられるヌメロロジーは周波数帯域と独立に選択されてよい。また、ＮＲシステムでは多数のヌメロロジーによる様々なフレーム構造が支援されてよい。

【0035】

以下、ＮＲシステムにおいて考慮可能なＯＦＤＭヌメロロジー及びフレーム構造について説明する。ＮＲシステムにおいて支援される多数のＯＦＤＭヌメロロジーは、下表１のように定義されてよい。

【0036】

【表1】

【0037】

ＮＲは、様々な５Ｇサービスを支援するための多数のヌメロロジー（又は、サブキャリア間隔（ＳＣＳ：ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ））を支援する。例えば、ＳＣＳが１５ｋＨｚである場合に、伝統的なセルラーバンドでの広い領域（ｗｉｄｅ ａｒｅａ）を支援し、ＳＣＳが３０ｋＨｚ／６０ｋＨｚである場合に、密集した都市（ｄｅｎｓｅ－ｕｒｂａｎ）、より低い遅延（ｌｏｗｅｒ ｌａｔｅｎｃｙ）、及びより広いキャリア帯域幅（ｗｉｄｅｒ ｃａｒｒｉｅｒ ｂａｎｄｗｉｄｔｈ）を支援し、ＳＣＳが６０ｋＨｚ又はそれよりも高い場合に、位相雑音（ｐｈａｓｅ ｎｏｉｓｅ）を克服するために２４．２５ＧＨｚよりも大きい帯域幅を支援する。

【0038】

ＮＲ周波数バンド（ｆｒｅｑｕｅｎｃｙ ｂａｎｄ）は、２タイプ（ＦＲ１、ＦＲ２）の周波数範囲（ｆｒｅｑｕｅｎｃｙ ｒａｎｇｅ）と定義される。ＦＲ１、ＦＲ２は、下表２のように構成されてよい。また、ＦＲ２は、ミリ波（ｍｍＷ：ｍｉｌｌｉｍｅｔｅｒ ｗａｖｅ）を意味できる。

【0039】

【表2】

【0040】

ＮＲシステムにおけるフレーム構造（ｆｒａｍｅ ｓｔｒｕｃｔｕｒｅ）と関連して、時間領域の様々なフィールドのサイズは、Ｔ_ｃ＝１／（Δｆ_ｍａｘ・Ｎ_ｆ）の時間単位の倍数と表現される。ここで、Δｆ_ｍａｘ＝４８０・１０^３Ｈｚであり、Ｎ_ｆ＝４０９６である。下りリンク（ｄｏｗｎｌｉｎｋ）及び上りリンク（ｕｐｌｉｎｋ）送信は、Ｔ_ｆ＝１／（Δｆ_ｍａｘＮ_ｆ／１００）・Ｔ_ｃ＝１０ｍｓの区間を有する無線フレーム（ｒａｄｉｏ ｆｒａｍｅ）で構成（ｏｒｇａｎｉｚｅｄ）される。ここで、無線フレームはそれぞれ、Ｔ_ｓｆ＝（Δｆ_ｍａｘＮ_ｆ／１０００）・Ｔ_ｃ＝１ｍｓの区間を有する１０個のサブフレーム（ｓｕｂｆｒａｍｅ）で構成される。この場合、上りリンクに対する１セットのフレーム及び下りリンクに対する１セットのフレームが存在してよい。また、端末からの上りリンクフレーム番号ｉにおける送信は、当該端末における該当の下りリンクフレームの開始よりＴ_ＴＡ＝（Ｎ_ＴＡ＋Ｎ_{ＴＡ，ｏｆｆｓｅｔ}）Ｔ_ｃ以前に始めなければならない。サブキャリア間隔構成μに対して、スロット（ｓｌｏｔ）は、サブフレーム内でｎ_ｓ ^μ∈｛０，．．．，Ｎ_ｓｌｏｔ ^{ｓｕｂｆｒａｍｅ，μ}－１｝の増加する順序で番号が付けられ、無線フレーム内でｎ_ｓ，ｆ ^μ∈｛０，．．．，Ｎ_ｓｌｏｔ ^{ｆｒａｍｅ，μ}－１｝の増加する順序で番号が付けられる。一つのスロットはＮ_ｓｙｍｂ ^ｓｌｏｔの連続するＯＦＤＭシンボルで構成され、Ｎ_ｓｙｍｂ ^ｓｌｏｔは、ＣＰによって決定される。サブフレームにおいてスロットｎ_ｓ ^μの開始は、同一サブフレームにおいてＯＦＤＭシンボルｎ_ｓ ^μＮ_ｓｙｍｂ ^ｓｌｏｔの開始と時間的に整列される。全ての端末が同時に送信及び受信を行うことができるわけではなく、これは、下りリンクスロット（ｄｏｗｎｌｉｎｋ ｓｌｏｔ）又は上りリンクスロット（ｕｐｌｉｎｋ ｓｌｏｔ）における全てのＯＦＤＭシンボルが用いられ得るわけではことを意味する。

【0041】

表３は、一般ＣＰにおいてスロット別ＯＦＤＭシンボルの個数（Ｎ_ｓｙｍｂ ^ｓｌｏｔ）、無線フレーム別スロットの個数（Ｎ_ｓｌｏｔ ^{ｆｒａｍｅ，μ}）、サブフレーム別スロットの個数（Ｎ_ｓｌｏｔ ^{ｓｕｂｆｒａｍｅ，μ}）を示し、表４は、拡張ＣＰにおいてスロット別ＯＦＤＭシンボルの個数、無線フレーム別スロットの個数、サブフレーム別スロットの個数を示す。

【0042】

【表3】

【0043】

【表4】

【0044】

図２は、μ＝２である場合（ＳＣＳが６０ｋＨｚ）の一例であり、表３を参照すると、１サブフレーム（ｓｕｂｆｒａｍｅ）は４個のスロット（ｓｌｏｔ）を含むことができる。図２に示す１サブフレーム＝｛１，２，４｝スロットは一例であり、１サブフレームに含まれ得るスロットの個数は、表３又は表４のように定義される。また、ミニスロット（ｍｉｎｉ－ｓｌｏｔ）は、２、４又は７シンボルを含むか、それよりも多い又はより少ないシンボルを含むことができる。

【0045】

ＮＲシステムにおける物理リソース（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ）と関連して、アンテナポート（ａｎｔｅｎｎａ ｐｏｒｔ）、リソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）、リソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）、リソースブロック（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）、キャリアパート（ｃａｒｒｉｅｒ ｐａｒｔ）などが考慮されてよい。以下、ＮＲシステムにおいて考慮可能な前記物理リソースについて具体的に説明する。

【0046】

まず、アンテナポートと関連して、アンテナポートは、アンテナポート上のシンボルが運搬されるチャネルを、同一のアンテナポート上の他のシンボルが運搬されるチャネルから推論できるように定義される。一つのアンテナポート上のシンボルが運搬されるチャネルの広範囲特性（ｌａｒｇｅ－ｓｃａｌｅ ｐｒｏｐｅｒｔｙ）が、他のアンテナポート上のシンボルが運搬されるチャネルから類推され得る場合、２個のアンテナポートはＱＣ／ＱＣＬ（ｑｕａｓｉ ｃｏ－ｌｏｃａｔｅｄ或いはｑｕａｓｉ ｃｏ－ｌｏｃａｔｉｏｎ）関係にあると言える。ここで、前記広範囲特性は、遅延拡散（Ｄｅｌａｙ ｓｐｒｅａｄ）、ドップラー拡散（Ｄｏｐｐｌｅｒ ｓｐｒｅａｄ）、周波数シフト（Ｆｒｅｑｕｅｎｃｙ ｓｈｉｆｔ）、平均受信電力（Ａｖｅｒａｇｅ ｒｅｃｅｉｖｅｄ ｐｏｗｅｒ）、受信タイミング（Ｒｅｃｅｉｖｅｄ Ｔｉｍｉｎｇ）のいずれか一つ以上を含む。

【0047】

図３には、本開示が適用可能な無線通信システムにおいてリソースグリッド（ｒｅｓｏｕｒｃｅ ｇｒｉｄ）を例示する。

【0048】

図３を参照すると、リソースグリッドが、周波数領域上にＮ_ＲＢ ^μＮ_ｓｃ ^ＲＢサブキャリアで構成され、一つのサブフレームが１４・２^μＯＦＤＭシンボルで構成されることを例示的に記述するが、これに限定されない。ＮＲシステムにおいて、送信される信号（ｔｒａｎｓｍｉｔｔｅｄ ｓｉｇｎａｌ）は、Ｎ_ＲＢ ^μＮ_ｓｃ ^ＲＢサブキャリアで構成される一つ又はそれ以上のリソースグリッド及び２^μＮ_ｓｙｍｂ ^（μ）のＯＦＤＭシンボルによって説明される。ここで、Ｎ_ＲＢ ^μ≦Ｎ_ＲＢ ^{ｍａｘ，μ}である。前記Ｎ_ＲＢ ^{ｍａｘ，μ}は、最大送信帯域幅を表し、これは、ヌメロロジーだけでなく、上りリンクと下りリンク間にも変わってよい。この場合、μ及びアンテナポートｐ別に一つのリソースグリッドが設定されてよい。μ及びアンテナポートｐに対するリソースグリッドの各要素は、リソース要素（ｒｅｓｏｕｒｃｅ ｅｌｅｍｅｎｔ）と呼ばれ、インデックス対

によって固有に識別される。ここで、ｋ＝０，．．．，Ｎ_ＲＢ ^μＮ_ｓｃ ^ＲＢ－１は、周波数領域上のインデックスであり、

サブフレーム内でシンボルの位置を表す。スロットにおいてリソース要素を示す時には、インデックス対（ｋ，ｌ）が用いられる。ここで、ｌ＝０，．．．，Ｎ_ｓｙｍｂ ^μ－１である。μ及びアンテナポートｐに対するリソース要素

は、複素値（ｃｏｍｐｌｅｘ ｖａｌｕｅ）

に該当する。混同（ｃｏｎｆｕｓｉｏｎ）する危険のない場合或いは特定アンテナポート又はヌメロロジーが特定されない場合には、インデックスｐ及びμはドロップ（ｄｒｏｐ）してよく、その結果、複素値は

又は

になり得る。また、リソースブロック（ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ，ＲＢ）は、周波数領域上のＮ_ｓｃ ^ＲＢ＝１２の連続するサブキャリアと定義される。

【0049】

ポイント（ｐｏｉｎｔ）Ａは、リソースブロックグリッドの共通基準ポイント（ｃｏｍｍｏｎ ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）として働き、次のように取得される。

【0050】

－ プライマリセル（ＰＣｅｌｌ：Ｐｒｉｍａｒｙ Ｃｅｌｌ）ダウンリンクに対するｏｆｆｓｅｔＴｏＰｏｉｎｔＡは、初期セル選択のために端末によって用いられたＳＳ／ＰＢＣＨブロックと重なる最低リソースブロックの最低サブキャリアとポイントＡ間の周波数オフセットを示す。ＦＲ１に対して１５ｋＨｚサブキャリア間隔及びＦＲ２に対して６０ｋＨｚサブキャリア間隔を仮定したリソースブロック単位（ｕｎｉｔ）で表現される。

【0051】

－ ａｂｓｏｌｕｔｅＦｒｅｑｕｅｎｃｙＰｏｉｎｔＡは、ＡＲＦＣＮ（ａｂｓｏｌｕｔｅ ｒａｄｉｏ－ｆｒｅｑｕｅｎｃｙ ｃｈａｎｎｅｌ ｎｕｍｂｅｒ）におけるように表現されたｐｏｉｎｔ Ａの周波数－位置を示す。

【0052】

共通リソースブロック（ｃｏｍｍｏｎ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）は、サブキャリア間隔設定μに対する周波数領域において０から上方に番号づけられる。サブキャリア間隔設定μに対する共通リソースブロック０のサブキャリア０の中心は、‘ポイントＡ’と一致する。周波数領域において共通リソースブロック番号ｎ_ＣＲＢ ^μとサブキャリア間隔設定μに対するリソース要素（ｋ，ｌ）との関係は、下記の式１のように与えられる。

【0053】

【数1】

【0054】

式１で、ｋは、ｋ＝０がポイントＡを中心とするサブキャリアに該当するようにポイントＡに相対的に定義される。物理リソースブロックは、帯域幅パート（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）内で０からＮ_{ＢＷＰ，ｉ} ^{ｓｉｚｅ，μ}－１まで番号が付けられ、ｉは、ＢＷＰの番号である。ＢＷＰ ｉにおいて物理リソースブロックｎ_ＰＲＢと共通リソースブロックｎ_ＣＲＢ間の関係は、下記の式２によって与えられる。

【0055】

【数2】

【0056】

Ｎ_{ＢＷＰ，ｉ} ^{ｓｔａｒｔ，μ}は、ＢＷＰが共通リソースブロック０に相対的に始まる共通リソースブロックである。

【0057】

図４には、本開示が適用可能な無線通信システムにおいて物理リソースブロック（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）を例示する。そして、図５には、本開示が適用可能な無線通信システムにおいてスロット構造を例示する。

【0058】

図４及び図５を参照すると、スロットは、時間ドメインにおいて複数のシンボルを含む。例えば、一般ＣＰでは１スロットが７個のシンボルを含むが、拡張ＣＰでは１スロットが６個のシンボルを含む。

【0059】

搬送波は、周波数ドメインにおいて複数の副搬送波を含む。ＲＢ（Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）は、周波数ドメインにおいて複数（例えば、１２）の連続した副搬送波と定義される。ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）は、周波数ドメインにおいて複数の連続した（物理）リソースブロックと定義され、一つのヌメロロジー（例えば、ＳＣＳ、ＣＰ長など）に対応し得る。搬送波は、最大でＮ個（例えば、５個）のＢＷＰを含むことができる。データ通信は活性化されたＢＷＰで行われ、一つの端末には一つのＢＷＰのみが活性化されてよい。リソースグリッドにおいてそれぞれの要素は、リソース要素（ＲＥ：Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ）と呼ばれ、一つの複素シンボルがマップされてよい。

【0060】

ＮＲシステムは、一つのコンポーネントキャリア（ＣＣ：Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ）当たりに最大４００ＭＨｚまで支援されてよい。このような広帯域ＣＣ（ｗｉｄｅｂａｎｄ ＣＣ）で動作する端末が常にＣＣ全体に対する無線周波数（ＲＦ：ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）チップ（ｃｈｉｐ）をオンにしたままで動作すると、端末バッテリー消耗が増加し得る。或いは、一つの広帯域ＣＣ内に動作する様々な活用ケース（例えば、ｅＭＢＢ、ＵＲＬＬＣ、Ｍｍｔｃ、Ｖ２Ｘなど）を考慮すれば、当該ＣＣ内に周波数帯域別に異なるヌメロロジー（例えば、サブキャリア間隔など）が支援されてよい。或いは、端末別に最大帯域幅に対する能力（ｃａｐａｂｉｌｉｔｙ）が異なることがある。これを考慮して、基地局は広帯域ＣＣの全体帯域幅ではなく一部の帯域幅でのみ動作するように端末に指示してよく、当該一部の帯域幅を便宜上、帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）と定義する。ＢＷＰは、周波数軸上で連続したＲＢで構成されてよく、一つのヌメロロジー（例えば、サブキャリア間隔、ＣＰ長、スロット／ミニスロット区間）に対応し得る。

【0061】

一方、基地局は、端末に設定された一つのＣＣ内でも多数のＢＷＰを設定できる。例えば、ＰＤＣＣＨモニタリングスロットでは相対的に小さい周波数領域を占めるＢＷＰを設定し、ＰＤＣＣＨで指示するＰＤＳＣＨは、それよりも大きいＢＷＰ上にスケジュールされてよい。或いは、特定ＢＷＰにＵＥが集中する場合に、ロードバランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）のために一部の端末に他のＢＷＰを設定してよい。或いは、隣接セル間の周波数ドメインセル間干渉除去（ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ ｉｎｔｅｒ－ｃｅｌｌ ｉｎｔｅｒｆｅｒｅｎｃｅ ｃａｎｃｅｌｌａｔｉｏｎ）などを考慮して、全帯域幅のうち一部のスペクトル（ｓｐｅｃｔｒｕｍ）を排除し、両方のＢＷＰを同一スロット内でも設定できる。すなわち、基地局は、広帯域ＣＣと関連付けられた（ａｓｓｏｃｉａｔｉｏｎ）端末に、少なくとも一つのＤＬ／ＵＬ ＢＷＰを設定できる。基地局は特定時点に設定されたＤＬ／ＵＬ ＢＷＰのうち少なくとも一つのＤＬ／ＵＬ ＢＷＰを（Ｌ１シグナリング又はＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）又はＲＲＣシグナリングなどによって）活性化させることができる。また、基地局は、他の設定されたＤＬ／ＵＬ ＢＷＰへのスイッチングを（Ｌ１シグナリング又はＭＡＣ ＣＥ又はＲＲＣシグナリングなどによって）指示できる。又は、タイマーベースでタイマー値が満了すると、定められたＤＬ／ＵＬ ＢＷＰにスイッチしてもよい。このとき、活性化されたＤＬ／ＵＬ ＢＷＰを活性（ａｃｔｉｖｅ）ＤＬ／ＵＬ ＢＷＰと定義する。ただし、端末が最初接続（ｉｎｉｔｉａｌ ａｃｃｅｓｓ）過程を行っている中であるか、或いはＲＲＣ連結がセットアップ（ｓｅｔ ｕｐ）される前であるなどの状況では、ＤＬ／ＵＬ ＢＷＰに対する設定を受信できないことがあるので、このような状況で端末が仮定するＤＬ／ＵＬ ＢＷＰは、最初活性ＤＬ／ＵＬ ＢＷＰと定義する。

【0062】

図６には、本開示が適用可能な無線通信システムにおいて用いられる物理チャネル及びそれらを用いた一般の信号送受信方法を例示する。

【0063】

無線通信システムにおいて、端末は基地局から下りリンク（Ｄｏｗｎｌｉｎｋ）で情報を受信し、端末は基地局に上りリンク（Ｕｐｌｉｎｋ）で情報を送信する。基地局と端末が送受信する情報は、データ及び様々な制御情報を含み、それらが送受信する情報の種類／用途によって様々な物理チャネルが存在する。

【0064】

端末は、電源が入るか、新しくセルに進入した場合に、基地局と同期を取るなどの初期セル探索（Ｉｎｉｔｉａｌ ｃｅｌｌ ｓｅａｒｃｈ）作業を行う（Ｓ６０１）。そのために、端末は基地局から主同期信号（ＰＳＳ：Ｐｒｉｍａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）及び副同期信号（ＳＳＳ：Ｓｅｃｏｎｄａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）を受信して基地局と同期を取り、セル識別子（ＩＤ：Ｉｄｅｎｔｉｆｉｅｒ）などの情報を取得できる。その後、端末は基地局から物理放送チャネル（ＰＢＣＨ：Ｐｈｙｓｉｃａｌ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）を受信してセル内放送情報を取得できる。一方、端末は、初期セル探索段階で下りリンク参照信号（ＤＬ ＲＳ：Ｄｏｗｎｌｉｎｋ Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ）を受信して下りリンクチャネル状態を確認することができる。

【0065】

初期セル探索を終えた端末は、物理下りリンク制御チャネル（ＰＤＣＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）及び前記ＰＤＣＣＨに乗せられた情報によって物理下りリンク共有チャネル（ＰＤＳＣＨ：Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）を受信し、より具体的なシステム情報をすることが取得できる（Ｓ６０２）。

【0066】

一方、基地局に最初に接続するか、信号送信のための無線リソースがない場合に、端末は、基地局に対して任意接続過程（ＲＡＣＨ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｒｏｃｅｄｕｒｅ）を行うことができる（段階Ｓ６０３～段階Ｓ６０６）。そのために、端末は、物理任意接続チャネル（ＰＲＡＣＨ：Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）で特定シーケンスをプリアンブルとして送信し（Ｓ６０３及びＳ６０５）、プリアンブルに対する応答メッセージを、ＰＤＣＣＨ及び対応するＰＤＳＣＨで受信することができる（Ｓ６０４及びＳ６０６）。競合ベースＲＡＣＨの場合、さらに、衝突解決手続（Ｃｏｎｔｅｎｔｉｏｎ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｃｅｄｕｒｅ）を行うことができる。

【0067】

上述したような手続を行った端末は、その後、一般の上りリンク／下りリンク信号送信手続として、ＰＤＣＣＨ／ＰＤＳＣＨ受信（Ｓ６０７）及び物理上りリンク共有チャネル（ＰＵＳＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）／物理上りリンク制御チャネル（ＰＵＣＣＨ：Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）送信（Ｓ６０８）を行うことができる。特に、端末はＰＤＣＣＨで下りリンク制御情報（ＤＣＩ：Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）を受信する。ここで、ＤＣＩは、端末に対するリソース割り当て情報のような制御情報を含み、その使用目的によってフォーマットが互いに異なる。

【0068】

一方、端末が上りリンクで基地局に送信する又は端末が基地局から受信する制御情報は、下りリンク／上りリンクＡＣＫ／ＮＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｏｎ－Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）信号、ＣＱＩ（Ｃｈａｎｎｅｌ Ｑｕａｌｉｔｙ Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ Ｍａｔｒｉｘ Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ Ｉｎｄｉｃａｔｏｒ）などを含む。３ＧＰＰ ＬＴＥシステムにおいて、端末は上述したＣＱＩ／ＰＭＩ／ＲＩなどの制御情報をＰＵＳＣＨ及び／又はＰＵＣＣＨで送信できる。

【0069】

表５は、ＮＲシステムでのＤＣＩフォーマット（ｆｏｒｍａｔ）の一例を示す。

【0070】

【表5】

【0071】

表５を参照すると、ＤＣＩ ｆｏｒｍａｔ０＿０、０＿１及び０＿２は、ＰＵＳＣＨのスケジューリングに関連したリソース情報（例えば、ＵＬ／ＳＵＬ（Ｓｕｐｐｌｅｍｅｎｔａｒｙ ＵＬ）、周波数リソース割り当て、時間リソース割り当て、周波数ホッピングなど）、伝送ブロック（ＴＢ：Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ）関連情報（例えば、ＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ Ｃｏｄｉｎｇ ａｎｄ Ｓｃｈｅｍｅ）、ＮＤＩ（Ｎｅｗ Ｄａｔａ Ｉｎｄｉｃａｔｏｒ）、ＲＶ（Ｒｅｄｕｎｄａｎｃｙ Ｖｅｒｓｉｏｎ）など）、ＨＡＲＱ（Ｈｙｂｒｉｄ－ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ａｎｄ ｒｅｑｕｅｓｔ）関連情報（例えば、プロセス番号、ＤＡＩ（Ｄｏｗｎｌｉｎｋ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｅｘ）、ＰＤＳＣＨ－ＨＡＲＱフィードバックタイミングなど）、多重アンテナ関連情報（例えば、ＤＭＲＳシーケンス初期化情報、アンテナポート、ＣＳＩ要請など）、電力制御情報（例えば、ＰＵＳＣＨ電力制御など）を含むことができ、ＤＣＩフォーマットのそれぞれに含まれる制御情報は、あらかじめ定義されてよい。

【0072】

ＤＣＩ ｆｏｒｍａｔ ０＿０は、一つのセルにおいてＰＵＳＣＨのスケジューリングに用いられる。ＤＣＩフォーマット０＿０に含まれた情報は、Ｃ－ＲＮＴＩ（Ｃｅｌｌ ＲＮＴＩ：Ｃｅｌｌ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）又はＣＳ－ＲＮＴＩ（Ｃｏｎｆｉｇｕｒｅｄ Ｓｃｈｅｄｕｌｉｎｇ ＲＮＴＩ）又はＭＣＳ－Ｃ－ＲＮＴＩ（Ｍｏｄｕｌａｔｉｏｎ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ Ｃｅｌｌ ＲＮＴＩ）によってＣＲＣ（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）スクランブルされて送信される。

【0073】

ＤＣＩ ｆｏｒｍａｔ ０＿１は、一つのセルにおいて一つ以上のＰＵＳＣＨのスケジューリング、又は設定されたグラント（ＣＧ：ｃｏｎｆｉｇｕｒｅｄ ｇｒａｎｔ）下りリンクフィードバック情報を端末に指示するために用いられる。ＤＣＩ ｆｏｒｍａｔ ０＿１に含まれた情報は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩ又はＳＰ－ＣＳＩ－ＲＮＴＩ（Ｓｅｍｉ－Ｐｅｒｓｉｓｔｅｎｔ ＣＳＩ ＲＮＴＩ）又はＭＣＳ－Ｃ－ＲＮＴＩによってＣＲＣスクランブルされて送信される。

【0074】

ＤＣＩ ｆｏｒｍａｔ ０＿２は、一つのセルにおいてＰＵＳＣＨのスケジューリングに用いられる。ＤＣＩ ｆｏｒｍａｔ ０＿２に含まれた情報は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩ又はＳＰ－ＣＳＩ－ＲＮＴＩ又はＭＣＳ－Ｃ－ＲＮＴＩによってＣＲＣスクランブルされて送信される。

【0075】

次に、ＤＣＩ ｆｏｒｍａｔ １＿０、１＿１及び１＿２は、ＰＤＳＣＨのスケジューリングに関連したリソース情報（例えば、周波数リソース割り当て、時間リソース割り当て、ＶＲＢ（ｖｉｒｔｕａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）－ＰＲＢ（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）マッピングなど）、伝送ブロック（ＴＢ）関連情報（例えば、ＭＣＳ、ＮＤＩ、ＲＶなど）、ＨＡＲＱ関連情報（例えば、プロセス番号、ＤＡＩ、ＰＤＳＣＨ－ＨＡＲＱフィードバックタイミングなど）、多重アンテナ関連情報（例えば、アンテナポート、ＴＣＩ（ｔｒａｎｓｍｉｓｓｉｏｎ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎｄｉｃａｔｏｒ）、ＳＲＳ（ｓｏｕｎｄｉｎｇ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）要請など）、ＰＵＣＣＨ関連情報（例えば、ＰＵＣＣＨ電力制御、ＰＵＣＣＨリソース指示子など）を含むことができ、ＤＣＩフォーマットのそれぞれに含まれる制御情報は、あらかじめ定義されてよい。

【0076】

ＤＣＩ ｆｏｒｍａｔ １＿０は、一つのＤＬセルにおいてＰＤＳＣＨのスケジューリングのために用いられる。ＤＣＩ ｆｏｒｍａｔ １＿０に含まれた情報は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩ又はＭＣＳ－Ｃ－ＲＮＴＩによってＣＲＣスクランブルされて送信される。

【0077】

ＤＣＩ ｆｏｒｍａｔ １＿１は、一つのセルにおいてＰＤＳＣＨのスケジューリングのために用いられる。ＤＣＩ ｆｏｒｍａｔ １＿１に含まれる情報は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩ又はＭＣＳ－Ｃ－ＲＮＴＩによってＣＲＣスクランブルされて送信される。

【0078】

ＤＣＩ ｆｏｒｍａｔ １＿２は、一つのセルにおいてＰＤＳＣＨのスケジューリングのために用いられる。ＤＣＩ ｆｏｒｍａｔ １＿２に含まれる情報は、Ｃ－ＲＮＴＩ又はＣＳ－ＲＮＴＩ又はＭＣＳ－Ｃ－ＲＮＴＩによってＣＲＣスクランブルされて送信される。

【0079】

システム情報取得
図７には、システム情報取得過程を例示する。

【0080】

端末は、システム情報（ＳＩ：ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）取得過程によってアクセスストラタム（ＡＳ：ａｃｃｅｓｓ ｓｔｒａｔｕｍ）／ノンアクセスストラタム（ＮＡＳ：ｎｏｎ－ａｃｃｅｓｓ ｓｔａｒａｔｕｍ）情報を取得することができる。ＳＩ取得過程は、ＲＲＣアイドル（ＲＲＣ＿ＩＤＬＥ）状態、ＲＲＣ非活性（ＲＲＣ＿ＩＮＡＣＴＩＶＥ）状態及びＲＲＣ連結（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）状態の端末に適用されてよい。

【0081】

ＳＩは、マスター情報ブロック（ＭＩＢ：Ｍａｓｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）と複数のシステム情報ブロック（ＳＩＢ：Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）とに分けられる。ＭＩＢ以外のＳＩは、残った最小のシステム情報（ＲＭＳＩ：Ｒｅｍａｉｎｉｎｇ Ｍｉｎｉｍｕｍ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）及び他のシステム情報（ＯＳＩ：Ｏｔｈｅｒ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ）と呼ぶことができる。ＲＭＳＩはＳＩＢ１に該当し、ＯＳＩは、ＳＩＢ１以外の残りＳＩＢ２以上のＳＩＢのことを指す。詳細な事項は、次を参照できる。

【0082】

ＭＩＢは、ＳＩＢ１（ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋＴｙｐｅ１）受信と関連した情報／パラメータを含み、ＳＳＢ（ＳＳ／ＰＢＣＨ ｂｌｏｃｋ）のＰＢＣＨでて送信される。ＭＩＢの情報は、表６のようなフィールドを含むことができる。

【0083】

表６は、ＭＩＢの一部を例示する。

【0084】

【表6】

【0085】

表７は、表６に例示されたＭＩＢフィールドに対する説明を例示する。

【0086】

【表7】

【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】

【表8-1】

【0156】

【表8-2】

【0157】

ここで、ＮＲ端末機が支援しなければならない支援される最大データ率（ｓｕｐｐｏｒｔｅｄ ｍａｘ ｄａｔａ ｒａｔｅ）を計算する式に必要なパラメータ（ｐａｒａｍｅｔｅｒ）は、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態で基地局要請によってＵＥが報告（ｒｅｐｏｒｔ）する。

【0158】

次は、このようなパラメータと当該パラメータが含まれるＲＲＣ ＩＥを例示する。

【0159】

－ ＦｅａｔｕｒｅＳｅｔＤｏｗｎｌｉｎｋ ＩＥ：ｓｃａｌｉｎｇＦａｃｔｏｒ
－ ＦｅａｔｕｒｅＳｅｔＤｏｗｎｌｉｎｋＰｅｒＣＣ ＩＥ：ｍａｘＮｕｍｂｅｒＭＩＭＯ－ＬａｙｅｒｓＰＤＳＣＨ、ｓｕｐｐｏｒｔｅｄＭｏｄｕｌａｔｉｏｎＯｒｄｅｒＤＬ、ｓｕｐｐｏｒｔｅｄＢａｎｄｗｉｄｔｈＤＬ、ｓｕｐｐｏｒｔｅｄＳｕｂＣａｒｒｉｅｒＳｐａｃｉｎｇＤＬ
－ ＦｅａｔｕｒｅＳｅｔＵｐｌｉｎｋ ＩＥ：ｓｃａｌｉｎｇＦａｃｔｏｒ
－ ＦｅａｔｕｒｅＳｅｔＵｐｌｉｎｋＰｅｒＣＣ ＩＥ：ｍａｘＮｕｍｂｅｒＭＩＭＯ－ＬａｙｅｒｓＣＢ－ＰＵＳＣＨ、ｍａｘＮｕｍｂｅｒＭＩＭＯ－ＬａｙｅｒｓＮｏｎＣＢ－ＰＵＳＣＨ、ｓｕｐｐｏｒｔｅｄＭｏｄｕｌａｔｉｏｎＯｒｄｅｒＵＬ、ｓｕｐｐｏｒｔｅｄＢａｎｄｗｉｄｔｈＵＬ、ｓｕｐｐｏｒｔｅｄＳｕｂＣａｒｒｉｅｒＳｐａｃｉｎｇＵＬ

【0160】

Ｒｅｄｃａｐ端末機の場合、支援される最大データ率を基準にしてｒｅｄｃａｐ装置タイプを分類する方法において、装置タイプ別に上記のパラメータの値を事前に標準に定義し、端末機は、ＵＥ－ＮＲ－Ｃａｐａｂｉｌｉｔｙ ＩＥのＲｅｄＣａｐＤｅｖｉｃｅＴｙｐｅフィールドの値を特定値に設定することによって、基地局にｒｅｄｃａｐ装置タイプ情報と共に上記のパラメータ情報を指示できる。ＮＲ端末機が上記のパラメータをＵＥ能力情報に含めて基地局に送信する従来の動作に比べて、ｒｅｄｃａｐ端末機は、装置タイプとそれに関連した上記のパラメータを一つのフィールドで報告することによってシグナリングオーバーヘッド減少（ｓｉｇｎａｌｉｎｇ ｏｖｅｒｈｅａｄ ｒｅｄｕｃｔｉｏｎ）効果を期待することができる。基地局はＲｅｄＣａｐＤｅｖｉｃｅＴｙｐｅフィールドの値から、装置タイプ、支援される最大データ率、及び上記に列挙したパラメータの値を取得し、端末機スケジューリングなどに用いることができる。

【0161】

－ 分類方法２
又は、主要要求事項を基準にｒｅｄｃａｐ装置タイプを分類するのではなく、Ｒｅｄｃａｐ装置タイプは義務的に支援しなければならない又は選択的に支援可能なＵＥ特徴（の組合せ）を基準に分類できる。これは、使用事例別に支援しなければならない又は支援可能な特徴が明確な場合に、より適切な方法であり得る。Ｒｅｄｃａｐ装置タイプ別に標準に事前に定義したＵＥ特徴（の組合せ）を特徴セット（ｆｅａｔｕｒｅ ｓｅｔ）と称し、そのうち、装置タイプ別に義務的に支援しなければならない特徴セットを、当該装置タイプの又は装置タイプを規定する義務的な特徴セット（ｍａｎｄａｔｏｒｙ ｆｅａｔｕｒｅ ｓｅｔ）と称する。この方法では、ｒｅｄｃａｐ装置タイプの定義が標準に明示されなくてよく、これは、上記のｒｅｄｃａｐ使用事例を、互いに異なる特徴セットを支援する別途の端末機形態で支援するという意味であり得る。

【0162】

上記の方法において、ｒｅｄｃａｐ端末機は、事前に定義された特徴セットを基地局に報告することによって、ｒｅｄｃａｐ装置タイプを又は自分が支援する使用事例を基地局に報告できる。これは、別途のＵＥカテゴリー（ｃａｔｅｇｏｒｙ）を区分せずに様々な選択的な特徴（ｏｐｔｉｏｎａｌ ｆｅａｔｕｒｅ）を用いて様々な使用事例を支援することに、より符合する方法であり得る。上記の特徴セットは、能力パラメータ（ｃａｐａｂｉｌｉｔｙ ｐａｒａｍｅｔｅｒ）の組合せ、すなわち、能力パラメータセット（ｃａｐａｂｉｌｉｔｙ ｐａｒａｍｅｔｅｒ ｓｅｔ）に代替可能である。上記の特徴セットは、ｒｅｄｃａｐ装置タイプ別に事前に標準に定義された義務的な特徴セットであってよい。上記の動作のために、ｒｅｄｃａｐ装置（タイプ）のための候補特徴（ｃａｎｄｉｄａｔｅ ｆｅａｔｕｒｅ）の集合、すなわち特徴プール（ｆｅａｔｕｒｅ ｐｏｏｌ）が事前に標準に定義又は設定されてよい。ｒｅｄｃａｐ装置は、自分のタイプに基づいてタイプ別に定義された義務的な特徴セットを基地局に報告できる。端末機は、義務的な特徴セットに加えて、選択的な特徴セットをさらに基地局に報告できる。端末機は、選択的な特徴セットをさらに選択して報告することによって、追加の動作又は特定使用事例に一層最適化された動作を行うことができる。例えば、監視カメラ使用事例（ｓｕｒｖｅｉｌｌａｎｃｅ ｃａｍｅｒａ ｕｓｅ ｃａｓｅ）のための装置タイプの場合、有線電力供給端末機とバッテリーを用いる電力供給端末機が共存する場合に、義務的な特徴セットには電力節減特徴（ｐｏｗｅｒ ｓａｖｉｎｇ ｆｅａｔｕｒｅ）を含まず、選択的な特徴と指定できる。したがって、端末機細部形態によって選択的に支援し、支援する場合に基地局に報告できる。基地局は、ｒｅｄｃａｐ端末機が報告した特徴セットに該当のパラメータが存在するか否かによって特徴の支援有無を把握し、当該端末機スケジューリング時に反映することができる。

【0163】

－ 分類方法３
又は、Ｒｅｄｃａｐ装置タイプは、能力パラメータ（ｃａｐａｂｉｌｉｔｙ ｐａｒａｍｅｔｅｒ）の組合せを基準に分類されてよい。Ｒｅｄｃａｐ装置タイプを分類する能力パラメータの組合せは、上記のＲｅｄｃａｐ要求事項を決定するパラメータであり得る。例えば、ｒｅｄｃａｐ装置タイプを決定する能力パラメータは、端末機が支援する支援される最大データ率要求事項を決定する端末機が支援する帯域幅（ｂａｎｄｗｉｄｔｈ）、変調次数（ｍｏｄｕｌａｔｉｏｎ ｏｒｄｅｒ）、ＭＩＭＯレイヤ（ＭＩＭＯ ｌａｙｅｒ）数などであってよい。上記のパラメータの値は、実際に支援可能な値を列挙したものであるか、或いは支援する値のうち最大値であってよい。

【0164】

例示）Ｒｅｄｃａｐ装置タイプを決定する能力パラメータ
－ 支援する帯域幅（Ｓｕｐｐｏｒｔｅｄ Ｂａｎｄｗｉｄｔｈ）（ＮＲＢ）：（ｍａｘ）ＵＥチャネル帯域幅（ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）又は（ｍａｘ）ＵＥ送信帯域幅（ｔｒａｎｓｍｉｓｓｉｏｎ ｂａｎｄｗｉｄｔｈ）；ＲＢ単位
－ 支援される変調次数（Ｓｕｐｐｏｒｔｅｄ ｍｏｄｕｌａｔｉｏｎ ｏｒｄｅｒ）（Ｑｍ）：ＱＰＳＫの場合にＱｍ＝２；１６ＱＡＭ場合に４；６４ＱＡＭの場合に６；など。

【0165】

－ 支援されるＭＩＭＯレイヤの個数（ＮＬ）：アンテナの個数（Ｎｕｍｂｅｒ ｏｆ ａｎｔｅｎｎａｓ）（Ｎａ）に代替可能

【0166】

Ｒｅｄｃａｐ装置タイプを決定する能力パラメータの組合せを、当該装置タイプの能力パラメータセット（ｃａｐａｂｉｌｉｔｙ ｐａｒａｍｅｔｅｒ ｓｅｔ）と称する。Ｒｅｄｃａｐ装置タイプは、例えば、能力パラメータセット値を、支援される最大データ率の昇順（又は、降順）で区分して定義することができる。次の例示は、支援される最大データ率昇順でＭ個の装置タイプを定義した場合の例示である。

【0167】

能力パラメータセット値によるｒｅｄｃａｐ装置タイプ区分（例示）：
－ Ｄｅｖｉｃｅ Ｔｙｐｅ １：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，２５，２｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ２：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，２５，４｝、又は｛１，５２，２｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ３：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，５２，４｝、又は｛１，１０６，２｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ４：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，１０６，４｝、又は｛２，１０６，２｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ５：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，１０６，６｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ６：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛２，１０６，４｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ７：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛２，１０６，６｝
．．．
－ Ｄｅｖｉｃｅ Ｔｙｐｅ Ｍ：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛Ｘ，Ｙ，Ｚ｝
Ｎ_ＲＢ値は、例えば、ＮＲ ＦＲ１（Ｆｒｅｑｕｅｎｃｙ Ｒａｎｇｅ １、すなわち６ＧＨｚ以下帯域）では、下表９で定義する値（ＵＥチャネル帯域幅（ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）別に設定可能な最大ＲＢ個数）のうち一つの値を使用することができる。上記の例示は、サブキャリア間隔（ＳＣＳ：ｓｕｂｃａｒｒｉｅｒ ｓｐａｃｉｎｇ）＝１５ｋＨｚ基準にしたがう値であるが、ｒｅｄｃａｐ装置がＳＣＳ＝３０ｋＨｚを支援し、接続しようとするセル（ｃｅｌｌ）がデータ送信のためにＳＣＳ＝３０ｋＨｚを用いる場合に、前記例示におけるＳＣＳ＝１５ｋＨｚ基準のＮ_ＲＢ値は、下表９を参照してＳＣＳ＝３０ｋＨｚに相応する値に代替されてよい。

【0168】

表９は、ＮＲ ＦＲ１でＳＣＳ別最大送信帯域幅設定（Ｎ_ＲＢ）を例示する。

【0169】

【表9】

【0170】

前記装置タイプ区分例示においてｄｅｖｉｃｅ Ｔｙｐｅ ２／３／４は、複数個の能力セット値で一つの装置タイプを定義した場合に該当する。上のように支援される最大データ率（ｓｕｐｐｏｒｔｅｄ ｍａｘ ｄａｔａ ｒａｔｅ）に基づいて装置タイプを区分する場合に、一つの装置タイプを定義する複数個の能力パラメータセット値は、同一又は類似の支援される最大データ率を支援する組合せを意味できる。

【0171】

上記の例示で定義した装置タイプ(Ｄｅｖｉｃｅ Ｔｙｐｅ)を用いて使用事例別に支援可能な装置タイプを次のように定義でき、支援可能な装置タイプに基づいて基地局はセル接続を制限したり、或いは加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）ベースの遮断（ｂａｒｒｉｎｇ）を行うことができる。

【0172】

例示）使用事例（Ｕｓｅ ｃａｓｅ）別支援可能な装置タイプ：
－ ＩＷＳ（Ｉｎｄｕｓｔｒｉａｌ Ｗｉｒｅｌｅｓｓ Ｓｅｎｓｏｒ）：装置タイプ１、２
－ ビデオ監視（Ｖｉｄｅｏ Ｓｕｒｖｅｉｌｌａｎｃｅ）：装置タイプ２、３
－ウェアラブル（Ｗｅａｒａｂｌｅｓ）：装置タイプ４、５、６、７
一方、過度な装置タイプの細分化による市場細分化（ｍａｒｋｅｔ ｓｅｇｍｅｎｔａｔｉｏｎ）による費用増加を回避するために、装置タイプの個数Ｍを制限してよい。極端な例示として、Ｍ＝１に制限する場合に、ｒｅｄｃａｐ ＵＥを複数個の装置タイプに区分せず、すなわち、シグナル装置タイプで上記のターゲット使用事例を全て支援するようにしてもよい。さらに他の例示として、Ｍ＝３に制限する場合に、装置タイプ区分と使用事例別支援可能な装置タイプは、次のように定義されてよい。

【0173】

例示）能力セット値による装置タイプ区分（例えば、Ｍ＝３の場合）：
－ Ｄｅｖｉｃｅ Ｔｙｐｅ １：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，２５，２｝（又は、｛１，２５，４｝又は｛１，５２，２｝）
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ２：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，５２，４｝又は｛１，１０６，２｝
－ Ｄｅｖｉｃｅ Ｔｙｐｅ ３：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛２，１０６，６｝
例示）使用事例別支援可能な装置タイプ（例えば、Ｍ＝３の場合）
－ ＩＷＳ：Ｄｅｖｉｃｅ ｔｙｐｅｓ １
－ Ｖｉｄｅｏ Ｓｕｒｖｅｉｌｌａｎｃｅ：Ｄｅｖｉｃｅ ｔｙｐｅｓ ３
－ Ｗｅａｒａｂｌｅｓ：Ｄｅｖｉｃｅ ｔｙｐｅｓ ７

【0174】

Ｒｅｄｃａｐ ＵＥの帯域幅能力、すなわち、ＵＥ最大帯域幅（ＵＥ ｍａｘ ｂａｎｄｗｉｄｔｈ）は、ターゲット使用事例で要求するビット率（ｂｉｔ ｒａｔｅ）を満たす最小の帯域幅と決定されてよい。ＵＥ最大帯域幅縮小は、ＲＦ（ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）素子及び／又はベースバンド処理（ｂａｓｅｂａｎｄ ｐｒｏｃｅｓｓｉｎｇ）費用を低減し、電力消耗も減らす効果を期待することができる。ここで要求される（ｒｅｑｕｉｒｅｄ）ビット率は、装置製造コストが平均ビット率（ａｖｅｒａｇｅ ｂｉｔ ｒａｔｅ）、参照ビット率（ｒｅｆｅｒｅｎｃｅ ｂｉｔ ｒａｔｅ）よりはピーク率（ｐｅａｋ ｒａｔｅ）、又は支援される最大データ率（ｓｕｐｐｏｒｔｅｄ ｍａｘ ｄａｔａ ｒａｔｅ）によって決定される点を勘案して、ピック率又は支援される最大データ率を意味してよい。要求されるビット率を支援する最大帯域幅を決定する時に、要求されるビット率を決定する他のパラメータ（例えば、アンテナの個数（Ｎ_Ｌ）、変調次数（Ｑ_ｍ）など）に対して特定値を仮定することができる。例えば、上記の例示において、Ｄｅｖｉｃｅ Ｔｙｐｅ ３は、～２８ＭＨｚ程度のピック率を支援できるが、このとき、必要な最大帯域幅は、｛Ｎ_Ｌ＝１，Ｑ_ｍ＝２｝を仮定する場合に２０ＭＨｚ（１０６ＲＢｓ）であり、｛Ｎ_Ｌ＝１，Ｑ_ｍ＝４｝を仮定する場合に１０ＭＨｚ（５２ＲＢｓ）である。又は、｛Ｎ_Ｌ＝２，Ｑ_ｍ＝４｝の場合に５ＭＨｚ（２５ＲＢｓ）であってよい。

【0175】

－ Ｄｅｖｉｃｅ Ｔｙｐｅ ３：｛Ｎ_Ｌ，Ｎ_ＲＢ，Ｑ_ｍ｝＝｛１，５２，４｝、又は｛１，１０６，２｝
Ｒｅｄｃａｐ ＵＥの最大ＵＥ帯域幅内ではＲＲＣシグナリングなどを用いたネットワーク設定（ｎｅｔｗｏｒｋ ｃｏｎｆｉｇｕｒａｔｉｏｎ）によって送信帯域幅（ｔｒａｎｓｍｉｓｓｉｏｎ ｂａｎｄｗｉｄｔｈ）が割り当てられ、その帯域幅で送／受信することができる。

【0176】

ＵＥ最小帯域幅（ＵＥ ｍｉｎ ｂａｎｄｗｉｄｔｈ）は、ＮＲ ＳＳＢ帯域幅より大きい又は等しいＮＲ ＵＥチャネル帯域幅（ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）（又は、送信帯域幅（ｔｒａｎｓｍｉｓｓｉｏｎ ｂａｎｄｗｉｄｔｈ））のうち最小値と定義されてよい。

【0177】

例示）ＦＲ１において、ＵＥ最小帯域幅＝ＳＣＳ＝１５ｋＨｚであるＮＲ ＳＳＢに対して５ＭＨｚ；ＳＣＳ＝３０ｋＨｚであるＮＲ ＳＳＢに対して１０ＭＨｚ
例示）ＦＲ２において、ＵＥ最小帯域幅＝ＳＣＳ＝１２０ｋＨｚであるＮＲ ＳＳＢに対して４０ＭＨｚ；ＳＣＳ＝２４０ｋＨｚであるＮＲ ＳＳＢに対して８０ＭＨｚ
これは、要求されるビット率の小さいサービスを最小限の帯域幅で支援することによって低い電力消耗（ｌｏｗ ｐｏｗｅｒ ｃｏｎｓｕｍｐｔｉｏｎ）を具現すると同時に、ＮＲ ＳＳＢを通じたＮＲセルへの接続を支援するためであり得る。

【0178】

－ 分類方法４
Ｒｅｄｃａｐ ＵＥの帯域幅能力（ｂａｎｄｗｉｄｔｈ ｃａｐａｂｉｌｉｔｙ）が各使用事例の要求されるビット率（ｒｅｑｕｉｒｅｄ ｂｉｔ ｒａｔｅ）によって決定される点を勘案して、Ｒｅｄｃａｐ装置タイプは、ＵＥ帯域幅能力を基準に分類されてよい。Ｒｅｄｃａｐ装置タイプを決定する帯域幅能力は、例えば、支援される帯域幅（ｓｕｐｐｏｒｔｅｄ ｂａｎｄｗｉｄｔｈ）（Ｎ_ＲＢ）、すなわち（最大）ＵＥチャネル帯域幅又は（最大）ＵＥ送信帯域幅をＲＢ単位で表示したものであり得る。又は、最小ＵＥチャネル帯域幅（ｍｉｎｉｍｕｍ ＵＥ ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）又は最小ＵＥ送信帯域幅（ｍｉｎｉｍｕｍ ＵＥ ｔｒａｎｓｍｉｓｓｉｏｎ ｂａｎｄｗｉｄｔｈ）であってよい。より具体的には、次のような分類が可能である。

【0179】

分類方法４－１）最大帯域幅によって区分され、実際データ送／受信帯域幅（＜＝最大帯域幅）が設定されて用いられる
分類方法４－２）最小帯域幅によって区分され、実際データ送／受信帯域幅（＞＝最小帯域幅）が設定されて用いられる
分類方法４－３）装置タイプ別に１個又は複数個の支援可能な帯域幅（セット）が定義され、当該帯域幅（セット）内で実際データ送／受信帯域幅が設定されて用いられる
分類方法４－１／２／３に対して、最大帯域幅は、ＮＲ帯域幅よりも小さい値（例えば、２０ＭＨｚ）に限定されてよく、最小帯域幅は、ＳＳＢ帯域幅（例えば、１５ｋＨｚ ＳＳＢの場合に５ＭＨｚ）より大きい又は等しくてよい。

【0180】

特定タイプの端末（例えば、ＲｅｄＣａｐ端末）の初期接続及びＰＵＣＣＨ送信方法
以下、本開示ではＲｅｄｃａｐ ＵＥの初期接続及びＰＵＣＣＨ送信方法について提案する。上述したＲｅｄＣａｐ装置のタイプ分類、基地局に報告する方法及びその下位内容、及びＲｅｄｃａｐ ＵＥの初期接続及びＵＬ周波数ホッピング（ｆｒｅｑｕｅｎｃｙ ｈｏｐｐｉｎｇ）支援方法及び下位内容は、本発明の主要提案の背景として参照されてよい。

【0181】

以下、本開示の説明において、一般端末は、無線通信システム（例えば、ＮＲシステム）で要求する全ての能力を支援する端末を意味し、特定タイプの端末は、前記無線通信システムで要求する全ての能力のうち特定要求事項及び／又は特定特徴及び／又は特定使用事例を支援する端末、例えば、ｒｅｄｃａｐ ＵＥを意味する。また、以下、本開示の説明において、説明の便宜のためにｒｅｄｃａｐ ＵＥと呼ぶことができるが、これは一つの例示に過ぎず、本開示はこれに限定されず、ｒｅｄｃａｐ ＵＥは特定タイプの端末と解釈されてよい。

【0182】

Ｒｅｄｃａｐ ＵＥを支援するＮＲセル（ｃｅｌｌ）において、すなわち、一般ＵＥ（ｎｏｒｍａｌ ＵＥ）とｒｅｄｃａｐ ＵＥが共存する又は共存可能なセルにおいて、リソース効率性側面で極力多いリソースを一般ＵＥとｒｅｄｃａｐ ＵＥ間に共有することが選好されてよい。一般ＵＥのために可用／スケジュール可能なリソースとｒｅｄｃａｐ ＵＥのために可用／スケジュール可能なリソースが互いに完全に分離される場合には、リソース活用度が低下し、また、基地局の立場でスケジューリング柔軟性が制約されるなどの問題点があり得るわけである。しかし、次のような場合、ｃｅｌｌ接続のためのランダムアクセス（ｒａｎｄｏｍ ａｃｃｅｓｓ）過程において一般ＵＥとｒｅｄｃａｐ ＵＥ間にリソースを共有することが従来の方法では効果的に支援されないことがある。

【0183】

１．Ｍｓｇ２（すなわち、ＲＡＲ）、ｍｓｇ４又はｍｓｇＢ段階でのＮＲ ＵＥとｒｅｄｃａｐ ＵＥ間のカバレッジ性能（ｃｏｖｅｒａｇｅ ｐｅｒｆｏｒｍａｎｃｅ）差によってｒｅｄｃａｐ ＵＥのための（追加）反復（ｒｅｐｅｔｉｔｉｏｎ）などが必要なことがあり得る。この場合、ｒｅｄｃａｐ ＵＥのＲＡＣＨ過程（すなわち、ｒａｄｏｍ ａｃｃｅｓｓ ｐｒｏｃｅｄｕｒｅ）での反復（ｒｅｐｅｔｉｔｉｏｎ）は、例えば、Ｍｓｇ １～４／Ｍｓｇ Ａ～Ｂのうち少なくとも一つ以上に同一に適用されてもよく、又は各メッセージに独立した設定によって個別に適用されてもよい。
２．レガシー（Ｌｅｇａｃｙ）ＮＲ ＵＥに対する影響（ｉｍｐａｃｔ）を考慮して初期（ｉｎｉｔｉａｌ）ＵＬ ＢＷＰをｒｅｄｃａｐ ＵＥの最大（ｍａｘ）ＵＥ帯域（ｂａｎｄｗｉｄｔｈ）内で設定できない場合
３．Ｒｅｄｃａｐ ＵＥのＵＥプロセシング時間緩和（ｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ ｒｅｌａｘａｔｉｏｎ）などによってランダムアクセス過程でＮＲ ＵＥに対する影響が不回避な場合
４．前記１、２、３番などの理由で、ｒｅｄｃａｐ ＵＥのための別途の初期ＵＬ ＢＷＰを設定して運営する場合
本開示は、一般ＵＥとｒｅｄｃａｐ ＵＥが共存するＮＲセルにおいて、ｒｅｄｃａｐ ＵＥの初期接続及びＰＵＣＣＨ送信支援方法に関する。ただし、本開示は、上述したシナリオに限定して適用されず、ＮＲ ＵＥの初期接続及びＰＵＣＣＨ送信時にも同一に適用されてよい。

【0184】

実施例１：ＲｅｄＣａｐ ＵＥのランダムアクセス応答（ＲＡＲ，ｒａｎｄｏｍ ａｃｃｅｓｓ ｒｅｓｐｏｎｓｅ）受信方法
ＲｅｄＣａｐ ＵＥは、端末機複雑度を考慮して、限定されたＵＥ帯域幅を支援できる。仮に、ＮＲ ＵＥのための従来の方法でＲＡＣＨ機会（ＲＯ：ＲＡＣＨ ｏｃｃａｓｉｏｎ）（又は、ＰＲＡＣＨ機会）を設定する場合に、このようなＲｅｄＣａｐ ＵＥの（初期）ＵＬ帯域幅は、設定されたＲＯの周波数領域を全て含むことができない場合が発生し得る。この場合、ｒｅｄｃａｐ ＵＥは、初期接続のためのＲＡ（ｒａｎｄｏｍ ａｃｃｅｓｓ）過程でＲＡプリアンブル（ｐｒｅａｍｂｌｅ）（すなわち、ＰＲＡＣＨプリアンブル）送信後に周波数リチューニング（ｆｒｅｑｕｅｎｃｙ ｒｅｔｕｎｉｎｇ）動作を行った後にＲＡＲを受信しなければならないことがある。また、ＦＤＤ帯域（ｂａｎｄ）において（初期接続過程で）ハーフデュプレックス（ｈａｌｆ－ｄｕｐｌｅｘ）ＦＤＤで動作する端末機は、同様に周波数リチューニング後にＲＡＲを受信しなければならないことがある。

【0185】

このような場合、（周波数リチューニングを伴う）ＵＬからＤＬへの（ＵＬ－ｔｏ－ＤＬ）スイッチング（ｓｗｉｔｃｈｉｎｇ）又はＴｘからＲｘへの（Ｔｘ－ｔｏ－Ｒｘ）スイッチングの間には、ＰＤＣＣＨモニタリング（ｍｏｎｉｔｏｒｉｎｇ）を含めてＤＬ受信が不可であり得る。したがって、これを考慮して、ｒｅｄｃａｐ ＵＥのＲＡＲウィンドウ（ｗｉｎｄｏｗ）は、一般ＵＥのＲＡＲウィンドウからＸシンボル（ｓｙｍｂｏｌ）又はＸ’ｕｓだけの後で始めるように設定／定義されてよい。ここで、Ｘ又はＸ’は、ＴＳ ３８．２１１標準規格で定義された変換時間（ｔｒａｎｓｉｔｉｏｎ ｔｉｍｅ）（Ｎ_{Ｒｘ－Ｔｘ}又はＮ_{Ｔｘ－Ｒｘ}）及び／又は周波数リチューニング時間（ｆｒｅｑｕｅｎｃｙ ｒｅｔｕｎｉｎｇ ｔｉｍｅ）より大きい又は等しい値であってよい。又は、ｒｅｄｃａｐ ＵＥの特性を考慮して新しく標準規格で定義されてよく、又は基地局によってシステム情報（ｓｙｓｔｅｍ ｉｎｆｏｒｍａｔｉｏｎ）などを用いて上位層シグナリングによって設定されてよい。

【0186】

ＮＲ ＵＥのための従来のＲＡＲウィンドウは、ＴＳ ３８．２１３規格書（表１０）及びＴＳ ３８．３２１規格書（表１１）に、次のように規定される。

【0187】

【表10】

【0188】

表１０を参照すると、ＲＡＲウィンドウは、ＰＲＡＣＨ送信に対応するＰＲＡＣＨ機会（すなわち、ＲＯ）の最後のシンボル後にＵＥがｔｙｐｅ１－ＰＤＣＣＨ ＣＳＳ（ｃｏｍｍｏｎ ｓｅａｒｃｈ ｓｐａｃｅ）セットに対するＰＤＣＣＨを受信するように設定された最も早いＣＯＲＥＳＥＴの最初シンボルから始まる。

【0189】

【表11】

【0190】

表１１を参照すると、ランダムアクセスプリアンブルが送信されると、ＭＡＣ個体（ｅｎｔｉｔｙ）は、ランダムアクセスプリアンブル送信の終了から一番目のＰＤＣＣＨ機会でＲＡＣＨ－ＣｏｎｆｉｇＣｏｍｍｏｎ内に設定されたｒａ－ＲｅｓｐｏｎｓｅＷｉｎｄｏｗ（すなわち、ＲＡＲウィンドウの長さ）を始めることができる。

【0191】

上のような方式でｒｅｄｃａｐ ＵＥのＲＡＲウィンドウを定義するために、ｒｅｄｃａｐ ＵＥは、ＲＡプリアンブル送信後に、ＲＡプリアンブル送信に用いたＲＯの最後のシンボルから少なくともＸシンボル後又はＸ’ｕｓ後に始まる最も早いＣＯＲＥＳＥＴの最初のシンボルから、ＲＡ－ＲＮＴＩでＣＲＣスクランブルされたＤＣＩフォーマット１＿０をモニターし始めるようにしてよい。又は、ＲＡＲ受信のためにＰＤＣＣＨをモニターする区間、すなわち、ＲＡＲウィンドウの開始点又はＲＡＲウィンドウカウンターが始まる時点は、ＲＡプリアンブル送信に用いたＲＯの最後のシンボルから少なくともＸシンボル後又はＸ’ｕｓ後に始まる最も早いＣＯＲＥＳＥＴの最初のシンボルと定義できる。Ｘ又はＸ’値は、上で説明した通りである。又は、シンボル単位のＸ値は、変換時間（ｔｒａｎｓｉｔｉｏｎ ｔｉｍｅ）及び／又は周波数リチューニング時間（ｆｒｅｑｕｅｎｃｙ ｒｅｔｕｎｉｎｇ ｔｉｍｅ）よりも大きい最小のシンボル区間（ｓｙｍｂｏｌ ｄｕｒａｔｉｏｎ）個数よりも１大きい値であってよい。

【0192】

Ｒｅｄｃａｐ ＵＥのＲＡＲウィンドウを設定するために（一般ＵＥのためのＲＡＲウィンドウに追加して）ｒｅｄｃａｐ ＵＥのための別途のＲＡＲウィンドウを用いることができる。ＲＡＲウィンドウのサイズは、ＲＡＲウィンドウカウンター（ｃｏｕｎｔｅｒ）の設定値によって決定されてよい。ここで、ｒｅｄｃａｐ ＵＥのための別のＲＡＲウィンドウのサイズは、（別のサイズ設定無しで）既存のＲＡＲウィンドウと同一のサイズを有してもよく、又は別に設定されてもよい。同一のサイズを有する場合に、ｒｅｄｃａｐ ＵＥのＲＡＲウィンドウは、従来のＲＡＲウィンドウと所定の時間差を有する（ｓｔａｇｇｅｒｅｄ）形態であってよい。

【0193】

又は、基地局は、ｒｅｄｃａｐ端末機に対して別のＲＡＲウィンドウを定義せず、一般ＵＥと同一のＲＡＲウィンドウを用いるように又は共有するように設定できる。この場合、これは、基地局が先に言及した変換時間及び／又は周波数リチューニング時間の条件を満たすように基地局具現によってＲＡＲウィンドウを保障するということを意味できる。

【0194】

実施例２：ＲｅｄＣａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨ送信方法
ＮＲ ＵＥの初期接続のためのＲＡ手続（ｐｒｏｃｅｄｕｒｅ）においてＭｓｇ３ ＰＵＳＣＨ送信はＲＡＲ ＵＬグラントによってスケジュールされる。ＲＡＲ ＵＬグラントのフィールド構成とそれによるＭｓｇ３ ＰＵＳＣＨ周波数ドメインリソース割り当て（ＦＤＲＡ：ｆｒｅｑｕｅｎｃｙ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）と周波数ホッピング（ＦＨ：Ｆｒｅｑｕｅｎｃｙ Ｈｏｐｐｉｎｇ）情報は、ＴＳ ３８．２１３に下表１２のように規定されている。

【0195】

【表12-1】

【0196】

【表12-2】

【0197】

上に規定しているように、従来の初期接続のためのＲＡ手続でＭｓｇ３ ＦＤＲＡ及びＦＨは、初期（ｉｎｉｔｉａｌ）ＵＬ帯域幅を基準に決定される。ここで、初期ＵＬ帯域幅は初期ＵＬ ＢＷＰの帯域幅を意味する。

【0198】

しかし、一般ＵＥとｒｅｄｃａｐ ＵＥを同時に支援するＮＲセルにおいてレガシー影響（ｌｅｇａｃｙ ｉｍｐａｃｔ）の点で初期ＵＬ ＢＷＰをｒｅｄｃａｐ ＵＥの最大ＵＥ帯域幅内に限定しない場合（すなわち、初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合）に、次のようなｒｅｄｃａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨ送信方法が考慮できる。

【0199】

下記の提案方法において、上記の理由でｒｅｄｃａｐ ＵＥのための別途の初期ＵＬ ＢＷＰを設定して運営する場合に、ｒｅｄｃａｐ ＵＥ帯域幅はｒｅｄｃａｐのための別途の初期ＵＬ ＢＷＰ又は別途の初期ＵＬ ＢＷＰの帯域幅の意味を含み得る。Ｒｅｄｃａｐ ＵＥのための別途の初期ＵＬ ＢＷＰの帯域幅はｒｅｄｃａｐ ＵＥ帯域幅以下に限定されてよい。

【0200】

上記の理由で、本開示において「初期ＵＬ ＢＷＰの帯域幅又は初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい」又は「基地局は一般ＵＥのための初期ＵＬ帯域幅をｒｅｄｃａｐ ＵＥ帯域幅よりも大きく設定しなければならない」との意味は、「ｒｅｄｃａｐのための別途の初期ＵＬ ＢＷＰが設定される／された」との意味を含み得る。

【0201】

実施例２－１：初期（ｉｎｉｔｉａｌ）ＵＬ帯域幅（ｂａｎｄｗｉｄｔｈ）がｒｅｄｃａｐ ＵＥ帯域幅よりも大きければ、周波数ホッピング（ＦＨ）非活性（ｏｆｆ又はｄｉｓａｂｌｅｄ）する方法
基地局は一般ＵＥのための初期ＵＬ帯域幅をｒｅｄｃａｐ ＵＥ帯域幅よりも大きく設定しなければならない場合に、ｒｅｄｃａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨに対してＦＨをｏｆｆ（又は、ｄｉｓａｂｌｅｄ）し、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する一番目の周波数ホップ（１ｓｔ ｆｒｅｑｕｅｎｃｙ ｈｏｐ）がｒｅｄｃａｐ ＵＥ帯域幅内に属するようにスケジュールできる。これにより、基地局は、一般ＵＥとｒｅｄｃａｐ ＵＥのＰＵＳＣＨ送信を全て受信することができる。そのために、基地局は、ＲＡＲ ＵＬグラントのＦＨフラグ（ｆｌａｇ）の値を０に設定できる。上記のＲＡＲ ＵＬグラントのＦＨフラグは別に構成され、ｒｅｄｃａｐ ＵＥのＦＨを活性／非活性（ｅｎａｂｌｅ／ｄｉｓａｂｌｅ）する用途に用いられてよい。又は、初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合に、ｒｅｄｃａｐ ＵＥは、ＦＨがｏｆｆ（又は、ＦＨフラグ値が０）であると仮定し、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域で上記の方法によってＭｓｇ３ ＰＵＳＣＨを基地局に送信できる。

【0202】

図１１は、本開示の一実施例に係る周波数ホッピングがないＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【0203】

図１１では、一般ＵＥの初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合に、基地局がＦＨ無しでｒｅｄｃａｐ ＵＥ帯域幅内にｒｅｄｃａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨをスケジュールした場合を例示する。

【0204】

図１１を参照すると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ（１ｓｔ ｆｒｅｑｕｅｎｃｙ ｈｏｐ）１１０１に対する送信を行うことができる。そして、ｒｅｄｃａｐ ＵＥは、周波数ホッピング無しで（基地局の指示によって又はＵＥの仮定によって）、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域でＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ（２ｎｄ ｆｒｅｑｕｅｎｃｙ ｈｏｐ）１１０２に対する送信を行うことができる。

【0205】

実施例２－２：ＲＡＲ ＵＬグラントのＦＤＲＡ及び／又はＦＨフラグを異なるように解釈する方法
基地局が一般ＵＥのための初期ＵＬ帯域幅をｒｅｄｃａｐ ＵＥ帯域幅よりも大きく設定しなければならない場合に、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡ及び／又はＦＨフラグが指示するＰＵＳＣＨスケジューリング情報／結果に対して又はＦＤＲＡ及び／又はＦＨフラグなどのフィールド値を一般ＵＥと異なるように適用／解釈できる。ここで、初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合に、ＲＡＲ ＵＬグラントのＦＤＲＡ及び／又はＦＨフラグが指示するＰＵＳＣＨスケジューリング情報／結果は、次の場合があり得る。

【0206】

［ケース１］一番目の周波数ホップ（１ｓｔ ｆｒｅｑｕｅｎｃｙ ｈｏｐ）はｒｅｄｃａｐ ＵＥ帯域幅内に属し／含まれ、二番目の周波数ホップ（２ｎｄ ｆｒｅｑｕｅｎｃｙ ｈｏｐ）はｒｅｄｃａｐ ＵＥ帯域幅を外れる／含まれない場合
［ケース２］一番目の周波数ホップは、ｒｅｄｃａｐ ＵＥ帯域幅を外れる／含まれなく、二番目の周波数ホップはｒｅｄｃａｐ ＵＥ帯域幅内に属する／含まれる場合
［ケース３］一番目の周波数ホップと二番目の周波数ホップが両方ともｒｅｄｃａｐ ＵＥ帯域幅内に属する／含まれる場合
［ケース４］一番目の周波数ホップと二番目の周波数ホップが両方ともｒｅｄｃａｐ ＵＥ帯域幅を外れる／含まれない場合
ケース１及び２のように、Ｍｓｇ３ ＰＵＳＣＨのＦＨがイネーブル（ｅｎａｂｌｅ）であり、二番目の周波数ホップのうち一つのホップのみがｒｅｄｃａｐ ＵＥ帯域幅に属する場合に、基地局は、そのｒｅｄｃａｐ ＵＥ帯域幅に属するホップの周波数リソースを用いて一番目のホップと二番目のホップの両方ともＦＨ無しで送信するように設定／指示できる。

【0207】

図１２～図１４は、本開示の一実施例に係る周波数ホッピングを考慮したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【0208】

図１２では、前記ケース１を例示する。図１２を参照すると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する又は一番目の周波数ホップの周波数領域で一番目の周波数ホップ１２０１と二番目の周波数ホップ１２０２に対する送信をＦＨ無しで行うことができる。言い換えると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ１２０１に対する送信を行うことができる。そして、ｒｅｄｃａｐ ＵＥは、周波数ホッピングがないと仮定し、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域又は一番目の周波数ホップの周波数領域でＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１２０２に対する送信を行うことができる。

【0209】

図１３では、前記ケース２を例示する。図１３を参照すると、ｒｅｄｃａｐ ＵＥは、ｒｅｄｃａｐ ＵＥ帯域幅に属する二番目のホップの周波数領域で一番目の周波数ホップ１３０１と二番目の周波数ホップ１３０２に対する送信をＦＨ無しで行うことができる。言い換えると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡによって決定されたＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１３０２の周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ１３０１とＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１３０２に対する送信を全て行うことができる。

【0210】

図１４では、前記ケース３を例示する。図１４を参照すると、Ｍｓｇ ＰＵＳＣＨの一番目の周波数ホップ１４０１とＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１４０２が両方ともｒｅｄｃａｐ ＵＥ帯域幅内に属して／含まれてよい。この場合、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡとＦＨフラグ（ＦＨ ｏｎ）によって指示されたそれぞれの周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ１４０１とＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１４０２に対する送信を行うことができる。

【0211】

前記ケース４の場合、ｒｅｄｃａｐ ＵＥは、一番目の周波数ホップ（又は、二番目の周波数ホップ）でＦＨ無しでＭｓｇ３ ＰＵＳＣＨを送信できる。ただし、一番目の周波数ホップ（又は、二番目の周波数ホップ）はｒｅｄｃａｐ ＵＥがシステム情報（例えば、ＳＩＢ１）によって受信した初期ＵＬ帯域幅に属しない場合であるので、ｒｅｄｃａｐ ＵＥは周波数リチューニング後にＭｓｇ３ ＰＵＳＣＨ送信を行うことができる。

【0212】

又は、ｒｅｄｃａｐ ＵＥは、この場合、当該セルがｒｅｄｃａｐ ＵＥを遮断（ｂａｒｒｉｎｇ）したと又はｒｅｄｃａｐ ＵＥの接続を許容しないと見なし、ｒｅｄｃａｐ ＵＥは他の接続可能なセルに対してセル探索（ｃｅｌｌ ｓｅａｒｃｈ）過程を続けて行うことができる。

【0213】

又は、基地局は、ＲＡＲ ＵＬグラントのＦＤＲＡ及び／又はＦＨフラグ値が指示するＭｓｇ３ ＰＵＳＣＨの一部又は全部がｒｅｄｃａｐ ＵＥ帯域幅又はｒｅｄｃａｐ ＵＥの初期ＵＬ帯域幅に属しないように設定／指示することによってｒｅｄｃａｐ ＵＥを遮断（ｂａｒｒｉｎｇ）できる。又は、基地局は、ＲＡＲ ＵＬグラントのＦＤＲＡ及び／又はＦＨフラグ値が指示するＭｓｇ３ ＰＵＳＣＨスケジューリング結果が、上のケース１、ケース２又はケース４のうち一つに属するようにすることによってｒｅｄｃａｐ ＵＥを遮断（ｂａｒｒｉｎｇ）できる。

【0214】

一方、Ｒｅｄｃａｐ初期ＵＬ帯域幅を基準にＭｓｇ３ ＰＵＳＣＨスケジューリング情報が解釈されてよい。

【0215】

ＲｅｄＣａｐ ＵＥは、自分の（別途の）初期ＵＬ帯域幅を基準に（外れるホップに対して）モジュラー演算（ｍｏｄｕｌｏ（ＭＯＤ） ｏｐｅｒａｔｉｏｎ）を適用して最終ホップを決定できる。基準となるｒｅｄｃａｐ初期ＵＬ帯域幅は、システム情報（例えば、ＳＩＢ１）を用いてセル特定に設定されてよい。そうでない場合、ｒｅｄｃａｐ ＵＥの初期ＵＬ帯域幅情報はＭｓｇ１段階で基地局に早期（ｅａｒｌｙ）送信されてよい。ＭＯＤ演算の便宜のために、一般ＵＥ初期ＵＬ帯域幅＝Ｎ＊（ＲｅｄＣａｐＵＥ初期ＵＬ帯域幅）に限定（例えば、Ｎ＝１、２、４、８、又は正の整数）されてよい。例えば、ｒｅｄｃａｐのための別途の初期ＵＬ ＢＷＰは、ｆｌｏｏｒ（ｉｎｉｔｉａｌ＿ＵＬ＿ｂａｎｄｗｉｄｔｈ／Ｎ）の帯域幅値を有するように設定されてよい。ここで、ｆｌｏｏｒ（ｘ）は、ｘよりも大きくない最大整数である。ここで、ｉｎｉｔｉａｌ＿ＵＬ＿ｂａｎｄｗｉｄｔｈは、一般ＵＥのための初期ＵＬ ＢＷＰの帯域幅を意味し、ＲＢ単位であってよい。

【0216】

図１５は、本開示の一実施例に係るＭＯＤ演算を適用したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【0217】

図１５では、ｒｅｄｃａｐのための別途の初期ＵＬ ＢＷＰは、ｆｌｏｏｒ（ｉｎｉｔｉａｌ＿ＵＬ＿ｂａｎｄｗｉｄｔｈ／２）の帯域幅を有する場合を例示する（すなわち、Ｎ＝２）。図１５を参照すると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ１５０１に対する送信を行うことができる。そして、ｒｅｄｃａｐ ＵＥは、上のようにＭＯＤ演算を適用して決定された周波数領域でＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１５０２に対する送信を行うことができる。

【0218】

図１５の例示によれば、ｒｅｄｃａｐ ＵＥ初期ＵＬ帯域幅を基準にモジュラー演算を行った結果が、周波数ダイバーシチ利得（ｆｒｅｑｕｅｎｃｙ ｄｉｖｅｒｓｉｔｙ ｇａｉｎ）が得られない結果を招くことがある。このような短所を改善するために、単純モジュラー演算ではなくｒｅｄｃａｐ初期ＵＬ帯域幅の境界を基準に対称となる周波数位置にホップを配置／決定する方法を考慮できる。

【0219】

図１６は、本開示の一実施例に係るミラーリングを適用したＭｓｇ３ ＰＵＳＣＨの周波数リソース割り当てを例示する図である。

【0220】

図１６では、二番目の周波数ホップがｒｅｄｃａｐ ＵＥ初期帯域幅を外れる場合に、二番目の周波数ホップがｒｅｄｃａｐ初期ＵＬ帯域幅の上位境界（ｕｐｐｅｒ ｂｏｕｎｄａｒｙ）を基準にミラーリング（ｍｉｒｒｏｒｉｎｇ）して配置されてよい。言い換えると、図１６を参照すると、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡが指示する周波数領域でＭｓｇ ＰＵＳＣＨの一番目の周波数ホップ１６０１に対する送信を行うことができる。そして、ｒｅｄｃａｐ ＵＥは、上のようにｒｅｄｃａｐ初期ＵＬ帯域幅の上位境界（ｕｐｐｅｒ ｂｏｕｎｄａｒｙ）を基準にミラーリング（ｍｉｒｒｏｒｉｎｇ）によって決定された周波数領域でＭｓｇ ＰＵＳＣＨの二番目の周波数ホップ１６０２に対する送信を行うことができる。

【0221】

これによれば、図１５の例示に比べて、周波数ダイバーシチ利得（ｆｒｅｑｕｅｎｃｙ ｄｉｖｅｒｓｉｔｙ ｇａｉｎ）を期待することができる。

【0222】

又は、ｒｅｄｃａｐ ＵＥは、ＲＡＲ ＵＬグラントのＦＤＲＡ値に周波数オフセット（ｆｒｅｑｕｅｎｃｙ ｏｆｆｓｅｔ）を適用して送信することによって、一般ＵＥと区分される周波数領域でＭｓｇ３ ＰＵＳＣＨを送信することができる。この方法は、一部の周波数ホップが重なる方法に比べて、基地局での感知（ｄｅｔｅｃｔｉｏｎ）が容易であるという長所がある。又は、ＲＡＲ ＵＬグラントでＦＨ活性（ｅｎａｂｌｅ又はｏｎ）を指示する場合に、二番目のホップの周波数オフセット値を従来と異なるように解釈したり、従来の二番目のホップの周波数オフセット値に追加の周波数オフセットを適用するように設定／定義されてよい。

【0223】

二番目のホップの周波数オフセット値を従来と異なるように解釈する場合に、ｒｅｄｃａｐ ＵＥは、ＴＳ ３８．２１３のＴａｂｌｅ ８．３－１（表１２参照）に基づいて計算した二番目のホップの位置値にスケーリング因子（スケーリング因子）をかけて適用できる。例えば、スケーリング因子は、ｒｅｄｃａｐ＿ＵＥ＿ｉｎｉｔｉａｌ＿ＵＬ＿ｂａｎｄｗｉｄｔｈ／ｎｏｒｍａｌ＿ＵＥ＿ｉｎｉｔｉａｌ＿ＵＬ＿ｂａｎｄｗｉｄｔｈであってよい。又は、一般ＵＥの初期ＵＬ帯域幅の代わりにｒｅｄｃａｐ ＵＥのＵＥ帯域幅又はｒｅｄｃａｐ ＵＥの初期ＵＬ帯域幅を適用して二番目のホップの周波数上の位置が決定されてもよい。

【0224】

上記の実施例２－１及び２－２に対して、ｒｅｄｃａｐ ＵＥ帯域幅は、ＲｅｄＣａｐ ＵＥが初期接続のために用いるように設定されたＲＯ帯域幅に代替して解釈してもよい。すなわち、ＲＯ帯域幅を基準にＦＨ非活性（ｏｆｆ又はｄｉｓａｂｌｅｄ）を決定したり、又はＦＨを行ったり、又はＦＤＲＡが解釈されてよい。ここで、ＲＯは、ＲｅｄＣａｐ ＵＥのために別個に設定されてよく、又は別途の設定無しでＮＲ ＵＥのために設定されたＲＯであってもよい。この場合、ＲｅｄＣａｐ ＵＥは、上記のＲＯ帯域幅をＲｅｄＣａｐ ＵＥの初期ＵＬ ＢＷＰと仮定して動作することができる。

【0225】

実施例２－３：Ｍｓｇ３ ＰＵＳＣＨ送信を用いたｒｅｄｃａｐ ＵＥ識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）
先に提案した方法によって一般ＵＥとｒｅｄｃａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨが時間／周波数（ｔｉｍｅ／ｆｒｅｑｕｅｎｃｙ）領域で区分されるリソース又は互いに異なるＦＨパターンで送信される時に、基地局は、上のように区分されるＭｓｇ３ ＰＵＳＣＨ時間／周波数送信リソース又はＦＨパターンに対してブラインド感知（ＢＤ：ｂｌｉｎｄ ｄｅｔｅｃｔｉｏｎ）することにより、ＵＥ（タイプ）（例えば、一般ＵＥか或いはｒｅｄｃａｐ ＵＥか）を区分できる。この方法は、Ｍｓｇ１で早期の（ｅａｒｌｙ）ＵＥ ＩＤを支援しない場合に、Ｍｓｇ３段階で一般ＵＥとの区分のために用いられてよい。

【0226】

又は、Ｍｓｇ１で早期（ｅａｒｌｙ）ＵＥ ＩＤと共に追加のＵＥ（ｔｙｐｅ）情報を提供するための用途に用いられてよい。例えば、追加のＵＥ（ｔｙｐｅ）情報は、Ｒｘアンテナブランチ（ａｎｔｅｎｎａ ｂｒａｎｃｈ）（又は、ポート（ｐｏｒｔ））個数に関する情報、又はｒｅｄｃａｐ ＵＥの特定特徴（ｆｅａｔｕｒｅ）支援の有無を示す情報などを含むことができる。

【0227】

また、この方法は、一般ＵＥと初期ＵＬ帯域幅サイズが同一である場合においても、（追加の）ＵＥ識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）のために適用できる。Ｍｓｇ３ ＰＵＳＣＨリソースの区分は周波数領域に限定されなくてもよい。例えば、ＲＡＲ ＵＬグラントで指示する時間ドメインリソース割り当て（ＴＤＲＡ：ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ）値を異なるように解釈して（例えば、追加のオフセットを適用して）又はＴＤＭの形態で一般ＵＥとｒｅｄｃａｐ ＵＥのＭｓｇ３ ＰＵＳＣＨを区分して送信するように設定／定義されてもよい。

【0228】

実施例２－４：先に言及した方法のうち一つとして、Ｍｓｇ３ ＰＵＳＣＨを送信した後、ｒｅｄｃａｐ ＵＥは、基地局からＭｓｇ３ ＰＵＳＣＨ再送信が指示されてよい。この場合、Ｍｓｇ３ ＰＵＳＣＨ再送信は、ＴＣ（ｔｅｍｐｏｒａｒａｙ ｃｅｌｌ）－ＲＮＴＩでスクランブリング（ｓｃｒａｂｌｉｎｇ）されたＣＲＣ（ｃｙｃｌｉｃ ｒｅｄｕｎｄａｎｃｙ ｃｈｅｃｋ）を有するＤＣＩ ｆｏｒｍａｔ０＿０で指示されてよい。ＤＣＩでＭｓｇ３ ＰＵＳＣＨ再送信が指示されるとき、Ｍｓｇ３ ＰＵＳＣＨ再送信のためのＦＤＲＡ／ＴＤＲＡ、ＦＨなどの情報はＭｓｇ３再送信ＤＣＩの指示に従えばよい。初期ＵＬ帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合に、ＦＤＲＡ／ＴＤＲＡ及び／又はＦＨなどに対する解釈／動作は、先にＲＡＲ ＵＬグラントで提案した方法を適用できる。

【0229】

仮に、Ｒｅｄｃａｐ ＵＥがＭｓｇ３初期送信に失敗して再送信が指示される場合に、ｒｅｄｃａｐ ＵＥは、初期送信と異なる方法で一般ＵＥと区分されるリソースを用いるようにすることができる。例えば、ｒｅｄｃａｐ ＵＥが初期送信においてＦＤＲＡ、ＦＨパターンなどの周波数リソースを一般ＵＥと区分して送信する場合に、再送信が指示されたｒｅｄｃａｐ ＵＥは、ＴＤＲＡ値に時間オフセット（ｔｉｍｅ ｏｆｆｓｅｔ）を適用して又はＴＤＭ方式で一般ＵＥと区分されるリソースを用いて送信できる。

【0230】

実施例３：ｒｅｄｃａｐ ＵＥの初期接続及びＰＵＣＣＨ送信方法
ＵＥが専用ＰＵＣＣＨリソース設定（Ｄｅｄｉｃａｔｅｄ ＰＵＣＣＨ ｒｅｓｏｕｒｃｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信する前のＰＵＣＣＨ送信方法は、下表１３のようにＴＳ ３８．２１３ ｓｐｅｃに次のように規定されている

【0231】

【表13-1】

【0232】

【表13-2】

【0233】

表１３を参照すると、ＵＥは、ＵＬ ＢＷＰに対する設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内のＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）に対する設定（ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）が提供されないと、周波数ホッピングを用いてＰＵＣＣＨを送信する。そうでないと、ＵＥは周波数ホッピング無しでＰＵＣＣＨを送信する。

【0234】

ＵＥがＰＤＳＣＨ受信又はＳＰＳ ＰＤＳＣＨ解除（ｒｅｌｅａｓｅ）をスケジュールするＤＣＩフォーマットの感知に対する応答としてＰＵＣＣＨ送信内でＨＡＲＱ－ＡＣＫ情報を提供すると、ＵＥは、ｒ_{ＰＵＣＣＨ}＝ｆｌｏｏｒ（２・ｎ_{ＣＣＥ，０}／Ｎ_ＣＣＥ）＋２・Δ_ＰＲＩ（ここで、ｆｌｏｏｒ（ｘ）はｘよりも大きくない最大整数）のようにインデックスｒ_{ＰＵＣＣＨ}（０≦ｒ_{ＰＵＣＣＨ}≦１５）とＰＵＣＣＨリソースを決定する。ここで、Ｎ_ＣＣＥは、ＤＣＩフォーマットを運ぶＰＤＣＣＨ受信のＣＯＲＥＳＥＴ内のＣＣＥの個数である。ｎ_{ＣＣＥ，０}は、ＰＤＣＣＨ受信のための一番目のＣＣＥのインデックスである。Δ_ＰＲＩは、ＤＣＩフォーマット内のＰＵＣＣＨリソース指示子フィールドの値である。

【0235】

また、ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝０であれば、ＵＥは、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}＋ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のように一番目のホップ内のＰＵＣＣＨ送信のＰＲＢインデックスを決定し、Ｎ_ＢＷＰ ^ｓｉｚｅ－１－ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}－ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のように二番目のホップ内のＰＵＣＣＨ送信のＰＲＢインデックスを決定する。ここで、Ｎ_ＣＳは、初期循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）インデックスのセット内初期ＣＳインデックスの全体個数である。

【0236】

一方、ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝１であれば、ＵＥは、Ｎ_ＢＷＰ ^ｓｉｚｅ－１－ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}－ｆｌｏｏｒ（（ｒ_{ＰＵＣＣＨ}－８）／Ｎ_ＣＳ）のように一番目のホップ内のＰＵＣＣＨ送信のＰＲＢインデックスを決定し、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}＋ｆｌｏｏｒ（（ｒ_{ＰＵＣＣＨ}－８）／Ｎ_ＣＳ）のように二番目のホップ内のＰＵＣＣＨ送信のＰＲＢインデックスを決定する。そして、ＵＥは、初期ＣＳインデックスのセット内の初期ＣＳインデックスの全体個数を（ｒ_{ＰＵＣＣＨ}－８）ｍｏｄＮ_ＣＳのように決定する。

【0237】

上記の表１３で規定するように、ＵＥは、専用（ｄｅｄｉｃａｔｅｄ）ＰＵＣＣＨリソース（ｒｅｓｏｕｒｃｅ）が設定される前に、ＰＵＣＣＨ送信のために初期（ｉｎｉｔｉａｌ）ＵＬ ＢＷＰの周波数（ｂａｎｄｗｉｄｔｈ）を基準に常に周波数ホッピング（ＦＨ）を行うように定義／規定されている。初期ＵＬ ＢＷＰの帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合におけるＦＨ問題は、先にＭｓｇ３ ＰＵＳＣＨで提案した内容と同一に適用されてよい。例えば、上の場合に、ＰＵＣＣＨに対する提案方法は、先にＭｓｇ３ ＰＵＳＣＨで提案した方法に対してＭｓｇ３ ＰＵＳＣＨをＰＵＣＣＨに代えて解釈することによって適用できる。すなわち、従来の一般ＵＥと違い、初期ＵＬ ＢＷＰの帯域幅がｒｅｄｃａｐ ＵＥ帯域幅よりも大きい場合に、ＲｅｄＣａｐ ＵＥのためにＰＵＣＣＨ ＦＨ非活性（ｄｉｓａｂｌｅ）を支援できる。ＰＵＣＣＨ ＦＨディセーブル時に、ＰＵＣＣＨ送信周波数リソースは、ＰＵＳＣＨと同じ方法で一般ＵＥのＰＵＣＣＨ送信のための一番目の（或いは、二番目の）周波数ホップ（のＰＲＢインデックス）決定方法によって決定されてよい。すなわち、ＲｅｄＣａｐのための別途の初期ＵＬ ＢＷＰを設定してランダムアクセスを行う場合に、ＰＵＣＣＨ送信周波数リソースを決定するための初期ＵＬ ＢＷＰの帯域幅を意味するＮ_ＢＷＰ ^ｓｉｚｅは、一般ＵＥの初期ＵＬ ＢＷＰであるか、又はｒｅｄｃａｐ ＵＥのために別個に設定した初期ＵＬ ＢＷＰの帯域幅に代替されてよい。

【0238】

また、上記のＭｓｇ３ ＰＵＳＣＨにおけると同様に、ｒｅｄｃａｐ ＵＥの場合、一般ＵＥのためのＰＵＣＣＨ送信周波数リソースにセル特定周波数オフセット（ｃｅｌｌ－ｓｐｅｃｉｆｉｃ ｆｒｅｑｕｅｎｃｙ ｏｆｆｓｅｔ）を適用して送信できる。これにより、一般ＵＥと区分される周波数領域でＰＵＣＣＨを送信するように設定／定義され得る。ここで、上記の表１３内にＴａｂｌｅ ９．２．１－１（の一部設定）を再使用し、追加のセル特定周波数オフセットを足してＰＵＣＣＨ送信周波数リソースが決定されてよい。それのために、セル特定周波数オフセットはシステム情報（例えば、ＳＩＢ１の初期ＵＬ ＢＷＰ設定ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ（－Ｒ））に含まれて送信されてよい。

【0239】

本開示では、説明の便宜のために、上記のＰＵＣＣＨ ＦＨがイントラスロット（ｉｎｔｒａ－ｓｌｏｔ）ＦＨを基準にして説明されたが、インタースロットＦＨが支援される場合にも同一に適用されてよい。

【0240】

本開示において、専用ＰＵＣＣＨリソース（ｄｅｄｉｃａｔｅｄ ＰＵＣＣＨ ｒｅｓｏｕｒｃｅ）が設定される前のＰＵＣＣＨ送信は、４－段階ＲＡＣＨの場合にＭｓｇ４ＡＣＫ／ＮＡＣＫ ＰＵＣＣＨ送信と、２段階ＲＡＣＨを支援する場合にＭｓｇＢ ＡＣＫ／ＮＡＣＫ ＰＵＣＣＨ送信を含み得る。

【0241】

互いに異なるＵＥ帯域幅を有する複数の端末機タイプ（例えば、ＲｅｄＣａｐとｎｏｎ－ＲｅｄＣａｐ）を支援するために、基地局は、複数個の端末機タイプが共通に使用可能な共通の初期（ｃｏｍｍｏｎ ｉｎｉｔｉａｌ）（ＤＬ／ＵＬ）ＢＷＰを設定したり、又は端末機タイプ別に別途の（ｓｅｐａｒａｔｅ）初期（ＤＬ／ＵＬ）ＢＷＰを設定することができる。ここで、端末機タイプ別に別個に設定される場合に、それぞれの初期（ＤＬ／ＵＬ）ＢＷＰに対して互いに異なる帯域幅、周波数上の位置などの値が設定されてよい。

【0242】

例えば、ｎｏｎ－ＲｅｄＣａｐ ＵＥとＲｅｄＣａｐ ＵＥを同時に支援するセルでｎｏｎ－ＲｅｄＣａｐ ＵＥのための初期ＵＬ ＢＷＰ（以下、ｉＢＷＰ－ＵＬと称する。）とＲｅｄＣａｐのための初期ＵＬ ＢＷＰ（以下、ｉＢＷＰ－ＵＬ－Ｒと称する。）が別個に設定されてよい。ここで、ｉＢＷＰ－ＵＬ－Ｒの帯域幅のサイズは、ＲｅｄＣａｐ端末機の縮小したＵＥ帯域幅によってｉＢＷＰ－ＵＬの帯域幅よりも小さくてよい。また、基地局は、周波数上でｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬに全体又は一部が含まれるように設定できる。

【0243】

ＲｅｄＣａｐとｎｏｎ－ＲｅｄＣａｐが共存するセルにおいてｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬに全部又は一部が含まれるように設定された場合に、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬリソースの一部を占有することにより、ｉＢＷＰ－ＵＬにＵＬ（特に、ＰＵＳＣＨ）リソース分割（ｒｅｓｏｕｒｃｅ ｆｒａｇｍｅｎｔａｔｉｏｎ）問題が発生し得る。このようなＰＵＳＣＨリソース分割問題により、ＰＵＳＣＨ送信リソースの効率的な使用や送信のためのスケジューリングが難しくなることがある。このような問題点を最小化するために、基地局は、ｉＢＷＰ－ＵＬ－ＲをｉＢＷＰ－ＵＬの帯域エッジ（ｂａｎｄ ｅｄｇｅ）（例えば、下位帯域エッジ（ｌｏｗｅｒ ｂａｎｄ ｅｄｇｅ）又は上位帯域エッジ（ｕｐｐｅｒ ｂａｎｄ ｅｄｇｅ））に位置するように設定できる。

【0244】

図１７は、本開示の一実施例に係る一般ＵＥの初期ＵＬ ＢＷＰとｒｅｄｃａｐ ＵＥの初期ＢＷＰの設定を例示する図である。

【0245】

図１７では、ｉＢＷＰ－ＵＬ内のＰＵＳＣＨリソース分割問題点を軽減させるために、ｉＢＷＰ－ＵＬ－ＲをｉＢＷＰ－ＵＬの上位帯域エッジに配置した場合を例示する。

【0246】

図１７の例示のように、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの帯域エッジ（下位帯域エッジ又は上位帯域エッジ）に位置するように設定されてよい。これに加えて、ＰＵＳＣＨリソース分割問題点をより改善するために、ｉＢＷＰ－ＵＬ－Ｒでの共通ＰＵＣＣＨ送信時に、イントラスロット（ｉｎｔｒａ－ｓｌｏｔ）ＦＨを、基地局が設定によって活性／非活性（ｅｎａｂｌｅ／ｄｉｓａｂｌｅ）できる方法が導入される予定である。これに基づいて、本開示では次のようなｉＢＷＰ－ＵＬ－Ｒでの共通ＰＵＣＣＨ送信方法及び共通ＰＵＣＣＨリソース決定方法を提案する。本開示において、共通ＰＵＣＣＨ送信は、ＵＥが専用ＰＵＣＣＨリソース設定（ｄｅｄｉｃａｔｅｄ ＰＵＣＣＨ ｒｅｓｏｕｒｃｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受ける前のＰＵＣＣＨ送信を意味できる。

【0247】

図１７では、周波数ホッピングが活性化（ｅｎａｂｌｅ）され、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースがｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ内で周波数ホップされる場合を例示する。また、先の表１３のように、非ｒｅｄｃａｐ（ｎｏｎ－ｒｅｄｃａｐ）ＵＥ（すなわち、一般ＵＥ）は、当該ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ内で割り当て周波数ホッピングを用いて決定されたＰＵＣＣＨリソースでＰＵＣＣＨを送信することができる。

【0248】

実施例３－１：周波数ホッピング（ＦＨ）を用いたＰＵＣＣＨ送信（そして、ｒｅｄｃａｐ特定の（追加の）ＲＢオフセット）
ｉＢＷＰ－ＵＬ－Ｒで共通ＰＵＣＣＨ送信時に、ＦＨイネーブルが指示された（又は、ＦＨディセーブルが指示されていない）ＲｅｄＣａｐ ＵＥ（ＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述された、上記の表１３参照）は、既存の方法を用いてＰＵＣＣＨ送信リソース（ＰＲＢ（ｐｈｙｓｉｃａｌ ｒｅｓｏｕｒｃｅ ｂｌｏｃｋ）インデックス、初期ＣＳ値を含む。）を決定し、ＰＵＣＣＨ送信を行うことができる。

【0249】

より具体的には、ＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節（表１３参照）に記述された方法でＲｅｄＣａｐ ＵＥのＰＵＣＣＨ送信リソースを決定するとき、Ｎ_ＢＷＰ ^ｓｉｚｅは、ｉＢＷＰ－ＵＬ－Ｒのサイズ（ＰＲＢ単位）を意味する。ここで、Ｎ_ＢＷＰ ^ｓｉｚｅは、基地局がＲｅｄＣａｐのために別個に設定でき、又はＮ_ＢＷＰ ^ｓｉｚｅはｎｏｎ－ＲｅｄＣａｐ ＵＥと初期ＵＬ ＢＷＰを共有する場合に、ｉＢＷＰ－ＵＬのサイズ（ＰＲＢ単位）を意味できる。

【0250】

また、ｉＢＷＰ－ＵＬの共通ＰＵＣＣＨリソースセットとのＰＵＣＣＨ送信リソース間の干渉を回避するために、従来の１６個の共通ＰＵＣＣＨリソースセットを全て支援するものの（例えば、ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１を再使用、表１３参照）、ＲｅｄＣａｐのための別個の（追加の）ＲＢオフセット（ｏｆｆｓｅｔ）が設定されてよい。又は、別個にｎｏｎ－ＲｅｄＣａｐと異なるＰＵＣＣＨリソースセットインデックスを設定して、ｎｏｎ－ＲｅｄＣａｐのための共通ＰＵＣＣＨリソースセットと重ならないように設定されてよい。これは、ＲｅｄＣａｐ ｎｏｎ－ＲｅｄＣａｐ間のＰＵＣＣＨリソースの一部が重なることによって発生し得る干渉（ｉｎｔｅｒｆｅｒｅｎｃｅ）又はＲｅｄＣａｐとｎｏｎ－ＲｅｄＣａｐ ＰＵＣＣＨ送信リソース間の直交性（ｏｒｔｈｏｇｏｎａｌｉｔｙ）の侵害による性能低下を防止するためであってよく、このような方法は、本開示のいずれの実施例の提案方法にも適用されてよい。

【0251】

本開示において、ＲｅｄＣａｐ ＵＥがＰＵＣＣＨ送信リソースを決定するために最終的に使用する（すなわち、上記の表１３のＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述された計算式においてＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}に代えて使用する）ＰＵＣＣＨリソースＲＢオフセット値を、便宜上、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}と称する。ここで、ＲｅｄＣａｐ ＵＥは、基地局から別個のＲＢオフセットが指示される場合に、ＰＵＣＣＨリソースセットインデックスが指示するＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}の代わりに、別個に指示されたＲＢオフセットをＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値として決定できる。又は、設定される値がＲｅｄＣａｐのための別個の追加のＲＢオフセットである場合に、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}に指示された追加のＲＢオフセットを足してＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値を決定することもできる。このような別個の（追加の）ＲＢオフセットの定義とそれによるＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}の決定方法は、本開示で提案するいずれの方法にも適用されてよい。

【0252】

図１８には、本開示の一実施例に係る周波数ホッピングを用いたｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0253】

図１８では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）１８０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット１８０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0254】

表１８を参照すると、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。また、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内でイントラスロット周波数ホッピングが用いられて決定されるが、（ｎｏｎ－ｒｅｄｃａｐ ＵＥのＰＵＣＣＨリソース決定方法を同一に適用して）、ｎｏｎ－ｒｅｄｃａｐ ＵＥのＰＵＣＣＨリソースと重ならないように周波数オフセットがさらに適用されてよい。

【0255】

図１８では、ｎｏｎ－ＲｅｄＣａｐとＲｅｄＣａｐに共通にＰＵＣＣＨリソースセットインデックス＝１２が設定され、ＲｅｄＣａｐのみのために別個に（追加の）ＲＢオフセット（ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}＝２）が設定される例示と解釈されてよい。又は、図１８では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためにＰＵＣＣＨリソースセットインデックス＝１２が設定され、ＲｅｄＣａｐのためにはＰＵＣＣＨリソースセットインデックス＝１３が設定される例示と解釈されてよい。

【0256】

また、図１８では、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの下位帯域エッジに配置された場合を例示するが、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの上位帯域エッジに配置された場合も同一の方式で説明されてよい。

【0257】

実施例３－２：周波数ホッピング（ＦＨ）のないＰＵＣＣＨ送信（及び、ｒｅｄｃａｐ特定の（追加の）ＲＢオフセット）
ｉＢＷＰ－ＵＬ－Ｒで共通ＰＵＣＣＨ送信時に、ＦＨディセーブルが指示された（又は、ＦＨイネーブルが指示されていない）ＲｅｄＣａｐ ＵＥ（ＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述された、上記の表１３参照）は、ｎｏｎ－ＲｅｄＣａｐ ＵＥのＰＵＣＣＨ送信のための一番目の周波数ホップのＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一のＲＢ位置で）ＰＵＣＣＨ送信を行うことができる。

【0258】

図１９には、本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0259】

図１９では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）１９０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット１９０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0260】

図１９を参照すると、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。

【0261】

一方、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内で周波数ホッピング無しで決定されてよい。すなわち、ＦＨ非活性（ｄｉｓａｂｌｅ）を除けば、上記の図１８と同じ設定に該当する。言い換えると、実施例３－１と比較したとき、各ＰＵＣＣＨリソースが一番目の周波数ホップ位置でＦＨ無しでＰＵＣＣＨを送信できる。ここで、ｎｏｎ－ｒｅｄｃａｐ ＵＥのＰＵＣＣＨリソースと重ならないように周波数オフセットがさらに適用されてよい。

【0262】

図１９では、ｎｏｎ－ＲｅｄＣａｐとＲｅｄＣａｐに共通にＰＵＣＣＨリソースセットインデックス＝１２が設定され、ＲｅｄＣａｐのみのために別個に（追加の）ＲＢオフセット（ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}＝２）が設定される例示と解釈されてよい。又は、図１９ではｎｏｎ－ＲｅｄＣａｐ ＵＥのためにＰＵＣＣＨリソースセットインデックス＝１２が設定され、ＲｅｄＣａｐのためにはＰＵＣＣＨリソースセットインデックス＝１３が設定される例示と解釈されてよい。

【0263】

また、図１９では、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの下位帯域エッジに配置された場合を例示するが、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの上位帯域エッジに配置された場合も、同一の方式で説明されてよい。

【0264】

実施例３－２の場合、基地局は、ＰＵＣＣＨリソースインデックスであるｒ_{ＰＵＣＣＨ}の０～１５のうち特定値を用いてｉＢＷＰ－ＵＬ－Ｒの下位帯域エッジ又は上位帯域エッジ又は両方の帯域エッジ（ｂａｎｄ ｅｄｇｅ）ともＰＵＣＣＨ送信に用いるように設定できる。例えば、図１９のように、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの下位帯域エッジに設定された場合に、ｒ_{ＰＵＣＣＨ}＝０～７値を用いて下位帯域エッジにのみＰＵＣＣＨを送信するように制御できる。又は、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの上位帯域エッジに設定された場合に、ｒ_{ＰＵＣＣＨ}＝８～１５値を用いて上位帯域エッジにのみＰＵＣＣＨを送信するように制御できる。基地局は、ＲｅｄＣａｐとｎｏｎ－ＲｅｄＣａｐを同時に支援する場合に、前述したＰＵＳＣＨリソース分割問題を最小化するための目的で実施例３－２の提案方法を用いることができる。実施例３－２は、既存方式を極力再利用していて標準文書への影響が少ないとい長所があるが、基地局設定によって、いずれか一方の帯域エッジのみをＰＵＣＣＨ送信に用いようとする場合に、基地局は一部のＰＵＣＣＨリソースしか使用できず、可用ＰＵＣＣＨリソースが足りなくなるという短所があり得る。

【0265】

実施例３－３：周波数ホッピング（ＦＨ）無しで単一帯域エッジ（ｓｉｎｇｌｅ ｂａｎｄ ｅｄｇｅ）内でＰＵＣＣＨ送信（そして、ｒｅｄｃａｐ特定の（追加の）ＲＢオフセット）
上述したＰＵＳＣＨリソース分割問題を最小化しながら、同時に最大限のＰＵＣＣＨリソースを支援するために（例えば、現在ｎｏｎ－ＲｅｄＣａｐと同一に１６個のＰＵＣＣＨリソースインデックスを全て使用するために）、基地局は、ｉＢＷＰ－ＵＬ－Ｒの下位帯域エッジ又は上位帯域エッジ（又は、エッジでなくても下部側面（ｌｏｗｅｒ ｓｉｄｅ）又は上部側面（ｕｐｐｅｒ ｓｉｄｅ））いずれか一方の連続した周波数リソースにのみＰＵＣＣＨリソースセットを設定することができる。実施例３－３は、ＲｅｄＣａｐとｎｏｎ－ＲｅｄＣａｐが共存し、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬに一部又は全部が含まれる場合に限って適用されてもよい。及び／又は、ＲｅｄＣａｐのためのＰＵＣＣＨ ＦＨがディセーブルされた場合に限って適用されてもよい。

【0266】

方法１：実施例３－３を支援するための一方法として、ｉＢＷＰ－ＵＬ－Ｒで共通ＰＵＣＣＨ送信時に、ＦＨ非活性（ｄｉｓａｂｌｅ）が指示された（又は、ＦＨイネーブルが指示されていない）ＲｅｄＣａｐ ＵＥ（ＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述された、上記の表１３参照）は、ｎｏｎ－ＲｅｄＣａｐ ＵＥのＰＵＣＣＨ送信のための一番目の周波数ホップのＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一の位置で）ＰＵＣＣＨ送信を行うことができる。実施例３－３の方法１において、ＰＵＣＣＨ送信ＰＲＢが一方の帯域エッジ（又は、帯域の一側）に連続して生成されるようにするために、前記実施例３－１又は実施例３－２とは違い、Ｎ_ＢＷＰ ^ｓｉｚｅがｉＢＷＰ－ＵＬ－Ｒ又はｉＢＷＰ－ＵＬのサイズ（ＰＲＢ単位）でなく新しい値に代えて適用されてよい。実施例３－３の方法１においてＮ_ＢＷＰ ^ｓｉｚｅを代替する値は、上記の表１３内のＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述されたＰＵＣＣＨ送信のための一番目の周波数ホップのＲＢ位置を決定する方式を適用したとき、ＰＵＣＣＨ送信ＰＲＢが一方の帯域エッジ（又は、帯域の一側）に連続して生成されるようにするために、基地局がシステム情報（例えば、ＳＩＢ１）を用いて指示したり、又は、例えば、次のような計算式のように決定されてよい。

【0267】

【数3】

【0268】

本開示では、説明の便宜上、上述した目的でＮ_ＢＷＰ ^ｓｉｚｅを代替する値を仮想（ｖｉｒｔｕａｌ）（初期）（ＵＬ）ＢＷＰサイズであるＮ_{ＢＷＰ，Ｖ} ^ｓｉｚｅと定義する。この場合、例えば、Ｎ_{ＢＷＰ，Ｖ} ^ｓｉｚｅは次のように定義され、ＰＵＣＣＨ送信ＲＢインデックス計算時に、

に代えて用いられてよい。

【0269】

【数4】

上記の式３及び４で、

は、従来の方式で設定されたＰＵＣＣＨリソースセットが各帯域エッジ別に占有する連続したＰＲＢ個数を意味する。

は、ｃｅｉｌｉｎｇ関数（すなわち、ｃｅｉｌ（ｘ）はｘよりも小さくない最小の整数）を表示する。

【0270】

より具体的には、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳ値を決定する初期ＣＳインデックスは、次のように決定されてよい。

【0271】

－ ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝０であり、ＵＥに、ＰＵＣＣＨリソースに対する共通設定（例えば、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ）によってＰＵＣＣＨリソースが提供され、ＵＬ ＢＷＰに対する共通設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内のＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）使用に対する設定（例えば、ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）が提供されないと、ＵＥは、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}＋ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のようにＰＵＣＣＨ送信のＰＲＢインデックスを決定できる。ここで、Ｎ_ＣＳは、初期ＣＳインデックスのセット内の初期ＣＳインデックスの全体個数である。また、ＵＥは、初期ＣＳインデックスのセット内の初期ＣＳインデックスをｒ_{ＰＵＣＣＨ}ｍｏｄＮ_ＣＳのように決定できる。

【0272】

－ 一方、ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝１であり、ＵＥにＰＵＣＣＨリソースに対する共通設定（例えば、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ）によってＰＵＣＣＨリソースが提供され、ＵＬ ＢＷＰに対する共通設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内のＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）使用に対する設定（例えば、ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）が提供されないと、ＵＥは、Ｎ_{ＢＷＰ，Ｖ} ^ｓｉｚｅ－１－ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}－ｆｌｏｏｒ（（ｒ_{ＰＵＣＣＨ}－８）／Ｎ_ＣＳ）のようにＰＵＣＣＨ送信のＰＲＢインデックスを決定できる。ここで、初期ＣＳインデックスのセット内の初期ＣＳインデックスを（ｒ_{ＰＵＣＣＨ}－８）ｍｏｄＮ_ＣＳのように決定できる。

【0273】

上述した説明において、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳインデックスを決定するために用いられる上位層パラメータは、ＴＳ ３８．２１３とＴＳ ３８．３３１の定義にしたがうことができる。

【0274】

図２０及び図２１には、本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0275】

図２０及び図２１では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）２００１，２１０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット２００２，２１０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0276】

図２０では、ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の下位帯域エッジに設定された場合を例示し、図２１では、ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の上位帯域エッジに設定された場合を例示する。前記実施例３－３の方法１のようにｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースセットは一方の帯域エッジ（又は、帯域の一側）に連続して決定されてよい（図２０では下位帯域エッジ、図２１では上位帯域エッジ）。

【0277】

より具体的には、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。

【0278】

一方、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、前記実施例３－３の方法１によって、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内で周波数ホッピング無しで決定されてよい。より具体的には、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}を用いてＮ_{ＢＷＰ，Ｖ} ^ｓｉｚｅが決定されてよい。そして、ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝０である場合に、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}を用いてｎｏｎ－ＲｅｄＣａｐ ＵＥのＰＵＣＣＨ送信のための一番目の周波数ホップのＲＢ位置が決定されてよい。また、ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／８）＝１である場合に、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}とＮ_{ＢＷＰ，Ｖ} ^ｓｉｚｅを用いてｎｏｎ－ＲｅｄＣａｐ ＵＥのＰＵＣＣＨ送信のための一番目の周波数ホップのＲＢ位置が決定されてよい。そして、当該ＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一のＲＢ位置で）ＰＵＣＣＨ送信が行われてよい。

【0279】

ここで、図２１のように、上位帯域エッジ例示の動作を支援するために、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値は、０からＮ_ＢＷＰ ^ｓｉｚｅ－４値までの範囲を支援可能でなければならない。

【0280】

方法２：実施例３－３を支援するためのさらに他の方法として、ｉＢＷＰ－ＵＬ－Ｒで共通ＰＵＣＣＨ送信時に、ＦＨ非活性（ｄｉｓａｂｌｅ）が指示された（又は、ＦＨイネーブルが指示されていない）ＲｅｄＣａｐ ＵＥは、（ＴＳ ３８．２１３ ｓｐｅｃ ９．２．１節に記述された）ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}から始まって順次にＰＵＣＣＨリソースインデックスの昇順でＲＢインデックスが増加しながら決定されたＰＵＣＣＨ送信ＲＢ位置でＰＵＣＣＨ送信を行うことができる。

【0281】

より具体的には、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳ値を決定する初期ＣＳインデックスは、次のように決定されてよい。

【0282】

ＵＥに、ＰＵＣＣＨリソースに対する共通設定（例えば、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ）によってＰＵＣＣＨリソースが提供され、ＵＬ ＢＷＰに対する共通設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内のＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）使用に対する設定（例えば、ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）を提供されないと、ＵＥは、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}＋ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のようにＰＵＣＣＨ送信のＰＲＢインデックスを決定できる。ここで、Ｎ_ＣＳは、初期ＣＳインデックスのセット内の初期ＣＳインデックスの全体個数である。また、ＵＥは、初期ＣＳインデックスのセット内の初期ＣＳインデックスをｒ_{ＰＵＣＣＨ}ｍｏｄＮ_ＣＳのように決定できる。

【0283】

上述した説明において、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳインデックスを決定するために用いられる上位層パラメータは、ＴＳ ３８．２１３とＴＳ ３８．３３１の定義にしたがうことができる。

【0284】

実施例３－３の方法２は、方法１と違い、Ｎ_{ＢＷＰ，Ｖ} ^ｓｉｚｅを要求しないため、Ｎ_{ＢＷＰ，Ｖ} ^ｓｉｚｅのため計算や別個のシグナリングが要求されない。

【0285】

図２２及び図２３には、本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0286】

図２２及び図２３では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）２２０１，２３０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット２２０２，２３０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0287】

図２２では、ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の下位帯域エッジに設定された場合を例示し、図２３では、ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の上位帯域エッジに設定された場合を例示する。上記の実施例３－３の方法２のように、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースセットは一方の帯域エッジ（又は、帯域の一側）に連続して決定されてよい（図２２では下位帯域エッジ、図２３では上位帯域エッジ）。

【0288】

より具体的には、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。

【0289】

一方、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、前記実施例３－３の方法１によって、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内で周波数ホッピング無しで決定されてよい。より具体的には、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}から始まって順次にＰＵＣＣＨリソースインデックスの昇順でＲＢインデックスが増加しながらＰＵＣＣＨ送信ＲＢの位置が決定されてよい。そして、当該ＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一のＲＢ位置で）ＰＵＣＣＨ送信が行われてよい。

【0290】

ここで、図２３のように、上位帯域エッジ例示の動作を支援するために、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値は０からＮ_ＢＷＰ ^ｓｉｚｅ－４値までの範囲を支援可能でなければならない。

【0291】

実施例３－４：周波数ホッピング（ＦＨ）のない単一帯域エッジ（ｓｉｎｇｌｅ ｂａｎｄ ｅｄｇｅ）内でＰＵＣＣＨ送信（帯域エッジ（ｂａｎｄ ｅｄｇｅ）指示を含む）
上位帯域エッジ例示の動作を支援するために、前記実施例３－３のように大きい値の範囲を有するＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}（例えば、０～Ｎ_ＢＷＰ ^ｓｉｚｅ－４）を支援する代わりに、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}の範囲をｉＢＷＰ－ＵＬ－Ｒの半分以内と定義／設定し、１ビットの追加情報によって上位帯域又は下位帯域のいずれか一方が指示されてよい。

【0292】

ここで、前記追加１ビット情報は、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が上位帯域エッジ（すなわち、ｉＢＷＰ－ＵＬ－Ｒの最上位ＲＢインデックス（ｈｉｇｈｅｓｔ ＲＢ ｉｎｄｅｘ））からのＲＢオフセット認知、下位帯域エッジ（すなわち、ｉＢＷＰ－ＵＬ－Ｒの最下位ＲＢインデックス（ｌｏｗｅｓｔ ＲＢ ｉｎｄｅｘ）又はＲＢインデックス＝０）からのＲＢオフセット認知を直接に知らせることができる。又は、前記追加１ｂｉｔ情報は、ｉＢＷＰ－ＵＬ－ＲがｉＢＷＰ－ＵＬの上位帯域エッジに配置されたか或いは下位帯域エッジに配置されたかを知らせることにより、端末機にとってのＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}の解釈を助ける情報であってよい。本開示では、追加１ビット情報を、便宜上、帯域エッジ指示子（ＢＥＩ：ｂａｎｄ ｅｄｇｅ ｉｎｄｉｃａｔｏｒ）と呼ぶ。例えば、ＢＥＩ＝０は下位帯域エッジを意味し、ＢＥＩ＝１は上位帯域エッジを意味するか（その逆も可能）、又は真（ｔｒｕｅ）／偽（ｆａｌｓｅ）によって下位帯域エッジと上位帯域エッジが区分されてもよい。また、ＢＥＩは、システム情報（例えば、ＳＩＢ１）で端末機に送信されてよい。

【0293】

仮に、ＢＥＩによってＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が下位帯域エッジからのＲＢオフセットである場合に、前述した実施例３－３の方法２の例示１（図２２参照）又は実施例３－３の方法１の例示１（図２０参照）と同じ方式でＰＵＣＣＨ送信リソースが決定されてよい。これについて、先の実施例３－３を参照でき、以下、詳細な説明は省略する。

【0294】

方法１：ＢＥＩによってＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が上位帯域エッジからのＲＢオフセットである場合に、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}は、ＰＵＣＣＨ送信リソースの最下位ＲＢインデックス（ｌｏｗｅｓｔ ＲＢインデックス）までのオフセットを指示できる。この場合、ＰＵＣＣＨ送信ＲＢインデックスは、Ｎ_ＣＳまで共に考慮してＰＵＣＣＨリソースインデックス（すなわち、ｒ_{ＰＵＣＣＨ}）が増加するにつれてＰＵＣＣＨ送信ＲＢインデックスが増加する方式で決定されてよい。

【0295】

このとき、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳ値を決定する初期ＣＳインデックスは、次のように決定されてよい（方法Ｐ２実施例２と同一）。

【0296】

ＵＥにＰＵＣＣＨリソースに対する共通設定（例えば、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ）によってＰＵＣＣＨリソースが提供され、ＵＬ ＢＷＰに対する共通設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内のＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）使用に対する設定（例えば、ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）が提供されないと、ＵＥは、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}＋ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のようにＰＵＣＣＨ送信のＰＲＢインデックスを決定できる。ここで、Ｎ_ＣＳは、初期ＣＳインデックスのセット内の初期ＣＳインデックスの全体個数である。また、ＵＥは、初期ＣＳインデックスのセット内の初期ＣＳインデックスをｒ_{ＰＵＣＣＨ}ｍｏｄＮ_ＣＳのように決定できる。

【0297】

上述した説明において、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳインデックスを決定するために用いられる上位層パラメータは、ＴＳ ３８．２１３とＴＳ ３８．３３１の定義にしたがうことができる。

【0298】

図２４には、本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0299】

図２４では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）２４０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット２４０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0300】

図２４では、ＢＥＩによってＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が上位帯域エッジ（すなわち、ｉＢＷＰ－ＵＬ－Ｒの最上位ＲＢインデックス（ｈｉｇｈｅｓｔ ＲＢ ｉｎｄｅｘ））からのＲＢオフセットであることが指示されたり又はｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の上位帯域エッジに設定されたと指示された場合を例示する。前記実施例３－４のように、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースセットは一方の帯域エッジ（又は、帯域の一側）に連続して決定されてよい。

【0301】

より具体的には、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。

【0302】

一方、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、前記実施例３－４の方法１によって、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内で周波数ホッピング無しで決定されてよい。より具体的には、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}から始まって順次にＰＵＣＣＨリソースインデックスの昇順でＲＢインデックスが増加しながらＰＵＣＣＨ送信ＲＢの位置が決定されてよい。そして、当該ＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一のＲＢ位置で）ＰＵＣＣＨ送信が行われてよい。

【0303】

方法２：ＢＥＩによってＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が上位帯域エッジからのＲＢオフセットである場合、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}はＰＵＣＣＨ送信リソースの最上位（ｈｉｇｈｅｓｔ）（すなわち、上位帯域に最も近い）ＲＢインデックスまでの間隔を指示できる。この場合、ＰＵＣＣＨ送信ＲＢインデックスはＮ_ＣＳまで共に考慮してＰＵＣＣＨリソースインデックス（すなわち、ｒ_{ＰＵＣＣＨ}）が増加するにつれてＰＵＣＣＨ送信ＲＢインデックスが減少する方式で決定されてよい。

【0304】

ここで、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳ値を決定する初期ＣＳインデックスは、次のように決定されてよい。

【0305】

ＵＥにＰＵＣＣＨリソースに対する共通設定（例えば、ｐｕｃｃｈ－ＲｅｓｏｕｒｃｅＣｏｍｍｏｎ）によってＰＵＣＣＨリソースが提供され、ＵＬ ＢＷＰに対する共通設定（例えば、ＢＷＰ－ＵｐｌｉｎｋＣｏｍｍｏｎ）内ＰＵＣＣＨとＰＵＳＣＨのインターレース（ｉｎｔｅｒｌａｃｅ）使用に対する設定（例えば、ｕｓｅＩｎｔｅｒｌａｃｅＰＵＣＣＨ－ＰＵＳＣＨ）が提供されないと、ＵＥは、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}－ｆｌｏｏｒ（ｒ_{ＰＵＣＣＨ}／Ｎ_ＣＳ）のようにＰＵＣＣＨ送信のＰＲＢインデックスを決定できる。ここで、Ｎ_ＣＳは、初期ＣＳインデックスのセット内の初期ＣＳインデックスの全体個数である。また、ＵＥは、初期ＣＳインデックスのセット内の初期ＣＳインデックスをｒ_{ＰＵＣＣＨ}ｍｏｄＮ_ＣＳのように決定できる。

【0306】

上述した説明において、ＰＵＣＣＨ送信ＲＢインデックスと初期ＣＳインデックスを決定するために用いられる上位層パラメータは、ＴＳ ３８．２１３とＴＳ ３８．３３１の定義にしたがうことができる。

【0307】

図２５には、本開示の一実施例に係る周波数ホッピングのないｒｅｄｃａｐ ＵＥのＰＵＣＣＨ送信を例示する。

【0308】

図２５では、ｎｏｎ－ＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット（ｒｅｓｏｕｒｃｅ ｓｅｔ）２５０１とＲｅｄＣａｐ ＵＥのためのＰＵＣＣＨリソースセット２５０２の時間／周波数リソースを例示する。また、周波数ホッピングの有無を表示するために、ＰＵＣＣＨ送信スロット内で一つのＰＵＣＣＨリソースが占有するシンボル（時間ドメイン内）／ＲＢ（周波数ドメイン内）領域は同一のパターンとして例示する。また、各ＰＵＣＣＨ送信ＲＢ内の数字は、ＰＵＣＣＨリソースインデックスｒ_{ＰＵＣＣＨ}を表す。同一のＰＵＣＣＨ送信ＲＢで送信されるＰＵＣＣＨリソースは、（ＴＳ ３８．２１３ Ｔａｂｌｅ ９．２．１－１で定義された）（上記の表１３参照）Ｎ_ＣＳ個の互いに異なるＣＳによってＰＵＣＣＨリソースが区分されてよい。

【0309】

図２５では、ＢＥＩによってＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}が上位帯域エッジ（すなわち、ｉＢＷＰ－ＵＬ－Ｒの最上位ＲＢインデックス（ｈｉｇｈｅｓｔ ＲＢ ｉｎｄｅｘ））からのＲＢオフセットであることが指示されたり又はｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）がｎｏｎ－ｒｅｄｃａｐ ＵＥに対する初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）の上位帯域エッジに設定されたと指示された場合を例示する。前記実施例３－４のようにｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースセットは一方の帯域エッジ（又は、帯域の一側）に連続して決定されてよい。

【0310】

より具体的には、ｎｏｎ－ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、ｎｏｎ－ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ）内でイントラスロット周波数ホッピングが用いられて決定される。

【0311】

一方、ｒｅｄｃａｐ ＵＥのためのＰＵＣＣＨリソースは、前記実施例３－４の方法２によって、ｒｅｄｃａｐ ＵＥのための初期ＵＬ ＢＷＰ（ｉＢＷＰ－ＵＬ－Ｒ）内で周波数ホッピング無しで決定されてよい。より具体的には、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}から始まって順次にＰＵＣＣＨリソースインデックスの昇順でＲＢインデックスが減少しながらＰＵＣＣＨ送信ＲＢの位置が決定されてよい。そして、当該ＲＢ位置でＦＨ無しで（すなわち、二番目の周波数ホップも一番目の周波数ホップに続いて同一のＲＢ位置で）ＰＵＣＣＨ送信が行われてよい。

【0312】

一方、上述した実施例３－４の方法１と方法２の両方において、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}は上位帯域エッジから最下位（ｌｏｗｅｓｔ）ＰＵＣＣＨリソースインデックス（例えば、ｒ_{ＰＵＣＣＨ}＝０）のＰＵＣＣＨ送信ＲＢインデックスまでのオフセットを指示できる（すなわち、このように定義されてよい。）。

【0313】

また、本開示で提案した方法（例えば、実施例１、実施例２、実施例３、実施例１～３の細部実施例のいずれか一つ又は複数の組合せ）において基地局がＲｅｄＣａｐ ＵＥの共通ＰＵＣＣＨ送信のために設定／指示するＲｅｄＣａｐのための（別個の）初期ＵＬ ＢＷＰと関連した設定、別個の（追加の）ＲＢオフセット（すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}）、別個のＰＵＣＣＨリソースセットインデックス、ＦＨ活性（ｅｎａｂｌｅ）／非活性（ｄｉｓａｂｌｅ）、Ｎ_ＢＷＰ ^ｓｉｚｅを代替する値などのパラメータは、上位層シグナリング（例えば、ＳＩＢ１のようなシステム情報）で端末に送信／設定されてよい。

【0314】

図２６は、本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する基地局と端末間のシグナリング手続を例示する図である。

【0315】

図２６では、先に提案した方法に基づく端末（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）と基地局（ＢＳ：ｂａｓｅ ｓｔａｔｉｏｎ）間のシグナリング手続を例示する。図２６の例示は説明の便宜のためのことであり、本開示の範囲を制限するのではない。図２６で例示された一部の段階は、状況及び／又は設定によって省略されてよい。また、図２６で基地局と端末は一つの例示に過ぎず、下の図２９で例示される装置によって具現されてよい。例えば、図２９のプロセッサ（ｐｒｏｃｅｓｓｏｒ）１０２／２０２は、トランシーバー１０６／２０６を用いてチャネル／信号／データ／情報などを送受信するように制御でき、送信する又は受信したチャネル／信号／データ／情報などをメモリ１０４／２０４に保存するように制御することができる。

【0316】

また、図２６の基地局と端末間の動作において、特に言及がなくても、上述した内容が参照／利用されてよい。

【0317】

基地局は、端末とデータの送受信を行う客体（ｏｂｊｅｃｔ）を総称する意味であってよい。例えば、前記基地局は、一つ以上のＴＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｏｉｎｔ）、一つ以上のＴＲＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ Ｒｅｃｅｐｔｉｏｎ Ｐｏｉｎｔ）などを含む概念であってよい。また、ＴＰ及び／又はＴＲＰは、基地局のパネル、送受信ユニット（ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ ｒｅｃｅｐｔｉｏｎ ｕｎｉｔ）などを含むものであってよい。また、「ＴＲＰ」は、パネル（ｐａｎｅｌ）、アンテナアレイ（ａｎｔｅｎｎａ ａｒｒａｙ）、セル（ｃｅｌｌ）（例えば、マクロセル（ｍａｃｒｏ ｃｅｌｌ）／スモールセル（ｓｍａｌｌ ｃｅｌｌ）／ピコセル（ｐｉｃｏ ｃｅｌｌ）など）、ＴＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｐｏｉｎｔ）、基地局（ｂａｓｅ ｓｔａｔｉｏｎ，ｇＮＢなど）などの表現に代えて適用されてよい。上述したように、ＴＲＰは、ＣＯＲＥＳＥＴグループ（又は、ＣＯＲＥＳＥＴプール）に関する情報（例えば、インデックス、ＩＤ）によって区分されてよい。一例として、一つの端末が複数のＴＲＰ（又は、セル）と送受信を行うように設定された場合に、これは、一つの端末に対して複数のＣＯＲＥＳＥＴグループ（又は、ＣＯＲＥＳＥＴプール）が設定されたことを意味できる。このようなＣＯＲＥＳＥＴグループ（又は、ＣＯＲＥＳＥＴプール）に対する設定は、上位層シグナリング（例えば、ＲＲＣシグナリングなど）によって行われてよい。

【0318】

図２６を参照すると、説明の便宜上、１個の基地局と端末間のシグナリングが考慮されるが、当該シグナリング方式が複数のＴＲＰ及び複数のＵＥとの間のシグナリングにも拡張して適用され得ることは勿論である。以下の説明において、基地局は一つのＴＲＰと解釈されてよい。又は、基地局は、複数のＴＲＰを含んでもよく、又は複数のＴＲＰを含む一つのセル（Ｃｅｌｌ）であってもよい。

【0319】

図２６を参照すると、特定タイプの端末（例えば、ｒｅｄｃａｐ端末）は基地局からシステム情報（例えば、ＳＩＢ１）を受信する（Ｓ２６０１）。

【0320】

前記システム情報は、ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供される前に、ｒｅｄｃａｐ端末の共通ＰＵＣＣＨ送信のための設定情報を含むことができる。

【0321】

例えば、システム情報は、ＲｅｄＣａｐのための（別個の）初期ＵＬ ＢＷＰと関連した設定、そして別個の（追加の）ＲＢオフセット（すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}）、別個のＰＵＣＣＨリソースセットインデックス、ＦＨ活性（ｅｎａｂｌｅ）／非活性（ｄｉｓａｂｌｅ）を指示する情報、Ｎ_ＢＷＰ ^ｓｉｚｅを代替する値などのパラメータを含み得る。

【0322】

また、システム情報は、ＰＵＣＣＨリソースに対するＰＲＢマッピングにおいて追加のＰＲＢオフセットに関する情報（以下、第１情報）、及び前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに関する情報（以下、第２情報）を含むことができる。

【0323】

また、上述したように、ｒｅｄｃａｐ端末のＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを決定するためのＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）と前記追加のＰＲＢオフセットを用いて決定されてよい。すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値は、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}に指示された追加のＲＢオフセットを足して決定されてよい。この場合、システム情報は、セル特定ＰＵＣＣＨリソースのセットを設定するための情報（以下、第３情報）をさらに含んでよく、前記ＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）は、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報から決定されてよい。

【0324】

端末は基地局からＰＤＳＣＨをスケジュールするＤＣＩを受信し（Ｓ２６０２）、端末は基地局から前記ＤＣＩに基づいてＰＤＳＣＨを受信する（Ｓ２６０３）。

【0325】

ここで、ＤＣＩは、ＰＤＣＣＨで送信されてよい。また、上述したように、本開示で提案する方法がｒｅｄｃａｐ端末のランダムアクセス手続中に適用されるとき、前記ＰＤＳＣＨは、ＭＳＧ２、ＭＳＧ４又はＭＳＧＢを運ぶことができる。ここで、ＭＳＧ２は、４－段階ランダムアクセス手続においてランダムアクセス応答に対するＰＤＣＣＨ、ＰＤＳＣＨを意味でき、ＭＳＧ４は、４－段階ランダムアクセス手続において競合解消のためのＰＤＳＣＨを意味でき、ＭＳＧＢは、２－段階ランダムアクセス手続においてランダムアクセス応答ＵＬグラントによってスケジュールされるＰＵＳＣＨ及び競合解消のためのＰＤＳＣＨを意味できる。

【0326】

ここで、前記ＰＤＳＣＨがＭＳＧ２を運ぶとき、ｒｅｄｃａｐ ＵＥは、前記実施例１で提案する方法によってＰＤＳＣＨを受信することができる。その後、図２６に図示してはいないが、ｒｅｄｃａｐ ＵＥは、前記実施例２で提案する方法に基づいてＭＳＧ３を基地局に送信できる。

【0327】

端末は、前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ情報をＰＵＣＣＨで基地局に送信する（Ｓ２６０４）。

【0328】

ここで、ｒｅｄｃａｐ ＵＥは、前記実施例３で提案する方法によってＰＵＣＣＨを送信できる。特に、ＰＵＣＣＨ送信のためのＰＲＢインデックスは、上述した実施例３（実施例３の細部実施例のいずれか一つ又は複数の組合せ）によって決定されてよい。

【0329】

例えば、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0330】

ここで、前記ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供されていない場合（例えば、専用ＰＵＣＣＨリソース設定受信前）に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0331】

また、前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）される場合に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。ここで、前記ＰＵＣＣＨの送信に対する周波数ホッピングが活性（ｅｎａｂｌｅｄ）されるか又は非活性（ｄｉｓａｂｌｅｄ）されるかは、前記基地局による設定に基づいて決定されてよい。

【0332】

また、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報によって決定されたＰＲＢオフセットと前記追加のＰＲＢオフセットを用いて決定されてよい。

【0333】

例えば、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加することにつれてＰＲＢインデックスが増加し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを正（ｐｏｓｉｔｉｖｅ）の値で適用して決定されてよい。

【0334】

さらに他の例として、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが減少し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを負（ｎｅｇａｔｉｖｅ）の値で適用して決定されてよい。

【0335】

図２７は、本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する端末の動作を例示する図である。

【0336】

図２７では、先に提案した方法に基づく端末の動作を例示する。図２７の例示は説明の便宜のためのものであり、本開示の範囲を制限するものではない。図２７で例示された一部の段階は状況及び／又は設定によって省略されてよい。また、図２７で、端末は一つの例示に過ぎず、下記の図２９で例示される装置によって具現されてよい。例えば、図２９のプロセッサ（ｐｒｏｃｅｓｓｏｒ）１０２／２０２は、トランシーバー１０６／２０６を用いてチャネル／信号／データ／情報などを送受信するように制御でき、送信する又は受信したチャネル／信号／データ／情報などをメモリ１０４／２０４に保存するように制御することができる。

【0337】

図２６を参照すると、特定タイプの端末（例えば、ｒｅｄｃａｐ端末）は基地局からシステム情報（例えば、ＳＩＢ１）を受信する（Ｓ２７０１）。

【0338】

前記システム情報は、ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供される前に、ｒｅｄｃａｐ端末の共通ＰＵＣＣＨ送信のための設定情報を含むことができる。

【0339】

例えば、システム情報は、ＲｅｄＣａｐのための（別個の）初期ＵＬ ＢＷＰと関連した設定、そして別個の（追加の）ＲＢオフセット（すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}）、別個のＰＵＣＣＨリソースセットインデックス、ＦＨ活性（ｅｎａｂｌｅ）／非活性（ｄｉｓａｂｌｅ）を指示する情報、Ｎ_ＢＷＰ ^ｓｉｚｅを代替する値などのパラメータを含むことができる。

【0340】

また、システム情報は、ＰＵＣＣＨリソースに対するＰＲＢマッピングにおいて追加のＰＲＢオフセットに関する情報（以下、第１情報）、及び前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに関する情報（以下、第２情報）を含むことができる。

【0341】

また、上述したように、ｒｅｄｃａｐ端末のＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを決定するためのＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）と前記追加のＰＲＢオフセットを用いて決定されてよい。すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値は、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}に指示された追加のＲＢオフセットを足して決定されてよい。この場合、システム情報は、セル特定ＰＵＣＣＨリソースのセットを設定するための情報（以下、第３情報）をさらに含んでよく、前記ＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）は、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報から決定されてよい。

【0342】

特定タイプの端末（例えば、ｒｅｄｃａｐ端末）は、基地局からＰＤＳＣＨをスケジュールするＤＣＩを受信し（Ｓ２７０２）、特定タイプの端末（例えば、ｒｅｄｃａｐ端末）は、基地局から前記ＤＣＩに基づいてＰＤＳＣＨを受信する（Ｓ２７０３）。

【0343】

ここで、ＤＣＩはＰＤＣＣＨで送信されてよい。また、上述したように、本開示で提案する方法がｒｅｄｃａｐ端末のランダムアクセス手続中に適用されるとき、前記ＰＤＳＣＨはＭＳＧ２、ＭＳＧ４又はＭＳＧＢを運ぶことができる。ここで、ＭＳＧ２は、４－段階ランダムアクセス手続においてランダムアクセス応答に対するＰＤＣＣＨ、ＰＤＳＣＨを意味でき、ＭＳＧ４は、４－段階ランダムアクセス手続において競合解消のためのＰＤＳＣＨを意味でき、ＭＳＧＢは、２－段階ランダムアクセス手続においてランダムアクセス応答ＵＬグラントによってスケジュールされるＰＵＳＣＨ及び競合解消のためのＰＤＳＣＨを意味できる。

【0344】

ここで、前記ＰＤＳＣＨがＭＳＧ２を運ぶとき、ｒｅｄｃａｐ ＵＥは、前記実施例１で提案する方法によってＰＤＳＣＨを受信することができる。その後、図２７には図示していないが、ｒｅｄｃａｐ ＵＥは、前記実施例２で提案する方法に基づいてＭＳＧ３を基地局に送信できる。

【0345】

特定タイプの端末（例えば、ｒｅｄｃａｐ端末）は、前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ情報をＰＵＣＣＨで基地局に送信する（Ｓ２７０４）。

【0346】

ここで、ｒｅｄｃａｐ ＵＥは、前記実施例３で提案する方法によってＰＵＣＣＨを送信できる。特に、ＰＵＣＣＨ送信のためのＰＲＢインデックスは、上述した実施例３（実施例３の細部実施例のいずれか一つ又は複数の組合せ）によって決定されてよい。

【0347】

例えば、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0348】

ここで、前記ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供されていない場合（例えば、専用ＰＵＣＣＨリソース設定受信前）に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0349】

また、前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）される場合に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。ここで、前記ＰＵＣＣＨの送信に対する周波数ホッピングが活性（ｅｎａｂｌｅｄ）されるか又は非活性（ｄｉｓａｂｌｅｄ）されるかは、前記基地局による設定に基づいて決定されてよい。

【0350】

また、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報によって決定されたＰＲＢオフセットと前記追加のＰＲＢオフセットを用いて決定されてよい。

【0351】

例えば、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが増加し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを正（ｐｏｓｉｔｉｖｅ）の値で適用して決定されてよい。

【0352】

さらに他の例として、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが減少し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを負（ｎｅｇａｔｉｖｅ）の値で適用して決定されてよい。

【0353】

図２８は、本開示の一実施例に係るＰＵＣＣＨ送受信方法に対する基地局の動作を例示する図である。

【0354】

図２８では、先に提案した方法に基づく基地局の動作を例示する。図２８の例示は説明の便宜のためのものであり、本開示の範囲を制限するものではない。図２８で例示された一部の段階は、状況及び／又は設定によって省略されてよい。また、図２８で基地局は一つの例示に過ぎず、下記の図２９で例示される装置によって具現されてよい。例えば、図２９のプロセッサ（ｐｒｏｃｅｓｓｏｒ）１０２／２０２は、トランシーバー１０６／２０６を用いてチャネル／信号／データ／情報などを送受信するように制御でき、送信する又は受信したチャネル／信号／データ／情報などをメモリ１０４／２０４に保存するように制御することができる。

【0355】

図２８を参照すると、基地局は特定タイプの端末（例えば、ｒｅｄｃａｐ端末）にシステム情報（例えば、ＳＩＢ１）を送信する（Ｓ２８０１）。

【0356】

前記システム情報は、ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供される前に、ｒｅｄｃａｐ端末の共通ＰＵＣＣＨ送信のための設定情報を含むことができる。

【0357】

例えば、システム情報は、ＲｅｄＣａｐのための（別個の）初期ＵＬ ＢＷＰと関連した設定、そして別個の（追加の）ＲＢオフセット（すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}）、別個のＰＵＣＣＨリソースセットインデックス、ＦＨ活性（ｅｎａｂｌｅ）／非活性（ｄｉｓａｂｌｅ）を指示する情報、Ｎ_ＢＷＰ ^ｓｉｚｅを代替する値などのパラメータを含むことができる。

【0358】

また、システム情報は、ＰＵＣＣＨリソースに対するＰＲＢマッピングにおいて追加のＰＲＢオフセットに関する情報（以下、第１情報）、及び前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期上りリンク帯域幅部分（ＢＷＰ：ｂａｎｄｗｉｄｔｈ ｐａｒｔ）の下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされるか又は上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされるかに関する情報（以下、第２情報）を含むことができる。

【0359】

また、上述したように、ｒｅｄｃａｐ端末のＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを決定するためのＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）と前記追加のＰＲＢオフセットを用いて決定されてよい。すなわち、ＲＢ_{ＢＷＰ，Ｒ} ^{ｏｆｆｓｅｔ}値は、ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}に指示された追加のＲＢオフセットを足して決定されてよい。この場合、システム情報は、セル特定ＰＵＣＣＨリソースのセットを設定するための情報（以下、第３情報）をさらに含んでよく、前記ＰＲＢオフセット（ＲＢ_ＢＷＰ ^{ｏｆｆｓｅｔ}）は、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報から決定されてよい。

【0360】

基地局は特定タイプの端末（例えば、ｒｅｄｃａｐ端末）に、ＰＤＳＣＨをスケジュールするＤＣＩを送信し（Ｓ２８０２）、基地局は特定タイプの端末（例えば、ｒｅｄｃａｐ端末）に、前記ＤＣＩに基づいてＰＤＳＣＨを送信する（Ｓ２８０３）。

【0361】

ここで、ＤＣＩはＰＤＣＣＨで送信されてよい。また、上述したように、本開示で提案する方法がｒｅｄｃａｐ端末のランダムアクセス手続中に適用されるとき、前記ＰＤＳＣＨは、ＭＳＧ２、ＭＳＧ４又はＭＳＧＢを運ぶことができる。ここで、ＭＳＧ２は、４－段階ランダムアクセス手続においてランダムアクセス応答に対するＰＤＣＣＨ、ＰＤＳＣＨを意味でき、ＭＳＧ４は、４－段階ランダムアクセス手続において競合解消のためのＰＤＳＣＨを意味でき、ＭＳＧＢは、２－段階ランダムアクセス手続においてランダムアクセス応答ＵＬグラントによってスケジュールされるＰＵＳＣＨ及び競合解消のためのＰＤＳＣＨを意味できる。

【0362】

ここで、前記ＰＤＳＣＨがＭＳＧ２を運ぶとき、基地局はｒｅｄｃａｐ ＵＥに前記実施例１で提案する方法によってＰＤＳＣＨを送信できる。その後、図２８には図示していないが、基地局はｒｅｄｃａｐ ＵＥから、前記実施例２で提案する方法に基づいてＭＳＧ３を受信することができる。

【0363】

基地局は特定タイプの端末（例えば、ｒｅｄｃａｐ端末）から、前記ＰＤＳＣＨと関連したＨＡＲＱ－ＡＣＫ情報をＰＵＣＣＨで受信する（Ｓ２８０４）。

【0364】

ここで、ｒｅｄｃａｐ ＵＥは、前記実施例３で提案する方法によってＰＵＣＣＨを送信できる。特に、ＰＵＣＣＨ送信のためのＰＲＢインデックスは、上述した実施例３（実施例３の細部実施例のいずれか一つ又は複数の組合せ）によって決定されてよい。

【0365】

例えば、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0366】

ここで、前記ｒｅｄｃａｐ端末に専用ＰＵＣＣＨリソース設定が提供されていない場合（例えば、専用ＰＵＣＣＨリソース設定受信前）に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。

【0367】

また、前記ＰＵＣＣＨの送信に対する周波数ホッピングが非活性（ｄｉｓａｂｌｅｄ）される場合に、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記第２情報に基づいて、前記第１情報によって提供された前記追加のＰＲＢオフセットを用いて決定されてよい。ここで、前記ＰＵＣＣＨの送信に対する周波数ホッピングが活性（ｅｎａｂｌｅｄ）されるか又は非活性（ｄｉｓａｂｌｅｄ）されるかは、前記基地局による設定に基づいて決定されてよい。

【0368】

また、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、セル特定ＰＵＣＣＨリソースのセットを設定するための第３情報によって決定されたＰＲＢオフセットと前記追加のＰＲＢオフセットを用いて決定されてよい。

【0369】

例えば、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの下位エッジ（ｌｏｗｅｒ ｅｄｇｅ）から増加する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが増加し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを正（ｐｏｓｉｔｉｖｅ）の値で適用して決定されてよい。

【0370】

さらに他の例として、前記第２情報が、前記ＰＲＢマッピングにおいてＰＲＢインデックスが前記ｒｅｄｃａｐ端末の初期ＢＷＰの上位エッジ（ｕｐｐｅｒ ｅｄｇｅ）から減少する順序でカウントされることを指示すると、循環シフト（ＣＳ：ｃｙｃｌｉｃ ｓｈｉｆｔ）個数を考慮してＰＵＣＣＨリソースインデックスが増加するにつれてＰＲＢインデックスが減少し得る。この場合、前記ＰＵＣＣＨの送信のためのＰＲＢインデックスは、前記ＰＲＢオフセットと前記追加のＰＲＢオフセットを負（ｎｅｇａｔｉｖｅ）の値で適用して決定されてよい。

【0371】

本開示が適用可能な装置一般
図２９には、本開示の一実施例に係る無線通信装置のブロック構成図を例示する。

【0372】

図２９を参照すると、第１無線機器１００と第２無線機器２００は、様々な無線接続技術（例えば、ＬＴＥ、ＮＲ）を用いて無線信号を送受信することができる。

【0373】

第１無線機器１００は、１つ以上のプロセッサ１０２及び１つ以上のメモリ１０４を含み、さらに、１つ以上の送受信機１０６及び／又は１つ以上のアンテナ１０８を含むことができる。プロセッサ１０２は、メモリ１０４及び／又は送受信機１０６を制御し、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を具現するように構成されてよい。例えば、プロセッサ１０２は、メモリ１０４内の情報を処理して第１情報／信号を生成した後、第１情報／信号を含む無線信号を送受信機１０６から送信してよい。また、プロセッサ１０２は、第２情報／信号を含む無線信号を送受信機１０６から受信した後、第２情報／信号の信号処理から得た情報をメモリ１０４に保存することができる。メモリ１０４は、プロセッサ１０２と連結されてよく、プロセッサ１０２の動作に関連した様々な情報を保存することができる。例えば、メモリ１０４は、プロセッサ１０２によって制御されるプロセスの一部又は全部を行うか、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を実行するための命令を含むソフトウェアコードを保存することができる。ここで、プロセッサ１０２とメモリ１０４は、無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現するように設計された通信モデム／回路／チップの一部であってよい。送受信機１０６は、プロセッサ１０２と連結されてよく、１つ以上のアンテナ１０８を介して無線信号を送信及び／又は受信することができる。送受信機１０６は、送信機及び／又は受信機を含むことができる。送受信機１０６は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニットに言い換えてもよい。本発明において、無線機器は、通信モデム／回路／チップを意味してもよい。

【0374】

第２無線機器２００は、１つ以上のプロセッサ２０２、１つ以上のメモリ２０４を含み、さらに、１つ以上の送受信機２０６及び／又は１つ以上のアンテナ２０８をさらに含むことができる。プロセッサ２０２は、メモリ２０４及び／又は送受信機２０６を制御し、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を具現するように構成されてよい。例えば、プロセッサ２０２は、メモリ２０４内の情報を処理して第３情報／信号を生成した後、送受信機２０６から第３情報／信号を含む無線信号を送信してよい。また、プロセッサ２０２は、第４情報／信号を含む無線信号を送受信機２０６から受信した後、第４情報／信号の信号処理から得た情報をメモリ２０４に保存することができる。メモリ２０４は、プロセッサ２０２と連結されてよく、プロセッサ２０２の動作に関連した様々な情報を保存することができる。例えば、メモリ２０４は、プロセッサ２０２によって制御されるプロセスの一部又は全部を行うか、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を実行するための命令を含むソフトウェアコードを保存することができる。ここで、プロセッサ２０２とメモリ２０４は、無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現するように設計された通信モデム／回路／チップの一部であってよい。送受信機２０６は、プロセッサ２０２と連結されてよく、１つ以上のアンテナ２０８を介して無線信号を送信及び／又は受信することができる。送受信機２０６は、送信機及び／又は受信機を含むことができる。送受信機２０６は、ＲＦユニットに言い換えてもよい。本発明において、無線機器は、通信モデム／回路／チップを意味してもよい。

【0375】

以下、無線機器１００，２００のハードウェア要素についてより具体的に説明する。これに制限されるものではないが、１つ以上のプロトコル層が１つ以上のプロセッサ１０２，２０２によって具現されてよい。例えば、１つ以上のプロセッサ１０２，２０２は、１つ以上の層（例えば、ＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ、ＲＲＣ、ＳＤＡＰのような機能的な層）を具現することができる。１つ以上のプロセッサ１０２，２０２は、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図によって、１つ以上のＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）及び／又は１つ以上のＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を生成することができる。１つ以上のプロセッサ１０２，２０２は、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図によって、メッセージ、制御情報、データ又は情報を生成できる。１つ以上のプロセッサ１０２，２０２は、本開示に開示された機能、手続、提案及び／又は方法によって、ＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ又は情報を含む信号（例えば、ベースバンド信号）を生成し、それを１つ以上の送受信機１０６，２０６に提供できる。１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６から信号（例えば、ベースバンド信号）を受信することができ、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図によって、ＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ又は情報を取得することができる。

【0376】

１つ以上のプロセッサ１０２，２０２は、コントローラ、マイクロコントローラ、マイクロプロセッサ又はマイクロコンピュータと呼ぶことができる。１つ以上のプロセッサ１０２，２０２は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組合せによって具現されてよい。一例として、１つ以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、１つ以上のＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、１つ以上のＤＳＰＤ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅ）、１つ以上のＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）又は１つ以上のＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）が１つ以上のプロセッサ１０２，２０２に含まれてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図は、ファームウェア又はソフトウェアを用いて具現されてよく、ファームウェア又はソフトウェアは、モジュール、手続、機能などを含むように具現されてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を実行するように設定されたファームウェア又はソフトウェアは、１つ以上のプロセッサ１０２，２０２に含まれるか、１つ以上のメモリ１０４，２０４に保存され、１つ以上のプロセッサ１０２，２０２によって駆動されてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図は、コード、命令語及び／又は命令語の集合の形態でファームウェア又はソフトウェアによって具現されてよい。

【0377】

１つ以上のメモリ１０４，２０４は１つ以上のプロセッサ１０２，２０２と連結されてよく、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び／又は命令を保存することができる。１つ以上のメモリ１０４，２０４は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ハードドライブ、レジスター、キャッシュメモリ、コンピュータ可読記憶媒体及び／又はそれらの組合せによって構成されてよい。１つ以上のメモリ１０４，２０４は、１つ以上のプロセッサ１０２，２０２の内部及び／又は外部に位置してよい。また、１つ以上のメモリ１０４，２０４は、有線又は無線連結のような様々な技術によって１つ以上のプロセッサ１０２，２０２と連結されてよい。

【0378】

１つ以上の送受信機１０６，２０６は、１つ以上の他の装置に、本開示の方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを送信できる。１つ以上の送受信機１０６，２０６は、１つ以上の他の装置から、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを受信することができる。例えば、１つ以上の送受信機１０６，２０６は１つ以上のプロセッサ１０２，２０２と連結されてよく、無線信号を送受信できる。例えば、１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６が１つ以上の他の装置にユーザデータ、制御情報又は無線信号を送信するように制御できる。また、１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６が１つ以上の他の装置からユーザデータ、制御情報又は無線信号を受信するように制御できる。また、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８と連結されてよく、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８を介して、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを送受信するように設定されてよい。本開示において、１つ以上のアンテナは複数の物理アンテナであるか、複数の論理アンテナ（例えば、アンテナポート）であってよい。１つ以上の送受信機１０６，２０６は、受信されたユーザデータ、制御情報、無線信号／チャネルなどを１つ以上のプロセッサ１０２，２０２を用いて処理するために、受信された無線信号／チャネルなどをＲＦバンド信号からベースバンド信号に変換（Ｃｏｎｖｅｒｔ）してよい。１つ以上の送受信機１０６，２０６は、１つ以上のプロセッサ１０２，２０２を用いて処理されたユーザデータ、制御情報、無線信号／チャネルなどを、ベースバンド信号からＲＦバンド信号に変換してよい。そのために、１つ以上の送受信機１０６，２０６は（アナログ）オシレーター及び／又はフィルターを含むことができる。

【0379】

以上で説明された実施例は、本開示の構成要素及び特徴が所定の形態で結合したものである。各構成要素又は特徴は、特に明示的言及がない限り、選択的なものとして考慮されるべきである。各構成要素又は特徴は、他の構成要素又は特徴と結合しない形態で実施されてもよい。また、一部の構成要素及び／又は特徴を結合させて本開示の実施例を構成することも可能である。本開示の実施例において説明される動作の順序は変更されてよい。ある実施例の一部の構成又は特徴は他の実施例に含まれてもよく、或いは他の実施例の対応する構成又は特徴に取り替えられてもよい。特許請求の範囲において明示的な引用関係を有しない請求項を結合させて実施例を構成するか、或いは出願後の補正によって新しい請求項として含めることができることは明らかである。

【0380】

本開示は、本開示の必須特徴を外れない範囲で他の特定の形態として具体化できることは当業者に自明である。したがって、上述した詳細な説明はいかなる面においても制限的に解釈されてはならず、例示的なものとして考慮されるべきである。本開示の範囲は、添付する請求項の合理的解釈によって決定されるべきであり、本開示の等価的範囲内における変更はいずれも本開示の範囲に含まれる。

【0381】

本開示の範囲は、様々な実施例の方法による動作を装置又はコンピュータ上で実行させるソフトウェア又はマシン実行可能な命令（例えば、運営体制、アプリケーション、ファームウェア（ｆｉｒｍｗａｒｅ）、プログラムなど）、及びこのようなソフトウェア又は命令などが記憶されて装置又はコンピュータ上で実行可能な非一時的コンピュータ可読媒体（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ－ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を含む。本開示で説明する特徴を実行するプロセシングシステムをプログラミングするために利用可能な命令は、記憶媒体又はコンピュータ可読記憶媒体上に／内に記憶されてよく、このような記憶媒体を含むコンピュータプログラム製品を用いて、本開示に説明の特徴が具現されてよい。記憶媒体は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ又は他のランダムアクセスソリッドステートメモリデバイスのような高速ランダムアクセスメモリを含むことができるが、それに制限されず、１つ以上の磁器ディスク記憶デバイス、光ディスク記憶装置、フラッシュメモリデバイス又は他の非揮発性ソリッドステート記憶デバイスのような非揮発性メモリを含むことができる。メモリは選択的に、プロセッサから遠隔に位置している１つ以上の記憶デバイスを含む。メモリ又は代案としてメモリ内の非揮発性メモリデバイスは、非一時的コンピュータ可読記憶媒体を含む。本開示に説明の特徴は、マシン可読媒体の任意の一つに記憶され、プロセシングシステムのハードウェアを制御でき、プロセシングシステムが本開示の実施例に係る結果を活用する他のメカニズムと相互作用するようにするソフトウェア及び／又はファームウェアに統合されてよい。このようなソフトウェア又はファームウェアは、アプリケーションコード、デバイスドライバー、運営体制及び実行環境／コンテナを含むことができるが、これに制限されない。

【0382】

ここで、本開示の無線機器１００，２００において具現される無線通信技術は、ＬＴＥ、ＮＲ及び６Ｇの他に、低電力通信のための狭帯域モノのインターネット（Ｎａｒｒｏｗｂａｎｄ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ，ＮＢ－ＩｏＴ）も含むことができる。このとき、例えば、ＮＢ－ＩｏＴ技術はＬＰＷＡＮ（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）技術の一例であってよく、ＬＴＥ Ｃａｔ ＮＢ１及び／又はＬＴＥ Ｃａｔ ＮＢ２などの規格によって具現されてよく、上述した名称に限定されるものではない。追加として又は代案として、本開示の無線機器（ＸＸＸ，ＹＹＹ）において具現される無線通信技術は、ＬＴＥ－Ｍ技術に基づいて通信を行うことができる。このとき、一例として、ＬＴＥ－Ｍ技術は、ＬＰＷＡＮ技術の一例であってよく、ｅＭＴＣ（ｅｎｈａｎｃｅｄ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などの様々な名称と呼ばれてよい。例えば、ＬＴＥ－Ｍ技術は、１）ＬＴＥ ＣＡＴ ０、２）ＬＴＥ Ｃａｔ Ｍ１、３）ＬＴＥ Ｃａｔ Ｍ２、４）ＬＴＥ ｎｏｎ－ＢＬ（ｎｏｎ－Ｂａｎｄｗｉｄｔｈ Ｌｉｍｉｔｅｄ）、５）ＬＴＥ－ＭＴＣ、６）ＬＴＥ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ、及び／又は７）ＬＴＥ Ｍなどの様々な規格のうち少なくともいずれか一つによって具現されてよく、上述した名称に限定されるものではない。追加として又は代案として、本開示の無線機器（ＸＸＸ，ＹＹＹ）において具現される無線通信技術は、低電力通信を考慮したジグビー（ＺｉｇＢｅｅ）（登録商標）、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）（登録商標）及び低電力広帯域通信網（Ｌｏｗ Ｐｏｗｅｒ Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ，ＬＰＷＡＮ）のうち少なくともいずれか一つを含むことができ、上述した名称に限定されるものではない。一例として、ＺｉｇＢｅｅ技術は、ＩＥＥＥ ８０２．１５．４などの様々な規格に基づいて小型／低い電力デジタル通信に関連したＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋｓ）を生成することができ、様々な名称と呼ばれてよい。

【産業上の利用可能性】

【0383】

本開示で提案する方法は、３ＧＰＰ ＬＴＥ／ＬＴＥ－Ａ、５Ｇシステムに適用される例を中心に説明したが、３ＧＰＰ ＬＴＥ／ＬＴＥ－Ａ、５Ｇシステムの他にも様々な無線通信システムに適用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】