Method and apparatus for recovering uplink control information in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. This method performed by a user equipment (UE) in a wireless communication system comprises the steps of: receiving, from a base station, configuration information related to uplink control information (UCI) retransmission; generating UCI; transmitting, to the base station, a first physical uplink shared channel (PUSCH) including at least a part of the UCI; receiving, from the base station, downlink control information (DCI) indicating the UCI retransmission; identifying, on the basis of the DCI, a UCI part requiring retransmission in the UCI; and transmitting, to the base station, a second PUSCH including the UCI part requiring retransmission.

Description

Method and apparatus for recovering uplink control information in a wireless communication system

[0001] The present disclosure relates to the operation of a terminal and a base station in a wireless communication system. Specifically, the present disclosure relates to a method for recovering uplink control information in a wireless communication system and an apparatus capable of performing the same.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz band (e.g., the 3 terahertz (3 THz) band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC), technologies included beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands; support for various numerologies (such as operating multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources; initial access techniques to support multi-beam transmission and broadband; the definition and operation of Band-Width Parts (BWP); Low Density Parity Check (LDPC) codes for high-volume data transmission; new channel coding methods such as Polar Codes for the reliable transmission of control information; and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) to support new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes to expand network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) to incorporate Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] In conventional wireless communication systems, a terminal can transmit Uplink Control Information (UCI) by multiplexing it through a single Physical Uplink Shared Channel (PUSCH). However, depending on the channel environment between the terminal and the base station, the Modulation and Coding Scheme (MCS) of the PUSCH, and the beta offset value of the UCI, a problem may arise where the base station fails to properly receive the UCI included in the PUSCH. This can cause the base station to be unable to acquire critical information, such as HARQ-ACK information or Channel State Information (CSI), which must be transmitted from the terminal to the base station, thereby leading to a degradation of the overall system performance.

[0009] In addition, when a terminal multiplexes a UCI to a PUSCH, certain types of UCIs (e.g., CSI part 2) may be partially or entirely dropped due to constraints such as the resource size, MCS, and UCI length allocated to the PUSCH. In particular, since the length of CSI part 2 can vary depending on the terminal's channel measurement results (e.g., channel rank), there may be a problem in that it is difficult for the base station to accurately predict this in advance and schedule the PUSCH. Consequently, an efficient method is required for the terminal to retransmit the UCI so that the base station can receive the UCI in its entirety.

[0010] The present disclosure proposes various embodiments for solving the aforementioned problems. More specifically, a method for transmitting a UCI through a single PUSCH, a method for transmitting a UCI through multiple PUSCHs, and a method for retransmitting the UCI to a base station when a UCI drop occurs are disclosed.

[0011] According to one embodiment of the present disclosure, a method is provided to be performed by user equipment (UE) of a wireless communication system. The method comprises: receiving configuration information related to the retransmission of uplink control information (UCI) from a base station; generating a UCI; transmitting a first physical uplink shared channel (PUSCH) containing at least a portion of the UCI to the base station; receiving downlink control information (DCI) from the base station indicating the retransmission of the UCI; identifying a portion of the UCI requiring retransmission based on the DCI; and transmitting a second PUSCH containing the portion of the UCI requiring retransmission to the base station.

[0012] According to one embodiment of the present disclosure, a method is provided to be performed by a base station of a wireless communication system. The method comprises the steps of: transmitting configuration information related to UCI retransmission to a UE; receiving from the UE a first PUSCH containing at least a portion of a UCI generated by the UE; transmitting to the UE a DCI indicating the UCI retransmission; and receiving from the UE a second PUSCH containing a portion of the UCI that requires retransmission.

[0013] According to one embodiment of the present disclosure, a UE of a wireless communication system is provided. The UE comprises at least one transceiver; at least one processor connected to communicate with the at least one transceiver; and a memory connected to communicate with the at least one processor and storing instructions that are executable individually or in any combination of the at least one processor. The instructions cause the UE to receive configuration information related to UCI retransmission from a base station, generate a UCI, and transmit a first PUSCH containing at least a portion of the UCI to the base station, receive a DCI from the base station directing the UCI retransmission, identify a portion of the UCI requiring retransmission based on the DCI, and transmit a second PUSCH containing the portion of the UCI requiring retransmission to the base station.

[0014] According to one embodiment of the present disclosure, a base station of a wireless communication system is provided. The base station comprises: at least one transceiver; at least one processor connected to communicate with the at least one transceiver; and a memory connected to communicate with the at least one processor and storing instructions that are executable individually or in any combination of the at least one processor. The instructions cause the base station to transmit configuration information related to UCI retransmission to a UE, receive from the UE a first PUSCH containing at least a portion of a UCI generated by the UE, transmit a DCI instructing the UCI retransmission to the UE, and receive from the UE a second PUSCH containing a portion of the UCI that requires retransmission.

[0015] According to various embodiments of the present disclosure, problems can be resolved where a base station fails to receive a UCI when a terminal transmits a UCI by multiplexing it over a PUSCH, or where a specific UCI (e.g., CSI part 2) is dropped and the base station fails to acquire it. More specifically, depending on the method of transmitting UCI through one PUSCH or multiple PUSCHs, it is possible to respond more flexibly to variations in the channel environment and the terminal's CSI measurement results. Furthermore, by efficiently retransmitting the UCI, the reliability of the wireless link is improved, and scheduling efficiency at the base station is increased, as well as the quality of service (QoS) and system throughput of the entire cell can be improved.

[0016] FIG. 1 is a diagram illustrating the basic structure of the time-frequency domain in a wireless communication system according to one embodiment of the present disclosure.

[0017] FIG. 2 is a drawing illustrating a frame, subframe, and slot structure in a wireless communication system according to one embodiment of the present disclosure.

[0018] FIG. 3 is a drawing illustrating an example of a bandwidth portion setting in a wireless communication system according to one embodiment of the present disclosure.

[0019] FIG. 4 is a diagram illustrating an example of setting a control area of ​​a downlink control channel in a wireless communication system according to one embodiment of the present disclosure.

[0020] FIG. 5 is a diagram illustrating the structure of a downlink control channel in a wireless communication system according to one embodiment of the present disclosure.

[0021] FIG. 6 is a diagram illustrating a method for transmitting and receiving data in a wireless communication system according to one embodiment of the present disclosure, in consideration of a downlink data channel and a rate matching resource, between a base station and a terminal.

[0022] FIG. 7 is a diagram illustrating an example of frequency axis resource allocation of a PDSCH in a wireless communication system according to one embodiment of the present disclosure.

[0023] FIG. 8 is a diagram illustrating an example of time axis resource allocation of PDSCH in a wireless communication system according to one embodiment of the present disclosure.

[0024] FIG. 9 is a diagram illustrating an example of time-axis resource allocation according to the subcarrier interval of a data channel and a control channel in a wireless communication system according to one embodiment of the present disclosure.

[0025] FIG. 10 is a diagram illustrating the wireless protocol structure of a base station and a terminal in a single cell, carrier aggregation, dual connectivity situation in a wireless communication system according to one embodiment of the present disclosure.

[0026] FIG. 11 is a flowchart illustrating a method of transmitting UL-SCH and UCI through PUSCH in a wireless communication system according to one embodiment of the present disclosure.

[0027] FIG. 12 is a diagram illustrating an example of UCI-to-RE mapping when a UCI is multiplexed on a PUSCH in a wireless communication system according to one embodiment of the present disclosure.

[0028] FIG. 13 is a diagram illustrating a scenario in which a PUCCH including a UCI overlaps with a plurality of PUSCHs in a wireless communication system according to one embodiment of the present disclosure.

[0029] FIG. 14 is a diagram illustrating a UCI multiplexed state in a plurality of PUSCHs according to one embodiment of the present disclosure.

[0030] FIG. 15 is a diagram illustrating a method of multiplexing by dividing UCI as one method of the present disclosure.

[0031] FIG. 16 is a drawing illustrating a method of iteratively multiplexing UCI as one method of the present disclosure.

[0032] FIG. 17 is a drawing illustrating a method of multiplexing by UCI type as one method of the present disclosure.

[0033] FIG. 18 is a drawing illustrating a method of multiplexing a dropped portion of UCI into a second PUSCH as one method of the present disclosure.

[0034] FIG. 19 is a flowchart illustrating a procedure for a terminal to multiplex UCIs to a plurality of PUSCHs according to one embodiment of the present disclosure.

[0035] FIG. 20 is a diagram illustrating a method in which a UCI is retransmitted according to one embodiment of the present disclosure.

[0036] FIG. 21 is a flowchart illustrating a procedure for a terminal to retransmit a UCI according to one embodiment of the present disclosure.

[0037] FIG. 22 is a drawing illustrating the structure of a terminal in a wireless communication system according to one embodiment of the present disclosure.

[0038] FIG. 23 is a drawing illustrating the structure of a base station in a wireless communication system according to one embodiment of the present disclosure.

[0039] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.

[0040] In describing the embodiments, technical details that are well known in the art to which this disclosure belongs and are not directly related to this disclosure are omitted. This is intended to convey the essence of this disclosure more clearly without obscuring it by omitting unnecessary explanations.

[0041] For the same reason, some components in the attached drawings have been exaggerated, omitted, or schematically depicted. Additionally, the dimensions of each component do not entirely reflect their actual dimensions. Identical or corresponding components in each drawing have been assigned the same reference numbers.

[0042] The advantages and features of the present disclosure, and the methods for achieving them, will become clear by referring to the embodiments described below in detail together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure is complete and to fully inform those skilled in the art of the scope of the disclosure, and the present disclosure is defined only by the scope of the claims. Throughout the specification, the same reference numerals refer to the same components. Furthermore, in describing the present disclosure, if it is determined that a detailed description of a related function or configuration might unnecessarily obscure the essence of the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined considering their functions in the present disclosure, and these may vary depending on the intentions or conventions of the user or operator. Therefore, their definitions should be based on the content throughout the specification.

[0043] Hereinafter, the base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. The terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. In this disclosure, the Downlink (DL) refers to the wireless transmission path of a signal transmitted by the base station to the terminal, and the Uplink (UL) refers to the wireless transmission path of a signal transmitted by the terminal to the base station. Furthermore, while LTE (Long-Term Evolution) or LTE-A (LTE-advanced) systems may be described as examples below, embodiments of this disclosure may also be applied to other communication systems having similar technical backgrounds or channel types. For example, 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A may be included, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. Furthermore, the present disclosure may be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure, at the discretion of a person with skilled technical knowledge.

[0044] At this point, it will be understood that each block of the process flow diagrams and combinations of the flow diagrams can be executed by computer program instructions. Since these computer program instructions can be loaded into the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, the instructions executed through the processor of the computer or other programmable data processing equipment create means to perform the functions described in the flow diagram block(s). Since these computer program instructions can also be stored in computer-available or computer-readable memory that can be directed toward the computer or other programmable data processing equipment to implement the function in a specific way, the instructions stored in computer-available or computer-readable memory can also produce a manufactured item containing instruction means to perform the function described in the flow diagram block(s). Since computer program instructions can be loaded onto a computer or other programmable data processing equipment, instructions that perform a series of operation steps on the computer or other programmable data processing equipment to create a process executed by the computer can also provide steps for executing the functions described in the flowchart block(s).

[0045] Additionally, each block may represent a module, segment, or part of code containing one or more executable instructions for executing a specific logical function(s). It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may occur out of order. For example, two blocks described in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order according to their corresponding functions.

[0046] In this embodiment, the term "part" refers to a software or hardware component such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), and the "part" performs certain roles. However, the meaning of "part" is not limited to software or hardware. The "part" may be configured to reside in an addressable storage medium or configured to run one or more processors. Thus, as an example, the "part" includes components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts." In addition, the components and 'parts' may be implemented to utilize one or more CPUs (central processing units) within the device or secure multimedia card. Also, in the embodiments, the 'parts' may include one or more processors.

[0047] Wireless communication systems are evolving from providing early voice-oriented services to broadband wireless communication systems that provide high-speed, high-quality packet data services, such as communication standards like 3GPP’s HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution or E-UTRA (Evolved Universal Terrestrial Radio Access)), LTE-Advanced (LTE-A), LTE-Pro, 3GPP2’s HRPD (High Rate Packet Data), UMB (Ultra Mobile Broadband), and IEEE’s 802.16e.

[0048] As a representative example of the above-mentioned broadband wireless communication system, the LTE system employs the Orthogonal Frequency Division Multiplexing (OFDM) method for the downlink (DL) and the Single Carrier Frequency Division Multiple Access (SC-FDMA) method for the uplink (UL). The uplink refers to a wireless link through which a terminal (User Equipment (UE) or Mobile Station (MS)) transmits data or control signals to a base station (eNode B, or base station (BS)), and the downlink refers to a wireless link through which a base station transmits data or control signals to a terminal. The above-mentioned multiple access method can distinguish the data or control information of each user by allocating and operating time-frequency resources to be sent for each user so that they do not overlap, that is, so that orthogonality is established.

[0049] As a future communication system following LTE, that is, a 5G communication system, it must be able to freely reflect the diverse requirements of users and service providers, and therefore, services that satisfy various requirements simultaneously must be supported. Services being considered for the 5G communication system include enhanced Mobile Broadband (eMBB), massive Machine Type Communication (mMTC), and Ultra Reliability Low Latency Communication (URLLC).

[0050] eMBB aims to provide data transmission speeds that are superior to those supported by existing LTE, LTE-A, or LTE-Pro. For example, in a 5G communication system, eMBB must be able to provide a peak data rate of 20 Gbps in the downlink and 10 Gbps in the uplink from the perspective of a single base station. Furthermore, while providing these peak data rates, the 5G communication system must also provide an increased user-perceived data rate. To satisfy these requirements, it necessitates improvements in various transmission and reception technologies, including enhanced Multi-Input Multi-Output (MIMO) transmission technology. Additionally, while LTE transmits signals using a maximum bandwidth of 20 MHz in the 2 GHz band, the 5G communication system can meet the data transmission speeds required by using a frequency bandwidth wider than 20 MHz in frequency bands of 3–6 GHz or above 6 GHz.

[0051] Simultaneously, mMTC is being considered to support application services such as the Internet of Things (IoT) in 5G communication systems. To efficiently provide IoT, mMTC requires support for a large number of terminal connections within a cell, improved terminal coverage, enhanced battery life, and reduced terminal costs. Since IoT devices are attached to various sensors and equipment to provide communication functions, the system must be able to support a large number of terminals within a cell (e.g., 1,000,000 terminals / km²). Furthermore, due to the nature of the service, terminals supporting mMTC are likely to be located in dead zones not covered by cells, such as building basements; therefore, they may require wider coverage compared to other services provided by 5G communication systems. Terminals supporting mMTC must consist of low-cost devices, and since it is difficult to frequently replace terminal batteries, a very long battery life of 10 to 15 years may be required.

[0052] Finally, URLLC is a mission-critical cellular-based wireless communication service. For example, consider services used for remote control of robots or machinery, industrial automation, unmanned aerial vehicles, remote health care, and emergency alerts. Therefore, the communication provided by URLLC must offer very low latency and very high reliability. For instance, services supporting URLLC must satisfy an air interface latency of less than 0.5 milliseconds, and simultaneously 10 -5The following packet error rate requirements apply. Therefore, for services supporting URLLC, 5G systems must provide a Transmit Time Interval (TTI) smaller than other services, and at the same time, design considerations may be required to allocate a wide resource in the frequency band to ensure the reliability of the communication link.

[0053] The three 5G services, namely eMBB, URLLC, and mMTC, can be multiplexed and transmitted within a single system. In this case, different transmission and reception techniques and parameters may be used between the services to satisfy the different requirements of each service. Of course, 5G is not limited to the three services mentioned above.

[0054] [NR Time-Frequency Resources]

[0055] The frame structure of the 5G system will be explained in more detail below with reference to the drawings.

[0056] FIG. 1 is a diagram illustrating the basic structure of the time-frequency domain in a wireless communication system according to one embodiment of the present disclosure.

[0057] The horizontal axis of FIG. 1 represents the time domain, and the vertical axis represents the frequency domain. In the time and frequency domains, the basic unit of a resource is a resource element (RE, 101), which can be defined as one OFDM (Orthogonal Frequency Division Multiplexing) symbol (102) on the time axis and one subcarrier (103) on the frequency axis. In the frequency domain (For example, 12) consecutive REs can form a single resource block (Resource Block, RB, 104). In the time axis, a single subframe (110) may contain multiple OFDM symbols (102). For example, the length of one subframe may be 1 ms.

[0058] FIG. 2 is a drawing illustrating a frame, subframe, and slot structure in a wireless communication system according to one embodiment of the present disclosure.

[0059] FIG. 2 illustrates an example of a frame (200), subframe (201), and slot (202) structure. One frame (200) can be defined as 10ms. One subframe (201) can be defined as 1ms, and thus one frame (200) can be composed of a total of 10 subframes (201). One slot (202, 203) can be defined as 14 OFDM symbols (i.e., the number of symbols per slot ( )=14). A subframe (201) may be composed of one or more slots (202, 203), and the number of slots (202, 203) per subframe (201) may vary depending on the setting value μ (204, 205) for the subcarrier spacing. In one example of FIG. 2, cases where μ=0 (204) and μ=1 (205) are shown as the setting value for the subcarrier spacing. When μ=0 (204), the subframe (201) may be composed of one slot (202), and when μ=1 (205), the subframe (201) may be composed of two slots (203). That is, the number of slots per subframe ( ) may vary, and accordingly, the number of slots per frame ( ) may vary. Depending on each subcarrier interval setting μ and It can be defined by Table 1 below.

[0060] μ 0141011142022144043148084141601651432032

[0061] [Bandwidth Section (BWP)]

[0062] Next, the Bandwidth Part (BWP) setting in the 5G communication system will be explained in detail with reference to the drawing.

[0063] FIG. 3 is a drawing illustrating an example of a bandwidth portion setting in a wireless communication system according to one embodiment of the present disclosure.

[0064] FIG. 3 shows an example in which the terminal bandwidth (UE bandwidth) (300) is configured into two bandwidth portions, namely bandwidth portion #1 (BWP#1) (301) and bandwidth portion #2 (BWP#2) (302). The base station may configure one or more bandwidth portions for the terminal and may configure information such as that shown in Table 2 below for each bandwidth portion.

[0065] BWP ::= SEQUENCE {bwp-Id BWP-Id,(bandwidth identifier)locationAndBandwidth INTEGER (1..65536),(bandwidth location)subcarrierSpacing ENUMERATED {n0, n1, n2, n3, n4, n5},(subcarrier spacing)cyclicPrefix ENUMERATED { extended}(cyclic prefix)}

[0066] Of course, the above examples are not limited, and various parameters related to bandwidth portions may be configured for the terminal in addition to the above configuration information. The above information may be transmitted by the base station to the terminal via upper-layer signaling, for example, Radio Resource Control (RRC) signaling. At least one of the configured bandwidth portions may be activated. Whether a configured bandwidth portion is activated may be transmitted semi-statically from the base station to the terminal via RRC signaling or dynamically via Downlink Control Information (DCI).

[0067] According to some embodiments, prior to the Radio Resource Control (RRC) connection, the terminal may receive an Initial Bandwidth Part (Initial BWP) for initial connection from the base station via a Master Information Block (MIB). More specifically, during the initial connection phase, the terminal may receive configuration information for a Control Resource Set (CORESET) and a Search Space via the MIB, through which a PDCCH can be transmitted to receive system information required for initial connection (Remaining System Information; which may correspond to RMSI or System Information Block 1; SIB1). The Control Resource Set and Search Space configured via the MIB may each be considered as Identity (ID) 0. The base station may notify the terminal via the MIB of configuration information, such as frequency allocation information, time allocation information, and numerology, for Control Resource Set #0. Additionally, the base station may notify the terminal via the MIB of configuration information regarding the monitoring period and occasion for Control Resource Set #0, i.e., configuration information for Search Space #0. The terminal may consider the frequency region set as control region #0 obtained from the MIB as the initial bandwidth portion for initial access. In this case, the identifier (ID) of the initial bandwidth portion may be considered as 0.

[0068] The settings for the bandwidth portion supported by the above 5G can be used for various purposes.

[0069] According to some embodiments, if the bandwidth supported by the terminal is smaller than the system bandwidth, this can be supported through the bandwidth portion setting. For example, by setting the frequency position of the bandwidth portion (setting information 2) to the terminal, the terminal can transmit and receive data at a specific frequency position within the system bandwidth.

[0070] In addition, according to some embodiments, a base station may set multiple bandwidth portions for a terminal for the purpose of supporting different numerologies. For example, to support data transmission and reception using both a 15 kHz subcarrier interval and a 30 kHz subcarrier interval for a terminal, two bandwidth portions may be set to subcarrier intervals of 15 kHz and 30 kHz, respectively. Different bandwidth portions may be frequency division multiplexed, and when data transmission and reception is to be performed at a specific subcarrier interval, the bandwidth portion set to that subcarrier interval may be activated.

[0071] In addition, according to some embodiments, a base station may set a bandwidth portion having different bandwidth sizes for the purpose of reducing the power consumption of the terminal. For example, if the terminal supports a very large bandwidth, such as 100 MHz, and always transmits and receives data using that bandwidth, very large power consumption may occur. In particular, in a situation where there is no traffic, performing monitoring of an unnecessary downlink control channel using a large bandwidth of 100 MHz can be very inefficient in terms of power consumption. To reduce the power consumption of the terminal, the base station may set a bandwidth portion of a relatively small bandwidth, such as 20 MHz, for the terminal. In a situation where there is no traffic, the terminal can perform monitoring operations in the 20 MHz bandwidth portion, and when data is generated, it can transmit and receive data using the 100 MHz bandwidth portion according to the instructions of the base station.

[0072] In the method for configuring the above bandwidth portion, terminals prior to RRC connection (Connected) can receive configuration information for the Initial Bandwidth Part through the Master Information Block (MIB) during the initial connection phase. More specifically, the terminal can receive a Control Resource Set (CORESET) for a downlink control channel through which Downlink Control Information (DCI) scheduling System Information Blocks (SIB) can be transmitted from the MIB of the Physical Broadcast Channel (PBCH). The bandwidth of the control resource set by the MIB can be considered as the Initial Bandwidth Part, and through the configured Initial Bandwidth Part, the terminal can receive the Physical Downlink Shared Channel (PDSCH) through which SIBs are transmitted. In addition to receiving SIBs, the Initial Bandwidth Part may also be utilized for Other System Information (OSI), paging, and Random Access.

[0073] [Bandwidth Section (BWP) Change]

[0074] When one or more bandwidth parts are set for a terminal, the base station may instruct the terminal to change (or switch, transition) the bandwidth part using the Bandwidth Part Indicator field within the DCI. For example, in FIG. 3, if the currently active bandwidth part of the terminal is Bandwidth Part #1 (301), the base station may instruct the terminal to Bandwidth Part #2 (302) using the Bandwidth Part Indicator within the DCI, and the terminal may perform a bandwidth part change to Bandwidth Part #2 (302) indicated by the received Bandwidth Part Indicator within the DCI.

[0075] As mentioned above, since DCI-based bandwidth portion changes can be directed by the DCI scheduling PDSCH or PUSCH, when a terminal receives a bandwidth portion change request, it must be able to receive or transmit the PDSCH or PUSCH scheduled by the corresponding DCI in the changed bandwidth portion without difficulty. To this end, the standard specifies the delay time (T) required when changing the bandwidth portion. BWP The requirements for ) have been defined, and can be defined as, for example, as shown in Table 3.

[0076] μNR Slot length (ms)BWP switch delay T BWP (slots)Type 1 Note 1 Type 2 Note 1 011310.52520.253930.125618Note 1: Depends on UE capability.Note 2: If the BWP switch involves changing of SCS, the BWP switch delay is determined by the larger one between the SCS before BWP switch and the SCS after BWP switch.

[0077] The requirements for bandwidth portion change delay time support Type 1 or Type 2 depending on the terminal's capability. The terminal can report the supported bandwidth portion delay time type to the base station.

[0078] In accordance with the aforementioned requirements for bandwidth portion change delay time, if the terminal receives a DCI containing a bandwidth portion change indicator in slot n, the terminal performs a change to the new bandwidth portion indicated by the bandwidth portion change indicator in slot n+T BWPCompletion can be performed at a time no later than the new bandwidth portion, and transmission and reception for the data channel scheduled by the corresponding DCI can be performed in the changed new bandwidth portion. If the base station intends to schedule a data channel in the new bandwidth portion, the terminal's bandwidth portion change delay time (T BWP By considering ), time-domain resource allocation for a data channel can be determined. That is, when a base station schedules a data channel with a new bandwidth portion, in the method for determining time-domain resource allocation for a data channel, the data channel can be scheduled after the bandwidth portion change delay time. Accordingly, the terminal [is notified] that the DCI instructing the bandwidth portion change is the bandwidth portion change delay time (T BWP You may not expect to indicate a slot offset (K0 or K2) value smaller than )

[0079] If a terminal receives a DCI (e.g., DCI format 1_1 or 0_1) instructing a change in the bandwidth portion, the terminal may not perform any transmission or reception during a time interval corresponding to the time interval from the third symbol of the slot in which the PDCCH containing the said DCI was received to the beginning of the slot indicated by the slot offset value (K0 or K2) indicated by the time domain resource allocation indicator field within the said DCI. For example, if a terminal receives a DCI instructing a change in the bandwidth portion in slot n, and the slot offset value indicated by the said DCI is K, the terminal may not perform any transmission or reception from the third symbol of slot n to the symbol before slot n+K (i.e., the last symbol of slot n+K-1).

[0080] [SS / PBCH Block]

[0081] Next, we will explain the SS (Synchronization Signal) / PBCH block in 5G.

[0082] An SS / PBCH block may refer to a physical layer channel block composed of PSS (Primary SS), SSS (Secondary SS), and PBCH. Specifically, it is as follows.

[0083] - PSS: A signal that serves as the reference for downlink time / frequency synchronization and provides some information about the cell ID.

[0084] - SSS: Serves as the reference for downlink time / frequency synchronization and provides the remaining cell ID information not provided by PSS. Additionally, it can serve as a reference signal for PBCH demodulation.

[0085] - PBCH: Provides essential system information required for the transmission and reception of the terminal's data and control channels. The essential system information may include search space-related control information representing wireless resource mapping information of the control channel, scheduling control information for a separate data channel transmitting system information, etc.

[0086] - SS / PBCH block: An SS / PBCH block is composed of a combination of PSS, SSS, and PBCH. One or more SS / PBCH blocks may be transmitted within a time of 5ms, and each transmitted SS / PBCH block may be distinguished by an index.

[0087] The terminal can detect PSS and SSS during the initial connection phase and can decode PBCH. It can obtain MIB from PBCH and receive a Control Resource Set (CORESET) #0 from it (which may correspond to a control resource set with a control resource index of 0). The terminal can perform monitoring of Control Resource Set #0 by assuming that the selected SS / PBCH block and the Demodulation Reference Signal (DMRS) transmitted from Control Resource Set #0 are Quasi-Co-Locations (QCL). The terminal can receive system information using downlink control information transmitted from Control Resource Set #0. The terminal can obtain configuration information related to the Random Access Channel (RACH) required for initial connection from the received system information. The terminal can transmit a Physical RACH (PRACH) to the base station considering the selected SS / PBCH index, and the base station receiving the PRACH can obtain information regarding the SS / PBCH block index selected by the terminal. The base station can know that the terminal has selected a block among the respective SS / PBCH blocks and is monitoring the associated control area #0.

[0088] [PDCCH: DCI related]

[0089] Next, Downlink Control Information (DCI) in 5G systems will be explained in detail.

[0090] In a 5G system, scheduling information for uplink data (or Physical Uplink Shared Channel (PUSCH)) or downlink data (or Physical Downlink Shared Channel (PDSCH)) is transmitted from the base station to the terminal via DCI. The terminal can monitor the fallback DCI format and the non-fallback DCI format for PUSCH or PDSCH. The fallback DCI format may consist of fixed fields selected between the base station and the terminal, and the non-fallback DCI format may include configurable fields.

[0091] DCI can be transmitted through the Physical Downlink Control Channel (PDCCH) after undergoing channel coding and modulation processes. A Cyclic Redundancy Check (CRC) is attached to the DCI message payload, and the CRC can be scrambled into a Radio Network Temporary Identifier (RNTI) corresponding to the terminal's identity. Different RNTIs may be used depending on the purpose of the DCI message, such as UE-specific data transmission, power control commands, or random access responses. In other words, the RNTI is not transmitted explicitly but is included in the CRC calculation process. Upon receiving a DCI message transmitted over the PDCCH, the terminal checks the CRC using the assigned RNTI; if the CRC check result is correct, the terminal knows that the message has been transmitted to it.

[0092] For example, a DCI scheduling a PDSCH for System Information (SI) can be scrambled to SI-RNTI. A DCI scheduling a PDSCH for Random Access Response (RAR) messages can be scrambled to RA-RNTI. A DCI scheduling a PDSCH for Paging messages can be scrambled to P-RNTI. A DCI notifying a Slot Format Indicator (SFI) can be scrambled to SFI-RNTI. A DCI notifying Transmit Power Control (TPC) can be scrambled to TPC-RNTI. A DCI scheduling a terminal-specific PDSCH or PUSCH can be scrambled to C-RNTI (Cell RNTI).

[0093] DCI format 0_0 can be used as a countermeasure DCI for scheduling PUSCH, in which case the CRC can be scrambled with C-RNTI. DCI format 0_0 with the CRC scrambled with C-RNTI can include, for example, the information in Table 4.

[0094] - Identifier for DCI formats - [1] bit- Frequency domain resource assignment -[ ] bits- Time domain resource assignment - X bits- Frequency hopping flag - 1 bit- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- TPC command for scheduled PUSCH - [2] bits- UL / SUL indicator - 0 or 1 bit

[0095] DCI format 0_1 ​​can be used as a non-defense DCI for scheduling PUSCH, whereby the CRC can be scrambled with C-RNTI. DCI format 0_1 ​​with the CRC scrambled with C-RNTI can include, for example, the information in Table 5.

[0096] - Carrier indicator - 0 or 3 bits - UL / SUL indicator - 0 or 1 bit - Identifier for DCI formats - [1] bits - Bandwidth part indicator - 0, 1 or 2 bits - Frequency domain resource assignment - For resource allocation type 0, bits- For resource allocation type 1, bits- Time domain resource assignment -1, 2, 3, or 4 bits- VRB-to-PRB mapping (virtual resource block-to-physical resource block mapping) - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- Frequency hopping flag - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- 1st downlink assignment index (first downlink allocation index)- 1 or 2 bits○ 1 bit for semi-static HARQ-ACK codebook (semi-static HARQ-ACK In case of codebook);○ 2 bits for dynamic HARQ-ACK codebook with single HARQ-ACK codebook (when a dynamic HARQ-ACK codebook is used with a single HARQ-ACK codebook).- 2nd downlink assignment index - 0 or 2 bits ○ 2 bits for dynamic HARQ-ACK codebook with two HARQ-ACK sub-codebooks (when a dynamic HARQ-ACK codebook is used with two HARQ-ACK sub-codebooks); ○ 0 bit otherwise.TPC command for scheduled PUSCH - 2 bits- SRS resource indicator (SRS resource indicator) -. or bits○ bits for non-codebook based PUSCH transmission(if PUSCH transmission is not codebook-based);○ bits for codebook-based PUSCH transmission. - Precoding information and number of layers - up to 6 bits - Antenna ports - up to 5 bits - SRS request - 2 bits - CSI request - 0, 1, 2, 3, 4, 5, or 6 bits - CBG transmission information - 0, 2, 4, 6, or 8 bits - PTRS-DMRS association - 0 or 2 bits - beta_offset indicator - 0 or 2 bits - DMRS sequence initialization - 0 or 1 bit

[0097] DCI format 1_0 can be used as a countermeasure DCI for scheduling PDSCH, whereby the CRC can be scrambled with C-RNTI. DCI format 1_0 with the CRC scrambled with C-RNTI can include, for example, the information in Table 6.

[0098] - Identifier for DCI formats - [1] bit- Frequency domain resource assignment -[ ] bits- Time domain resource assignment - X bits- VRB-to-PRB mapping - 1 bit- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- Downlink assignment index - 2 bits- TPC command for scheduled PUCCH - [2] bits- PUCCH resource indicator - 3 bits- PDSCH-to-HARQ feedback timing indicator - [3] bits

[0099] DCI format 1_1 can be used as a non-defense DCI for scheduling PDSCH, whereby the CRC can be scrambled with C-RNTI. DCI format 1_1 with the CRC scrambled with C-RNTI can include, for example, the information in Table 7.

[0100] - Carrier indicator - 0 or 3 bits- Identifier for DCI formats - [1] bits- Bandwidth part indicator - 0, 1 or 2 bits- Frequency domain resource assignment○ For resource allocation type 0, bits○ For resource allocation type 1, bits- Time domain resource assignment -1, 2, 3, or 4 bits- VRB-to-PRB mapping - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- PRB bundling size indicator - 0 or 1 bit - Rate matching indicator - 0, 1, or 2 bits - ZP CSI-RS trigger - 0, 1, or 2 bits - For transport block 1: - Modulation and coding scheme - 5 bits - New data indicator - 1 bit - Redundancy version - 2 bits - For transport block 2: - Modulation and coding scheme - 5 bits - New data indicator - 1 bit - Redundancy version - 2 bits - HARQ process number - 4 bits - Downlink assignment index - 0 or 2 or 4 bits - TPC command for scheduled PUCCH - 2 bits - PUCCH resource indicator - 3 bits - PDSCH-to-HARQ_feedback timing indicator - 3 bits - Antenna ports 4, 5, or 6 bits - Transmission configuration indication - 0 or 3 bits - SRS request - 2 bits - CBG transmission information - 0, 2, 4, 6, or 8 bits - CBG flushing out information - 0 or 1 bit - DMRS sequence initialization - 1 bit.

[0101] [PDCCH: CORESET, REG, CCE, Search Space]

[0102] In the following, the downlink control channel in a 5G communication system will be explained in more detail with reference to the drawings.

[0103] FIG. 4 is a diagram illustrating an example of setting a control area of ​​a downlink control channel in a wireless communication system according to one embodiment of the present disclosure.

[0104] FIG. 4 illustrates an example in which two control areas (control area #1 (401), control area #2 (402)) are set within a terminal bandwidth part (UE bandwidth part) (410) on the frequency axis and a slot (420) on the time axis. The control areas (401, 402) can be set to a specific frequency resource (403) within the entire terminal bandwidth part (410) on the frequency axis. On the time axis, they can be set to one or more OFDM symbols and can be defined as the control area length (Control Resource Set Duration, 404). Referring to the example illustrated in FIG. 4, control area #1 (401) is set to a control area length of 2 symbols, and control area #2 (402) is set to a control area length of 1 symbol.

[0105] The control domain in the aforementioned 5G can be configured by a base station to a terminal through upper-layer signaling (e.g., System Information, Master Information Block (MIB), Radio Resource Control (RRC) signaling). Configuring a control domain to a terminal means providing information such as a control domain identifier, the frequency location of the control domain, and the symbol length of the control domain. For example, it may include the information in Table 8.

[0106] ControlResourceSet ::= SEQUENCE {-- Corresponds to L1 parameter 'CORESET-ID'controlResourceSetId ControlResourceSetId,(Control Domain Identifier(Identity))frequencyDomainResources BIT STRING (SIZE (45)),(Frequency Axis Resource Allocation Info)duration INTEGER (1..maxCoReSetDuration),(Time Axis Resource Allocation Info)cce-REG-MappingType CHOICE {(CCE-to-REG Mapping Type)interleaved SEQUENCE {reg-BundleSize ENUMERATED {n2, n3, n6},(REG Bundle Size)precoderGranularity ENUMERATED {sameAsREG-bundle, allContiguousRBs},interleaverSize ENUMERATED {n2, n3, n6}(Interleaver Size)shiftIndex INTEGER(0..maxNrofPhysicalResourceBlocks-1) OPTIONAL(Interleaved Shift)},nonInterleaved NULL},tci-StatesPDCCH SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId OPTIONAL,(QCL setting information)tci-PresentInDCI ENUMERATED {enabled} OPTIONAL, -- Need S}

[0107] In Table 8, the tci-StatesPDCCH (simply named TCI (Transmission Configuration Indication) state) configuration information may include information on one or more SS (Synchronization Signal) / PBCH (Physical Broadcast Channel) block indices or CSI-RS (Channel State Information Reference Signal) indices that are in a QCL (Quasi Co Located) relationship with the DMRS transmitted in the corresponding control area.

[0108] FIG. 5 is a diagram illustrating the structure of a downlink control channel in a wireless communication system according to one embodiment of the present disclosure.

[0109] According to FIG. 5, the basic unit of time and frequency resources constituting a control channel can be called a REG (Resource Element Group, 503), and the REG (503) can be defined as 1 OFDM symbol (501) on the time axis and 1 PRB (Physical Resource Block, 502) on the frequency axis, i.e., 12 subcarriers. A base station can concatenate REGs (503) to form a downlink control channel allocation unit.

[0110] As illustrated in FIG. 5, if the basic unit to which a downlink control channel is allocated in 5G is called a CCE (Control Channel Element, 504), then 1 CCE (504) can be composed of multiple REGs (503). For example, if the REG (503) illustrated in FIG. 5 is described, the REG (503) can be composed of 12 REs, and if 1 CCE (504) is composed of 6 REGs (503), then 1 CCE (504) can be composed of 72 REs. When a downlink control area is established, the area can be composed of multiple CCEs (504), and a specific downlink control channel can be mapped to one or multiple CCEs (504) and transmitted according to the Aggregation Level (AL) within the control area. The CCEs (504) in the control area are distinguished by numbers, and the numbers of the CCEs (504) can be assigned according to a logical mapping method.

[0111] The basic unit of the downlink control channel, namely the REG (503) shown in FIG. 5, may include both the REs to which the DCI is mapped and the DMRS (505), which is a reference signal for decoding, to which the area is mapped. As shown in FIG. 5, three DMRS (505) may be transmitted within one REG (503). The number of CCEs required to transmit the PDCCH may be 1, 2, 4, 8, or 16 depending on the Aggregation Level (AL), and different numbers of CCEs may be used to implement link adaptation of the downlink control channel. For example, when AL=L, one downlink control channel may be transmitted through L CCEs. The terminal must detect the signal without knowing information about the downlink control channel, and a search space representing a set of CCEs is defined for blind decoding. A search space is a set of downlink control channel candidates consisting of CCEs that a terminal must attempt to decode at a given aggregation level, and since there are various aggregation levels that form a group of 1, 2, 4, 8, or 16 CCEs, a terminal may have multiple search spaces. A search space set can be defined as a set of search spaces at all configured aggregation levels.

[0112] Search spaces can be classified into common search spaces and UE-specific search spaces. A certain group of terminals or all terminals may examine the common search space of the PDCCH to receive cell-common control information, such as dynamic scheduling or paging messages regarding system information. For example, PDSCH scheduling allocation information for the transmission of SIBs containing cell operator information can be received by examining the common search space of the PDCCH. In the case of the common search space, since a certain group of terminals or all terminals must receive the PDCCH, it can be defined as a pre-arranged set of CCEs. Scheduling allocation information for a UE-specific PDSCH or PUSCH can be received by examining the UE-specific search space of the PDCCH. The UE-specific search space can be defined specifically as a function of the terminal's identity and various system parameters.

[0113] In 5G, parameters for the search space for a PDCCH can be configured from the base station to the terminal via upper-layer signaling (e.g., SIB, MIB, RRC signaling). For example, the base station may configure the terminal the number of PDCCH candidates at each aggregation level L, the monitoring period for the search space, the occasion for monitoring in slot-symbol units for the search space, the search space type (common search space or terminal-specific search space), the combination of DCI format and RNTI to be monitored in the search space, and the control domain index to be monitored in the search space. For example, the information in Table 9 may be included.

[0114] SearchSpace ::= SEQUENCE {-- Identity of the search space. SearchSpaceId = 0 identifies the SearchSpace configured via PBCH (MIB) or ServingCellConfigCommon.searchSpaceId SearchSpaceId,(Search Space Identifier)controlResourceSetId ControlResourceSetId,(Control Area Identifier)monitoringSlotPeriodicityAndOffset CHOICE {(Monitoring Slot Level Period)sl1 NULL,sl2 INTEGER (0..1),sl4 INTEGER (0..3),sl5 INTEGER (0..4),sl8 INTEGER (0..7),sl10 INTEGER (0..9),sl16 INTEGER (0..15),sl20 INTEGER (0..19)} OPTIONAL,duration(Monitoring Length) INTEGER (2..2559)monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL,(슬롘 내 나이스 심보)nrofCandidates SEQUENCE {(집성 별보 PDCCH 이리군 수)aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}},searchSpaceType CHOICE {(தமாற்க்குக்க்கு திய்தை)-- Configures this search space as common search space (CSS) and DCI formats to monitor.common SEQUENCE {(공통이이국이)}ue-Specific SEQUENCE {(단말-특정이스국)-- Indicates whether the UE monitors in this USS for DCI formats 0-0 and 1-0 or for formats 0-1 and 1-1.formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1},...}.

[0115] According to the configuration information, the base station may set one or multiple sets of search spaces for the terminal. According to some embodiments, the base station may set search space set 1 and search space set 2 for the terminal, and may set DCI format A scrambled with X-RNTI in search space set 1 to be monitored in a common search space, and may set DCI format B scrambled with Y-RNTI in search space set 2 to be monitored in a terminal-specific search space.

[0116] According to the configuration information, one or more sets of search spaces may exist in a common search space or a terminal-specific search space. For example, Search Space Set #1 and Search Space Set #2 may be configured as a common search space, and Search Space Set #3 and Search Space Set #4 may be configured as a terminal-specific search space.

[0117] In the common search space, the following combinations of DCI formats and RNTI can be monitored. Of course, they are not limited to the examples below.

[0118] - DCI format 0_0 / 1_0 with CRC scrambled by C-RNTI, CS-RNTI, SP-CSI-RNTI, RA-RNTI, TC-RNTI, P-RNTI, SI-RNTI

[0119] - DCI format 2_0 with CRC scrambled by SFI-RNTI

[0120] - DCI format 2_1 with CRC scrambled by INT-RNTI

[0121] - DCI format 2_2 with CRC scrambled by TPC-PUSCH-RNTI, TPC-PUCCH-RNTI

[0122] - DCI format 2_3 with CRC scrambled by TPC-SRS-RNTI

[0123] In terminal-specific search spaces, the following combinations of DCI formats and RNTI can be monitored. Of course, they are not limited to the examples below.

[0124] - DCI format 0_0 / 1_0 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI

[0125] - DCI format 1_0 / 1_1 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI

[0126] The specified RNTIs may follow the definitions and uses below.

[0127] C-RNTI (Cell RNTI): Used for terminal-specific PDSCH scheduling

[0128] TC-RNTI (Temporary Cell RNTI): Used for terminal-specific PDSCH scheduling

[0129] CS-RNTI (Configured Scheduling RNTI): Used for semi-statically configured terminal-specific PDSCH scheduling.

[0130] RA-RNTI (Random Access RNTI): Used for PDSCH scheduling during the random access phase

[0131] P-RNTI (Paging RNTI): Used for PDSCH scheduling where paging is transmitted.

[0132] SI-RNTI (System Information RNTI): Used for PDSCH scheduling where system information is transmitted.

[0133] INT-RNTI (Interruption RNTI): Used to indicate whether PDSCH has been punctured.

[0134] TPC-PUSCH-RNTI (Transmit Power Control for PUSCH RNTI): Used to instruct power control commands to the PUSCH

[0135] TPC-PUCCH-RNTI (Transmit Power Control for PUCCH RNTI): Used to instruct power control commands to the PUCCH

[0136] TPC-SRS-RNTI (Transmit Power Control for SRS RNTI): Used to instruct power regulation commands to the SRS

[0137] The aforementioned specified DCI formats may follow definitions such as the examples in Table 10.

[0138] DCI formatUsage0_0Scheduling of PUSCH in one cell0_1Scheduling of PUSCH in one cell1_0Scheduling of PDSCH in one cell1_1Scheduling of PDSCH in one cell2_0Notifying a group of UEs of the slot format2_1Notifying a group of UEs of the PRB(s) and OFDM symbol(s) where UE may assume no transmission is intended for the UE2_2Transmission of TPC commands for PUCCH and PUSCH2_3Transmission of a group of TPC commands for SRS transmissions by one or more UEs

[0139] In 5G, the search space of aggregation level L in the control domain p and search space set s can be expressed as Equation 1 below.

[0140] [Mathematical Formula 1]

[0141]

[0142] - : Lamination level

[0143] - : Carrier Index

[0144] - : Total number of CCEs existing within control domain p

[0145] - : Slot Index

[0146] - : Number of PDCCH candidates at assembly level L

[0147] - = 0, ..., -1: PDCCH candidate index of aggregation level L

[0148] - = 0, ..., -1

[0149] - , , , , ,

[0150] - : Terminal identifier

[0151] The value may be 0 for the common search space.

[0152] In the case of a terminal-specific search space, the value may correspond to a value that changes according to the terminal's identity (C-RNTI or ID set by the base station for the terminal) and the time index.

[0153] In 5G, as multiple sets of search spaces can be configured with different parameters (e.g., the parameters in Table 9), the set of search space sets monitored by the terminal at each point in time may vary. For example, if search space set #1 is configured with an X-slot period and search space set #2 is configured with a Y-slot period and X and Y are different, the terminal may monitor both search space set #1 and search space set #2 in a specific slot, and monitor either search space set #1 or search space set #2 in a specific slot.

[0154] [PDCCH: BD / CCE limit]

[0155] When multiple sets of search spaces are configured for a terminal, the following conditions may be considered in determining the set of search spaces that the terminal must monitor.

[0156] If the terminal receives the value of monitoringCapabilityConfig-r16, which is an upper layer signaling, as r15monitoringcapability, the terminal defines the maximum value for the number of PDCCH candidates that can be monitored and the number of CCEs constituting the entire search space (where the entire search space refers to the entire set of CCEs corresponding to the union area of ​​multiple search space sets) per slot, and if the value of monitoringCapabilityConfig-r16 is received as r16monitoringcapability, the terminal defines the maximum value for the number of PDCCH candidates that can be monitored and the number of CCEs constituting the entire search space (where the entire search space refers to the entire set of CCEs corresponding to the union area of ​​multiple search space sets) per span.

[0157] [Condition 1: Limit on the maximum number of PDCCH candidates]

[0158] As described above, M is the maximum number of PDCCH candidate groups that the terminal can monitor, depending on the setting value of the upper layer signaling. μ The subcarrier interval is 15·2 μ In a cell set to kHz, if defined based on slots, follow Table 11 below, and if defined based on spans, follow Table 12 below.

[0159] μMaximum number of PDCCH candidates per slot and per serving cell (M μ )044136222320

[0160] Maximum number M μ of monitored PDCCH candidates per span for combination (X,Y) and per serving cellμ(2,2)(4,3)(7,3)01428441122436

[0161] [Condition 2: Limit on Maximum CCEs]

[0162] As described above, depending on the setting value of the upper layer signaling, C, which is the maximum number of CCEs constituting the entire search space (where the entire search space refers to the entire set of CCEs corresponding to the union area of ​​multiple search space sets), μ The subcarrier interval is 15·2 μ In a cell set to kHz, if defined based on slots, follow Table 13 below, and if defined based on spans, follow Table 14 below.

[0163] μMaximum number of non-overlapped CCEs per slot and per serving cell (C μ )056156248332

[0164] Maximum number C μof non-overlapped CCEs per span for combination (X,Y) and per serving cellμ(2,2)(4,3)(7,3)01836561183656

[0165] For the convenience of explanation, a situation in which both of the above conditions 1 and 2 are satisfied at a specific point in time is defined as "condition A". Therefore, not satisfying condition A may mean not satisfying at least one of the above conditions 1 and 2.

[0166] [PDCCH: Overbooking]

[0167] Depending on the configuration of the base station's search space sets, there may be cases where Condition A is not satisfied at a specific point in time. If Condition A is not satisfied at a specific point in time, the terminal may select and monitor only some of the search space sets configured to satisfy Condition A at that point in time, and the base station may transmit a PDCCH to the selected search space sets.

[0168] You can follow the method below to select some of the navigation spaces from the entire set of configured navigation spaces.

[0169] If condition A for PDCCH is not satisfied at a specific time point (slot), the terminal (or base station) may preferentially select a search space set with a search space type set as a common search space among the search space sets existing at that time point, over a search space set with a search space type set as a terminal-specific search space.

[0170] When all sets of search spaces configured as common search spaces have been selected (i.e., when Condition A is satisfied even after selecting all search spaces configured as common search spaces), the terminal (or base station) may select sets of search spaces configured as terminal-specific search spaces. In this case, if there are multiple sets of search spaces configured as terminal-specific search spaces, the search space set with a lower search space set index may have a higher priority. Considering the priority, sets of terminal-specific search spaces may be selected within the range where Condition A is satisfied.

[0171] [Regarding Rate Matching / Puncturing]

[0172] In the following, the rate matching operation and puncturing operation will be described in detail.

[0173] When a time and frequency resource A intended to transmit an arbitrary symbol sequence A overlaps with an arbitrary time and frequency resource B, rate matching or puncturing operations may be considered as transmission and reception operations of channel A, taking into account the area resource C where resource A and resource B overlap. Specific operations may follow the details below.

[0174] Rate Matching Operation

[0175] - A base station may transmit a symbol sequence A to a terminal by mapping Channel A only to the remaining resource area, excluding Resource C which corresponds to the area overlapping with Resource B, from the entire Resource A. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, Resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and Resource B is {Resource #3, Resource #5}, the base station may sequentially map and send symbol sequence A to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3} which corresponds to Resource C within Resource A. Consequently, the base station can transmit the symbol sequence {Symbol #1, Symbol #2, Symbol #3} by mapping it to {Resource #1, Resource #2, Resource #4}, respectively.

[0176] The terminal can determine Resource A and Resource B from scheduling information regarding Symbol Sequence A from the base station, and thereby determine Resource C, which is the area where Resource A and Resource B overlap. The terminal can receive Symbol Sequence A by assuming that Symbol Sequence A was transmitted by mapping it to the remaining area of ​​Resource A, excluding Resource C. For example, if Symbol Sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, Resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and Resource B is {Resource #3, Resource #5}, the terminal can receive Symbol Sequence A by assuming that it was sequentially mapped to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3}, which corresponds to Resource C. Consequently, the terminal can perform a series of subsequent reception operations by assuming that Symbol Sequence {Symbol #1, Symbol #2, Symbol #3} was transmitted by mapping it to {Resource #1, Resource #2, Resource #4}, respectively.

[0177] Puncturing action

[0178] If there is a resource C corresponding to an area overlapping with resource B among all resources A to which the base station intends to transmit symbol sequence A to a terminal, the base station maps symbol sequence A to the entire resource A, but does not perform transmission in the resource area corresponding to resource C, and can perform transmission only in the remaining resource area of ​​resource A excluding resource C. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and resource B is {Resource #3, Resource #5}, the base station can map symbol sequence A {Symbol #1, Symbol #2, Symbol #3, Symbol #4} to resource A {Resource #1, Resource #2, Resource #3, Resource #4} respectively, and transmit only the symbol sequence {Symbol #1, Symbol #2, Symbol #4} corresponding to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3} corresponding to resource C, and may not transmit {Symbol #3} mapped to {Resource #3} corresponding to resource C. Consequently, the base station can map and transmit the symbol sequence {Symbol #1, Symbol #2, Symbol #4} to {Resource #1, Resource #2, Resource #4} respectively.

[0179] The terminal can determine resources A and B from scheduling information for symbol sequence A from the base station, and thereby determine resource C, which is the area where resources A and B overlap. The terminal can receive symbol sequence A by assuming that symbol sequence A is mapped to the entire resource A, but is transmitted only in the remaining area of ​​resource A excluding resource C. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and resource B is {Resource #3, Resource #5}, the terminal can assume that symbol sequence A {Symbol #1, Symbol #2, Symbol #3, Symbol #4} is mapped to resource A {Resource #1, Resource #2, Resource #3, Resource #4} respectively, but {Symbol #3} mapped to {Resource #3} corresponding to resource C is not transmitted, and can receive by assuming that symbol sequence {Symbol #1, Symbol #2, Symbol #4} corresponding to the remaining resources {Resource #1, Resource #2, Resource #4}—excluding {Resource #3} corresponding to resource C—is mapped and transmitted. Consequently, the terminal can perform a subsequent series of receiving operations by assuming that the symbol sequence {Symbol #1, Symbol #2, Symbol #4} has been transmitted and mapped to {Resource #1, Resource #2, Resource #4}, respectively.

[0180] In the following, a method for configuring rate matching resources for the purpose of rate matching in a 5G communication system is described. Rate matching refers to the adjustment of the signal size by considering the amount of resources available to transmit the signal. For example, rate matching of a data channel may mean that the data channel is mapped to a specific time and frequency resource range so that the data size is adjusted accordingly without transmission.

[0181] FIG. 6 is a diagram illustrating a method for transmitting and receiving data in a wireless communication system according to one embodiment of the present disclosure, in consideration of a downlink data channel and a rate matching resource, between a base station and a terminal.

[0182] FIG. 6 illustrates a downlink data channel (PDSCH, 601) and a rate matching resource (602). A base station may set one or more rate matching resources (602) to a terminal through upper layer signaling (e.g., RRC signaling). The rate matching resource (602) setting information may include time axis resource allocation information (603), frequency axis resource allocation information (604), and period information (605). In the following, the bitmap corresponding to the frequency axis resource allocation information (604) is named the "first bitmap," the bitmap corresponding to the time axis resource allocation information (603) is named the "second bitmap," and the bitmap corresponding to the period information (605) is named the "third bitmap." If all or part of the time and frequency resources of a scheduled data channel (601) overlap with a set rate matching resource (602), the base station can transmit the data channel (601) by rate matching it in the rate matching resource (602) portion, and the terminal can perform reception and decoding after assuming that the data channel (601) is rate matched in the rate matching resource (602) portion.

[0183] The base station can dynamically notify the terminal via DCI whether to rate match a data channel in the above-mentioned rate matching resource portion through additional settings (corresponding to the "rate matching indicator" within the aforementioned DCI format). Specifically, the base station can select some of the above-mentioned rate matching resources and group them into rate matching resource groups, and can indicate to the terminal via DCI using a bitmap method whether to rate match a data channel for each rate matching resource group. For example, if four rate matching resources, RMR#1, RMR#2, RMR#3, and RMR#4, are set, the base station can set RMG#1={RMR#1, RMR#2} and RMG#2={RMR#3, RMR#4} as rate matching groups, and can indicate to the terminal via a bitmap whether to rate match in RMG#1 and RMG#2, respectively, using 2 bits within the DCI field. For example, you can indicate "1" when rate matching is required and "0" when rate matching is not required.

[0184] In 5G, the granularity of "RB symbol level" and "RE level" is supported by setting the aforementioned rate matching resources to the terminal. More specifically, the following setting method may be followed.

[0185] RB symbol level

[0186] The terminal can receive up to four RateMatchPatterns as upper layer signaling for each bandwidth portion, and one RateMatchPattern may include the following contents.

[0187] - As a Reserved Resource within the bandwidth portion, a resource may be included in which the time and frequency resource domains of the said Reserved Resource are set as a combination of an RB level bitmap and a symbol level bitmap along the frequency axis. The said Reserved Resource may span across one or two slots. A time domain pattern (periodicityAndPattern) in which the time and frequency domains composed of each RB level and symbol level bitmap pair are repeated may be additionally set.

[0188] - It may include time and frequency domain resource areas set as control resource sets within the bandwidth portion, and resource areas corresponding to time domain patterns set as search space settings where the resource areas are repeated.

[0189] RE level

[0190] The terminal can receive the following settings through upper-layer signaling.

[0191] - Configuration information for an RE corresponding to an LTE CRS (Cell-specific Reference Signal or Common Reference Signal) pattern (lte-CRS-ToMatchAround) may include the number of ports of the LTE CRS (nrofCRS-Ports) and the LTE-CRS-vshift(s) value (v-shift), location information of the LTE carrier's center subcarrier (carrierFreqDL) from a reference frequency point (e.g., reference point A), information on the LTE carrier's bandwidth (carrierBandwidthDL), and subframe configuration information corresponding to a Multiast-broadcast single-frequency network (mbsfn-SubframConfigList). Based on the aforementioned information, the terminal can determine the location of the CRS within the NR slot corresponding to the LTE subframe.

[0192] - It may include configuration information for resource sets corresponding to one or more ZP (Zero Power) CSI-RS within the bandwidth portion.

[0193] [Regarding LTE CRS rate match]

[0194] Next, the rate match process for the LTE CRS described above will be explained in detail. For the coexistence of LTE (Long Term Evolution) and NR (New RAT) (LTE-NR Coexistence), NR provides a function to set the pattern of the LTE CRS (Cell Specific Reference Signal) to the NR terminal. More specifically, the CRS pattern may be provided by RRC signaling that includes at least one parameter within the ServingCellConfig IE (Information Element) or ServingCellConfigCommon IE. Examples of the above parameters may include lte-CRS-ToMatchAround, lte-CRS-PatternList1-r16, lte-CRS-PatternList2-r16, crs-RateMatch-PerCORESETPoolIndex-r16, etc.

[0195] In Rel-15 NR, the lte-CRS-ToMatchAround parameter provides the ability to set one CRS pattern per serving cell. In Rel-16 NR, this ability has been extended to allow multiple CRS patterns to be set per serving cell. More specifically, for a Single-TRP (transmission and reception point) configured terminal, one CRS pattern can be set per LTE carrier, and for a Multi-TRP configured terminal, two CRS patterns can be set per LTE carrier. For example, for a Single-TRP configured terminal, up to three CRS patterns per serving cell can be set through the lte-CRS-PatternList1-r16 parameter. As another example, for a multi-TRP configured terminal, CRS can be set per TRP. In other words, the CRS pattern for TRP1 is set via the lte-CRS-PatternList1-r16 parameter, and the CRS pattern for TRP2 can be set via the lte-CRS-PatternList2-r16 parameter. Meanwhile, when two TRPs are configured as described above, whether to apply both TRP1 and TRP2's CRS patterns to a specific PDSCH (Physical Downlink Shared Channel) or only one TRP's CRS pattern is determined by the crs-RateMatch-PerCORESETPoolIndex-r16 parameter; if the crs-RateMatch-PerCORESETPoolIndex-r16 parameter is set to enabled, only one TRP's CRS pattern is applied, whereas otherwise, both TRP's CRS patterns are applied.

[0196] Table 15 shows a ServingCellConfig IE including the above CRS pattern, and Table 16 shows a RateMatchPatternLTE-CRS IE including at least one parameter for the CRS pattern.

[0197] ServingCellConfig ::= SEQUENCE {tdd-UL-DL-ConfigurationDedicated TDD-UL-DL-ConfigDedicated OPTIONAL, -- Cond TDDinitialDownlinkBWP BWP-DownlinkDedicated OPTIONAL, -- Need MdownlinkBWP-ToReleaseList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Id OPTIONAL, -- Need NdownlinkBWP-ToAddModList SEQUENCE (SIZE (1..maxNrofBWPs)) OF BWP-Downlink OPTIONAL, -- Need NfirstActiveDownlinkBWP-Id BWP-Id OPTIONAL, -- Cond SyncAndCellAddbwp-InactivityTimer ENUMERATED {ms2, ms3, ms4, ms5, ms6, ms8, ms10, ms20, ms30,ms40,ms50, ms60, ms80,ms100, ms200,ms300, ms500,ms750, ms1280, ms1920, ms2560, spare10, spare9, spare8,spare7, spare6, spare5, spare4, spare3, spare2, spare1} OPTIONAL, --Need RdefaultDownlinkBWP-Id BWP-Id OPTIONAL, -- Need SuplinkConfig UplinkConfig OPTIONAL, -- Need MsupplementaryUplink UplinkConfig OPTIONAL, -- Need Mpdcch-ServingCellConfig SetupRelease { PDCCH-ServingCellConfig} OPTIONAL, -- Need Mpdsch-ServingCellConfig SetupRelease { PDSCH-ServingCellConfig} OPTIONAL,-- Need Mcsi-MeasConfig SetupRelease { CSI-MeasConfig} OPTIONAL, -- Need MsCellDeactivationTimer ENUMERATED {ms20, ms40, ms80, ms160, ms200, ms240,ms320, ms400, ms480, ms520, ms640, ms720,ms840, ms1280, spare2,spare1} OPTIONAL, -- Cond ServingCellWithoutPUCCHcrossCarrierSchedulingConfig CrossCarrierSchedulingConfig OPTIONAL, -- Need Mtag-Id TAG-Id,dummy ENUMERATED {enabled} OPTIONAL, -- Need RpathlossReferenceLinking ENUMERATED {spCell, sCell} OPTIONAL, -- Cond SCellOnlyservingCellMO MeasObjectId OPTIONAL, -- Cond MeasObject...,[[lte-CRS-ToMatchAround SetupRelease { RateMatchPatternLTE-CRS} OPTIONAL, -- Need MrateMatchPatternToAddModList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPattern OPTIONAL, -- Need NrateMatchPatternToReleaseList SEQUENCE (SIZE (1..maxNrofRateMatchPatterns)) OF RateMatchPatternId OPTIONAL, -- Need NdownlinkChannelBW-PerSCS-List SEQUENCE (SIZE (1..maxSCSs)) OF SCS-SpecificCarrier OPTIONAL -- Need S]],[[supplementaryUplinkRelease ENUMERATED {true} OPTIONAL, -- Need Ntdd-UL-DL-ConfigurationDedicated-IAB-MT-r16 TDD-UL-DL-ConfigDedicated-IAB-MT-r16 OPTIONAL, -- Cond TDD_IABdormantBWP-Config-r16 SetupRelease { DormantBWP-Config-r16} OPTIONAL, -- Need Mca-SlotOffset-r16 CHOICE {refSCS15kHz INTEGER (-2..2),refSCS30KHz INTEGER (-5..5),refSCS60KHz INTEGER (-10..10),refSCS120KHz INTEGER (-20..20)} OPTIONAL, -- Cond AsyncCAchannelAccessConfig-r16 SetupRelease { ChannelAccessConfig-r16} OPTIONAL, -- Need MintraCellGuardBandsDL-List-r16 SEQUENCE (SIZE (1..maxSCSs)) OF IntraCellGuardBandsPerSCS-r16 OPTIONAL, -- Need SintraCellGuardBandsUL-List-r16 SEQUENCE (SIZE (1..maxSCSs)) OF IntraCellGuardBandsPerSCS-r16 OPTIONAL, -- Need Scsi-RS-ValidationWith-DCI-r16 ENUMERATED {enabled} OPTIONAL, -- Need Rlte-CRS-PatternList1-r16 SetupRelease { LTE-CRS-PatternList-r16} OPTIONAL, -- Need Mlte-CRS-PatternList2-r16 SetupRelease { LTE-CRS-PatternList-r16} OPTIONAL,-- Need Mcrs-RateMatch-PerCORESETPoolIndex-r16 ENUMERATED {enabled} OPTIONAL, -- Need RenableTwoDefaultTCI-States-r16 ENUMERATED {enabled} OPTIONAL, -- Need RenableDefaultTCI-StatePerCoresetPoolIndex-r16 ENUMERATED {enabled} OPTIONAL, -- Need RenableBeamSwitchTiming-r16 ENUMERATED {true} OPTIONAL, -- Need Rcbg-TxDiffTBsProcessingType1-r16 ENUMERATED {enabled} OPTIONAL, -- Need Rcbg-TxDiffTBsProcessingType2-r16 ENUMERATED {enabled} OPTIONAL -- Need R]]},

[0198] -RateMatchPatternLTE-CRSThe IERateMatchPatternLTE-CRSis used to configure a pattern to rate match around LTE CRS. See TS 38.214, clause 5.1.4.2.RateMatchPatternLTE-CRSinformation element-- ASN1START-- TAG-RATEMATCHPATTERNLTE-CRS-STARTRateMatchPatternLTE-CRS ::= SEQUENCE {carrierFreqDL INTEGER (0..16383),carrierBandwidthDL ENUMERATED {n6, n15, n25, n50, n75, n100, spare2, spare1},mbsfn-SubframeConfigList EUTRA-MBSFN-SubframeConfigList OPTIONAL, -- Need MnrofCRS-Ports ENUMERATED {n1, n2, n4},v-Shift ENUMERATED {n0, n1, n2, n3, n4, n5}}LTE-CRS-PatternList-r16 ::= SEQUENCE (SIZE (1..maxLTE-CRS-Patterns-r16)) OF RateMatchPatternLTE-CRS-- TAG-RATEMATCHPATTERNLTE-CRS-STOP-- ASN1STOPRateMatchPatternLTE-CRSfield descriptionscarrierBandwidthDLBW of the LTE carrier in number of PRBs (see TS 38.214, clause 5.1.4.2).carrierFreqDLCenter of the LTE carrier (see TS 38.214, clause 5.1.4.2).mbsfn-SubframeConfigListLTE MBSFN subframe configuration (see TS 38.214, clause 5.1.4.2).nrofCRS-PortsNumber of LTE CRS antenna port to rate-match around (see TS 38.214, clause 5.1.4.2).v-ShiftShifting value v-shift in LTE to rate match around LTE CRS (see TS 38.214, clause 5.1.4.2).

[0199] [PDSCH: Regarding Frequency Resource Allocation]

[0200] FIG. 7 is a diagram illustrating an example of frequency axis resource allocation of a PDSCH in a wireless communication system according to one embodiment of the present disclosure.

[0201] Referring to FIG. 7, three frequency axis resource allocation methods are illustrated, which are configurable through the upper layer in an NR wireless communication system: type 0 (7-00), type 1 (7-05), and dynamic switch (7-10).

[0202] If the terminal is configured to use only resource type 0 through upper layer signaling (7-00), some downlink control information (DCI) that assigns PDSCH to the terminal includes a bitmap consisting of NRBG bits. The conditions for this will be explained later. In this case, NRBG refers to the number of RBGs (resource block groups) determined as shown in [Table 17] below according to the BWP size assigned by the BWP indicator and the upper layer parameter rbg-Size, and data is transmitted to the RBG indicated as 1 by the bitmap.

[0203] Bandwidth Part SizeConfiguration 1Configuration 21-362437-724873-144816145-2751616

[0204] If the terminal is configured to use only resource type 1 through upper layer signaling (7-05), some DCIs that assign PDSCH to the terminal are It includes frequency axis resource allocation information consisting of bits. The conditions for this will be explained later. Through this, the base station can set the starting VRB (7-20) and the length (7-25) of the frequency axis resources continuously allocated therefrom.

[0205] If the terminal is configured to use both resource type 0 and resource type 1 through upper layer signaling (7-10), some DCIs that allocate PDSCH to the terminal include frequency axis resource allocation information consisting of bits of the larger value (7-35) of the payload (7-15) for setting resource type 0 and the payload (7-20, 7-25) for setting resource type 1. The conditions for this will be explained later. At this time, one bit may be added to the beginning part (MSB) of the frequency axis resource allocation information within the DCI, and if the bit has a value of '0', it indicates that resource type 0 is used, and if it has a value of '1', it indicates that resource type 1 is used.

[0206] [PDSCH / PUSCH: Time Resource Allocation]

[0207] The following describes a time-domain resource allocation method for data channels in next-generation mobile communication systems (5G or NR systems).

[0208] The base station may set a table for time-domain resource allocation information for the Physical Downlink Shared Channel (PDSCH) and the Physical Uplink Shared Channel (PUSCH) for the terminal using upper-layer signaling (e.g., RRC signaling). For PDSCH, a table consisting of a maximum of maxNrofDL-Allocations = 16 entries may be set, and for PUSCH, a table consisting of a maximum of maxNrofUL-Allocations = 16 entries may be set. In one embodiment, the time domain resource allocation information may include PDCCH-to-PDSCH slot timing (corresponding to a slot-unit time interval between the time when the PDCCH is received and the time when the PDSCH scheduled by the received PDCCH is transmitted, denoted as K0), PDCCH-to-PUSCH slot timing (corresponding to a slot-unit time interval between the time when the PDCCH is received and the time when the PUSCH scheduled by the received PDCCH is transmitted, denoted as K2), information on the position and length of the start symbol for which the PDSCH or PUSCH is scheduled within the slot, and the mapping type of the PDSCH or PUSCH. For example, information such as [Table 18] or [Table 19] below may be transmitted from the base station to the terminal.

[0209] PDSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofDL-Allocations)) OF PDSCH-TimeDomainResourceAllocationPDSCH-TimeDomainResourceAllocation ::= SEQUENCE {k0 INTEGER(0..32) OPTIONAL, -- Need S(PDCCH-to-PDSCH timing, slots)mappingType ENUMERATED {typeA, typeB},(PDSCH mapping type)startSymbolAndLength INTEGER (0..127)(start symbol and length of PDSCH)}

[0210] PUSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofUL-Allocations)) OF PUSCH-TimeDomainResourceAllocationPUSCH-TimeDomainResourceAllocation ::= SEQUENCE {k2 INTEGER(0..32) OPTIONAL, -- Need S(PDCCH-to-PUSCH timing, slots)mappingType ENUMERATED {typeA, typeB},(PUSCH mapping type)startSymbolAndLength INTEGER (0..127)(start symbol and length of PUSCH)}

[0211] The base station may notify the terminal of one of the entries in the table for the time domain resource allocation information described above via L1 signaling (e.g., DCI) (e.g., indicated by the 'time domain resource allocation' field within the DCI). The terminal may obtain time domain resource allocation information for PDSCH or PUSCH based on the DCI received from the base station.

[0212] FIG. 8 is a diagram illustrating an example of time axis resource allocation of PDSCH in a wireless communication system according to one embodiment of the present disclosure.

[0213] Referring to FIG. 8, the base station uses the upper layer to set the subcarrier spacing (SCS) (μ) of the data channel and control channel. PDSCH , μ PDCCH The time axis position of the PDSCH resource can be indicated according to the scheduling offset (K0) value, and the OFDM symbol start position (8-00) and length (8-05) within a slot that are dynamically indicated through DCI.

[0214] FIG. 9 is a diagram illustrating an example of time-axis resource allocation according to the subcarrier interval of a data channel and a control channel in a wireless communication system according to one embodiment of the present disclosure.

[0215] Referring to FIG. 9, when the subcarrier spacing of the data channel and the control channel is the same (9-00, μ PDSCH = μ PDCCH ), since the slot numbers for data and control are the same, the base station and the terminal can generate a scheduling offset by aligning with a predetermined slot offset K0. On the other hand, when the subcarrier spacing of the data channel and the control channel is different (9-05, μ PDSCH ≠ μ PDCCH Since the slot numbers for data and control are different, the base station and the terminal can generate a scheduling offset based on the subcarrier interval of the PDCCH and in accordance with a predetermined slot offset K0.

[0216] [PUSCH: Regarding transmission method]

[0217] Next, the scheduling method for PUSCH transfers is described. PUSCH transfers can be dynamically scheduled by UL grants within the DCI, or operated by configured grant Type 1 or Type 2. Dynamic scheduling instructions for PUSCH transfers can be provided in DCI format 0_0 or 0_1.

[0218] Configured grant Type 1 PUSCH transmissions can be semi-statically configured by receiving configuredGrantConfig, which includes rrc-ConfiguredUplinkGrant of [Table 20], through the upper signaling, without receiving UL grants within the DCI. Configured grant Type 2 PUSCH transmissions can be semi-continuously scheduled by UL grants within the DCI after receiving configuredGrantConfig, which does not include rrc-ConfiguredUplinkGrant of [Table 20], through the upper signaling. When a PUSCH transmission is operated by a configured grant, the parameters applied to the PUSCH transmission are applied through configuredGrantConfig, the upper signaling of [Table 20], with the exception of dataScramblingIdentityPUSCH, txConfig, codebookSubset, maxRank, and scaling of UCI-OnPUSCH, which are provided by pusch-Config, the upper signaling of [Table 21]. If the terminal is provided with transformPrecoder in configuredGrantConfig, which is the upper signaling of [Table 20], the terminal applies tp-pi2BPSK in pusch-Config of [Table 21] to PUSCH transmissions operated by the configured grant.

[0219] ConfiguredGrantConfig ::= SEQUENCE {frequencyHopping ENUMERATED {intraSlot, interSlot} OPTIONAL, -- Need S,cg-DMRS-Configuration DMRS-UplinkConfig,mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Smcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Suci-OnPUSCH SetupRelease { CG-UCI-OnPUSCH} OPTIONAL, -- Need MresourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},rbg-Size ENUMERATED {config2} OPTIONAL, -- Need SpowerControlLoopToUse ENUMERATED {n0, n1},p0-PUSCH-Alpha P0-PUSCH-AlphaSetId,transformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need SnrofHARQ-Processes INTEGER(1..16),repK ENUMERATED {n1, n2, n4, n8},repK-RV ENUMERATED {s1-0231, s2-0303, s3-0000} OPTIONAL, -- Need Rperiodicity ENUMERATED {sym2, sym7, sym1x14, sym2x14, sym4x14, sym5x14, sym8x14, sym10x14, sym16x14, sym20x14,sym32x14, sym40x14, sym64x14, sym80x14, sym128x14, sym160x14, sym256x14, sym320x14, sym512x14,sym640x14, sym1024x14, sym1280x14, sym2560x14, sym5120x14,sym6, sym1x12, sym2x12, sym4x12, sym5x12, sym8x12, sym10x12, sym16x12, sym20x12, sym32x12,sym40x12, sym64x12, sym80x12, sym128x12, sym160x12, sym256x12, sym320x12, sym512x12, sym640x12,sym1280x12, sym2560x12},configuredGrantTimer INTEGER (1..64) OPTIONAL, -- Need Rrrc-ConfiguredUplinkGrant SEQUENCE {timeDomainOffset INTEGER (0..5119),timeDomainAllocation INTEGER (0..15),frequencyDomainAllocation BIT STRING (SIZE(18)),antennaPort INTEGER (0..31),dmrs-SeqInitialization INTEGER (0..1) OPTIONAL, -- Need RprecodingAndNumberOfLayers INTEGER (0..63),srs-ResourceIndicator INTEGER (0..15) OPTIONAL, -- Need RmcsAndTBS INTEGER (0..31),frequencyHoppingOffset INTEGER (1.. maxNrofPhysicalResourceBlocks-1) OPTIONAL, -- Need RpathlossReferenceIndex INTEGER (0..maxNrofPUSCH-PathlossReferenceRSs-1),...} OPTIONAL, -- Need R...}.

[0220] Next, the PUSCH transmission method is described. The DMRS antenna port for PUSCH transmission is the same as the antenna port for SRS transmission. PUSCH transmission can follow a codebook-based transmission method and a non-codebook-based transmission method, respectively, depending on whether the value of txConfig in pusch-Config in [Table 21], the upper signaling, is 'codebook' or 'nonCodebook'.

[0221] As described above, PUSCH transmissions can be dynamically scheduled via DCI format 0_0 or 0_1 and semi-statically configured by a configured grant. If a terminal is instructed to schedule a PUSCH transmission via DCI format 0_0, the terminal performs beam configuration for the PUSCH transmission using the pucch-spatialRelationInfoID corresponding to the terminal-specific PUCCH resource corresponding to the minimum ID within the active uplink BWP in the serving cell, wherein the PUSCH transmission is based on a single antenna port. The terminal does not expect scheduling for a PUSCH transmission via DCI format 0_0 within a BWP where the PUCCH resource containing pucch-spatialRelationInfo is not configured. If the terminal has not been configured with txConfig in pusch-Config of [Table 21], the terminal does not expect to be scheduled via DCI format 0_1.

[0222] PUSCH-Config ::= SEQUENCE {dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need StxConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need Sdmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig} OPTIONAL, -- Need Mdmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig} OPTIONAL, -- Need Mpusch-PowerControl PUSCH-PowerControl OPTIONAL, -- Need MfrequencyHopping ENUMERATED {intraSlot, interSlot} OPTIONAL, -- Need SfrequencyHoppingOffsetLists SEQUENCE (SIZE (1..4)) OF INTEGER (1..maxNrofPhysicalResourceBlocks-1)OPTIONAL, -- Need MresourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList} OPTIONAL, -- Need Mpusch-AggregationFactor ENUMERATED { n2, n4, n8} OPTIONAL, -- Need Smcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Smcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need StransformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need ScodebookSubset ENUMERATED {fullyAndPartialAndNonCoherent, partialAndNonCoherent,nonCoherent}OPTIONAL, -- Cond codebookBasedmaxRank INTEGER (1..4) OPTIONAL, -- Cond codebookBasedrbg-Size ENUMERATED { config2} OPTIONAL, -- Need Suci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need Mtp-pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need S...}.

[0223] Next, codebook-based PUSCH transmission is described. Codebook-based PUSCH transmission can be dynamically scheduled via DCI format 0_0 or 0_1 and can operate semi-statically via a configured grant. When codebook-based PUSCH is dynamically scheduled via DCI format 0_1 ​​or semi-statically configured via a configured grant, the terminal determines a precoder for PUSCH transmission based on the SRS Resource Indicator (SRI), Transmission Precoding Matrix Indicator (TPMI), and the transmission rank (number of PUSCH transmission layers).

[0224] In this case, the SRI can be provided via the SRS resource indicator field within the DCI or configured via the higher-level signaling srs-ResourceIndicator. During codebook-based PUSCH transmission, the terminal receives at least one SRS resource and can receive up to two. When the terminal receives an SRI via the DCI, the SRS resource indicated by that SRI refers to the SRS resource corresponding to the SRI among the SRS resources transmitted prior to the PDCCH containing that SRI. Additionally, the TPMI and transmission rank can be provided via the precoding information and number of layers field within the DCI or configured via the higher-level signaling precodingAndNumberOfLayers. The TPMI is used to indicate the precoder applied to the PUSCH transmission. If the terminal receives one SRS resource, the TPMI is used to indicate the precoder to be applied from that one configured SRS resource. If the terminal is configured with multiple SRS resources, TPMI is used to specify the precoder to be applied to the SRS resource indicated by SRI.

[0225] The precoder to be used for PUSCH transmission is selected from an uplink codebook having the same number of antenna ports as the nrofSRS-Ports value in the upper signaling SRS-Config. In codebook-based PUSCH transmission, the terminal determines the codebook subset based on TPMI and the codebookSubset in the upper signaling pusch-Config. The codebookSubset in the upper signaling pusch-Config can be set to one of 'fullyAndPartialAndNonCoherent', 'partialAndNonCoherent', or 'nonCoherent' based on the UE capability reported by the terminal to the base station. If the terminal reports 'partialAndNonCoherent' as the UE capability, the terminal does not expect the value of the upper signaling codebookSubset to be set to 'fullyAndPartialAndNonCoherent'. Additionally, if the terminal reports 'nonCoherent' as a UE capability, the terminal does not expect the value of the parent signaling codebookSubset to be set to 'fullyAndPartialAndNonCoherent' or 'partialAndNonCoherent'. If nrofSRS-Ports in the parent signaling SRS-ResourceSet points to two SRS antenna ports, the terminal does not expect the value of the parent signaling codebookSubset to be set to 'partialAndNonCoherent'.

[0226] A terminal may receive one SRS resource set in which the value of usage in the upper signaling SRS-ResourceSet is set to 'codebook', and one SRS resource within that SRS resource set may be indicated via SRI. If multiple SRS resources are set in the SRS resource set in which the value of usage in the upper signaling SRS-ResourceSet is set to 'codebook', the terminal expects that the value of nrofSRS-Ports in the upper signaling SRS-Resource will be set to the same value for all SRS resources.

[0227] The terminal transmits one or more SRS resources included in an SRS resource set in which the usage value is set to 'codebook' according to the upper signaling to the base station, and the base station selects one of the SRS resources transmitted by the terminal and instructs the terminal to perform PUSCH transmission using the transmit beam information of the corresponding SRS resource. In this case, in codebook-based PUSCH transmission, SRI is used as information to select the index of one SRS resource and is included in the DCI. Additionally, the base station includes information in the DCI that instructs the TPMI and rank to be used by the terminal for PUSCH transmission. The terminal performs PUSCH transmission using the SRS resource instructed by the SRI, by applying the instructed rank and the precoder instructed by the TPMI based on the transmit beam of the corresponding SRS resource.

[0228] Next, non-codebook-based PUSCH transmission is described. Non-codebook-based PUSCH transmission can be dynamically scheduled via DCI format 0_0 or 0_1 and can operate semi-statically via configured grant. If at least one SRS resource is configured within an SRS resource set in which the value of usage within the upper signaling SRS-ResourceSet is set to 'nonCodebook', the terminal can receive a non-codebook-based PUSCH transmission via DCI format 0_1.

[0229] For an SRS resource set in which the value of usage within the upper signaling SRS-ResourceSet is set to 'nonCodebook', the terminal can receive one connected NZP CSI-RS resource (non-zero power CSI-RS). The terminal can perform calculations for a precoder for SRS transmission by measuring the NZP CSI-RS resource connected to the SRS resource set. If the difference between the last received symbol of the aperiodic NZP CSI-RS resource connected to the SRS resource set and the first symbol of the aperiodic SRS transmission at the terminal is less than 42 symbols, the terminal does not expect the information for the precoder for SRS transmission to be updated.

[0230] If the value of resourceType in the upper signaling SRS-ResourceSet is set to 'aperiodic', the connected NZP CSI-RS is indicated by the SRS request field in DCI format 0_1 ​​or 1_1. In this case, if the connected NZP CSI-RS resource is an aperiodic NZP CSI-RS resource, the existence of the connected NZP CSI-RS is indicated if the value of the SRS request field in DCI format 0_1 ​​or 1_1 is not '00'. In this case, the corresponding DCI must not indicate cross-carrier or cross-BWP scheduling. Additionally, if the value of the SRS request indicates the existence of the NZP CSI-RS, the NZP CSI-RS is located in the slot where the PDCCH containing the SRS request field was transmitted. In this case, the TCI states set on the scheduled subcarrier are not set to QCL-TypeD.

[0231] If a periodic or semi-persistent SRS resource set is established, the associated NZP CSI-RS can be indicated via the associated CSI-RS within the parent signaling SRS-ResourceSet. For non-codebook-based transmissions, the terminal does not expect the parent signaling spatialRelationInfo for the SRS resource and the associated CSI-RS within the parent signaling SRS-ResourceSet to be established together.

[0232] When a terminal is configured with multiple SRS resources, it can determine the precoder and transmission rank to be applied to PUSCH transmission based on the SRI indicated by the base station. In this case, the SRI can be indicated via the field SRS resource indicator within the DCI or configured via the higher-level signaling srs-ResourceIndicator. Similar to the codebook-based PUSCH transmission described above, when the terminal receives the SRI via the DCI, the SRS resource indicated by the SRI refers to the SRS resource corresponding to the SRI among the SRS resources transmitted prior to the PDCCH containing the SRI. The terminal may use one or multiple SRS resources for SRS transmission, and the maximum number of SRS resources that can be transmitted simultaneously within the same symbol in a single SRS resource set, as well as the maximum number of SRS resources, are determined by the UE capability reported by the terminal to the base station. In this case, the SRS resources transmitted simultaneously by the terminal occupy the same RB. The terminal configures one SRS port for each SRS resource. Only one SRS resource set can be configured with the value of usage in the upper signaling SRS-ResourceSet set set to 'nonCodebook', and up to four SRS resources can be configured for non-codebook-based PUSCH transmission.

[0233] The base station transmits one NZP-CSI-RS associated with an SRS resource set to the terminal, and the terminal calculates a precoder to be used when transmitting one or more SRS resources within the SRS resource set based on the results measured upon receiving the NZP-CSI-RS. When the terminal transmits one or more SRS resources within an SRS resource set where usage is set to 'nonCodebook' to the base station, it applies the calculated precoder, and the base station selects one or more SRS resources from among the received one or more SRS resources. At this time, in non-codebook-based PUSCH transmission, the SRI represents an index capable of expressing a combination of one or more SRS resources, and the SRI is included within the DCI. At this time, the number of SRS resources indicated by the SRI transmitted by the base station may be the number of transmission layers of the PUSCH, and the terminal transmits the PUSCH by applying the precoder applied for SRS resource transmission to each layer.

[0234] [PUSCH: Preparation Process Time]

[0235] Next, the PUSCH preparation procedure time is described. When a base station schedules a terminal to transmit a PUSCH using DCI format 0_0, 0_1, or 0_2, the terminal may require PUSCH preparation procedure time to transmit the PUSCH by applying the transmission method specified through the DCI (transmission precoding method of the SRS resource, number of transmission layers, spatial domain transmission filter). In NR, the PUSCH preparation procedure time has been defined taking this into account. The terminal's PUSCH preparation procedure time may follow [Equation 2] below.

[0236] [Mathematical Formula 2]

[0237] T proc,2 = max(( N2+ d 2,1 + d2)( 2048 + 144 ) κ2 -μ T c + T ext + T switch , d 2,2 )

[0238] T mentioned above using mathematical formula 2 proc,2 In this, each variable can have the following meanings.

[0239] - N2: A number of symbols determined by the terminal processing capability (UE processing capability) 1 or 2 and the numerology μ according to the terminal's capability. If the terminal processing capability is reported as 1 according to the terminal's capability report, it has the value of [Table 22], and if the terminal processing capability is reported as 2 and the ability to use terminal processing capability 2 is set through upper layer signaling, it may have the value of [Table 23].

[0240] μPUSCH preparation timer N2[symbols]010112223336

[0241] μPUSCH preparation timer N2[symbols]0515.5211 for frequency range 1

[0242] - d 2,1 : The number of symbols determined as 0 if the resource elements of the first OFDM symbol of the PUSCH transmission are all configured to consist only of DM-RS, and 1 otherwise.

[0243] - κ: 64

[0244] - μ: μ DL or μ UL Middle, T proc,2 It follows the value that becomes larger. μ DL represents the numerology of the downlink through which a PDCCH containing a DCI scheduling PUSCH is transmitted, and μ UL represents the numerology of the uplink through which PUSCH is transmitted.

[0245] - T c : 1 / (Δf max *N f ), Δf max = 480*10 3 Hz, N f It has =4096.

[0246] - d 2,2 : If the DCI scheduling PUSCH directs BWP switching, follow the BWP switching time; otherwise, have 0.

[0247] - d2: If the OFDM symbols of PUCCH, PUSCH with a higher priority index, and PUCCH with a lower priority index overlap in time, the d2 value of PUSCH with the higher priority index is used. Otherwise, d2 is 0.

[0248] - T ext : If the terminal uses a shared spectrum channel access method, the terminal is T extIt can be calculated and applied to the PUSCH preparation process time. Otherwise, T ext is assumed to be 0.

[0249] - T switch : T when the uplink switching interval is triggered switch is assumed to be the switching interval time. Otherwise, it is assumed to be 0.

[0250] When the base station and terminal consider the time-axis resource mapping information of the PUSCH scheduled via DCI and the influence of uplink-downlink timing advance, from the last symbol of the PDCCH including the DCI that scheduled the PUSCH, T proc,2 Subsequently, if the first symbol of the PUSCH starts before the first uplink symbol initiated by the CP, it is determined that the PUSCH preparation time is insufficient. Otherwise, the base station and the terminal determine that the PUSCH preparation time is sufficient. The terminal transmits the PUSCH only when the preparation time is sufficient, and may ignore the DCI scheduling the PUSCH if the preparation time is insufficient.

[0251] [CA / DC Related]

[0252] FIG. 10 is a diagram illustrating the wireless protocol structure of a base station and a terminal in a single cell, carrier aggregation, dual connectivity situation in a wireless communication system according to one embodiment of the present disclosure.

[0253] Referring to FIG. 10, the wireless protocol of the next-generation mobile communication system consists of NR SDAP (Service Data Adaptation Protocol S25, S70), NR PDCP (Packet Data Convergence Protocol S30, S65), NR RLC (Radio Link Control S35, S60), and NR MAC (Medium Access Control S40, S55) at the terminal and the NR base station, respectively.

[0254] The main functions of NR SDAP (S25, S70) may include some of the following functions.

[0255] - User data transfer function (transfer of user plane data)

[0256] - Mapping function between a QoS flow and a DRB for both DL and UL for uplink and downlink

[0257] - Marking QoS flow ID for uplink and downlink (marking QoS flow ID in both DL and UL packets)

[0258] - Function to map reflective QoS flow to data bearers for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).

[0259] Regarding the SDAP layer device, the terminal may receive a setting via an RRC message indicating whether to use the header of the SDAP layer device or the functions of the SDAP layer device for each PDCP layer device, bearer, or logical channel. If the SDAP header is configured, the terminal may be instructed to update or reset the mapping information for the uplink and downlink QoS flows and data bearers to the NAS reflective QoS and AS reflective QoS 1-bit indicators of the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used for data processing priorities, scheduling information, etc., to support smooth service.

[0260] The main functions of NR PDCP (S30, S65) may include some of the following functions.

[0261] - Header compression and decompression features (ROHC only)

[0262] - User data transfer function (Transfer of user data)

[0263] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0264] - Out-of-sequence delivery of upper layer PDUs

[0265] - Reordering function (PDCP PDU reordering for reception)

[0266] - Duplicate detection function (Duplicate detection of lower layer SDUs)

[0267] - Retransmission of PDCP SDUs

[0268] - Encryption and decryption functions (Ciphering and deciphering)

[0269] - Timer-based SDU discard in uplink.

[0270] In the above, the reordering function of the NR PDCP device refers to a function that reorders PDCP PDUs received from a lower layer in order based on the PDCP SN (sequence number), and may include a function that transmits data to an upper layer in the reordered order. Alternatively, the reordering function of the NR PDCP device may include a function that transmits immediately without considering the order, a function that records lost PDCP PDUs by reordering, a function that reports the status of lost PDCP PDUs to the transmitting side, and a function that requests retransmission of lost PDCP PDUs.

[0271] The main functions of NR RLC(S35, S60) may include some of the following functions.

[0272] - Data transfer function (Transfer of upper layer PDUs)

[0273] - Sequential delivery function (In-sequence delivery of upper layer PDUs)

[0274] - Out-of-sequence delivery of upper layer PDUs

[0275] - ARQ function (Error Correction through ARQ)

[0276] - Concatenation, segmentation, and reassembly functions of RLC SDUs

[0277] - Re-segmentation function (Re-segmentation of RLC data PDUs)

[0278] - Reordering function (Reordering of RLC data PDUs)

[0279] - Duplicate detection

[0280] - Error detection function (Protocol error detection)

[0281] - RLC SDU discard function

[0282] RLC re-establishment function

[0283] In the above, the in-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from a lower layer to an upper layer in order. The in-sequence delivery function of the NR RLC device may include a function of reassembling and delivering the RLC SDUs when the original RLC SDU is received divided into multiple RLC SDUs, a function of rearranging the received RLC PDUs based on an RLC SN (sequence number) or PDCP SN (sequence number), a function of recording lost RLC PDUs by rearranging the order, a function of reporting the status of lost RLC PDUs to the transmitting side, and a function of requesting retransmission of lost RLC PDUs. The in-sequence delivery function of the NR RLC device may include a function to deliver only the RLC SDUs prior to the lost RLC SDU in order to the upper layer if there is a lost RLC SDU, or a function to deliver all RLC SDUs received before the timer started in order to the upper layer if a predetermined timer has expired even if there is a lost RLC SDU. Alternatively, the in-sequence delivery function of the NR RLC device may include a function to deliver all RLC SDUs received up to the present in order to the upper layer if a predetermined timer has expired even if there is a lost RLC SDU.In addition, the RLC PDUs described above may be processed in the order they are received (regardless of the order of sequence numbers, in the order of arrival) and delivered to the PDCP device out of order (out-of-sequence delivery). In the case of segments, segments stored in a buffer or to be received later may be received, reconstructed into a single complete RLC PDU, processed, and delivered to the PDCP device. The NR RLC layer may not include a concatenation function, and this function may be performed by the NR MAC layer or replaced by the multiplexing function of the NR MAC layer.

[0284] In the above, the out-of-sequence delivery function of the NR RLC device refers to the function of delivering RLC SDUs received from a lower layer directly to an upper layer regardless of order. It may include a function of reassembling and delivering RLC SDUs when a single RLC SDU is received divided into multiple RLC SDUs, and may include a function of storing the RLC SN or PDCP SN of the received RLC PDUs and sorting the order to record the lost RLC PDUs.

[0285] The NR MAC (S40, S55) can be connected to multiple NR RLC layer devices configured in a terminal, and the main functions of the NR MAC may include some of the following functions.

[0286] - Mapping function (Mapping between logical channels and transport channels)

[0287] - Multiplexing and demultiplexing functions (Multiplexing / demultiplexing of MAC SDUs)

[0288] - Scheduling information reporting function

[0289] - HARQ function (Error correction through HARQ)

[0290] - Priority handling between logical channels of one UE

[0291] - Priority handling between UEs by means of dynamic scheduling

[0292] - MBMS service identification function

[0293] - Transport format selection function

[0294] - Padding

[0295] The NR PHY layer (S45, S50) can perform the operation of channel coding and modulating upper layer data, creating OFDM symbols and transmitting them to the wireless channel, or demodulating OFDM symbols received through the wireless channel and channel decoding them to transmit them to the upper layer.

[0296] The detailed structure of the above wireless protocol structure may vary depending on the carrier (or cell) operation method. For example, when a base station transmits data to a terminal based on a single carrier (or cell), the base station and the terminal use a protocol structure having a single structure for each layer, as shown in S00. On the other hand, when a base station transmits data to a terminal based on Carrier Aggregation (CA) using multiple carriers in a single TRP, the base station and the terminal use a protocol structure that has a single structure up to the RLC, as shown in S10, but multiplexes the PHY layer through the MAC layer. As another example, when a base station transmits data to a terminal based on Dual Connectivity (DC) using multiple carriers in multiple TRPs, the base station and the terminal use a protocol structure that has a single structure up to the RLC, as shown in S20, but multiplexes the PHY layer through the MAC layer.

[0297] Referring to the descriptions regarding PDCCH and beam settings mentioned above, current Rel-15 and Rel-16 NR do not support repeated PDCCH transmission, making it difficult to achieve the required reliability in scenarios requiring high reliability, such as URLLC. The present invention provides a method for repeated PDCCH transmission through multiple transmission points (TRPs) to improve the PDCCH reception reliability of a terminal. The specific method is described in detail in the following examples.

[0298] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The contents of the present disclosure are applicable to FDD and TDD systems. In the present disclosure, upper signaling (or upper layer signaling) is a signal transmission method transmitted from a base station to a terminal using a physical layer downlink data channel, or from a terminal to a base station using a physical layer uplink data channel, and may be referred to as RRC signaling, PDCP signaling, or a MAC (medium access control) control element (MAC CE).

[0299] In the present disclosure, when determining whether cooperative communication is applied, the terminal may use various methods, such as the PDCCH(s) that allocate the PDSCH to which cooperative communication is applied having a specific format, or the PDCCH(s) that allocate the PDSCH to which cooperative communication is applied including a specific indicator indicating whether cooperative communication is applied, or the PDCCH(s) that allocate the PDSCH to which cooperative communication is applied being scrambled with a specific RNTI, or assuming the application of cooperative communication in a specific section indicated to an upper layer. For convenience of explanation thereafter, the case in which the terminal receives a PDSCH to which cooperative communication is applied based on conditions similar to those above will be referred to as the NC-JT case.

[0300] In the following disclosure, determining the priority between A and B may be referred to in various ways, such as selecting the one with the higher priority according to a predetermined priority rule and performing the corresponding action, or omitting or dropping the action for the one with the lower priority.

[0301] In the following disclosure, the examples are described through a number of embodiments, but these are not independent, and one or more embodiments may be applied simultaneously or in combination.

[0302] Embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. Hereinafter, a base station is an entity that performs resource allocation for terminals and may be at least one of a gNode B, gNB, eNode B, Node B, BS (Base Station), wireless access unit, base station controller, or a node on a network. A terminal may include a UE (User Equipment), MS (Mobile Station), cellular phone, smartphone, computer, or a multimedia system capable of performing communication functions. Although embodiments of the present disclosure are described below using a 5G system as an example, embodiments of the present disclosure may be applied to other communication systems having similar technical backgrounds or channel types. For example, LTE or LTE-A mobile communication and mobile communication technologies developed after 5G may be included therein. Accordingly, embodiments of the present disclosure may be applied to other communication systems with some modifications without significantly departing from the scope of the present disclosure, as judged by a person skilled in the art. The contents of the present disclosure are applicable to FDD and TDD systems.

[0303] Furthermore, in describing the present disclosure, if it is determined that a detailed description of related functions or configurations could unnecessarily obscure the essence of the present disclosure, such detailed description is omitted. Additionally, the terms described below are defined in consideration of their functions within the present disclosure, and these definitions may vary depending on the intentions or practices of the user or operator. Therefore, their definitions should be based on the content throughout this specification.

[0304] In describing the present disclosure below, the term "upper layer signaling" may refer to a signaling corresponding to at least one or a combination of at least one of the following signalings.

[0305] - MIB (Master Information Block)

[0306] - SIB (System Information Block) or SIB

[0307] - RRC (Radio Resource Control)

[0308] - MAC (Medium Access Control) CE (Control Element)

[0309] In addition, L1 signaling may be a signaling corresponding to at least one or a combination of at least one of the following physical layer channels or signaling methods using signaling.

[0310] - PDCCH (Physical Downlink Control Channel)

[0311] - DCI (Downlink Control Information)

[0312] - Terminal-specific (UE-specific) DCI

[0313] - Group common DCI

[0314] - Common DCI

[0315] - Scheduling DCI (e.g., DCI used for the purpose of scheduling downlink or uplink data)

[0316] - Non-scheduling DCI (e.g., DCI not intended for scheduling downlink or uplink data)

[0317] - PUCCH (Physical Uplink Control Channel)

[0318] - UCI (Uplink Control Information)

[0319] In the following disclosure, determining the priority between A and B may be referred to in various ways, such as selecting the one with the higher priority according to a predetermined priority rule and performing the corresponding action, or omitting or dropping the action for the one with the lower priority.

[0320] In the following disclosure, the examples are described through a number of embodiments, but these are not independent, and one or more embodiments may be applied simultaneously or in combination.

[0321] [UCI Multiplexing]

[0322] The terminal can transmit uplink control information (UCI) to a physical uplink control channel (PUCCH) and / or a physical uplink shared channel (PUSCH). Herein, the uplink control information may include at least one of the following information elements.

[0323] - HARQ-ACK (hybrid automatic repeat request-acknowledgement) information: Can indicate whether the reception of PDSCH or PDCCH was successful.

[0324] - CSI: Information on CSI-RS and / or SSB (SS / PBCH block) measurements, which may include CQI (channel quality indicator), RI (rank indicator), PMI (precoder matrix indicator), RSSI (received signal strength indicator), or RSRP (reference signal received power).

[0325] - CG-UCI (configured grant UCI) information: Information associated with CG PUSCH, which may include, for example, the HARQ process number of the CG PUSCH being transmitted.

[0326] - UTO-UCI (unused transmission occasion(s) inciated by UCI) information: May include information about CG PUSCH occasions that will not be used for actual transmission among subsequent CG PUSCH occasions.

[0327] The types of uplink control information described above are merely examples, and other types of UCI may be included. Additionally, the uplink control information described above may be subdivided and considered as different types. Furthermore, the same type of UCI with different priorities may be considered as different types of UCI. For example, HARQ-ACK information with a lower priority and HARQ-ACK information with a higher priority may be considered as different types of UCI. For convenience in this disclosure, UCI types may be expressed as UCI type 1, UCI type 2, ...

[0328] When a terminal transmits a UCI over a PUSCH, the PUSCH may include an UL-SCH (uplink shared channel). Here, the UL-SCH may generally contain data transmitted by the terminal to a base station. Specifically, the UL-SCH may contain data composed of multiple bits transmitted from the upper layer of the terminal to the physical layer of the terminal. The terminal may transmit the UL-SCH to the base station via the PUSCH. The physical layer of the base station may acquire the UL-SCH by receiving the PUSCH and transmit the UL-SCH to the upper layer of the base station. The multiple bits constituting the UL-SCH at the physical layer may be referred to as a transport block (TB).

[0329] In the present disclosure, unless specifically mentioned, PUSCH may include UL-SCH (or TB) and / or UCI.

[0330] FIG. 11 is a flowchart illustrating a method of transmitting UL-SCH and UCI through PUSCH in a wireless communication system according to one embodiment of the present disclosure.

[0331] TB generation and TB CRC attachment block: The terminal receives an UL-SCH from an upper layer and can generate a TB based on the bits included in the UL-SCH. Here, the length of the TB (the number of bits included) can be determined based on the scheduling information of the PUSCH. The terminal may include a cyclic redundancy code (CRC) in the TB. The terminal may refer to the CRC as TB-CRC. When the base station receives the PUSCH, it can determine whether the TB has been correctly decoded based on the TB-CRC. The length of the TB-CRC may be 24 bits.

[0332] Here, the PUSCH scheduling information used to determine the TB length includes the Modulation and Coding Scheme (MCS), Time Domain Resource Assignment (TDRA), Frequency Domain Resource Assignment (FDRA), and DMRS configuration information, antenna port (AP) related information, and overhead related information (X oh At least one or a plurality of ) may be used.

[0333] Code block segmentation and code block CRC attachment block: TB and TB-CRC can be divided into one or more code blocks (CB). Here, the number of bits contained in each CB can be the same. A CB-CRC can be attached to each CB. Here, when the base station decodes PUSCH, the CB-CRC can be used to determine whether the corresponding CB has been correctly decoded.

[0334] UL-SCH Channel Coding Block: Each CB and CB-CRC can be encoded according to channel coding. For example, the CB and CB-CRC can be encoded using LDPC channel coding.

[0335] UL-SCH Rate Matching Block: Rate matching can be performed on encoded CBs and CB-CRCs based on the number of resources through which UL-SCH can be transmitted in PUSCH. That is, among the encoded CBs and CB-CRCs, the bits to be transmitted in PUSCH can be determined. Here, the resources through which UL-SCH can be transmitted in PUSCH may be resources excluding those transmitted to UCI. Therefore, the result of the Rate Matching Block may vary depending on the number of resources occupied by UCI included in PUSCH.

[0336] Codeblock concatenation block: If multiple CBs are generated, the encoded bits (number determined in the rate matching block) corresponding to each CB and CB-CRC can be composed of a single bit stream. For example, if two CBs are generated, the encoded bits corresponding to the 0th CB and CB-CRC are {C 0,0 , C 0,1 , ... , C 0,M-1}, encoded bits corresponding to the first CB and CB-CRC {C 1,0 , C 1,1 , ... , C 1,M-1 When saying}, {C 0,0 , C 0,1 , ... , C 0,M-1 ,C 1,0 , C 1,1 , ... , C 1,M-1} can be generated.

[0337] UCI bit generation block: The terminal can generate UCI bits to be included in PUSCH according to the instructions of the base station. Although only a single type of UCI is assumed in this drawing, the UCI may include one or more types.

[0338] Code block segmentation and CRC attachment block: If the UCI bits exceed a certain size, the terminal can divide the UCI into multiple UCI code blocks and attach a CRC to each UCI code block.

[0339] UCI Channel Coding Block: The UCI codebook and CRC can be encoded according to channel coding. For example, the UCI codebook and CRC can be encoded using Polar channel coding. UCI Rate Matching Block: The number of resources transmitted over PUSCH using the encoded UCI codeblock and CRC can be determined. Specifically, the terminal [uses] a beta offset value corresponding to the UCI type ( ) (relative coding rate of UCI compared to the coding rate of UL-SCH in PUSCH) and alpha value( ) (the maximum ratio of resources included in PUSCH that can be used for UCI) can be set, and the number of resources transmitted in PUSCH can be determined based on the above value. For example, if the type of UCI is HARQ-ACK, the number of resources (number of modulation symbols per MIMO layer) can be determined by Equation 3.

[0340] [Mathematical Formula 3]

[0341]

[0342] Here, is the number of HARQ-ACK bits, is the number of CRC bits, and is the beta offset value for HARQ-ACK (the encoding rate of HARQ-ACK relative to the encoding rate of UL-SCH in PUSCH), and is the number of CBs included in PUSCH, and is the number of bits included in the CB, and represents the number of REs that can be used for UCI transmission in OFDM symbol l, and is the alpha value (the maximum proportion of resources included in PUSCH that can be used for HARQ-ACK), is the number of symbols included in PUSCH, and is the index of the OFDM symbol that does not contain a DMRS after the first DMRS.

[0343] Similarly, if the UCI type is CSI part 1 and CSI part 2, the number of resources ( , ) (number of modulation symbols per MIMO layer) can be determined by Equation 4.

[0344] [Mathematical Formula 4]

[0345]

[0346]

[0347] Here, When deciding, is the beta offset value corresponding to CSI part 1 (the encoding rate of CSI part 1 relative to the encoding rate of PUSCH's UL-SCH), and When deciding, may be a beta offset value corresponding to CSI part 2 (the encoding rate of CSI part 2 relative to the encoding rate of UL-SCH of PUSCH).

[0348] Referring to mathematical formulas 3 and 4, the beta offset can be used for the following purposes.

[0349] The beta offset is used to determine the code rate of the UCI and represents the relative value of the UCI code rate to the code rate of the PUSCH UL-SCH. More specifically, the code rate of the PUSCH UL-SCH can be expressed as (UL-SCH payload size) / (number of resources transmitted by UL-SCH * modulation order * number of MIMO layers). Referring to Equations 3 and 4, the code rate of the PUSCH UL-SCH is ( It may be. The coding rate of the UCI multiplexed in PUSCH can be expressed as (UCI payload size) / (number of resources transmitted by UCI * modulation order * number of MIMO layers). If the UCI is HARQ-ACK, refer to Equation 3, It can be expressed as follows. The Beta offset is a value relative to the UL-SCH encoding rate, and It can be expressed as follows. Therefore, And, the first part of mathematical equation 3 can be derived.

[0350] The values ​​of the Beta offset of HARQ-ACK are shown in [Table 24]. Referring to [Table 24], the value of the Beta offset at index 0 is 1. Therefore, UL-SCH and UCI (HARQ-ACK) can have the same encoding rate. The Beta offset at index 11 is 20. Therefore, the encoding rate of UCI (HARQ-ACK) can be 20 times lower than the encoding rate of UL-SCH. The Beta offset at index 19 is 0.1. Therefore, the encoding rate of UCI can be 10 times higher than the encoding rate of UL-SCH.

[0351] Index 01.00012.00022.50033.12544.00055.00066.25078.000810.000912.62 51015.8751120.0001231.0001350.0001480.00015126.000160.6170.418 0.2190.1200.0521Reserved22Reserved23Reserved24Reserved25Reserved26Reserved27Reserved28Reserved29Reserved30Reserved31Reserved

[0352] Referring to mathematical formulas 3 and 4, the alpha value can be used for the following purposes.

[0353] If resources included in PUSCH are used as UCI, the reception performance of UL-SCH may degrade. Therefore, the base station can set the maximum amount of PUSCH resources that can be used as UCI for the terminal through an alpha value. For example, based on the beta-offset, the number of resources to be used for UCI (HARQ-ACK) Let's assume that. The base station can allocate the maximum number of resources available for UCI equal to the alpha ratio of the number of resources included in PUSCH. In other words, the number of maximum resources available for UCI (HARQ-ACK) is It could be. Here, can be the number of resources included in PUSCH. Therefore, (Based on beta-offset, the number of resources to be used for UCI (HARQ-ACK) The maximum number of resources that ) can use in UCI ( If it exceeds ), the terminal N resources may be used. Here, for CSI part 1 and / or CSI part 2, resources used by the UCIs mapped first may be excluded from the number of resources included by PUSCH. That is, since HARQ-ACK is mapped first in CSI part 1, the number of resources included by PUSCH It can be. Since HARQ-ACK and CSI part 1 are mapped first in CSI part 2, the number of resources included in PUSCH is It could be.

[0354] Codeblock concatenation block: If the UCI consists of multiple UCI codeblocks, each encoded UCI codeblock and CRC can be combined into a single bit stream.

[0355] Data and control multiplexing block: Encoded UCI and encoded UL-SCH can be multiplexed on PUSCH. In this case, the REs occupied by UCI on PUSCH can be determined according to the UCI-to-RE mapping method.

[0356] FIG. 12 is a diagram illustrating an example of UCI-to-RE mapping when a UCI is multiplexed on a PUSCH in a wireless communication system according to one embodiment of the present disclosure.

[0357] Referring to Fig. 12, the specific UCI-to-RE mapping method and PUSCH may be as follows.

[0358] If the HARQ-ACK bits are greater than 2 bits, UCI and UL-SCH can be mapped onto PUSCH according to the following steps.

[0359] Step 1: HARQ-ACK bits can be multiplexed on PUSCH using a first UCI-to-RE mapping method.

[0360] For example, HARQ-ACK can be mapped to available REs in OFDM symbols following the first consecutive DMRS OFDM symbol. Here, if the number of REs required for HARQ-ACK transmission is greater than the number of REs included in the OFDM symbol, all REs are used for HARQ-ACK transmission; otherwise, some of the REs included in the OFDM symbol may be used for HARQ-ACK transmission.

[0361] Step 2: CSI part 1 bits can be multiplexed on PUSCH using a second UCI-to-RE mapping method.

[0362] For example, CSI part 1 bits may start from the first available non-DMRS OFDM within the PUSCH allocation. If the number of REs for CSI part 1 transmission is greater than the REs included in the OFDM symbol, all REs may be used for CSI part 1 transmission. Otherwise, some of the REs included in the OFDM symbol may be used for CSI part 1 transmission. Here, if the OFDM symbol includes REs used for HARQ-ACK, said REs may be excluded.

[0363] Step 3: The CSI part 2 bits can be multiplexed over PUSCH using a third UCI-to-RE mapping method.

[0364] For example, CSI part 2 bits may start from the first available non-DMRS OFDM within the PUSCH allocation. If the number of REs for CSI part 2 transmission is greater than the REs included in the OFDM symbol, all REs may be used for CSI part 2 transmission. Otherwise, some of the REs included in the OFDM symbol may be used for CSI part 2 transmission. Here, if the OFDM symbol includes REs used for HARQ-ACK, said REs may be excluded. Here, if the OFDM symbol includes REs used for CSI part 1, said REs may be excluded.

[0365] Step 4: UL-SCH can be multiplexed on PUSCH.

[0366] For example, the terminal may transmit UL-SCH in REs where UL-SCH is transmittable among REs not occupied by HARQ-ACK, CSI part 1, and / or CSI part 2 on PUSCH. If UL-SCH contains multiple CBs, the terminal may transmit CBs of a preceding index in the preceding symbol. Thus, CB#0 (CB with index 0) can be mapped along the frequency axis starting from the earliest OFDM symbol; and if there are no more remaining REs in one OFDM symbol, it can be mapped along the frequency axis to the next symbol. Such a mapping method may be referred to as a 'frequency-first, time-second' mapping method.

[0367] Specific UCI-to-RE mapping methods and PUSCH generation methods can be found in Section 6.2.7 of the 3GPP standard document TS38.212.

[0368] FIG. 13 is a diagram illustrating a scenario in which a PUCCH including a UCI overlaps with a plurality of PUSCHs in a wireless communication system according to one embodiment of the present disclosure.

[0369] Referring to FIG. 13, transmission of multiple PUSCHs (1310, 1320) from multiple serving cells (or multiple carriers, or multiple UL subbands) may be scheduled to a terminal. The multiple PUSCHs may be scheduled through a single DCI, each PUSCH may be scheduled through a different DCI, or the multiple PUSCHs may include a configured grant (CG) PUSCH.

[0370] The terminal can multiplex the UCI to one of the multiple PUSCHs (1310, 1320) that overlap with the PUCCH (1300) containing the UCI, and the PUCCH (1300) may not be transmitted.

[0371] One example of a method for a terminal to select one of multiple PUSCHs is to select the PUSCH associated with the lowest index among the serving cell indices corresponding to the PUSCH. That is, the terminal identifies a serving cell index for each of the multiple PUSCHs and can use the PUSCH (1310) of the lowest index among the serving cell indices for UCI transmission.

[0372] Alternatively, a method for a terminal to select one PUSCH to multiplex the UCI among multiple PUSCHs may include the following process.

[0373] - Among multiple PUSCHs, if some PUSCHs are dynamic grant PUSCHs (where a corresponding DCI format exists) and others are configured grant PUSCHs (where a corresponding DCI format does not exist), the dynamic grant PUSCHs may take precedence over the configured grant PUSCHs.

[0374] - If there are multiple PUSCHs in the cell with the lowest index, the PUSCH that is earlier in time may take precedence over the PUSCH that is later in time.

[0375] According to at least one of the methods described above, the terminal can multiplex UCIs in a single PUSCH. However, depending on the channel conditions between the terminal and the base station, the Modulation and coding scheme (MCS) of the PUSCH, or the beta offset value of the UCI, the base station may not receive the UCI contained in the PUSCH. Consequently, a problem may occur in which the base station fails to receive HARQ-ACK information, CSI information, etc., that it is supposed to receive from the terminal.

[0376] Additionally, when a terminal multiplexes a UCI to a PUSCH, some types of UCI may be dropped without being multiplexed. This may occur depending on the size of the resources included in the PUSCH and the lengths of the MCS and UCI. More specifically, part or all of the CSI part 2 may be dropped according to the conditions defined in Table 25. Consequently, the terminal cannot transmit part or all of the CSI part 2 depending on the PUSCH selected for UCI multiplexing, and the base station cannot obtain the CSI part 2 information. Here, since the length of the CSI part 2 may vary depending on the terminal's CSI measurement results (channel rank), the base station cannot know the terminal's CSI measurement results (e.g., channel rank) in advance. As a result, there may be a limitation in that the base station cannot schedule the PUSCH to prevent the CSI part 2 from being dropped.

[0377] When UL-SCH is included in PUSCH, this If it is greater, CSI Part 2 may be dropped. Here, starting from the lowest priority of the information included in CSI Part 2, this CSI part 2 can be dropped until it is less than or equal to.

[0378] In this disclosure, methods for solving the problem of a base station being unable to receive a UCI as described above are disclosed.

[0379] In the present disclosure, a method of transmitting a UCI through a single PUSCH, a method of transmitting a UCI through a plurality of PUSCHs, and a method of retransmitting the UCI to a base station when a UCI drop occurs are proposed.

[0380] How to select a single PUSCH for UCI multiplexing

[0381] According to one embodiment of the present disclosure, a terminal can select a PUSCH that minimizes UCI transmission failure as a single PUSCH for UCI multiplexing. As described above, in the prior art, the index of a serving cell, the type of grant (whether it is a dynamic grant or a configured grant), and time-domain information of the PUSCH were used as a method for the terminal to select one of a plurality of PUSCHs. However, a single PUSCH selected according to the prior art may not match the length of the UCI, or the reliability of the PUSCH may be low. Therefore, a PUSCH selection method to solve this is proposed.

[0382] [Method 1-1] MCS-based PUSCH Selection

[0383] In one method of the present disclosure, a terminal may select one PUSCH based on a modulation and coding scheme (MCS) of a plurality of PUSCHs. Herein, the MCS may be obtained from a DCI or an upper layer signal (RRC signal) that schedules the PUSCH.

[0384] For example, a terminal can select the PUSCH with the lowest MCS among multiple PUSCHs. Here, the lowest MCS may represent the lowest modulation order, the lowest coding rate, or the lowest spectral efficiency. Therefore, the corresponding PUSCH may be the PUSCH with the highest reliability. By multiplexing the UCI to the PUSCH with the highest reliability, the terminal can transmit the UCI with the highest reliability.

[0385] For example, a terminal can select the PUSCH with the highest MCS among multiple PUSCHs. Here, the highest MCS may represent the highest modulation order, the highest coding rate, or the highest spectral efficiency. Therefore, the PUSCH may be the one transmitted in the best channel environment. Consequently, the PUSCH not only has a high probability of successful reception but may also contain multiple bits.

[0386] In the case of a retransmitted PUSCH, the MCS value obtained from the DCI can indicate only the modulation order. In this case, the terminal can use the MCS value used for the initial transmission.

[0387] If the terminal includes multiple TBs in a PUSCH, the terminal can determine which PUSCH to multiplex the UCI based on the MCS of the individual TBs. For example, the UCI may be multiplexed to a PUSCH containing a TB corresponding to the highest MCS, or multiplexed to a PUSCH containing a TB corresponding to the lowest MCS.

[0388] If a terminal includes multiple TBs in a PUSCH, the terminal can determine which PUSCH to multiplex the UCI based on the MCS of one of the TBs included in the PUSCH. For example, if a PUSCH includes multiple TBs, the highest MCS among the MCSs of the multiple TBs may be considered as the MCS corresponding to the PUSCH, or the lowest MCS may be considered as the MCS corresponding to the PUSCH. The UCI may be multiplexed to the PUSCH corresponding to the highest MCS, or multiplexed to the PUSCH corresponding to the lowest MCS.

[0389] [Method 1-2] Waveform-based PUSCH Selection

[0390] In one method of the present disclosure, a terminal may select one PUSCH based on the waveforms of a plurality of PUSCHs. Here, information regarding the waveform of the PUSCH may be obtained from a DCI or a higher-level signal (RRC signal) that schedules the PUSCH. Here, the waveform of the PUSCH may be at least one of CP-OFDM (Cyclic Prefix-Orthogonal Frequency Division Multiplexing) or DFT-s-OFDM (Discrete Fourier Transform spread-OFDM). When the terminal transmits a plurality of PUSCHs in a plurality of cells, the PUSCHs may have different waveforms. Accordingly, for example, the terminal may transmit the PUSCH using DFT-s-OFDM for wider coverage and transmit the PUSCH using CP-OFDM for a higher transmission rate.

[0391] When selecting a PUSCH to multiplex UCI, the terminal may prioritize one waveform over another. For example, to ensure UCI coverage (or reception performance), the terminal may prioritize DFT-s-OFDM. That is, among a PUSCH using DFT-s-OFDM and a PUSCH using CP-OFDM, the terminal may perform UCI multiplexing on the PUSCH using DFT-s-OFDM.

[0392] As another example, the terminal can prioritize CP-OFDM to prevent UCI drop phenomena. That is, the terminal can perform UCI multiplexing on the PUSCH using CP-OFDM between the PUSCH using DFT-s-OFDM and the PUSCH using CP-OFDM.

[0393] In the example described above, the terminal can receive information about the prioritized waveform from the base station via an upper layer signal (RRC signal) or DCI.

[0394] [Method 1-3] PUSCH selection based on the number of MIMO layers / TBs

[0395] In one method of the present disclosure, a terminal may select one PUSCH based on the number of MIMO layers or the number of TBs of a plurality of PUSCHs. For example, the number of MIMO layers of a PUSCH may be up to 8, and when the number of MIMO layers is 1, 2, 3, or 4, the PUSCH may include only 1 TB, and when the number of MIMO layers is 5, 6, 7, or 8, the PUSCH may include 2 TBs. Here, information regarding the number of MIMO layers may be obtained from a DCI or upper layer signal (RRC signal) that schedules the PUSCH.

[0396] The number of MIMO layers in PUSCH can be determined based on the channel environment between the base station and the terminal. For example, if the channel environment between the base station and the terminal is poor, the base station may instruct or configure the terminal to transmit PUSCH using only one layer. This is because reception performance can be improved by concentrating the terminal's power on a single layer. If the channel environment between the base station and the terminal is excellent, the base station may instruct or configure the terminal to transmit PUSCH using multiple layers. When multiple layers are used for PUSCH, the PUSCH can have a high transmission rate.

[0397] When selecting a PUSCH to multiplex a UCI, the terminal may select the PUSCH based on the number of layers. For example, the terminal may prioritize a lower number of layers to ensure UCI coverage (or reception performance). That is, the terminal may perform UCI multiplexing on the PUSCH with the lowest layer among multiple PUSCHs.

[0398] As another example, the terminal can prioritize the number of higher layers to prevent UCI dropouts. That is, the terminal can perform UCI multiplexing on the PUSCH of the highest layer among multiple PUSCHs.

[0399] Alternatively, when selecting a PUSCH to multiplex the UCI, the terminal may select the PUSCH based on the number of TBs. For example, the terminal may prioritize a PUSCH containing one TB to ensure UCI coverage (or reception performance). That is, the terminal may perform UCI multiplexing on a PUSCH containing one TB among multiple PUSCHs.

[0400] As another example, the terminal may prioritize a PUSCH containing multiple TBs to prevent UCI drop phenomena. That is, the terminal may perform UCI multiplexing on a PUSCH containing multiple TBs among multiple PUSCHs.

[0401] [Method 1-4] TBS-based PUSCH Selection

[0402] In one method of the present disclosure, a terminal may select one PUSCH based on the transport block size (TBS) of a plurality of PUSCHs. The TBS of a PUSCH may correspond to the length of information transmitted by the PUSCH. The TBS may be a value determined by values ​​such as the number of RBs scheduled for the PUSCH, the number of OFDM symbols, MCS, and MIMO layer. Information regarding the TBS may be obtained from the DCI or upper layer signal (RRC signal) that schedules the PUSCH.

[0403] The TBS of a PUSCH can be determined based on the channel environment between the base station and the terminal. For example, if the channel environment between the base station and the terminal is poor, the base station may instruct or configure the terminal to transmit the PUSCH using a low TBS. This is because increasing the power per information bit contained in the terminal's PUSCH can improve reception performance. If the channel environment between the base station and the terminal is excellent, the base station may instruct or configure the terminal to transmit the PUSCH using a high TBS. When transmitting the PUSCH using a high TBS, the PUSCH can have a high transmission rate.

[0404] When selecting a PUSCH to multiplex a UCI, the terminal may select the PUSCH based on TBS. For example, the terminal may select a PUSCH with a low TBS to ensure UCI coverage (or reception performance). That is, the terminal may perform UCI multiplexing on the PUSCH with the lowest TBS among multiple PUSCHs.

[0405] As another example, the terminal can prioritize a higher number of layers to prevent UCI dropouts. It can select a PUSCH with a high TBS. That is, the terminal can perform UCI multiplexing on the PUSCH with the highest TBS among multiple PUSCHs.

[0406] [Method 1-5] Priority-based PUSCH selection

[0407] In one method of the present disclosure, a terminal may select one PUSCH based on the priority of a plurality of PUSCHs. The priority of the PUSCHs may be determined at the physical layer, and a PUSCH with a higher priority may be given priority over a PUSCH with a lower priority. Additionally, for the successful transmission of a PUSCH with a higher priority, scheduling parameters (MCS, transmission power, etc.) may be determined for the PUSCH with a lower BLER.

[0408] Information regarding the physical layer priority of PUSCH may be included in the DCI scheduling PUSCH or the upper layer signal (RRC signal) setting PUSCH.

[0409] When selecting a PUSCH to multiplex the UCI, the terminal may select the PUSCH based on priority. For example, the terminal may prioritize a high-priority PUSCH to ensure UCI coverage (or reception performance). That is, the terminal may perform UCI multiplexing on the PUSCH with the highest priority among multiple PUSCHs.

[0410] As another example, the terminal can prioritize lower-priority PUSCHs to prevent UCI dropouts. That is, the terminal can perform UCI multiplexing on the PUSCH with the lowest priority among multiple PUSCHs.

[0411] Alternatively, there may be a physical layer priority corresponding to the UCI. The terminal can select a PUSCH based on the priority corresponding to the UCI and / or the priority of the PUSCH.

[0412] For example, the terminal can prioritize a PUSCH that has the same priority as the UCI. That is, the terminal can perform UCI multiplexing on the PUSCH among multiple PUSCHs that has the same priority as the UCI.

[0413] As another example, the terminal may prioritize a PUSCH that has a priority higher than or equal to the priority of the UCI. That is, the terminal may perform UCI multiplexing on a PUSCH among multiple PUSCHs that has a priority higher than or equal to the priority of the UCI. According to this example, the UCI can be multiplexed on at least a PUSCH that has a priority higher than or equal to the priority of the UCI, and thus, the UCI can have high reception performance.

[0414] As another example, the terminal may prioritize a PUSCH with a priority lower than or equal to the priority of the UCI. That is, the terminal may perform UCI multiplexing on a PUSCH among multiple PUSCHs that has a priority lower than or equal to the priority of the UCI. According to this example, the UCI can be multiplexed on at least a PUSCH with a priority lower than or equal to the priority of the UCI, and thus, the UCI can be multiplexed on a PUSCH with a high transmission volume.

[0415] [Method 1-6] Frequency Band-Based PUSCH Selection

[0416] In one method of the present disclosure, a terminal may select one PUSCH based on the frequency of a cell corresponding to a plurality of PUSCHs. For example, when a terminal transmits a plurality of PUSCHs in a plurality of cells, the PUSCHs may be transmitted from different cells. Depending on the radio wave characteristics, a PUSCH transmitted at a low frequency may have wide coverage, and a PUSCH transmitted at a high frequency may have a high transmission capacity.

[0417] When a terminal selects a PUSCH to multiplex the UCI, one PUSCH may be selected based on the corresponding frequency. For example, the terminal may select a PUSCH of a low frequency to ensure UCI coverage (or reception performance). That is, the terminal may select the PUSCH corresponding to the lowest frequency among multiple PUSCHs.

[0418] As another example, the terminal can select a high-frequency PUSCH to prevent UCI drop phenomena. That is, the terminal can select the PUSCH corresponding to the highest frequency among multiple PUSCHs.

[0419] [Method 1-7] PUSCH selection based on the number of OFDM symbols / number of RBs / number of REs

[0420] In one method of the present disclosure, a terminal may select one PUSCH based on at least one of {number of OFDM symbols, number of RBs, number of REs} scheduled for a plurality of PUSCHs or a combination thereof. For example, when the terminal transmits a plurality of PUSCHs, each of the scheduled PUSCHs may include a different number of OFDM symbols, a number of RBs, and / or a number of REs. When scheduling a PUSCH to the terminal, the base station may indicate or set the number of OFDM symbols, the number of RBs, and / or REs corresponding to the reception performance and transmission volume of the PUSCH.

[0421] When the terminal selects a PUSCH to multiplex UCI, one PUSCH may be selected based on the number of OFDM symbols, the number of RBs, and the number of REs corresponding to the PUSCH. For example, the terminal may perform UCI multiplexing on the PUSCH corresponding to the highest number of OFDM symbols, the highest number of RBs, and / or the highest number of REs among a plurality of PUSCHs.

[0422] [Method 1-8] DCI format / RNTI-based PUSCH selection

[0423] In one method of the present disclosure, a terminal may select a PUSCH based on a DCI format and / or RNTI scheduled for a plurality of PUSCHs. More specifically, the PUSCH may be scheduled for DCI format 0_0, 0_1, and / or 0_2. Here, DCI format 0_0 may be a DCI format containing basic PUSCH transmission-related DCI fields. DCI format 0_1 ​​is a non-fallback DCI and may be used for more complex PUSCH scheduling, such as Carrier Aggregation (CA) or MIMO, based on a higher layer signal (RRC signal). DCI format 0_2 may have a relatively smaller payload size than DCI format 0_1. Since DCI format 0_0 contains only basic PUSCH transmission-related DCI fields, the receive performance and transmission volume of a PUSCH scheduled for DCI format 0_0 may be lower than that of DCI format 0_1 ​​and / or 0_2.

[0424] When a terminal transmits multiple PUSCHs, the terminal may prioritize one DCI format over another DCI format. Here, the DCI format may be a DCI format that schedules the PUSCH. For example, the terminal may prioritize a PUSCH scheduled in DCI format 0_1 ​​and / or DCI format 0_2 over a PUSCH scheduled in DCI format 0_0. That is, the terminal may perform UCI multiplexing on a PUSCH scheduled in DCI format 0_1 ​​and / or DCI format 0_2.

[0425] Alternatively, the DCI format for scheduling PUSCH can be scrambled into C-RNTI, CS-RNTI, and / or MCS-C-RNTI. The DCI format scrambled into MCS-C-RNTI may use a different MCS table for higher receive performance. The DCI format scrambled into CS-RNTI can be used for CG PUSCH enable and retransmission.

[0426] When a terminal transmits multiple PUSCHs, the terminal may prioritize one RNTI over another RNTI. Here, the RNTI may be scrambled in a DCI format that schedules the PUSCH. For example, the terminal may prioritize a PUSCH scheduled by a DCI format scrambled with MCS-C-RNTI over a PUSCH scheduled by a DCI format scrambled with C-RNTI and / or CS-RNTI. That is, the terminal may perform UCI multiplexing on a PUSCH scheduled by a DCI format scrambled with MCS-C-RNTI.

[0427] [Method 1-9] A single PUSCH instruction in upper-layer signal or DCI format

[0428] In one method of the present disclosure, a terminal may receive information regarding a PUSCH to perform UCI multiplexing from a base station as an upper layer signal. More specifically, the terminal may receive a priority for cell-specific UCI multiplexing from the base station.

[0429] For example, if three cells are configured for a terminal, the cell indices may be 0, 1, and 2. According to the prior art, the terminal can multiplex a UCI to the PUSCH of the cell with the lowest index among the cells where the PUSCH is scheduled. For example, if three PUSCHs are scheduled for three cells with indices 0, 1, and 2, the terminal can multiplex a UCI to the PUSCH scheduled for the cell with index 0 among the three PUSCHs. To multiplex a UCI to a cell with a different index, the base station may transmit information regarding the priority for cell-specific UCI multiplexing to the terminal. For example, the highest priority (priority value 2) may be set for the cell with index 1, the second highest priority (priority value 1) for the cell with index 2, and the lowest priority (priority value 0) for the cell with index 0. The terminal can multiplex UCI on the PUSCH of the cell corresponding to the highest priority value among the priority values ​​corresponding to each cell where PUSCHs are scheduled. Therefore, the terminal can perform UCI multiplexing on the PUSCH of cell 1, which has the highest priority (priority value 2) set.

[0430] Alternatively, the terminal may exclude the PUSCH of some cells from UCI multiplexing. For example, cells with low coverage (or reception reliability) may be excluded from the UCI multiplexing process. To this end, the base station may transmit information to the terminal regarding whether to use cells for UCI multiplexing.

[0431] For example, if three cells are configured for a terminal, the cell indices may be 0, 1, and 2. According to the prior art, the terminal can multiplex a UCI on the PUSCH of the cell with the lowest index among the cells where the PUSCH is scheduled. For example, if three PUSCHs are scheduled for three cells with indices 0, 1, and 2, the terminal can multiplex a UCI on the PUSCH scheduled for the cell with index 0 among the three PUSCHs. To prevent UCI multiplexing in a specific cell, the base station may transmit information to the terminal regarding whether UCI multiplexing is possible in each cell. For example, the cell with index 0 may be configured so that UCI multiplexing does not occur. Therefore, even if a PUSCH is scheduled for the cell with index 0, the terminal can multiplex a UCI on one of the remaining PUSCHs (PUSCHs scheduled for Cell 1 and Cell 2) excluding the PUSCH.

[0432] Here, if PUSCH is scheduled for only one cell and said cell is a cell excluded from UCI multiplexing, the terminal can perform UCI multiplexing on said PUSCH. That is, this can be applied only when PUSCH is scheduled for multiple cells that are cells excluded from UCI multiplexing set by the base station to the terminal.

[0433] Here, if PUSCH is scheduled for only one cell and said cell is excluded from UCI multiplexing, and PUCCH including UCI is scheduled for another cell, the terminal may not perform UCI multiplexing. That is, the terminal can transmit PUSCH in said one cell and transmit UCI in another cell via PUCCH. In other words, PUSCH and PUCCH can be transmitted simultaneously in different cells.

[0434] Here, if PUSCH is scheduled for only one cell and said cell is excluded from UCI multiplexing, and PUCCH including UCI is scheduled for the same cell, the terminal may transmit only one of the channels, PUSCH or PUCCH, over the uplink. For example, PUCCH including UCI may be transmitted over the uplink, and PUSCH may be dropped.

[0435] The terminal may be instructed in the DCI format to have a PUSCH for UCI multiplexing. For example, a single DCI format may schedule multiple PUSCHs for multiple cells. For example, DCI format 0_3 may schedule multiple PUSCHs for multiple cells. One of the multiple PUSCHs scheduled in the DCI format may be used for UCI multiplexing. The single PUSCH used for UCI multiplexing may be indicated in the corresponding DCI format.

[0436] More specifically, the DCI format may include an indicator indicating a cell or PUSCH to be multiplexed with UCI. For example, when the DCI format schedules four cells or four PUSCHs, the terminal may obtain a 2-bit indicator from the DCI format. Depending on the value of the 2-bit indicator, a UCI may be multiplexed in one cell or PUSCH. If the value of the 2-bit indicator is '0', a UCI may be multiplexed in the first cell or first PUSCH; if the value of the 2-bit indicator is '1', a UCI may be multiplexed in the second cell or second PUSCH; if the value of the 2-bit indicator is '2', a UCI may be multiplexed in the third cell or third PUSCH; and if the value of the 2-bit indicator is '3', a UCI may be multiplexed in the fourth cell or fourth PUSCH.

[0437] [Method 1-10] PUSCH Selection Based on Beta-Offset / Effective Code Rate

[0438] In one method of the present disclosure, a terminal can select a PUSCH based on the beta-offset and effective code rate of a plurality of PUSCHs. The terminal can receive a beta-offset value for each cell. The beta-offset can be set for each UCI and can be used to determine the number of modulation symbols transmitted by the UCI. If a larger beta-offset is set, a larger number of modulation symbols are used for UCI transmission, so UCI reception performance can be improved.

[0439] The effective code rate of UCI can be determined as follows. For example, the effective code rate of HARQ-ACK is (O ACK +L ACK ) / (Q ACK *Modulation_order) can be. Here, O ACK and L ACK ≠ ACK can be the number of modulation symbols determined by the beta-offset value. Here, Modulation_order can be the modulation order of PUSCH (1 for BPSK, 2 for QPSK, 4 for 16QAM, 6 for 64QAM, 8 for 256QAM, 10 for 1024QAM). As another example, the effective code rate of HARQ-ACK is (O ACK +L ACK ) / (Q ACK It can be *Modulation_order*MIMO_layer). Here, MIMO_layer may be the number of MIMO layers included in PUSCH. The lower the effective code rate, the higher the reception performance of the UCI can be.

[0440] The terminal can select a PUSCH based on the beta-offset values ​​of multiple PUSCHs.

[0441] For example, among the beta-offset values ​​of multiple PUSCHs, the PUSCH with the highest beta-offset can be selected. Here, the highest beta-offset may be the PUSCH with the highest reception performance. If the UCI includes multiple UCI types and each UCI type corresponds to a different beta-offset value, the terminal can select one of the beta-offset values. For example, the terminal can select the highest beta-offset value and consider it as the beta-offset corresponding to the PUSCH.

[0442] The terminal can select a PUSCH based on the effective code rate values ​​of multiple PUSCHs.

[0443] For example, among the effective code rate values ​​of multiple PUSCHs, the PUSCH with the lowest effective code rate can be selected. Here, the lowest effective code rate may be the PUSCH with the highest reception performance. If the UCI includes multiple UCI types and each UCI type corresponds to a different beta-offset value, the terminal can determine the effective code rate value by selecting one of the beta-offset values. For example, the terminal can determine the effective code rate value by selecting the highest beta-offset value and consider it as the effective code rate value corresponding to the PUSCH.

[0444] UCI multiplexing method over multiple PUSCHs

[0445] According to one embodiment of the present disclosure, a terminal can multiplex a UCI on a plurality of PUSCHs. Here, the number of plurality of PUSCHs on which the UCI can be multiplexed may be set by a base station. For example, the number of plurality of PUSCHs on which the UCI is multiplexed may be two. The terminal can multiplex a UCI on the plurality of PUSCHs. Alternatively, the terminal may report the maximum number of PUSCHs on which the UCI can be multiplexed to the base station through UE capability information. The base station may set the number of PUSCHs on which the UCI can be multiplexed to the terminal according to the UE capability information. If the terminal does not receive a separate setting from the base station for the number of plurality of PUSCHs on which the UCI can be multiplexed, the terminal may multiplex a UCI on a single PUSCH.

[0446] A method for a terminal to select multiple PUSCHs may use at least one of the methods 1-1 through 1-10 described above, or a combination thereof. Although the methods 1-1 through 1-10 described above select a single PUSCH, multiple PUSCHs (e.g., two PUSCHs) can be selected based on the above methods. For example, a method of selecting a single PUSCH based on the highest MCS can be extended to a method of selecting multiple PUSCHs (i.e., two PUSCHs with the highest MCS) in descending order of MCS values. For example, a method of selecting a single PUSCH based on the lowest MCS can be extended to a method of selecting multiple PUSCHs (i.e., two PUSCHs with the lowest MCS) in ascending order of MCS values.

[0447] As another example, the terminal can select multiple PUSCHs based on the frequency index in ascending order of the frequency index. For example, the terminal can select two PUSCHs with the lowest frequency index.

[0448] FIG. 14 is a diagram illustrating a UCI multiplexed state in a plurality of PUSCHs according to one embodiment of the present disclosure.

[0449] Referring to FIG. 14, transmission of multiple PUSCHs (1410, 1420) from multiple serving cells (or multiple carriers, or multiple UL subbands) may be scheduled to a terminal. The multiple PUSCHs may be scheduled through a single DCI, each PUSCH may be scheduled through a different DCI, or the multiple PUSCHs may include a configured grant (CG) PUSCH.

[0450] The terminal may multiplex the UCI on multiple PUSCHs (1410, 1420) among multiple PUSCHs that overlap with the PUCCH (1400) containing the UCI, and may not transmit the PUCCH (1400). Here, UCI multiplexing may be performed on two PUSCHs (1410, 1420). Thus, the first UCI may be multiplexed on the first PUSCH (1410), and the second UCI may be multiplexed on the second PUSCH (1420).

[0451] Below, methods for a terminal to multiplex UCIs over multiple PUSCHs are explained in more detail.

[0452] [Method 2-1] UCI Split Multiplexing

[0453] FIG. 15 is a diagram illustrating a method of multiplexing by dividing UCI as one method of the present disclosure.

[0454] In one method of the present disclosure, a terminal may divide a UCI payload to multiplex a UCI over a plurality of PUSCHs. When the UCI is divided and multiplexed over two PUSCHs, a first UCI segment may be multiplexed and transmitted over the first PUSCH, and a second UCI segment may be multiplexed and transmitted over the second PUSCH. In this case, the UCI segment may be performed in a step before CRC attachment or in a step after CRC attachment.

[0455] The specific UCI splitting method prior to the CRC attachment stage is as follows.

[0456] Length of HARQ-ACK information O ACK bits is O ACK-i It can be partitioned into (i=1...n). For example, when n=2, O ACK bits is O ACK-1 and O ACK-2 It can be partitioned into. Here, O ACK-1 + O ACK-2 = O ACK It could be. ACK-1 can be multiplexed in the 1st PUSCH, and O ACK-2 It can be multiplexed in the second PUSCH.

[0457] More specifically, O ACK-1 bits and O ACK-2 Each bit can be assigned a CRC. Additionally, each can be channel-coded and rate-matched. O ACK-i L based on bits ACK-i bits CRC is generated and attached, O ACK-i +L ACK-i bits can be formed. The above O ACK-i +L ACK-iBits are encoded using channel coding (such as Polar coding or Reed-Mullar coding), and rate matching can then be performed. After passing through the above rate matching, Q is the number of HARQ-ACK resources (number of modulation symbols per MIMO layer) multiplexed to the i-th PUSCH. ACK-i It can be determined as shown in the following mathematical formula 5.

[0458] [Mathematical Formula 5]

[0459]

[0460] O ACK-i and Q ACK-i Regarding, is the number of OFDM symbols included in the i-th PUSCH, and is the number of CBs included in the i-th PUSCH, and class can be the beta offset and alpha values ​​corresponding to the i-th PUSCH. can be the number of resources available to UCI in each PUSCH OFDM symbol l.

[0461] The specific division method for the stage after CRC attachment is as follows.

[0462] For example, the length of the HARQ-ACK information is O ACK If we say bits, then O ACK A CRC can be attached to bits. O ACK L based on bits ACK bits CRC is generated and attached, O ACK +L ACK bits can be formed O ACK +L ACK bits is O ACK-i It can be partitioned into (i=1...n). For example, when n=2, O ACK +L ACK bits is O ACK-1 and O ACK-2 It can be partitioned into. Here, O ACK-1 + OACK-2 = O ACK +L ACK It could be. ACK-1 is multiplexed in the 1st PUSCH, O ACK-2 It is multiplexed on the second PUSCH and can be channel-coded and rate-matched respectively. After passing through the above rate-matching, the number of HARQ-ACK resources (number of modulation symbols per MIMO layer) Q that are multiplexed on the i-th PUSCH ACK-i can be determined as shown in the following mathematical formula 6.

[0463] [Mathematical Formula 6]

[0464]

[0465] O ACK-I and Q ACK-i Regarding, is the number of OFDM symbols included in the i-th PUSCH, and is the number of CBs included in the i-th PUSCH, and class can be the beta offset and alpha values ​​corresponding to the i-th PUSCH. can be the number of resources available to UCI in each PUSCH OFDM symbol l.

[0466] The above method was explained using the example where the UCI type is HARQ-ACK, but a similar method can also be applied when the UCI type is CSI part 1 and CSI part 2.

[0467] A base station can receive multiple multiplexed PUSCHs from a terminal in which the UCI is divided. The base station can decode the first UCI division in the first PUSCH. That is, the base station can decode the first HARQ-ACK division, the first CSI part 1 division, and / or the first CSI part 2 division from the first PUSCH. Each of the first HARQ-ACK division, the first CSI part 1 division, and / or the first CSI part 2 division can be decoded individually from each other. The base station can decode the second UCI division in the second PUSCH. That is, the base station can decode the second HARQ-ACK division, the second CSI part 1 division, and / or the second CSI part 2 division from the second PUSCH. Each of the second HARQ-ACK division, the second CSI part 1 division, and / or the second CSI part 2 division can be decoded individually from each other.

[0468] The base station can obtain HARQ-ACK information by combining the first HARQ-ACK segmentation and the second HARQ-ACK segmentation. The base station can obtain CSI part 1 by combining the first CSI part 1 segmentation and the second CSI part 1 segmentation. The base station can obtain CSI part 2 by combining the first CSI part 2 segmentation and the second CSI part 2 segmentation.

[0469] The terminal is O ACK bits O ACK-1 and O ACK-2 When partitioning, O ACK-1 and O ACK-2 It can be determined by at least one of the following methods.

[0470] As a method, the UCI can be divided evenly according to the number of PUSCHs to be multiplexed. For example, when HARQ-ACK is multiplexed evenly across 2 PUSCHs, O ACK-1 = O ACK / 2 or O ACK-1 = ceil(OACK / 2) or O ACK-1 = floor(O ACK / 2) could be. And, O ACK-2 = O ACK / 2 or O ACK-2 = floor(O ACK / 2) or O ACK-1 = ceil(O ACK / 2) It could be. Or, O ACK-2 = O ACK -O ACK-1 It could be.

[0471] In one method, the UCI can be divided based on the information of the PUSCH to be multiplexed. Let M1 be the value of the information associated with the first PUSCH and M2 be the value of the information associated with the second PUSCH, and the HARQ-ACK can be divided as follows.

[0472] O ACK-1 = O ACK *M1 / (M1+M2) or O ACK-1 = ceil(O ACK *M1 / (M1+M2)) or O ACK-1 = floor(O ACK It could be *M1 / (M1+M2)). O ACK-2 = O ACK *M2 / (M1+M2) or O ACK-2 = floor(O ACK *M2 / (M1+M2)) or O ACK-2 = ceil(O ACK *M2 / (M1+M2)) or, O ACK-2 = O ACK -O ACK-1 It could be.

[0473] Here, M1 and M2 may be the TB size of the first PUSCH and the TB size of the second PUSCH, respectively.

[0474] Here, M1 and M2 may be the number of resources included in the first PUSCH and the number of resources included in the second PUSCH, respectively. The number of resources of each PUSCH is It can be determined as. When determining the number of resources included in the first PUSCH, is the OFDM symbol number of the first PUSCH, and may be the number of resources available for data transmission in the OFDM symbol l of the first PUSCH. When determining the number of resources included in the second PUSCH, is the OFDM symbol number of the second PUSCH, and can be the number of resources available for data transmission in OFDM symbol l of the second PUSCH.

[0475] Here, M1 and M2 are beta offsets corresponding to the first PUSCH ( ) and beta offset corresponding to the second PUSCH ( It can be a value related to ). For example, M1= , M2= It can be. That is, UCI splitting can be proportional to the beta offset. As another example, M1= , M2=1 / , or, M1= , M2= It is possible. In other words, UCI splitting can be inversely proportional to the beta offset.

[0476] According to one embodiment of the present disclosure, UCI splitting may be performed only when the length of the UCI exceeds a certain length. For example, if the length of the HARQ-ACK information is less than or equal to a certain length, or is less than or equal to a certain length, the HARQ-ACK information may not be split and may be multiplexed to only one PUSCH. If the length of the HARQ-ACK information is greater than or equal to a certain length, or is greater than or equal to a certain length, the HARQ-ACK information may be split and multiplexed to multiple PUSCHs. For example, the first HARQ-ACK split may be multiplexed to the first PUSCH, and the second HARQ-ACK split may be multiplexed to the second PUSCH.

[0477] [Method 2-2] UCI Iterative Multiplexing

[0478] FIG. 16 is a drawing illustrating a method of iteratively multiplexing UCI as one method of the present disclosure.

[0479] In one method of the present disclosure, a UCI may be transmitted repeatedly over a plurality of PUSCHs. More specifically, the same UCI may be transmitted over a plurality of PUSCHs. That is, the same UCI may be repeatedly multiplexed and transmitted over a first PUSCH and a second PUSCH.

[0480] The specific UCI iterative multiplexing method is as follows.

[0481] Length of HARQ-ACK information O ACK A CRC can be attached to bits. That is, O ACK L based on bits ACK bits CRC is generated and attached, O ACK +L ACK bits can be formed. The above O ACK +L ACK Bits are encoded using channel coding (such as Polar coding or Reed-Mullar coding), and then rate matching can be performed. Rate matching can be performed commonly for multiple PUSCHs or independently.

[0482] A base station can receive multiple multiplexed PUSCHs from a terminal, in which UCI is repeated. The base station can decode the UCI repetition in the first PUSCH. That is, the base station can decode the HARQ-ACK repetition, the CSI part 1 repetition, and the CSI part 2 repetition from the first PUSCH. Each HARQ-ACK repetition, CSI part 1 repetition, and CSI part 2 repetition can be decoded individually from each other. The base station can decode the UCI repetition in the second PUSCH. That is, the base station can decode the HARQ-ACK repetition, the CSI part 1 repetition, and the CSI part 2 repetition from the second PUSCH. Each HARQ-ACK repetition, CSI part 1 repetition, and CSI part 2 repetition can be decoded individually from each other. The base station can decode the UCI repetitions of the two PUSCHs together (joint). That is, the base station can decode HARQ-ACK repetitions, CSI part 1 repetitions, and CSI part 2 repetitions from the first PUSCH and the second PUSCH. At this time, identical UCI repetitions included in the two PUSCHs can be combined and decoded. In this way, the reception performance of the UCI can be improved.

[0483] When rate matching is performed independently for multiple PUSCHs, the number of HARQ-ACK resources (number of modulation symbols per MIMO layer) Q that are multiplexed to the i-th PUSCH after passing through the rate matching. ACK-i It can be determined as shown in the following mathematical formula 7.

[0484] [Mathematical Formula 7]

[0485]

[0486] Here is the number of OFDM symbols included in the i-th PUSCH, and is the number of CBs included in the i-th PUSCH, and class may be the beta offset and alpha values ​​corresponding to the i-th PUSCH. That is, the terminal can perform rate matching based on each PUSCH. Therefore, different rate matching result values ​​( class They can have different (from each other).

[0487] When rate matching is performed commonly for multiple PUSCHs, Q is the number of HARQ-ACK resources (number of modulation symbols per MIMO layer) multiplexed to multiple PUSCHs after passing through the rate matching. ACK It can be determined as shown in the following mathematical formula 8.

[0488] [Mathematical Formula 8]

[0489]

[0490] Here is the number of OFDM symbols included in the first PUSCH, and is the number of CBs included in the first PUSCH, and class may be a beta offset and alpha value corresponding to the first PUSCH. Here, the first PUSCH may be one of a plurality of PUSCHs. That is, the terminal may perform rate matching based on one PUSCH and apply the result of the rate matching to a plurality of PUSCHs. According to the present disclosure, It is determined based on the first PUSCH, but can be applied to other PUSCHs where the UCI is multiplexed (e.g., the second PUSCH).

[0491] Alternatively, rate matching can be performed based on the maximum amount of resources available for ACK multiplexing on each PUSCH. For example, Q, the number of bits of HARQ-ACK multiplexed across multiple PUSCHs. ACK It can be determined as shown in the following mathematical formula 9.

[0492] [Mathematical Formula 9]

[0493]

[0494] Here, is the maximum amount of resources available for HARQ-ACK multiplexing in the first PUSCH, and may be the maximum amount of resources available for HARQ-ACK multiplexing in the second PUSCH. That is, the terminal, based on one PUSCH and based on the beta offset, the amount of resources required for HARQ-ACK multiplexing ( ) determines, and based on the maximum amount of resources available for HARQ-ACK multiplexing of multiple PUSCHs, the final rate matching result value ( ) can be obtained. The above value can be applied to the first PUSCH and the second PUSCH where the UCI is multiplexed.

[0495] In another way, rate matching is It can be determined as ). Here, and f(x,y) is a function that returns a non-negative integer value, and , may be a value used when rate matching is performed independently for multiple PUSCHs. Accordingly, the terminal performs rate matching for each PUSCH, and and The terminal can obtain the above rate matching result value ( and A single rate matching value can be obtained based on ). For example, ) or It can be.

[0496] In the method described above, the beta offset value of the PUSCH to which the UCI is multiplexed (the beta offset value of the first PUSCH) and the beta offset value of the second PUSCH It can be set from the base station. For example, the terminal can receive a beta offset value per serving cell, and the beta offset can be used regardless of the number of PUSCHs in which the UCI is multiplexed.

[0497] Alternatively, the base station may set multiple beta offset values, whereby the first beta offset value is used when the UCI is multiplexed to a single PUSCH, and the second beta offset value is used when the UCI is multiplexed to multiple (two) PUSCHs. In other words, different beta offset values ​​may be used depending on the number of PUSCHs to which the UCI is multiplexed.

[0498] Alternatively, the terminal has the beta offset value of the first PUSCH ( ) and the beta offset value of the 2nd PUSCH( Based on the number of PUSCHs to which the UCI is multiplexed, the beta offset value to be used when the UCI is multiplexed on two PUSCHs can be determined. Here, the beta offset value of the i-th PUSCH can be set by the base station as the beta offset value used when the UCI is multiplexed only on the i-th PUSCH. For example, It can be. Here, N is the number of PUSCHs into which the UCI is multiplexed, and if the UCI is multiplexed into 2 PUSCHs, N=2.

[0499] According to the method described above, when UCIs are multiplexed across multiple PUSCHs, the terminal can reduce the number of REs used for UCI multiplexing on a single PUSCH by using a small beta offset value.

[0500] [Method 2-3] Multiplexing by UCI Type

[0501] FIG. 17 is a drawing illustrating a method of multiplexing by UCI type as one method of the present disclosure.

[0502] In one method of the present disclosure, a terminal can transmit on a plurality of PUSCHs divided by UCI type. That is, different UCI types can be transmitted on different PUSCHs. For example, when the UCI types are HARQ-ACK, CSI part 1, and CSI part 2, HARQ-ACK and CSI part 1 can be transmitted on the first PUSCH, and CSI part 2 can be transmitted on the second PUSCH.

[0503] The specific multiplexing methods for each UCI type are as follows.

[0504] The terminal can determine the types of UCIs to be multiplexed to multiple PUSCHs. The terminal can determine the types of UCIs to be transmitted to the first PUSCH and the types of UCIs to be transmitted to the second PUSCH among the types of UCIs. Here, the types of UCIs to be transmitted to the first PUSCH and the types of UCIs to be transmitted to the second PUSCH may be at least one of the following combinations.

[0505] - Combination 1: UCI type to be transmitted via 1st PUSCH={HARQ=ACK, CSI part 1}, UCI type to be transmitted via 2nd PUSCH={CSI part 2}

[0506] Here, HARQ-ACK information and CSI part 1 information can be multiplexed in the first PUSCH, and CSI part 2 information can be multiplexed in the second PUSCH.

[0507] - Combination 2: UCI type to be transmitted via 1st PUSCH={HARQ=ACK}, UCI type to be transmitted via 2nd PUSCH={CSI part 1, CSI part 2}

[0508] Here, HARQ-ACK information can be multiplexed in the first PUSCH, and CSI part 1 information and CSI part 2 information can be multiplexed in the second PUSCH.

[0509] The base station can set information about combination 1 and / or combination 2 to the terminal through an upper layer signal (RRC signal).

[0510] A base station can receive multiple multiplexed UCIs from a terminal. The base station can determine the multiplexed UCI types in the first and second PUSCHs. In the case of combination 1, the base station can decode HARQ-ACK information and CSI part 1 information in the first PUSCH and decode CSI part 2 information in the second PUSCH. In the case of combination 2, the base station can decode HARQ-ACK information in the first PUSCH and decode CSI part 1 information and CSI part 2 information in the second PUSCH.

[0511] [Method 2-4] Multiplex the dropped portion of the UCI to the 2nd PUSCH

[0512] FIG. 18 is a drawing illustrating a method of multiplexing a dropped portion of UCI into a second PUSCH as one method of the present disclosure.

[0513] In one method of the present disclosure, when a UCI is multiplexed to a first PUSCH, if some of the UCIs cannot be multiplexed to the first PUSCH, the terminal may multiplex the portion of the UCIs that could not be multiplexed to the first PUSCH to a second PUSCH. For example, some or all of the CSI part 2 may be dropped based on the amount of resources available to the first PUSCH. In this case, some or all of the dropped CSI part 2 may be transmitted on the second PUSCH.

[0514] The specific multiplexing method is as follows.

[0515] The terminal can multiplex the UCI with the first PUSCH. Here, the UCI may include HARQ-ACK, CSI part 1, and / or CSI part 2. The terminal can determine the UCI that can be multiplexed in the first PUSCH. For example, in the case of CSI part 2, some or all of it may not be multiplexed according to the conditions of [Table 25] described above. In this case, the UCI (CSI part 2) that is not multiplexed in the first PUSCH may be multiplexed in the second PUSCH.

[0516] The total CSI part 2 information that the terminal must transmit to the base station (before being dropped) It could be bits. The above bits can be multiplexed to the first PUSCH bits and cannot be multiplexed to the first PUSCH (or can be multiplexed to the second PUSCH) It can be divided into bits. Here, + It can be bits. Here, the terminal is Based on this, rate matching for transmitting CSI part 2 information in the first PUSCH can be performed. For example, the number of resources (number of modulation symbols per MIMO layer) capable of transmitting CSI part 2 information in the first PUSCH It can be calculated based on the following mathematical formula 10.

[0517] [Mathematical Formula 10]

[0518]

[0519] Here Is It is the length of the CRC corresponding to the CSI part 2 information of bits.

[0520] The terminal Based on this, rate matching can be performed to transmit CSI part 2 information in the second PUSCH. For example, the number of resources (number of modulation symbols per MIMO layer) capable of transmitting CSI part 2 information in the second PUSCH It can be calculated based on the following mathematical formula 11.

[0521] [Mathematical Formula 11]

[0522]

[0523] Here Is It is the CRC length corresponding to the CSI part 2 information of bits.

[0524] In one example, ...may not all be transmitted on the second PUSCH either. For example, based on the number of resources on the second PUSCH according to the conditions in Table 26 Some or all of the bits may be dropped.

[0525] When UL-SCH is included in the second PUSCH, this If it is greater, CSI Part 2 may be dropped. Here, starting from the lowest priority of the information included in CSI Part 2, this CSI part 2 can be dropped until it is less than or equal to.

[0526] A base station may receive a UCI from a terminal on a first PUSCH. The base station may decode a HARQ-ACK, CSI part 1, and / or CSI part 2 from the first PUSCH. The base station may determine whether all bits of CSI part 2 are included in the multiplexed UCI on the first PUSCH or if a drop has occurred. If it is determined that no drop has occurred, the base station may not decode the UCI on another PUSCH. For example, if the base station determines that a drop of the UCI has occurred on the first PUSCH, the base station may additionally decode the dropped CSI part 2 on the second PUSCH. The base station may obtain the entire CSI part 2 by combining the bits of CSI part 2 decoded on the first PUSCH and the bits of CSI part 2 decoded on the second PUSCH.

[0527] FIG. 19 is a flowchart illustrating a procedure for a terminal to multiplex UCIs to a plurality of PUSCHs according to one embodiment of the present disclosure.

[0528] FIG. 19 illustrates an exemplary method that can be implemented according to the principles of the present disclosure, and various modifications may be made to the method illustrated in the flowchart. For example, although illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, each step may be omitted or replaced with another step.

[0529] In step 1900, multiple PUSCHs may be scheduled for the terminal in multiple cells and / or multiple slots. Here, multiple PUSCHs may overlap with a PUCCH containing a UCI. Here, the terminal may determine that a PUSCH and a PUCCH overlap if they are transmitted in the same symbol. Or, the terminal may determine that a PUSCH and a PUCCH overlap if they are transmitted in the same slot.

[0530] In step 1910, the terminal may select multiple PUSCHs for UCI multiplexing. Here, the method for selecting multiple PUSCHs may be determined based on at least one of methods 1-1 through 1-10 described above, or a combination thereof. Here, information regarding the number of multiple PUSCHs for UCI multiplexing may be set by the base station. Alternatively, the number of multiple PUSCHs may be determined according to the terminal capability (UE capability). For example, the terminal may report the maximum number of PUSCHs capable of multiplexing UCI to the base station through the terminal capability information. Based on the terminal capability information, the base station may set the number of multiple PUSCHs capable of multiplexing UCI to the terminal.

[0531] In step 1920, the terminal can multiplex UCIs on a selected plurality of PUSCHs. Here, the UCI multiplexing method may be performed based on at least one of methods 2-1 through 2-4 described above, or a combination thereof. The terminal may receive information regarding the UCI multiplexing method to be applied from the base station as an upper layer signal (RRC signal).

[0532] In step 1930, the terminal can transmit multiple PUSCHs with multiple UCIs in multiple cells and / or multiple slots.

[0533] UCI retransmission method

[0534] According to one embodiment of the present disclosure, a terminal may receive a request for UCI retransmission from a base station and may retransmit the UCI to the base station in accordance with the request. Here, the DCI requesting the UCI retransmission may be one of the DCI formats for scheduling PUSCH.

[0535] FIG. 20 is a diagram illustrating a method in which a UCI is retransmitted according to one embodiment of the present disclosure.

[0536] Referring to FIG. 20, the first DCI (2000) can schedule the first PUSCH (2010). The first PUSCH (2010) may have a UCI multiplexed. Here, the UCI may include at least one of HARQ-ACK, CSI part 1, and CSI part 2. The terminal may not multiplex some UCIs in the first PUSCH (2010). This may occur due to a shortage of resources in the scheduled PUSCH. For example, some or all of the CSI part 2 may not be multiplexed in the first PUSCH (2010). The terminal may receive the second DCI (2020). The second DCI (2020) may be a DCI requesting a UCI retransmission. The second DCI (2020) may schedule the second PUSCH (2030), and the UCI may be retransmitted to the second PUSCH (2030). According to the present disclosure, the UCI retransmitted in the second PUSCH (2030) may be a portion dropped in the preceding first PUSCH (2010), or all or part of the types of UCI transmitted in the first PUSCH (2010).

[0537] The DCI requesting the retransmission of the terminal's UCI may include information regarding the UCI requiring retransmission. More specifically, at least one of the following information elements or a combination thereof can be obtained through the DCI requesting the retransmission of the terminal's UCI and / or an upper layer signal (RRC signal).

[0538] - First information: Information about the slot in which the terminal transmitted the UCI. For example, the terminal can obtain information about the slot in which the UCI was transmitted via the DCI, and based on said information, can determine which slot's UCI needs to be retransmitted.

[0539] ■ More specifically, information related to the slot index of the PUSCH to which the UCI is multiplexed may be included in the DCI. For example, the DCI may include an offset value between the slot in which the DCI was received and the slot of the PUSCH to which the UCI is multiplexed. For example, if the DCI is received in slot n and the offset value is 0, the terminal may determine that a retransmission has been requested for the UCI multiplexed in the PUSCH transmitted in slot n0.

[0540] ■ Alternatively, information related to the HARQ process number of a PUSCH with a multiplexed UCI may be included in the DCI. For example, a terminal can obtain the HARQ process number through the DCI and determine the PUSCH corresponding to the said HARQ process number. Here, the PUSCH may be the most recently transmitted PUSCH among the PUSCHs corresponding to the said HARQ process number. The terminal can determine that a retransmission of the UCI included in the said PUSCH has been requested.

[0541] ■ Alternatively, if a UCI type is indicated via DCI, the terminal may determine that a retransmission of the UCI corresponding to the most recently indicated UCI type has been requested. For example, if the UCI type indicated by DCI is CSI part 2, the terminal may determine that the most recently transmitted CSI part 2 among the CSI part 2s transmitted prior to receiving the DCI is the UCI for which retransmission has been requested.

[0542] - Second Information: Information regarding UCI types requiring retransmission. A base station may succeed in decoding some UCI types but fail to decode others. This is because different beta offsets may be used since the target Block Error Rate (BLER) differs for each UCI type. Therefore, it may not be necessary to retransmit all UCIs for the base station to successfully decode them. For example, if a UCI includes HARQ-ACK, CSI part 1, and CSI part 2, the base station may instruct the terminal via the DCI regarding the UCI types requiring retransmission among the three types mentioned above. This information may be indicated as a bitmap in the DCI. More specifically, a 3-bit bitmap may be included, and each bit may correspond to a specific UCI type. The terminal may determine that retransmission has been instructed for the corresponding UCI type if the bit in the bitmap is '1'. Therefore, the types of UCI being retransmitted may correspond to bits '1' in the bitmap.

[0543] - Third Information: Information indicating whether the terminal should retransmit the UCI including the dropped portion of CSI part 2. The terminal may be unable to multiplex part or all of CSI part 2 depending on the PUSCH resources used to multiplex the UCI. This may occur because the base station does not know the number of resources required for CSI part 2 when scheduling the PUSCH. On the other hand, when retransmitting the UCI, the base station can know the number of resources required for CSI part 2. For example, the base station can obtain the number of PUSCH resources required for CSI part 2 by receiving CSI part 1. Therefore, the base station can schedule the PUSCH so that CSI part 2 is not dropped during UCI retransmission, and the terminal can retransmit the UCI including the dropped portion of CSI part 2. The terminal can obtain the above third information through the DCI. Alternatively, whether the terminal retransmits the UCI including the dropped portion of CSI part 2 can be configured via upper-layer information from the base station. Alternatively, the terminal may be predefined in the system to always retransmit the UCI including the dropped portion of CSI part 2. For example, if the terminal is instructed to retransmit CSI part 2 based on the second information described above, the terminal may retransmit CSI part 2 on a newly scheduled PUSCH. In this case, the drop of CSI part 2 may be determined according to the conditions of [Table 25] described above, based on the number of resources of the newly scheduled PUSCH. The CSI part 2 to be retransmitted may be determined regardless of which part of CSI part 2 was dropped in the PUSCH previously transmitted by the terminal.

[0544] - Fourth information: Information indicating whether the terminal should retransmit only the dropped portion. If the channel environment is excellent, the base station can successfully receive multiplexed UCIs on the PUSCH. However, the base station cannot receive UCIs (dropped CSI part 2) that the terminal dropped without multiplexing on the PUSCH. Therefore, the base station may request the terminal to retransmit only the dropped UCI. The terminal may obtain the above fourth information through the DCI. Alternatively, whether the terminal should retransmit only the dropped portion of CSI part 2 may be set through upper-layer information from the base station. Alternatively, the terminal may always have only the dropped portion of CSI part 2 predefined in the system. For example, if the terminal is instructed to retransmit CSI part 2 based on the above-described second information, the terminal may retransmit only the dropped CSI part 2 on the newly scheduled PUSCH.

[0545] - Fifth Information: Information indicating the carrier of the PUSCH where the UCI was dropped. The terminal may retransmit the UCI through different carriers or cells. For example, if part or all of CSI part 2 is dropped in the first PUSCH transmitted from the first carrier, said CSI part 2 may be multiplexed and retransmitted in the second PUSCH transmitted from the second carrier. As another example, if the UCI is multiplexed in multiple PUSCHs of multiple carriers, the base station may request the retransmission of the UCI multiplexed in the PUSCH of one carrier. The base station may indicate to the terminal, via the fifth information, which carrier the dropped UCI multiplexed in the PUSCH transmitted from. For example, the DCI requesting the UCI retransmission may include the carrier index. The terminal may retransmit the UCI multiplexed in the PUSCH transmitted from the carrier corresponding to the carrier index. A PUSCH for retransmission can be transmitted from a second carrier, and the index of the second carrier can be included in a DCI requesting UCI retransmission.

[0546] According to one embodiment of the present disclosure, since the terminal can receive a DCI requesting UCI retransmission, the terminal may store the UCI in the terminal's buffer. However, since continuously storing the UCI in the terminal's buffer may place a burden on the terminal's buffer management, the terminal may store the UCI in the terminal's buffer only for a certain period of time and delete the UCI from the terminal's buffer after that period of time. Alternatively, the terminal may expect to receive a DCI requesting UCI retransmission only for a certain period of time after UCI transmission, and may not expect to receive the DCI requesting UCI retransmission after that period of time. Here, the certain period of time may be expressed as the number of slots and / or absolute time units (e.g., ms). Here, the value of the certain period of time may be set by the base station to the terminal.

[0547] According to one embodiment of the present disclosure, the terminal may store only one identical UCI type in the terminal buffer. For example, the terminal may store only one CSI part 2 in the buffer. For example, the terminal may store only the most recent CSI part 2 in the buffer, and if the base station requests the terminal to retransmit the CSI part 2, the terminal may retransmit the most recent CSI part 2 that was stored in the buffer.

[0548] FIG. 21 is a flowchart illustrating a procedure for a terminal to retransmit a UCI according to one embodiment of the present disclosure.

[0549] FIG. 21 illustrates an exemplary method that can be implemented according to the principles of the present disclosure, and various modifications may be made to the method illustrated in the flowchart. For example, although illustrated as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in a different order, or occur multiple times. In other examples, each step may be omitted or replaced with another step.

[0550] In step 2100, the terminal may receive a setting for UCI retransmission from the base station via an upper layer signal (RRC signal). For example, prior to receiving the setting for UCI retransmission from the base station, the terminal may report UCI retransmission-related UE capability information to the base station, and the base station may generate and transmit the setting for UCI retransmission based on the UE capability information. The terminal may receive some or all of the information from the first to the fifth from the base station. Additionally, the terminal may receive a setting from the base station to receive some or all of the information from the first to the fifth in DCI format.

[0551] In step 2110, when the terminal transmits a PUCCH containing a UCI and / or a PUSCH with a UCI multiplexed to a base station, it may monitor a DCI or PDCCH requesting a UCI retransmission based on the time of transmission of the UCI. For example, the terminal may monitor the DCI or PDCCH for a certain period of time from the time of transmission of the UCI.

[0552] In step 2120, when the terminal receives a DCI or PDCCH requesting a UCI retransmission, the terminal may obtain at least one of the first to fifth information or a combination thereof from the DCI. The terminal may determine which UCI retransmission was requested based on at least one of the first to fifth information or a combination thereof.

[0553] In step 2130, the terminal may retransmit the UCI instructed to be retransmitted in the PUSCH and / or PUCCH scheduled by the DCI requesting the UCI retransmission.

[0554] FIG. 22 is a drawing illustrating the structure of a terminal in a wireless communication system according to one embodiment of the present disclosure.

[0555] Referring to FIG. 22, the terminal may include a transceiver (referring to a terminal receiver (2200) and a terminal transmitter (2210)), a memory (not shown), and a terminal processing unit (2205, or a terminal control unit or processor). Depending on the communication method of the terminal described above, the transceiver (2200, 2210), memory, and terminal processing unit (2205) of the terminal may operate. However, the components of the terminal are not limited to the examples described above. For example, the terminal may include more components or fewer components than the components described above. Furthermore, the transceiver, memory, and processor may be implemented in the form of a single chip.

[0556] The transceiver can transmit and receive signals with a base station. Here, the signal may include control information and data. To this end, the transceiver may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts its frequency. However, this is merely one embodiment of the transceiver, and the components of the transceiver are not limited to an RF transmitter and an RF receiver.

[0557] In addition, the transceiver receives a signal through a wireless channel and outputs it to a processor, and can transmit the signal output from the processor through a wireless channel.

[0558] Memory can store programs and data necessary for the operation of the terminal. Additionally, memory can store control information or data included in signals transmitted and received by the terminal. Memory may be composed of storage media or combinations of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Additionally, there may be multiple memories.

[0559] Additionally, the processor may control a series of processes to enable the terminal to operate according to the embodiments described above. For example, the processor may control the components of the terminal to select a PUSCH for UCI multiplexing, multiplex UCI over a plurality of PUSCHs, and / or retransmit UCI according to various embodiments of the present disclosure described above. There may be multiple processors, and the processor may perform the operation of controlling the components of the terminal by executing a program stored in memory.

[0560] FIG. 23 is a drawing illustrating the structure of a base station in a wireless communication system according to one embodiment of the present disclosure.

[0561] Referring to FIG. 23, the base station may include a transceiver unit (referring to a base station receiver unit (2300) and a base station transmitter unit (2310)), a memory (not shown), and a base station processing unit (2305, or a base station control unit or processor). Depending on the communication method of the base station described above, the transceiver unit (2300, 2310), the memory, and the base station processing unit (2305) of the base station may operate. However, the components of the base station are not limited to the examples described above. For example, the base station may include more components or fewer components than the components described above. In addition, the transceiver unit, the memory, and the processor may be implemented in the form of a single chip.

[0562] The transceiver can transmit and receive signals with a terminal. Here, the signal may include control information and data. To this end, the transceiver may be composed of an RF transmitter that up-converts and amplifies the frequency of a transmitted signal, and an RF receiver that low-noise amplifies a received signal and down-converts its frequency. However, this is merely one embodiment of the transceiver, and the components of the transceiver are not limited to an RF transmitter and an RF receiver.

[0563] In addition, the transceiver receives a signal through a wireless channel and outputs it to a processor, and can transmit the signal output from the processor through a wireless channel.

[0564] Memory can store programs and data necessary for the operation of the base station. Additionally, memory can store control information or data included in signals transmitted and received by the base station. Memory can be composed of storage media or combinations of storage media such as ROM, RAM, hard disk, CD-ROM, and DVD. Additionally, there may be multiple memories.

[0565] A processor can control a series of processes to enable a base station to operate according to the embodiments of the present disclosure described above. For example, the processor can control each component of the base station to transmit control information associated with the UCI multiplexing of a terminal and / or receive a retransmitted UCI according to various embodiments of the present disclosure described above. There may be multiple processors, and the processors can perform control operations on the components of the base station by executing a program stored in memory.

[0566] Methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

[0567] When implemented in software, a computer-readable storage medium may be provided for storing one or more programs (software modules). One or more programs stored in the computer-readable storage medium are configured for execution by one or more processors within an electronic device. One or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of this disclosure.

[0568] Such programs (software modules, software) may be stored in random access memory, non-volatile memory including flash memory, ROM (Read Only Memory), Electrically Erasable Programmable Read Only Memory (EEPROM), magnetic disc storage devices, Compact Disc-ROM (CD-ROM), Digital Versatile Discs (DVDs), or other forms of optical storage devices, magnetic cassettes. Alternatively, they may be stored in memory composed of some or all of these. Additionally, each constituent memory may include multiple units.

[0569] Additionally, the program may be stored on an attachable storage device accessible via a communication network such as the Internet, Intranet, Local Area Network (LAN), Wide LAN (WLAN), or Storage Area Network (SAN), or a combination thereof. Such a storage device may be connected to the device performing the embodiment of the present disclosure through an external port. Additionally, a separate storage device on the communication network may be connected to the device performing the embodiment of the present disclosure.

[0570] In the specific embodiments of the present disclosure described above, the components included in the invention are expressed in a singular or plural form according to the specific embodiments presented. However, the singular or plural expression is selected to suit the situation presented for convenience of explanation, and the present disclosure is not limited to singular or plural components; even if a component is expressed in the plural form, it may be composed of a singular form, or even if a component is expressed in the singular form, it may be composed of a plural form.

[0571] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples provided to facilitate the explanation of the technical content of the present disclosure and to aid in understanding the present disclosure, and are not intended to limit the scope of the present disclosure. That is, it is obvious to those skilled in the art that other variations based on the technical concept of the present disclosure are possible. Furthermore, each of the above embodiments may be combined and operated as needed. For example, parts of one embodiment of the present disclosure and parts of another embodiment may be combined to operate a base station and a terminal. For example, parts of the first embodiment and the second embodiment of the present disclosure may be combined to operate a base station and a terminal. In addition, although the above embodiments are presented based on an FDD LTE system, other variations based on the technical concept of the above embodiments may be implemented in other systems such as a TDD LTE system, 5G, or NR system.

[0572] Meanwhile, the order of description in the drawings illustrating the method of the present invention does not necessarily correspond to the order of execution, and the order of execution may be changed or executed in parallel.

[0573] Alternatively, drawings describing the method of the present invention may omit some components and include only some components to the extent that the essence of the present invention is not impaired.

[0574] In addition, the method of the present invention may be implemented by combining some or all of the contents included in each embodiment within a scope that does not impair the essence of the invention.

[0575] Various embodiments of the present disclosure have been described above. The foregoing description of the present disclosure is for illustrative purposes only and is not limited to the embodiments disclosed. Those skilled in the art will understand that other specific forms can be easily modified without altering the technical spirit or essential features of the present disclosure. The scope of the present disclosure is defined by the claims set forth below rather than by the foregoing detailed description, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts should be interpreted as being included within the scope of the present disclosure.

Claims

1. A method performed by a UE (user equipment) of a wireless communication system, A step of receiving configuration information related to UCI (uplink control information) retransmission from a base station; Steps to generate UCI; A step of transmitting a first PUSCH (physical uplink shared channel) containing at least a portion of the above UCI to the base station; A step of receiving DCI (downlink control information) from the base station that instructs the retransmission of the UCI; Based on the above DCI, a step of identifying a portion of the above UCI that requires retransmission among the above UCIs; and A method comprising the step of transmitting a second PUSCH containing a UCI portion requiring retransmission to the base station.

2. In Paragraph 1, The above DCI is, First information for identifying the target of the above UCI retransmission, Second information indicating the type of UCI requiring retransmission among the above UCIs, Third information indicating whether the UCI portion requiring retransmission includes CSI (channel state information) part 2 that was dropped during the first PUSCH transmission, A fourth piece of information indicating whether the UCI portion requiring retransmission includes only the portion dropped during the first PUSCH transmission among the UCI, and Fifth information indicating a carrier associated with the first PUSCH above A method comprising at least one of the following.

3. In Paragraph 2, The first information indicates a slot offset between the first PUSCH and the DCI or a HARQ (hybrid automatic repeat request) process number corresponding to the first PUSCH, and A method characterized in that the second information above is a bitmap in which each bit corresponds to a specific UCI type.

4. In Paragraph 1, A method characterized in that the above setting information includes information regarding the time interval during which the UCI is stored in the buffer of the UE.

5. A method performed by a base station of a wireless communication system, A step of transmitting configuration information related to the retransmission of UCI (uplink control information) to UE (user equipment); A step of receiving a first PUSCH (physical uplink shared channel) from the above UE, comprising at least a portion of the UCI generated by the UE; A step of transmitting downlink control information (DCI) instructing the above UCI retransmission to the UE; and A method comprising the step of receiving a second PUSCH from the above UE, the second PUSCH including a portion of the UCI that requires retransmission among the above UCIs.

6. In Paragraph 5, The above DCI is, First information for identifying the target of the above UCI retransmission, Second information indicating the type of UCI requiring retransmission among the above UCIs, Third information indicating whether the UCI portion requiring retransmission includes CSI (channel state information) part 2 that was dropped during the first PUSCH transmission, A fourth piece of information indicating whether the UCI portion requiring retransmission includes only the portion dropped during the first PUSCH transmission among the UCI, and Fifth information indicating a carrier associated with the first PUSCH above A method comprising at least one of the following.

7. In Paragraph 6, The first information indicates a slot offset between the first PUSCH and the DCI or a HARQ (hybrid automatic repeat request) process number corresponding to the first PUSCH, and A method characterized in that the second information above is a bitmap in which each bit corresponds to a specific UCI type.

8. In Paragraph 5, A method characterized in that the above setting information includes information regarding the time interval during which the UCI is stored in the buffer of the UE.

9. In the UE (user equipment) of a wireless communication system, At least one transceiver; At least one processor connected to the above at least one transceiver so as to be able to communicate; and Connected to communicate with at least one processor and capable of executing individually or in any combination of the at least one processor, the UE, Receive configuration information related to UCI (uplink control information) retransmission from the base station, and Create a UCI, Transmit a first PUSCH (physical uplink shared channel) containing at least a portion of the above UCI to the base station, and Receive DCI (downlink control information) from the above base station instructing the retransmission of the above UCI, and Based on the above DCI, identify the UCI portions among the above UCI that require retransmission, and Transmit the second PUSCH, which includes the UCI portion requiring retransmission, to the base station. A UE including memory that stores instructions causing it to do so.

10. In Paragraph 9, The above DCI is, First information for identifying the target of the above UCI retransmission, Second information indicating the type of UCI requiring retransmission among the above UCIs, Third information indicating whether the UCI portion requiring retransmission includes CSI (channel state information) part 2 that was dropped during the first PUSCH transmission, A fourth piece of information indicating whether the UCI portion requiring retransmission includes only the portion dropped during the first PUSCH transmission among the UCI, and Fifth information indicating a carrier associated with the first PUSCH above A UE comprising at least one of the following.

11. In Paragraph 10, The first information indicates a slot offset between the first PUSCH and the DCI or a HARQ (hybrid automatic repeat request) process number corresponding to the first PUSCH, and The above second information is a UE characterized in that each bit is a bitmap corresponding to a specific UCI type.

12. In Paragraph 9, A UE characterized in that the above setting information includes information regarding the time interval during which the UCI is stored in the buffer of the UE.

13. In a base station of a wireless communication system, At least one transceiver; At least one processor connected to the above at least one transceiver so as to be able to communicate; and The base station is connected to communicate with at least one processor and is capable of executing individually or in any combination of the at least one processor, and, Transmit configuration information related to the retransmission of UCI (uplink control information) to the UE (user equipment), and Receive a first PUSCH (physical uplink shared channel) from the above UE, comprising at least a portion of the UCI generated by the above UE, and Transmit DCI (downlink control information) instructing the above UCI retransmission to the UE, and Receive a second PUSCH from the above UE, which includes a portion of the UCI that requires retransmission among the above UCIs. A base station including memory that stores commands causing it to do so.

14. In Paragraph 13, The above DCI is, First information for identifying the target of the above UCI retransmission, Second information indicating the type of UCI requiring retransmission among the above UCIs, Third information indicating whether the UCI portion requiring retransmission includes CSI (channel state information) part 2 that was dropped during the first PUSCH transmission, A fourth piece of information indicating whether the UCI portion requiring retransmission includes only the portion dropped during the first PUSCH transmission among the UCI, and Fifth information indicating a carrier associated with the first PUSCH above Includes at least one of the following, The first information indicates a slot offset between the first PUSCH and the DCI or a HARQ (hybrid automatic repeat request) process number corresponding to the first PUSCH, and A base station characterized in that the second information above is a bitmap in which each bit corresponds to a specific UCI type.

15. In Paragraph 13, A base station characterized by the above setting information including information regarding the time interval during which the UCI is stored in the buffer of the UE.

Images