US20180167933A1 - Base stations, user equipments, and related communication methods - Google Patents

Base stations, user equipments, and related communication methods Download PDF

Info

Publication number
US20180167933A1
US20180167933A1 US15/839,798 US201715839798A US2018167933A1 US 20180167933 A1 US20180167933 A1 US 20180167933A1 US 201715839798 A US201715839798 A US 201715839798A US 2018167933 A1 US2018167933 A1 US 2018167933A1
Authority
US
United States
Prior art keywords
pucch
pusch
transmission
uci
simultaneous
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.)
Granted
Application number
US15/839,798
Other versions
US10716100B2 (en
Inventor
Zhanping Yin
Toshizo Nogami
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.)
Sharp Corp
Original Assignee
Sharp Laboratories of America 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 Sharp Laboratories of America Inc filed Critical Sharp Laboratories of America Inc
Priority to PCT/US2017/065928 priority Critical patent/WO2018111948A1/en
Priority to US15/839,798 priority patent/US10716100B2/en
Assigned to SHARP LABORATORIES OF AMERICA, INC. reassignment SHARP LABORATORIES OF AMERICA, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NOGAMI, TOSHIZO, YIN, ZHANPING
Publication of US20180167933A1 publication Critical patent/US20180167933A1/en
Application granted granted Critical
Publication of US10716100B2 publication Critical patent/US10716100B2/en
Assigned to SHARP KABUSHIKI KAISHA, FG Innovation Company Limited reassignment SHARP KABUSHIKI KAISHA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SHARP LABORATORIES OF AMERICA, INC.
Assigned to SHARP KABUSHIKI KAISHA, SHARP CORPORATION reassignment SHARP KABUSHIKI KAISHA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FG Innovation Company Limited, SHARP KABUSHIKI KAISHA
Assigned to SHARP KABUSHIKI KAISHA reassignment SHARP KABUSHIKI KAISHA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SHARP CORPORATION, SHARP KABUSHIKI KAISHA
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H04W72/0413
    • 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
    • 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/0048Allocation of pilot signals, i.e. of signals known to the receiver
    • H04L5/0051Allocation of pilot signals, i.e. of signals known to the receiver of dedicated pilots, i.e. pilots destined for a single user or terminal
    • 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/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0231Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W72/1284
    • 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
    • H04L5/001Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT the frequencies being arranged in component carriers
    • 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/0014Three-dimensional division
    • H04L5/0023Time-frequency-space
    • 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/0032Distributed allocation, i.e. involving a plurality of allocating devices, each making partial allocation
    • H04L5/0035Resource allocation in a cooperative multipoint environment

Definitions

  • SLA3698P application The disclosure of the SLA3698P application is hereby incorporated fully by reference into the present application.
  • the present disclosure relates generally to communication systems. More specifically, the present disclosure relates to a base station apparatus, a user equipment apparatus and related communication methods.
  • Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts.
  • Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power).
  • multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.
  • CDMA code division multiple access
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • OFDMA orthogonal frequency division multiple access
  • SC-FDMA single-carrier frequency division multiple access
  • TD-SCDMA time division synchronous code division multiple access
  • the uplink control information carries hybrid-ARQ acknowledgements (HARQ-ACK), Channel-State Information (CSI), and Scheduling Request (SR).
  • HARQ-ACK hybrid-ARQ acknowledgements
  • CSI Channel-State Information
  • SR Scheduling Request
  • the UCI carries HARQ-ACK, SR, Channel Quality Indicator (CQI), Precoding Type Indicator (PTI), Precoding Matrix Indicator (PMI), and Rank Indication (RI).
  • NR new radio
  • the UCI carries HARQ-ACK, SR, Channel Quality Indicator (CQI), Precoding Type Indicator (PTI), Precoding Matrix Indicator (PMI), and Rank Indication (RI).
  • the CSI may include one or more of CQI, RI, PMI, PTI, and etc.
  • Multiple dimensions of CSI may be reported from one or more cells to support full-dimension multiple input multiple output (FD-MIMO) and Coordinated Multi Point (CoMP) operations.
  • FD-MIMO full-dimension multiple input multiple output
  • CoMP Coordinated Multi Point
  • SR and HARQ-ACK need to be transmitted outside of physical uplink shared channel (PUSCH) for latency reasons.
  • the CSI report in NR should be enhanced to support massive MIMO and beamforming methods.
  • multiple sets of CSI may be reported in NR.
  • a CSI feedback may include one or more of CQI, RI, PMI, PTI, beam index, and etc. At least two types of CSI reports may be supported, namely periodic CSI and aperiodic CSI reports.
  • a periodic CSI report can be configured semi-statically, while an aperiodic CSI report can be triggered with a CSI request from a base station. Therefore, physical uplink control signaling should be able to carry at least HARQ-ACKs, CSI reports (possibly including beamforming information), and SRs.
  • OFDMA Orthogonal Frequency Division Multiple Access
  • SC-FDMA Single Carrier Frequency Division Multiple Access
  • MIMO multiple-input multiple-output
  • FIG. 1 is a block diagram illustrating one implementation of one or more next generation NodeBs (gNBs) and one or more user equipments (UEs) in which systems and methods for UCI operations may be implemented.
  • gNBs next generation NodeBs
  • UEs user equipments
  • FIG. 2 is an example of a resource grid for a downlink.
  • FIG. 3 is an example of a resource grid for an uplink.
  • FIGS. 4A, 4B, 4C, and 4D show examples of several numerologies.
  • FIGS. 5A, 5B, 5C, and 5D show examples of subframe structures.
  • FIGS. 6A, 6B, 6C, 6D, 6E, and 6F show examples of slots and sub-slots.
  • FIGS. 7A, 7B, 7C, and 7D show examples of scheduling timelines.
  • FIGS. 8A and 8B show examples of downlink control channel monitoring regions.
  • FIGS. 9A and 9B show examples of downlink control channel each having more than one control channel elements.
  • FIGS. 10A, 10B, and 10C show examples of uplink control channel structures.
  • FIG. 11 is a block diagram illustrating one implementation of a gNB.
  • FIG. 12 is a block diagram illustrating one implementation of a UE.
  • FIG. 13A is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12 , for UCI reporting on PUCCH or PUSCH in case of channel overlap or collision on a single carrier or serving cell.
  • FIG. 13B is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12 , for reporting UCI.
  • FIG. 13C is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the gNB in FIG. 11 , for receiving UCI from a UE.
  • FIG. 14A is a schematic diagram illustrating an exemplary implementation of a NR short physical uplink control channel (PUCCH).
  • PUCCH physical uplink control channel
  • FIG. 14B is a schematic diagram illustrating an exemplary implementation of data and UCI multiplexing with short PUCCH formats.
  • FIG. 15 is a schematic diagram illustrating various types of PUSCH and short PUCCH overlapping or collision.
  • FIG. 16A is a schematic diagram illustrating exemplary implementations of prioritized short PUCCH transmission over PUSCH data.
  • FIG. 16B is a schematic diagram illustrating exemplary implementations of UCI multiplexing on PUSCH in the overlapping portions of PUSCH and short PUCCH.
  • FIG. 17 is a schematic diagram illustrating an exemplary implementation of simultaneous PUCCH and PUSCH transmission with prioritized short PUCCH transmission and PUSCH power scaling.
  • FIG. 18 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and long PUCCH overlapping or collision.
  • FIG. 19A is a schematic diagram illustrating an exemplary implementation of prioritized long PUCCH transmission over PUSCH data.
  • FIG. 19B is a schematic diagram illustrating an exemplary implementation of UCI multiplexing on PUSCH in the overlapping portions of PUSCH and long PUCCH.
  • FIG. 20 is a schematic diagram illustrating an exemplary implementation of a simultaneous PUCCH and PUSCH transmission with prioritized long PUCCH transmission and PUSCH power scaling.
  • a user equipment is described.
  • the UE is configured to report uplink control information (UCI).
  • the UE includes a processor, such as a higher layer processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported.
  • the instructions include transmitting the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and dropping the overlapping portion of the PUSCH.
  • the instructions further include determining a PUCCH format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB).
  • the PUCCH format is determined from a short PUCCH format and a long PUCCH format.
  • the PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies.
  • the channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
  • the information on whether the simultaneous PUCCH and PUSCH transmission is supported is either the UE's capability or a base station's configuration. When the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH.
  • a base station is described.
  • the base station is configured to acquire uplink control information (UCI) from a user equipment (UE).
  • the base station includes a processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE.
  • the instructions include receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not receiving the overlapping portion of the PUSCH.
  • a PUCCH format and a configuration of the PUCCH from the UE are determined based on a signaling from the base station.
  • the PUCCH format is determined from a short PUCCH format and a long PUCCH format.
  • the PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies.
  • the channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
  • the information on whether the simultaneous PUCCH and PUSCH transmission is supported is either the UE's capability or the base station's configuration. When the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the base station is configured to receive a non-overlapping portion of the PUSCH.
  • a method for reporting uplink control information (UCI) by a user equipment (UE) includes storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported.
  • the method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and dropping the overlapping portion of the PUSCH.
  • a method for receiving uplink control information (UCI) from a user equipment (UE) by a base station includes acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE.
  • the method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not receiving the overlapping portion of the PUSCH.
  • PUCCH physical uplink control channel
  • PUSCH physical uplink shared channel
  • a method for reporting uplink control information (UCI) by a user equipment (UE) in case of a channel collision between a physical uplink control channel (PUCCH) transmission and a physical uplink shared channel (PUSCH) transmission is described.
  • the UE includes a processor and a non-transitory machine-readable memory storing instructions executable by the processor. the method includes determining, by the processor, whether a simultaneous PUCCH and PUSCH transmission is supported.
  • the method includes performing one of (1) transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not transmitting the overlapping portion of the PUSCH, and (2) transmitting, by the UE, the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported includes determining a format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB), and determining a format and a configuration of the PUSCH based on a signaling from the gNB.
  • gNB next generation NodeB
  • the format of the PUCCH comprises a short PUCCH format and a long PUCCH format, the short PUCCH format and long PUCCH format each have a waveform and a numerology.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported comprises determining whether a format of the PUCCH and a format of the PUSCH have the same or different waveforms and/or numerologies.
  • the method further includes determining, by the processor, whether the collision between the PUCCH and the PUSCH occurs, wherein the collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported is based on the UE's capability or the gNB's configuration.
  • the simultaneous PUCCH and PUSCH transmission is not supported when the PUCCH and the PUSCH are configured with different waveforms, or the PUCCH and the PUSCH are configured with Discrete Fourier Transform-Spreading-Orthogonal Frequency Division Multiple (DFT-S-OFDM), but have different numerologies.
  • the simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with DFT-S-OFDM waveforms and the same numerology.
  • the simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with Cyclic Prefix (CP)-OFDM waveforms.
  • CP Cyclic Prefix
  • the UE When the simultaneous PUCCH and PUSCH transmission is not supported, and when the collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH.
  • the UCI is transmitted using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH, the PUCCH is not transmitted.
  • the simultaneous PUCCH and PUSCH transmission is supported, when the PUCCH and the PUSCH have the overlapping portion, and when power is limited, the UE is configured to allocate the power to transmit the PUCCH, and after transmitting the PUCCH, allocate the remaining power to transmit the PUSCH with power scaling in symbols of the overlapping portion.
  • a user equipment for reporting uplink control information (UCI) in case of a channel collision between a physical uplink control channel (PUCCH) and a physical uplink shared channel (PUSCH) is described.
  • the UE includes a processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for determining, by the processor, whether a simultaneous PUCCH and PUSCH transmission is supported.
  • the method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported, performing one of (1) transmitting the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not transmitting the overlapping portion of the PUSCH, and (2) transmitting the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported includes determining a format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB), and determining a format and a configuration of the PUSCH based on a signaling from the gNB.
  • gNB next generation NodeB
  • the format of the PUCCH comprises a short PUCCH format and a long PUCCH format, the short PUCCH format and long PUCCH format each have a waveform and a numerology.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported comprises determining whether a format of the PUCCH and a format of the PUSCH have the same or different waveforms and/or numerologies. The collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
  • the determining whether the simultaneous PUCCH and PUSCH transmission is supported is based on the UE's capability or the gNB's configuration.
  • the simultaneous PUCCH and PUSCH transmission is not supported when the PUCCH and the PUSCH are configured with different waveforms, or when the PUCCH and the PUSCH are configured with Discrete Fourier Transform-Spreading-Orthogonal Frequency Division Multiple (DFT-S-OFDM), but have different numerologies.
  • the simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with DFT-S-OFDM waveforms and the same numerology.
  • the simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with Cyclic Prefix (CP)-OFDM waveforms.
  • CP Cyclic Prefix
  • the simultaneous PUCCH and PUSCH transmission is not supported, and when the collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH.
  • the UCI is transmitted using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH, the PUCCH is not transmitted.
  • the simultaneous PUCCH and PUSCH transmission is supported, when the PUCCH and the PUSCH have the overlapping portion, and when power is limited, the UE is further configured to allocate the power to transmit the PUCCH, and after transmitting the PUCCH, allocate the remaining power to transmit the PUSCH with power scaling in symbols of the overlapping portion.
  • FIG. 1 is a block diagram illustrating one implementation of one or more next generation NodeBs (gNBs) 160 and one or more user equipments (UEs) 102 in which systems and methods for UCI operations may be implemented.
  • the one or more UEs 102 communicate with one or more gNBs 160 using one or more antennas 122 a - n .
  • a UE 102 transmits electromagnetic signals to the gNB 160 and receives electromagnetic signals from the gNB 160 using the one or more antennas 122 a - n .
  • the gNB 160 communicates with the UE 102 using one or more antennas 180 a - n.
  • the UE 102 and the gNB 160 may use one or more channels 119 , 121 to communicate with each other.
  • a UE 102 may transmit information or data to the gNB 160 using one or more uplink channels 121 .
  • uplink channels 121 include a PUCCH and a PUSCH, etc.
  • the one or more gNBs 160 may also transmit information or data to the one or more UEs 102 using one or more downlink channels 119 , for instance.
  • Examples of downlink channels 119 include a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), etc. Other kinds of channels may be used.
  • PDCCH physical downlink control channel
  • PDSCH physical downlink shared channel
  • Each of the one or more UEs 102 may include one or more transceivers 118 , one or more demodulators 114 , one or more decoders 108 , one or more encoders 150 , one or more modulators 154 , a data buffer 104 and a UE operations module 124 .
  • one or more reception and/or transmission paths may be implemented in the UE 102 .
  • transceiver 118 For convenience, only a single transceiver 118 , decoder 108 , demodulator 114 , encoder 150 and modulator 154 are illustrated in the UE 102 , though multiple parallel elements (e.g., transceivers 118 , decoders 108 , demodulators 114 , encoders 150 and modulators 154 ) may be implemented.
  • the transceiver 118 may include one or more receivers 120 and one or more transmitters 158 .
  • the one or more receivers 120 may receive signals from the gNB 160 using one or more antennas 122 a - n .
  • the receiver 120 may receive and downconvert signals to produce one or more received signals 116 .
  • the one or more received signals 116 may be provided to a demodulator 114 .
  • the one or more transmitters 158 may transmit signals to the gNB 160 using one or more antennas 122 a - n .
  • the one or more transmitters 158 may upconvert and transmit one or more modulated signals 156 .
  • the demodulator 114 may demodulate the one or more received signals 116 to produce one or more demodulated signals 112 .
  • the one or more demodulated signals 112 may be provided to the decoder 108 .
  • the UE 102 may use the decoder 108 to decode signals.
  • the decoder 108 may produce decoded signals 110 , which may include a UE-decoded signal 106 (also referred to as a first UE-decoded signal 106 ).
  • the first UE-decoded signal 106 may comprise received payload data, which may be stored in a data buffer 104 .
  • Another signal included in the decoded signals 110 may comprise overhead data and/or control data.
  • the second UE decoded signal 110 may provide data that may be used by the UE operations module 124 to perform one or more operations.
  • the UE operations module 124 may enable the UE 102 to communicate with the one or more gNBs 160 .
  • the UE operations module 124 may include one or more of a UE UCI module 126 .
  • the UE UCI module 126 may perform UCI operations.
  • UCI operations may include UCI generation, UCI multiplexing, UCI dropping, UCI compression, etc.
  • Each of the one or more gNBs 160 may include one or more transceivers 176 , one or more demodulators 172 , one or more decoders 166 , one or more encoders 109 , one or more modulators 113 , a data buffer 162 and a gNB operations module 182 .
  • one or more reception and/or transmission paths may be implemented in the gNB 160 .
  • transceiver 176 For convenience, only a single transceiver 176 , decoder 166 , demodulator 172 , encoder 109 and modulator 113 are illustrated in the gNB 160 , though multiple parallel elements (e.g., transceivers 176 , decoders 166 , demodulators 172 , encoders 109 and modulators 113 ) may be implemented.
  • the transceiver 176 may include one or more receivers 178 and one or more transmitters 117 .
  • the one or more receivers 178 may receive signals from the UE 102 using one or more antennas 180 a - n .
  • the receiver 178 may receive and downconvert signals to produce one or more received signals 174 .
  • the one or more received signals 174 may be provided to a demodulator 172 .
  • the one or more transmitters 117 may transmit signals to the UE 102 using one or more antennas 180 a - n .
  • the one or more transmitters 117 may upconvert and transmit one or more modulated signals 115 .
  • the demodulator 172 may demodulate the one or more received signals 174 to produce one or more demodulated signals 170 .
  • the one or more demodulated signals 170 may be provided to the decoder 166 .
  • the gNB 160 may use the decoder 166 to decode signals.
  • the decoder 166 may produce decoded signals 168 and a gNB-decoded signal 164 (also referred to as a first gNB-decoded signal 164 ).
  • the first gNB-decoded signal 164 may comprise received payload data, which may be stored in a data buffer 162 .
  • Another signal included in the decoded signals 168 may comprise overhead data and/or control data.
  • the second gNB decoded signal 168 may provide data that may be used by the gNB operations module 182 to perform one or more operations.
  • the gNB operations module 182 may enable the gNB 160 to communicate with the one or more UEs 102 .
  • the gNB operations module 182 may include one or more of a gNB UCI module 194 .
  • the gNB UCI module 194 may perform UCI operations.
  • UCI operations may include UCI extraction, UCI de-multiplexing, UCI reconstruction, UCI recompression, etc.
  • the OFDM access scheme with cyclic prefix may be employed, which may be also referred to as CP-OFDM.
  • CP cyclic prefix
  • PDCCH, EPDCCH, PDSCH and the like may be transmitted.
  • a downlink radio frame may comprise multiple pairs of downlink resource blocks (RBs) which is also referred to as physical resource blocks (PRBs).
  • the downlink RB pair is a unit for assigning downlink radio resources, defined by a predetermined bandwidth (RB bandwidth) and a time slot.
  • the downlink RB pair consists of two downlink RBs that are continuous in the time domain.
  • the downlink RB consists of twelve sub-carriers in frequency domain and seven (for normal CP) or six (for extended CP) OFDM symbols in time domain.
  • a region defined by one sub-carrier in frequency domain and one OFDM symbol in time domain is referred to as a resource element (RE) and is uniquely identified by the index pair (k,l) in a slot, where k and 1 are indices in the frequency and time domains, respectively.
  • resource element RE
  • k,l index pair
  • downlink subframes in one component carrier (CC) are discussed herein, downlink subframes are defined for each CC and downlink subframes are substantially in synchronization with each other among CCs.
  • An example of a resource grid in a downlink is discussed in connection with FIG. 2 .
  • a Single-Carrier Frequency Division Multiple Access (SC-FDMA) access scheme may be employed, which is also referred to as Discrete Fourier Transform-Spreading OFDM (DFT-S-OFDM).
  • DFT-S-OFDM Discrete Fourier Transform-Spreading OFDM
  • PUCCH, PDSCH, PRACH and the like may be transmitted.
  • An uplink radio frame may comprise multiple pairs of uplink resource blocks.
  • the uplink RB pair is a unit for assigning uplink radio resources, defined by a predetermined bandwidth (RB bandwidth) and a time slot.
  • the uplink RB pair consists of two uplink RBs that are continuous in the time domain.
  • the uplink RB may comprise twelve sub-carriers in frequency domain and seven (for normal CP) or six (for extended CP) OFDM/DFT-S-OFDM symbols in time domain.
  • a region defined by one sub-carrier in the frequency domain and one OFDM/DFT-S-OFDM symbol in the time domain is referred to as a resource element (RE) and is uniquely identified by the index pair (k,l) in a slot, where k and 1 are indices in the frequency and time domains respectively.
  • resource element RE
  • k,l index pair
  • uplink subframes in one component carrier (CC) are discussed herein, uplink subframes are defined for each CC.
  • An example of a resource grid in an uplink is discussed in connection with FIG. 3 .
  • FIGS. 4A, 4B, 4C, and 4D show examples of several numerologies.
  • the numerology #1 may be a basic numerology.
  • a RE of the basic numerology is defined with subcarrier spacing of 15 kHz in frequency domain and 2048 Ts+CP length (e.g., 160 Ts or 144 Ts) in time domain, where Ts denotes a baseband sampling time unit defined as 1/(15000*2048) seconds.
  • the subcarrier spacing may be equal to 15*2 1 and the effective OFDM symbol length 2048*2 ⁇ i *Ts.
  • the symbol length is 2048*2 ⁇ i *Ts+CP length (e.g., 160*2 ⁇ i *Ts or 144*2 ⁇ i *Ts).
  • the subcarrier spacing of the i+l-th numerology is a double of the one for the i-th numerology
  • the symbol length of the i+l-th numerology is a half of the one for the i-th numerology.
  • FIGS. 5A, 5B, 5C, and 5D show examples of subframe structures for the numerologies that are shown in FIGS. 4A, 4B, 4C, and 4D , respectively.
  • the slot length of the i+l-th numerology is a half of the one for the i-th numerology, and eventually the number of slots in a subframe (i.e., 1 ms) becomes double.
  • a radio frame may consists of 10 subframes, and the radio frame length may be equal to 10 ms.
  • FIGS. 6A, 6B, 6C, 6D, 6E and 6F show examples of slots and sub-slots. If sub-slot is not configured by higher layer signaling, the UE and the gNB may only use a slot as a scheduling unit. More specifically, a given transport block may be allocated to a slot. If the sub-slot is configured by higher layer signaling, the UE and the gNB may use the sub-slot as well as the slot.
  • the sub-slot may comprise one or more OFDM symbols.
  • the maximum number of OFDM symbols that constitute the sub-slot may be N DL symb ⁇ 1 (or N UL symb ⁇ 1).
  • the sub-slot length may be configured by higher layer signaling.
  • the sub-slot length may be indicated by a physical layer control channel (e.g., by DCI format).
  • the sub-slot may start at any symbol within a slot unless it collides with a control channel.
  • There could be restrictions of mini-slot length based on restrictions on the starting position.
  • the sub-slot with the length of N DL symb ⁇ 1 (or N UL symb ⁇ 1) may start at the second symbol in a slot.
  • the starting position of a sub-slot may be indicated by a physical layer control channel (e.g., by DCI format).
  • the starting position of a sub-slot may be derived from information (e.g., search space index, blind decoding candidate index, frequency and/or time resource indices, PRB index, a control channel element index, control channel element aggregation level, an antenna port index, etc.) of the physical layer control channel which schedules the data in the concerned sub-slot.
  • information e.g., search space index, blind decoding candidate index, frequency and/or time resource indices, PRB index, a control channel element index, control channel element aggregation level, an antenna port index, etc.
  • a given transport block may be allocated to either a slot, a sub-slot, aggregated sub-slots or aggregated sub-slot(s) and slot.
  • This unit may also be a unit for HARQ-ACK bit generation.
  • FIGS. 7A, 7B, 7C, and 7D show examples of scheduling timelines.
  • DL control channels are mapped the initial part of a slot.
  • the DL control channels schedule DL shared channels in the same slot.
  • HARQ-ACKs for the DL shared channels i.e., HARQ-ACKs each of which indicates whether or not transport block in each DL shared channel is detected successfully
  • a given slot may contain either one of DL transmission and UL transmission.
  • DL control channels are mapped the initial part of a slot.
  • the DL control channels schedule UL shared channels in a later slot.
  • the association timing (time shift) between the DL slot and the UL slot may be fixed or configured by higher layer signaling. Alternatively, it may be indicated by a physical layer control channel (e.g., the DL assignment DCI format, the UL grant DCI format, or another DCI format such as UE-common signaling DCI format which may be monitored in common search space).
  • a physical layer control channel e.g., the DL assignment DCI format, the UL grant DCI format, or another DCI format such as UE-common signaling DCI format which may be monitored in common search space.
  • DL control channels are mapped the initial part of a slot.
  • the DL control channels schedules DL shared channels in the same slot.
  • HARQ-ACKs for the DL shared channels are reported UL control channels which are mapped at the ending part of the slot.
  • DL control channels are mapped the initial part of a slot.
  • the DL control channels schedules UL shared channels in the same slot.
  • the slot may contain DL and UL portions, and there may be a guard period between the DL and UL transmissions.
  • the use of self-contained slot may be upon a configuration of self-contained slot.
  • the use of self-contained slot may be upon a configuration of the sub-slot.
  • the use of self-contained slot may be upon a configuration of shortened physical channel (e.g., PDSCH, PUSCH, PUCCH, etc.).
  • FIGS. 8A and 8B show examples of DL control channel monitoring regions.
  • One or more sets of PRB(s) may be configured for DL control channel monitoring.
  • a control resource set is, in the frequency domain, a set of PRBs within which the UE attempts to blindly decode downlink control information, where the PRBs may or may not be frequency contiguous, a UE may have one or more control resource sets, and one DCI message may be located within one control resource set.
  • a PRB is the resource unit size (may or may not including DM-RS) for control channel.
  • DL shared channel may start at a later OFDM symbol than the one(s) which carries the detected DL control channel.
  • the DL shared channel may start at or an earlier OFDM symbol than the last OFDM symbol which carries the detected DL control channel.
  • dynamic reuse of at least part of resources in the control resource sets for data for the same or a different UE, at least in the frequency domain may be supported.
  • FIGS. 9A and 9B show examples of DL control channel which consists of more than one control channel elements.
  • a control channel candidate may be mapped to multiple OFDM symbols or may be mapped to a single OFDM symbol.
  • One DL control channel element may be mapped on REs defined by a single PRB and a single OFDM symbol. If more than one DL control channel elements are used for a single DL control channel transmission, DL control channel element aggregation may be performed.
  • the number of aggregated DL control channel elements is referred to as DL control channel element aggregation level.
  • the DL control channel element aggregation level may be 1 or 2 to the power of an integer.
  • the gNB may inform UE of which control channel candidates are mapped to each subset of OFDM symbols in the control resource set. If one DL control channel is mapped to a single OFDM symbol and does not span multiple OFDM symbols, the DL control channel element aggregation is performed within an OFDM symbol, namely multiple DL control channel elements within an OFDM symbol are aggregated. Otherwise, DL control channel elements in different OFDM symbols can be aggregated.
  • FIGS. 10A, 10B, and 10C show examples of UL control channel structures.
  • UL control channel may be mapped on REs which are defined by a PRB and a slot in frequency and time domains, respectively.
  • This UL control channel may be referred to as a long format (or just the 1st format).
  • UL control channels may be mapped on REs on a limited OFDM symbols in time domain. This may be referred to as a short format (or just the 2nd format).
  • the UL control channels with a short format may be mapped on REs with in a single PRB.
  • the UL control channels with a short format may be mapped on REs with in multiple PRBs.
  • interlaced mapping may be applied, namely the UL control channel may be mapped to every N PRBs (e.g., 5 PRBs or 10 PRBs) within a system bandwidth.
  • FIG. 11 is a block diagram illustrating one implementation of a gNB.
  • a gNB 1160 may substantially correspond to the gNB 160 in FIG. 1 .
  • the gNB 1160 may include a higher layer processor 1123 a , a DL transmitter 1125 , a UL receiver 1133 , and antennas 1131 a .
  • the DL transmitter 1125 may include a PDCCH transmitter 1127 and a PDSCH transmitter 1129 .
  • the UL receiver 1133 may include a PUCCH receiver 1135 and a PUSCH receiver 1137 .
  • the higher layer processor 1123 a may manage physical layer's behaviors (the DL transmitter 1125 's and the UL receiver 1133 's behaviors) and provide higher layer parameters to the physical layer.
  • the higher layer processor 1123 a may obtain transport blocks from the physical layer.
  • the higher layer processor 1123 a may send/acquire higher layer messages such as an RRC message and MAC message to/from a UE's higher layer.
  • the higher layer processor 1123 a may provide the PDSCH transmitter 1129 transport blocks and provide the PDCCH transmitter 1127 transmission parameters related to the transport blocks.
  • the UL receiver 1133 may receive multiplexed uplink physical channels and uplink physical signals via receiving antennas 1131 a and de-multiplex them.
  • the PUCCH receiver 1135 may provide the higher layer processor UCI.
  • the PUSCH receiver 1137 may provide the higher layer processor received transport blocks.
  • FIG. 12 is a block diagram illustrating one implementation of a UE.
  • a UE 1202 may substantially correspond to the UE 102 in FIG. 1 .
  • the UE 1202 may include a higher layer processor 1223 b , a UL transmitter 1249 , a DL receiver 1243 , and antennas 1231 b .
  • the UL transmitter 1249 may include a PUCCH transmitter 1251 and a PUSCH transmitter 1253 .
  • the DL receiver 1243 may include a PDCCH receiver 1245 and a PDSCH receiver 1247 .
  • the higher layer processor 1223 b may manage physical layer's behaviors (the UL transmitter 1249 's and the DL receiver 1243 's behaviors) and provide higher layer parameters to the physical layer.
  • the higher layer processor 1223 b may obtain transport blocks from the physical layer.
  • the higher layer processor 1223 b may send/acquire higher layer messages such as an RRC message and MAC message to/from a UE's higher layer.
  • the higher layer processor 1223 b may provide the PUSCH transmitter 1253 transport blocks and provide the PUCCH transmitter 1251 UCI.
  • the DL receiver 1243 may receive multiplexed downlink physical channels and downlink physical signals via receiving antennas 1231 b and de-multiplex them.
  • the PDCCH receiver 1245 may provide the higher layer processor 1223 b DCI.
  • the PDSCH receiver 1247 may provide the higher layer processor 1223 b received transport blocks.
  • names of physical channels described herein are examples.
  • the other names such as “NRPDCCH, NRPDSCH, NRPUCCH and NRPUSCH” or the like can be used.
  • FIG. 13 is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12 , for UCI reporting on PUCCH or PUSCH in case of channel overlap or collision on a single carrier or serving cell.
  • a process 1300 an exemplary process of UCI reporting on PUCCH or PUSCH in case of a channel overlap or collision is provided by way of example, as there are a variety of ways to carry out the method.
  • Each block shown in FIG. 13A represents one or more processes, methods, or subroutines, carried out in the exemplary processing method. Additionally, the illustrated order of blocks is by example only and the order of the blocks can change.
  • the method 1300 for UCI reporting on PUCCH or PUSCH in case of a channel overlap or collision includes blocks 1302 , 1304 , 1306 , 1308 , 1310 , 1312 , 1314 , 1316 , and 1318 .
  • the format and configuration of a PUCCH transmission is determined based on a signaling from a gNB (e.g., gNB 1160 in FIG. 11 ).
  • a gNB e.g., gNB 1160 in FIG. 11
  • the format, waveform, numerology, and configuration of the UCI in the PUCCH transmission are determined.
  • the format and configuration of a PUSCH transmission is determined based on a signaling from the gNB (e.g., gNB 1160 in FIG. 11 ).
  • the format, waveform, and numerology, and configuration of the UCI in the PUSCH transmission are determined.
  • the UE determines whether there is an overlapping portion between the PUSCH and PUCCH transmissions.
  • An overlapping portion exists, for example, when there are one or more overlapping symbols, for example, in time domain. If it is determined that no overlapping portion is present, the PUSCH and PUCCH are transmitted in block 1308 .
  • the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. For example, situations where simultaneous transmission of PUCCH and PUSCH is supported include CP-OFDM configured for both the PUCCH and PUSCH, or DFT-S-OFDM with the same numerology configured for both the PUCCH and PUSCH. In one implementation, the UE may make the determination in the block 1310 by using the following three cases:
  • the method 1300 proceeds to either the block 1312 or 1314 .
  • the UE determines whether the UCI is carried on the PUCCH or the PUSCH, and whether to transmit the PUCCH and/or PUSCH.
  • the UE is to transmit the UCI using the PUCCH in the overlapping portion between the PUCCH transmission and the PUSCH transmission, and drop (e.g., not transmit) PUSCH symbols in the overlapping portion of the PUSCH transmission.
  • the UE is to transmit the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH transmission, and drop (e.g., not transmit) the PUCCH.
  • the default behavior of selecting the block 1312 or 1314 may depend on the uplink control channel format.
  • the method 1300 proceeds to the block 1316 .
  • simultaneous PUCCH and PUSCH data transmission on the overlapping symbols is performed, and power allocation of overlapping symbols prioritizes the PUCCH transmission.
  • the remaining power after PUCCH allocation may be allocated to the PUSCH REs in the symbol with power scaling if applicable.
  • uplink control channel In NR, at least two different types of uplink control channel (PUCCH) formats may be specified, at least one short PUCCH format and one long PUCCH format.
  • the PUCCH channel is designed to carry uplink control information (UCI).
  • the physical uplink shared channel PUSCH
  • the UCI may be reported on PUCCH or a PUSCH or both.
  • the PUCCH format and PUSCH format may be configured independently.
  • the waveform type and numerologies for different channels may be the same or different.
  • simultaneous transmission of PUCCH and PUSCH is restricted by many different conditions.
  • the present disclosure provides solutions and procedures for UCI reporting on different UL channels and formats.
  • PUSCH channel may also be very flexible, the size of a PUSCH may be a mini-slot, a slot, or span over multiple slots.
  • both cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) and discrete Fourier transform spread OFDM (DFT-S-OFDM) waveforms are supported for UL transmission.
  • different numerologies may be used on one or more carriers or serving cells.
  • the PUCCH and PUSCH transmissions from a UE may experience collision in some cases.
  • the UCI may be transmitted as L1/L2 control signaling, for example, via a PUCCH, PUSCH, or uplink data channel. Furthermore, the timing, between data reception and HARQ-ACK transmission as part of the downlink control information (DCI), may be dynamically indicate (at least in combination with radio resource control (RRC)).
  • RRC radio resource control
  • OFDM Orthogonal Frequency Division Multiplexing
  • CP-OFDM Cyclic Prefix OFDM
  • DFT-S-OFDM Discrete Fourier Transform
  • SC-FDMA Single Carrier FDMA
  • PAPR Peak-to-Average Power Ratio
  • the uplink control and uplink data channel may be configured separately with the same or different waveforms and numerologies.
  • the uplink control channel and uplink data channel collision and multiplexing should take into account all possible combinations.
  • FIG. 13B is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12 , for reporting UCI.
  • a method 1360 includes blocks 1362 and 1364 .
  • the method 1360 includes storing, by the UE, information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported.
  • PUCCH physical uplink control channel
  • PUSCH physical uplink shared channel
  • the method 1360 further includes transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH transmission and the PUSCH transmission, and dropping the overlapping portion of the PUSCH transmission, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH transmission and a PUSCH transmission.
  • FIG. 13C is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the gNB in FIG. 11 , for receiving UCI from a UE.
  • a method 1380 includes blocks 1382 and 1384 .
  • the method 1380 includes acquiring, by the gNB, information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE.
  • PUCCH physical uplink control channel
  • PUSCH physical uplink shared channel
  • the method 1380 further includes receiving the UCI using the PUCCH transmission in an overlapping portion between the PUCCH transmission and the PUSCH transmission, and not receiving the overlapping portion of the PUSCH transmission, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH transmission and a PUSCH transmission.
  • FIG. 14A illustrates examples of short PUCCH formats.
  • at least two transmission durations are supported for uplink control, one short around the last OFDM symbol in a slot, TDMed or FDMed with data, and one long spanning multiple symbols (e.g., filling most of a slot or slots), FDMed with data.
  • a short PUCCH is suitable for 1 or 2 bits of HARQ-ACK feedback and/or SR.
  • a short PUCCH format may occupy only one symbol.
  • CP-OFDM modulation may be used.
  • Reference symbols 1404 and UCI carrying symbols 1402 may be multiplexed in different subcarriers of a PUCCH resource, as shown in slot 1401 of FIG. 14A (i.e., FDM case).
  • a short PUCCH format may occupy two symbols.
  • both CP-OFDM and DFT-S-OFDM modulations may be used.
  • reference symbol 1404 and the UCI carrying symbol 1402 may be TDM multiplexed, as shown in slot 1405 of FIG. 14A (i.e., TDM case).
  • a short PUCCH may occupy one symbol of a reference numerology by splitting it into two symbols with a higher numerology, for example, by doubling the subcarrier spacing and reducing the symbol length by half, as shown in slot 1407 of FIG. 14A (i.e., TDM with symbol splitting case).
  • a 2-symbol PUCCH may be used.
  • a mechanism to tell the UE in which symbol(s) in a slot to transmit the short PUCCH on is supported at 6 GHz or above.
  • a long PUCCH format may span multiple symbols and slots. Multiple long PUCCH formats may be defined, e.g., 4 symbols, a slot, and multiple slots, and etc. A long PUCCH format may be useful for larger payload HARQ-ACK feedback, CSI feedback, and etc.
  • At least a low PAPR/CM waveform should be supported for the long PUCCH format.
  • a UCI carried by long duration UL control channel at least with low PAPR waveform may be transmitted in one slot or multiple slots, and transmission across multiple slots may allow a total duration of about 1 ms at least for some cases.
  • PUCCH format configuration a combination of semi-static configuration and (at least for some types of UCI information) dynamic signaling is used to determine the PUCCH resource both for the long and short PUCCH formats.
  • a PUSCH may span over all symbols in a UL subframe.
  • the last portion of a PUSCH may be punctured and replaced by a sounding reference signal (SRS) transmission.
  • SRS sounding reference signal
  • a PUSCH may not transmit in the first symbol and/or the last symbol of a UL LAA subframe.
  • LTE shortened transmission time interval (sTTI) design a UL sTTI may have a length of 2 symbols, 4 symbols or 7 symbols.
  • a PUSCH structure is more flexible as compared to that in LTE.
  • a PUSCH may be scheduled in mini-slot and slot levels.
  • slot aggregation is supported.
  • a PUSCH can be scheduled across multiple slots.
  • a mini-slot may be the minimum scheduling unit of a PUSCH transmission.
  • the length of a mini-slot may be 2 symbols to the (slot length ⁇ 1).
  • the mini-slot length may support one symbol at least for bands over 6 GHz.
  • a PUSCH in NR may use the reference numerology of a serving cell.
  • a PUSCH in NR may be scheduled using a different numerology from the reference numerology of the serving cell.
  • UCI on PUSCH is supported, for example, using portions of the scheduled resources for UCI in case of simultaneous UCI and data transmission.
  • a long PUCCH format may use CP-OFDM modulation and DFT-S-OFDM modulation.
  • a long PUCCH format may use the reference numerology of the serving cell, or a different numerology from the reference numerology of the serving cell.
  • the short PUCCH and long PUCCH formats may be configured for each UE.
  • the short PUCCH format and the long PUCCH format may use the same modulation method (e.g., all CP-OFDM based).
  • the short PUCCH format and the long PUCCH format may use different modulation methods (e.g., a short 1-symbol PUCCH using CP-OFDM, and a long multiple-symbol PUCCH using DFT-S-OFDM).
  • the short PUCCH and long PUCCH may be configured with the same numerology or with different numerologies.
  • the PUSCH format may have the same waveform modulation as the PUCCH format.
  • the PUSCH format may have a different waveform modulation from the PUCCH format.
  • the PUSCH format may have the same numerology as the PUCCH format.
  • the PUSCH format may have a different numerology from the PUCCH format.
  • the length of a scheduled PUSCH transmission may be the same or different from the PUCCH format.
  • a PUSCH resource may fully overlap or partially overlap with a PUCCH resource (e.g., symbols), for example, in time domain.
  • the PUSCH and PUCCH multiplexing There are several different cases to be considered for the PUSCH and PUCCH multiplexing, depending on the waveform/modulation methods and other configurations. If the modulation method is CP-OFDM for both PUCCH and PUSCH, multiplexing of different channels is possible. Furthermore, applying different numerologies for PUSCH and PUSCH may also be possible in FDM.
  • NR may support different short or long PUCCH formats with different lengths
  • the length of a scheduled PUSCH transmission may be the same or different from a PUCCH format.
  • a PUSCH resource may overlap or partial overlap with a PUCCH resource.
  • a short PUCCH only occupies 1 or 2 symbols, while a long PUCCH format may span over multiple slots.
  • the two PUCCH formats are discussed separately below.
  • FIG. 14B illustrates some examples of data and UCI multiplexing with short PUCCH shown in slots 1411 , 1413 , 1415 , and 1417 for downlink (DL) and uplink (UL) transmissions.
  • DL downlink
  • UL uplink
  • FDM FDM and/or TDM
  • FDM of short UCI and data should be supported, both within a UE and between UEs at least for the case where the PRBs for short UCI and data are non-overlapping.
  • FDM of data and UCI on short PUCCH should be supported, as least can be configurable.
  • simultaneous short PUCCH and PUSCH transmission should be supported when possible.
  • the last symbol may be reserved for HARQ-ACK feedback.
  • UL data may not be allowed in the last symbol, and may not be scheduled for PUSCH transmission.
  • simultaneous PUCCH and PUSCH transmission may be supported.
  • a short PUCCH in NR may be TDMed in different symbols for different UEs.
  • the short PUCCH may not be limited to the last symbol(s) of a slot.
  • the short PUCCH may use one or two symbols.
  • a simple solution of prioritizing short PUCCH over PUSCH data may be sufficient.
  • Several methods are considered for simultaneous PUCCH and PUSCH transmission.
  • FIG. 15 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and short PUCCH overlapping or collision.
  • An overlap or collision between a short PUCCH and a PUSCH occurs if there is any overlapping in time domain.
  • FIG. 15 several examples of a short PUCCH 1502 using one or two symbols are shown where the PUCCH and PUSCH may have overlapping resource elements (REs) in a frequency subcarrier.
  • a PUCCH and PUSCH overlap or collision may occur even if the PUCCH and PUSCH use different frequency subcarriers.
  • the short PUCCH 1502 is prioritized over the PUSCH transmission 1504 .
  • FIG. 15 several overlapping/collision cases, as shown in examples 1501 , 1503 , 1505 , and 1507 , are considered for simultaneous PUCCH and PUSCH transmissions.
  • the collision(s) may be a full overlap or a partial overlap in time domain between the PUCCH and PUSCH transmissions.
  • an overlap or collision may occur, when the short PUCCH 1502 (e.g., a 1-symbol short PUCCH) overlaps with a scheduled PUSCH transmission 1504 .
  • the short PUCCH 1502 e.g., a 1-symbol short PUCCH
  • a short PUCCH 1502 (e.g., a 2-symbol short PUCCH), as shown in the examples 1503 , 1505 , and 1507 , an overlap or collision may occur, when any symbol of a short PUCCH 1502 overlaps with a scheduled PUSCH transmission 1504 .
  • a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) fully overlaps with a scheduled PUSCH transmission 1504 .
  • a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) partially overlaps with an end portion of a scheduled PUSCH transmission 1504 .
  • a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) partially overlaps with a beginning portion of a scheduled PUSCH transmission 1504 .
  • the PUCCH and PUSCH transmissions do not overlap or collide
  • the PUCCH and PUSCH are transmitted according to their scheduling.
  • the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. If simultaneous transmission of PUCCH and PUSCH is not supported, the UE determines which method to use to transmit the PUCCH and PUSCH.
  • simultaneous PUCCH and PUSCH transmission may not be supported.
  • simultaneous transmission of PUCCH and PUSCH may not be supported when the UE is not capable and/or configured for simultaneous PUCCH and PUSCH transmission.
  • simultaneous transmission of PUCCH and PUSCH may not be supported when the PUCCH and the PUSCH are configured with different waveforms, or the PUCCH and the PUSCH are configured with DFT-S-OFDM but have different numerologies.
  • simultaneous PUCCH and PUSCH transmission may have a default behavior, whether or not to support simultaneous PUCCH and PUSCH transmission may be a UE's capability, and whether or not to support simultaneous PUCCH and PUSCH transmission may be configured. Since NR supports different short or long PUCCH formats with different lengths, the length of a scheduled PUSCH transmission may be the same or different from a PUCCH format. Also, a PUSCH may fully overlap or partially overlap with a PUCCH resource. Furthermore, simultaneous transmission of a short PUCCH format and a long PUCCH format can be very different. A short PUCCH only occupies 1 or 2 symbols, while a long PUCCH format may span over multiple slots.
  • FIG. 16A illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported.
  • examples 1601 , 1603 , 1605 , and 1607 each illustrate a short PUCCH 1602 overlapping (e.g., fully or partially) with a PUSCH 1604 .
  • the UE transmits the short PUCCH transmission 1604 and drops (not transmit) the overlapping portion of the PUSCH data 1606 of the PUSCH 1604 .
  • the short PUCCH 1602 (e.g., a 1-symbol short PUCCH) fully overlaps with a scheduled PUSCH 1604 .
  • a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) fully overlaps with a scheduled PUSCH 1604 .
  • a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) partially overlaps with an end portion of a scheduled PUSCH 1604 .
  • a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) partially overlaps with a beginning portion of a scheduled PUSCH 1604 .
  • the UE transmits the short PUCCH 1602 and drops (not transmit) the overlapping portion of the PUSCH data 1606 of the PUSCH 1604 . It is noted that the remaining portions of the PUSCH 1604 are still transmitted. That is, only the REs of the PUSCH data 1606 (e.g., symbol(s)) that overlaps or collides with the short PUCCH 1602 is dropped.
  • the PUSCH transmission may be stopped before the PUCCH transmission, and resumed after the PUCCH transmission.
  • the PUCCH transmission may take priority over the PUSCH transmission regardless of whether the same or different waveforms and/or numerologies are applied for PUCCH and PUSCH.
  • This method is particularly advantageous for a downlink centric slot where only UL symbols for short PUCCH is present in the slot.
  • the present exemplary method handles overlapping portions of a PUCCH and a PUSCH, when simultaneous PUCCH and PUSCH transmission is not supported, by transmitting the short PUCCH and dropping (not transmitting) the overlapping portion of the PUSCH data of the PUSCH transmission.
  • the PUCCH transmission is prioritized over PUSCH data in the PUSCH transmission. Since a short PUCCH occupies one or two symbols, the number of REs available for PUSCH is limited on the PUCCH carrying symbols. Thus, dropping the PUSCH on a limited number of symbols may not have a significant impact on the PUSCH performance.
  • the present exemplary method may be set as a default behavior for short PUCCH and PUSCH overlap/collision examples shown in FIG. 16A .
  • a sounding reference signal (SRS) transmission only occupies one or two symbols.
  • SRS sounding reference signal
  • the same method described with reference to FIG. 16 may be used for an SRS transmission with a PUSCH transmission. Therefore, if an SRS transmission is scheduled with overlapping symbols of a PUSCH transmission, the overlapping PUSCH symbols may be dropped, and the SRS should be transmitted. It is noted that if a PUCCH collides with a scheduled SRS transmission, the SRS may be dropped.
  • the transmission priority from the highest to the lowest, according to an implementation of the presentation is as follows: UCI on PUCCH, UCI on PUSCH, SRS, and PUSCH with data only.
  • FIG. 16B illustrates an exemplary implementation of another method of handling overlapping portions of a short PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported.
  • examples 1601 , 1603 , 1605 , and 1607 each illustrate a short PUCCH 1602 overlapping with a PUSCH 1604 .
  • the UE drops the short PUCCH 1602 and multiplexes the UCI of the short PUCCH 1602 on the PUSCH 1604 .
  • the UCI is multiplexed on PUSCH data 1606 of the symbol(s) scheduled for the short PUCCH 1602 in an overlapping region 1609 .
  • the short PUCCH 1602 e.g., a 1-symbol short PUCCH
  • the UCI is multiplexed on the PUSCH 1604 .
  • This ensures the UCI timing of PUCCH reporting is maintained even when the UCI is carried on the PUSCH 1604 .
  • a beta offset may be configured for control information multiplexing.
  • the beta offset determines the coding rate redundancy of control information over data information.
  • the coded bit after beta offset rate matching may be multiplexed on the PUSCH data symbols by replacing the existing PUSCH data symbols.
  • FIG. 16B shows several examples of a UCI multiplexing on a PUSCH in the overlapping symbols of a short PUCCH 1602 and a PUSCH 1604 .
  • each UCI is multiplexed on the overlapping PUCCH 1602 and PUSCH 1604 symbol(s) (e.g., only 1 symbol in each case), as shown in the overlapping region 1609 .
  • the coded UCI bit loading may be performed in frequency domain of the PUSCH allocated resources (e.g., on REs in subcarriers with frequency high to low). In another example, if DFT-S-OFDM is used on the PUSCH, and the overlapping symbol is the DMRS symbol, the bit loading may be performed on the next symbol instead.
  • the method described with reference to FIG. 16A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case.
  • the UCI may be multiplexed on all overlapping symbols, shown in the approach 1611 , to provide time diversity gain.
  • the coded UCI bit multiplexing may be performed first in time domain, and then in frequency domain of the PUSCH allocated resources (e.g., on REs in time domain from the earliest symbol first on subcarriers with frequencies from high to low).
  • the UCI may be multiplexed to the earliest symbol of the overlapping region, which provides slightly faster UCI feedback than the multiplexing in the approach 1611 .
  • the coded UCI bit multiplexing may be performed first in the frequency domain then in the time domain of the PUSCH allocated resources (e.g., on REs in the earliest symbol first on subcarriers with frequency from high to low).
  • NR may determine a default behavior.
  • the default behavior may include (1) transmitting the PUCCH and dropping the overlapping symbols on the PUSCH; (2) PUCCH UCI multiplexing on the PUSCH.
  • the UE's behavior may be configured by a base station (e.g., gNB).
  • FIG. 17 illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is supported.
  • the PUSCH may not overlap with the configured PUCCH region in frequency domain.
  • Simultaneous PUCCH and PUSCH data transmission on the overlapping symbols may be performed in a FDM manner.
  • the PUCCH symbol(s) may be transmitted, and the PUSCH symbol(s) of the overlapped REs may be punctured, for example.
  • the overlapping PUSCH REs can be punctured.
  • puncturing overlapping PUSCH REs may be one option, which might cause minor issues during decoding on the receiver end (e.g., a gNB) due to, for example, break(s) in the DFT output.
  • the puncturing may be performed at input complex number input before the DFT.
  • the punctured input may then undergo DFT and bit loading to the corresponding REs with rate matching over the punctured symbols by the PUCCH transmission.
  • the power allocation of overlapping symbols prioritizes the short PUCCH transmission.
  • the remaining powers after the PUCCH 1702 allocation can be allocated to the PUSCH REs 1706 in the symbol with power scaling when applicable.
  • FIG. 18 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and long PUCCH overlapping or collision.
  • examples 1801 , 1803 , 1805 , and 1807 each show an overlapping or collision between a long PUCCH 1802 and a PUSCH 1804 .
  • the long PUCCH 1802 formats may span over multiple symbols or slots, and are more likely to schedule simultaneously with the PUSCH 1804 .
  • the UCI may use at least a portion of the scheduled data resources.
  • the length of a scheduled PUSCH transmission may be the same or different from the PUCCH format.
  • a PUSCH may fully overlap or partial overlap with a PUCCH resource.
  • a long PUCCH 1802 may fully overlap within a PUSCH 1804 .
  • a long PUCCH 1802 may partially overlap within a PUSCH 1804 .
  • a long PUCCH transmission 1802 format may be longer than a scheduled PUSCH 1804 . Similar to collision with short PUCCH cases described above, the following cases can be considered for PUSCH collision with long PUCCH formats.
  • the PUCCH and PUSCH are transmitted according to their scheduling. However, when there is an overlap or collision between the PUCCH and PUSCH transmissions, the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. If simultaneous transmission of PUCCH and PUSCH is not supported, the UE determines which method to use to transmit the PUCCH and PUSCH.
  • simultaneous PUCCH and PUSCH transmission may not be supported:
  • FIG. 19A illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported.
  • examples 1901 , 1903 , 1905 , and 1907 each illustrate a long PUCCH 1902 transmission overlapping (e.g., fully or partially) with a PUSCH 1904 .
  • the UE transmits the long PUCCH 1904 and drops (not transmit) the overlapping portion of the PUSCH data 1906 of the PUSCH 1904 .
  • a long PUCCH 1902 fully overlaps with a scheduled PUSCH 1904 , where the long PUCCH 1902 is shorter than the PUSCH 1904 .
  • a long PUCCH 1902 partially overlaps with an end portion of a scheduled PUSCH 1904 .
  • a long PUCCH 1902 partially overlaps with a beginning portion of a scheduled PUSCH 1904 .
  • a long PUCCH 1902 fully overlaps with a scheduled PUSCH 1904 , where the long PUCCH 1902 is longer than the PUSCH 1904 . It is noted that, in the example 1907 , the entire PUSCH is dropped.
  • the UE transmits the long PUCCH 1902 and drops (not transmit) the overlapping portion of the PUSCH data 1906 of the PUSCH 1904 . It is noted that the remaining portions (if any) of the PUSCH 1904 are still transmitted. That is, only the REs of the PUSCH data 1906 (e.g., symbol(s)) that overlaps or collides with the long PUCCH 1902 is dropped. For example, the PUSCH transmission may be stopped before the PUCCH transmission, and resumed after the PUCCH transmission.
  • the PUCCH transmission may take priority over the PUSCH transmission regardless of whether the same or different waveforms and/or numerologies are applied for PUCCH and PUSCH.
  • the long PUCCH 1902 may span over multiple symbols, dropping all PUSCH REs of these symbols may have more impact on the PUSCH performance than the short PUCCH case.
  • the present exemplary method shown in FIG. 19A may not be preferable for long PUCCH and PUSCH overlapping at least from some implementations, since dropping the entire or a major portion of the PUSCH may cause issues during decoding on the receiver end (e.g., a gNB).
  • the PUSCH dropping method as described with reference to FIG. 16 a may be conditional.
  • a threshold value can be used to determine whether the PUSCH should be partially transmitted or dropped entirely.
  • the threshold can be a number of overlapping symbols or a percentage of overlapping symbols within the PUSCH transmission. If below the threshold, the PUSCH is partially transmitted by dropping the overlapping symbols with the PUCCH. If above the threshold, the PUSCH is dropped entirely.
  • the threshold can be a default value or semi-statically configured by higher layer signaling.
  • FIG. 19B illustrates an exemplary implementation of another method of handling overlapping portions of a long PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported.
  • examples 1901 , 1903 , 1905 , and 1907 each illustrate a long PUCCH 1902 transmission overlapping with a PUSCH 1904 .
  • the UE drops the long PUCCH 1902 and multiplexes the UCI of the long PUCCH transmission 1902 on the PUSCH 1904 .
  • the present exemplary method provides UCI multiplexing on the PUSCH, and may be a default behavior for long PUCCH and PUSCH overlapping.
  • the UCI is multiplexed with the PUSCH 1904 on the overlapping symbol(s) scheduled for the long PUCCH 1902 in an overlapping region. This ensures the UCI timing of PUCCH reporting is maintained even when the UCI is carried on the PUSCH 1904 .
  • a beta offset may be configured for control information multiplexing. The beta offset determines the coding rate redundancy of control information over data information. The coded bit after beta offset rate matching should be multiplexed on the PUSCH data symbols by replacing existing PUSCH data symbols.
  • the multiplexing region includes multiple symbols, at least two approaches for multiplexing the UCI of long PUCCH 1902 to the PUSCH 1904 can be considered, as shown in example 1901 , 1903 , 1905 and 1907 .
  • the UCI may be multiplexed on all overlapping symbols between the long PUCCH 1902 and PUSCH 1904 , to provide time diversity gain, as shown in example 1901 of FIG. 19B .
  • the coded UCI bit multiplexing may be performed first in time domain, and then in frequency domain of the PUSCH allocated resources (e.g., on REs in time domain from earliest symbol first on subcarriers with frequencies from high to low). It is noted that, in a special case of the approach 1909 , not all symbols may be used for UCI multiplexing.
  • the UCI may be multiplexed on a subset of symbols in the overlapping region (e.g., on symbols adjacent or close to the demodulation symbols only), especially for the case of DFT-S-OFDM based transmission. While this approach may be more suitable for DFT-S-OFDM based transmissions, it may also be used for CP-OFDM based transmissions.
  • the UCI may be first multiplexed to the earliest symbols, which may provide a slight faster UCI feedback than the first exemplary approach.
  • the coded UCI bit multiplexing may be performed first in frequency domain, and then in time domain of the PUSCH allocated resources (e.g., on REs in the earliest symbol first on subcarriers with frequencies from high to low).
  • not all symbols may be used for UCI multiplexing. That is, the UCI may be multiplexed on a subset of symbols in the overlapping region (e.g., on symbols adjacent or close to the demodulation symbols only). While this approach may be more suitable for CP-OFDM based transmissions, it may also be used for DFT-S-OFDM based transmissions.
  • the method described with reference to FIG. 19A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case.
  • the overlapping region on a PUSCH is too small, and/or does not have the capacity to carry all of the UCI of a long PUCCH, the method described with reference to FIG. 19A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case.
  • the multiplexing method as described with reference to FIG. 19B may be conditional.
  • a threshold value can be used to determine whether the UCI should be multiplexed on PUSCH or transmitted on PUCCH.
  • the threshold may be a number of REs required for UCI multiplexing on a given PUSCH. If the number of REs in the overlapping area is less than the number of REs required for UCI multiplexing on a given PUSCH, the UE may transmit the long PUCCH and drop the overlapping symbols on the PUSCH. Otherwise, the UCI is multiplexed on the PUSCH.
  • NR may determine a default behavior.
  • the default behavior may include (1) transmitting the PUCCH and dropping the overlapping symbols on the PUSCH; (2) PUCCH UCI multiplexing on the PUSCH.
  • the UE's behavior may be configured by a base station (e.g., gNB).
  • FIG. 20 illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is supported.
  • the PUSCH may multiplex with the configured PUCCH region.
  • the PUCCH REs overlap with PUSCH REs
  • the PUCCH REs e.g., symbols
  • the PUSCH REs e.g., symbols
  • the overlapping PUSCH REs can be punctured.
  • puncturing overlapping PUSCH REs may be one option, which might cause minor issues during decoding on the receiver end (e.g., a gNB) due to, for example, break(s) in the DFT output.
  • the puncturing may be performed at input complex number input before DFT.
  • the punctured input may then undergo DFT and bit loading to the corresponding REs with rate matching over the punctured symbols by the PUCCH transmission.
  • the power allocation of overlapping symbols prioritizes the short PUCCH transmission.
  • the remaining powers after the PUCCH 2002 allocation can be allocated to the PUSCH REs 2006 in the symbol with power scaling when applicable.
  • Computer-readable medium refers to any available medium that can be accessed by a computer or a processor.
  • the term “computer-readable medium,” as used herein, may denote a computer- and/or processor-readable medium that is non-transitory and tangible.
  • a computer-readable or processor-readable medium may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor.
  • Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.
  • one or more of the methods described herein may be implemented in and/or performed using hardware.
  • one or more of the methods described herein may be implemented in and/or realized using a chipset, an application-specific integrated circuit (ASIC), a large-scale integrated circuit (LSI) or integrated circuit, etc.
  • ASIC application-specific integrated circuit
  • LSI large-scale integrated circuit
  • Each of the methods disclosed herein comprises one or more steps or actions for achieving the described method.
  • the method steps and/or actions may be interchanged with one another and/or combined into a single step without departing from the scope of the claims.
  • the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.
  • a program running on the gNB (e.g., gNB 160 in FIG. 1 ) or the UE (e.g., UE 102 in FIG. 1 ) according to the described systems and methods is a program (a program for causing a computer to operate) that controls a CPU and the like in such a manner as to realize the function according to the described systems and methods. Then, the information that is handled in these apparatuses is temporarily stored in a RAM while being processed. Thereafter, the information is stored in various ROMs or HDDs, and whenever necessary, is read by the CPU to be modified or written.
  • a recording medium on which the program is stored among a semiconductor (for example, a ROM, a nonvolatile memory card, and the like), an optical storage medium (for example, a DVD, a MO, a MD, a CD, a BD, and the like), a magnetic storage medium (for example, a magnetic tape, a flexible disk, and the like), and the like, any one may be possible.
  • a semiconductor for example, a ROM, a nonvolatile memory card, and the like
  • an optical storage medium for example, a DVD, a MO, a MD, a CD, a BD, and the like
  • a magnetic storage medium for example, a magnetic tape, a flexible disk, and the like
  • the program stored on a portable recording medium can be distributed or the program can be transmitted to a server computer that connects through a network such as the Internet.
  • a storage device in the server computer also is included.
  • some or all of the eNB 160 and the UE e.g., UE 102 in FIG. 1 ) according to the systems and methods described above may be realized as an LSI that is a typical integrated circuit.
  • Each functional block of the eNB 160 and the UE 102 may be individually built into a chip, and some or all functional blocks may be integrated into a chip.
  • a technique of the integrated circuit is not limited to the LSI, and an integrated circuit for the functional block may be realized with a dedicated circuit or a general-purpose processor. Furthermore, if with advances in a semiconductor technology, a technology of an integrated circuit that substitutes for the LSI appears, it is also possible to use an integrated circuit to which the technology applies.
  • each functional block or various features of the base station device and the terminal device used in each of the aforementioned embodiments may be implemented or executed by a circuitry, which is typically an integrated circuit or a plurality of integrated circuits.
  • the circuitry designed to execute the functions described in the present specification may comprise a general-purpose processor, a digital signal processor (DSP), an application specific or general application integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic, or a discrete hardware component, or a combination thereof.
  • the general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, a controller, a microcontroller or a state machine.
  • the general-purpose processor or each circuit described above may be configured by a digital circuit or may be configured by an analogue circuit. Further, when a technology of making into an integrated circuit superseding integrated circuits at the present time appears due to advancement of a semiconductor technology, the integrated circuit by this technology is also able to be used.

Abstract

A method for reporting uplink control information (UCI) by a user equipment (UE) is disclosed. The method includes storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported. The method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and dropping the overlapping portion of the PUSCH.

Description

    CROSS-REFERENCE TO RELATED APPLICATION(S)
  • The present application claims the benefit of and priority to a provisional U.S. Patent Application Ser. No. 62/433,677 filed on Dec. 13, 2016, entitled “BASE STATIONS, USER EQUIPMENTS, AND RELATED COMMUNICATION METHODS,” Attorney Docket No. SLA3698P (hereinafter referred to as “SLA3698P application”). The disclosure of the SLA3698P application is hereby incorporated fully by reference into the present application.
  • TECHNICAL FIELD
  • The present disclosure relates generally to communication systems. More specifically, the present disclosure relates to a base station apparatus, a user equipment apparatus and related communication methods.
  • BACKGROUND
  • Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power). Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.
  • In Long-Term Evolution (LTE), the uplink control information (UCI) carries hybrid-ARQ acknowledgements (HARQ-ACK), Channel-State Information (CSI), and Scheduling Request (SR). In the next generation (e.g., 5th generation (5G)) communication networks, such as new radio (NR), the UCI carries HARQ-ACK, SR, Channel Quality Indicator (CQI), Precoding Type Indicator (PTI), Precoding Matrix Indicator (PMI), and Rank Indication (RI). The CSI may include one or more of CQI, RI, PMI, PTI, and etc. Multiple dimensions of CSI may be reported from one or more cells to support full-dimension multiple input multiple output (FD-MIMO) and Coordinated Multi Point (CoMP) operations. Similarly, in NR, SR and HARQ-ACK need to be transmitted outside of physical uplink shared channel (PUSCH) for latency reasons. The CSI report in NR should be enhanced to support massive MIMO and beamforming methods. Thus, multiple sets of CSI may be reported in NR. Again, a CSI feedback may include one or more of CQI, RI, PMI, PTI, beam index, and etc. At least two types of CSI reports may be supported, namely periodic CSI and aperiodic CSI reports. A periodic CSI report can be configured semi-statically, while an aperiodic CSI report can be triggered with a CSI request from a base station. Therefore, physical uplink control signaling should be able to carry at least HARQ-ACKs, CSI reports (possibly including beamforming information), and SRs.
  • These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. With the emerging telecommunication standard of NR, there is a need in the art for a transmission method that can better support wireless communication by improving spectral efficiency, lowering costs, improving services, making use of new spectrum, and better integrating with other open standards using Orthogonal Frequency Division Multiple Access (OFDMA) on the downlink (DL), Single Carrier Frequency Division Multiple Access (SC-FDMA) on the uplink (UL), and multiple-input multiple-output (MIMO) antenna technology.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • Implementations of the present technology will now be described, by way of example only, with reference to the attached figures.
  • FIG. 1 is a block diagram illustrating one implementation of one or more next generation NodeBs (gNBs) and one or more user equipments (UEs) in which systems and methods for UCI operations may be implemented.
  • FIG. 2 is an example of a resource grid for a downlink.
  • FIG. 3 is an example of a resource grid for an uplink.
  • FIGS. 4A, 4B, 4C, and 4D show examples of several numerologies.
  • FIGS. 5A, 5B, 5C, and 5D show examples of subframe structures.
  • FIGS. 6A, 6B, 6C, 6D, 6E, and 6F show examples of slots and sub-slots.
  • FIGS. 7A, 7B, 7C, and 7D show examples of scheduling timelines.
  • FIGS. 8A and 8B show examples of downlink control channel monitoring regions.
  • FIGS. 9A and 9B show examples of downlink control channel each having more than one control channel elements.
  • FIGS. 10A, 10B, and 10C show examples of uplink control channel structures.
  • FIG. 11 is a block diagram illustrating one implementation of a gNB.
  • FIG. 12 is a block diagram illustrating one implementation of a UE.
  • FIG. 13A is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12, for UCI reporting on PUCCH or PUSCH in case of channel overlap or collision on a single carrier or serving cell.
  • FIG. 13B is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12, for reporting UCI.
  • FIG. 13C is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the gNB in FIG. 11, for receiving UCI from a UE.
  • FIG. 14A is a schematic diagram illustrating an exemplary implementation of a NR short physical uplink control channel (PUCCH).
  • FIG. 14B is a schematic diagram illustrating an exemplary implementation of data and UCI multiplexing with short PUCCH formats.
  • FIG. 15 is a schematic diagram illustrating various types of PUSCH and short PUCCH overlapping or collision.
  • FIG. 16A is a schematic diagram illustrating exemplary implementations of prioritized short PUCCH transmission over PUSCH data.
  • FIG. 16B is a schematic diagram illustrating exemplary implementations of UCI multiplexing on PUSCH in the overlapping portions of PUSCH and short PUCCH.
  • FIG. 17 is a schematic diagram illustrating an exemplary implementation of simultaneous PUCCH and PUSCH transmission with prioritized short PUCCH transmission and PUSCH power scaling.
  • FIG. 18 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and long PUCCH overlapping or collision.
  • FIG. 19A is a schematic diagram illustrating an exemplary implementation of prioritized long PUCCH transmission over PUSCH data.
  • FIG. 19B is a schematic diagram illustrating an exemplary implementation of UCI multiplexing on PUSCH in the overlapping portions of PUSCH and long PUCCH.
  • FIG. 20 is a schematic diagram illustrating an exemplary implementation of a simultaneous PUCCH and PUSCH transmission with prioritized long PUCCH transmission and PUSCH power scaling.
  • DETAILED DESCRIPTION
  • A user equipment (UE) is described. The UE is configured to report uplink control information (UCI). The UE includes a processor, such as a higher layer processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported. When the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH transmission and a PUSCH transmission, the instructions include transmitting the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and dropping the overlapping portion of the PUSCH. The instructions further include determining a PUCCH format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB). The PUCCH format is determined from a short PUCCH format and a long PUCCH format. The PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies. The channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH. The information on whether the simultaneous PUCCH and PUSCH transmission is supported, is either the UE's capability or a base station's configuration. When the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH.
  • A base station is described. The base station is configured to acquire uplink control information (UCI) from a user equipment (UE). The base station includes a processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE. When the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, the instructions include receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not receiving the overlapping portion of the PUSCH. A PUCCH format and a configuration of the PUCCH from the UE are determined based on a signaling from the base station. The PUCCH format is determined from a short PUCCH format and a long PUCCH format. The PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies. The channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH. The information on whether the simultaneous PUCCH and PUSCH transmission is supported, is either the UE's capability or the base station's configuration. When the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the base station is configured to receive a non-overlapping portion of the PUSCH.
  • A method for reporting uplink control information (UCI) by a user equipment (UE) is described. The method includes storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported. The method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and dropping the overlapping portion of the PUSCH.
  • A method for receiving uplink control information (UCI) from a user equipment (UE) by a base station is described. The method includes acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE. The method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH, receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not receiving the overlapping portion of the PUSCH.
  • A method for reporting uplink control information (UCI) by a user equipment (UE) in case of a channel collision between a physical uplink control channel (PUCCH) transmission and a physical uplink shared channel (PUSCH) transmission is described. The UE includes a processor and a non-transitory machine-readable memory storing instructions executable by the processor. the method includes determining, by the processor, whether a simultaneous PUCCH and PUSCH transmission is supported. When the simultaneous PUCCH and PUSCH transmission is not supported, the method includes performing one of (1) transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not transmitting the overlapping portion of the PUSCH, and (2) transmitting, by the UE, the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH. The determining whether the simultaneous PUCCH and PUSCH transmission is supported includes determining a format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB), and determining a format and a configuration of the PUSCH based on a signaling from the gNB. The format of the PUCCH comprises a short PUCCH format and a long PUCCH format, the short PUCCH format and long PUCCH format each have a waveform and a numerology. The determining whether the simultaneous PUCCH and PUSCH transmission is supported comprises determining whether a format of the PUCCH and a format of the PUSCH have the same or different waveforms and/or numerologies. The method further includes determining, by the processor, whether the collision between the PUCCH and the PUSCH occurs, wherein the collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH. The determining whether the simultaneous PUCCH and PUSCH transmission is supported is based on the UE's capability or the gNB's configuration. The simultaneous PUCCH and PUSCH transmission is not supported when the PUCCH and the PUSCH are configured with different waveforms, or the PUCCH and the PUSCH are configured with Discrete Fourier Transform-Spreading-Orthogonal Frequency Division Multiple (DFT-S-OFDM), but have different numerologies. The simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with DFT-S-OFDM waveforms and the same numerology. The simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with Cyclic Prefix (CP)-OFDM waveforms. When the simultaneous PUCCH and PUSCH transmission is not supported, and when the collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH. When the UCI is transmitted using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH, the PUCCH is not transmitted. When the simultaneous PUCCH and PUSCH transmission is supported, when the PUCCH and the PUSCH have the overlapping portion, and when power is limited, the UE is configured to allocate the power to transmit the PUCCH, and after transmitting the PUCCH, allocate the remaining power to transmit the PUSCH with power scaling in symbols of the overlapping portion.
  • A user equipment (UE) for reporting uplink control information (UCI) in case of a channel collision between a physical uplink control channel (PUCCH) and a physical uplink shared channel (PUSCH) is described. The UE includes a processor, and a non-transitory machine-readable memory storing instructions, executable by the processor, for determining, by the processor, whether a simultaneous PUCCH and PUSCH transmission is supported. The method also includes, when the simultaneous PUCCH and PUSCH transmission is not supported, performing one of (1) transmitting the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and not transmitting the overlapping portion of the PUSCH, and (2) transmitting the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH. The determining whether the simultaneous PUCCH and PUSCH transmission is supported includes determining a format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB), and determining a format and a configuration of the PUSCH based on a signaling from the gNB. The format of the PUCCH comprises a short PUCCH format and a long PUCCH format, the short PUCCH format and long PUCCH format each have a waveform and a numerology. The determining whether the simultaneous PUCCH and PUSCH transmission is supported comprises determining whether a format of the PUCCH and a format of the PUSCH have the same or different waveforms and/or numerologies. The collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH. The determining whether the simultaneous PUCCH and PUSCH transmission is supported is based on the UE's capability or the gNB's configuration. The simultaneous PUCCH and PUSCH transmission is not supported when the PUCCH and the PUSCH are configured with different waveforms, or when the PUCCH and the PUSCH are configured with Discrete Fourier Transform-Spreading-Orthogonal Frequency Division Multiple (DFT-S-OFDM), but have different numerologies. The simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with DFT-S-OFDM waveforms and the same numerology. The simultaneous PUCCH and PUSCH transmission is supported when the PUCCH and the PUSCH are configured with Cyclic Prefix (CP)-OFDM waveforms. The simultaneous PUCCH and PUSCH transmission is not supported, and when the collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH. The UCI is transmitted using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH, the PUCCH is not transmitted. The simultaneous PUCCH and PUSCH transmission is supported, when the PUCCH and the PUSCH have the overlapping portion, and when power is limited, the UE is further configured to allocate the power to transmit the PUCCH, and after transmitting the PUCCH, allocate the remaining power to transmit the PUSCH with power scaling in symbols of the overlapping portion.
  • It will be appreciated that for simplicity and clarity of illustration, where appropriate, reference numerals have been repeated among the different figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary implementations described herein. However, it will be understood by those of ordinary skill in the art that the exemplary implementations described herein can be practiced without these specific details. In other instances, methods, procedures, and components have not been described in detail so as not to obscure the related relevant feature being described. The drawings are not necessarily to scale and the proportions of certain parts may be exaggerated to better illustrate details and features. The description is not to be considered as limiting the scope of the exemplary implementations described herein.
  • FIG. 1 is a block diagram illustrating one implementation of one or more next generation NodeBs (gNBs) 160 and one or more user equipments (UEs) 102 in which systems and methods for UCI operations may be implemented. The one or more UEs 102 communicate with one or more gNBs 160 using one or more antennas 122 a-n. For example, a UE 102 transmits electromagnetic signals to the gNB 160 and receives electromagnetic signals from the gNB 160 using the one or more antennas 122 a-n. The gNB 160 communicates with the UE 102 using one or more antennas 180 a-n.
  • The UE 102 and the gNB 160 may use one or more channels 119, 121 to communicate with each other. For example, a UE 102 may transmit information or data to the gNB 160 using one or more uplink channels 121. Examples of uplink channels 121 include a PUCCH and a PUSCH, etc. The one or more gNBs 160 may also transmit information or data to the one or more UEs 102 using one or more downlink channels 119, for instance. Examples of downlink channels 119 include a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), etc. Other kinds of channels may be used.
  • Each of the one or more UEs 102 may include one or more transceivers 118, one or more demodulators 114, one or more decoders 108, one or more encoders 150, one or more modulators 154, a data buffer 104 and a UE operations module 124. For example, one or more reception and/or transmission paths may be implemented in the UE 102. For convenience, only a single transceiver 118, decoder 108, demodulator 114, encoder 150 and modulator 154 are illustrated in the UE 102, though multiple parallel elements (e.g., transceivers 118, decoders 108, demodulators 114, encoders 150 and modulators 154) may be implemented.
  • The transceiver 118 may include one or more receivers 120 and one or more transmitters 158. The one or more receivers 120 may receive signals from the gNB 160 using one or more antennas 122 a-n. For example, the receiver 120 may receive and downconvert signals to produce one or more received signals 116. The one or more received signals 116 may be provided to a demodulator 114. The one or more transmitters 158 may transmit signals to the gNB 160 using one or more antennas 122 a-n. For example, the one or more transmitters 158 may upconvert and transmit one or more modulated signals 156.
  • The demodulator 114 may demodulate the one or more received signals 116 to produce one or more demodulated signals 112. The one or more demodulated signals 112 may be provided to the decoder 108. The UE 102 may use the decoder 108 to decode signals. The decoder 108 may produce decoded signals 110, which may include a UE-decoded signal 106 (also referred to as a first UE-decoded signal 106). For example, the first UE-decoded signal 106 may comprise received payload data, which may be stored in a data buffer 104. Another signal included in the decoded signals 110 (also referred to as a second UE-decoded signal 110) may comprise overhead data and/or control data. For example, the second UE decoded signal 110 may provide data that may be used by the UE operations module 124 to perform one or more operations.
  • In general, the UE operations module 124 may enable the UE 102 to communicate with the one or more gNBs 160. The UE operations module 124 may include one or more of a UE UCI module 126.
  • The UE UCI module 126 may perform UCI operations. UCI operations may include UCI generation, UCI multiplexing, UCI dropping, UCI compression, etc.
  • Each of the one or more gNBs 160 may include one or more transceivers 176, one or more demodulators 172, one or more decoders 166, one or more encoders 109, one or more modulators 113, a data buffer 162 and a gNB operations module 182. For example, one or more reception and/or transmission paths may be implemented in the gNB 160. For convenience, only a single transceiver 176, decoder 166, demodulator 172, encoder 109 and modulator 113 are illustrated in the gNB 160, though multiple parallel elements (e.g., transceivers 176, decoders 166, demodulators 172, encoders 109 and modulators 113) may be implemented.
  • The transceiver 176 may include one or more receivers 178 and one or more transmitters 117. The one or more receivers 178 may receive signals from the UE 102 using one or more antennas 180 a-n. For example, the receiver 178 may receive and downconvert signals to produce one or more received signals 174. The one or more received signals 174 may be provided to a demodulator 172. The one or more transmitters 117 may transmit signals to the UE 102 using one or more antennas 180 a-n. For example, the one or more transmitters 117 may upconvert and transmit one or more modulated signals 115.
  • The demodulator 172 may demodulate the one or more received signals 174 to produce one or more demodulated signals 170. The one or more demodulated signals 170 may be provided to the decoder 166. The gNB 160 may use the decoder 166 to decode signals. The decoder 166 may produce decoded signals 168 and a gNB-decoded signal 164 (also referred to as a first gNB-decoded signal 164). For example, the first gNB-decoded signal 164 may comprise received payload data, which may be stored in a data buffer 162. Another signal included in the decoded signals 168 (also referred to as a second gNB-decoded signal 168) may comprise overhead data and/or control data. For example, the second gNB decoded signal 168 may provide data that may be used by the gNB operations module 182 to perform one or more operations.
  • The gNB operations module 182 may enable the gNB 160 to communicate with the one or more UEs 102. The gNB operations module 182 may include one or more of a gNB UCI module 194.
  • The gNB UCI module 194 may perform UCI operations. UCI operations may include UCI extraction, UCI de-multiplexing, UCI reconstruction, UCI recompression, etc.
  • In the downlink, the OFDM access scheme with cyclic prefix (CP) may be employed, which may be also referred to as CP-OFDM. In the downlink, PDCCH, EPDCCH, PDSCH and the like may be transmitted. A downlink radio frame may comprise multiple pairs of downlink resource blocks (RBs) which is also referred to as physical resource blocks (PRBs). The downlink RB pair is a unit for assigning downlink radio resources, defined by a predetermined bandwidth (RB bandwidth) and a time slot. The downlink RB pair consists of two downlink RBs that are continuous in the time domain.
  • The downlink RB consists of twelve sub-carriers in frequency domain and seven (for normal CP) or six (for extended CP) OFDM symbols in time domain. A region defined by one sub-carrier in frequency domain and one OFDM symbol in time domain is referred to as a resource element (RE) and is uniquely identified by the index pair (k,l) in a slot, where k and 1 are indices in the frequency and time domains, respectively. While downlink subframes in one component carrier (CC) are discussed herein, downlink subframes are defined for each CC and downlink subframes are substantially in synchronization with each other among CCs. An example of a resource grid in a downlink is discussed in connection with FIG. 2.
  • In the uplink, in addition to CP-OFDM, a Single-Carrier Frequency Division Multiple Access (SC-FDMA) access scheme may be employed, which is also referred to as Discrete Fourier Transform-Spreading OFDM (DFT-S-OFDM). In the uplink, PUCCH, PDSCH, PRACH and the like may be transmitted. An uplink radio frame may comprise multiple pairs of uplink resource blocks. The uplink RB pair is a unit for assigning uplink radio resources, defined by a predetermined bandwidth (RB bandwidth) and a time slot. The uplink RB pair consists of two uplink RBs that are continuous in the time domain.
  • The uplink RB may comprise twelve sub-carriers in frequency domain and seven (for normal CP) or six (for extended CP) OFDM/DFT-S-OFDM symbols in time domain. A region defined by one sub-carrier in the frequency domain and one OFDM/DFT-S-OFDM symbol in the time domain is referred to as a resource element (RE) and is uniquely identified by the index pair (k,l) in a slot, where k and 1 are indices in the frequency and time domains respectively. While uplink subframes in one component carrier (CC) are discussed herein, uplink subframes are defined for each CC. An example of a resource grid in an uplink is discussed in connection with FIG. 3.
  • FIGS. 4A, 4B, 4C, and 4D show examples of several numerologies. The numerology #1 may be a basic numerology. For example, a RE of the basic numerology is defined with subcarrier spacing of 15 kHz in frequency domain and 2048 Ts+CP length (e.g., 160 Ts or 144 Ts) in time domain, where Ts denotes a baseband sampling time unit defined as 1/(15000*2048) seconds. For the i-th numerology, the subcarrier spacing may be equal to 15*21 and the effective OFDM symbol length 2048*2−i*Ts. It may cause the symbol length is 2048*2−i*Ts+CP length (e.g., 160*2−i*Ts or 144*2−i*Ts). In other words, the subcarrier spacing of the i+l-th numerology is a double of the one for the i-th numerology, and the symbol length of the i+l-th numerology is a half of the one for the i-th numerology. FIGS. 4A, 4B, 4C, and 4D show four numerologies, but the system may support another number of numerologies. Furthermore, the system does not have to support all of the 0-th to the I-th numerologies, i=0, 1, . . . , I.
  • FIGS. 5A, 5B, 5C, and 5D show examples of subframe structures for the numerologies that are shown in FIGS. 4A, 4B, 4C, and 4D, respectively. Given that a slot consists of NDL symb (or NUL symb)=7 symbols, the slot length of the i+l-th numerology is a half of the one for the i-th numerology, and eventually the number of slots in a subframe (i.e., 1 ms) becomes double. It may be noted that a radio frame may consists of 10 subframes, and the radio frame length may be equal to 10 ms.
  • FIGS. 6A, 6B, 6C, 6D, 6E and 6F show examples of slots and sub-slots. If sub-slot is not configured by higher layer signaling, the UE and the gNB may only use a slot as a scheduling unit. More specifically, a given transport block may be allocated to a slot. If the sub-slot is configured by higher layer signaling, the UE and the gNB may use the sub-slot as well as the slot. The sub-slot may comprise one or more OFDM symbols. The maximum number of OFDM symbols that constitute the sub-slot may be NDL symb−1 (or NUL symb−1). The sub-slot length may be configured by higher layer signaling. Alternatively, the sub-slot length may be indicated by a physical layer control channel (e.g., by DCI format). The sub-slot may start at any symbol within a slot unless it collides with a control channel. There could be restrictions of mini-slot length based on restrictions on the starting position. For example, the sub-slot with the length of NDL symb−1 (or NUL symb−1) may start at the second symbol in a slot. The starting position of a sub-slot may be indicated by a physical layer control channel (e.g., by DCI format). Alternatively, the starting position of a sub-slot may be derived from information (e.g., search space index, blind decoding candidate index, frequency and/or time resource indices, PRB index, a control channel element index, control channel element aggregation level, an antenna port index, etc.) of the physical layer control channel which schedules the data in the concerned sub-slot. In cases when the sub-slot is configured, a given transport block may be allocated to either a slot, a sub-slot, aggregated sub-slots or aggregated sub-slot(s) and slot. This unit may also be a unit for HARQ-ACK bit generation.
  • FIGS. 7A, 7B, 7C, and 7D show examples of scheduling timelines. For a normal DL scheduling timeline, DL control channels are mapped the initial part of a slot. The DL control channels schedule DL shared channels in the same slot. HARQ-ACKs for the DL shared channels (i.e., HARQ-ACKs each of which indicates whether or not transport block in each DL shared channel is detected successfully) are reported via UL control channels in a later slot. In this instance, a given slot may contain either one of DL transmission and UL transmission. For a normal UL scheduling timeline, DL control channels are mapped the initial part of a slot. The DL control channels schedule UL shared channels in a later slot. For these cases, the association timing (time shift) between the DL slot and the UL slot may be fixed or configured by higher layer signaling. Alternatively, it may be indicated by a physical layer control channel (e.g., the DL assignment DCI format, the UL grant DCI format, or another DCI format such as UE-common signaling DCI format which may be monitored in common search space).
  • For a self-contained base DL scheduling timeline, DL control channels are mapped the initial part of a slot. The DL control channels schedules DL shared channels in the same slot. HARQ-ACKs for the DL shared channels are reported UL control channels which are mapped at the ending part of the slot. For a self-contained base UL scheduling timeline, DL control channels are mapped the initial part of a slot. The DL control channels schedules UL shared channels in the same slot. For these cases, The slot may contain DL and UL portions, and there may be a guard period between the DL and UL transmissions. The use of self-contained slot may be upon a configuration of self-contained slot. Alternatively, the use of self-contained slot may be upon a configuration of the sub-slot. Yet alternatively, the use of self-contained slot may be upon a configuration of shortened physical channel (e.g., PDSCH, PUSCH, PUCCH, etc.).
  • FIGS. 8A and 8B show examples of DL control channel monitoring regions. One or more sets of PRB(s) may be configured for DL control channel monitoring. For example, a control resource set is, in the frequency domain, a set of PRBs within which the UE attempts to blindly decode downlink control information, where the PRBs may or may not be frequency contiguous, a UE may have one or more control resource sets, and one DCI message may be located within one control resource set. In frequency-domain, a PRB is the resource unit size (may or may not including DM-RS) for control channel. DL shared channel may start at a later OFDM symbol than the one(s) which carries the detected DL control channel. Alternatively, the DL shared channel may start at or an earlier OFDM symbol than the last OFDM symbol which carries the detected DL control channel. For example, dynamic reuse of at least part of resources in the control resource sets for data for the same or a different UE, at least in the frequency domain may be supported.
  • FIGS. 9A and 9B show examples of DL control channel which consists of more than one control channel elements. When the control resource set spans multiple OFDM symbols, a control channel candidate may be mapped to multiple OFDM symbols or may be mapped to a single OFDM symbol. One DL control channel element may be mapped on REs defined by a single PRB and a single OFDM symbol. If more than one DL control channel elements are used for a single DL control channel transmission, DL control channel element aggregation may be performed. The number of aggregated DL control channel elements is referred to as DL control channel element aggregation level. The DL control channel element aggregation level may be 1 or 2 to the power of an integer. The gNB may inform UE of which control channel candidates are mapped to each subset of OFDM symbols in the control resource set. If one DL control channel is mapped to a single OFDM symbol and does not span multiple OFDM symbols, the DL control channel element aggregation is performed within an OFDM symbol, namely multiple DL control channel elements within an OFDM symbol are aggregated. Otherwise, DL control channel elements in different OFDM symbols can be aggregated.
  • FIGS. 10A, 10B, and 10C show examples of UL control channel structures. UL control channel may be mapped on REs which are defined by a PRB and a slot in frequency and time domains, respectively. This UL control channel may be referred to as a long format (or just the 1st format). UL control channels may be mapped on REs on a limited OFDM symbols in time domain. This may be referred to as a short format (or just the 2nd format). The UL control channels with a short format may be mapped on REs with in a single PRB. Alternatively, the UL control channels with a short format may be mapped on REs with in multiple PRBs. For example, interlaced mapping may be applied, namely the UL control channel may be mapped to every N PRBs (e.g., 5 PRBs or 10 PRBs) within a system bandwidth.
  • FIG. 11 is a block diagram illustrating one implementation of a gNB. In FIG. 11, a gNB 1160 may substantially correspond to the gNB 160 in FIG. 1. As shown in FIG. 11, the gNB 1160 may include a higher layer processor 1123 a, a DL transmitter 1125, a UL receiver 1133, and antennas 1131 a. The DL transmitter 1125 may include a PDCCH transmitter 1127 and a PDSCH transmitter 1129. The UL receiver 1133 may include a PUCCH receiver 1135 and a PUSCH receiver 1137. The higher layer processor 1123 a may manage physical layer's behaviors (the DL transmitter 1125's and the UL receiver 1133's behaviors) and provide higher layer parameters to the physical layer. The higher layer processor 1123 a may obtain transport blocks from the physical layer. The higher layer processor 1123 a may send/acquire higher layer messages such as an RRC message and MAC message to/from a UE's higher layer. The higher layer processor 1123 a may provide the PDSCH transmitter 1129 transport blocks and provide the PDCCH transmitter 1127 transmission parameters related to the transport blocks. The UL receiver 1133 may receive multiplexed uplink physical channels and uplink physical signals via receiving antennas 1131 a and de-multiplex them. The PUCCH receiver 1135 may provide the higher layer processor UCI. The PUSCH receiver 1137 may provide the higher layer processor received transport blocks.
  • FIG. 12 is a block diagram illustrating one implementation of a UE. In FIG. 12, a UE 1202 may substantially correspond to the UE 102 in FIG. 1. As shown in FIG. 12, the UE1202 may include a higher layer processor 1223 b, a UL transmitter 1249, a DL receiver 1243, and antennas 1231 b. The UL transmitter 1249 may include a PUCCH transmitter 1251 and a PUSCH transmitter 1253. The DL receiver 1243 may include a PDCCH receiver 1245 and a PDSCH receiver 1247. The higher layer processor 1223 b may manage physical layer's behaviors (the UL transmitter 1249's and the DL receiver 1243's behaviors) and provide higher layer parameters to the physical layer. The higher layer processor 1223 b may obtain transport blocks from the physical layer. The higher layer processor 1223 b may send/acquire higher layer messages such as an RRC message and MAC message to/from a UE's higher layer. The higher layer processor 1223 b may provide the PUSCH transmitter 1253 transport blocks and provide the PUCCH transmitter 1251 UCI. The DL receiver 1243 may receive multiplexed downlink physical channels and downlink physical signals via receiving antennas 1231 b and de-multiplex them. The PDCCH receiver 1245 may provide the higher layer processor 1223 b DCI. The PDSCH receiver 1247 may provide the higher layer processor 1223 b received transport blocks.
  • It should be noted that names of physical channels described herein are examples. The other names such as “NRPDCCH, NRPDSCH, NRPUCCH and NRPUSCH” or the like can be used.
  • FIG. 13 is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12, for UCI reporting on PUCCH or PUSCH in case of channel overlap or collision on a single carrier or serving cell.
  • In a method 1300, an exemplary process of UCI reporting on PUCCH or PUSCH in case of a channel overlap or collision is provided by way of example, as there are a variety of ways to carry out the method. Each block shown in FIG. 13A represents one or more processes, methods, or subroutines, carried out in the exemplary processing method. Additionally, the illustrated order of blocks is by example only and the order of the blocks can change. The method 1300 for UCI reporting on PUCCH or PUSCH in case of a channel overlap or collision includes blocks 1302, 1304, 1306, 1308, 1310, 1312, 1314, 1316, and 1318.
  • In the block 1302, the format and configuration of a PUCCH transmission is determined based on a signaling from a gNB (e.g., gNB 1160 in FIG. 11). In the block 1302, the format, waveform, numerology, and configuration of the UCI in the PUCCH transmission are determined.
  • In the block 1304, the format and configuration of a PUSCH transmission is determined based on a signaling from the gNB (e.g., gNB 1160 in FIG. 11). In the block 1304, the format, waveform, and numerology, and configuration of the UCI in the PUSCH transmission are determined.
  • In the block 1306, the UE determines whether there is an overlapping portion between the PUSCH and PUCCH transmissions. An overlapping portion exists, for example, when there are one or more overlapping symbols, for example, in time domain. If it is determined that no overlapping portion is present, the PUSCH and PUCCH are transmitted in block 1308.
  • In the block 1310, after the UE makes the determination that there is an overlapping portion between the PUSCH and PUCCH transmissions in the block 1306, the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. For example, situations where simultaneous transmission of PUCCH and PUSCH is supported include CP-OFDM configured for both the PUCCH and PUSCH, or DFT-S-OFDM with the same numerology configured for both the PUCCH and PUSCH. In one implementation, the UE may make the determination in the block 1310 by using the following three cases:
      • (1) The PUCCH and PUSCH are configured with different waveform/modulation methods (e.g., PUCCH using CP-OFDM and PUSCH using DFT-S-OFDM or vice versa).
      • (2) The PUCCH and PUSCH are configured with DFT-S-OFDM, but different numerologies are applied for the PUCCH and PUSCH transmissions.
      • (3) The UE does not support simultaneous PUCCH and PUSCH transmission, or simultaneous PUCCH and PUSCH is not configured for the UE.
  • If the UE determines that simultaneous PUCCH and PUSCH transmission is not supported, then the method 1300 proceeds to either the block 1312 or 1314. The UE determines whether the UCI is carried on the PUCCH or the PUSCH, and whether to transmit the PUCCH and/or PUSCH. In the block 1312, the UE is to transmit the UCI using the PUCCH in the overlapping portion between the PUCCH transmission and the PUSCH transmission, and drop (e.g., not transmit) PUSCH symbols in the overlapping portion of the PUSCH transmission. In the block 1314, the UE is to transmit the UCI using the PUSCH by multiplexing the UCI on the overlapping portion of the PUSCH transmission, and drop (e.g., not transmit) the PUCCH. The default behavior of selecting the block 1312 or 1314 may depend on the uplink control channel format.
  • In the block 1310, if the UE determines that simultaneous PUCCH and PUSCH transmission is supported, then the method 1300 proceeds to the block 1316.
  • In the block 1316, simultaneous PUCCH and PUSCH data transmission on the overlapping symbols is performed, and power allocation of overlapping symbols prioritizes the PUCCH transmission.
  • In the block 1318, if power is limited in the block 1316, the remaining power after PUCCH allocation may be allocated to the PUSCH REs in the symbol with power scaling if applicable.
  • In NR, at least two different types of uplink control channel (PUCCH) formats may be specified, at least one short PUCCH format and one long PUCCH format. The PUCCH channel is designed to carry uplink control information (UCI). Also, the physical uplink shared channel (PUSCH) will be defined to carry uplink data. The UCI may be reported on PUCCH or a PUSCH or both.
  • In NR, the PUCCH format and PUSCH format may be configured independently. The waveform type and numerologies for different channels may be the same or different. Thus, simultaneous transmission of PUCCH and PUSCH is restricted by many different conditions. Detailed methods on how to report UCI on which type of channel is under study and not defined yet. The present disclosure provides solutions and procedures for UCI reporting on different UL channels and formats.
  • In NR, several PUCCH formats will be specified. For UCI, different UCI may be reported on different PUCCH channel formats. Also, for NR, the PUSCH channel may also be very flexible, the size of a PUSCH may be a mini-slot, a slot, or span over multiple slots.
  • In NR, both cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) and discrete Fourier transform spread OFDM (DFT-S-OFDM) waveforms are supported for UL transmission. Also, different numerologies may be used on one or more carriers or serving cells. The PUCCH and PUSCH transmissions from a UE may experience collision in some cases.
  • The UCI may be transmitted as L1/L2 control signaling, for example, via a PUCCH, PUSCH, or uplink data channel. Furthermore, the timing, between data reception and HARQ-ACK transmission as part of the downlink control information (DCI), may be dynamically indicate (at least in combination with radio resource control (RRC)).
  • In NR, different numerologies are supported on the same or different carriers. For the uplink transmission supports two waveform/modulation schemes based on Orthogonal Frequency Division Multiplexing (OFDM), such as Cyclic Prefix OFDM (CP-OFDM), Discrete Fourier Transform (DFT) Spread OFDM (DFT-S-OFDM), also known as Single Carrier FDMA (SC-FDMA), or low Peak-to-Average Power Ratio (PAPR) waveform.
  • Therefore, the uplink control and uplink data channel may be configured separately with the same or different waveforms and numerologies. The uplink control channel and uplink data channel collision and multiplexing should take into account all possible combinations.
  • FIG. 13B is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the UE in FIG. 12, for reporting UCI. A method 1360 includes blocks 1362 and 1364. In block 1362, the method 1360 includes storing, by the UE, information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported. In block 1364, the method 1360 further includes transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH transmission and the PUSCH transmission, and dropping the overlapping portion of the PUSCH transmission, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH transmission and a PUSCH transmission.
  • FIG. 13C is a schematic diagram illustrating an exemplary implementation of a flow chart of a method, performed by the gNB in FIG. 11, for receiving UCI from a UE. A method 1380 includes blocks 1382 and 1384. In block 1382, the method 1380 includes acquiring, by the gNB, information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE. In block 1384, the method 1380 further includes receiving the UCI using the PUCCH transmission in an overlapping portion between the PUCCH transmission and the PUSCH transmission, and not receiving the overlapping portion of the PUSCH transmission, when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH transmission and a PUSCH transmission.
  • FIG. 14A illustrates examples of short PUCCH formats. In NR, at least two transmission durations are supported for uplink control, one short around the last OFDM symbol in a slot, TDMed or FDMed with data, and one long spanning multiple symbols (e.g., filling most of a slot or slots), FDMed with data. A short PUCCH is suitable for 1 or 2 bits of HARQ-ACK feedback and/or SR.
  • In one implementation, a short PUCCH format may occupy only one symbol. In this implementation, CP-OFDM modulation may be used. Reference symbols 1404 and UCI carrying symbols 1402 may be multiplexed in different subcarriers of a PUCCH resource, as shown in slot 1401 of FIG. 14A (i.e., FDM case).
  • In another implementation, a short PUCCH format may occupy two symbols. In this implementation, both CP-OFDM and DFT-S-OFDM modulations may be used. In case of DFT-S-OFDM, reference symbol 1404 and the UCI carrying symbol 1402 may be TDM multiplexed, as shown in slot 1405 of FIG. 14A (i.e., TDM case).
  • In yet another implementation, a short PUCCH may occupy one symbol of a reference numerology by splitting it into two symbols with a higher numerology, for example, by doubling the subcarrier spacing and reducing the symbol length by half, as shown in slot 1407 of FIG. 14A (i.e., TDM with symbol splitting case). In another example, a 2-symbol PUCCH may be used.
  • In yet another implementation, for TDM of a short PUCCH, in order to support TDM of short PUCCH from different UEs in the same slot, a mechanism to tell the UE in which symbol(s) in a slot to transmit the short PUCCH on is supported at 6 GHz or above.
  • A long PUCCH format may span multiple symbols and slots. Multiple long PUCCH formats may be defined, e.g., 4 symbols, a slot, and multiple slots, and etc. A long PUCCH format may be useful for larger payload HARQ-ACK feedback, CSI feedback, and etc.
  • At least a low PAPR/CM waveform should be supported for the long PUCCH format. A UCI carried by long duration UL control channel at least with low PAPR waveform may be transmitted in one slot or multiple slots, and transmission across multiple slots may allow a total duration of about 1 ms at least for some cases.
  • In terms of PUCCH format configuration, a combination of semi-static configuration and (at least for some types of UCI information) dynamic signaling is used to determine the PUCCH resource both for the long and short PUCCH formats.
  • In a LTE licensed band, a PUSCH may span over all symbols in a UL subframe. The last portion of a PUSCH may be punctured and replaced by a sounding reference signal (SRS) transmission. In LTE licenses assisted access (LAA), a PUSCH may not transmit in the first symbol and/or the last symbol of a UL LAA subframe. Furthermore, in the LTE shortened transmission time interval (sTTI) design, a UL sTTI may have a length of 2 symbols, 4 symbols or 7 symbols.
  • In NR, a PUSCH structure is more flexible as compared to that in LTE. For example, a PUSCH may be scheduled in mini-slot and slot levels. Furthermore, slot aggregation is supported. As such, a PUSCH can be scheduled across multiple slots. A mini-slot may be the minimum scheduling unit of a PUSCH transmission. The length of a mini-slot may be 2 symbols to the (slot length−1). The mini-slot length may support one symbol at least for bands over 6 GHz.
  • A PUSCH in NR may use the reference numerology of a serving cell. A PUSCH in NR may be scheduled using a different numerology from the reference numerology of the serving cell.
  • As in LTE, in NR, UCI on PUSCH is supported, for example, using portions of the scheduled resources for UCI in case of simultaneous UCI and data transmission.
  • For a UE, a long PUCCH format may use CP-OFDM modulation and DFT-S-OFDM modulation. A long PUCCH format may use the reference numerology of the serving cell, or a different numerology from the reference numerology of the serving cell.
  • In one implementation, the short PUCCH and long PUCCH formats may be configured for each UE. The short PUCCH format and the long PUCCH format may use the same modulation method (e.g., all CP-OFDM based). In another implementation, the short PUCCH format and the long PUCCH format may use different modulation methods (e.g., a short 1-symbol PUCCH using CP-OFDM, and a long multiple-symbol PUCCH using DFT-S-OFDM). Furthermore, the short PUCCH and long PUCCH may be configured with the same numerology or with different numerologies.
  • Different UEs may be configured with the same or different PUCCH formats. For a given UE, the PUSCH format may have the same waveform modulation as the PUCCH format. The PUSCH format may have a different waveform modulation from the PUCCH format. The PUSCH format may have the same numerology as the PUCCH format. The PUSCH format may have a different numerology from the PUCCH format. In addition, since NR supports different short or long PUCCH formats with different lengths, the length of a scheduled PUSCH transmission may be the same or different from the PUCCH format. Furthermore, a PUSCH resource may fully overlap or partially overlap with a PUCCH resource (e.g., symbols), for example, in time domain.
  • There are several different cases to be considered for the PUSCH and PUCCH multiplexing, depending on the waveform/modulation methods and other configurations. If the modulation method is CP-OFDM for both PUCCH and PUSCH, multiplexing of different channels is possible. Furthermore, applying different numerologies for PUSCH and PUSCH may also be possible in FDM.
  • If different waveform/modulation methods are used for PUCCH and PUSCH, multiplexing PUCCH and PUSCH channels is not possible regardless of whether the same or different numerologies are used. If DFT-S-OFDM is used for both PUCCH and PUSCH, but PUCCH and PUSCH are configured with different numerologies, multiplexing PUCCH and PUSCH channels is not possible. Table 1 lists the combinations of PUCCH and PUSCH and whether simultaneous PUCCH and PUSCH transmission is possible.
  • TABLE 1
    Simultaneous
    PUCCH PUSCH PUCCH and
    Waveform Waveform Numerology PUSCH
    CP-OFDM DFT-S-OFDM Any Not possible
    DFT-S-OFDM CP-OFDM Any Not possible
    DFT-S-OFDM DFT-S-OFDM Different numerologies Not possible
    for PUCCH and
    PUSCH
    DFT-S-OFDM DFT-S-OFDM Same numerology Possible
    for PUCCH and
    PUSCH
    CP-OFDM CP-OFDM Any Possible
  • If simultaneous PUCCH and PUSCH transmission is possible, there are several options:
      • (1) Simultaneous PUCCH and PUSCH transmission may have a default behavior.
      • (2) Whether or not to support simultaneous PUCCH and PUSCH transmission may be a UE capability.
      • (3) Whether or not to support simultaneous PUCCH and PUSCH transmission may be configured.
  • Since NR may support different short or long PUCCH formats with different lengths, the length of a scheduled PUSCH transmission may be the same or different from a PUCCH format. Also, a PUSCH resource may overlap or partial overlap with a PUCCH resource.
  • Furthermore, simultaneous transmission of a short PUCCH format and a long PUCCH format can be very different. A short PUCCH only occupies 1 or 2 symbols, while a long PUCCH format may span over multiple slots. Thus, the two PUCCH formats are discussed separately below.
  • FIG. 14B illustrates some examples of data and UCI multiplexing with short PUCCH shown in slots 1411, 1413, 1415, and 1417 for downlink (DL) and uplink (UL) transmissions. In case of a short uplink control format, it has been agreed that it can be multiplexed with data using FDM and/or TDM.
  • FDM of short UCI and data should be supported, both within a UE and between UEs at least for the case where the PRBs for short UCI and data are non-overlapping. Thus, if possible, FDM of data and UCI on short PUCCH should be supported, as least can be configurable. Thus, simultaneous short PUCCH and PUSCH transmission should be supported when possible.
  • In a DL centric slot, the last symbol may be reserved for HARQ-ACK feedback. Thus, UL data may not be allowed in the last symbol, and may not be scheduled for PUSCH transmission. On the other hand, if the last symbol is scheduled as a part of a UL data transmission, simultaneous PUCCH and PUSCH transmission may be supported.
  • Moreover, a short PUCCH in NR may be TDMed in different symbols for different UEs. Thus, the short PUCCH may not be limited to the last symbol(s) of a slot. The short PUCCH may use one or two symbols. Thus, a simple solution of prioritizing short PUCCH over PUSCH data may be sufficient. Several methods are considered for simultaneous PUCCH and PUSCH transmission.
  • FIG. 15 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and short PUCCH overlapping or collision. An overlap or collision between a short PUCCH and a PUSCH occurs if there is any overlapping in time domain. In FIG. 15, several examples of a short PUCCH 1502 using one or two symbols are shown where the PUCCH and PUSCH may have overlapping resource elements (REs) in a frequency subcarrier. In other implementations, a PUCCH and PUSCH overlap or collision may occur even if the PUCCH and PUSCH use different frequency subcarriers. In the present implementation, the short PUCCH 1502 is prioritized over the PUSCH transmission 1504.
  • In FIG. 15, several overlapping/collision cases, as shown in examples 1501, 1503, 1505, and 1507, are considered for simultaneous PUCCH and PUSCH transmissions. The collision(s) may be a full overlap or a partial overlap in time domain between the PUCCH and PUSCH transmissions. For example, in the example 1501, an overlap or collision may occur, when the short PUCCH 1502 (e.g., a 1-symbol short PUCCH) overlaps with a scheduled PUSCH transmission 1504. For a short PUCCH 1502 (e.g., a 2-symbol short PUCCH), as shown in the examples 1503, 1505, and 1507, an overlap or collision may occur, when any symbol of a short PUCCH 1502 overlaps with a scheduled PUSCH transmission 1504. In the example 1503, a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) fully overlaps with a scheduled PUSCH transmission 1504. In the example 1505, a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) partially overlaps with an end portion of a scheduled PUSCH transmission 1504. In the example 1507, a short PUCCH 1502 (e.g., a 2-symbol short PUCCH) partially overlaps with a beginning portion of a scheduled PUSCH transmission 1504.
  • In a case, where the PUCCH and PUSCH transmissions do not overlap or collide, the PUCCH and PUSCH are transmitted according to their scheduling. However, when there is an overlap or collision between the PUCCH and PUSCH transmissions, the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. If simultaneous transmission of PUCCH and PUSCH is not supported, the UE determines which method to use to transmit the PUCCH and PUSCH.
  • In the following cases, simultaneous PUCCH and PUSCH transmission may not be supported.
      • (1) The PUCCH and PUSCH are configured with different waveform/modulation methods (e.g., PUCCH using CP-OFDM and PUSCH using DFT-S-OFDM or vice versa).
      • (2) The PUCCH and PUSCH are configured with DFT-S-OFDM, but different numerologies are applied for the PUCCH and PUSCH transmissions.
      • (3) The UE does not support simultaneous PUCCH and PUSCH transmission, or simultaneous PUCCH and PUSCH is not configured for the UE.
  • Thus, simultaneous transmission of PUCCH and PUSCH may not be supported when the UE is not capable and/or configured for simultaneous PUCCH and PUSCH transmission. Moreover, simultaneous transmission of PUCCH and PUSCH may not be supported when the PUCCH and the PUSCH are configured with different waveforms, or the PUCCH and the PUSCH are configured with DFT-S-OFDM but have different numerologies.
  • When simultaneous transmission of PUCCH and PUSCH is not supported, there are several options: simultaneous PUCCH and PUSCH transmission may have a default behavior, whether or not to support simultaneous PUCCH and PUSCH transmission may be a UE's capability, and whether or not to support simultaneous PUCCH and PUSCH transmission may be configured. Since NR supports different short or long PUCCH formats with different lengths, the length of a scheduled PUSCH transmission may be the same or different from a PUCCH format. Also, a PUSCH may fully overlap or partially overlap with a PUCCH resource. Furthermore, simultaneous transmission of a short PUCCH format and a long PUCCH format can be very different. A short PUCCH only occupies 1 or 2 symbols, while a long PUCCH format may span over multiple slots.
  • FIG. 16A illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported. As shown in FIG. 16A, examples 1601, 1603, 1605, and 1607 each illustrate a short PUCCH 1602 overlapping (e.g., fully or partially) with a PUSCH 1604. In the present exemplary method shown in FIG. 16A, the UE transmits the short PUCCH transmission 1604 and drops (not transmit) the overlapping portion of the PUSCH data 1606 of the PUSCH 1604.
  • As shown in FIG. 16A, in the example 1601, the short PUCCH 1602 (e.g., a 1-symbol short PUCCH) fully overlaps with a scheduled PUSCH 1604. In the example 1603, a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) fully overlaps with a scheduled PUSCH 1604. In the example 1605, a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) partially overlaps with an end portion of a scheduled PUSCH 1604. In the example 1607, a short PUCCH 1602 (e.g., a 2-symbol short PUCCH) partially overlaps with a beginning portion of a scheduled PUSCH 1604. In all of the examples 1601, 1603, 1605, and 1607, the UE transmits the short PUCCH 1602 and drops (not transmit) the overlapping portion of the PUSCH data 1606 of the PUSCH 1604. It is noted that the remaining portions of the PUSCH 1604 are still transmitted. That is, only the REs of the PUSCH data 1606 (e.g., symbol(s)) that overlaps or collides with the short PUCCH 1602 is dropped. For example, the PUSCH transmission may be stopped before the PUCCH transmission, and resumed after the PUCCH transmission.
  • In the present exemplary method shown in FIG. 16A, the PUCCH transmission may take priority over the PUSCH transmission regardless of whether the same or different waveforms and/or numerologies are applied for PUCCH and PUSCH. This method is particularly advantageous for a downlink centric slot where only UL symbols for short PUCCH is present in the slot.
  • The present exemplary method handles overlapping portions of a PUCCH and a PUSCH, when simultaneous PUCCH and PUSCH transmission is not supported, by transmitting the short PUCCH and dropping (not transmitting) the overlapping portion of the PUSCH data of the PUSCH transmission. In other words, when there is an overlap or collision between a short PUCCH transmission and a PUSCH transmission, the PUCCH transmission is prioritized over PUSCH data in the PUSCH transmission. Since a short PUCCH occupies one or two symbols, the number of REs available for PUSCH is limited on the PUCCH carrying symbols. Thus, dropping the PUSCH on a limited number of symbols may not have a significant impact on the PUSCH performance. The present exemplary method may be set as a default behavior for short PUCCH and PUSCH overlap/collision examples shown in FIG. 16A.
  • Similar to a short PUCCH transmission, a sounding reference signal (SRS) transmission only occupies one or two symbols. Thus, the same method described with reference to FIG. 16 may be used for an SRS transmission with a PUSCH transmission. Therefore, if an SRS transmission is scheduled with overlapping symbols of a PUSCH transmission, the overlapping PUSCH symbols may be dropped, and the SRS should be transmitted. It is noted that if a PUCCH collides with a scheduled SRS transmission, the SRS may be dropped. The transmission priority from the highest to the lowest, according to an implementation of the presentation is as follows: UCI on PUCCH, UCI on PUSCH, SRS, and PUSCH with data only.
  • FIG. 16B illustrates an exemplary implementation of another method of handling overlapping portions of a short PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported. As shown in FIG. 16B, examples 1601, 1603, 1605, and 1607 each illustrate a short PUCCH 1602 overlapping with a PUSCH 1604. In the present exemplary method shown in FIG. 16B, the UE drops the short PUCCH 1602 and multiplexes the UCI of the short PUCCH 1602 on the PUSCH 1604.
  • In the present exemplary method, the UCI is multiplexed on PUSCH data 1606 of the symbol(s) scheduled for the short PUCCH 1602 in an overlapping region 1609. As shown in the overlapping region 1609 of FIG. 16B, for the short PUCCH 1602 (e.g., a 1-symbol short PUCCH), the UCI is multiplexed on the PUSCH 1604. This ensures the UCI timing of PUCCH reporting is maintained even when the UCI is carried on the PUSCH 1604. To provide enough protection, a beta offset may be configured for control information multiplexing. The beta offset determines the coding rate redundancy of control information over data information. The coded bit after beta offset rate matching may be multiplexed on the PUSCH data symbols by replacing the existing PUSCH data symbols.
  • FIG. 16B shows several examples of a UCI multiplexing on a PUSCH in the overlapping symbols of a short PUCCH 1602 and a PUSCH 1604. In the examples 1601, 1605, and 1607, each UCI is multiplexed on the overlapping PUCCH 1602 and PUSCH 1604 symbol(s) (e.g., only 1 symbol in each case), as shown in the overlapping region 1609. The coded UCI bit loading may be performed in frequency domain of the PUSCH allocated resources (e.g., on REs in subcarriers with frequency high to low). In another example, if DFT-S-OFDM is used on the PUSCH, and the overlapping symbol is the DMRS symbol, the bit loading may be performed on the next symbol instead.
  • It should be noted that, in a case where the short PUCCH 1602 starts earlier than the PUSCH 1604, if the short PUCCH 1602 has already started before the PUSCH 1604, the method described with reference to FIG. 16A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case.
  • In the example 1603 in FIG. 16B, two approaches may be considered for fully overlapping of a 2-symbol short PUCCH. In the first approach (i.e., approach 1613), the UCI may be multiplexed on all overlapping symbols, shown in the approach 1611, to provide time diversity gain. The coded UCI bit multiplexing may be performed first in time domain, and then in frequency domain of the PUSCH allocated resources (e.g., on REs in time domain from the earliest symbol first on subcarriers with frequencies from high to low). In the second approach (i.e., approach 1613), the UCI may be multiplexed to the earliest symbol of the overlapping region, which provides slightly faster UCI feedback than the multiplexing in the approach 1611. In approach 1613, the coded UCI bit multiplexing may be performed first in the frequency domain then in the time domain of the PUSCH allocated resources (e.g., on REs in the earliest symbol first on subcarriers with frequency from high to low).
  • For the two methods described with reference to FIGS. 16A and 16B, NR may determine a default behavior. The default behavior may include (1) transmitting the PUCCH and dropping the overlapping symbols on the PUSCH; (2) PUCCH UCI multiplexing on the PUSCH. In another implementation, the UE's behavior may be configured by a base station (e.g., gNB).
  • FIG. 17 illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is supported. If a PUCCH region is defined/configured, the PUSCH may not overlap with the configured PUCCH region in frequency domain. Thus, there is no overlapping between PUCCH and PUSCH resource elements (REs) scheduled for a UE. Simultaneous PUCCH and PUSCH data transmission on the overlapping symbols may be performed in a FDM manner. On the other hand, if a PUCCH resource element overlaps with a scheduled PUSCH transmission, the PUCCH symbol(s) may be transmitted, and the PUSCH symbol(s) of the overlapped REs may be punctured, for example.
  • For CP-OFDM based transmissions, the overlapping PUSCH REs can be punctured. For DFT-S-OFDM based transmissions, puncturing overlapping PUSCH REs may be one option, which might cause minor issues during decoding on the receiver end (e.g., a gNB) due to, for example, break(s) in the DFT output. In another option, the puncturing may be performed at input complex number input before the DFT. The punctured input may then undergo DFT and bit loading to the corresponding REs with rate matching over the punctured symbols by the PUCCH transmission. For both options, the power allocation of overlapping symbols prioritizes the short PUCCH transmission.
  • As shown in examples 1701, 1703, 1705, and 1707 of FIG. 17, in the power limited case, the remaining powers after the PUCCH 1702 allocation can be allocated to the PUSCH REs 1706 in the symbol with power scaling when applicable.
  • FIG. 18 is a schematic diagram illustrating an exemplary implementation of types of PUSCH and long PUCCH overlapping or collision. In FIG. 18, examples 1801, 1803, 1805, and 1807 each show an overlapping or collision between a long PUCCH 1802 and a PUSCH 1804. The long PUCCH 1802 formats may span over multiple symbols or slots, and are more likely to schedule simultaneously with the PUSCH 1804. In case of simultaneous UCI and data, the UCI may use at least a portion of the scheduled data resources. Furthermore, since NR supports long PUCCH formats with different lengths, the length of a scheduled PUSCH transmission may be the same or different from the PUCCH format. Thus, a PUSCH may fully overlap or partial overlap with a PUCCH resource.
  • In FIG. 18, several overlapping/collision cases, as shown in examples 1801, 1803, 1805, and 1807, are considered for simultaneous PUCCH and PUSCH transmissions. The collision(s) may be a full overlap or a partial overlap in time domain between the PUCCH and PUSCH transmissions. For example, in the example 1801, a long PUCCH 1802 may fully overlap within a PUSCH 1804. In the examples 1803 and 1805, a long PUCCH 1802 may partially overlap within a PUSCH 1804. In the example 1807, a long PUCCH transmission 1802 format may be longer than a scheduled PUSCH 1804. Similar to collision with short PUCCH cases described above, the following cases can be considered for PUSCH collision with long PUCCH formats.
  • In a case, where PUCCH and PUSCH transmissions do not overlap or collide, the PUCCH and PUSCH are transmitted according to their scheduling. However, when there is an overlap or collision between the PUCCH and PUSCH transmissions, the UE determines whether simultaneous transmission of PUCCH and PUSCH is supported. If simultaneous transmission of PUCCH and PUSCH is not supported, the UE determines which method to use to transmit the PUCCH and PUSCH.
  • In the following cases, simultaneous PUCCH and PUSCH transmission may not be supported:
      • (1) PUCCH and PUSCH are configured with different waveform/modulation methods (e.g., PUCCH using CP-OFDM and PUSCH using DFT-S-OFDM or vice versa).
      • (2) PUCCH and PUSCH are configured with DFT-S-OFDM, but different numerologies are applied for PUCCH and PUSCH transmissions.
      • (3) The UE does not support simultaneous PUCCH and PUSCH transmission, or simultaneous PUCCH and PUSCH is not configured for a UE.
  • FIG. 19A illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported. As shown in FIG. 19A, examples 1901, 1903, 1905, and 1907 each illustrate a long PUCCH 1902 transmission overlapping (e.g., fully or partially) with a PUSCH 1904. In the present exemplary method shown in FIG. 19A, the UE transmits the long PUCCH 1904 and drops (not transmit) the overlapping portion of the PUSCH data 1906 of the PUSCH 1904.
  • As shown in FIG. 19A, in the example 1901, a long PUCCH 1902 fully overlaps with a scheduled PUSCH 1904, where the long PUCCH 1902 is shorter than the PUSCH 1904. In the example 1903, a long PUCCH 1902 partially overlaps with an end portion of a scheduled PUSCH 1904. In the example 1905, a long PUCCH 1902 partially overlaps with a beginning portion of a scheduled PUSCH 1904. In the example 1907, a long PUCCH 1902 fully overlaps with a scheduled PUSCH 1904, where the long PUCCH 1902 is longer than the PUSCH 1904. It is noted that, in the example 1907, the entire PUSCH is dropped.
  • In all of the examples 1901, 1903, 1905, and 1907, the UE transmits the long PUCCH 1902 and drops (not transmit) the overlapping portion of the PUSCH data 1906 of the PUSCH 1904. It is noted that the remaining portions (if any) of the PUSCH 1904 are still transmitted. That is, only the REs of the PUSCH data 1906 (e.g., symbol(s)) that overlaps or collides with the long PUCCH 1902 is dropped. For example, the PUSCH transmission may be stopped before the PUCCH transmission, and resumed after the PUCCH transmission.
  • In the present exemplary method shown in FIG. 19A, the PUCCH transmission may take priority over the PUSCH transmission regardless of whether the same or different waveforms and/or numerologies are applied for PUCCH and PUSCH.
  • However, since the long PUCCH 1902 may span over multiple symbols, dropping all PUSCH REs of these symbols may have more impact on the PUSCH performance than the short PUCCH case. Thus, the present exemplary method shown in FIG. 19A may not be preferable for long PUCCH and PUSCH overlapping at least from some implementations, since dropping the entire or a major portion of the PUSCH may cause issues during decoding on the receiver end (e.g., a gNB).
  • Thus, the PUSCH dropping method as described with reference to FIG. 16a may be conditional. A threshold value can be used to determine whether the PUSCH should be partially transmitted or dropped entirely. The threshold can be a number of overlapping symbols or a percentage of overlapping symbols within the PUSCH transmission. If below the threshold, the PUSCH is partially transmitted by dropping the overlapping symbols with the PUCCH. If above the threshold, the PUSCH is dropped entirely. The threshold can be a default value or semi-statically configured by higher layer signaling.
  • FIG. 19B illustrates an exemplary implementation of another method of handling overlapping portions of a long PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is not supported. As shown in FIG. 19B, examples 1901, 1903, 1905, and 1907 each illustrate a long PUCCH 1902 transmission overlapping with a PUSCH 1904. In present exemplary method shown in FIG. 19B, the UE drops the long PUCCH 1902 and multiplexes the UCI of the long PUCCH transmission 1902 on the PUSCH 1904. When simultaneous PUCCH and PUSCH transmission is not supported, the present exemplary method provides UCI multiplexing on the PUSCH, and may be a default behavior for long PUCCH and PUSCH overlapping.
  • In the present exemplary method, the UCI is multiplexed with the PUSCH 1904 on the overlapping symbol(s) scheduled for the long PUCCH 1902 in an overlapping region. This ensures the UCI timing of PUCCH reporting is maintained even when the UCI is carried on the PUSCH 1904. To provide enough protection, a beta offset may be configured for control information multiplexing. The beta offset determines the coding rate redundancy of control information over data information. The coded bit after beta offset rate matching should be multiplexed on the PUSCH data symbols by replacing existing PUSCH data symbols.
  • Since the multiplexing region includes multiple symbols, at least two approaches for multiplexing the UCI of long PUCCH 1902 to the PUSCH 1904 can be considered, as shown in example 1901,1903, 1905 and 1907.
  • In the first exemplary approach (i.e., approach 1909), the UCI may be multiplexed on all overlapping symbols between the long PUCCH 1902 and PUSCH 1904, to provide time diversity gain, as shown in example 1901 of FIG. 19B. In the approach 1909, the coded UCI bit multiplexing may be performed first in time domain, and then in frequency domain of the PUSCH allocated resources (e.g., on REs in time domain from earliest symbol first on subcarriers with frequencies from high to low). It is noted that, in a special case of the approach 1909, not all symbols may be used for UCI multiplexing. That is, the UCI may be multiplexed on a subset of symbols in the overlapping region (e.g., on symbols adjacent or close to the demodulation symbols only), especially for the case of DFT-S-OFDM based transmission. While this approach may be more suitable for DFT-S-OFDM based transmissions, it may also be used for CP-OFDM based transmissions.
  • In the second exemplary approach (i.e., approach 1911), the UCI may be first multiplexed to the earliest symbols, which may provide a slight faster UCI feedback than the first exemplary approach. In this approach 1911, the coded UCI bit multiplexing may be performed first in frequency domain, and then in time domain of the PUSCH allocated resources (e.g., on REs in the earliest symbol first on subcarriers with frequencies from high to low). It is noted that, in a special case under the approach 1911, not all symbols may be used for UCI multiplexing. That is, the UCI may be multiplexed on a subset of symbols in the overlapping region (e.g., on symbols adjacent or close to the demodulation symbols only). While this approach may be more suitable for CP-OFDM based transmissions, it may also be used for DFT-S-OFDM based transmissions.
  • Furthermore, long PUCCH UCI multiplexing on PUSCH should consider two exceptional cases.
  • It should be noted that, in a case where the PUCCH transmission has already started before the PUSCH transmission, the method described with reference to FIG. 19A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case. In another case, the overlapping region on a PUSCH is too small, and/or does not have the capacity to carry all of the UCI of a long PUCCH, the method described with reference to FIG. 19A may be a better approach for transmitting the UCI, as multiplexing may not be suitable in such case.
  • Thus, the multiplexing method as described with reference to FIG. 19B may be conditional. A threshold value can be used to determine whether the UCI should be multiplexed on PUSCH or transmitted on PUCCH. The threshold may be a number of REs required for UCI multiplexing on a given PUSCH. If the number of REs in the overlapping area is less than the number of REs required for UCI multiplexing on a given PUSCH, the UE may transmit the long PUCCH and drop the overlapping symbols on the PUSCH. Otherwise, the UCI is multiplexed on the PUSCH.
  • For the two methods described with reference to FIGS. 19A and 19B, NR may determine a default behavior. The default behavior may include (1) transmitting the PUCCH and dropping the overlapping symbols on the PUSCH; (2) PUCCH UCI multiplexing on the PUSCH. In another implementation, the UE's behavior may be configured by a base station (e.g., gNB).
  • FIG. 20, illustrates an exemplary implementation of a method of handling overlapping portions of a PUCCH and a PUSCH when simultaneous PUCCH and PUSCH transmission is supported. If a PUCCH region is defined/configured, the PUSCH may multiplex with the configured PUCCH region. Thus, there is no overlapping between PUCCH and PUSCH REs scheduled for a UE. On the other hand, if PUCCH REs overlap with PUSCH REs, the PUCCH REs (e.g., symbols) may be transmitted, and the PUSCH REs (e.g., symbols) of the overlapped REs may be punctured.
  • For CP-OFDM based transmissions, the overlapping PUSCH REs can be punctured. For DFT-S-OFDM based transmissions, puncturing overlapping PUSCH REs may be one option, which might cause minor issues during decoding on the receiver end (e.g., a gNB) due to, for example, break(s) in the DFT output. In another option the puncturing may be performed at input complex number input before DFT. The punctured input may then undergo DFT and bit loading to the corresponding REs with rate matching over the punctured symbols by the PUCCH transmission. For both options, the power allocation of overlapping symbols prioritizes the short PUCCH transmission.
  • As shown in examples 2001, 2003, 2005, and 2007 of FIG. 20, in the power limited case, the remaining powers after the PUCCH 2002 allocation can be allocated to the PUSCH REs 2006 in the symbol with power scaling when applicable.
  • The term “computer-readable medium” refers to any available medium that can be accessed by a computer or a processor. The term “computer-readable medium,” as used herein, may denote a computer- and/or processor-readable medium that is non-transitory and tangible. By way of example, and not limitation, a computer-readable or processor-readable medium may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray® disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.
  • It should be noted that one or more of the methods described herein may be implemented in and/or performed using hardware. For example, one or more of the methods described herein may be implemented in and/or realized using a chipset, an application-specific integrated circuit (ASIC), a large-scale integrated circuit (LSI) or integrated circuit, etc.
  • Each of the methods disclosed herein comprises one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another and/or combined into a single step without departing from the scope of the claims. In other words, unless a specific order of steps or actions is required for proper operation of the method that is being described, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.
  • It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various modifications, changes and variations may be made in the arrangement, operation and details of the systems, methods, and apparatus described herein without departing from the scope of the claims.
  • A program running on the gNB (e.g., gNB 160 in FIG. 1) or the UE (e.g., UE 102 in FIG. 1) according to the described systems and methods is a program (a program for causing a computer to operate) that controls a CPU and the like in such a manner as to realize the function according to the described systems and methods. Then, the information that is handled in these apparatuses is temporarily stored in a RAM while being processed. Thereafter, the information is stored in various ROMs or HDDs, and whenever necessary, is read by the CPU to be modified or written. As a recording medium on which the program is stored, among a semiconductor (for example, a ROM, a nonvolatile memory card, and the like), an optical storage medium (for example, a DVD, a MO, a MD, a CD, a BD, and the like), a magnetic storage medium (for example, a magnetic tape, a flexible disk, and the like), and the like, any one may be possible. Furthermore, in some cases, the function according to the described systems and methods described above is realized by running the loaded program, and in addition, the function according to the described systems and methods is realized in conjunction with an operating system or other application programs, based on an instruction from the program.
  • Furthermore, in a case where the programs are available on the market, the program stored on a portable recording medium can be distributed or the program can be transmitted to a server computer that connects through a network such as the Internet. In this case, a storage device in the server computer also is included. Furthermore, some or all of the eNB 160 and the UE (e.g., UE 102 in FIG. 1) according to the systems and methods described above may be realized as an LSI that is a typical integrated circuit. Each functional block of the eNB 160 and the UE 102 may be individually built into a chip, and some or all functional blocks may be integrated into a chip. Furthermore, a technique of the integrated circuit is not limited to the LSI, and an integrated circuit for the functional block may be realized with a dedicated circuit or a general-purpose processor. Furthermore, if with advances in a semiconductor technology, a technology of an integrated circuit that substitutes for the LSI appears, it is also possible to use an integrated circuit to which the technology applies.
  • Moreover, each functional block or various features of the base station device and the terminal device used in each of the aforementioned embodiments may be implemented or executed by a circuitry, which is typically an integrated circuit or a plurality of integrated circuits. The circuitry designed to execute the functions described in the present specification may comprise a general-purpose processor, a digital signal processor (DSP), an application specific or general application integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic, or a discrete hardware component, or a combination thereof. The general-purpose processor may be a microprocessor, or alternatively, the processor may be a conventional processor, a controller, a microcontroller or a state machine. The general-purpose processor or each circuit described above may be configured by a digital circuit or may be configured by an analogue circuit. Further, when a technology of making into an integrated circuit superseding integrated circuits at the present time appears due to advancement of a semiconductor technology, the integrated circuit by this technology is also able to be used.

Claims (16)

What is claimed is:
1. A method for reporting uplink control information (UCI) by a user equipment (UE), the method comprising:
storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported;
when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH,
transmitting, by the UE, the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and
dropping the overlapping portion of the PUSCH.
2. A method for receiving uplink control information (UCI) from a user equipment (UE) by a base station, the method comprising:
acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE;
when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH,
receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and
not receiving the overlapping portion of the PUSCH.
3. A user equipment (UE) configured to report uplink control information (UCI), the UE comprising:
a processor; and
a non-transitory machine-readable memory storing instructions, executable by the processor, for:
storing information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported;
when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH,
transmitting the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and
dropping the overlapping portion of the PUSCH.
4. The UE of claim 3, wherein the instructions further comprise:
determining a PUCCH format and a configuration of the PUCCH based on a signaling from a next generation NodeB (gNB).
5. The UE of claim 4, wherein the PUCCH format is determined from a short PUCCH format and a long PUCCH format.
6. The UE of claim 3, wherein the PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies.
7. The UE of claim 3, wherein the channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
8. The UE of claim 3, wherein the information is either the UE's capability or a base station's configuration.
9. The UE of claim 3, wherein when the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the UE is configured to transmit a non-overlapping portion of the PUSCH.
10. A base station configured to acquire uplink control information (UCI) from a user equipment (UE), the base station comprising:
a processor; and
a non-transitory machine-readable memory storing instructions, executable by the processor, for:
acquiring information on whether a simultaneous physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH) transmission is supported by the UE;
when the simultaneous PUCCH and PUSCH transmission is not supported and in case of a channel collision between a PUCCH and a PUSCH,
receiving the UCI using the PUCCH in an overlapping portion between the PUCCH and the PUSCH, and
not receiving the overlapping portion of the PUSCH.
11. The base station of claim 10, wherein a PUCCH format and a configuration of the PUCCH from the UE are determined based on a signaling from the base station.
12. The base station of claim 11, wherein the PUCCH format is determined from a short PUCCH format and a long PUCCH format.
13. The base station of claim 10, wherein the PUCCH format is determined based on whether the PUCCH and the PUSCH have the same or different waveforms and/or numerologies.
14. The base station of claim 10, wherein the channel collision occurs when there is at least one overlapping symbol between the PUSCH and the PUCCH.
15. The base station of claim 10, wherein the information is either the UE's capability or the base station's configuration.
16. The base station of claim 10, wherein when the simultaneous PUCCH and PUSCH transmission is not supported, and when the channel collision occurs, the base station is configured to receive a non-overlapping portion of the PUSCH.
US15/839,798 2016-12-13 2017-12-12 Base stations, user equipments, and related communication methods Active US10716100B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/US2017/065928 WO2018111948A1 (en) 2016-12-13 2017-12-12 Base stations, user equipments, and related communication methods
US15/839,798 US10716100B2 (en) 2016-12-13 2017-12-12 Base stations, user equipments, and related communication methods

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662433677P 2016-12-13 2016-12-13
US15/839,798 US10716100B2 (en) 2016-12-13 2017-12-12 Base stations, user equipments, and related communication methods

Publications (2)

Publication Number Publication Date
US20180167933A1 true US20180167933A1 (en) 2018-06-14
US10716100B2 US10716100B2 (en) 2020-07-14

Family

ID=62490481

Family Applications (1)

Application Number Title Priority Date Filing Date
US15/839,798 Active US10716100B2 (en) 2016-12-13 2017-12-12 Base stations, user equipments, and related communication methods

Country Status (4)

Country Link
US (1) US10716100B2 (en)
EP (1) EP3556161A4 (en)
CN (1) CN110383912A (en)
WO (1) WO2018111948A1 (en)

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180199366A1 (en) * 2017-01-06 2018-07-12 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US10206232B2 (en) 2016-09-29 2019-02-12 At&T Intellectual Property I, L.P. Initial access and radio resource management for integrated access and backhaul (IAB) wireless networks
CN109417463A (en) * 2018-09-18 2019-03-01 北京小米移动软件有限公司 Determine the method and apparatus for needing the PUCCH transmitted
US20190215747A1 (en) * 2018-01-09 2019-07-11 Htc Corporation Device and Method for Handling New Radio Capabilities
US10355813B2 (en) * 2017-02-14 2019-07-16 At&T Intellectual Property I, L.P. Link adaptation on downlink control channel in a wireless communications system
US20190230659A1 (en) * 2016-08-12 2019-07-25 Telefonaktiebolaget Lm Ericsson (Publ) Short TTI Patterns
US10405305B2 (en) * 2017-03-24 2019-09-03 Qualcomm Incorporated Single slot short PUCCH with support for intra slot frequency hopping
US10425962B2 (en) * 2016-12-14 2019-09-24 Qualcomm Incorporated PUCCH design with flexible symbol configuration
US20190327759A1 (en) * 2017-01-07 2019-10-24 Lg Electronics Inc. Method for terminal transmitting uplink control channel in wireless communication system, and communication device using same
US20200008156A1 (en) * 2018-06-29 2020-01-02 Sharp Laboratories of America (SLA), Inc. Power Control for Enhancement of Physical Uplink Control Channel (PUCCH) Reliability for 5th Generation (5G) New Radio (NR)
CN110661607A (en) * 2018-06-29 2020-01-07 维沃移动通信有限公司 Method and terminal for processing uplink conflict
WO2020034813A1 (en) * 2018-08-13 2020-02-20 电信科学技术研究院有限公司 Uci combined transmission method, terminal, and network device
US10602507B2 (en) 2016-09-29 2020-03-24 At&T Intellectual Property I, L.P. Facilitating uplink communication waveform selection
US20200100241A1 (en) * 2017-04-27 2020-03-26 Ntt Docomo, Inc. User terminal and radio communication method
US10616092B2 (en) 2016-09-29 2020-04-07 At&T Intellectual Property I, L.P. Facilitation of route optimization for a 5G network or other next generation network
CN110972286A (en) * 2018-09-28 2020-04-07 电信科学技术研究院有限公司 Transmission method of uplink control information UCI, user terminal and base station
US10623158B2 (en) 2016-09-29 2020-04-14 At&T Intellectual Property I, L.P. Channel state information framework design for 5G multiple input multiple output transmissions
US10644924B2 (en) 2016-09-29 2020-05-05 At&T Intellectual Property I, L.P. Facilitating a two-stage downlink control channel in a wireless communication system
WO2020092199A1 (en) * 2018-10-29 2020-05-07 Intel Corporation Connectivity enhancement
CN111464259A (en) * 2019-01-18 2020-07-28 上海朗帛通信技术有限公司 Method and device used in user equipment and base station for wireless communication
US10743339B2 (en) 2017-06-16 2020-08-11 Motorola Mobility Llc Method and apparatus for communicating a HARQ-ACK feedback on an uplink control channel
WO2020167065A1 (en) * 2019-02-15 2020-08-20 엘지전자 주식회사 Method, user equipment, and storage medium for transmitting uplink channel, and method and base station for receiving uplink channel
WO2020164347A1 (en) * 2019-02-15 2020-08-20 电信科学技术研究院有限公司 Transmission method and device
WO2020167178A1 (en) * 2019-02-15 2020-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Uplink transmission in radio access network
CN111585728A (en) * 2019-02-15 2020-08-25 电信科学技术研究院有限公司 Transmission method, terminal and network equipment
US10764880B2 (en) 2016-05-13 2020-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Configuration of downlink transmissions
CN111726206A (en) * 2019-03-21 2020-09-29 宏碁股份有限公司 Multiplexing method of uplink control information
WO2020197358A1 (en) * 2019-03-28 2020-10-01 엘지전자 주식회사 Method, user equipment, device, and storage medium for performing uplink transmission, and method and base station for performing uplink reception
US10869300B2 (en) * 2017-01-08 2020-12-15 Lg Electronics Inc. Uplink signal transmission method of terminal in wireless communication system and device for supporting same
WO2020248158A1 (en) * 2019-06-12 2020-12-17 Qualcomm Incorporated Adaptive sounding reference signal port configuration
US10893512B2 (en) * 2017-01-16 2021-01-12 Mediatek Inc. Resource element (RE) allocation for uplink control information (UCI) on physical uplink shared channel (PUSCH)
WO2021034236A1 (en) * 2019-08-16 2021-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Channel multiplexing in urllc
US20210144702A1 (en) * 2018-05-10 2021-05-13 Beijing Xiaomi Mobile Software Co., Ltd. Method for multiplexing transmission of information and apparatus, and information receiving method and apparatus
CN112805932A (en) * 2018-08-09 2021-05-14 株式会社Ntt都科摩 User terminal and wireless communication method
CN113056952A (en) * 2018-09-21 2021-06-29 株式会社Ntt都科摩 User terminal
US20210204276A1 (en) * 2018-09-19 2021-07-01 Huawei Technologies Co., Ltd. Uplink Control Information Sending and Receiving Method and Communications Apparatus
WO2021134619A1 (en) * 2019-12-31 2021-07-08 Oppo广东移动通信有限公司 Method and apparatus for transmitting uplink control information, device, and storage medium
CN113163502A (en) * 2020-01-22 2021-07-23 维沃移动通信有限公司 Communication processing method and related equipment
US11140666B2 (en) * 2018-01-12 2021-10-05 Huawei Technologies Co., Ltd. Uplink control information transmission method and apparatus
US11166262B2 (en) * 2017-01-05 2021-11-02 FG Innovation Company Limited Long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
EP3855663A4 (en) * 2018-10-19 2021-11-17 Samsung Electronics Co., Ltd. Method and device for transmitting and receiving signals in wireless communication system
WO2021229319A1 (en) * 2020-05-13 2021-11-18 Nokia Technologies Oy Apparatus and methods of scheduling request multiplexing
US11206646B2 (en) 2017-04-01 2021-12-21 Lg Electronics Inc. Method and apparatus for transmitting or receiving uplink signal for terminal supporting short TTI in wireless communication system
US11228900B2 (en) 2019-11-01 2022-01-18 Samsung Electronics Co., Ltd Method and apparatus for determining UE capability based on number of processed channels
WO2022025601A1 (en) * 2020-07-27 2022-02-03 Samsung Electronics Co., Ltd. Multiplexing information with different priority values
WO2022030920A1 (en) * 2020-08-03 2022-02-10 Samsung Electronics Co., Ltd. Transmitting method and receiving method for control information, user equipment and base station
US20220103229A1 (en) * 2017-08-10 2022-03-31 Comcast Cable Communications, Llc Priority of Beam Failure Recovery Request and Uplink Channels
WO2022087474A1 (en) * 2020-10-23 2022-04-28 Intel Corporation Intra-user equipment prioritization for handling overlap of uplink control and uplink data channels
US11399388B2 (en) * 2018-01-17 2022-07-26 Lg Electronics Inc. Method and device for transmitting uplink signal in wireless communication system
US11483092B2 (en) * 2019-02-26 2022-10-25 Qualcomm Incorporated Collision handling for physical uplink shared channel (PUSCH) repetition
EP3970434A4 (en) * 2019-05-13 2023-01-25 Telefonaktiebolaget LM Ericsson (publ) Methods, terminal device and network node for uplink transmission
WO2023057219A1 (en) * 2021-10-06 2023-04-13 Nokia Technologies Oy Physical uplink control channel adjustment for parallel uplink transmissions
US11785605B2 (en) 2017-03-23 2023-10-10 Panasonic Intellectual Property Corporation Of America Base station, terminal, and communication method
WO2024002471A1 (en) * 2022-06-29 2024-01-04 Nokia Technologies Oy Dynamic resource usage
US11870724B2 (en) 2017-08-10 2024-01-09 Comcast Cable Communications, Llc Beam failure recovery request transmission
US11903018B2 (en) * 2017-07-19 2024-02-13 Samsung Electronics Co., Ltd Method and apparatus for performing uplink channel transmission in wireless cellular communication system
US11937212B2 (en) 2018-08-13 2024-03-19 Datang Mobile Communications Equipment Co., Ltd. UCI combined transmission method, terminal, and network device

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3639492A4 (en) * 2017-06-15 2020-06-24 Nec Corporation Method and device for cross-numerology scheduling
US10973038B2 (en) 2018-01-19 2021-04-06 Qualcomm Incorporated UCI transmission for overlapping uplink resource assignments with repetition
AU2018408266B2 (en) * 2018-02-09 2023-10-26 Ntt Docomo, Inc. User terminal and radio communication method
EP3567776B1 (en) * 2018-05-10 2021-08-18 Comcast Cable Communications, LLC Prioritization in beam failure recovery procedures
CN116961864A (en) 2018-05-18 2023-10-27 中兴通讯股份有限公司 Channel configuration method, terminal, storage medium and electronic device
CN110719646B (en) * 2018-07-13 2021-04-02 维沃移动通信有限公司 Uplink transmission method and terminal
CN110740521B (en) * 2018-07-18 2022-10-18 大唐移动通信设备有限公司 Uplink transmission method, device, terminal and network side equipment
US11272539B2 (en) 2018-08-09 2022-03-08 Ofinno, Llc Channel access and bandwidth part switching
US11375483B2 (en) 2019-03-15 2022-06-28 FG Innovation Company Limited Method and apparatus for multiplexing UCI
CN111757496B (en) * 2019-03-29 2023-07-11 华为技术有限公司 Communication method and device
CN114303425A (en) * 2019-08-15 2022-04-08 中兴通讯股份有限公司 System and method for transmitting signals
WO2021087805A1 (en) * 2019-11-06 2021-05-14 Oppo广东移动通信有限公司 Method processing for split resources and processing device
CN112929966B (en) * 2019-12-05 2022-08-05 维沃移动通信有限公司 Method and terminal for selecting uplink transmission resources
CN113225811B (en) * 2020-01-21 2023-04-07 维沃移动通信有限公司 Uplink transmission processing method and device and terminal
EP4173418A4 (en) * 2020-06-25 2024-03-20 Qualcomm Inc Uplink control information multiplexing rule for simultaneous uplink control channel and uplink shared channel transmission
CN112203359B (en) * 2020-09-29 2022-06-21 广东云纱供应链管理有限公司 Upstream supply chain information transmission method and system for block chain system
CN114389771A (en) * 2020-10-19 2022-04-22 大唐移动通信设备有限公司 Transmission method and device for uplink channel
CN115175332A (en) * 2021-04-06 2022-10-11 维沃移动通信有限公司 Uplink channel transmission method, device, terminal and network side equipment
CN115209401A (en) * 2021-04-13 2022-10-18 大唐移动通信设备有限公司 Channel processing method, device and storage medium
CN117322108A (en) * 2021-05-27 2023-12-29 株式会社Ntt都科摩 Terminal, wireless communication system, and wireless communication method

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120113827A1 (en) 2010-11-08 2012-05-10 Sharp Laboratories Of America, Inc. Dynamic simultaneous pucch and pusch switching for lte-a
US8797966B2 (en) * 2011-09-23 2014-08-05 Ofinno Technologies, Llc Channel state information transmission
WO2013048056A1 (en) * 2011-09-30 2013-04-04 엘지전자 주식회사 Method and apparatus for transmitting channel state information in wireless communication system
JP2013102398A (en) * 2011-11-09 2013-05-23 Ntt Docomo Inc Radio communication system, user terminal and radio communication method
WO2014058236A1 (en) * 2012-10-10 2014-04-17 엘지전자 주식회사 Method and user device for receiving uplink control information, and method and base station for transmitting uplink control information
US9967079B2 (en) * 2012-10-12 2018-05-08 Google Llc Controlling uplink power for transmission of an uplink channel and an uplink reference signal
CN104956726A (en) * 2013-01-24 2015-09-30 诺基亚技术有限公司 Method and apparatus for cell reselection
US10555286B2 (en) * 2013-07-30 2020-02-04 Qualcomm Incorporated Uplink control information (UCI) transmission with bundling considerations
WO2015020440A1 (en) * 2013-08-06 2015-02-12 Lg Electronics Inc. The method and apparatus for wireless communication
RU2627306C1 (en) * 2013-09-04 2017-08-07 ЭлДжи ЭЛЕКТРОНИКС ИНК. Method and device for transmitting power reserve report in wireless communication system
CN112564875A (en) * 2014-01-28 2021-03-26 索尼公司 Method, base station and user equipment for wireless communication in wireless communication system
WO2016121567A1 (en) * 2015-01-28 2016-08-04 京セラ株式会社 User terminal and base station
US10251132B2 (en) * 2015-07-23 2019-04-02 Acer Incorporated Device and method of handling uplink power control for unlicensed serving cell
US10630433B2 (en) * 2015-12-11 2020-04-21 Lg Electronics Inc. Method for transmitting uplink signal and apparatus therefor
US20170223695A1 (en) * 2016-02-03 2017-08-03 Lg Electronics Inc. Method and apparatus for transmitting an uplink channel in a wireless communication system
WO2017173388A1 (en) * 2016-04-01 2017-10-05 Huawei Technologies Co., Ltd. System and method for srs switching, transmission, and enhancements
JP6850308B2 (en) * 2016-06-15 2021-03-31 コンヴィーダ ワイヤレス, エルエルシー Upload control signaling for new radio
US10405332B2 (en) * 2016-09-06 2019-09-03 Samsung Electronics Co., Ltd. Coexistence of different radio access technologies or services on a same carrier
EP3313129B1 (en) * 2016-10-21 2022-03-09 ASUSTek Computer Inc. Method and apparatus for power headroom report for beam operation in a wireless communication system
US10506596B2 (en) * 2016-10-28 2019-12-10 Qualcomm Incorporated Coexistence of interleaved and contiguous uplink transmissions

Cited By (89)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10764880B2 (en) 2016-05-13 2020-09-01 Telefonaktiebolaget Lm Ericsson (Publ) Configuration of downlink transmissions
US11140678B2 (en) 2016-08-12 2021-10-05 Telefonaktiebolaget Lm Ericsson (Publ) Short TTI patterns
US20190230659A1 (en) * 2016-08-12 2019-07-25 Telefonaktiebolaget Lm Ericsson (Publ) Short TTI Patterns
US10575302B2 (en) * 2016-08-12 2020-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Short TTI patterns
US11729752B2 (en) 2016-08-12 2023-08-15 Telefonaktiebolaget Lm Ericsson (Publ) Short TTI patterns
US10644924B2 (en) 2016-09-29 2020-05-05 At&T Intellectual Property I, L.P. Facilitating a two-stage downlink control channel in a wireless communication system
US11129216B2 (en) 2016-09-29 2021-09-21 At&T Intellectual Property I, L.P. Initial access and radio resource management for integrated access and backhaul (IAB) wireless networks
US11252716B2 (en) 2016-09-29 2022-02-15 At&T Intellectual Property I, L.P. Facilitating uplink communication waveform selection
US11672032B2 (en) 2016-09-29 2023-06-06 At&T Intettectual Property I, L.P. Initial access and radio resource management for integrated access and backhaul (IAB) wireless networks
US10687375B2 (en) 2016-09-29 2020-06-16 At&T Intellectual Property I, L.P. Initial access and radio resource management for integrated access and backhaul (IAB) wireless networks
US10206232B2 (en) 2016-09-29 2019-02-12 At&T Intellectual Property I, L.P. Initial access and radio resource management for integrated access and backhaul (IAB) wireless networks
US10623158B2 (en) 2016-09-29 2020-04-14 At&T Intellectual Property I, L.P. Channel state information framework design for 5G multiple input multiple output transmissions
US10602507B2 (en) 2016-09-29 2020-03-24 At&T Intellectual Property I, L.P. Facilitating uplink communication waveform selection
US11431543B2 (en) 2016-09-29 2022-08-30 At&T Intellectual Property I, L.P. Facilitating a two-stage downlink control channel in a wireless communication system
US10616092B2 (en) 2016-09-29 2020-04-07 At&T Intellectual Property I, L.P. Facilitation of route optimization for a 5G network or other next generation network
US10425962B2 (en) * 2016-12-14 2019-09-24 Qualcomm Incorporated PUCCH design with flexible symbol configuration
US11166262B2 (en) * 2017-01-05 2021-11-02 FG Innovation Company Limited Long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US11558890B2 (en) * 2017-01-06 2023-01-17 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US10616914B2 (en) * 2017-01-06 2020-04-07 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US20180199366A1 (en) * 2017-01-06 2018-07-12 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US11902997B2 (en) * 2017-01-06 2024-02-13 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US20200205190A1 (en) * 2017-01-06 2020-06-25 Qualcomm Incorporated Unicast data transmission on a downlink common burst of a slot using mini-slots
US10880918B2 (en) 2017-01-07 2020-12-29 Lg Electronics Inc. Method for terminal transmitting uplink control channel in wireless communication system, and communication device using same
US11284426B2 (en) 2017-01-07 2022-03-22 Lg Electronics Inc. Method for terminal transmitting uplink control channel in wireless communication system, and communication device using same
US11109404B2 (en) * 2017-01-07 2021-08-31 Lg Electronics Inc. Method for terminal transmitting uplink control channel in wireless communication system, and communication device using same
US20190327759A1 (en) * 2017-01-07 2019-10-24 Lg Electronics Inc. Method for terminal transmitting uplink control channel in wireless communication system, and communication device using same
US10869300B2 (en) * 2017-01-08 2020-12-15 Lg Electronics Inc. Uplink signal transmission method of terminal in wireless communication system and device for supporting same
US10893512B2 (en) * 2017-01-16 2021-01-12 Mediatek Inc. Resource element (RE) allocation for uplink control information (UCI) on physical uplink shared channel (PUSCH)
US10355813B2 (en) * 2017-02-14 2019-07-16 At&T Intellectual Property I, L.P. Link adaptation on downlink control channel in a wireless communications system
US11785605B2 (en) 2017-03-23 2023-10-10 Panasonic Intellectual Property Corporation Of America Base station, terminal, and communication method
US10405305B2 (en) * 2017-03-24 2019-09-03 Qualcomm Incorporated Single slot short PUCCH with support for intra slot frequency hopping
US11206646B2 (en) 2017-04-01 2021-12-21 Lg Electronics Inc. Method and apparatus for transmitting or receiving uplink signal for terminal supporting short TTI in wireless communication system
US20200100241A1 (en) * 2017-04-27 2020-03-26 Ntt Docomo, Inc. User terminal and radio communication method
US11696287B2 (en) * 2017-04-27 2023-07-04 Ntt Docomo, Inc. User terminal and radio communication method
US10750529B2 (en) * 2017-06-16 2020-08-18 Motorola Mobility Llc Method and apparatus for communicating over a long physical uplink channel resource
US10743339B2 (en) 2017-06-16 2020-08-11 Motorola Mobility Llc Method and apparatus for communicating a HARQ-ACK feedback on an uplink control channel
US11903018B2 (en) * 2017-07-19 2024-02-13 Samsung Electronics Co., Ltd Method and apparatus for performing uplink channel transmission in wireless cellular communication system
US11870724B2 (en) 2017-08-10 2024-01-09 Comcast Cable Communications, Llc Beam failure recovery request transmission
US20220103229A1 (en) * 2017-08-10 2022-03-31 Comcast Cable Communications, Llc Priority of Beam Failure Recovery Request and Uplink Channels
US11252628B2 (en) * 2018-01-09 2022-02-15 Htc Corporation Device and method for handling new radio capabilities
US20190215747A1 (en) * 2018-01-09 2019-07-11 Htc Corporation Device and Method for Handling New Radio Capabilities
US11140666B2 (en) * 2018-01-12 2021-10-05 Huawei Technologies Co., Ltd. Uplink control information transmission method and apparatus
US11399388B2 (en) * 2018-01-17 2022-07-26 Lg Electronics Inc. Method and device for transmitting uplink signal in wireless communication system
US11683807B2 (en) * 2018-01-17 2023-06-20 Lg Electronics Inc. Method and device for transmitting uplink signal in wireless communication system
US20220369349A1 (en) * 2018-01-17 2022-11-17 Lg Electronics Inc. Method and device for transmitting uplink signal in wireless communication system
US20210144702A1 (en) * 2018-05-10 2021-05-13 Beijing Xiaomi Mobile Software Co., Ltd. Method for multiplexing transmission of information and apparatus, and information receiving method and apparatus
US20200008156A1 (en) * 2018-06-29 2020-01-02 Sharp Laboratories of America (SLA), Inc. Power Control for Enhancement of Physical Uplink Control Channel (PUCCH) Reliability for 5th Generation (5G) New Radio (NR)
CN110661607A (en) * 2018-06-29 2020-01-07 维沃移动通信有限公司 Method and terminal for processing uplink conflict
CN112805932A (en) * 2018-08-09 2021-05-14 株式会社Ntt都科摩 User terminal and wireless communication method
WO2020034813A1 (en) * 2018-08-13 2020-02-20 电信科学技术研究院有限公司 Uci combined transmission method, terminal, and network device
US11937212B2 (en) 2018-08-13 2024-03-19 Datang Mobile Communications Equipment Co., Ltd. UCI combined transmission method, terminal, and network device
TWI715140B (en) * 2018-08-13 2021-01-01 大陸商電信科學技術研究院有限公司 Uplink control information combined transmission method, terminal, network side equipment and computer readable storage medium
CN110831232A (en) * 2018-08-13 2020-02-21 电信科学技术研究院有限公司 UCI combined transmission method, terminal and network side equipment
CN109417463A (en) * 2018-09-18 2019-03-01 北京小米移动软件有限公司 Determine the method and apparatus for needing the PUCCH transmitted
US20210204276A1 (en) * 2018-09-19 2021-07-01 Huawei Technologies Co., Ltd. Uplink Control Information Sending and Receiving Method and Communications Apparatus
CN113056952A (en) * 2018-09-21 2021-06-29 株式会社Ntt都科摩 User terminal
CN110972286A (en) * 2018-09-28 2020-04-07 电信科学技术研究院有限公司 Transmission method of uplink control information UCI, user terminal and base station
EP3855663A4 (en) * 2018-10-19 2021-11-17 Samsung Electronics Co., Ltd. Method and device for transmitting and receiving signals in wireless communication system
US20210385809A1 (en) * 2018-10-19 2021-12-09 Samsung Electronics Co., Ltd. Method and device for transmitting and receiving signals in wireless communication system
KR102650125B1 (en) * 2018-10-29 2024-03-21 애플 인크. Improved connectivity
WO2020092199A1 (en) * 2018-10-29 2020-05-07 Intel Corporation Connectivity enhancement
CN112970277A (en) * 2018-10-29 2021-06-15 苹果公司 Connectivity enhancement
CN111464259A (en) * 2019-01-18 2020-07-28 上海朗帛通信技术有限公司 Method and device used in user equipment and base station for wireless communication
WO2020167065A1 (en) * 2019-02-15 2020-08-20 엘지전자 주식회사 Method, user equipment, and storage medium for transmitting uplink channel, and method and base station for receiving uplink channel
WO2020164347A1 (en) * 2019-02-15 2020-08-20 电信科学技术研究院有限公司 Transmission method and device
WO2020167178A1 (en) * 2019-02-15 2020-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Uplink transmission in radio access network
CN111585728A (en) * 2019-02-15 2020-08-25 电信科学技术研究院有限公司 Transmission method, terminal and network equipment
US11483092B2 (en) * 2019-02-26 2022-10-25 Qualcomm Incorporated Collision handling for physical uplink shared channel (PUSCH) repetition
TWI790425B (en) * 2019-03-21 2023-01-21 宏碁股份有限公司 Multiplexing method of uplink control information (uci) for ultra-reliable and low latency communications (urllc)
EP3723317A3 (en) * 2019-03-21 2020-12-16 Acer Incorporated Multiplexing method of uplink control information (uci) for ultra-reliable and low latency communications (urllc)
CN111726206A (en) * 2019-03-21 2020-09-29 宏碁股份有限公司 Multiplexing method of uplink control information
US11758540B2 (en) 2019-03-21 2023-09-12 Acer Incorporated Multiplexing method of uplink control information (UCI) for ultra-reliable and low latency communications (URLLC)
WO2020197358A1 (en) * 2019-03-28 2020-10-01 엘지전자 주식회사 Method, user equipment, device, and storage medium for performing uplink transmission, and method and base station for performing uplink reception
EP3970434A4 (en) * 2019-05-13 2023-01-25 Telefonaktiebolaget LM Ericsson (publ) Methods, terminal device and network node for uplink transmission
WO2020248158A1 (en) * 2019-06-12 2020-12-17 Qualcomm Incorporated Adaptive sounding reference signal port configuration
WO2020248821A1 (en) * 2019-06-12 2020-12-17 Qualcomm Incorporated Adaptive sounding reference signal port configuration
WO2021034236A1 (en) * 2019-08-16 2021-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Channel multiplexing in urllc
CN114586302A (en) * 2019-08-16 2022-06-03 瑞典爱立信有限公司 Channel multiplexing in URLLC
US11589215B2 (en) 2019-11-01 2023-02-21 Samsung Electronics Co., Ltd Method and apparatus for determining UE capability based on number of processed channels
US11228900B2 (en) 2019-11-01 2022-01-18 Samsung Electronics Co., Ltd Method and apparatus for determining UE capability based on number of processed channels
WO2021134619A1 (en) * 2019-12-31 2021-07-08 Oppo广东移动通信有限公司 Method and apparatus for transmitting uplink control information, device, and storage medium
CN113163502A (en) * 2020-01-22 2021-07-23 维沃移动通信有限公司 Communication processing method and related equipment
WO2021229319A1 (en) * 2020-05-13 2021-11-18 Nokia Technologies Oy Apparatus and methods of scheduling request multiplexing
US11811538B2 (en) 2020-07-27 2023-11-07 Samsung Electronics Co., Ltd. Multiplexing information with different priority values
WO2022025601A1 (en) * 2020-07-27 2022-02-03 Samsung Electronics Co., Ltd. Multiplexing information with different priority values
WO2022030920A1 (en) * 2020-08-03 2022-02-10 Samsung Electronics Co., Ltd. Transmitting method and receiving method for control information, user equipment and base station
WO2022087474A1 (en) * 2020-10-23 2022-04-28 Intel Corporation Intra-user equipment prioritization for handling overlap of uplink control and uplink data channels
WO2023057219A1 (en) * 2021-10-06 2023-04-13 Nokia Technologies Oy Physical uplink control channel adjustment for parallel uplink transmissions
WO2024002471A1 (en) * 2022-06-29 2024-01-04 Nokia Technologies Oy Dynamic resource usage

Also Published As

Publication number Publication date
EP3556161A1 (en) 2019-10-23
CN110383912A (en) 2019-10-25
US10716100B2 (en) 2020-07-14
EP3556161A4 (en) 2020-06-24
WO2018111948A1 (en) 2018-06-21

Similar Documents

Publication Publication Date Title
US10716100B2 (en) Base stations, user equipments, and related communication methods
US10841904B2 (en) Short physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US11844077B2 (en) Slot structure of long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US10455560B2 (en) Short physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US10601566B2 (en) Multiple slot long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US11166262B2 (en) Long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
US10609689B2 (en) Long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
AU2018216827B2 (en) Short physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
EP3566371B1 (en) Short physical uplink control channel (pucch) design for 5th generation (5g) new radio (nr)
US10616888B2 (en) Multiple slot long physical uplink control channel (PUCCH) design for 5th generation (5G) new radio (NR)
WO2018144471A1 (en) LONG PHYSICAL UPLINK CONTROL CHANNEL (PUCCH) DESIGN FOR 5th GENERATION (5G) NEW RADIO (NR)
EP3566370B1 (en) Long physical uplink control channel (pucch) design for 5th generation (5g) new radio (nr)
WO2019099565A1 (en) MULTIPLE SLOT LONG PHYSICAL UPLINK CONTROL CHANNEL (PUCCH) DESIGN FOR 5th GENERATION (5G) NEW RADIO (NR)
RU2774066C2 (en) Structure of interval of long physical uplink control channel (pucch) for new radio network (nr) of 5th generation (5g)

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: SHARP LABORATORIES OF AMERICA, INC., WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YIN, ZHANPING;NOGAMI, TOSHIZO;SIGNING DATES FROM 20171215 TO 20180115;REEL/FRAME:045035/0531

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: FINAL REJECTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: RESPONSE AFTER FINAL ACTION FORWARDED TO EXAMINER

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

STCF Information on status: patent grant

Free format text: PATENTED CASE

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: FG INNOVATION COMPANY LIMITED, HONG KONG

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHARP LABORATORIES OF AMERICA, INC.;REEL/FRAME:053258/0189

Effective date: 20200410

Owner name: SHARP KABUSHIKI KAISHA, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHARP LABORATORIES OF AMERICA, INC.;REEL/FRAME:053258/0189

Effective date: 20200410

AS Assignment

Owner name: SHARP CORPORATION, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHARP KABUSHIKI KAISHA;FG INNOVATION COMPANY LIMITED;REEL/FRAME:062389/0715

Effective date: 20220801

Owner name: SHARP KABUSHIKI KAISHA, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHARP KABUSHIKI KAISHA;FG INNOVATION COMPANY LIMITED;REEL/FRAME:062389/0715

Effective date: 20220801

AS Assignment

Owner name: SHARP KABUSHIKI KAISHA, JAPAN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SHARP KABUSHIKI KAISHA;SHARP CORPORATION;REEL/FRAME:063815/0589

Effective date: 20230404

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4