JP7073520B2 - 無線通信システムにおける無線信号の送受信方法及び装置 - Google Patents

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

Info

Publication number
JP7073520B2
JP7073520B2 JP2020549544A JP2020549544A JP7073520B2 JP 7073520 B2 JP7073520 B2 JP 7073520B2 JP 2020549544 A JP2020549544 A JP 2020549544A JP 2020549544 A JP2020549544 A JP 2020549544A JP 7073520 B2 JP7073520 B2 JP 7073520B2
Authority
JP
Japan
Prior art keywords
pucch
uci
resource
transmission
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020549544A
Other languages
English (en)
Other versions
JP2021506195A (ja
Inventor
ソクチョル ヤン
ハンチュン パク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of JP2021506195A publication Critical patent/JP2021506195A/ja
Application granted granted Critical
Publication of JP7073520B2 publication Critical patent/JP7073520B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/0091Signaling for the administration of the divided path
    • H04L5/0094Indication of how sub-channels of the path are allocated
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/0001Arrangements for dividing the transmission path
    • H04L5/0003Two-dimensional division
    • H04L5/0005Time-frequency
    • H04L5/0007Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0044Arrangements for allocating sub-channels of the transmission path allocation of payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0078Timing of allocation
    • H04L5/0082Timing of allocation at predetermined intervals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource
    • H04W72/0453Resources in frequency domain, e.g. a carrier in FDMA
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/12Wireless traffic scheduling
    • H04W72/1263Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H04W72/1268Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows of uplink data flows
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/21Control channels or signalling for resource management in the uplink direction of a wireless link, i.e. towards the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/20Control channels or signalling for resource management
    • H04W72/23Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/38Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は無線通信システムに関し、より具体的には無線信号の送受信方法及び装置に関する。
無線通信システムが音声やデータなどの種々の通信サービスを提供するために広範囲に展開されている。一般に、無線通信システムは利用可能なシステムリソース(帯域幅、伝送パワーなど)を共有して多重使用者との通信を支援することができる多元接続(multiple access)システムである。多元接続システムの例としては、CDMA(code division multiple access)システム、FDMA(frequency division multiple access)システム、TDMA(time division multiple access)システム、OFDMA(orthogonal frequency division multiple access)システム、SC-FDMA(single carrier frequency division multiple access)システムなどがある。
本発明の目的は、無線信号の送受信過程を効率的に行う方法及びそのための装置を提供することにある。
本発明で達成しようとする技術的課題は前記技術的課題に制限されず、言及しなかった他の技術的課題は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。
本発明の一様相において、無線通信システムにおいて通信装置が制御情報を送信する方法であって、PDSCH(Physical Downlink Shared Channel)を受信する段階と、(i)PDSCHと、(ii)時間軸で重畳する複数のUL(Uplink)チャネルのうちの最も早いULチャネルとの間の時間間隔を決定する段階であって、複数のULチャネルはPDSCHに関する応答情報のための第1ULチャネルを含む、段階と、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のULチャネルに関連するUCI(Uplink Control Information)を多重化する段階と、を含み、基準時間間隔はシンボルの数とSCS(Subcarrier Carrier Spacing)とに基づいて決定され、SCSは複数のULチャネルに対する複数のSCSのうちの最小値を含む方法が提供される。
本発明の他の様相において、無線通信システムに使用される通信装置であって、メモリとプロセッサとを含み、該プロセッサは、PDSCH(Physical Downlink Shared Channel)を受信し、(i)PDSCHと、(ii)時間軸で重畳する複数のUL(Uplink)チャネルのうちの最も早いULチャネルとの間の時間間隔を決定し、複数のULチャネルはPDSCHに関する応答情報のための第1ULチャネルを含み、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きいことに基づいて、複数のULチャネルに関連するUCI(Uplink Control Information)を多重化するように構成され、基準時間間隔はシンボルの数とSCS(Subcarrier Carrier Spacing)に基づいて決定され、SCSは複数のULチャネルに対する複数のSCSのうちの最小値を含む通信装置が提供される。
好ましくは、最も早いULチャネルのSCSは、複数のULチャネルに対する複数のSCSのうちの最小値より大きい。
好ましくは、時間間隔が基準時間間隔と等しい又は基準時間間隔より大きい場合、応答情報を含むUCIは一つのULチャネルに多重化されて送信され、時間間隔が基準時間間隔より小さい場合、応答情報は多重化されず第1ULチャネルを介して送信される、又は、複数のULチャネル送信は全て省略される。
好ましくは、時間間隔は、(i)PDSCHの最後のシンボルと、(ii)最も早いULチャネルの1番目のシンボルとの間隔に基づいて決定される。
好ましくは、複数のULチャネルはPUCCH(Physical Uplink Control Channel)を含む。
好ましくは、複数のULチャネルがPDCCH(Physical Downlink Control Channel)によりスケジュールされたPUSCH(Physical Uplink Shared Channel)を含む場合、(i)PDCCHと(ii)最も早いULチャネルとの間の時間間隔が追加基準時間間隔を満たすか否かをさらに確認することを含む。
好ましくは、シンボルの長さはSCSに基づいて決定され、シンボルの長さとSCSは反比例する。
好ましくは、通信装置は少なくとも端末、ネットワーク及び通信装置以外の他の自律走行車両と通信可能な自律走行車両を含む。
好ましくは、さらに通信装置はRF(Radio Frequency)ユニットを含む。
本発明によれば、無線通信システムにおいて無線信号の送受信を効率的に行うことができる。
本発明で得られる効果は以上で言及した効果に制限されず、言及しなかった他の効果は下記の記載から本発明が属する技術分野で通常の知識を有する者に明らかに理解可能であろう。
本発明に関する理解を助けるために詳細な説明の一部として含まれる添付図面は本発明の実施例を提供し、詳細な説明とともに本発明の技術的思想を説明する。
無線通信システムの一例である3GPPシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。 無線フレームの構造を例示する図である。 スロットのリソースグリッドを例示する図である。 ACK/NACK送信過程を例示する図である。 PUSCH(Physical Uplink Shared Channel)送信過程を例示する図である。 制御情報をPUSCHに多重化する例を示す図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明による信号送信を例示する図である。 本発明に適用可能な通信システム及び無線機器を例示する図である。 本発明に適用可能な通信システム及び無線機器を例示する図である。 本発明に適用可能な通信システム及び無線機器を例示する図である。 本発明に適用可能な通信システム及び無線機器を例示する図である。
以下の技術は、CDMA(code division multiple access)、FDMA(frequency division multiple access)、TDMA(time division multiple access)、OFDMA(orthogonal frequency division multiple access)、SC-FDMA(single carrier frequency division multiple access)などのような様々な無線アクセスシステムに用いることができる。CDMAは、UTRA(Universal Terrestrial Radio Access)やCDMA2000のような無線技術(radio technology)によって具現化することができる。TDMAは、GSM(Global System for Mobile communications)/GPRS(General Packet Radio Service)/EDGE(Enhanced Data Rates for GSM Evolution)のような無線技術によって具現化することができる。OFDMAは、IEEE 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802-20、E-UTRA(Evolved UTRA)などのような無線技術によって具現化することができる。UTRAは、UMTS(Universal Mobile Telecommunications System)の一部である。3GPP(3rd Generation Partnership Project)LTE(long term evolution)は、E-UTRAを用いるE-UMTS(Evolved UMTS)の一部であり、LTE-Aは3GPP LTEの進化したバージョンである。3GPP NR(New Radio or New Radio Access Technology)は3GPP LTE/LTE-Aの進化したバージョンである。
より多い通信機器がより大きい通信容量を要求することにより、既存の無線アクセス技術(radio Access technology、RAT)に比べて向上した無線広帯域(mobile broadband、eMBB)通信に対する必要性が台頭しつつある。また、複数の機器及びモノを連結していつでもどこでも様々なサービスを提供する大規模MTC(massive Machine Type Communications)が次世代通信において考慮すべき重要なイッシュの一つである。のみならず、信頼度(reliability)及びレイテンシ(latency)に敏感なサービス/UEを考慮したURLLC(Ultra-Reliable and Low Latency Communication)が論議されている。このようにeMBB(enhanced Mobile BroadBand Communication)、大規模MTC、URLLC(Ultra-Reliable and Low Latency Communication)などを考慮した次世代RATの導入が論議されており、本発明では、便宜上、該当技術をNR(New radio又はNew RAT)と呼ぶ。
説明を明確にするために、3GPP NRを主として説明するが、本発明の技術的思想はこれに限られない。
無線通信システムにおいて、端末は基地局から下りリンク(Downlink、DL)を介して情報を受信し、端末は基地局から上りリンク(Uplink、UL)を介して情報を伝送する。基地局と端末が送受信する情報はデータ及び様々な制御情報を含み、これらが送受信する情報の種類/用途によって様々な物理チャネルが存在する。
図1は3GPP NRシステムに用いられる物理チャネル及びこれらを用いた一般的な信号伝送方法を例示する図である。
電源Off状態で電源を入れたか或いは新しくセルに進入した端末は、段階S101において、基地局と同期を確立するなどの初期セルサーチ(Initial cell search)作業を行う。このために、端末は基地局から主同期チャネル(Primary Synchronization Channel、P-SCH)及び副同期チャネル(Secondary Synchronization Channel、S-SCH)を受信して基地局と同期を確立し、セルID(cell identity)などの情報を得る。その後、端末は基地局から物理ブロードキャストチャネル(Physical Broadcast Channel、PBCH)を受信してセル内のブロードキャスト情報を得る。なお、端末は初期セルサーチの段階において、下りリンク参照信号(Downlink Reference Signal、DL RS)を受信して下りリンクチャネルの状態を確認できる。
初期セルサーチが終了した端末は、段階S102において、物理下りリンク制御チャネル(Physical Downlink Control Channel、PDCCH)及び物理下りリンク制御チャネルの情報に基づく物理下りリンク共有チャネル(Physical Downlink Control Channel、PDSCH)を受信して、より具体的なシステム情報を得る。
以後、端末は基地局に接続を完了するために、段階S103乃至段階S106のようなランダムアクセス過程(Random Access Procedure)を行う。このために端末は、物理ランダムアクセスチャネル(Physical Random Access Channel、PRACH)を介してプリアンブル(preamble)を伝送し(S103)、物理下りリンク制御チャネル及びこれに対応する物理下りリンク共有チャネルを介してプリアンブルに対する応答メッセージを受信する(S104)。コンテンションベースのランダムアクセス(Contention based random access)の場合、さらなる物理ランダムアクセスチャネルの伝送(S105)、物理下りリンク制御チャネル及びそれに対応する物理下りリンク共有チャネルの受信(S106)のような競合解決手順(Contention Resolution Procedure)を行う。
このような手順を行った端末は、その後一般的な上り/下りリンク信号の伝送手順として物理下りリンク制御チャネル/物理下りリンク共有チャネルの受信(S107)、及び物理上りリンク共有チャネル(Physical Uplink Shared Channel、PUSCH)/物理上りリンク制御チャネル(Physical Uplink Control Channel、PUCCH)の伝送を行う(S108)。端末が基地局に伝送する制御情報を併せて上りリンク制御情報(Uplink Control Information、UCI)と称する。UCIは、HARQ ACK/NACK(Hybrid Automatic Repeat and reQuest Acknowledgement/Negative-ACK)、SR(Scheduling Request)、CSI(Channel State Information)などを含む。CSIは、CQI(Channel Quality Indicator)、PMI(Precoding Matrix Indicator)、RI(Rank Indication)などを含む。UCIは一般的にPUCCHを介して伝送されるが、制御情報とトラフィックデータが同時に伝送される必要がある場合にはPUSCHを介して伝送される。また、ネットワークの要求/指示によってPUSCHを介してUCIを非周期的に伝送することができる。
図2は無線フレームの構造を例示する図である。NRにおいて、上りリンク及び下りリンク送信はフレームで構成される。無線フレームは10msの長さを有し、2個の5msハーフフレーム(Half-Frame、HF)で定義される。ハーフフレームは5個の1msサブフレーム(Subframe、SF)で定義される。サブフレームは1つ以上のスロットに分割され、サブフレーム内のスロット数はSCS(Subcarrier Spacing)に依存する。各スロットはCP(cyclic prefix)によって12個又は14個のOFDM(A)シンボルを含む。一般CPが使用される場合、各スロットは14個のシンボルを含む。拡張CPが使用される場合は、各スロットは12個のシンボルを含む。
表1は一般CPが使用される場合、SCSによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。
Figure 0007073520000001
*Nslot symb:スロット内のシンボル数
*Nframe,u slot:フレーム内のスロット数
*Nsubframe,u slot:サブフレーム内のスロット数
表2は拡張CPが使用される場合、SCSによってスロットごとのシンボル数、フレームごとのスロット数とサブフレームごとのスロット数が変化することを例示している。
Figure 0007073520000002
フレーム構造は例示に過ぎず、フレームにおいてサブフレーム数、スロット数及びシンボル数は様々に変更できる。
NRシステムでは1つの端末に併合される複数のセル間でOFDMニューマロロジー(numerology)(例えば、SCS)が異なるように設定されることができる。これにより、同じ数のシンボルで構成された時間リソース(例えば、SF、スロット又はTTI)(便宜上、TU(Time Unit)と称する)の(絶対時間)区間が併合されたセル間で異なるように設定されることができる。ここで、シンボルはOFDMシンボル(或いはCP-OFDMシンボル)、SC-FDMAシンボル(或いはDiscrete Fourier Transform-spread-OFDM、DFT-s-OFDMシンボル)を含む。
図3はスロットのリソースグリッド(resource grid)を例示する図である。スロットは時間ドメインで複数のシンボルを含む。例えば、一般CPの場合、1つのスロットが14個のシンボルを含むが、拡張CPの場合は、1つのスロットが12個のシンボルを含む。搬送波は周波数ドメインで複数の副搬送波を含む。RB(Resource Block)は周波数ドメインで複数(例えば、12)の連続する副搬送波で定義される。BWPは周波数ドメインで複数の連続するPRB(Physical RB)で定義され、1つのニューマロロジー(numerology)(例えば、SCS、CPの長さなど)に対応することができる。搬送波は最大N個(例えば、5個)のBWPを含む。データ通信は活性化されたBWPで行われ、1つの端末には1つのBWPのみが活性化される。リソースグリッドにおいて各々の要素はリソースエレメント(Resource Element、RE)と称され、1つの複素シンボルがマッピングされることができる。
以下、各々の物理チャネルについてより詳しく説明する。
PDCCHはDCI(Downlink Control Information)を運ぶ。例えば、PCCCH(即ち、DCI)はDL-SCH(downlink shared channel)の送信フォーマット及びリソースの割り当て、UL-SCH(uplink shared channel)に対するリソース割り当て情報、PCH(Paging Channel)に関するページング情報、DL-SCH上のシステム情報、PDSCH上で送信されるランダムアクセス応答のような上位層制御メッセージに関するリソース割り当て情報、送信電力制御命令、CS(Configured scheduling)の活性化/解除などを運ぶ。DCIはCRC(cyclic redundancy check)を含み、CRCはPDCCHの所有者又は使用用途によって様々な識別子(例えば、Radio Network Temporary Identifier、RNTI)にマスキング/スクランブルされる。例えば、PDCCHが特定の端末のためのものであれば、CRCは端末識別子(例えば、cell-RNTI、C-RNTI)にマスキングされる。PDCCHがページングに関するものであれば、CRCはP-RNTI(Paging-RNTI)にマスキングされる。PDCCHがシステム情報(例えば、System Information Block、SIB)に関するものであれば、CRCはSI-RNTI(System Information RNTI)にマスキングされる。PDCCHがランダムアクセス応答に関するものであれば、CRCはRA-RNTI(Random Access-RNTI)にマスキングされる。
PDSCHは下りリンクデータ(例、DL-SCH transport block、DL-SCH TB)を運び、QPSK(Quadrature Phase Shift Keying)、16QAM(Quadrature Amplitude Modulation)、64QAM、256QAMなどの変調方法が適用される。TBを符号化してコードワード(codeword)が生成される。PDSCHは最大2個のコードワードを運ぶ。コードワードごとにスクランブル及び変調マッピングが行われ、各コードワードから生成された変調シンボルは1つ以上のレイヤにマッピングされる。各レイヤはDMRS(Demodulation Reference Signal)と共にリソースにマッピングされてOFDMシンボル信号に生成され、該当アンテナポートにより送信される。
PUCCHは、UCI(Uplink Control Information)を運ぶ。UCIは以下を含む。
-SR(Scheduling Request):UL-SCHリソースを要求するために使用される情報である。
-HARQ-ACK:PDSCH上の下りリンクデータパケット(例えば、コードワード)に対する応答である。下りリンクデータパケットが正常に受信されたか否かを示す。単一のコードワードに対する応答としてHARQ-ACK 1ビットが送信され、2個のコードワードに対する応答としてHARQ-ACK 2ビットが送信される。HARQ-ACK応答は、ポジティブACK(簡単に、ACK)、ネガティブACK(以下、NACK)、DTX(Discontinuous Transmission)又はNACK/DTXを含む。ここで、HARQ-ACKという用語は、HARQ ACK/NACK、ACK/NACKと同じ意味で使われる。
-CSI(Channel State Information):下りリンクチャンネルに対するフィードバック情報である。MIMO(Multiple Input Multiple Output)-関連フィードバック情報は、RI(Rank Indicator)及びPMI(Precoding Matrix Indicator)を含む。
表3はPUCCHフォーマットを例示する。PUCCH送信の長さによってShort PUCCH(フォーマット0,2)及びLong PUCCH(フォーマット1,3,4)に区分できる。
Figure 0007073520000003
PUCCHフォーマット0は最大2ビットサイズのUCIを運び、シーケンスに基づいてマッピングされて送信される。具体的には、端末は複数のシーケンスのうちの1つのシーケンスをPUCCHフォーマット0であるPUCCHを介して送信して特定のUCIを基地局に送信する。端末は肯定(positive)のSRを送信する場合のみに対応するSR設定のためのPUCCHリソース内でPUCCHフォーマット0であるPUCCHを送信する。
PUCCHフォーマット1は最大2ビットサイズのUCIを運び、変調シンボルは時間領域で(周波数ホッピング有無によって異なるように設定される)直交カバーコード(OCC)により拡散される。DMRSは変調シンボルが送信されないシンボルで送信される(即ち、TDM(Time Division Multiplexing)されて送信される)。
PUCCHフォーマット2は2ビットより大きいビットサイズのUCIを運び、変調シンボルはDMRSとFDM(Frequency Division Multiplexing)されて送信される。DM-RSは1/3の密度のリソースブロック内のシンボルインデックス#1、#4、#7及び#10に位置する。PN(Pseudo Noise)シーケンスがDM_RSシーケンスのために使用される。2シンボルPUCCHフォーマット2のために周波数ホッピングが活性化されることができる。
PUCCHフォーマット3は同一の物理リソースブロック内において端末多重化が行われず、2ビットより大きいビットサイズのUCIを運ぶ。即ち、PUCCHフォーマット3のPUCCHリソースは直交カバーコードを含まない。変調シンボルはDMRSとTDM(Time Division Multiplexing)されて送信される。
PUCCHフォーマット4は同一の物理リソースブロック内に最大4個の端末まで多重化が支援され、2ビットより大きいビットサイズのUCIを運ぶ。即ち、PUCCHフォーマット3のPUCCHリソースは直交カバーコードを含む。変調シンボルはDMRSとTDM(Time Division Multiplexing)されて送信される。
PUSCHは上りリンクデータ(例えば、UL-SCH transport block、UL-SCH TB)及び/又は上りリンク制御情報(UCI)を運び、CP-OFDM(Cyclic Prefix-Orthogonal Frequency Division Multiplexing)波形又はDFT-s-OFDM(Discrete Fourier Transform-spread-Orthogonal Frequency Division Multiplexing)波形に基づいて送信される。PUSCHがDFT-s-OFDM波形に基づいて送信される場合、端末は変換プリコーディング(transform precoding)を適用してPUSCHを送信する。一例として、変換プリコーディングが不可能な場合は(例えば、transform precoding is disabled)、端末はCP-OFDM波形に基づいてPUSCHを送信し、変換プリコーディングが可能な場合には(例えば、transform precoding is enabled)、端末はCP-OFDM波形又はDFT-s-OFDM波形に基づいてPUSCHを送信する。PUSCH送信はDCI内のULグラントにより動的にスケジュールされるか、又は上位層(例えば、RRC)シグナリング(及び/又はLayer 1(L1)シグナリング(例えば、PDCCH))に基づいて準静的(semi-static)にスケジュールされる(configured grant)。PUSCH送信はコードブックベース又は非コードブックベースで行われる。
図4はACK/NACK送信過程を例示する。図4を参照すると、端末はスロット#nでPDCCHを検出する。ここで、PDCCHは下りリンクスケジューリング情報(例えば、DCIフォーマット1_0、1_1)を含み、PDCCHはDL割り当て-to-PDSCHオフセット(K0)とPDSCH-HARQ-ACK報告オフセット(K1)を示す。例えば、DCIフォーマット1_0、1_1は以下の情報を含む。
-Frequency domain resource assignment:PDSCHに割り当てられたRBセットを示す。
-Time domain resource assignment:K0、スロット内のPDSCHの開始位置(例えば、OFDMシンボルインデックス)及び長さ(例:OFDMシンボル数)を示す
-PDSCH-to-HARQ_feedback timing indicator:K1を示す
今後、端末はスロット#nのスケジューリング情報によってスロット#(n+K0)でPDSCHを受信した後、スロット#(n+K1)でPUCCHを介してUCIを送信する。ここで、UCIはPDSCHに対するHARQ-ACK応答を含む。PDSCHが最大1個のTBを送信するように構成された場合、HARQ-ACK応答は1ビットで構成される。PDSCHが最大2個のTBを送信するように構成された場合は、HARQ-ACK応答は空間(spatial)バンドリングが構成されていない場合は、2ビットで構成され、空間バンドリングが構成された場合は、1ビットで構成される。複数のPDSCHに対するHARQ-ACK送信時点がスロット#(n+K1)と指定された場合、スロット#(n+K1)で送信されるUCIは複数のPDSCHに対するHARQ-ACK応答を含む。
図5はPUSCH送信過程を例示する。図5を参照すると、端末はスロット#nでPDCCHを検出する。ここで、PDCCHは上りリンクスケジューリング情報(例えば、DCIフォーマット0_0、0_1)を含む。DCIフォーマット0_0、0_1は以下の情報を含む。
-Frequency domain resource assignment:PUSCHに割り当てられたRBセットを示す。
-Time domain resource assignment:スロットオフセットK2、スロット内のPUSCHの開始位置(例えば、シンボルインデックス)及び長さ(例:OFDMシンボル数)を示す。開始シンボル及び長さはSLIV(Start and Length Indicator Value)により指示されるか、又は各々指示される。
以後、端末はスロット#nのスケジューリング情報によってスロット#(n+K2)でPUSCHを送信する。ここで、PUSCHはUL-SCH TBを含む。
図6はUSIをPUSCHに多重化する例を示す。スロット内で複数のPUCCHリソースとPUSCHリソースが重畳し、PUCCH-PUSCH同時送信が設定されていない場合、UCIは、図示したように、PUSCHを介して送信される(UCIピギーバック又はPUSCHピギーバック)。図6はHARQ-ACKとCSIがPUSCHリソースに含まれる場合を例示する。
実施例:ULチャネルの多重化
NRシステムでは、単一の物理ネットワーク上に複数の論理ネットワークを具現化する方法が考えられている。ここで、論理ネットワークは様々な要求条件を有するサービス(例えば、eMBB、mMTC、URLLCなど)を支援する必要がある。従って、NRの物理層は様々なサービスに対する要求条件を考えて柔軟な送信構造を支援するように設計されている。一例として、NRの物理層は必要によってOFDMシンボルの長さ(OFDMシンボル区間)及び副搬送波間隔(SCS)(以下、OFDMニューマロロジー)を変更することができる。また物理チャネルの送信リソースも(シンボル単位で)一定範囲内で変更可能である。例えば、NRにおいて、PUCCH(リソース)とPUSCH(リソース)は送信の長さ/送信開始時点が一定範囲内で柔軟に設定される。
一方、基地局と端末で構成された無線通信システムにおいて、端末がUCIをPUCCHを介して送信するとき、PUCCHリソースが時間軸で他のPUCCHリソース或いはPUSCHリソースと重畳することができる。例えば、同じ端末の観点で(同じスロット内で)、(1)(互いに異なるUCI送信のための)PUCCH(リソース)とPUCCH(リソース)、或いは(2)PUCCH(リソース)とPUSCH(リソース)が時間軸で重畳することができる。一方、端末は(端末能力の制限、又は基地局からの設定情報によって)PUCCH-PUCCH同時送信或いはPUCCH-PUSCH同時送信を支援しないことができる。この場合、端末は、(1)互いに異なるUCI、或いは(2)UCIとULデータを最大限多重化して送信することが好ましい。しかし、NRシステムでは、(スロット内の)時間軸で重畳した(1)PUCCH(リソース)とPUCCH(リソース)、或いは(2)PUCCH(リソース)とPUSCH(リソース)の間に送信の長さ(例えば、シンボル数)及び/又は送信開始時点(例えば、開始シンボル)が異なることができる。従って、端末の処理時間の観点で、端末が(1)互いに異なるUCI、或いは(2)UCIとULデータを多重化して送信することが難しい場合がある。例えば、A/Nを送信するPUCCH(以下、A/N PUCCH)とSRを送信するPUCCH(以下、SR PUCCH)が時間軸で(一部或いは全部)重畳することができる。この場合、端末がSR PUCCHに対する送信を既に開始したか又は送信準備を完了した後、SR PUCCHと重畳するA/N PUCCHの存在を認知すると、端末はA/N PUCCH内のA/NをSRと多重化して送信することが難しい。
既存のNRシステムでは、A/N PUCCHリソースとSR PUCCHリソースが時間軸で完全に重畳した場合(即ち、送信区間が一致)、A/N PUCCHのPUCCHフォーマットによって以下のようにUCI多重化規定を適用する。Positive SRは端末が送信するULデータがあることを意味し、negative SRは端末が送信するULデータがないことを意味する。
(1)A/N PUCCHがPUCCHフォーマット0である場合
A.SRに対するUCI状態がPositive SRである場合
-A/NをA/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースを介して送信
B.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
(2)A/N PUCCHがPUCCHフォーマット1である場合
A.SRに対するUCI状態がPositive SRである場合
-A/NをSR PUCCHリソースを介して送信
B.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
(3)A/N PUCCHがPUCCHフォーマット2/3/4のうちの1つである場合
A.SRに対するUCI状態がPositive SR又はnegative SRである場合
-SRを明示的ビットで表現してA/Nに付け加えて(Appending)UCIペイロードを生成後、生成されたUCIをA/N PUCCHリソースを介して送信
しかし、既存の方法では、A/N PUCCHリソースとSR PUCCHリソースが時間軸で完全に重畳する場合に限ってUCI多重化方法を定義している。よって、効率的なUCI送信のために、様々な状況を考えてUCI多重化方法を論議する必要がある。
上記問題を解決するために、本発明では時間軸で重畳したULチャネルに対するUCI及び/又はデータを多重化する動作を提案する。具体的には、本発明ではULチャネルの送信開始時点及び/又は端末の処理時間を考えてULチャネルに対するUCI及び/又はデータを多重化する動作を提案する。
まず、以下のように用語を定義する。
-UCI:端末がUL送信する制御情報を意味する。UCIは複数のタイプの制御情報(即ち、UCIタイプ)を含む。例えば、UCIはHARQ-ACK(簡単に、A/N、AN)、SR、CSIを含む。
-PUCCH:UCI送信のための物理層ULチャネルを意味する。便宜上、A/N、SR、CSI送信のために、基地局が設定した及び/又は送信を指示したPUCCHリソースを各々A/N PUCCHリソース、SR PUCCHリソース、CSI PUCCHリソースと呼ぶ。
-PUSCH:ULデータ送信のための物理層ULチャネルを意味する。
-UCI多重化(multiplexing):互いに異なるUCI(タイプ)を共通の物理層ULチャネル(例えば、PUCCH、PUSCH)を介して送信する動作を意味する。UCI多重化は、互いに異なるUCI(タイプ)を多重化する動作を含む。便宜上、多重化されたUCIをMUX UCIと称する。またUCI多重化はMUX UCIに関連して行われる動作を含む。例えば、UCI多重化はMUX UCIを送信するためにULチャネルリソースを決定する過程を含む。
-UCI/データ多重化:UCIとデータを共通の物理層ULチャネル(例えば、PUSCH)により送信する動作を意味する。UCI/データ多重化はUCIとデータを多重化する動作を含む。便宜上、多重化されたUCIをMUX UCI/Dataと称する。またUCI/データの多重化はMUX UCI/Dataに関連して行われる動作を含む。例えば、UCI/データの多重化はMUX UCI/Dataを送信するためにULチャネルリソースを決定する過程を含む。
-スロット:データスケジューリングのための基本時間単位(time unit(TU)又はtime interval)を意味する。スロットは複数のシンボルを含む。ここで、シンボルはOFDMベースのシンボルを含む(例えば、CP-OFDMシンボル、DFT-s-OFDMシンボル)。この明細書において、シンボル、OFDMベースのシンボル、OFDMシンボル、CP-OFDMシンボル及びDFT-s-OFDMシンボルは互いに代替することができる。
-重畳したULチャネルリソース:所定の時間区間(例えば、スロット)内で時間軸で(少なくとも一部が)重畳したULチャネル(例えば、PUCCH、PUSCH)リソースを意味する。重畳したULチャネルリソースはUCI多重化を行う前のULチャネルリソースを意味する。
PUCCHフォーマットはUCIペイロードサイズ及び/又は送信の長さ(例えば、PUCCHリソースを構成するシンボル数)によって以下のように区分される。PUCCHフォーマットに関する事項は表3を参照できる。
(0)PUCCHフォーマット0(PF0、F0)
-支援可能なUCIペイロードサイズ:最大Kビットまで(例えば、K=2)
-単一のPUCCHを構成するOFDMシンボル数:1~Xシンボル(例えば、X=2)
-送信構造:DM-RS無しにUCI信号のみで構成され、複数のシーケンスのうちの1つを選択及び送信することによりUCI状態を送信
(1)PUCCHフォーマット1(PF1、F1)
-支援可能なUCIペイロードサイズ:最大Kビットまで(例えば、K=2)
-単一のPUCCHを構成するOFDMシンボル数:Y~Zシンボル(例えば、Y=4、Z=14)
-送信構造:DM-RSとUCIが互いに異なるOFDMシンボルにTDM形態で構成され、UCIは特定のシーケンスに変調(例えば、QPSK)シンボルを乗ずる形態。UCIとDM-RSに全てCS(Cyclic Shift)/OCC(Orthogonal Cover Code)を適用して、(同じRB内で)(PUCCHフォーマット1に従う)複数のPUCCHリソースの間でCDMを支援
(2)PUCCHフォーマット2(PF2、F2)
-支援可能なUCIペイロードサイズ:Kビットを超える(例えば、K=2)
-単一のPUCCHを構成するOFDMシンボル数:1~Xシンボル(例えば、X=2)
-送信構造:DMRSとUCIが同じシンボル内でFDM形態で構成/マッピングされ、符号化されたUCIビットにDFT無しにIFFTのみを適用して送信される構造
(3)PUCCHフォーマット3(PF3、F3)
-支援可能なUCIペイロードサイズ:Kビットを超える(例えば、K=2)
-単一のPUCCHを構成するOFDMシンボル数:Y~Zシンボル(例えば、Y=4、Z=14)
-送信構造:DMRSとUCIが互いに異なるシンボルにTDM形態で構成/マッピングされ、符号化されたUCIビットにDFTを適用して送信する形態。UCIにはDFTの前端でOCCを適用し、DMRSにはCS(又はIFDMマッピング)を適用して複数の端末に多重化を支援
(4)PUCCHフォーマット4(PF4、F4)
-支援可能なUCIペイロードサイズ:Kビットを超える(例えば、K=2)
-単一のPUCCHを構成するOFDMシンボル数:Y~Zシンボル(例えば、Y=4、Z=14)
-送信構造:DMRSとUCIが互いに異なるシンボルにTDM形態で構成/マッピングされ、符号化されたUCIビットにDFTを適用して端末間の多重化無しに送信される構造
UCIタイプ(例えば、A/N、SR、CSI)ごとにPUCCHリソースが決定される。UCI送信に使用されるPUCCHリソースはUCI(ペイロード)サイズに基づいて決定される。一例として、基地局は端末に複数のPUCCHリソースセットを設定し、端末はUCI(ペイロード)サイズ(例えば、UCIビット数)の範囲によって、特定の範囲に対応する特定のPUCCHリソースセットを選択する。例えば、端末はUCIビット数(NUCI)によって、以下のうちのいずれか1つのPUCCHリソースセットを選択することができる。
-PUCCHリソースセット#0、UCIビット数≦2であると、
-PUCCHリソースセット#1、2<UCIビット数≦N1であると、
...
-PUCCHリソースセット#(K-1)、NK-2<UCIビット数≦NK-1であると、
ここで、KはPUCCHリソースセット数を示し(K>1)、NiはPUCCHリソースセット#iが支援する最大のUCIビット数である。例えば、PUCCHリソースセット#1はPUCCHフォーマット0~1のリソースで構成され、それ以外のPUCCHリソースセットはPUCCHフォーマット2~4のリソースで構成される(表3を参照)。
UCIタイプがSR、CSIである場合、PUCCHリソースセット内でUCI送信に活用するPUCCHリソースは上位層シグナリング(例えば、RRCシグナリング)により設定される。UCIタイプがSPS(Semi-Persistent Scheduling)PDSCHに対するHARQ-ACKである場合、PUCCHリソースセット内でUCI送信に活用するPUCCHリソースは上位層シグナリング(例えば、RRCシグナリング)により設定される。反面、UCIタイプが普通のPDSCH(即ち、DCIによりスケジュールされたPDSCH)に対するHARQ-ACKである場合は、PUCCHリソースセット内でUCI送信に活用するPUCCHリソースはDCIに基づいてスケジュールされる。
DCIベースのPUCCHリソーススケジューリングの場合、基地局は端末にPDCCHを介してDCIを送信し、DCI内のARI(ACK/NACK Resource Indicator)により特定のPUCCHリソースセット内でUCI送信に活用するPUCCHリソースを指示する。ARIはACK/NACK送信のためのPUCCHリソースを指示するために使用され、PRI(PUCCH Resource Indicator)とも呼ばれる。ここで、DCIはPDSCHスケジューリングに使用されるDCIであり、UCIはPDSCHに対するHARQ-ACKを含む。一方、基地局はARIが表現できる状態(state)の数より多いPUCCHリソースで構成されたPUCCHリソースセットを(端末-特定の)上位層(例えば、RRC)信号により端末に設定する。この時、ARIはPUCCHリソースセット内のPUCCHリソースサブセットを指示し、指示されたPUCCHリソースサブセット内でどのPUCCHリソースを使用するかは、PDCCHに関する送信リソース情報(例えば、PDCCHの開始CCEインデックスなど)に基づく暗黙的な規則(implicit rule)によって決定される。
以下の提案方法は他の提案方法と互いに相反しない限り、共に結合して適用できる。
PUCCH/PUCCH多重化
[提案方法#1]A/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この場合、(基準時点から)特定の時点の前まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳するか否かによって、端末でA/Nと(positive)SRの間の多重化の有無を決定することができる。
但し、端末がA/Nと(positive)SRの間の多重化を行わない場合、A/Nと(positive)SRのうちの一つの送信を省略することができる。
一例として、端末はSR PUCCHの送信開始時点(例えば、開始シンボル)(以下、Tsr)を基準として、T0以前の時点(以下、Tref,sr)まで受信された(又は送信が開始された)PDSCH(又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳するか否かによって、A/Nと(positive)SRの間の多重化の有無を決定することができる。Tref,sr=Tsr-T0と定義され、OFDMシンボル単位で表現することができる。
(ケース1)Tref,srまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳する場合、端末はA/Nと(positive)SRを多重化して送信することができる(又はA/N PUCCHとSR PUCCHが時間軸でPUCCH内の全てのシンボルが完全に重畳する場合と同じUCI多重化規則に従うことができる)。
(1)A/N PUCCHがPUCCHフォーマット0である場合
A.SRに対するUCI状態がPositive SRである場合
-A/NをA/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースを介して送信
B.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
(2)A/N PUCCHがPUCCHフォーマット1である場合
A.SRに対するUCI状態がPositive SRである場合
-A/NをSR PUCCHリソースを介して送信。但し、SR PUCCHがPUCCHフォーマット0である場合には、SRを送信せず、A/Nのみを送信することができる。
B.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
(3)A/N PUCCHがPUCCHフォーマット2/3/4のうちの1つである場合
A.SRに対するUCI状態がPositive SR又はnegative SRである場合
-SRを明示的ビットで表現してA/Nに付け加えて(Appending)UCIペイロードを生成後、生成されたUCIをA/N PUCCHリソースを介して送信
(ケース2)(ケース1)に該当しない場合、端末はA/Nと(positive)SRのうちの1つを選択して送信することができる。例えば、(i)Tref,sr時点後に受信された(又は送信が開始/終了した)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳するか、(ii)Tref,srまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳しないか、又は(iii),srまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが存在しない場合、端末はA/Nと(positive)SRのうちの1つを選択して送信することができる。
(1)SRに対するUCI状態がPositive SRである場合
-SRをSR PUCCHリソースを介して送信(A/N送信を省略)
(2)SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
0は以下のうちの1つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力(capability)によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による復調に必要な端末処理時間又はそれに対応する値
(4)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(5)基地局と端末の間に予め約束した値(例えば、固定値)
[提案方法#1]はA/N PUCCH以外のPUCCHにも拡張して適用できる。
一方、NRシステムでは、A/N PUCCHとSR PUCCHの間の開始(starting)(OFDM)シンボル(或いは開始時間)が一致する場合、A/N PUCCHとSR PUCCHが時間軸で完全に重畳する場合と同一のUCI多重化規則を適用する端末動作が合議されている。反面、A/N PUCCHとSR PUCCHの間の開始(OFDM)シンボルが異なる場合には、A/N PUCCHとSR PUCCHの間の開始(OFDM)シンボル(或いは開始時間)を比較して、A/NとSRの間のUCI多重化の有無を決定する方法が論議されている。例えば、SR PUCCHの開始(OFDM)シンボルがA/N PUCCHの開始(OFDM)シンボルより先立つ場合、端末はSR PUCCHを送信し、A/N送信を省略する。逆に、SR PUCCHの開始(OFDM)シンボルがA/N PUCCHの開始(OFDM)シンボルより遅れる場合は、端末はSRとA/NをUCI多重化して単一のPUCCHで送信する。この動作は端末がSR送信を準備した後(又はSR送信中)にA/N送信があることを認知した場合、SR送信を取り消し、A/NとSRをUCI多重化して送信する過程が端末の具現化上、容易ではないという点で提案されたものである。しかし、SR PUCCHの開始(OFDM)シンボルがA/N PUCCHの開始(OFDM)シンボルより先立っても、A/N PUCCHに対応するPDSCH(及び/又はPDCCH)の受信時点がしばらく前であると、端末はA/NとSRをUCI多重化して送信することができる。従って、既存の方法は、端末処理時間の観点で端末にA/NとSRの間のUCI多重化を行う余力があっても、A/N送信を省略するという点で好ましくない。
従って、A/NとSRの多重化を支援するために、端末に(i)SR onlyの送信を行うか、又は(ii)SRとA/Nを多重化して送信するかを決定する時点を明示することができる。たとえ、端末は特定のSR PUCCHに対する送信開始時点(Tsr)を基準として、T0以前の時点(Tref,sr)まで受信されたPDSCH(及び/又はPDCCH)に対するA/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳しない場合、Positive SRであれば、SR PUCCHを送信すると決定することができる。この時、端末はTref,sr後に受信されたPDSCH(及び/又はPDCCH)に対するA/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳しても、A/N送信を省略し、SR PUCCH送信を行うことができる。反面、Tref,srまで受信されたPDSCH(及び/又はPDCCH)に対するA/N PUCCHリソースがSR PUCCHリソースと時間軸で重畳する場合は、端末は(i)SR情報がpositive SRであれば、A/NとSRをUCI多重化して単一のPUCCHリソースを介して送信し、(ii)SR情報がnegative SRであれば、A/NのみをA/N PUCCHを介して送信するか、又はnegative SRを表現する明示的ビットをA/Nに付け加えてA/N PUCCHを介して送信することができる。
一方、端末は今後A/N PUCCHリソースがSR PUCCHと重畳しないように更新されてもA/NとSRをUCI多重化すると予め決定したので、決定を翻さず、相変わらずUCI多重化されたA/NとSRを単一のPUCCHリソースを介して送信することができる。
図7はA/N PUCCHがPUCCHフォーマット0/2/3/4である場合の動作を例示する。図8はA/N PUCCHがPUCCHフォーマット1である場合の動作を例示する。
[提案方法#1]は、端末がTref,sr(即ち、Tsr-To)前に終了した/受信したPDSCH(及び/又はPDCCH)に対応するA/N PUCCHについてはSR PUCCHに対する送信を確定する前に存在の有無を把握できるという仮定を前提とする。即ち、[提案方法#1]は、Tref,SR後に終了したPDSCH(及び/又はPDCCH)については端末がSR PUCCHに対する送信を確定する前に把握することが難しいと判断し、A/NとSRの多重化を判断する時に参照しない。[提案方法#1]によれば、端末はTref,SR前に終了した/受信したPDSCH(及び/又はPDCCH)に対応するA/N PUCCHがSR PUCCHと時間軸で重畳すると、A/NとSRを共に多重化して送信することができる。A/N PUCCHがSR PUCCHと時間軸で重畳しないか又は存在しないと、SRのみを送信することができるので、端末の具現化が容易である。また、[提案方法#1]は、ほとんどの場合にA/NとSRが多重化されるようにすることにより、A/N又はSR送信が省略される場合を減らす効果がある。また[提案方法#1]は、A/NとSRが多重化されてSR PUCCHで送信される場合、(例えば、A/N PUCCHがF1であり、SR PUCCHもF1である場合にも)A/N送信に対する最小のPDSCH-to-HARQ-ACK送信処理時間を保証して、できる限り単一化された解決策を提示するという長所がある。もし一つのスロット内に互いに区分される複数のSR PUCCHが設定された場合は、端末はスロット内の先立つSR PUCCHに対してA/Nとの多重化の有無を判断した後、A/N送信が省略されないと、次のSR PUCCHとA/Nとの多重化の有無を判断するように順に動作を適用することができる。
[提案方法#1]の変形として、Tref,sr(即ち、Tsr-To)まで送信が開始されたPDSCH(及び/又はPDCCH)に対応するA/N PUCCHがSR PUCCHと重畳する場合には、A/NとSRに対する多重化を行い、そうではない場合には、SRのみを送信する。この動作は、(A/N PUCCHに対応する)PDSCH(及び/又はPDCCH)の送信開始時点がTref,srより先立つ(又は同一である)場合、端末が該当PDSCHに対応するPDCCH(例えば、DL割り当て)を検出及び復調する時間が十分であり、SR PUCCHに対する送信を確定する前に該当SR PUCCHと衝突するA/N PUCCHが存在することを認知できるという仮定を前提とする。従って、(A/N PUCCHに対応する)PDSCH(及び/又はPDCCH)の送信開始時点がTref,srより遅れる場合は、該当PDSCHに対応するPDCCH(例えば、DL割り当て)を検出及び復調する時間が十分でないので、端末は該当PDSCHについてはA/NとSRに対する多重化の有無を判断する時に反映されない。
[提案方法#1]の変形として、端末が送信しようとするA/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の一部OFDMシンボルに対して)重畳した場合、A/N PUCCHリソースに対応するPDSCH(及び/又はPDCCH)の送信終了(或いは開始)時点とSR PUCCHの送信開始時点の間の相対的な関係によって、A/Nと(positive)SRの間の多重化の有無を決定する方法を考慮できる。
但し、端末がA/Nと(positive)SRの間の多重化を行わない場合、A/Nと(positive)SRのうちの一つの送信を省略することができる。
一例として、端末は(A/N PUCCHリソースに対応する)PDSCH(及び/又はPDCCH)送信終了(或いは開始)時点がTref,sr(即ち、Tsr-To)より先立つか/遅れるかによって以下のようにA/Nと(positive)SRの間の多重化の有無を決定することができる。
(1)(A/N PUCCHリソースに対応する)PDSCH(及び/又はPDCCH)の送信終了(或いは開始)時点がTref,srより遅れた場合
A.A/Nと(positive)SRのうちの1つを選択して送信
i.SRに対するUCI状態がPositive SRである場合
1.SRをSR PUCCHリソースを介して送信(A/N送信を省略)
ii.SRに対するUCI状態がnegative SRである場合
1.A/NをA/N PUCCHリソースを介して送信
(2)(A/N PUCCHリソースに対応する)PDSCH(及び/又はPDCCH)の送信終了(或いは開始)時点がTref,srより先立つ(又は同一である)場合
A.A/Nと(positive)SRを多重化して送信(又はA/N PUCCHとSR PUCCHが時間軸でPUCCH内の全てのOFDMシンボルが完全に重畳する場合と同一のUCI多重化規則に従う)
i.A/N PUCCHがPUCCHフォーマット0である場合
1.SRに対するUCI状態がPositive SRである場合
-A/NをA/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースを介して送信
2.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
ii.A/N PUCCHがPUCCHフォーマット1である場合
1.SRに対するUCI状態がPositive SRである場合
-A/NをSR PUCCHリソースを介して送信。但し、SR PUCCHがPUCCHフォーマット0である場合にはSRを送信せず、A/Nのみを送信する。
2.SRに対するUCI状態がnegative SRである場合
-A/NをA/N PUCCHリソースを介して送信
iii.A/N PUCCHがPUCCHフォーマット2/3/4のうちの一つである場合
1.SRに対するUCI状態がPositive SR又はnegative SRである場合
-SRを明示的ビットで表現してA/Nに付け加えてUCIペイロードを生成後、生成されたUCIをA/N PUCCHリソースを介して送信
0は以下のうちの1つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力(capability)によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による復調に必要な端末処理時間又はそれに対応する値
(4)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(5)基地局と端末の間に予め約束した値(例えば、固定値)
[提案方法#1]の変形として、A/NとCSIの間のUCI多重化についても、A/NとSRの間のUCI多重化のように、以下の動作を行うことができる。例えば、A/N PUCCHリソースとCSI PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この場合、端末は(基準時点から)特定時点の前まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳するか否かによってA/NとCSIの間の多重化の有無を決定することができる。
但し、端末がA/NとCSIの間の多重化を行わない場合には、A/NとCSIのうちの一つの送信を省略することができる。
一例として、端末はCSI PUCCHの送信開始時点(例えば、開始シンボル)(以下、Tcsi)を基準として、T0以前の時点(以下、Tref,csi)まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳するか否かによってA/NとCSIの間の多重化の有無を決定することができる。Tref,csi=Tcsi-T0と定義され、OFDMシンボル単位で表現することができる。
(ケース1)Tref,csiまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳する場合は、端末はA/NとCSIを多重化して送信することができる。
(1)A/N PUCCHがDL割り当てにより指示される場合
-A/NとCSIを多重化してA/N PUCCHリソースを介して送信
(2)A/N PUCCHがDL割り当てにより指示されない場合
-A/NとCSIを多重化してCSI PUCCHリソースを介して送信
(ケース2)(ケース1)に該当しない場合、端末はA/NとCSIのうちの1つを選択して送信することができる。例えば、(i)Tref,CSI時点後に受信された(又は送信が開始/終了した)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳するか、(ii)Tref,CSIまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳しないか、又は(iii)Tref,CSIまで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが存在しない場合、端末はA/NとCSIのうちの1つを選択して送信することができる。
(1)Opt.1:CSIをCSI PUCCHリソースを介して送信(A/N送信を省略)
(2)Opt.2:A/NをA/N PUCCHリソースを介して送信(CSI送信を省略)
0は以下のうちの1つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による復調に必要な端末処理時間又はそれに対応する値
(4)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(5)基地局と端末の間に予め約束した値(例えば、固定値)
[提案方法#1A]端末に送信設定/指示されたPUCCHリソースがスロット内の時間軸で全体又は一部のOFDMシンボルが重畳する場合、端末が以下のUCI多重化規則に従ってUCI多重化(例えば、UCI多重化)を行う方法
(1)スロット内で重畳したPUCCHリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したPUCCHリソースに対するUCIを多重化して単一のPUCCHリソース(以下、MUX PUCCH)を介して送信
A.条件#1
i.Opt.1:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、多重化されたUCIを送信する(単一の)PUCCHリソースの1番目の(OFDM)シンボルがHARQ-ACKに対するPDSCH及び/又はSPS PDSCH解除(release)の(各々の)最後の(OFDM)シンボルからT1以後に開始
ii.Opt.2:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロットの1番目の(OFDM)シンボル(又はUL送信が許容された1番目の(OFDM)シンボル)がHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の最後の(各々の)(OFDM)シンボルからT1以後に開始
iii.Opt.3:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、多重化されたUCIを送信する(単一の)PUCCHリソース、及びスロット内に重畳したPUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルがHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
iv.Opt.4:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、多重化されたUCIを送信する(単一の)PUCCHリソース、及びスロット内に重畳したCSI PUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルがHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
v.Opt.5:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内の任意のUCIの組み合わせ/UCIペイロードに対して端末に設定された(全ての)PUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルがHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
B.条件#2
i.Opt.1:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、特定の規則によって選択される(単一の)PUCCHリソース、及びスロット内に重畳したPUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
ii.Opt.2:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
iii.Opt.3:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロット内の任意のUCIの組み合わせ/UCIペイロードについて端末に設定された(全ての)PUCCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
iv.Opt.4:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロットの1番目の(OFDM)シンボル(又はUL送信が許容された1番目の(OFDM)シンボル)が(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
ここで、(スケジューリング)DCIベースのPUCCHリソースは、DCIにより割り当てられたHARQ-ACK送信PUCCHリソースである。上記DCIの最後のシンボルは該当DCIを運ぶPDCCHが送信された最後のシンボルである。
(2)スロット内に重畳した(一部の)PUCCHリソースが条件を満たさない場合、端末は以下の動作を行うことができる。
A.Opt.1:端末は(2)の場合を期待せず、(2)の場合が発生した時に端末動作は端末の具現化に従う
B.Opt.2:端末は(1)の条件を満たさない(一部の)PUCCHリソースに対するUCIに対する送信を省略し、(1)の条件を満たす残りのPUCCHリソースに対するUCIを多重化して単一のPUCCHリソースを介して送信
C.Opt.3:端末はスロット内に重畳したPUCCHリソースに対する送信を省略
D.Opt.4:端末は(スロット内に重畳したPUCCHリソースのうち)特定の(一つの)PUCCHリソース(例えば、最も高い優先順位のUCIを送信するPUCCHリソース、又は時間軸で最も先になるPUCCHリソース)のみを送信し、残りは送信を省略
但し、スロット内(上位層(例えば、RRC)信号及び/又はDCIにより送信が指示された)の重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、(多重化する)UCIの組み合わせ、(全体)UCIペイロードサイズなどに基づいて定められた特定の規則によって、多重化されたUCIを送信する(単一の)PUCCHリソース(以下、MUX PUCCH)が新しく決定される。
ここで、T1は端末がPDSCHを受信した後、HARQ-ACK送信を行うために必要な端末処理時間に対応する値である。また、T2は端末がUL送信に対する(スケジューリング)DCIを受信した後、UL送信を行うために必要な端末処理時間に対応する値である。T1とT2は(OFDM)シンボル単位で表現することができる。
端末は時間軸で重畳したPUCCHリソースの間のUCI多重化の有無を決定するとき、少なくとも2個のタイムライン条件を考える。タイムライン条件#1は、PDSCHの受信後、HARQ-ACK送信までの端末処理時間を保証するための条件である。タイムライン条件#1は、HARQ-ACKに対応するPDSCHの最後の(OFDM)シンボルから一定時間T1以後にHARQ-ACK送信が行われることを目的とする。従って、T1時間に基づく条件は、HARQ-ACK送信が行われるULリソースを基準として適用する必要があり、重畳したUCIが多重化されると仮定するとき、(特定の規則によって)決定されるPUCCHリソースの開始時点とHARQ-ACKに対応するPDSCHの最後の(OFDM)シンボルの間に適用することができる。タイムライン条件#2は、PDCCHの受信後、UL送信までの端末処理時間を保証するための条件である。タイムライン条件#2は、(重畳したPUCCHのうちの一つ以上のUL送信をスケジュールする)PDCCHの最後の(OFDM)シンボルから一定の時間T2以後にUL送信が行われることを目的とする。タイムライン条件#2は、任意のUL送信開始からT2以前にスケジュール有無を把握できるようにするという目的もある。従って、重畳したPUCCHリソースのうち、最も早いULリソースよりT2以前に(重畳したPUCCHのうちの一つ以上のUL送信をスケジュールする)PDCCHに対する受信が終了しなければならない。即ち、タイムライン条件#2は、スロット内に重畳したPUCCHリソース(及びUCIを多重化すると仮定するとき、特定の規則によって選択される(単一の)PUCCHリソース)のうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始される条件である。
[提案方法#1B]端末に設定/指示されたPUCCHリソースとPUSCHリソースがスロット内の時間軸で全体或いは一部のOFDMシンボルが重畳する場合、端末が以下のUCI多重化規則に従ってUCI多重化を行う方法
(1)スロット内に重畳したPUCCHリソース及びPUSCHリソースが以下の条件の全体或いは一部を満たす場合、端末は重畳したPUCCHリソース及びPUSCHリソースに対するUCI及びUL-SCH TBを多重化して、単一のPUSCHリソース(以下、MUX PUSCH)により送信
A.条件#1
i.Opt.1:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、多重化されたUCIを送信する(単一の)PUSCHリソースの1番目の(OFDM)シンボルがHARQ-ACKに対するPDSCH及び/又はSPS PDSCH解除の(各々の)最後の(OFDM)シンボルからT1以後に開始
ii.Opt.2:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロットの1番目の(OFDM)シンボル(又はUL送信が許容された1番目の(OFDM)シンボル)がHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
iii.Opt.3:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソース及びPUSCHリソースのうち、(時間軸で)最も先になるUL送信リソースの1番目の(OFDM)シンボルがHARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
iv.Opt.4:(スロット内に重畳したPUCCHリソースのうち、HARQ-ACK送信のためのPUCCHリソースが存在する場合)スロット内の任意のUCIの組み合わせ/UCIペイロードに対して端末に設定された(全ての)PUCCHリソースとスロット内の(全ての)PUSCHリソースのうち、(時間軸で)最も先になるUL送信リソースの1番目の(OFDM)シンボルが HARQ-ACKに対応するPDSCH(又はSPS PDSCH解除)の(各々の)最後の(OFDM)シンボルからT1以後に開始
B.条件#2
i.Opt.1:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロット内に重畳したPUCCHリソース及びPUSCHリソースのうち、(時間軸で)最も先になるUL送信リソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
ii.Opt.2:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロット内の任意のUCIの組み合わせ/UCI ペイロードに対して端末に設定された(全ての)PUCCHリソースと(全ての)PUSCHリソースのうち、(時間軸で)最も先になるUL送信リソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
iii.Opt.3:(スロット内に重畳したPUCCHリソースのうち、DCIにより送信が指示されたPUCCHリソースが存在する場合)スロットの1番目の(OFDM)シンボル(又はUL送信が許容された1番目の(OFDM)シンボル)が(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始
ここで、(スケジューリング)DCIベースのPUCCHリソースは、DCIにより割り当てられたHARQ-ACK送信のPUCCHリソースである。上記DCIの最後のシンボルは該当DCIを運ぶPDCCHが送信された最後のシンボルである。
(2)スロット内に重畳した(一部の)PUCCHリソース及び/又は(一部の)PUSCHリソースが上記条件を満たさない場合、
A.Opt.1:端末は(2)の場合を期待せず、(2)の場合が発生する時に端末動作は端末の具現化に従う
B.Opt.2:端末は(1)の条件を満たさない(一部の)PUCCHリソースに対応するUCIに対する送信及び/又は(一部の)PUSCHリソースに対応するUL-SCH TBに対する送信を省略。反面、端末は(1)の条件を満たす残りのPUCCHリソース及び/又は残りのPUSCHリソースに対するUCI及び/又はUL-SCHを多重化して、単一のPUCCHリソースや((1)の条件を満たす重畳したPUSCHリソースが存在する場合は)単一のPUSCHリソースを介して送信
C.Opt.3:端末はスロット内に重畳したPUCCHリソース及び/又はPUSCHリソースに対する送信を省略
D.Opt.4:端末は(スロット内に重畳したPUCCHリソース及びPUSCHリソースのうち)特定の(一つの)PUCCH又はPUSCHリソース(例えば、最も高い優先順位のUCIを送信するULリソース又は時間軸で最も先になるULリソース)のみを送信し、残りは送信を省略
但し、スロット内の(上位層(例えば、RRC)信号及び/又はDCIにより送信指示された)重畳したPUCCHリソースに対するUCIを多重化すると仮定するとき、(多重化する)UCIの組み合わせ、(全体)UCIペイロードサイズなどに基づいて定められた特定の規則に従って、多重化されたUCIを送信する(単一の)PUCCHリソース(以下、MUX PUCCH)が新しく決定される。
ここで、T1は端末がPDSCHを受信した後、HARQ-ACK送信を行うために必要な端末処理時間に対応する値である。またT2は端末がUL送信に対する(スケジューリング)DCIを受信した後、UL送信を行うために必要な端末処理時間に対応する値である。T1とT2は(OFDM)シンボル単位で表現することができる。
端末は時間軸で重畳したPUCCHリソース及びPUSCHリソースの間のUCI多重化の有無を決定するとき、少なくとも2個のタイムライン条件を考える。タイムライン条件#1は、PDSCHの受信後、HARQ-ACK送信までの端末処理時間を保証するための条件である。タイムライン条件#1は、HARQ-ACKに対応するPDSCHの最後の(OFDM)シンボルから一定時間T1以後にHARQ-ACK送信が行われることを目的とする。従って、T1時間に基づく条件は、HARQ-ACK送信が行われるULリソースを基準として適用する必要があり、重畳したUCIが多重化されると仮定するとき、(特定の規則によって)決定されるPUCCHリソース又はPUSCHリソースの開始時点とHARQ-ACKに対応するPDSCHの最後の(OFDM)シンボルの間に適用できる。タイムライン条件#2は、PDCCHの受信後、UL送信までの端末処理時間を保証するための条件である。タイムライン条件#2は、(重畳したPUCCHのうちの一つ以上のUL送信をスケジュールする)PDCCHの最後の(OFDM)シンボルから一定時間T2以後にUL送信が行われることを目的とする。タイムライン条件#2は、任意のUL送信開始からT2以前にスケジュール有無を把握できるようにするという目的もある。従って、重畳したPUCCHリソースのうち、最も早いULリソースよりT2以前に(重畳したPUCCHのうちの一つ以上のUL送信をスケジュールする)PDCCHに対する受信が終了しなければならない。即ち、タイムライン条件#2は、スロット内に重畳したPUCCHリソース及びPUSCHリソースのうち、(時間軸で)最も先になるPUCCHリソースの1番目の(OFDM)シンボルが(スケジューリング)DCIの最後の(OFDM)シンボルからT2以後に開始される条件である。
[提案方法#1C]スロット内において端末に設定/指示されたPUCCHリソース及び/又はPUSCHリソースに対してUCI多重化を行うとき、端末が(段階的な)UCI多重化、及び多重化されたUCI(即ち、MUX UCI)に対する送信リソース決定を行う方法
[方法#A]
(1)Step 1:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUSCHリソースに代替
(2)Step 2:(多重化されたUCI送信が許容された)(DCIに基づいてスケジュールされた)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソース(以下、MUX PUCCH)に代替
A.多重化されたUCIを送信する(単一の)PUCCHリソース(即ち、MUX PUCCH)が(時間軸で)他のPUSCHリソース及び/又はPUCCHリソース)と(新しく)重量する場合は、端末は以下のうちの1つの動作を行う。
-Opt.1:(単一の)PUCCHリソースと(DCIに基づいてスケジュールされた)PUCCHリソースに対してStep 1及び/又はStep 2を再適用
-Opt.2:(単一の)PUCCHリソースによりMUX UCIを送信し、(単一の)PUCCHリソースと重畳するULリソースは送信を省略
-Opt.3:(単一の)PUCCHリソースの送信を省略
-Opt.4:エラーケースに処理(unspecified)
(3)Step 3:(多重化されたUCI送信が許容された)(上位層(例えば、RRC)信号により設定された)PUCCHリソースが存在するとき、PUCCHリソースごとに(i)該当PUCCHリソースと、(ii)(時間軸で)重畳する(上位層信号により設定された)PUCCHリソースに対してUCI多重化規則を適用する。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定(単一)のPUCCHリソース(即ち、MUX PUCCH)に代替する。
[方法#B]
(1)Step 1:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに該当PUSCHリソースと(時間軸で)重畳するPUCCHリソースについてUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定(単一)のPUSCHリソースに代替
(2)Step 2:(多重化されたUCI送信が許容された)開始シンボルが最も早い(或いは最も高い優先順位のUCIを運ぶ)PUCCHリソース(以下、PUCCH1)を基準として、(i)PUCCH1と、(ii)(時間軸で)重畳するPUCCHリソース(以下、PUCCH2)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定(単一)のPUCCHリソース(以下、PUCCH3;即ち、MUX PUCCH)に代替
(3)Step 3
A.Step 3-1:(i)Step 2のPUCCH3と、(ii)(PUCCH1とPUCCH2を除いた)PUCCHリソース(以下、PUCCH4)が(時間軸で)重畳する場合
-Opt.1:PUCCH3とPUCCH4に対してUCI多重化規則を適用(Step 2)。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定(単一)のPUCCHリソースに代替
-Opt.2:PUCCH3の送信を省略する
-Opt.3:PUCCH4の送信を省略する
B.Step 3-2:PUCCH3及びPUCCH4が(時間軸で)重畳しない場合
-PUCCH4内のPUCCHリソースを対象としてStep 2及びStep 3を適用
UCI多重化規則は、[提案方法#1A]又は[提案方法#1B]に従う。
各段階において、多重化されたUCIに対する既存のULリソースが特定の(単一の)PUCCH或いはPUSCHリソースに代替される場合、端末は代替された既存のULリソースを、以後の段階では存在しないリソースと見なすことができる。即ち、代替された既存のULリソースは、以後の過程ではUCI多重化対象として考慮されない。反面、多重化されたUCIを送信するように決定された(単一の)PUCCH或いはPUSCHリソースは、以後の過程でUCI多重化対象として考慮される。
各段階に複数のPUCCH(又はPUSCH)リソースが存在するとき、複数のPUCCH(又はPUSCH)リソースの間に該当段階の動作を適用する順序は所定の優先順位規則に従う。一例として、優先順位規則は、(スロット内の)相対的な送信時点(例えば、開始位置/シンボル)、UCIタイプ、リソース割り当て方式(例えば、動的又は準静的)、スケジュールされた順序、送信容量などを基準として決定される。
一例として、スロット内の時間軸で重畳するPUCCHリソース及び/又はPUSCHリソースに対してUCI多重化を行うとき、一つのスロット内で複数のPUCCH送信及びPUCCH時間リソースの柔軟な割り当てが支援されるNRシステムの特徴により、UCI多重化を行う対象となるPUCCHリソース及び/又はPUSCHリソースを決定することが不明な場合がある。たとえ、AN PUCCH、CSI PUCCH、SR PUCCHリソースが一つのスロット内に共存するとき、CSI PUCCHリソースはAN PUCCHリソース/SR PUCCHリソースと時間軸で重畳する反面、AN PUCCHリソースとSR PUCCHリソースは互いに時間軸で重畳しないと仮定する。この場合、(1)HARQ-ACK、CSI、SRの全てに対する多重化を行うか、又は(2)HARQ-ACK-CSI対に対する多重化とCSI-SR対に対する多重化を行うかという端末動作が不明である。従って、本発明では、最も多い種類のUCIを含むULリソースの順でUCI多重化を行う方法(例えば、[方法#A])、又は最も早い(或いは最も高い優先順位のUCIを含む)PUCCHリソースを基準として時間軸で重畳したPUCCHリソースに対して順にUCI多重化を行う方法(例えば、[方法#B])を提案する。[方法#A]の場合、PUSCH=>(DCIベースにスケジュールされた)AN PUCCH=>CSI PUCCH=>(上位層(例えば、RRC)信号により設定された)AN PUCCHの順にUCI多重化を行うことができる。この時、一度UCI多重化対象として選定されたPUCCHリソースは、以後のUCI多重化過程では排除される。
[提案方法#1C]の変形として、[方法#A]/[方法#B]でStep間の順序を変更することができる。例えば、以下の動作が考えられる。
[方法#A-1]
(1)Step 1:(多重化されたUCI送信が許容された)(上位層(例えば、RRC)信号により設定された)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳する(上位層信号により設定された)PUCCHリソースに対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一の)PUCCHリソース(以下、MUX PUCCHリソース)に代替することができる。
(2)Step 2:(多重化されたUCI送信が許容された)(DCIに基づいてスケジュールされた)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一の)PUCCHリソース(即ち、MUX PUCCHリソース)に代替することができる。ここで、重畳したPUCCHリソースは、スロット内のPUCCHリソースを意味する。
A.MUX PUCCHリソースが(時間軸で)他のPUCCHリソース)と(新しく)重畳する場合、以下の動作を行う。
-Opt.1:(i)MUX PUCCHリソースと、(ii)(DCIに基づいてスケジュールされた)PUCCHリソースに対してStep 2を再適用
-Opt.2:MUX PUCCHリソースに対する送信を行うが、MUX PUCCHリソースと重畳するULリソースに対する送信を省略
-Opt.3:MUX PUCCHリソースに対する送信を省略
-Opt.4:エラーケースに処理(unspecified)
(3)Step 3:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用することができる。ここで、PUCCHリソースはMUX PUCCHリソースを含む。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、特定の(単一の)PUSCHリソースに代替することができる。
[方法#A-2]
(1)Step 1:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一の)PUSCHリソース(以下、MUX PUSCHリソース)に代替することができる。
(2)Step 2:(多重化されたUCI送信が許容された)(上位層(例えば、RRC)信号により設定された)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳する(上位層信号により設定された)PUCCHリソースに対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一の)PUCCHリソース(即ち、MUX PUCCHリソース)に代替することができる。
(3)Step 3:(多重化されたUCI送信が許容された)(DCIに基づいてスケジュールされた)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは(単一の)PUCCHリソース(即ち、MUX PUCCHリソース)に代替することができる。
A.MUX PUCCHリソースが(時間軸で)他のPUSCHリソース及び/又はPUCCHリソース)と(新しく)重畳する場合、以下の動作を行う。
-Opt.1:(i)MUX PUCCHリソースと、(ii)(DCIに基づいてスケジュールされた)PUCCHリソースに対してStep 1及び/又はStep 3を再適用
-Opt.2:MUX PUCCHリソースに対する送信を行うが、MUX PUCCHリソースと重畳するULリソースに対するUCI送信を省略
-Opt.3:MUX PUCCHリソースに対するUCI送信を省略
-Opt.4:エラーケースに処理(unspecified)
[方法#B-1]
(1)Step 1:(多重化されたUCI送信が許容された)開始シンボル(又は最後のシンボル)が最も早い(或いは最高優先順位のUCIを運ぶ)PUCCHリソース(以下、PUCCH1)を基準として、(i)PUCCH1と、(ii)これと(時間軸で)重畳するPUCCHリソース(以下、PUCCH2))に対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソース(即ち、PUCCH1/PUCCH2)は、(単一)PUCCHリソース(以下、PUCCH3又はMUX PUCCH1)に代替することができる。
(2)Step 2
A.Step 2-1:(i)PUCCH3と、(ii)(PUCCH1/PUCCH2を除いた)PUCCHリソース(以下、PUCCH4)が(時間軸で)重畳する場合
-Opt.1:PUCCH3とPUCCH4に対してUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一)PUCCHリソース(以下、PUCCH3-1又はMUX PUCCH2)に代替することができる。
-Opt.2:PUCCH3の送信を省略する。
-Opt.3:PUCCH4の送信を省略する。
B.Step 2-2:(i)PUCCH3と、(ii)(PUCCH1/PUCCH2を除いた)PUCCHリソース(以下、PUCCH4)が(時間軸で)重畳しない場合
-PUCCH4内のPUCCHリソースを対象としてStep 1/2を適用
(3)Step 3:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用することができる。ここで、PUCCHリソースはStep 1/2が行われた後のPUCCHリソースを意味する。即ち、PUCCHリソースは時間軸で重畳せず、MUX PUCCHリソースを含む。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースは、(単一)PUSCHリソース(即ち、MUX PUSCHリソース)に代替することができる。
UCI多重化規則は[提案方法#1A]又は[提案方法#1B]に従う。[提案方法#1A]はPUCCH-PUCCH UCI多重化のためのタイムライン条件を含み、[提案方法#1B]はPUCCH-PUSCH UCI多重化のためのタイムライン条件を含む。スロット内の重畳したULチャネル(リソース)はタイムライン条件を満たす場合に限って、Step 1/2/3でUCI多重化が行われるように制限することができる。タイムライン条件は、(1)HARQ-ACK送信のための端末処理時間、(2)PDCCHの受信後、UL送信(例:PUCCH、PUSCH)のための端末処理時間に関連する。従って、(1)/(2)に関連するUL送信がない場合は、タイムライン条件を考える必要がなく、重畳したULチャネル(リソース)に対してUCI多重化を行うことができる。UCI多重化が行われる場合、(多重化する)UCIの組み合わせ、(全体)UCIペイロードサイズなどに基づいて、特定の規則に従って、多重化されたUCIを送信する(単一)PUCCHリソース(即ち、MUX PUCCH)が新しく決定される。
MUX PUCCHは本発明で提案する様々な方法により決定される。例えば、[提案方法#1H]を参照すると、端末はANと他のUCIを多重化した後、多重化された(総)UCIペイロードサイズに対応するPUCCHリソース集合を選択する。その後、端末は該当PUCCHリソース集合内のPUCCHリソースのうち、ARIにより指示されたPUCCHリソースを用いて多重化されたUCIを送信する。PUCCHリソース集合が支援するUCIサイズが2ビット以下である場合、PUCCHリソース集合はPUCCHフォーマット0/1を含む。反面、PUCCHリソース集合が支援するUCIサイズが3ビット以上である場合は、PUCCHリソース集合はPUCCHフォーマット2/3/4を含む。PUCCHリソース集合個数が一つ以上であると、少なくとも一つのPUCCHリソース集合は2ビット以下のUCI送信用として設定される。
各段階で多重化されたUCIに対する既存のULリソースが(単一)PUCCH或いはPUSCHリソース(以下、MUX ULリソース)に代替された場合、端末は代替された既存のULリソースは以後の段階では存在しないとみなすことができる。即ち、MUX ULリソースに代替された既存のULリソースは、以後の段階ではUCI多重化対象として考慮されない。反面、MUX ULリソースは以後の段階でUCI多重化対象として考慮される。
各段階に複数のPUCCH(又はPUSCH)リソースが存在するとき、複数のPUCCH(又はPUSCH)リソースの間において該当段階の動作を適用する手順は、所定の優先順位規則に従う。一例として、優先順位規則は(スロット内の)相対的な送信時点(例:開始位置/シンボル)、UCIタイプ、リソース割り当て方式(例:動的又は準静的)、スケジューリング手順、送信容量などを基準として定められる。
図9は方法#B-1に従うチャネル多重化過程を例示する。図9を参照すると、端末は(スロット内の)重畳したPUCCHリソースに対してUCI多重化を行う(Step 1、S1102)。例えば、端末は(多重化されたUCI送信が許容された)開始シンボルが最も早いPUCCHリソース(以下、PUCCH1)を基準として、(i)PUCCH1と、(ii)それと(時間軸で)重畳するPUCCHリソース(以下、PUCCH2))に対してUCI多重化規則を適用することができる。UCI多重化が適用される重畳したULリソース(即ち、PUCCH1/PUCCH2)は、(単一)PUCCHリソース(以下、MUX PUCCH1)に代替することができる。その後、端末はStep 1の結果に基づいてPUSCHリソースにUCIピギーバックを行う(Step 2、S1104)。例えば、端末は(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用する。より詳しくは、方法#B-1に関する説明を参照することができる。その後、端末はPUSCHを介してUCIを送信する。スロット内に重畳したPUSCHがない場合、Step 2は省略され、UCIはPUCCHを介して送信される。
[提案方法#1C]の変形として以下の動作を考えることができる。この提案は方法#B-1の変形として理解できる。Step#A/#B1/#B2は方法#B-1のStep1/2-2/2-1に対応し、方法#B-1においてStep1/2-1/2-2は各々Step#A/#B1/#B2に代替することができる。
(1)Step#A:開始シンボル(又は最後のシンボル)が最も早い(或いは最も高い優先順位のUCIを運ぶ)PUCCH(以下、PUCCH1)を基準として、(i)PUCCH1と、(ii)これと(時間軸で)重なるPUCCH(以下、PUCCH2)に限ってPUCCH-PUCCHの間のUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIを送信するために(単一の)コンテナーPUCCH(以下、MUX PUCCH1)が決定される。即ち、重畳した既存のULリソース(即ち、PUCCH1/PUCCH2)はMUX PUCCH1に代替することができる。
(2)Step#B1:(i)Step#Aで決定された(多重化されたUCI送信用)コンテナーPUCCH(即ち、MUX PUCCH1)と、(ii)(PUCCH1/PUCCH2を除いた)残りのPUCCH(以下、PUCCH3)が重ならない場合、
-(PUCCH3内のPUCCHの間にStep#Aを適用して)時間軸で重畳しないPUCCHをTDMに送信することができる。
(3)Step#B2:(i)MUX PUCCH1と(ii)PUCCH3が重なる場合、
-Opt 1:コンテナーPUCCH(即ち、MUX PUCCH1)とPUCCH3に対して再度PUCCH-PUCCHの間のUCI多重化規則を適用することができる。UCI多重化を行うとき、多重化されたUCIを送信するために、(単一の)コンテナーPUCCH(以下、MUX PUCCH2)が新しく決定される。即ち、重畳した既存のULリソース(即ち、MUX PUCCH1/PUCCH3)をMUX PUCCH2に代替することができる。MUX PUCCH2に対してStep#B1/#B2が再び適用されることができる。
-Opt 2:PUCCH3の送信を省略することができる。
図10はStep#A/#B1/#B2によるチャネル多重化過程を例示する。UCI送信のために、端末はUCIごとにPUCCHリソースを決定する。各PUCCHリソースは開始シンボルと送信の長さにより定義される。(スロット内に)重畳したPUCCHリソースがある場合、端末は最も早い(例えば、開始シンボルが最も早い)PUCCHリソースAと重畳するPUCCHリソースセットXを決定する(Step A1、S1202)。その後、端末は(i)PUCCHリソースAと、(ii)PUCCHリソースセットXに対してUCI多重化を行う(Step A1、S1204)。UCI多重化を行うとき、多重化されたUCIを送信するために、(単一の)コンテナーPUCCH(以下、MUX PUCCH)が決定される。これにより、PUCCHリソースAとPUCCHリソースセットXをMUX PUCCHに代替できる。その後、端末はMUX PUCCHを介してUCIを送信する。もしMUX PUCCHが(PUCCHリソースA/PUCCHリソースセットXを除いた)残りのPUCCHと重なる場合は、端末はMUX PUCCH(又はこれを含む残りのPUCCHのうち、最も早い(例えば、開始シンボルが最も早い)PUCCH)を最も早い(例えば、開始シンボルが最も早い)PUCCHリソースAに代替した状態でStep A1/A2を再度行うことができる。より詳しい事項は、Step#A/#B1/#B2に関する説明を参照する。図10のStep A1/A2は図9のStep 1に対応し、図9のStep 1は図10のStep A1/A2に代替することができる。
図11は図10によるUCI多重化を例示する。図11を参照すると、スロット内に複数のPUCCHリソースが重畳する場合、最も早い(例えば、開始シンボルが最も早い)PUCCHリソースAを基準としてUCI多重化が行われる。ケース1/2は1番目のPUCCHリソースが他のPUCCHリソースと重畳する場合を示す。この場合、1番目のPUCCHリソースを最も早いPUCCHリソースAと見なした状態で図10の過程が行われる。反面、ケース3は、1番目のPUCCHリソースが他のPUCCHリソースと重畳せず、2番目のPUCCHリソースが他のPUCCHリソースと重畳する場合である。この場合、1番目のPUCCHリソースについてはUCI多重化が行われない。その代わりに、2番目のPUCCHリソースを最も早いPUCCHリソースAと見なした状態で図10の過程が行われる。ケース2は、多重化されたUCIを送信するために決定されたMUX PUCCHリソースが他のPUCCHリソースと新しく重畳する場合である。この場合、MUX PUCCHリソース(又はこれを含む残りのPUCCHのうち、最も早い(例えば、開始シンボルが最も早い)PUCCHリソース)を最も早いPUCCHリソースAと見なした状態で図10の過程がさらに行われる。より詳しい事項はStep#A/#B1/#B2に関する説明を参照する。
[提案方法#1C]の変形として、端末に設定/指示されたPUCCHリソース及び/又はPUSCHリソースに対してUCI多重化(即ち、UCI多重化)を行うとき、端末は以下のように(段階的な)UCI多重化、及び多重化されたUCIに対する送信リソース決定を行う方法を考えることができる。
(1)Step 1:(多重化されたUCI送信が許容された)(上位層(例えば、RRC)信号により設定された)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳する(上位層信号により設定された)PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替
A.一例として、Step 1の詳しい段階は以下の通りである。
[Example #1]
-Step 1-1:CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
-Step 1-2:CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するAN PUCCHリソース及び/又はSR PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
-Step 1-3:AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するSR PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
(2)Step 2:(多重化されたUCI送信が許容された)(DCIに基づいてスケジュールされた)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替
A.一例として、Step 2の詳しい段階は以下の通りである。
[Example #1]
-Step 2-1:(DCIに基づいてスケジュールされた)AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソース及び/又はSR PUCCHリソース(及び/又はAN PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
[Example #2]
-Step 2-1:(DCIに基づいてスケジュールされた)AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソース及び/又はSR PUCCHリソース(及び/又はAN PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
-Step 2-2:(DCIに基づいてスケジュールされた)CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するSR PUCCHリソース(及び/又はCSI PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
(3)Step 3:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUSCHリソースに代替
各段階に複数のPUCCH(又はPUSCH)リソースが存在するとき、複数のPUCCH(又はPUSCH)リソースの間に該当段階の動作を適用する順序は、所定の優先順位規則に従う。一例として、優先順位規則は、(スロット内の)相対的な送信時点(例えば、開始位置/シンボル)、UCIタイプ、リソース割り当て方式(例えば、動的又は準静的)、スケジュールされた順序、送信容量などを基準として決定される。
各段階において、多重化されたUCIを送信するために新しく選択されたPUCCHリソースが、多重化されたUCIに対する(既存の)PUCCHリソース以外の他のPUCCHリソースと(時間軸で)重畳する場合は、端末はこの場合をエラーケースと判断して期待しない。又は、新しく選択されたPUCCHリソースと重畳したPUCCHリソースとUCI多重化規則を適用し、UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替することができる。
[提案方法#1C]の変形として、スロット内の端末に設定/指示されたPUCCHリソース及び/又はPUSCHリソースに対してUCI多重化を行うとき、端末は以下のように(段階的な)UCI多重化、及び多重化されたUCIに対する送信リソース決定を行う方法を考えることができる。
(1)Step 1:(多重化されたUCI送信が許容された)PUSCHリソースが存在するとき、PUSCHリソースごとに、(i)該当PUSCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUSCHリソースに代替
(2)Step 2:(多重化されたUCI送信が許容された)(DCIに基づいてスケジュールされた)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するPUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替
A.一例として、Step 2の詳しい段階は以下の通りである。
[Example #1]
-Step 2-1:(DCIに基づいてスケジュールされた)AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソース及び/又はSR PUCCHリソース(及び/又はAN PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
[Example #2]
-Step 2-1:(DCIに基づいてスケジュールされた)AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソース及び/又はSR PUCCHリソース(及び/又はAN PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
-Step 2-2:(DCIに基づいてスケジュールされた)CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するSR PUCCHリソース(及び/又はCSI PUCCHリソース)に対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
(3)Step 3:(多重化されたUCI送信が許容された)(上位層(例えば、RRC)信号により設定された)PUCCHリソースが存在するとき、PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳する(上位層信号により設定された)PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替
A.一例として、Step 3の詳しい段階は以下の通りである。
[Example #1]
-Step 3-1:CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するCSI PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
-Step 3-2:CSI PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するAN PUCCHリソース及び/又はSR PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(CSI)PUCCHリソースに代替
-Step 3-3:AN PUCCHリソースごとに、(i)該当PUCCHリソースと、(ii)(時間軸で)重畳するSR PUCCHリソースに対してUCI多重化規則を適用。UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)(AN)PUCCHリソースに代替
各段階に複数のPUCCH(又はPUSCH)リソースが存在するとき、複数のPUCCH(又はPUSCH)リソースの間に該当段階の動作を適用する順序は、所定の優先順位規則に従う。一例として、優先順位規則は、(スロット内の)相対的な送信時点(例えば、開始位置/シンボル)、UCIタイプ、リソース割り当て方式(例えば、動的又は準静的)、スケジュールされた順序、送信容量などを基準として決定される。
各段階において、多重化されたUCIを送信するために新しく選択されたPUCCHリソースが、多重化されたUCIに対する(既存の)PUCCHリソース以外の他のPUCCHリソースと(時間軸で)重畳する場合、端末はこの場合をエラーケースと判断して期待しない。又は、新しく選択されたPUCCHリソースと重畳したPUCCHリソースとUCI多重化規則を適用し、UCI多重化を行うとき、多重化されたUCIに対する既存のULリソースを特定の(単一の)PUCCHリソースに代替することができる。
[提案方法#1D]スロット内で端末に設定/指示された(準静的に設定された)(単一の)SR PUCCHリソースが2つ以上の(準静的に設定された)CSI PUCCHリソースと時間軸で重畳する場合に、端末が以下のうちの一つの動作を行う方法
(1)Opt.1:SRビットを各CSI PUCCHリソースのUCIペイロードに全て追加してCSIとSRを多重化して送信。即ち、SR情報をSR PUCCHと重畳した全てのCSI PUCCHに含めることができる。
-複数のCSI PUCCHリソースに含まれるSR情報は、最初のCSI PUCCHリソースに送信されたSR情報がコピーされる(或いは同一に送信される)形態である。即ち、複数のCSI PUCCHリソースに含まれるSR情報は、全て同一にコピーされた情報である。また複数のCSI PUCCHリソースに含まれるSR情報は、各CSI PUCCHリソースごとに更新された(或いは、各CSI PUCCH時点の端末のSR状態(例えば、negative又はpositive)を反映する)SR情報である。即ち、複数のCSI PUCCHリソースに含まれるSR情報は、各CSI PUCCHリソースの送信時点ごとに更新されたSR情報である。
(2)Opt.2:SRビットを特定の一つのCSI PUCCHリソースのUCIペイロードのみに追加してCSIとSRを多重化して送信。ここで、特定の一つのCSI PUCCHリソースは以下のうちの一つである。
-Opt.2-1:時間軸で最初(又は最後)のCSI PUCCHリソース、或いは開始時点が最も早い(又は遅い)CSI PUCCHリソース。即ち、SR情報をSR PUCCHと重畳した全てのCSI PUCCHのうちの1番目のCSI PUCCHのみに含めることができる。
-Opt.2-2:最も送信容量が大きいCSI PUCCHリソース
-Opt.2-3:最も高い優先順位を有するCSIに設定されたCSI PUCCHリソース
NRシステムでは単一のCSI PUCCHリソースと一つ又はそれ以上のSR PUCCHリソースが一つのスロット内で重畳する場合、全てのUCIを多重化して単一のCSI PUCCHリソースを介して送信する動作が考えられる。この時、CSIとSRを多重化する問題について、上記の場合とは逆に、単一のSR PUCCHリソースが複数のCSI PUCCHリソースと重畳する場合のUCI多重化規則も定める必要がある。この問題については、上述したオプションを考慮できる。
[提案方法#1F]スロット内において、端末に設定/指示された(単一の)PUSCHリソースが2つ以上のCSI PUCCHリソース(又はAN PUCCHリソース)と時間軸で重畳する場合に、端末が以下のうちの一つの動作を行う方法
(1)Opt.1:PUSCHと重畳したCSI PUCCHリソース(又はAN PUCCHリソース)のうち、特定の一つのCSI PUCCHリソース(又はAN PUCCHリソース)に対するCSI報告(又はHARQ-ACK情報)をUL-SCH TB(例えば、ULデータ)と多重化してPUSCHリソースを介して送信(例えば、UCIピギーバック)。
-特定の一つのCSI PUCCHリソースは、時間軸で最も早い或いは優先順位が最も高いCSIに設定されたCSI PUCCHリソースを含む。また、特定の一つのAN PUCCHリソースは、時間軸で最も早いAN PUCCHリソースを含む。
-特定の一つのCSI PUCCH(又はAN PUCCH)以外の残りのCSI PUCCH(又はAN PUCCH)及び対応するCSI報告(又はHARQ-ACK)の送信は省略できる。
(2)Opt.2:PUSCHと重畳したCSI PUCCHリソース(又はAN PUCCHリソース)に対するCSI報告(又はHARQ-ACK情報)を全てUL-SCH TB(例えば、ULデータ)と多重化してPUSCHリソースを介して送信(例えば、UCIピギーバック)。又はPUSCHと重畳したCSI PUCCHリソース(又はAN PUCCHリソース)に対するCSI報告(又はHARQ-ACK情報)のうち、予め定義/設定された優先順位規則に従って優先順位が高い最大M個までのCSI報告(又はHARQ-ACK情報)をUL-SCH TB(例えば、ULデータ)と多重化してPUSCHリソースを介して送信(例えば、UCIピギーバック)
-M値は1又は2である。
-M値は予め約束された値であるか、又は上位層(例えば、RRC)信号により設定/定義される値である。
[提案方法#1F]において、PUSCHリソースをCSI PUCCHリソースに置き換え、UL-SCH TBをCSIに置き換えた場合、CSI PUCCHリソースとAN PUCCHリソースに対するCI多重化動作は同様に適用できる。
NRシステムは柔軟なPUCCH送信区間の設定が支援されるので、単一のPUSCHリソースと一つ又はそれ以上のCSI PUCCHリソース(又はAN PUCCHリソース)が1スロット内で重畳する場合があり得る。この場合、優先順位規則に基づいて(優先順位が高い)M個のCSI PUCCHリソース(又はAN PUCCHリソース)に対するM個のCSI報告のみをPUSCHでUCIピギーバックすることができる。M値は予め約束された値であるか、又は上位層信号により設定/定義された値である。又は簡単な方法として、PUSCHリソースと時間軸で1番目に重畳したCSI PUCCHリソース(又はAN PUCCHリソース)に対するCSI報告(又はHARQ-ACK)のみをPUSCHでUCIピギーバックすることができる。
[提案方法#1H]端末が、(2ビット以下のANに対する)AN PUCCHリソースとN個の(例えば、N>1)SR PUCCHリソースに対するUCI多重化を行うとき、AN PUCCHに対するスケジューリング方法及び/又はAN PUCCHに対して設定されたPUCCHリソース集合数Kによって多重化されたUCI(例えば、AN/SR)を送信するPUCCHフォーマットを以下のように異ならせる方法
(1)AN PUCCHリソースがDCI(例えば、ARI)により指示された場合
A.K>1である場合
-多重化されたUCI(例えば、AN/SR)をPUCCHフォーマット2/3/4のうちの1つで送信
B.K=1である場合
-多重化されたUCI(例えば、AN/SR)をPUCCHフォーマット0/1のうちの1つで送信
(2)AN PUCCHリソースがDCI(例えば、ARI)により指示されない場合(例えば、AN PUCCHリソースがSPS PDSCHに対するA/N情報に連関する場合)
A.K>1である場合
-Opt.1:多重化されたUCI(例えば、AN/SR)をPUCCHフォーマット0/1のうちの1つで送信
-Opt.2:多重化されたUCI(例えば、AN/SR)を特定のARI値を仮定して選択されたPUCCHフォーマット2/3/4のうちの1つで送信
B.K=1である場合
-多重化されたUCI(例えば、AN/SR)をPUCCHフォーマット0/1のうちの1つで送信
上述した方法により、AN PUCCHリソースがN個(例えば、N>1)のSR PUCCHリソースと時間軸で重畳するとき、端末はANとSRを多重化することができる。
端末は(総)UCIペイロードサイズによってPUCCHリソース集合を選択した後、選択されたPUCCHリソース集合内のPUCCHリソースのうち、ARIにより指示されたPUCCHリソースによりUCI(例えば、HARQ-ACK)を送信することができる。ここで、ARI(ACK/NACKリソース指示子)はDCI内のPUCCHリソースを指示するビットフィールドを意味する。
一方、AN PUCCHリソースに対するPUCCHリソース集合個数は複数である(K>1)。この場合、端末はANと他のUCIを多重化した後、多重化された(総)UCIペイロードサイズに対応するPUCCHリソース集合を選択する。その後、端末は該当PUCCHリソース集合内のPUCCHリソースのうち、ARIにより指示されたPUCCHリソースを用いて多重化されたUCIを送信する。この時、PUCCHリソース集合が支援するUCIサイズが2ビット以下である場合、PUCCHリソース集合はPUCCHフォーマット0/1を含む。反面、PUCCHリソース集合が支援するUCIサイズが3ビット以上である場合は、PUCCHリソース集合はPUCCHフォーマット2/3/4を含む。PUCCHリソース集合個数が一つ以上であると、少なくとも一つのPUCCHリソース集合は2ビット以下のUCI送信用として設定される。従って、AN PUCCHリソースがARIにより指示され、AN PUCCHリソースに対するPUCCHリソース集合個数が2個以上であると、端末は3ビット以上のUCI送信用であるPUCCHフォーマット2/3/4によりUCIを送信することができる。この場合、端末はANと複数のSRとの間で多重化を行うとき、複数のSR PUCCHリソースに関するSR情報をマルチビットSR情報をANペイロードに追加した後、全体UCIペイロードサイズにより選択されたPUCCHリソース集合内でARIにより指示されたPUCCHフォーマット2/3/4のうちの一つにより多重化されたAN/SRを送信することができる。
しかし、AN PUCCHリソースがARIにより指示されても、AN PUCCHリソースに対するPUCCHリソース集合個数が1個であると、端末はPUCCHフォーマット2/3/4リソースを使用できない。従って、多重化されたAN/SRをPUCCHフォーマット0/1リソースを介して送信する方法が考えられる。例えば、端末はANと複数のSRの間の多重化を行うとき、AN PUCCHがPUCCHフォーマット1であると、PUCCHフォーマット0に従うSR PUCCHリソースに対するSR送信を省略し、PUCCHフォーマット1に従うSR PUCCHリソースのうち、positive SRでありかつ優先順位が最も高いSRに対応するSR PUCCHリソースによりANを送信する(但し、全部negative SRであると、AN PUCCH送信)。又はAN PUCCHがPUCCHフォーマット0であると、AN PUCCHリソースに対して最大2個のCSオフセットを適用して2個のSR PUCCH(グループ)に関するSR情報を表現することができる。即ち、positive SRであるSR PUCCHを少なくとも一つ以上含みながら、優先順位が最も高いSR PUCCH(グループ)に対応するCSオフセットをAN PUCCHフォーマット0に適用することができる。
一方、SPS(Semi-Static scheduling)PDSCH送信に対応するAN PUCCHリソースはARIにより指示されず、上位層(例えば、RRC)信号により準静的に設定される。従って、SPS PDSCH送信に対応するAN PUCCHリソースとSR PUCCHリソースが重畳する場合、端末はANと複数のSRの間の多重化を行うとき、PUCCHフォーマット2/3/4リソースを使用することができない。従って、多重化されたAN/SRをPUCCHフォーマット0/1リソースを介して送信する方法を考えることができる。たとえば、端末がANと複数のSRの間の多重化を行うとき、AN PUCCHがPUCCHフォーマット1であると、PUCCHフォーマット0に従うSR PUCCHリソースに対するSR送信を省略し、PUCCHフォーマット1を従うSR PUCCHリソースのうち、positive SRでありかつ優先順位が最も高いSRに対応するSR PUCCHリソースによりANを送信する(但し、全部negative SRであると、AN PUCCH送信)。又はAN PUCCHがPUCCHフォーマット0であると、AN PUCCHリソースに対して最大2個までCSオフセットを適用して2個のSR PUCCH(グループ)に関するSR情報を表現することができる。即ち、positive SRであるSR PUCCHを少なくとも一つ以上含みながら優先順位が最も高いSR PUCCH(グループ)に対応するCSオフセットをAN PUCCHフォーマット0に適用することができる。しかし、AN PUCCHリソースに対するPUCCHリソース集合個数が2個以上である場合は、ARIは指示されないが、端末はAN PUCCHリソースを決定するために特定のARI値(例えば、ARI=0)を仮定することができる。その後、端末は(1)複数のSR PUCCHリソースに関するSR情報をマルチビットSR情報で表現してANペイロードに追加した後、(2)多重化された全体UCIペイロードサイズにより選択されたPUCCHリソース集合内でARI=0に対応するPUCCHフォーマット2/3/4リソースのうちの一つを用いて多重化されたAN/SRを送信することができる。
[提案方法#1H]の“多重化されたUCI(例えば、AN/SR)をPUCCHフォーマット0/1のうちの1つで送信”する動作について、端末がANとSRを以下のように多重化する動作を考えることができる。但し、PF0/1/2/3/4はPUCCHフォーマット0/1/2/3/4を意味する。
(1)Case #1:(単一の)ANと(単一の)SRの間のUCI多重化
A.AN PF0である場合
i.SR PF0である場合:Positive SRであると、ANをAN PF0リソースにCSオフセットを適用したリソースを介して送信。negative SRであると、ANをAN PF0リソースを介して送信。
ii.SR PF1である場合
-Opt.1:Positive SRであると、ANをAN PF0リソースにCSオフセットを適用したリソースを介して送信。negative SRであると、ANをAN PF0リソースを介して送信。
-Opt.2:Positive SRであると、ANをSR PF1リソースを介して送信。negative SRであると、ANをAN PF0リソースを介して送信。
B.AN PF1である場合
i.SR PF0である場合:ANをAN PF1リソースを介して送信(SR drop)
ii.SR PF1である場合:Positive SRであると、ANをSR PF1リソースを介して送信。negative SRであると、ANをAN PF1リソースを介して送信。
(2)Case #2:(単一の)ANと(マルチプル)SR(w/単一のPUCCHフォーマット)の間のUCI多重化
A.AN PF0である場合
i.(マルチプル)SR PF0である場合
-(特定のSR PUCCHグループ内の)少なくとも一つのSR PUCCHに対するSR情報がPositive SRであると、ANをAN PF0リソースに(特定のSR PUCCHグループに対応する)CSオフセットを適用したリソースを介して送信
-この場合、全K個のSR PUCCHをL個(例えば、L=2、K>L)のSR PUCCHグループにグルーピングした後、該当L個のSR PUCCHグループを各々互いに異なるL個のCSオフセットに対応/マッピングすることができる。特定のSR PUCCHグループに属するSRのうちのいずれか1つがPositiveであると、該当特定のSR PUCCHグループに対応するCSオフセットを適用したリソースによりANを送信するように動作
-全てのSR PUCCHに対するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
ii.(マルチプル)SR PF1である場合
-Opt.1:(特定のSR PUCCHグループ内の)少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANをAN PF0リソースに(特定のSR PUCCHグループに対応する)CSオフセットを適用したリソースを介して送信。この場合、全K個のSR PUCCHをL個(例えば、L=2、K>L)のSR PUCCHグループにグループ化した後、該当L個のSR PUCCHグループを各々互いに異なるL個のCSオフセットに対応/マッピングする。特定のSR PUCCHグループに属するSRのうちの少なくとも一つがPositiveであると、該当特定のSR PUCCHグループに対応するCSオフセットを適用したリソースによりANを送信するように動作。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
-Opt.2:少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANをSR PUCCHのうちの(最優先順位の)SR PUCCHに対応するSR PF1リソースを介して送信。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
B.AN PF1である場合
i.(マルチプル)SR PF0である場合:ANをAN PF1リソースを介して送信(SR drop)
ii.(マルチプル)SR PF1である場合:少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANをSR PUCCHのうちの(最優先順位の)SR PUCCHに対応するSR PF1リソースを介して送信。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF1リソースを介して送信
(3)Case #3:(単一の)ANと(マルチプル)SR(w/互いに異なるPUCCHフォーマット)の間のUCI多重化
A.AN PF0である場合
i.(マルチプル)SR PF0+(マルチプル) SR F1である場合
-Opt.1:少なくとも一つのSR PUCCHに関するSR情報がPositive SRであり、SR PUCCHのうち、(最優先順位の)SR PUCCHがPF0である場合、ANをAN PF0リソースにCSオフセットを適用したリソースを介して送信。この場合、全体或いはPF0に設定されたK個のSR PUCCHをL個(例えば、L=2、K>L)のSR PUCCHグループにグループ化した後、該当L個のSR PUCCHグループを各々互いに異なるL個CSオフセットに対応/マッピングする。この場合、特定のSR PUCCHグループに属するSRのうちの少なくとも一つがPositiveであると、該当特定のSR PUCCHグループに対応するCSオフセットを適用したリソースによりANを送信するように動作。もしPF0に設定されたSR PUCCH数KがLと同一であるか、又はLより小さい場合には、別のグループ化無しに該当K個のSR PUCCHを各々互いに異なるK個のCSオフセットに対応/マッピングする。この場合、Positive SR PUCCHに対応するCSオフセットを適用したリソースによりANを送信するように動作。少なくとも一つのSR PUCCHに関するSR情報がPositive SRであり、SR PUCCHのうち、(最優先順位の)SR PUCCHがPF1である場合、ANを(該当)SR PF1リソースを介して送信。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
-Opt.2:(特定のSR PUCCHグループ内の)少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANをAN PF0リソースに(特定のSR PUCCHグループに対応する)CSオフセットを適用したリソースを介して送信。この場合、全K個のSR PUCCHをL個(例えば、L=2、K>L)のSR PUCCHグループにグループ化した後、該当L個のSR PUCCHグループを各々互いに異なるL個のCSオフセットに対応/マッピングする。この場合、特定のSR PUCCHグループに属するSRのうちの少なくとも一つがPositiveであると、該当特定のSR PUCCHグループに対応するCSオフセットを適用したリソースによりANを送信するように動作。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
-Opt.3:(特定のSR PUCCHグループ内の)少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANを(上記特定のSR PUCCHグループに対応する)特定のSR PF1リソースを介して送信。この場合、全K個のSR PUCCHをL個(例えば、L=the number of SRs configured with F1、K>L)SR PUCCHグループにグループ化した後、該当L個のSR PUCCHグループを各々互いに異なるL個のSR F1リソースに対応/マッピングする。この場合、特定のSR PUCCHグループに属するSRのうちの少なくとも一つがPositiveであると、該当特定のSR PUCCHグループに対応するSR F1リソースによりANを送信するように動作。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF0リソースを介して送信
B.AN PF1である場合
i.(マルチプル)SR PF0+(マルチプル)SR F1である場合
-Opt.1:少なくとも一つのSR PUCCHに関するSR情報がPositive SRであり、SR PUCCHのうち、(最優先順位の)SR PUCCHがPF0である場合、ANをAN PF1リソースを介して送信(SR drop)。少なくとも一つのSR PUCCHに関するSR情報がPositive SRであり、SR PUCCHのうち、(最優先順位の)SR PUCCHがPF1である場合、ANを(該当)SR PF1リソースを介して送信。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF1リソースを介して送信
-Opt.2:(特定のSR PUCCHグループ内の)少なくとも一つのSR PUCCHに関するSR情報がPositive SRであると、ANを(上記特定のSR PUCCHグループに対応する)特定のSR PF1リソースを介して送信。この場合、全K個のSR PUCCHをL個の(例えば、L=the number of SRs configured with F1、K>L)SR PUCCHグループにグループ化した後、該当L個のSR PUCCHグループを各々互いに異なるL個のSR F1リソースに対応/マッピングする。この場合、特定のSR PUCCHグループに属するSRのうちの少なくとも一つがPositiveであると、該当特定のSR PUCCHグループに対応するSR F1リソースによりANを送信するように動作。全てのSR PUCCHに関するSR情報がnegative SRであると、ANをAN PF1リソースを介して送信
ここで、SRPUCCHグループは一つ以上のSR PUCCHで構成され、一つ以上のSR PUCCHグループが定義される。
上述した内容を整理すると以下の通りである。
(1)Case #1
A.AN PF0+単一のSR PF0=>AN+SR on AN PF0(CSオフセットにより)
B.AN PF0+単一のSR PF1=>AN+SR on AN PF0(CSオフセットにより)又はSR PF1(CH選択により)
C.AN PF1+単一のSR PF0=>AN only on AN PF1(SR省略により)
D.AN PF1+単一のSR PF1=>AN+SR on SR PF1(CH選択により)
(2)Case #2
A.AN PF0+マルチプルSR PF0=>AN+SR on AN PF0(CSオフセット及びSRバンドリングにより)
B.AN PF0+マルチプルSR PF1=>AN+SR on AN PF0(CSオフセット及びSRバンドリングにより)又はSR PF1(CH選択により)
C.AN PF1+マルチプルSR PF0=>AN only on AN PF1(SR省略により)
D.AN PF1+マルチプルSR PF1=>AN+SR on SR PF1(CH選択により)
(3)Case #3
A.AN PF0+(マルチプル)SR PF0+(マルチプル)SR PF1
i.Option 1
1.SR PF0がPositive SRであり、優先順位が最も高い場合、AN+SR on AN F0(CSオフセット及びSRバンドリングにより)。この場合、SRバンドリング対象はSR F0のみに限定
2.SR PF1がPositive SRであり、優先順位が最も高い場合、AN+SR on SR PF1(CH選択により)
ii.Option 2
1.SR PFがPositive SRであるか否かに関係なく、AN+SR on AN PF0(CSオフセット及びSRバンドリングにより)。この場合、SRバンドリング対象はSR PF0とSR PF1を全て含む
iii.Option 3
1.SR PFがPositive SRであるか否かに関係なく、AN+SR on SR PF1(CH選択及びSRバンドリングにより)。この場合、SRバンドリング対象はSR PF0とSR PF1を全て含む
B.AN PF1+(マルチプル)SR PF0+(マルチプル)SR PF1
i.Option 1
1.SR PF0がPositive SRであり、優先順位が最も高い場合、AN only on AN PF1(SR省略により)
2.SR PF1がPositive SRであり、優先順位が最も高い場合、AN+SR on SR PF1(CH選択により)
ii.Option 2
1.AN+SR on SR PF1(CH選択及びSRバンドリングにより)。この場合、SRバンドリング対象はSR PF0とSR PF1を全て含む
[提案方法#2]スロット内において、A/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この場合、端末はA/Nと(positive)SRの間の多重化を仮定する時に使用されるPUCCH(以下、MUX PUCCH)の送信開始時点とSR PUCCHの送信開始時点の相対的な関係によってA/Nと(positive)SRの間の多重化の有無を決定することができる。
但し、端末がA/Nと(positive)SRの間の多重化を行わない場合、A/Nと(positive)SRのうちの1つの送信が省略される。
一例として、端末はSR PUCCHの送信開始時点がMUX PUCCHの送信開始時点よりT0ほど先立つか又は遅れるかによって、以下のようにA/Nと(positive)SRの間の多重化の有無が決定される。
(1)SR PUCCHの送信開始時点がMUX PUCCHの送信開始時点を基準としてT0以前の時点より先立つ場合
A.A/Nと(positive)SRのうちの一つを選択して送信
i.SRに対するUCI状態がPositive SRである場合、SRをSR PUCCHリソースを介して送信(A/N送信を省略)
ii.SRに対するUCI状態がnegative SRである場合、A/NをA/N PUCCHリソースを介して送信
(2)SR PUCCHの送信開始時点がMUX PUCCHの送信開始時点を基準としてT0以前の時点より遅れる(又は同一である)場合
A.A/Nと(positive)SRを多重化して送信(又はA/N PUCCHとSR PUCCHが時間軸でPUCCH内の全てのOFDMシンボルに対して完全に重畳する場合と同一のUCI多重化規則に従う)
i.A/N PUCCHがPUCCHフォーマット0である場合
1.SRに対するUCI状態がPositive SRである場合、A/NをA/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースを介して送信
2.SRに対するUCI状態がnegative SRである場合、A/NをA/N PUCCHリソースを介して送信
ii.A/N PUCCHがPUCCHフォーマット1である場合
1.SRに対するUCI状態がPositive SRである場合、A/NをSR PUCCHリソースを介して送信。但し、SR PUCCHがPUCCHフォーマット0である場合には、SRを送信せず、A/Nのみを送信することができる。
2.SRに対するUCI状態がnegative SRである場合、A/NをA/N PUCCHリソースを介して送信
iii.A/N PUCCHがPUCCHフォーマット2/3/4のうちの一つである場合
1.SRに対するUCI状態がPositive SR又はnegative SRである場合、A.SRを明示的ビットで表現してA/Nに付け加えてUCIペイロードを生成後、生成されたUCIをA/N PUCCHリソースを介して送信
0は以下のうちの一つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による復調に必要な端末処理時間又はそれに対応する値
(4)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(5)基地局と端末の間で予め約束した値(例えば、固定値)
[提案方法#2]はA/N PUCCHがPUCCHフォーマット0/2/3/4である場合に適用される。
NRシステムにおいて、A/N PUCCHとSR PUCCHの間の開始(OFDM)シンボルが異なる場合、A/N onlyの送信を仮定したA/N PUCCH(以下、A/N PUCCH1)とSR PUCCHの間の開始(OFDM)シンボル(或いは開始時間)を比較して、A/NとSRの間のUCI多重化の有無を決定する方法が論議されている。例えば、SR PUCCHの開始(OFDM)シンボルがA/N PUCCH1の開始(OFDM)シンボルより先立つ場合、端末はSR PUCCHを送信し、A/N送信を省略する。逆に、SR PUCCHの開始(OFDM)シンボルがA/N PUCCH1の開始(OFDM)シンボルより遅れた(或いは同一である)場合には、端末はSRとA/NをUCI多重化して単一のPUCCHで送信することができる。上述した動作は、端末が開始(OFDM)シンボルが先立つPUCCHを先に処理することが期待されるためである。しかし、NRシステムにおいて、A/NとSRを多重化して単一のPUCCHリソースを介して送信するとき、A/N PUCCHがPUCCHフォーマット0/2/3/4である場合は、単一のPUCCHリソースはA/NとSRに対する全体UCIペイロードサイズを算定して新しく選択されたA/N PUCCHリソース(以下、A/N PUCCH2)であり、A/N PUCCH1とは異なることができる。従って、端末がSR PUCCHの開始(OFDM)シンボルがA/N PUCCH1の開始(OFDM)シンボルより遅れた(或いは同一である)場合であると判断した後、A/N PUCCH2でA/NとSRを送信するとき、SR PUCCHよりA/N PUCCH2の開始(OFDM)シンボルが先立つ場合があり得る。従って、より一貫した端末の動作のために、A/N PUCCH1ではなく、A/N PUCCH2の開始(OFDM)シンボルとSR PUCCHの開始(OFDM)シンボルの間の先後関係を比較することが好ましい。
[提案方法#3]スロット内において、A/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この時、A/Nと(positive)SRの間の多重化を仮定する時に使用されるPUCCH(以下、MUX PUCCH)の送信開始時点がSR PUCCHの送信開始時点より遅いことができる。この場合、端末は(ベストエフォート方式により)On-going SR PUCCH送信があれば、該当SR PUCCHの送信を中断して、MUX PUCCHでA/Nと(positive)SRを多重化して送信することができる。
さらに、A/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳した場合は、端末はA/Nと(positive)SRの間の多重化を仮定する時に使用されるPUCCH(以下、MUX PUCCH)の送信開始時点がA/N PUCCHの送信開始時点より遅いことができる。この場合、端末は(ベストエフォート方式により)On-going A/N PUCCH送信があれば、該当A/N PUCCHの送信を中断して、MUX PUCCHでA/Nと(positive)SRを多重化して送信する方法
但し、上記動作は特定の端末能力を有する端末に限定して適用される。
端末がSR送信を行った後にSR PUCCHと時間軸で一部重畳するA/N PUCCHリソースの存在を把握した場合、簡単な方法で端末は該当A/N送信を省略することができる。しかし、端末に十分な能力があれば、できる限り(即ち、ベストエフォート方式により)現在進行中のSR送信を中断し、A/NとSRを多重化して単一のPUCCHリソースを介して送信することができる。逆に、端末がA/N送信を行った後にA/N PUCCHと時間軸で一部重畳するSR PUCCHリソースに対するPositive SRが発生することができる。この場合にも、端末は(即ち、ベストエフォート方式により)現在進行中のA/N送信を中断し、A/NとSRを多重化して単一のPUCCHリソースを介して送信することができる。[提案方法#3]により、端末はSRとA/Nが衝突する場合にもA/NとSRの多重化された送信を最大に支援することができる。
[提案方法#4]A/N PUCCHがPF0又はPF1であり、スロット内でA/N PUCCHリソースとSR PUCCHリソースが時間軸で(PUCCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この場合、端末はA/N PUCCHリソースと重畳したSR PUCCHリソースに対応するSRプロセス数によって、A/NとSRに対するUCI多重化規則を異なるように適用することができる。
一例として、A/N PUCCHリソースと重畳したSR PUCCHリソースに対応するSRプロセスが一つであるか、或いは複数であるかによって、端末は以下のようにA/NとSRに対してUCI多重化規則を適用することができる。
(1)(A/Nと重畳する)SRプロセスが一つである場合
A.A/N PUCCHがPUCCHフォーマット0である場合
i.SRに対するUCI状態がPositive SRである場合、A/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースによりA/Nを送信
ii.SRに対するUCI状態がnegative SRである場合、A/N PUCCHリソースによりA/Nを送信
B.A/N PUCCHがPUCCHフォーマット1である場合
i.SRに対するUCI状態がPositive SRである場合、SR PUCCHリソースによりA/Nを送信
ii.SRに対するUCI状態がnegative SRである場合、A/N PUCCHリソースによりA/Nを送信
(2)(A/Nと重畳する)SRプロセスが複数である場合
A.A/N PUCCHがPF0又はPF1である場合
i.A/Nに(複数のSRプロセスに対する)SRを表現するマルチビットを付け加えた後、A/N PUCCHリソースにより全体UCIを送信。ここで、A/N PUCCHリソースはA/NとマルチビットSRを含むUCIペイロードサイズを基準として選択されたリソースであり、PF2/3/4のうちの一つである。
ここで、複数のSRプロセスに対応するSR PUCCHリソースの設定は特定のIDにより区分され、各々独立している。
NRシステムでは、A/N PUCCHがPF0又はPF1である場合、支援されるA/Nペイロードサイズは2ビット以下である。この時、一つのSRプロセスに関する情報が追加される場合、端末は多重化容量が落ちるラージUCIペイロードサイズ用のPUCCHフォーマット(例えば、PF2/3/4)を使用するよりは、リソース選択方式を用いて該当SRプロセスに対するpositive/negative SRを表現することができる。しかし、A/N PUCCHリソースと複数のSRプロセスに対応するSR PUCCHリソースが重畳した場合は、端末はpositive/negative SR以外に、どのSRプロセスがpositive/negative SRであるかに関する情報も基地局に伝達する必要がある。この場合、SR情報を表現するために必要なビット数が多いので、SRプロセスが1個である場合のように、リソース選択方式を活用するよりは、3ビット以上のラージUCIペイロードサイズ用のPUCCHフォーマット(例えば、PF2/3/4)を使用した方がより効率的である。
[提案方法#5]スロット内のA/N PUCCHリソースとCSI PUCCHリソースが時間軸で(PUCCH内の全体或いは一部OFDMシンボルが)重畳する場合、以下のようにA/NとCSIの間の多重化を支援する方法
(1)A/N PUCCHリソースがDL割り当てベースではない場合
A.CSI PUCCHの送信開始時点を基準としてT0以前の時点まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがCSI PUCCHリソースと時間軸で重畳する場合
i.A/NとCSIを多重化してCSI PUCCHで送信
B.その他の場合
i.Opt.1:CSIをCSI PUCCHリソースを介して送信(A/N送信を省略)
ii.Opt.2:A/NをA/N PUCCHリソースを介して送信(CSI送信を省略)
(2)A/N PUCCHリソースがDL割り当てベースである場合
A.A/NとCSIを多重化して(全体UCI基準として再選択された)A/N PUCCHリソースを介して送信。但し、CSIを更新する時間が足りない場合は(例えば、CSI参照リソースがA/N PUCCHリソースの送信開始時点を基準としてT1以前の時点である場合は)、端末はCSIを更新しないことができる。
CSI参照リソースはCSI計算の参照となる時間リソースを意味する。(有効な)DLスロットは(端末に)DLスロットとして設定されたスロット及び/又は測定ギャップ(例えば、measurement gap)に含まれないスロット及び/又はCSI報告が行われるDL BWPと同一のDL BWPに含まれるスロットを意味する。
0は以下のうちの一つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの終了後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による復調に必要な端末処理時間又はそれに対応する値
(4)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(5)基地局と端末の間に予め約束した値(例えば、固定値)
1は以下のうちの一つである。T1は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるCSI計算及び報告のために必要な端末の処理時間又はそれに対応する値
(2)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(3)基地局と端末の間に予め約束した値(例えば、固定値)
NRシステムでは、DL割り当て(=DL scheduling DCI)に基づくPDSCHに対するA/NとCSIが多重化される場合、A/NとCSIに対する全体UCIペイロードサイズを基準として再選択されたA/N PUCCHリソースにより多重化されたA/NとCSIを送信することができる。多重化動作はA/N PUCCHとCSI PUCCHが時間軸で一部重畳する場合にも適用できる。但し、CSI参照リソースがA/N PUCCHの送信開始地点を基準として、端末処理時間であるT0以前に存在する場合には、端末がCSIを新しく更新することが難しい。従って、CSIを新しく更新することが難しい場合には、CSIを更新せず(但し、更新されないCSIは相変わらずA/Nと多重化して報告)、その他の場合にはCSIを更新してA/Nと多重化して報告する方法を提案する。
反面、A/NがDL割り当てに基づくPDSCHに対応しない場合は、端末はA/NとCSIをCSI PUCCHに多重化して送信することができる。CSI PUCCHによりA/Nを送信する場合、A/N送信のための最小のULタイミングが保証される場合にのみA/NとCSIの間の多重化を許容する。即ち、端末はCSI PUCCH送信開始時点を基準として、T1以前の時点まで受信した(或いは送信を開始した)PDSCH(及び/又はPDCCH)に対するA/N PUCCHがCSI PUCCHと重畳する場合にのみA/NとCSIの間の多重化を行い、そうではない場合にはA/N送信を省略して、CSI PUCCHのみを送信することができる。
[提案方法#6]端末が特定のPUCCH(又はPUSCH)リソース(以下、UL-CH1)内の一部の(OFDM)シンボルをパンクチャリングし、(OFDM)シンボルにおいて他のPUCCH(又はPUSCH)リソース(以下、UL-CH2)を送信することができる。この場合、UL-CH2に対する送信電力は以下のように適用できる。
(1)Opt.1
A.UL-CH2に対して(UL-CH1と)独立して設定された送信電力を適用
i.UL-CH2の送信電力がUL-CH1の送信電力を基準として一定の範囲内の値を有する場合、端末はUL-CH1のパンクチャリング後のリソースを(不連続に)全部送信する。
ii.UL-CH2の送信電力がUL-CH1の送信電力を基準として一定範囲外の値を有する場合、
1.UL-CH1のパンクチャリング後のリソース内にDM-RSが存在すると、UL-CH1の残りのリソースに対する送信を全部行う。ここで、DM-RSはデータ復調用の参照信号を意味する。
2.UL-CH1のパンクチャリング後のリソース内にDM-RSが存在すると、UL-CH1の残りのリソースに対する送信を省略
(2)Opt.2
A.UL-CH2に対してUL-CH1と同じ送信電力を適用
(3)Opt.3
A.UL-CH2に対して(UL-CH1と)独立して設定された送信電力がTXP1であり、UL-CH1に対する位相連続性(Phase continuity)を保証する最大の送信電力がTXP2であるとき、min(TXP1、TXP2)をUL-CH2に対する送信電力として適用。ここで、位相連続性はUL-CH1に対してパンクチャリング以前のリソースと以後のリソースの間にチャネル変化による位相差を除いた他の位相差がないことを意味する。
i.TXP2は端末が具現化により任意に選択する値である。
i.UL-CH2について設定された既存のUL PC(power control)規則を例外にすることができる。
一例として、端末がPUSCH送信中に緊急サービス(例えば、URLLC)に対するPUCCH送信を行わなければならない場合がある。この場合は、端末がPUSCH送信を既に進行中であるので(例えば、On-going transmission)、端末はPUSCH送信を中止してPUCCHを送信しなければならない。この時、PUSCH送信の観点では、PUCCHが送信されるOFDMシンボルのみがパンクチャリングされることができる。この場合、パンクチャリング区間内のPUCCH送信電力がPUSCHとは異なるので、PA(power amplifier)設定が初期化されてパンクチャリング区間を基準として前側に送信されたPUSCHリソースと後側に送信されたPUSCHリソースの間に(送信信号の)位相が変化することができる。この問題は、PUSCH送信中にPUCCH送信を行いながら端末の送信電力が大きく変更するためである。従って、本発明では、PUCCH(又はPUSCH)リソース(即ち、UL-CH1)内の一部(OFDM)シンボルをパンクチャリングし、(OFDM)シンボル内で他のPUCCH(又はPUSCH)リソース(即ち、UL-CH2)を送信するとき、端末は位相変化を減らすために、以下の動作を行うことができる。
(1)UL-CH2に対する送信電力をUL-CH1と同値に設定するか、又は
(2)UL-CH2に対して独立したUL電力制御を行い、UL-CH1の送信電力と比較して位相差を誘発する電力差が発生する場合には、UL-CH2の送信以後の残りのUL-CH1のリソースはDM-RSが存在する場合にのみ送信する動作を考えることができる。
PUCCH/PUSCH多重化
[提案方法#6.1]スロット内において、A/N PUCCHリソースとPUSCHリソースが時間軸で(PUCCH或いはPUSCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この場合、端末は(基準時点から)特定時点の前まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが時間軸でPUSCHリソースと重畳するか否かによって、A/NとULデータの間の多重化の有無(或いはA/NをPUSCHにUCIピギーバックするか否か)を決定する方法
但し、端末がA/NとULデータの間の多重化を行わない場合には、A/NとULデータのうちの一つの送信を省略できる。
一例として、端末はPUSCHの送信開始時点(例えば、開始シンボル)を基準として、T0以前の時点まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが時間軸でPUSCHと重畳するか否かによって、PUSCHへのA/Nピギーバックの有無を決定することができる。
(1)PUSCHの送信開始時点を基準として、T0以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがPUSCHリソースと時間軸で重畳する場合
-A/NとULデータを多重化して送信(即ち、A/NをPUSCHにUCIピギーバックして送信)(又はA/N PUCCHとPUSCHが時間軸でPUCCH或いはPUSCH内の全てのOFDMシンボルと完全に重畳する場合と同じUCI多重化規則に従う)
(2)(1)に該当しない場合(例えば、PUSCHの送信開始時点を基準として、T0以前の時点後に受信された(又は送信開始/終了された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが時間軸でPUSCHリソースと重畳するか、又はPUSCHの送信開始時点を基準として、T0以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが時間軸でPUSCHリソースと重畳しないか、又はPUSCHの送信開始時点を基準として、T0以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが存在しない場合)
-Opt.1:ULデータをPUSCHリソースを介して送信(A/N送信を省略)
-Opt.2:A/NをA/N PUCCHリソースを介して送信(PUSCH送信を省略)
但し、特定のバージョンの端末である場合、PUSCHに対するULグラントの受信後に受信された、DL割り当てによりスケジュールされたPDSCHに対するA/NはPUSCHへのUCIピギーバック対象ではない。
0は以下のうちの一つである。T0は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの終了後、A/N送信まで必要な端末処理時間又はそれに対応する値。端末能力によるUCI(PUCCH)送信のために必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値。又は、端末能力によるUCI(PUCCH)送信のために必要な端末処理時間又はそれに対応する値
(3)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による(特定の)UCI送信のために必要な端末処理時間又はそれに対応する値
(4)端末能力によるULグラントの受信後、PUSCH送信まで必要な端末処理時間又はそれに対応する値
(5)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(6)基地局と端末の間に予め約束した値(例えば、固定値)
[提案方法#6.1]はA/N PUCCH以外のPUCCHにも拡張して適用することができる。
NRシステムではPUCCHとPUSCHの間の開始(OFDM)シンボル(或いは開始時間)が一致する場合、PUCCHとPUSCHが時間軸で完全に重畳する場合と同一のUCI多重化規則を適用する端末動作が合議されている。この時、PUCCHとPUSCHが多重化して送信されるリソースがPUSCHリソースであるので、PUSCHリソースの送信開始前までPUCCH内の特定のUCI送信に必要な処理時間が満たさない場合には、該当PUCCHをPUSCHに多重化することができない。たとえ、PUCCHがHARQ-ACK送信のためのPUCCH(以下、A/N PUCCH)である場合、端末はPUSCHの送信開始時点を基準として(端末能力によるPDSCHの受信後、A/N送信まで必要な時間である)T0時間以前の時点まで受信されたPDSCH(及び/又はPDCCH)に対するA/NのみをPUSCHで送信することができる。従って、本発明はSR PUCCHとA/N PUCCHの間のUCI多重化規則([提案方法#1])のように、端末がPUSCH送信開始時点を基準として、T0以前の時点まで受信されたPDSCH(及び/又はPDCCH)に対するA/N PUCCHリソースが時間軸でPUSCHリソースと重畳するか否かによりA/Nに対するUCIピギーバックの有無を決定することができる。即ち、端末はPUSCH送信開始時点を基準として、T0以前の時点まで受信されたPDSCH(及び/又はPDCCH)に対するA/N PUCCHリソースが時間軸でPUSCHリソースと重畳すると、A/NをPUSCHにUCIピギーバックして送信し、そうではない場合には、A/Nに対する送信無しにPUSCHのみを送信することができる。図12は[提案方法#6.1]の動作を例示する。
[提案方法#6.1]の変形として、CSI PUCCHとPUSCHが時間軸で重畳した場合は、端末はCSI PUCCHを送信せず、PUSCHでCSIをUCIピギーバックすることができる。この時、CSI計算のための処理時間がPUSCH送信準備まで十分ではない場合は、端末はCSIを更新しないことができる。
A/N PUCCHリソースと他のULチャネルが時間軸で(一部或いは全体)重畳するとき、[提案方法#1]と[提案方法#6.1]を統合すると、端末が以下のように動作する。
(1)A/N PUCCHの送信開始時点(又はスロット)を基準として、T0以前の時点までA/N PUCCHと時間軸で重畳するULチャネルが設定/指示されない場合(例えば、ULチャネルはSRを送信するPUCCH又はUL-SCH TBを運ぶPUSCHである)
A.端末はA/NのみをA/N PUCCHリソースを介して送信(上記時点以後、A/N PUCCHと重畳するULチャネルが発生しても無視するか又は該当ULチャネル送信を省略/放棄)
(2)A/N PUCCHの送信開始時点(又はスロット)を基準として、T0以前の時点までA/N PUCCHと時間軸で重畳するULチャネルが設定/指示された場合(例えば、該当ULチャネルはSRを送信するPUCCH又はUL-SCH TBを運ぶPUSCHである)
A.ULチャネルが(特定の)UCI(以下、UCI-A)を送信するPUCCH(以下、PUCCH-A)である場合
i.PUCCH-Aリソースの送信開始時点を基準として、T1以前の時点まで受信された(又は送信が開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがPUCCH-Aリソースと時間軸で重畳する場合、A/NとUCI-Aを多重化して単一のPUCCHリソースを介して送信
ii.その他の場合(例えば、PUCCH-Aリソースの送信開始時点を基準として、T1以前の時点まで受信された(又は送信が開始した)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがPUCCH-Aリソースと時間軸で重畳しないか、又はPUCCH-Aリソースの送信開始時点を基準として、T1以前の時点まで受信された(又は送信が開始した)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが存在しない場合)、A/NとUCI-Aのうちの一つを選択して送信
-Opt.1:UCI-A(only)をPUCCH-Aリソースを介して送信(A/N送信を省略)
-Opt.2:A/N(only)をA/N PUCCHリソースを介して送信(UCI-A送信を省略)
-Opt.3:UCI-Aの状態によってOpt.1又はOpt.2を適用
B.ULチャネルがUL-SCH TB(又はULデータ)を送信するPUSCHである場合
i.PUSCHの送信開始時点を基準としてT2以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがPUSCHリソースと時間軸で重畳する場合
1.A/NとULデータを多重化して送信(即ち、A/NをPUSCHによりUCIピギーバック)(又はA/N PUCCHとPUSCHが時間軸でPUCCH或いはPUSCH内の全てのOFDMシンボルに対して完全に重畳する場合と同一のUCI多重化規則に従う)
ii.その他の場合(例えば、PUSCHリソースの送信開始時点を基準としてT2以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースがPUSCHリソースと時間軸で重畳しない場合、又はPUSCHリソースの送信開始時点を基準としてT2以前の時点まで受信された(又は送信開始された)PDSCH(及び/又はPDCCH)に対応する(又は該当PDSCH/PDCCHから指示された)A/N PUCCHリソースが存在しない場合)、A/NとUL-SCHのうちの一つを選択して送信
-Opt.1:UL-SCH(only)をPUSCHリソースを介して送信(A/N送信を省略)
-Opt.2:A/N(only)をA/N PUCCHリソースを介して送信(UL-SCH送信を省略)
0、T1、T2は以下のうちの一つである。T0、T1、T2は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による(特定の)UCI送信のために必要な端末処理時間又はそれに対応する値
(4)端末能力によるULグラントの受信後、PUSCH送信まで必要な端末処理時間又はそれに対応する値
(5)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(6)基地局と端末の間に予め約束した値(例えば、固定値)
本発明の変形により、スロットにおいてPUCCH-PUCCH又はPUCCH-PUSCHが時間軸で重畳する場合、端末は以下の(一般化した)UCI多重化規則を適用することができる。
(1)特定のUCIに対するPUCCHリソースの送信開始時点(又はスロット)を基準として、T0以前の時点までPUCCHリソースと時間軸で重畳するULチャネルが設定/指示されない場合(例えば、ULチャネルはPUCCH又はPUSCHである)
A.端末は特定のUCIのみをPUCCHリソースを介して送信(時点以後のPUCCHと重畳するULチャネルが発生しても無視或いは該当ULチャネルの送信を省略/放棄)
(2)特定のUCI1に対するPUCCHリソース(PUCCH1)が先に指示/指示された後、UCI1に対するPUCCHリソース(PUCCH1)の送信開始時点(又はスロット)を基準として、T0以前の時点までPUCCH1と時間軸で重畳する特定のUCI2に対するPUCCHリソース(PUCCH2)が設定/指示された場合
A.端末はUCI1とUCI2を多重化して単一のPUCCHリソースを介して送信
i.但し、単一のPUCCHリソースはPUCCH1とPUCCH2以外のリソースであることができる。
(3)特定のUCIに対するPUCCHリソースが先に設定/指示された後、特定のUCIに対するPUCCHリソースの送信開始時点(又はスロット)を基準として、T0以前の時点までPUCCHリソースと時間軸で重畳するUL-SCH TBに対するPUSCHリソースが設定/指示された場合
A.端末はUCIとUL-SCHを多重化してPUSCHリソースを介して送信(即ち、UCIピギーバック)
(4)特定のUL-SCHに対するPUSCHリソースの送信開始時点(又はスロット)を基準として、T1以前の時点までPUSCHと時間軸で重畳するULチャネルが設定/指示されていない場合(例えば、該当ULチャネルはPUCCHである)
A.端末は特定のUL-SCHのみをPUSCHリソースを介して送信(時点以後のPUSCHと重畳するULチャネルが発生しても無視或いは該当ULチャネルの送信を省略/放棄)
(5)特定のUL-SCHに対するPUSCHリソースが先に設定/指示された後、特定のUL-SCHに対するPUSCHリソースの送信開始時点(又はスロット)を基準として、T1以前の時点までPUSCHリソースと時間軸で重畳する特定のUCIに対するPUCCHリソースが設定/指示された場合
A.端末はUCIとUL-SCH TBを多重化してPUSCHリソースを介して送信(即ち、UCIピギーバック)
0、T1は以下のうちの一つである。T0、T1は(OFDM)シンボル単位で示すことができる。
(1)端末能力によるPDSCHの受信後、PDSCHに対応するA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(2)端末能力によるPDCCHの受信後、PDCCHから指示されたA/N(PUCCH)送信まで必要な端末処理時間又はそれに対応する値
(3)端末能力による(特定の)UCI送信のために必要な端末処理時間又はそれに対応する値
(4)端末能力によるULグラントの受信後、PUSCH送信まで必要な端末処理時間又はそれに対応する値
(5)上位層(例えば、RRC)信号及び/又はDCIにより設定された値
(6)基地局と端末の間に予め約束した値(例えば、固定値)
特定のUCIがA/Nであるとき、該当UCIに対するPUCCHリソースが設定/指示される時点は、A/Nに対応するPDSCHの受信(終了)時点と見なされる。
特定のUCIに対するPUCCHリソースが先に設定/指示される動作は、上位層(例えば、RRC)信号に基づいて設定される動作を含む。例えば、上位層信号により予め設定されたPUCCHリソースは、DCIにより指示されたPUCCHリソースより常に先に設定/指示されたリソースと見なされることができる。例えば、UCI1とUCI2は、各々SRとA/Nであるか、又は各々(periodic)CSIとHARQ-ACKである。
但し、UCI1とUCI2に対して以下の多重化動作が適用される。
(1)UCI1=SR、UCI2=A/Nである場合
A.A/N PUCCHがPUCCHフォーマット0である場合
i.SRに対するUCI状態がPositive SRである場合
1.A/NをA/N PUCCHにCS/OCC/PRBオフセットが適用されたリソースを介して送信
ii.SRに対するUCI状態がnegative SRである場合
1.A/NをA/N PUCCHリソースを介して送信
B.A/N PUCCHがPUCCHフォーマット1である場合
i.SRに対するUCI状態がPositive SRである場合
1.A/NをSR PUCCHリソースを介して送信
A.但し、SR PUCCHがPUCCHフォーマット0である場合には、SRを送信せず、A/Nのみを送信することができる。
ii.SRに対するUCI状態がnegative SRである場合
1.A/NをA/N PUCCHリソースを介して送信
C.A/N PUCCHがPUCCHフォーマット2/3/4のうちの一つである場合
i.SRに対するUCI状態がPositive SR又はnegative SRである場合
1.SRを明示的ビットで表現してA/Nに付け加えてUCIペイロードを生成後、生成されたUCIをA/N PUCCHリソースを介して送信
(2)UCI1=CSI、UCI2=A/Nである場合
A.A/N PUCCHがDL割り当てにより指示された場合
i.A/NとCSIを多重化してA/N PUCCHリソースを介して送信
B.A/N PUCCHがDL割り当てにより指示されない場合
i.A/NとCSIを多重化してCSI PUCCHリソースを介して送信
[提案方法#7]スロット内において、A/N PUCCHリソースとPUSCHリソースが時間軸で(PUCCH或いはPUSCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この時、端末はA/N PUCCHの送信開始時点がPUSCHの送信時点より遅いことができる。この場合、端末は(ベストエフォート方式により)On-going PUSCH送信があれば、該当PUSCH送信を中断し、A/N PUCCHを介してA/Nを送信する。
さらにスロット内において、A/N PUCCHリソースとPUSCHリソースが時間軸で(PUCCH或いはPUSCH内の全体或いは一部のOFDMシンボルが)重畳することができる。この時、A/N PUCCHの送信開始時点がPUSCHの送信時点より早いことができる。この場合、端末は(ベストエフォート方式により)On-going PUCCH送信があれば、該当PUCCH送信を中断し、A/NをPUSCHによりピギーバックする。
端末がPUSCH送信を行った後に該当PUCCHと時間軸で一部重畳するA/N PUCCHリソースの存在を把握した場合は、端末は簡単な方法により該当A/N送信を省略することができる。しかし、端末が十分な能力があれば、できる限り(即ち、ベストエフォート方式により)現在進行中のPUSCH送信を中断し、A/NをA/N PUCCHリソースを介して送信しようとする。[提案方法#6.1]の動作により、端末はPUSCHとA/Nが衝突した場合にもA/N送信を最大限支援することができる。
[提案方法#8]NRシステムでは、A-CSI Only PUSCHに対する送信の有無を端末に確実に知らせるために、ULグラント内にA-CSI(Aperiodic CSI)の報告の有無を知らせるA-CSIトリガーフィールド以外に、PUSCH内のデータ(例:UL-SCH TB、簡単には、UL-SCH)の存在の有無を知らせるUL-SCH指示子が含まれる。例えば、A-CSIトリガーフィールドはNビットで構成され、UL-SCH指示子は1ビットで構成される。この時、UL-SCH指示子がUL-SCHがないと指示し、A-CSIトリガーフィールドがA-CSI報告があると指示すると、端末はA-CSI Only PUSCH送信が指示されたと判断する。しかし、UL-SCH指示子がUL-SCHがないと指示したが、A-CSIトリガーフィールドもA-CSI報告もないと指示すると、この場合に対する解釈が曖昧になる。従って、この提案では、UL-SCH指示子がUL-SCHがないことを指示し、A-CSIトリガーフィールドもA-CSI報告がないことを指示した場合、端末が以下のうちの一つに解釈する方法を提案する。
(1)UCI Only PUSCH without UL-SCHを送信。ここで、UCI Only PUSCH without UL-SCH送信は、ULデータなしに同一のスロット/時点内の送信が指示/設定されたUCIをPUSCHにピギーバックすることを含む。
(2)誤り状況であると判断(error case)。これにより、端末はPUSCH送信を期待しないことができる。ここで、PUSCH送信を期待しないことは、例えば、該当PUSCH送信を省略(Drop)するか、又は該当PUSCHをスケジュールするDCIを廃棄(discard)することを含む。DCIを廃棄することは、DCIにより指示された動作を従わない/行わないことを含む。
(3)PUSCHに対してUL-SCH(或いはULデータ)送信がないと指示され、A-CSI送信もないと指示された場合、端末は指示されたPUSCHリソースに特定のPUCCHに対するUCIを多重化してUCI Only PUSCH without UL-SCHを送信することができる。この時、UCIはHARQ-ACKのみが存在する場合、端末はPUSCHリソースによりHARQ-ACKのみを送信する。この場合、以下のようにHARQ-ACKにはPUSCH内の(利用可能な)全てのREが割り当てられる。例えば、PUSCHリソース領域にRSが送信されるシンボル或いはREを除いた全てのREが割り当てられることができる。HARQ-ACKは一般的な規則によって1番目のDM-RS以後のnon-DM-RS OFDMシンボルのみについてマッピングされるか(例:DMRS又はData Mapping Type Bである場合)、1番目のDM-RS以前のOFDMシンボルにもマッパイングされることができる(例:DMRS又はData Mapping Type Aである場合)。
(4)PUSCHに対してUL-SCH(或いはULデータ)送信がないと指示され、A-CSI送信もないと指示された場合、端末は指示されたPUSCHリソースを、UL-SCH(又はULデータ)を送信するがUCIピギーバックを許容しないPUSCHリソースと判断することができる。
(5)PUSCHをスケジュールするDCI内にUCIピギーバック(On/Off)フィールド(以下、フィールドA)とA-CSIトリガー(On/Off)フィールド(以下、フィールドB)がある場合、各フィールドの2つの状態の組み合わせである4個の状態で端末のPUSCHスケジューリング情報を表現することができる。例えば、フィールドAとフィールドBにより以下のようにPUSCHスケジューリング情報を表現することができる。ここで、フィールドAのOn/Offは、PUSCH内のUCIピギーバックが許容される場合(’On’)と、PUSCH内のUCIピギーバックが許容されない場合(’Off’)を意味する。また、フィールドBのOn/Offは、A-CSI報告送信を指示する場合(’On’)と、A-CSI報告送信を指示しない場合(’Off’)を意味する。
-フィールドA=’On’、フィールドB=’Off’
・PUSCH内にUL-SCHが存在し、A-CSI報告が存在せず、(PUSCHとの)UCI多重化条件を満たすPUCCHに対するUCIピギーバックを許容
-フィールドA=’On’、フィールドB=’On’
・PUSCH内にUL-SCHが存在し、A-CSI報告が存在し、(PUSCHとの)UCI多重化条件を満たすPUCCHに対するUCIピギーバックを許容
-フィールドA=’Off’、フィールドB=’Off’
・PUSCH内にUL-SCHが存在し、A-CSI報告が存在せず、(PUSCHとの)UCI多重化条件を満たすPUCCHに対するUCIピギーバックを許容しない
-フィールドA=’Off’、フィールドB=’On’
・PUSCH内にUL-SCHが存在せず、A-CSI報告が存在し、(PUSCHとの)UCI多重化条件を満たすPUCCHに対するUCIピギーバックを許容
[提案方法#9]端末が時間軸で重畳するPUCCH/PUSCHに対するUCI多重化を行うとき、PUCCH或いはPUSCHに対する柔軟なULタイミング設定によっては端末のプロセシング時間が足りないことができる。これを予防するために、(時間軸で)重畳したPUCCH(/PUSCH)に対するUCI多重化の有無を判断するために、以下の2つのタイムライン条件が考えられる(以下、多重化タイムライン条件)。
(1)HARQ-ACKに対応するPDSCHの最後のシンボルは、(時間軸で)重畳するPUCCH/PUSCHのうちの最も早いチャネルの開始シンボルからN1+={N1+d1}シンボル前に受信、及び/又は
(2)PUCCH又はPUSCH送信を指示する(例:トリガー)PDCCHの最後のシンボルは、(時間軸で)重畳するPUCCH/PUSCHのうちの最も早いチャネルの開始シンボルからN2+={N2+d2}シンボル前に受信
これに関連して、本発明の優先日前に公開された3GPP TS 38.213 V15.2.0(2018-06)(以下、38.213)に以下のように規定されている。
3GPP TS 38.213 V15.2.0(2018-06):Timeline for UCI Multiplexing
Figure 0007073520000004
ここで、この提案におけるN1+は38.213のN1+(=N1+1)+d1,1+d1,2に対応し、N2+は38.213のN2+(=N2+1)+d2,1に対応する。N1(又はN1)は端末能力によって定義された最小のPDSCHプロセシング時間を示し、N2(又はN2)は端末能力によって定義された最小のPUSCHプロセシング時間を示す。dx,xは0以上の定数であり、例えば、スケジュールされたシンボルの位置やBWPスイッチングなどを考慮して予め定義された値である。
表4及び表5は38.213に定義されたN1とN2を各々例示する。
Figure 0007073520000005
Figure 0007073520000006
図13はタイムライン条件を考慮したUCI多重化を例示する。図13を参照すると、端末は同一のスロットで複数のULチャネル(例:ULチャネル#1~#4)を送信する。ここで、UL CH#1はPDCCH#1によりスケジュールされたPUSCHである。またUL CH#2はPDSCHに対するHARQ-ACKを送信するためのPUCCHである。PDSCHはPDCCH#2によりスケジュールされ、UL CH#2のリソースもPDCCH#2により指示される。
この時、時間軸で重畳するULチャネル(例:ULチャネル#1~#3)が多重化タイムライン条件を満たす場合、端末は時間軸で重畳したULチャネル#1~#3に対してUCI多重化を行うことができる。具体的には、端末はPDSCHの最後のシンボルからUL CH#3の最初のシンボルがN1+d1の条件を満たすか否かを確認する。また端末はPDCCH#1の最後のシンボルからUL CH#3の最初のシンボルがN2+d2の条件を満たすか否かを確認する。多重化タイムライン条件を満たす場合、端末はULチャネル#1~#3に対してUCI多重化を行う(例:提案方法#1Cを参照)。反面、多重化タイムライン条件を満たさない場合は、端末はUCI多重化なしに、ULチャネルの送信動作を行うことができる。この場合、ULチャネル#1~#3は全て一緒に送信されるか、又はUCI/チャネル優先順位を考慮して、一部のULチャネルは送信がスキップ/省略され、一部のULチャネルのみが送信される。
一方、NRシステムは様々なOFDMニューマロロジー(例:SCS)を支援し、端末プロセシング時間はSCSによって以下を満たす値が与えられる。
(1)シンボル数(例:N1+)*シンボル当たりのサンプル数*サンプリング時間(例:SCSが15kHzである時のサンプリング時間)*2-u
(2)シンボル数(例:N2+)*シンボル当たりのサンプル数*サンプリング時間(例:SCSが15kHzである時のサンプリング時間)*2-u
ここで、シンボル当たりのサンプル数は(2048+144)であり、SCSが15kHzである時のサンプリング時間は1/(2048*15000)である。2048はFFTサイズを示し、144はCPを構成するサンプル数を例示する。uは表1を参照することができる。
タイムライン条件において、uは(スロット内で)時間軸で重畳するULチャネルのSCSに基づいて決定される。ここで、ULチャネルはPUCCH/PUSCHを含む。この時、時間軸で重畳するPUCCH/PUSCHに対して適用されたOFDMニューマロロジー(例:SCS)が互いに同一である場合は、N1+、N2+に適用されるSCSが明らかである。しかし、時間軸で重畳するPUCCH/PUSCHに対して適用されたOFDMニューマロロジーが異なる場合には、N1+、N2+に適用されるSCSが不明である。ここで、PUCCH/PUSCHはPUCCH及び/又はPUSCHを意味する。
従って、この発明では、N1+、N2+に適用されるSCSを以下のうちのいずれかの方式で決定する方法を提案する。
(1)Opt.1:N1+、N2+に対して(時間軸で)重畳する全てのULチャネルのSCSのうち、最小のSCSを適用する。Opt.1において、最小のSCSを適用することは、相対的にN1+、N2+に適用されるシンボルサイズを大きく設定することにより、タイムライン条件を保守的に適用する方法である。
(2)Opt.2:N1+、N2+に対して(時間軸で)重畳する全てのULチャネルのうち、最も早いチャネルのSCSを適用する。
(3)Opt.3:N1+に対しては、A/N PUCCH(或いはA/Nを含むULチャネル)のSCSを適用する。一方、N2+に対しては、PDCCHで送信指示される全てのULチャネル(例:PUSCH)のうち、最小SCS(或いは最も早いULチャネルのSCS)を適用する。A/N PUCCHはHARQ-ACKの送信目的として設定/指示されたPUCCHを意味する。
一方、NRシステムでは、PDCCH、PDSCH及びULチャネル(例:PUCCH/PUSCH)のSCSが全部異なることができる。これにより、端末プロセシング時間はPDCCH SCS、PDSCH SCS及びULチャネルのSCSを全て考慮して決定される。例えば、端末プロセシング時間の計算に使用されるSCS(即ち、u)は、PDCCH SCS、PDSCH SCS及びULチャネルのSCSの関数により与えられるか、又はこれらのうちの一つの値により与えられる。
図14は本発明により制御情報を送信する方法を例示する。
図14を参照すると、端末は基地局からPDSCHを受信する(S1702)。ここで、PDSCHはPDCCH(例:DCIフォーマット1_0、1_1)によりスケジュールされる。図4を参照すると、PDCCHの受信時点からK0スロット後にPDSCH受信時点からK1スロット後にPDSCHに関する応答情報(例:HARQ-ACK応答)が第1ULチャネル(例:PUCCH)を介して送信される。第1ULチャネルリソースはPDCCH内のPRIにより指示される。一方、第1ULチャネルの送信が指示されたスロットに複数のULチャネルが割り当てられることができる。複数のULチャネルは複数のPUCCHを含む。また複数のULチャネルはさらに一つ以上のPUSCHを含む。この場合、端末はUCI多重化の有無を判断するために、(i)PDSCHと、(ii)時間軸で重畳する複数のULチャネルのうちの最も早いULチャネルとの間の時間間隔が基準時間を満たすか否かを確認する(S1704)。ここで、時間間隔は、(i)PDSCHの最後のシンボルと、(ii)最も早いULチャネルの1番目のシンボルとの間隔に基づいて決定される。また複数のULチャネルはPDSCHに関する応答情報のための第1ULチャネルを含む。その後、端末は基準時間を満たしたか否かによって、複数のULチャネルに関連するUCIを一つのULチャネルで多重化することができる(S1706)。
ここで、基準時間はシンボル数とSCSに基づいて決定され、SCSは複数のULチャネルに対する複数のSCSのうちの最小値を含む。ここで、シンボルの長さはSCSに基づいて決定され、シンボルの長さとSCSは反比例する。例えば、基準時間は以下の値に基づいて決定される。
-シンボル数(例:N1+)*シンボル当たりのサンプル数*サンプリング時間(例:SCSが15kHzである時のサンプリング時間)*2-u
ここで、N1+はPDSCH処理に必要な最小プロセシング時間を示し、uは0以上の整数であって、SCSに対応するインデックスを示す(表1を参照)。
最も早いULチャネルのSCSは、複数のULチャネルに対する複数のSCSのうちの最小値より大きい。時間間隔が基準時間より大きい場合、応答情報を含むUCIは一つのULチャネルに多重化されて送信され、時間間隔が基準時間より小さいか又は等しい場合は、端末は時間軸で重なる複数のULチャネルに対してUCI多重化を行わない。従って、PDSCHに関する応答情報は多重化なしに第1ULチャネルを介して送信される。
また複数のULチャネルがPDCCHによりスケジュールされたPUSCHを含む場合、端末はUCI多重化の有無を判断するために、(i)PDCCHと、(ii)最も早いULチャネルとの間の時間間隔が追加基準時間を満たすか否かをさらに確認する。この場合、追加基準時間を満たさないと、UCI多重化が行われない。例えば、追加基準時間は以下の値に基づいて決定される。
-シンボル数(例:N2+)*シンボル当たりのサンプル数*サンプリング時間(例:SCSが15kHzである時のサンプリング時間)*2-u
ここで、N2+はPUSCHの準備に必要な最小プロセシング時間を示し、uは0以上の整数であって、SCSに対応するインデックスを示す(表1を参照)。
図15は本発明によるタイムライン条件を考慮したUCI多重化を例示する。図15を参照すると、端末は同一のスロットにおいて複数のULチャネル(例:ULチャネル#1~#4)を送信する。ここで、UL CH#1はPDCCH#1によりスケジュールされたPUSCHである。またUL CH#2はPDSCHに対するHARQ-ACKを送信するためのPUCCHである。PDSCHはPDCCH#2によりスケジュールされ、UL CH#2のリソースもPDCCH#2により指示される。この時、UL CH#1~#3のSCSは各々u=1(u1)、u=0(u0)及びu=2(u2)であると仮定する(表1を参照)。
この時、時間軸で重畳するULチャネル(例:ULチャネル#1~#3)が多重化タイムライン条件を満たす場合、端末は時間軸で重畳するULチャネル#1~#3に対してUCI多重化を行う。具体的には、端末はPDSCHの最後のシンボルからUL CH#3の最初シンボルがN1+d1の条件を満たすか否かを確認する。また端末はPDCCH#1の最後のシンボルからUL CH#3の最初のシンボルがN2+d2の条件を満たすか否かを確認する。一方、{N1+d1}及び{N2+d2}には、UL CH#1~#3のSCSのうちの最小のSCSが適用される(即ち、UL CH#1;u=0)。多重化タイムライン条件を満たす場合、端末はULチャネル#1~#3に対してUCI多重化を行うことができる(例:提案方法#1Cを参照)。反面、多重化タイムライン条件を満たさない場合、端末はUCI多重化なしに、ULチャネルの送信動作を行うことができる。この場合、ULチャネル#1~#3は全て一緒に送信されるか、又はUCI/チャネル優先順位を考慮して、一部のULチャネルは送信がスキップ/省略され、一部のULチャネルのみが送信される。例えば、UCIがHARQ-ACK応答とCSIがある場合、UCI優先順位に従ってCSI送信がスキップ/省略されることができる。
[提案方法#10]NRシステムにおいて、基地局は端末に複数のSRリソースを設定する。SRリソースがPUCCHフォーマット1のリソースである場合、端末は同時送信が指示されたK個のSRリソースのうち、(優先順位が高い)1個のSRリソースのみを選択して送信する(例:チャネル/リソース選択)。この時、K値によって基地局でSR受信のために仮定する仮定(hypothesis)の数が増加し、UCI送信性能が低下することができる。従って、この提案では、端末に一つ以上のK個のSRリソースが(時間上重畳するように)設定され、以下のうちのいずれかの場合について、K値の関数で表現される(或いはK値に比例する)電力オフセットをPUCCH送信に反映する方法を提案する。
(1)Case 1:K個のSRリソースのうちの一つのSRリソースを選択して送信する場合
(2)Case 2:K個のSRリソース及びA/Nリソースのうちの一つのリソースを選択して該当リソースでA/Nを送信する場合
ここで、電力オフセットはK値に比例する。例えば、電力オフセットはK(又は、K-1)又はlog2(K)(又は、log2(K-1))又はceil(log2(K))(又は、ceil(log2(K-1))の関数である。ceil()は切り上げ関数である。これにより、PUCCH送信電力はK値に比例して増加する。
ここで、2つのケースに対する電力オフセットは互いに異なる形態である。Case2の場合、さらにA/Nが送信されるので、Case 1に比較して相対的に大きい電力オフセットが適用される。またこの提案はSRとA/Nに対して割り当てられたPUCCHリソースがPUCCHフォーマット1である場合に限られる。
図16は本発明に適用される通信システム1を例示する。
図16を参照すると、本発明に適用される通信システム1は、無線機器、基地局及びネットワークを含む。ここで、無線機器は無線アクセス技術(例えば、5G NR、LTE)を用いて通信を行う機器を意味し、通信/無線/5G機器とも称される。これに限られないが、無線機器はロボット100a、車両100b-1,100b-2、XR(eXtended Reality)機器100c、携帯機器(Hand-held Device)100d、家電100e、IoT(Internet of Thing)機器100f及びAIサーバ/機器400を含む。例えば、車両は無線通信機能が備えられた車両、自律走行車両、車両間通信を行える車両などを含む。ここで、車両はUAV(Unmanned Aerial Vehicle)(例えば、ドローン)を含む。XR機器はAR(Augmented Reality)/VR(Virtual Reality)/MR(Mixed Reality)機器を含み、HMD(Head-Mounted Device)、車両に備えられたHUD(Head-Up Display)、TV、スマートホン、コンピュータ、ウェアラブルデバイス、家電機器、デジタル看板、車両、ロボットなどの形態で具現化される。携帯機器はスマートホン、スマートパッド、ウェアラブル機器(例えば、スマートウォッチ、スマートグラス)、コンピュータ(例えば、ノートブックパソコンなど)などを含む。家電はTV、冷蔵庫、洗濯機などを含む。IoT機器はセンサ、スマートメータなどを含む。例えば、基地局、ネットワークは無線機器にも具現化され、特定の無線機器200aは他の無線機器に基地局/ネットワークノードで動作することもできる。
無線機器100a~100fは基地局200を介してネットワーク300に連結される。無線機器100a~100fにはAI(Artificial Intelligence)技術が適用され、無線機器100a~100fはネットワーク300を介してAIサーバ400に連結される。ネットワーク300は3Gネットワーク、4G(例えば、LTE)ネットワーク又は5G(例えば、NR)ネットワークなどを用いて構成される。無線機器100a~100fは基地局200/ネットワーク300を介して互いに通信できるが、基地局/ネットワークを介することなく、直接通信することもできる(例えば、サイドリンク通信)。例えば、車両100b-1、100b-2は直接通信することができる(例えば、V2V(Vehicle to Vehicle)/V2X(Vehicle to everything)通信)。またIoT機器(例えば、センサ)は他のIoT機器(例えば、センサ)又は他の無線機器100a~100fと直接通信することができる。
無線機器100a~100f/基地局200、基地局200/基地局200の間には無線通信/連結150a、150b、150cが行われる。ここで、無線通信/連結は上り/下りリンク通信150aとサイドリンク通信150b(又は、D2D通信)、基地局間の通信150c(例えば、relay、IAB(Integrated Access Backhaul)のような様々な無線アクセス技術により行われる(例えば、5G NR)。無線通信/連結150a、150b、150cにより無線機器と基地局/無線機器、基地局と基地局は互いに無線信号を送信/受信することができる。例えば、無線通信/連結150a、150b、150cは様々な物理チャネルを介して信号を送信/受信することができる。このために、本発明の様々な提案に基づいて、無線信号の送信/受信のための様々な構成情報の設定過程、様々な信号処理過程(例えば、チャネル符号化/復号、変調/復調、リソースマッピング/デマッピングなど)、リソース割り当て過程のうちのいずれか1つが行われる。
図17は本発明に適用可能な無線機器を例示する。
図17を参照すると、第1無線機器100と第2無線機器200は様々な無線アクセス技術(例えば、LTE、NR)により無線信号を送受信する。ここで、{第1無線機器100、第2無線機器200}は図16の{無線機器100a~100f、基地局200}及び/又は{無線機器100a~100f、無線機器100a~100f}に対応する。
第1無線機器100は1つ以上のプロセッサ102及び1つ以上のメモリ104を含み、さらに1つ以上の送受信機106及び/又は1つ以上のアンテナ108を含む。プロセッサ102はメモリ104及び/又は送受信機106を制御し、この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートを具現化するように構成される。例えば、プロセッサ102はメモリ104内の情報を処理して第1情報/信号を生成した後、送受信機106で第1情報/信号を含む無線信号を送信する。またプロセッサ102は送受信機106で第2情報/信号を含む無線信号を受信した後、第2情報/信号の信号処理から得た情報をメモリ104に格納する。メモリ104はプロセッサ102に連結され、プロセッサ102の動作に関連する様々な情報を格納する。例えば、メモリ104はプロセッサ102により制御されるプロセスのうちの一部又は全部を行うか、又はこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートを行うための命令を含むソフトウェアコードを格納する。ここで、プロセッサ102とメモリ104は無線通信技術(例えば、LTE、NR)を具現化するように設計された通信モデム/回路/チップの一部である。送受信機106はプロセッサ102に連結され、1つ以上のアンテナ108により無線信号を送信及び/又は受信する。送受信機106は送信機及び/又は受信機を含む。送受信機106はRF(radio Frequency)ユニットとも混用することができる。本発明において、無線機器は通信モデム/回路/チップを意味することもできる。
第2無線機器200は1つ以上のプロセッサ202及び1つ以上のメモリ204を含み、さらに1つ以上の送受信機206及び/又は1つ以上のアンテナ208を含む。プロセッサ202はメモリ204及び/又は送受信機206を制御し、この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートを具現化するように構成される。例えば、プロセッサ202はメモリ204内の情報を処理して第3情報/信号を生成した後、送受信機206で第3情報/信号を含む無線信号を送信する。またプロセッサ202は送受信機206で第4情報/信号を含む無線信号を受信した後、第4情報/信号の信号処理から得た情報をメモリ204に格納する。メモリ204はプロセッサ202に連結され、プロセッサ202の動作に関連する様々な情報を格納する。例えば、メモリ204はプロセッサ202により制御されるプロセスのうちの一部又は全部を行うか、又はこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートを行うための命令を含むソフトウェアコードを格納する。ここで、プロセッサ202とメモリ204は無線通信技術(例えば、LTE、NR)を具現化するように設計された通信モデム/回路/チップの一部である。送受信機206はプロセッサ202に連結され、1つ以上のアンテナ208により無線信号を送信及び/又は受信する。送受信機206は送信機及び/又は受信機を含む。送受信機206はRFユニットとも混用することができる。本発明において、無線機器は通信モデム/回路/チップを意味することもできる。
以下、無線機器100,200のハードウェア要素についてより具体的に説明する。これに限られないが、1つ以上のプロトコル層が1つ以上のプロセッサ102,202により具現化される。例えば、1つ以上のプロセッサ102,202は1つ以上の層(例えば、PHY、MAC、RLC、PDCP、RRC、SDAPのような機能層)を具現化する。1つ以上のプロセッサ102,202はこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートによって1つ以上のPDU(Protocol Data Unit)及び/又は1つ以上のSDU(Service Data Unit)を生成する。1つ以上のプロセッサ102,202はこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートによってメッセージ、制御情報、データ又は情報を生成する。1つ以上のプロセッサ102,202はこの明細書に開示された機能、手順、提案及び/又は方法によってPDU、SDU、メッセージ、制御情報、データ又は情報を含む信号(例えば、ベースバンド信号)を生成して、1つ以上の送受信機106,206に提供する。1つ以上のプロセッサ102,202は1つ以上の送受信機106,206から信号(例えば、ベースバンド信号)を受信して、この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートによってPDU、SDU、メッセージ、制御情報、データ又は情報を得ることができる。
1つ以上のプロセッサ102,202はコントローラ、マイクロコントローラ、マイクロプロセッサ又はマイクロコンピュータとも称される。1つ以上のプロセッサ102,202はハードウェア、ファームウェア、ソフトウェア又はこれらの組み合わせにより具現化される。一例として、1つ以上のASIC(Application Specific Integrated Circuit)、1つ以上のDSP(Digital Signal Processor)、1つ以上のDSPD(Digital Signal Processing Device)、1つ以上のPLD(Programmable Logic Device)又は1つ以上のFPGA(Field Programmable Gate Arrays)が1つ以上のプロセッサ102,202に含まれる。この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートはファームウェア又はソフトウェアを使用して具現化され、ファームウェア又はソフトウェアはモジュール、手順、機能などを含むように具現化される。この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートを行うように設定されたファームウェア又はソフトウェアは1つ以上のプロセッサ102,202に含まれるか、又は1つ以上のメモリ104,204に格納されて1つ以上のプロセッサ102,202により駆動される。この明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートはコード、命令語(instruction)及び/又は命令語の集合の形態でファームウェア又はソフトウェアを使用して具現化される。
1つ以上のメモリ104,204は1つ以上のプロセッサ102,202に連結され、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び/又は命令を格納することができる。1つ以上のメモリ104,204はROM、RAM、EPROM、フラッシメモリ、ハードドライブ、レジスター、キャッシュメモリ、コンピュータ読み取り格納媒体及び/又はこれらの組み合わせにより構成される。1つ以上のメモリ104,204は1つ以上のプロセッサ102,202の内部及び/又は外部に位置する。また、1つ以上のメモリ104,204は有線又は無線連結のような様々な技術により1つ以上のプロセッサ102,202に連結される。
1つ以上の送受信機106,206は1つ以上の他の装置にこの明細書における方法及び/又はフローチャートなどで言及されたユーザデータ、制御情報、無線信号/チャネルなどを送信することができる。1つ以上の送受信機106,206は1つ以上の他の装置からこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートなどで言及されるユーザデータ、制御情報、無線信号/チャネルなどを受信することができる。例えば、1つ以上の送受信機106,206は1つ以上のプロセッサ102,202に連結され、無線信号を送受信することができる。例えば、1つ以上のプロセッサ102,202は1つ以上の送受信機106,206が1つ以上の他の装置にユーザデータ、制御情報又は無線信号を送信するように制御することができる。また、1つ以上のプロセッサ102,202は1つ以上の送受信機106,206が1つ以上の他の装置からユーザデータ、制御情報又は無線信号を受信するように制御することができる。また、1つ以上の送受信機106,206は1つ以上のアンテナ108,208に連結され、1つ以上の送受信機106,206は1つ以上のアンテナ108,208によりこの明細書に開示された説明、機能、手順、提案、方法及び/又はフローチャートなどで言及されるユーザデータ、制御情報、無線信号/チャネルなどを送受信するように設定される。この明細書において、1つ以上のアンテナは複数の物理アンテナであるか、複数の論理アンテナ(例えば、アンテナポート)である。1つ以上の送受信機106,206は受信されたユーザデータ、制御情報、無線信号/チャネルなどを1つ以上のプロセッサ102,202を用いて処理するために、受信された無線信号/チャネルなどをRFバンド信号からベースバンド信号に変換する(Convert)。1つ以上の送受信機106,206は1つ以上のプロセッサ102,202を用いて処理されたユーザデータ、制御情報、無線信号/チャネルなどをベースバンド信号からRFバンド信号に変換する。このために、1つ以上の送受信機106,206は(アナログ)オシレーター及び/又はフィルターを含む。
図18は本発明に適用される無線機器の他の例を示す。無線機器は使用例/サービスによって様々な形態で具現化される(図16を参照)。
図18を参照すると、無線機器100,200は図17の無線機器100,200に対応し、様々な要素(element)、部品(component)、ユニット/部及び/又はモジュールで構成される。例えば、無線機器100,200は通信部110、制御部120、メモリ部130及び追加要素140を含む。通信部は通信回路112及び送受信機114を含む。例えば、通信回路112は図17における1つ以上のプロセッサ102,202及び/又は1つ以上のメモリ104,204を含む。例えば、送受信機114は図17の1つ以上の送受信機106,206及び/又は1つ以上のアンテナ108,208を含む。制御部120は通信部110、メモリ部130及び追加要素140に電気的に連結され、無線機器の諸般の動作を制御する。例えば、制御部120はメモリ部130に格納されたプログラム/コード/命令/情報に基づいて無線機器の電気的/機械的動作を制御する。また制御部120はメモリ部130に格納された情報を通信部110により外部(例えば、他の通信機器)に無線/有線インターフェースにより送信するか、又は通信部110により外部(例えば、他の通信機器)から無線/有線インターフェースにより受信された情報をメモリ部130に格納する。
追加要素140は無線機器の種類によって様々に構成される。例えば、追加要素140はパワーユニット/バッテリー、入出力部(I/O unit)、駆動部及びコンピュータ部のうち、いずれか1つを含む。これに限られないが、無線機器はロボット(図16、100a)、車両(図16、100b-1、100b-2)、XR機器(図16、100c)、携帯機器(図16、100d)、家電(図16、100e)、IoT機器(図16、100f)、デジタル放送用端末、ホログラム装置、公共安全装置、MTC装置、医療装置、フィンテック装置(又は金融装置)、保安装置、気候/環境装置、AIサーバ/機器(図16、400)、基地局(図16、200)及びネットワークノードなどの形態で具現化される。無線機器は使用例/サービスによって移動可能であるか、又は固定した場所で使用される。
図18において、無線機器100,200内の様々な要素、部品、ユニット/部及び/又はモジュールは全体が有線インターフェースにより互いに連結されるか、又は少なくとも一部が通信部110により無線連結される。例えば、無線機器100,200内で制御部120と通信部110は有線連結され、制御部120と第1ユニット(例えば、130、140)は通信部110により無線連結される。また無線機器100,200内の各要素、部品、ユニット/部及び/又はモジュールは1つ以上の要素をさらに含む。例えば、制御部120は1つ以上のプロセッサの集合で構成される。例えば、制御部120は通信制御プロセッサ、アプリケーションプロセッサ(Application PROCESSOR)、ECU(Electronic control Unit)、グラフィック処理プロセッサ、メモリ制御プロセッサなどの集合で構成される。他の例として、メモリ部130はRAM(Random Access Memory)、DRAM(Dynamic RAM)、ROM(Read Only Memory)、フラッシュメモリ(flash Memory)、揮発性メモリ(volatile Memory)、非揮発生メモリ及び/又はこれらの組み合わせで構成される。
図19は本発明に適用される車両又は自律走行車両を例示する図である。車両又は自律走行車両は移動型ロボット、車両、電車、有人/無人飛行体(Aerial Vehicle、AV)、船舶などで具現化される。
図19を参照すると、車両又は自律走行車両100はアンテナ部108、通信部110、制御部120、駆動部140a)、電源供給部140b、センサ部140c及び自律走行部140dを含む。アンテナ部108は通信部110の一部で構成される。ブロック110/130/140a~140dは各々図18におけるブロック110/130/140に対応する。
通信部110は他の車両、基地局(例えば、基地局、路辺基地局(Road Side unit)など)、サーバなどの外部機器と信号(例えば、データ、制御信号など)を送受信する。制御部120は車両又は自律走行車両100の要素を制御して様々な動作を行う。制御部120はECU(Electronic control Unit)を含む。駆動部140aにより車両又は自律走行車両100が地上で走行する。駆動部140aはエンジン、モータ、パワートレイン、車輪、ブレーキ、ステアリング装置などを含む。電源供給部140bは車両又は自律走行車両100に電源を供給し、有線/無線充電回路、バッテリーなどを含む。センサ部140cは車両状態、周辺環境情報、ユーザ情報などを得ることができる。センサ部140cはIMU(inertial measurement unit)センサ、衝突センサ、ホイールセンサ(wheel sensor)、速度センサ、傾斜センサ、重量感知センサ、ヘッディングセンサ(heading sensor)、ポジションモジュール(position module)、車両前進/後進センサ、バッテリーセンサ、燃料センサ、タイヤセンサ、ステアリングセンサ、温度センサ、湿度センサ、超音波センサ、照度センサ、ペダルポジションセンサなどを含む。自律走行部140dは走行中の車線を維持する技術、車間距離制御装置(adaptive cruise control)のように速度を自動に調節する技術、所定の経路によって自動走行する技術、目的地が設定されると自動に経路を設定して走行する技術などを具現化する。
一例として、通信部110は外部サーバから地図データ、交通情報データなどを受信する。自律走行部140dは得られたデータに基づいて自律走行経路とドライブプランを生成する。制御部120はドライブプランに従って車両又は自律走行車両100が自律走行経路に移動するように駆動部140aを制御する(例えば、速度/方向調節)。通信部110は自律走行中に外部サーバから最新交通情報データを非周期的に得る、また、周りの車両から周りの交通情報データを得る。またセンサ部140cは自律走行中に車両状態、周辺環境情報を得る。自律走行部140dは新しく得たデータ/情報に基づいて自律走行経路とドライブプランを更新する。通信部110は車両位置、自律走行経路、ドライブプランなどに関する情報を外部サーバに伝達する。外部サーバは車両又は自律走行車両から集められた情報に基づいて、AI技術などを用いて交通情報データを予め予測し、予測された交通情報データを車両又は自律走行車両に提供することができる。
以上の実施例は、本発明の構成要素及び特徴を所定の形態で結合したものである。各構成要素又は特徴は、別に明示しない限り、選択的なものとして考慮され得る。各構成要素又は特徴は、他の構成要素や特徴と結合しない形態で実施されてもよく、また、一部の構成要素及び/又は特徴は結合されて本発明の実施例を構成してもよい。本発明の実施例で説明される動作の順序は変更されてもよい。ある実施例の一部の構成や特徴は、他の実施例に含まれてもよく、他の実施例の対応する構成又は特徴に代えてもよい。また、特許請求の範囲で明示的な引用関係を有しない請求項を結合して実施例を構成したり、出願後の補正によって新たな請求項として含むことができる。
本発明は、本発明の特徴を逸脱しない範囲で他の特定の形態に具体化できることは当業者にとって自明である。よって、前記の詳細な説明は、全ての面で制限的に解釈してはならなく、例示的なものとして考慮しなければならない。本発明の範囲は、添付の請求項の合理的解釈によって決定しなければならず、本発明の等価的範囲内での全ての変更は本発明の範囲に含まれる。
本発明は無線移動通信システムの端末機、基地局又はその他の装備に使用できる。

Claims (15)

  1. 無線通信システムにおいて通信装置が制御情報を送信する方法であって、
    PDSCH(Physical Downlink Shared Channel)を受信する段階と、
    (i)前記PDSCHと(ii)複数のUL(uplink)チャネルの最も早いものとの間の時間間隔が基準時間間隔と等しい又はより大きいことに基づいて、前記複数のULチャネルに関連するUCI(Uplink Control Information)を多重化する段階と、を含み、
    前記複数のULチャネルは、時間軸上でオーバーラップし、かつ、前記PDSCHに関する応答情報のための第1ULチャネルを含み、
    前記基準時間間隔は、(a)シンボルの数と(b)前記複数のULチャネルに対する複数のSCSの最小のSCS(Subcarrier Carrier Spacing)とに基づいて決定され、
    前記複数のULチャネルに関連する前記UCIは、前記時間間隔が前記基準時間間隔より小さいことに基づいて多重化されない、方法。
  2. 前記最も早いULチャネルのSCSは、前記複数のULチャネルに対する前記複数のSCSのうちの最小のものより大きい、請求項1に記載の方法。
  3. 前記応答情報を含むUCIは、前記時間間隔が前記基準時間間隔と等しい又はより大きいことに基づいて、一つのULチャネルで多重化及び送信され、
    前記時間間隔が前記基準時間間隔より小さいことに基づいて、
    前記応答情報は、多重化されずに前記第1ULチャネルで送信される、又は、
    前記複数のULチャネルの全ての信は、省略される、請求項1又は2に記載の方法。
  4. 前記時間間隔は、(i)前記PDSCHの最後のシンボルと(ii)前記最も早いULチャネルの1番目のシンボルとの間隔に基づいて決定される、請求項1~3のいずれか一項に記載の方法。
  5. 前記複数のULチャネルは、PUCCH(Physical Uplink Control Channel)を含む、請求項1~4のいずれか一項に記載の方法。
  6. PDCCH(Physical Downlink Control Channel)によりスケジュールされたPUSCH(Physical Uplink Shared Channel)を含む前記複数のULチャネルに基づいて、前記UCIは、(i)前記PDCCHと(ii)前記最も早いULチャネルとの間の時間間隔が追加基準時間間隔と等しい又はより大きいとき、前記PUSCHにさらに多重化される、請求項1~5のいずれか一項に記載の方法。
  7. シンボルの長さは、SCSに基づいて決定され、
    前記シンボルの長さ及び前記SCSは、互いに反比例する、請求項1~6のいずれか一項に記載の方法。
  8. 無線通信システム内の通信装置であって、
    メモリと、
    プロセッサと、を含み、
    前記プロセッサは、
    PDSCH(Physical Downlink Shared Channel)を受信し、
    (i)前記PDSCHと(ii)複数のUL(uplink)チャネルの最も早いものとの間の時間間隔が基準時間間隔と等しい又はより大きいことに基づいて、前記複数のULチャネルに関連するUCI(Uplink Control Information)を多重化するように構成され、
    前記複数のULチャネルは、時間軸上でオーバーラップし、かつ、前記PDSCHに関する応答情報のための第1ULチャネルを含み、
    前記基準時間間隔は、(a)シンボルの数と(b)前記複数のULチャネルに対する複数のSCSの最小のSCS(Subcarrier Carrier Spacing)とに基づいて決定され、
    前記複数のULチャネルに関連する前記UCIは、前記時間間隔が前記基準時間間隔より小さいことに基づいて多重化されない、通信装置。
  9. 前記最も早いULチャネルのSCSは、前記複数のULチャネルに対する前記複数のSCSのうちの最小のものより大きい、請求項8に記載の通信装置。
  10. 前記応答情報を含むUCIは、前記時間間隔が前記基準時間間隔と等しい又はより大きいことに基づいて、一つのULチャネルで多重化及び送信され、
    前記時間間隔が前記基準時間間隔より小さいことに基づいて、
    前記応答情報は、多重化されずに前記第1ULチャネルで送信される、又は、
    前記複数のULチャネルの全ての信は、省略される、請求項8又は9に記載の通信装置。
  11. 前記時間間隔は、(i)前記PDSCHの最後のシンボルと(ii)前記最も早いULチャネルの1番目のシンボルとの間隔に基づいて決定される、請求項8~10のいずれか一項に記載の通信装置。
  12. 前記複数のULチャネルは、PUCCH(Physical Uplink Control Channel)を含む、請求項8~11のいずれか一項に記載の通信装置。
  13. PDCCH(Physical Downlink Control Channel)によりスケジュールされたPUSCH(Physical Uplink Shared Channel)を含む前記複数のULチャネルに基づいて、前記UCIは、(i)前記PDCCHと(ii)前記最も早いULチャネルとの間の時間間隔が追加基準時間間隔と等しい又はより大きいとき、前記PUSCHにさらに多重化される、請求項8~12のいずれか一項に記載の通信装置。
  14. シンボルの長さは、SCSに基づいて決定され、
    前記シンボルの長さ及び前記SCSは、互いに反比例する、請求項8~13のいずれか一項に記載の通信装置。
  15. 前記通信装置は、自律走行車両の一部として含まれる、請求項8に記載の通信装置。
JP2020549544A 2018-08-09 2019-08-09 無線通信システムにおける無線信号の送受信方法及び装置 Active JP7073520B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862716945P 2018-08-09 2018-08-09
US62/716,945 2018-08-09
PCT/KR2019/010172 WO2020032753A1 (ko) 2018-08-09 2019-08-09 무선 통신 시스템에서 무선 신호 송수신 방법 및 장치

Publications (2)

Publication Number Publication Date
JP2021506195A JP2021506195A (ja) 2021-02-18
JP7073520B2 true JP7073520B2 (ja) 2022-05-23

Family

ID=69415030

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020549544A Active JP7073520B2 (ja) 2018-08-09 2019-08-09 無線通信システムにおける無線信号の送受信方法及び装置

Country Status (6)

Country Link
US (1) US11316650B2 (ja)
EP (1) EP3694134B1 (ja)
JP (1) JP7073520B2 (ja)
KR (1) KR102229988B1 (ja)
CN (1) CN111602363B (ja)
WO (1) WO2020032753A1 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109511168B (zh) * 2017-09-14 2021-06-15 华为技术有限公司 信号处理的方法、装置和可读存储介质
US11064514B2 (en) * 2018-08-10 2021-07-13 Qualcomm Incorporated Uplink collision handling for wireless communications
EP3855658A4 (en) * 2018-09-18 2021-09-08 Beijing Xiaomi Mobile Software Co., Ltd. PUCCH DETERMINATION METHOD AND DEVICE REQUIRING TRANSMISSION
CN111083782B (zh) * 2018-10-19 2023-09-08 荣耀终端有限公司 一种被用于无线通信的用户设备、基站中的方法和装置
US11258546B2 (en) * 2018-11-30 2022-02-22 Qualcomm Incorporated Acknowledgment feedback techniques in wireless communications
JP6804509B2 (ja) * 2018-12-27 2020-12-23 シャープ株式会社 端末装置、基地局装置、および、通信方法
US11705995B2 (en) * 2018-12-28 2023-07-18 Samsung Electronics Co., Ltd. Method and device for transmitting uplink control information
KR20200084607A (ko) * 2019-01-03 2020-07-13 삼성전자주식회사 무선 통신 시스템에서 단말의 전력 소모 감소를 위한 하향 제어 채널 수신 방법 및 장치
EP3922068A4 (en) * 2019-02-08 2022-09-07 QUALCOMM Incorporated TRANSMISSION OF GROUP PLANNING CONTROL INFORMATION VIA A SHARED DOWNLINK PHYSICAL CHANNEL
US11212821B2 (en) * 2019-04-02 2021-12-28 Lenovo (Singapore) Pte. Ltd. Method and apparatus for cancelling transmission based on overlapping transmission occasions
US11601935B2 (en) * 2020-08-28 2023-03-07 Trellisware Technologies, Inc. Multi-channel time-division multiplexing access methods and systems
US11937291B2 (en) * 2020-09-11 2024-03-19 Qualcomm Incorporated Dynamic multiplexing and prioritization for resolving a collision of physical uplink channels
JPWO2022074843A1 (ja) * 2020-10-09 2022-04-14
CN114828231A (zh) * 2021-01-18 2022-07-29 大唐移动通信设备有限公司 上行控制信息uci传输方法和装置
CN115052344A (zh) * 2021-03-08 2022-09-13 维沃移动通信有限公司 上行传输处理方法及终端
WO2022215271A1 (ja) * 2021-04-09 2022-10-13 株式会社Nttドコモ 端末、無線通信システム及び無線通信方法
US20230284223A1 (en) 2021-09-24 2023-09-07 Apple Inc. Multiplexing of Uplink Control Information
WO2023061646A1 (en) * 2021-10-14 2023-04-20 Sony Group Corporation Method for facilitating channel management

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010519838A (ja) 2007-02-23 2010-06-03 テレフオンアクチーボラゲット エル エム エリクソン(パブル) サブキャリア間隔の識別
US20170289733A1 (en) 2016-03-31 2017-10-05 Samsung Electronics Co., Ltd Method and apparatus for transmission of control and data in vehicle to vehicle communication

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010123893A1 (en) * 2009-04-22 2010-10-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting uplink control information for carrier aggregated spectrums
KR101753586B1 (ko) * 2010-02-03 2017-07-04 엘지전자 주식회사 무선 통신 시스템에서 제어 정보의 전송 방법 및 장치
KR101880460B1 (ko) * 2011-01-10 2018-07-20 엘지전자 주식회사 무선통신 시스템에서의 제어정보의 전송 방법 및 장치
EP3131215A4 (en) 2014-02-12 2017-11-08 LG Electronics Inc. Method for transmitting/receiving signal in wireless communication system, and apparatus therefor
CN105846977B (zh) * 2015-01-29 2021-02-02 北京三星通信技术研究有限公司 一种增强载波聚合系统的harq-ack传输方法和设备
WO2017218794A1 (en) * 2016-06-15 2017-12-21 Convida Wireless, Llc Upload control signaling for new radio
US10608856B2 (en) * 2016-06-16 2020-03-31 Samsung Electronics Co., Ltd. Transmission of reference signals in a communication system
KR102573653B1 (ko) * 2016-09-27 2023-09-05 삼성전자 주식회사 무선통신 시스템에서 프레임 구조 및 이를 이용한 송수신 방법 및 장치
US11528729B2 (en) * 2016-11-01 2022-12-13 Ntt Docomo, Inc. User terminal and radio communication method
US11283575B2 (en) * 2016-11-10 2022-03-22 Qualcomm Incorporated Sequence generation for systems supporting mixed numerologies
US10966223B2 (en) * 2018-01-22 2021-03-30 Apple Inc. Handling overlapping of PUCCH and PUSCH for new radio systems
KR102058701B1 (ko) * 2018-01-25 2019-12-23 엘지전자 주식회사 무선 통신 시스템에서 물리 상향 링크 제어 채널 상에서 다수의 상향 링크 제어 정보를 전송하는 방법 및 이를 위한 장치
US20190349917A1 (en) * 2018-05-11 2019-11-14 Qualcomm Incorporated Uplink control information multiplexing on physical uplink shared channels in new radio

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010519838A (ja) 2007-02-23 2010-06-03 テレフオンアクチーボラゲット エル エム エリクソン(パブル) サブキャリア間隔の識別
US20170289733A1 (en) 2016-03-31 2017-10-05 Samsung Electronics Co., Ltd Method and apparatus for transmission of control and data in vehicle to vehicle communication

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LG Electronics,Remaining issues on UCI multiplexing[online],3GPP TSG RAN WG1 Meeting #93 R1-1806623,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_93/Docs/R1-1806623.zip>,2018年05月21日
Panasonic,Discussion on UCI multiplexing[online],3GPP TSG RAN WG1 Meeting #93 R1-1806181,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_93/Docs/R1-1806181.zip>,2018年05月21日

Also Published As

Publication number Publication date
KR102229988B1 (ko) 2021-03-19
US20200344032A1 (en) 2020-10-29
US11316650B2 (en) 2022-04-26
JP2021506195A (ja) 2021-02-18
CN111602363B (zh) 2023-04-11
EP3694134B1 (en) 2022-02-16
KR20200062335A (ko) 2020-06-03
WO2020032753A1 (ko) 2020-02-13
EP3694134A4 (en) 2021-03-10
CN111602363A (zh) 2020-08-28
EP3694134A1 (en) 2020-08-12

Similar Documents

Publication Publication Date Title
JP7073520B2 (ja) 無線通信システムにおける無線信号の送受信方法及び装置
US20220174707A1 (en) Method and apparatus for transmitting or receiving wireless signals in wireless communication system
CN113678557B (zh) 发送或接收用于多传输块调度的信号的方法及其设备
CN113678556B (zh) 在无线通信系统中发送/接收无线信号的方法和装置
US20220124686A1 (en) Method for transmitting and receiving downlink control information between terminal and base station in wireless communication system and device for supporting same
CN114902602A (zh) 在无线通信系统中发送和接收信号的方法和设备
JP2022527747A (ja) 多重送信ブロックスケジューリングのための信号の送受信方法及びそのための装置
KR20230006832A (ko) 무선 통신 시스템에서 무선 신호 송수신 방법 및 장치
JP7385773B2 (ja) 無線通信システムにおいて無線信号の送受信方法及び装置
KR102588873B1 (ko) 무선 통신 시스템에서 신호를 송수신 하는 방법 및 이를 지원하는 장치
CN113748732B (zh) 发送和接收用于副链路通信的控制信息的方法和装置
CN115462162A (zh) 接收下行链路信道的方法、用户设备、处理装置、存储介质和计算机程序及发送下行链路信道的方法和基站
CN113424479B (zh) 在无线通信系统中发送和接收信号的方法和设备
CN117796118A (zh) 在无线通信系统中发送或接收信号的方法和装置
CN115088367A (zh) 发送和接收下行链路控制信道的方法及其装置
CN113748737B (zh) 发送和接收用于副链路通信的控制信息的方法和频带部分
EP4270845A1 (en) Method and apparatus for transmitting and receiving signal in wireless communication system
US20230199596A1 (en) Method for transmitting and receiving signal in wireless communication system, and apparatus for supporting same
CN115208541B (zh) 在无线通信系统中发送和接收无线信号的方法和设备
US20230254849A1 (en) Method and device for determining resource for wireless communication in nr v2x
US20210360615A1 (en) Method and apparatus for transmitting/receiving wireless signal in wireless communication system

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200603

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200603

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210824

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211122

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220420

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220511

R150 Certificate of patent or registration of utility model

Ref document number: 7073520

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150