(57)【要約】本発明は無線通信システムに関し、具体的には、ＰＤＳＣＨを受信する段階と、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Ｕｐｌｉｎｋ）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定する段階であって、複数のＵＬチャネルは、ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む段階と、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のＵＬチャネルに関連するＵＣＩを多重化する段階と、を含み、基準時間間隔は、シンボルの数とＳＣＳとに基づいて決定され、ＳＣＳは、複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む方法及びそのための装置に関する。【選択図】図１４
2021506195.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおいて通信装置が制御情報を送信する方法であって、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信する段階と、
（ｉ）前記ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Uplink）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定する段階であって、前記複数のＵＬチャネルは、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む、段階と、
前記時間間隔が基準時間間隔と等しい又は前記基準時間間隔より大きいことに基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化する段階と、を含み、
前記基準時間間隔は、シンボルの数とＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記ＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む、方法。
【請求項２】
前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい、請求項１に記載の方法。
【請求項３】
前記時間間隔が前記基準時間間隔と等しい又は前記基準時間間隔より大きい場合、前記応答情報を含むＵＣＩは、一つのＵＬチャネルに多重化されて送信され、
前記時間間隔が前記基準時間間隔より小さい場合、
前記応答情報は、多重化されずに前記第１ＵＬチャネルを介して送信される、又は、
前記複数のＵＬチャネル送信は、全て省略される、請求項１に記載の方法。
【請求項４】
前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと、（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項１に記載の方法。
【請求項５】
前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項１に記載の方法。
【請求項６】
前記複数のＵＬチャネルがＰＤＣＣＨ（Physical Downlink Control Channel）によりスケジュールされたＰＵＳＣＨ（Physical Uplink Shared Channel）を含む場合、（ｉ）前記ＰＤＣＣＨと（ｉｉ）前記最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔を満たすか否かをさらに確認することを含む、請求項１に記載の方法。
【請求項７】
前記シンボルの長さは、ＳＣＳに基づいて決定され、
シンボルの長さとＳＣＳは、反比例する、請求項１に記載の方法。
【請求項８】
無線通信システムに使用される通信装置であって、
メモリと、
プロセッサと、を含み、
前記プロセッサは、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信し、
（ｉ）前記ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Uplink）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定し、前記複数のＵＬチャネルは、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、
前記時間間隔が基準時間間隔と等しい又は前記基準時間間隔より大きいことに基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化するように構成され、
前記基準時間間隔は、シンボルの数とＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記ＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む、通信装置。
【請求項９】
前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい、請求項８に記載の通信装置。
【請求項１０】
前記時間間隔が前記基準時間間隔と等しい又は前記基準時間間隔より大きい場合、前記応答情報を含むＵＣＩは、一つのＵＬチャネルに多重化されて送信され、
前記時間間隔が前記基準時間間隔より小さい場合、
前記応答情報は、多重化されずに前記第１ＵＬチャネルを介して送信される、又は、
前記複数のＵＬチャネル送信は、全て省略される、請求項８に記載の通信装置。
【請求項１１】
前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと、（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項８に記載の通信装置。
【請求項１２】
前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項８に記載の通信装置。
【請求項１３】
前記複数のＵＬチャネルがＰＤＣＣＨ（Physical Downlink Control Channel）によりスケジュールされたＰＵＳＣＨ（Physical Uplink Shared Channel）を含む場合、（ｉ）前記ＰＤＣＣＨと（ｉｉ）前記最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔を満たすか否かをさらに確認することを含む、請求項８に記載の通信装置。
【請求項１４】
前記シンボルの長さは、ＳＣＳに基づいて決定され、
シンボルの長さとＳＣＳは、反比例する、請求項８に記載の通信装置。
【請求項１５】
前記通信装置は、少なくとも端末、ネットワーク及び前記通信装置以外の他の自律走行車両と通信可能な自律走行車両を含む、請求項８に記載の通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信システムに関し、より具体的には無線信号の送受信方法及び装置に関する。
【背景技術】
【０００２】
無線通信システムが音声やデータなどの種々の通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは利用可能なシステムリソース（帯域幅、伝送パワーなど）を共有して多重使用者との通信を支援することができる多元接続（ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システムである。多元接続システムの例としては、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システム、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システム、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システム、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システム、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）システムなどがある。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明の目的は、無線信号の送受信過程を効率的に行う方法及びそのための装置を提供することにある。
【０００４】
本発明で達成しようとする技術的課題は前記技術的課題に制限されず、言及しなかった他の技術的課題は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。
【課題を解決するための手段】
【０００５】
本発明の一様相において、無線通信システムにおいて通信装置が制御情報を送信する方法であって、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を受信する段階と、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Ｕｐｌｉｎｋ）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定する段階であって、複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む、段階と、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のＵＬチャネルに関連するＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を多重化する段階と、を含み、基準時間間隔はシンボルの数とＳＣＳ（Ｓｕｂｃａｒｒｉｅｒ  Ｃａｒｒｉｅｒ  Ｓｐａｃｉｎｇ）とに基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む方法が提供される。
【０００６】
本発明の他の様相において、無線通信システムに使用される通信装置であって、メモリとプロセッサとを含み、該プロセッサは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を受信し、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬ（Ｕｐｌｉｎｋ）チャネルのうちの最も早いＵＬチャネルとの間の時間間隔を決定し、複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のＵＬチャネルに関連するＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を多重化するように構成され、基準時間間隔はシンボルの数とＳＣＳ（Ｓｕｂｃａｒｒｉｅｒ  Ｃａｒｒｉｅｒ  Ｓｐａｃｉｎｇ）に基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む通信装置が提供される。
【０００７】
好ましくは、最も早いＵＬチャネルのＳＣＳは、複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい。
【０００８】
好ましくは、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きい場合、応答情報を含むＵＣＩは一つのＵＬチャネルに多重化されて送信され、時間間隔が基準時間間隔より小さい場合、応答情報は多重化されず第１ＵＬチャネルを介して送信される、又は、複数のＵＬチャネル送信は全て省略される。
【０００９】
好ましくは、時間間隔は、（ｉ）ＰＤＳＣＨの最後のシンボルと、（ｉｉ）最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される。
【００１０】
好ましくは、複数のＵＬチャネルはＰＵＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）を含む。
【００１１】
好ましくは、複数のＵＬチャネルがＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）によりスケジュールされたＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を含む場合、（ｉ）ＰＤＣＣＨと（ｉｉ）最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔を満たすか否かをさらに確認することを含む。
【００１２】
好ましくは、シンボルの長さはＳＣＳに基づいて決定され、シンボルの長さとＳＣＳは反比例する。
【００１３】
好ましくは、通信装置は少なくとも端末、ネットワーク及び通信装置以外の他の自律走行車両と通信可能な自律走行車両を含む。
【００１４】
好ましくは、さらに通信装置はＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）ユニットを含む。
【発明の効果】
【００１５】
本発明によれば、無線通信システムにおいて無線信号の送受信を効率的に行うことができる。
【００１６】
本発明で得られる効果は以上で言及した効果に制限されず、言及しなかった他の効果は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。
【図面の簡単な説明】
【００１７】
本発明に関する理解を助けるために詳細な説明の一部として含まれる添付図面は本発明の実施例を提供し、詳細な説明とともに本発明の技術的思想を説明する。
【００１８】
【図１】無線通信システムの一例である３ＧＰＰシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。
【図２】無線フレームの構造を例示する図である。
【図３】スロットのリソースグリッドを例示する図である。
【図４】ＡＣＫ／ＮＡＣＫ送信過程を例示する図である。
【図５】ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）送信過程を例示する図である。
【図６】制御情報をＰＵＳＣＨに多重化する例を示す図である。
【図７】本発明による信号送信を例示する図である。
【図８】本発明による信号送信を例示する図である。
【図９】本発明による信号送信を例示する図である。
【図１０】本発明による信号送信を例示する図である。
【図１１】本発明による信号送信を例示する図である。
【図１２】本発明による信号送信を例示する図である。
【図１３】本発明による信号送信を例示する図である。
【図１４】本発明による信号送信を例示する図である。
【図１５】本発明による信号送信を例示する図である。
【図１６】本発明に適用可能な通信システム及び無線機器を例示する図である。
【図１７】本発明に適用可能な通信システム及び無線機器を例示する図である。
【図１８】本発明に適用可能な通信システム及び無線機器を例示する図である。
【図１９】本発明に適用可能な通信システム及び無線機器を例示する図である。
【発明を実施するための形態】
【００１９】
以下の技術は、ＣＤＭＡ（ｃｏｄｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＦＤＭＡ（ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＴＤＭＡ（ｔｉｍｅ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＯＦＤＭＡ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）、ＳＣ−ＦＤＭＡ（ｓｉｎｇｌｅ  ｃａｒｒｉｅｒ  ｆｒｅｑｕｅｎｃｙ  ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）などのような様々な無線アクセスシステムに用いることができる。ＣＤＭＡは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）やＣＤＭＡ２０００のような無線技術（ｒａｄｉｏ  ｔｅｃｈｎｏｌｏｇｙ）によって具現化することができる。ＴＤＭＡは、ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）／ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  Ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）のような無線技術によって具現化することができる。ＯＦＤＭＡは、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２−２０、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  ＵＴＲＡ）などのような無線技術によって具現化することができる。ＵＴＲＡは、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）の一部である。３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）は、Ｅ−ＵＴＲＡを用いるＥ−ＵＭＴＳ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ）の一部であり、ＬＴＥ−Ａは３ＧＰＰ  ＬＴＥの進化したバージョンである。３ＧＰＰ  ＮＲ（Ｎｅｗ  Ｒａｄｉｏ  ｏｒ  Ｎｅｗ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｔｅｃｈｎｏｌｏｇｙ）は３ＧＰＰ  ＬＴＥ／ＬＴＥ−Ａの進化したバージョンである。
【００２０】
より多い通信機器がより大きい通信容量を要求することにより、既存の無線アクセス技術（ｒａｄｉｏ  Ａｃｃｅｓｓ  ｔｅｃｈｎｏｌｏｇｙ、ＲＡＴ）に比べて向上した無線広帯域（ｍｏｂｉｌｅ  ｂｒｏａｄｂａｎｄ、ｅＭＢＢ）通信に対する必要性が台頭しつつある。また、複数の機器及びモノを連結していつでもどこでも様々なサービスを提供する大規模ＭＴＣ（ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）が次世代通信において考慮すべき重要なイッシュの一つである。のみならず、信頼度（ｒｅｌｉａｂｉｌｉｔｙ）及びレイテンシ（ｌａｔｅｎｃｙ）に敏感なサービス／ＵＥを考慮したＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）が論議されている。このようにｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  ＢｒｏａｄＢａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、大規模ＭＴＣ、ＵＲＬＬＣ（Ｕｌｔｒａ−Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）などを考慮した次世代ＲＡＴの導入が論議されており、本発明では、便宜上、該当技術をＮＲ（Ｎｅｗ  ｒａｄｉｏ又はＮｅｗ  ＲＡＴ）と呼ぶ。
【００２１】
説明を明確にするために、３ＧＰＰ  ＮＲを主として説明するが、本発明の技術的思想はこれに限られない。
【００２２】
無線通信システムにおいて、端末は基地局から下りリンク（Ｄｏｗｎｌｉｎｋ、ＤＬ）を介して情報を受信し、端末は基地局から上りリンク（Ｕｐｌｉｎｋ、ＵＬ）を介して情報を伝送する。基地局と端末が送受信する情報はデータ及び様々な制御情報を含み、これらが送受信する情報の種類／用途によって様々な物理チャネルが存在する。
【００２３】
図１は３ＧＰＰ  ＮＲシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。
【００２４】
電源Ｏｆｆ状態で電源を入れたか或いは新しくセルに進入した端末は、段階Ｓ１０１において、基地局と同期を確立するなどの初期セルサーチ（Ｉｎｉｔｉａｌ  ｃｅｌｌ  ｓｅａｒｃｈ）作業を行う。このために、端末は基地局から主同期チャネル（Ｐｒｉｍａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ、Ｐ−ＳＣＨ）及び副同期チャネル（Ｓｅｃｏｎｄａｒｙ  Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  Ｃｈａｎｎｅｌ、Ｓ−ＳＣＨ）を受信して基地局と同期を確立し、セルＩＤ（ｃｅｌｌ  ｉｄｅｎｔｉｔｙ）などの情報を得る。その後、端末は基地局から物理ブロードキャストチャネル（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ、ＰＢＣＨ）を受信してセル内のブロードキャスト情報を得る。なお、端末は初期セルサーチの段階において、下りリンク参照信号（Ｄｏｗｎｌｉｎｋ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ、ＤＬ  ＲＳ）を受信して下りリンクチャネルの状態を確認できる。
【００２５】
初期セルサーチが終了した端末は、段階Ｓ１０２において、物理下りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＤＣＣＨ）及び物理下りリンク制御チャネルの情報に基づく物理下りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＤＳＣＨ）を受信して、より具体的なシステム情報を得る。
【００２６】
以後、端末は基地局に接続を完了するために、段階Ｓ１０３乃至段階Ｓ１０６のようなランダムアクセス過程（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｒｏｃｅｄｕｒｅ）を行う。このために端末は、物理ランダムアクセスチャネル（Ｐｈｙｓｉｃａｌ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｃｈａｎｎｅｌ、ＰＲＡＣＨ）を介してプリアンブル（ｐｒｅａｍｂｌｅ）を伝送し（Ｓ１０３）、物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルを介してプリアンブルに対する応答メッセージを受信する（Ｓ１０４）。コンテンションベースのランダムアクセス（Ｃｏｎｔｅｎｔｉｏｎ  ｂａｓｅｄ  ｒａｎｄｏｍ  ａｃｃｅｓｓ）の場合、さらなる物理ランダムアクセスチャネルの伝送（Ｓ１０５）、物理下りリンク制御チャネル及びそれに対応する物理下りリンク共有チャネルの受信（Ｓ１０６）のような競合解決手順（Ｃｏｎｔｅｎｔｉｏｎ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｃｅｄｕｒｅ）を行う。
【００２７】
このような手順を行った端末は、その後一般的な上り／下りリンク信号の伝送手順として物理下りリンク制御チャネル／物理下りリンク共有チャネルの受信（Ｓ１０７）、及び物理上りリンク共有チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ、ＰＵＳＣＨ）／物理上りリンク制御チャネル（Ｐｈｙｓｉｃａｌ  Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ、ＰＵＣＣＨ）の伝送を行う（Ｓ１０８）。端末が基地局に伝送する制御情報を併せて上りリンク制御情報（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ、ＵＣＩ）と称する。ＵＣＩは、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ（Ｈｙｂｒｉｄ  Ａｕｔｏｍａｔｉｃ  Ｒｅｐｅａｔ  ａｎｄ  ｒｅＱｕｅｓｔ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ／Ｎｅｇａｔｉｖｅ−ＡＣＫ）、ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）、ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）などを含む。ＣＳＩは、ＣＱＩ（Ｃｈａｎｎｅｌ  Ｑｕａｌｉｔｙ  Ｉｎｄｉｃａｔｏｒ）、ＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｉｏｎ）などを含む。ＵＣＩは一般的にＰＵＣＣＨを介して伝送されるが、制御情報とトラフィックデータが同時に伝送される必要がある場合にはＰＵＳＣＨを介して伝送される。また、ネットワークの要求／指示によってＰＵＳＣＨを介してＵＣＩを非周期的に伝送することができる。
【００２８】
図２は無線フレームの構造を例示する図である。ＮＲにおいて、上りリンク及び下りリンク送信はフレームで構成される。無線フレームは１０ｍｓの長さを有し、２個の５ｍｓハーフフレーム（Ｈａｌｆ−Ｆｒａｍｅ、ＨＦ）で定義される。ハーフフレームは５個の１ｍｓサブフレーム（Ｓｕｂｆｒａｍｅ、ＳＦ）で定義される。サブフレームは１つ以上のスロットに分割され、サブフレーム内のスロット数はＳＣＳ（Ｓｕｂｃａｒｒｉｅｒ  Ｓｐａｃｉｎｇ）に依存する。各スロットはＣＰ（ｃｙｃｌｉｃ  ｐｒｅｆｉｘ）によって１２個又は１４個のＯＦＤＭ（Ａ）シンボルを含む。一般ＣＰが使用される場合、各スロットは１４個のシンボルを含む。拡張ＣＰが使用される場合は、各スロットは１２個のシンボルを含む。
【００２９】
表１は一般ＣＰが使用される場合、ＳＣＳによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。
【００３０】
【表１】
2021506195.tif 000003
【００３１】
＊Ｎslotsymb：スロット内のシンボル数
【００３２】
＊Ｎframe,uslot：フレーム内のスロット数
【００３３】
＊Ｎsubframe,uslot：サブフレーム内のスロット数
【００３４】
表２は拡張ＣＰが使用される場合、ＳＣＳによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。
【００３５】
【表２】
2021506195.tif 000004
【００３６】
フレーム構造は例示に過ぎず、フレームにおいてサブフレーム数、スロット数及びシンボル数は様々に変更できる。
【００３７】
ＮＲシステムでは１つの端末に併合される複数のセル間でＯＦＤＭニューマロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ）が異なるように設定されることができる。これにより、同じ数のシンボルで構成された時間リソース（例えば、ＳＦ、スロット又はＴＴＩ）（便宜上、ＴＵ（Ｔｉｍｅ  Ｕｎｉｔ）と称する）の（絶対時間）区間が併合されたセル間で異なるように設定されることができる。ここで、シンボルはＯＦＤＭシンボル（或いはＣＰ−ＯＦＤＭシンボル）、ＳＣ−ＦＤＭＡシンボル（或いはＤｉｓｃｒｅｔｅ  Ｆｏｕｒｉｅｒ  Ｔｒａｎｓｆｏｒｍ−ｓｐｒｅａｄ−ＯＦＤＭ、ＤＦＴ−ｓ−ＯＦＤＭシンボル）を含む。
【００３８】
図３はスロットのリソースグリッド（ｒｅｓｏｕｒｃｅ  ｇｒｉｄ）を例示する図である。スロットは時間ドメインで複数のシンボルを含む。例えば、一般ＣＰの場合、１つのスロットが１４個のシンボルを含むが、拡張ＣＰの場合は、１つのスロットが１２個のシンボルを含む。搬送波は周波数ドメインで複数の副搬送波を含む。ＲＢ（Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）は周波数ドメインで複数（例えば、１２）の連続する副搬送波で定義される。ＢＷＰは周波数ドメインで複数の連続するＰＲＢ（Ｐｈｙｓｉｃａｌ  ＲＢ）で定義され、１つのニューマロロジー（ｎｕｍｅｒｏｌｏｇｙ）（例えば、ＳＣＳ、ＣＰの長さなど）に対応することができる。搬送波は最大Ｎ個（例えば、５個）のＢＷＰを含む。データ通信は活性化されたＢＷＰで行われ、１つの端末には１つのＢＷＰのみが活性化される。リソースグリッドにおいて各々の要素はリソースエレメント（Ｒｅｓｏｕｒｃｅ  Ｅｌｅｍｅｎｔ、ＲＥ）と称され、１つの複素シンボルがマッピングされることができる。
【００３９】
以下、各々の物理チャネルについてより詳しく説明する。
【００４０】
ＰＤＣＣＨはＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を運ぶ。例えば、ＰＣＣＣＨ（即ち、ＤＣＩ）はＤＬ−ＳＣＨ（ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）の送信フォーマット及びリソースの割り当て、ＵＬ−ＳＣＨ（ｕｐｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）に対するリソース割り当て情報、ＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）に関するページング情報、ＤＬ−ＳＣＨ上のシステム情報、ＰＤＳＣＨ上で送信されるランダムアクセス応答のような上位層制御メッセージに関するリソース割り当て情報、送信電力制御命令、ＣＳ（Ｃｏｎｆｉｇｕｒｅｄ  ｓｃｈｅｄｕｌｉｎｇ）の活性化／解除などを運ぶ。ＤＣＩはＣＲＣ（ｃｙｃｌｉｃ  ｒｅｄｕｎｄａｎｃｙ  ｃｈｅｃｋ）を含み、ＣＲＣはＰＤＣＣＨの所有者又は使用用途によって様々な識別子（例えば、Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｔｅｍｐｏｒａｒｙ  Ｉｄｅｎｔｉｆｉｅｒ、ＲＮＴＩ）にマスキング／スクランブルされる。例えば、ＰＤＣＣＨが特定の端末のためのものであれば、ＣＲＣは端末識別子（例えば、ｃｅｌｌ−ＲＮＴＩ、Ｃ−ＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがページングに関するものであれば、ＣＲＣはＰ−ＲＮＴＩ（Ｐａｇｉｎｇ−ＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがシステム情報（例えば、Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ、ＳＩＢ）に関するものであれば、ＣＲＣはＳＩ−ＲＮＴＩ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  ＲＮＴＩ）にマスキングされる。ＰＤＣＣＨがランダムアクセス応答に関するものであれば、ＣＲＣはＲＡ−ＲＮＴＩ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ−ＲＮＴＩ）にマスキングされる。
【００４１】
ＰＤＳＣＨは下りリンクデータ（例、ＤＬ−ＳＣＨ  ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ、ＤＬ−ＳＣＨ  ＴＢ）を運び、ＱＰＳＫ（Ｑｕａｄｒａｔｕｒｅ  Ｐｈａｓｅ  Ｓｈｉｆｔ  Ｋｅｙｉｎｇ）、１６ＱＡＭ（Ｑｕａｄｒａｔｕｒｅ  Ａｍｐｌｉｔｕｄｅ  Ｍｏｄｕｌａｔｉｏｎ）、６４ＱＡＭ、２５６ＱＡＭなどの変調方法が適用される。ＴＢを符号化してコードワード（ｃｏｄｅｗｏｒｄ）が生成される。ＰＤＳＣＨは最大２個のコードワードを運ぶ。コードワードごとにスクランブル及び変調マッピングが行われ、各コードワードから生成された変調シンボルは１つ以上のレイヤにマッピングされる。各レイヤはＤＭＲＳ（Ｄｅｍｏｄｕｌａｔｉｏｎ  Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ）と共にリソースにマッピングされてＯＦＤＭシンボル信号に生成され、該当アンテナポートにより送信される。
【００４２】
ＰＵＣＣＨは、ＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）を運ぶ。ＵＣＩは以下を含む。
【００４３】
−ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）：ＵＬ−ＳＣＨリソースを要求するために使用される情報である。
【００４４】
−ＨＡＲＱ−ＡＣＫ：ＰＤＳＣＨ上の下りリンクデータパケット（例えば、コードワード）に対する応答である。下りリンクデータパケットが正常に受信されたか否かを示す。単一のコードワードに対する応答としてＨＡＲＱ−ＡＣＫ  １ビットが送信され、２個のコードワードに対する応答としてＨＡＲＱ−ＡＣＫ  ２ビットが送信される。ＨＡＲＱ−ＡＣＫ応答は、ポジティブＡＣＫ（簡単に、ＡＣＫ）、ネガティブＡＣＫ（以下、ＮＡＣＫ）、ＤＴＸ（Ｄｉｓｃｏｎｔｉｎｕｏｕｓ  Ｔｒａｎｓｍｉｓｓｉｏｎ）又はＮＡＣＫ／ＤＴＸを含む。ここで、ＨＡＲＱ−ＡＣＫという用語は、ＨＡＲＱ  ＡＣＫ／ＮＡＣＫ、ＡＣＫ／ＮＡＣＫと同じ意味で使われる。
【００４５】
−ＣＳＩ（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ）：下りリンクチャンネルに対するフィードバック情報である。ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ  Ｉｎｐｕｔ  Ｍｕｌｔｉｐｌｅ  Ｏｕｔｐｕｔ）−関連フィードバック情報は、ＲＩ（Ｒａｎｋ  Ｉｎｄｉｃａｔｏｒ）及びＰＭＩ（Ｐｒｅｃｏｄｉｎｇ  Ｍａｔｒｉｘ  Ｉｎｄｉｃａｔｏｒ）を含む。
【００４６】
表３はＰＵＣＣＨフォーマットを例示する。ＰＵＣＣＨ送信の長さによってＳｈｏｒｔ  ＰＵＣＣＨ（フォーマット０，２）及びＬｏｎｇ  ＰＵＣＣＨ（フォーマット１，３，４）に区分できる。
【００４７】
【表３】
2021506195.tif 000005
【００４８】
ＰＵＣＣＨフォーマット０は最大２ビットサイズのＵＣＩを運び、シーケンスに基づいてマッピングされて送信される。具体的には、端末は複数のシーケンスのうちの１つのシーケンスをＰＵＣＣＨフォーマット０であるＰＵＣＣＨを介して送信して特定のＵＣＩを基地局に送信する。端末は肯定（ｐｏｓｉｔｉｖｅ）のＳＲを送信する場合のみに対応するＳＲ設定のためのＰＵＣＣＨリソース内でＰＵＣＣＨフォーマット０であるＰＵＣＣＨを送信する。
【００４９】
ＰＵＣＣＨフォーマット１は最大２ビットサイズのＵＣＩを運び、変調シンボルは時間領域で（周波数ホッピング有無によって異なるように設定される）直交カバーコード（ＯＣＣ）により拡散される。ＤＭＲＳは変調シンボルが送信されないシンボルで送信される（即ち、ＴＤＭ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて送信される）。
【００５０】
ＰＵＣＣＨフォーマット２は２ビットより大きいビットサイズのＵＣＩを運び、変調シンボルはＤＭＲＳとＦＤＭ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。ＤＭ−ＲＳは１／３の密度のリソースブロック内のシンボルインデックス＃１、＃４、＃７及び＃１０に位置する。ＰＮ（Ｐｓｅｕｄｏ  Ｎｏｉｓｅ）シーケンスがＤＭ＿ＲＳシーケンスのために使用される。２シンボルＰＵＣＣＨフォーマット２のために周波数ホッピングが活性化されることができる。
【００５１】
ＰＵＣＣＨフォーマット３は同一の物理リソースブロック内において端末多重化が行われず、２ビットより大きいビットサイズのＵＣＩを運ぶ。即ち、ＰＵＣＣＨフォーマット３のＰＵＣＣＨリソースは直交カバーコードを含まない。変調シンボルはＤＭＲＳとＴＤＭ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。
【００５２】
ＰＵＣＣＨフォーマット４は同一の物理リソースブロック内に最大４個の端末まで多重化が支援され、２ビットより大きいビットサイズのＵＣＩを運ぶ。即ち、ＰＵＣＣＨフォーマット３のＰＵＣＣＨリソースは直交カバーコードを含む。変調シンボルはＤＭＲＳとＴＤＭ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）されて送信される。
【００５３】
ＰＵＳＣＨは上りリンクデータ（例えば、ＵＬ−ＳＣＨ  ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ、ＵＬ−ＳＣＨ  ＴＢ）及び／又は上りリンク制御情報（ＵＣＩ）を運び、ＣＰ−ＯＦＤＭ（Ｃｙｃｌｉｃ  Ｐｒｅｆｉｘ−Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）波形又はＤＦＴ−ｓ−ＯＦＤＭ（Ｄｉｓｃｒｅｔｅ  Ｆｏｕｒｉｅｒ  Ｔｒａｎｓｆｏｒｍ−ｓｐｒｅａｄ−Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅｘｉｎｇ）波形に基づいて送信される。ＰＵＳＣＨがＤＦＴ−ｓ−ＯＦＤＭ波形に基づいて送信される場合、端末は変換プリコーディング（ｔｒａｎｓｆｏｒｍ  ｐｒｅｃｏｄｉｎｇ）を適用してＰＵＳＣＨを送信する。一例として、変換プリコーディングが不可能な場合は（例えば、ｔｒａｎｓｆｏｒｍ  ｐｒｅｃｏｄｉｎｇ  ｉｓ  ｄｉｓａｂｌｅｄ）、端末はＣＰ−ＯＦＤＭ波形に基づいてＰＵＳＣＨを送信し、変換プリコーディングが可能な場合には（例えば、ｔｒａｎｓｆｏｒｍ  ｐｒｅｃｏｄｉｎｇ  ｉｓ  ｅｎａｂｌｅｄ）、端末はＣＰ−ＯＦＤＭ波形又はＤＦＴ−ｓ−ＯＦＤＭ波形に基づいてＰＵＳＣＨを送信する。ＰＵＳＣＨ送信はＤＣＩ内のＵＬグラントにより動的にスケジュールされるか、又は上位層（例えば、ＲＲＣ）シグナリング（及び／又はＬａｙｅｒ  １（Ｌ１）シグナリング（例えば、ＰＤＣＣＨ））に基づいて準静的（ｓｅｍｉ−ｓｔａｔｉｃ）にスケジュールされる（ｃｏｎｆｉｇｕｒｅｄ  ｇｒａｎｔ）。ＰＵＳＣＨ送信はコードブックベース又は非コードブックベースで行われる。
【００５４】
図４はＡＣＫ／ＮＡＣＫ送信過程を例示する。図４を参照すると、端末はスロット＃ｎでＰＤＣＣＨを検出する。ここで、ＰＤＣＣＨは下りリンクスケジューリング情報（例えば、ＤＣＩフォーマット１＿０、１＿１）を含み、ＰＤＣＣＨはＤＬ割り当て−ｔｏ−ＰＤＳＣＨオフセット（Ｋ０）とＰＤＳＣＨ−ＨＡＲＱ−ＡＣＫ報告オフセット（Ｋ１）を示す。例えば、ＤＣＩフォーマット１＿０、１＿１は以下の情報を含む。
【００５５】
−Ｆｒｅｑｕｅｎｃｙ  ｄｏｍａｉｎ  ｒｅｓｏｕｒｃｅ  ａｓｓｉｇｎｍｅｎｔ：ＰＤＳＣＨに割り当てられたＲＢセットを示す。
【００５６】
−Ｔｉｍｅ  ｄｏｍａｉｎ  ｒｅｓｏｕｒｃｅ  ａｓｓｉｇｎｍｅｎｔ：Ｋ０、スロット内のＰＤＳＣＨの開始位置（例えば、ＯＦＤＭシンボルインデックス）及び長さ（例：ＯＦＤＭシンボル数）を示す
【００５７】
−ＰＤＳＣＨ−ｔｏ−ＨＡＲＱ＿ｆｅｅｄｂａｃｋ  ｔｉｍｉｎｇ  ｉｎｄｉｃａｔｏｒ：Ｋ１を示す
【００５８】
今後、端末はスロット＃ｎのスケジューリング情報によってスロット＃（ｎ＋Ｋ０）でＰＤＳＣＨを受信した後、スロット＃（ｎ＋Ｋ１）でＰＵＣＣＨを介してＵＣＩを送信する。ここで、ＵＣＩはＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫ応答を含む。ＰＤＳＣＨが最大１個のＴＢを送信するように構成された場合、ＨＡＲＱ−ＡＣＫ応答は１ビットで構成される。ＰＤＳＣＨが最大２個のＴＢを送信するように構成された場合は、ＨＡＲＱ−ＡＣＫ応答は空間（ｓｐａｔｉａｌ）バンドリングが構成されていない場合は、２ビットで構成され、空間バンドリングが構成された場合は、１ビットで構成される。複数のＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫ送信時点がスロット＃（ｎ＋Ｋ１）と指定された場合、スロット＃（ｎ＋Ｋ１）で送信されるＵＣＩは複数のＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫ応答を含む。
【００５９】
図５はＰＵＳＣＨ送信過程を例示する。図５を参照すると、端末はスロット＃ｎでＰＤＣＣＨを検出する。ここで、ＰＤＣＣＨは上りリンクスケジューリング情報（例えば、ＤＣＩフォーマット０＿０、０＿１）を含む。ＤＣＩフォーマット０＿０、０＿１は以下の情報を含む。
【００６０】
−Ｆｒｅｑｕｅｎｃｙ  ｄｏｍａｉｎ  ｒｅｓｏｕｒｃｅ  ａｓｓｉｇｎｍｅｎｔ：ＰＵＳＣＨに割り当てられたＲＢセットを示す。
【００６１】
−Ｔｉｍｅ  ｄｏｍａｉｎ  ｒｅｓｏｕｒｃｅ  ａｓｓｉｇｎｍｅｎｔ：スロットオフセットＫ２、スロット内のＰＵＳＣＨの開始位置（例えば、シンボルインデックス）及び長さ（例：ＯＦＤＭシンボル数）を示す。開始シンボル及び長さはＳＬＩＶ（Ｓｔａｒｔ  ａｎｄ  Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ  Ｖａｌｕｅ）により指示されるか、又は各々指示される。
【００６２】
以後、端末はスロット＃ｎのスケジューリング情報によってスロット＃（ｎ＋Ｋ２）でＰＵＳＣＨを送信する。ここで、ＰＵＳＣＨはＵＬ−ＳＣＨ  ＴＢを含む。
【００６３】
図６はＵＳＩをＰＵＳＣＨに多重化する例を示す。スロット内で複数のＰＵＣＣＨリソースとＰＵＳＣＨリソースが重畳し、ＰＵＣＣＨ−ＰＵＳＣＨ同時送信が設定されていない場合、ＵＣＩは、図示したように、ＰＵＳＣＨを介して送信される（ＵＣＩピギーバック又はＰＵＳＣＨピギーバック）。図６はＨＡＲＱ−ＡＣＫとＣＳＩがＰＵＳＣＨリソースに含まれる場合を例示する。
【００６４】
実施例：ＵＬチャネルの多重化
【００６５】
ＮＲシステムでは、単一の物理ネットワーク上に複数の論理ネットワークを具現化する方法が考えられている。ここで、論理ネットワークは様々な要求条件を有するサービス（例えば、ｅＭＢＢ、ｍＭＴＣ、ＵＲＬＬＣなど）を支援する必要がある。従って、ＮＲの物理層は様々なサービスに対する要求条件を考えて柔軟な送信構造を支援するように設計されている。一例として、ＮＲの物理層は必要によってＯＦＤＭシンボルの長さ（ＯＦＤＭシンボル区間）及び副搬送波間隔（ＳＣＳ）（以下、ＯＦＤＭニューマロロジー）を変更することができる。また物理チャネルの送信リソースも（シンボル単位で）一定範囲内で変更可能である。例えば、ＮＲにおいて、ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）は送信の長さ／送信開始時点が一定範囲内で柔軟に設定される。
【００６６】
一方、基地局と端末で構成された無線通信システムにおいて、端末がＵＣＩをＰＵＣＣＨを介して送信するとき、ＰＵＣＣＨリソースが時間軸で他のＰＵＣＣＨリソース或いはＰＵＳＣＨリソースと重畳することができる。例えば、同じ端末の観点で（同じスロット内で）、（１）（互いに異なるＵＣＩ送信のための）ＰＵＣＣＨ（リソース）とＰＵＣＣＨ（リソース）、或いは（２）ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）が時間軸で重畳することができる。一方、端末は（端末能力の制限、又は基地局からの設定情報によって）ＰＵＣＣＨ−ＰＵＣＣＨ同時送信或いはＰＵＣＣＨ−ＰＵＳＣＨ同時送信を支援しないことができる。この場合、端末は、（１）互いに異なるＵＣＩ、或いは（２）ＵＣＩとＵＬデータを最大限多重化して送信することが好ましい。しかし、ＮＲシステムでは、（スロット内の）時間軸で重畳した（１）ＰＵＣＣＨ（リソース）とＰＵＣＣＨ（リソース）、或いは（２）ＰＵＣＣＨ（リソース）とＰＵＳＣＨ（リソース）の間に送信の長さ（例えば、シンボル数）及び／又は送信開始時点（例えば、開始シンボル）が異なることができる。従って、端末の処理時間の観点で、端末が（１）互いに異なるＵＣＩ、或いは（２）ＵＣＩとＵＬデータを多重化して送信することが難しい場合がある。例えば、Ａ／Ｎを送信するＰＵＣＣＨ（以下、Ａ／Ｎ  ＰＵＣＣＨ）とＳＲを送信するＰＵＣＣＨ（以下、ＳＲ  ＰＵＣＣＨ）が時間軸で（一部或いは全部）重畳することができる。この場合、端末がＳＲ  ＰＵＣＣＨに対する送信を既に開始したか又は送信準備を完了した後、ＳＲ  ＰＵＣＣＨと重畳するＡ／Ｎ  ＰＵＣＣＨの存在を認知すると、端末はＡ／Ｎ  ＰＵＣＣＨ内のＡ／ＮをＳＲと多重化して送信することが難しい。
【００６７】
既存のＮＲシステムでは、Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で完全に重畳した場合（即ち、送信区間が一致）、Ａ／Ｎ  ＰＵＣＣＨのＰＵＣＣＨフォーマットによって以下のようにＵＣＩ多重化規定を適用する。Ｐｏｓｉｔｉｖｅ  ＳＲは端末が送信するＵＬデータがあることを意味し、ｎｅｇａｔｉｖｅ  ＳＲは端末が送信するＵＬデータがないことを意味する。
【００６８】
（１）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【００６９】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【００７０】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信
【００７１】
Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【００７２】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【００７３】
（２）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【００７４】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【００７５】
−Ａ／ＮをＳＲ  ＰＵＣＣＨリソースを介して送信
【００７６】
Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【００７７】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【００７８】
（３）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの１つである場合
【００７９】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲ又はｎｅｇａｔｉｖｅ  ＳＲである場合
【００８０】
−ＳＲを明示的ビットで表現してＡ／Ｎに付け加えて（Ａｐｐｅｎｄｉｎｇ）ＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【００８１】
しかし、既存の方法では、Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で完全に重畳する場合に限ってＵＣＩ多重化方法を定義している。よって、効率的なＵＣＩ送信のために、様々な状況を考えてＵＣＩ多重化方法を論議する必要がある。
【００８２】
上記問題を解決するために、本発明では時間軸で重畳したＵＬチャネルに対するＵＣＩ及び／又はデータを多重化する動作を提案する。具体的には、本発明ではＵＬチャネルの送信開始時点及び／又は端末の処理時間を考えてＵＬチャネルに対するＵＣＩ及び／又はデータを多重化する動作を提案する。
【００８３】
まず、以下のように用語を定義する。
【００８４】
−ＵＣＩ：端末がＵＬ送信する制御情報を意味する。ＵＣＩは複数のタイプの制御情報（即ち、ＵＣＩタイプ）を含む。例えば、ＵＣＩはＨＡＲＱ−ＡＣＫ（簡単に、Ａ／Ｎ、ＡＮ）、ＳＲ、ＣＳＩを含む。
【００８５】
−ＰＵＣＣＨ：ＵＣＩ送信のための物理層ＵＬチャネルを意味する。便宜上、Ａ／Ｎ、ＳＲ、ＣＳＩ送信のために、基地局が設定した及び／又は送信を指示したＰＵＣＣＨリソースを各々Ａ／Ｎ  ＰＵＣＣＨリソース、ＳＲ  ＰＵＣＣＨリソース、ＣＳＩ  ＰＵＣＣＨリソースと呼ぶ。
【００８６】
−ＰＵＳＣＨ：ＵＬデータ送信のための物理層ＵＬチャネルを意味する。
【００８７】
−ＵＣＩ多重化（ｍｕｌｔｉｐｌｅｘｉｎｇ）：互いに異なるＵＣＩ（タイプ）を共通の物理層ＵＬチャネル（例えば、ＰＵＣＣＨ、ＰＵＳＣＨ）を介して送信する動作を意味する。ＵＣＩ多重化は、互いに異なるＵＣＩ（タイプ）を多重化する動作を含む。便宜上、多重化されたＵＣＩをＭＵＸ  ＵＣＩと称する。またＵＣＩ多重化はＭＵＸ  ＵＣＩに関連して行われる動作を含む。例えば、ＵＣＩ多重化はＭＵＸ  ＵＣＩを送信するためにＵＬチャネルリソースを決定する過程を含む。
【００８８】
−ＵＣＩ／データ多重化：ＵＣＩとデータを共通の物理層ＵＬチャネル（例えば、ＰＵＳＣＨ）により送信する動作を意味する。ＵＣＩ／データ多重化はＵＣＩとデータを多重化する動作を含む。便宜上、多重化されたＵＣＩをＭＵＸ  ＵＣＩ／Ｄａｔａと称する。またＵＣＩ／データの多重化はＭＵＸ  ＵＣＩ／Ｄａｔａに関連して行われる動作を含む。例えば、ＵＣＩ／データの多重化はＭＵＸ  ＵＣＩ／Ｄａｔａを送信するためにＵＬチャネルリソースを決定する過程を含む。
【００８９】
−スロット：データスケジューリングのための基本時間単位（ｔｉｍｅ  ｕｎｉｔ（ＴＵ）又はｔｉｍｅ  ｉｎｔｅｒｖａｌ）を意味する。スロットは複数のシンボルを含む。ここで、シンボルはＯＦＤＭベースのシンボルを含む（例えば、ＣＰ−ＯＦＤＭシンボル、ＤＦＴ−ｓ−ＯＦＤＭシンボル）。この明細書において、シンボル、ＯＦＤＭベースのシンボル、ＯＦＤＭシンボル、ＣＰ−ＯＦＤＭシンボル及びＤＦＴ−ｓ−ＯＦＤＭシンボルは互いに代替することができる。
【００９０】
−重畳したＵＬチャネルリソース：所定の時間区間（例えば、スロット）内で時間軸で（少なくとも一部が）重畳したＵＬチャネル（例えば、ＰＵＣＣＨ、ＰＵＳＣＨ）リソースを意味する。重畳したＵＬチャネルリソースはＵＣＩ多重化を行う前のＵＬチャネルリソースを意味する。
【００９１】
ＰＵＣＣＨフォーマットはＵＣＩペイロードサイズ及び／又は送信の長さ（例えば、ＰＵＣＣＨリソースを構成するシンボル数）によって以下のように区分される。ＰＵＣＣＨフォーマットに関する事項は表３を参照できる。
【００９２】
（０）ＰＵＣＣＨフォーマット０（ＰＦ０、Ｆ０）
【００９３】
−支援可能なＵＣＩペイロードサイズ：最大Ｋビットまで（例えば、Ｋ＝２）
【００９４】
−単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：１〜Ｘシンボル（例えば、Ｘ＝２）
【００９５】
−送信構造：ＤＭ−ＲＳ無しにＵＣＩ信号のみで構成され、複数のシーケンスのうちの１つを選択及び送信することによりＵＣＩ状態を送信
【００９６】
（１）ＰＵＣＣＨフォーマット１（ＰＦ１、Ｆ１）
【００９７】
−支援可能なＵＣＩペイロードサイズ：最大Ｋビットまで（例えば、Ｋ＝２）
【００９８】
−単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ〜Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）
【００９９】
−送信構造：ＤＭ−ＲＳとＵＣＩが互いに異なるＯＦＤＭシンボルにＴＤＭ形態で構成され、ＵＣＩは特定のシーケンスに変調（例えば、ＱＰＳＫ）シンボルを乗ずる形態。ＵＣＩとＤＭ−ＲＳに全てＣＳ（Ｃｙｃｌｉｃ  Ｓｈｉｆｔ）／ＯＣＣ（Ｏｒｔｈｏｇｏｎａｌ  Ｃｏｖｅｒ  Ｃｏｄｅ）を適用して、（同じＲＢ内で）（ＰＵＣＣＨフォーマット１に従う）複数のＰＵＣＣＨリソースの間でＣＤＭを支援
【０１００】
（２）ＰＵＣＣＨフォーマット２（ＰＦ２、Ｆ２）
【０１０１】
−支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）
【０１０２】
−単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：１〜Ｘシンボル（例えば、Ｘ＝２）
【０１０３】
−送信構造：ＤＭＲＳとＵＣＩが同じシンボル内でＦＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴ無しにＩＦＦＴのみを適用して送信される構造
【０１０４】
（３）ＰＵＣＣＨフォーマット３（ＰＦ３、Ｆ３）
【０１０５】
−支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）
【０１０６】
−単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ〜Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）
【０１０７】
−送信構造：ＤＭＲＳとＵＣＩが互いに異なるシンボルにＴＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴを適用して送信する形態。ＵＣＩにはＤＦＴの前端でＯＣＣを適用し、ＤＭＲＳにはＣＳ（又はＩＦＤＭマッピング）を適用して複数の端末に多重化を支援
【０１０８】
（４）ＰＵＣＣＨフォーマット４（ＰＦ４、Ｆ４）
【０１０９】
−支援可能なＵＣＩペイロードサイズ：Ｋビットを超える（例えば、Ｋ＝２）
【０１１０】
−単一のＰＵＣＣＨを構成するＯＦＤＭシンボル数：Ｙ〜Ｚシンボル（例えば、Ｙ＝４、Ｚ＝１４）
【０１１１】
−送信構造：ＤＭＲＳとＵＣＩが互いに異なるシンボルにＴＤＭ形態で構成／マッピングされ、符号化されたＵＣＩビットにＤＦＴを適用して端末間の多重化無しに送信される構造
【０１１２】
ＵＣＩタイプ（例えば、Ａ／Ｎ、ＳＲ、ＣＳＩ）ごとにＰＵＣＣＨリソースが決定される。ＵＣＩ送信に使用されるＰＵＣＣＨリソースはＵＣＩ（ペイロード）サイズに基づいて決定される。一例として、基地局は端末に複数のＰＵＣＣＨリソースセットを設定し、端末はＵＣＩ（ペイロード）サイズ（例えば、ＵＣＩビット数）の範囲によって、特定の範囲に対応する特定のＰＵＣＣＨリソースセットを選択する。例えば、端末はＵＣＩビット数（ＮUCI）によって、以下のうちのいずれか１つのＰＵＣＣＨリソースセットを選択することができる。
【０１１３】
−ＰＵＣＣＨリソースセット＃０、ＵＣＩビット数≦２であると、
【０１１４】
−ＰＵＣＣＨリソースセット＃１、２＜ＵＣＩビット数≦Ｎ1であると、
【０１１５】
．．．
【０１１６】
−ＰＵＣＣＨリソースセット＃（Ｋ−１）、ＮK-2＜ＵＣＩビット数≦ＮK-1であると、
【０１１７】
ここで、ＫはＰＵＣＣＨリソースセット数を示し（Ｋ＞１）、ＮiはＰＵＣＣＨリソースセット＃ｉが支援する最大のＵＣＩビット数である。例えば、ＰＵＣＣＨリソースセット＃１はＰＵＣＣＨフォーマット０〜１のリソースで構成され、それ以外のＰＵＣＣＨリソースセットはＰＵＣＣＨフォーマット２〜４のリソースで構成される（表３を参照）。
【０１１８】
ＵＣＩタイプがＳＲ、ＣＳＩである場合、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースは上位層シグナリング（例えば、ＲＲＣシグナリング）により設定される。ＵＣＩタイプがＳＰＳ（Ｓｅｍｉ−Ｐｅｒｓｉｓｔｅｎｔ  Ｓｃｈｅｄｕｌｉｎｇ）ＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫである場合、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースは上位層シグナリング（例えば、ＲＲＣシグナリング）により設定される。反面、ＵＣＩタイプが普通のＰＤＳＣＨ（即ち、ＤＣＩによりスケジュールされたＰＤＳＣＨ）に対するＨＡＲＱ−ＡＣＫである場合は、ＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースはＤＣＩに基づいてスケジュールされる。
【０１１９】
ＤＣＩベースのＰＵＣＣＨリソーススケジューリングの場合、基地局は端末にＰＤＣＣＨを介してＤＣＩを送信し、ＤＣＩ内のＡＲＩ（ＡＣＫ／ＮＡＣＫ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒ）により特定のＰＵＣＣＨリソースセット内でＵＣＩ送信に活用するＰＵＣＣＨリソースを指示する。ＡＲＩはＡＣＫ／ＮＡＣＫ送信のためのＰＵＣＣＨリソースを指示するために使用され、ＰＲＩ（ＰＵＣＣＨ  Ｒｅｓｏｕｒｃｅ  Ｉｎｄｉｃａｔｏｒ）とも呼ばれる。ここで、ＤＣＩはＰＤＳＣＨスケジューリングに使用されるＤＣＩであり、ＵＣＩはＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫを含む。一方、基地局はＡＲＩが表現できる状態（ｓｔａｔｅ）の数より多いＰＵＣＣＨリソースで構成されたＰＵＣＣＨリソースセットを（端末−特定の）上位層（例えば、ＲＲＣ）信号により端末に設定する。この時、ＡＲＩはＰＵＣＣＨリソースセット内のＰＵＣＣＨリソースサブセットを指示し、指示されたＰＵＣＣＨリソースサブセット内でどのＰＵＣＣＨリソースを使用するかは、ＰＤＣＣＨに関する送信リソース情報（例えば、ＰＤＣＣＨの開始ＣＣＥインデックスなど）に基づく暗黙的な規則（ｉｍｐｌｉｃｉｔ  ｒｕｌｅ）によって決定される。
【０１２０】
以下の提案方法は他の提案方法と互いに相反しない限り、共に結合して適用できる。
【０１２１】
ＰＵＣＣＨ／ＰＵＣＣＨ多重化
【０１２２】
［提案方法＃１］Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、（基準時点から）特定の時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳するか否かによって、端末でＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。
【０１２３】
但し、端末がＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を行わない場合、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの一つの送信を省略することができる。
【０１２４】
一例として、端末はＳＲ  ＰＵＣＣＨの送信開始時点（例えば、開始シンボル）（以下、Ｔｓｒ）を基準として、Ｔ0以前の時点（以下、Ｔｒｅｆ，ｓｒ）まで受信された（又は送信が開始された）ＰＤＳＣＨ（又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳するか否かによって、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。Ｔｒｅｆ，ｓｒ＝Ｔｓｒ−Ｔ0と定義され、ＯＦＤＭシンボル単位で表現することができる。
【０１２５】
（ケース１）Ｔｒｅｆ，ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳する場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信することができる（又はＡ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのシンボルが完全に重畳する場合と同じＵＣＩ多重化規則に従うことができる）。
【０１２６】
（１）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【０１２７】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１２８】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信
【０１２９】
Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１３０】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１３１】
（２）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【０１３２】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１３３】
−Ａ／ＮをＳＲ  ＰＵＣＣＨリソースを介して送信。但し、ＳＲ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。
【０１３４】
Ｂ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１３５】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１３６】
（３）Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの１つである場合
【０１３７】
Ａ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲ又はｎｅｇａｔｉｖｅ  ＳＲである場合
【０１３８】
−ＳＲを明示的ビットで表現してＡ／Ｎに付け加えて（Ａｐｐｅｎｄｉｎｇ）ＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１３９】
（ケース２）（ケース１）に該当しない場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信することができる。例えば、（ｉ）Ｔｒｅｆ，ｓｒ時点後に受信された（又は送信が開始／終了した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳するか、（ｉｉ）Ｔｒｅｆ，ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳しないか、又は（ｉｉｉ），ｓｒまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが存在しない場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信することができる。
【０１４０】
（１）ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１４１】
−ＳＲをＳＲ  ＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０１４２】
（２）ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１４３】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１４４】
Ｔ0は以下のうちの１つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０１４５】
（１）端末能力（ｃａｐａｂｉｌｉｔｙ）によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０１４６】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０１４７】
（３）端末能力による復調に必要な端末処理時間又はそれに対応する値
【０１４８】
（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０１４９】
（５）基地局と端末の間に予め約束した値（例えば、固定値）
【０１５０】
［提案方法＃１］はＡ／Ｎ  ＰＵＣＣＨ以外のＰＵＣＣＨにも拡張して適用できる。
【０１５１】
一方、ＮＲシステムでは、Ａ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨの間の開始（ｓｔａｒｔｉｎｇ）（ＯＦＤＭ）シンボル（或いは開始時間）が一致する場合、Ａ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨが時間軸で完全に重畳する場合と同一のＵＣＩ多重化規則を適用する端末動作が合議されている。反面、Ａ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボルが異なる場合には、Ａ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）を比較して、Ａ／ＮとＳＲの間のＵＣＩ多重化の有無を決定する方法が論議されている。例えば、ＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより先立つ場合、端末はＳＲ  ＰＵＣＣＨを送信し、Ａ／Ｎ送信を省略する。逆に、ＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより遅れる場合は、端末はＳＲとＡ／ＮをＵＣＩ多重化して単一のＰＵＣＣＨで送信する。この動作は端末がＳＲ送信を準備した後（又はＳＲ送信中）にＡ／Ｎ送信があることを認知した場合、ＳＲ送信を取り消し、Ａ／ＮとＳＲをＵＣＩ多重化して送信する過程が端末の具現化上、容易ではないという点で提案されたものである。しかし、ＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルより先立っても、Ａ／Ｎ  ＰＵＣＣＨに対応するＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の受信時点がしばらく前であると、端末はＡ／ＮとＳＲをＵＣＩ多重化して送信することができる。従って、既存の方法は、端末処理時間の観点で端末にＡ／ＮとＳＲの間のＵＣＩ多重化を行う余力があっても、Ａ／Ｎ送信を省略するという点で好ましくない。
【０１５２】
従って、Ａ／ＮとＳＲの多重化を支援するために、端末に（ｉ）ＳＲ  ｏｎｌｙの送信を行うか、又は（ｉｉ）ＳＲとＡ／Ｎを多重化して送信するかを決定する時点を明示することができる。たとえ、端末は特定のＳＲ  ＰＵＣＣＨに対する送信開始時点（Ｔｓｒ）を基準として、Ｔ0以前の時点（Ｔｒｅｆ，ｓｒ）まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳しない場合、Ｐｏｓｉｔｉｖｅ  ＳＲであれば、ＳＲ  ＰＵＣＣＨを送信すると決定することができる。この時、端末はＴｒｅｆ，ｓｒ後に受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳しても、Ａ／Ｎ送信を省略し、ＳＲ  ＰＵＣＣＨ送信を行うことができる。反面、Ｔｒｅｆ，ｓｒまで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨリソースと時間軸で重畳する場合は、端末は（ｉ）ＳＲ情報がｐｏｓｉｔｉｖｅ  ＳＲであれば、Ａ／ＮとＳＲをＵＣＩ多重化して単一のＰＵＣＣＨリソースを介して送信し、（ｉｉ）ＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであれば、Ａ／ＮのみをＡ／Ｎ  ＰＵＣＣＨを介して送信するか、又はｎｅｇａｔｉｖｅ  ＳＲを表現する明示的ビットをＡ／Ｎに付け加えてＡ／Ｎ  ＰＵＣＣＨを介して送信することができる。
【０１５３】
一方、端末は今後Ａ／Ｎ  ＰＵＣＣＨリソースがＳＲ  ＰＵＣＣＨと重畳しないように更新されてもＡ／ＮとＳＲをＵＣＩ多重化すると予め決定したので、決定を翻さず、相変わらずＵＣＩ多重化されたＡ／ＮとＳＲを単一のＰＵＣＣＨリソースを介して送信することができる。
【０１５４】
図７はＡ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合の動作を例示する。図８はＡ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合の動作を例示する。
【０１５５】
［提案方法＃１］は、端末がＴｒｅｆ，ｓｒ（即ち、Ｔｓｒ−Ｔｏ）前に終了した／受信したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／Ｎ  ＰＵＣＣＨについてはＳＲ  ＰＵＣＣＨに対する送信を確定する前に存在の有無を把握できるという仮定を前提とする。即ち、［提案方法＃１］は、Ｔｒｅｆ，ＳＲ後に終了したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）については端末がＳＲ  ＰＵＣＣＨに対する送信を確定する前に把握することが難しいと判断し、Ａ／ＮとＳＲの多重化を判断する時に参照しない。［提案方法＃１］によれば、端末はＴｒｅｆ，ＳＲ前に終了した／受信したＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／Ｎ  ＰＵＣＣＨがＳＲ  ＰＵＣＣＨと時間軸で重畳すると、Ａ／ＮとＳＲを共に多重化して送信することができる。Ａ／Ｎ  ＰＵＣＣＨがＳＲ  ＰＵＣＣＨと時間軸で重畳しないか又は存在しないと、ＳＲのみを送信することができるので、端末の具現化が容易である。また、［提案方法＃１］は、ほとんどの場合にＡ／ＮとＳＲが多重化されるようにすることにより、Ａ／Ｎ又はＳＲ送信が省略される場合を減らす効果がある。また［提案方法＃１］は、Ａ／ＮとＳＲが多重化されてＳＲ  ＰＵＣＣＨで送信される場合、（例えば、Ａ／Ｎ  ＰＵＣＣＨがＦ１であり、ＳＲ  ＰＵＣＣＨもＦ１である場合にも）Ａ／Ｎ送信に対する最小のＰＤＳＣＨ−ｔｏ−ＨＡＲＱ−ＡＣＫ送信処理時間を保証して、できる限り単一化された解決策を提示するという長所がある。もし一つのスロット内に互いに区分される複数のＳＲ  ＰＵＣＣＨが設定された場合は、端末はスロット内の先立つＳＲ  ＰＵＣＣＨに対してＡ／Ｎとの多重化の有無を判断した後、Ａ／Ｎ送信が省略されないと、次のＳＲ  ＰＵＣＣＨとＡ／Ｎとの多重化の有無を判断するように順に動作を適用することができる。
【０１５６】
［提案方法＃１］の変形として、Ｔｒｅｆ，ｓｒ（即ち、Ｔｓｒ−Ｔｏ）まで送信が開始されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応するＡ／Ｎ  ＰＵＣＣＨがＳＲ  ＰＵＣＣＨと重畳する場合には、Ａ／ＮとＳＲに対する多重化を行い、そうではない場合には、ＳＲのみを送信する。この動作は、（Ａ／Ｎ  ＰＵＣＣＨに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信開始時点がＴｒｅｆ，ｓｒより先立つ（又は同一である）場合、端末が該当ＰＤＳＣＨに対応するＰＤＣＣＨ（例えば、ＤＬ割り当て）を検出及び復調する時間が十分であり、ＳＲ  ＰＵＣＣＨに対する送信を確定する前に該当ＳＲ  ＰＵＣＣＨと衝突するＡ／Ｎ  ＰＵＣＣＨが存在することを認知できるという仮定を前提とする。従って、（Ａ／Ｎ  ＰＵＣＣＨに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信開始時点がＴｒｅｆ，ｓｒより遅れる場合は、該当ＰＤＳＣＨに対応するＰＤＣＣＨ（例えば、ＤＬ割り当て）を検出及び復調する時間が十分でないので、端末は該当ＰＤＳＣＨについてはＡ／ＮとＳＲに対する多重化の有無を判断する時に反映されない。
【０１５７】
［提案方法＃１］の変形として、端末が送信しようとするＡ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の一部ＯＦＤＭシンボルに対して）重畳した場合、Ａ／Ｎ  ＰＵＣＣＨリソースに対応するＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点とＳＲ  ＰＵＣＣＨの送信開始時点の間の相対的な関係によって、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定する方法を考慮できる。
【０１５８】
但し、端末がＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を行わない場合、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの一つの送信を省略することができる。
【０１５９】
一例として、端末は（Ａ／Ｎ  ＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）送信終了（或いは開始）時点がＴｒｅｆ，ｓｒ（即ち、Ｔｓｒ−Ｔｏ）より先立つか／遅れるかによって以下のようにＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。
【０１６０】
（１）（Ａ／Ｎ  ＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点がＴｒｅｆ，ｓｒより遅れた場合
【０１６１】
Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つを選択して送信
【０１６２】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１６３】
１．ＳＲをＳＲ  ＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０１６４】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１６５】
１．Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１６６】
（２）（Ａ／Ｎ  ＰＵＣＣＨリソースに対応する）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）の送信終了（或いは開始）時点がＴｒｅｆ，ｓｒより先立つ（又は同一である）場合
【０１６７】
Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信（又はＡ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのＯＦＤＭシンボルが完全に重畳する場合と同一のＵＣＩ多重化規則に従う）
【０１６８】
ｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【０１６９】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１７０】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信
【０１７１】
２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１７２】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１７３】
ｉｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【０１７４】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０１７５】
−Ａ／ＮをＳＲ  ＰＵＣＣＨリソースを介して送信。但し、ＳＲ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合にはＳＲを送信せず、Ａ／Ｎのみを送信する。
【０１７６】
２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０１７７】
−Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１７８】
ｉｉｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合
【０１７９】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲ又はｎｅｇａｔｉｖｅ  ＳＲである場合
【０１８０】
−ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１８１】
Ｔ0は以下のうちの１つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０１８２】
（１）端末能力（ｃａｐａｂｉｌｉｔｙ）によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０１８３】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０１８４】
（３）端末能力による復調に必要な端末処理時間又はそれに対応する値
【０１８５】
（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０１８６】
（５）基地局と端末の間に予め約束した値（例えば、固定値）
【０１８７】
［提案方法＃１］の変形として、Ａ／ＮとＣＳＩの間のＵＣＩ多重化についても、Ａ／ＮとＳＲの間のＵＣＩ多重化のように、以下の動作を行うことができる。例えば、Ａ／Ｎ  ＰＵＣＣＨリソースとＣＳＩ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末は（基準時点から）特定時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳するか否かによってＡ／ＮとＣＳＩの間の多重化の有無を決定することができる。
【０１８８】
但し、端末がＡ／ＮとＣＳＩの間の多重化を行わない場合には、Ａ／ＮとＣＳＩのうちの一つの送信を省略することができる。
【０１８９】
一例として、端末はＣＳＩ  ＰＵＣＣＨの送信開始時点（例えば、開始シンボル）（以下、Ｔｃｓｉ）を基準として、Ｔ0以前の時点（以下、Ｔｒｅｆ，ｃｓｉ）まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳するか否かによってＡ／ＮとＣＳＩの間の多重化の有無を決定することができる。Ｔｒｅｆ，ｃｓｉ＝Ｔｃｓｉ−Ｔ0と定義され、ＯＦＤＭシンボル単位で表現することができる。
【０１９０】
（ケース１）Ｔｒｅｆ，ｃｓｉまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳する場合は、端末はＡ／ＮとＣＳＩを多重化して送信することができる。
【０１９１】
（１）Ａ／Ｎ  ＰＵＣＣＨがＤＬ割り当てにより指示される場合
【０１９２】
−Ａ／ＮとＣＳＩを多重化してＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０１９３】
（２）Ａ／Ｎ  ＰＵＣＣＨがＤＬ割り当てにより指示されない場合
【０１９４】
−Ａ／ＮとＣＳＩを多重化してＣＳＩ  ＰＵＣＣＨリソースを介して送信
【０１９５】
（ケース２）（ケース１）に該当しない場合、端末はＡ／ＮとＣＳＩのうちの１つを選択して送信することができる。例えば、（ｉ）Ｔｒｅｆ，ＣＳＩ時点後に受信された（又は送信が開始／終了した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳するか、（ｉｉ）Ｔｒｅｆ，ＣＳＩまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳しないか、又は（ｉｉｉ）Ｔｒｅｆ，ＣＳＩまで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが存在しない場合、端末はＡ／ＮとＣＳＩのうちの１つを選択して送信することができる。
【０１９６】
（１）Ｏｐｔ．１：ＣＳＩをＣＳＩ  ＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０１９７】
（２）Ｏｐｔ．２：Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（ＣＳＩ送信を省略）
【０１９８】
Ｔ0は以下のうちの１つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０１９９】
（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０２００】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０２０１】
（３）端末能力による復調に必要な端末処理時間又はそれに対応する値
【０２０２】
（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０２０３】
（５）基地局と端末の間に予め約束した値（例えば、固定値）
【０２０４】
［提案方法＃１Ａ］端末に送信設定／指示されたＰＵＣＣＨリソースがスロット内の時間軸で全体又は一部のＯＦＤＭシンボルが重畳する場合、端末が以下のＵＣＩ多重化規則に従ってＵＣＩ多重化（例えば、ＵＣＩ多重化）を行う方法
【０２０５】
（１）スロット内で重畳したＰＵＣＣＨリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化して単一のＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨ）を介して送信
【０２０６】
Ａ．条件＃１
【０２０７】
ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対するＰＤＳＣＨ及び／又はＳＰＳ  ＰＤＳＣＨ解除（ｒｅｌｅａｓｅ）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２０８】
ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）がＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の最後の（各々の）（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２０９】
ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２１０】
ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＣＳＩ  ＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２１１】
ｖ．Ｏｐｔ．５：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードに対して端末に設定された（全ての）ＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２１２】
Ｂ．条件＃２
【０２１３】
ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、特定の規則によって選択される（単一の）ＰＵＣＣＨリソース、及びスロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２１４】
ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２１５】
ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードについて端末に設定された（全ての）ＰＵＣＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２１６】
ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）が（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２１７】
ここで、（スケジューリング）ＤＣＩベースのＰＵＣＣＨリソースは、ＤＣＩにより割り当てられたＨＡＲＱ−ＡＣＫ送信ＰＵＣＣＨリソースである。上記ＤＣＩの最後のシンボルは該当ＤＣＩを運ぶＰＤＣＣＨが送信された最後のシンボルである。
【０２１８】
（２）スロット内に重畳した（一部の）ＰＵＣＣＨリソースが条件を満たさない場合、端末は以下の動作を行うことができる。
【０２１９】
Ａ．Ｏｐｔ．１：端末は（２）の場合を期待せず、（２）の場合が発生した時に端末動作は端末の具現化に従う
【０２２０】
Ｂ．Ｏｐｔ．２：端末は（１）の条件を満たさない（一部の）ＰＵＣＣＨリソースに対するＵＣＩに対する送信を省略し、（１）の条件を満たす残りのＰＵＣＣＨリソースに対するＵＣＩを多重化して単一のＰＵＣＣＨリソースを介して送信
【０２２１】
Ｃ．Ｏｐｔ．３：端末はスロット内に重畳したＰＵＣＣＨリソースに対する送信を省略
【０２２２】
Ｄ．Ｏｐｔ．４：端末は（スロット内に重畳したＰＵＣＣＨリソースのうち）特定の（一つの）ＰＵＣＣＨリソース（例えば、最も高い優先順位のＵＣＩを送信するＰＵＣＣＨリソース、又は時間軸で最も先になるＰＵＣＣＨリソース）のみを送信し、残りは送信を省略
【０２２３】
但し、スロット内（上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより送信が指示された）の重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、（多重化する）ＵＣＩの組み合わせ、（全体）ＵＣＩペイロードサイズなどに基づいて定められた特定の規則によって、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨ）が新しく決定される。
【０２２４】
ここで、Ｔ1は端末がＰＤＳＣＨを受信した後、ＨＡＲＱ−ＡＣＫ送信を行うために必要な端末処理時間に対応する値である。また、Ｔ2は端末がＵＬ送信に対する（スケジューリング）ＤＣＩを受信した後、ＵＬ送信を行うために必要な端末処理時間に対応する値である。Ｔ1とＴ2は（ＯＦＤＭ）シンボル単位で表現することができる。
【０２２５】
端末は時間軸で重畳したＰＵＣＣＨリソースの間のＵＣＩ多重化の有無を決定するとき、少なくとも２個のタイムライン条件を考える。タイムライン条件＃１は、ＰＤＳＣＨの受信後、ＨＡＲＱ−ＡＣＫ送信までの端末処理時間を保証するための条件である。タイムライン条件＃１は、ＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルから一定時間Ｔ1以後にＨＡＲＱ−ＡＣＫ送信が行われることを目的とする。従って、Ｔ1時間に基づく条件は、ＨＡＲＱ−ＡＣＫ送信が行われるＵＬリソースを基準として適用する必要があり、重畳したＵＣＩが多重化されると仮定するとき、（特定の規則によって）決定されるＰＵＣＣＨリソースの開始時点とＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルの間に適用することができる。タイムライン条件＃２は、ＰＤＣＣＨの受信後、ＵＬ送信までの端末処理時間を保証するための条件である。タイムライン条件＃２は、（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨの最後の（ＯＦＤＭ）シンボルから一定の時間Ｔ2以後にＵＬ送信が行われることを目的とする。タイムライン条件＃２は、任意のＵＬ送信開始からＴ2以前にスケジュール有無を把握できるようにするという目的もある。従って、重畳したＰＵＣＣＨリソースのうち、最も早いＵＬリソースよりＴ2以前に（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨに対する受信が終了しなければならない。即ち、タイムライン条件＃２は、スロット内に重畳したＰＵＣＣＨリソース（及びＵＣＩを多重化すると仮定するとき、特定の規則によって選択される（単一の）ＰＵＣＣＨリソース）のうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始される条件である。
【０２２６】
［提案方法＃１Ｂ］端末に設定／指示されたＰＵＣＣＨリソースとＰＵＳＣＨリソースがスロット内の時間軸で全体或いは一部のＯＦＤＭシンボルが重畳する場合、端末が以下のＵＣＩ多重化規則に従ってＵＣＩ多重化を行う方法
【０２２７】
（１）スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースに対するＵＣＩ及びＵＬ−ＳＣＨ  ＴＢを多重化して、単一のＰＵＳＣＨリソース（以下、ＭＵＸ  ＰＵＳＣＨ）により送信
【０２２８】
Ａ．条件＃１
【０２２９】
ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、多重化されたＵＣＩを送信する（単一の）ＰＵＳＣＨリソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対するＰＤＳＣＨ及び／又はＳＰＳ  ＰＤＳＣＨ解除の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２３０】
ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）がＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２３１】
ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルがＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２３２】
ｉｖ．Ｏｐｔ．４：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩペイロードに対して端末に設定された（全ての）ＰＵＣＣＨリソースとスロット内の（全ての）ＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルが  ＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ（又はＳＰＳ  ＰＤＳＣＨ解除）の（各々の）最後の（ＯＦＤＭ）シンボルからＴ1以後に開始
【０２３３】
Ｂ．条件＃２
【０２３４】
ｉ．Ｏｐｔ．１：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２３５】
ｉｉ．Ｏｐｔ．２：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロット内の任意のＵＣＩの組み合わせ／ＵＣＩ  ペイロードに対して端末に設定された（全ての）ＰＵＣＣＨリソースと（全ての）ＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＵＬ送信リソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２３６】
ｉｉｉ．Ｏｐｔ．３：（スロット内に重畳したＰＵＣＣＨリソースのうち、ＤＣＩにより送信が指示されたＰＵＣＣＨリソースが存在する場合）スロットの１番目の（ＯＦＤＭ）シンボル（又はＵＬ送信が許容された１番目の（ＯＦＤＭ）シンボル）が（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始
【０２３７】
ここで、（スケジューリング）ＤＣＩベースのＰＵＣＣＨリソースは、ＤＣＩにより割り当てられたＨＡＲＱ−ＡＣＫ送信のＰＵＣＣＨリソースである。上記ＤＣＩの最後のシンボルは該当ＤＣＩを運ぶＰＤＣＣＨが送信された最後のシンボルである。
【０２３８】
（２）スロット内に重畳した（一部の）ＰＵＣＣＨリソース及び／又は（一部の）ＰＵＳＣＨリソースが上記条件を満たさない場合、
【０２３９】
Ａ．Ｏｐｔ．１：端末は（２）の場合を期待せず、（２）の場合が発生する時に端末動作は端末の具現化に従う
【０２４０】
Ｂ．Ｏｐｔ．２：端末は（１）の条件を満たさない（一部の）ＰＵＣＣＨリソースに対応するＵＣＩに対する送信及び／又は（一部の）ＰＵＳＣＨリソースに対応するＵＬ−ＳＣＨ  ＴＢに対する送信を省略。反面、端末は（１）の条件を満たす残りのＰＵＣＣＨリソース及び／又は残りのＰＵＳＣＨリソースに対するＵＣＩ及び／又はＵＬ−ＳＣＨを多重化して、単一のＰＵＣＣＨリソースや（（１）の条件を満たす重畳したＰＵＳＣＨリソースが存在する場合は）単一のＰＵＳＣＨリソースを介して送信
【０２４１】
Ｃ．Ｏｐｔ．３：端末はスロット内に重畳したＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対する送信を省略
【０２４２】
Ｄ．Ｏｐｔ．４：端末は（スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースのうち）特定の（一つの）ＰＵＣＣＨ又はＰＵＳＣＨリソース（例えば、最も高い優先順位のＵＣＩを送信するＵＬリソース又は時間軸で最も先になるＵＬリソース）のみを送信し、残りは送信を省略
【０２４３】
但し、スロット内の（上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより送信指示された）重畳したＰＵＣＣＨリソースに対するＵＣＩを多重化すると仮定するとき、（多重化する）ＵＣＩの組み合わせ、（全体）ＵＣＩペイロードサイズなどに基づいて定められた特定の規則に従って、多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨ）が新しく決定される。
【０２４４】
ここで、Ｔ1は端末がＰＤＳＣＨを受信した後、ＨＡＲＱ−ＡＣＫ送信を行うために必要な端末処理時間に対応する値である。またＴ2は端末がＵＬ送信に対する（スケジューリング）ＤＣＩを受信した後、ＵＬ送信を行うために必要な端末処理時間に対応する値である。Ｔ1とＴ2は（ＯＦＤＭ）シンボル単位で表現することができる。
【０２４５】
端末は時間軸で重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースの間のＵＣＩ多重化の有無を決定するとき、少なくとも２個のタイムライン条件を考える。タイムライン条件＃１は、ＰＤＳＣＨの受信後、ＨＡＲＱ−ＡＣＫ送信までの端末処理時間を保証するための条件である。タイムライン条件＃１は、ＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルから一定時間Ｔ1以後にＨＡＲＱ−ＡＣＫ送信が行われることを目的とする。従って、Ｔ1時間に基づく条件は、ＨＡＲＱ−ＡＣＫ送信が行われるＵＬリソースを基準として適用する必要があり、重畳したＵＣＩが多重化されると仮定するとき、（特定の規則によって）決定されるＰＵＣＣＨリソース又はＰＵＳＣＨリソースの開始時点とＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨの最後の（ＯＦＤＭ）シンボルの間に適用できる。タイムライン条件＃２は、ＰＤＣＣＨの受信後、ＵＬ送信までの端末処理時間を保証するための条件である。タイムライン条件＃２は、（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨの最後の（ＯＦＤＭ）シンボルから一定時間Ｔ2以後にＵＬ送信が行われることを目的とする。タイムライン条件＃２は、任意のＵＬ送信開始からＴ2以前にスケジュール有無を把握できるようにするという目的もある。従って、重畳したＰＵＣＣＨリソースのうち、最も早いＵＬリソースよりＴ2以前に（重畳したＰＵＣＣＨのうちの一つ以上のＵＬ送信をスケジュールする）ＰＤＣＣＨに対する受信が終了しなければならない。即ち、タイムライン条件＃２は、スロット内に重畳したＰＵＣＣＨリソース及びＰＵＳＣＨリソースのうち、（時間軸で）最も先になるＰＵＣＣＨリソースの１番目の（ＯＦＤＭ）シンボルが（スケジューリング）ＤＣＩの最後の（ＯＦＤＭ）シンボルからＴ2以後に開始される条件である。
【０２４６】
［提案方法＃１Ｃ］スロット内において端末に設定／指示されたＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対してＵＣＩ多重化を行うとき、端末が（段階的な）ＵＣＩ多重化、及び多重化されたＵＣＩ（即ち、ＭＵＸ  ＵＣＩ）に対する送信リソース決定を行う方法
【０２４７】
［方法＃Ａ］
【０２４８】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＳＣＨリソースに代替
【０２４９】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨ）に代替
【０２５０】
Ａ．多重化されたＵＣＩを送信する（単一の）ＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨ）が（時間軸で）他のＰＵＳＣＨリソース及び／又はＰＵＣＣＨリソース）と（新しく）重量する場合は、端末は以下のうちの１つの動作を行う。
【０２５１】
−Ｏｐｔ．１：（単一の）ＰＵＣＣＨリソースと（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースに対してＳｔｅｐ  １及び／又はＳｔｅｐ  ２を再適用
【０２５２】
−Ｏｐｔ．２：（単一の）ＰＵＣＣＨリソースによりＭＵＸ  ＵＣＩを送信し、（単一の）ＰＵＣＣＨリソースと重畳するＵＬリソースは送信を省略
【０２５３】
−Ｏｐｔ．３：（単一の）ＰＵＣＣＨリソースの送信を省略
【０２５４】
−Ｏｐｔ．４：エラーケースに処理（ｕｎｓｐｅｃｉｆｉｅｄ）
【０２５５】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）（上位層（例えば、ＲＲＣ）信号により設定された）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳する（上位層信号により設定された）ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用する。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定（単一）のＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨ）に代替する。
【０２５６】
［方法＃Ｂ］
【０２５７】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに該当ＰＵＳＣＨリソースと（時間軸で）重畳するＰＵＣＣＨリソースについてＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定（単一）のＰＵＳＣＨリソースに代替
【０２５８】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）開始シンボルが最も早い（或いは最も高い優先順位のＵＣＩを運ぶ）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ１）を基準として、（ｉ）ＰＵＣＣＨ１と、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソース（以下、ＰＵＣＣＨ２）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定（単一）のＰＵＣＣＨリソース（以下、ＰＵＣＣＨ３；即ち、ＭＵＸ  ＰＵＣＣＨ）に代替
【０２５９】
（３）Ｓｔｅｐ  ３
【０２６０】
Ａ．Ｓｔｅｐ  ３−１：（ｉ）Ｓｔｅｐ  ２のＰＵＣＣＨ３と、（ｉｉ）（ＰＵＣＣＨ１とＰＵＣＣＨ２を除いた）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ４）が（時間軸で）重畳する場合
【０２６１】
−Ｏｐｔ．１：ＰＵＣＣＨ３とＰＵＣＣＨ４に対してＵＣＩ多重化規則を適用（Ｓｔｅｐ  ２）。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定（単一）のＰＵＣＣＨリソースに代替
【０２６２】
−Ｏｐｔ．２：ＰＵＣＣＨ３の送信を省略する
【０２６３】
−Ｏｐｔ．３：ＰＵＣＣＨ４の送信を省略する
【０２６４】
Ｂ．Ｓｔｅｐ  ３−２：ＰＵＣＣＨ３及びＰＵＣＣＨ４が（時間軸で）重畳しない場合
【０２６５】
−ＰＵＣＣＨ４内のＰＵＣＣＨリソースを対象としてＳｔｅｐ  ２及びＳｔｅｐ  ３を適用
【０２６６】
ＵＣＩ多重化規則は、［提案方法＃１Ａ］又は［提案方法＃１Ｂ］に従う。
【０２６７】
各段階において、多重化されたＵＣＩに対する既存のＵＬリソースが特定の（単一の）ＰＵＣＣＨ或いはＰＵＳＣＨリソースに代替される場合、端末は代替された既存のＵＬリソースを、以後の段階では存在しないリソースと見なすことができる。即ち、代替された既存のＵＬリソースは、以後の過程ではＵＣＩ多重化対象として考慮されない。反面、多重化されたＵＣＩを送信するように決定された（単一の）ＰＵＣＣＨ或いはＰＵＳＣＨリソースは、以後の過程でＵＣＩ多重化対象として考慮される。
【０２６８】
各段階に複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースが存在するとき、複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースの間に該当段階の動作を適用する順序は所定の優先順位規則に従う。一例として、優先順位規則は、（スロット内の）相対的な送信時点（例えば、開始位置／シンボル）、ＵＣＩタイプ、リソース割り当て方式（例えば、動的又は準静的）、スケジュールされた順序、送信容量などを基準として決定される。
【０２６９】
一例として、スロット内の時間軸で重畳するＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対してＵＣＩ多重化を行うとき、一つのスロット内で複数のＰＵＣＣＨ送信及びＰＵＣＣＨ時間リソースの柔軟な割り当てが支援されるＮＲシステムの特徴により、ＵＣＩ多重化を行う対象となるＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースを決定することが不明な場合がある。たとえ、ＡＮ  ＰＵＣＣＨ、ＣＳＩ  ＰＵＣＣＨ、ＳＲ  ＰＵＣＣＨリソースが一つのスロット内に共存するとき、ＣＳＩ  ＰＵＣＣＨリソースはＡＮ  ＰＵＣＣＨリソース／ＳＲ  ＰＵＣＣＨリソースと時間軸で重畳する反面、ＡＮ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースは互いに時間軸で重畳しないと仮定する。この場合、（１）ＨＡＲＱ−ＡＣＫ、ＣＳＩ、ＳＲの全てに対する多重化を行うか、又は（２）ＨＡＲＱ−ＡＣＫ−ＣＳＩ対に対する多重化とＣＳＩ−ＳＲ対に対する多重化を行うかという端末動作が不明である。従って、本発明では、最も多い種類のＵＣＩを含むＵＬリソースの順でＵＣＩ多重化を行う方法（例えば、［方法＃Ａ］）、又は最も早い（或いは最も高い優先順位のＵＣＩを含む）ＰＵＣＣＨリソースを基準として時間軸で重畳したＰＵＣＣＨリソースに対して順にＵＣＩ多重化を行う方法（例えば、［方法＃Ｂ］）を提案する。［方法＃Ａ］の場合、ＰＵＳＣＨ＝＞（ＤＣＩベースにスケジュールされた）ＡＮ  ＰＵＣＣＨ＝＞ＣＳＩ  ＰＵＣＣＨ＝＞（上位層（例えば、ＲＲＣ）信号により設定された）ＡＮ  ＰＵＣＣＨの順にＵＣＩ多重化を行うことができる。この時、一度ＵＣＩ多重化対象として選定されたＰＵＣＣＨリソースは、以後のＵＣＩ多重化過程では排除される。
【０２７０】
［提案方法＃１Ｃ］の変形として、［方法＃Ａ］／［方法＃Ｂ］でＳｔｅｐ間の順序を変更することができる。例えば、以下の動作が考えられる。
【０２７１】
［方法＃Ａ−１］
【０２７２】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）（上位層（例えば、ＲＲＣ）信号により設定された）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳する（上位層信号により設定された）ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一の）ＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨリソース）に代替することができる。
【０２７３】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一の）ＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨリソース）に代替することができる。ここで、重畳したＰＵＣＣＨリソースは、スロット内のＰＵＣＣＨリソースを意味する。
【０２７４】
Ａ．ＭＵＸ  ＰＵＣＣＨリソースが（時間軸で）他のＰＵＣＣＨリソース）と（新しく）重畳する場合、以下の動作を行う。
【０２７５】
−Ｏｐｔ．１：（ｉ）ＭＵＸ  ＰＵＣＣＨリソースと、（ｉｉ）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースに対してＳｔｅｐ  ２を再適用
【０２７６】
−Ｏｐｔ．２：ＭＵＸ  ＰＵＣＣＨリソースに対する送信を行うが、ＭＵＸ  ＰＵＣＣＨリソースと重畳するＵＬリソースに対する送信を省略
【０２７７】
−Ｏｐｔ．３：ＭＵＸ  ＰＵＣＣＨリソースに対する送信を省略
【０２７８】
−Ｏｐｔ．４：エラーケースに処理（ｕｎｓｐｅｃｉｆｉｅｄ）
【０２７９】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ここで、ＰＵＣＣＨリソースはＭＵＸ  ＰＵＣＣＨリソースを含む。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、特定の（単一の）ＰＵＳＣＨリソースに代替することができる。
【０２８０】
［方法＃Ａ−２］
【０２８１】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一の）ＰＵＳＣＨリソース（以下、ＭＵＸ  ＰＵＳＣＨリソース）に代替することができる。
【０２８２】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）（上位層（例えば、ＲＲＣ）信号により設定された）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳する（上位層信号により設定された）ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一の）ＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨリソース）に代替することができる。
【０２８３】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは（単一の）ＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨリソース）に代替することができる。
【０２８４】
Ａ．ＭＵＸ  ＰＵＣＣＨリソースが（時間軸で）他のＰＵＳＣＨリソース及び／又はＰＵＣＣＨリソース）と（新しく）重畳する場合、以下の動作を行う。
【０２８５】
−Ｏｐｔ．１：（ｉ）ＭＵＸ  ＰＵＣＣＨリソースと、（ｉｉ）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースに対してＳｔｅｐ  １及び／又はＳｔｅｐ  ３を再適用
【０２８６】
−Ｏｐｔ．２：ＭＵＸ  ＰＵＣＣＨリソースに対する送信を行うが、ＭＵＸ  ＰＵＣＣＨリソースと重畳するＵＬリソースに対するＵＣＩ送信を省略
【０２８７】
−Ｏｐｔ．３：ＭＵＸ  ＰＵＣＣＨリソースに対するＵＣＩ送信を省略
【０２８８】
−Ｏｐｔ．４：エラーケースに処理（ｕｎｓｐｅｃｉｆｉｅｄ）
【０２８９】
［方法＃Ｂ−１］
【０２９０】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）開始シンボル（又は最後のシンボル）が最も早い（或いは最高優先順位のＵＣＩを運ぶ）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ１）を基準として、（ｉ）ＰＵＣＣＨ１と、（ｉｉ）これと（時間軸で）重畳するＰＵＣＣＨリソース（以下、ＰＵＣＣＨ２））に対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソース（即ち、ＰＵＣＣＨ１／ＰＵＣＣＨ２）は、（単一）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ３又はＭＵＸ  ＰＵＣＣＨ１）に代替することができる。
【０２９１】
（２）Ｓｔｅｐ  ２
【０２９２】
Ａ．Ｓｔｅｐ  ２−１：（ｉ）ＰＵＣＣＨ３と、（ｉｉ）（ＰＵＣＣＨ１／ＰＵＣＣＨ２を除いた）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ４）が（時間軸で）重畳する場合
【０２９３】
−Ｏｐｔ．１：ＰＵＣＣＨ３とＰＵＣＣＨ４に対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ３−１又はＭＵＸ  ＰＵＣＣＨ２）に代替することができる。
【０２９４】
−Ｏｐｔ．２：ＰＵＣＣＨ３の送信を省略する。
【０２９５】
−Ｏｐｔ．３：ＰＵＣＣＨ４の送信を省略する。
【０２９６】
Ｂ．Ｓｔｅｐ  ２−２：（ｉ）ＰＵＣＣＨ３と、（ｉｉ）（ＰＵＣＣＨ１／ＰＵＣＣＨ２を除いた）ＰＵＣＣＨリソース（以下、ＰＵＣＣＨ４）が（時間軸で）重畳しない場合
【０２９７】
−ＰＵＣＣＨ４内のＰＵＣＣＨリソースを対象としてＳｔｅｐ  １／２を適用
【０２９８】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用することができる。ここで、ＰＵＣＣＨリソースはＳｔｅｐ  １／２が行われた後のＰＵＣＣＨリソースを意味する。即ち、ＰＵＣＣＨリソースは時間軸で重畳せず、ＭＵＸ  ＰＵＣＣＨリソースを含む。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースは、（単一）ＰＵＳＣＨリソース（即ち、ＭＵＸ  ＰＵＳＣＨリソース）に代替することができる。
【０２９９】
ＵＣＩ多重化規則は［提案方法＃１Ａ］又は［提案方法＃１Ｂ］に従う。［提案方法＃１Ａ］はＰＵＣＣＨ−ＰＵＣＣＨ  ＵＣＩ多重化のためのタイムライン条件を含み、［提案方法＃１Ｂ］はＰＵＣＣＨ−ＰＵＳＣＨ  ＵＣＩ多重化のためのタイムライン条件を含む。スロット内の重畳したＵＬチャネル（リソース）はタイムライン条件を満たす場合に限って、Ｓｔｅｐ  １／２／３でＵＣＩ多重化が行われるように制限することができる。タイムライン条件は、（１）ＨＡＲＱ−ＡＣＫ送信のための端末処理時間、（２）ＰＤＣＣＨの受信後、ＵＬ送信（例：ＰＵＣＣＨ、ＰＵＳＣＨ）のための端末処理時間に関連する。従って、（１）／（２）に関連するＵＬ送信がない場合は、タイムライン条件を考える必要がなく、重畳したＵＬチャネル（リソース）に対してＵＣＩ多重化を行うことができる。ＵＣＩ多重化が行われる場合、（多重化する）ＵＣＩの組み合わせ、（全体）ＵＣＩペイロードサイズなどに基づいて、特定の規則に従って、多重化されたＵＣＩを送信する（単一）ＰＵＣＣＨリソース（即ち、ＭＵＸ  ＰＵＣＣＨ）が新しく決定される。
【０３００】
ＭＵＸ  ＰＵＣＣＨは本発明で提案する様々な方法により決定される。例えば、［提案方法＃１Ｈ］を参照すると、端末はＡＮと他のＵＣＩを多重化した後、多重化された（総）ＵＣＩペイロードサイズに対応するＰＵＣＣＨリソース集合を選択する。その後、端末は該当ＰＵＣＣＨリソース集合内のＰＵＣＣＨリソースのうち、ＡＲＩにより指示されたＰＵＣＣＨリソースを用いて多重化されたＵＣＩを送信する。ＰＵＣＣＨリソース集合が支援するＵＣＩサイズが２ビット以下である場合、ＰＵＣＣＨリソース集合はＰＵＣＣＨフォーマット０／１を含む。反面、ＰＵＣＣＨリソース集合が支援するＵＣＩサイズが３ビット以上である場合は、ＰＵＣＣＨリソース集合はＰＵＣＣＨフォーマット２／３／４を含む。ＰＵＣＣＨリソース集合個数が一つ以上であると、少なくとも一つのＰＵＣＣＨリソース集合は２ビット以下のＵＣＩ送信用として設定される。
【０３０１】
各段階で多重化されたＵＣＩに対する既存のＵＬリソースが（単一）ＰＵＣＣＨ或いはＰＵＳＣＨリソース（以下、ＭＵＸ  ＵＬリソース）に代替された場合、端末は代替された既存のＵＬリソースは以後の段階では存在しないとみなすことができる。即ち、ＭＵＸ  ＵＬリソースに代替された既存のＵＬリソースは、以後の段階ではＵＣＩ多重化対象として考慮されない。反面、ＭＵＸ  ＵＬリソースは以後の段階でＵＣＩ多重化対象として考慮される。
【０３０２】
各段階に複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースが存在するとき、複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースの間において該当段階の動作を適用する手順は、所定の優先順位規則に従う。一例として、優先順位規則は（スロット内の）相対的な送信時点（例：開始位置／シンボル）、ＵＣＩタイプ、リソース割り当て方式（例：動的又は準静的）、スケジューリング手順、送信容量などを基準として定められる。
【０３０３】
図９は方法＃Ｂ−１に従うチャネル多重化過程を例示する。図９を参照すると、端末は（スロット内の）重畳したＰＵＣＣＨリソースに対してＵＣＩ多重化を行う（Ｓｔｅｐ  １、Ｓ１１０２）。例えば、端末は（多重化されたＵＣＩ送信が許容された）開始シンボルが最も早いＰＵＣＣＨリソース（以下、ＰＵＣＣＨ１）を基準として、（ｉ）ＰＵＣＣＨ１と、（ｉｉ）それと（時間軸で）重畳するＰＵＣＣＨリソース（以下、ＰＵＣＣＨ２））に対してＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化が適用される重畳したＵＬリソース（即ち、ＰＵＣＣＨ１／ＰＵＣＣＨ２）は、（単一）ＰＵＣＣＨリソース（以下、ＭＵＸ  ＰＵＣＣＨ１）に代替することができる。その後、端末はＳｔｅｐ  １の結果に基づいてＰＵＳＣＨリソースにＵＣＩピギーバックを行う（Ｓｔｅｐ  ２、Ｓ１１０４）。例えば、端末は（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用する。より詳しくは、方法＃Ｂ−１に関する説明を参照することができる。その後、端末はＰＵＳＣＨを介してＵＣＩを送信する。スロット内に重畳したＰＵＳＣＨがない場合、Ｓｔｅｐ  ２は省略され、ＵＣＩはＰＵＣＣＨを介して送信される。
【０３０４】
［提案方法＃１Ｃ］の変形として以下の動作を考えることができる。この提案は方法＃Ｂ−１の変形として理解できる。Ｓｔｅｐ＃Ａ／＃Ｂ１／＃Ｂ２は方法＃Ｂ−１のＳｔｅｐ１／２−２／２−１に対応し、方法＃Ｂ−１においてＳｔｅｐ１／２−１／２−２は各々Ｓｔｅｐ＃Ａ／＃Ｂ１／＃Ｂ２に代替することができる。  
【０３０５】
（１）Ｓｔｅｐ＃Ａ：開始シンボル（又は最後のシンボル）が最も早い（或いは最も高い優先順位のＵＣＩを運ぶ）ＰＵＣＣＨ（以下、ＰＵＣＣＨ１）を基準として、（ｉ）ＰＵＣＣＨ１と、（ｉｉ）これと（時間軸で）重なるＰＵＣＣＨ（以下、ＰＵＣＣＨ２）に限ってＰＵＣＣＨ−ＰＵＣＣＨの間のＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩを送信するために（単一の）コンテナーＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ１）が決定される。即ち、重畳した既存のＵＬリソース（即ち、ＰＵＣＣＨ１／ＰＵＣＣＨ２）はＭＵＸ  ＰＵＣＣＨ１に代替することができる。
【０３０６】
（２）Ｓｔｅｐ＃Ｂ１：（ｉ）Ｓｔｅｐ＃Ａで決定された（多重化されたＵＣＩ送信用）コンテナーＰＵＣＣＨ（即ち、ＭＵＸ  ＰＵＣＣＨ１）と、（ｉｉ）（ＰＵＣＣＨ１／ＰＵＣＣＨ２を除いた）残りのＰＵＣＣＨ（以下、ＰＵＣＣＨ３）が重ならない場合、
【０３０７】
−（ＰＵＣＣＨ３内のＰＵＣＣＨの間にＳｔｅｐ＃Ａを適用して）時間軸で重畳しないＰＵＣＣＨをＴＤＭに送信することができる。
【０３０８】
（３）Ｓｔｅｐ＃Ｂ２：（ｉ）ＭＵＸ  ＰＵＣＣＨ１と（ｉｉ）ＰＵＣＣＨ３が重なる場合、
【０３０９】
−Ｏｐｔ  １：コンテナーＰＵＣＣＨ（即ち、ＭＵＸ  ＰＵＣＣＨ１）とＰＵＣＣＨ３に対して再度ＰＵＣＣＨ−ＰＵＣＣＨの間のＵＣＩ多重化規則を適用することができる。ＵＣＩ多重化を行うとき、多重化されたＵＣＩを送信するために、（単一の）コンテナーＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ２）が新しく決定される。即ち、重畳した既存のＵＬリソース（即ち、ＭＵＸ  ＰＵＣＣＨ１／ＰＵＣＣＨ３）をＭＵＸ  ＰＵＣＣＨ２に代替することができる。ＭＵＸ  ＰＵＣＣＨ２に対してＳｔｅｐ＃Ｂ１／＃Ｂ２が再び適用されることができる。
【０３１０】
−Ｏｐｔ  ２：ＰＵＣＣＨ３の送信を省略することができる。
【０３１１】
図１０はＳｔｅｐ＃Ａ／＃Ｂ１／＃Ｂ２によるチャネル多重化過程を例示する。ＵＣＩ送信のために、端末はＵＣＩごとにＰＵＣＣＨリソースを決定する。各ＰＵＣＣＨリソースは開始シンボルと送信の長さにより定義される。（スロット内に）重畳したＰＵＣＣＨリソースがある場合、端末は最も早い（例えば、開始シンボルが最も早い）ＰＵＣＣＨリソースＡと重畳するＰＵＣＣＨリソースセットＸを決定する（Ｓｔｅｐ  Ａ１、Ｓ１２０２）。その後、端末は（ｉ）ＰＵＣＣＨリソースＡと、（ｉｉ）ＰＵＣＣＨリソースセットＸに対してＵＣＩ多重化を行う（Ｓｔｅｐ  Ａ１、Ｓ１２０４）。ＵＣＩ多重化を行うとき、多重化されたＵＣＩを送信するために、（単一の）コンテナーＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ）が決定される。これにより、ＰＵＣＣＨリソースＡとＰＵＣＣＨリソースセットＸをＭＵＸ  ＰＵＣＣＨに代替できる。その後、端末はＭＵＸ  ＰＵＣＣＨを介してＵＣＩを送信する。もしＭＵＸ  ＰＵＣＣＨが（ＰＵＣＣＨリソースＡ／ＰＵＣＣＨリソースセットＸを除いた）残りのＰＵＣＣＨと重なる場合は、端末はＭＵＸ  ＰＵＣＣＨ（又はこれを含む残りのＰＵＣＣＨのうち、最も早い（例えば、開始シンボルが最も早い）ＰＵＣＣＨ）を最も早い（例えば、開始シンボルが最も早い）ＰＵＣＣＨリソースＡに代替した状態でＳｔｅｐ  Ａ１／Ａ２を再度行うことができる。より詳しい事項は、Ｓｔｅｐ＃Ａ／＃Ｂ１／＃Ｂ２に関する説明を参照する。図１０のＳｔｅｐ  Ａ１／Ａ２は図９のＳｔｅｐ  １に対応し、図９のＳｔｅｐ  １は図１０のＳｔｅｐ  Ａ１／Ａ２に代替することができる。
【０３１２】
図１１は図１０によるＵＣＩ多重化を例示する。図１１を参照すると、スロット内に複数のＰＵＣＣＨリソースが重畳する場合、最も早い（例えば、開始シンボルが最も早い）ＰＵＣＣＨリソースＡを基準としてＵＣＩ多重化が行われる。ケース１／２は１番目のＰＵＣＣＨリソースが他のＰＵＣＣＨリソースと重畳する場合を示す。この場合、１番目のＰＵＣＣＨリソースを最も早いＰＵＣＣＨリソースＡと見なした状態で図１０の過程が行われる。反面、ケース３は、１番目のＰＵＣＣＨリソースが他のＰＵＣＣＨリソースと重畳せず、２番目のＰＵＣＣＨリソースが他のＰＵＣＣＨリソースと重畳する場合である。この場合、１番目のＰＵＣＣＨリソースについてはＵＣＩ多重化が行われない。その代わりに、２番目のＰＵＣＣＨリソースを最も早いＰＵＣＣＨリソースＡと見なした状態で図１０の過程が行われる。ケース２は、多重化されたＵＣＩを送信するために決定されたＭＵＸ  ＰＵＣＣＨリソースが他のＰＵＣＣＨリソースと新しく重畳する場合である。この場合、ＭＵＸ  ＰＵＣＣＨリソース（又はこれを含む残りのＰＵＣＣＨのうち、最も早い（例えば、開始シンボルが最も早い）ＰＵＣＣＨリソース）を最も早いＰＵＣＣＨリソースＡと見なした状態で図１０の過程がさらに行われる。より詳しい事項はＳｔｅｐ＃Ａ／＃Ｂ１／＃Ｂ２に関する説明を参照する。
【０３１３】
［提案方法＃１Ｃ］の変形として、端末に設定／指示されたＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対してＵＣＩ多重化（即ち、ＵＣＩ多重化）を行うとき、端末は以下のように（段階的な）ＵＣＩ多重化、及び多重化されたＵＣＩに対する送信リソース決定を行う方法を考えることができる。
【０３１４】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）（上位層（例えば、ＲＲＣ）信号により設定された）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳する（上位層信号により設定された）ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替
【０３１５】
Ａ．一例として、Ｓｔｅｐ  １の詳しい段階は以下の通りである。
【０３１６】
［Ｅｘａｍｐｌｅ  ＃１］
【０３１７】
−Ｓｔｅｐ  １−１：ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３１８】
−Ｓｔｅｐ  １−２：ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＡＮ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３１９】
−Ｓｔｅｐ  １−３：ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＳＲ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３２０】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替
【０３２１】
Ａ．一例として、Ｓｔｅｐ  ２の詳しい段階は以下の通りである。
【０３２２】
［Ｅｘａｍｐｌｅ  ＃１］
【０３２３】
−Ｓｔｅｐ  ２−１：（ＤＣＩに基づいてスケジュールされた）ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソース（及び／又はＡＮ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３２４】
［Ｅｘａｍｐｌｅ  ＃２］
【０３２５】
−Ｓｔｅｐ  ２−１：（ＤＣＩに基づいてスケジュールされた）ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソース（及び／又はＡＮ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３２６】
−Ｓｔｅｐ  ２−２：（ＤＣＩに基づいてスケジュールされた）ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＳＲ  ＰＵＣＣＨリソース（及び／又はＣＳＩ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３２７】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＳＣＨリソースに代替
【０３２８】
各段階に複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースが存在するとき、複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースの間に該当段階の動作を適用する順序は、所定の優先順位規則に従う。一例として、優先順位規則は、（スロット内の）相対的な送信時点（例えば、開始位置／シンボル）、ＵＣＩタイプ、リソース割り当て方式（例えば、動的又は準静的）、スケジュールされた順序、送信容量などを基準として決定される。
【０３２９】
各段階において、多重化されたＵＣＩを送信するために新しく選択されたＰＵＣＣＨリソースが、多重化されたＵＣＩに対する（既存の）ＰＵＣＣＨリソース以外の他のＰＵＣＣＨリソースと（時間軸で）重畳する場合は、端末はこの場合をエラーケースと判断して期待しない。又は、新しく選択されたＰＵＣＣＨリソースと重畳したＰＵＣＣＨリソースとＵＣＩ多重化規則を適用し、ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替することができる。
【０３３０】
［提案方法＃１Ｃ］の変形として、スロット内の端末に設定／指示されたＰＵＣＣＨリソース及び／又はＰＵＳＣＨリソースに対してＵＣＩ多重化を行うとき、端末は以下のように（段階的な）ＵＣＩ多重化、及び多重化されたＵＣＩに対する送信リソース決定を行う方法を考えることができる。
【０３３１】
（１）Ｓｔｅｐ  １：（多重化されたＵＣＩ送信が許容された）ＰＵＳＣＨリソースが存在するとき、ＰＵＳＣＨリソースごとに、（ｉ）該当ＰＵＳＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＳＣＨリソースに代替
【０３３２】
（２）Ｓｔｅｐ  ２：（多重化されたＵＣＩ送信が許容された）（ＤＣＩに基づいてスケジュールされた）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替
【０３３３】
Ａ．一例として、Ｓｔｅｐ  ２の詳しい段階は以下の通りである。
【０３３４】
［Ｅｘａｍｐｌｅ  ＃１］
【０３３５】
−Ｓｔｅｐ  ２−１：（ＤＣＩに基づいてスケジュールされた）ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソース（及び／又はＡＮ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３３６】
［Ｅｘａｍｐｌｅ  ＃２］
【０３３７】
−Ｓｔｅｐ  ２−１：（ＤＣＩに基づいてスケジュールされた）ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソース（及び／又はＡＮ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３３８】
−Ｓｔｅｐ  ２−２：（ＤＣＩに基づいてスケジュールされた）ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＳＲ  ＰＵＣＣＨリソース（及び／又はＣＳＩ  ＰＵＣＣＨリソース）に対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３３９】
（３）Ｓｔｅｐ  ３：（多重化されたＵＣＩ送信が許容された）（上位層（例えば、ＲＲＣ）信号により設定された）ＰＵＣＣＨリソースが存在するとき、ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳する（上位層信号により設定された）ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替
【０３４０】
Ａ．一例として、Ｓｔｅｐ  ３の詳しい段階は以下の通りである。
【０３４１】
［Ｅｘａｍｐｌｅ  ＃１］
【０３４２】
−Ｓｔｅｐ  ３−１：ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＣＳＩ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３４３】
−Ｓｔｅｐ  ３−２：ＣＳＩ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＡＮ  ＰＵＣＣＨリソース及び／又はＳＲ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＣＳＩ）ＰＵＣＣＨリソースに代替
【０３４４】
−Ｓｔｅｐ  ３−３：ＡＮ  ＰＵＣＣＨリソースごとに、（ｉ）該当ＰＵＣＣＨリソースと、（ｉｉ）（時間軸で）重畳するＳＲ  ＰＵＣＣＨリソースに対してＵＣＩ多重化規則を適用。ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）（ＡＮ）ＰＵＣＣＨリソースに代替
【０３４５】
各段階に複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースが存在するとき、複数のＰＵＣＣＨ（又はＰＵＳＣＨ）リソースの間に該当段階の動作を適用する順序は、所定の優先順位規則に従う。一例として、優先順位規則は、（スロット内の）相対的な送信時点（例えば、開始位置／シンボル）、ＵＣＩタイプ、リソース割り当て方式（例えば、動的又は準静的）、スケジュールされた順序、送信容量などを基準として決定される。
【０３４６】
各段階において、多重化されたＵＣＩを送信するために新しく選択されたＰＵＣＣＨリソースが、多重化されたＵＣＩに対する（既存の）ＰＵＣＣＨリソース以外の他のＰＵＣＣＨリソースと（時間軸で）重畳する場合、端末はこの場合をエラーケースと判断して期待しない。又は、新しく選択されたＰＵＣＣＨリソースと重畳したＰＵＣＣＨリソースとＵＣＩ多重化規則を適用し、ＵＣＩ多重化を行うとき、多重化されたＵＣＩに対する既存のＵＬリソースを特定の（単一の）ＰＵＣＣＨリソースに代替することができる。
【０３４７】
［提案方法＃１Ｄ］スロット内で端末に設定／指示された（準静的に設定された）（単一の）ＳＲ  ＰＵＣＣＨリソースが２つ以上の（準静的に設定された）ＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳する場合に、端末が以下のうちの一つの動作を行う方法
【０３４８】
（１）Ｏｐｔ．１：ＳＲビットを各ＣＳＩ  ＰＵＣＣＨリソースのＵＣＩペイロードに全て追加してＣＳＩとＳＲを多重化して送信。即ち、ＳＲ情報をＳＲ  ＰＵＣＣＨと重畳した全てのＣＳＩ  ＰＵＣＣＨに含めることができる。
【０３４９】
−複数のＣＳＩ  ＰＵＣＣＨリソースに含まれるＳＲ情報は、最初のＣＳＩ  ＰＵＣＣＨリソースに送信されたＳＲ情報がコピーされる（或いは同一に送信される）形態である。即ち、複数のＣＳＩ  ＰＵＣＣＨリソースに含まれるＳＲ情報は、全て同一にコピーされた情報である。また複数のＣＳＩ  ＰＵＣＣＨリソースに含まれるＳＲ情報は、各ＣＳＩ  ＰＵＣＣＨリソースごとに更新された（或いは、各ＣＳＩ  ＰＵＣＣＨ時点の端末のＳＲ状態（例えば、ｎｅｇａｔｉｖｅ又はｐｏｓｉｔｉｖｅ）を反映する）ＳＲ情報である。即ち、複数のＣＳＩ  ＰＵＣＣＨリソースに含まれるＳＲ情報は、各ＣＳＩ  ＰＵＣＣＨリソースの送信時点ごとに更新されたＳＲ情報である。
【０３５０】
（２）Ｏｐｔ．２：ＳＲビットを特定の一つのＣＳＩ  ＰＵＣＣＨリソースのＵＣＩペイロードのみに追加してＣＳＩとＳＲを多重化して送信。ここで、特定の一つのＣＳＩ  ＰＵＣＣＨリソースは以下のうちの一つである。
【０３５１】
−Ｏｐｔ．２−１：時間軸で最初（又は最後）のＣＳＩ  ＰＵＣＣＨリソース、或いは開始時点が最も早い（又は遅い）ＣＳＩ  ＰＵＣＣＨリソース。即ち、ＳＲ情報をＳＲ  ＰＵＣＣＨと重畳した全てのＣＳＩ  ＰＵＣＣＨのうちの１番目のＣＳＩ  ＰＵＣＣＨのみに含めることができる。
【０３５２】
−Ｏｐｔ．２−２：最も送信容量が大きいＣＳＩ  ＰＵＣＣＨリソース
【０３５３】
−Ｏｐｔ．２−３：最も高い優先順位を有するＣＳＩに設定されたＣＳＩ  ＰＵＣＣＨリソース
【０３５４】
ＮＲシステムでは単一のＣＳＩ  ＰＵＣＣＨリソースと一つ又はそれ以上のＳＲ  ＰＵＣＣＨリソースが一つのスロット内で重畳する場合、全てのＵＣＩを多重化して単一のＣＳＩ  ＰＵＣＣＨリソースを介して送信する動作が考えられる。この時、ＣＳＩとＳＲを多重化する問題について、上記の場合とは逆に、単一のＳＲ  ＰＵＣＣＨリソースが複数のＣＳＩ  ＰＵＣＣＨリソースと重畳する場合のＵＣＩ多重化規則も定める必要がある。この問題については、上述したオプションを考慮できる。
【０３５５】
［提案方法＃１Ｆ］スロット内において、端末に設定／指示された（単一の）ＰＵＳＣＨリソースが２つ以上のＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）と時間軸で重畳する場合に、端末が以下のうちの一つの動作を行う方法
【０３５６】
（１）Ｏｐｔ．１：ＰＵＳＣＨと重畳したＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）のうち、特定の一つのＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）に対するＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ情報）をＵＬ−ＳＣＨ  ＴＢ（例えば、ＵＬデータ）と多重化してＰＵＳＣＨリソースを介して送信（例えば、ＵＣＩピギーバック）。
【０３５７】
−特定の一つのＣＳＩ  ＰＵＣＣＨリソースは、時間軸で最も早い或いは優先順位が最も高いＣＳＩに設定されたＣＳＩ  ＰＵＣＣＨリソースを含む。また、特定の一つのＡＮ  ＰＵＣＣＨリソースは、時間軸で最も早いＡＮ  ＰＵＣＣＨリソースを含む。
【０３５８】
−特定の一つのＣＳＩ  ＰＵＣＣＨ（又はＡＮ  ＰＵＣＣＨ）以外の残りのＣＳＩ  ＰＵＣＣＨ（又はＡＮ  ＰＵＣＣＨ）及び対応するＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ）の送信は省略できる。
【０３５９】
（２）Ｏｐｔ．２：ＰＵＳＣＨと重畳したＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）に対するＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ情報）を全てＵＬ−ＳＣＨ  ＴＢ（例えば、ＵＬデータ）と多重化してＰＵＳＣＨリソースを介して送信（例えば、ＵＣＩピギーバック）。又はＰＵＳＣＨと重畳したＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）に対するＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ情報）のうち、予め定義／設定された優先順位規則に従って優先順位が高い最大Ｍ個までのＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ情報）をＵＬ−ＳＣＨ  ＴＢ（例えば、ＵＬデータ）と多重化してＰＵＳＣＨリソースを介して送信（例えば、ＵＣＩピギーバック）
【０３６０】
−Ｍ値は１又は２である。
【０３６１】
−Ｍ値は予め約束された値であるか、又は上位層（例えば、ＲＲＣ）信号により設定／定義される値である。
【０３６２】
［提案方法＃１Ｆ］において、ＰＵＳＣＨリソースをＣＳＩ  ＰＵＣＣＨリソースに置き換え、ＵＬ−ＳＣＨ  ＴＢをＣＳＩに置き換えた場合、ＣＳＩ  ＰＵＣＣＨリソースとＡＮ  ＰＵＣＣＨリソースに対するＣＩ多重化動作は同様に適用できる。
【０３６３】
ＮＲシステムは柔軟なＰＵＣＣＨ送信区間の設定が支援されるので、単一のＰＵＳＣＨリソースと一つ又はそれ以上のＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）が１スロット内で重畳する場合があり得る。この場合、優先順位規則に基づいて（優先順位が高い）Ｍ個のＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）に対するＭ個のＣＳＩ報告のみをＰＵＳＣＨでＵＣＩピギーバックすることができる。Ｍ値は予め約束された値であるか、又は上位層信号により設定／定義された値である。又は簡単な方法として、ＰＵＳＣＨリソースと時間軸で１番目に重畳したＣＳＩ  ＰＵＣＣＨリソース（又はＡＮ  ＰＵＣＣＨリソース）に対するＣＳＩ報告（又はＨＡＲＱ−ＡＣＫ）のみをＰＵＳＣＨでＵＣＩピギーバックすることができる。
【０３６４】
［提案方法＃１Ｈ］端末が、（２ビット以下のＡＮに対する）ＡＮ  ＰＵＣＣＨリソースとＮ個の（例えば、Ｎ＞１）ＳＲ  ＰＵＣＣＨリソースに対するＵＣＩ多重化を行うとき、ＡＮ  ＰＵＣＣＨに対するスケジューリング方法及び／又はＡＮ  ＰＵＣＣＨに対して設定されたＰＵＣＣＨリソース集合数Ｋによって多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）を送信するＰＵＣＣＨフォーマットを以下のように異ならせる方法
【０３６５】
（１）ＡＮ  ＰＵＣＣＨリソースがＤＣＩ（例えば、ＡＲＩ）により指示された場合
【０３６６】
Ａ．Ｋ＞１である場合
【０３６７】
−多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）をＰＵＣＣＨフォーマット２／３／４のうちの１つで送信
【０３６８】
Ｂ．Ｋ＝１である場合
【０３６９】
−多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）をＰＵＣＣＨフォーマット０／１のうちの１つで送信
【０３７０】
（２）ＡＮ  ＰＵＣＣＨリソースがＤＣＩ（例えば、ＡＲＩ）により指示されない場合（例えば、ＡＮ  ＰＵＣＣＨリソースがＳＰＳ  ＰＤＳＣＨに対するＡ／Ｎ情報に連関する場合）
【０３７１】
Ａ．Ｋ＞１である場合
【０３７２】
−Ｏｐｔ．１：多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）をＰＵＣＣＨフォーマット０／１のうちの１つで送信
【０３７３】
−Ｏｐｔ．２：多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）を特定のＡＲＩ値を仮定して選択されたＰＵＣＣＨフォーマット２／３／４のうちの１つで送信
【０３７４】
Ｂ．Ｋ＝１である場合
【０３７５】
−多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）をＰＵＣＣＨフォーマット０／１のうちの１つで送信
【０３７６】
上述した方法により、ＡＮ  ＰＵＣＣＨリソースがＮ個（例えば、Ｎ＞１）のＳＲ  ＰＵＣＣＨリソースと時間軸で重畳するとき、端末はＡＮとＳＲを多重化することができる。
【０３７７】
端末は（総）ＵＣＩペイロードサイズによってＰＵＣＣＨリソース集合を選択した後、選択されたＰＵＣＣＨリソース集合内のＰＵＣＣＨリソースのうち、ＡＲＩにより指示されたＰＵＣＣＨリソースによりＵＣＩ（例えば、ＨＡＲＱ−ＡＣＫ）を送信することができる。ここで、ＡＲＩ（ＡＣＫ／ＮＡＣＫリソース指示子）はＤＣＩ内のＰＵＣＣＨリソースを指示するビットフィールドを意味する。
【０３７８】
一方、ＡＮ  ＰＵＣＣＨリソースに対するＰＵＣＣＨリソース集合個数は複数である（Ｋ＞１）。この場合、端末はＡＮと他のＵＣＩを多重化した後、多重化された（総）ＵＣＩペイロードサイズに対応するＰＵＣＣＨリソース集合を選択する。その後、端末は該当ＰＵＣＣＨリソース集合内のＰＵＣＣＨリソースのうち、ＡＲＩにより指示されたＰＵＣＣＨリソースを用いて多重化されたＵＣＩを送信する。この時、ＰＵＣＣＨリソース集合が支援するＵＣＩサイズが２ビット以下である場合、ＰＵＣＣＨリソース集合はＰＵＣＣＨフォーマット０／１を含む。反面、ＰＵＣＣＨリソース集合が支援するＵＣＩサイズが３ビット以上である場合は、ＰＵＣＣＨリソース集合はＰＵＣＣＨフォーマット２／３／４を含む。ＰＵＣＣＨリソース集合個数が一つ以上であると、少なくとも一つのＰＵＣＣＨリソース集合は２ビット以下のＵＣＩ送信用として設定される。従って、ＡＮ  ＰＵＣＣＨリソースがＡＲＩにより指示され、ＡＮ  ＰＵＣＣＨリソースに対するＰＵＣＣＨリソース集合個数が２個以上であると、端末は３ビット以上のＵＣＩ送信用であるＰＵＣＣＨフォーマット２／３／４によりＵＣＩを送信することができる。この場合、端末はＡＮと複数のＳＲとの間で多重化を行うとき、複数のＳＲ  ＰＵＣＣＨリソースに関するＳＲ情報をマルチビットＳＲ情報をＡＮペイロードに追加した後、全体ＵＣＩペイロードサイズにより選択されたＰＵＣＣＨリソース集合内でＡＲＩにより指示されたＰＵＣＣＨフォーマット２／３／４のうちの一つにより多重化されたＡＮ／ＳＲを送信することができる。
【０３７９】
しかし、ＡＮ  ＰＵＣＣＨリソースがＡＲＩにより指示されても、ＡＮ  ＰＵＣＣＨリソースに対するＰＵＣＣＨリソース集合個数が１個であると、端末はＰＵＣＣＨフォーマット２／３／４リソースを使用できない。従って、多重化されたＡＮ／ＳＲをＰＵＣＣＨフォーマット０／１リソースを介して送信する方法が考えられる。例えば、端末はＡＮと複数のＳＲの間の多重化を行うとき、ＡＮ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１であると、ＰＵＣＣＨフォーマット０に従うＳＲ  ＰＵＣＣＨリソースに対するＳＲ送信を省略し、ＰＵＣＣＨフォーマット１に従うＳＲ  ＰＵＣＣＨリソースのうち、ｐｏｓｉｔｉｖｅ  ＳＲでありかつ優先順位が最も高いＳＲに対応するＳＲ  ＰＵＣＣＨリソースによりＡＮを送信する（但し、全部ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮ  ＰＵＣＣＨ送信）。又はＡＮ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０であると、ＡＮ  ＰＵＣＣＨリソースに対して最大２個のＣＳオフセットを適用して２個のＳＲ  ＰＵＣＣＨ（グループ）に関するＳＲ情報を表現することができる。即ち、ｐｏｓｉｔｉｖｅ  ＳＲであるＳＲ  ＰＵＣＣＨを少なくとも一つ以上含みながら、優先順位が最も高いＳＲ  ＰＵＣＣＨ（グループ）に対応するＣＳオフセットをＡＮ  ＰＵＣＣＨフォーマット０に適用することができる。
【０３８０】
一方、ＳＰＳ（Ｓｅｍｉ−Ｓｔａｔｉｃ  ｓｃｈｅｄｕｌｉｎｇ）ＰＤＳＣＨ送信に対応するＡＮ  ＰＵＣＣＨリソースはＡＲＩにより指示されず、上位層（例えば、ＲＲＣ）信号により準静的に設定される。従って、ＳＰＳ  ＰＤＳＣＨ送信に対応するＡＮ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが重畳する場合、端末はＡＮと複数のＳＲの間の多重化を行うとき、ＰＵＣＣＨフォーマット２／３／４リソースを使用することができない。従って、多重化されたＡＮ／ＳＲをＰＵＣＣＨフォーマット０／１リソースを介して送信する方法を考えることができる。たとえば、端末がＡＮと複数のＳＲの間の多重化を行うとき、ＡＮ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１であると、ＰＵＣＣＨフォーマット０に従うＳＲ  ＰＵＣＣＨリソースに対するＳＲ送信を省略し、ＰＵＣＣＨフォーマット１を従うＳＲ  ＰＵＣＣＨリソースのうち、ｐｏｓｉｔｉｖｅ  ＳＲでありかつ優先順位が最も高いＳＲに対応するＳＲ  ＰＵＣＣＨリソースによりＡＮを送信する（但し、全部ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮ  ＰＵＣＣＨ送信）。又はＡＮ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０であると、ＡＮ  ＰＵＣＣＨリソースに対して最大２個までＣＳオフセットを適用して２個のＳＲ  ＰＵＣＣＨ（グループ）に関するＳＲ情報を表現することができる。即ち、ｐｏｓｉｔｉｖｅ  ＳＲであるＳＲ  ＰＵＣＣＨを少なくとも一つ以上含みながら優先順位が最も高いＳＲ  ＰＵＣＣＨ（グループ）に対応するＣＳオフセットをＡＮ  ＰＵＣＣＨフォーマット０に適用することができる。しかし、ＡＮ  ＰＵＣＣＨリソースに対するＰＵＣＣＨリソース集合個数が２個以上である場合は、ＡＲＩは指示されないが、端末はＡＮ  ＰＵＣＣＨリソースを決定するために特定のＡＲＩ値（例えば、ＡＲＩ＝０）を仮定することができる。その後、端末は（１）複数のＳＲ  ＰＵＣＣＨリソースに関するＳＲ情報をマルチビットＳＲ情報で表現してＡＮペイロードに追加した後、（２）多重化された全体ＵＣＩペイロードサイズにより選択されたＰＵＣＣＨリソース集合内でＡＲＩ＝０に対応するＰＵＣＣＨフォーマット２／３／４リソースのうちの一つを用いて多重化されたＡＮ／ＳＲを送信することができる。
【０３８１】
［提案方法＃１Ｈ］の“多重化されたＵＣＩ（例えば、ＡＮ／ＳＲ）をＰＵＣＣＨフォーマット０／１のうちの１つで送信”する動作について、端末がＡＮとＳＲを以下のように多重化する動作を考えることができる。但し、ＰＦ０／１／２／３／４はＰＵＣＣＨフォーマット０／１／２／３／４を意味する。
【０３８２】
（１）Ｃａｓｅ  ＃１：（単一の）ＡＮと（単一の）ＳＲの間のＵＣＩ多重化
【０３８３】
Ａ．ＡＮ  ＰＦ０である場合
【０３８４】
ｉ．ＳＲ  ＰＦ０である場合：Ｐｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信。
【０３８５】
ｉｉ．ＳＲ  ＰＦ１である場合
【０３８６】
−Ｏｐｔ．１：Ｐｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信。
【０３８７】
−Ｏｐｔ．２：Ｐｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＳＲ  ＰＦ１リソースを介して送信。ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信。
【０３８８】
Ｂ．ＡＮ  ＰＦ１である場合
【０３８９】
ｉ．ＳＲ  ＰＦ０である場合：ＡＮをＡＮ  ＰＦ１リソースを介して送信（ＳＲ  ｄｒｏｐ）
【０３９０】
ｉｉ．ＳＲ  ＰＦ１である場合：Ｐｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＳＲ  ＰＦ１リソースを介して送信。ｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ１リソースを介して送信。
【０３９１】
（２）Ｃａｓｅ  ＃２：（単一の）ＡＮと（マルチプル）ＳＲ（ｗ／単一のＰＵＣＣＨフォーマット）の間のＵＣＩ多重化
【０３９２】
Ａ．ＡＮ  ＰＦ０である場合
【０３９３】
ｉ．（マルチプル）ＳＲ  ＰＦ０である場合
【０３９４】
−（特定のＳＲ  ＰＵＣＣＨグループ内の）少なくとも一つのＳＲ  ＰＵＣＣＨに対するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースに（特定のＳＲ  ＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信
【０３９５】
−この場合、全Ｋ個のＳＲ  ＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲ  ＰＵＣＣＨグループにグルーピングした後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングすることができる。特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちのいずれか１つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作
【０３９６】
−全てのＳＲ  ＰＵＣＣＨに対するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０３９７】
ｉｉ．（マルチプル）ＳＲ  ＰＦ１である場合
【０３９８】
−Ｏｐｔ．１：（特定のＳＲ  ＰＵＣＣＨグループ内の）少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースに（特定のＳＲ  ＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信。この場合、全Ｋ個のＳＲ  ＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲ  ＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングする。特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０３９９】
−Ｏｐｔ．２：少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＳＲ  ＰＵＣＣＨのうちの（最優先順位の）ＳＲ  ＰＵＣＣＨに対応するＳＲ  ＰＦ１リソースを介して送信。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０４００】
Ｂ．ＡＮ  ＰＦ１である場合
【０４０１】
ｉ．（マルチプル）ＳＲ  ＰＦ０である場合：ＡＮをＡＮ  ＰＦ１リソースを介して送信（ＳＲ  ｄｒｏｐ）
【０４０２】
ｉｉ．（マルチプル）ＳＲ  ＰＦ１である場合：少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＳＲ  ＰＵＣＣＨのうちの（最優先順位の）ＳＲ  ＰＵＣＣＨに対応するＳＲ  ＰＦ１リソースを介して送信。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ１リソースを介して送信
【０４０３】
（３）Ｃａｓｅ  ＃３：（単一の）ＡＮと（マルチプル）ＳＲ（ｗ／互いに異なるＰＵＣＣＨフォーマット）の間のＵＣＩ多重化
【０４０４】
Ａ．ＡＮ  ＰＦ０である場合
【０４０５】
ｉ．（マルチプル）ＳＲ  ＰＦ０＋（マルチプル）  ＳＲ  Ｆ１である場合
【０４０６】
−Ｏｐｔ．１：少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであり、ＳＲ  ＰＵＣＣＨのうち、（最優先順位の）ＳＲ  ＰＵＣＣＨがＰＦ０である場合、ＡＮをＡＮ  ＰＦ０リソースにＣＳオフセットを適用したリソースを介して送信。この場合、全体或いはＰＦ０に設定されたＫ個のＳＲ  ＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲ  ＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個ＣＳオフセットに対応／マッピングする。この場合、特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。もしＰＦ０に設定されたＳＲ  ＰＵＣＣＨ数ＫがＬと同一であるか、又はＬより小さい場合には、別のグループ化無しに該当Ｋ個のＳＲ  ＰＵＣＣＨを各々互いに異なるＫ個のＣＳオフセットに対応／マッピングする。この場合、Ｐｏｓｉｔｉｖｅ  ＳＲ  ＰＵＣＣＨに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであり、ＳＲ  ＰＵＣＣＨのうち、（最優先順位の）ＳＲ  ＰＵＣＣＨがＰＦ１である場合、ＡＮを（該当）ＳＲ  ＰＦ１リソースを介して送信。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０４０７】
−Ｏｐｔ．２：（特定のＳＲ  ＰＵＣＣＨグループ内の）少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースに（特定のＳＲ  ＰＵＣＣＨグループに対応する）ＣＳオフセットを適用したリソースを介して送信。この場合、全Ｋ個のＳＲ  ＰＵＣＣＨをＬ個（例えば、Ｌ＝２、Ｋ＞Ｌ）のＳＲ  ＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個のＣＳオフセットに対応／マッピングする。この場合、特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＣＳオフセットを適用したリソースによりＡＮを送信するように動作。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０４０８】
−Ｏｐｔ．３：（特定のＳＲ  ＰＵＣＣＨグループ内の）少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮを（上記特定のＳＲ  ＰＵＣＣＨグループに対応する）特定のＳＲ  ＰＦ１リソースを介して送信。この場合、全Ｋ個のＳＲ  ＰＵＣＣＨをＬ個（例えば、Ｌ＝ｔｈｅ  ｎｕｍｂｅｒ  ｏｆ  ＳＲｓ  ｃｏｎｆｉｇｕｒｅｄ  ｗｉｔｈ  Ｆ１、Ｋ＞Ｌ）ＳＲ  ＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個のＳＲ  Ｆ１リソースに対応／マッピングする。この場合、特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＳＲ  Ｆ１リソースによりＡＮを送信するように動作。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ０リソースを介して送信
【０４０９】
Ｂ．ＡＮ  ＰＦ１である場合
【０４１０】
ｉ．（マルチプル）ＳＲ  ＰＦ０＋（マルチプル）ＳＲ  Ｆ１である場合
【０４１１】
−Ｏｐｔ．１：少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであり、ＳＲ  ＰＵＣＣＨのうち、（最優先順位の）ＳＲ  ＰＵＣＣＨがＰＦ０である場合、ＡＮをＡＮ  ＰＦ１リソースを介して送信（ＳＲ  ｄｒｏｐ）。少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであり、ＳＲ  ＰＵＣＣＨのうち、（最優先順位の）ＳＲ  ＰＵＣＣＨがＰＦ１である場合、ＡＮを（該当）ＳＲ  ＰＦ１リソースを介して送信。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ１リソースを介して送信
【０４１２】
−Ｏｐｔ．２：（特定のＳＲ  ＰＵＣＣＨグループ内の）少なくとも一つのＳＲ  ＰＵＣＣＨに関するＳＲ情報がＰｏｓｉｔｉｖｅ  ＳＲであると、ＡＮを（上記特定のＳＲ  ＰＵＣＣＨグループに対応する）特定のＳＲ  ＰＦ１リソースを介して送信。この場合、全Ｋ個のＳＲ  ＰＵＣＣＨをＬ個の（例えば、Ｌ＝ｔｈｅ  ｎｕｍｂｅｒ  ｏｆ  ＳＲｓ  ｃｏｎｆｉｇｕｒｅｄ  ｗｉｔｈ  Ｆ１、Ｋ＞Ｌ）ＳＲ  ＰＵＣＣＨグループにグループ化した後、該当Ｌ個のＳＲ  ＰＵＣＣＨグループを各々互いに異なるＬ個のＳＲ  Ｆ１リソースに対応／マッピングする。この場合、特定のＳＲ  ＰＵＣＣＨグループに属するＳＲのうちの少なくとも一つがＰｏｓｉｔｉｖｅであると、該当特定のＳＲ  ＰＵＣＣＨグループに対応するＳＲ  Ｆ１リソースによりＡＮを送信するように動作。全てのＳＲ  ＰＵＣＣＨに関するＳＲ情報がｎｅｇａｔｉｖｅ  ＳＲであると、ＡＮをＡＮ  ＰＦ１リソースを介して送信
【０４１３】
ここで、ＳＲＰＵＣＣＨグループは一つ以上のＳＲ  ＰＵＣＣＨで構成され、一つ以上のＳＲ  ＰＵＣＣＨグループが定義される。
【０４１４】
上述した内容を整理すると以下の通りである。
【０４１５】
（１）Ｃａｓｅ  ＃１
【０４１６】
Ａ．ＡＮ  ＰＦ０＋単一のＳＲ  ＰＦ０＝＞ＡＮ＋ＳＲ  ｏｎ  ＡＮ  ＰＦ０（ＣＳオフセットにより）
【０４１７】
Ｂ．ＡＮ  ＰＦ０＋単一のＳＲ  ＰＦ１＝＞ＡＮ＋ＳＲ  ｏｎ  ＡＮ  ＰＦ０（ＣＳオフセットにより）又はＳＲ  ＰＦ１（ＣＨ選択により）
【０４１８】
Ｃ．ＡＮ  ＰＦ１＋単一のＳＲ  ＰＦ０＝＞ＡＮ  ｏｎｌｙ  ｏｎ  ＡＮ  ＰＦ１（ＳＲ省略により）
【０４１９】
Ｄ．ＡＮ  ＰＦ１＋単一のＳＲ  ＰＦ１＝＞ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択により）
【０４２０】
（２）Ｃａｓｅ  ＃２
【０４２１】
Ａ．ＡＮ  ＰＦ０＋マルチプルＳＲ  ＰＦ０＝＞ＡＮ＋ＳＲ  ｏｎ  ＡＮ  ＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）
【０４２２】
Ｂ．ＡＮ  ＰＦ０＋マルチプルＳＲ  ＰＦ１＝＞ＡＮ＋ＳＲ  ｏｎ  ＡＮ  ＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）又はＳＲ  ＰＦ１（ＣＨ選択により）
【０４２３】
Ｃ．ＡＮ  ＰＦ１＋マルチプルＳＲ  ＰＦ０＝＞ＡＮ  ｏｎｌｙ  ｏｎ  ＡＮ  ＰＦ１（ＳＲ省略により）
【０４２４】
Ｄ．ＡＮ  ＰＦ１＋マルチプルＳＲ  ＰＦ１＝＞ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択により）
【０４２５】
（３）Ｃａｓｅ  ＃３
【０４２６】
Ａ．ＡＮ  ＰＦ０＋（マルチプル）ＳＲ  ＰＦ０＋（マルチプル）ＳＲ  ＰＦ１
【０４２７】
ｉ．Ｏｐｔｉｏｎ  １
【０４２８】
１．ＳＲ  ＰＦ０がＰｏｓｉｔｉｖｅ  ＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲ  ｏｎ  ＡＮ  Ｆ０（ＣＳオフセット及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲ  Ｆ０のみに限定
【０４２９】
２．ＳＲ  ＰＦ１がＰｏｓｉｔｉｖｅ  ＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択により）
【０４３０】
ｉｉ．Ｏｐｔｉｏｎ  ２
【０４３１】
１．ＳＲ  ＰＦがＰｏｓｉｔｉｖｅ  ＳＲであるか否かに関係なく、ＡＮ＋ＳＲ  ｏｎ  ＡＮ  ＰＦ０（ＣＳオフセット及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲ  ＰＦ０とＳＲ  ＰＦ１を全て含む
【０４３２】
ｉｉｉ．Ｏｐｔｉｏｎ  ３
【０４３３】
１．ＳＲ  ＰＦがＰｏｓｉｔｉｖｅ  ＳＲであるか否かに関係なく、ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲ  ＰＦ０とＳＲ  ＰＦ１を全て含む
【０４３４】
Ｂ．ＡＮ  ＰＦ１＋（マルチプル）ＳＲ  ＰＦ０＋（マルチプル）ＳＲ  ＰＦ１
【０４３５】
ｉ．Ｏｐｔｉｏｎ  １
【０４３６】
１．ＳＲ  ＰＦ０がＰｏｓｉｔｉｖｅ  ＳＲであり、優先順位が最も高い場合、ＡＮ  ｏｎｌｙ  ｏｎ  ＡＮ  ＰＦ１（ＳＲ省略により）
【０４３７】
２．ＳＲ  ＰＦ１がＰｏｓｉｔｉｖｅ  ＳＲであり、優先順位が最も高い場合、ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択により）
【０４３８】
ｉｉ．Ｏｐｔｉｏｎ  ２
【０４３９】
１．ＡＮ＋ＳＲ  ｏｎ  ＳＲ  ＰＦ１（ＣＨ選択及びＳＲバンドリングにより）。この場合、ＳＲバンドリング対象はＳＲ  ＰＦ０とＳＲ  ＰＦ１を全て含む
【０４４０】
［提案方法＃２］スロット内において、Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ）の送信開始時点とＳＲ  ＰＵＣＣＨの送信開始時点の相対的な関係によってＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無を決定することができる。
【０４４１】
但し、端末がＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を行わない場合、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの１つの送信が省略される。
【０４４２】
一例として、端末はＳＲ  ＰＵＣＣＨの送信開始時点がＭＵＸ  ＰＵＣＣＨの送信開始時点よりＴ0ほど先立つか又は遅れるかによって、以下のようにＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化の有無が決定される。
【０４４３】
（１）ＳＲ  ＰＵＣＣＨの送信開始時点がＭＵＸ  ＰＵＣＣＨの送信開始時点を基準としてＴ0以前の時点より先立つ場合
【０４４４】
Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲのうちの一つを選択して送信
【０４４５】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合、ＳＲをＳＲ  ＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０４４６】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０４４７】
（２）ＳＲ  ＰＵＣＣＨの送信開始時点がＭＵＸ  ＰＵＣＣＨの送信開始時点を基準としてＴ0以前の時点より遅れる（又は同一である）場合
【０４４８】
Ａ．Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信（又はＡ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨが時間軸でＰＵＣＣＨ内の全てのＯＦＤＭシンボルに対して完全に重畳する場合と同一のＵＣＩ多重化規則に従う）
【０４４９】
ｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【０４５０】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合、Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信
【０４５１】
２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０４５２】
ｉｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【０４５３】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合、Ａ／ＮをＳＲ  ＰＵＣＣＨリソースを介して送信。但し、ＳＲ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。
【０４５４】
２．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０４５５】
ｉｉｉ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合
【０４５６】
１．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲ又はｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ．ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０４５７】
Ｔ0は以下のうちの一つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０４５８】
（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０４５９】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０４６０】
（３）端末能力による復調に必要な端末処理時間又はそれに対応する値
【０４６１】
（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０４６２】
（５）基地局と端末の間で予め約束した値（例えば、固定値）
【０４６３】
［提案方法＃２］はＡ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合に適用される。
【０４６４】
ＮＲシステムにおいて、Ａ／Ｎ  ＰＵＣＣＨとＳＲ  ＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボルが異なる場合、Ａ／Ｎ  ｏｎｌｙの送信を仮定したＡ／Ｎ  ＰＵＣＣＨ（以下、Ａ／Ｎ  ＰＵＣＣＨ１）とＳＲ  ＰＵＣＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）を比較して、Ａ／ＮとＳＲの間のＵＣＩ多重化の有無を決定する方法が論議されている。例えば、ＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより先立つ場合、端末はＳＲ  ＰＵＣＣＨを送信し、Ａ／Ｎ送信を省略する。逆に、ＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより遅れた（或いは同一である）場合には、端末はＳＲとＡ／ＮをＵＣＩ多重化して単一のＰＵＣＣＨで送信することができる。上述した動作は、端末が開始（ＯＦＤＭ）シンボルが先立つＰＵＣＣＨを先に処理することが期待されるためである。しかし、ＮＲシステムにおいて、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信するとき、Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０／２／３／４である場合は、単一のＰＵＣＣＨリソースはＡ／ＮとＳＲに対する全体ＵＣＩペイロードサイズを算定して新しく選択されたＡ／Ｎ  ＰＵＣＣＨリソース（以下、Ａ／Ｎ  ＰＵＣＣＨ２）であり、Ａ／Ｎ  ＰＵＣＣＨ１とは異なることができる。従って、端末がＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルがＡ／Ｎ  ＰＵＣＣＨ１の開始（ＯＦＤＭ）シンボルより遅れた（或いは同一である）場合であると判断した後、Ａ／Ｎ  ＰＵＣＣＨ２でＡ／ＮとＳＲを送信するとき、ＳＲ  ＰＵＣＣＨよりＡ／Ｎ  ＰＵＣＣＨ２の開始（ＯＦＤＭ）シンボルが先立つ場合があり得る。従って、より一貫した端末の動作のために、Ａ／Ｎ  ＰＵＣＣＨ１ではなく、Ａ／Ｎ  ＰＵＣＣＨ２の開始（ＯＦＤＭ）シンボルとＳＲ  ＰＵＣＣＨの開始（ＯＦＤＭ）シンボルの間の先後関係を比較することが好ましい。
【０４６５】
［提案方法＃３］スロット内において、Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、Ａ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ）の送信開始時点がＳＲ  ＰＵＣＣＨの送信開始時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ−ｇｏｉｎｇ  ＳＲ  ＰＵＣＣＨ送信があれば、該当ＳＲ  ＰＵＣＣＨの送信を中断して、ＭＵＸ  ＰＵＣＣＨでＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信することができる。
【０４６６】
さらに、Ａ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳した場合は、端末はＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲの間の多重化を仮定する時に使用されるＰＵＣＣＨ（以下、ＭＵＸ  ＰＵＣＣＨ）の送信開始時点がＡ／Ｎ  ＰＵＣＣＨの送信開始時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ−ｇｏｉｎｇ  Ａ／Ｎ  ＰＵＣＣＨ送信があれば、該当Ａ／Ｎ  ＰＵＣＣＨの送信を中断して、ＭＵＸ  ＰＵＣＣＨでＡ／Ｎと（ｐｏｓｉｔｉｖｅ）ＳＲを多重化して送信する方法
【０４６７】
但し、上記動作は特定の端末能力を有する端末に限定して適用される。
【０４６８】
端末がＳＲ送信を行った後にＳＲ  ＰＵＣＣＨと時間軸で一部重畳するＡ／Ｎ  ＰＵＣＣＨリソースの存在を把握した場合、簡単な方法で端末は該当Ａ／Ｎ送信を省略することができる。しかし、端末に十分な能力があれば、できる限り（即ち、ベストエフォート方式により）現在進行中のＳＲ送信を中断し、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信することができる。逆に、端末がＡ／Ｎ送信を行った後にＡ／Ｎ  ＰＵＣＣＨと時間軸で一部重畳するＳＲ  ＰＵＣＣＨリソースに対するＰｏｓｉｔｉｖｅ  ＳＲが発生することができる。この場合にも、端末は（即ち、ベストエフォート方式により）現在進行中のＡ／Ｎ送信を中断し、Ａ／ＮとＳＲを多重化して単一のＰＵＣＣＨリソースを介して送信することができる。［提案方法＃３］により、端末はＳＲとＡ／Ｎが衝突する場合にもＡ／ＮとＳＲの多重化された送信を最大に支援することができる。
【０４６９】
［提案方法＃４］Ａ／Ｎ  ＰＵＣＣＨがＰＦ０又はＰＦ１であり、スロット内でＡ／Ｎ  ＰＵＣＣＨリソースとＳＲ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末はＡ／Ｎ  ＰＵＣＣＨリソースと重畳したＳＲ  ＰＵＣＣＨリソースに対応するＳＲプロセス数によって、Ａ／ＮとＳＲに対するＵＣＩ多重化規則を異なるように適用することができる。
【０４７０】
一例として、Ａ／Ｎ  ＰＵＣＣＨリソースと重畳したＳＲ  ＰＵＣＣＨリソースに対応するＳＲプロセスが一つであるか、或いは複数であるかによって、端末は以下のようにＡ／ＮとＳＲに対してＵＣＩ多重化規則を適用することができる。
【０４７１】
（１）（Ａ／Ｎと重畳する）ＳＲプロセスが一つである場合
【０４７２】
Ａ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【０４７３】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合、Ａ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースによりＡ／Ｎを送信
【０４７４】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ／Ｎ  ＰＵＣＣＨリソースによりＡ／Ｎを送信
【０４７５】
Ｂ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【０４７６】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合、ＳＲ  ＰＵＣＣＨリソースによりＡ／Ｎを送信
【０４７７】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合、Ａ／Ｎ  ＰＵＣＣＨリソースによりＡ／Ｎを送信
【０４７８】
（２）（Ａ／Ｎと重畳する）ＳＲプロセスが複数である場合
【０４７９】
Ａ．Ａ／Ｎ  ＰＵＣＣＨがＰＦ０又はＰＦ１である場合
【０４８０】
ｉ．Ａ／Ｎに（複数のＳＲプロセスに対する）ＳＲを表現するマルチビットを付け加えた後、Ａ／Ｎ  ＰＵＣＣＨリソースにより全体ＵＣＩを送信。ここで、Ａ／Ｎ  ＰＵＣＣＨリソースはＡ／ＮとマルチビットＳＲを含むＵＣＩペイロードサイズを基準として選択されたリソースであり、ＰＦ２／３／４のうちの一つである。
【０４８１】
ここで、複数のＳＲプロセスに対応するＳＲ  ＰＵＣＣＨリソースの設定は特定のＩＤにより区分され、各々独立している。
【０４８２】
ＮＲシステムでは、Ａ／Ｎ  ＰＵＣＣＨがＰＦ０又はＰＦ１である場合、支援されるＡ／Ｎペイロードサイズは２ビット以下である。この時、一つのＳＲプロセスに関する情報が追加される場合、端末は多重化容量が落ちるラージＵＣＩペイロードサイズ用のＰＵＣＣＨフォーマット（例えば、ＰＦ２／３／４）を使用するよりは、リソース選択方式を用いて該当ＳＲプロセスに対するｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅ  ＳＲを表現することができる。しかし、Ａ／Ｎ  ＰＵＣＣＨリソースと複数のＳＲプロセスに対応するＳＲ  ＰＵＣＣＨリソースが重畳した場合は、端末はｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅ  ＳＲ以外に、どのＳＲプロセスがｐｏｓｉｔｉｖｅ／ｎｅｇａｔｉｖｅ  ＳＲであるかに関する情報も基地局に伝達する必要がある。この場合、ＳＲ情報を表現するために必要なビット数が多いので、ＳＲプロセスが１個である場合のように、リソース選択方式を活用するよりは、３ビット以上のラージＵＣＩペイロードサイズ用のＰＵＣＣＨフォーマット（例えば、ＰＦ２／３／４）を使用した方がより効率的である。
【０４８３】
［提案方法＃５］スロット内のＡ／Ｎ  ＰＵＣＣＨリソースとＣＳＩ  ＰＵＣＣＨリソースが時間軸で（ＰＵＣＣＨ内の全体或いは一部ＯＦＤＭシンボルが）重畳する場合、以下のようにＡ／ＮとＣＳＩの間の多重化を支援する方法
【０４８４】
（１）Ａ／Ｎ  ＰＵＣＣＨリソースがＤＬ割り当てベースではない場合
【０４８５】
Ａ．ＣＳＩ  ＰＵＣＣＨの送信開始時点を基準としてＴ0以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＣＳＩ  ＰＵＣＣＨリソースと時間軸で重畳する場合
【０４８６】
ｉ．Ａ／ＮとＣＳＩを多重化してＣＳＩ  ＰＵＣＣＨで送信
【０４８７】
Ｂ．その他の場合
【０４８８】
ｉ．Ｏｐｔ．１：ＣＳＩをＣＳＩ  ＰＵＣＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０４８９】
ｉｉ．Ｏｐｔ．２：Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（ＣＳＩ送信を省略）
【０４９０】
（２）Ａ／Ｎ  ＰＵＣＣＨリソースがＤＬ割り当てベースである場合
【０４９１】
Ａ．Ａ／ＮとＣＳＩを多重化して（全体ＵＣＩ基準として再選択された）Ａ／Ｎ  ＰＵＣＣＨリソースを介して送信。但し、ＣＳＩを更新する時間が足りない場合は（例えば、ＣＳＩ参照リソースがＡ／Ｎ  ＰＵＣＣＨリソースの送信開始時点を基準としてＴ1以前の時点である場合は）、端末はＣＳＩを更新しないことができる。
【０４９２】
ＣＳＩ参照リソースはＣＳＩ計算の参照となる時間リソースを意味する。（有効な）ＤＬスロットは（端末に）ＤＬスロットとして設定されたスロット及び／又は測定ギャップ（例えば、ｍｅａｓｕｒｅｍｅｎｔ  ｇａｐ）に含まれないスロット及び／又はＣＳＩ報告が行われるＤＬ  ＢＷＰと同一のＤＬ  ＢＷＰに含まれるスロットを意味する。
【０４９３】
Ｔ0は以下のうちの一つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０４９４】
（１）端末能力によるＰＤＳＣＨの終了後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０４９５】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０４９６】
（３）端末能力による復調に必要な端末処理時間又はそれに対応する値
【０４９７】
（４）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０４９８】
（５）基地局と端末の間に予め約束した値（例えば、固定値）
【０４９９】
Ｔ1は以下のうちの一つである。Ｔ1は（ＯＦＤＭ）シンボル単位で示すことができる。
【０５００】
（１）端末能力によるＣＳＩ計算及び報告のために必要な端末の処理時間又はそれに対応する値
【０５０１】
（２）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０５０２】
（３）基地局と端末の間に予め約束した値（例えば、固定値）
【０５０３】
ＮＲシステムでは、ＤＬ割り当て（＝ＤＬ  ｓｃｈｅｄｕｌｉｎｇ  ＤＣＩ）に基づくＰＤＳＣＨに対するＡ／ＮとＣＳＩが多重化される場合、Ａ／ＮとＣＳＩに対する全体ＵＣＩペイロードサイズを基準として再選択されたＡ／Ｎ  ＰＵＣＣＨリソースにより多重化されたＡ／ＮとＣＳＩを送信することができる。多重化動作はＡ／Ｎ  ＰＵＣＣＨとＣＳＩ  ＰＵＣＣＨが時間軸で一部重畳する場合にも適用できる。但し、ＣＳＩ参照リソースがＡ／Ｎ  ＰＵＣＣＨの送信開始地点を基準として、端末処理時間であるＴ0以前に存在する場合には、端末がＣＳＩを新しく更新することが難しい。従って、ＣＳＩを新しく更新することが難しい場合には、ＣＳＩを更新せず（但し、更新されないＣＳＩは相変わらずＡ／Ｎと多重化して報告）、その他の場合にはＣＳＩを更新してＡ／Ｎと多重化して報告する方法を提案する。
【０５０４】
反面、Ａ／ＮがＤＬ割り当てに基づくＰＤＳＣＨに対応しない場合は、端末はＡ／ＮとＣＳＩをＣＳＩ  ＰＵＣＣＨに多重化して送信することができる。ＣＳＩ  ＰＵＣＣＨによりＡ／Ｎを送信する場合、Ａ／Ｎ送信のための最小のＵＬタイミングが保証される場合にのみＡ／ＮとＣＳＩの間の多重化を許容する。即ち、端末はＣＳＩ  ＰＵＣＣＨ送信開始時点を基準として、Ｔ1以前の時点まで受信した（或いは送信を開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨがＣＳＩ  ＰＵＣＣＨと重畳する場合にのみＡ／ＮとＣＳＩの間の多重化を行い、そうではない場合にはＡ／Ｎ送信を省略して、ＣＳＩ  ＰＵＣＣＨのみを送信することができる。
【０５０５】
［提案方法＃６］端末が特定のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（以下、ＵＬ−ＣＨ１）内の一部の（ＯＦＤＭ）シンボルをパンクチャリングし、（ＯＦＤＭ）シンボルにおいて他のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（以下、ＵＬ−ＣＨ２）を送信することができる。この場合、ＵＬ−ＣＨ２に対する送信電力は以下のように適用できる。
【０５０６】
（１）Ｏｐｔ．１
【０５０７】
Ａ．ＵＬ−ＣＨ２に対して（ＵＬ−ＣＨ１と）独立して設定された送信電力を適用
【０５０８】
ｉ．ＵＬ−ＣＨ２の送信電力がＵＬ−ＣＨ１の送信電力を基準として一定の範囲内の値を有する場合、端末はＵＬ−ＣＨ１のパンクチャリング後のリソースを（不連続に）全部送信する。
【０５０９】
ｉｉ．ＵＬ−ＣＨ２の送信電力がＵＬ−ＣＨ１の送信電力を基準として一定範囲外の値を有する場合、
【０５１０】
１．ＵＬ−ＣＨ１のパンクチャリング後のリソース内にＤＭ−ＲＳが存在すると、ＵＬ−ＣＨ１の残りのリソースに対する送信を全部行う。ここで、ＤＭ−ＲＳはデータ復調用の参照信号を意味する。
【０５１１】
２．ＵＬ−ＣＨ１のパンクチャリング後のリソース内にＤＭ−ＲＳが存在すると、ＵＬ−ＣＨ１の残りのリソースに対する送信を省略
【０５１２】
（２）Ｏｐｔ．２
【０５１３】
Ａ．ＵＬ−ＣＨ２に対してＵＬ−ＣＨ１と同じ送信電力を適用
【０５１４】
（３）Ｏｐｔ．３
【０５１５】
Ａ．ＵＬ−ＣＨ２に対して（ＵＬ−ＣＨ１と）独立して設定された送信電力がＴＸＰ１であり、ＵＬ−ＣＨ１に対する位相連続性（Ｐｈａｓｅ  ｃｏｎｔｉｎｕｉｔｙ）を保証する最大の送信電力がＴＸＰ２であるとき、ｍｉｎ（ＴＸＰ１、ＴＸＰ２）をＵＬ−ＣＨ２に対する送信電力として適用。ここで、位相連続性はＵＬ−ＣＨ１に対してパンクチャリング以前のリソースと以後のリソースの間にチャネル変化による位相差を除いた他の位相差がないことを意味する。
【０５１６】
ｉ．ＴＸＰ２は端末が具現化により任意に選択する値である。
【０５１７】
ｉ．ＵＬ−ＣＨ２について設定された既存のＵＬ  ＰＣ（ｐｏｗｅｒ  ｃｏｎｔｒｏｌ）規則を例外にすることができる。
【０５１８】
一例として、端末がＰＵＳＣＨ送信中に緊急サービス（例えば、ＵＲＬＬＣ）に対するＰＵＣＣＨ送信を行わなければならない場合がある。この場合は、端末がＰＵＳＣＨ送信を既に進行中であるので（例えば、Ｏｎ−ｇｏｉｎｇ  ｔｒａｎｓｍｉｓｓｉｏｎ）、端末はＰＵＳＣＨ送信を中止してＰＵＣＣＨを送信しなければならない。この時、ＰＵＳＣＨ送信の観点では、ＰＵＣＣＨが送信されるＯＦＤＭシンボルのみがパンクチャリングされることができる。この場合、パンクチャリング区間内のＰＵＣＣＨ送信電力がＰＵＳＣＨとは異なるので、ＰＡ（ｐｏｗｅｒ  ａｍｐｌｉｆｉｅｒ）設定が初期化されてパンクチャリング区間を基準として前側に送信されたＰＵＳＣＨリソースと後側に送信されたＰＵＳＣＨリソースの間に（送信信号の）位相が変化することができる。この問題は、ＰＵＳＣＨ送信中にＰＵＣＣＨ送信を行いながら端末の送信電力が大きく変更するためである。従って、本発明では、ＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（即ち、ＵＬ−ＣＨ１）内の一部（ＯＦＤＭ）シンボルをパンクチャリングし、（ＯＦＤＭ）シンボル内で他のＰＵＣＣＨ（又はＰＵＳＣＨ）リソース（即ち、ＵＬ−ＣＨ２）を送信するとき、端末は位相変化を減らすために、以下の動作を行うことができる。
【０５１９】
（１）ＵＬ−ＣＨ２に対する送信電力をＵＬ−ＣＨ１と同値に設定するか、又は
【０５２０】
（２）ＵＬ−ＣＨ２に対して独立したＵＬ電力制御を行い、ＵＬ−ＣＨ１の送信電力と比較して位相差を誘発する電力差が発生する場合には、ＵＬ−ＣＨ２の送信以後の残りのＵＬ−ＣＨ１のリソースはＤＭ−ＲＳが存在する場合にのみ送信する動作を考えることができる。
【０５２１】
ＰＵＣＣＨ／ＰＵＳＣＨ多重化
【０５２２】
［提案方法＃６．１］スロット内において、Ａ／Ｎ  ＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この場合、端末は（基準時点から）特定時点の前まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか否かによって、Ａ／ＮとＵＬデータの間の多重化の有無（或いはＡ／ＮをＰＵＳＣＨにＵＣＩピギーバックするか否か）を決定する方法
【０５２３】
但し、端末がＡ／ＮとＵＬデータの間の多重化を行わない場合には、Ａ／ＮとＵＬデータのうちの一つの送信を省略できる。
【０５２４】
一例として、端末はＰＵＳＣＨの送信開始時点（例えば、開始シンボル）を基準として、Ｔ0以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨと重畳するか否かによって、ＰＵＳＣＨへのＡ／Ｎピギーバックの有無を決定することができる。
【０５２５】
（１）ＰＵＳＣＨの送信開始時点を基準として、Ｔ0以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳する場合
【０５２６】
−Ａ／ＮとＵＬデータを多重化して送信（即ち、Ａ／ＮをＰＵＳＣＨにＵＣＩピギーバックして送信）（又はＡ／Ｎ  ＰＵＣＣＨとＰＵＳＣＨが時間軸でＰＵＣＣＨ或いはＰＵＳＣＨ内の全てのＯＦＤＭシンボルと完全に重畳する場合と同じＵＣＩ多重化規則に従う）
【０５２７】
（２）（１）に該当しない場合（例えば、ＰＵＳＣＨの送信開始時点を基準として、Ｔ0以前の時点後に受信された（又は送信開始／終了された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか、又はＰＵＳＣＨの送信開始時点を基準として、Ｔ0以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳しないか、又はＰＵＳＣＨの送信開始時点を基準として、Ｔ0以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが存在しない場合）
【０５２８】
−Ｏｐｔ．１：ＵＬデータをＰＵＳＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０５２９】
−Ｏｐｔ．２：Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（ＰＵＳＣＨ送信を省略）
【０５３０】
但し、特定のバージョンの端末である場合、ＰＵＳＣＨに対するＵＬグラントの受信後に受信された、ＤＬ割り当てによりスケジュールされたＰＤＳＣＨに対するＡ／ＮはＰＵＳＣＨへのＵＣＩピギーバック対象ではない。
【０５３１】
Ｔ0は以下のうちの一つである。Ｔ0は（ＯＦＤＭ）シンボル単位で示すことができる。
【０５３２】
（１）端末能力によるＰＤＳＣＨの終了後、Ａ／Ｎ送信まで必要な端末処理時間又はそれに対応する値。端末能力によるＵＣＩ（ＰＵＣＣＨ）送信のために必要な端末処理時間又はそれに対応する値
【０５３３】
（２）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値。又は、端末能力によるＵＣＩ（ＰＵＣＣＨ）送信のために必要な端末処理時間又はそれに対応する値
【０５３４】
（３）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０５３５】
（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値
【０５３６】
（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値
【０５３７】
（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０５３８】
（６）基地局と端末の間に予め約束した値（例えば、固定値）
【０５３９】
［提案方法＃６．１］はＡ／Ｎ  ＰＵＣＣＨ以外のＰＵＣＣＨにも拡張して適用することができる。
【０５４０】
ＮＲシステムではＰＵＣＣＨとＰＵＳＣＨの間の開始（ＯＦＤＭ）シンボル（或いは開始時間）が一致する場合、ＰＵＣＣＨとＰＵＳＣＨが時間軸で完全に重畳する場合と同一のＵＣＩ多重化規則を適用する端末動作が合議されている。この時、ＰＵＣＣＨとＰＵＳＣＨが多重化して送信されるリソースがＰＵＳＣＨリソースであるので、ＰＵＳＣＨリソースの送信開始前までＰＵＣＣＨ内の特定のＵＣＩ送信に必要な処理時間が満たさない場合には、該当ＰＵＣＣＨをＰＵＳＣＨに多重化することができない。たとえ、ＰＵＣＣＨがＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨ（以下、Ａ／Ｎ  ＰＵＣＣＨ）である場合、端末はＰＵＳＣＨの送信開始時点を基準として（端末能力によるＰＤＳＣＨの受信後、Ａ／Ｎ送信まで必要な時間である）Ｔ0時間以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／ＮのみをＰＵＳＣＨで送信することができる。従って、本発明はＳＲ  ＰＵＣＣＨとＡ／Ｎ  ＰＵＣＣＨの間のＵＣＩ多重化規則（［提案方法＃１］）のように、端末がＰＵＳＣＨ送信開始時点を基準として、Ｔ0以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳するか否かによりＡ／Ｎに対するＵＣＩピギーバックの有無を決定することができる。即ち、端末はＰＵＳＣＨ送信開始時点を基準として、Ｔ0以前の時点まで受信されたＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対するＡ／Ｎ  ＰＵＣＣＨリソースが時間軸でＰＵＳＣＨリソースと重畳すると、Ａ／ＮをＰＵＳＣＨにＵＣＩピギーバックして送信し、そうではない場合には、Ａ／Ｎに対する送信無しにＰＵＳＣＨのみを送信することができる。図１２は［提案方法＃６．１］の動作を例示する。
【０５４１】
［提案方法＃６．１］の変形として、ＣＳＩ  ＰＵＣＣＨとＰＵＳＣＨが時間軸で重畳した場合は、端末はＣＳＩ  ＰＵＣＣＨを送信せず、ＰＵＳＣＨでＣＳＩをＵＣＩピギーバックすることができる。この時、ＣＳＩ計算のための処理時間がＰＵＳＣＨ送信準備まで十分ではない場合は、端末はＣＳＩを更新しないことができる。
【０５４２】
Ａ／Ｎ  ＰＵＣＣＨリソースと他のＵＬチャネルが時間軸で（一部或いは全体）重畳するとき、［提案方法＃１］と［提案方法＃６．１］を統合すると、端末が以下のように動作する。
【０５４３】
（１）Ａ／Ｎ  ＰＵＣＣＨの送信開始時点（又はスロット）を基準として、Ｔ0以前の時点までＡ／Ｎ  ＰＵＣＣＨと時間軸で重畳するＵＬチャネルが設定／指示されない場合（例えば、ＵＬチャネルはＳＲを送信するＰＵＣＣＨ又はＵＬ−ＳＣＨ  ＴＢを運ぶＰＵＳＣＨである）
【０５４４】
Ａ．端末はＡ／ＮのみをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（上記時点以後、Ａ／Ｎ  ＰＵＣＣＨと重畳するＵＬチャネルが発生しても無視するか又は該当ＵＬチャネル送信を省略／放棄）
【０５４５】
（２）Ａ／Ｎ  ＰＵＣＣＨの送信開始時点（又はスロット）を基準として、Ｔ0以前の時点までＡ／Ｎ  ＰＵＣＣＨと時間軸で重畳するＵＬチャネルが設定／指示された場合（例えば、該当ＵＬチャネルはＳＲを送信するＰＵＣＣＨ又はＵＬ−ＳＣＨ  ＴＢを運ぶＰＵＳＣＨである）
【０５４６】
Ａ．ＵＬチャネルが（特定の）ＵＣＩ（以下、ＵＣＩ−Ａ）を送信するＰＵＣＣＨ（以下、ＰＵＣＣＨ−Ａ）である場合
【０５４７】
ｉ．ＰＵＣＣＨ−Ａリソースの送信開始時点を基準として、Ｔ1以前の時点まで受信された（又は送信が開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＰＵＣＣＨ−Ａリソースと時間軸で重畳する場合、Ａ／ＮとＵＣＩ−Ａを多重化して単一のＰＵＣＣＨリソースを介して送信
【０５４８】
ｉｉ．その他の場合（例えば、ＰＵＣＣＨ−Ａリソースの送信開始時点を基準として、Ｔ1以前の時点まで受信された（又は送信が開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＰＵＣＣＨ−Ａリソースと時間軸で重畳しないか、又はＰＵＣＣＨ−Ａリソースの送信開始時点を基準として、Ｔ1以前の時点まで受信された（又は送信が開始した）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが存在しない場合）、Ａ／ＮとＵＣＩ−Ａのうちの一つを選択して送信
【０５４９】
−Ｏｐｔ．１：ＵＣＩ−Ａ（ｏｎｌｙ）をＰＵＣＣＨ−Ａリソースを介して送信（Ａ／Ｎ送信を省略）
【０５５０】
−Ｏｐｔ．２：Ａ／Ｎ（ｏｎｌｙ）をＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（ＵＣＩ−Ａ送信を省略）
【０５５１】
−Ｏｐｔ．３：ＵＣＩ−Ａの状態によってＯｐｔ．１又はＯｐｔ．２を適用
【０５５２】
Ｂ．ＵＬチャネルがＵＬ−ＳＣＨ  ＴＢ（又はＵＬデータ）を送信するＰＵＳＣＨである場合
【０５５３】
ｉ．ＰＵＳＣＨの送信開始時点を基準としてＴ2以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳する場合
【０５５４】
１．Ａ／ＮとＵＬデータを多重化して送信（即ち、Ａ／ＮをＰＵＳＣＨによりＵＣＩピギーバック）（又はＡ／Ｎ  ＰＵＣＣＨとＰＵＳＣＨが時間軸でＰＵＣＣＨ或いはＰＵＳＣＨ内の全てのＯＦＤＭシンボルに対して完全に重畳する場合と同一のＵＣＩ多重化規則に従う）
【０５５５】
ｉｉ．その他の場合（例えば、ＰＵＳＣＨリソースの送信開始時点を基準としてＴ2以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースがＰＵＳＣＨリソースと時間軸で重畳しない場合、又はＰＵＳＣＨリソースの送信開始時点を基準としてＴ2以前の時点まで受信された（又は送信開始された）ＰＤＳＣＨ（及び／又はＰＤＣＣＨ）に対応する（又は該当ＰＤＳＣＨ／ＰＤＣＣＨから指示された）Ａ／Ｎ  ＰＵＣＣＨリソースが存在しない場合）、Ａ／ＮとＵＬ−ＳＣＨのうちの一つを選択して送信
【０５５６】
−Ｏｐｔ．１：ＵＬ−ＳＣＨ（ｏｎｌｙ）をＰＵＳＣＨリソースを介して送信（Ａ／Ｎ送信を省略）
【０５５７】
−Ｏｐｔ．２：Ａ／Ｎ（ｏｎｌｙ）をＡ／Ｎ  ＰＵＣＣＨリソースを介して送信（ＵＬ−ＳＣＨ送信を省略）
【０５５８】
Ｔ0、Ｔ1、Ｔ2は以下のうちの一つである。Ｔ0、Ｔ1、Ｔ2は（ＯＦＤＭ）シンボル単位で示すことができる。
【０５５９】
（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０５６０】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０５６１】
（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値
【０５６２】
（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値
【０５６３】
（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０５６４】
（６）基地局と端末の間に予め約束した値（例えば、固定値）
【０５６５】
本発明の変形により、スロットにおいてＰＵＣＣＨ−ＰＵＣＣＨ又はＰＵＣＣＨ−ＰＵＳＣＨが時間軸で重畳する場合、端末は以下の（一般化した）ＵＣＩ多重化規則を適用することができる。
【０５６６】
（１）特定のＵＣＩに対するＰＵＣＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ0以前の時点までＰＵＣＣＨリソースと時間軸で重畳するＵＬチャネルが設定／指示されない場合（例えば、ＵＬチャネルはＰＵＣＣＨ又はＰＵＳＣＨである）
【０５６７】
Ａ．端末は特定のＵＣＩのみをＰＵＣＣＨリソースを介して送信（時点以後のＰＵＣＣＨと重畳するＵＬチャネルが発生しても無視或いは該当ＵＬチャネルの送信を省略／放棄）
【０５６８】
（２）特定のＵＣＩ1に対するＰＵＣＣＨリソース（ＰＵＣＣＨ1）が先に指示／指示された後、ＵＣＩ1に対するＰＵＣＣＨリソース（ＰＵＣＣＨ1）の送信開始時点（又はスロット）を基準として、Ｔ0以前の時点までＰＵＣＣＨ1と時間軸で重畳する特定のＵＣＩ2に対するＰＵＣＣＨリソース（ＰＵＣＣＨ2）が設定／指示された場合
【０５６９】
Ａ．端末はＵＣＩ1とＵＣＩ2を多重化して単一のＰＵＣＣＨリソースを介して送信
【０５７０】
ｉ．但し、単一のＰＵＣＣＨリソースはＰＵＣＣＨ1とＰＵＣＣＨ2以外のリソースであることができる。
【０５７１】
（３）特定のＵＣＩに対するＰＵＣＣＨリソースが先に設定／指示された後、特定のＵＣＩに対するＰＵＣＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ0以前の時点までＰＵＣＣＨリソースと時間軸で重畳するＵＬ−ＳＣＨ  ＴＢに対するＰＵＳＣＨリソースが設定／指示された場合
【０５７２】
Ａ．端末はＵＣＩとＵＬ−ＳＣＨを多重化してＰＵＳＣＨリソースを介して送信（即ち、ＵＣＩピギーバック）
【０５７３】
（４）特定のＵＬ−ＳＣＨに対するＰＵＳＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ1以前の時点までＰＵＳＣＨと時間軸で重畳するＵＬチャネルが設定／指示されていない場合（例えば、該当ＵＬチャネルはＰＵＣＣＨである）
【０５７４】
Ａ．端末は特定のＵＬ−ＳＣＨのみをＰＵＳＣＨリソースを介して送信（時点以後のＰＵＳＣＨと重畳するＵＬチャネルが発生しても無視或いは該当ＵＬチャネルの送信を省略／放棄）
【０５７５】
（５）特定のＵＬ−ＳＣＨに対するＰＵＳＣＨリソースが先に設定／指示された後、特定のＵＬ−ＳＣＨに対するＰＵＳＣＨリソースの送信開始時点（又はスロット）を基準として、Ｔ1以前の時点までＰＵＳＣＨリソースと時間軸で重畳する特定のＵＣＩに対するＰＵＣＣＨリソースが設定／指示された場合
【０５７６】
Ａ．端末はＵＣＩとＵＬ−ＳＣＨ  ＴＢを多重化してＰＵＳＣＨリソースを介して送信（即ち、ＵＣＩピギーバック）
【０５７７】
Ｔ0、Ｔ1は以下のうちの一つである。Ｔ0、Ｔ1は（ＯＦＤＭ）シンボル単位で示すことができる。
【０５７８】
（１）端末能力によるＰＤＳＣＨの受信後、ＰＤＳＣＨに対応するＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０５７９】
（２）端末能力によるＰＤＣＣＨの受信後、ＰＤＣＣＨから指示されたＡ／Ｎ（ＰＵＣＣＨ）送信まで必要な端末処理時間又はそれに対応する値
【０５８０】
（３）端末能力による（特定の）ＵＣＩ送信のために必要な端末処理時間又はそれに対応する値
【０５８１】
（４）端末能力によるＵＬグラントの受信後、ＰＵＳＣＨ送信まで必要な端末処理時間又はそれに対応する値
【０５８２】
（５）上位層（例えば、ＲＲＣ）信号及び／又はＤＣＩにより設定された値
【０５８３】
（６）基地局と端末の間に予め約束した値（例えば、固定値）
【０５８４】
特定のＵＣＩがＡ／Ｎであるとき、該当ＵＣＩに対するＰＵＣＣＨリソースが設定／指示される時点は、Ａ／Ｎに対応するＰＤＳＣＨの受信（終了）時点と見なされる。
【０５８５】
特定のＵＣＩに対するＰＵＣＣＨリソースが先に設定／指示される動作は、上位層（例えば、ＲＲＣ）信号に基づいて設定される動作を含む。例えば、上位層信号により予め設定されたＰＵＣＣＨリソースは、ＤＣＩにより指示されたＰＵＣＣＨリソースより常に先に設定／指示されたリソースと見なされることができる。例えば、ＵＣＩ1とＵＣＩ2は、各々ＳＲとＡ／Ｎであるか、又は各々（ｐｅｒｉｏｄｉｃ）ＣＳＩとＨＡＲＱ−ＡＣＫである。
【０５８６】
但し、ＵＣＩ1とＵＣＩ2に対して以下の多重化動作が適用される。
【０５８７】
（１）ＵＣＩ1＝ＳＲ、ＵＣＩ2＝Ａ／Ｎである場合
【０５８８】
Ａ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合
【０５８９】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０５９０】
１．Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨにＣＳ／ＯＣＣ／ＰＲＢオフセットが適用されたリソースを介して送信
【０５９１】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０５９２】
１．Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０５９３】
Ｂ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット１である場合
【０５９４】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲである場合
【０５９５】
１．Ａ／ＮをＳＲ  ＰＵＣＣＨリソースを介して送信
【０５９６】
Ａ．但し、ＳＲ  ＰＵＣＣＨがＰＵＣＣＨフォーマット０である場合には、ＳＲを送信せず、Ａ／Ｎのみを送信することができる。
【０５９７】
ｉｉ．ＳＲに対するＵＣＩ状態がｎｅｇａｔｉｖｅ  ＳＲである場合
【０５９８】
１．Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０５９９】
Ｃ．Ａ／Ｎ  ＰＵＣＣＨがＰＵＣＣＨフォーマット２／３／４のうちの一つである場合
【０６００】
ｉ．ＳＲに対するＵＣＩ状態がＰｏｓｉｔｉｖｅ  ＳＲ又はｎｅｇａｔｉｖｅ  ＳＲである場合
【０６０１】
１．ＳＲを明示的ビットで表現してＡ／Ｎに付け加えてＵＣＩペイロードを生成後、生成されたＵＣＩをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０６０２】
（２）ＵＣＩ1＝ＣＳＩ、ＵＣＩ2＝Ａ／Ｎである場合
【０６０３】
Ａ．Ａ／Ｎ  ＰＵＣＣＨがＤＬ割り当てにより指示された場合
【０６０４】
ｉ．Ａ／ＮとＣＳＩを多重化してＡ／Ｎ  ＰＵＣＣＨリソースを介して送信
【０６０５】
Ｂ．Ａ／Ｎ  ＰＵＣＣＨがＤＬ割り当てにより指示されない場合
【０６０６】
ｉ．Ａ／ＮとＣＳＩを多重化してＣＳＩ  ＰＵＣＣＨリソースを介して送信
【０６０７】
［提案方法＃７］スロット内において、Ａ／Ｎ  ＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、端末はＡ／Ｎ  ＰＵＣＣＨの送信開始時点がＰＵＳＣＨの送信時点より遅いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ−ｇｏｉｎｇ  ＰＵＳＣＨ送信があれば、該当ＰＵＳＣＨ送信を中断し、Ａ／Ｎ  ＰＵＣＣＨを介してＡ／Ｎを送信する。
【０６０８】
さらにスロット内において、Ａ／Ｎ  ＰＵＣＣＨリソースとＰＵＳＣＨリソースが時間軸で（ＰＵＣＣＨ或いはＰＵＳＣＨ内の全体或いは一部のＯＦＤＭシンボルが）重畳することができる。この時、Ａ／Ｎ  ＰＵＣＣＨの送信開始時点がＰＵＳＣＨの送信時点より早いことができる。この場合、端末は（ベストエフォート方式により）Ｏｎ−ｇｏｉｎｇ  ＰＵＣＣＨ送信があれば、該当ＰＵＣＣＨ送信を中断し、Ａ／ＮをＰＵＳＣＨによりピギーバックする。
【０６０９】
端末がＰＵＳＣＨ送信を行った後に該当ＰＵＣＣＨと時間軸で一部重畳するＡ／Ｎ  ＰＵＣＣＨリソースの存在を把握した場合は、端末は簡単な方法により該当Ａ／Ｎ送信を省略することができる。しかし、端末が十分な能力があれば、できる限り（即ち、ベストエフォート方式により）現在進行中のＰＵＳＣＨ送信を中断し、Ａ／ＮをＡ／Ｎ  ＰＵＣＣＨリソースを介して送信しようとする。［提案方法＃６．１］の動作により、端末はＰＵＳＣＨとＡ／Ｎが衝突した場合にもＡ／Ｎ送信を最大限支援することができる。
【０６１０】
［提案方法＃８］ＮＲシステムでは、Ａ−ＣＳＩ  Ｏｎｌｙ  ＰＵＳＣＨに対する送信の有無を端末に確実に知らせるために、ＵＬグラント内にＡ−ＣＳＩ（Ａｐｅｒｉｏｄｉｃ  ＣＳＩ）の報告の有無を知らせるＡ−ＣＳＩトリガーフィールド以外に、ＰＵＳＣＨ内のデータ（例：ＵＬ−ＳＣＨ  ＴＢ、簡単には、ＵＬ−ＳＣＨ）の存在の有無を知らせるＵＬ−ＳＣＨ指示子が含まれる。例えば、Ａ−ＣＳＩトリガーフィールドはＮビットで構成され、ＵＬ−ＳＣＨ指示子は１ビットで構成される。この時、ＵＬ−ＳＣＨ指示子がＵＬ−ＳＣＨがないと指示し、Ａ−ＣＳＩトリガーフィールドがＡ−ＣＳＩ報告があると指示すると、端末はＡ−ＣＳＩ  Ｏｎｌｙ  ＰＵＳＣＨ送信が指示されたと判断する。しかし、ＵＬ−ＳＣＨ指示子がＵＬ−ＳＣＨがないと指示したが、Ａ−ＣＳＩトリガーフィールドもＡ−ＣＳＩ報告もないと指示すると、この場合に対する解釈が曖昧になる。従って、この提案では、ＵＬ−ＳＣＨ指示子がＵＬ−ＳＣＨがないことを指示し、Ａ−ＣＳＩトリガーフィールドもＡ−ＣＳＩ報告がないことを指示した場合、端末が以下のうちの一つに解釈する方法を提案する。
【０６１１】
（１）ＵＣＩ  Ｏｎｌｙ  ＰＵＳＣＨ  ｗｉｔｈｏｕｔ  ＵＬ−ＳＣＨを送信。ここで、ＵＣＩ  Ｏｎｌｙ  ＰＵＳＣＨ  ｗｉｔｈｏｕｔ  ＵＬ−ＳＣＨ送信は、ＵＬデータなしに同一のスロット／時点内の送信が指示／設定されたＵＣＩをＰＵＳＣＨにピギーバックすることを含む。
【０６１２】
（２）誤り状況であると判断（ｅｒｒｏｒ  ｃａｓｅ）。これにより、端末はＰＵＳＣＨ送信を期待しないことができる。ここで、ＰＵＳＣＨ送信を期待しないことは、例えば、該当ＰＵＳＣＨ送信を省略（Ｄｒｏｐ）するか、又は該当ＰＵＳＣＨをスケジュールするＤＣＩを廃棄（ｄｉｓｃａｒｄ）することを含む。ＤＣＩを廃棄することは、ＤＣＩにより指示された動作を従わない／行わないことを含む。
【０６１３】
（３）ＰＵＳＣＨに対してＵＬ−ＳＣＨ（或いはＵＬデータ）送信がないと指示され、Ａ−ＣＳＩ送信もないと指示された場合、端末は指示されたＰＵＳＣＨリソースに特定のＰＵＣＣＨに対するＵＣＩを多重化してＵＣＩ  Ｏｎｌｙ  ＰＵＳＣＨ  ｗｉｔｈｏｕｔ  ＵＬ−ＳＣＨを送信することができる。この時、ＵＣＩはＨＡＲＱ−ＡＣＫのみが存在する場合、端末はＰＵＳＣＨリソースによりＨＡＲＱ−ＡＣＫのみを送信する。この場合、以下のようにＨＡＲＱ−ＡＣＫにはＰＵＳＣＨ内の（利用可能な）全てのＲＥが割り当てられる。例えば、ＰＵＳＣＨリソース領域にＲＳが送信されるシンボル或いはＲＥを除いた全てのＲＥが割り当てられることができる。ＨＡＲＱ−ＡＣＫは一般的な規則によって１番目のＤＭ−ＲＳ以後のｎｏｎ−ＤＭ−ＲＳ  ＯＦＤＭシンボルのみについてマッピングされるか（例：ＤＭＲＳ又はＤａｔａ  Ｍａｐｐｉｎｇ  Ｔｙｐｅ  Ｂである場合）、１番目のＤＭ−ＲＳ以前のＯＦＤＭシンボルにもマッパイングされることができる（例：ＤＭＲＳ又はＤａｔａ  Ｍａｐｐｉｎｇ  Ｔｙｐｅ  Ａである場合）。
【０６１４】
（４）ＰＵＳＣＨに対してＵＬ−ＳＣＨ（或いはＵＬデータ）送信がないと指示され、Ａ−ＣＳＩ送信もないと指示された場合、端末は指示されたＰＵＳＣＨリソースを、ＵＬ−ＳＣＨ（又はＵＬデータ）を送信するがＵＣＩピギーバックを許容しないＰＵＳＣＨリソースと判断することができる。
【０６１５】
（５）ＰＵＳＣＨをスケジュールするＤＣＩ内にＵＣＩピギーバック（Ｏｎ／Ｏｆｆ）フィールド（以下、フィールドＡ）とＡ−ＣＳＩトリガー（Ｏｎ／Ｏｆｆ）フィールド（以下、フィールドＢ）がある場合、各フィールドの２つの状態の組み合わせである４個の状態で端末のＰＵＳＣＨスケジューリング情報を表現することができる。例えば、フィールドＡとフィールドＢにより以下のようにＰＵＳＣＨスケジューリング情報を表現することができる。ここで、フィールドＡのＯｎ／Ｏｆｆは、ＰＵＳＣＨ内のＵＣＩピギーバックが許容される場合（’Ｏｎ’）と、ＰＵＳＣＨ内のＵＣＩピギーバックが許容されない場合（’Ｏｆｆ’）を意味する。また、フィールドＢのＯｎ／Ｏｆｆは、Ａ−ＣＳＩ報告送信を指示する場合（’Ｏｎ’）と、Ａ−ＣＳＩ報告送信を指示しない場合（’Ｏｆｆ’）を意味する。
【０６１６】
−フィールドＡ＝’Ｏｎ’、フィールドＢ＝’Ｏｆｆ’
【０６１７】
・ＰＵＳＣＨ内にＵＬ−ＳＣＨが存在し、Ａ−ＣＳＩ報告が存在せず、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容
【０６１８】
−フィールドＡ＝’Ｏｎ’、フィールドＢ＝’Ｏｎ’
【０６１９】
・ＰＵＳＣＨ内にＵＬ−ＳＣＨが存在し、Ａ−ＣＳＩ報告が存在し、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容
【０６２０】
−フィールドＡ＝’Ｏｆｆ’、フィールドＢ＝’Ｏｆｆ’
【０６２１】
・ＰＵＳＣＨ内にＵＬ−ＳＣＨが存在し、Ａ−ＣＳＩ報告が存在せず、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容しない
【０６２２】
−フィールドＡ＝’Ｏｆｆ’、フィールドＢ＝’Ｏｎ’
【０６２３】
・ＰＵＳＣＨ内にＵＬ−ＳＣＨが存在せず、Ａ−ＣＳＩ報告が存在し、（ＰＵＳＣＨとの）ＵＣＩ多重化条件を満たすＰＵＣＣＨに対するＵＣＩピギーバックを許容
【０６２４】
［提案方法＃９］端末が時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対するＵＣＩ多重化を行うとき、ＰＵＣＣＨ或いはＰＵＳＣＨに対する柔軟なＵＬタイミング設定によっては端末のプロセシング時間が足りないことができる。これを予防するために、（時間軸で）重畳したＰＵＣＣＨ（／ＰＵＳＣＨ）に対するＵＣＩ多重化の有無を判断するために、以下の２つのタイムライン条件が考えられる（以下、多重化タイムライン条件）。
【０６２５】
（１）ＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨの最後のシンボルは、（時間軸で）重畳するＰＵＣＣＨ／ＰＵＳＣＨのうちの最も早いチャネルの開始シンボルからＮ１+＝｛Ｎ１＋ｄ１｝シンボル前に受信、及び／又は
【０６２６】
（２）ＰＵＣＣＨ又はＰＵＳＣＨ送信を指示する（例：トリガー）ＰＤＣＣＨの最後のシンボルは、（時間軸で）重畳するＰＵＣＣＨ／ＰＵＳＣＨのうちの最も早いチャネルの開始シンボルからＮ２+＝｛Ｎ２＋ｄ２｝シンボル前に受信
【０６２７】
これに関連して、本発明の優先日前に公開された３ＧＰＰ  ＴＳ  ３８．２１３  Ｖ１５．２．０（２０１８−０６）（以下、３８．２１３）に以下のように規定されている。
【０６２８】
３ＧＰＰ  ＴＳ  ３８．２１３  Ｖ１５．２．０（２０１８−０６）：Ｔｉｍｅｌｉｎｅ  ｆｏｒ  ＵＣＩ  Ｍｕｌｔｉｐｌｅｘｉｎｇ
2021506195.tif 000006
【０６２９】
ここで、この提案におけるＮ１＋は３８．２１３のＮ１＋（＝Ｎ１＋１）＋ｄ1,1＋ｄ1,2に対応し、Ｎ２＋は３８．２１３のＮ2＋（＝Ｎ2＋１）＋ｄ2,1に対応する。Ｎ１（又はＮ1）は端末能力によって定義された最小のＰＤＳＣＨプロセシング時間を示し、Ｎ２（又はＮ2）は端末能力によって定義された最小のＰＵＳＣＨプロセシング時間を示す。ｄx,xは０以上の定数であり、例えば、スケジュールされたシンボルの位置やＢＷＰスイッチングなどを考慮して予め定義された値である。
【０６３０】
表４及び表５は３８．２１３に定義されたＮ１とＮ２を各々例示する。
【０６３１】
【表４】
2021506195.tif 000007
【０６３２】
【表５】
2021506195.tif 000008
【０６３３】
図１３はタイムライン条件を考慮したＵＣＩ多重化を例示する。図１３を参照すると、端末は同一のスロットで複数のＵＬチャネル（例：ＵＬチャネル＃１〜＃４）を送信する。ここで、ＵＬ  ＣＨ＃１はＰＤＣＣＨ＃１によりスケジュールされたＰＵＳＣＨである。またＵＬ  ＣＨ＃２はＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫを送信するためのＰＵＣＣＨである。ＰＤＳＣＨはＰＤＣＣＨ＃２によりスケジュールされ、ＵＬ  ＣＨ＃２のリソースもＰＤＣＣＨ＃２により指示される。
【０６３４】
この時、時間軸で重畳するＵＬチャネル（例：ＵＬチャネル＃１〜＃３）が多重化タイムライン条件を満たす場合、端末は時間軸で重畳したＵＬチャネル＃１〜＃３に対してＵＣＩ多重化を行うことができる。具体的には、端末はＰＤＳＣＨの最後のシンボルからＵＬ  ＣＨ＃３の最初のシンボルがＮ１＋ｄ１の条件を満たすか否かを確認する。また端末はＰＤＣＣＨ＃１の最後のシンボルからＵＬ  ＣＨ＃３の最初のシンボルがＮ２＋ｄ２の条件を満たすか否かを確認する。多重化タイムライン条件を満たす場合、端末はＵＬチャネル＃１〜＃３に対してＵＣＩ多重化を行う（例：提案方法＃１Ｃを参照）。反面、多重化タイムライン条件を満たさない場合は、端末はＵＣＩ多重化なしに、ＵＬチャネルの送信動作を行うことができる。この場合、ＵＬチャネル＃１〜＃３は全て一緒に送信されるか、又はＵＣＩ／チャネル優先順位を考慮して、一部のＵＬチャネルは送信がスキップ／省略され、一部のＵＬチャネルのみが送信される。
【０６３５】
一方、ＮＲシステムは様々なＯＦＤＭニューマロロジー（例：ＳＣＳ）を支援し、端末プロセシング時間はＳＣＳによって以下を満たす値が与えられる。
【０６３６】
（１）シンボル数（例：Ｎ１+）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２-u
【０６３７】
（２）シンボル数（例：Ｎ２+）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２-u
【０６３８】
ここで、シンボル当たりのサンプル数は（２０４８＋１４４）であり、ＳＣＳが１５ｋＨｚである時のサンプリング時間は１／（２０４８＊１５０００）である。２０４８はＦＦＴサイズを示し、１４４はＣＰを構成するサンプル数を例示する。ｕは表１を参照することができる。
【０６３９】
タイムライン条件において、ｕは（スロット内で）時間軸で重畳するＵＬチャネルのＳＣＳに基づいて決定される。ここで、ＵＬチャネルはＰＵＣＣＨ／ＰＵＳＣＨを含む。この時、時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対して適用されたＯＦＤＭニューマロロジー（例：ＳＣＳ）が互いに同一である場合は、Ｎ１+、Ｎ２+に適用されるＳＣＳが明らかである。しかし、時間軸で重畳するＰＵＣＣＨ／ＰＵＳＣＨに対して適用されたＯＦＤＭニューマロロジーが異なる場合には、Ｎ１+、Ｎ２+に適用されるＳＣＳが不明である。ここで、ＰＵＣＣＨ／ＰＵＳＣＨはＰＵＣＣＨ及び／又はＰＵＳＣＨを意味する。
【０６４０】
従って、この発明では、Ｎ１+、Ｎ２+に適用されるＳＣＳを以下のうちのいずれかの方式で決定する方法を提案する。
【０６４１】
（１）Ｏｐｔ．１：Ｎ１+、Ｎ２+に対して（時間軸で）重畳する全てのＵＬチャネルのＳＣＳのうち、最小のＳＣＳを適用する。Ｏｐｔ．１において、最小のＳＣＳを適用することは、相対的にＮ１+、Ｎ２+に適用されるシンボルサイズを大きく設定することにより、タイムライン条件を保守的に適用する方法である。
【０６４２】
（２）Ｏｐｔ．２：Ｎ１+、Ｎ２+に対して（時間軸で）重畳する全てのＵＬチャネルのうち、最も早いチャネルのＳＣＳを適用する。
【０６４３】
（３）Ｏｐｔ．３：Ｎ１+に対しては、Ａ／Ｎ  ＰＵＣＣＨ（或いはＡ／Ｎを含むＵＬチャネル）のＳＣＳを適用する。一方、Ｎ２+に対しては、ＰＤＣＣＨで送信指示される全てのＵＬチャネル（例：ＰＵＳＣＨ）のうち、最小ＳＣＳ（或いは最も早いＵＬチャネルのＳＣＳ）を適用する。Ａ／Ｎ  ＰＵＣＣＨはＨＡＲＱ−ＡＣＫの送信目的として設定／指示されたＰＵＣＣＨを意味する。
【０６４４】
一方、ＮＲシステムでは、ＰＤＣＣＨ、ＰＤＳＣＨ及びＵＬチャネル（例：ＰＵＣＣＨ／ＰＵＳＣＨ）のＳＣＳが全部異なることができる。これにより、端末プロセシング時間はＰＤＣＣＨ  ＳＣＳ、ＰＤＳＣＨ  ＳＣＳ及びＵＬチャネルのＳＣＳを全て考慮して決定される。例えば、端末プロセシング時間の計算に使用されるＳＣＳ（即ち、ｕ）は、ＰＤＣＣＨ  ＳＣＳ、ＰＤＳＣＨ  ＳＣＳ及びＵＬチャネルのＳＣＳの関数により与えられるか、又はこれらのうちの一つの値により与えられる。
【０６４５】
図１４は本発明により制御情報を送信する方法を例示する。
【０６４６】
図１４を参照すると、端末は基地局からＰＤＳＣＨを受信する（Ｓ１７０２）。ここで、ＰＤＳＣＨはＰＤＣＣＨ（例：ＤＣＩフォーマット１＿０、１＿１）によりスケジュールされる。図４を参照すると、ＰＤＣＣＨの受信時点からＫ０スロット後にＰＤＳＣＨ受信時点からＫ１スロット後にＰＤＳＣＨに関する応答情報（例：ＨＡＲＱ−ＡＣＫ応答）が第１ＵＬチャネル（例：ＰＵＣＣＨ）を介して送信される。第１ＵＬチャネルリソースはＰＤＣＣＨ内のＰＲＩにより指示される。一方、第１ＵＬチャネルの送信が指示されたスロットに複数のＵＬチャネルが割り当てられることができる。複数のＵＬチャネルは複数のＰＵＣＣＨを含む。また複数のＵＬチャネルはさらに一つ以上のＰＵＳＣＨを含む。この場合、端末はＵＣＩ多重化の有無を判断するために、（ｉ）ＰＤＳＣＨと、（ｉｉ）時間軸で重畳する複数のＵＬチャネルのうちの最も早いＵＬチャネルとの間の時間間隔が基準時間を満たすか否かを確認する（Ｓ１７０４）。ここで、時間間隔は、（ｉ）ＰＤＳＣＨの最後のシンボルと、（ｉｉ）最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される。また複数のＵＬチャネルはＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含む。その後、端末は基準時間を満たしたか否かによって、複数のＵＬチャネルに関連するＵＣＩを一つのＵＬチャネルで多重化することができる（Ｓ１７０６）。
【０６４７】
ここで、基準時間はシンボル数とＳＣＳに基づいて決定され、ＳＣＳは複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値を含む。ここで、シンボルの長さはＳＣＳに基づいて決定され、シンボルの長さとＳＣＳは反比例する。例えば、基準時間は以下の値に基づいて決定される。
【０６４８】
−シンボル数（例：Ｎ１+）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２-u
【０６４９】
ここで、Ｎ１+はＰＤＳＣＨ処理に必要な最小プロセシング時間を示し、ｕは０以上の整数であって、ＳＣＳに対応するインデックスを示す（表１を参照）。
【０６５０】
最も早いＵＬチャネルのＳＣＳは、複数のＵＬチャネルに対する複数のＳＣＳのうちの最小値より大きい。時間間隔が基準時間より大きい場合、応答情報を含むＵＣＩは一つのＵＬチャネルに多重化されて送信され、時間間隔が基準時間より小さいか又は等しい場合は、端末は時間軸で重なる複数のＵＬチャネルに対してＵＣＩ多重化を行わない。従って、ＰＤＳＣＨに関する応答情報は多重化なしに第１ＵＬチャネルを介して送信される。
【０６５１】
また複数のＵＬチャネルがＰＤＣＣＨによりスケジュールされたＰＵＳＣＨを含む場合、端末はＵＣＩ多重化の有無を判断するために、（ｉ）ＰＤＣＣＨと、（ｉｉ）最も早いＵＬチャネルとの間の時間間隔が追加基準時間を満たすか否かをさらに確認する。この場合、追加基準時間を満たさないと、ＵＣＩ多重化が行われない。例えば、追加基準時間は以下の値に基づいて決定される。
【０６５２】
−シンボル数（例：Ｎ２+）＊シンボル当たりのサンプル数＊サンプリング時間（例：ＳＣＳが１５ｋＨｚである時のサンプリング時間）＊２-u
【０６５３】
ここで、Ｎ２+はＰＵＳＣＨの準備に必要な最小プロセシング時間を示し、ｕは０以上の整数であって、ＳＣＳに対応するインデックスを示す（表１を参照）。
【０６５４】
図１５は本発明によるタイムライン条件を考慮したＵＣＩ多重化を例示する。図１５を参照すると、端末は同一のスロットにおいて複数のＵＬチャネル（例：ＵＬチャネル＃１〜＃４）を送信する。ここで、ＵＬ  ＣＨ＃１はＰＤＣＣＨ＃１によりスケジュールされたＰＵＳＣＨである。またＵＬ  ＣＨ＃２はＰＤＳＣＨに対するＨＡＲＱ−ＡＣＫを送信するためのＰＵＣＣＨである。ＰＤＳＣＨはＰＤＣＣＨ＃２によりスケジュールされ、ＵＬ  ＣＨ＃２のリソースもＰＤＣＣＨ＃２により指示される。この時、ＵＬ  ＣＨ＃１〜＃３のＳＣＳは各々ｕ＝１（ｕ１）、ｕ＝０（ｕ０）及びｕ＝２（ｕ２）であると仮定する（表１を参照）。
【０６５５】
この時、時間軸で重畳するＵＬチャネル（例：ＵＬチャネル＃１〜＃３）が多重化タイムライン条件を満たす場合、端末は時間軸で重畳するＵＬチャネル＃１〜＃３に対してＵＣＩ多重化を行う。具体的には、端末はＰＤＳＣＨの最後のシンボルからＵＬ  ＣＨ＃３の最初シンボルがＮ１＋ｄ１の条件を満たすか否かを確認する。また端末はＰＤＣＣＨ＃１の最後のシンボルからＵＬ  ＣＨ＃３の最初のシンボルがＮ２＋ｄ２の条件を満たすか否かを確認する。一方、｛Ｎ１＋ｄ１｝及び｛Ｎ２＋ｄ２｝には、ＵＬ  ＣＨ＃１〜＃３のＳＣＳのうちの最小のＳＣＳが適用される（即ち、ＵＬ  ＣＨ＃１；ｕ＝０）。多重化タイムライン条件を満たす場合、端末はＵＬチャネル＃１〜＃３に対してＵＣＩ多重化を行うことができる（例：提案方法＃１Ｃを参照）。反面、多重化タイムライン条件を満たさない場合、端末はＵＣＩ多重化なしに、ＵＬチャネルの送信動作を行うことができる。この場合、ＵＬチャネル＃１〜＃３は全て一緒に送信されるか、又はＵＣＩ／チャネル優先順位を考慮して、一部のＵＬチャネルは送信がスキップ／省略され、一部のＵＬチャネルのみが送信される。例えば、ＵＣＩがＨＡＲＱ−ＡＣＫ応答とＣＳＩがある場合、ＵＣＩ優先順位に従ってＣＳＩ送信がスキップ／省略されることができる。
【０６５６】
［提案方法＃１０］ＮＲシステムにおいて、基地局は端末に複数のＳＲリソースを設定する。ＳＲリソースがＰＵＣＣＨフォーマット１のリソースである場合、端末は同時送信が指示されたＫ個のＳＲリソースのうち、（優先順位が高い）１個のＳＲリソースのみを選択して送信する（例：チャネル／リソース選択）。この時、Ｋ値によって基地局でＳＲ受信のために仮定する仮定（ｈｙｐｏｔｈｅｓｉｓ）の数が増加し、ＵＣＩ送信性能が低下することができる。従って、この提案では、端末に一つ以上のＫ個のＳＲリソースが（時間上重畳するように）設定され、以下のうちのいずれかの場合について、Ｋ値の関数で表現される（或いはＫ値に比例する）電力オフセットをＰＵＣＣＨ送信に反映する方法を提案する。
【０６５７】
（１）Ｃａｓｅ  １：Ｋ個のＳＲリソースのうちの一つのＳＲリソースを選択して送信する場合
【０６５８】
（２）Ｃａｓｅ  ２：Ｋ個のＳＲリソース及びＡ／Ｎリソースのうちの一つのリソースを選択して該当リソースでＡ／Ｎを送信する場合
【０６５９】
ここで、電力オフセットはＫ値に比例する。例えば、電力オフセットはＫ（又は、Ｋ−１）又はｌｏｇ2（Ｋ）（又は、ｌｏｇ2（Ｋ−１））又はｃｅｉｌ（ｌｏｇ2（Ｋ））（又は、ｃｅｉｌ（ｌｏｇ2（Ｋ−１））の関数である。ｃｅｉｌ（）は切り上げ関数である。これにより、ＰＵＣＣＨ送信電力はＫ値に比例して増加する。
【０６６０】
ここで、２つのケースに対する電力オフセットは互いに異なる形態である。Ｃａｓｅ２の場合、さらにＡ／Ｎが送信されるので、Ｃａｓｅ  １に比較して相対的に大きい電力オフセットが適用される。またこの提案はＳＲとＡ／Ｎに対して割り当てられたＰＵＣＣＨリソースがＰＵＣＣＨフォーマット１である場合に限られる。
【０６６１】
図１６は本発明に適用される通信システム１を例示する。
【０６６２】
図１６を参照すると、本発明に適用される通信システム１は、無線機器、基地局及びネットワークを含む。ここで、無線機器は無線アクセス技術（例えば、５Ｇ  ＮＲ、ＬＴＥ）を用いて通信を行う機器を意味し、通信／無線／５Ｇ機器とも称される。これに限られないが、無線機器はロボット１００ａ、車両１００ｂ−１，１００ｂ−２、ＸＲ（ｅＸｔｅｎｄｅｄ  Ｒｅａｌｉｔｙ）機器１００ｃ、携帯機器（Ｈａｎｄ−ｈｅｌｄ  Ｄｅｖｉｃｅ）１００ｄ、家電１００ｅ、ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇ）機器１００ｆ及びＡＩサーバ／機器４００を含む。例えば、車両は無線通信機能が備えられた車両、自律走行車両、車両間通信を行える車両などを含む。ここで、車両はＵＡＶ（Ｕｎｍａｎｎｅｄ  Ａｅｒｉａｌ  Ｖｅｈｉｃｌｅ）（例えば、ドローン）を含む。ＸＲ機器はＡＲ（Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ）／ＶＲ（Ｖｉｒｔｕａｌ  Ｒｅａｌｉｔｙ）／ＭＲ（Ｍｉｘｅｄ  Ｒｅａｌｉｔｙ）機器を含み、ＨＭＤ（Ｈｅａｄ−Ｍｏｕｎｔｅｄ  Ｄｅｖｉｃｅ）、車両に備えられたＨＵＤ（Ｈｅａｄ−Ｕｐ  Ｄｉｓｐｌａｙ）、ＴＶ、スマートホン、コンピュータ、ウェアラブルデバイス、家電機器、デジタル看板、車両、ロボットなどの形態で具現化される。携帯機器はスマートホン、スマートパッド、ウェアラブル機器（例えば、スマートウォッチ、スマートグラス）、コンピュータ（例えば、ノートブックパソコンなど）などを含む。家電はＴＶ、冷蔵庫、洗濯機などを含む。ＩｏＴ機器はセンサ、スマートメータなどを含む。例えば、基地局、ネットワークは無線機器にも具現化され、特定の無線機器２００ａは他の無線機器に基地局／ネットワークノードで動作することもできる。
【０６６３】
無線機器１００ａ〜１００ｆは基地局２００を介してネットワーク３００に連結される。無線機器１００ａ〜１００ｆにはＡＩ（Ａｒｔｉｆｉｃｉａｌ  Ｉｎｔｅｌｌｉｇｅｎｃｅ）技術が適用され、無線機器１００ａ〜１００ｆはネットワーク３００を介してＡＩサーバ４００に連結される。ネットワーク３００は３Ｇネットワーク、４Ｇ（例えば、ＬＴＥ）ネットワーク又は５Ｇ（例えば、ＮＲ）ネットワークなどを用いて構成される。無線機器１００ａ〜１００ｆは基地局２００／ネットワーク３００を介して互いに通信できるが、基地局／ネットワークを介することなく、直接通信することもできる（例えば、サイドリンク通信）。例えば、車両１００ｂ−１、１００ｂ−２は直接通信することができる（例えば、Ｖ２Ｖ（Ｖｅｈｉｃｌｅ  ｔｏ  Ｖｅｈｉｃｌｅ）／Ｖ２Ｘ（Ｖｅｈｉｃｌｅ  ｔｏ  ｅｖｅｒｙｔｈｉｎｇ）通信）。またＩｏＴ機器（例えば、センサ）は他のＩｏＴ機器（例えば、センサ）又は他の無線機器１００ａ〜１００ｆと直接通信することができる。
【０６６４】
無線機器１００ａ〜１００ｆ／基地局２００、基地局２００／基地局２００の間には無線通信／連結１５０ａ、１５０ｂ、１５０ｃが行われる。ここで、無線通信／連結は上り／下りリンク通信１５０ａとサイドリンク通信１５０ｂ（又は、Ｄ２Ｄ通信）、基地局間の通信１５０ｃ（例えば、ｒｅｌａｙ、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ  Ａｃｃｅｓｓ  Ｂａｃｋｈａｕｌ）のような様々な無線アクセス技術により行われる（例えば、５Ｇ  ＮＲ）。無線通信／連結１５０ａ、１５０ｂ、１５０ｃにより無線機器と基地局／無線機器、基地局と基地局は互いに無線信号を送信／受信することができる。例えば、無線通信／連結１５０ａ、１５０ｂ、１５０ｃは様々な物理チャネルを介して信号を送信／受信することができる。このために、本発明の様々な提案に基づいて、無線信号の送信／受信のための様々な構成情報の設定過程、様々な信号処理過程（例えば、チャネル符号化／復号、変調／復調、リソースマッピング／デマッピングなど）、リソース割り当て過程のうちのいずれか１つが行われる。
【０６６５】
図１７は本発明に適用可能な無線機器を例示する。
【０６６６】
図１７を参照すると、第１無線機器１００と第２無線機器２００は様々な無線アクセス技術（例えば、ＬＴＥ、ＮＲ）により無線信号を送受信する。ここで、｛第１無線機器１００、第２無線機器２００｝は図１６の｛無線機器１００ａ〜１００ｆ、基地局２００｝及び／又は｛無線機器１００ａ〜１００ｆ、無線機器１００ａ〜１００ｆ｝に対応する。
【０６６７】
第１無線機器１００は１つ以上のプロセッサ１０２及び１つ以上のメモリ１０４を含み、さらに１つ以上の送受信機１０６及び／又は１つ以上のアンテナ１０８を含む。プロセッサ１０２はメモリ１０４及び／又は送受信機１０６を制御し、この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートを具現化するように構成される。例えば、プロセッサ１０２はメモリ１０４内の情報を処理して第１情報／信号を生成した後、送受信機１０６で第１情報／信号を含む無線信号を送信する。またプロセッサ１０２は送受信機１０６で第２情報／信号を含む無線信号を受信した後、第２情報／信号の信号処理から得た情報をメモリ１０４に格納する。メモリ１０４はプロセッサ１０２に連結され、プロセッサ１０２の動作に関連する様々な情報を格納する。例えば、メモリ１０４はプロセッサ１０２により制御されるプロセスのうちの一部又は全部を行うか、又はこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートを行うための命令を含むソフトウェアコードを格納する。ここで、プロセッサ１０２とメモリ１０４は無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現化するように設計された通信モデム／回路／チップの一部である。送受信機１０６はプロセッサ１０２に連結され、１つ以上のアンテナ１０８により無線信号を送信及び／又は受信する。送受信機１０６は送信機及び／又は受信機を含む。送受信機１０６はＲＦ（ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）ユニットとも混用することができる。本発明において、無線機器は通信モデム／回路／チップを意味することもできる。
【０６６８】
第２無線機器２００は１つ以上のプロセッサ２０２及び１つ以上のメモリ２０４を含み、さらに１つ以上の送受信機２０６及び／又は１つ以上のアンテナ２０８を含む。プロセッサ２０２はメモリ２０４及び／又は送受信機２０６を制御し、この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートを具現化するように構成される。例えば、プロセッサ２０２はメモリ２０４内の情報を処理して第３情報／信号を生成した後、送受信機２０６で第３情報／信号を含む無線信号を送信する。またプロセッサ２０２は送受信機２０６で第４情報／信号を含む無線信号を受信した後、第４情報／信号の信号処理から得た情報をメモリ２０４に格納する。メモリ２０４はプロセッサ２０２に連結され、プロセッサ２０２の動作に関連する様々な情報を格納する。例えば、メモリ２０４はプロセッサ２０２により制御されるプロセスのうちの一部又は全部を行うか、又はこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートを行うための命令を含むソフトウェアコードを格納する。ここで、プロセッサ２０２とメモリ２０４は無線通信技術（例えば、ＬＴＥ、ＮＲ）を具現化するように設計された通信モデム／回路／チップの一部である。送受信機２０６はプロセッサ２０２に連結され、１つ以上のアンテナ２０８により無線信号を送信及び／又は受信する。送受信機２０６は送信機及び／又は受信機を含む。送受信機２０６はＲＦユニットとも混用することができる。本発明において、無線機器は通信モデム／回路／チップを意味することもできる。
【０６６９】
以下、無線機器１００，２００のハードウェア要素についてより具体的に説明する。これに限られないが、１つ以上のプロトコル層が１つ以上のプロセッサ１０２，２０２により具現化される。例えば、１つ以上のプロセッサ１０２，２０２は１つ以上の層（例えば、ＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ、ＲＲＣ、ＳＤＡＰのような機能層）を具現化する。１つ以上のプロセッサ１０２，２０２はこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートによって１つ以上のＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）及び／又は１つ以上のＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）を生成する。１つ以上のプロセッサ１０２，２０２はこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートによってメッセージ、制御情報、データ又は情報を生成する。１つ以上のプロセッサ１０２，２０２はこの明細書に開示された機能、手順、提案及び／又は方法によってＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ又は情報を含む信号（例えば、ベースバンド信号）を生成して、１つ以上の送受信機１０６，２０６に提供する。１つ以上のプロセッサ１０２，２０２は１つ以上の送受信機１０６，２０６から信号（例えば、ベースバンド信号）を受信して、この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートによってＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ又は情報を得ることができる。
【０６７０】
１つ以上のプロセッサ１０２，２０２はコントローラ、マイクロコントローラ、マイクロプロセッサ又はマイクロコンピュータとも称される。１つ以上のプロセッサ１０２，２０２はハードウェア、ファームウェア、ソフトウェア又はこれらの組み合わせにより具現化される。一例として、１つ以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、１つ以上のＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、１つ以上のＤＳＰＤ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｄｅｖｉｃｅ）、１つ以上のＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）又は１つ以上のＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙｓ）が１つ以上のプロセッサ１０２，２０２に含まれる。この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートはファームウェア又はソフトウェアを使用して具現化され、ファームウェア又はソフトウェアはモジュール、手順、機能などを含むように具現化される。この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートを行うように設定されたファームウェア又はソフトウェアは１つ以上のプロセッサ１０２，２０２に含まれるか、又は１つ以上のメモリ１０４，２０４に格納されて１つ以上のプロセッサ１０２，２０２により駆動される。この明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートはコード、命令語（ｉｎｓｔｒｕｃｔｉｏｎ）及び／又は命令語の集合の形態でファームウェア又はソフトウェアを使用して具現化される。
【０６７１】
１つ以上のメモリ１０４，２０４は１つ以上のプロセッサ１０２，２０２に連結され、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び／又は命令を格納することができる。１つ以上のメモリ１０４，２０４はＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、フラッシメモリ、ハードドライブ、レジスター、キャッシュメモリ、コンピュータ読み取り格納媒体及び／又はこれらの組み合わせにより構成される。１つ以上のメモリ１０４，２０４は１つ以上のプロセッサ１０２，２０２の内部及び／又は外部に位置する。また、１つ以上のメモリ１０４，２０４は有線又は無線連結のような様々な技術により１つ以上のプロセッサ１０２，２０２に連結される。
【０６７２】
１つ以上の送受信機１０６，２０６は１つ以上の他の装置にこの明細書における方法及び／又はフローチャートなどで言及されたユーザデータ、制御情報、無線信号／チャネルなどを送信することができる。１つ以上の送受信機１０６，２０６は１つ以上の他の装置からこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートなどで言及されるユーザデータ、制御情報、無線信号／チャネルなどを受信することができる。例えば、１つ以上の送受信機１０６，２０６は１つ以上のプロセッサ１０２，２０２に連結され、無線信号を送受信することができる。例えば、１つ以上のプロセッサ１０２，２０２は１つ以上の送受信機１０６，２０６が１つ以上の他の装置にユーザデータ、制御情報又は無線信号を送信するように制御することができる。また、１つ以上のプロセッサ１０２，２０２は１つ以上の送受信機１０６，２０６が１つ以上の他の装置からユーザデータ、制御情報又は無線信号を受信するように制御することができる。また、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８に連結され、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８によりこの明細書に開示された説明、機能、手順、提案、方法及び／又はフローチャートなどで言及されるユーザデータ、制御情報、無線信号／チャネルなどを送受信するように設定される。この明細書において、１つ以上のアンテナは複数の物理アンテナであるか、複数の論理アンテナ（例えば、アンテナポート）である。１つ以上の送受信機１０６，２０６は受信されたユーザデータ、制御情報、無線信号／チャネルなどを１つ以上のプロセッサ１０２，２０２を用いて処理するために、受信された無線信号／チャネルなどをＲＦバンド信号からベースバンド信号に変換する（Ｃｏｎｖｅｒｔ）。１つ以上の送受信機１０６，２０６は１つ以上のプロセッサ１０２，２０２を用いて処理されたユーザデータ、制御情報、無線信号／チャネルなどをベースバンド信号からＲＦバンド信号に変換する。このために、１つ以上の送受信機１０６，２０６は（アナログ）オシレーター及び／又はフィルターを含む。
【０６７３】
図１８は本発明に適用される無線機器の他の例を示す。無線機器は使用例／サービスによって様々な形態で具現化される（図１６を参照）。
【０６７４】
図１８を参照すると、無線機器１００，２００は図１７の無線機器１００，２００に対応し、様々な要素（ｅｌｅｍｅｎｔ）、部品（ｃｏｍｐｏｎｅｎｔ）、ユニット／部及び／又はモジュールで構成される。例えば、無線機器１００，２００は通信部１１０、制御部１２０、メモリ部１３０及び追加要素１４０を含む。通信部は通信回路１１２及び送受信機１１４を含む。例えば、通信回路１１２は図１７における１つ以上のプロセッサ１０２，２０２及び／又は１つ以上のメモリ１０４，２０４を含む。例えば、送受信機１１４は図１７の１つ以上の送受信機１０６，２０６及び／又は１つ以上のアンテナ１０８，２０８を含む。制御部１２０は通信部１１０、メモリ部１３０及び追加要素１４０に電気的に連結され、無線機器の諸般の動作を制御する。例えば、制御部１２０はメモリ部１３０に格納されたプログラム／コード／命令／情報に基づいて無線機器の電気的／機械的動作を制御する。また制御部１２０はメモリ部１３０に格納された情報を通信部１１０により外部（例えば、他の通信機器）に無線／有線インターフェースにより送信するか、又は通信部１１０により外部（例えば、他の通信機器）から無線／有線インターフェースにより受信された情報をメモリ部１３０に格納する。
【０６７５】
追加要素１４０は無線機器の種類によって様々に構成される。例えば、追加要素１４０はパワーユニット／バッテリー、入出力部（Ｉ／Ｏ  ｕｎｉｔ）、駆動部及びコンピュータ部のうち、いずれか１つを含む。これに限られないが、無線機器はロボット（図１６、１００ａ）、車両（図１６、１００ｂ−１、１００ｂ−２）、ＸＲ機器（図１６、１００ｃ）、携帯機器（図１６、１００ｄ）、家電（図１６、１００ｅ）、ＩｏＴ機器（図１６、１００ｆ）、デジタル放送用端末、ホログラム装置、公共安全装置、ＭＴＣ装置、医療装置、フィンテック装置（又は金融装置）、保安装置、気候／環境装置、ＡＩサーバ／機器（図１６、４００）、基地局（図１６、２００）及びネットワークノードなどの形態で具現化される。無線機器は使用例／サービスによって移動可能であるか、又は固定した場所で使用される。
【０６７６】
図１８において、無線機器１００，２００内の様々な要素、部品、ユニット／部及び／又はモジュールは全体が有線インターフェースにより互いに連結されるか、又は少なくとも一部が通信部１１０により無線連結される。例えば、無線機器１００，２００内で制御部１２０と通信部１１０は有線連結され、制御部１２０と第１ユニット（例えば、１３０、１４０）は通信部１１０により無線連結される。また無線機器１００，２００内の各要素、部品、ユニット／部及び／又はモジュールは１つ以上の要素をさらに含む。例えば、制御部１２０は１つ以上のプロセッサの集合で構成される。例えば、制御部１２０は通信制御プロセッサ、アプリケーションプロセッサ（Ａｐｐｌｉｃａｔｉｏｎ  ＰＲＯＣＥＳＳＯＲ）、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ  ｃｏｎｔｒｏｌ  Ｕｎｉｔ）、グラフィック処理プロセッサ、メモリ制御プロセッサなどの集合で構成される。他の例として、メモリ部１３０はＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ  ＲＡＭ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、フラッシュメモリ（ｆｌａｓｈ  Ｍｅｍｏｒｙ）、揮発性メモリ（ｖｏｌａｔｉｌｅ  Ｍｅｍｏｒｙ）、非揮発生メモリ及び／又はこれらの組み合わせで構成される。
【０６７７】
図１９は本発明に適用される車両又は自律走行車両を例示する図である。車両又は自律走行車両は移動型ロボット、車両、電車、有人／無人飛行体（Ａｅｒｉａｌ  Ｖｅｈｉｃｌｅ、ＡＶ）、船舶などで具現化される。
【０６７８】
図１９を参照すると、車両又は自律走行車両１００はアンテナ部１０８、通信部１１０、制御部１２０、駆動部１４０ａ）、電源供給部１４０ｂ、センサ部１４０ｃ及び自律走行部１４０ｄを含む。アンテナ部１０８は通信部１１０の一部で構成される。ブロック１１０／１３０／１４０ａ〜１４０ｄは各々図１８におけるブロック１１０／１３０／１４０に対応する。
【０６７９】
通信部１１０は他の車両、基地局（例えば、基地局、路辺基地局（Ｒｏａｄ  Ｓｉｄｅ  ｕｎｉｔ）など）、サーバなどの外部機器と信号（例えば、データ、制御信号など）を送受信する。制御部１２０は車両又は自律走行車両１００の要素を制御して様々な動作を行う。制御部１２０はＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ  ｃｏｎｔｒｏｌ  Ｕｎｉｔ）を含む。駆動部１４０ａにより車両又は自律走行車両１００が地上で走行する。駆動部１４０ａはエンジン、モータ、パワートレイン、車輪、ブレーキ、ステアリング装置などを含む。電源供給部１４０ｂは車両又は自律走行車両１００に電源を供給し、有線／無線充電回路、バッテリーなどを含む。センサ部１４０ｃは車両状態、周辺環境情報、ユーザ情報などを得ることができる。センサ部１４０ｃはＩＭＵ（ｉｎｅｒｔｉａｌ  ｍｅａｓｕｒｅｍｅｎｔ  ｕｎｉｔ）センサ、衝突センサ、ホイールセンサ（ｗｈｅｅｌ  ｓｅｎｓｏｒ）、速度センサ、傾斜センサ、重量感知センサ、ヘッディングセンサ（ｈｅａｄｉｎｇ  ｓｅｎｓｏｒ）、ポジションモジュール（ｐｏｓｉｔｉｏｎ  ｍｏｄｕｌｅ）、車両前進／後進センサ、バッテリーセンサ、燃料センサ、タイヤセンサ、ステアリングセンサ、温度センサ、湿度センサ、超音波センサ、照度センサ、ペダルポジションセンサなどを含む。自律走行部１４０ｄは走行中の車線を維持する技術、車間距離制御装置（ａｄａｐｔｉｖｅ  ｃｒｕｉｓｅ  ｃｏｎｔｒｏｌ）のように速度を自動に調節する技術、所定の経路によって自動走行する技術、目的地が設定されると自動に経路を設定して走行する技術などを具現化する。
【０６８０】
一例として、通信部１１０は外部サーバから地図データ、交通情報データなどを受信する。自律走行部１４０ｄは得られたデータに基づいて自律走行経路とドライブプランを生成する。制御部１２０はドライブプランに従って車両又は自律走行車両１００が自律走行経路に移動するように駆動部１４０ａを制御する（例えば、速度／方向調節）。通信部１１０は自律走行中に外部サーバから最新交通情報データを非周期的に得る、また、周りの車両から周りの交通情報データを得る。またセンサ部１４０ｃは自律走行中に車両状態、周辺環境情報を得る。自律走行部１４０ｄは新しく得たデータ／情報に基づいて自律走行経路とドライブプランを更新する。通信部１１０は車両位置、自律走行経路、ドライブプランなどに関する情報を外部サーバに伝達する。外部サーバは車両又は自律走行車両から集められた情報に基づいて、ＡＩ技術などを用いて交通情報データを予め予測し、予測された交通情報データを車両又は自律走行車両に提供することができる。
【０６８１】
以上の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、別に明示しない限り、選択的なものとして考慮され得る。各構成要素又は特徴は、他の構成要素や特徴と結合しない形態で実施されてもよく、また、一部の構成要素及び／又は特徴は結合されて本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は、他の実施例に含まれてもよく、他の実施例の対応する構成又は特徴に代えてもよい。また、特許請求の範囲で明示的な引用関係を有しない請求項を結合して実施例を構成したり、出願後の補正によって新たな請求項として含むことができる。
【０６８２】
本発明は、本発明の特徴を逸脱しない範囲で他の特定の形態に具体化できることは当業者にとって自明である。よって、前記の詳細な説明は、全ての面で制限的に解釈してはならなく、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的解釈によって決定しなければならず、本発明の等価的範囲内での全ての変更は本発明の範囲に含まれる。
【産業上の利用可能性】
【０６８３】
本発明は無線移動通信システムの端末機、基地局又はその他の装備に使用できる。
【図１】
2021506195.tif 000009
【図２】
2021506195.tif 000010
【図３】
2021506195.tif 000011
【図４】
2021506195.tif 000012
【図５】
2021506195.tif 000013
【図６】
2021506195.tif 000014
【図７】
2021506195.tif 000015
【図８】
2021506195.tif 000016
【図９】
2021506195.tif 000017
【図１０】
2021506195.tif 000018
【図１１】
2021506195.tif 000019
【図１２】
2021506195.tif 000020
【図１３】
2021506195.tif 000021
【図１４】
2021506195.tif 000022
【図１５】
2021506195.tif 000023
【図１６】
2021506195.tif 000024
【図１７】
2021506195.tif 000025
【図１８】
2021506195.tif 000026
【図１９】
2021506195.tif 000027
【手続補正書】
【提出日】令和2年6月3日(2020.6.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システムにおいて通信装置が制御情報を送信する方法であって、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信する段階と、
（ｉ）前記ＰＤＳＣＨと（ｉｉ）複数のＵＬ（uplink）チャネルのうち最も早いものとの間で、基準時間間隔以上の時間間隔に基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化する段階と、を含み、
前記複数のＵＬチャネルは、時間軸上でオーバーラップし、かつ、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、
前記基準時間間隔は、シンボルの数とＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記ＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小のものを含む、方法。
【請求項２】
前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小のものより大きい、請求項１に記載の方法。
【請求項３】
前記応答情報を含むＵＣＩは、前記基準時間間隔以上の前記時間間隔に基づいて、一つのＵＬチャネルで多重化及び送信され、
前記基準時間間隔未満の前記時間間隔に基づいて、
前記応答情報は、多重化されずに前記第１ＵＬチャネルで送信される、又は、
前記複数のＵＬチャネル送信の全ては、省略される、請求項１に記載の方法。
【請求項４】
前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと、（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項１に記載の方法。
【請求項５】
前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項１に記載の方法。
【請求項６】
ＰＤＣＣＨ（Physical Downlink Control Channel）によりスケジュールされたＰＵＳＣＨ（Physical Uplink Shared Channel）を含む前記複数のＵＬチャネルに基づいて、前記ＵＣＩは、（ｉ）前記ＰＤＣＣＨと（ｉｉ）前記最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔以上のとき、前記ＰＵＳＣＨにさらに多重化される、請求項１に記載の方法。
【請求項７】
シンボルの長さは、ＳＣＳに基づいて決定され、
前記シンボルの長さ及び前記ＳＣＳは、互いに反比例する、請求項１に記載の方法。
【請求項８】
無線通信システムに使用される通信装置であって、
メモリと、
プロセッサと、を含み、
前記プロセッサは、
ＰＤＳＣＨ（Physical Downlink Shared Channel）を受信し、
（ｉ）前記ＰＤＳＣＨと（ｉｉ）複数のＵＬ（uplink）チャネルのうち最も早いものとの間で、基準時間間隔以上の時間間隔に基づいて、前記複数のＵＬチャネルに関連するＵＣＩ（Uplink Control Information）を多重化するように構成され、
前記複数のＵＬチャネルは、時間軸上でオーバーラップし、かつ、前記ＰＤＳＣＨに関する応答情報のための第１ＵＬチャネルを含み、
前記基準時間間隔は、シンボルの数とＳＣＳ（Subcarrier Carrier Spacing）とに基づいて決定され、
前記ＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小のものを含む、通信装置。
【請求項９】
前記最も早いＵＬチャネルのＳＣＳは、前記複数のＵＬチャネルに対する複数のＳＣＳのうちの最小のものより大きい、請求項８に記載の通信装置。
【請求項１０】
前記応答情報を含むＵＣＩは、前記基準時間間隔以上の前記時間間隔に基づいて、一つのＵＬチャネルで多重化及び送信され、
前記基準時間間隔未満の前記時間間隔に基づいて、
前記応答情報は、多重化されずに前記第１ＵＬチャネルで送信される、又は、
前記複数のＵＬチャネル送信の全ては、省略される、請求項８に記載の通信装置。
【請求項１１】
前記時間間隔は、（ｉ）前記ＰＤＳＣＨの最後のシンボルと、（ｉｉ）前記最も早いＵＬチャネルの１番目のシンボルとの間隔に基づいて決定される、請求項８に記載の通信装置。
【請求項１２】
前記複数のＵＬチャネルは、ＰＵＣＣＨ（Physical Uplink Control Channel）を含む、請求項８に記載の通信装置。
【請求項１３】
ＰＤＣＣＨ（Physical Downlink Control Channel）によりスケジュールされたＰＵＳＣＨ（Physical Uplink Shared Channel）を含む前記複数のＵＬチャネルに基づいて、前記ＵＣＩは、（ｉ）前記ＰＤＣＣＨと（ｉｉ）前記最も早いＵＬチャネルとの間の時間間隔が追加基準時間間隔以上のとき、前記ＰＵＳＣＨにさらに多重化される、請求項８に記載の通信装置。
【請求項１４】
シンボルの長さは、ＳＣＳに基づいて決定され、
前記シンボルの長さ及び前記ＳＣＳは、互いに反比例する、請求項８に記載の通信装置。
【請求項１５】
前記通信装置は、少なくともＵＥ（user equipment）、ネットワーク及び前記通信装置以外の自律走行車両と通信可能な自律走行車両を含む、請求項８に記載の通信装置。
【国際調査報告】
2021506195.tif 000028
2021506195.tif 000029
2021506195.tif 000030
2021506195.tif 000031