特許7073520 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ エルジー　エレクトロニクス　インコーポレイティドの特許一覧

特許7073520無線通信システムにおける無線信号の送受信方法及び装置

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

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

(11)【特許番号】

(24)【登録日】2022-05-13

(45)【発行日】2022-05-23

(54)【発明の名称】無線通信システムにおける無線信号の送受信方法及び装置

(51)【国際特許分類】

H04L 27/26 20060101AFI20220516BHJP

H04W 72/04 20090101ALI20220516BHJP

【ＦＩ】

H04L27/26 113

H04W72/04 136

H04W72/04 131

【請求項の数】 15

(21)【出願番号】P 2020549544

(86)(22)【出願日】2019-08-09

(65)【公表番号】

(43)【公表日】2021-02-18

(86)【国際出願番号】 KR2019010172

(87)【国際公開番号】W WO2020032753

(87)【国際公開日】2020-02-13

【審査請求日】2020-06-03

(31)【優先権主張番号】62/716,945

(32)【優先日】2018-08-09

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

(73)【特許権者】

【識別番号】502032105

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

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

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

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木篤

(74)【代理人】

【識別番号】100123582

【弁理士】

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

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合章

(74)【代理人】

【識別番号】100114018

【弁理士】

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

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本実

(72)【発明者】

【氏名】ヤンソクチョル

(72)【発明者】

【氏名】パクハンチュン

【審査官】齊藤晶

(56)【参考文献】

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

【文献】米国特許出願公開第２０１７／０２８９７３３（ＵＳ，Ａ１）

【文献】LG Electronics，Remaining issues on UCI multiplexing[online]，3GPP TSG RAN WG1 Meeting #93 R1-1806623，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_93/Docs/R1-1806623.zip>，2018年05月21日

【文献】Panasonic，Discussion on UCI multiplexing[online]，3GPP TSG RAN WG1 Meeting #93 R1-1806181，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_93/Docs/R1-1806181.zip>，2018年05月21日

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

Ｈ０４Ｌ２７／２６

Ｈ０４Ｗ７２／０４

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

ＳＡＷＧ１－４

ＣＴＷＧ１－４

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

【請求項1】

無線通信システムにおいて通信装置が制御情報を送信する方法であって、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信する段階と、
（ｉ）前記ＰＤＳＣＨと（ｉｉ）複数のＵＬ（uplink）チャネルの最も早いものとの間の時間間隔が基準時間間隔と等しい又はより大きいことに基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化する段階と、を含み、
前記複数のＵＬチャネルは、時間軸上でオーバーラップし、かつ、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、
前記基準時間間隔は、（ａ）シンボルの数と（ｂ）前記複数のＵＬチャネルに対する複数のＳＣＳの最小のＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記複数のＵＬチャネルに関連する前記ＵＣＩは、前記時間間隔が前記基準時間間隔より小さいことに基づいて多重化されない、方法。

【請求項2】

前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する前記複数のＳＣＳのうちの最小のものより大きい、請求項１に記載の方法。

【請求項3】

前記応答情報を含むＵＣＩは、前記時間間隔が前記基準時間間隔と等しい又はより大きいことに基づいて、一つのＵＬチャネルで多重化及び送信され、
前記時間間隔が前記基準時間間隔より小さいことに基づいて、
前記応答情報は、多重化されずに前記第１ＵＬチャネルで送信される、又は、
前記複数のＵＬチャネルの全ての送信は、省略される、請求項１又は２に記載の方法。

【請求項4】

前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項１～３のいずれか一項に記載の方法。

【請求項5】

前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項１～４のいずれか一項に記載の方法。

【請求項6】

ＰＤＣＣＨ（Physical Downlink Control Channel）によりスケジュールされたＰＵＳＣＨ（Physical Uplink Shared Channel）を含む前記複数のＵＬチャネルに基づいて、前記ＵＣＩは、（ｉ）前記ＰＤＣＣＨと（ｉｉ）前記最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔と等しい又はより大きいとき、前記ＰＵＳＣＨにさらに多重化される、請求項１～５のいずれか一項に記載の方法。

【請求項7】

シンボルの長さは、ＳＣＳに基づいて決定され、
前記シンボルの長さ及び前記ＳＣＳは、互いに反比例する、請求項１～６のいずれか一項に記載の方法。

【請求項8】

無線通信システム内の通信装置であって、
メモリと、
プロセッサと、を含み、
前記プロセッサは、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信し、
（ｉ）前記ＰＤＳＣＨと（ｉｉ）複数のＵＬ（uplink）チャネルの最も早いものとの間の時間間隔が基準時間間隔と等しい又はより大きいことに基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化するように構成され、
前記複数のＵＬチャネルは、時間軸上でオーバーラップし、かつ、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、
前記基準時間間隔は、（ａ）シンボルの数と（ｂ）前記複数のＵＬチャネルに対する複数のＳＣＳの最小のＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記複数のＵＬチャネルに関連する前記ＵＣＩは、前記時間間隔が前記基準時間間隔より小さいことに基づいて多重化されない、通信装置。

【請求項9】

前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する前記複数のＳＣＳのうちの最小のものより大きい、請求項８に記載の通信装置。

【請求項10】

【請求項11】

前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項８～１０のいずれか一項に記載の通信装置。

【請求項12】

前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項８～１１のいずれか一項に記載の通信装置。

【請求項13】

【請求項14】

シンボルの長さは、ＳＣＳに基づいて決定され、
前記シンボルの長さ及び前記ＳＣＳは、互いに反比例する、請求項８～１３のいずれか一項に記載の通信装置。

【請求項15】

前記通信装置は、自律走行車両の一部として含まれる、請求項８に記載の通信装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は無線通信システムに関し、より具体的には無線信号の送受信方法及び装置に関する。

【背景技術】

【0002】

無線通信システムが音声やデータなどの種々の通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは利用可能なシステムリソース（帯域幅、伝送パワーなど）を共有して多重使用者との通信を支援することができる多元接続（ｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システムである。多元接続システムの例としては、ＣＤＭＡ（ｃｏｄｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＴＤＭＡ（ｔｉｍｅｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システム、ＳＣ－ＦＤＭＡ（ｓｉｎｇｌｅｃａｒｒｉｅｒｆｒｅｑｕｅｎｃｙｄｉｖｉｓｉｏｎｍｕｌｔｉｐｌｅａｃｃｅｓｓ）システムなどがある。

【発明の概要】

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

【0003】

本発明の目的は、無線信号の送受信過程を効率的に行う方法及びそのための装置を提供することにある。

【0004】

本発明で達成しようとする技術的課題は前記技術的課題に制限されず、言及しなかった他の技術的課題は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。

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

【0005】

本発明の一様相において、無線通信システムにおいて通信装置が制御情報を送信する方法であって、ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）を受信する段階と、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Ｕｐｌｉｎｋ）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定する段階であって、複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む、段階と、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のＵＬチャネルに関連するＵＣＩ（ＵｐｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を多重化する段階と、を含み、基準時間間隔はシンボルの数とＳＣＳ（ＳｕｂｃａｒｒｉｅｒＣａｒｒｉｅｒＳｐａｃｉｎｇ）とに基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む方法が提供される。

【0006】

本発明の他の様相において、無線通信システムに使用される通信装置であって、メモリとプロセッサとを含み、該プロセッサは、ＰＤＳＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）を受信し、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Ｕｐｌｉｎｋ）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定し、複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のＵＬチャネルに関連するＵＣＩ（ＵｐｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を多重化するように構成され、基準時間間隔はシンボルの数とＳＣＳ（ＳｕｂｃａｒｒｉｅｒＣａｒｒｉｅｒＳｐａｃｉｎｇ）に基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む通信装置が提供される。

【0007】

好ましくは、最も早いＵＬチャネルのＳＣＳは、複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい。

【0008】

好ましくは、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きい場合、応答情報を含むＵＣＩは一つのＵＬチャネルに多重化されて送信され、時間間隔が基準時間間隔より小さい場合、応答情報は多重化されず第１ＵＬチャネルを介して送信される、又は、複数のＵＬチャネル送信は全て省略される。

【0009】

好ましくは、時間間隔は、（ｉ）ＰＤＳＣＨの最後のシンボルと、（ｉｉ）最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される。

【0010】

好ましくは、複数のＵＬチャネルはＰＵＣＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）を含む。

【0011】

好ましくは、複数のＵＬチャネルがＰＤＣＣＨ（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ）によりスケジュールされたＰＵＳＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）を含む場合、（ｉ）ＰＤＣＣＨと（ｉｉ）最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔を満たすか否かをさらに確認することを含む。

【0012】

好ましくは、シンボルの長さはＳＣＳに基づいて決定され、シンボルの長さとＳＣＳは反比例する。

【0013】

好ましくは、通信装置は少なくとも端末、ネットワーク及び通信装置以外の他の自律走行車両と通信可能な自律走行車両を含む。

【0014】

好ましくは、さらに通信装置はＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）ユニットを含む。

【発明の効果】

【0015】

本発明によれば、無線通信システムにおいて無線信号の送受信を効率的に行うことができる。

【0016】

本発明で得られる効果は以上で言及した効果に制限されず、言及しなかった他の効果は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。

【図面の簡単な説明】

【0017】

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

【0018】

【図1】無線通信システムの一例である３ＧＰＰシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。

【図2】無線フレームの構造を例示する図である。

【図3】スロットのリソースグリッドを例示する図である。

【図4】ＡＣＫ／ＮＡＣＫ送信過程を例示する図である。

【図5】ＰＵＳＣＨ（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）送信過程を例示する図である。

【図6】制御情報をＰＵＳＣＨに多重化する例を示す図である。

【図7】本発明による信号送信を例示する図である。

【図8】本発明による信号送信を例示する図である。

【図9】本発明による信号送信を例示する図である。

【図10】本発明による信号送信を例示する図である。

【図11】本発明による信号送信を例示する図である。

【図12】本発明による信号送信を例示する図である。

【図13】本発明による信号送信を例示する図である。

【図14】本発明による信号送信を例示する図である。

【図15】本発明による信号送信を例示する図である。

【図16】本発明に適用可能な通信システム及び無線機器を例示する図である。

【図17】本発明に適用可能な通信システム及び無線機器を例示する図である。

【図18】本発明に適用可能な通信システム及び無線機器を例示する図である。

【図19】本発明に適用可能な通信システム及び無線機器を例示する図である。

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

【0019】

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

【0020】

より多い通信機器がより大きい通信容量を要求することにより、既存の無線アクセス技術（ｒａｄｉｏＡｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ、ＲＡＴ）に比べて向上した無線広帯域（ｍｏｂｉｌｅｂｒｏａｄｂａｎｄ、ｅＭＢＢ）通信に対する必要性が台頭しつつある。また、複数の機器及びモノを連結していつでもどこでも様々なサービスを提供する大規模ＭＴＣ（ｍａｓｓｉｖｅＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ）が次世代通信において考慮すべき重要なイッシュの一つである。のみならず、信頼度（ｒｅｌｉａｂｉｌｉｔｙ）及びレイテンシ（ｌａｔｅｎｃｙ）に敏感なサービス／ＵＥを考慮したＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎ）が論議されている。このようにｅＭＢＢ（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄＢａｎｄＣｏｍｍｕｎｉｃａｔｉｏｎ）、大規模ＭＴＣ、ＵＲＬＬＣ（Ｕｌｔｒａ－ＲｅｌｉａｂｌｅａｎｄＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎ）などを考慮した次世代ＲＡＴの導入が論議されており、本発明では、便宜上、該当技術をＮＲ（Ｎｅｗｒａｄｉｏ又はＮｅｗＲＡＴ）と呼ぶ。

【0021】

説明を明確にするために、３ＧＰＰＮＲを主として説明するが、本発明の技術的思想はこれに限られない。

【0022】

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

【0023】

図１は３ＧＰＰＮＲシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。

【0024】

電源Ｏｆｆ状態で電源を入れたか或いは新しくセルに進入した端末は、段階Ｓ１０１において、基地局と同期を確立するなどの初期セルサーチ（Ｉｎｉｔｉａｌｃｅｌｌｓｅａｒｃｈ）作業を行う。このために、端末は基地局から主同期チャネル（ＰｒｉｍａｒｙＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＣｈａｎｎｅｌ、Ｐ－ＳＣＨ）及び副同期チャネル（ＳｅｃｏｎｄａｒｙＳｙｎｃｈｒｏｎｉｚａｔｉｏｎＣｈａｎｎｅｌ、Ｓ－ＳＣＨ）を受信して基地局と同期を確立し、セルＩＤ（ｃｅｌｌｉｄｅｎｔｉｔｙ）などの情報を得る。その後、端末は基地局から物理ブロードキャストチャネル（ＰｈｙｓｉｃａｌＢｒｏａｄｃａｓｔＣｈａｎｎｅｌ、ＰＢＣＨ）を受信してセル内のブロードキャスト情報を得る。なお、端末は初期セルサーチの段階において、下りリンク参照信号（ＤｏｗｎｌｉｎｋＲｅｆｅｒｅｎｃｅＳｉｇｎａｌ、ＤＬＲＳ）を受信して下りリンクチャネルの状態を確認できる。

【0025】

初期セルサーチが終了した端末は、段階Ｓ１０２において、物理下りリンク制御チャネル（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ、ＰＤＣＣＨ）及び物理下りリンク制御チャネルの情報に基づく物理下りリンク共有チャネル（ＰｈｙｓｉｃａｌＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ、ＰＤＳＣＨ）を受信して、より具体的なシステム情報を得る。

【0026】

以後、端末は基地局に接続を完了するために、段階Ｓ１０３乃至段階Ｓ１０６のようなランダムアクセス過程（ＲａｎｄｏｍＡｃｃｅｓｓＰｒｏｃｅｄｕｒｅ）を行う。このために端末は、物理ランダムアクセスチャネル（ＰｈｙｓｉｃａｌＲａｎｄｏｍＡｃｃｅｓｓＣｈａｎｎｅｌ、ＰＲＡＣＨ）を介してプリアンブル（ｐｒｅａｍｂｌｅ）を伝送し（Ｓ１０３）、物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルを介してプリアンブルに対する応答メッセージを受信する（Ｓ１０４）。コンテンションベースのランダムアクセス（Ｃｏｎｔｅｎｔｉｏｎｂａｓｅｄｒａｎｄｏｍａｃｃｅｓｓ）の場合、さらなる物理ランダムアクセスチャネルの伝送（Ｓ１０５）、物理下りリンク制御チャネル及びそれに対応する物理下りリンク共有チャネルの受信（Ｓ１０６）のような競合解決手順（ＣｏｎｔｅｎｔｉｏｎＲｅｓｏｌｕｔｉｏｎＰｒｏｃｅｄｕｒｅ）を行う。

【0027】

このような手順を行った端末は、その後一般的な上り／下りリンク信号の伝送手順として物理下りリンク制御チャネル／物理下りリンク共有チャネルの受信（Ｓ１０７）、及び物理上りリンク共有チャネル（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ、ＰＵＳＣＨ）／物理上りリンク制御チャネル（ＰｈｙｓｉｃａｌＵｐｌｉｎｋＣｏｎｔｒｏｌＣｈａｎｎｅｌ、ＰＵＣＣＨ）の伝送を行う（Ｓ１０８）。端末が基地局に伝送する制御情報を併せて上りリンク制御情報（ＵｐｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）と称する。ＵＣＩは、ＨＡＲＱＡＣＫ／ＮＡＣＫ（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔａｎｄｒｅＱｕｅｓｔＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ－ＡＣＫ）、ＳＲ（ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔ）、ＣＳＩ（ＣｈａｎｎｅｌＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ）などを含む。ＣＳＩは、ＣＱＩ（ＣｈａｎｎｅｌＱｕａｌｉｔｙＩｎｄｉｃａｔｏｒ）、ＰＭＩ（ＰｒｅｃｏｄｉｎｇＭａｔｒｉｘＩｎｄｉｃａｔｏｒ）、ＲＩ（ＲａｎｋＩｎｄｉｃａｔｉｏｎ）などを含む。ＵＣＩは一般的にＰＵＣＣＨを介して伝送されるが、制御情報とトラフィックデータが同時に伝送される必要がある場合にはＰＵＳＣＨを介して伝送される。また、ネットワークの要求／指示によってＰＵＳＣＨを介してＵＣＩを非周期的に伝送することができる。

【0028】

図２は無線フレームの構造を例示する図である。ＮＲにおいて、上りリンク及び下りリンク送信はフレームで構成される。無線フレームは１０ｍｓの長さを有し、２個の５ｍｓハーフフレーム（Ｈａｌｆ－Ｆｒａｍｅ、ＨＦ）で定義される。ハーフフレームは５個の１ｍｓサブフレーム（Ｓｕｂｆｒａｍｅ、ＳＦ）で定義される。サブフレームは１つ以上のスロットに分割され、サブフレーム内のスロット数はＳＣＳ（ＳｕｂｃａｒｒｉｅｒＳｐａｃｉｎｇ）に依存する。各スロットはＣＰ（ｃｙｃｌｉｃｐｒｅｆｉｘ）によって１２個又は１４個のＯＦＤＭ（Ａ）シンボルを含む。一般ＣＰが使用される場合、各スロットは１４個のシンボルを含む。拡張ＣＰが使用される場合は、各スロットは１２個のシンボルを含む。

【0029】

表１は一般ＣＰが使用される場合、ＳＣＳによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。

【0030】

【表1】

【0031】

＊Ｎ^slot _symb：スロット内のシンボル数

【0032】

＊Ｎ^frame,u _slot：フレーム内のスロット数

【0033】

＊Ｎ^subframe,u _slot：サブフレーム内のスロット数

【0034】

表２は拡張ＣＰが使用される場合、ＳＣＳによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。

【0035】

【表2】

【0036】

フレーム構造は例示に過ぎず、フレームにおいてサブフレーム数、スロット数及びシンボル数は様々に変更できる。

【0037】

ＮＲシステムでは１つの端末に併合される複数のセル間でＯＦＤＭニューマロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ）が異なるように設定されることができる。これにより、同じ数のシンボルで構成された時間リソース（例えば、ＳＦ、スロット又はＴＴＩ）（便宜上、ＴＵ（ＴｉｍｅＵｎｉｔ）と称する）の（絶対時間）区間が併合されたセル間で異なるように設定されることができる。ここで、シンボルはＯＦＤＭシンボル（或いはＣＰ－ＯＦＤＭシンボル）、ＳＣ－ＦＤＭＡシンボル（或いはＤｉｓｃｒｅｔｅＦｏｕｒｉｅｒＴｒａｎｓｆｏｒｍ－ｓｐｒｅａｄ－ＯＦＤＭ、ＤＦＴ－ｓ－ＯＦＤＭシンボル）を含む。

【0038】

図３はスロットのリソースグリッド（ｒｅｓｏｕｒｃｅｇｒｉｄ）を例示する図である。スロットは時間ドメインで複数のシンボルを含む。例えば、一般ＣＰの場合、１つのスロットが１４個のシンボルを含むが、拡張ＣＰの場合は、１つのスロットが１２個のシンボルを含む。搬送波は周波数ドメインで複数の副搬送波を含む。ＲＢ（ＲｅｓｏｕｒｃｅＢｌｏｃｋ）は周波数ドメインで複数（例えば、１２）の連続する副搬送波で定義される。ＢＷＰは周波数ドメインで複数の連続するＰＲＢ（ＰｈｙｓｉｃａｌＲＢ）で定義され、１つのニューマロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ、ＣＰの長さなど）に対応することができる。搬送波は最大Ｎ個（例えば、５個）のＢＷＰを含む。データ通信は活性化されたＢＷＰで行われ、１つの端末には１つのＢＷＰのみが活性化される。リソースグリッドにおいて各々の要素はリソースエレメント（ＲｅｓｏｕｒｃｅＥｌｅｍｅｎｔ、ＲＥ）と称され、１つの複素シンボルがマッピングされることができる。

【0039】

以下、各々の物理チャネルについてより詳しく説明する。

【0040】

ＰＤＣＣＨはＤＣＩ（ＤｏｗｎｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を運ぶ。例えば、ＰＣＣＣＨ（即ち、ＤＣＩ）はＤＬ－ＳＣＨ（ｄｏｗｎｌｉｎｋｓｈａｒｅｄｃｈａｎｎｅｌ）の送信フォーマット及びリソースの割り当て、ＵＬ－ＳＣＨ（ｕｐｌｉｎｋｓｈａｒｅｄｃｈａｎｎｅｌ）に対するリソース割り当て情報、ＰＣＨ（ＰａｇｉｎｇＣｈａｎｎｅｌ）に関するページング情報、ＤＬ－ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答のような上位層制御メッセージに関するリソース割り当て情報、送信電力制御命令、ＣＳ（Ｃｏｎｆｉｇｕｒｅｄｓｃｈｅｄｕｌｉｎｇ）の活性化／解除などを運ぶ。ＤＣＩはＣＲＣ（ｃｙｃｌｉｃｒｅｄｕｎｄａｎｃｙｃｈｅｃｋ）を含み、ＣＲＣはＰＤＣＣＨの所有者又は使用用途によって様々な識別子（例えば、ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ、ＲＮＴＩ）にマスキング／スクランブルされる。例えば、ＰＤＣＣＨが特定の端末のためのものであれば、ＣＲＣは端末識別子（例えば、ｃｅｌｌ－ＲＮＴＩ、Ｃ－ＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがページングに関するものであれば、ＣＲＣはＰ－ＲＮＴＩ（Ｐａｇｉｎｇ－ＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがシステム情報（例えば、ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ、ＳＩＢ）に関するものであれば、ＣＲＣはＳＩ－ＲＮＴＩ（ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがランダムアクセス応答に関するものであれば、ＣＲＣはＲＡ－ＲＮＴＩ（ＲａｎｄｏｍＡｃｃｅｓｓ－ＲＮＴＩ）にマスキングされる。

【0041】

ＰＤＳＣＨは下りリンクデータ（例、ＤＬ－ＳＣＨｔｒａｎｓｐｏｒｔｂｌｏｃｋ、ＤＬ－ＳＣＨＴＢ）を運び、ＱＰＳＫ（ＱｕａｄｒａｔｕｒｅＰｈａｓｅＳｈｉｆｔＫｅｙｉｎｇ）、１６ＱＡＭ（ＱｕａｄｒａｔｕｒｅＡｍｐｌｉｔｕｄｅＭｏｄｕｌａｔｉｏｎ）、６４ＱＡＭ、２５６ＱＡＭなどの変調方法が適用される。ＴＢを符号化してコードワード（ｃｏｄｅｗｏｒｄ）が生成される。ＰＤＳＣＨは最大２個のコードワードを運ぶ。コードワードごとにスクランブル及び変調マッピングが行われ、各コードワードから生成された変調シンボルは１つ以上のレイヤにマッピングされる。各レイヤはＤＭＲＳ（ＤｅｍｏｄｕｌａｔｉｏｎＲｅｆｅｒｅｎｃｅＳｉｇｎａｌ）と共にリソースにマッピングされてＯＦＤＭシンボル信号に生成され、該当アンテナポートにより送信される。

【0042】

ＰＵＣＣＨは、ＵＣＩ（ＵｐｌｉｎｋＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を運ぶ。ＵＣＩは以下を含む。

【0043】

－ＳＲ（ＳｃｈｅｄｕｌｉｎｇＲｅｑｕｅｓｔ）：ＵＬ－ＳＣＨリソースを要求するために使用される情報である。

【0044】

－ＨＡＲＱ－ＡＣＫ：ＰＤＳＣＨ上の下りリンクデータパケット（例えば、コードワード）に対する応答である。下りリンクデータパケットが正常に受信されたか否かを示す。単一のコードワードに対する応答としてＨＡＲＱ－ＡＣＫ１ビットが送信され、２個のコードワードに対する応答としてＨＡＲＱ－ＡＣＫ２ビットが送信される。ＨＡＲＱ－ＡＣＫ応答は、ポジティブＡＣＫ（簡単に、ＡＣＫ）、ネガティブＡＣＫ（以下、ＮＡＣＫ）、ＤＴＸ（ＤｉｓｃｏｎｔｉｎｕｏｕｓＴｒａｎｓｍｉｓｓｉｏｎ）又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ－ＡＣＫという用語は、ＨＡＲＱＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと同じ意味で使われる。

【0045】

－ＣＳＩ（ＣｈａｎｎｅｌＳｔａｔｅＩｎｆｏｒｍａｔｉｏｎ）：下りリンクチャンネルに対するフィードバック情報である。ＭＩＭＯ（ＭｕｌｔｉｐｌｅＩｎｐｕｔＭｕｌｔｉｐｌｅＯｕｔｐｕｔ）－関連フィードバック情報は、ＲＩ（ＲａｎｋＩｎｄｉｃａｔｏｒ）及びＰＭＩ（ＰｒｅｃｏｄｉｎｇＭａｔｒｉｘＩｎｄｉｃａｔｏｒ）を含む。

【0046】

表３はＰＵＣＣＨフォーマットを例示する。ＰＵＣＣＨ送信の長さによってＳｈｏｒｔＰＵＣＣＨ（フォーマット０，２）及びＬｏｎｇＰＵＣＣＨ（フォーマット１，３，４）に区分できる。

【0047】

【表3】

【0048】

ＰＵＣＣＨフォーマット０は最大２ビットサイズのＵＣＩを運び、シーケンスに基づいてマッピングされて送信される。具体的には、端末は複数のシーケンスのうちの１つのシーケンスをＰＵＣＣＨフォーマット０であるＰＵＣＣＨを介して送信して特定のＵＣＩを基地局に送信する。端末は肯定（ｐｏｓｉｔｉｖｅ）のＳＲを送信する場合のみに対応するＳＲ設定のためのＰＵＣＣＨリソース内でＰＵＣＣＨフォーマット０であるＰＵＣＣＨを送信する。

【0049】

ＰＵＣＣＨフォーマット１は最大２ビットサイズのＵＣＩを運び、変調シンボルは時間領域で（周波数ホッピング有無によって異なるように設定される）直交カバーコード（ＯＣＣ）により拡散される。ＤＭＲＳは変調シンボルが送信されないシンボルで送信される（即ち、ＴＤＭ（ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）されて送信される）。

【0050】

ＰＵＣＣＨフォーマット２は２ビットより大きいビットサイズのＵＣＩを運び、変調シンボルはＤＭＲＳとＦＤＭ（ＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。ＤＭ－ＲＳは１／３の密度のリソースブロック内のシンボルインデックス＃１、＃４、＃７及び＃１０に位置する。ＰＮ（ＰｓｅｕｄｏＮｏｉｓｅ）シーケンスがＤＭ＿ＲＳシーケンスのために使用される。２シンボルＰＵＣＣＨフォーマット２のために周波数ホッピングが活性化されることができる。

【0051】

ＰＵＣＣＨフォーマット３は同一の物理リソースブロック内において端末多重化が行われず、２ビットより大きいビットサイズのＵＣＩを運ぶ。即ち、ＰＵＣＣＨフォーマット３のＰＵＣＣＨリソースは直交カバーコードを含まない。変調シンボルはＤＭＲＳとＴＤＭ（ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。

【0052】

ＰＵＣＣＨフォーマット４は同一の物理リソースブロック内に最大４個の端末まで多重化が支援され、２ビットより大きいビットサイズのＵＣＩを運ぶ。即ち、ＰＵＣＣＨフォーマット３のＰＵＣＣＨリソースは直交カバーコードを含む。変調シンボルはＤＭＲＳとＴＤＭ（ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。

【0053】

ＰＵＳＣＨは上りリンクデータ（例えば、ＵＬ－ＳＣＨｔｒａｎｓｐｏｒｔｂｌｏｃｋ、ＵＬ－ＳＣＨＴＢ）及び／又は上りリンク制御情報（ＵＣＩ）を運び、ＣＰ－ＯＦＤＭ（ＣｙｃｌｉｃＰｒｅｆｉｘ－ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）波形又はＤＦＴ－ｓ－ＯＦＤＭ（ＤｉｓｃｒｅｔｅＦｏｕｒｉｅｒＴｒａｎｓｆｏｒｍ－ｓｐｒｅａｄ－ＯｒｔｈｏｇｏｎａｌＦｒｅｑｕｅｎｃｙＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）波形に基づいて送信される。ＰＵＳＣＨがＤＦＴ－ｓ－ＯＦＤＭ波形に基づいて送信される場合、端末は変換プリコーディング（ｔｒａｎｓｆｏｒｍｐｒｅｃｏｄｉｎｇ）を適用してＰＵＳＣＨを送信する。一例として、変換プリコーディングが不可能な場合は（例えば、ｔｒａｎｓｆｏｒｍｐｒｅｃｏｄｉｎｇｉｓｄｉｓａｂｌｅｄ）、端末はＣＰ－ＯＦＤＭ波形に基づいてＰＵＳＣＨを送信し、変換プリコーディングが可能な場合には（例えば、ｔｒａｎｓｆｏｒｍｐｒｅｃｏｄｉｎｇｉｓｅｎａｂｌｅｄ）、端末はＣＰ－ＯＦＤＭ波形又はＤＦＴ－ｓ－ＯＦＤＭ波形に基づいてＰＵＳＣＨを送信する。ＰＵＳＣＨ送信はＤＣＩ内のＵＬグラントにより動的にスケジュールされるか、又は上位層（例えば、ＲＲＣ）シグナリング（及び／又はＬａｙｅｒ１（Ｌ１）シグナリング（例えば、ＰＤＣＣＨ））に基づいて準静的（ｓｅｍｉ－ｓｔａｔｉｃ）にスケジュールされる（ｃｏｎｆｉｇｕｒｅｄｇｒａｎｔ）。ＰＵＳＣＨ送信はコードブックベース又は非コードブックベースで行われる。

【0054】

図４はＡＣＫ／ＮＡＣＫ送信過程を例示する。図４を参照すると、端末はスロット＃ｎでＰＤＣＣＨを検出する。ここで、ＰＤＣＣＨは下りリンクスケジューリング情報（例えば、ＤＣＩフォーマット１＿０、１＿１）を含み、ＰＤＣＣＨはＤＬ割り当て－ｔｏ－ＰＤＳＣＨオフセット（Ｋ０）とＰＤＳＣＨ－ＨＡＲＱ－ＡＣＫ報告オフセット（Ｋ１）を示す。例えば、ＤＣＩフォーマット１＿０、１＿１は以下の情報を含む。

【0055】

－Ｆｒｅｑｕｅｎｃｙｄｏｍａｉｎｒｅｓｏｕｒｃｅａｓｓｉｇｎｍｅｎｔ：ＰＤＳＣＨに割り当てられたＲＢセットを示す。

【0056】

－Ｔｉｍｅｄｏｍａｉｎｒｅｓｏｕｒｃｅａｓｓｉｇｎｍｅｎｔ：Ｋ０、スロット内のＰＤＳＣＨの開始位置（例えば、ＯＦＤＭシンボルインデックス）及び長さ（例：ＯＦＤＭシンボル数）を示す

【0057】

－ＰＤＳＣＨ－ｔｏ－ＨＡＲＱ＿ｆｅｅｄｂａｃｋｔｉｍｉｎｇｉｎｄｉｃａｔｏｒ：Ｋ１を示す

【0058】

今後、端末はスロット＃ｎのスケジューリング情報によってスロット＃（ｎ＋Ｋ０）でＰＤＳＣＨを受信した後、スロット＃（ｎ＋Ｋ１）でＰＵＣＣＨを介してＵＣＩを送信する。ここで、ＵＣＩはＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫ応答を含む。ＰＤＳＣＨが最大１個のＴＢを送信するように構成された場合、ＨＡＲＱ－ＡＣＫ応答は１ビットで構成される。ＰＤＳＣＨが最大２個のＴＢを送信するように構成された場合は、ＨＡＲＱ－ＡＣＫ応答は空間（ｓｐａｔｉａｌ）バンドリングが構成されていない場合は、２ビットで構成され、空間バンドリングが構成された場合は、１ビットで構成される。複数のＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫ送信時点がスロット＃（ｎ＋Ｋ１）と指定された場合、スロット＃（ｎ＋Ｋ１）で送信されるＵＣＩは複数のＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫ応答を含む。

【0059】

図５はＰＵＳＣＨ送信過程を例示する。図５を参照すると、端末はスロット＃ｎでＰＤＣＣＨを検出する。ここで、ＰＤＣＣＨは上りリンクスケジューリング情報（例えば、ＤＣＩフォーマット０＿０、０＿１）を含む。ＤＣＩフォーマット０＿０、０＿１は以下の情報を含む。

【0060】

－Ｆｒｅｑｕｅｎｃｙｄｏｍａｉｎｒｅｓｏｕｒｃｅａｓｓｉｇｎｍｅｎｔ：ＰＵＳＣＨに割り当てられたＲＢセットを示す。

【0061】

－Ｔｉｍｅｄｏｍａｉｎｒｅｓｏｕｒｃｅａｓｓｉｇｎｍｅｎｔ：スロットオフセットＫ２、スロット内のＰＵＳＣＨの開始位置（例えば、シンボルインデックス）及び長さ（例：ＯＦＤＭシンボル数）を示す。開始シンボル及び長さはＳＬＩＶ（ＳｔａｒｔａｎｄＬｅｎｇｔｈＩｎｄｉｃａｔｏｒＶａｌｕｅ）により指示されるか、又は各々指示される。

【0062】

以後、端末はスロット＃ｎのスケジューリング情報によってスロット＃（ｎ＋Ｋ２）でＰＵＳＣＨを送信する。ここで、ＰＵＳＣＨはＵＬ－ＳＣＨＴＢを含む。

【0063】

図６はＵＳＩをＰＵＳＣＨに多重化する例を示す。スロット内で複数のＰＵＣＣＨリソースとＰＵＳＣＨリソースが重畳し、ＰＵＣＣＨ－ＰＵＳＣＨ同時送信が設定されていない場合、ＵＣＩは、図示したように、ＰＵＳＣＨを介して送信される（ＵＣＩピギーバック又はＰＵＳＣＨピギーバック）。図６はＨＡＲＱ－ＡＣＫとＣＳＩがＰＵＳＣＨリソースに含まれる場合を例示する。

【0064】

実施例：ＵＬチャネルの多重化

【0065】

ＮＲシステムでは、単一の物理ネットワーク上に複数の論理ネットワークを具現化する方法が考えられている。ここで、論理ネットワークは様々な要求条件を有するサービス（例えば、ｅＭＢＢ、ｍＭＴＣ、ＵＲＬＬＣなど）を支援する必要がある。従って、ＮＲの物理層は様々なサービスに対する要求条件を考えて柔軟な送信構造を支援するように設計されている。一例として、ＮＲの物理層は必要によってＯＦＤＭシンボルの長さ（ＯＦＤＭシンボル区間）及び副搬送波間隔（ＳＣＳ）（以下、ＯＦＤＭニューマロロジー）を変更することができる。また物理チャネルの送信リソースも（シンボル単位で）一定範囲内で変更可能である。例えば、ＮＲにおいて、ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）は送信の長さ／送信開始時点が一定範囲内で柔軟に設定される。

【0066】

一方、基地局と端末で構成された無線通信システムにおいて、端末がＵＣＩをＰＵＣＣＨを介して送信するとき、ＰＵＣＣＨリソースが時間軸で他のＰＵＣＣＨリソース或いはＰＵＳＣＨリソースと重畳することができる。例えば、同じ端末の観点で（同じスロット内で）、（１）（互いに異なるＵＣＩ送信のための）ＰＵＣＣＨ（リソース）とＰＵＣＣＨ（リソース）、或いは（２）ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）が時間軸で重畳することができる。一方、端末は（端末能力の制限、又は基地局からの設定情報によって）ＰＵＣＣＨ－ＰＵＣＣＨ同時送信或いはＰＵＣＣＨ－ＰＵＳＣＨ同時送信を支援しないことができる。この場合、端末は、（１）互いに異なるＵＣＩ、或いは（２）ＵＣＩとＵＬデータを最大限多重化して送信することが好ましい。しかし、ＮＲシステムでは、（スロット内の）時間軸で重畳した（１）ＰＵＣＣＨ（リソース）とＰＵＣＣＨ（リソース）、或いは（２）ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）の間に送信の長さ（例えば、シンボル数）及び／又は送信開始時点（例えば、開始シンボル）が異なることができる。従って、端末の処理時間の観点で、端末が（１）互いに異なるＵＣＩ、或いは（２）ＵＣＩとＵＬデータを多重化して送信することが難しい場合がある。例えば、Ａ／Ｎを送信するＰＵＣＣＨ（以下、Ａ／ＮＰＵＣＣＨ）とＳＲを送信するＰＵＣＣＨ（以下、ＳＲＰＵＣＣＨ）が時間軸で（一部或いは全部）重畳することができる。この場合、端末がＳＲＰＵＣＣＨに対する送信を既に開始したか又は送信準備を完了した後、ＳＲＰＵＣＣＨと重畳するＡ／ＮＰＵＣＣＨの存在を認知すると、端末はＡ／ＮＰＵＣＣＨ内のＡ／ＮをＳＲと多重化して送信することが難しい。

【0067】

既存のＮＲシステムでは、Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で完全に重畳した場合（即ち、送信区間が一致）、Ａ／ＮＰＵＣＣＨのＰＵＣＣＨフォーマットによって以下のようにＵＣＩ多重化規定を適用する。ＰｏｓｉｔｉｖｅＳＲは端末が送信するＵＬデータがあることを意味し、ｎｅｇａｔｉｖｅＳＲは端末が送信するＵＬデータがないことを意味する。

【0068】

（１）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0069】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0070】

－Ａ／ＮをＡ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信

【0071】

Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0072】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0073】

（２）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0074】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0075】

－Ａ／ＮをＳＲＰＵＣＣＨリソースを介して送信

【0076】

Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0077】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0078】

（３）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの１つである場合

【0079】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲ又はｎｅｇａｔｉｖｅＳＲである場合

【0080】

－ＳＲを明示的ビットで表現してＡ／Ｎに付け加えて（Ａｐｐｅｎｄｉｎｇ）ＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／ＮＰＵＣＣＨリソースを介して送信

【0081】

しかし、既存の方法では、Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で完全に重畳する場合に限ってＵＣＩ多重化方法を定義している。よって、効率的なＵＣＩ送信のために、様々な状況を考えてＵＣＩ多重化方法を論議する必要がある。

【0082】

上記問題を解決するために、本発明では時間軸で重畳したＵＬチャネルに対するＵＣＩ及び／又はデータを多重化する動作を提案する。具体的には、本発明ではＵＬチャネルの送信開始時点及び／又は端末の処理時間を考えてＵＬチャネルに対するＵＣＩ及び／又はデータを多重化する動作を提案する。

【0083】

まず、以下のように用語を定義する。

【0084】

－ＵＣＩ：端末がＵＬ送信する制御情報を意味する。ＵＣＩは複数のタイプの制御情報（即ち、ＵＣＩタイプ）を含む。例えば、ＵＣＩはＨＡＲＱ－ＡＣＫ（簡単に、Ａ／Ｎ、ＡＮ）、ＳＲ、ＣＳＩを含む。

【0085】

－ＰＵＣＣＨ：ＵＣＩ送信のための物理層ＵＬチャネルを意味する。便宜上、Ａ／Ｎ、ＳＲ、ＣＳＩ送信のために、基地局が設定した及び／又は送信を指示したＰＵＣＣＨリソースを各々Ａ／ＮＰＵＣＣＨリソース、ＳＲＰＵＣＣＨリソース、ＣＳＩＰＵＣＣＨリソースと呼ぶ。

【0086】

－ＰＵＳＣＨ：ＵＬデータ送信のための物理層ＵＬチャネルを意味する。

【0087】

－ＵＣＩ多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）：互いに異なるＵＣＩ（タイプ）を共通の物理層ＵＬチャネル（例えば、ＰＵＣＣＨ、ＰＵＳＣＨ）を介して送信する動作を意味する。ＵＣＩ多重化は、互いに異なるＵＣＩ（タイプ）を多重化する動作を含む。便宜上、多重化されたＵＣＩをＭＵＸＵＣＩと称する。またＵＣＩ多重化はＭＵＸＵＣＩに関連して行われる動作を含む。例えば、ＵＣＩ多重化はＭＵＸＵＣＩを送信するためにＵＬチャネルリソースを決定する過程を含む。

【0088】

－ＵＣＩ／データ多重化：ＵＣＩとデータを共通の物理層ＵＬチャネル（例えば、ＰＵＳＣＨ）により送信する動作を意味する。ＵＣＩ／データ多重化はＵＣＩとデータを多重化する動作を含む。便宜上、多重化されたＵＣＩをＭＵＸＵＣＩ／Ｄａｔａと称する。またＵＣＩ／データの多重化はＭＵＸＵＣＩ／Ｄａｔａに関連して行われる動作を含む。例えば、ＵＣＩ／データの多重化はＭＵＸＵＣＩ／Ｄａｔａを送信するためにＵＬチャネルリソースを決定する過程を含む。

【0089】

－スロット：データスケジューリングのための基本時間単位（ｔｉｍｅｕｎｉｔ（ＴＵ）又はｔｉｍｅｉｎｔｅｒｖａｌ）を意味する。スロットは複数のシンボルを含む。ここで、シンボルはＯＦＤＭベースのシンボルを含む（例えば、ＣＰ－ＯＦＤＭシンボル、ＤＦＴ－ｓ－ＯＦＤＭシンボル）。この明細書において、シンボル、ＯＦＤＭベースのシンボル、ＯＦＤＭシンボル、ＣＰ－ＯＦＤＭシンボル及びＤＦＴ－ｓ－ＯＦＤＭシンボルは互いに代替することができる。

【0090】

－重畳したＵＬチャネルリソース：所定の時間区間（例えば、スロット）内で時間軸で（少なくとも一部が）重畳したＵＬチャネル（例えば、ＰＵＣＣＨ、ＰＵＳＣＨ）リソースを意味する。重畳したＵＬチャネルリソースはＵＣＩ多重化を行う前のＵＬチャネルリソースを意味する。

【0091】

ＰＵＣＣＨフォーマットはＵＣＩペイロードサイズ及び／又は送信の長さ（例えば、ＰＵＣＣＨリソースを構成するシンボル数）によって以下のように区分される。ＰＵＣＣＨフォーマットに関する事項は表３を参照できる。

【0092】

（０）ＰＵＣＣＨフォーマット０（ＰＦ０、Ｆ０）

【0093】

－支援可能なＵＣＩペイロードサイズ：最大Ｋビットまで（例えば、Ｋ＝２）

【0094】

－単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：１～Ｘシンボル（例えば、Ｘ＝２）

【0095】

－送信構造：ＤＭ－ＲＳ無しにＵＣＩ信号のみで構成され、複数のシーケンスのうちの１つを選択及び送信することによりＵＣＩ状態を送信

【0096】

（１）ＰＵＣＣＨフォーマット１（ＰＦ１、Ｆ１）

【0097】

－支援可能なＵＣＩペイロードサイズ：最大Ｋビットまで（例えば、Ｋ＝２）

【0098】

－単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ～Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）

【0099】

－送信構造：ＤＭ－ＲＳとＵＣＩが互いに異なるＯＦＤＭシンボルにＴＤＭ形態で構成され、ＵＣＩは特定のシーケンスに変調（例えば、ＱＰＳＫ）シンボルを乗ずる形態。ＵＣＩとＤＭ－ＲＳに全てＣＳ（ＣｙｃｌｉｃＳｈｉｆｔ）／ＯＣＣ（ＯｒｔｈｏｇｏｎａｌＣｏｖｅｒＣｏｄｅ）を適用して、（同じＲＢ内で）（ＰＵＣＣＨフォーマット１に従う）複数のＰＵＣＣＨリソースの間でＣＤＭを支援

【0100】

（２）ＰＵＣＣＨフォーマット２（ＰＦ２、Ｆ２）

【0101】

－支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）

【0102】

－単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：１～Ｘシンボル（例えば、Ｘ＝２）

【0103】

－送信構造：ＤＭＲＳとＵＣＩが同じシンボル内でＦＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴ無しにＩＦＦＴのみを適用して送信される構造

【0104】

（３）ＰＵＣＣＨフォーマット３（ＰＦ３、Ｆ３）

【0105】

－支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）

【0106】

－単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ～Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）

【0107】

－送信構造：ＤＭＲＳとＵＣＩが互いに異なるシンボルにＴＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴを適用して送信する形態。ＵＣＩにはＤＦＴの前端でＯＣＣを適用し、ＤＭＲＳにはＣＳ（又はＩＦＤＭマッピング）を適用して複数の端末に多重化を支援

【0108】

（４）ＰＵＣＣＨフォーマット４（ＰＦ４、Ｆ４）

【0109】

－支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）

【0110】

－単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ～Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）

【0111】

－送信構造：ＤＭＲＳとＵＣＩが互いに異なるシンボルにＴＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴを適用して端末間の多重化無しに送信される構造

【0112】

ＵＣＩタイプ（例えば、Ａ／Ｎ、ＳＲ、ＣＳＩ）ごとにＰＵＣＣＨリソースが決定される。ＵＣＩ送信に使用されるＰＵＣＣＨリソースはＵＣＩ（ペイロード）サイズに基づいて決定される。一例として、基地局は端末に複数のＰＵＣＣＨリソースセットを設定し、端末はＵＣＩ（ペイロード）サイズ（例えば、ＵＣＩビット数）の範囲によって、特定の範囲に対応する特定のＰＵＣＣＨリソースセットを選択する。例えば、端末はＵＣＩビット数（Ｎ_UCI）によって、以下のうちのいずれか１つのＰＵＣＣＨリソースセットを選択することができる。

【0113】

－ＰＵＣＣＨリソースセット＃０、ＵＣＩビット数≦２であると、

【0114】

－ＰＵＣＣＨリソースセット＃１、２＜ＵＣＩビット数≦Ｎ₁であると、

【0115】

．．．

【0116】

－ＰＵＣＣＨリソースセット＃（Ｋ－１）、Ｎ_K-2＜ＵＣＩビット数≦Ｎ_K-1であると、

【0117】

ここで、ＫはＰＵＣＣＨリソースセット数を示し（Ｋ＞１）、Ｎ_iはＰＵＣＣＨリソースセット＃ｉが支援する最大のＵＣＩビット数である。例えば、ＰＵＣＣＨリソースセット＃１はＰＵＣＣＨフォーマット０～１のリソースで構成され、それ以外のＰＵＣＣＨリソースセットはＰＵＣＣＨフォーマット２～４のリソースで構成される（表３を参照）。

【0118】

ＵＣＩタイプがＳＲ、ＣＳＩである場合、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースは上位層シグナリング（例えば、ＲＲＣシグナリング）により設定される。ＵＣＩタイプがＳＰＳ（Ｓｅｍｉ－ＰｅｒｓｉｓｔｅｎｔＳｃｈｅｄｕｌｉｎｇ）ＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫである場合、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースは上位層シグナリング（例えば、ＲＲＣシグナリング）により設定される。反面、ＵＣＩタイプが普通のＰＤＳＣＨ（即ち、ＤＣＩによりスケジュールされたＰＤＳＣＨ）に対するＨＡＲＱ－ＡＣＫである場合は、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースはＤＣＩに基づいてスケジュールされる。

【0119】

ＤＣＩベースのＰＵＣＣＨリソーススケジューリングの場合、基地局は端末にＰＤＣＣＨを介してＤＣＩを送信し、ＤＣＩ内のＡＲＩ（ＡＣＫ／ＮＡＣＫＲｅｓｏｕｒｃｅＩｎｄｉｃａｔｏｒ）により特定のＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースを指示する。ＡＲＩはＡＣＫ／ＮＡＣＫ送信のためのＰＵＣＣＨリソースを指示するために使用され、ＰＲＩ（ＰＵＣＣＨＲｅｓｏｕｒｃｅＩｎｄｉｃａｔｏｒ）とも呼ばれる。ここで、ＤＣＩはＰＤＳＣＨスケジューリングに使用されるＤＣＩであり、ＵＣＩはＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫを含む。一方、基地局はＡＲＩが表現できる状態（ｓｔａｔｅ）の数より多いＰＵＣＣＨリソースで構成されたＰＵＣＣＨリソースセットを（端末－特定の）上位層（例えば、ＲＲＣ）信号により端末に設定する。この時、ＡＲＩはＰＵＣＣＨリソースセット内のＰＵＣＣＨリソースサブセットを指示し、指示されたＰＵＣＣＨリソースサブセット内でどのＰＵＣＣＨリソースを使用するかは、ＰＤＣＣＨに関する送信リソース情報（例えば、ＰＤＣＣＨの開始ＣＣＥインデックスなど）に基づく暗黙的な規則（ｉｍｐｌｉｃｉｔｒｕｌｅ）によって決定される。

【0120】

以下の提案方法は他の提案方法と互いに相反しない限り、共に結合して適用できる。

【0121】

ＰＵＣＣＨ／ＰＵＣＣＨ多重化

【0122】

［提案方法＃１］Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、（基準時点から）特定の時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳するか否かによって、端末でＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。

【0123】

但し、端末がＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を行わない場合、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの一つの送信を省略することができる。

【0124】

一例として、端末はＳＲＰＵＣＣＨの送信開始時点（例えば、開始シンボル）（以下、Ｔｓｒ）を基準として、Ｔ₀以前の時点（以下、Ｔｒｅｆ，ｓｒ）まで受信された（又は送信が開始された）ＰＤＳＣＨ（又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳するか否かによって、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。Ｔｒｅｆ，ｓｒ＝Ｔｓｒ－Ｔ₀と定義され、ＯＦＤＭシンボル単位で表現することができる。

【0125】

（ケース１）Ｔｒｅｆ，ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳する場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信することができる（又はＡ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのシンボルが完全に重畳する場合と同じＵＣＩ多重化規則に従うことができる）。

【0126】

（１）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0127】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0128】

－Ａ／ＮをＡ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信

【0129】

Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0130】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0131】

（２）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0132】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0133】

－Ａ／ＮをＳＲＰＵＣＣＨリソースを介して送信。但し、ＳＲＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。

【0134】

Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0135】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0136】

（３）Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの１つである場合

【0137】

Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲ又はｎｅｇａｔｉｖｅＳＲである場合

【0138】

【0139】

（ケース２）（ケース１）に該当しない場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信することができる。例えば、（ｉ）Ｔｒｅｆ，ｓｒ時点後に受信された（又は送信が開始／終了した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳するか、（ｉｉ）Ｔｒｅｆ，ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳しないか、又は（ｉｉｉ），ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが存在しない場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信することができる。

【0140】

（１）ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0141】

－ＳＲをＳＲＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0142】

（２）ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0143】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0144】

Ｔ₀は以下のうちの１つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0145】

（１）端末能力（ｃａｐａｂｉｌｉｔｙ）によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0146】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0147】

（３）端末能力による復調に必要な端末処理時間又はそれに対応する値

【0148】

（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0149】

（５）基地局と端末の間に予め約束した値（例えば、固定値）

【0150】

［提案方法＃１］はＡ／ＮＰＵＣＣＨ以外のＰＵＣＣＨにも拡張して適用できる。

【0151】

一方、ＮＲシステムでは、Ａ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨの間の開始（ｓｔａｒｔｉｎｇ）（ＯＦＤＭ）シンボル（或いは開始時間）が一致する場合、Ａ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨが時間軸で完全に重畳する場合と同一のＵＣＩ多重化規則を適用する端末動作が合議されている。反面、Ａ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボルが異なる場合には、Ａ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）を比較して、Ａ／ＮとＳＲの間のＵＣＩ多重化の有無を決定する方法が論議されている。例えば、ＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより先立つ場合、端末はＳＲＰＵＣＣＨを送信し、Ａ／Ｎ送信を省略する。逆に、ＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより遅れる場合は、端末はＳＲとＡ／ＮをＵＣＩ多重化して単一のＰＵＣＣＨで送信する。この動作は端末がＳＲ送信を準備した後（又はＳＲ送信中）にＡ／Ｎ送信があることを認知した場合、ＳＲ送信を取り消し、Ａ／ＮとＳＲをＵＣＩ多重化して送信する過程が端末の具現化上、容易ではないという点で提案されたものである。しかし、ＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより先立っても、Ａ／ＮＰＵＣＣＨに対応するＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の受信時点がしばらく前であると、端末はＡ／ＮとＳＲをＵＣＩ多重化して送信することができる。従って、既存の方法は、端末処理時間の観点で端末にＡ／ＮとＳＲの間のＵＣＩ多重化を行う余力があっても、Ａ／Ｎ送信を省略するという点で好ましくない。

【0152】

従って、Ａ／ＮとＳＲの多重化を支援するために、端末に（ｉ）ＳＲｏｎｌｙの送信を行うか、又は（ｉｉ）ＳＲとＡ／Ｎを多重化して送信するかを決定する時点を明示することができる。たとえ、端末は特定のＳＲＰＵＣＣＨに対する送信開始時点（Ｔｓｒ）を基準として、Ｔ₀以前の時点（Ｔｒｅｆ，ｓｒ）まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳しない場合、ＰｏｓｉｔｉｖｅＳＲであれば、ＳＲＰＵＣＣＨを送信すると決定することができる。この時、端末はＴｒｅｆ，ｓｒ後に受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳しても、Ａ／Ｎ送信を省略し、ＳＲＰＵＣＣＨ送信を行うことができる。反面、Ｔｒｅｆ，ｓｒまで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨリソースと時間軸で重畳する場合は、端末は（ｉ）ＳＲ情報がｐｏｓｉｔｉｖｅＳＲであれば、Ａ／ＮとＳＲをＵＣＩ多重化して単一のＰＵＣＣＨリソースを介して送信し、（ｉｉ）ＳＲ情報がｎｅｇａｔｉｖｅＳＲであれば、Ａ／ＮのみをＡ／ＮＰＵＣＣＨを介して送信するか、又はｎｅｇａｔｉｖｅＳＲを表現する明示的ビットをＡ／Ｎに付け加えてＡ／ＮＰＵＣＣＨを介して送信することができる。

【0153】

一方、端末は今後Ａ／ＮＰＵＣＣＨリソースがＳＲＰＵＣＣＨと重畳しないように更新されてもＡ／ＮとＳＲをＵＣＩ多重化すると予め決定したので、決定を翻さず、相変わらずＵＣＩ多重化されたＡ／ＮとＳＲを単一のＰＵＣＣＨリソースを介して送信することができる。

【0154】

図７はＡ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合の動作を例示する。図８はＡ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合の動作を例示する。

【0155】

［提案方法＃１］は、端末がＴｒｅｆ，ｓｒ（即ち、Ｔｓｒ－Ｔｏ）前に終了した／受信したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／ＮＰＵＣＣＨについてはＳＲＰＵＣＣＨに対する送信を確定する前に存在の有無を把握できるという仮定を前提とする。即ち、［提案方法＃１］は、Ｔｒｅｆ，ＳＲ後に終了したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）については端末がＳＲＰＵＣＣＨに対する送信を確定する前に把握することが難しいと判断し、Ａ／ＮとＳＲの多重化を判断する時に参照しない。［提案方法＃１］によれば、端末はＴｒｅｆ，ＳＲ前に終了した／受信したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／ＮＰＵＣＣＨがＳＲＰＵＣＣＨと時間軸で重畳すると、Ａ／ＮとＳＲを共に多重化して送信することができる。Ａ／ＮＰＵＣＣＨがＳＲＰＵＣＣＨと時間軸で重畳しないか又は存在しないと、ＳＲのみを送信することができるので、端末の具現化が容易である。また、［提案方法＃１］は、ほとんどの場合にＡ／ＮとＳＲが多重化されるようにすることにより、Ａ／Ｎ又はＳＲ送信が省略される場合を減らす効果がある。また［提案方法＃１］は、Ａ／ＮとＳＲが多重化されてＳＲＰＵＣＣＨで送信される場合、（例えば、Ａ／ＮＰＵＣＣＨがＦ１であり、ＳＲＰＵＣＣＨもＦ１である場合にも）Ａ／Ｎ送信に対する最小のＰＤＳＣＨ－ｔｏ－ＨＡＲＱ－ＡＣＫ送信処理時間を保証して、できる限り単一化された解決策を提示するという長所がある。もし一つのスロット内に互いに区分される複数のＳＲＰＵＣＣＨが設定された場合は、端末はスロット内の先立つＳＲＰＵＣＣＨに対してＡ／Ｎとの多重化の有無を判断した後、Ａ／Ｎ送信が省略されないと、次のＳＲＰＵＣＣＨとＡ／Ｎとの多重化の有無を判断するように順に動作を適用することができる。

【0156】

［提案方法＃１］の変形として、Ｔｒｅｆ，ｓｒ（即ち、Ｔｓｒ－Ｔｏ）まで送信が開始されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／ＮＰＵＣＣＨがＳＲＰＵＣＣＨと重畳する場合には、Ａ／ＮとＳＲに対する多重化を行い、そうではない場合には、ＳＲのみを送信する。この動作は、（Ａ／ＮＰＵＣＣＨに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信開始時点がＴｒｅｆ，ｓｒより先立つ（又は同一である）場合、端末が該当ＰＤＳＣＨに対応するＰＤＣＣＨ（例えば、ＤＬ割り当て）を検出及び復調する時間が十分であり、ＳＲＰＵＣＣＨに対する送信を確定する前に該当ＳＲＰＵＣＣＨと衝突するＡ／ＮＰＵＣＣＨが存在することを認知できるという仮定を前提とする。従って、（Ａ／ＮＰＵＣＣＨに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信開始時点がＴｒｅｆ，ｓｒより遅れる場合は、該当ＰＤＳＣＨに対応するＰＤＣＣＨ（例えば、ＤＬ割り当て）を検出及び復調する時間が十分でないので、端末は該当ＰＤＳＣＨについてはＡ／ＮとＳＲに対する多重化の有無を判断する時に反映されない。

【0157】

［提案方法＃１］の変形として、端末が送信しようとするＡ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の一部ＯＦＤＭシンボルに対して）重畳した場合、Ａ／ＮＰＵＣＣＨリソースに対応するＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点とＳＲＰＵＣＣＨの送信開始時点の間の相対的な関係によって、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定する方法を考慮できる。

【0158】

【0159】

一例として、端末は（Ａ／ＮＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）送信終了（或いは開始）時点がＴｒｅｆ，ｓｒ（即ち、Ｔｓｒ－Ｔｏ）より先立つか／遅れるかによって以下のようにＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。

【0160】

（１）（Ａ／ＮＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点がＴｒｅｆ，ｓｒより遅れた場合

【0161】

Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信

【0162】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0163】

１．ＳＲをＳＲＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0164】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0165】

１．Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0166】

（２）（Ａ／ＮＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点がＴｒｅｆ，ｓｒより先立つ（又は同一である）場合

【0167】

Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信（又はＡ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのＯＦＤＭシンボルが完全に重畳する場合と同一のＵＣＩ多重化規則に従う）

【0168】

ｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0169】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0170】

－Ａ／ＮをＡ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信

【0171】

２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0172】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0173】

ｉｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0174】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0175】

－Ａ／ＮをＳＲＰＵＣＣＨリソースを介して送信。但し、ＳＲＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合にはＳＲを送信せず、Ａ／Ｎのみを送信する。

【0176】

２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0177】

－Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0178】

ｉｉｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合

【0179】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲ又はｎｅｇａｔｉｖｅＳＲである場合

【0180】

－ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／ＮＰＵＣＣＨリソースを介して送信

【0181】

Ｔ₀は以下のうちの１つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0182】

【0183】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0184】

（３）端末能力による復調に必要な端末処理時間又はそれに対応する値

【0185】

（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0186】

（５）基地局と端末の間に予め約束した値（例えば、固定値）

【0187】

［提案方法＃１］の変形として、Ａ／ＮとＣＳＩの間のＵＣＩ多重化についても、Ａ／ＮとＳＲの間のＵＣＩ多重化のように、以下の動作を行うことができる。例えば、Ａ／ＮＰＵＣＣＨリソースとＣＳＩＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末は（基準時点から）特定時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳するか否かによってＡ／ＮとＣＳＩの間の多重化の有無を決定することができる。

【0188】

但し、端末がＡ／ＮとＣＳＩの間の多重化を行わない場合には、Ａ／ＮとＣＳＩのうちの一つの送信を省略することができる。

【0189】

一例として、端末はＣＳＩＰＵＣＣＨの送信開始時点（例えば、開始シンボル）（以下、Ｔｃｓｉ）を基準として、Ｔ₀以前の時点（以下、Ｔｒｅｆ，ｃｓｉ）まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳するか否かによってＡ／ＮとＣＳＩの間の多重化の有無を決定することができる。Ｔｒｅｆ，ｃｓｉ＝Ｔｃｓｉ－Ｔ₀と定義され、ＯＦＤＭシンボル単位で表現することができる。

【0190】

（ケース１）Ｔｒｅｆ，ｃｓｉまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳する場合は、端末はＡ／ＮとＣＳＩを多重化して送信することができる。

【0191】

（１）Ａ／ＮＰＵＣＣＨがＤＬ割り当てにより指示される場合

【0192】

－Ａ／ＮとＣＳＩを多重化してＡ／ＮＰＵＣＣＨリソースを介して送信

【0193】

（２）Ａ／ＮＰＵＣＣＨがＤＬ割り当てにより指示されない場合

【0194】

－Ａ／ＮとＣＳＩを多重化してＣＳＩＰＵＣＣＨリソースを介して送信

【0195】

（ケース２）（ケース１）に該当しない場合、端末はＡ／ＮとＣＳＩのうちの１つを選択して送信することができる。例えば、（ｉ）Ｔｒｅｆ，ＣＳＩ時点後に受信された（又は送信が開始／終了した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳するか、（ｉｉ）Ｔｒｅｆ，ＣＳＩまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳しないか、又は（ｉｉｉ）Ｔｒｅｆ，ＣＳＩまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが存在しない場合、端末はＡ／ＮとＣＳＩのうちの１つを選択して送信することができる。

【0196】

（１）Ｏｐｔ．１：ＣＳＩをＣＳＩＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0197】

（２）Ｏｐｔ．２：Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信（ＣＳＩ送信を省略）

【0198】

Ｔ₀は以下のうちの１つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0199】

（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0200】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0201】

（３）端末能力による復調に必要な端末処理時間又はそれに対応する値

【0202】

（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0203】

（５）基地局と端末の間に予め約束した値（例えば、固定値）

【0204】

［提案方法＃１Ａ］端末に送信設定／指示されたＰＵＣＣＨリソースがスロット内の時間軸で全体又は一部のＯＦＤＭシンボルが重畳する場合、端末が以下のＵＣＩ多重化規則に従ってＵＣＩ多重化（例えば、ＵＣＩ多重化）を行う方法

【0205】

（１）スロット内で重畳したＰＵＣＣＨリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化して単一のＰＵＣＣＨリソース（以下、ＭＵＸＰＵＣＣＨ）を介して送信

【0206】

Ａ．条件＃１

【0207】

ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対するＰＤＳＣＨ及び／又はＳＰＳＰＤＳＣＨ解除（ｒｅｌｅａｓｅ）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0208】

ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）がＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の最後の（各々の）（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0209】

ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0210】

ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＣＳＩＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0211】

ｖ．Ｏｐｔ．５：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードに対して端末に設定された（全ての）ＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0212】

Ｂ．条件＃２

【0213】

ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、特定の規則によって選択される（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ₂以後に開始

【0214】

ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ₂以後に開始

【0215】

ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードについて端末に設定された（全ての）ＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ₂以後に開始

【0216】

ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）が（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ₂以後に開始

【0217】

ここで、（スケジューリング）ＤＣＩベースのＰＵＣＣＨリソースは、ＤＣＩにより割り当てられたＨＡＲＱ－ＡＣＫ送信ＰＵＣＣＨリソースである。上記ＤＣＩの最後のシンボルは該当ＤＣＩを運ぶＰＤＣＣＨが送信された最後のシンボルである。

【0218】

（２）スロット内に重畳した（一部の）ＰＵＣＣＨリソースが条件を満たさない場合、端末は以下の動作を行うことができる。

【0219】

Ａ．Ｏｐｔ．１：端末は（２）の場合を期待せず、（２）の場合が発生した時に端末動作は端末の具現化に従う

【0220】

Ｂ．Ｏｐｔ．２：端末は（１）の条件を満たさない（一部の）ＰＵＣＣＨリソースに対するＵＣＩに対する送信を省略し、（１）の条件を満たす残りのＰＵＣＣＨリソースに対するＵＣＩを多重化して単一のＰＵＣＣＨリソースを介して送信

【0221】

Ｃ．Ｏｐｔ．３：端末はスロット内に重畳したＰＵＣＣＨリソースに対する送信を省略

【0222】

Ｄ．Ｏｐｔ．４：端末は（スロット内に重畳したＰＵＣＣＨリソースのうち）特定の（一つの）ＰＵＣＣＨリソース（例えば、最も高い優先順位のＵＣＩを送信するＰＵＣＣＨリソース、又は時間軸で最も先になるＰＵＣＣＨリソース）のみを送信し、残りは送信を省略

【0223】

但し、スロット内（上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより送信が指示された）の重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、（多重化する）ＵＣＩの組み合わせ、（全体）ＵＣＩペイロードサイズなどに基づいて定められた特定の規則によって、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース（以下、ＭＵＸＰＵＣＣＨ）が新しく決定される。

【0224】

ここで、Ｔ₁は端末がＰＤＳＣＨを受信した後、ＨＡＲＱ－ＡＣＫ送信を行うために必要な端末処理時間に対応する値である。また、Ｔ₂は端末がＵＬ送信に対する（スケジューリング）ＤＣＩを受信した後、ＵＬ送信を行うために必要な端末処理時間に対応する値である。Ｔ₁とＴ₂は（ＯＦＤＭ）シンボル単位で表現することができる。

【0225】

端末は時間軸で重畳したＰＵＣＣＨリソースの間のＵＣＩ多重化の有無を決定するとき、少なくとも２個のタイムライン条件を考える。タイムライン条件＃１は、ＰＤＳＣＨの受信後、ＨＡＲＱ－ＡＣＫ送信までの端末処理時間を保証するための条件である。タイムライン条件＃１は、ＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルから一定時間Ｔ₁以後にＨＡＲＱ－ＡＣＫ送信が行われることを目的とする。従って、Ｔ₁時間に基づく条件は、ＨＡＲＱ－ＡＣＫ送信が行われるＵＬリソースを基準として適用する必要があり、重畳したＵＣＩが多重化されると仮定するとき、（特定の規則によって）決定されるＰＵＣＣＨリソースの開始時点とＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルの間に適用することができる。タイムライン条件＃２は、ＰＤＣＣＨの受信後、ＵＬ送信までの端末処理時間を保証するための条件である。タイムライン条件＃２は、（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨの最後の（ＯＦＤＭ）シンボルから一定の時間Ｔ₂以後にＵＬ送信が行われることを目的とする。タイムライン条件＃２は、任意のＵＬ送信開始からＴ₂以前にスケジュール有無を把握できるようにするという目的もある。従って、重畳したＰＵＣＣＨリソースのうち、最も早いＵＬリソースよりＴ₂以前に（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨに対する受信が終了しなければならない。即ち、タイムライン条件＃２は、スロット内に重畳したＰＵＣＣＨリソース（及びＵＣＩを多重化すると仮定するとき、特定の規則によって選択される（単一の）ＰＵＣＣＨリソース）のうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ₂以後に開始される条件である。

【0226】

［提案方法＃１Ｂ］端末に設定／指示されたＰＵＣＣＨリソースとＰＵＳＣＨリソースがスロット内の時間軸で全体或いは一部のＯＦＤＭシンボルが重畳する場合、端末が以下のＵＣＩ多重化規則に従ってＵＣＩ多重化を行う方法

【0227】

（１）スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースに対するＵＣＩ及びＵＬ－ＳＣＨＴＢを多重化して、単一のＰＵＳＣＨリソース（以下、ＭＵＸＰＵＳＣＨ）により送信

【0228】

Ａ．条件＃１

【0229】

ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＳＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対するＰＤＳＣＨ及び／又はＳＰＳＰＤＳＣＨ解除の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0230】

ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）がＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0231】

ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

【0232】

ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードに対して端末に設定された（全ての）ＰＵＣＣＨリソースとスロット内の（全ての）ＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ₁以後に開始

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

各段階において、多重化されたＵＣＩに対する既存のＵＬリソースが特定の（単一の）ＰＵＣＣＨ或いはＰＵＳＣＨリソースに代替される場合、端末は代替された既存のＵＬリソースを、以後の段階では存在しないリソースと見なすことができる。即ち、代替された既存のＵＬリソースは、以後の過程ではＵＣＩ多重化対象として考慮されない。反面、多重化されたＵＣＩを送信するように決定された（単一の）ＰＵＣＣＨ或いはＰＵＳＣＨリソースは、以後の過程でＵＣＩ多重化対象として考慮される。

【0268】

各段階に複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースが存在するとき、複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースの間に該当段階の動作を適用する順序は所定の優先順位規則に従う。一例として、優先順位規則は、（スロット内の）相対的な送信時点（例えば、開始位置／シンボル）、ＵＣＩタイプ、リソース割り当て方式（例えば、動的又は準静的）、スケジュールされた順序、送信容量などを基準として決定される。

【0269】

一例として、スロット内の時間軸で重畳するＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対してＵＣＩ多重化を行うとき、一つのスロット内で複数のＰＵＣＣＨ送信及びＰＵＣＣＨ時間リソースの柔軟な割り当てが支援されるＮＲシステムの特徴により、ＵＣＩ多重化を行う対象となるＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースを決定することが不明な場合がある。たとえ、ＡＮＰＵＣＣＨ、ＣＳＩＰＵＣＣＨ、ＳＲＰＵＣＣＨリソースが一つのスロット内に共存するとき、ＣＳＩＰＵＣＣＨリソースはＡＮＰＵＣＣＨリソース／ＳＲＰＵＣＣＨリソースと時間軸で重畳する反面、ＡＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースは互いに時間軸で重畳しないと仮定する。この場合、（１）ＨＡＲＱ－ＡＣＫ、ＣＳＩ、ＳＲの全てに対する多重化を行うか、又は（２）ＨＡＲＱ－ＡＣＫ－ＣＳＩ対に対する多重化とＣＳＩ－ＳＲ対に対する多重化を行うかという端末動作が不明である。従って、本発明では、最も多い種類のＵＣＩを含むＵＬリソースの順でＵＣＩ多重化を行う方法（例えば、［方法＃Ａ］）、又は最も早い（或いは最も高い優先順位のＵＣＩを含む）ＰＵＣＣＨリソースを基準として時間軸で重畳したＰＵＣＣＨリソースに対して順にＵＣＩ多重化を行う方法（例えば、［方法＃Ｂ］）を提案する。［方法＃Ａ］の場合、ＰＵＳＣＨ＝＞（ＤＣＩベースにスケジュールされた）ＡＮＰＵＣＣＨ＝＞ＣＳＩＰＵＣＣＨ＝＞（上位層（例えば、ＲＲＣ）信号により設定された）ＡＮＰＵＣＣＨの順にＵＣＩ多重化を行うことができる。この時、一度ＵＣＩ多重化対象として選定されたＰＵＣＣＨリソースは、以後のＵＣＩ多重化過程では排除される。

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

Ａ．ＡＮＰＦ０である場合

【0384】

ｉ．ＳＲＰＦ０である場合：ＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。ｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信。

【0385】

ｉｉ．ＳＲＰＦ１である場合

【0386】

－Ｏｐｔ．１：ＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。ｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信。

【0387】

－Ｏｐｔ．２：ＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＳＲＰＦ１リソースを介して送信。ｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信。

【0388】

Ｂ．ＡＮＰＦ１である場合

【0389】

ｉ．ＳＲＰＦ０である場合：ＡＮをＡＮＰＦ１リソースを介して送信（ＳＲｄｒｏｐ）

【0390】

ｉｉ．ＳＲＰＦ１である場合：ＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＳＲＰＦ１リソースを介して送信。ｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ１リソースを介して送信。

【0391】

（２）Ｃａｓｅ＃２：（単一の）ＡＮと（マルチプル）ＳＲ（ｗ／単一のＰＵＣＣＨフォーマット）の間のＵＣＩ多重化

【0392】

Ａ．ＡＮＰＦ０である場合

【0393】

ｉ．（マルチプル）ＳＲＰＦ０である場合

【0394】

－（特定のＳＲＰＵＣＣＨグループ内の）少なくとも一つのＳＲＰＵＣＣＨに対するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースに（特定のＳＲＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信

【0395】

－この場合、全Ｋ個のＳＲＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲＰＵＣＣＨグループにグルーピングした後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングすることができる。特定のＳＲＰＵＣＣＨグループに属するＳＲのうちのいずれか１つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作

【0396】

－全てのＳＲＰＵＣＣＨに対するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0397】

ｉｉ．（マルチプル）ＳＲＰＦ１である場合

【0398】

－Ｏｐｔ．１：（特定のＳＲＰＵＣＣＨグループ内の）少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースに（特定のＳＲＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信。この場合、全Ｋ個のＳＲＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングする。特定のＳＲＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0399】

－Ｏｐｔ．２：少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＳＲＰＵＣＣＨのうちの（最優先順位の）ＳＲＰＵＣＣＨに対応するＳＲＰＦ１リソースを介して送信。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0400】

Ｂ．ＡＮＰＦ１である場合

【0401】

ｉ．（マルチプル）ＳＲＰＦ０である場合：ＡＮをＡＮＰＦ１リソースを介して送信（ＳＲｄｒｏｐ）

【0402】

ｉｉ．（マルチプル）ＳＲＰＦ１である場合：少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＳＲＰＵＣＣＨのうちの（最優先順位の）ＳＲＰＵＣＣＨに対応するＳＲＰＦ１リソースを介して送信。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ１リソースを介して送信

【0403】

（３）Ｃａｓｅ＃３：（単一の）ＡＮと（マルチプル）ＳＲ（ｗ／互いに異なるＰＵＣＣＨフォーマット）の間のＵＣＩ多重化

【0404】

Ａ．ＡＮＰＦ０である場合

【0405】

ｉ．（マルチプル）ＳＲＰＦ０＋（マルチプル）ＳＲＦ１である場合

【0406】

－Ｏｐｔ．１：少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであり、ＳＲＰＵＣＣＨのうち、（最優先順位の）ＳＲＰＵＣＣＨがＰＦ０である場合、ＡＮをＡＮＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。この場合、全体或いはＰＦ０に設定されたＫ個のＳＲＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個ＣＳオフセットに対応／マッピングする。この場合、特定のＳＲＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。もしＰＦ０に設定されたＳＲＰＵＣＣＨ数ＫがＬと同一であるか、又はＬより小さい場合には、別のグループ化無しに該当Ｋ個のＳＲＰＵＣＣＨを各々互いに異なるＫ個のＣＳオフセットに対応／マッピングする。この場合、ＰｏｓｉｔｉｖｅＳＲＰＵＣＣＨに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであり、ＳＲＰＵＣＣＨのうち、（最優先順位の）ＳＲＰＵＣＣＨがＰＦ１である場合、ＡＮを（該当）ＳＲＰＦ１リソースを介して送信。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0407】

－Ｏｐｔ．２：（特定のＳＲＰＵＣＣＨグループ内の）少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースに（特定のＳＲＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信。この場合、全Ｋ個のＳＲＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングする。この場合、特定のＳＲＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0408】

－Ｏｐｔ．３：（特定のＳＲＰＵＣＣＨグループ内の）少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮを（上記特定のＳＲＰＵＣＣＨグループに対応する）特定のＳＲＰＦ１リソースを介して送信。この場合、全Ｋ個のＳＲＰＵＣＣＨをＬ個（例えば、Ｌ＝ｔｈｅｎｕｍｂｅｒｏｆＳＲｓｃｏｎｆｉｇｕｒｅｄｗｉｔｈＦ１、Ｋ＞Ｌ）ＳＲＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個のＳＲＦ１リソースに対応／マッピングする。この場合、特定のＳＲＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＳＲＦ１リソースによりＡＮを送信するように動作。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ０リソースを介して送信

【0409】

Ｂ．ＡＮＰＦ１である場合

【0410】

ｉ．（マルチプル）ＳＲＰＦ０＋（マルチプル）ＳＲＦ１である場合

【0411】

－Ｏｐｔ．１：少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであり、ＳＲＰＵＣＣＨのうち、（最優先順位の）ＳＲＰＵＣＣＨがＰＦ０である場合、ＡＮをＡＮＰＦ１リソースを介して送信（ＳＲｄｒｏｐ）。少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであり、ＳＲＰＵＣＣＨのうち、（最優先順位の）ＳＲＰＵＣＣＨがＰＦ１である場合、ＡＮを（該当）ＳＲＰＦ１リソースを介して送信。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ１リソースを介して送信

【0412】

－Ｏｐｔ．２：（特定のＳＲＰＵＣＣＨグループ内の）少なくとも一つのＳＲＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅＳＲであると、ＡＮを（上記特定のＳＲＰＵＣＣＨグループに対応する）特定のＳＲＰＦ１リソースを介して送信。この場合、全Ｋ個のＳＲＰＵＣＣＨをＬ個の（例えば、Ｌ＝ｔｈｅｎｕｍｂｅｒｏｆＳＲｓｃｏｎｆｉｇｕｒｅｄｗｉｔｈＦ１、Ｋ＞Ｌ）ＳＲＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲＰＵＣＣＨグループを各々互いに異なるＬ個のＳＲＦ１リソースに対応／マッピングする。この場合、特定のＳＲＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲＰＵＣＣＨグループに対応するＳＲＦ１リソースによりＡＮを送信するように動作。全てのＳＲＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅＳＲであると、ＡＮをＡＮＰＦ１リソースを介して送信

【0413】

ここで、ＳＲＰＵＣＣＨグループは一つ以上のＳＲＰＵＣＣＨで構成され、一つ以上のＳＲＰＵＣＣＨグループが定義される。

【0414】

上述した内容を整理すると以下の通りである。

【0415】

（１）Ｃａｓｅ＃１

【0416】

Ａ．ＡＮＰＦ０＋単一のＳＲＰＦ０＝＞ＡＮ＋ＳＲｏｎＡＮＰＦ０（ＣＳオフセットにより）

【0417】

Ｂ．ＡＮＰＦ０＋単一のＳＲＰＦ１＝＞ＡＮ＋ＳＲｏｎＡＮＰＦ０（ＣＳオフセットにより）又はＳＲＰＦ１（ＣＨ選択により）

【0418】

Ｃ．ＡＮＰＦ１＋単一のＳＲＰＦ０＝＞ＡＮｏｎｌｙｏｎＡＮＰＦ１（ＳＲ省略により）

【0419】

Ｄ．ＡＮＰＦ１＋単一のＳＲＰＦ１＝＞ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択により）

【0420】

（２）Ｃａｓｅ＃２

【0421】

Ａ．ＡＮＰＦ０＋マルチプルＳＲＰＦ０＝＞ＡＮ＋ＳＲｏｎＡＮＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）

【0422】

Ｂ．ＡＮＰＦ０＋マルチプルＳＲＰＦ１＝＞ＡＮ＋ＳＲｏｎＡＮＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）又はＳＲＰＦ１（ＣＨ選択により）

【0423】

Ｃ．ＡＮＰＦ１＋マルチプルＳＲＰＦ０＝＞ＡＮｏｎｌｙｏｎＡＮＰＦ１（ＳＲ省略により）

【0424】

Ｄ．ＡＮＰＦ１＋マルチプルＳＲＰＦ１＝＞ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択により）

【0425】

（３）Ｃａｓｅ＃３

【0426】

Ａ．ＡＮＰＦ０＋（マルチプル）ＳＲＰＦ０＋（マルチプル）ＳＲＰＦ１

【0427】

ｉ．Ｏｐｔｉｏｎ１

【0428】

１．ＳＲＰＦ０がＰｏｓｉｔｉｖｅＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲｏｎＡＮＦ０（ＣＳオフセット及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲＦ０のみに限定

【0429】

２．ＳＲＰＦ１がＰｏｓｉｔｉｖｅＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択により）

【0430】

ｉｉ．Ｏｐｔｉｏｎ２

【0431】

１．ＳＲＰＦがＰｏｓｉｔｉｖｅＳＲであるか否かに関係なく、ＡＮ＋ＳＲｏｎＡＮＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲＰＦ０とＳＲＰＦ１を全て含む

【0432】

ｉｉｉ．Ｏｐｔｉｏｎ３

【0433】

１．ＳＲＰＦがＰｏｓｉｔｉｖｅＳＲであるか否かに関係なく、ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲＰＦ０とＳＲＰＦ１を全て含む

【0434】

Ｂ．ＡＮＰＦ１＋（マルチプル）ＳＲＰＦ０＋（マルチプル）ＳＲＰＦ１

【0435】

ｉ．Ｏｐｔｉｏｎ１

【0436】

１．ＳＲＰＦ０がＰｏｓｉｔｉｖｅＳＲであり、優先順位が最も高い場合、ＡＮｏｎｌｙｏｎＡＮＰＦ１（ＳＲ省略により）

【0437】

２．ＳＲＰＦ１がＰｏｓｉｔｉｖｅＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択により）

【0438】

ｉｉ．Ｏｐｔｉｏｎ２

【0439】

１．ＡＮ＋ＳＲｏｎＳＲＰＦ１（ＣＨ選択及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲＰＦ０とＳＲＰＦ１を全て含む

【0440】

［提案方法＃２］スロット内において、Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸＰＵＣＣＨ）の送信開始時点とＳＲＰＵＣＣＨの送信開始時点の相対的な関係によってＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。

【0441】

但し、端末がＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を行わない場合、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つの送信が省略される。

【0442】

一例として、端末はＳＲＰＵＣＣＨの送信開始時点がＭＵＸＰＵＣＣＨの送信開始時点よりＴ₀ほど先立つか又は遅れるかによって、以下のようにＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無が決定される。

【0443】

（１）ＳＲＰＵＣＣＨの送信開始時点がＭＵＸＰＵＣＣＨの送信開始時点を基準としてＴ₀以前の時点より先立つ場合

【0444】

Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの一つを選択して送信

【0445】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合、ＳＲをＳＲＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0446】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合、Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0447】

（２）ＳＲＰＵＣＣＨの送信開始時点がＭＵＸＰＵＣＣＨの送信開始時点を基準としてＴ₀以前の時点より遅れる（又は同一である）場合

【0448】

Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信（又はＡ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのＯＦＤＭシンボルに対して完全に重畳する場合と同一のＵＣＩ多重化規則に従う）

【0449】

ｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0450】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合、Ａ／ＮをＡ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信

【0451】

２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合、Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0452】

ｉｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0453】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合、Ａ／ＮをＳＲＰＵＣＣＨリソースを介して送信。但し、ＳＲＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。

【0454】

２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合、Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0455】

ｉｉｉ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合

【0456】

１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲ又はｎｅｇａｔｉｖｅＳＲである場合、Ａ．ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／ＮＰＵＣＣＨリソースを介して送信

【0457】

Ｔ₀は以下のうちの一つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0458】

（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0459】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0460】

（３）端末能力による復調に必要な端末処理時間又はそれに対応する値

【0461】

（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0462】

（５）基地局と端末の間で予め約束した値（例えば、固定値）

【0463】

［提案方法＃２］はＡ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合に適用される。

【0464】

ＮＲシステムにおいて、Ａ／ＮＰＵＣＣＨとＳＲＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボルが異なる場合、Ａ／Ｎｏｎｌｙの送信を仮定したＡ／ＮＰＵＣＣＨ（以下、Ａ／ＮＰＵＣＣＨ１）とＳＲＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）を比較して、Ａ／ＮとＳＲの間のＵＣＩ多重化の有無を決定する方法が論議されている。例えば、ＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより先立つ場合、端末はＳＲＰＵＣＣＨを送信し、Ａ／Ｎ送信を省略する。逆に、ＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより遅れた（或いは同一である）場合には、端末はＳＲとＡ／ＮをＵＣＩ多重化して単一のＰＵＣＣＨで送信することができる。上述した動作は、端末が開始（ＯＦＤＭ）シンボルが先立つＰＵＣＣＨを先に処理することが期待されるためである。しかし、ＮＲシステムにおいて、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信するとき、Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合は、単一のＰＵＣＣＨリソースはＡ／ＮとＳＲに対する全体ＵＣＩペイロードサイズを算定して新しく選択されたＡ／ＮＰＵＣＣＨリソース（以下、Ａ／ＮＰＵＣＣＨ２）であり、Ａ／ＮＰＵＣＣＨ１とは異なることができる。従って、端末がＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／ＮＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより遅れた（或いは同一である）場合であると判断した後、Ａ／ＮＰＵＣＣＨ２でＡ／ＮとＳＲを送信するとき、ＳＲＰＵＣＣＨよりＡ／ＮＰＵＣＣＨ２の開始（ＯＦＤＭ）シンボルが先立つ場合があり得る。従って、より一貫した端末の動作のために、Ａ／ＮＰＵＣＣＨ１ではなく、Ａ／ＮＰＵＣＣＨ２の開始（ＯＦＤＭ）シンボルとＳＲＰＵＣＣＨの開始（ＯＦＤＭ）シンボルの間の先後関係を比較することが好ましい。

【0465】

［提案方法＃３］スロット内において、Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸＰＵＣＣＨ）の送信開始時点がＳＲＰＵＣＣＨの送信開始時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ－ｇｏｉｎｇＳＲＰＵＣＣＨ送信があれば、該当ＳＲＰＵＣＣＨの送信を中断して、ＭＵＸＰＵＣＣＨでＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信することができる。

【0466】

さらに、Ａ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳した場合は、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸＰＵＣＣＨ）の送信開始時点がＡ／ＮＰＵＣＣＨの送信開始時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ－ｇｏｉｎｇＡ／ＮＰＵＣＣＨ送信があれば、該当Ａ／ＮＰＵＣＣＨの送信を中断して、ＭＵＸＰＵＣＣＨでＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信する方法

【0467】

但し、上記動作は特定の端末能力を有する端末に限定して適用される。

【0468】

端末がＳＲ送信を行った後にＳＲＰＵＣＣＨと時間軸で一部重畳するＡ／ＮＰＵＣＣＨリソースの存在を把握した場合、簡単な方法で端末は該当Ａ／Ｎ送信を省略することができる。しかし、端末に十分な能力があれば、できる限り（即ち、ベストエフォート方式により）現在進行中のＳＲ送信を中断し、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信することができる。逆に、端末がＡ／Ｎ送信を行った後にＡ／ＮＰＵＣＣＨと時間軸で一部重畳するＳＲＰＵＣＣＨリソースに対するＰｏｓｉｔｉｖｅＳＲが発生することができる。この場合にも、端末は（即ち、ベストエフォート方式により）現在進行中のＡ／Ｎ送信を中断し、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信することができる。［提案方法＃３］により、端末はＳＲとＡ／Ｎが衝突する場合にもＡ／ＮとＳＲの多重化された送信を最大に支援することができる。

【0469】

［提案方法＃４］Ａ／ＮＰＵＣＣＨがＰＦ０又はＰＦ１であり、スロット内でＡ／ＮＰＵＣＣＨリソースとＳＲＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末はＡ／ＮＰＵＣＣＨリソースと重畳したＳＲＰＵＣＣＨリソースに対応するＳＲプロセス数によって、Ａ／ＮとＳＲに対するＵＣＩ多重化規則を異なるように適用することができる。

【0470】

一例として、Ａ／ＮＰＵＣＣＨリソースと重畳したＳＲＰＵＣＣＨリソースに対応するＳＲプロセスが一つであるか、或いは複数であるかによって、端末は以下のようにＡ／ＮとＳＲに対してＵＣＩ多重化規則を適用することができる。

【0471】

（１）（Ａ／Ｎと重畳する）ＳＲプロセスが一つである場合

【0472】

Ａ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0473】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合、Ａ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースによりＡ／Ｎを送信

【0474】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合、Ａ／ＮＰＵＣＣＨリソースによりＡ／Ｎを送信

【0475】

Ｂ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0476】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合、ＳＲＰＵＣＣＨリソースによりＡ／Ｎを送信

【0477】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合、Ａ／ＮＰＵＣＣＨリソースによりＡ／Ｎを送信

【0478】

（２）（Ａ／Ｎと重畳する）ＳＲプロセスが複数である場合

【0479】

Ａ．Ａ／ＮＰＵＣＣＨがＰＦ０又はＰＦ１である場合

【0480】

ｉ．Ａ／Ｎに（複数のＳＲプロセスに対する）ＳＲを表現するマルチビットを付け加えた後、Ａ／ＮＰＵＣＣＨリソースにより全体ＵＣＩを送信。ここで、Ａ／ＮＰＵＣＣＨリソースはＡ／ＮとマルチビットＳＲを含むＵＣＩペイロードサイズを基準として選択されたリソースであり、ＰＦ２／３／４のうちの一つである。

【0481】

ここで、複数のＳＲプロセスに対応するＳＲＰＵＣＣＨリソースの設定は特定のＩＤにより区分され、各々独立している。

【0482】

ＮＲシステムでは、Ａ／ＮＰＵＣＣＨがＰＦ０又はＰＦ１である場合、支援されるＡ／Ｎペイロードサイズは２ビット以下である。この時、一つのＳＲプロセスに関する情報が追加される場合、端末は多重化容量が落ちるラージＵＣＩペイロードサイズ用のＰＵＣＣＨフォーマット（例えば、ＰＦ２／３／４）を使用するよりは、リソース選択方式を用いて該当ＳＲプロセスに対するｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅＳＲを表現することができる。しかし、Ａ／ＮＰＵＣＣＨリソースと複数のＳＲプロセスに対応するＳＲＰＵＣＣＨリソースが重畳した場合は、端末はｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅＳＲ以外に、どのＳＲプロセスがｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅＳＲであるかに関する情報も基地局に伝達する必要がある。この場合、ＳＲ情報を表現するために必要なビット数が多いので、ＳＲプロセスが１個である場合のように、リソース選択方式を活用するよりは、３ビット以上のラージＵＣＩペイロードサイズ用のＰＵＣＣＨフォーマット（例えば、ＰＦ２／３／４）を使用した方がより効率的である。

【0483】

［提案方法＃５］スロット内のＡ／ＮＰＵＣＣＨリソースとＣＳＩＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部ＯＦＤＭシンボルが）重畳する場合、以下のようにＡ／ＮとＣＳＩの間の多重化を支援する方法

【0484】

（１）Ａ／ＮＰＵＣＣＨリソースがＤＬ割り当てベースではない場合

【0485】

Ａ．ＣＳＩＰＵＣＣＨの送信開始時点を基準としてＴ₀以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＣＳＩＰＵＣＣＨリソースと時間軸で重畳する場合

【0486】

ｉ．Ａ／ＮとＣＳＩを多重化してＣＳＩＰＵＣＣＨで送信

【0487】

Ｂ．その他の場合

【0488】

ｉ．Ｏｐｔ．１：ＣＳＩをＣＳＩＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0489】

ｉｉ．Ｏｐｔ．２：Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信（ＣＳＩ送信を省略）

【0490】

（２）Ａ／ＮＰＵＣＣＨリソースがＤＬ割り当てベースである場合

【0491】

Ａ．Ａ／ＮとＣＳＩを多重化して（全体ＵＣＩ基準として再選択された）Ａ／ＮＰＵＣＣＨリソースを介して送信。但し、ＣＳＩを更新する時間が足りない場合は（例えば、ＣＳＩ参照リソースがＡ／ＮＰＵＣＣＨリソースの送信開始時点を基準としてＴ₁以前の時点である場合は）、端末はＣＳＩを更新しないことができる。

【0492】

ＣＳＩ参照リソースはＣＳＩ計算の参照となる時間リソースを意味する。（有効な）ＤＬスロットは（端末に）ＤＬスロットとして設定されたスロット及び／又は測定ギャップ（例えば、ｍｅａｓｕｒｅｍｅｎｔｇａｐ）に含まれないスロット及び／又はＣＳＩ報告が行われるＤＬＢＷＰと同一のＤＬＢＷＰに含まれるスロットを意味する。

【0493】

Ｔ₀は以下のうちの一つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0494】

（１）端末能力によるＰＤＳＣＨの終了後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0495】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0496】

（３）端末能力による復調に必要な端末処理時間又はそれに対応する値

【0497】

（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0498】

（５）基地局と端末の間に予め約束した値（例えば、固定値）

【0499】

Ｔ₁は以下のうちの一つである。Ｔ₁は（ＯＦＤＭ）シンボル単位で示すことができる。

【0500】

（１）端末能力によるＣＳＩ計算及び報告のために必要な端末の処理時間又はそれに対応する値

【0501】

（２）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0502】

（３）基地局と端末の間に予め約束した値（例えば、固定値）

【0503】

ＮＲシステムでは、ＤＬ割り当て（＝ＤＬｓｃｈｅｄｕｌｉｎｇＤＣＩ）に基づくＰＤＳＣＨに対するＡ／ＮとＣＳＩが多重化される場合、Ａ／ＮとＣＳＩに対する全体ＵＣＩペイロードサイズを基準として再選択されたＡ／ＮＰＵＣＣＨリソースにより多重化されたＡ／ＮとＣＳＩを送信することができる。多重化動作はＡ／ＮＰＵＣＣＨとＣＳＩＰＵＣＣＨが時間軸で一部重畳する場合にも適用できる。但し、ＣＳＩ参照リソースがＡ／ＮＰＵＣＣＨの送信開始地点を基準として、端末処理時間であるＴ₀以前に存在する場合には、端末がＣＳＩを新しく更新することが難しい。従って、ＣＳＩを新しく更新することが難しい場合には、ＣＳＩを更新せず（但し、更新されないＣＳＩは相変わらずＡ／Ｎと多重化して報告）、その他の場合にはＣＳＩを更新してＡ／Ｎと多重化して報告する方法を提案する。

【0504】

反面、Ａ／ＮがＤＬ割り当てに基づくＰＤＳＣＨに対応しない場合は、端末はＡ／ＮとＣＳＩをＣＳＩＰＵＣＣＨに多重化して送信することができる。ＣＳＩＰＵＣＣＨによりＡ／Ｎを送信する場合、Ａ／Ｎ送信のための最小のＵＬタイミングが保証される場合にのみＡ／ＮとＣＳＩの間の多重化を許容する。即ち、端末はＣＳＩＰＵＣＣＨ送信開始時点を基準として、Ｔ₁以前の時点まで受信した（或いは送信を開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨがＣＳＩＰＵＣＣＨと重畳する場合にのみＡ／ＮとＣＳＩの間の多重化を行い、そうではない場合にはＡ／Ｎ送信を省略して、ＣＳＩＰＵＣＣＨのみを送信することができる。

【0505】

［提案方法＃６］端末が特定のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（以下、ＵＬ－ＣＨ１）内の一部の（ＯＦＤＭ）シンボルをパンクチャリングし、（ＯＦＤＭ）シンボルにおいて他のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（以下、ＵＬ－ＣＨ２）を送信することができる。この場合、ＵＬ－ＣＨ２に対する送信電力は以下のように適用できる。

【0506】

（１）Ｏｐｔ．１

【0507】

Ａ．ＵＬ－ＣＨ２に対して（ＵＬ－ＣＨ１と）独立して設定された送信電力を適用

【0508】

ｉ．ＵＬ－ＣＨ２の送信電力がＵＬ－ＣＨ１の送信電力を基準として一定の範囲内の値を有する場合、端末はＵＬ－ＣＨ１のパンクチャリング後のリソースを（不連続に）全部送信する。

【0509】

ｉｉ．ＵＬ－ＣＨ２の送信電力がＵＬ－ＣＨ１の送信電力を基準として一定範囲外の値を有する場合、

【0510】

１．ＵＬ－ＣＨ１のパンクチャリング後のリソース内にＤＭ－ＲＳが存在すると、ＵＬ－ＣＨ１の残りのリソースに対する送信を全部行う。ここで、ＤＭ－ＲＳはデータ復調用の参照信号を意味する。

【0511】

２．ＵＬ－ＣＨ１のパンクチャリング後のリソース内にＤＭ－ＲＳが存在すると、ＵＬ－ＣＨ１の残りのリソースに対する送信を省略

【0512】

（２）Ｏｐｔ．２

【0513】

Ａ．ＵＬ－ＣＨ２に対してＵＬ－ＣＨ１と同じ送信電力を適用

【0514】

（３）Ｏｐｔ．３

【0515】

Ａ．ＵＬ－ＣＨ２に対して（ＵＬ－ＣＨ１と）独立して設定された送信電力がＴＸＰ１であり、ＵＬ－ＣＨ１に対する位相連続性（Ｐｈａｓｅｃｏｎｔｉｎｕｉｔｙ）を保証する最大の送信電力がＴＸＰ２であるとき、ｍｉｎ（ＴＸＰ１、ＴＸＰ２）をＵＬ－ＣＨ２に対する送信電力として適用。ここで、位相連続性はＵＬ－ＣＨ１に対してパンクチャリング以前のリソースと以後のリソースの間にチャネル変化による位相差を除いた他の位相差がないことを意味する。

【0516】

ｉ．ＴＸＰ２は端末が具現化により任意に選択する値である。

【0517】

ｉ．ＵＬ－ＣＨ２について設定された既存のＵＬＰＣ（ｐｏｗｅｒｃｏｎｔｒｏｌ）規則を例外にすることができる。

【0518】

一例として、端末がＰＵＳＣＨ送信中に緊急サービス（例えば、ＵＲＬＬＣ）に対するＰＵＣＣＨ送信を行わなければならない場合がある。この場合は、端末がＰＵＳＣＨ送信を既に進行中であるので（例えば、Ｏｎ－ｇｏｉｎｇｔｒａｎｓｍｉｓｓｉｏｎ）、端末はＰＵＳＣＨ送信を中止してＰＵＣＣＨを送信しなければならない。この時、ＰＵＳＣＨ送信の観点では、ＰＵＣＣＨが送信されるＯＦＤＭシンボルのみがパンクチャリングされることができる。この場合、パンクチャリング区間内のＰＵＣＣＨ送信電力がＰＵＳＣＨとは異なるので、ＰＡ（ｐｏｗｅｒａｍｐｌｉｆｉｅｒ）設定が初期化されてパンクチャリング区間を基準として前側に送信されたＰＵＳＣＨリソースと後側に送信されたＰＵＳＣＨリソースの間に（送信信号の）位相が変化することができる。この問題は、ＰＵＳＣＨ送信中にＰＵＣＣＨ送信を行いながら端末の送信電力が大きく変更するためである。従って、本発明では、ＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（即ち、ＵＬ－ＣＨ１）内の一部（ＯＦＤＭ）シンボルをパンクチャリングし、（ＯＦＤＭ）シンボル内で他のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（即ち、ＵＬ－ＣＨ２）を送信するとき、端末は位相変化を減らすために、以下の動作を行うことができる。

【0519】

（１）ＵＬ－ＣＨ２に対する送信電力をＵＬ－ＣＨ１と同値に設定するか、又は

【0520】

（２）ＵＬ－ＣＨ２に対して独立したＵＬ電力制御を行い、ＵＬ－ＣＨ１の送信電力と比較して位相差を誘発する電力差が発生する場合には、ＵＬ－ＣＨ２の送信以後の残りのＵＬ－ＣＨ１のリソースはＤＭ－ＲＳが存在する場合にのみ送信する動作を考えることができる。

【0521】

ＰＵＣＣＨ／ＰＵＳＣＨ多重化

【0522】

［提案方法＃６．１］スロット内において、Ａ／ＮＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末は（基準時点から）特定時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか否かによって、Ａ／ＮとＵＬデータの間の多重化の有無（或いはＡ／ＮをＰＵＳＣＨにＵＣＩピギーバックするか否か）を決定する方法

【0523】

但し、端末がＡ／ＮとＵＬデータの間の多重化を行わない場合には、Ａ／ＮとＵＬデータのうちの一つの送信を省略できる。

【0524】

一例として、端末はＰＵＳＣＨの送信開始時点（例えば、開始シンボル）を基準として、Ｔ₀以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨと重畳するか否かによって、ＰＵＳＣＨへのＡ／Ｎピギーバックの有無を決定することができる。

【0525】

（１）ＰＵＳＣＨの送信開始時点を基準として、Ｔ₀以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳する場合

【0526】

－Ａ／ＮとＵＬデータを多重化して送信（即ち、Ａ／ＮをＰＵＳＣＨにＵＣＩピギーバックして送信）（又はＡ／ＮＰＵＣＣＨとＰＵＳＣＨが時間軸でＰＵＣＣＨ或いはＰＵＳＣＨ内の全てのＯＦＤＭシンボルと完全に重畳する場合と同じＵＣＩ多重化規則に従う）

【0527】

（２）（１）に該当しない場合（例えば、ＰＵＳＣＨの送信開始時点を基準として、Ｔ₀以前の時点後に受信された（又は送信開始／終了された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか、又はＰＵＳＣＨの送信開始時点を基準として、Ｔ₀以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳しないか、又はＰＵＳＣＨの送信開始時点を基準として、Ｔ₀以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが存在しない場合）

【0528】

－Ｏｐｔ．１：ＵＬデータをＰＵＳＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0529】

－Ｏｐｔ．２：Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信（ＰＵＳＣＨ送信を省略）

【0530】

但し、特定のバージョンの端末である場合、ＰＵＳＣＨに対するＵＬグラントの受信後に受信された、ＤＬ割り当てによりスケジュールされたＰＤＳＣＨに対するＡ／ＮはＰＵＳＣＨへのＵＣＩピギーバック対象ではない。

【0531】

Ｔ₀は以下のうちの一つである。Ｔ₀は（ＯＦＤＭ）シンボル単位で示すことができる。

【0532】

（１）端末能力によるＰＤＳＣＨの終了後、Ａ／Ｎ送信まで必要な端末処理時間又はそれに対応する値。端末能力によるＵＣＩ（ＰＵＣＣＨ）送信のために必要な端末処理時間又はそれに対応する値

【0533】

（２）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値。又は、端末能力によるＵＣＩ（ＰＵＣＣＨ）送信のために必要な端末処理時間又はそれに対応する値

【0534】

（３）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0535】

（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値

【0536】

（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値

【0537】

（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0538】

（６）基地局と端末の間に予め約束した値（例えば、固定値）

【0539】

［提案方法＃６．１］はＡ／ＮＰＵＣＣＨ以外のＰＵＣＣＨにも拡張して適用することができる。

【0540】

ＮＲシステムではＰＵＣＣＨとＰＵＳＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）が一致する場合、ＰＵＣＣＨとＰＵＳＣＨが時間軸で完全に重畳する場合と同一のＵＣＩ多重化規則を適用する端末動作が合議されている。この時、ＰＵＣＣＨとＰＵＳＣＨが多重化して送信されるリソースがＰＵＳＣＨリソースであるので、ＰＵＳＣＨリソースの送信開始前までＰＵＣＣＨ内の特定のＵＣＩ送信に必要な処理時間が満たさない場合には、該当ＰＵＣＣＨをＰＵＳＣＨに多重化することができない。たとえ、ＰＵＣＣＨがＨＡＲＱ－ＡＣＫ送信のためのＰＵＣＣＨ（以下、Ａ／ＮＰＵＣＣＨ）である場合、端末はＰＵＳＣＨの送信開始時点を基準として（端末能力によるＰＤＳＣＨの受信後、Ａ／Ｎ送信まで必要な時間である）Ｔ₀時間以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮのみをＰＵＳＣＨで送信することができる。従って、本発明はＳＲＰＵＣＣＨとＡ／ＮＰＵＣＣＨの間のＵＣＩ多重化規則（［提案方法＃１］）のように、端末がＰＵＳＣＨ送信開始時点を基準として、Ｔ₀以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか否かによりＡ／Ｎに対するＵＣＩピギーバックの有無を決定することができる。即ち、端末はＰＵＳＣＨ送信開始時点を基準として、Ｔ₀以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳すると、Ａ／ＮをＰＵＳＣＨにＵＣＩピギーバックして送信し、そうではない場合には、Ａ／Ｎに対する送信無しにＰＵＳＣＨのみを送信することができる。図１２は［提案方法＃６．１］の動作を例示する。

【0541】

［提案方法＃６．１］の変形として、ＣＳＩＰＵＣＣＨとＰＵＳＣＨが時間軸で重畳した場合は、端末はＣＳＩＰＵＣＣＨを送信せず、ＰＵＳＣＨでＣＳＩをＵＣＩピギーバックすることができる。この時、ＣＳＩ計算のための処理時間がＰＵＳＣＨ送信準備まで十分ではない場合は、端末はＣＳＩを更新しないことができる。

【0542】

Ａ／ＮＰＵＣＣＨリソースと他のＵＬチャネルが時間軸で（一部或いは全体）重畳するとき、［提案方法＃１］と［提案方法＃６．１］を統合すると、端末が以下のように動作する。

【0543】

（１）Ａ／ＮＰＵＣＣＨの送信開始時点（又はスロット）を基準として、Ｔ₀以前の時点までＡ／ＮＰＵＣＣＨと時間軸で重畳するＵＬチャネルが設定／指示されない場合（例えば、ＵＬチャネルはＳＲを送信するＰＵＣＣＨ又はＵＬ－ＳＣＨＴＢを運ぶＰＵＳＣＨである）

【0544】

Ａ．端末はＡ／ＮのみをＡ／ＮＰＵＣＣＨリソースを介して送信（上記時点以後、Ａ／ＮＰＵＣＣＨと重畳するＵＬチャネルが発生しても無視するか又は該当ＵＬチャネル送信を省略／放棄）

【0545】

（２）Ａ／ＮＰＵＣＣＨの送信開始時点（又はスロット）を基準として、Ｔ₀以前の時点までＡ／ＮＰＵＣＣＨと時間軸で重畳するＵＬチャネルが設定／指示された場合（例えば、該当ＵＬチャネルはＳＲを送信するＰＵＣＣＨ又はＵＬ－ＳＣＨＴＢを運ぶＰＵＳＣＨである）

【0546】

Ａ．ＵＬチャネルが（特定の）ＵＣＩ（以下、ＵＣＩ－Ａ）を送信するＰＵＣＣＨ（以下、ＰＵＣＣＨ－Ａ）である場合

【0547】

ｉ．ＰＵＣＣＨ－Ａリソースの送信開始時点を基準として、Ｔ₁以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＰＵＣＣＨ－Ａリソースと時間軸で重畳する場合、Ａ／ＮとＵＣＩ－Ａを多重化して単一のＰＵＣＣＨリソースを介して送信

【0548】

ｉｉ．その他の場合（例えば、ＰＵＣＣＨ－Ａリソースの送信開始時点を基準として、Ｔ₁以前の時点まで受信された（又は送信が開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＰＵＣＣＨ－Ａリソースと時間軸で重畳しないか、又はＰＵＣＣＨ－Ａリソースの送信開始時点を基準として、Ｔ₁以前の時点まで受信された（又は送信が開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが存在しない場合）、Ａ／ＮとＵＣＩ－Ａのうちの一つを選択して送信

【0549】

－Ｏｐｔ．１：ＵＣＩ－Ａ（ｏｎｌｙ）をＰＵＣＣＨ－Ａリソースを介して送信（Ａ／Ｎ送信を省略）

【0550】

－Ｏｐｔ．２：Ａ／Ｎ（ｏｎｌｙ）をＡ／ＮＰＵＣＣＨリソースを介して送信（ＵＣＩ－Ａ送信を省略）

【0551】

－Ｏｐｔ．３：ＵＣＩ－Ａの状態によってＯｐｔ．１又はＯｐｔ．２を適用

【0552】

Ｂ．ＵＬチャネルがＵＬ－ＳＣＨＴＢ（又はＵＬデータ）を送信するＰＵＳＣＨである場合

【0553】

ｉ．ＰＵＳＣＨの送信開始時点を基準としてＴ₂以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳する場合

【0554】

１．Ａ／ＮとＵＬデータを多重化して送信（即ち、Ａ／ＮをＰＵＳＣＨによりＵＣＩピギーバック）（又はＡ／ＮＰＵＣＣＨとＰＵＳＣＨが時間軸でＰＵＣＣＨ或いはＰＵＳＣＨ内の全てのＯＦＤＭシンボルに対して完全に重畳する場合と同一のＵＣＩ多重化規則に従う）

【0555】

ｉｉ．その他の場合（例えば、ＰＵＳＣＨリソースの送信開始時点を基準としてＴ₂以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳しない場合、又はＰＵＳＣＨリソースの送信開始時点を基準としてＴ₂以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／ＮＰＵＣＣＨリソースが存在しない場合）、Ａ／ＮとＵＬ－ＳＣＨのうちの一つを選択して送信

【0556】

－Ｏｐｔ．１：ＵＬ－ＳＣＨ（ｏｎｌｙ）をＰＵＳＣＨリソースを介して送信（Ａ／Ｎ送信を省略）

【0557】

－Ｏｐｔ．２：Ａ／Ｎ（ｏｎｌｙ）をＡ／ＮＰＵＣＣＨリソースを介して送信（ＵＬ－ＳＣＨ送信を省略）

【0558】

Ｔ₀、Ｔ₁、Ｔ₂は以下のうちの一つである。Ｔ₀、Ｔ₁、Ｔ₂は（ＯＦＤＭ）シンボル単位で示すことができる。

【0559】

（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0560】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0561】

（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値

【0562】

（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値

【0563】

（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0564】

（６）基地局と端末の間に予め約束した値（例えば、固定値）

【0565】

本発明の変形により、スロットにおいてＰＵＣＣＨ－ＰＵＣＣＨ又はＰＵＣＣＨ－ＰＵＳＣＨが時間軸で重畳する場合、端末は以下の（一般化した）ＵＣＩ多重化規則を適用することができる。

【0566】

（１）特定のＵＣＩに対するＰＵＣＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ₀以前の時点までＰＵＣＣＨリソースと時間軸で重畳するＵＬチャネルが設定／指示されない場合（例えば、ＵＬチャネルはＰＵＣＣＨ又はＰＵＳＣＨである）

【0567】

Ａ．端末は特定のＵＣＩのみをＰＵＣＣＨリソースを介して送信（時点以後のＰＵＣＣＨと重畳するＵＬチャネルが発生しても無視或いは該当ＵＬチャネルの送信を省略／放棄）

【0568】

（２）特定のＵＣＩ₁に対するＰＵＣＣＨリソース（ＰＵＣＣＨ₁）が先に指示／指示された後、ＵＣＩ₁に対するＰＵＣＣＨリソース（ＰＵＣＣＨ₁）の送信開始時点（又はスロット）を基準として、Ｔ₀以前の時点までＰＵＣＣＨ₁と時間軸で重畳する特定のＵＣＩ₂に対するＰＵＣＣＨリソース（ＰＵＣＣＨ₂）が設定／指示された場合

【0569】

Ａ．端末はＵＣＩ₁とＵＣＩ₂を多重化して単一のＰＵＣＣＨリソースを介して送信

【0570】

ｉ．但し、単一のＰＵＣＣＨリソースはＰＵＣＣＨ₁とＰＵＣＣＨ₂以外のリソースであることができる。

【0571】

（３）特定のＵＣＩに対するＰＵＣＣＨリソースが先に設定／指示された後、特定のＵＣＩに対するＰＵＣＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ₀以前の時点までＰＵＣＣＨリソースと時間軸で重畳するＵＬ－ＳＣＨＴＢに対するＰＵＳＣＨリソースが設定／指示された場合

【0572】

Ａ．端末はＵＣＩとＵＬ－ＳＣＨを多重化してＰＵＳＣＨリソースを介して送信（即ち、ＵＣＩピギーバック）

【0573】

（４）特定のＵＬ－ＳＣＨに対するＰＵＳＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ₁以前の時点までＰＵＳＣＨと時間軸で重畳するＵＬチャネルが設定／指示されていない場合（例えば、該当ＵＬチャネルはＰＵＣＣＨである）

【0574】

Ａ．端末は特定のＵＬ－ＳＣＨのみをＰＵＳＣＨリソースを介して送信（時点以後のＰＵＳＣＨと重畳するＵＬチャネルが発生しても無視或いは該当ＵＬチャネルの送信を省略／放棄）

【0575】

（５）特定のＵＬ－ＳＣＨに対するＰＵＳＣＨリソースが先に設定／指示された後、特定のＵＬ－ＳＣＨに対するＰＵＳＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ₁以前の時点までＰＵＳＣＨリソースと時間軸で重畳する特定のＵＣＩに対するＰＵＣＣＨリソースが設定／指示された場合

【0576】

Ａ．端末はＵＣＩとＵＬ－ＳＣＨＴＢを多重化してＰＵＳＣＨリソースを介して送信（即ち、ＵＣＩピギーバック）

【0577】

Ｔ₀、Ｔ₁は以下のうちの一つである。Ｔ₀、Ｔ₁は（ＯＦＤＭ）シンボル単位で示すことができる。

【0578】

（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0579】

（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値

【0580】

（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値

【0581】

（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値

【0582】

（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値

【0583】

（６）基地局と端末の間に予め約束した値（例えば、固定値）

【0584】

特定のＵＣＩがＡ／Ｎであるとき、該当ＵＣＩに対するＰＵＣＣＨリソースが設定／指示される時点は、Ａ／Ｎに対応するＰＤＳＣＨの受信（終了）時点と見なされる。

【0585】

特定のＵＣＩに対するＰＵＣＣＨリソースが先に設定／指示される動作は、上位層（例えば、ＲＲＣ）信号に基づいて設定される動作を含む。例えば、上位層信号により予め設定されたＰＵＣＣＨリソースは、ＤＣＩにより指示されたＰＵＣＣＨリソースより常に先に設定／指示されたリソースと見なされることができる。例えば、ＵＣＩ₁とＵＣＩ₂は、各々ＳＲとＡ／Ｎであるか、又は各々（ｐｅｒｉｏｄｉｃ）ＣＳＩとＨＡＲＱ－ＡＣＫである。

【0586】

但し、ＵＣＩ₁とＵＣＩ₂に対して以下の多重化動作が適用される。

【0587】

（１）ＵＣＩ₁＝ＳＲ、ＵＣＩ₂＝Ａ／Ｎである場合

【0588】

Ａ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合

【0589】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0590】

１．Ａ／ＮをＡ／ＮＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信

【0591】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0592】

１．Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0593】

Ｂ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合

【0594】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲである場合

【0595】

１．Ａ／ＮをＳＲＰＵＣＣＨリソースを介して送信

【0596】

Ａ．但し、ＳＲＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。

【0597】

ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅＳＲである場合

【0598】

１．Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信

【0599】

Ｃ．Ａ／ＮＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合

【0600】

ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅＳＲ又はｎｅｇａｔｉｖｅＳＲである場合

【0601】

１．ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／ＮＰＵＣＣＨリソースを介して送信

【0602】

（２）ＵＣＩ₁＝ＣＳＩ、ＵＣＩ₂＝Ａ／Ｎである場合

【0603】

Ａ．Ａ／ＮＰＵＣＣＨがＤＬ割り当てにより指示された場合

【0604】

ｉ．Ａ／ＮとＣＳＩを多重化してＡ／ＮＰＵＣＣＨリソースを介して送信

【0605】

Ｂ．Ａ／ＮＰＵＣＣＨがＤＬ割り当てにより指示されない場合

【0606】

ｉ．Ａ／ＮとＣＳＩを多重化してＣＳＩＰＵＣＣＨリソースを介して送信

【0607】

［提案方法＃７］スロット内において、Ａ／ＮＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、端末はＡ／ＮＰＵＣＣＨの送信開始時点がＰＵＳＣＨの送信時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ－ｇｏｉｎｇＰＵＳＣＨ送信があれば、該当ＰＵＳＣＨ送信を中断し、Ａ／ＮＰＵＣＣＨを介してＡ／Ｎを送信する。

【0608】

さらにスロット内において、Ａ／ＮＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、Ａ／ＮＰＵＣＣＨの送信開始時点がＰＵＳＣＨの送信時点より早いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ－ｇｏｉｎｇＰＵＣＣＨ送信があれば、該当ＰＵＣＣＨ送信を中断し、Ａ／ＮをＰＵＳＣＨによりピギーバックする。

【0609】

端末がＰＵＳＣＨ送信を行った後に該当ＰＵＣＣＨと時間軸で一部重畳するＡ／ＮＰＵＣＣＨリソースの存在を把握した場合は、端末は簡単な方法により該当Ａ／Ｎ送信を省略することができる。しかし、端末が十分な能力があれば、できる限り（即ち、ベストエフォート方式により）現在進行中のＰＵＳＣＨ送信を中断し、Ａ／ＮをＡ／ＮＰＵＣＣＨリソースを介して送信しようとする。［提案方法＃６．１］の動作により、端末はＰＵＳＣＨとＡ／Ｎが衝突した場合にもＡ／Ｎ送信を最大限支援することができる。

【0610】

［提案方法＃８］ＮＲシステムでは、Ａ－ＣＳＩＯｎｌｙＰＵＳＣＨに対する送信の有無を端末に確実に知らせるために、ＵＬグラント内にＡ－ＣＳＩ（ＡｐｅｒｉｏｄｉｃＣＳＩ）の報告の有無を知らせるＡ－ＣＳＩトリガーフィールド以外に、ＰＵＳＣＨ内のデータ（例：ＵＬ－ＳＣＨＴＢ、簡単には、ＵＬ－ＳＣＨ）の存在の有無を知らせるＵＬ－ＳＣＨ指示子が含まれる。例えば、Ａ－ＣＳＩトリガーフィールドはＮビットで構成され、ＵＬ－ＳＣＨ指示子は１ビットで構成される。この時、ＵＬ－ＳＣＨ指示子がＵＬ－ＳＣＨがないと指示し、Ａ－ＣＳＩトリガーフィールドがＡ－ＣＳＩ報告があると指示すると、端末はＡ－ＣＳＩＯｎｌｙＰＵＳＣＨ送信が指示されたと判断する。しかし、ＵＬ－ＳＣＨ指示子がＵＬ－ＳＣＨがないと指示したが、Ａ－ＣＳＩトリガーフィールドもＡ－ＣＳＩ報告もないと指示すると、この場合に対する解釈が曖昧になる。従って、この提案では、ＵＬ－ＳＣＨ指示子がＵＬ－ＳＣＨがないことを指示し、Ａ－ＣＳＩトリガーフィールドもＡ－ＣＳＩ報告がないことを指示した場合、端末が以下のうちの一つに解釈する方法を提案する。

【0611】

（１）ＵＣＩＯｎｌｙＰＵＳＣＨｗｉｔｈｏｕｔＵＬ－ＳＣＨを送信。ここで、ＵＣＩＯｎｌｙＰＵＳＣＨｗｉｔｈｏｕｔＵＬ－ＳＣＨ送信は、ＵＬデータなしに同一のスロット／時点内の送信が指示／設定されたＵＣＩをＰＵＳＣＨにピギーバックすることを含む。

【0612】

（２）誤り状況であると判断（ｅｒｒｏｒｃａｓｅ）。これにより、端末はＰＵＳＣＨ送信を期待しないことができる。ここで、ＰＵＳＣＨ送信を期待しないことは、例えば、該当ＰＵＳＣＨ送信を省略（Ｄｒｏｐ）するか、又は該当ＰＵＳＣＨをスケジュールするＤＣＩを廃棄（ｄｉｓｃａｒｄ）することを含む。ＤＣＩを廃棄することは、ＤＣＩにより指示された動作を従わない／行わないことを含む。

【0613】

（３）ＰＵＳＣＨに対してＵＬ－ＳＣＨ（或いはＵＬデータ）送信がないと指示され、Ａ－ＣＳＩ送信もないと指示された場合、端末は指示されたＰＵＳＣＨリソースに特定のＰＵＣＣＨに対するＵＣＩを多重化してＵＣＩＯｎｌｙＰＵＳＣＨｗｉｔｈｏｕｔＵＬ－ＳＣＨを送信することができる。この時、ＵＣＩはＨＡＲＱ－ＡＣＫのみが存在する場合、端末はＰＵＳＣＨリソースによりＨＡＲＱ－ＡＣＫのみを送信する。この場合、以下のようにＨＡＲＱ－ＡＣＫにはＰＵＳＣＨ内の（利用可能な）全てのＲＥが割り当てられる。例えば、ＰＵＳＣＨリソース領域にＲＳが送信されるシンボル或いはＲＥを除いた全てのＲＥが割り当てられることができる。ＨＡＲＱ－ＡＣＫは一般的な規則によって１番目のＤＭ－ＲＳ以後のｎｏｎ－ＤＭ－ＲＳＯＦＤＭシンボルのみについてマッピングされるか（例：ＤＭＲＳ又はＤａｔａＭａｐｐｉｎｇＴｙｐｅＢである場合）、１番目のＤＭ－ＲＳ以前のＯＦＤＭシンボルにもマッパイングされることができる（例：ＤＭＲＳ又はＤａｔａＭａｐｐｉｎｇＴｙｐｅＡである場合）。

【0614】

（４）ＰＵＳＣＨに対してＵＬ－ＳＣＨ（或いはＵＬデータ）送信がないと指示され、Ａ－ＣＳＩ送信もないと指示された場合、端末は指示されたＰＵＳＣＨリソースを、ＵＬ－ＳＣＨ（又はＵＬデータ）を送信するがＵＣＩピギーバックを許容しないＰＵＳＣＨリソースと判断することができる。

【0615】

（５）ＰＵＳＣＨをスケジュールするＤＣＩ内にＵＣＩピギーバック（Ｏｎ／Ｏｆｆ）フィールド（以下、フィールドＡ）とＡ－ＣＳＩトリガー（Ｏｎ／Ｏｆｆ）フィールド（以下、フィールドＢ）がある場合、各フィールドの２つの状態の組み合わせである４個の状態で端末のＰＵＳＣＨスケジューリング情報を表現することができる。例えば、フィールドＡとフィールドＢにより以下のようにＰＵＳＣＨスケジューリング情報を表現することができる。ここで、フィールドＡのＯｎ／Ｏｆｆは、ＰＵＳＣＨ内のＵＣＩピギーバックが許容される場合（’Ｏｎ’）と、ＰＵＳＣＨ内のＵＣＩピギーバックが許容されない場合（’Ｏｆｆ’）を意味する。また、フィールドＢのＯｎ／Ｏｆｆは、Ａ－ＣＳＩ報告送信を指示する場合（’Ｏｎ’）と、Ａ－ＣＳＩ報告送信を指示しない場合（’Ｏｆｆ’）を意味する。

【0616】

－フィールドＡ＝’Ｏｎ’、フィールドＢ＝’Ｏｆｆ’

【0617】

・ＰＵＳＣＨ内にＵＬ－ＳＣＨが存在し、Ａ－ＣＳＩ報告が存在せず、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容

【0618】

－フィールドＡ＝’Ｏｎ’、フィールドＢ＝’Ｏｎ’

【0619】

・ＰＵＳＣＨ内にＵＬ－ＳＣＨが存在し、Ａ－ＣＳＩ報告が存在し、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容

【0620】

－フィールドＡ＝’Ｏｆｆ’、フィールドＢ＝’Ｏｆｆ’

【0621】

・ＰＵＳＣＨ内にＵＬ－ＳＣＨが存在し、Ａ－ＣＳＩ報告が存在せず、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容しない

【0622】

－フィールドＡ＝’Ｏｆｆ’、フィールドＢ＝’Ｏｎ’

【0623】

・ＰＵＳＣＨ内にＵＬ－ＳＣＨが存在せず、Ａ－ＣＳＩ報告が存在し、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容

【0624】

［提案方法＃９］端末が時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対するＵＣＩ多重化を行うとき、ＰＵＣＣＨ或いはＰＵＳＣＨに対する柔軟なＵＬタイミング設定によっては端末のプロセシング時間が足りないことができる。これを予防するために、（時間軸で）重畳したＰＵＣＣＨ（／ＰＵＳＣＨ）に対するＵＣＩ多重化の有無を判断するために、以下の２つのタイムライン条件が考えられる（以下、多重化タイムライン条件）。

【0625】

（１）ＨＡＲＱ－ＡＣＫに対応するＰＤＳＣＨの最後のシンボルは、（時間軸で）重畳するＰＵＣＣＨ／ＰＵＳＣＨのうちの最も早いチャネルの開始シンボルからＮ１⁺＝｛Ｎ１＋ｄ１｝シンボル前に受信、及び／又は

【0626】

（２）ＰＵＣＣＨ又はＰＵＳＣＨ送信を指示する（例：トリガー）ＰＤＣＣＨの最後のシンボルは、（時間軸で）重畳するＰＵＣＣＨ／ＰＵＳＣＨのうちの最も早いチャネルの開始シンボルからＮ２⁺＝｛Ｎ２＋ｄ２｝シンボル前に受信

【0627】

これに関連して、本発明の優先日前に公開された３ＧＰＰＴＳ３８．２１３Ｖ１５．２．０（２０１８－０６）（以下、３８．２１３）に以下のように規定されている。

【0628】

３ＧＰＰＴＳ３８．２１３Ｖ１５．２．０（２０１８－０６）：ＴｉｍｅｌｉｎｅｆｏｒＵＣＩＭｕｌｔｉｐｌｅｘｉｎｇ

【0629】

ここで、この提案におけるＮ１＋は３８．２１３のＮ１＋（＝Ｎ１＋１）＋ｄ_1,1＋ｄ_1,2に対応し、Ｎ２＋は３８．２１３のＮ₂＋（＝Ｎ₂＋１）＋ｄ_2,1に対応する。Ｎ１（又はＮ₁）は端末能力によって定義された最小のＰＤＳＣＨプロセシング時間を示し、Ｎ２（又はＮ₂）は端末能力によって定義された最小のＰＵＳＣＨプロセシング時間を示す。ｄ_x,xは０以上の定数であり、例えば、スケジュールされたシンボルの位置やＢＷＰスイッチングなどを考慮して予め定義された値である。

【0630】

表４及び表５は３８．２１３に定義されたＮ１とＮ２を各々例示する。

【0631】

【表4】

【0632】

【表5】

【0633】

図１３はタイムライン条件を考慮したＵＣＩ多重化を例示する。図１３を参照すると、端末は同一のスロットで複数のＵＬチャネル（例：ＵＬチャネル＃１～＃４）を送信する。ここで、ＵＬＣＨ＃１はＰＤＣＣＨ＃１によりスケジュールされたＰＵＳＣＨである。またＵＬＣＨ＃２はＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫを送信するためのＰＵＣＣＨである。ＰＤＳＣＨはＰＤＣＣＨ＃２によりスケジュールされ、ＵＬＣＨ＃２のリソースもＰＤＣＣＨ＃２により指示される。

【0634】

この時、時間軸で重畳するＵＬチャネル（例：ＵＬチャネル＃１～＃３）が多重化タイムライン条件を満たす場合、端末は時間軸で重畳したＵＬチャネル＃１～＃３に対してＵＣＩ多重化を行うことができる。具体的には、端末はＰＤＳＣＨの最後のシンボルからＵＬＣＨ＃３の最初のシンボルがＮ１＋ｄ１の条件を満たすか否かを確認する。また端末はＰＤＣＣＨ＃１の最後のシンボルからＵＬＣＨ＃３の最初のシンボルがＮ２＋ｄ２の条件を満たすか否かを確認する。多重化タイムライン条件を満たす場合、端末はＵＬチャネル＃１～＃３に対してＵＣＩ多重化を行う（例：提案方法＃１Ｃを参照）。反面、多重化タイムライン条件を満たさない場合は、端末はＵＣＩ多重化なしに、ＵＬチャネルの送信動作を行うことができる。この場合、ＵＬチャネル＃１～＃３は全て一緒に送信されるか、又はＵＣＩ／チャネル優先順位を考慮して、一部のＵＬチャネルは送信がスキップ／省略され、一部のＵＬチャネルのみが送信される。

【0635】

一方、ＮＲシステムは様々なＯＦＤＭニューマロロジー（例：ＳＣＳ）を支援し、端末プロセシング時間はＳＣＳによって以下を満たす値が与えられる。

【0636】

（１）シンボル数（例：Ｎ１⁺）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２^-u

【0637】

（２）シンボル数（例：Ｎ２⁺）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２^-u

【0638】

ここで、シンボル当たりのサンプル数は（２０４８＋１４４）であり、ＳＣＳが１５ｋＨｚである時のサンプリング時間は１／（２０４８＊１５０００）である。２０４８はＦＦＴサイズを示し、１４４はＣＰを構成するサンプル数を例示する。ｕは表１を参照することができる。

【0639】

タイムライン条件において、ｕは（スロット内で）時間軸で重畳するＵＬチャネルのＳＣＳに基づいて決定される。ここで、ＵＬチャネルはＰＵＣＣＨ／ＰＵＳＣＨを含む。この時、時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対して適用されたＯＦＤＭニューマロロジー（例：ＳＣＳ）が互いに同一である場合は、Ｎ１⁺、Ｎ２⁺に適用されるＳＣＳが明らかである。しかし、時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対して適用されたＯＦＤＭニューマロロジーが異なる場合には、Ｎ１⁺、Ｎ２⁺に適用されるＳＣＳが不明である。ここで、ＰＵＣＣＨ／ＰＵＳＣＨはＰＵＣＣＨ及び／又はＰＵＳＣＨを意味する。

【0640】

従って、この発明では、Ｎ１⁺、Ｎ２⁺に適用されるＳＣＳを以下のうちのいずれかの方式で決定する方法を提案する。

【0641】

（１）Ｏｐｔ．１：Ｎ１⁺、Ｎ２⁺に対して（時間軸で）重畳する全てのＵＬチャネルのＳＣＳのうち、最小のＳＣＳを適用する。Ｏｐｔ．１において、最小のＳＣＳを適用することは、相対的にＮ１⁺、Ｎ２⁺に適用されるシンボルサイズを大きく設定することにより、タイムライン条件を保守的に適用する方法である。

【0642】

（２）Ｏｐｔ．２：Ｎ１⁺、Ｎ２⁺に対して（時間軸で）重畳する全てのＵＬチャネルのうち、最も早いチャネルのＳＣＳを適用する。

【0643】

（３）Ｏｐｔ．３：Ｎ１⁺に対しては、Ａ／ＮＰＵＣＣＨ（或いはＡ／Ｎを含むＵＬチャネル）のＳＣＳを適用する。一方、Ｎ２⁺に対しては、ＰＤＣＣＨで送信指示される全てのＵＬチャネル（例：ＰＵＳＣＨ）のうち、最小ＳＣＳ（或いは最も早いＵＬチャネルのＳＣＳ）を適用する。Ａ／ＮＰＵＣＣＨはＨＡＲＱ－ＡＣＫの送信目的として設定／指示されたＰＵＣＣＨを意味する。

【0644】

一方、ＮＲシステムでは、ＰＤＣＣＨ、ＰＤＳＣＨ及びＵＬチャネル（例：ＰＵＣＣＨ／ＰＵＳＣＨ）のＳＣＳが全部異なることができる。これにより、端末プロセシング時間はＰＤＣＣＨＳＣＳ、ＰＤＳＣＨＳＣＳ及びＵＬチャネルのＳＣＳを全て考慮して決定される。例えば、端末プロセシング時間の計算に使用されるＳＣＳ（即ち、ｕ）は、ＰＤＣＣＨＳＣＳ、ＰＤＳＣＨＳＣＳ及びＵＬチャネルのＳＣＳの関数により与えられるか、又はこれらのうちの一つの値により与えられる。

【0645】

図１４は本発明により制御情報を送信する方法を例示する。

【0646】

図１４を参照すると、端末は基地局からＰＤＳＣＨを受信する（Ｓ１７０２）。ここで、ＰＤＳＣＨはＰＤＣＣＨ（例：ＤＣＩフォーマット１＿０、１＿１）によりスケジュールされる。図４を参照すると、ＰＤＣＣＨの受信時点からＫ０スロット後にＰＤＳＣＨ受信時点からＫ１スロット後にＰＤＳＣＨに関する応答情報（例：ＨＡＲＱ－ＡＣＫ応答）が第１ＵＬチャネル（例：ＰＵＣＣＨ）を介して送信される。第１ＵＬチャネルリソースはＰＤＣＣＨ内のＰＲＩにより指示される。一方、第１ＵＬチャネルの送信が指示されたスロットに複数のＵＬチャネルが割り当てられることができる。複数のＵＬチャネルは複数のＰＵＣＣＨを含む。また複数のＵＬチャネルはさらに一つ以上のＰＵＳＣＨを含む。この場合、端末はＵＣＩ多重化の有無を判断するために、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬチャネルのうちの最も早いＵＬチャネルとの間の時間間隔が基準時間を満たすか否かを確認する（Ｓ１７０４）。ここで、時間間隔は、（ｉ）ＰＤＳＣＨの最後のシンボルと、（ｉｉ）最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される。また複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む。その後、端末は基準時間を満たしたか否かによって、複数のＵＬチャネルに関連するＵＣＩを一つのＵＬチャネルで多重化することができる（Ｓ１７０６）。

【0647】

ここで、基準時間はシンボル数とＳＣＳに基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む。ここで、シンボルの長さはＳＣＳに基づいて決定され、シンボルの長さとＳＣＳは反比例する。例えば、基準時間は以下の値に基づいて決定される。

【0648】

－シンボル数（例：Ｎ１⁺）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２^-u

【0649】

ここで、Ｎ１⁺はＰＤＳＣＨ処理に必要な最小プロセシング時間を示し、ｕは０以上の整数であって、ＳＣＳに対応するインデックスを示す（表１を参照）。

【0650】

最も早いＵＬチャネルのＳＣＳは、複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい。時間間隔が基準時間より大きい場合、応答情報を含むＵＣＩは一つのＵＬチャネルに多重化されて送信され、時間間隔が基準時間より小さいか又は等しい場合は、端末は時間軸で重なる複数のＵＬチャネルに対してＵＣＩ多重化を行わない。従って、ＰＤＳＣＨに関する応答情報は多重化なしに第１ＵＬチャネルを介して送信される。

【0651】

また複数のＵＬチャネルがＰＤＣＣＨによりスケジュールされたＰＵＳＣＨを含む場合、端末はＵＣＩ多重化の有無を判断するために、（ｉ）ＰＤＣＣＨと、（ｉｉ）最も早いＵＬチャネルとの間の時間間隔が追加基準時間を満たすか否かをさらに確認する。この場合、追加基準時間を満たさないと、ＵＣＩ多重化が行われない。例えば、追加基準時間は以下の値に基づいて決定される。

【0652】

－シンボル数（例：Ｎ２⁺）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２^-u

【0653】

ここで、Ｎ２⁺はＰＵＳＣＨの準備に必要な最小プロセシング時間を示し、ｕは０以上の整数であって、ＳＣＳに対応するインデックスを示す（表１を参照）。

【0654】

図１５は本発明によるタイムライン条件を考慮したＵＣＩ多重化を例示する。図１５を参照すると、端末は同一のスロットにおいて複数のＵＬチャネル（例：ＵＬチャネル＃１～＃４）を送信する。ここで、ＵＬＣＨ＃１はＰＤＣＣＨ＃１によりスケジュールされたＰＵＳＣＨである。またＵＬＣＨ＃２はＰＤＳＣＨに対するＨＡＲＱ－ＡＣＫを送信するためのＰＵＣＣＨである。ＰＤＳＣＨはＰＤＣＣＨ＃２によりスケジュールされ、ＵＬＣＨ＃２のリソースもＰＤＣＣＨ＃２により指示される。この時、ＵＬＣＨ＃１～＃３のＳＣＳは各々ｕ＝１（ｕ１）、ｕ＝０（ｕ０）及びｕ＝２（ｕ２）であると仮定する（表１を参照）。

【0655】

この時、時間軸で重畳するＵＬチャネル（例：ＵＬチャネル＃１～＃３）が多重化タイムライン条件を満たす場合、端末は時間軸で重畳するＵＬチャネル＃１～＃３に対してＵＣＩ多重化を行う。具体的には、端末はＰＤＳＣＨの最後のシンボルからＵＬＣＨ＃３の最初シンボルがＮ１＋ｄ１の条件を満たすか否かを確認する。また端末はＰＤＣＣＨ＃１の最後のシンボルからＵＬＣＨ＃３の最初のシンボルがＮ２＋ｄ２の条件を満たすか否かを確認する。一方、｛Ｎ１＋ｄ１｝及び｛Ｎ２＋ｄ２｝には、ＵＬＣＨ＃１～＃３のＳＣＳのうちの最小のＳＣＳが適用される（即ち、ＵＬＣＨ＃１；ｕ＝０）。多重化タイムライン条件を満たす場合、端末はＵＬチャネル＃１～＃３に対してＵＣＩ多重化を行うことができる（例：提案方法＃１Ｃを参照）。反面、多重化タイムライン条件を満たさない場合、端末はＵＣＩ多重化なしに、ＵＬチャネルの送信動作を行うことができる。この場合、ＵＬチャネル＃１～＃３は全て一緒に送信されるか、又はＵＣＩ／チャネル優先順位を考慮して、一部のＵＬチャネルは送信がスキップ／省略され、一部のＵＬチャネルのみが送信される。例えば、ＵＣＩがＨＡＲＱ－ＡＣＫ応答とＣＳＩがある場合、ＵＣＩ優先順位に従ってＣＳＩ送信がスキップ／省略されることができる。

【0656】

［提案方法＃１０］ＮＲシステムにおいて、基地局は端末に複数のＳＲリソースを設定する。ＳＲリソースがＰＵＣＣＨフォーマット１のリソースである場合、端末は同時送信が指示されたＫ個のＳＲリソースのうち、（優先順位が高い）１個のＳＲリソースのみを選択して送信する（例：チャネル／リソース選択）。この時、Ｋ値によって基地局でＳＲ受信のために仮定する仮定（ｈｙｐｏｔｈｅｓｉｓ）の数が増加し、ＵＣＩ送信性能が低下することができる。従って、この提案では、端末に一つ以上のＫ個のＳＲリソースが（時間上重畳するように）設定され、以下のうちのいずれかの場合について、Ｋ値の関数で表現される（或いはＫ値に比例する）電力オフセットをＰＵＣＣＨ送信に反映する方法を提案する。

【0657】

（１）Ｃａｓｅ１：Ｋ個のＳＲリソースのうちの一つのＳＲリソースを選択して送信する場合

【0658】

（２）Ｃａｓｅ２：Ｋ個のＳＲリソース及びＡ／Ｎリソースのうちの一つのリソースを選択して該当リソースでＡ／Ｎを送信する場合

【0659】

ここで、電力オフセットはＫ値に比例する。例えば、電力オフセットはＫ（又は、Ｋ－１）又はｌｏｇ₂（Ｋ）（又は、ｌｏｇ₂（Ｋ－１））又はｃｅｉｌ（ｌｏｇ₂（Ｋ））（又は、ｃｅｉｌ（ｌｏｇ₂（Ｋ－１））の関数である。ｃｅｉｌ（）は切り上げ関数である。これにより、ＰＵＣＣＨ送信電力はＫ値に比例して増加する。

【0660】

ここで、２つのケースに対する電力オフセットは互いに異なる形態である。Ｃａｓｅ２の場合、さらにＡ／Ｎが送信されるので、Ｃａｓｅ１に比較して相対的に大きい電力オフセットが適用される。またこの提案はＳＲとＡ／Ｎに対して割り当てられたＰＵＣＣＨリソースがＰＵＣＣＨフォーマット１である場合に限られる。

【0661】

図１６は本発明に適用される通信システム１を例示する。

【0662】

図１６を参照すると、本発明に適用される通信システム１は、無線機器、基地局及びネットワークを含む。ここで、無線機器は無線アクセス技術（例えば、５ＧＮＲ、ＬＴＥ）を用いて通信を行う機器を意味し、通信／無線／５Ｇ機器とも称される。これに限られないが、無線機器はロボット１００ａ、車両１００ｂ－１，１００ｂ－２、ＸＲ（ｅＸｔｅｎｄｅｄＲｅａｌｉｔｙ）機器１００ｃ、携帯機器（Ｈａｎｄ－ｈｅｌｄＤｅｖｉｃｅ）１００ｄ、家電１００ｅ、ＩｏＴ（ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇ）機器１００ｆ及びＡＩサーバ／機器４００を含む。例えば、車両は無線通信機能が備えられた車両、自律走行車両、車両間通信を行える車両などを含む。ここで、車両はＵＡＶ（ＵｎｍａｎｎｅｄＡｅｒｉａｌＶｅｈｉｃｌｅ）（例えば、ドローン）を含む。ＸＲ機器はＡＲ（ＡｕｇｍｅｎｔｅｄＲｅａｌｉｔｙ）／ＶＲ（ＶｉｒｔｕａｌＲｅａｌｉｔｙ）／ＭＲ（ＭｉｘｅｄＲｅａｌｉｔｙ）機器を含み、ＨＭＤ（Ｈｅａｄ－ＭｏｕｎｔｅｄＤｅｖｉｃｅ）、車両に備えられたＨＵＤ（Ｈｅａｄ－ＵｐＤｉｓｐｌａｙ）、ＴＶ、スマートホン、コンピュータ、ウェアラブルデバイス、家電機器、デジタル看板、車両、ロボットなどの形態で具現化される。携帯機器はスマートホン、スマートパッド、ウェアラブル機器（例えば、スマートウォッチ、スマートグラス）、コンピュータ（例えば、ノートブックパソコンなど）などを含む。家電はＴＶ、冷蔵庫、洗濯機などを含む。ＩｏＴ機器はセンサ、スマートメータなどを含む。例えば、基地局、ネットワークは無線機器にも具現化され、特定の無線機器２００ａは他の無線機器に基地局／ネットワークノードで動作することもできる。

【0663】

無線機器１００ａ～１００ｆは基地局２００を介してネットワーク３００に連結される。無線機器１００ａ～１００ｆにはＡＩ（ＡｒｔｉｆｉｃｉａｌＩｎｔｅｌｌｉｇｅｎｃｅ）技術が適用され、無線機器１００ａ～１００ｆはネットワーク３００を介してＡＩサーバ４００に連結される。ネットワーク３００は３Ｇネットワーク、４Ｇ（例えば、ＬＴＥ）ネットワーク又は５Ｇ（例えば、ＮＲ）ネットワークなどを用いて構成される。無線機器１００ａ～１００ｆは基地局２００／ネットワーク３００を介して互いに通信できるが、基地局／ネットワークを介することなく、直接通信することもできる（例えば、サイドリンク通信）。例えば、車両１００ｂ－１、１００ｂ－２は直接通信することができる（例えば、Ｖ２Ｖ（ＶｅｈｉｃｌｅｔｏＶｅｈｉｃｌｅ）／Ｖ２Ｘ（Ｖｅｈｉｃｌｅｔｏｅｖｅｒｙｔｈｉｎｇ）通信）。またＩｏＴ機器（例えば、センサ）は他のＩｏＴ機器（例えば、センサ）又は他の無線機器１００ａ～１００ｆと直接通信することができる。

【0664】

無線機器１００ａ～１００ｆ／基地局２００、基地局２００／基地局２００の間には無線通信／連結１５０ａ、１５０ｂ、１５０ｃが行われる。ここで、無線通信／連結は上り／下りリンク通信１５０ａとサイドリンク通信１５０ｂ（又は、Ｄ２Ｄ通信）、基地局間の通信１５０ｃ（例えば、ｒｅｌａｙ、ＩＡＢ（ＩｎｔｅｇｒａｔｅｄＡｃｃｅｓｓＢａｃｋｈａｕｌ）のような様々な無線アクセス技術により行われる（例えば、５ＧＮＲ）。無線通信／連結１５０ａ、１５０ｂ、１５０ｃにより無線機器と基地局／無線機器、基地局と基地局は互いに無線信号を送信／受信することができる。例えば、無線通信／連結１５０ａ、１５０ｂ、１５０ｃは様々な物理チャネルを介して信号を送信／受信することができる。このために、本発明の様々な提案に基づいて、無線信号の送信／受信のための様々な構成情報の設定過程、様々な信号処理過程（例えば、チャネル符号化／復号、変調／復調、リソースマッピング／デマッピングなど）、リソース割り当て過程のうちのいずれか１つが行われる。

【0665】

図１７は本発明に適用可能な無線機器を例示する。

【0666】

図１７を参照すると、第１無線機器１００と第２無線機器２００は様々な無線アクセス技術（例えば、ＬＴＥ、ＮＲ）により無線信号を送受信する。ここで、｛第１無線機器１００、第２無線機器２００｝は図１６の｛無線機器１００ａ～１００ｆ、基地局２００｝及び／又は｛無線機器１００ａ～１００ｆ、無線機器１００ａ～１００ｆ｝に対応する。

【0667】

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

【0668】

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

【0669】

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

【0670】

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

【0671】

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

【0672】

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

【0673】

図１８は本発明に適用される無線機器の他の例を示す。無線機器は使用例／サービスによって様々な形態で具現化される（図１６を参照）。

【0674】

図１８を参照すると、無線機器１００，２００は図１７の無線機器１００，２００に対応し、様々な要素（ｅｌｅｍｅｎｔ）、部品（ｃｏｍｐｏｎｅｎｔ）、ユニット／部及び／又はモジュールで構成される。例えば、無線機器１００，２００は通信部１１０、制御部１２０、メモリ部１３０及び追加要素１４０を含む。通信部は通信回路１１２及び送受信機１１４を含む。例えば、通信回路１１２は図１７における１つ以上のプロセッサ１０２，２０２及び／又は１つ以上のメモリ１０４，２０４を含む。例えば、送受信機１１４は図１７の１つ以上の送受信機１０６，２０６及び／又は１つ以上のアンテナ１０８，２０８を含む。制御部１２０は通信部１１０、メモリ部１３０及び追加要素１４０に電気的に連結され、無線機器の諸般の動作を制御する。例えば、制御部１２０はメモリ部１３０に格納されたプログラム／コード／命令／情報に基づいて無線機器の電気的／機械的動作を制御する。また制御部１２０はメモリ部１３０に格納された情報を通信部１１０により外部（例えば、他の通信機器）に無線／有線インターフェースにより送信するか、又は通信部１１０により外部（例えば、他の通信機器）から無線／有線インターフェースにより受信された情報をメモリ部１３０に格納する。

【0675】

追加要素１４０は無線機器の種類によって様々に構成される。例えば、追加要素１４０はパワーユニット／バッテリー、入出力部（Ｉ／Ｏｕｎｉｔ）、駆動部及びコンピュータ部のうち、いずれか１つを含む。これに限られないが、無線機器はロボット（図１６、１００ａ）、車両（図１６、１００ｂ－１、１００ｂ－２）、ＸＲ機器（図１６、１００ｃ）、携帯機器（図１６、１００ｄ）、家電（図１６、１００ｅ）、ＩｏＴ機器（図１６、１００ｆ）、デジタル放送用端末、ホログラム装置、公共安全装置、ＭＴＣ装置、医療装置、フィンテック装置（又は金融装置）、保安装置、気候／環境装置、ＡＩサーバ／機器（図１６、４００）、基地局（図１６、２００）及びネットワークノードなどの形態で具現化される。無線機器は使用例／サービスによって移動可能であるか、又は固定した場所で使用される。

【0676】

図１８において、無線機器１００，２００内の様々な要素、部品、ユニット／部及び／又はモジュールは全体が有線インターフェースにより互いに連結されるか、又は少なくとも一部が通信部１１０により無線連結される。例えば、無線機器１００，２００内で制御部１２０と通信部１１０は有線連結され、制御部１２０と第１ユニット（例えば、１３０、１４０）は通信部１１０により無線連結される。また無線機器１００，２００内の各要素、部品、ユニット／部及び／又はモジュールは１つ以上の要素をさらに含む。例えば、制御部１２０は１つ以上のプロセッサの集合で構成される。例えば、制御部１２０は通信制御プロセッサ、アプリケーションプロセッサ（ＡｐｐｌｉｃａｔｉｏｎＰＲＯＣＥＳＳＯＲ）、ＥＣＵ（ＥｌｅｃｔｒｏｎｉｃｃｏｎｔｒｏｌＵｎｉｔ）、グラフィック処理プロセッサ、メモリ制御プロセッサなどの集合で構成される。他の例として、メモリ部１３０はＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、ＤＲＡＭ（ＤｙｎａｍｉｃＲＡＭ）、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）、フラッシュメモリ（ｆｌａｓｈＭｅｍｏｒｙ）、揮発性メモリ（ｖｏｌａｔｉｌｅＭｅｍｏｒｙ）、非揮発生メモリ及び／又はこれらの組み合わせで構成される。

【0677】

図１９は本発明に適用される車両又は自律走行車両を例示する図である。車両又は自律走行車両は移動型ロボット、車両、電車、有人／無人飛行体（ＡｅｒｉａｌＶｅｈｉｃｌｅ、ＡＶ）、船舶などで具現化される。

【0678】

図１９を参照すると、車両又は自律走行車両１００はアンテナ部１０８、通信部１１０、制御部１２０、駆動部１４０ａ）、電源供給部１４０ｂ、センサ部１４０ｃ及び自律走行部１４０ｄを含む。アンテナ部１０８は通信部１１０の一部で構成される。ブロック１１０／１３０／１４０ａ～１４０ｄは各々図１８におけるブロック１１０／１３０／１４０に対応する。

【0679】

通信部１１０は他の車両、基地局（例えば、基地局、路辺基地局（ＲｏａｄＳｉｄｅｕｎｉｔ）など）、サーバなどの外部機器と信号（例えば、データ、制御信号など）を送受信する。制御部１２０は車両又は自律走行車両１００の要素を制御して様々な動作を行う。制御部１２０はＥＣＵ（ＥｌｅｃｔｒｏｎｉｃｃｏｎｔｒｏｌＵｎｉｔ）を含む。駆動部１４０ａにより車両又は自律走行車両１００が地上で走行する。駆動部１４０ａはエンジン、モータ、パワートレイン、車輪、ブレーキ、ステアリング装置などを含む。電源供給部１４０ｂは車両又は自律走行車両１００に電源を供給し、有線／無線充電回路、バッテリーなどを含む。センサ部１４０ｃは車両状態、周辺環境情報、ユーザ情報などを得ることができる。センサ部１４０ｃはＩＭＵ（ｉｎｅｒｔｉａｌｍｅａｓｕｒｅｍｅｎｔｕｎｉｔ）センサ、衝突センサ、ホイールセンサ（ｗｈｅｅｌｓｅｎｓｏｒ）、速度センサ、傾斜センサ、重量感知センサ、ヘッディングセンサ（ｈｅａｄｉｎｇｓｅｎｓｏｒ）、ポジションモジュール（ｐｏｓｉｔｉｏｎｍｏｄｕｌｅ）、車両前進／後進センサ、バッテリーセンサ、燃料センサ、タイヤセンサ、ステアリングセンサ、温度センサ、湿度センサ、超音波センサ、照度センサ、ペダルポジションセンサなどを含む。自律走行部１４０ｄは走行中の車線を維持する技術、車間距離制御装置（ａｄａｐｔｉｖｅｃｒｕｉｓｅｃｏｎｔｒｏｌ）のように速度を自動に調節する技術、所定の経路によって自動走行する技術、目的地が設定されると自動に経路を設定して走行する技術などを具現化する。

【0680】

一例として、通信部１１０は外部サーバから地図データ、交通情報データなどを受信する。自律走行部１４０ｄは得られたデータに基づいて自律走行経路とドライブプランを生成する。制御部１２０はドライブプランに従って車両又は自律走行車両１００が自律走行経路に移動するように駆動部１４０ａを制御する（例えば、速度／方向調節）。通信部１１０は自律走行中に外部サーバから最新交通情報データを非周期的に得る、また、周りの車両から周りの交通情報データを得る。またセンサ部１４０ｃは自律走行中に車両状態、周辺環境情報を得る。自律走行部１４０ｄは新しく得たデータ／情報に基づいて自律走行経路とドライブプランを更新する。通信部１１０は車両位置、自律走行経路、ドライブプランなどに関する情報を外部サーバに伝達する。外部サーバは車両又は自律走行車両から集められた情報に基づいて、ＡＩ技術などを用いて交通情報データを予め予測し、予測された交通情報データを車両又は自律走行車両に提供することができる。

【0681】

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

【0682】

本発明は、本発明の特徴を逸脱しない範囲で他の特定の形態に具体化できることは当業者にとって自明である。よって、前記の詳細な説明は、全ての面で制限的に解釈してはならなく、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的解釈によって決定しなければならず、本発明の等価的範囲内での全ての変更は本発明の範囲に含まれる。

【産業上の利用可能性】

【0683】

本発明は無線移動通信システムの端末機、基地局又はその他の装備に使用できる。

【図1】