Method and device for reporting uplink power headroom in wireless communication system
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2026-02-05
- Publication Date
- 2026-08-13
Smart Images
Figure KR2026002157_13082026_PF_FP_ABST
Abstract
Description
Method and device for reporting uplink power headroom in a wireless communication system
[0001] The present disclosure relates to the operation of a terminal and a base station in a wireless communication system. Specifically, the present disclosure relates to a method for a terminal of a wireless communication system to report uplink power headroom to a base station 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, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.
[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding 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) for incorporating 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, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas to guarantee coverage in the terahertz band of 6G mobile communication technology; metamaterial-based lenses and antennas; high-dimensional spatial multiplexing technology using Orbital Angular Momentum (OAM); and Reconfigurable Intelligent Surface (RIS) technology to improve terahertz band signal coverage; 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 Artificial Intelligence (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 development and advancements in wireless communication systems, it has become possible to provide various services, and thus measures are required to provide these services smoothly.
[0009] The embodiments of the present disclosure aim to provide an apparatus and a method capable of effectively providing services in a wireless communication system.
[0010] According to one embodiment of the present disclosure, a method is provided to be performed by a terminal of a wireless communication system. The method comprises: receiving configuration information for a time resource including subband full duplex (SBFD) symbols and non-SBFD (non-SBFD) symbols from a base station; identifying that a power headroom report (PHR) has been triggered; identifying whether the type of symbol scheduled for a physical uplink shared channel (PUSCH) for the PHR is the SBFD symbol or the non-SBFD symbol; calculating an actual PHR based on at least one power control parameter corresponding to the identified type of symbol; and transmitting the PUSCH containing the actual PHR to the base station.
[0011] According to one embodiment of the present disclosure, a method is provided to be performed by a base station of a wireless communication system. The method comprises the steps of: transmitting configuration information for a time resource, including SBFD symbols and non-SBFD symbols, to a terminal; and receiving a PUSCH for a PHR triggered at the terminal from the terminal. The PUSCH includes an actual PHR. The actual PHR is calculated based on at least one power control parameter corresponding to the type of symbol to which the PUSCH is scheduled, among the SBFD symbols or the non-SBFD symbols.
[0012] According to one embodiment of the present disclosure, a terminal of a wireless communication system is provided. The terminal comprises at least one transceiver; at least one processor connected to communicate with the at least one transceiver; and a memory connected to communicate with the at least one processor and storing instructions that are executable individually or in any combination of the at least one processor. The instructions cause the terminal to receive configuration information for a time resource, including SBFD symbols and non-SBFD symbols, from a base station, identify that a PHR has been triggered, identify whether the type of symbol for which a PUSCH for the PHR is scheduled is the SBFD symbol or the non-SBFD symbol, calculate an actual PHR based on at least one power control parameter corresponding to the identified type of symbol, and cause the PUSCH containing the actual PHR to be transmitted to the base station.
[0013] According to one embodiment of the present disclosure, a base station of a wireless communication system comprises: at least one transceiver; at least one processor connected to communicate with the at least one transceiver; and a memory connected to communicate with the at least one processor and storing instructions that are executable individually or in any combination of the at least one processor. The instructions cause the base station to transmit configuration information for a time resource, including SBFD symbols and non-SBFD symbols, to a terminal and to receive a PUSCH from the terminal for a PHR triggered at the terminal. The PUSCH includes an actual PHR. The actual PHR is calculated based on at least one power control parameter corresponding to the type of symbol to which the PUSCH is scheduled, among the SBFD symbols or the non-SBFD symbols.
[0014] An embodiment of the present disclosure provides an apparatus and a method capable of effectively providing services in a wireless communication system.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] FIG. 11 illustrates a random access procedure in a wireless communication system according to one embodiment of the present disclosure.
[0026] FIG. 12 is a diagram illustrating an example in which an SBFD is operated in the TDD band of a wireless communication system according to one embodiment of the present disclosure.
[0027] FIG. 13 illustrates a Single Entry PHR MAC-CE format according to one embodiment of the present disclosure.
[0028] FIG. 14 illustrates a Multiple Entry PHR MAC-CE format according to one embodiment of the present disclosure.
[0029] FIG. 15 is a diagram illustrating a symbol type and a TCI state and power parameters corresponding to the symbol type according to one embodiment of the present disclosure.
[0030] FIG. 16 is a diagram of transmitting a PHR for one cell according to one embodiment of the present disclosure.
[0031] FIG. 17 illustrates a PHR MAC-CE format for multiple PHR reports according to one embodiment of the present disclosure.
[0032] FIG. 18 illustrates a PHR MAC-CE format for multiple PHR reports according to one embodiment of the present disclosure.
[0033] FIG. 19 illustrates a case in which the PUSCH of a second cell overlaps with the PUSCH of a first cell according to one embodiment of the present disclosure and does not overlap with the PUSCH of a first cell.
[0034] FIG. 20 illustrates a case where the PUSCH of a first cell and the PUSCH of a second cell overlap according to one embodiment of the present disclosure.
[0035] FIG. 21 is a drawing illustrating the structure of a terminal in a wireless communication system according to one embodiment of the present disclosure.
[0036] FIG. 22 is a drawing illustrating the structure of a base station in a wireless communication system according to one embodiment of the present disclosure.
[0037] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the attached drawings.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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 the means of instruction 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).
[0043] 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.
[0044] 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. Furthermore, in the embodiment, the 'part' may include one or more processors.
[0045] 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.
[0046] 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.
[0047] 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).
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] [NR Time-Frequency Resources]
[0053] The frame structure of the 5G system will be explained in more detail below with reference to the drawings.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] μ 0141011142022144043148084141601651432032
[0059] [Bandwidth Section (BWP)]
[0060] Next, the Bandwidth Part (BWP) setting in the 5G communication system will be explained in detail with reference to the drawing.
[0061] 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.
[0062] 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.
[0063] BWP ::= SEQUENCE {bwp-Id BWP-Id,(Bandwidth Identifier)locationAndBandwidth INTEGER (1..65536),(Bandwidth Location)subcarrierSpacing ENUMERATED {n0, n1, n2, n3, n4, n5},(Subcarrier Spacing)cyclicPrefix ENUMERATED { extended}(Cyclical Prefix)}
[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 specified and can be defined, for example, as shown in Table 3.
[0074] μNR Slot length (ms)BWP switch delay T BWP (slots)Type 1 Note 1 Type 2 Note 1 011310.52520.253930.125618Note 1: Depends on UE capability.Note 2: If the BWP switch involves changing of SCS, the BWP switch delay is determined by the larger one between the SCS before BWP switch and the SCS after BWP switch.
[0075] 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.
[0076] In accordance with the aforementioned requirements for bandwidth portion change delay time, if the terminal receives a DCI containing a bandwidth portion change indicator in slot n, the terminal performs a change to the new bandwidth portion indicated by the bandwidth portion change indicator in slot n+T BWPCompletion can be performed at a time no later than the new bandwidth portion, and transmission and reception for the data channel scheduled by the corresponding DCI can be performed in the changed new bandwidth portion. If the base station intends to schedule a data channel in the new bandwidth portion, the terminal's bandwidth portion change delay time (T BWP By considering ), time-domain resource allocation for a data channel can be determined. That is, when a base station schedules a data channel with a new bandwidth portion, in the method for determining time-domain resource allocation for a data channel, the data channel can be scheduled after the bandwidth portion change delay time. Accordingly, the terminal [is notified] that the DCI instructing the bandwidth portion change is the bandwidth portion change delay time (T BWP You may not expect to indicate a slot offset (K0 or K2) value smaller than )
[0077] 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).
[0078] [SS / PBCH Block]
[0079] Next, we will explain the SS (Synchronization Signal) / PBCH block in 5G.
[0080] 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.
[0081] - PSS: A signal that serves as the reference for downlink time / frequency synchronization and provides some information about the cell ID.
[0082] - 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.
[0083] - 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.
[0084] - 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.
[0085] 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.
[0086] [PDCCH: DCI related]
[0087] Next, Downlink Control Information (DCI) in 5G systems will be explained in detail.
[0088] 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.
[0089] 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.
[0090] 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).
[0091] 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.
[0092] - Identifier for DCI formats - [1] bit- Frequency domain resource assignment -[ ] bits- Time domain resource assignment - X bits- Frequency hopping flag - 1 bit- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- TPC command for scheduled PUSCH - [2] bits- UL / SUL indicator - 0 or 1 bit
[0093] 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.
[0094] - Carrier indicator - 0 or 3 bits - UL / SUL indicator - 0 or 1 bit - Identifier for DCI formats - [1] bits - Bandwidth part indicator - 0, 1 or 2 bits - Frequency domain resource assignment - For resource allocation type 0, bits- For resource allocation type 1, bits- Time domain resource assignment -1, 2, 3, or 4 bits- VRB-to-PRB mapping (virtual resource block-to-physical resource block mapping) - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- Frequency hopping flag - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- 1st downlink assignment index (first downlink allocation index)- 1 or 2 bits○ 1 bit for semi-static HARQ-ACK codebook (semi-static HARQ-ACK In case of codebook);○ 2 bits for dynamic HARQ-ACK codebook with single HARQ-ACK codebook (when a dynamic HARQ-ACK codebook is used with a single HARQ-ACK codebook).- 2nd downlink assignment index - 0 or 2 bits ○ 2 bits for dynamic HARQ-ACK codebook with two HARQ-ACK sub-codebooks (when a dynamic HARQ-ACK codebook is used with two HARQ-ACK sub-codebooks); ○ 0 bit otherwise.TPC command for scheduled PUSCH - 2 bits- SRS resource indicator (SRS resource indicator) -. or bits○ bits for non-codebook based PUSCH transmission(if PUSCH transmission is not codebook-based);○ bits for codebook-based PUSCH transmission. - Precoding information and number of layers - up to 6 bits - Antenna ports - up to 5 bits - SRS request - 2 bits - CSI request - 0, 1, 2, 3, 4, 5, or 6 bits - CBG transmission information - 0, 2, 4, 6, or 8 bits - PTRS-DMRS association - 0 or 2 bits - beta_offset indicator - 0 or 2 bits - DMRS sequence initialization - 0 or 1 bit
[0095] 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.
[0096] - Identifier for DCI formats - [1] bit- Frequency domain resource assignment -[ ] bits- Time domain resource assignment - X bits- VRB-to-PRB mapping - 1 bit- Modulation and coding scheme - 5 bits- New data indicator - 1 bit- Redundancy version - 2 bits- HARQ process number - 4 bits- Downlink assignment index - 2 bits- TPC command for scheduled PUCCH - [2] bits- PUCCH resource indicator - 3 bits- PDSCH-to-HARQ feedback timing indicator - [3] bits
[0097] 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.
[0098] - Carrier indicator - 0 or 3 bits- Identifier for DCI formats - [1] bits- Bandwidth part indicator - 0, 1 or 2 bits- Frequency domain resource assignment○ For resource allocation type 0, bits○ For resource allocation type 1, bits- Time domain resource assignment -1, 2, 3, or 4 bits- VRB-to-PRB mapping - 0 or 1 bit, only for resource allocation type 1.○ 0 bit if only resource allocation type 0 is configured;○ 1 bit otherwise.- PRB bundling size indicator - 0 or 1 bit - Rate matching indicator - 0, 1, or 2 bits - ZP CSI-RS trigger - 0, 1, or 2 bits - For transport block 1: - Modulation and coding scheme - 5 bits - New data indicator - 1 bit - Redundancy version - 2 bits - For transport block 2: - Modulation and coding scheme - 5 bits - New data indicator - 1 bit - Redundancy version - 2 bits - HARQ process number - 4 bits - Downlink assignment index - 0 or 2 or 4 bits - TPC command for scheduled PUCCH - 2 bits - PUCCH resource indicator - 3 bits - PDSCH-to-HARQ_feedback timing indicator - 3 bits - Antenna ports 4, 5, or 6 bits - Transmission configuration indication - 0 or 3 bits - SRS request - 2 bits - CBG transmission information - 0, 2, 4, 6, or 8 bits - CBG flushing out information - 0 or 1 bit - DMRS sequence initialization - 1 bit.
[0099] [PDCCH: CORESET, REG, CCE, Search Space]
[0100] In the following, the downlink control channel in a 5G communication system will be explained in more detail with reference to the drawings.
[0101] 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.
[0102] FIG. 4 illustrates an example in which two control areas (control area #1 (401), control area #2 (402)) are set within a terminal bandwidth part (UE bandwidth part) (410) on the frequency axis and a slot (420) on the time axis. The control areas (401, 402) can be set to a specific frequency resource (403) within the entire terminal bandwidth part (410) on the frequency axis. On the time axis, they can be set to one or more OFDM symbols and can be defined as the control area length (Control Resource Set Duration, 404). Referring to the example illustrated in FIG. 4, control area #1 (401) is set to a control area length of 2 symbols, and control area #2 (402) is set to a control area length of 1 symbol.
[0103] 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.
[0104] ControlResourceSet ::= SEQUENCE {-- Corresponds to L1 parameter 'CORESET-ID'controlResourceSetId ControlResourceSetId,(Control Domain Identifier(Identity))frequencyDomainResources BIT STRING (SIZE (45)),(Frequency Axis Resource Allocation Info)duration INTEGER (1..maxCoReSetDuration),(Time Axis Resource Allocation Info)cce-REG-MappingType CHOICE {(CCE-to-REG Mapping Type)interleaved SEQUENCE {reg-BundleSize ENUMERATED {n2, n3, n6},(REG Bundle Size)precoderGranularity ENUMERATED {sameAsREG-bundle, allContiguousRBs},interleaverSize ENUMERATED {n2, n3, n6}(Interleaver Size)shiftIndex INTEGER(0..maxNrofPhysicalResourceBlocks-1) OPTIONAL(Interleaved Shift)},nonInterleaved NULL},tci-StatesPDCCH SEQUENCE(SIZE (1..maxNrofTCI-StatesPDCCH)) OF TCI-StateId OPTIONAL,(QCL setting information)tci-PresentInDCI ENUMERATED {enabled} OPTIONAL, -- Need S}
[0105] 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.
[0106] 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.
[0107] According to FIG. 5, the basic unit of time and frequency resources constituting a control channel can be called a REG (Resource Element Group, 503), and the REG (503) can be defined as 1 OFDM symbol (501) on the time axis and 1 PRB (Physical Resource Block, 502) on the frequency axis, i.e., 12 subcarriers. A base station can concatenate REGs (503) to form a downlink control channel allocation unit.
[0108] 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, the REG (503) illustrated in FIG. 5 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.
[0109] 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.
[0110] 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.
[0111] 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.
[0112] SearchSpace ::= SEQUENCE {-- Identity of the search space. SearchSpaceId = 0 identifies the SearchSpace configured via PBCH (MIB) or ServingCellConfigCommon.searchSpaceId SearchSpaceId,(Search Space Identifier)controlResourceSetId ControlResourceSetId,(Control Area Identifier)monitoringSlotPeriodicityAndOffset CHOICE {(Monitoring Slot Level Period)sl1 NULL,sl2 INTEGER (0..1),sl4 INTEGER (0..3),sl5 INTEGER (0..4),sl8 INTEGER (0..7),sl10 INTEGER (0..9),sl16 INTEGER (0..15),sl20 INTEGER (0..19)} OPTIONAL,duration(Monitoring Length) INTEGER (2..2559)monitoringSymbolsWithinSlot BIT STRING (SIZE (14)) OPTIONAL,(슬롘 내 나이스 심보)nrofCandidates SEQUENCE {(집성 별별 PDCCH 이리군 수)aggregationLevel1 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}, aggregationLevel2 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel4 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel8 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8},aggregationLevel16 ENUMERATED {n0, n1, n2, n3, n4, n5, n6, n8}},searchSpaceType CHOICE {(தமம்ப்புக்குக்க்கு திய்)-- Configures this search space as common search space (CSS) and DCI formats to monitor.common SEQUENCE {(공통이이국)}ue-Specific SEQUENCE {(단말-특정이스국)-- Indicates whether the UE monitors in this USS for DCI formats 0-0 and 1-0 or for formats 0-1 and 1-1.formats ENUMERATED {formats0-0-And-1-0, formats0-1-And-1-1},...}.
[0113] 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.
[0114] 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.
[0115] 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.
[0116] - 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
[0117] - DCI format 2_0 with CRC scrambled by SFI-RNTI
[0118] - DCI format 2_1 with CRC scrambled by INT-RNTI
[0119] - DCI format 2_2 with CRC scrambled by TPC-PUSCH-RNTI, TPC-PUCCH-RNTI
[0120] - DCI format 2_3 with CRC scrambled by TPC-SRS-RNTI
[0121] 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.
[0122] - DCI format 0_0 / 1_0 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI
[0123] - DCI format 1_0 / 1_1 with CRC scrambled by C-RNTI, CS-RNTI, TC-RNTI
[0124] The specified RNTIs may follow the definitions and uses below.
[0125] C-RNTI (Cell RNTI): Used for terminal-specific PDSCH scheduling
[0126] TC-RNTI (Temporary Cell RNTI): Used for terminal-specific PDSCH scheduling
[0127] CS-RNTI (Configured Scheduling RNTI): Used for semi-statically configured terminal-specific PDSCH scheduling.
[0128] RA-RNTI (Random Access RNTI): Used for PDSCH scheduling during the random access phase
[0129] P-RNTI (Paging RNTI): Used for PDSCH scheduling where paging is transmitted.
[0130] SI-RNTI (System Information RNTI): Used for PDSCH scheduling where system information is transmitted.
[0131] INT-RNTI (Interruption RNTI): Used to indicate whether PDSCH has been punctured.
[0132] TPC-PUSCH-RNTI (Transmit Power Control for PUSCH RNTI): Used to instruct power control commands to the PUSCH
[0133] TPC-PUCCH-RNTI (Transmit Power Control for PUCCH RNTI): Used to instruct power control commands to the PUCCH
[0134] TPC-SRS-RNTI (Transmit Power Control for SRS RNTI): Used to instruct power regulation commands to the SRS
[0135] The aforementioned specified DCI formats may follow definitions such as the examples in Table 10.
[0136] DCI formatUsage0_0Scheduling of PUSCH in one cell0_1Scheduling of PUSCH in one cell1_0Scheduling of PDSCH in one cell1_1Scheduling of PDSCH in one cell2_0Notifying a group of UEs of the slot format2_1Notifying a group of UEs of the PRB(s) and OFDM symbol(s) where UE may assume no transmission is intended for the UE2_2Transmission of TPC commands for PUCCH and PUSCH2_3Transmission of a group of TPC commands for SRS transmissions by one or more UEs
[0137] 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.
[0138] [Mathematical Formula 1]
[0139]
[0140] - : Lamination level
[0141] - : Carrier Index
[0142] - : Total number of CCEs existing within control domain p
[0143] - : Slot Index
[0144] - : Number of PDCCH candidates at assembly level L
[0145] - = 0, ..., -1: PDCCH candidate index of aggregation level L
[0146] - = 0, ..., -1
[0147] - , , , , ,
[0148] - : Terminal identifier
[0149] The value may be 0 for the common search space.
[0150] In the case of a terminal-specific search space, the value may correspond to a value that changes according to the terminal's identity (C-RNTI or ID set by the base station for the terminal) and the time index.
[0151] 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.
[0152] [Regarding Rate Matching / Puncturing]
[0153] In the following, the rate matching operation and puncturing operation will be described in detail.
[0154] When a time and frequency resource A intended to transmit an arbitrary symbol sequence A overlaps with an arbitrary time and frequency resource B, rate matching or puncturing operations may be considered as transmission and reception operations of channel A, taking into account the area resource C where resource A and resource B overlap. Specific operations may follow the details below.
[0155] Rate Matching Operation
[0156] - A base station may transmit a symbol sequence A to a terminal by mapping Channel A only to the remaining resource area, excluding Resource C which corresponds to the area overlapping with Resource B, from the entire Resource A. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, Resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and Resource B is {Resource #3, Resource #5}, the base station may sequentially map and send symbol sequence A to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3} which corresponds to Resource C within Resource A. Consequently, the base station may transmit the symbol sequence {Symbol #1, Symbol #2, Symbol #3} by mapping it to {Resource #1, Resource #2, Resource #4}, respectively.
[0157] The terminal can determine Resource A and Resource B from scheduling information regarding Symbol Sequence A from the base station, and thereby determine Resource C, which is the area where Resource A and Resource B overlap. The terminal can receive Symbol Sequence A by assuming that Symbol Sequence A was transmitted by mapping it to the remaining area of Resource A, excluding Resource C. For example, if Symbol Sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, Resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and Resource B is {Resource #3, Resource #5}, the terminal can receive Symbol Sequence A by assuming that it was sequentially mapped to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3}, which corresponds to Resource C. Consequently, the terminal can perform a series of subsequent reception operations by assuming that Symbol Sequence {Symbol #1, Symbol #2, Symbol #3} was transmitted by mapping it to {Resource #1, Resource #2, Resource #4}, respectively.
[0158] Puncturing action
[0159] If there is a resource C corresponding to an area overlapping with resource B among all resources A to which the base station intends to transmit symbol sequence A to a terminal, the base station maps symbol sequence A to the entire resource A, but does not perform transmission in the resource area corresponding to resource C, and can perform transmission only in the remaining resource area of resource A excluding resource C. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and resource B is {Resource #3, Resource #5}, the base station can map symbol sequence A {Symbol #1, Symbol #2, Symbol #3, Symbol #4} to resource A {Resource #1, Resource #2, Resource #3, Resource #4} respectively, and transmit only the symbol sequence {Symbol #1, Symbol #2, Symbol #4} corresponding to the remaining resources {Resource #1, Resource #2, Resource #4}, excluding {Resource #3} corresponding to resource C, and may not transmit {Symbol #3} mapped to {Resource #3} corresponding to resource C. Consequently, the base station can map and transmit the symbol sequence {Symbol #1, Symbol #2, Symbol #4} to {Resource #1, Resource #2, Resource #4} respectively.
[0160] The terminal can determine resources A and B from scheduling information for symbol sequence A from the base station, and thereby determine resource C, which is the area where resources A and B overlap. The terminal can receive symbol sequence A by assuming that symbol sequence A is mapped to the entire resource A, but is transmitted only in the remaining area of resource A excluding resource C. For example, if symbol sequence A consists of {Symbol #1, Symbol #2, Symbol #3, Symbol #4}, resource A is {Resource #1, Resource #2, Resource #3, Resource #4}, and resource B is {Resource #3, Resource #5}, the terminal can assume that symbol sequence A {Symbol #1, Symbol #2, Symbol #3, Symbol #4} is mapped to resource A {Resource #1, Resource #2, Resource #3, Resource #4} respectively, but {Symbol #3} mapped to {Resource #3} corresponding to resource C is not transmitted, and can receive by assuming that symbol sequence {Symbol #1, Symbol #2, Symbol #4} corresponding to the remaining resources {Resource #1, Resource #2, Resource #4}—excluding {Resource #3} corresponding to resource C—is mapped and transmitted. Consequently, the terminal can perform a subsequent series of receiving operations by assuming that the symbol sequence {Symbol #1, Symbol #2, Symbol #4} has been transmitted and mapped to {Resource #1, Resource #2, Resource #4}, respectively.
[0161] In the following, a method for configuring rate matching resources for the purpose of rate matching in a 5G communication system is described. Rate matching refers to the adjustment of the signal size by considering the amount of resources available to transmit the signal. For example, rate matching of a data channel may mean that the data channel is mapped to a specific time and frequency resource range so that the data size is adjusted accordingly without transmission.
[0162] 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.
[0163] FIG. 6 illustrates a downlink data channel (PDSCH, 601) and a rate matching resource (602). A base station may set one or more rate matching resources (602) to a terminal through upper layer signaling (e.g., RRC signaling). The rate matching resource (602) setting information may include time-axis resource allocation information (603), frequency-axis resource allocation information (604), and period information (605). In the following, the bitmap corresponding to the frequency-axis resource allocation information (604) is named the "first bitmap," the bitmap corresponding to the time-axis resource allocation information (603) is named the "second bitmap," and the bitmap corresponding to the period information (605) is named the "third bitmap." If all or part of the time and frequency resources of a scheduled data channel (601) overlap with a set rate matching resource (602), the base station can transmit the data channel (601) by rate matching it in the rate matching resource (602) portion, and the terminal can perform reception and decoding after assuming that the data channel (601) is rate matched in the rate matching resource (602) portion.
[0164] The base station can dynamically notify the terminal via DCI whether to rate match a data channel in the above-mentioned rate matching resource portion through additional settings (corresponding to the "rate matching indicator" within the aforementioned DCI format). Specifically, the base station can select some of the above-mentioned rate matching resources and group them into rate matching resource groups, and can indicate to the terminal via DCI using a bitmap method whether to rate match a data channel for each rate matching resource group. For example, if four rate matching resources, RMR#1, RMR#2, RMR#3, and RMR#4, are set, the base station can set RMG#1={RMR#1, RMR#2} and RMG#2={RMR#3, RMR#4} as rate matching groups, and can indicate to the terminal via a bitmap whether to rate match in RMG#1 and RMG#2, respectively, using 2 bits within the DCI field. For example, you can indicate "1" when rate matching is required and "0" when rate matching is not required.
[0165] In 5G, the granularity of "RB symbol level" and "RE level" is supported by setting the aforementioned rate matching resources to the terminal. More specifically, the following setting method may be followed.
[0166] RB symbol level
[0167] The terminal can receive up to four RateMatchPatterns as upper layer signaling for each bandwidth portion, and one RateMatchPattern may include the following contents.
[0168] - As a Reserved Resource within the bandwidth portion, a resource may be included in which the time and frequency resource domains of the said Reserved Resource are set as a combination of an RB level bitmap and a symbol level bitmap along the frequency axis. The said Reserved Resource may span across one or two slots. A time domain pattern (periodicityAndPattern) in which the time and frequency domains composed of each RB level and symbol level bitmap pair are repeated may be additionally set.
[0169] - It may include time and frequency domain resource areas set as control resource sets within the bandwidth portion, and resource areas corresponding to time domain patterns set as search space settings where the resource areas are repeated.
[0170] RE level
[0171] The terminal can receive the following settings through upper-layer signaling.
[0172] - Configuration information for an RE corresponding to an LTE CRS (Cell-specific Reference Signal or Common Reference Signal) pattern (lte-CRS-ToMatchAround) may include the number of ports of the LTE CRS (nrofCRS-Ports) and the LTE-CRS-vshift(s) value (v-shift), the location information of the LTE carrier's center subcarrier (carrierFreqDL) from a reference frequency point (e.g., reference point A), the LTE carrier's bandwidth size (carrierBandwidthDL) information, and subframe configuration information corresponding to a Multiast-broadcast single-frequency network (mbsfn-SubframConfigList). Based on the aforementioned information, the terminal can determine the location of the CRS within an NR slot corresponding to an LTE subframe.
[0173] - It may include configuration information for resource sets corresponding to one or more ZP (Zero Power) CSI-RS within the bandwidth portion.
[0174] [PDSCH: Regarding Frequency Resource Allocation]
[0175] 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.
[0176] Referring to FIG. 7, three frequency axis resource allocation methods are illustrated, including type 0 (7-00), type 1 (7-05), and dynamic switch (7-10), which can be configured through the upper layer in an NR wireless communication system.
[0177] 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.
[0178] Bandwidth Part SizeConfiguration 1Configuration 21-362437-724873-144816145-2751616
[0179] 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.
[0180] 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.
[0181] [PDSCH / PUSCH: Time Resource Allocation]
[0182] The following describes a time-domain resource allocation method for data channels in next-generation mobile communication systems (5G or NR systems).
[0183] 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.
[0184] PDSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofDL-Allocations)) OF PDSCH-TimeDomainResourceAllocationPDSCH-TimeDomainResourceAllocation ::= SEQUENCE {k0 INTEGER(0..32) OPTIONAL, -- Need S(PDCCH-to-PDSCH timing, slots)mappingType ENUMERATED {typeA, typeB},(PDSCH mapping type)startSymbolAndLength INTEGER (0..127)(start symbol and length of PDSCH)}
[0185] PUSCH-TimeDomainResourceAllocationList ::= SEQUENCE (SIZE(1..maxNrofUL-Allocations)) OF PUSCH-TimeDomainResourceAllocationPUSCH-TimeDomainResourceAllocation ::= SEQUENCE {k2 INTEGER(0..32) OPTIONAL, -- Need S(PDCCH-to-PUSCH timing, slots)mappingType ENUMERATED {typeA, typeB},(PUSCH mapping type)startSymbolAndLength INTEGER (0..127)(start symbol and length of PUSCH)}
[0186] 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.
[0187] 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.
[0188] 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.
[0189] 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.
[0190] 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.
[0191] [PUSCH: Regarding transmission method]
[0192] 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.
[0193] 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.
[0194] ConfiguredGrantConfig ::= SEQUENCE {frequencyHopping ENUMERATED {intraSlot, interSlot} OPTIONAL, -- Need S,cg-DMRS-Configuration DMRS-UplinkConfig,mcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Smcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Suci-OnPUSCH SetupRelease { CG-UCI-OnPUSCH} OPTIONAL, -- Need MresourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},rbg-Size ENUMERATED {config2} OPTIONAL, -- Need SpowerControlLoopToUse ENUMERATED {n0, n1},p0-PUSCH-Alpha P0-PUSCH-AlphaSetId,transformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need SnrofHARQ-Processes INTEGER(1..16),repK ENUMERATED {n1, n2, n4, n8},repK-RV ENUMERATED {s1-0231, s2-0303, s3-0000} OPTIONAL, -- Need Rperiodicity ENUMERATED {sym2, sym7, sym1x14, sym2x14, sym4x14, sym5x14, sym8x14, sym10x14, sym16x14, sym20x14,sym32x14, sym40x14, sym64x14, sym80x14, sym128x14, sym160x14, sym256x14, sym320x14, sym512x14,sym640x14, sym1024x14, sym1280x14, sym2560x14, sym5120x14,sym6, sym1x12, sym2x12, sym4x12, sym5x12, sym8x12, sym10x12, sym16x12, sym20x12, sym32x12,sym40x12, sym64x12, sym80x12, sym128x12, sym160x12, sym256x12, sym320x12, sym512x12, sym640x12,sym1280x12, sym2560x12},configuredGrantTimer INTEGER (1..64) OPTIONAL, -- Need Rrrc-ConfiguredUplinkGrant SEQUENCE {timeDomainOffset INTEGER (0..5119),timeDomainAllocation INTEGER (0..15),frequencyDomainAllocation BIT STRING (SIZE(18)),antennaPort INTEGER (0..31),dmrs-SeqInitialization INTEGER (0..1) OPTIONAL, -- Need RprecodingAndNumberOfLayers INTEGER (0..63),srs-ResourceIndicator INTEGER (0..15) OPTIONAL, -- Need RmcsAndTBS INTEGER (0..31),frequencyHoppingOffset INTEGER (1.. maxNrofPhysicalResourceBlocks-1) OPTIONAL, -- Need RpathlossReferenceIndex INTEGER (0..maxNrofPUSCH-PathlossReferenceRSs-1),...} OPTIONAL, -- Need R...}.
[0195] 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'.
[0196] 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.
[0197] PUSCH-Config ::= SEQUENCE {dataScramblingIdentityPUSCH INTEGER (0..1023) OPTIONAL, -- Need StxConfig ENUMERATED {codebook, nonCodebook} OPTIONAL, -- Need Sdmrs-UplinkForPUSCH-MappingTypeA SetupRelease { DMRS-UplinkConfig} OPTIONAL, -- Need Mdmrs-UplinkForPUSCH-MappingTypeB SetupRelease { DMRS-UplinkConfig} OPTIONAL, -- Need Mpusch-PowerControl PUSCH-PowerControl OPTIONAL, -- Need MfrequencyHopping ENUMERATED {intraSlot, interSlot} OPTIONAL, -- Need SfrequencyHoppingOffsetLists SEQUENCE (SIZE (1..4)) OF INTEGER (1..maxNrofPhysicalResourceBlocks-1)OPTIONAL, -- Need MresourceAllocation ENUMERATED { resourceAllocationType0, resourceAllocationType1, dynamicSwitch},pusch-TimeDomainAllocationList SetupRelease { PUSCH-TimeDomainResourceAllocationList} OPTIONAL, -- Need Mpusch-AggregationFactor ENUMERATED { n2, n4, n8} OPTIONAL, -- Need Smcs-Table ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need Smcs-TableTransformPrecoder ENUMERATED {qam256, qam64LowSE} OPTIONAL, -- Need StransformPrecoder ENUMERATED {enabled, disabled} OPTIONAL, -- Need ScodebookSubset ENUMERATED {fullyAndPartialAndNonCoherent, partialAndNonCoherent,nonCoherent}OPTIONAL, -- Cond codebookBasedmaxRank INTEGER (1..4) OPTIONAL, -- Cond codebookBasedrbg-Size ENUMERATED { config2} OPTIONAL, -- Need Suci-OnPUSCH SetupRelease { UCI-OnPUSCH} OPTIONAL, -- Need Mtp-pi2BPSK ENUMERATED {enabled} OPTIONAL, -- Need S...}.
[0198] 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).
[0199] 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.
[0200] 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'.
[0201] 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.
[0202] 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.
[0203] 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.
[0204] 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.
[0205] 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.
[0206] 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.
[0207] When a terminal is configured with multiple SRS resources, it can determine the precoder and transmission rank to be applied to PUSCH transmission based on the SRI indicated by the base station. In this case, the SRI can be indicated via the field SRS resource indicator within the DCI or configured via the higher-level signaling srs-ResourceIndicator. Similar to the codebook-based PUSCH transmission described above, when the terminal receives the SRI via the DCI, the SRS resource indicated by the SRI refers to the SRS resource corresponding to the SRI among the SRS resources transmitted prior to the PDCCH containing the SRI. The terminal may use one or multiple SRS resources for SRS transmission, and the maximum number of SRS resources that can be transmitted simultaneously within the same symbol in a single SRS resource set, as well as the maximum number of SRS resources, are determined by the UE capability reported by the terminal to the base station. In this case, the SRS resources transmitted simultaneously by the terminal occupy the same RB. The terminal configures one SRS port for each SRS resource. Only one SRS resource set can be configured with the value of usage in the upper signaling SRS-ResourceSet set set to 'nonCodebook', and up to four SRS resources can be configured for non-codebook-based PUSCH transmission.
[0208] 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 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.
[0209] [CA / DC Related]
[0210] 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.
[0211] 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.
[0212] The main functions of NR SDAP (S25, S70) may include some of the following functions.
[0213] - User data transfer function (transfer of user plane data)
[0214] - Mapping function between a QoS flow and a DRB for both DL and UL for uplink and downlink
[0215] - Marking QoS flow ID for uplink and downlink (marking QoS flow ID in both DL and UL packets)
[0216] - Function to map reflective QoS flow to data bearers for uplink SDAP PDUs (reflective QoS flow to DRB mapping for the UL SDAP PDUs).
[0217] Regarding the SDAP layer device, the terminal may receive a setting via an RRC message indicating whether to use the header of the SDAP layer device or the functions of the SDAP layer device for each PDCP layer device, bearer, or logical channel. If the SDAP header is configured, the terminal may be instructed to update or reset the mapping information for the uplink and downlink QoS flows and data bearers to the NAS reflective QoS and AS reflective QoS 1-bit indicators of the SDAP header. The SDAP header may include QoS flow ID information indicating QoS. The QoS information may be used for data processing priorities, scheduling information, etc., to support smooth service.
[0218] The main functions of NR PDCP (S30, S65) may include some of the following functions.
[0219] - Header compression and decompression features (ROHC only)
[0220] - User data transfer function (Transfer of user data)
[0221] - Sequential delivery function (In-sequence delivery of upper layer PDUs)
[0222] - Out-of-sequence delivery of upper layer PDUs
[0223] - Reordering function (PDCP PDU reordering for reception)
[0224] - Duplicate detection function (Duplicate detection of lower layer SDUs)
[0225] - Retransmission of PDCP SDUs
[0226] - Encryption and decryption functions (Ciphering and deciphering)
[0227] - Timer-based SDU discard in uplink.
[0228] 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.
[0229] The main functions of NR RLC(S35, S60) may include some of the following functions.
[0230] - Data transfer function (Transfer of upper layer PDUs)
[0231] - Sequential delivery function (In-sequence delivery of upper layer PDUs)
[0232] - Out-of-sequence delivery of upper layer PDUs
[0233] - ARQ function (Error Correction through ARQ)
[0234] - Concatenation, segmentation, and reassembly functions of RLC SDUs
[0235] - Re-segmentation function (Re-segmentation of RLC data PDUs)
[0236] - Reordering function (Reordering of RLC data PDUs)
[0237] - Duplicate detection
[0238] - Error detection function (Protocol error detection)
[0239] - RLC SDU discard function
[0240] RLC re-establishment function
[0241] 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.
[0242] 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.
[0243] 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.
[0244] - Mapping function (Mapping between logical channels and transport channels)
[0245] - Multiplexing and demultiplexing functions (Multiplexing / demultiplexing of MAC SDUs)
[0246] - Scheduling information reporting function
[0247] - HARQ function (Error correction through HARQ)
[0248] *- Priority handling between logical channels of one UE
[0249] - Priority handling between UEs by means of dynamic scheduling
[0250] - MBMS service identification function
[0251] - Transport format selection function
[0252] - Padding
[0253] 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.
[0254] 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.
[0255] 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.
[0256] 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).
[0257] 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.
[0258] 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.
[0259] 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.
[0260] In describing the present disclosure below, the term "upper layer signaling" may be a signaling corresponding to at least one or a combination of at least one of the following signalings.
[0261] - MIB (Master Information Block)
[0262] - SIB (System Information Block) or SIB
[0263] - RRC (Radio Resource Control)
[0264] - MAC (Medium Access Control) CE (Control Element)
[0265] 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.
[0266] *- PDCCH (Physical Downlink Control Channel)
[0267] - DCI (Downlink Control Information)
[0268] - Terminal-specific (UE-specific) DCI
[0269] - Group common DCI
[0270] - Common DCI
[0271] - Scheduling DCI (e.g., DCI used for the purpose of scheduling downlink or uplink data)
[0272] - Non-scheduling DCI (e.g., DCI not intended for scheduling downlink or uplink data)
[0273] - PUCCH (Physical Uplink Control Channel)
[0274] - UCI (Uplink Control Information)
[0275] 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.
[0276] 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.
[0277] [Subband non-overlapping Full Duplex: SBFD]
[0278] Meanwhile, 3GPP introduced SBFD (Subband non-overlapping Full Duplex), a new duplex method based on NR. SBFD is a technology that utilizes a portion of downlink resources as uplink resources in the TDD spectrum of frequencies below 6 GHz or above 6 GHz, thereby allowing the base station to receive uplink transmissions from the terminals to expand the uplink coverage of the terminals by the amount of increased uplink resources, and can reduce feedback delay by receiving feedback on downlink transmissions from the terminals in the expanded uplink resources.
[0279] In the present disclosure, a terminal capable of receiving information from a base station regarding SBFD support and performing uplink transmission on a portion of downlink resources may be referred to as an SBFD terminal (SBFD-capable UE) for convenience. The SBFD method is defined in the standard, and the following method may be considered for the SBFD terminal to determine whether the SBFD is supported in a specific cell (or frequency, frequency band).
[0280] 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 above frame structure type 2 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 in the specific cell (or frequency, frequency band).
[0281] Second method: Without defining a new frame structure type, it may be indicated whether the SBFD is additionally supported at a specific frequency or frequency band of the existing unpaired spectrum (or TDD). In the second method, it may be defined whether the SBFD is additionally supported at a specific frequency or frequency band of the existing unpaired spectrum, or the base station may indicate to the terminal whether the SBFD is supported using system information. The SBFD terminal may receive system information including whether the SBFD is supported and determine whether the SBFD is supported in the specific cell (or frequency, frequency band).
[0282] 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.
[0283] 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.
[0284] 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). The SBFD terminal may determine SBFD support 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.
[0285] If the information regarding SBFD support is included in system information for a terminal that supports a different version of the standard (e.g., an existing TDD terminal), the information regarding SBFD support may be inserted at the very end 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.
[0286] Alternatively, 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 to 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 is not obtained (i.e., if the system information of the first PDSCH does not include information about the search space), the terminal can receive the second PDCCH in the same search space as the search space of the first PDCCH.
[0287] 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.
[0288] 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).
[0289] 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 use the random access resources for TDD terminals. In the latter case, the SBFD terminal can always use only the separate random access resources for SBFD terminals.
[0290] An SBFD terminal may be instructed by the base station on whether it can use random access resources for a TDD terminal. This may be indicated by being included 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, the availability of random access resources for the TDD terminal may be indicated. This may be indicated by 1 bit. If the 1 bit is '0' (or FALSE), the SBFD terminal cannot use the random access resource for the TDD terminal. If the 1 bit is '1' (or TRUE), the SBFD terminal can use the random access resource for the TDD terminal.
[0291] 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 through a separate random access resource for the SBFD terminal, and upon receiving the PRACH, the base station may determine that the SBFD terminal is attempting to connect to a cell. For example, a TDD terminal may transmit a PRACH through a random access resource for the TDD terminal, and upon receiving the PRACH, the base station 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 through the random access resource of a TDD terminal is allowed, 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.
[0292] 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, the msg2 and msg4 may be scheduled so that they are not received in the uplink subband (when the terminal receives a PDSCH including msg2 and msg4, the PDSCH is received in a frequency resource excluding the uplink subband). When the base station schedules the msg3 PUSCH to the terminal, the msg3 PUSCH may be scheduled to be transmitted within the uplink subband.
[0293] When a base station determines that a terminal is a TDD terminal, the base station cannot use uplink subband settings when scheduling msg2, msg3, and msg4 to the terminal. That is, even if uplink subbands are set for downlink symbols and / or flexible symbols, the base station can assume that the terminal cannot obtain the uplink subband setting information. When the base station schedules msg3 PUSCH to the terminal, msg3 PUSCH can be scheduled for flexible symbols and / or uplink symbols. In other words, msg3 PUSCH cannot be scheduled for uplink subbands.
[0294] 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. Afterward, the SBFD terminal may complete the random access process and proceed to an RRC connection mode to transmit and receive 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 may transmit an uplink signal from the uplink resource as an SBFD operation.
[0295] 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.
[0296] 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.
[0297] 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.
[0298] FIG. 11 illustrates a random access procedure in a wireless communication system according to one embodiment of the present disclosure.
[0299] Referring to FIG. 11, a contention-based random access procedure is illustrated as an example. Additionally, although not illustrated in FIG. 11, 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.
[0300] 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 (1101). 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.
[0301] - Random access preamble sequence index detected by the network (or base station)
[0302] -TC-RNTI (temporary cell radio network temporary identifier)
[0303] - Uplink scheduling grant
[0304] - Timing advance value
[0305] 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.
[0306] 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.
[0307] In step 4 (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 step 3 (1103) to the terminal. In this regard, if multiple terminals receive the same TC-RNTI in step 2 (1102), the multiple terminals that received the same TC-RNTI each include their own terminal identifier (UE contention resolution identity) in message 3 in step 3 (1103) and transmit it to the base station, 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).
[0308] 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).
[0309] 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.
[0310] 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 to the terminal the starting RB point of transmission, and the number of RBs used may be determined by the preamble format transmitted via PRACH and the applied subcarrier interval. Time resources for PRACH transmission may be provided through a PRACH configuration index (from 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.
[0311] PRACHConfigurationIndexPreamble format Subframe numberStarting symbolNumber of PRACH slots within a subframe , number of time-domain PRACH occasions within a PRACH slot ,PRACH durationxy0016110--01016140--02016170--03016190--0408110--0508140--0608170--0708190--0804110--0904140--01004170--0.................................1 04A1101,4,70262................................251C2102,70226252C2101,4,7022 6253C2100,2,4,6,80226254C2100,1,2,3,4,5,6,7,8,90226255C2101,3,5,7,90226
[0312] Here, the first PRACH setting and the second PRACH setting may be as follows.
[0313] The first PRACH setting can determine a valid RACH occasion based on the TDD DL / UL setting and the SSB setting. The first valid RACH occasion according to the first PRACH setting may be located in the uplink symbol or flexible symbol of the TDD DL / UL setting.
[0314] The second PRACH setting can determine a valid RACH occasion based on the TDD DL / UL setting, the SSB setting, and the SBFD setting. The valid RACH occasion determined according to the second PRACH setting may be located in the symbols where the SBFD UL subband is set among the downlink symbols of the TDD DL / UL setting.
[0315] For convenience in the present disclosure, a RACH opportunity according to the first PRACH setting may be referred to as a legacy RACH opportunity or legacy RO (RACH occasion), and a RACH opportunity according to the second PRACH setting may be referred to as an SBFD RACH opportunity or SBFD RO.
[0316] According to the present disclosure, the first PRACH setting may include at least one of the following information for uplink power control.
[0317] - preambleReceivedTargetPower: Received power target value of PRACH transmitted from legacy RO
[0318] - 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.
[0319] - msg3-Alpha: Path attenuation index value used by the terminal when transmitting msg3 PUSCH in non-SBFD symbols
[0320] - msg3-DeltaPreamble: Power parameter used by the terminal when transmitting msg3 PUSCH in a non-SBFD symbol
[0321] The uplink power value corresponding to the above first PRACH setting can be applied to the legacy RO.
[0322] - p0-nomial: PUCCH reception power target value when the terminal transmits PUCCH in a non-SBFD symbol
[0323] According to the present disclosure, the second PRACH setting may include at least one of the following information for uplink power control.
[0324] - preambleReceivedTargetPower_SBFD: Received power target value of PRACH transmitted from the SBFD RO
[0325] - 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.
[0326] - msg3-Alpha_SBFD: Path attenuation index value used by the terminal when transmitting msg3 PUSCH in the SBFD symbol
[0327] - msg3-DeltaPreamble_SBFD: Power parameter used by the terminal when transmitting msg3 PUSCH in the SBFD symbol
[0328] - p0-nomial_SBFD: PUCCH reception power target value when the terminal transmits PUCCH on a non-SBFD symbol
[0329] FIG. 12 is a diagram illustrating an example in which an SBFD is operated in the TDD band of a wireless communication system according to one embodiment of the present disclosure.
[0330] 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.
[0331] 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' represents a slot composed entirely of downlink symbols, 'U' represents a slot composed entirely of uplink symbols, and 'S' represents a slot that is neither 'D' nor 'U'—that is, a slot containing downlink symbols and / or uplink symbols, or a flexible symbol. For convenience, it can be assumed here that S consists of 12 downlink symbols and 2 flexible symbols. Furthermore, the DDDSU slot format can be repeated according to the TDD UL-DL resource configuration information. That is, the repetition cycle of the TDD configuration is 5 slots (5ms for 15kHz SCS, 2.5ms for 30kHz SCS, etc.).
[0332] Next, Figures 12(b), 12(c), and 12(d) illustrate cases where SBFD is operated with TDD in a specific frequency band.
[0333] 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. This band 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 and / or uplink signal scheduled to all symbols (1212) within the subband (UL subband). However, the terminal may not transmit an uplink channel and / or uplink signal in a band other than the subband (UL subband).
[0334] 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, this frequency band may be referred to as 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 and / or uplink signal in the uplink subband (UL subband) (1222) of the remaining slots. For reference, although the uplink subband (UL subband) is activated on a slot basis here, its activation status may be configured on a symbol basis.
[0335] 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.
[0336] In the following description, the time-frequency resources capable of uplink transmission in downlink symbols or flexible symbols may be referred to as SBFD resources / UL subbands.
[0337] [Power Headroom Reporting: PHR]
[0338] The terminal can determine the transmission power of PUSCH based on mathematical formula 2.
[0339] [Mathematical Formula 2]
[0340]
[0341] - represents the index of the transmission occasion.
[0342] - If so, PUSCH corresponding to the RAR UL grant (including initial / re-transmission), If so, configured grant (CG) PUSCH, If so, it is the power parameter of the dynamic grant (DG) PUSCH.
[0343] - represents the index of the beam (or QCL (quasi-co-located)).
[0344] - represents closed-loop power control adjustment states, and or It could be.
[0345] - can be the maximum output power value set for the terminal at the transmission occasion i of the carrier wave f of cell c.
[0346] - 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 a CSI-RS.
[0347] - is a path loss compensation index, which can be a value (alpha) that the base station sets for the terminal.
[0348] ■ Regarding, can be a value set in the upper layer parameter (msg3-Alpha or msgA-Alpha). If the upper layer parameter is not set, It could be.
[0349] ■ Regarding, It can be set in the upper layer setting value (p0AlphaSetforPUSCH) corresponding to the activated TCI state.
[0350] - can be the number of RBs scheduled for PUSCH, and can be a value corresponding to the subcarrier interval.
[0351] - can be a power value controlled according to the bits per RE (resource element) of PUSCH.
[0352] - may be a value associated with the PUSCH's received power target. It could be. Here is a value commonly set for terminals within the cell, and may be a value set per terminal.
[0353] ■ If the terminal established an RRC connection using a Type-1 random access procedure (4-step random access procedure) and did not receive a specific RRC parameter (P0-PUSCH-AlphaSet), or if it is a PUSCH corresponding to a RAR UL grant (including initial / retransmission),
[0354] ◆ If, And, is the receive target power (preambleReceivedTargetPower) of the PRACH preamble set in the upper layer, and may be the power difference (msg3-DeltaPreamble or deltaPreamble) between the PRACH preamble and msg3 PUSCH set in the upper layer. If the power difference (msg3-DeltaPreamble or deltaPreamble) between the PRACH preamble and msg3 PUSCH set in the upper layer is not set, It could be.
[0355] ■ If the terminal has established an RRC connection using a Type-2 random access procedure (2-step random access procedure) and has not received specific RRC parameters (P0-PUSCH-AlphaSet), or if it is a PUSCH for a Type-2 random access procedure (including initial / retransmission),
[0356] ◆ If, And, is the receive target power of the PRACH preamble set in the upper layer (msgA-preambleReceivedTargetPower or preambleReceivedTargetPower), and can be the power difference (msgA-DeltaPreamble or deltaPreamble) between the PRACH preamble and msg3 PUSCH set in the upper layer. If the power difference (msgA-DeltaPreamble or deltaPreamble) between the PRACH preamble and msg3 PUSCH set in the upper layer is not set, It could be.
[0357] ■ Regarding the configured grant PUSCH, , can be set to a specific upper-level parameter (p0-NominalWithoutGrant). If p0-NominalWithoutGrant is not set, = It could be.
[0358] ■ Regarding the Dynamic Grant PUSCH , can be set to a specific upper-level parameter (p0-NominalWithout). If p0-NominalWithout is not set, = It could be.
[0359] ■ Regarding, It can be set in the upper layer setting value (p0AlphaSetforPUSCH) corresponding to the activated TCI state.
[0360] - can be a closed-loop power control value at transmission opportunity i. l is a value representing the PUSCH power control adjustment state, and l=0 or l=1. The value of can be determined based on the TPC (transmit power control) command value indicated in the DCI format that schedules PUSCH.
[0361] The PUSCH transmission power used by the terminal may change over time. For example, The value may be a value measured by the terminal from the path loss reference signal. Therefore, depending on the terminal's mobility or channel environment, The value may change. In addition, the maximum transmission power of the PUSCH that the terminal can use is This may be the case. Therefore, when a terminal reaches its maximum transmission power, even if the base station instructs the terminal to increase its transmission power further to improve the reception signal quality (e.g., by instructing via a TPC command included in the DCI format), the quality of the signal received by the base station may not improve because the terminal's transmission power does not increase. Therefore, the base station may need to receive information regarding the terminal's PUSCH transmission power value.
[0362] In an NR system, a terminal can report the terminal's PUSCH transmission power value to a base station. Specifically, the PUSCH transmission power value may be an actual power headroom (PH) (or actual PHR) and a virtual PH (or virtual PHR). In this disclosure, 'actual PHR' may be referred to interchangeably with 'actual PH', 'first PHR', or 'first PH', and 'virtual PHR' may be referred interchangeably with 'virtual PH', 'second PHR', or 'second PH'. Here, the actual PHR may be generated based on Equation 3.
[0363] [Mathematical Formula 3]
[0364]
[0365] Here, , , , , , , can be the same as the value defined in mathematical equation 2. That is, the terminal is and The difference between them can be reported to the base station as an actual PHR. For reference, If this is positive, it indicates that the terminal can use additional power for PUSCH transmission, and If this is negative, the terminal's PUSCH transmission power is already It can indicate that it has reached.
[0366] In the case of Actual PHR It is calculated using PUSCH scheduling information. For example, is the number of PRBs included in the scheduled PUSCH, and may be a value determined by the number of bits per RE of the scheduled PUSCH (bits per RE, BPRE). If uplink power control is performed based on the unified TCI framework (if ul-powerControl is configured), (alpha) and (p0) and the l value (closedLoopIndex) can be determined based on the parameter (p0AlphaSetforPUSCH) set in the active TCI.
[0367] Virtual PHR is a power reporting method used when PUSCH scheduling information is unavailable or invalid. More specifically, Virtual PHR can be generated based on Equation 4.
[0368] [Mathematical Formula 4]
[0369]
[0370] Here, is the maximum output power value set for the terminal at transmission occasion i of carrier f of cell c, and when the terminal calculates, the values determined by PUSCH scheduling are Maximum power reduction (MPR), Additional-MPR (A-MPR), Power management MPR (P-MPR), and It can be assumed to be 0dB. If uplink power control is performed based on the unified TCI framework (if ul-powerControl is configured), (p0), (alpha), and the value (closedLoopIndex) can be determined based on the parameter (p0AlphaSetforPUSCH) set in the active TCI. Also It may be a downlink path loss reference signal corresponding to the TCI state.
[0371] Since Virtual PHR does not utilize PUSCH scheduling information, the terminal can calculate Virtual PHR even if it is not scheduled to PUSCH.
[0372] The PHR is triggered when the path loss measurement value changes above a predetermined threshold value, when the prohibit PHR timer expires, or when a predetermined period has elapsed after the PHR is generated. Even if the PHR is triggered, the terminal may not transmit the PHR immediately but wait until a point when uplink transmission is possible, for example, when a PUSCH resource is allocated.
[0373] The terminal can include the PHR in the MAC-CE and transmit it to the base station. Here, the MAC-CE can be included in the PUSCH and transmitted. For transmitting the PHR in the MAC-CE, there may be a Single Entry PHR MAC-CE format and a Multiple Entry MAC-CE format.
[0374] FIG. 13 illustrates a Single Entry PHR MAC-CE format according to one embodiment of the present disclosure.
[0375] The Single Entry PHR MAC-CE format can be used for single-cell PHR reporting. Therefore, the Single Entry PHR MAC-CE format contains one P CMAX Values and PHR values may be included.
[0376] Referring to FIG. 13, the Single Entry PHR MAC-CE format may be composed of 2 Octets (=16 bits). Here, the R field may be set to '0' as a reserved 1 bit. The P field indicates whether P-MPR (power-management power reduction) is applied to meet the MPE (maximum permissible exposure) requirements for limiting electromagnetic wave exposure to the human body, and may be 1 bit. The DPC (delta power class) field may have a length of 2 bits as a value for the terminal's power class. The MPE field may have a length of 2 bits, indicating power backoff applied to meet MPE requirements when the P field is set to 1, and may be 2 bits.
[0377] P CMAX,f,c The field can indicate the maximum output power value set to the terminal used to calculate the PHR. The said value can be transmitted after being quantized into 6 bits. Table 17 shows P CMAX,f,c Represents the quantization of the value.
[0378] The PH (Power Headroom) field may contain the power headroom (Actual PHR or Virtual PHR) calculated by the terminal. Here, PH can be transmitted after being quantized into 6 bits. Table 18 shows the quantization of the PH values.
[0379] P CMAX,f,c Nominal UE transmit power level0PCMAX_C_001PCMAX_C_012PCMAX_C_023PCMAX_C_03......60PCMAX_C_6061PCMAX_C_6162PCMAX_C_6263PCMAX_C_63
[0380] PHPower Headroom Level0POWER_HEADROOM_01POWER_HEADROOM_12POWER_HEADROOM_23POWER_HEADROOM_3......60POWER_HEADROOM_6061POWER_HEADROOM_6162POWER_HEADROOM_6263POWER_HEADROOM_63
[0381] FIG. 14 illustrates a Multiple Entry PHR MAC-CE format according to one embodiment of the present disclosure.
[0382] The Multiple Entry PHR MAC-CE format can be used for PHR reporting of multiple cells in dual connectivity or carrier aggregation. Therefore, the Multiple Entry PHR MAC-CE format includes multiple P for each cell CMAX Values and PHR values may be included.
[0383] Referring to FIG. 14, the Multiple Entry PHR MAC-CE format can be composed of multiple Octets.
[0384] The terminal provides a bitmap {C7, C6, ... C1} regarding which serving cells power headroom is reported, and for each serving cell instructed to report PHR, multiple power headrooms (PH(Type 2, SpCell of the other MAC entity), PH(Type 1, PCell), PH(Type X, Serving Cell 1), ..., PH(Type X, Serving Cell n)) are reported, and the corresponding P CMAX,f,c Value (P CMAX,f,c 1, P CMAX,f,c 2,..., P CMAX,f,c m) can be reported together.
[0385] DPC BCThe (delta power class for band combination) field is 1 bit and indicates the power class adjustment value for the band combination operating in FR1. The V field is 1 bit and can indicate whether the power headroom (PH) value reported by the terminal for each cell is the Actual PHR or the Virtual PHR.
[0386] For a description of the remaining fields shown in Fig. 14, refer to the Single Entry PHR MAC-CE format of Fig. 13.
[0387] In carrying out the various embodiments of the present disclosure below, the terminal can determine whether the PHR for a cell is an Actual PHR or a Virtual PHR. For example:
[0388] - When a PHR is reported in a PUSCH scheduled by a first DCI, the terminal can determine whether the triggered PHR is an Actual PHR or a Virtual PHR based on the upper layer signals of the DCI received by the terminal and the CG (configured grant) PUSCH up to the PDCCH monitoring opportunity where the terminal receives the first DCI that schedules the initial transmission of the transmission block after the PHR was triggered.
[0389] - When a PHR is reported as a CG PUSCH, the terminal can determine whether the triggered PHR is an Actual PHR or a Virtual PHR based on the downlink DCI received up to a certain time prior to the first symbol of the CG PUSCH and the upper layer signals of the CG PUSCH. Here, the certain time may be a value related to the processing time of the PUSCH.
[0390] Additionally or alternatively, the terminal can determine whether the PHR is an Actual PHR or a Virtual PHR for a single symbol type. For example:
[0391] - When a PHR is reported in a PUSCH scheduled for a first symbol type by a first DCI, the terminal can determine whether the triggered PHR is an Actual PHR or a Virtual PHR based on the DCI received by the terminal and the upper layer signal of the CG PUSCH scheduled for the first symbol type, up to the PDCCH monitoring opportunity where the terminal receives the first DCI that schedules the first transmission block of the transmission block after the PHR was triggered to the first symbol type.
[0392] - When a PHR is reported as a CG PUSCH of the first symbol type, the terminal can determine whether the treeed PHR is an Actual PHR or a Virtual PHR based on the DCIs that schedule the PUSCH of the first symbol type among the downlink DCIs received up to a certain time prior to the first symbol of the CG PUSCH, and the upper layer signals of the CG PUSCH of the first symbol type. Here, the certain time may be a value related to the processing time of the PUSCH.
[0393] Single Cell Scenario
[0394] According to the present disclosure, a terminal may transmit a PHR for a single cell. This may be a case where the terminal is configured such that (1) only one cell is configured for uplink communication, (2) even if multiple cells are configured, only one cell is activated and the remaining cells are deactivated, or (3) even if multiple cells are configured and multiple cells are activated, only one cell is configured to report a PHR.
[0395] A terminal may have an SBFD resource configured in a cell in which a PHR report is configured. Here, the SBFD resource may include SBFD symbols and downlink subbands transmitted downlink from said symbols and uplink subbands transmitted uplink from said symbols. In the present disclosure, SBFD symbols may refer to symbols in which downlink subbands and uplink subbands are configured according to the SBFD resource configuration. And non-SBFD symbols may refer to the remaining symbols excluding said SBFD symbols.
[0396] The terminal can transmit PUSCH to the base station from a single cell where PHR reporting is configured.
[0397] Here, PUSCH that is not repeatedly transmitted may be scheduled only on SBFD symbols or only on non-SBFD symbols. That is, PUSCH may not be scheduled across SBFD symbols and non-SBFD symbols.
[0398] In the case of a PUSCH that is repeatedly transmitted, the PUSCH transmission may consist of multiple PUSCH iterations. Each PUSCH iteration may be scheduled only with SBFD symbols or only with non-SBFD symbols. A single PUSCH iteration may not be scheduled across SBFD symbols and non-SBFD symbols. That is, if a single PUSCH iteration overlaps with two symbol types, the PUSCH iteration may not be transmitted.
[0399] In the case of a configured grant (CG) PUSCH, a single CG PUSCH transmission opportunity may be scheduled only for SBFD symbols or only for non-SBFD symbols. A single CG PUSCH transmission opportunity may not be scheduled across SBFD symbols and non-SBFD symbols. That is, if a single CG PUSCH transmission opportunity overlaps with two symbol types, the CG PUSCH transmission opportunity may not be transmitted.
[0400] FIG. 15 is a diagram illustrating a symbol type and a TCI state and power parameters corresponding to the symbol type according to one embodiment of the present disclosure.
[0401] Referring to FIG. 15, OFDM symbols can be classified into SBFD symbols with UL subband and DL subband set, and other non-SBFD symbols. When a terminal transmits a PUSCH, different power parameters may be set depending on the symbol type (whether it is an SBFD symbol or a non-SBFD symbol) to which the PUSCH is transmitted. More specifically, (1) corresponding to a non-SBFD symbol , (alpha), (p0) value, l value (closedloopIndex), and path loss reference signal and (2)corresponding to the SBFD symbol (alpha), (p0) value, l value, and path loss reference signal can be set differently. For convenience, the value corresponding to the SBFD symbol (alpha_SBFD), (p0_SBFD), l value (closedloopIndex_SBFD), and It can be called.
[0402] Power parameters corresponding to non-SBFD symbols ( , (alpha), (p0), l value (closedloopIndex), and path loss reference signal At least one of) and power parameters corresponding to the SBFD symbol ( , (alpha_SBFD), (p0_SBFD), l value (closedloopIndex_SBFD), and path loss reference signal At least one of) may be a parameter set per TCI state.
[0403] The terminal can determine the transmission power of the PUSCH transmitted in non-SBFD based on power parameters corresponding to non-SBFD symbols. The terminal can determine the transmission power of the PUSCH transmitted in SBFD based on power parameters corresponding to SBFD symbols.
[0404] According to the present disclosure, can be the target power of PUSCH set as cell common in non-SBFD symbols. can be the target power of PUSCH set commonly in the SBFD symbol. That is, different target powers can be set commonly in the cells.
[0405] or, and It may not be set separately. In this case, can use the received power target value (preambleReceivedTargetPower) of the PRACH preamble among the values set in the first PRACH setting for the TDD terminal, and Among the values set in the second PRACH setting for the SBFD terminal, the received power target value of the PRACH preamble (preambleReceivedTargetPower_SBFD) can be used.
[0406] More specifically, and If it is not set separately, , = It could be, preambleReceivedTargetPower+msg3-DeltaPreamble, It could be preambleReceivedTargetPower_SBFD +msg3-DeltaPreamble_SBFD.
[0407] According to the present disclosure, is set, It may not be set separately. In this case, It can be represented as, can be the difference between preambleReceivedTargetPower_SBFD and preambleReceivedTargetPower (preambleReceivedTargetPower_SBFD - preambleReceivedTargetPower). Or may be the difference between preambleReceivedTargetPower_SBFD+msg3-DeltaPreamble_SBFD and preambleReceivedTargetPower+msg3-DeltaPreamble (preambleReceivedTargetPower_SBFD+msg3-DeltaPreamble_SBFD-(preambleReceivedTargetPower+msg3-DeltaPreamble)).
[0408] According to the present disclosure, and It may not be set separately. In this case, and It can be determined based on either preambleReceivedTargetPower or preambleReceivedTargetPower_SBFD. Here, between the two values, it can be determined based on the type of RO used by the terminal for PRACH transmission in random access. For example, if the terminal used a legacy RO in random access, and can be preambleReceivedTargetPower+msg3-DeltaPreamble. If the terminal used SBFD RO in random access, and can be preambleReceivedTargetPower_SBFD+msg3-DeltaPreamble_SBFD.
[0409] A terminal can trigger a PHR in a cell where a PHR report is configured. The terminal can transmit a PUSCH including the triggered PHR in the PUSCH.
[0410] Since SBFD resources are configured in a single cell where PHR reporting is configured, the PUSCH containing the PHR is i) a PUSCH located in a non-SBFD symbol, ii) a PUSCH located in an SBFD symbol, or iii) in the case of PUSCH repetitions, some of the PUSCH repetitions may be located in non-SBFD symbols and others in SBFD symbols. For convenience, in the case of iii), it can be said that the PUSCH repetition spans both non-SBFD symbols and SBFD symbols.
[0411] The symbol at the time when the PHR report is triggered may be a non-SBFD symbol or an SBFD symbol. The terminal may determine the time when the PHR report is triggered. For example, if the PHR report is triggered when a measurement of a downlink path loss reference signal changes by more than a certain amount, the terminal may determine that the symbol at the time when the PHR report is triggered is a non-SBFD symbol or an SBFD symbol based on the type of symbol in which the downlink path loss reference signal is received. If the PHR report is determined based on the expiration of the PHR timer, the terminal may determine that the symbol at the time when the PHR report is triggered is a non-SBFD symbol or an SBFD symbol based on the type of symbol at the time when the timer expires.
[0412] In a scenario where a single cell exists, the terminal can transmit PHR to PUSCH based on at least one of the methods described below or a combination thereof.
[0413] Method 1: Method to transmit a single PHR to PUSCH
[0414] Method 1-1: A terminal may include a PHR in the first scheduled PUSCH after the time at which the PHR is triggered, regardless of the type of symbol at which the PHR is triggered and / or regardless of the type of symbol at which the PUSCH is scheduled. That is, the terminal may include a PHR in the first scheduled PUSCH after the time at which the PHR is triggered (whether scheduled for a non-SBFD symbol or an SBFD symbol), regardless of whether the symbol at the time at which the PHR is triggered is a non-SBFD symbol or an SBFD symbol. Here, the PHR may be generated as follows.
[0415] Method 1-1-1: A terminal may calculate an Actual PHR based on the symbol type of a PUSCH containing a PHR and include it in the PUSCH. Here, the terminal may include an Actual PHR generated based on the symbol type corresponding to the PUSCH in the PUSCH, regardless of the symbol type to which the PHR was triggered.
[0416] - If PUSCH is scheduled to a non-SBFD symbol, the terminal has at least one power parameter corresponding to the non-SBFD symbol ( (alpha), (p0), l value (closedLoopIndex), and path loss reference signal An Actual PHR generated based on at least one of the above can be included in PUSCH.
[0417] - When PUSCH is scheduled to an SBFD symbol, the terminal may include an Actual PHR generated based on at least one power parameter corresponding to the SBFD symbol in the PUSCH.
[0418] Method 1-1-2a: The terminal may generate an Actual PHR or a Virtual PHR based on the symbol type triggered by the PHR and include it in the PUSCH.
[0419] If the symbol type triggered by the PHR is the same as the symbol type of the PUSCH, the terminal may include an Actual PHR based on the symbol type triggered by the PHR in the PUSCH.
[0420] - If a PHR is triggered at a non-SBFD symbol and the PHR is included in a PUSCH scheduled at a non-SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the non-SBFD symbol in the PUSCH.
[0421] - If a PHR is triggered at an SBFD symbol and the PHR is included in a PUSCH scheduled at the SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the SBFD symbol in the PUSCH.
[0422] If the symbol type triggered by the PHR is different from the symbol type of the PUSCH, the terminal may include a Virtual PHR based on the symbol type triggered by the PHR in the PUSCH.
[0423] - If a PHR is triggered in a non-SBFD symbol and the PHR is included in a PUSCH scheduled in an SBFD symbol, the terminal may include a Virtual PHR based on at least one power parameter corresponding to the SBFD symbol in the PUSCH.
[0424] - If a PHR is triggered at an SBFD symbol and the PHR is included in a PUSCH scheduled at a non-SBFD symbol, the terminal may include a Virtual PHR based on at least one power parameter corresponding to the non-SBFD symbol in the PUSCH.
[0425] Method 1-1-2b: The terminal may generate an Actual PHR based on the symbol type triggered by the PHR and include it in the PUSCH.
[0426] - If the PHR is triggered at a non-SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the non-SBFD symbol in the PUSCH.
[0427] - If the PHR is triggered at the SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the SBFD symbol in the PUSCH.
[0428] For reference, when generating the above Actual PHR, scheduling information of a PUSCH scheduled for a different symbol type may be used. For example, if the PHR is generated based on SBFD symbols and the PUSCH is scheduled for non-SBFD symbols, the terminal uses values determined based on the scheduling information of the PUSCH scheduled for non-SBFD symbols ( , , MPR, A-MPR, P-MPR, and At least one of) can be used to generate the PHR of the SBFD symbol. For example, if the PHR is generated based on a non-SBFD symbol and PUSCH is scheduled on an SBFD symbol, the terminal uses values determined based on the scheduling information of the PUSCH scheduled on the SBFD symbol ( , , MPR, A-MPR, P-MPR, and At least one of) can be used to generate a PHR of non-SBFD symbols.
[0429] Method 1-2: The terminal may include the PHR in a PUSCH scheduled on a symbol of the same type as the symbol on which the PHR was triggered, after the time the PHR was triggered. That is, if the PHR is triggered on a non-SBFD symbol, the terminal may include the PHR in a PUSCH scheduled on the non-SBFD symbol first. If the PHR is triggered on an SBFD symbol, the terminal may include the PHR in a PUSCH scheduled on the SBFD symbol first. Here, the PHR may be generated as follows.
[0430] Method 1-2-1: The terminal may generate an Actual PHR based on the symbol type triggered by the PHR and the symbol type of the PUSCH and include it in the PUSCH. Here, the symbol type triggered by the PHR and the symbol type of the PUSCH may be the same.
[0431] - If the symbol triggered by PHR is a non-SBFD symbol and PUSCH is scheduled to the non-SBFD symbol, at least one power parameter corresponding to the terminal non-SBFD symbol ( (alpha), (p0), l value (closedloopIndex), and path loss reference signal An Actual PHR generated based on at least one of the above can be included in PUSCH.
[0432] - If the symbol triggered by PHR is an SBFD symbol and PUSCH is scheduled to the SBFD symbol, the terminal has at least one power parameter corresponding to the SBFD symbol ( (alpha_SBFD), (p0_SBFD), l value (closedloopIndex_SBFD), and path loss reference signal It may include an Actual PHR generated based on at least one of the following.
[0433] Method 1-3: The terminal may trigger and report a PHR only for specific symbol types. More specifically, the terminal may determine that the PHR triggering is determined only in non-SBFD symbols. Additionally, the PHR may be included only in PUSCHs scheduled in non-SBFD symbols. For example, a PHR may be triggered in a non-SBFD symbol, and when the PHR is triggered, the triggered PHR may be included in the earliest PUSCH among the PUSCHs scheduled in the non-SBFD symbol. Here, the PHR may be an Actual PHR generated based on the non-SBFD symbol.
[0434] FIG. 16 is a diagram of transmitting a PHR for one cell according to one embodiment of the present disclosure.
[0435] Figure 16(a) illustrates a situation where the PHR is triggered (1600a) at a non-SBFD symbol.
[0436] According to the first method and at least one sub-method described above, the terminal can identify a PUSCH to transmit a PHR and generate a PHR as follows.
[0437] According to Method 1-1, the PHR may be included in the earliest PUSCH (1610a) among the PUSCHs (1610a, 1620a) after the point in time when the PHR is triggered (1600a).
[0438] According to Method 1-1-1, the actual PHR can be generated based on at least one power parameter corresponding to a non-SBFD symbol, which is a symbol type of PUSCH (1610a).
[0439] According to Method 1-1-2a, since the symbol type at the time when the PHR is triggered (1600a) and the symbol type of PUSCH (1610a) are the same as non-SBFD symbols, an actual PHR can be generated based on at least one power parameter corresponding to a non-SBFD symbol type.
[0440] According to method 1-1-2b, an actual PHR can be generated based on at least one power parameter corresponding to a non-SBFD symbol type, which is the symbol type at the time when the PHR is triggered (1600a).
[0441] According to method 1-2, among the PUSCHs (1610a, 1620a) after the point in time when the PHR was triggered (1600a), the PHR may be included in the earliest PUSCH (1610a) scheduled in a symbol of the same type (non-SBFD symbol) as the symbol in which the PHR was triggered.
[0442] According to Method 1-2-1, the actual PHR can be generated based on at least one power parameter corresponding to the symbol type at the time when the PHR is triggered (1600a) and the non-SBFD symbol, which is the symbol type of PUSCH (1610a).
[0443] Figure 16(b) illustrates a situation where the PHR is triggered (1600b) at the SBFD symbol.
[0444] According to the first method and at least one sub-method described above, the terminal can identify a PUSCH to transmit a PHR and generate a PHR as follows.
[0445] According to Method 1-1, the PHR may be included in the earliest PUSCH (1610b) among the PUSCHs (1610b, 1620b) after the point in time when the PHR is triggered (1600b).
[0446] According to Method 1-1-1, the actual PHR can be generated based on at least one power parameter corresponding to a non-SBFD symbol, which is a symbol type of PUSCH (1610b).
[0447] According to Method 1-1-2a, since the symbol type at the time when the PHR is triggered (1600b) is an SBFD symbol and the symbol type of PUSCH (1610b) is a non-SBFD symbol, a Virtual PHR can be generated based on at least one power parameter corresponding to the SBFD symbol type, which is the symbol type at which the PHR is triggered (1600b).
[0448] According to method 1-1-2b, an actual PHR can be generated based on at least one parameter corresponding to the SBFD symbol type, which is the symbol type at the time when the PHR is triggered (1600b).
[0449] According to method 1-2, among the PUSCHs (1610b, 1620b) after the point in time when the PHR was triggered (1600b), the PHR may be included in the earliest PUSCH (1620b) scheduled in a symbol of the same type (SBFD symbol) as the symbol in which the PHR was triggered.
[0450] According to Method 1-2-1, the actual PHR can be generated based on at least one power parameter corresponding to the SBFD symbol, which is the symbol type of PUSCH (1620b), and the symbol type of the PHR at the time when the PHR is triggered (1600b).
[0451] According to the first method, the terminal can include one PHR in the Single Entry PHR MAC-CE format.
[0452] According to at least one of methods 1-1-1 through 1-2-1, the base station can determine which symbol type PHR was generated based on, based on the type of symbol for which PUSCH was scheduled.
[0453] However, in Method 1-1-2a, the base station may be ambiguous as to which symbol type the PHR included in the terminal was generated on. For example, PUSCH is scheduled on non-SBFD symbols, but depending on whether the PHR is triggered on non-SBFD symbols or on SBFD symbols, the symbol type of the power parameter used to generate the PHR may differ. Methods to resolve this are disclosed.
[0454] For example, the terminal may include a 1-bit field in the Single Entry PHR MAC-CE format indicating the symbol type in which the PHR is triggered. If the 1-bit field is set to '0', it indicates that the PHR was triggered from a non-SBFD symbol, and if it is set to '1', it indicates that the PHR was triggered from an SBFD symbol. Alternatively, the opposite is also possible. The 1-bit field may be included in place of the 'R' (reserved bit) of the Single Entry PHR MAC-CE format shown in FIG. 13.
[0455] For example, the terminal may include a 1-bit field in the Single Entry PHR MAC-CE format indicating the type of PHR (whether it is an Actual PHR or a Virtual PHR). If the 1-bit field is set to '0', it indicates that an actual PHR has been triggered, and if it is set to '1', it indicates that a virtual PHR has been triggered. Alternatively, the opposite is also possible. The 1-bit field may be included in place of the 'R' (reserved bit) of the Single Entry PHR MAC-CE format shown in FIG. 13. Here, if an Actual PHR is indicated, it may mean that the type of the symbol for which the PHR was triggered is the same as the type of the symbol for which PUSCH was scheduled. Here, if a Virtual PHR is indicated, it may mean that the type of the symbol for which the PHR was triggered is different from the type of the symbol for which PUSCH was scheduled.
[0456] For example, the terminal may include a 1-bit field in the Single Entry PHR MAC-CE format indicating the symbol type to which the PHR is triggered and a 1-bit field indicating the type of the PHR (whether it is an Actual PHR or a Virtual PHR). The two aforementioned 1-bit fields may be included in place of the 2-bit 'R' (reserved bit) of the Single Entry PHR MAC-CE format shown in FIG. 13.
[0457] In the example described above, when PUSCH repetition transmission is performed, the terminal may perform PHR reporting based on the earliest PUSCH repetition. That is, in the example described above, the symbol type corresponding to PUSCH may be the symbol type corresponding to the earliest PUSCH repetition.
[0458] In the example described above, when PUSCH repeat transmission is performed, all PUSCH repeats may need to be scheduled for the same symbol type. For example, a terminal may be configured by a base station so that PUSCH repeat transmissions are all repeated only for the same symbol type. In this case, based on the method described above, one PHR may be included in the PUSCH repeat transmission. On the other hand, if the terminal is configured by a base station to allow PUSCH repeat transmissions for different symbol types, the Single Entry PHR MAC-CE format according to the first method described above may not be applied. In this case, based on the second method described below, multiple PHRs may be included in the PUSCH repeat transmission.
[0459] The above example may be applied only when at least one power parameter corresponding to the PUSCH transmitted in a non-SBFD symbol and at least one power parameter corresponding to the PUSCH transmitted in an SBFD symbol are identical. If the power parameters are different, multiple PHRs may be included in the repeated PUSCH transmission based on the second method described below.
[0460] The above-described example may be used depending on the configuration of the base station. For example, the base station may be configured to report only one PHR to the terminal. If multiple (2) PHR reports are configured to the terminal, multiple PHRs may be included in the PUSCH repeated transmission based on the second method described below.
[0461] Method 2: Method for transmitting multiple PHRs via PUSCH
[0462] In the second method, PUSCH may include both PHR generated based on non-SBFD symbols and PHR generated based on SBFD symbols.
[0463] Method 2-1: The terminal can generate an Actual PHR based on a symbol type corresponding to PUSCH, and can generate a Virtual PHR based on a symbol type that is not a symbol type corresponding to PUSCH. For example,
[0464] - When PUSCH is scheduled to a non-SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the non-SBFD symbol and a Virtual PHR based on at least one power parameter corresponding to the SBFD symbol.
[0465] - When PUSCH is scheduled to an SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the SBFD symbol and a Virtual PHR based on at least one power parameter corresponding to a Non-SBFD symbol.
[0466] Method 2-2: The terminal can generate an Actual PHR based on the symbol type that triggers the PHR, and can generate a Virtual PHR based on a symbol type that is not the symbol type that triggers the PHR. For example,
[0467] - When the PHR is triggered at a non-SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the non-SBFD symbol and a Virtual PHR based on at least one power parameter corresponding to the SBFD symbol.
[0468] - When the PHR is triggered at an SBFD symbol, the terminal may include an Actual PHR based on at least one power parameter corresponding to the SBFD symbol and a Virtual PHR based on at least one power parameter corresponding to a non-SBFD symbol.
[0469] Method 2-3: The terminal can generate an Actual PHR for two symbol types (SBFD symbols and non-SBFD symbols). For example,
[0470] - The terminal may include a first Actual PHR based on at least one power parameter corresponding to a non-SBFD symbol, and a second Actual PHR based on at least one power parameter corresponding to an SBFD symbol.
[0471] For reference, when generating the above Actual PHR, scheduling information of a PUSCH scheduled for a different symbol type may be used. For example, if the PHR is generated based on SBFD symbols and the PUSCH is scheduled for non-SBFD symbols, the terminal uses values determined based on the scheduling information of the PUSCH scheduled for non-SBFD symbols ( , , MPR, A-MPR, P-MPR, and At least one of) can be used to generate the PHR of the SBFD symbol. For example, if the PHR is generated based on a non-SBFD symbol and PUSCH is scheduled on an SBFD symbol, the terminal uses values determined based on the scheduling information of the PUSCH scheduled on the SBFD symbol ( , , MPR, A-MPR, P-MPR, and At least one of) can be used to generate a PHR of non-SBFD symbols.
[0472] Below, we will describe the PHR MAC-CE format proposed in this disclosure for reporting multiple PHRs.
[0473] FIG. 17 illustrates a PHR MAC-CE format for multiple PHR reports according to one embodiment of the present disclosure.
[0474] Referring to FIG. 17, the PHR MAC-CE format for multiple PHR reports may consist of 3 Octets (=24 bits). However, each field described below is not required to be included and may be omitted as necessary.
[0475] The above PHR MAC-CE format may include a plurality of power headrooms (PH1 field and PH2 field).
[0476] Here, the PH1 field indicates a power headroom value determined in the first symbol type, and the PH2 field indicates a power headroom value determined in the second symbol type. For example, the first symbol type is a non-SBFD symbol and the second symbol type is an SBFD symbol, and the power headroom of the non-SBFD symbol may be included in a position preceding the power headroom of the SBFD symbol.
[0477] Here, the PH1 field indicates the power headroom value of the symbol type corresponding to the symbol for which PUSCH is scheduled, and PH2 indicates the power headroom value of another symbol, and the power headroom value of the symbol type corresponding to the symbol for which PUSCH is scheduled may be included in a position preceding the power headroom value of another symbol.
[0478] Here, the PH1 field is the Actual PHR and the PH2 field is the Virtual PHR, and the Actual PHR may be included in a position preceding the Virtual PHR.
[0479] Multiple SRS resource sets are configured for the terminal, and one of the SRS resource sets may correspond to a non-SBFD symbol, and the other may correspond to an SBFD symbol. The terminal can identify at least one power parameter corresponding to each SRS resource set. The at least one power parameter may be used in a PUSCH of the corresponding symbol type. Additionally, a unique index may be assigned to each SRS resource set. Here, the PH1 field indicates the power headroom value of the symbol type corresponding to the lower index value of the SRS resource set, and the PH2 field indicates the power headroom value corresponding to the higher index value of the SRS resource set.
[0480] Referring to Fig. 17, the PHR MAC-CE format for multiple PHR reporting includes one P CMAX,f,C Fields may be included. P CMAX,f,c The field can indicate the maximum output power value set to the terminal used to generate the PHR. The said value can be transmitted after being quantized into 6 bits. The said P CMAX,f,c The field may indicate the maximum output power value determined from the symbol type where the Actual PHR is reported. Here, the above P CMAX,f,c The field can indicate the maximum output power value determined from the type of symbol to which PUSCH is scheduled. Here, the above P CMAX,f,c The field can indicate the maximum output power value determined from the symbol type triggered by the PHR. Here, the above P CMAX,f,c The field can indicate the maximum output power value corresponding to PH 1.
[0481] The R field is a reserved 1 bit and can be set to '0'. The P field indicates whether P-MPR (power-management power reduction) is applied to meet MPE (maximum permissible exposure) requirements that limit electromagnetic exposure to the human body, and can be 1 bit. The DPC (delta power class) field is a value for the terminal's power class and can have a length of 2 bits. The MPE field is 2 bits long and indicates the power backoff applied to meet MPE requirements when the P field is set to 1, and can have a length of 2 bits. The V field is 1 bit and can indicate whether the Power Headroom (PH) value belonging to the same octet is Actual PHR or Virtual PHR.
[0482] FIG. 18 illustrates a PHR MAC-CE format for multiple PHR reports according to one embodiment of the present disclosure.
[0483] Referring to FIG. 18, the PHR MAC-CE format for multiple PHR reports may consist of 4 Octets (=32 bits). However, each field described below is not required to be included and may be omitted as necessary.
[0484] The above PHR MAC-CE format may include a plurality of power headrooms (PH1 field and PH2 field). Specific details regarding PH1 and PH2 can be found in the description of FIG. 17.
[0485] In addition, the above PHR MAC-CE format includes a plurality of P CMAX,f,C (P CMAX,f,C 1 field, P CMAX,f,C 2 fields) values may be included. Here, P CMAX,f,C Field 1 indicates the maximum output power value corresponding to Field PH1, and P CMAX,f,CField 2 can indicate the maximum output power value corresponding to the PH2 field.
[0486] According to Fig. 18(a), in the PHR MAC-CE format, the PH1 and PH2 fields are placed first in the leading part, and subsequently P CMAX,f,c 1 Field and P CMAX,f,c 2 fields can be placed.
[0487] According to Fig. 18(b), in the preceding part of the PHR MAC-CE format, the PH1 field and P CMAX,f,c Field 1 is placed first, followed by Field PH2 and P CMAX,f,c 2 fields can be placed.
[0488] The R field is a reserved 1 bit and can be set to '0'. The P field indicates whether P-MPR (power-management power reduction) is applied to meet MPE (maximum permissible exposure) requirements that limit electromagnetic exposure to the human body, and can be 1 bit. The DPC (delta power class) field is a value for the terminal's power class and can have a length of 2 bits. The MPE field is 2 bits long and indicates the power backoff applied to meet MPE requirements when the P field is set to 1, and can have a length of 2 bits. The V field is 1 bit and can indicate whether the Power Headroom (PH) value belonging to the same octet is Actual PHR or Virtual PHR.
[0489] The PHR MAC-CE format for multiple PHR reporting of FIGS. 17 and 18 described above may include a 1-bit field indicating the symbol type in which the PHR is triggered. If the 1-bit field is set to '0', it indicates that the PHR was triggered from a non-SBFD symbol, and if it is set to '1', it indicates that the PHR was triggered from an SBFD symbol. Alternatively, the opposite is also possible. The 1-bit field may be included in place of the 1-bit 'R' (reserved bit) shown in FIGS. 17 and 18, respectively.
[0490] In the PHR MAC-CE format for multiple PHR reporting of FIGS. 17 and 18 described above, the V field may indicate whether the value of the power headroom (PH) belonging to the same octet is an Actual PHR or a Virtual PHR. Here, if an Actual PHR is indicated, it may mean that the type of symbol triggered by the PHR is the same as the type of symbol scheduled by PUSCH. Here, if a Virtual PHR is indicated, it may mean that the type of symbol triggered by the PHR is different from the type of symbol scheduled by PUSCH.
[0491] <Multiple Cell Scenario>
[0492] According to the present disclosure, a terminal may be capable of uplink transmission in a plurality of cells through dual access and / or carrier coupling. In this case, the terminal may transmit a plurality of PHRs for the plurality of cells by including them in a PUSCH. Some of the plurality of cells may be cells with SBFD resources configured, and some of the other cells may be cells without SBFD resources configured.
[0493] For convenience, the description herein assumes that the terminal transmits multiple PHRs to two cells, but the scope of the present disclosure is not limited thereto. For example, the first cell may be a cell in which the SBFD resource is not set (TDD / FDD cell), and the second cell may be a cell in which the SBFD resource is set (SBFD cell).
[0494] When a PHR is triggered at a terminal, the PHR may be included in and transmitted via the PUSCH of the first cell. The terminal may include both the PHR of the first cell and the PHR of the second cell in the PUSCH and transmit them. Unless otherwise noted, the PHR of the first cell may be an Actual PHR generated based on the PUSCH scheduled for the first cell. The PHR of the second cell may be an Actual PHR or a Virtual PHR according to the method described below. The PHR of the second cell may include one PHR or multiple PHRs.
[0495] In a situation where multiple cells exist, the terminal can transmit PHR to PUSCH based on at least one of the methods described below or a combination thereof.
[0496] Method 3: Method for generating the PHR of a second cell based on a single symbol type
[0497] In the third method, the terminal may determine a symbol type for generating a PHR of a second cell based on a PUSCH of a first cell containing a PHR, or independently of a PUSCH of the first cell. A PHR of the second cell may be generated based on the determined symbol type and included in a PUSCH of the first cell.
[0498] The terminal can determine whether there is a second cell's PUSCH that overlaps with the first cell's PUSCH in the time axis. If there is a second cell's PUSCH that overlaps with a scheduled symbol of the first cell's PUSCH, the terminal can determine that the first cell's PUSCH and the second cell's PUSCH overlap.
[0499] If there is a second cell PUSCH that overlaps with the first cell's PUSCH in the time axis, the terminal can generate an Actual PHR based on power parameters corresponding to the scheduled symbol type (non-SBFD symbol or SBFD symbol) of the second cell's PUSCH. The Actual PHR may be included in the first cell's PUSCH.
[0500] If there is no PUSCH of the second cell that overlaps with the PUSCH of the first cell in the time axis, the terminal can generate a Virtual PHR based on one symbol type of the second cell. Here, the method for determining one symbol type to generate the Virtual PHR is as follows.
[0501] Method 3-1: When a PHR is triggered in a second cell, the terminal can determine which symbol type of the second cell the PHR was triggered from. The terminal can generate a Virtual PHR based on the symbol type at the time when the PHR was triggered in the second cell.
[0502] Method 3-2: The terminal can generate a Virtual PHR based on the types of symbols in the second cell that overlap with the PUSCH of the first cell. For example, if all the symbols in the second cell that overlap with the PUSCH of the first cell are non-SBFD symbols, the terminal can generate a Virtual PHR based on at least one power parameter corresponding to the non-SBFD symbols. If all the symbols in the second cell that overlap with the PUSCH of the first cell are SBFD symbols, the terminal can generate a Virtual PHR based on at least one power parameter corresponding to the SBFD symbols. If some of the symbols in the second cell that overlap with the PUSCH of the first cell are non-SBFD symbols and the rest are SBFD symbols, the terminal can generate a Virtual PHR based on at least one power parameter corresponding to the type of the earliest symbol in time. As another example, if some of the symbols of the second cell that overlap with the PUSCH of the first cell are non-SBFD symbols and the rest are SBFD symbols, the terminal can generate a Virtual PHR based on at least one power parameter corresponding to a predetermined symbol type (non-SBFD symbol or SBFD symbol).
[0503] Meanwhile, if there is a PUSCH in a slot of a second cell that overlaps with a slot scheduled for a PUSCH of a first cell, the terminal can determine that the PUSCH of the first cell and the PUSCH of the second cell overlap. If the slot scheduled for a PUSCH of the first cell overlaps with multiple slots of the second cell, the terminal determines the overlap based on the earliest slot, and if there is a PUSCH in this slot, it can determine that the PUSCH of the first cell and the PUSCH of the second cell overlap. If there are multiple PUSCHs in the slots of the second cell, the terminal can determine that the PUSCH that is earliest in time overlaps.
[0504] Method 4: Method for generating the PHR of a second cell based on two symbol types
[0505] In the fourth method, the terminal may generate two PHRs for two symbol types (non-SBFD symbol and SBFD symbol) of the second cell and include them in the PUSCH of the first cell.
[0506] Here, one of the two PHRs may be an Actual PHR and the other may be a Virtual PHR.
[0507] Here, both of the two PHRs can be Actual PHRs.
[0508] Here, both of the two PHRs can be Virtual PHRs.
[0509] The method for determining whether each PHR is an Actual PHR or a Virtual PHR is as follows.
[0510] The terminal can determine whether there is a second cell's PUSCH that overlaps with the first cell's PUSCH in the time axis. If there is a second cell's PUSCH that overlaps with a scheduled symbol of the first cell's PUSCH, the terminal can determine that the first cell's PUSCH and the second cell's PUSCH overlap.
[0511] If there is a PUSCH of a second cell that overlaps with the PUSCH of a first cell in the time axis, the terminal may generate an Actual PHR based on power parameters corresponding to a symbol type (non-SBFD symbol or SBFD symbol) corresponding to the PUSCH of the second cell, and generate a Virtual PHR based on power parameters corresponding to a different symbol type. The Actual PHR and the Virtual PHR may be included in the PUSCH of the first cell.
[0512] If there is no second cell PUSCH that overlaps with the first cell's PUSCH in the time axis, the terminal can generate Virtual PHRs for each of the two symbol types. The two Virtual PHRs can be included in the first cell's PUSCH.
[0513] If there are multiple PUSCHs of a second cell that overlap with the PUSCH of a first cell in the time axis, and some of the multiple PUSCHs are scheduled on SBFD symbols and the remaining ones are scheduled on non-SBFD symbols, the terminal can generate Actual PHRs for each of the two symbol types. That is, the terminal can generate an Actual PHR based on the scheduling information of the PUSCH scheduled on non-SBFD symbols, generate an Actual PHR based on the scheduling information of the PUSCH scheduled on SBFD symbols, and include the two Actual PHRs in the PUSCH of the first cell. Here, if there are multiple PUSCHs for a single symbol type, an Actual PHR can be generated for the PUSCH that is earliest in time.
[0514] FIG. 19 illustrates a case in which the PUSCH of a second cell overlaps with the PUSCH of a first cell according to one embodiment of the present disclosure and does not overlap with the PUSCH of a first cell.
[0515] Referring to FIG. 19, there may be no scheduled PUSCH in the symbol (1910) of the second cell that overlaps with the PUSCH (1900) of the first cell. There may be no scheduled PUSCH in the symbol (1911) of the second cell that overlaps with the PUSCH (1901) of the first cell. There may be no scheduled PUSCH in the symbol (1912) of the second cell that overlaps with the PUSCH (1902) of the first cell.
[0516] According to the third method, the terminal may include an Actual PHR of a first cell (non-SBFD cell or TDD / FDD cell) and a Virtual PHR of a second cell (SBFD cell) in PUSCH (1900 or 1901 or 1902).
[0517] According to the 3-1 method, when a Virtual PHR of the 2nd cell (SBFD cell) is generated, the Virtual PHR can be generated based on the symbol type at the time when the PHR was triggered.
[0518] According to method 3-2, the terminal can determine the symbol type of the second cell that overlaps with the PUSCH of the first cell and generate a Virtual PHR based thereon. More specifically, since the symbol types of the symbols (1910) that overlap with PUSCH (1900) are all SBFD symbols, a Virtual PHR can be generated based on the SBFD symbols and included in PUSCH (1900). Since the symbol types of the symbols (1912) that overlap with PUSCH (1902) are all non-SBFD symbols, a Virtual PHR can be generated based on the non-SBFD symbols and included in PUSCH (1902). Since the symbols (1911) that overlap with PUSCH (1901) include both non-SBFD symbols and SBFD symbols, a Virtual PHR can be generated based on the SBFD symbol, which is the earliest symbol in time, and included in PUSCH (1901).
[0519] According to the fourth method, the terminal may include an Actual PHR of a first cell (non-SBFD cell or TDD / FDD cell) and a Virtual PHR of a non-SBFD symbol type and a Virtual PHR of an SBFD symbol type in a second cell (SBFD cell).
[0520] FIG. 20 illustrates a case where the PUSCH of a first cell and the PUSCH of a second cell overlap according to one embodiment of the present disclosure.
[0521] Referring to FIG. 20, there may be a scheduled PUSCH (2020) in the symbol (2010) of the second cell that overlaps with the PUSCH (2000) of the first cell. There may be two scheduled PUSCHs (2020, 2021) in the symbol (2011) of the second cell that overlaps with the PUSCH (2001) of the first cell. There may be a scheduled PUSCH (2021) in the symbol (2012) of the second cell that overlaps with the PUSCH (2002) of the first cell.
[0522] According to the third method, the terminal may include the Actual PHR of the first cell (non-SBFD cell or TDD / FDD cell) and the Actual PHR of the second cell (SBFD cell) in the PUSCH (2000 or 2001 or 2002). Here, the Actual PHR of the second cell may be generated based on a symbol type corresponding to the PUSCH (2020 or 2021) of the second cell that overlaps with the PUSCH (2000 or 2001 or 2002) of the first cell. More specifically, if the PUSCH (2020) of the second cell that overlaps with the PUSCH (2000) of the first cell is scheduled to a non-SBFD symbol, the Actual PHR of the second cell may be generated based on the power parameter of the non-SBFD symbol. If the PUSCH (2021) of the second cell, which overlaps with the PUSCH (2002) of the first cell, is scheduled in an SBFD symbol, the Actual PHR of the second cell can be generated based on the power parameters of the SBFD symbol. Since the PUSCH (2001) of the first cell overlaps with the two PUSCHs (2020, 2021) of the second cell, the Actual PHR of the second cell can be generated based on the one PUSCH (2020) that is the earliest in time among the PUSCHs. Although not shown in this drawing, if the one PUSCH (2020) that is the earliest in time is scheduled in a non-SBFD symbol, the Actual PHR of the second cell can be generated based on the power parameters of the non-SBFD symbol. On the other hand, as shown in FIG. 20, if the earliest PUSCH (2020) in time is scheduled in the SBFD symbol, the Actual PHR of the second cell can be generated based on the power parameters of the SBFD symbol.
[0523] According to the fourth method, the terminal may include an Actual PHR of a first cell (non-SBFD cell or TDD / FDD cell) and two Actual PHRs of a second cell (SBFD cell) (or {one Actual PHR and one Virtual PHR}) in a PUSCH. For example, if there is one PUSCH of a second cell that overlaps with the PUSCH of a first cell, an Actual PHR may be generated based on a symbol type corresponding to the one PUSCH of the second cell, and a Virtual PHR may be generated based on another symbol type. For example, if there are multiple PUSCHs of a second cell that overlap with the PUSCH of a first cell, the terminal may generate an actual PHR based on a PUSCH scheduled to a non-SBFD symbol of the second cell, and generate an Actual PHR based on a PUSCH scheduled to an SBFD symbol of the second cell.
[0524] FIG. 21 is a drawing illustrating the structure of a terminal in a wireless communication system according to one embodiment of the present disclosure.
[0525] Referring to FIG. 21, the terminal may include a transceiver (referring to a terminal receiver (2100) and a terminal transmitter (2110)), a memory (not shown), and a terminal processing unit (2105, or a terminal control unit or processor). According to the communication method of the terminal described above, the transceiver (2100, 2110), memory, and terminal processing unit (2105) of the terminal may operate. The terminal processing unit (2105, 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.
[0526] 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.
[0527] 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.
[0528] 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.
[0529] Additionally, the processor may control a series of processes to enable the terminal to operate according to the aforementioned embodiments. For example, the processor may be configured to generate one or more PHRs for SBFD operation and transmit them through the transceiver, according to various embodiments proposed in this disclosure. There may be multiple processors, and the processors may perform component control operations of the terminal by executing a program stored in memory.
[0530] FIG. 22 is a drawing illustrating the structure of a base station in a wireless communication system according to one embodiment of the present disclosure.
[0531] Referring to FIG. 22, the base station may include a transceiver unit (2200) and a base station transmitter (2210), a memory (not shown), and a base station processing unit (2205, or a base station control unit or processor). According to the communication method of the base station described above, the transceiver unit (2200, 2210), the memory, and the base station processing unit (2205) of the base station may operate. The base station processing unit (2205, 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.
[0532] 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.
[0533] 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.
[0534] 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.
[0535] 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, according to various embodiments proposed in the present disclosure, the processor may be configured to receive one or more PHRs for SBFD operation through the transceiver. There may be multiple processors, and the processors may perform control operations of the base station components by executing a program stored in memory.
[0536] 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.
[0537] 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.
[0538] 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.
[0539] 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.
[0540] 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.
[0541] 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.
[0542] 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.
[0543] 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 compromised.
[0544] 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. A method performed by a terminal of a wireless communication system, A step of receiving configuration information for a time resource including SBFD (subband full duplex) symbols and non-SBFD (non-SBFD) symbols from a base station; A step of identifying that a PHR (power headroom report) has been triggered; A step of identifying whether the type of scheduled symbol for the PUSCH (physical uplink shared channel) for the above PHR is the SBFD symbol or the non-SBFD symbol; A step of calculating an actual PHR based on at least one power control parameter corresponding to the type of the identified symbol; and A method comprising the step of transmitting the PUSCH containing the actual PHR to the base station.
2. In Paragraph 1, A method characterized in that, when the above PUSCH is configured to be transmitted through a plurality of PUSCH iterations, the type of the symbol to which the above PUSCH is scheduled is determined as the type of the symbol in which the PUSCH iteration that is earliest in time among the plurality of PUSCH iterations is located.
3. In Paragraph 1, A method characterized in that the above PUSCH further comprises a virtual PHR calculated based on at least one power control parameter corresponding to the type of symbol for which the PUSCH is scheduled and the type of symbol other than the PUSCH.
4. In Paragraph 1, The above PUSCH is transmitted through the first cell, and A method characterized in that the above PUSCH further includes a virtual PHR calculated based on at least one power control parameter corresponding to the type of symbol of a second cell superimposed in time with the above PUSCH.
5. In Paragraph 1, The above PHR further includes a step of identifying whether the type of the triggered symbol is the SBFD symbol or the non-SBFD symbol, and A method characterized in that the type of symbol for which the above PUSCH is scheduled is the same as the type of symbol for which the above PHR is triggered.
6. A method performed by a base station of a wireless communication system, A step of transmitting configuration information for a time resource including SBFD (subband full duplex) symbols and non-SBFD (non-SBFD) symbols to a terminal; and The method includes the step of receiving a PUSCH (physical uplink shared channel) for a PHR (power headroom report) triggered at the terminal from the terminal, and The above PUSCH includes an actual PHR, and A method characterized in that the actual PHR is calculated based on at least one power control parameter corresponding to the type of symbol for which the PUSCH is scheduled, among the SBFD symbol or the non-SBFD symbol.
7. In Paragraph 6, A method characterized in that, when the above PUSCH is configured to be received through a plurality of PUSCH iterations, the type of the symbol to which the PUSCH is scheduled is determined as the type of the symbol where the PUSCH iteration that is earliest in time among the plurality of PUSCH iterations is located.
8. In Paragraph 6, The above PUSCH is received through the first cell, and The above PUSCH further includes a virtual PHR calculated based on at least one power control parameter corresponding to a type of symbol different from the type of symbol scheduled by the PUSCH, or a type of symbol of a second cell that is temporally superimposed with the PUSCH. A method characterized in that the type of symbol for which the above PUSCH is scheduled is the same as the type of symbol for which the above PHR is triggered.
9. In a terminal of a wireless communication system, At least one transceiver; At least one processor connected to the above at least one transceiver so as to be able to communicate; and The terminal is connected to communicate with at least one processor and is capable of executing individually or in any combination of the at least one processor, so that the terminal, Receive configuration information for a time resource including SBFD (subband full duplex) symbols and non-SBFD (non-SBFD) symbols from a base station, and Identify that the PHR (power headroom report) has been triggered, and The PUSCH (physical uplink shared channel) for the above PHR identifies whether the type of scheduled symbol is the above SBFD symbol or the above non-SBFD symbol, and Calculate the actual PHR based on at least one power control parameter corresponding to the type of the identified symbol above, and A terminal comprising a memory that stores a command causing the PUSCH containing the actual PHR to be transmitted to the base station.
10. In Paragraph 9, A terminal characterized in that, when the above PUSCH is configured to be transmitted through a plurality of PUSCH repetitions, the type of the symbol to which the above PUSCH is scheduled is determined as the type of the symbol in which the PUSCH repetition that is earliest in time among the plurality of PUSCH repetitions is located.
11. In Paragraph 9, The above PUSCH is transmitted through the first cell, and A terminal characterized in that the above PUSCH further includes a virtual PHR calculated based on at least one power control parameter corresponding to a type of symbol different from the type of symbol scheduled by the above PUSCH, or a type of symbol of a second cell that is temporally superimposed with the above PUSCH.
12. In Paragraph 9, An instruction executable individually or in any combination of the above at least one processor further causes the terminal to identify whether the type of symbol triggered by the PHR is the SBFD symbol or the non-SBFD symbol, and A terminal characterized in that the type of symbol for which the above PUSCH is scheduled is the same as the type of symbol for which the above PHR is triggered.
13. In a base station of a wireless communication system, At least one transceiver; At least one processor connected to the above at least one transceiver so as to be able to communicate; and The base station is connected to communicate with at least one processor and is capable of executing individually or in any combination of the at least one processor, and, Transmit configuration information for a time resource including SBFD (subband full duplex) symbols and non-SBFD (non-SBFD) symbols to a terminal, and It includes a memory that stores a command causing to receive a PUSCH (physical uplink shared channel) for a PHR (power headroom report) triggered at the terminal, and The above PUSCH includes an actual PHR, and A base station characterized in that the actual PHR is calculated based on at least one power control parameter corresponding to the type of symbol for which the PUSCH is scheduled, among the SBFD symbol or the non-SBFD symbol.
14. In Paragraph 13, A base station characterized in that, when the above PUSCH is configured to be received through a plurality of PUSCH repetitions, the type of the symbol to which the above PUSCH is scheduled is determined as the type of the symbol where the PUSCH repetition that is earliest in time among the plurality of PUSCH repetitions is located.
15. In Paragraph 13, The above PUSCH is received through the first cell, and The above PUSCH further includes a virtual PHR calculated based on at least one power control parameter corresponding to a type of symbol different from the type of symbol scheduled by the PUSCH, or a type of symbol of a second cell that is temporally superimposed with the PUSCH. A base station characterized in that the type of symbol for which the above PUSCH is scheduled is the same as the type of symbol for which the above PHR is triggered.