Method and apparatus for uplink power control in wireless communication system

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. The present disclosure provides a random access method in a wireless communication system. In the present disclosure, a method of a terminal comprises the steps of: receiving, from a base station, a random access response (RAR) uplink (UL) grant for scheduling a physical uplink shared channel (PUSCH); identifying, on the basis of the RAR UL grant, a symbol type of a symbol on which the PUSCH is scheduled; determining a power of the PUSCH on the basis of the symbol type of the symbol on which the PUSCH is scheduled; and transmitting, to the base station, the PUSCH on the basis of the power of the PUSCH.

Description

Uplink power control method and device 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 of arbitrary connection of a terminal 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 such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of 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, 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, physical layer standardization 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 that meets 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] As a result of the aforementioned developments and advancements in wireless communication systems, it has become possible to provide various services, and thus measures are required to facilitate the smooth provision of these services.

[0009] The disclosed embodiment aims to provide an apparatus and method capable of effectively providing services in a mobile communication system.

[0010] The present disclosure proposes an optional connection method in a subband non-overlapping full duplex (SBFD).

[0011] The disclosed embodiment provides a device and method capable of effectively providing services in a mobile communication system.

[0012] 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.

[0013] 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.

[0014] 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.

[0015] 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.

[0016] 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.

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

[0018] 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.

[0019] 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.

[0020] 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.

[0021] 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.

[0022] FIG. 11 is a drawing illustrating an optional connection procedure in one embodiment of the present disclosure.

[0023] FIG. 12 is a drawing illustrating TDD settings and SBFD settings according to one embodiment of the present disclosure.

[0024] FIG. 13 is a diagram illustrating an effective RACH opportunity in a TDD setting and an SBFD setting according to one embodiment of the present disclosure.

[0025] Figure 14 is a diagram illustrating scenarios according to the RO transmission type and the transmission symbol type of msg3 PUSCH.

[0026] FIG. 15 is a diagram showing the transmission power of msg3 PUSCH according to the first method of the present disclosure.

[0027] FIG. 16 is a flowchart for determining the power of msg3 PUSCH according to the first method of the present disclosure.

[0028] FIG. 17 is a diagram showing the transmission power of msg3 PUSCH according to the second method of the present disclosure.

[0029] FIG. 18 is a flowchart for determining the power of msg3 PUSCH according to the second method of the present disclosure.

[0030] FIG. 19 is a diagram showing the transmission power of msg3 PUSCH according to the third method of the present disclosure.

[0031] FIG. 20 is a flowchart for determining the power of msg3 PUSCH according to the third method of the present disclosure.

[0032] Figure 21 is a diagram illustrating the retransmission of msg3 PUSCH.

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

[0034] 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.

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

[0036] In describing the embodiments, technical details that are well known in the technical field 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.

[0037] 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.

[0038] 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 related functions or configurations 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.

[0039] Hereinafter, a 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. A 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, a downlink (DL) refers to a wireless transmission path of a signal transmitted by a base station to a terminal, and an uplink (UL) refers to a wireless transmission path of a signal transmitted by a terminal to a base station. Furthermore, while LTE or LTE-A 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 technologies (5G, new radio, NR) developed after LTE-A may be included therein, and the 5G below may be a concept that includes existing LTE, LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems with some modifications made at the discretion of a person with skilled technical knowledge, without significantly departing from the scope of the present disclosure.

[0040] 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).

[0041] 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.

[0042] In this embodiment, the term "part" refers to a software or hardware component such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), 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 may be configured to run one or more processors. Accordingly, 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 within the device or secure multimedia card. Also, in the embodiment, the '~part' may include one or more processors.

[0043] 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.

[0044] 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.

[0045] 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).

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] [NR Time-Frequency Resources]

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

[0052] Figure 1 is a diagram illustrating the basic structure of the time-frequency domain, which is a wireless resource domain where data or control channels are transmitted in a 5G system.

[0053] 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.

[0054] 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.

[0055] 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). One subframe (201) may be composed of one or more slots (202, 203), and the number of slots (202, 203) per one 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 set as the subcarrier spacing value are illustrated. When μ=0 (204), one subframe (201) may be composed of one slot (202), and when μ=1 (205), one subframe (201) may be composed of two slots (203). That is, the number of slots per one subframe ( ) may vary, and accordingly, the number of slots per frame ( ) may vary. Depending on each subcarrier spacing setting μ and It can be defined by Table 1 below.

[0056] [Table 1]

[0057]

[0058] [Bandwidth Section (BWP)]

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

[0060] 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.

[0061] 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.

[0062] [Table 2]

[0063]

[0064] 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).

[0065] 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.

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

[0067] 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.

[0068] 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 with a specific subcarrier interval, the bandwidth portion set to that subcarrier interval may be activated.

[0069] In addition, according to some embodiments, a base station may set bandwidth portions with 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, monitoring an unnecessary downlink control channel using a large bandwidth of 100 MHz may be very inefficient in terms of power consumption. To reduce the power consumption of the terminal, the base station may set a bandwidth portion with 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.

[0070] 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.

[0071] [Bandwidth Section (BWP) Change]

[0072] 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.

[0073] 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.

[0074] [Table 3]

[0075]

[0076] 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.

[0077] 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 BWP Completion 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 BWPYou may not expect to indicate a slot offset (K0 or K2) value smaller than )

[0078] 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).

[0079] [SS / PBCH Block]

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

[0081] 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.

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

[0083] - 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.

[0084] - 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.

[0085] - 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.

[0086] 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.

[0087] [PDCCH: DCI related]

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

[0089] 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.

[0090] 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.

[0091] 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).

[0092] 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.

[0093] [Table 4]

[0094]

[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] [Table 5]

[0097]

[0098]

[0099] 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.

[0100] [Table 6]

[0101]

[0102] 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.

[0103] [Table 7]

[0104]

[0105]

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

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

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

[0109] 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.

[0110] [Table 8]

[0111]

[0112] 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.

[0113] FIG. 5 is a diagram showing an example of a basic unit of time and frequency resources that constitute a downlink control channel that can be used in 5G. According to FIG. 5, the basic unit of time and frequency resources that constitute 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, that is, 12 subcarriers. A base station can construct a downlink control channel allocation unit by concatenating REGs (503).

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] [Table 9]

[0119]

[0120]

[0121] 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.

[0122] 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.

[0123] 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.

[0124] - 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

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

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

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

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

[0129] 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.

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

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

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

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

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

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

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

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

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

[0139] INT-RNTI (Interruption RNTI): Used to indicate whether PDSCH is pucturing.

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

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

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

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

[0144] [Table 10]

[0145]

[0146] 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.

[0147] [Mathematical Formula 1]

[0148]

[0149] 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.

[0150] [PDSCH: Regarding Frequency Resource Allocation]

[0151] FIG. 7 is a diagram illustrating an example of frequency axis resource allocation of a physical downlink shared channel (PDSCH) in a wireless communication system according to one embodiment of the present disclosure.

[0152] FIG. 7 is a diagram illustrating three frequency axis resource allocation methods that can be configured through the upper layer in an NR wireless communication system: type 0 (7-00), type 1 (7-05), and dynamic switch (7-10).

[0153] Referring to FIG. 7, 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 11] 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.

[0154] [Table 11]

[0155]

[0156] 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.

[0157] 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.

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

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

[0160] 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 regarding the position and length of the start symbol in 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 12] or [Table 13] below may be transmitted from the base station to the terminal.

[0161] [Table 12]

[0162]

[0163] [Table 13]

[0164]

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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.

[0170] [PUSCH: Regarding transmission method]

[0171] 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 in DCI format 0_0 or 0_1.

[0172] Configured grant Type 1 PUSCH transmissions can be semi-statically configured by receiving configuredGrantConfig, which includes rrc-ConfiguredUplinkGrant from [Table 14], 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 from [Table 14], 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 14], with the exception of dataScramblingIdentityPUSCH, txConfig, codebookSubset, maxRank, and scaling of UCI-OnPUSCH, which are provided by pusch-Config, the upper signaling of [Table 15]. If the terminal is provided with transformPrecoder in configuredGrantConfig, which is the upper signaling of [Table 14], the terminal applies tp-pi2BPSK in pusch-Config of [Table 15] to PUSCH transmissions operated by the configured grant.

[0173] [Table 14]

[0174]

[0175]

[0176]

[0177] 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 15], the upper signaling, is 'codebook' or 'nonCodebook'.

[0178] 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 the PUSCH transmission via DCI format 0_0 within a BWP where the PUCCH resource containing pucch-spatialRelationInfo is not configured. If the terminal is not configured with txConfig within pusch-Config of [Table 15], the terminal does not expect to be scheduled via DCI format 0_1.

[0179] [Table 15]

[0180]

[0181]

[0182]

[0183] 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).

[0184] 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.

[0185] 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'.

[0186] 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.

[0187] 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.

[0188] 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 scheduled via DCI format 0_1.

[0189] 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.

[0190] 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 a non-periodic 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.

[0191] 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.

[0192] 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 usage value 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.

[0193] 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.

[0194] [CA / DC Related]

[0195] 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 according to one embodiment of the present disclosure.

[0196] 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.

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

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

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

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

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

[0202] Regarding the above 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 above SDAP header may include QoS flow ID information indicating QoS. The above QoS information may be used for data processing priority, scheduling information, etc., to support smooth service.

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

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

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

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

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

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

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

[0210] - Retransmission of PDCP SDUs

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

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

[0213] 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.

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

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

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

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

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

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

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

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

[0222] - Duplicate detection

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

[0224] - RLC SDU discard function

[0225] RLC re-establishment function

[0226] 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.

[0227] 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.

[0228] 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.

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

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

[0231] - Scheduling information reporting function

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

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

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

[0235] - MBMS service identification function

[0236] - Transport format selection function

[0237] - Padding

[0238] 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.

[0239] 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.

[0240] 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 embodiments.

[0241] 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).

[0242] 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.

[0243] 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.

[0244] In the following disclosure, the above 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.

[0245] 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, provided that they do not deviate significantly from the scope of the present disclosure, in the judgment of a person skilled in the art. The contents of the present disclosure are applicable to FDD and TDD systems.

[0246] 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.

[0247] 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.

[0248] - MIB (Master Information Block)

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

[0250] - RRC (Radio Resource Control)

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

[0252] 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.

[0253] - PDCCH (Physical Downlink Control Channel)

[0254] - DCI (Downlink Control Information)

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

[0256] - Group common DCI

[0257] - Common DCI

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

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

[0260] - PUCCH (Physical Uplink Control Channel)

[0261] - UCI (Uplink Control Information)

[0262] 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.

[0263] In the following disclosure, the above 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.

[0264] [Random Access procedure in SBFD]

[0265] Meanwhile, 3GPP introduced Subband Non-Overlapping Full Duplex (SBFD) as a new NR-based duplex method. SBFD is a technology that utilizes a portion of downlink resources as uplink resources in the TDD spectrum of frequencies below or above 6 GHz, thereby using the increased uplink resources for uplink transmission to expand the uplink coverage of the terminal, and using the increased uplink resources for feedback on downlink transmission to reduce feedback delay. In this disclosure, a terminal capable of receiving information from a base station regarding SBFD support and performing uplink transmission using a portion of downlink resources may be referred to as an SBFD terminal (SBFD-capable UE) for convenience. To define the above SBFD method in the standard and for an SBFD terminal to determine whether the SBFD is supported in a specific cell (or frequency, frequency band), the following method may be considered.

[0266] In the first method, in addition to the existing frame structure types of unpaired spectrum (or time division duplex, TDD) or paired spectrum (or frequency division duplex, FDD), another frame structure type (e.g., frame structure type 2) may be introduced to define the above SBFD. The frame structure type for defining the above SBFD may be defined as being supported at the specific frequency or frequency band, or the base station may instruct the terminal whether SBFD is supported through system information. The SBFD terminal may receive system information including whether SBFD is supported and determine whether SBFD is supported for the specific cell (or frequency, frequency band).

[0267] In a second method, whether the SBFD is additionally supported at a specific frequency or frequency band of the existing unpaired spectrum (or TDD) may be indicated without defining a new frame structure type. In the second method, whether the SBFD is additionally supported at a specific frequency or frequency band of the existing unpaired spectrum may be defined, or the base station may indicate to the terminal whether the SBFD is supported through system information. The SBFD terminal may receive system information including whether the SBFD is supported and determine whether the SBFD is supported for the specific cell (or frequency, frequency band).

[0268] In the first and second methods above, the information regarding SBFD support may be information indicating whether SBFD is supported indirectly by additionally setting a part of the downlink resource as an uplink resource in addition to the setting of TDD UL (uplink)-DL (downlink) resource configuration information indicating TDD downlink slot (or symbol) resources and uplink slot (or symbol) resources (e.g., SBFD resource configuration information in FIG. 12 described later), or it may be information indicating whether SBFD is supported directly.

[0269] In the present disclosure, the SBFD terminal may obtain cell synchronization by receiving a synchronization signal block during an initial cell connection for connecting to a cell (or base station). The process of obtaining cell synchronization may be the same for the SBFD terminal and the existing TDD terminal. Subsequently, the SBFD terminal may determine whether the cell supports SBFD through MIB acquisition, SIB acquisition, or a random access process.

[0270] The system information for transmitting information regarding SBFD support may be system information transmitted separately, distinguished from system information for a terminal supporting a different version of the standard within the cell (e.g., an existing TDD terminal), and the SBFD terminal may determine whether SBFD is supported by acquiring all or part of the system information transmitted separately from the system information for the existing TDD terminal. If the SBFD terminal acquires only the system information for the existing TDD terminal or acquires system information regarding SBFD non-support, the cell (or base station) may determine that it supports only TDD.

[0271] If the information regarding SBFD support is included in system information for a terminal supporting a different version of the standard (e.g., an existing TDD terminal), the information regarding SBFD support may be inserted at the very end of the system information so as not to affect the acquisition of system information by the existing TDD terminal. If the SBFD terminal fails to acquire the information regarding SBFD support inserted at the very end, or acquires information that SBFD is not supported, the SBFD terminal may determine that the cell (or base station) supports only TDD.

[0272] If the information regarding SBFD support is included in the system information for a terminal supporting a different version of the specification (e.g., an existing TDD terminal), the information regarding SBFD support may be transmitted via a separate PDSCH so as not to affect the acquisition of system information for the existing TDD terminal. That is, a terminal that does not support SBFD may receive a first SIB (or SIB1) containing existing TDD-related system information from the first PDSCH. A terminal that supports SBFD may receive a first SIB (or SIB) containing existing TDD-related system information from the first PDSCH and may receive a second SIB containing SBFD-related system information from the second PDSCH. Here, the first PDSCH and the second PDSCH may be scheduled as the first PDCCH and the second PDCCH, and the cyclic redundancy code (CRC) of the first PDCCH and the second PDCCH may be scrambled with the same RNTI (e.g., SI-RNTI). The search space for monitoring the second PDCCH can be obtained from the system information of the first PDSCH, and if it cannot be obtained (i.e., if the system information of the first PDSCH does not include information about the search space), the second PDCCH can be received in the same search space as the search space of the first PDCCH.

[0273] As described above, if the SBFD terminal determines that the cell (or base station) supports only TDD, the SBFD terminal can perform random access procedures and transmit / receive data / control signals in the same way as an existing TDD terminal.

[0274] A base station may configure separate random access resources for each of the existing TDD terminals or SBFD terminals (e.g., an SBFD terminal supporting duplex communication and an SBFD terminal supporting half-duplex communication), and transmit configuration information for said random access resources (control information or configuration information indicating time-frequency resources that can be used for PRACH) to the SBFD terminals through system information. The system information for transmitting information about said random access resources may be system information transmitted separately, distinct from system information for terminals supporting different versions of specifications within the cell (e.g., existing TDD terminals).

[0275] The base station may set up random access resources for TDD terminals and additionally set up separate random access resources for SBFD terminals. Here, the SBFD terminal may use the random access resources for TDD terminals, or the SBFD terminal may not be able to use the random access resources for TDD terminals. If the SBFD terminal cannot use the random access resources for TDD terminals, the SBFD terminal may always use only the separate random access resources for SBFD terminals.

[0276] The SBFD terminal may be instructed by the base station whether it can use random access resources for the TDD terminal. Whether the SBFD terminal can use random access resources for the TDD terminal may be indicated by including them in the SIB. That is, a separate random access resource for the SBFD terminal may be configured in the SIB, and along with said configuration, whether the SBFD terminal can use random access resources for the TDD terminal may be indicated. Whether the SBFD terminal can use random access resources for the TDD terminal may be indicated by 1 bit. If the 1 bit is '0' (or FALSE), it indicates that the SBFD terminal cannot use random access resources for the TDD terminal, and if the 1 bit is '1' (or TRUE), it indicates that the SBFD terminal can use random access resources for the TDD terminal.

[0277] A base station can determine the type of terminal attempting to connect to a cell based on the random access resources used by the terminal. For example, an SBFD terminal may transmit a PRACH from a separate random access resource for the SBFD terminal, and when the base station receives the PRACH from the separate random access resource for the SBFD terminal, it may determine that the SBFD terminal is attempting to connect to a cell. For example, a TDD terminal may transmit a PRACH from a random access resource for the TDD terminal, and when the base station receives the PRACH from the random access resource for the TDD terminal, it may determine that the TDD terminal is attempting to connect to a cell. For reference, if the transmission of a PRACH by an SBFD terminal is allowed through the random access resource of a TDD terminal, the base station may be ambiguous as to whether the type of terminal transmitting the PRACH is a TDD terminal or an SBFD terminal. In this case, the base station may always assume that the type of the terminal is a TDD terminal.

[0278] When a base station determines that a terminal is an SBFD terminal, the base station may schedule msg2, msg3, msg4, etc. to the terminal based on uplink subband settings. That is, when the base station schedules the reception of msg2 and msg4 to the terminal, said msg2 and msg4 may be scheduled so that they are not received in the uplink subband. When the terminal receives a PDSCH including said msg2 and msg4, it may receive the PDSCH in a frequency resource excluding the uplink subband. When the base station schedules a msg3 PUSCH to the terminal, said msg3 PUSCH may be scheduled to be transmitted within the uplink subband.

[0279] If the base station determines that the terminal is a TDD terminal, the base station may not use uplink subband settings when scheduling msg2, msg3, and msg4 to the terminal. That is, even if an uplink subband is configured for a downlink symbol or a flexible symbol, the base station may assume that the terminal cannot obtain the said uplink subband configuration information. When the base station schedules msg3 PUSCH to the terminal, said msg3 PUSCH may be scheduled for a flexible symbol or an uplink symbol. In other words, msg3 PUSCH cannot be scheduled for an uplink subband configured for a downlink symbol or a flexible symbol.

[0280] Alternatively, the base station may not set a separate random access resource for the SBFD terminal, but may set a common random access resource for all terminals within the cell. In this case, configuration information regarding the random access resource may be transmitted to all terminals within the cell via system information, and the SBFD terminal that receives the system information may perform random access to the random access resource. Subsequently, the SBFD terminal may complete the random access process and proceed to an RRC connection mode for transmitting and receiving data with the cell. After the RRC connection mode, the SBFD terminal may receive an upper or physical signal from the base station that determines that a portion of the frequency resources of the downlink time resources is set as an uplink resource, and transmit an uplink signal from the uplink resource, for example, SBFD operation.

[0281] When the SBFD terminal determines that the cell supports SBFD, it can notify the base station that the terminal attempting to connect is an SBFD terminal by transmitting capability information to the base station that includes at least one of the following: whether the terminal supports SBFD, whether it supports full-duplex or half-duplex communication, and the number of transmitting or receiving antennas it has (or supports). Alternatively, if half-duplex communication support is a mandatory implementation for the SBFD terminal, the half-duplex communication support status may be omitted from the capability information. The SBFD terminal's report regarding the capability information may be reported to the base station through a random access process, after the random access process is completed, or after proceeding to an RRC connection mode for transmitting and receiving data with the cell.

[0282] The above SBFD terminal may support half-duplex communication, which performs only uplink transmission or downlink reception at a time like an existing TDD terminal, or it may support full-duplex communication, which performs both uplink transmission and downlink reception at a time. Accordingly, whether the above half-duplex or full-duplex communication is supported can be reported to the base station by the SBFD terminal through a capability report, and after the report, the base station may configure the SBFD terminal to transmit and receive using half-duplex communication or full-duplex communication. When the SBFD terminal reports the capability for half-duplex communication to the base station, a switching gap to change RF between transmission and reception may be required when operating in FDD or TDD, as a duplexer generally does not exist.

[0283] Generally, a terminal can establish a wireless link with a network through a random access procedure based on network synchronization and system information acquired during the cell search process. Random access may utilize contention-based or contention-free methods. A contention-based random access method may be used when the terminal performs cell selection and re-selection during the initial connection phase of a cell, for example, when moving from an RRC_IDLE state to an RRC_CONNECTED state. Contention-free random access may be used to reset uplink synchronization when downlink data arrives, in the case of a handover, or for location measurement.

[0284] FIG. 11 is a diagram illustrating a random access procedure in a wireless communication system to which the present disclosure applies.

[0285] Referring to FIG. 11, a contention-based random access procedure is illustrated as an example. Additionally, although not illustrated, a base station may transmit a synchronization signal block as described in the embodiments above. In this case, the base station may periodically transmit the synchronization signal block using beam sweeping. For example, the base station may transmit a synchronization signal block containing PSS / SSS (synchronization signal) and PBCH (broadcast channel) signals using up to 64 different beams for 5 ms, and multiple synchronization signal blocks may be transmitted using different beams. The terminal may detect (select) a synchronization signal block having an optimal beam direction (e.g., a beam direction where the received signal strength is strongest or greater than a predetermined threshold) and transmit a preamble using the PRACH (physical random access channel) resource associated with the detected synchronization signal block. For example, as a first step (1101) of the random access procedure, the terminal may transmit a random access preamble (or message 1) to the base station. A base station that receives the above random access preamble can measure the transmission delay value between the terminal and the base station and synchronize the uplink. Specifically, the terminal can transmit a random access preamble arbitrarily selected from a set of random access preambles given in advance by system information. Furthermore, the initial transmission power of the random access preamble can be determined based on the path loss between the base station and the terminal measured by the terminal. Additionally, the terminal can determine the transmission beam direction (or transmission beam or beam) of the random access preamble based on the synchronization signal block received from the base station and transmit the random access preamble by applying the determined transmission beam direction.

[0286] In the second step (1102), the base station may transmit a response to the detected random access attempt (random access response, RAR, or message 2 (message 2, msg2)) to the terminal. The base station may transmit an uplink transmission timing control command to the terminal based on the transmission delay value measured from the random access preamble received in the first step. Additionally, the base station may transmit uplink resource and power control commands to be used by the terminal as scheduling information. The scheduling information may include control information for the terminal's uplink transmission beam. The RAR is transmitted via PDSCH and may include at least one of the following information.

[0287] - Random access preamble sequence index detected by the network (or base station)

[0288] - TC-RNTI (temporary cell radio network temporary identifier)

[0289] - Uplink scheduling grant

[0290] - Timing advance value

[0291] If the terminal does not receive RAR, which is scheduling information for message 3, from the base station for a predetermined period of time in the second step (1102), the first step (1101) can be performed again. If the first step is performed again, the terminal increases the transmission power of the random access preamble by a predetermined step (this is called power ramping), thereby increasing the probability of the base station receiving the random access preamble.

[0292] In the third step (1103), the terminal may transmit a scheduled transmission (or Message 3) to the base station via the uplink data channel (physical uplink shared channel, PUSCH) using the uplink resources allocated in the second step (1102). The PUSCH may be referred to as Message 3 PUSCH (msg3 PUSCH). The transmission timing of the uplink data channel for transmitting Message 3 may follow the uplink transmission timing control command received from the base station in the second step (1102). Additionally, the transmission power of the uplink data channel for transmitting Message 3 may be determined by considering the power control command received from the base station in the second step (1102) and the power ramping value of the random access preamble. The message The uplink data channel for transmitting 3 may be the first uplink data signal that the terminal transmits to the base station after the random access preamble transmission.

[0293] Finally, in the fourth step (1104), if the base station determines that the terminal has performed random access without collision with other terminals, it may transmit a message (contention resolution message: CR message, or message 4) containing the identifier of the terminal that transmitted uplink data in the third step (1103) to the terminal. In this regard, if multiple terminals receive the same TC-RNTI in the second step (1102), the multiple terminals that received the same TC-RNTI each transmit to the base station in the third step (1103) their own terminal identifier (UE contention resolution identity) in message 3, and the base station may transmit message 4 (CR message) containing the terminal identifier of one of the multiple terminals to resolve the contention. When a terminal receives a message 4 (CR message) containing its terminal identifier from a base station in step 4 (1104) (or transmits a message 3 (message 3) containing a terminal identifier (C-RNTI) in step 3 (1103) and receives terminal-specific control information containing a CRC based on the terminal identifier (C-RNTI) via PDCCH in step 4 (1104), it can determine that random access has succeeded. Therefore, among multiple terminals that have received the same TC-RNTI from a base station, a terminal that confirms that its terminal identifier is included in message 4 (CR message) can confirm that it has succeeded in the competition. Then, the terminal can transmit a HARQ-ACK / NACK indicating successful reception of message 4 to the base station via a physical uplink control channel (PUCCH).

[0294] If the data transmitted by the terminal in the third step (1103) and the data of another terminal collide with each other, and the base station fails to receive the data signal from the terminal, the base station may not perform further data transmission to the terminal. Accordingly, if the terminal fails to receive the data transmitted from the base station in the fourth step (1104) for a certain period of time, it is determined that the random access procedure has failed, and the process may be restarted from the first step (1101).

[0295] As described above, in the first step (1101) of the random access process, the terminal can transmit a random access preamble onto PRACH. Each cell has 64 available preamble sequences, and depending on the transmission format, 4 long preamble formats and 9 short preamble formats may be used. The terminal generates 64 preamble sequences using a root sequence index and a cyclic shift value signaled as system information, and can randomly select one sequence to use as a preamble.

[0296] A base station may provide a terminal with configuration information for random access resources, such as control information (or configuration information) indicating time-frequency resources that can be used for PRACH, using at least one of SIB, upper layer signaling (RRC (Radio Resource Control) information), or DCI (Downlink Control Information). Frequency resources for PRACH transmission may indicate the starting RB point of transmission to the terminal, and the number of RBs used may be determined according to the preamble format transmitted via PRACH and the applied subcarrier interval. Time resources for PRACH transmission may be provided through a PRACH configuration index (0 to 255), such as a pre-set PRACH setting period, a subframe index containing a PRACH transmission time (PRACH occasion, which may be used interchangeably with transmission time), a start symbol, and the number of PRACH transmission times within a slot, as shown in Table 16 below. The terminal determines the validity of the PRACH transmission timestamps indicated in the PRACH configuration index and determines only the valid PRACH transmission timestamps as PRACH transmission timestamps capable of transmitting a random access preamble. Through the PRACH configuration index, the random access configuration information included in the SIB, and the index of the SSB selected by the terminal, the terminal identifies the time and frequency resources for transmitting the random access preamble and can transmit the selected sequence as a preamble to the base station.

[0297] Meanwhile, according to an embodiment of the present disclosure, a method is required for an SBFD terminal to determine the validity of a PRACH transmission time through a PRACH setting index and an SBFD setting for performing PRACH transmission, and to perform PRACH transmission through a PRACH transmission time determined to be valid, and a procedure of the SBFD terminal is required when a valid PRACH transmission time overlaps with a downlink reception.

[0298] [Table 16]

[0299]

[0300]

[0301]

[0302]

[0303]

[0304]

[0305]

[0306]

[0307]

[0308]

[0309] FIG. 12 is a diagram illustrating an example of SBFD operating in the TDD band of a wireless communication system to which the present disclosure applies.

[0310] FIG. 12(a) illustrates a case where TDD is operated in a specific frequency band. In a cell operating the TDD, the base station can transmit and receive signals containing data / control information in the downlink slot (or symbol), uplink slot (or symbol) (1201), and flexible slot (or symbol) based on the configuration of TDD UL-DL resource configuration information indicating the downlink slot (or symbol) resource and uplink slot (or symbol) resource of the existing TDD terminal or SBFD terminal.

[0311] In Fig. 12, it can be assumed that the DDDSU slot format is configured according to the TDD UL-DL resource configuration information. Here, 'D' is a slot composed entirely of downlink symbols, 'U' is a slot composed entirely of uplink symbols (1201, 1211, 1221, 1231), and 'S' is a slot that is not 'D' or 'U', that is, a slot containing downlink symbols, uplink symbols, or flexible symbols. For convenience, it can be assumed here that S is composed of 12 downlink symbols and 2 flexible symbols. Also, the DDDSU slot format can be repeated according to the TDD UL-DL resource configuration information. That is, the repetition period of the TDD configuration can be 5 slots (5ms for 15kHz SCS, 2.5ms for 30kHz SCS, etc.).

[0312] Next, FIGS. 12(b), 12(c) to 12(d) illustrate cases where SBFD is operated together with TDD in a specific frequency band.

[0313] Referring to FIG. 12(b), the terminal may be configured to set a portion of the cell's frequency band as a frequency band (1210) capable of uplink transmission. Here, the band configured as a frequency band capable of uplink transmission may be called an uplink subband (UL subband). The uplink subband (UL subband) may be applied to all symbols of all slots. The terminal may transmit an uplink channel or signal scheduled to all symbols (1212) within the subband (UL subband). However, the terminal may not transmit an uplink channel or signal in a band other than the subband (UL subband).

[0314] Referring to FIG. 12(c), the terminal may be configured to set a portion of the cell's frequency band as a frequency band (1220) capable of uplink transmission, and may be configured to set a time range in which the frequency band is activated. Here, the frequency band configured as a frequency band capable of uplink transmission may be called an uplink subband (UL subband). In FIG. 12(c), the uplink subband (UL subband) is deactivated in the first slot, and the uplink subband (UL subband) may be activated in the remaining slots. Accordingly, the terminal may transmit an uplink channel or signal in the uplink subband (UL subband) (1222) of the remaining slots. For reference, FIG. 12(c) illustrates an example in which the uplink subband (UL subband) is activated or deactivated on a slot-by-slot basis, but the uplink subband (UL subband) may also be activated or deactivated on a symbol-by-symbol basis.

[0315] Referring to FIG. 12(d), the terminal may be configured with a time-frequency resource capable of uplink transmission. The terminal may be configured with one or more time-frequency resources capable of uplink transmission. For example, a portion of the frequency band (1232) of the first slot and the second slot may be configured with a time-frequency resource capable of uplink transmission. Additionally, a portion of the frequency band (1233) of the third slot and a portion of the frequency band (1234) of the fourth slot may be configured with a time-frequency resource capable of uplink transmission.

[0316] In the following description, time-frequency resources capable of uplink transmission in downlink symbols or flexible symbols may be referred to as SBFD resources / UL subbands.

[0317] The base station may transmit a first PRACH setting to the terminal through system information, and RACH occasions may be set according to the first PRACH setting. The terminal may determine that all or some of the RACH occasions are valid. For reference, the first PRACH setting may be a PRACH setting for a TDD terminal. Therefore, when the TDD terminal determines valid RACH occasions according to the first PRACH setting, it cannot use setting information for SBFD resources or UL subbands.

[0318] In an FDD cell, all RACH opportunities according to the configured first PRACH setting can be defined as valid. Here, valid RACH opportunities can be called first valid RACH Occasions (ROs).

[0319] In a TDD cell, among the configured first PRACH settings, only RACH opportunities satisfying the following conditions can be considered valid. Here, valid RACH opportunities can be called first valid RACH Occasions (ROs).

[0320] - If the terminal has not received TDD DL / UL configuration information via system information, the RACH opportunity in the PRACH slot does not precede the SS / PBCH, and N from the last received symbol of the SS / PBCH gap If it starts after the symbol, the terminal can determine that the corresponding RACH opportunity is valid.

[0321] - When the terminal receives TDD DL / UL configuration information from system information, the RACH opportunity within the UL symbol or the RACH opportunity in the PRACH slot does not precede the SS / PBCH, and N from the last received symbol of the SS / PBCH gap Starts after the symbol and N from the last DL symbol gapIf it starts after the symbol, the terminal can determine that the corresponding RACH opportunity is valid.

[0322] N gap The value of can be determined based on the PRACH preamble format and the subcarrier interval of the preamble. For example, in the case of preamble format B4, N gap = can be 0. For other preamplifier formats, if the subcarrier spacing is 1.25 kHz or 5 kHz, N gap If =0 and the subcarrier spacing is 15kHz, 30kHz, 60kHz, or 120kHz, then N gap = can be 2. If the subcarrier spacing is 480 kHz, N gap = can be 8, and if the subcarrier spacing is 960kHz, then N gap It could be 16 days.

[0323] FIG. 13 is a diagram illustrating an effective RACH opportunity in a TDD setting and an SBFD setting according to one embodiment of the present disclosure.

[0324] Referring to FIG. 13(a), it is assumed that the terminal receives DDDSU as TDD DL / UL setting information, and that a slot RACH opportunity (1300, 1301, 1302, 1303, 1304) is set according to the first PRACH setting. The terminal can determine that a RACH opportunity that overlaps with a UL symbol among the RACH opportunities determined according to the first PRACH setting is a valid RACH opportunity. Here, the 5th slot (the last slot of the TDD cycle set by DDDSU) is an uplink slot, and the RACH opportunity (1304) included in the uplink slot may be valid. However, the RACH opportunities (1300, 1301, 1302, 1303) of the 1st, 2nd, 3rd, and 4th slots (the preceding 4 slots of the TDD cycle set to DDDSU) overlap with the DL symbol, or N after the DL symbol gapSince it does not start after the symbol, it may not be valid. For reference, the RACH opportunities (1301, 1302) according to the first PRACH setting are located within the SBFD UL subband, but the SBFD UL subband may not be considered in determining the validity of the first PRACH setting. A valid RACH opportunity determined according to the first PRACH setting may be called the first RACH opportunity (first RO) or the legacy RACH opportunity (legacy RO).

[0325] A terminal can determine the validity of a RACH opportunity according to the second PRACH setting as follows. Here, the second PRACH setting may be a PRACH setting for an SBFD terminal. An SBFD terminal is a terminal capable of obtaining resource setting information regarding a TDD DL / UL setting and an SBFD resource / UL subband. Therefore, when determining a RACH opportunity according to the second PRACH setting, the resource setting information regarding the TDD DL / UL setting format and the SBFD resource / UL subband may be used.

[0326] In a TDD cell, among the configured 2nd PRACH settings, only RACH opportunities that satisfy the following conditions can be considered valid. Here, valid RACH opportunities can be called 2nd valid RACH Occasions (ROs).

[0327] - When the terminal receives TDD DL / UL configuration information from system information, in the PRACH slot, the RACH opportunity does not precede the SS / PBCH, and from the last received symbol of the SS / PBCH N gap Starting after the symbol, not overlapping with DL symbols that are not SBFD symbols, and N from the last symbol among the DL symbols that are not SBFD symbols gap Starts after the symbol,

[0328] - If a RACH opportunity overlaps with SBFD symbols, and the RACH opportunity is located within the SBFD UL subband, the terminal can determine that the RACH opportunity is valid.

[0329] Here, SBFD symbols may be symbols with an SBFD UL subband set. And the remaining symbols (symbols without an SBFD UL subband set) may be non-SBFD symbols.

[0330] Under the above conditions, the condition "when the RACH opportunity overlaps with SBFD symbols" may be replaced with "when the RACH opportunity starts at an SBFD symbol and ends at a non-SBFD symbol" depending on the base station settings.

[0331] Referring to FIG. 13(b), the terminal receives DDDSU as TDD DL / UL configuration information, and the SBFD UL subband can be configured in the 2nd slot, 3rd slot, and 4th slot (SBFD configuration 2 of FIG. 12). It is assumed that according to the 2nd PRACH configuration, a RACH opportunity (1310, 1311, 1312) is configured for every 2 slots. The terminal can determine a valid RACH opportunity among the RACH opportunities determined according to the 2nd PRACH configuration. Here, the RACH opportunity (1311) included in the SBFD UL subband may be valid. However, since the RACH opportunities (1310, 1312) are not included in the SBFD UL subband, they may not be valid. A valid RACH opportunity determined according to the second PRACH setting may be called the second RACH opportunity (second RO) or SBFD RACH opportunity (SBFD RO).

[0332] The terminal can determine valid RACH opportunities determined according to the first PRACH setting and / or valid RACH opportunities determined according to the second PRACH setting as valid RACH opportunities.

[0333] FIG. 13(c) illustrates valid RACH opportunities determined by the terminal according to the first PRACH setting and the second PRACH setting. Referring to FIG. 13(c), the terminal can determine the legacy RO (1304) according to the first PRACH setting and the SBFD RO (1311) according to the second PRACH setting as valid RACH opportunities. The terminal can transmit PRACH at the valid RACH opportunities.

[0334] According to the present disclosure, the first PRACH setting may include at least one of the following information for uplink power control.

[0335] - preambleReceivedTargetPower: Received power target value of PRACH transmitted from legacy RO

[0336] - powerRampingStep: The increase value of the PRACH transmission power if the terminal does not receive a response to the PRACH after transmitting it from the legacy RO.

[0337] -msg3-Alpha: Path attenuation index value used by the terminal when transmitting msg3 PUSCH in non-SBFD symbols

[0338] -msg3-DeltaPreamble: Power parameter used by the terminal when transmitting msg3 PUSCH in a non-SBFD symbol

[0339] The uplink power value corresponding to the above first PRACH setting can be applied to the legacy RO.

[0340] - p0-nominal: PUCCH reception power target value when the terminal transmits PUCCH in a non-SBFD symbol

[0341] According to the present disclosure, the second PRACH setting may include at least one of the following information for uplink power control.

[0342] - preambleReceivedTargetPower_SBFD: Received power target value of PRACH transmitted from the SBFD RO

[0343] - powerRampingStep_SBFD: Increase value of PRACH transmission power if the terminal does not receive a response to the PRACH after transmitting it from the SBFD RO.

[0344] - msg3-Alpha_SBFD: Path attenuation index value used by the terminal when transmitting msg3 PUSCH in the SBFD symbol

[0345] - msg3-DeltaPreamble_SBFD: Power parameter used by the terminal when transmitting msg3 PUSCH in the SBFD symbol

[0346] - p0-nominal_SBFD: PUCCH reception power target value when the terminal transmits PUCCH on a non-SBFD symbol

[0347] The uplink power value corresponding to the above second PRACH setting can be applied to the SBFD RO. For reference, at least one symbol of the SBFD RO may overlap with the SBFD symbol.

[0348] In the present disclosure, only power parameters may be set in the second PRACH setting. In this case, in addition to the power parameters set through the second PRACH setting, parameters associated with the PRACH setting may use the parameters of the first PRACH setting.

[0349] In the present disclosure, only some power parameters may be set in the second PRACH setting. In this case, a default value (e.g., '0') may be used as the value of the power parameter that is not set. As another example, the value of the power parameter of the first PRACH setting may be used as the value of the power parameter that is not set in the second PRACH setting. For example, depending on the power parameter, '0' may be used or the value of the power parameter of the first PRACH setting may be used.

[0350] p0-nominal and p0-nominal_SBFD may be included in other higher-level settings (e.g., cell common PUCCH setting (PUCCH-ConfigCommon). For convenience, the present disclosure may describe that the first PRACH setting to the second PRACH setting include p0-nominal and p0-nominal_SBFD.

[0351] In the present disclosure, the difference between the power parameter of the first PRACH setting and the power parameter of the second PRACH setting may be set as the power parameter of the second PRACH setting. For example, the power parameter of the second PRACH setting may be set as the difference value between preambleReceivedTargetPower and preambleReceivedTargetPower_SBFD (preambleReceivedTargetPower_SBFD - preambleReceivedTargetPower) instead of preambleReceivedTargetPower_SBFD. In this case, the terminal may determine the value of the power parameter of the second PRACH setting based on the difference value and the value of the power parameter of the first PRACH setting.

[0352] The terminal can determine the transmission power of the PRACH transmitted from the legacy RO based on the first PRACH setting, and determine the transmission power of the PRACH transmitted from the SBFD RO based on the second PRACH setting. More specifically, the transmission power of the PRACH can be determined as follows.

[0353] [Mathematical Formula 2]

[0354]

[0355] Here, can be the maximum output power value set for the terminal at the transmission occasion i of the carrier wave f of cell c.

[0356] may be a path loss value measured from a downlink path loss reference signal corresponding to the uplink BWP b of the carrier f of cell c. Path loss can be calculated as referenceSignalPower-higher layer filtered RSRP (reference signal received power). Here, referenceSignalPower is a value set by the base station for the terminal and may be included in SIB1. Higher layer filtered RSRP may be a value obtained by filtering the RSRP value measured from the path loss reference signal. Here, the path loss reference signal may be an SSB or CSI-RS.

[0357] may be a value associated with the PRACH's received power target. can be a received power target value specified by the upper layer.

[0358] PRACH transmitted from legacy RO is PREAMBLE_RECEIVED_TARGET_POWER, which can appear as follows.

[0359] [Mathematical Formula 3]

[0360] PREAMBLE_RECEIVED_TARGET_POWER=

[0361] preambleReceivedTargetPower+DELTA_PREAMBLE+(PREAMBLE_POWER_RAMPING_COUNTER-1) * PREAMBLE_POWER_RAMPING_STEP

[0362] Here, PREAMBLE_POWER_RAMPING_STEP may be the powerRampingStep of the first PRACH setting. Here, preambleReceivedTargetPower may be a value set in the first PRACH setting. Here, DELTA_PREAMBLE may be a value corresponding to the PRACH format of the first PRACH setting. Here, PREAMBLE_POWER_RAMPING_COUNTER may be incremented by 1 if the terminal fails to transmit PRACH at the legacy RO and transmits PRACH at the next legacy RO.

[0363] Based on Equation 3, when the terminal initially transmits PRACH from the legacy RO, PREAMBLE_RECEIVED_TARGET_POWER = preambleReceivedTargetPower + DELTA_PREAMBLE You can send PRACH by configuring it. If PRACH transmission fails (if a Random access response (RAR) is not received within the RAR window), the terminal can resend PRACH from the legacy RO. In this case, PREAMBLE_POWER_RAMPING_COUNTER can be incremented by 1.

[0364] PRACH transmitted from SBFD RO is PREAMBLE_RECEIVED_TARGET_POWER_SBFD, which can be expressed as follows.

[0365] [Mathematical Formula 4]

[0366] PREAMBLE_RECEIVED_TARGET_POWER_SBFD=

[0367] preambleReceivedTargetPower_SBFD +DELTA_PREAMBLE_SBFD +(PREAMBLE_POWER_RAMPING_COUNTER_SBFD -1) * PREAMBLE_POWER_RAMPING_STEP_SBFD

[0368] Here, PREAMBLE_POWER_RAMPING_STEP_SBFD may be powerRampingStep_SBFD of the second PRACH setting. Here, preambleReceivedTargetPower_SBFD may be a value set in the second PRACH setting. Here, DELTA_PREAMBLE_SBFD may be a value corresponding to the PRACH format of the second PRACH setting. Here, PREAMBLE_POWER_RAMPING_COUNTER_SBFD may perform PRACH transmission at the next SBFD RO if the terminal fails to transmit PRACH at the SBFD RO, and at this time, PREAMBLE_POWER_RAMPING_COUNTER_SBFD may be increased by 1.

[0369] Based on Equation 4, when the terminal initially transmits PRACH from the SBFD RO, PREAMBLE_RECEIVED_TARGET_POWER_SBFD = preambleReceivedTargetPower_SBFD + DELTA_PREAMBLE_SBFD You can send PRACH by setting it. If PRACH transmission fails (if a Random access response (RAR) is not received within the RAR window), the terminal can retransmit PRACH from the SBFD RO. In this case, PREAMBLE_POWER_RAMPING_COUNTER_SBFD can be incremented by 1.

[0370] According to the present disclosure, a terminal may perform an arbitrary connection by selecting one of a legacy RO and / or an SBFD RO. For example, if the terminal performs an arbitrary connection by selecting a legacy RO, the terminal may perform an initial transmission and retransmission of PRACH on the legacy RO. However, in this case, the terminal cannot retransmit PRACH on the SBFD RO. For example, if the terminal performs an arbitrary connection by selecting an SBFD RO, the terminal may perform an initial transmission and retransmission of PRACH on the SBFD RO. However, in this case, the terminal cannot retransmit PRACH on the legacy RO.

[0371] However, the terminal may transmit the HARQ-ACKs for msg3 PUSCH and msg4 PDSCH in SBFD and non-SBFD symbols. For example, the terminal may select a legacy RO to transmit PRACH, and the HARQ-ACKs for msg3 PUSCH and msg4 PDSCH may be transmitted in SBFD symbols. For example, the terminal may select an SBFD RO to transmit PRACH, and the HARQ-ACKs for msg3 PUSCH and msg4 PDSCH may be transmitted in non-SBFD symbols. In this case, a method is required to determine the transmission power of the HARQ-ACKs for msg3 PUSCH and msg4 PDSCH.

[0372] More specifically, the method for determining the transmission power of msg3 PUSCH is as follows.

[0373] [Mathematical Formula 5]

[0374]

[0375] Here, for msg3 PUSCH, j=0 and l=0.

[0376] - can be the maximum output power value set for the terminal at the transmission occasion i of the carrier wave f of cell c.

[0377] - may be a path loss value measured from a downlink path loss reference signal corresponding to the uplink BWP b of the carrier f of cell c. Path loss can be calculated as referenceSignalPower-higher layer filtered RSRP (reference signal received power). Here, referenceSignalPower is a value set by the base station for the terminal and may be included in SIB1. Higher layer filtered RSRP may be a value obtained by filtering the RSRP value measured from the path loss reference signal. Here, the path loss reference signal may be an SSB or CSI-RS.

[0378] - is a path loss compensation index, which may be a value (msg3-Alpha or msg3-Alpha_SBFD) set by the base station for the terminal. If no value is set, It could be.

[0379] - can be the number of RBs scheduled for PUSCH, and can be a value corresponding to the subcarrier interval.

[0380] - can be a power value controlled according to the bits per RE (resource element) of PUSCH.

[0381] - may be a value associated with the PUSCH's received power target. It appears as, and in the case of msg3 PUCH, It could be. Furthermore, It can be represented as, may be a value set by the base station for the terminal (msg3-DeltaPreamble or msg3-DeltaPreamble_SBFD). may be a value set by the base station for the terminal (preambleReceivedTargetPower or preambleReceivedTargetPower_SBFD).

[0382] - can be a closed-loop power control value. In the initial msg3 PUSCH transmission plan (i=0), It can be expressed as. Here can be the TPC command value specified in the RAR UL grant scheduling msg3 PUSCH. It can be determined by the following mathematical formula 6.

[0383] [Mathematical Formula 6]

[0384]

[0385] Here is the total power value used for power ramping of PRACH in the upper layer, which can be (PREAMBLE_POWER_RAMPING_COUNTER-1) * PREAMBLE_POWER_RAMPING_STEP or (PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1) * PREAMBLE_POWER_RAMPING_STEP_SBFD. For reference, (PREAMBLE_POWER_RAMPING_COUNTER-1) * PREAMBLE_POWER_RAMPING_STEP is the total power value used for power ramping when PRACH is transmitted from the legacy RO, and (PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1) * PREAMBLE_POWER_RAMPING_STEP_SBFD is the total power value used for power ramping when PRACH is transmitted from the SBFD RO.

[0386] When determining the power of Msg3 PUSCH, at least the following must be determined.

[0387] 1) To determine the value of, decide which value to use: msg3-Alpha or msg3-Alpha_SBFD.

[0388] 2) To determine, decide which value to use between msg3-DeltaPreamble or msg3-DeltaPreamble_SBFD.

[0389] 3) To determine, decide which value to use between preambleReceivedTargetPower or preambleReceivedTargetPower_SBFD.

[0390] 4) To determine, decide which value to use between (PREAMBLE_POWER_RAMPING_COUNTER-1) * PREAMBLE_POWER_RAMPING_STEP or (PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1) * PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0391] For reference, the terminal can obtain msg3-Alpha, msg3-Alpha_SBFD, msg3-DeltaPreamble, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower, preambleReceivedTargetPower_SBFD, PREAMBLE_POWER_RAMPING_STEP, and PREAMBLE_POWER_RAMPING_STEP_SBFD from the base station settings (e.g., SIB1). However, since the terminal initializes and retransmits PRACH with only one RO type (either Legacy RO or SBFD RO), it can only have one value between PREAMBLE_POWER_RAMPING_COUNTER and PREAMBLE_POWER_RAMPING_COUNTER_SBFD. For example, a terminal that initializes and retransmits PRACH to a legacy RO may have PREAMBLE_POWER_RAMPING_COUNTER, but may not have PREAMBLE_POWER_RAMPING_COUNTER_SBFD. For example, a terminal that initializes and retransmits PRACH to an SBFD RO may have PREAMBLE_POWER_RAMPING_COUNTER_SBFD, but may not have PREAMBLE_POWER_RAMPING_COUNTER.

[0392] Figure 14 is a diagram illustrating scenarios according to the RO transmission type and the transmission symbol type of msg3 PUSCH.

[0393] Referring to FIG. 14, the RO to which the terminal transmits PRACH may be a legacy RO (Scenario A and Scenario B) or an SBFD RO (Scenario C and Scenario D). Also, msg3 PUSCH may be transmitted in a non-SBFD symbol (Scenario A and Scenario C) or in an SBFD symbol (Scenario B and Scenario D).

[0394] Referring to Scenario A of Fig. 14, the terminal can initially transmit and retransmit PRACH from the legacy RO, and transmit msg3 PUSCH from non-SBFD symbols.

[0395] Referring to Scenario B of Fig. 14, the terminal can initially transmit and retransmit PRACH from the legacy RO, and transmit msg3 PUSCH from the SBFD symbol.

[0396] Referring to Scenario C of Fig. 14, the terminal can initially transmit and retransmit PRACH from the SBFD RO, and transmit msg3 PUSCH from a non-SBFD symbol.

[0397] Referring to Scenario D of Fig. 14, the terminal can initially transmit and retransmit PRACH from the SBFD RO, and transmit msg3 PUSCH from the SBFD symbol.

[0398] A method for determining the power of Msg3 PUSCH in each scenario is disclosed. For reference, in the case of scenarios A and D, since PRACH transmission and msg3 PUSCH transmission are performed in the same symbol type, the power of msg3 PUSCH can be determined using a setting value and a power ramping counter (PREAMBLE_POWER_RAMPING_COUNTER or PREAMBLE_POWER_RAMPING_COUNTER_SBFD) corresponding to each symbol type. For example, in the case of scenario A, since PRACH transmission and msg3 PUSCH transmission are performed in a Non-SBFD symbol, the power of msg3 PUSCH can be determined based on a setting value and a power ramping counter (PREAMBLE_POWER_RAMPING_COUNTER) corresponding to the Non-SBFD symbol type. In the case of Scenario D, since PRACH transmission and msg3 PUSCH transmission are performed in the SBFD symbol, the power of msg3 PUSCH can be determined based on the setting value corresponding to the SBFD symbol type and the power ramping counter (PREAMBLE_POWER_RAMPING_COUNTER_SBFD).

[0399] However, for Scenario B or Scenario C, when determining the power of msg3 PUSCH, you must determine which symbol type's corresponding setting value and power ramping counter value to use. In the following description, the power ramping counter value is PREAMBLE_POWER_RAMPING_COUNTER or PREAMBLE_POWER_RAMPING_COUNTER_SBFD.

[0400] [Method 1: Determining Power Parameters and Power Ramping Counter Values ​​Based on Connected RO Type]

[0401] In the first method of the present disclosure, a terminal can determine power parameters based on a connected RO type. The terminal can perform initial transmission and retransmission of PRACH by selecting one of an RO type, either a legacy RO or an SBFD RO. The terminal can determine an RO and a type of RO corresponding to a RAR UL grant that schedules msg3 PUSCH. The power of msg3 PUSCH can be determined based on a power parameter value corresponding to the type of RO.

[0402] For example, when the terminal initially transmits and retransmits PRACH from the legacy RO, the RAR UL grant received by the terminal may correspond to the legacy RO. When determining the power of msg3 PUSCH, the terminal may determine the power of msg3 PUSCH based on the value of the setting (first PRACH setting) corresponding to the legacy RO. Here, the value of the setting (first PRACH setting) corresponding to the legacy RO may include at least one of msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP.

[0403] For example, when the terminal initially transmits and retransmits PRACH from the SBFD RO, the RAR UL grant received by the terminal may correspond to the SBFD RO. When determining the power of msg3 PUSCH, the terminal may determine the power of msg3 PUSCH based on the value of the setting (second PRACH setting) corresponding to the SBFD RO. Here, the value of the setting (second PRACH setting) corresponding to the SBFD RO may include at least one of msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0404] In the first method of the present disclosure, the terminal can determine a power ramping counter value based on the connected RO type. For reference, the terminal may have a power ramping counter value corresponding to the connected RO type.

[0405] For example, when the terminal initially transmits and retransmits PRACH from the legacy RO, the RAR UL grant received by the terminal may correspond to the legacy RO. When determining the power of msg3 PUSCH, the terminal may use the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER) obtained by initially transmitting and retransmitting PRACH from the legacy RO. More specifically, according to [Equation 6], the terminal When deciding, can be the total power value of power ramping during PRACH transmission in legacy RO ((PREAMBLE_POWER_RAMPING_COUNTER-1)*PREAMBLE_POWER_RAMPING_STEP).

[0406] For example, when the terminal initially transmits and retransmits PRACH from the SBFD RO, the RAR UL grant received by the terminal may correspond to the SBFD RO. When determining the power of msg3 PUSCH, the terminal may use the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) obtained by initially transmitting and retransmitting PRACH from the SBFD RO. More specifically, according to [Equation 6], the terminal When deciding, can be the total power value of power ramping during PRACH transmission in SBFD RO ((PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1)*PREAMBLE_POWER_RAMPING_STEP_SBFD).

[0407] According to the first method, the transmission power of msg3 PUSCH is determined based on the type of RO corresponding to msg3 PUSCH, regardless of which symbol type msg3 PUSCH is transmitted.

[0408] FIG. 15 is a diagram showing the transmission power of msg3 PUSCH according to the first method of the present disclosure.

[0409] Referring to FIG. 15, the terminal connects to the SBFD RO and can receive a scheduled msg3 PUSCH in a non-SBFD symbol (Scenario C). According to the first method of the present disclosure, the transmission power of the msg3 PUSCH can be determined using power parameter values ​​(msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, PREAMBLE_POWER_RAMPING_STEP_SBFD) and a power ramping counter (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) corresponding to the SBFD RO. In this case, the parameters and the power ramping counter are values ​​suitable for the interference (inter-base station interference), antenna structure, channel conditions, and the PRACH format of the SBFD symbol, but may not be suitable for a non-SBFD symbol. Therefore, the transmission power of the determined msg3 PUSCH is suitable for SBFD symbols but may be unsuitable for non-SBFD symbols. For example, in FIG. 15, if preambleReceivedTargetPower_SBFD is a relatively larger value than preambleReceivedTargetPower ( Preparation (If this is a relatively large value), the transmission power of msg3 PUSCH transmitted in non-SBFD symbols can be relatively large. Therefore, msg3 PUSCH in non-SBFD symbols can cause significant interference.

[0410] FIG. 16 is a flowchart for determining the power of msg3 PUSCH according to the first method of the present disclosure.

[0411] In the first step (1600), the terminal can select one of the legacy RO or SBFD RO and transmit PRACH. If the terminal selects the legacy RO and transmits and retransmits PRACH, the symbol type corresponding to the legacy RO may be a non-SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (first PRACH setting) corresponding to the legacy RO. If the terminal selects the SBFD RO and transmits and retransmits PRACH, the symbol type corresponding to the SBFD RO may be an SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (second PRACH setting) corresponding to the SBFD RO.

[0412] In the second step (1610), the terminal may receive a RAR UL grant from the base station and obtain scheduling information for msg3 PUSCH from the RAR UL grant. The scheduling information for msg3 PUSCH may include a frequency hopping flag indicating whether frequency hopping is performed, frequency resource allocation, start resource allocation, and TPC command. The terminal may determine the transmission power of msg3 PUSCH based on a PRACH setting and power ramping value corresponding to the RO used for PRACH transmission in the first step (1600). For example, if the terminal uses a legacy RO for initial transmission and retransmission of PRACH, the transmission power of msg3 PUSCH may be determined based on the first PRACH setting. If the terminal uses an SBFD RO for initial transmission and retransmission of PRACH, the transmission power of msg3 PUSCH may be determined based on the second PRACH setting.

[0413] In the third step (1810), the terminal can transmit msg3 PUSCH to the base station based on the transmission power of the determined msg3 PUSCH.

[0414] [Method 2: Determining Power Parameters and Power Ramping Counter Values ​​Based on msg3 PUSCH Symbol Type]

[0415] In the second method of the present disclosure, the terminal can determine a power parameter based on the type of symbol to which msg3 PUSCH is scheduled. The terminal can perform initial transmission and retransmission of PRACH by selecting one RO type from legacy RO and SBFD RO. The terminal can schedule msg3 PUSCH with a RAR UL grant. In this case, the RAR UL grant can schedule msg3 PUSCH to one of SBFD symbols or non-SBFD symbols. The terminal can determine the power of msg3 PUSCH based on a power parameter value corresponding to the type of symbol to which msg3 PUSCH is scheduled.

[0416] For example, when the terminal determines the power of msg3 PUSCH in a non-SBFD symbol, it may determine the power of msg3 PUSCH based on the value of a setting corresponding to the legacy RO (first PRACH setting). Here, the value of the setting corresponding to the legacy RO (first PRACH setting) may include at least one of msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP.

[0417] For example, when the terminal determines the power of msg3 PUSCH in the SBFD symbol, the power of msg3 PUSCH can be determined based on the value of the setting (second PRACH setting) corresponding to the SBFD RO. Here, the value of the setting (second PRACH setting) corresponding to the SBFD RO may include at least one of msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0418] In the second method of the present disclosure, the terminal may use a power ramping counter value corresponding to a symbol for which msg3 PUSCH is scheduled to determine the msg3 PUSCH transmission power. If the terminal does not have a power ramping counter value corresponding to a symbol for which msg3 PUSCH is scheduled to be scheduled, the terminal may consider the power ramping counter value to be '1'.

[0419] For example, when the terminal initializes and retransmits PRACH from the legacy RO, the terminal may have a power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER) obtained by initializing and retransmitting PRACH from the legacy RO. If msg3 PUSCH is scheduled on a non-SBFD symbol (Scenario A), the terminal may determine the transmission power of msg3 PUSCH based on the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER). More specifically, the terminal [according to Equation 6] When deciding, can be the total power value of power ramping during PRACH transmission in legacy RO ((PREAMBLE_POWER_RAMPING_COUNTER-1)*PREAMBLE_POWER_RAMPING_STEP).

[0420] For example, when the terminal initializes and retransmits PRACH from a legacy RO, the terminal may have a power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER) obtained by initializing and retransmitting PRACH from the legacy RO. If msg3 PUSCH is scheduled on an SBFD symbol (Scenario B), the terminal may consider the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) for the SBFD RO to be '1'. Therefore, the terminal can determine the transmission power of msg3 PUSCH based on the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD = 1). More specifically, according to [Equation 6], the terminal When deciding, ((PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1)*PREAMBLE_POWER_RAMPING_STEP_SBFD) = 0. That is, can be considered as 0.

[0421] For example, when the terminal initializes and retransmits PRACH on the SBFD RO, the terminal may have a power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) obtained by initializing and retransmitting PRACH on the SBFD RO. If msg3 PUSCH is scheduled on the SBFD symbol (Scenario D), the terminal may determine the transmission power of msg3 PUSCH based on the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD). More specifically, the terminal [according to Equation 6] When deciding, can be the total power value of power ramping during PRACH transmission in SBFD RO ((PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1)*PREAMBLE_POWER_RAMPING_STEP_SBFD).

[0422] For example, when the terminal initializes and retransmits PRACH on an SBFD RO, the terminal may have a power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) obtained by initializing and retransmitting PRACH on the SBFD RO. If msg3 PUSCH is scheduled on a non-SBFD symbol (Scenario C), the terminal may consider the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER) for the legacy RO to be '1'. Therefore, the terminal can determine the transmission power of msg3 PUSCH based on the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER = 1). More specifically, according to [Equation 6], the terminal When deciding, ((PREAMBLE_POWER_RAMPING_COUNTER-1)*PREAMBLE_POWER_RAMPING_STEP) = 0. That is, can be considered as 0.

[0423] In one method of the present disclosure, when determining the transmission power of msg3 PUSCH, msg3-DeltaPreamble to msg3-DeltaPreamble_SBFD may be considered as '0'. This may be applied when at least one of the following conditions is satisfied.

[0424] - When the type of the scheduled symbol for the connected RO and msg3 PUSCH is different, (Scenario B and Scenario C)

[0425] - When the types of scheduled symbols of the connected RO and msg3 PUSCH are different ((Scenario B and Scenario C)), and the types of the PRACH preamble of the legacy RO and SBFD RO are different,

[0426] According to the second method, regardless of the type of RO connected to the terminal, the transmission power of msg3 PUSCH is determined based on the type of symbol for which msg3 PUSCH is scheduled.

[0427] FIG. 17 is a diagram showing the transmission power of msg3 PUSCH according to the second method of the present disclosure.

[0428] Referring to FIG. 17, the terminal connects to the SBFD RO and can receive a msg3 PUSCH scheduled for a non-SBFD symbol (Scenario C). According to the second method of the present disclosure, a setting value corresponding to the symbol for which the msg3 PUSCH is scheduled is used. Thus, when the msg3 PUSCH is scheduled for a non-SBFD symbol, the transmission power of the msg3 PUSCH is determined based on msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP included in the setting of the legacy RO (first PRACH setting). Thus, transmission power parameters suitable for the symbol for which the msg3 PUSCH is scheduled can be used. However, if the type of the connected RO is different from the symbol to which msg3 PUSCH is scheduled (i.e., msg3 PUSCH is scheduled to the SBFD symbol, but the connected RO is a legacy RO), the terminal uses '0' as the power ramping value, so the power increase amount according to power ramping may not be applied to msg3 PUSCH.

[0429] FIG. 18 is a flowchart for determining the power of msg3 PUSCH according to the second method of the present disclosure.

[0430] In the first step (1800), the terminal can select one of the legacy RO or SBFD RO and transmit PRACH. If the terminal selects the legacy RO and transmits and retransmits PRACH, the symbol type corresponding to the legacy RO may be a non-SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (first PRACH setting) corresponding to the legacy RO. If the terminal selects the SBFD RO and transmits and retransmits PRACH, the symbol type corresponding to the SBFD RO may be an SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (second PRACH setting) corresponding to the SBFD RO.

[0431] In the second step (1810), the terminal may receive a RAR UL grant from the base station and obtain scheduling information for msg3 PUSCH from the RAR UL grant. The scheduling information for msg3 PUSCH may include a frequency hopping flag indicating whether frequency hopping is performed, frequency resource allocation, start resource allocation, and TPC command. The terminal may determine the transmission power of msg3 PUSCH based on a PRACH setting and a power ramping value corresponding to the symbol type for which msg3 PUSCH is scheduled. For example, if the symbol for which msg3 PUSCH is scheduled is a non-SBFD symbol, the transmission power of msg3 PUSCH may be determined based on the first PRACH setting. If the symbol for which msg3 PUSCH is scheduled is an SBFD symbol, the transmission power of msg3 PUSCH may be determined based on the second PRACH setting.

[0432] If the symbol type corresponding to the RO selected in the first step (1800) and the symbol type scheduled for msg3 PUSCH are different, the terminal may consider '0' as the power ramping value when determining the transmission power of msg3 PUSCH.

[0433] In the third step (1610), the terminal can transmit msg3 PUSCH to the base station based on the transmission power of the determined msg3 PUSCH.

[0434] [Method 3: Determine power parameters based on msg3 PUSCH symbol type and determine power ramping counter value based on connected RO type]

[0435] In the third method of the present disclosure, the terminal can determine a power parameter based on the type of symbol to which msg3 PUSCH is scheduled. The terminal can perform initial transmission and retransmission of PRACH by selecting one RO type from legacy RO and SBFD RO. The terminal can schedule msg3 PUSCH with a RAR UL grant. In this case, the RAR UL grant can schedule msg3 PUSCH to one of SBFD symbols or non-SBFD symbols. The terminal can determine the power of msg3 PUSCH based on a power parameter value corresponding to the type of symbol to which msg3 PUSCH is scheduled.

[0436] For example, when the terminal determines the power of msg3 PUSCH in a non-SBFD symbol, it may determine the power of msg3 PUSCH based on the value of a setting corresponding to the legacy RO (first PRACH setting). Here, the value of the setting corresponding to the legacy RO (first PRACH setting) may include at least one of msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP.

[0437] For example, when the terminal determines the power of msg3 PUSCH in the SBFD symbol, the power of msg3 PUSCH can be determined based on the value of the setting (second PRACH setting) corresponding to the SBFD RO. Here, the value of the setting (second PRACH setting) corresponding to the SBFD RO may include at least one of msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0438] In the third method of the present disclosure, the terminal can determine a power ramping counter value based on the connected RO type. For reference, the terminal may have a power ramping counter value corresponding to the connected RO type.

[0439] For example, when the terminal initially transmits and retransmits PRACH from the legacy RO, the RAR UL grant received by the terminal may correspond to the legacy RO. When determining the power of msg3 PUSCH, the terminal may use the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER) obtained by initially transmitting and retransmitting PRACH from the legacy RO. More specifically, according to [Equation 6], the terminal When deciding, can be the total power value of power ramping during PRACH transmission in legacy RO ((PREAMBLE_POWER_RAMPING_COUNTER-1)*PREAMBLE_POWER_RAMPING_STEP).

[0440] For example, when the terminal initially transmits and retransmits PRACH from the SBFD RO, the RAR UL grant received by the terminal may correspond to the SBFD RO. When determining the power of msg3 PUSCH, the terminal may use the power ramping counter value (PREAMBLE_POWER_RAMPING_COUNTER_SBFD) obtained by initially transmitting and retransmitting PRACH from the SBFD RO. More specifically, according to [Equation 6], the terminal When deciding, can be the total power value of power ramping during PRACH transmission in SBFD RO ((PREAMBLE_POWER_RAMPING_COUNTER_SBFD-1)*PREAMBLE_POWER_RAMPING_STEP_SBFD).

[0441] In one method of the present disclosure, when determining the transmission power of msg3 PUSCH, msg3-DeltaPreamble to msg3-DeltaPreamble_SBFD may be considered as '0'. This may be applied when at least one of the following conditions is satisfied.

[0442] - When the type of the scheduled symbol for the connected RO and msg3 PUSCH is different, (Scenario B and Scenario C)

[0443] - When the types of scheduled symbols of the connected RO and msg3 PUSCH are different ((Scenario B and Scenario C)), and the types of the PRACH preamble of the legacy RO and SBFD RO are different,

[0444] According to the third method, the terminal uses a corresponding setting value for the transmission power of msg3 PUSCH according to the type of symbol scheduled in msg3 PUSCH, and a power ramping counter value can be used based on the RO type used for connection.

[0445] FIG. 19 is a diagram showing the transmission power of msg3 PUSCH according to the third method of the present disclosure.

[0446] Referring to FIG. 19, the terminal connects to an SBFD RO and can receive a msg3 PUSCH scheduled for a non-SBFD symbol (Scenario C). According to the third method of the present disclosure, a setting value corresponding to the symbol to which the msg3 PUSCH is scheduled is used. Accordingly, when the msg3 PUSCH is scheduled for a non-SBFD symbol, the transmission power of the msg3 PUSCH is determined based on msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP included in the setting of the legacy RO (first PRACH setting). Accordingly, transmission power parameters suitable for the symbol to which the msg3 PUSCH is scheduled can be used. In addition, since a power ramping value corresponding to the type of the connected RO is used, the power ramping value can also be used to determine the power of the msg3 PUSCH.

[0447] FIG. 20 is a flowchart for determining the power of msg3 PUSCH according to the third method of the present disclosure.

[0448] In the first step (2000), the terminal can select one of the legacy RO or SBFD RO and transmit PRACH. If the terminal selects the legacy RO and transmits and retransmits PRACH, the symbol type corresponding to the legacy RO may be a non-SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (first PRACH setting) corresponding to the legacy RO. If the terminal selects the SBFD RO and transmits and retransmits PRACH, the symbol type corresponding to the SBFD RO may be an SBFD symbol type. Then, the terminal can determine the transmission power of PRACH based on the PRACH setting (second PRACH setting) corresponding to the SBFD RO.

[0449] In the second step (2010), the terminal may receive a RAR UL grant from the base station and obtain scheduling information for msg3 PUSCH from the RAR UL grant. The scheduling information for msg3 PUSCH may include a frequency hopping flag indicating whether frequency hopping is performed, frequency resource allocation, start resource allocation, and TPC command. The terminal may determine the transmission power of msg3 PUSCH based on a PRACH setting corresponding to the symbol type for which msg3 PUSCH is scheduled. For example, if the symbol for which msg3 PUSCH is scheduled is a non-SBFD symbol, the transmission power of msg3 PUSCH may be determined based on a first PRACH setting. If the symbol for which msg3 PUSCH is scheduled is an SBFD symbol, the transmission power of msg3 PUSCH may be determined based on a second PRACH setting.

[0450] And, the PRACH transmission power can be determined based on the power ramping value corresponding to the symbol type corresponding to the RO selected in the first step (2000).

[0451] In the third step (2010), the terminal can transmit msg3 PUSCH to the base station based on the transmission power of the determined msg3 PUSCH.

[0452] [Method 4: Power determination based on the maximum or minimum transmission power of the two symbol types msg3 PUSCH]

[0453] In the fourth method of the present disclosure, the terminal can determine the transmission power of msg3 PUSCH based on the maximum or minimum value among the transmission power determined by the setting corresponding to the legacy RO (first PRACH setting) and the transmission power determined by the setting corresponding to the SBFD RO (second PRACH setting).

[0454] Here, the transmission power determined by the setting corresponding to the legacy RO (first PRACH setting) may be the transmission power determined based on msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP.

[0455] Here, the transmission power determined by the setting corresponding to the SBFD RO (the second PRACH setting) may be the transmission power determined based on msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0456] The power ramping value can be included only in the transmission power determined by the setting corresponding to one RO.

[0457] When the terminal connects to the legacy RO, the power ramping value may be included in the transmission power determined by the setting corresponding to the legacy RO (the first PRACH setting). And in the transmission power determined by the setting corresponding to the SBFD RO (the second PRACH setting), the power ramping value ( It can be considered as '0'.

[0458] When the terminal connects to the SBFD RO, the power ramping value may be included in the transmission power determined by the setting corresponding to the SBFD RO (the second PRACH setting). And in the transmission power determined by the setting corresponding to the legacy RO (the first PRACH setting), the power ramping value ( It can be considered as '0'.

[0459] The power ramping value can be applied commonly to the transmission power corresponding to the two RO types. That is, when a terminal connects to a legacy RO, when determining the transmission power corresponding to each of the two RO types, the power ramping value ( (PREAMBLE_POWER_RAMPING_COUNTER -1)*PREAMBLE_POWER_RAMPING_STEP can be used. When the terminal is connected via SBFD RO, when determining the transmission power corresponding to each of the two RO types, the power ramping value ( You can use (PREAMBLE_POWER_RAMPING_COUNTER_SBFD -1)*PREAMBLE_POWER_RAMPING_STEP_SBFD as ).

[0460] In one embodiment of the present disclosure, one of the first to fourth methods may be determined according to the settings of the base station. For example, according to the RACH settings of the base station, the terminal may determine the following two options, and the terminal may use a method corresponding to said option.

[0461] Here, the first option is a case where the base station provides the terminal with multiple information elements (IEs) for the PRACH setting. Here, the terminal may receive two separate IEs for the PRACH setting from the base station, determine one IE as the first PRACH setting, and determine the other IE as the second PRACH setting.

[0462] Here, the second option is when the base station provides one IE for a PRACH setting to the terminal. In the one IE, power parameters for SBFD RO (e.g., PREAMBLE_POWER_RAMPING_COUNTER_SBFD) may be additionally set. Here, the terminal may receive one IE for a PRACH setting from the base station, determine one IE as the first PRACH setting, and the second PRACH setting may be identical to the first PRACH setting but use power parameters for SBFD RO.

[0463] When the terminal determines that it is the first option, the terminal can determine the transmission power of msg3 PUSCH based on the first method. That is, when the terminal selects and transmits an RO type (legacy RO or SBFD RO) according to the PRACH setting corresponding to one IE, the terminal can determine the transmission power of msg3 PUSCH using only the upper layer parameters set in the said one IE.

[0464] When the terminal determines that it is the second option, the terminal can determine the transmission power of msg3 PUSCH based on at least one of the second method, the third method, or the fourth method. That is, in the case of the second option, since multiple PRACH settings are determined based on one IE, the values ​​of power parameters corresponding to the first PRACH setting and the second PRACH setting may all be included in the one IE. Accordingly, the terminal can determine the transmission power of msg3 PUSCH by selecting or combining the values ​​of power parameters corresponding to the first PRACH setting and the second PRACH setting.

[0465] [Method 5: Modifying the TPC command table]

[0466] When the terminal receives the initial transmission of msg3 PUSCH from the base station, it may be instructed to a TPC command value. Referring to Equation 6, may be a TPC command value specified in the RAR UL grant that schedules msg3 PUSCH. The RAR UL grant may specify the TPC command value using 3 bits. The TPC command values ​​corresponding to these 3 bits are shown in Table 17. Referring to Table 17, the TPC command values ​​that can be specified in the RAR UL grant may be in 2dB increments from -6dB to 8dB.

[0467] When the type of connected RO and the type of symbol for which msg3 PUSCH is scheduled are different (Scenario B, Scenario C), the base station can perform closed-loop power control based on the TPC command of the RAR UL grant. For example, if the transmission power of msg3 PUSCH determined in a non-SBFD symbol is high, the base station can reduce the transmission power based on the TPC command. However, it may be necessary to instruct a value larger than the range of values ​​of the TPC command in Table 17. A method for this is disclosed.

[0468] The terminal can determine the TPC command table based on the type of the connected RO and the type of the symbol scheduled for msg3 PUSCH. For example, if the type of the connected RO and the symbol scheduled for msg3 PUSCH are the same (Scenario A, Scenario D), the terminal can perform TPC command interpretation based on Table 17. If the type of the connected RO and the type of the symbol scheduled for msg3 PUSCH are different (Scenario B, Scenario C), the terminal can perform TPC command interpretation based on Table 18. In Table 18, the value of X can be greater than 2. For example, X can have a value of 3 or 4. Table 18 is an example, and the table for TPC command interpretation may be determined differently from Table 18.

[0469] [Table 17]

[0470]

[0471] [Table 18]

[0472]

[0473] [Method 6: Instructions for PRACH setting values ​​to use in RAR UL grant]

[0474] In the sixth method of the present disclosure, the terminal may be instructed by the base station to use a PRACH setting value when determining the transmission power of msg3 PUSCH. The terminal may determine which PRACH setting value to use for determining the transmission power of msg3 PUSCH based on a RAR UL grant that schedules msg3 PUSCH.

[0475] According to one example, some bits among the bits included in the RAR UL grant may indicate at least one of the first PRACH setting or the second PRACH setting. The said some bits may use the CSI request 1 bit among the bits included in the RAR UL grant. Alternatively, the said some bits may use 1 bit of a 3-bit TPC command (e.g., the most significant bit, MSB). Alternatively, the said some bits may use 1 bit of a 14-bit PUSCH frequency resource allocation field (e.g., the most significant bit, MSB excluding bits indicating hopping).

[0476] More specifically, if the type of the connected RO and the type of the symbol scheduled by msg3 PUSCH are different, the terminal obtains 1 bit from the RAR UL grant, and the said 1 bit can determine the transmission power based on a certain PRACH setting. If the type of the connected RO and the type of the symbol scheduled by msg3 PUSCH are the same, the terminal may not obtain the said 1 bit from the RAR UL grant. That is, if the type of the connected RO and the type of the symbol scheduled by msg3 PUSCH are the same, 1 bit in the TPC command or PUSCH frequency resource allocation field can be used for conventional purposes.

[0477] In a 3-bit TPC command, if 1 bit is used to indicate which PRACH setting value to use for determining the transmission power of msg3 PUSCH, the remaining 2 bits may be used to indicate the TPC command value. Here, the value of the TPC command indicated by the 2 bits may be as shown in Table 19. Here, X may be a positive integer. Table 19 is an example, and the value of the TPC command indicated by the 2 bits may be determined differently from Table 19.

[0478] [Table 19]

[0479]

[0480] [Method 7: msg3 PUSCH transmission possible with the same symbol type as RO type]

[0481] In the seventh method of the present disclosure, the terminal can expect to receive a msg3 PUSCH scheduled with the same symbol type as the connected RO type. That is, if the terminal performs the initial transmission and retransmission of PRACH with the legacy RO type, and a msg3 PUSCH is scheduled for a non-SBFD symbol, the terminal may consider the msg3 PUSCH for the non-SBFD symbol as a valid scheduling and transmit the msg3 PUSCH from the non-SBFD symbol to the base station. However, if the terminal performs the initial transmission and retransmission of PRACH with the legacy RO type, and a msg3 PUSCH is scheduled for an SBFD symbol, the terminal may consider the msg3 PUSCH for the SBFD symbol as an invalid scheduling and retransmit PRACH. Here, the retransmission of PRACH may be transmitted from the legacy RO type. If the terminal performs the initial transmission and retransmission of PRACH in SBFD RO type, and msg3 PUSCH is scheduled for an SBFD symbol, the terminal considers the msg3 PUSCH of the SBFD symbol as a valid scheduling and can transmit msg3 PUSCH from the SBFD symbol to the base station. However, if the terminal performs the initial transmission and retransmission of PRACH in SBFD RO type, and msg3 PUSCH is scheduled for a non-SBFD symbol, the terminal considers the msg3 PUSCH of the non-SBFD symbol as an invalid scheduling and can retransmit PRACH. Here, the retransmission of PRACH can be transmitted in SBFD RO type.

[0482] That is, the terminal can determine the validity of the scheduling based on the type of the connected RO and the type of the symbol scheduled through the RAR UL grant, and if the symbol type of the RO connected to the terminal and the symbol type of the msg3 PUSCH scheduled through the RAR UL grant are different types, the terminal can retransmit PRACH without transmitting msg3 PUSCH. Here, the retransmission of PRACH can be performed on the same type as the connected RO.

[0483] According to the method described above, only scenarios A and D of FIG. 14 may be valid scheduling. In the above scenarios, since only one symbol type corresponds to the RO type and the scheduled symbol for msg3 PUSCH, the transmission power of msg3 PUSCH can be determined based on the setting value of PRACH corresponding to the symbol type (a first PRACH setting in the case of scenario A; a second PRACH setting in the case of scenario D).

[0484] Figure 21 is a diagram illustrating the retransmission of msg3 PUSCH.

[0485] Msg3 PUSCH may be directed to retransmit with DCI format 0_0, where the CRC of DCI format 0_0 may be scrambled with TC-RNTI. Here, the retransmission of Msg3 PUSCH may be scheduled on non-SBFD symbols and may be scheduled on SBFD symbols.

[0486] Referring to FIG. 21(a), the initial transmission of msg3 PUSCH was transmitted on a non-SBFD symbol, but the retransmission of msg3 PUSCH can be scheduled on an SBFD symbol. (Scenario E)

[0487] Referring to FIG. 21(b), the initial transmission of msg3 PUSCH was transmitted on an SBFD symbol, but the retransmission of msg3 PUSCH can be scheduled on a non-SBFD symbol. (Scenario F)

[0488] Thus, when the initial transmission and retransmission of msg3 PUSCH are scheduled for different symbol types, the terminal requires a method to determine the transmission power of the retransmitted msg3 PUSCH. A method for determining the transmission power of msg3 PUSCH during retransmission is disclosed.

[0489] In the first method, the terminal may use the same parameters used to determine the transmission power of the initially transmitted msg3 PUSCH to determine the transmission power of the retransmitted msg3 PUSCH. For example, if the transmission power of the initially transmitted msg3 PUSCH is determined based on the values ​​of msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP, which are the values ​​of the setting corresponding to the legacy RO (the first PRACH setting), the transmission power of the retransmitted msg3 PUSCH may be determined based on the same values ​​of msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP, which are the values ​​of the setting corresponding to the legacy RO (the first PRACH setting). For example, if the transmission power of the initially transmitted msg3 PUSCH is determined based on the values ​​of the settings (second PRACH settings) corresponding to the SBFD RO, such as msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD, the transmission power of the retransmitted msg3 PUSCH can be determined based on the values ​​of the settings (second PRACH settings) corresponding to the SBFD RO, such as msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0490] In a second method, the terminal can use the retransmitted msg3 PUSCH to determine the transmission power of the retransmitted msg3 PUSCH based on the symbol type to which the retransmitted msg3 PUSCH is scheduled. For example, if the retransmitted msg3 PUSCH is scheduled for a non-SBFD symbol, the transmission power of the msg3 PUSCH can be determined based on msg3-Alpha, msg3-DeltaPreamble, preambleReceivedTargetPower, and PREAMBLE_POWER_RAMPING_STEP, which are the values ​​of the legacy RO settings (first PRACH settings) corresponding to the non-SBFD symbol. For example, when a retransmitted msg3 PUSCH is scheduled to an SBFD symbol, the transmission power of msg3 PUSCH can be determined based on the values ​​of the SBFD RO settings (second PRACH settings) corresponding to the SBFD symbol, namely msg3-Alpha_SBFD, msg3-DeltaPreamble_SBFD, preambleReceivedTargetPower_SBFD, and PREAMBLE_POWER_RAMPING_STEP_SBFD.

[0491] The terminal can obtain the value of a TPC command from DCI format 0_0, which instructs the retransmission of msg3 PUSCH. The value of the TPC command can be added to the transmission power of the previous msg3 PUSCH. More specifically, in Equation 5, the transmission power value of msg3 PUSCH is It can be determined based on, and the above It can be determined as. Here may be the value of the TPC command obtained from DCI format 0_0. That is, the transmission power value of msg3 PUSCH scheduled at transmission opportunity i is It can be determined based on, and the above The value is transmission opportunity i-i0's and TPC commands specified in the received DCI format ( It can be determined as the sum of ). In this way The value of previous The method of adding TPC commands to it can be called accumulating TPC.

[0492] According to the present disclosure, a terminal may transmit the initial transmission of msg3 PUSCH in non-SBFD symbols and transmit the retransmission of msg3 PUSCH in SBFD symbols. Conversely, the terminal may transmit the initial transmission of msg3 PUSCH in SBFD symbols and transmit the retransmission of msg3 PUSCH in non-SBFD symbols. The terminal may apply an accumulate TPC to both symbol types in common or individually.

[0493] More specifically, when msg3 PUSCH is scheduled on a non-SBFD symbol, the terminal, when determining the transmit power of msg3 PUSCH, based on the TPC command specified in DCI format 0_0 that transmitted msg3 PUSCH on the non-SBFD symbol It can be determined. However, the TPC command indicated in DCI format 0_0 that sent msg3 PUSCH to the SBFD symbol may be ignored.

[0494] More specifically, when msg3 PUSCH is scheduled for an SBFD symbol, the terminal, when determining the transmit power of msg3 PUSCH, based on the TPC command specified in DCI format 0_0 that transmitted msg3 PUSCH for the SBFD symbol It can be determined. However, the TPC command indicated in DCI format 0_0 that sent msg3 PUSCH to a non-SBFD symbol may be ignored.

[0495] Alternatively, if the symbol type of the previously scheduled msg3 PUSCH and the symbol type of the newly scheduled msg3 PUSCH are different, the terminal ... can be initialized. Here, being initialized may mean ignoring all TPC commands specified in DCI format 0_0. Accordingly, the terminal can apply accumulated TPC commands for a single symbol type to which msg3 PUSCH is scheduled, but if msg3 PUSCH is scheduled for a different symbol, it can initialize the accumulated TPC commands and perform TPC command accumulation again.

[0496] Each of the methods, including the first to seventh methods described above, may be operated independently of each other, or two or more methods may be combined and operated as needed.

[0497] In the present disclosure, a method for determining the transmission power of msg3 PUSCH has been described in detail. The same method can be applied to determine the transmission power of the HARQ-ACK of msg4 PDSCH. More specifically, when the HARQ-ACK of msg4 PDSCH is transmitted to PUCCH, the transmission power of PUCCH can be determined by Equation 7.

[0498] [Mathematical Formula 7]

[0499]

[0500] Here, It is possible. And, when sending the HARQ-ACK of msg4 PDSCH to PUCCH, It could be. And, can be determined as an upper layer signal, p0-nominal (a setting value included in the first PRACH setting) or p0-nominal_SBFD (a setting value included in the second PRACH setting). Here, the method for determining p0-nominal or p0-nominal_SBFD may be the same as the method for determining one of preambleReceivedTargetPower (a setting value included in the first PRACH setting) or preambleReceivedTargetPower_SBFD (a setting value included in the second PRACH setting) in the method described above.

[0501] For example, by referring to the first method of the present disclosure, the terminal can determine power parameters based on the connected RO type. The terminal can perform initial transmission and retransmission of PRACH by selecting one of the RO types, either a legacy RO or an SBFD RO. The power of PUCCH for HARQ-ACK of msg4 PDSCH can be determined based on the power parameter value corresponding to the RO type. When the terminal performs initial transmission and retransmission of PRACH in the legacy RO, the terminal can determine the power of PUCCH for HARQ-ACK of msg4 PDSCH based on the value of the setting (first PRACH setting) corresponding to the legacy RO. Here, the value of the setting (first PRACH setting) corresponding to the legacy RO may include p0-nominal. For example, when a terminal initially transmits and retransmits PRACH in SBFD RO, the terminal may determine the power of PUCCH for HARQ-ACK of msg4 PDSCH based on the value of a setting (second PRACH setting) corresponding to SBFD RO when determining the power of PUCCH for HARQ-ACK of msg4 PDSCH. Here, the value of the setting (second PRACH setting) corresponding to SBFD RO may include p0-nominal_SBFD.

[0502] For example, by referring to the second and / or third methods of the present disclosure, the terminal may determine a power parameter based on the symbol type of the PUCCH for the HARQ-ACK of the msg4 PDSCH. The terminal may perform initial transmission and retransmission of the PRACH by selecting one of the RO types, either legacy RO or SBFD RO. In this case, the PUCCH for the HARQ-ACK of the msg4 PDSCH may be transmitted in one of the SBFD symbols or non-SBFD symbols. The terminal may determine the power of the PUCCH for the HARQ-ACK of the msg4 PDSCH based on a power parameter value corresponding to the symbol type in which the PUCCH for the HARQ-ACK of the msg4 PDSCH is transmitted. For example, when the terminal determines the power of the PUCCH for the HARQ-ACK of the msg4 PDSCH in a non-SBFD symbol, it may determine the power of the PUCCH for the HARQ-ACK of the msg4 PDSCH based on the value of the setting corresponding to the legacy RO (the first PRACH setting). Here, the value of the setting corresponding to the legacy RO (the first PRACH setting) may include p0-nominal. For example, when the terminal determines the power of the PUCCH for the HARQ-ACK of the msg4 PDSCH in an SBFD symbol, it may determine the power of the PUCCH for the HARQ-ACK of the msg4 PDSCH based on the value of the setting corresponding to the SBFD RO (the second PRACH setting). Here, the value of the setting corresponding to the SBFD RO (the second PRACH setting) may include p0-nominal_SBFD.

[0503] For example, by referring to the fourth method of the present disclosure, the terminal may determine the transmission power of the PUCCH for the HARQ-ACK of the msg4 PDSCH based on the maximum or minimum value among the transmission power determined by the setting corresponding to the legacy RO (first PRACH setting) and the transmission power determined by the setting corresponding to the SBFD RO (second PRACH setting). Here, the transmission power determined by the setting corresponding to the legacy RO (first PRACH setting) may be the transmission power determined based on p0-nominal. Here, the transmission power determined by the setting corresponding to the SBFD RO (second PRACH setting) may be the transmission power determined based on p0-nominal_SBFD.

[0504] For example, by referring to the fifth method of the present disclosure, the terminal can determine a table of TPC commands based on the symbol type of the connected RO and the symbol type of the PUCCH for HARQ-ACK of the msg4 PDSCH. For example, if the symbol type of the connected RO and the symbol type of the PUCCH for HARQ-ACK are the same (Scenario A, Scenario D), the terminal can perform the interpretation of the TPC command based on Table 17. If the symbol type of the connected RO and the symbol type of the PUCCH for HARQ-ACK are different (Scenario B, Scenario C), the terminal can perform the interpretation of the TPC command based on Table 18 or a separate table defined differently from Table 18.

[0505] For example, by referring to the sixth method of the present disclosure, the terminal may be instructed by the base station to use a PRACH setting value to determine the transmission power of the PUCCH for the HARQ-ACK of the msg4 PDSCH. The terminal may determine which PRACH setting value to use to determine the transmission power of the PUCCH for the HARQ-ACK of the msg4 PDSCH based on the DCI format for scheduling the msg4 PDSCH.

[0506] For example, by referring to the seventh method of the present disclosure, the terminal may expect to transmit a PUCCH for a HARQ-ACK of a msg4 PDSCH with the same symbol type as the symbol type of the connected RO.

[0507] Although not explained in detail to avoid duplication of explanation, it should be noted that the content of the first and seventh methods, which were previously explained in detail regarding the determination of the transmission power of msg3 PUSCH, can be equally applied to the transmission power of PUCCH for HARQ-ACK of msg4 PDSCH.

[0508] In the method described above, the terminal can determine p0-nominal_SBFD based on the difference between preambleReceivedTargetPower and preambleReceivedTargetPower_SBFD without separate configuration from the base station. For example, p0-nominal_SBFD = p0-nominal + (preambleReceivedTargetPower_SBFD - preambleReceivedTargetPower). That is, compared to p0-nominal, the power of p0-nominal_SBFD can be increased or decreased by the difference between preambleReceivedTargetPower and preambleReceivedTargetPower_SBFD.

[0509] In the method described above, the terminal can determine p0-nominal_SBFD based on the difference between preambleReceivedTargetPower+msg3-DeltaPreamble and preambleReceivedTargetPower_SBFD+msg3-DeltaPreamble_SBFD without separate configuration from the base station. For example, p0-nominal_SBFD = p0-nominal + (preambleReceivedTargetPower_SBFD + msg3-DeltaPreamble_SBFD - (preambleReceivedTargetPower + msg3-DeltaPreamble_SBFD)). That is, compared to p0-nominal, the power of p0-nominal_SBFD can be increased or decreased by the difference between preambleReceivedTargetPower+msg3-DeltaPreamble and preambleReceivedTargetPower_SBFD + msg3-DeltaPreamble_SBFD.

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

[0511] 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). According to the communication method of the terminal described above, the transceiver (2200, 2210), memory, and terminal processing unit (2205) of the terminal may operate. The terminal processing unit (2205, or processor) may control the operation of the terminal according to each of the embodiments described above, as well as a combination of at least one embodiment. 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.

[0512] 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.

[0513] 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.

[0514] 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.

[0515] In addition, the processor can control a series of processes to enable the terminal to operate according to the aforementioned embodiment. For example, the processor can receive a DCI composed of two layers and control the components of the terminal to receive multiple PDSCHs simultaneously. There may be multiple processors, and the processors can perform the operation of controlling the components of the terminal by executing a program stored in memory.

[0516] 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.

[0517] Referring to FIG. 23, the base station may include a transceiver unit (2300) and a base station transmitter (2310), a memory (not shown), and a base station processing unit (2305, or a base station control unit or processor). According to 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. The base station processing unit (2305, or processor) may control the operation of the base station according to each of the embodiments described above, as well as a combination of at least one embodiment. 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. Furthermore, the transceiver unit, the memory, and the processor may be implemented in the form of a single chip.

[0518] 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.

[0519] 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.

[0520] 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.

[0521] 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 configure two layers of DCIs containing allocation information for a plurality of PDSCHs and to transmit them. 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.

[0522] 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.

[0523] 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.

[0524] 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.

[0525] 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.

[0526] 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.

[0527] 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.

[0528] 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.

[0529] 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.

[0530] 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.

Claims

1. In the method of the terminal, A step of receiving a RAR (random access response) UL (uplink) grant from a base station for scheduling a PUSCH (physical uplink shared channel); A step of identifying the symbol type of the scheduled symbol by the PUSCH based on the RAR UL grant; A step of determining the power of the PUSCH based on the symbol type of the symbol scheduled by the above PUSCH; A method characterized by including the step of transmitting a PUSCH to the base station based on the power of the PUSCH.

2. In Paragraph 1, A method characterized in that the symbol type of the PUSCH scheduled symbol is sub-band full duplex (SBFD) or non-SBFD.

3. In paragraph 1, the above method is: The method further includes the step of transmitting a PUCCH (physical uplink control channel) to the base station, and A method characterized in that the power of the above PUCCH is determined based on the symbol type of the symbol to which the above PUCCH is transmitted.

4. In Paragraph 2, A method characterized in that the power of the above PUSCH is determined based on an Alpha parameter associated with SBFD and a preambleReceivedTargetPower parameter associated with SBFD when the symbol type of the above scheduled symbol is SBFD.

5. Regarding the base station method, A step of transmitting a RAR (random access response) UL (uplink) grant for scheduling a PUSCH (physical uplink shared channel) to a terminal, wherein the symbol type of the symbol for which the PUSCH is scheduled is identified based on the RAR UL grant; The method includes the step of receiving the PUSCH from the terminal, A method characterized in that the power of the above PUSCH is determined based on the symbol type of the symbol to which the above PUSCH is received.

6. In Paragraph 5, A method characterized in that the symbol type of the PUSCH scheduled symbol is sub-band full duplex (SBFD) or non-SBFD.

7. In paragraph 5, the above method is: The method further includes the step of receiving a PUCCH (physical uplink control channel) from the terminal, and A method characterized in that the power of the above PUCCH is determined based on the symbol type of the symbol to which the above PUCCH is received.

8. In Paragraph 6, A method characterized in that the power of the above PUSCH is determined based on an Alpha parameter associated with SBFD and a preambleReceivedTargetPower parameter associated with SBFD when the symbol type of the above scheduled symbol is SBFD.

9. Regarding the terminal, Transmitter / receiver; and Receives a RAR (random access response) UL (uplink) grant from the base station for scheduling a PUSCH (physical uplink shared channel), and Based on the above RAR UL grant, the above PUSCH identifies the symbol type of the scheduled symbol, and The above PUSCH determines the power of the PUSCH based on the symbol type of the scheduled symbol, and A terminal characterized by including a control unit configured to transmit a PUSCH to the base station based on the power of the PUSCH.

10. In Paragraph 9, A terminal characterized in that the symbol type of the PUSCH scheduled symbol is sub-band full duplex (SBFD) or non-SBFD.

11. In paragraph 9, the control unit of the terminal above: It is further configured to transmit a PUCCH (physical uplink control channel) to the above base station, and A terminal characterized in that the power of the above PUCCH is determined based on the symbol type of the symbol transmitted by the above PUCCH.

12. In Paragraph 10, A terminal characterized in that the power of the above PUSCH is determined based on an Alpha parameter associated with SBFD and a preambleReceivedTargetPower parameter associated with SBFD when the symbol type of the above scheduled symbol is SBFD.

13. Regarding base stations, Transmitter / receiver; and A RAR (random access response) UL (uplink) grant for scheduling a PUSCH (physical uplink shared channel) is transmitted to a terminal, wherein the symbol type of the symbol for which the PUSCH is scheduled is identified based on the RAR UL grant, and A control unit configured to receive the PUSCH from the above terminal, and A base station characterized in that the power of the above PUSCH is determined based on the symbol type of the symbol to which the above PUSCH is received.

14. In Paragraph 13, The symbol type of the symbol scheduled by the above PUSCH is sub-band full duplex (SBFD) or non-SBFD, and A base station characterized in that the power of the above PUSCH is determined based on an Alpha parameter associated with SBFD and a preambleReceivedTargetPower parameter associated with SBFD when the symbol type of the above scheduled symbol is SBFD.

15. In paragraph 13, the control unit above: It is further configured to receive a PUCCH (physical uplink control channel) from the above terminal, and A base station characterized in that the power of the above PUCCH is determined based on the symbol type of the symbol received by the above PUCCH.

Images