Method and apparatus for transferring beam information in wireless communication system

Abstract

This terminal method may comprise the steps of: receiving, from a base station, configuration information for an event-detection reference signal (ED-RS) resource set including at least one ED-RS resource; monitoring an occurrence of an event or events by using at least a part of the at least one ED-RS resource; and when an occurrence of at least one event is monitored, transmitting, to the base station, a first report for reporting the at least one event that has occurred.

Description

Method and device for transmitting beam information in a wireless communication system

[0001] The present invention relates to a wireless communication system, and more particularly, to a terminal-driven beam reporting method and device.

[0002] With the advancement of information and communication technology, various wireless communication technologies are being developed. Representative wireless communication technologies include LTE (long term evolution) and NR (new radio), both of which are defined by the 3rd generation partnership project (3GPP) standards. LTE can be one of the 4th generation (4G) wireless communication technologies, and NR can be one of the 5th generation (5G) wireless communication technologies.

[0003] To handle the rapidly increasing volume of wireless data following the commercialization of 4G communication systems (e.g., communication systems supporting LTE), 5G communication systems (e.g., communication systems supporting NR) that utilize higher frequency bands (e.g., frequency bands higher than 6 GHz) than the frequency bands of 4G communication systems (e.g., frequency bands below 6 GHz) are being considered. 5G communication systems can support enhanced Mobile Broadband (eMBB), Ultra-Reliable and Low Latency Communication (URLLC), and massive Machine Type Communication (mMTC). Discussions are ongoing regarding 6G communication systems that will follow 5G communication systems.

[0004] UE-initiated beam management is a new beam management method being discussed in 3GPP Release-19, and is a concept that contrasts with the existing network-initiated method. In the existing beam management method, the network mainly selects the optimal beam through measurements of CSI-RS and / or SSB, and the terminal operates passively. However, 3GPP Release-19 is discussing a mechanism that allows the terminal to actively search for beams and select the optimal beam. This allows the terminal to perform its own beam measurement and selection without waiting for commands from the network, and enables improved beam management, especially in environments where beam diversity is important, such as millimeter wave (mmWave) and FR2 bands. Currently, 3GPP Release-19 is working on specific standardization of the operation method of UEI beam management, signaling procedures, and cooperation mechanisms between the network and the terminal.

[0005] The purpose of the present invention to solve the above problems is to provide a UE-initiated beam information reporting method and a device therefor in a wireless communication system.

[0006] According to one embodiment of the present invention for achieving the above object, a method of a terminal may include: receiving configuration information on a set of event-detection reference signal (ED-RS) resources including at least one ED-RS resource from a base station; monitoring occurrence of an event(s) using at least a part of the at least one ED-RS resource; and, when occurrence of at least one event is monitored, transmitting a first report for reporting the at least one event that has occurred to the base station.

[0007] The method may further include: receiving a first instruction from the base station to change quasi-co-location (QCL) information of the at least one ED-RS resource; and changing the QCL information of the at least one ED-RS resource according to the first instruction.

[0008] The above first instruction may be received as included in a MAC (medium access control) CE (control element) or may be received through a specific MAC CE (or MAC subPDU) format.

[0009] The method may further include a step of determining that the occupation of at least one CPU (CSI processing unit) has begun at a time when the occurrence of at least one event is monitored or when the first report is transmitted to the base station.

[0010] The method may further include, after transmitting the first report, transmitting to the base station a second report including information about measurement value(s) for at least some ED-RS resources associated with the occurrence of the at least one event, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources associated with the occurrence of the at least one event.

[0011] The above measurement value(s) may be L1-RSRP (layer 1-reference signal received power) value(s).

[0012] The first report is transmitted via a physical uplink control channel (PUCCH), and the second report may be transmitted via a PUCCH or a physical uplink shared channel (PUSCH).

[0013] The first report or the second report may include information about at least one event that occurred.

[0014] The method may further include a step of determining that the occupation of at least one CPU has begun from the time the second report is transmitted to the base station.

[0015] If at least some of the ED-RS resources include a specific RS, the terminal can monitor the occurrence of at least one event by measuring a downlink RS corresponding to a reception beam of the terminal derived from a transmission configuration indicator (TCI) state or QCL information of the specific RS on behalf of the specific RS.

[0016] The above specific RS may be a TRS (tracking reference signal), and the downlink RS may be a SSB (synchronization signal block) or a CSI-RS (channel state information-reference signal) for beam management.

[0017] A method of a base station according to an embodiment of the present invention for achieving the above object may include: transmitting, to a terminal, configuration information for a set of event-detection reference signal (ED-RS) resources including at least one ED-RS resource; and receiving, from the terminal, a first report for reporting the occurrence of at least one event among event(s) monitored using at least a part of the at least one ED-RS resource.

[0018] The method may further include a step of transmitting, from the terminal, a first instruction for changing quasi-co-location (QCL) information of the at least one ED-RS resource.

[0019] The above first instruction may be transmitted in a medium access control (MAC) CE (control element) or may be transmitted through a specific MAC CE (or MAC subPDU) format.

[0020] The method may further include, after receiving the first report, receiving from the terminal a second report including information about measurement value(s) for at least some ED-RS resources associated with the occurrence of the at least one event, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources associated with the occurrence of the at least one event.

[0021] The first report is received via a physical uplink control channel (PUCCH), and the second report can be received via a PUCCH or a physical uplink shared channel (PUSCH).

[0022] According to one embodiment of the present invention for achieving the above object, a terminal includes at least one processor, and the at least one processor may perform the steps of: receiving configuration information on an event-detection reference signal (ED-RS) resource set including at least one ED-RS resource from a base station; monitoring occurrence of an event(s) using at least a part of the at least one ED-RS resource; and transmitting a first report for reporting the at least one event that has occurred to the base station when occurrence of the at least one event is monitored.

[0023] The at least one processor may further cause the terminal to perform the steps of: receiving a first instruction from the base station to change QCL (quasi-co-location) information of the at least one ED-RS resource; and changing the QCL information of the at least one ED-RS resource according to the first instruction.

[0024] The at least one processor may further perform the step of: after transmitting the first report, transmitting a second report to the base station, the second report including information about measurement value(s) for at least some ED-RS resources associated with the at least one event occurrence, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources associated with the at least one event occurrence.

[0025] The first report is transmitted via a physical uplink control channel (PUCCH), and the second report may be transmitted via a PUCCH or a physical uplink shared channel (PUSCH).

[0026] According to embodiments of the present disclosure, a terminal can perform its own beam measurement and selection without waiting for network commands, enabling improved beam management, particularly in environments where beam diversity is critical, such as millimeter wave (mmWave) and FR2 bands. This enables smooth communication and improved communication performance in communication systems.

[0027] Figure 1 is a conceptual diagram illustrating a first embodiment of a communication system.

[0028] Figure 2 is a block diagram illustrating a first embodiment of a communication node constituting a communication system.

[0029] Figure 3 is a flowchart illustrating a beam failure detection and reporting procedure.

[0030] FIG. 4 is a flowchart illustrating an event detection and reporting procedure according to one embodiment of the present invention.

[0031] FIG. 5 is a flowchart illustrating an event detection and reporting procedure according to another embodiment of the present invention.

[0032] FIG. 6 is a timing diagram for explaining the time relationship of a terminal initiation reporting procedure according to an embodiment of the present invention.

[0033] Figure 7 is a conceptual diagram for explaining a case where multiple ED-RS resources belonging to one CMR set are received.

[0034] Figure 8 is a timing diagram illustrating CPU occupancy of non-aperiodic CSI reporting.

[0035] Figure 9 is a timing diagram illustrating CPU occupancy of aperiodic CSI reporting.

[0036] Figures 10 to 12 are timing diagrams for explaining the relationship between CMR / IMR resources, CSI reference resources, event triggers, and CSI reporting timing and CPU occupancy.

[0037] FIG. 13 and FIG. 14 are timing diagrams for explaining the time relationship required for a terminal initiation reporting procedure according to another embodiment of the present invention.

[0038] FIGS. 15 and 16 are timing diagrams for explaining the concept of applying a time window to transmit a beam report according to embodiments of the present invention.

[0039] Figure 17 is a timing diagram for explaining a case where a terminal detects two events.

[0040] FIG. 18 is a timing diagram for explaining a concept of performing reporting on two events of a terminal in two stages according to an embodiment of the present invention.

[0041] FIG. 19 is a flowchart illustrating a method for determining CPU occupation and release according to embodiments of the present invention.

[0042] FIGS. 20 to 23 are conceptual diagrams for explaining procedures in which an event is triggered based on ED-RS and a UCI corresponding to the event is generated according to embodiments of the present invention.

[0043] Figures 24 to 26 are conceptual diagrams for explaining a UCI expression method according to embodiments of the present invention.

[0044] This disclosure may be subject to various modifications and various embodiments. Specific embodiments are illustrated and described in detail in the drawings. However, this is not intended to limit the disclosure to specific embodiments, but rather to encompass all modifications, equivalents, and alternatives falling within the spirit and technical scope of the disclosure.

[0045] While terms such as "first" and "second" may be used to describe various components, these components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a "second component," and similarly, a second component could also be referred to as a "first component." The term "and / or" encompasses any combination of multiple related items or any one of multiple related items.

[0046] In embodiments of the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.” Furthermore, in embodiments of the present disclosure, “at least one of A and B” may mean “at least one of A or B” or “at least one of combinations of one or more of A and B.”

[0047] When a component is referred to as being "connected" or "connected" to another component, it should be understood that it may be directly connected or connected to that other component, but that there may be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0048] The terminology used in this disclosure is only used to describe specific embodiments and is not intended to limit the present disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this disclosure, it should be understood that the terms "comprises" or "has" indicate the presence of a feature, number, step, operation, component, part, or combination thereof described in the specification, but do not preclude the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

[0049] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person of ordinary skill in the art to which this disclosure pertains. Terms defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and shall not be interpreted in an idealized or overly formal sense unless explicitly defined herein.

[0050] Hereinafter, preferred embodiments of the present disclosure will be described in more detail with reference to the attached drawings. In order to facilitate an overall understanding in describing the present disclosure, identical reference numerals are used for identical components in the drawings, and redundant descriptions of identical components are omitted.

[0051] A communication system to which embodiments according to the present disclosure are applied will be described. The communication system to which embodiments according to the present disclosure are applied is not limited to the scope described below, and embodiments according to the present disclosure can be applied to various communication systems. Here, the term "communication system" may be used interchangeably with "communication network."

[0052] In an embodiment, "an operation (e.g., a transmission operation) is set" may mean that "setting information for the operation (e.g., an information element, a parameter)" and / or "information instructing performance of the operation" are signaled. "An information element (e.g., a parameter) is set" may mean that the information element is signaled. The signaling may be at least one of system information (SI) signaling (e.g., transmission of a system information block (SIB) and / or a master information block (MIB)), RRC signaling (e.g., transmission of an RRC message, an RRC parameter, and / or an upper layer parameter), MAC control element (CE) signaling (e.g., transmission of a MAC message and / or a MAC CE and / or a MAC subPDU), or PHY signaling (e.g., transmission of downlink control information (DCI), uplink control information (UCI), and / or sidelink control information (SCI)).

[0053] Figure 1 is a conceptual diagram illustrating a first embodiment of a communication system.

[0054] Referring to FIG. 1, the communication system (100) may include a plurality of communication nodes (110-1, 110-2, 110-3, 120-1, 120-2, 130-1, 130-2, 130-3, 130-4, 130-5, 130-6). In addition, the communication system (100) may further include a core network (e.g., a serving-gateway (S-GW), a packet data network (PDN)-gateway (P-GW), a mobility management entity (MME)). If the communication system (100) is a 5G communication system (e.g., a new radio (NR) system), the core network may include an access and mobility management function (AMF), a user plane function (UPF), a session management function (SMF), etc.

[0055] A plurality of communication nodes (110 to 130) can support a communication protocol (e.g., LTE communication protocol, LTE-A communication protocol, NR communication protocol, etc.) specified in the 3GPP (3rd generation partnership project) standard. The plurality of communication nodes (110 to 130) may support CDMA (code division multiple access) technology, WCDMA (wideband CDMA) technology, TDMA (time division multiple access) technology, FDMA (frequency division multiple access) technology, OFDM (orthogonal frequency division multiplexing) technology, Filtered OFDM technology, CP (cyclic prefix)-OFDM technology, DFT-s-OFDM (discrete Fourier transform-spread-OFDM) technology, OFDMA (orthogonal frequency division multiple access) technology, SC (single carrier)-FDMA technology, NOMA (non-orthogonal multiple access) technology, GFDM (generalized frequency division multiplexing) technology, FBMC (filter bank multi-carrier) technology, UFMC (universal filtered multi-carrier) technology, SDMA (space division multiple access) technology, etc. Each of the plurality of communication nodes may have the following structure.

[0056] Figure 2 is a block diagram illustrating a first embodiment of a communication node constituting a communication system.

[0057] Referring to FIG. 2, a communication node (200) may include at least one processor (210), a memory (220), and a transmission / reception device (230) that is connected to a network and performs communication. In addition, the communication node (200) may further include an input interface device (240), an output interface device (250), a storage device (260), etc. Each component included in the communication node (200) may be connected by a bus (270) and communicate with each other.

[0058] However, each component included in the communication node (200) may be connected through an individual interface or individual bus centered around the processor (210), rather than a common bus (270). For example, the processor (210) may be connected to at least one of a memory (220), a transmission / reception device (230), an input interface device (240), an output interface device (250), and a storage device (260) through a dedicated interface.

[0059] The processor (210) can execute program commands stored in at least one of the memory (220) and the storage device (260). The processor (210) may refer to a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor in which the methods according to embodiments of the present disclosure are performed. Each of the memory (220) and the storage device (260) may be configured with at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory (220) may be configured with at least one of a read-only memory (ROM) and a random access memory (RAM).

[0060] Referring again to FIG. 1, the communication system (100) may include a plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) and a plurality of terminals (130-1, 130-2, 130-3, 130-4, 130-5, 130-6). Each of the first base station (110-1), the second base station (110-2), and the third base station (110-3) may form a macro cell. Each of the fourth base station (120-1) and the fifth base station (120-2) may form a small cell. The fourth base station (120-1), the third terminal (130-3), and the fourth terminal (130-4) may be within the cell coverage of the first base station (110-1). The second terminal (130-2), the fourth terminal (130-4), and the fifth terminal (130-5) may be within the cell coverage of the second base station (110-2). The fifth base station (120-2), the fourth terminal (130-4), the fifth terminal (130-5), and the sixth terminal (130-6) may be within the cell coverage of the third base station (110-3). The first terminal (130-1) may be within the cell coverage of the fourth base station (120-1). The sixth terminal (130-6) may be within the cell coverage of the fifth base station (120-2).

[0061] Here, each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) may be referred to as a NodeB (NB), an evolved NodeB (eNB), a gNB, an advanced base station (ABS), a high reliability-base station (HR-BS), a base transceiver station (BTS), a radio base station, a radio transceiver, an access point, an access node, a radio access station (RAS), a mobile multihop relay-base station (MMR-BS), a relay station (RS), an advanced relay station (ARS), a high reliability-relay station (HR-RS), a home NodeB (HNB), a home eNodeB (HeNB), a road side unit (RSU), a radio remote head (RRH), a transmission point (TP), a transmission and reception point (TRP), etc.

[0062] Each of the plurality of terminals (130-1, 130-2, 130-3, 130-4, 130-5, 130-6) may be referred to as a user equipment (UE), terminal equipment (TE), advanced mobile station (AMS), high reliability-mobile station (HR-MS), terminal, access terminal, mobile terminal, station, subscriber station, mobile station, portable subscriber station, node, device, OBU (on board unit), etc.

[0063] Meanwhile, each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) may operate in a different frequency band or may operate in the same frequency band. Each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) may be connected to each other via an ideal backhaul link or a non-ideal backhaul link, and may exchange information with each other via the ideal backhaul link or the non-ideal backhaul link. Each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) may be connected to the core network via the ideal backhaul link or the non-ideal backhaul link. Each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) can transmit a signal received from the core network to the corresponding terminal (130-1, 130-2, 130-3, 130-4, 130-5, 130-6), and can transmit a signal received from the corresponding terminal (130-1, 130-2, 130-3, 130-4, 130-5, 130-6) to the core network.

[0064] Additionally, each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) may support multi-input multi-output (MIMO) transmission (e.g., single user (SU)-MIMO, multi user (MU)-MIMO, massive MIMO, etc.), coordinated multipoint (CoMP) transmission, carrier aggregation (CA) transmission, transmission in an unlicensed band, device to device communication (D2D) (or, proximity services (ProSe)), Internet of Things (IoT) communication, dual connectivity (DC), etc. Here, each of the plurality of terminals (130-1, 130-2, 130-3, 130-4, 130-5, 130-6) can perform an operation corresponding to the base station (110-1, 110-2, 110-3, 120-1, 120-2) and an operation supported by the base station (110-1, 110-2, 110-3, 120-1, 120-2). For example, the second base station (110-2) can transmit a signal to the fourth terminal (130-4) based on the SU-MIMO scheme, and the fourth terminal (130-4) can receive a signal from the second base station (110-2) by the SU-MIMO scheme. Alternatively, the second base station (110-2) can transmit signals to the fourth terminal (130-4) and the fifth terminal (130-5) based on the MU-MIMO method, and each of the fourth terminal (130-4) and the fifth terminal (130-5) can receive signals from the second base station (110-2) based on the MU-MIMO method.

[0065] Each of the first base station (110-1), the second base station (110-2), and the third base station (110-3) can transmit a signal to the fourth terminal (130-4) based on the CoMP scheme, and the fourth terminal (130-4) can receive a signal from the first base station (110-1), the second base station (110-2), and the third base station (110-3) based on the CoMP scheme. Each of the plurality of base stations (110-1, 110-2, 110-3, 120-1, 120-2) can transmit and receive a signal with terminals (130-1, 130-2, 130-3, 130-4, 130-5, 130-6) within its cell coverage based on the CA scheme. Each of the first base station (110-1), the second base station (110-2), and the third base station (110-3) can control D2D between the fourth terminal (130-4) and the fifth terminal (130-5), and each of the fourth terminal (130-4) and the fifth terminal (130-5) can perform D2D under the control of the second base station (110-2) and the third base station (110-3).

[0066] Next, the operating methods of communication nodes in a communication system will be described. Even if a method (e.g., signal transmission or reception) performed by a first communication node among communication nodes is described, a corresponding second communication node can perform a method (e.g., signal reception or transmission) corresponding to the method performed by the first communication node. In other words, if the operation of a terminal is described, the corresponding base station can perform an operation corresponding to the operation of the terminal. Conversely, if the operation of a base station is described, the corresponding terminal can perform an operation corresponding to the operation of the base station.

[0067]

[0068] To reduce data error rates, a lower modulation and coding scheme (MCS) level (e.g., a lower MCS index) can be applied. To prevent the size of the field indicated by the downlink control information (DCI) from increasing, the most frequently used MCS(s) can be selected. Subsequently, to apply a lower MCS, a repetitive transmission operation can be supported. Since quadrature phase shift keying (QPSK) has the lowest modulation rate, this can further reduce the code rate. In particular, since the transmit power in uplink (UL) transmission is limited, the repetitive transmission operation can be performed in the time domain rather than the frequency domain.

[0069] eMBB (enhanced Mobile Broadband) traffic and URLLC (Ultra-Reliable and Low Latency Communication) traffic can use low MCS for different purposes. eMBB traffic can use low MCS to extend the reach. On the other hand, URLLC traffic can use low MCS to reduce latency and achieve low error rates. Because of their different requirements, eMBB traffic can be transmitted repeatedly even if latency occurs, while URLLC traffic can be transmitted using a new MCS (e.g., a lower MCS) rather than repeated transmissions. The new MCS can be set by an RRC message and / or DCI.

[0070] To support repetitive transmissions for eMBB traffic in the time domain, physical uplink shared channel (PUSCH) repetition (e.g., PUSCH repetition type A) may be introduced. In this case, PUSCH allocated in slot units may be repeatedly transmitted. To extend the reach, time resources may be allocated to multiple slots. When PUSCH repetition type A is used, the time resources may be configured by an RRC message and / or a DCI. The number of repeated PUSCH transmissions may be indicated by an RRC message, and the time resource in which the PUSCH is transmitted in the first slot may be indicated by a DCI (e.g., a type 2 CG (configured grant) or a dynamic grant) or an RRC message (e.g., a type 1 CG).

[0071] Repeated transmission of URLLC traffic may not be appropriate because it incurs delay. However, if a sufficiently low MCS is used, the delay for decoding URLLC traffic can be reduced. That is, if a sufficiently low MCS is used, the number of REs (resource elements) to which URLLC traffic is mapped may increase, and the base station (e.g., the base station decoder) must wait until all REs are received. In this case, the delay for decoding URLLC traffic can be reduced.

[0072] On the other hand, if a PUSCH with a relatively high MCS is repeatedly transmitted, the base station can perform a decoding operation using only some REs. Therefore, the time point of first successful decoding in a PUSCH repeated transmission (e.g., a PUSCH repeated transmission with a relatively high MCS) may be earlier than the time point of first successful decoding in a PUSCH transmission without repetition (e.g., a PUSCH transmission with a low MCS). If PUSCH repetition type A is used, unnecessary delay may occur, and PUSCH repetition type B may be introduced to reduce the delay time for repeated transmission. If PUSCH repetition type B is used, a PUSCH allocated in units of mini-slots may be repeatedly transmitted. If PUSCH repetition type B is used, the time resource may be set by an RRC message and / or DCI. The combination of the reference time resource and the number of repeated transmissions of a PUSCH instance can be indicated by a DCI (e.g., Type 2 CG and / or dynamic grant) or an RRC message (e.g., Type 1 CG).

[0073] In order to control the transmit power of SRS resources indicated by SRI (SRS (sounding reference signal) resource indicator), the base station can estimate the path attenuation for each SRS resource. The base station can control the transmit power for the SRS resource(s) using DCI. The transmit power of the SRS resource(s) can be controlled based on the estimated path attenuation. The DCI can be scheduling DCI (e.g., DCI format 0_0, DCI format 0_1, DCI format 0_2, DCI format 1_0, DCI format 1_1, or DCI format 1_2) or GC (group common)-DCI (e.g., DCI format 2_2 or DCI format 2_3). The DCI can include a field indicating a transmit power control (TPC) command, and the TPC command can be used to control the transmit power of a terminal. For example, the transmission power of a terminal may be increased or decreased based on a TPC command included in the DCI. To determine the transmission power of a PUSCH, the terminal may consider a value obtained based on path attenuation, a value according to a TPC command included in the DCI, and / or a PUSCH bandwidth indicated by the DCI.

[0074] A base station can configure two or more sets for a terminal using higher layer signaling. The terminal can receive configuration information for the two or more sets from the base station. Each element constituting the two or more sets can be a transmit power parameter(s), which can be designated to suit different scenarios (e.g., a URLLC scenario, an eMBB scenario). The terminal can receive a scheduling DCI or an activating DCI from the base station that allocates PUSCH resources, and the scheduling DCI or the activating DCI can indicate a set for interpreting the transmit power parameter(s). If the sets of transmit power parameter(s) are different, the magnitude of the increase or decrease in transmit power designated by the same TPC command can be different.

[0075] When Type 1 CG or Type 2 CG is used, the transmit power may be determined based on DCI format 2_3 for the SRI associated with the PUSCH instance. When Type 2 CG is used, the activation DCI may indicate a set of transmit power parameter(s) applicable to a PUSCH occasion. A PUSCH occasion may mean a PUSCH instance. The UE may obtain a TPC command for the SRI by receiving a GC (group common)-DCI, interpret the TPC command to be suitable for the set of transmit power parameter(s) indicated by the base station, and derive the transmit power applicable to the PUSCH instance based on the interpretation result.

[0076] In a dynamically scheduled PUSCH transmission, the UE can derive the transmit power applied to the PUSCH instance based on a combination of GC-DCI and scheduling DCI. The UE can identify the TPC command of the SRI by receiving the GC-DCI and store the identified TPC command. In a dynamically scheduled PUSCH transmission, a set of transmit power parameter(s) and / or TPC command applied to the PUSCH occasion can be indicated by scheduling DCI. The UE can derive the transmit power applied to the PUSCH instance based on the transmit power of the SRI associated with the PUSCH instance.

[0077] Repeated HARQ-ACK transmissions can be indicated (or configured) by higher-layer signaling for each physical uplink control channel (PUCCH) format. The number of repeated transmissions for PUCCH format i can be independently configured. i can be 1, 3, or 4. A terminal can repeatedly transmit a PUCCH format in slots. In this case, the PUCCH format can be transmitted using the same time resource in each slot.

[0078] Uplink control information (UCI) types can be classified according to the type of information included in the UCI. UCI can include at least one of scheduling request (SR), L1-RSRP (reference signal received power), HARQ-ACK, or channel state information (CSI). In embodiments, UCI and UCI type can be used interchangeably. In a repeated transmission operation of UCI, only one UCI type can be transmitted. To support this operation, the priority of UCI types can be defined in the technical specification. One UCI type can be selected, and a PUCCH including one UCI type can be repeatedly transmitted. In this case, the UE can assume that no other UCI types are transmitted before the transmission of the corresponding UCI type is completed. To support this operation, the base station can instruct the UE to transmit UCI (e.g., SR or HARQ-ACK) after the PUCCH transmission is completed. The latency for a given UCI transmission may be high, and this latency may act as a scheduling constraint for the base station.

[0079] When "transmission of HARQ-ACKs in the same slot (or the same sub-slot)" or "PUCCH time resources indicated by DCI and / or RRC message allocating PDSCH (physical downlink shared channel) overlap each other," a terminal may generate a HARQ codebook to be transmitted in one PUCCH (e.g., one PUCCH time resource). Within the HARQ codebook, HARQ-ACK bits may be arranged according to an order defined in a technical specification. Information bits may be generated by the above-described operation. The terminal may generate coded bits by performing an coding operation.

[0080] Reed-Muller codes or polar codes can be used in encoding operations. The code rate applied in encoding operations can be indicated by higher-layer signaling. For example, in the PUCCH format, a single value can be the code rate and can be indicated to the terminal.

[0081] A codeword can be mapped to a PUCCH. In a PUCCH repeated transmission operation, a UCI type can be generated as a codeword. When a PUCCH is transmitted once, information bits of one UCI type or two or more UCI types can be concatenated, and the terminal can generate a codeword by performing the same encoding operation on the information bits. When a Reed-Muller code or a polar code is used, performing a soft combining operation may be difficult in implementation. Therefore, even when a PUCCH is repeatedly transmitted, the same codeword can be transmitted, and the base station can perform a chase combining operation on the same codeword. The encoded bits or codeword can mean a bit string in which multiple code blocks (code blocks) are concatenated. A modulation operation can be performed on the codeword, and the result of the modulation operation can be mapped to an RE.

[0082] Meanwhile, identical UCI types may be considered different information. Identical UCI types that are considered different information can be mapped. For example, UCIs may be created to support traffic with different priorities. UCIs supporting eMBB traffic (e.g., SR or HARQ-ACK) may be considered distinct information from UCIs supporting URLLC traffic (e.g., SR or HARQ-ACK). In this case, even if UCI types are identical, they may be distinguished as different information.

[0083] Encoded UCI can be mapped to PUCCH. The same preprocessing scheme (e.g., spatial information, spatial relation) can be maintained in PUCCH transmission operations. Alternatively, the use of different preprocessing schemes for each PUCCH can be permitted through RRC signaling from the base station in PUCCH transmission operations.

[0084] To support URLLC traffic, it may be desirable for a terminal to perform frequent reception operations on downlink (DL) resources and / or frequent transmission operations on uplink (UL) resources. In a time division duplex (TDD) system, a terminal may operate based on a half-duplex scheme. Therefore, the support time for DL ​​traffic and / or UL traffic may increase depending on the slot pattern. On the other hand, in a frequency division duplex (FDD) system, a terminal can utilize DL resources and UL resources. Therefore, the above-described problem in a TDD system may not occur in an FDD system. An FDD system can use two or more carriers. If two or more serving cells are configured for a terminal in a TDD system, the terminal can utilize DL resources and UL resources.

[0085] In a communication system including at least one carrier to which FDD is applied (hereinafter referred to as an "FDD carrier"), there may be no problem with the delay time of the terminal. In a communication system including only carrier(s) to which TDD is applied (hereinafter referred to as "TDD carrier(s)"), there may be a problem with the delay time of the terminal. To solve the above problem, slots in TDD carriers may be configured according to different patterns.

[0086] Carrier aggregation (CA) can be configured in the UE, and PCell and SCell(s) can be activated. Depending on whether a cell includes a common search space (CSS) set, it can be classified as a PCell or SCell. For example, a PCell may include a CSS set, and an SCell may not include a CSS set. To reduce latency in a communication system supporting URLLC traffic, slots with different patterns can be configured and / or indicated to the UE.

[0087] eMBB or URLLC traffic can be supported in licensed bands, but can also be supported in unlicensed bands. Carriers in either the licensed or unlicensed bands can be utilized independently, but depending on base station configuration, carriers in both licensed and unlicensed bands can be utilized through frequency aggregation.

[0088] In an embodiment, two or more terminals may receive data from one or more TRPs and transmit data to one or more TRPs. It may be assumed that one base station or one server performs management operations and / or scheduling operations for one or more TRPs among the plurality of TRPs. The TRPs may be directly connected. Alternatively, the TRPs may be connected via a base station. The above-described connection may be a connection according to an Xn interface or a wireless interface (e.g., an interface of 3GPP NR).

[0089] Shadow regions can occur between the areas supported by TRPs. Therefore, TRPs can resolve shadow regions through cooperative transmission. Cooperative transmission can be performed on terminals located between TRPs. Even if shadow regions do not occur, wireless link quality can be improved by installing numerous TRPs (or base stations) to transmit and receive large amounts of data.

[0090] Depending on the cooperative transmission and reception of TRPs, communication methods can be classified into dynamic point selection (DPS) and joint transmission (JT). For a specific set of physical resource blocks (PRBs), DPS may be a method of receiving data through a single TRP, and JT may be a method of receiving data through two or more TRPs. Dynamic point blanking (DPB) may be a type of JT. When DPB is used, the terminal may not receive data from some TRPs and may receive data from the remaining TRPs. JT can be classified into coherent JP and noncoherent JP. Depending on whether a coherent combining operation is performed on signals received from TRPs, either coherent JP or noncoherent JP may be used.

[0091] Depending on the latency and traffic capacity of the backhaul network to which base stations or TRPs are connected, TRPs may or may not participate in real-time cooperative transmission and reception. A terminal can support JT through a single DCI (i.e., single DCI (sDCI)). Alternatively, a terminal can support JT through multiple DCIs (i.e., multi-DCI (mDCI)).

[0092] When using sDCI, a terminal can transmit and receive data with TRPs. When using sDCI, it is desirable for TRPs to be able to collaborate without delay through a backhaul network. When using mDCI, a terminal can transmit and receive data with some TRPs. When a terminal transmits and receives data with other TRPs, it is difficult for these TRPs to collaborate in real time through the backhaul network. Therefore, it is desirable to allocate semi-fixed resources to these TRPs.

[0093] In the existing technical specifications, the CORESET pool index was introduced to identify a TRP. A CORESET pool is a set of CORESETs, and the transmission configuration indication (TCI) state applied to each CORESET can be independently indicated to the UE via RRC signaling and / or MAC control element (CE). Therefore, the CORESET pool index may not necessarily correspond to a TRP. More specifically, if a TRP is divided into a transmission point (TxP) and a reception point (RxP), the CORESET pool index can correspond to an RxP. For example, an Rx beam received from a TxP can be derived from the TCI state, and uplink signals / channels scheduled from DCIs discovered in CORESETs belonging to a CORESET pool indicated by a single CORESET pool index can be interpreted as being received by the same RxP.

[0094] For a terminal to benefit from coherent combining, the TRPs for that terminal must be synchronized to a certain degree, and CSI reports for those TRPs must be shared. If this is not the case, performing noncoherent combining at the terminal is more advantageous in terms of performance.

[0095] When a terminal is mounted on a vehicle, constraints on its size and weight can be relaxed. However, for terminals carried by a person, portability may also be a consideration.

[0096] To expand the signal coverage area, small cells or IAB nodes can be deployed. The throughput of small cells or IAB nodes can be affected by the quality of the backhaul link, and securing a backhaul network can be expensive. As an alternative, wireless relay devices can be deployed to deliver higher-quality signals to terminals. Wireless relay devices can be categorized into several types depending on the method of signal transmission. Wireless relay devices that support more functions can exhibit performance similar to that of a base station, while wireless relay devices that support fewer functions can be deployed at a lower cost. The wireless relay device considered in the present invention allows beamforming to terminals, but can perform the minimum function of transmitting data. The base station must transmit wireless signals to control these wireless relay devices. These wireless signals can be used to set appropriate parameters for the wireless relay devices.

[0097] In the present disclosure, transmission of a channel may mean transmission of a message, data, signal, and / or information through the channel, and reception of a channel may mean transmission of a message, data, signal, and / or information through the channel. The channel may be a physical downlink control channel (PDCCH), a physical downlink shared channel (PDSCH), a physical uplink control channel (PUCCH), a physical uplink shared channel (PUSCH), a physical random access channel (PRACH), a physical sidelink broadcast channel (PSBCH), a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), and / or a physical sidelink feedback channel (PSFCH).

[0098] In a communication system supporting TDD (time division duplex), downlink (DL) communication and uplink (UL) communication can be performed in different time resources. The ratio between the DL time, in which DL communication is performed, and the UL time, in which UL communication is performed, can be determined based on the ratio of traffic (e.g., DL traffic and / or UL traffic). For example, in an NR system, since the amount of DL traffic is greater than the amount of UL traffic, more DL slots can be allocated than UL slots. For example, slots (e.g., slot patterns) can be configured to repeat a DDDSU pattern. D can denote a DL slot, S can denote a slot including DL symbol(s), FL (flexible) symbol(s), and UL symbol(s), and U can denote a UL slot. The arrangement order of symbols in an S slot can be DL symbol(s)-FL symbol(s)-DL symbol(s). The base station can instruct or set the slot pattern to the terminal(s) through signaling (e.g., RRC signaling). The base station can indicate some FL symbol(s) among the FL symbols set by the RRC signaling as DL symbol(s) or UL symbol(s). The some FL symbol(s) can be indicated as DL symbol(s) or UL symbol(s) through DCI.

[0099] The terminal and base station may perform additional procedures to manage the radio link. Because the propagation characteristics of the wireless channel are poor in high-frequency bands, it is desirable for the terminal and base station to transmit and receive using a narrow beam. However, a terminal that has not yet established an RRC connection may not be able to receive a narrow beam. This is because the base station cannot transmit a narrow beam because it is unaware of the terminal's presence. Therefore, the base station transmits a wide beam, and the terminal receives it and responds with a wide beam. This process allows the RRC connection to be established, and the beam can then be gradually narrowed. Here, narrow beam or wide beam can refer to the beam width or beam gain. For convenience of explanation, the beam used for transmission can be referred to as the Tx beam, and the beam used for reception can be referred to as the Rx beam.

[0100]

[0101] The terminal can measure the strength of the beam and report it to the base station. DL RS (e.g., SSB or CSI-RS, or CSI-RS configured for beam management) can be measured to derive RSRP, or SINR can be derived by separately configuring CMR and / or IMR. Here, RSRP can be referred to as L1-RSRP because it does not go through L3 filtering. L1-RSRP / SINR is regarded as a CSI report and can be multiplexed with other UCI types if necessary. The strength of DL RS can be measured as L1-RSRP / SINR and transmitted to the base station on PUCCH (or PUSCH).

[0102]

[0103] A base station can instruct a terminal which beam to use for communication. The base station can use RRC signaling or MAC CE (or MAC SUBPDU) to instruct the terminal which receive beam (Rx) to use to receive PDCCH and PDSCH, and can instruct the terminal which transmit (Tx) beam to use to transmit PUCCH and PUSCH.

[0104] The base station can indicate the Rx beam and Tx beam of the terminal using independent indices. Alternatively, the base station can indicate the Rx beam and Tx beam of the terminal together using a single index. When a single index is used, the Rx beam and Tx beam of the terminal can be derived from the same downlink reference signal (DL RS) by taking advantage of the reciprocity of the wireless channel.

[0105] More specifically, the terminal can be configured with two DL-RSs that are used when deriving the Rx beam that should be applied to receive the DL signal / channel. The DL RSs are a qcl-typeA source RS and a qcl-typeD source RS. The qcl-typeA source RS can provide synchronization in the time domain and frequency domain, and the qcl-typeD source RS can provide the remaining processing for forming the corresponding Rx beam.

[0106] When a wireless channel satisfies certain conditions (e.g., equality), the terminal can derive a Tx beam to transmit an UL signal / channel. In this case, a qcl-typeD source RS can be used. The Rx beam for the DL signal / channel with this relationship and the Tx beam for the UL signal / channel can be indicated through a single index.

[0107] According to the prior art, a serving base station can indicate a list of candidate beams (CandidateRSList) to a terminal via RRC signaling. Thereafter, the base station can activate and allocate beam(s) from among the candidate beams to the terminal using MAC CE (or MAC SUBPDU) and / or DCI.

[0108] Some MAC CEs may only indicate the activation / deactivation of TCI states (e.g., TCI States Activation / Deactivation for UE-specific PDSCH MAC CE), while some MAC CEs may indicate a single TCI state (e.g., TCI State Indication for UE-specific PDCCH MAC CE).

[0109] When candidate beams need to be reset or updated, the serving base station must perform a reset procedure via RRC signaling, which can result in a time delay of hundreds of milliseconds. Controlling beams without resetting RRC requires using existing candidate beams, which can limit the freedom of beam selection. To address this issue, candidate beams can be managed using beam failure recovery (BFR) MAC CE. This provides a similar degree of freedom as managing candidate beams using RRC signaling. Similarly, path loss RS (PL-RS) can also be managed using MAC CE. When a terminal performs frequency aggregation, beam control can be performed independently for each component carrier (CC). Alternatively, similar beams can be controlled jointly across multiple CCs.

[0110]

[0111] Meanwhile, the terminal can detect beam failure and report it to the base station.

[0112] Figure 3 is a flowchart illustrating a beam failure detection and reporting procedure.

[0113] Referring to FIG. 3, the terminal (301) can receive a control channel from the base station (302) using a separate DL RS (e.g., beam failure detection (BFD)-RS) (S310). If the terminal (301) determines that it cannot normally receive the control channel, it can consider that a beam failure has occurred (S320). More specifically, the terminal (301) can determine that a beam failure instance (BFI) has occurred if it receives a virtual PDCCH and the block error rate (BLER) thereof is higher than a specific standard. The terminal can count the number of occurrences of BFI, and if the number exceeds a specific standard (e.g., beamFailureInstanceMaxCount), it can consider that a beam failure detection (BFD) has occurred.

[0114] The terminal determines the occurrence of BFD at the MAC layer and, based on this, can instruct the PHY layer to transmit UL signals / channels to restore the beam. For example, the terminal can transmit a PRACH if a beam failure occurs in the SpCell (S340). If the terminal performs frequency aggregation, the terminal can transmit a PUCCH containing an LRR (link recovery request) if a beam failure occurs in the SCell (S340). In other words, step S340 may be a step for transmitting a BFRQ (beam failure recovery request).

[0115] The terminal can indirectly inform the base station of a new beam through the UL resource selected for transmitting the PRACH or LRR. Therefore, the terminal must find a new beam that can be used during beam recovery before transmitting the PRACH / LRR (S330).

[0116] It can be assumed that an SSB index is derived from a random access occasion (RO) selected by the terminal, and that the base station can transmit control information for beam recovery to the terminal using the SSB index. In addition, an LRR can be derived through the PUCCH resource selected by the terminal, and that the base station can transmit control information for beam recovery using a specific SCell and / or DL ​​RS based on this. The terminal can then receive beam instruction information (BFRR (beam failure recovery response)) from the base station (S350) and recover the beam failure.

[0117]

[0118] During the beam measurement and reporting process and the beam failure recovery process, the terminal must follow the instructions of the base station and therefore must wait for a certain amount of time. This is because, after the terminal reports beam-related information, the base station must generate a response based on the information and transmit new control information to the terminal. The base station does not necessarily need to generate control information based on the information reported by the terminal. However, since the fading characteristics of the wireless channel change over time, it may be desirable to follow the terminal's report. In particular, when considering beam management, it may be desirable to directly reflect the terminal's report. On the other hand, when the base station performs scheduling for multiple terminals, it may be more effective not to directly reflect the report of a specific terminal. In addition, since the fading speed of the wireless channel becomes even faster when the terminal moves, it is desirable to introduce a method that can manage the beam more quickly.

[0119]

[0120] The transmission of UE-initiated beam information can be considered not only in beam management and beam recovery procedures, but also in the procedure for measuring and reporting beam strength. According to the prior art specification, for beam management, the UE can measure the RSRP and SINR of the DL RS and report the measured RSRP and SINR to the base station as a CSI report. Accordingly, the base station can trigger an aperiodic CSI report to the UE and receive an aperiodic CSI report from the UE, or receive a periodic / semi-persistent CSI report from the UE. In addition, the base station can transmit a beam instruction to the UE via MAC CE (or MAC SUBPDU) or DCI. As described in FIG. 3, according to the prior art specification, when the UE detects a beam failure, it must transmit a BFRQ to the base station, and then receive a BFRR to complete the beam recovery procedure.

[0121] In addition, considering the mobility of the terminal, the RSRP and SINR of the DL RS received from the neighboring base station (or neighboring TRP) can be measured. According to the conventional technical standard, the terminal can monitor the occurrence of specific event(s) to perform a handover. For example, handover events A1 to A6 can be considered as handover events that occur when the serving base station (or source base station) and the neighboring base station (or target base station) use the same radio access technology (RAT). In addition, events B1 and B2 can be considered as handover events involving two or more RATs. For convenience of explanation, these events can be collectively referred to as 'event An' and 'event Bn'.

[0122] For example, events can be defined as follows:

[0123] - Event A1: When the RSRP / RSRQ / SINR derived from the DL RS of the serving base station exceeds a certain standard.

[0124] - Event A2: When the RSRP / RSRQ / SINR derived from the DL RS of the serving base station does not exceed a certain standard.

[0125] - Event A3: When the RSRP / RSRQ / SINR derived from the DL RS of the neighboring base station is greater than the value obtained by adding a specific offset to the RSRP / RSRQ / SINR values ​​derived from the DL RS of the serving base station.

[0126] - Event A4: When the RSRP / RSRQ / SINR derived from the DL RS of the neighboring base station exceeds a certain standard.

[0127] - Event A5: When the RSRP / RSRQ / SINR derived from the DL RS of the serving base station does not exceed a certain criterion, and the RSRP / RSRQ / SINR derived from the DL RS of the neighboring base station exceeds another certain criterion.

[0128] - Event A6: When the RSRP / RSRQ / SINR derived from the DL RS of the serving base station is greater than the value obtained by adding a specific offset to the RSRP / RSRQ / SINR values ​​derived from the DL RS of the neighboring base station.

[0129] Through the event-based measurement procedure described above, the terminal can determine whether to perform a handover.

[0130] Events An and Bn have thresholds for RSRP, RSRQ, and / or SINR, and may be subject to hysteresis and offset. If the terminal receives a hysteresis value from the base station, that value can be used to determine both the trigger condition and the cancellation condition.

[0131] For example, if the measured value of DL RS is greater than (reference value + hysteresis), the trigger condition may be satisfied. Conversely, if the measured value of DL RS is less than (reference value - hysteresis), the cancel condition may be satisfied. Here, if the trigger condition is satisfied, it may mean that the terminal is moving away from the serving base station. If the cancel condition is satisfied, it may mean that the terminal is moving closer to the serving base station again. Depending on the event type, an additional offset may be applied, which can reduce events that may occur in the short term due to the movement of the terminal and enable more stable setting of the trigger condition and cancel condition.

[0132] Additionally, both RSRP and RSRQ considered in this section may be measurements that have undergone L3 filtering. It may be desirable to utilize L1-RSRP, L1-RSRQ, and SINR to detect events more quickly.

[0133]

[0134] When a terminal is instructed to a specific beam, the time to apply the beam may be considered. The Rx beam of the control channel (PDCCH) and the Rx beam of the scheduled data channel (PDSCH) may be the same or different. When monitoring CORESET 0, the terminal may use the most recent Rx beam among the Rx beams indicated by the MAC CE (or MAC subPDU) or the Rx beams derived from the Type1-PDCCH CSS set. When monitoring a CORESET other than CORESET 0, the terminal may use the Rx beam indicated through RRC signaling and / or the MAC CE (or MAC subPDU). The Rx beam of the PDSCH may be indicated through DCI. If the time interval between the last symbol of the PDCCH and the first symbol of the PDSCH is less than a specific threshold (e.g., timeDurationForQCL), the Rx beam of the PDSCH may follow the Rx beam of the PDCCH. On the other hand, if the time interval between the last symbol of the PDCCH and the first symbol of the PDSCH is greater than a certain threshold, the Rx beam of the PDSCH can be derived based on the TCI state index indicated in the DCI.

[0135] A terminal requires a certain amount of time and processing resources to generate a CSI report. The terminal may consume CPU (CSI processing unit)(s) to process a specific reportQuantity.

[0136] Example 1) If reportQuantity is set to none for receiving TRS (CSI-RS for tracking), CPU usage can be interpreted as 0.

[0137] Example 2) If reportQuantity includes RSRP and SINR, but is used for purposes other than TRS (e.g., when performing a beam refinement procedure or a P3 procedure, when repetition of DL RS is set to on), CPU usage can be interpreted as 1.

[0138] Example 3) If reportQuantity is indicated by tdcp (Time Domain Correlation Property), it can be interpreted that (1+Y) or (2+2Y) CPUs are occupied when processing Y delay values.

[0139] Example 4) reportQuantity may include PMI (Precoding Matrix Indicator) and various forms of CSI reports (e.g., CRI-RI-PMI-CQI, CRI-RI-i1, CRI-RI-i1-CQI, CRI-RI-CQI, CRI-LI-PMI-CQI, and other PMI-related information). CPU usage may be interpreted differently depending on the PMI configuration information.

[0140] When a base station triggers a CSI report (i.e., an aperiodic CSI report), the UE may assume that its CPU is already fully occupied and may allocate additional CPU to generate a new CSI report. For periodic or semi-persistent CSI reports, if the UE determines that it does not have enough CPU for some CSI reports, it may not drop them but may not update them.

[0141]

[0142] To enable faster beam management and recovery, the base station can instruct the terminal to report CSI frequently. However, this method requires a lot of feedback, so it may be more efficient for the terminal to proactively perform beam management and recovery when an event occurs. According to the proposed method, after detecting a specific event, the terminal can transmit the necessary configuration information to the base station via PUCCH or PUSCH. Furthermore, after a predetermined period of time, the terminal can reflect the information without further instructions from the base station. Here, events can occur under various conditions.

[0143]

[0144] Terminal-driven event detection and reporting procedures

[0145] FIG. 4 is a flowchart illustrating an event detection and reporting procedure according to one embodiment of the present invention.

[0146] Referring to FIG. 4, the terminal (401) can receive a DL RS (i.e., an ED (event detection)-RS) and interpret it as a metric that serves as a basis for various events (one or more events) (S410). For example, in the case of a beam failure event, the terminal can interpret the DL RS as a BFD-RS and derive the BLER using it. In the case of a beam measurement event, the terminal can measure and report the RSRP, RSRQ, and SINR of the DL RS. In the case of a handover event, the terminal can measure RSRP(s), RSRQ(s), and / or SINR(s) based on one or more DL RSs and compare them to determine the necessity of a handover. In addition, the terminal can recognize events A1 to A6 or separate events detected by the physical layer and derive an event identifier or event index (S420).

[0147] The terminal can generate UCI (uplink control information) or UL-SCH (e.g., MAC CE (or MAC subPDU)) based on the derived information, select a resource for reporting the same (S430), and transmit the generated UCI or UL-SCH to the base station via PUCCH or PUSCH (S440). Here, step S440 can be performed through one uplink transmission or two or more uplink transmissions. If two or more uplink transmissions are performed, the first transmission can be a PUCCH transmission, and subsequent additional transmissions can be PUSCH or PUCCH transmissions. If PUSCH is transmitted, all or part of the information derived by the terminal in step S420 can be included in the UCI or UL-SCH.

[0148] After a certain amount of time has passed, the terminal and base station can assume that the relevant parameters have been updated identically based on the same event (S450). This can be interpreted as meaning that the terminal and base station share the same parameters. This procedure can enable faster and more efficient beam management and recovery. Even after the terminal reports, the base station may perform additional signaling to change some parameters.

[0149] Referring back to Figure 4, after detecting an event, the terminal can generate and transmit a UCI (or UL-SCH) corresponding to the event. However, this process does not necessarily occur in a single step and may consist of two or more steps.

[0150] FIG. 5 is a flowchart illustrating an event detection and reporting procedure according to another embodiment of the present invention.

[0151] Referring to FIG. 5, an embodiment is illustrated in which steps S430 and S440 of FIG. 4 are performed in more detail. For example, if UCI or UL-SCH occurs in two stages, step S430 can be divided into S530-1 and S530-2. Similarly, if PUCCH or PUSCH is transmitted in two stages, step S440 can be divided into steps S540-1 and S540-2. In this case, the same procedure can be performed in the order of S530-1 --> S540-1 --> S530-2 --> S540-2. UCI (or UL-SCH) can be divided into two parts according to a specific method to be described later, and accordingly, PUCCH and PUSCH can perform the role of transmitting UCI or UL-SCH, respectively. Additionally, since the terminal can receive ED-RS periodically, step S510 may not necessarily follow the procedure of FIG. 4 or FIG. 5.

[0152] The proposed events can be utilized for various use cases, and depending on the use case, the method of measuring the current beam and the method of measuring a new beam can be different. For example, the first use case may correspond to a case where a new beam is searched for in order to change the beam, and the second use case may correspond to a case where a new beam is searched for in order to update the list of activated TCI states. The events can be derived based on the measurement results of the current beam and / or the measurement results of the new beam. In this process, when a DL RS resource or a set of resources is used, the resource can be referred to as an ED-RS, an ED-RS resource, or an ED-RS resource set.

[0153] Depending on the different purposes, the identifier of the ED-RS for measurements on the current beam can be derived from the index of the TCI state associated with the current beam. Conversely, the identifier of the ED-RS for measurements on a new beam can be derived from the index of the TCI state associated with the new beam or from the identifier of a separate DL RS.

[0154] For the first purpose, the terminal may regard the ED-RS used for measurements on the current beam as a qcl-typeD source RS with a TCI state indicating the current beam to the terminal. The terminal may receive upper layer signaling from the base station that can associate the ED-RS used for measurements on the new beam with a separate DL RS identifier. The terminal may perform measurements on the new beam using DL RS resources belonging to the measurement resource set.

[0155] According to the second purpose, the terminal may regard the ED-RS used for measurement of the current beam as a qcl-typeD source RS of one of the activated TCI states. At this time, the identifier of the ED-RS for measuring the current beam may be expressed as the identifier of the qcl-typeD source RS. In addition, the terminal may regard the ED-RS used for measurement of the new beam as a qcl-typeD source RS of one of the deactivated TCI states. Therefore, it is desirable for the terminal to report the identifier of the ED-RS and its measurement result so that the serving base station can utilize the deactivated TCI states for updating the list of activated TCI states.

[0156] In not all cases, measurements can be performed using the qcl-typeD source RS of the TCI state. For example, even if a specific RS (e.g., a tracking reference signal (TRS)) is regarded as an ED-RS, the function for the terminal to measure L1-RSRP or L1-SINR using it may not be supported in the prior art specifications. In such a case, the serving base station can instruct the terminal through upper layer signaling so that a separate DL RS identifier can be associated with the corresponding TCI state. Accordingly, the identifier of the ED-RS for measuring the current beam or a new beam can be expressed as the identifier of the qcl-typeD source RS or a separate DL RS identifier. That is, the terminal can measure the DL RS corresponding to the reception beam of the terminal, which is derived from the TCI (transmission configuration indicator) state or QCL information of the specific RS, instead of the specific RS. Here, the DL-RS indicated by a separate DL-RS identifier may be a synchronization signal block (SSB) or a CSI-RS for beam management.

[0157] FIG. 6 is a timing diagram for explaining the time relationship of a terminal initiation reporting procedure according to an embodiment of the present invention.

[0158] Referring to Fig. 6, when a certain event occurs, the UE can generate UCI or UL-SCH (e.g., MAC CE (or MAC subPDU)). The UE can be periodically allocated PUCCH or PUSCH, and the PUCCH can include periodic CSI reports or semi-persistent CSI reports. The PUSCH can include semi-persistent CSI reports, and a configured grant (CG) PUSCH can also be allocated. According to the proposed method, if the UE has no information to report, it may not transmit the PUCCH or PUSCH. This may correspond to the case where the UE fails to detect an event.

[0159] When a terminal detects an event, a preparation time may be required to prepare a report. After the preparation time, the UCI or UL-SCH (or its first part) may be transmitted on the first PUCCH or PUSCH that occurs. If the UCI or UL-SCH consists of two or more parts, the terminal may require a separate preparation time to derive the remaining parts. The terminal may transmit the remaining parts of the UCI or UL-SCH using the PUCCH or PUSCH. Alternatively, the time resources of the PUCCH / PUSCH for transmitting the remaining parts of the UCI or UL-SCH may occur periodically, and the terminal may transmit the PUCCH or PUSCH on the first time resource that occurs after the separate preparation time has elapsed.

[0160] PUCCH or PUSCH can only be transmitted on valid UL resources. For example, in a TDD system, a terminal cannot transmit UL signals / channels on DL symbols or DL ​​resource regions. Therefore, UL transmission is only possible on UL symbols, FL symbols (flexible), or SD symbols (subband full-duplex) with defined UL resource regions. This means that additional delay time may be required, separate from the preparation time.

[0161]

[0162] Depending on how the terminal initiates the UCI, the CPU may be occupied during the process of generating the UCI to determine whether an event exists or not. The terminal may need to measure RSRP, RSRQ, or SINR using the DL RS to detect events A1 to A6 or events B1 and B2. For this purpose, the terminal may be instructed about the DL RS resources by the base station. According to the prior art specification, the CPU occupied time may differ between non-aperiodic CSI reporting (i.e., periodic CSI reporting and semi-persistent CSI reporting) and aperiodic CSI reporting.

[0163]

[0164] A terminal may be instructed to monitor one or more events. Some events may be based on measuring multiple ED-RS resources and comparing the measured values ​​(L1-RSRP, L1-SINR, etc.). For example, the L1-RSRP of the reference ED-RS ( ) and L1-RSRP of other ED-RS( ) can be compared. A specific offset ( ) when applied, If this is established, an event can be detected (or triggered). For example, this method can correspond to event A3 in the prior art specification. In addition, an additional offset ( ) can also be taken into account to reflect the hysteresis of L1-RSRP.

[0165] In the proposed method, the ED-RS resource set may include a reference ED-RS and other ED-RS(s) that can replace the reference ED-RS. In addition, the ED-RS resource set and a predetermined offset ( and / or ) may be indicated to the terminal. In one example, the ED-RS resource set may consist of only periodic ED-RS resources. In one example, the reference ED-RS may mean the current beam or scheduled beam indicated to the terminal.

[0166] In the proposed method, the terminal can perform measurements only on some ED-RSs belonging to the ED-RS resource set. The terminal can report all or part of the measurement results to the base station. The number of measurement values ​​that can be reported on a single UL signal / channel can be indicated to the terminal via RRC signaling.

[0167] According to prior art standards, a set of RS resources may contain only one RS resource. This approach may not be suitable for event detection using ED-RS.

[0168] According to the prior art, RS resources belonging to an RS resource set form one mTRP hypothesis (or CoMP hypothesis), and a single CSI report can be derived. However, according to the proposed method, one CSI report can be derived from only one ED-RS resource belonging to an RS resource set. A UE can select one or more ED-RS resources based on some ED-RS resource(s) included in the ED-RS resource set. For example, an ED-RS resource set can be composed of N ED-RS resources, and a UE can detect an event using measurements for M ED-RS resources (M ≤ N).

[0169] An ED-RS resource set can be indicated to a UE via RRC signaling and can include multiple ED-RS resources. These ED-RS resources can be utilized for event detection. However, depending on the characteristics of the event, some ED-RS resource(s) may be unsuitable in the ED-RS resource set. For example, a UE may perform beam management by utilizing ED-RSs belonging to the ED-RS resource set. In this case, it may be desirable for the L1-RSRP or L1-SINR of the ED-RS resources for beam management to have a quality higher than a certain standard. This is because, when a certain event occurs while the UE performs beam management, it must be able to change the TCI state by utilizing another ED-RS belonging to the ED-RS resource set. Therefore, if a specific ED-RS resource has a quality lower than the L1-RSRP or L1-SINR standard, the ED-RS resource can be excluded from the ED-RS resource set. Alternatively, it may be desirable to add more suitable ED-RS resources to the ED-RS resource set.

[0170] In the proposed method, the TCI state (TCI state group) index(es) of ED-RS resource(s) belonging to the ED-RS resource set can be changed using MAC CE (or MAC subPDU).

[0171] In one example, an ED-RS resource set may include one or more ED-RS resources. Each ED-RS resource may be indicated (or activated) with a TCI state index. The UE may receive upper layer signaling (MAC CE or MAC subPDU) consisting of at least TCI state indices. The number of TCI state indices may be equal to the number of ED-RS resources. Each TCI state index may correspond one-to-one to each ED-RS resource. The upper layer signaling may also include other information to which the ED-RS resource set applies. For example, it may be a serving cell index or a BWP index.

[0172] In the proposed method, management such as addition and exclusion of ED-RS resources belonging to an ED-RS resource set can be performed using MAC CE (or MAC subPDU).

[0173] In one example, a MAC CE (or MAC subPDU) may contain identifiers of two or more ED-RS resources, in which case an operation may be performed where one ED-RS resource replaces another ED-RS resource.

[0174] In another example, a separate field in the MAC CE (or MAC subPDU) may indicate whether an ED-RS resource is to be added or excluded, and another field in the MAC CE (or MAC subPDU) may indicate the identifier of the ED-RS resource to be added or excluded.

[0175] An ED-RS resource set can include multiple ED-RS resources, and the number of ED-RS resources (H) can be determined through upper layer signaling. However, when managing an ED-RS resource set using MAC CE (or MAC subPDU), the number of ED-RS resources to be managed may not always match H. That is, the number of ED-RS resources managed through MAC CE (or MAC subPDU) at a specific point in time may vary.

[0176] In the proposed method, a MAC CE (or MAC SUBPDU) can always manage H ED-RS resources. This means that the size of the MAC CE (or MAC SUBPDU) can be determined through RRC signaling. Therefore, a fixed amount of UCI can be considered in the preparation procedure of the UL signal / channel through which the UE reports the measurement value. On the other hand, compared to methods that minimize the number of ED-RS resources included in the MAC CE (or MAC subPDU) (i.e., methods that must consider a variable amount of UCI), the proposed method can be implemented relatively simply.

[0177] In another proposed method, the information composing the MAC CE (or MAC subPDU) can support variable sizes. For example, the size (length) of the MAC CE (or MAC subPDU) can be derived from the MAC subheader. The size of the MAC CE (or MAC subPDU) can be determined based on the number of ED-RS resources to be managed, and this can be indicated in a single field.

[0178] Additionally, the size (length) of a MAC CE (or MAC subPDU) may be determined from the payload. Information about ED-RS resources to be managed within a MAC CE (or MAC subPDU) may be arranged in a specific order. Accordingly, one of the fields constituting the information of each ED-RS resource may indicate the presence or absence of the next information (i.e., information about the next ED-RS resource). For example, if the field has a specific value, it may indicate that information about additional ED-RS resources is included later. On the other hand, if the field has a different value, it may indicate that the ED-RS resource is the last resource managed in the ED-RS resource set by the MAC CE (or MAC subPDU).

[0179]

[0180] Meanwhile, some events may be based on comparing the measurements of an ED-RS with a predetermined boundary. For example, L1-RSRP of a specific ED-RS ( ) is the boundary value ( ) can be compared to. If a person is present, an event can be triggered. If , an event can be triggered. Additionally, an additional offset ( ) can also be considered to reflect the hysteresis of L1-RSRP. In the proposed method, the ED-RS resource set can include a reference ED-RS. The ED-RS resource set and a predetermined boundary value ( and / or ) can be directed to the terminal.

[0181]

[0182] As previously described, monitoring for one or more event(s) may be instructed or configured at the terminal.

[0183] According to the proposed method, the terminal can be instructed of event(s) and / or measurement resource(s) via RRC signaling.

[0184] According to another proposed method, the terminal can activate or deactivate certain event(s) and / or measurement resource(s) indicated via RRC signaling. For example, monitoring of two or more events (Event-A, Event-B, ...) can be indicated to the terminal via RRC signaling. In this case, Event-A can be deactivated according to a deactivation command, and Event-B can be activated according to an activation command.

[0185] According to another proposed method, the terminal may assume that the event(s) and / or measurement resource(s) indicated by RRC signaling are activated by default. Alternatively, the terminal may assume that the event(s) and / or measurement resource(s) are deactivated until a separate activation command is received. Here, the activation or deactivation command may be indicated via a MAC CE (or MAC subPDU).

[0186]

[0187] To detect an event, the terminal can derive a measurement value (L1-RSRP or L1-SINR) for each ED-RS resource included as a measurement resource. To fairly compare the measurement values, a reference time may be required. For example, there may be ED-RS resources with the same period but different slot offsets applied. Furthermore, the ED-RS resources may have different periods and different slot offsets. For example, a case may be considered where the first ED-RS and the second ED-RS have the same period but different slot offsets. The calculation for event detection may be performed depending on the terminal implementation, and the technical specification may define a method for determining an event detection method by utilizing the time resource of the ED-RS.

[0188] Figure 7 is a conceptual diagram for explaining a case where multiple ED-RS resources belonging to one CMR set are received.

[0189] Referring to Figure 7, a terminal can receive ED-RS resources belonging to a single CMR set at the same cycle. However, the time point at which an event condition is evaluated may vary depending on the definition of the event.

[0190] It is desirable for a serving cell or TRP to instruct a UE to receive ED-RS resources belonging to a CMR set at similar times once. The UE can evaluate an event condition after receiving all ED-RSs included in the CMR set according to a predetermined order of the ED-RS resources (or a predetermined order of the identifiers of the ED-RS resources). If the event condition is satisfied, the UE can increment a counter. If the counter exceeds a certain threshold, the UE can consider an event to have been detected. If an event is detected, the UE can generate a beam report to report to the serving base station.

[0191] According to the proposed method, a single CMR set can be commonly indicated to a terminal for two or more events to perform UE-initiated (UEI) reporting for two or more events, and the terminal can evaluate conditions for the two or more events using ED-RS resources belonging to the CMR set. According to another proposed method, a separate CMR set can be indicated to a terminal for each event to perform UEI reporting, and in this case, each CMR set can be used to evaluate conditions for one event.

[0192] For example, the CMR set for monitoring the first event and the CMR set for monitoring the second event may be the same, and some ED-RS resource(s) may be common to both CMR sets. Alternatively, two or more events may be monitored in a single CMR set. For some events, the event may be monitored using only some ED-RS resources belonging to a CMR set.

[0193] For example, a specific ED-RS may be considered as a qcl-D RS of a serving beam or a current beam (or TCI state), and the L1-RSRP value of the ED-RS may be measured and compared with a threshold. If the L1-RSRP of the ED-RS is determined to be less than the threshold, a counter value for event detection may be changed. A CMR set may consist of only one ED-RS, or a CMR set may be associated with two or more events. Among the ED-RSs belonging to the CMR set, an ED-RS corresponding to the serving beam or the current beam may be selected.

[0194] Depending on the metrics (L1-RSRP or L1-SINR) of two or more ED-RSs included in the CMR set, a specific order (Qth) of ED-RSs may be compared with a threshold value. When considering such an event, the terminal can evaluate the condition of the event after all ED-RSs included in the CMR set are received. Depending on the evaluation result, a counter associated with the event (or a counter associated with the ED-RS) may be changed. When a specific condition is met, the terminal can recognize the occurrence of the event and generate a beam report. When a 2-step report method is applied, the terminal can generate a first report.

[0195]

[0196] Relationship between CSI reporting timing and event trigger timing and CPU usage

[0197] Below, the type of CSI report, the measurement time, the event trigger time, and / or the relationship between the CSI report time and CPU occupancy are described.

[0198] Figure 8 is a timing diagram illustrating CPU occupancy of non-aperiodic CSI reporting.

[0199] Referring to Fig. 8, in case of non-aperiodic CSI reporting (periodic or semi-persistent CSI reporting), the CPU may be considered occupied when the terminal receives DL RS (CMR (channel measurement resource) and / or IMR (interference measurement resource)), and the CPU occupancy may be considered terminated when UCI is transmitted. Here, the CPU occupancy amount may be determined as described above.

[0200] Figure 9 is a timing diagram illustrating CPU occupancy of aperiodic CSI reporting.

[0201] Referring to FIG. 9, in the case of aperiodic CSI reporting, the CPU may be considered occupied when the terminal receives a UL grant (i.e., PDCCH) that triggers the aperiodic CSI reporting, and the CPU occupancy may be considered terminated when the UCI is transmitted.

[0202] As previously explained, a terminal can be allocated multiple UL resources temporally to transmit UCI, and UCI can be transmitted only when an event is detected. Therefore, event detection can be interpreted as a condition for triggering UCI transmission. It can also be interpreted that the CPU is occupied from the time when the terminal processing to detect the event begins. On the other hand, if the UCI is interpreted as being derived after the event is detected, it can also be interpreted that the CPU is occupied from the time the event occurs. This difference can be explained in more detail in FIGS. 10 and 11, which will be described later. Here, the event is depicted as being detected at a higher layer such as the MAC layer and triggered at the PHY layer, but it is not necessarily limited to this.

[0203] Meanwhile, FIGS. 8 and 9 and FIGS. 10 to 12 and 17 to be described later are conceptual diagrams for explaining CSI reference resources. In particular, FIGS. 10 to 12 and 17 to be described later illustrate that the time at which an event is triggered and the time at which a terminal transmits a PUCCH or PUSCH are distinguished. Since the event is determined at a higher layer of the terminal, the physical layer of the terminal can transmit measurement values ​​such as L1-RSRP, RSRQ, and SINR to the higher layer of the terminal. The CSI reference resource used to determine the event trigger and the CSI reference resource to which the terminal reports via PUCCH or PUSCH transmission (i.e., the CSI reference resource on which the measurement value is reported) may be different.

[0204] According to the proposed method, the terminal can report the measurement values ​​utilized at the time of event triggering via PUCCH or PUSCH. This means that separate CSI reference resources may not be applied during PUCCH or PUSCH transmission. In some cases, no additional CPU usage may occur after the event is triggered. In other cases, even after the event is triggered, the CPU may continue to be occupied to encode the UCI containing the measurement values.

[0205] Figures 10 to 12 are timing diagrams for explaining the relationship between CMR / IMR resources, CSI reference resources, event triggers, and CSI reporting timing and CPU occupancy.

[0206] Referring to Figure 10, a terminal may trigger an event using CSI reference resource 1020 and may not apply a separate CSI reference resource when transmitting a PUCCH or PUSCH. In this case, no additional CPU usage may occur after the event trigger.

[0207] Meanwhile, referring to FIG. 11, although the terminal does not occupy the CPU before the event trigger, it can apply the CSI reference resource 1130 for PUCCH or PUSCH transmission.

[0208] According to another proposed method, measurements applied to PUCCH or PUSCH can be updated from the CSI reference resource. That is, the ED-RS measurements at the time of event triggering and the measurements at the time of PUCCH or PUSCH transmission can be different.

[0209] Referring to FIG. 12, both CSI reference resource 1220 and CSI reference resource 1250 may be considered. The terminal may derive a measurement value based on CSI reference resource 1220 and trigger an event. The terminal may trigger an event based on CSI reference resource 1220 and include the same measurement value in PUCCH or PUSCH, thereby ignoring CSI reference resource 1250. Alternatively, the terminal may trigger an event based on CSI reference resource 1220, but apply a measurement value derived based on CSI reference resource 1250 when transmitting PUCCH or PUSCH.

[0210] According to another proposed method, CSI reference resources are not applied when an event is triggered, and values ​​derived from the terminal's implementation can be utilized. Technical specifications may not necessarily specify the values ​​transmitted from the terminal's physical layer to its upper layers. The terminal can apply CSI reference resources for PUCCH or PUSCH transmission. Here, the CPU may be occupied for the event trigger, or conversely, no CPU occupancy may occur.

[0211] Referring to Figure 12, DL RS can be measured to detect the presence or absence of an event. The terminal can consider the CPU to be occupied from the time point (1210) when the CMR or IMR for DL ​​RS measurement is received. For example, L1-RSRP, RSRQ, or SINR can be derived, and the presence or absence of an event can be determined based on the result calculated based on these values ​​(1230). Thereafter, the terminal can occupy the CPU again to transmit UCI to the base station. CSI reference resources (1220, 1250) can be considered to derive the UCI.

[0212] In one example, the CPU occupancy for deriving an event (CPU1) and the CPU occupancy for transmitting UCI (CPU2) may always be the same. For example, if the terminal includes all L1-RSRP, RSRQ, or SINR values ​​in the UCI, the CPU occupancy may not change ( ).

[0213] In another example, CPU1 and CPU2 may differ. For example, the number of DL RSs observed to derive an event and the number of DL RSs to be included in the UCI may differ. Furthermore, the identifiers or indices of DL RSs with L1-RSRP, RSRQ, or SINR above a threshold may be included in the UCI. In this case, or can be established.

[0214] Referring back to Figure 10, to detect an event, the terminal may perform a step (1010) of receiving a CMR / IMR. Thereafter, a step (1020) of considering a CSI reference resource may be performed. However, after an event is detected (1030), the terminal may report uplink control information (UCI) without occupying the CPU (1040).

[0215] For example, the terminal may generate UCI by directly applying L1-RSRP, RSRQ, or SINR to the CMR / IMR observed to derive the event. In this case, the terminal may not additionally receive a DL RS (Downlink Reference Signal) after the event is detected (1030). Therefore, the step of receiving the CMR / IMR (1010) may be considered only before the event is detected, and CPU occupancy may not occur after the event is detected. In this case, the relationship CPU1 > CPU2 = 0 may be established.

[0216] In addition, the terminal can perform a procedure for beam recovery. Here, the event may be a beam failure. The physical layer of the terminal can perform a step (1010) of receiving a beam failure detection reference signal (BFD-RS) to detect a beam failure. Thereafter, a step (1020) of considering a CSI reference resource can be performed to derive an L1-RSRP, an RSRQ, an SINR, or a beam failure indicator (BFI). The upper layer of the terminal can detect whether a beam failure has occurred. If a beam failure has occurred (1030), the terminal can transmit a PRACH (pandom access channel) or an LRR (link recovery request) to the base station (1040). Even in this case, A relationship can be established.

[0217] Referring back to Figure 11, the CPU may not be occupied during the event detection process. However, the CPU may be occupied from the step of detecting the event in the upper layer of the terminal (1110) to the step of reporting the UCI (1140). Such an event may be triggered by a timer expiration in the upper layer of the terminal.

[0218] In FIGS. 8 to 12, a terminal may receive an ED-RS resource and measure a metric of L1-RSRP (or L1-SINR) to detect an event. The terminal may trigger an event based on a measurement value derived from a CSI reference resource, and the CSI reference resource that triggered the event may be different from the CSI reference resource for PUCCH / PUSCH transmission.

[0219] Even before an event is detected, the CPU may be occupied to receive ED-RS resources and measure L1-RSRP (or L1-SINR). If L1-RSRP (or L1-SINR) is transmitted from the PHY layer of the terminal to the MAC layer, the CPU may be additionally occupied in the event instance counting operation to detect the event. If L1-RSRP (or L1-SINR) is measured and event instances are counted only at the PHY layer of the terminal, the CPU may also be additionally occupied.

[0220] After detecting an event, the terminal determines what information to report to the base station, and, if necessary, reports it via UCI or UL-SCH. This process may incur additional CPU usage, which may vary depending on the terminal's processing method.

[0221] In one example, the amount of CPU occupied may be 0 before the event is detected, and may increase from 0 to a certain value upon detection of the event. In another example, the amount of CPU occupied may initially start at a certain value, and may then vary in how the CPU is occupied depending on the action of counting event instances and / or detecting the event.

[0222] In one example, the process of counting event instances during event detection may also increase CPU usage. In another example, the CPU usage may be increased only during the event detection process, and the process of counting event instances alone may not increase CPU usage.

[0223]

[0224] Terminal-led two-step event occurrence reporting procedure

[0225] According to the proposed method, a terminal may use one or more uplink signals or channels to transmit uplink control information (UCI). The UCI may be divided into a first UCI and a second UCI. The first UCI and the second UCI may undergo the same encoding procedure or may undergo different encoding procedures. When applying different encoding procedures, parameters such as the code rate may differ.

[0226] FIG. 13 and FIG. 14 are timing diagrams for explaining the time relationship required for a terminal initiation reporting procedure according to another embodiment of the present invention.

[0227] Referring to FIGS. 13 and 14, a terminal can transmit the first UCI and the second UCI on different PUCCHs or PUSCHs. In FIG. 13, the resources on which the first UCI and the second UCI are transmitted can be periodically indicated to the terminal. Additionally, the resource on which the second UCI is transmitted can be occupied when the first UCI is transmitted. In FIG. 14, the resource on which the first UCI is transmitted is periodically indicated to the terminal, but the resource on which the second UCI is transmitted can be dynamically indicated to the terminal by the base station. In this case, the PUCCH or PUSCH can be transmitted on the dynamically indicated resource.

[0228] In FIGS. 13 and 14, a terminal may receive an ED-RS resource and measure a metric of L1-RSRP (or L1-SINR) to detect an event. The terminal may trigger an event based on a measurement value derived from a CSI reference resource, and the CSI reference resource that triggered the event may be different from the CSI reference resource for PUCCH / PUSCH transmission.

[0229] Even before an event is detected, the CPU may be occupied to receive ED-RS resources and measure L1-RSRP (or L1-SINR). If L1-RSRP (or L1-SINR) is transmitted from the PHY layer of the terminal to the MAC layer, the CPU may be additionally occupied in the operation of counting event instances to detect the event. If L1-RSRP (or L1-SINR) is measured and event instances are counted only at the PHY layer of the terminal, additional CPU may be occupied.

[0230] After detecting an event, the terminal determines what information to report to the base station, and, if necessary, reports it via UCI or UL-SCH. This process may incur additional CPU usage, which may vary depending on the terminal's processing method.

[0231] In one example, the amount of CPU occupied may be 0 before the event is detected, and may increase from 0 to a certain value upon detection of the event. In another example, the amount of CPU occupied may initially start at a certain value, and may then vary in how the CPU is occupied depending on the action of counting event instances and / or detecting the event.

[0232] In one example, the process of counting event instances during event detection may also increase CPU usage. In another example, the CPU usage may be increased only during the event detection process, and the process of counting event instances alone may not increase CPU usage.

[0233]

[0234] If the first UCI and the second UCI are transmitted periodically on a PUCCH generated in a concatenated form, a method is needed to avoid wasting system resources because PUCCH resources are allocated even when no event occurs or a specific condition is met. To solve this, the first PUCCH including the first UCI can be transmitted periodically, but the second PUCCH including the second UCI can be transmitted only when an event occurs or a specific condition is met and the first PUCCH is transmitted. If the first UCI and the second UCI are transmitted in a concatenated form, the two UCIs may not have originated from the same event or the same serving cell. The event or serving cell corresponding to the first UCI may be different from the event or serving cell corresponding to the second UCI. In this case, a separate second UCI corresponding to the first UCI may exist, and a separate first UCI corresponding to the second UCI may exist.

[0235] In the proposed method, a first PUCCH including a first UCI and a second PUCCH (or PUSCH) including a second UCI are transmitted with time separation, so that the base station can detect the presence or absence of the first PUCCH. Through this, the base station can utilize the resources required for the second PUCCH or PUSCH in dynamic scheduling by utilizing the detection results. The minimum interval between the first PUCCH and the second PUCCH (or PUSCH) can be determined by considering the time until the base station decodes the first UCI, reflects it in the scheduler, and generates DCI including UL grant or DL ​​assignment. At this time, it is desirable to secure a sufficient time interval so that another UL signal or channel can be scheduled on the resource when the resource that could have been occupied by the second PUCCH or PUSCH is not used for transmission of the second PUCCH or PUSCH.

[0236] Referring back to FIG. 13, the time (1320) at which the first UCI is transmitted and the time (1330) at which the second UCI is transmitted may have a sufficient interval. As previously explained, the interval (1350) between the first PUCCH and the second PUCCH (or PUSCH) may be determined by considering the base station's first UCI decoding time, the scheduler's processing time, the DCI encoding time, and the terminal's UL transmission execution time.

[0237] In another proposed method, the first PUCCH containing the first UCI may be transmitted periodically, but the resources of the second PUCCH or PUSCH may not be separately allocated periodically to allow the second UCI to be transmitted conditionally. The terminal may transmit information to the base station to request resources for transmitting the second UCI. Alternatively, the terminal may receive a separate DCI from the base station and transmit the second UCI using the PUCCH or PUSCH resources allocated by the DCI.

[0238] Referring to FIG. 14, after transmitting the first UCI (1420), the terminal may receive the DCI (1430). The DCI may or may not schedule the PDSCH. Additionally, the DCI may or may not schedule the PDSCH or PUSCH. In some cases, the DCI may not always schedule the PDSCH. If the DCI is used for UL grant, the PUSCH for transmitting the second UCI may be scheduled. Alternatively, if the DCI is used for DL ​​allocation, a PUCCH resource indicator (PRI) may be used for transmitting the second UCI. The terminal may be allocated a dedicated PUCCH resource set from the base station through higher layer signaling, and based on this, may receive only the PRI to derive the resources of the second PUCCH or PUSCH on which the second UCI can be transmitted (1440).

[0239] Although the base station dynamically allocates the second PUCCH or PUSCH, thereby enabling efficient use of system resources, additional delay may occur. That is, the time difference between the time the first UCI is transmitted (1420) and the time the second UCI is transmitted (1440) may include not only the processing time of the base station, but also the time required to receive the DCI and transmit the PUCCH or PUSCH.

[0240] If the base station allocates a second PUSCH to the UE using an UL grant, information for transmitting the second UCI may be included in a specific field of the UL grant. This may imply that the UE can transmit the second PUSCH by multiplexing the second UCI with the UL-SCH. In the proposed method, the field indicating the CSI trigger in the UL grant can be reused to transmit the second UCI.

[0241] In one example, information for transmitting a second UCI in a CSI trigger state may be associated. Additionally, one or more events corresponding to the second UCI may be associated with a specific value of the CSI trigger field.

[0242] In the above method, the first UCI can be interpreted as an improved form of the SR (scheduling request) or LRR (link recovery request) supported by existing technical specifications. The SR can be transmitted to receive UL authorization, and the LRR can be transmitted to recover from beam failure. The SR and LRR can be transmitted using PUCCH format 0 or PUCCH format 1, and the terminal can also multiplex it with other UCI types and transmit it in another PUCCH format. In particular, the SR is a signal transmitted to notify the base station that data has arrived in the buffer of the terminal and to receive scheduling. However, even if the base station receives the SR, it cannot know the amount of data in the buffer of the terminal or the required quality of service (QoS). Therefore, the terminal must generate a buffer status report (BSR) supported by the MAC layer and transmit a MAC PDU or a TB (transport block) to the base station. In other words, the SR can be interpreted as the terminal's response to an event in which a TB has occurred.

[0243] In contrast, the proposed first UCI can be interpreted as a terminal's response to an event occurrence or condition satisfaction. Even if the base station receives the first UCI, it can derive rough information (e.g., an event identifier) ​​and use this to determine the amount of feedback (e.g., the type and / or amount of measurement) that may be required for the event. In addition, the event identifier and / or the type and / or amount of measurement can be derived through the first UCI. The base station can determine the amount of resources required to transmit the second UCI and dynamically allocate this to the terminal using a PUCCH resource indicator (PRI). Alternatively, the amount of resources required for the second UCI transmission can be dynamically allocated to the terminal using a CSI trigger. When the PRI is used, the PUCCH can be transmitted. When the CSI trigger is used, the PUSCH can be transmitted. In order to dynamically allocate the amount of resources required for the second UCI transmission, the code rate of the second UCI can be indicated in the UL allocation that allocates the PUSCH. The code rate of the second UCI can be derived using the MCS field and / or beta offset.

[0244] The proposed method can specify the transmission method of the existing SR and the proposed first UCI. According to the conventional technical specifications, the SR is used to request a UL signal or UL channel according to a change in the buffer status of the terminal, while the first UCI can be used to notify the base station of an event occurrence. If the first PUCCH for transmitting the first UCI and the zeroth PUCCH for transmitting the SR can be transmitted in the same slot, specific collision avoidance operations may be required.

[0245] In one example, a terminal can select and transmit only on either the 0th PUCCH or the 1st PUCCH. This means that, if a separate collision resolution method is not defined, the terminal can operate in a manner that avoids collisions on its own. If the priority indices of the 0th PUCCH and the 1st PUCCH are different, the priority indices can be compared according to existing technical specifications to select only one PUCCH.

[0246] In one example, the terminal may prioritize SR over event detection, always selecting only the 0th PUCCH. In another example, the terminal may multiplex the 0th PUCCH and the 1st PUCCH and transmit them on separate PUCCHs. This allows the terminal to simultaneously transmit event detection results and buffer status change information to the base station.

[0247] There may be instances where the transmission of a PUCCH containing the first UCI may fail (drop). If the PUCCH is considered identical to the SR, the SR ID may be associated with the PUCCH resource containing the first UCI. If the UE must transmit a PRACH, a PUSCH or PUCCH with a higher priority, or an SR with a higher priority, the PUCCH containing the first UCI may not be transmitted.

[0248] According to existing technical specifications, SR retransmission is possible. Furthermore, a separate timer (prohibit timer) can be used to prevent a terminal from frequently performing SR. A terminal may not be able to transmit an SR, or even if it has already transmitted an SR, it may retransmit an SR if the serving base station does not schedule it.

[0249] In the proposed method, if a time period during which DCI is not received from the base station exceeds a predetermined interval after the PUCCH including the first UCI is transmitted to the serving base station, the terminal can retransmit the PUCCH including the first UCI.

[0250] In one example, the first UCI may not be re-derived, and only PUCCH retransmission may be considered. In this case, the terminal's CPU may not be occupied, and a PUCCH with the same first UCI applied may be transmitted.

[0251] In another example, the first UCI may or may not be updated to match the timing of the PUCCH transmission and / or the CSI reference resource. In this case, the terminal's CPU may remain occupied until the PUCCH containing the first UCI is actually transmitted.

[0252] In another proposed method, if a predetermined interval elapses after a PUCCH including the first UCI is transmitted to the serving base station and no DCI is received from the base station, the terminal may derive the first UCI again. That is, the PUCCH dropped in the previous transmission may not be retransmitted as is. The terminal may determine that a significant amount of time has passed since the event was detected and may perform event detection again. In this case, the terminal may not occupy the CPU for a predetermined period of time (e.g., a time corresponding to the prohibit timer of the first UCI), and the counter counting the event triggers may not be changed. Thereafter, the terminal may occupy the CPU again to derive the first UCI and / or the second UCI again.

[0253] In another proposed method, retransmission of the first UCI may not be performed. In this case, the terminal may stop generating the second UCI if the PUCCH transmission is dropped. Therefore, depending on whether the first UCI is transmitted, the CPU usage of the terminal may be further extended or released. If the first UCI is transmitted, the second UCI is also transmitted, thus further extending the CPU usage. If the first UCI is dropped, the second UCI is not transmitted, thus releasing the CPU usage. In this method, since the terminal does not need to support retransmission of the first UCI, a timer associated with PUCCH retransmission may also be unnecessary.

[0254]

[0255] According to the proposed method, a terminal can operate a counter that records the number of event occurrences. If the counter value exceeds a threshold within a specific time window, the terminal can consider an event to have occurred and generate a first UCI. That is, after generating the first UCI, the terminal can reset the counter. In one example, the counter can be managed individually for each event. In another example, the counter can be managed for each serving cell.

[0256] Additionally, the counter may be reset when the CMR set changes. When the CMR set changes, there may be changed ED-RS resource(s) and unchanged ED-RS resource(s). In the proposed method, the counter for unchanged ED-RS resources may not be reset. On the other hand, in another proposed method, the counters associated with all ED-RS resources belonging to the changed CMR set may be reset.

[0257] If an event occurs when a metric (L1-RSRP, L1-SINR, etc.) for the serving beam, current beam, or qcl-D RS of a specific TCI state is compared to a threshold, then when a TCI state change occurs, the counter associated with that event must be reset.

[0258] Furthermore, if an event is detected by comparing metrics between the serving beam and the candidate beam, it is desirable that the counter associated with the event be reset when a TCI state change occurs, since the serving beam changes. However, if the candidate beam is changed or modified, the counter associated with the event may not be reset according to the proposed method. Furthermore, the counter may be reset. Thus, whether the counter is reset when the candidate beam changes may vary depending on the specific method.

[0259] In the proposed method, when a terminal detects an event occurrence and performs a CSI report to a serving base station, the associated counter may be reset. When the terminal receives a beam report consisting of a single step, the associated counter may be reset by the beam report. When the terminal performs a beam report consisting of a two-step process, the terminal may notify the serving base station of the event occurrence in the first step report and transmit the beam report measured by the terminal in the second step report. In this case, the counter may be reset after the second step report is received.

[0260] The second-phase report can be transmitted using the PUSCH. The PUSCH can be transmitted by receiving a DCI format from the serving base station, or it can be transmitted without a separate dynamic scheduling instruction using the Type 1 CG (configured grant) PUSCH. Since the UE may drop the second-phase report according to the UL multiplexing and priority procedure, it is desirable to reset the associated counter after determining that the second-phase report has actually been transmitted to the serving base station.

[0261] In subsequent scheduling by the serving base station, the HARQ process ID of the PUSCH used in the second-stage report may be reused, and the NDI may be toggled. This may indicate that the UL-SCH included in the PUSCH has been successfully received by the serving base station and is no longer used in the circular buffer. Furthermore, the UE can determine whether UCI transmission is occurring based on the HPN (HARQ process number) and NDI (new data indicator).

[0262] In the proposed method, the second stage report is considered to have been successfully transmitted using HPN and NDI in both cases where PUSCH is dynamically allocated (Mode A) and semi-statically allocated (Mode B), and the related counters can be reset.

[0263]

[0264] The terminal may utilize specific criteria to detect events. Event detection may involve comparing measurements of ED-RS resources with each other or comparing measurements of ED-RS resources with a preset threshold. For this purpose, the terminal may consider a counter within a predetermined time window. The time window may be expressed as the number of slots or symbols, and may follow the subcarrier spacing (SCS) of the active BWP or the SCS of the reference BWP.

[0265] According to the proposed method, the terminal can reset the counter after a time window has elapsed. This may mean that the counter value is initialized.

[0266] Alternatively, the terminal can be interpreted as moving through a time window. The occurrence of an event can be divided into two stages. First, the terminal derives an event instance using the measurements of the ED-RS resource(s). This instance may need to fall within the time window to be reflected in the counter. If the event instance falls outside the time window, the counter may be adjusted. If the counter value exceeds a predetermined or indicated threshold, the event is considered detected and the first UCI may be generated.

[0267] FIGS. 15 and 16 are timing diagrams for explaining the concept of applying a time window to transmit a beam report according to embodiments of the present invention.

[0268] Referring to Figure 15, a time window may be applied to the reference time for transmitting the first stage report (i.e., the first UCI). The terminal may evaluate the conditions for detecting an event using the ED-RS resource(s) included in the CMR set. Figure 15 illustrates the points in time when the conditions are met.

[0269] Referring to Fig. 15, the time points at which the event condition is satisfied within the time window are from t1 to t5, and accordingly, the counter value may be 5. If the counter value is greater than or equal to the threshold value, the terminal may report the detection result of the corresponding event to the serving base station using the first-stage report. On the other hand, if the counter value is less than or equal to the threshold value, the detection of the corresponding event may not be reported to the serving base station through the first-stage report. In addition, there may also be events that are not included in the time window. According to Fig. 15, although there were two cases in which the terminal evaluated the event condition and the condition was satisfied (1501), this may not be reflected in the counter.

[0270] According to the proposed method, when an event condition is satisfied, the PHY layer of the terminal can transmit information about the time when the condition occurred to the upper layer of the terminal (e.g., MAC layer).

[0271] Another way is to have a separate timer or sub-counter start when the event condition is satisfied, so that validity can be determined each time the event condition is satisfied.

[0272] According to another proposed method, the terminal can apply a time window based on the time point of the resource capable of transmitting the first UCI (or the first phase report). The terminal can count the number of times an event condition is met. Evaluating the event condition may involve measuring ED-RS resources and comparing the measurements with each other or with a preset threshold. The number of times the event condition is met can be interpreted as a counter.

[0273] Referring to Figure 16, a time window can be interpreted as starting whenever an event condition is satisfied. For example, if a condition is satisfied at a specific time point t0, the occurrence condition of the event can be interpreted as valid during that time window. Similarly, even if the condition is satisfied at another time point, the occurrence condition of the event can be interpreted as valid during that time window. When the first stage report occurs, that time point is considered valid and can be reflected in the counter. On the other hand, a time point outside the time window may not be reflected in the counter.

[0274]

[0275] In another proposed method, information about the second UCI can be transmitted using a MAC CE (or MAC subPDU). In this case, the base station can instruct the UE to transmit PUSCH via a PDCCH (UL grant). Alternatively, the UE can transmit the MAC CE (or MAC subPDU) to the base station using a configured and / or activated CG PUSCH without a PDCCH.

[0276]

[0277] According to the proposed method, there may be various cases in which a terminal detects two or more events. The first case may correspond to the case in which the same events are detected based on the same ED-RS (same ED-RS identifier (or same TCI state identifier)). The second case may correspond to the case in which the same event is detected but based on different ED-RSs (different ES-RS identifiers (or different TCI state identifiers)). The third case may correspond to the case in which different events are detected based on the same ED-RS resource (same ED-RS identifier (or same TCI state index or identifier)). The fourth case may correspond to the case in which different events are detected based on different ED-RSs (different ED-RS identifiers (or different TCI state indexes or identifiers)). The fifth case may correspond to the case in which the same or different events are detected in two or more serving cells while multiple serving cells are activated.

[0278] Figure 17 is a timing diagram for explaining a case where a terminal detects two events.

[0279] Referring to Fig. 17, the first case described above is illustrated. Based on measurements for the same ED-RS, the same event can be triggered twice (x30, y30). This may mean that the UE can report UCI or MAC CE (or MAC subPDU) to the base station using a one-step procedure or a two-step procedure. When the UE measures the same ED-RS, triggers for the same events occur at a predetermined time interval (), and may not occur at a smaller interval. Alternatively, the upper layer of the UE (L2 layer or MAC layer) may count the number of events or calculate the time between identical events (e.g., in slot or symbol units) to secure the predetermined time interval or more. Here, the predetermined time interval may be applied only to identical events derived from the same ED-RS.

[0280] When a terminal reports the first and second UCI separately, the PUCCH or PUSCH on which the first UCI is reported may only contain information related to one event. Conversely, the PUCCH or PUSCH on which the second UCI is reported may contain information related to two or more events. At any given time, the terminal can trigger only one event. This is reflected in the first UCI, so that the terminal can only include the event identifier and minimal information related to it. The PUCCH or PUSCH on which the first UCI is transmitted may use periodically indicated resources or may use resources dynamically indicated by the base station. Therefore, when two or more events are triggered, information about the two or more events may be multiplexed depending on the transmission resources of the PUCCH or PUSCH.

[0281] Subsequently, the second UCI may include additional information related to the event and / or measurements of the ED-RS (resource) that triggered the event. The PUCCH or PUSCH on which the second UCI is transmitted may use periodically indicated resources or resources dynamically indicated by the base station. Therefore, as described above, if two or more events are triggered, information about the two or more events may be multiplexed depending on the transmission resources of the PUCCH or PUSCH.

[0282]

[0283] According to the proposed method, the PUSCH through which the second UCI is transmitted can use the periodically indicated resources. That is, the terminal can transmit the second UCI using the Type-1 CG PUSCH.

[0284] While resources for the PUCCH transmitting the first UCI to the UE may be periodically designated, the PUCCH is not always transmitted. The PUCCH may only be transmitted when the UE determines that an event has been detected, resulting in the first UCI occurring. When the serving base station receives a PUCCH containing the first UCI, it can anticipate that the UE will use the CG PUSCH. The UE can map the second UCI to the CG PUSCH and transmit it to the serving base station.

[0285] After reporting the first UCI, the terminal may transmit the second UCI on the CG PUSCH resource that is temporally fastest after a predetermined time has elapsed. Here, the predetermined time may be indicated to the terminal via RRC signaling.

[0286] In the proposed method, the resource(s) of the CG PUSCH indicated to the UE for transmitting the second UCI can be individually indicated for each event and / or serving cell(s). Here, one CG PUSCH resource can have an amount that includes the second UCI generated from one event and one serving cell. Accordingly, if multiple serving cells are activated for the UE or multiple events can occur, the second UCI can be generated multiple times.

[0287] According to the proposed method, a terminal can map two or more resource(s) to a CG PUSCH corresponding to a second UCI. If the second UCI occurs multiple times, they can be concatenated and considered as a single larger UCI, which can be transmitted on an additionally indicated CG PUSCH.

[0288] In the proposed method, not only the second UCI, but also the first UCI / second UCI and / or MAC subPDU and / or MAC CE and / or MAC SDU and / or other TB(s) for other event(s) may be multiplexed on the CG PUSCH. In addition, in another proposed method, multiplexing of other elements (such as the first UCI / second UCI and / or MAC subPDU and / or MAC CE and / or MAC SDU and / or other TB(s)) other than the second UCI on the CG PUSCH may not be allowed.

[0289] In the proposed method, some of the resource(s) of the CG PUSCH can be adjusted. The UE can use sufficiently large CG PUSCH resource(s) to map a single UCI multiplexed with multiple secondary UCI(s). However, rate matching can be performed on the CG PUSCH resource(s) even after applying the code rate to the UCI. Therefore, an operation to reduce the bandwidth of the CG PUSCH can be performed. By deriving the minimum number of PRBs that satisfy the code rate of the UCI, the UE can reduce interference to the serving base station or neighboring base stations and increase the EPRE.

[0290] In the proposed method, the second UCI not included in the CG PUSCH may be dropped. Since the serving base station has already received the first UCI, it can predict to some extent what event occurred at the terminal. Therefore, if the serving base station fails to receive the second UCI, it can use aperiodic CSI reporting to instruct the terminal to report more accurate beam information.

[0291] In another proposed method, if there are resources not included in the CG PUSCH, the serving base station can perform retransmission by switching the resources to dynamic PUSCH because it failed to receive the CG PUSCH. According to the existing technical specifications, this corresponds to a retransmission of TB, and thus cannot directly indicate retransmission of the second UCI. However, the UE can expect to receive a DCI indicating retransmission of the second UCI when the CG PUSCH is dropped. For example, the DCI can be scrambled with CS-RNTI, through which the second UCI can be transmitted.

[0292] In another proposed method, resources not included in the CG PUSCH can be deferred. The UE can retransmit the first UCI, or transmit the second UCI on a later allocated CG PUSCH resource without retransmitting the first UCI. In this case, the transmission order of the first UCI can be determined according to a predetermined order instructed to the UE, and the UE can transmit the appropriate second UCI using the first available CG PUSCH resource according to this order. In other words, the second UCI included in the CG PUSCH can correspond to a single event occurring in a single serving cell.

[0293] FIG. 18 is a timing diagram for explaining a concept of performing reporting on two events of a terminal in two stages according to an embodiment of the present invention.

[0294] Referring to FIG. 18, a terminal can perform reporting for two events (Event-A, Event-B) in two stages. Event-A can be triggered at z10, and Event-B can be triggered at z20, and can be transmitted as a first UCI and a second UCI, respectively. The first UCI for Event-A can be transmitted at z30, and the second UCI for Event-B can be transmitted at z40. In other words, they can be transmitted on different PUCCHs or PUSCHs.

[0295] To transmit the second UCI, the terminal may use the same PUCCH or PUSCH. For example, if a periodically indicated PUCCH or PUSCH is used, it may not occur too frequently for resource efficiency reasons. In this case, resources corresponding to the second UCI may overlap for different events (z50).

[0296]

[0297] How to decide whether to occupy or release the CPU

[0298] FIG. 19 is a flowchart illustrating a method for determining CPU occupation and release according to embodiments of the present invention.

[0299] Referring to Figure 19, the terminal may occupy the CPU during the event detection phase and / or the UCI preparation phase (S1910), but may also occupy the CPU for other reasons. According to the proposed method, CPU occupancy can be released according to a predetermined priority.

[0300] For convenience of explanation, in conventional technical specifications, the CPU may be occupied or released and the CPU occupancy may change at the time when a CMR / IMR is received or a PDCCH is received in relation to non-aperiodic CSI reporting and aperiodic CSI reporting.

[0301] According to the prior art, when an event occurs and the CPU is occupied (S1920), this persists until the time resource for transmitting UCI is available, and the CPU occupancy may not be interrupted before that. If the maximum number of CPUs allowed for occupancy within the terminal's capabilities is exceeded, the CSI report may be reported to the base station without being updated.

[0302] A case may be considered (S1930) where an event triggers at a higher level of the terminal, requiring additional CPU allocation. In this case, the terminal can compare the remaining CPU(s) with the additional CPU(s) required to determine whether the additional CPU(s) required exceeds the remaining CPU(s) (S1940).

[0303] If a terminal already occupies a significant amount of CPU, the additional CPU demand may exceed the terminal's capabilities. In such cases, the terminal may be expected to secure the CPU requested by the event.

[0304] According to the proposed method, a terminal configured to detect an event indicated or activated via upper layer signaling can be allocated A CPUs (or units of A, A > 0), and other CSI reports may not occupy the corresponding CPUs. Here, A may have a separate value for each event. For example, A may vary depending on the type and number of events. For the first event, A1 CPUs may be reserved, and for the second event, A2 CPUs may be reserved. Therefore, when the first and second events are configured or activated in the terminal, a total of A1 + A2 CPUs may be reserved. In this case, the terminal can occupy the CPU with a higher priority than the CSI report for event detection. In addition, since the terminal can detect events when it already has sufficient CPUs, the process of determining whether there is a shortage of CPUs (S1940) may not be performed.

[0305] In another proposed method, the terminal may release the CPU it is currently occupying to secure the CPU required by the event (S1970).

[0306] To release a previously occupied CPU, the priorities of the CSI reports corresponding to the CPU may be compared (S1960). For example, the priority of a CSI report may be applied based on the priority reporting level.

[0307] According to existing technical specifications, if two CSI reports overlap and are assigned to the same UL signal or UL channel, the two reports can be said to conflict. Here, CSI reports can be assigned priorities (Pri_iCSI) based on the following criteria.

[0308] - Periodic report, aperiodic report, semi-persistent report?

[0309] - Whether L1-RSRP

[0310] - Serving cell index

[0311] - report identifier (reportConfigID)

[0312] When the priorities of two CSI reports are compared, only one CSI report may be selected and reported to the base station. Alternatively, if certain conditions are met, two CSI reports may be multiplexed and reported to the base station.

[0313] Extending this priority reporting level concept, if an event occupies the CPU, a priority can be derived and then CSI reports with lower priorities can be sequentially selected to secure the CPU. This involves repeatedly performing the steps of checking whether sufficient CPU is available (S1940) and selecting specific CSI reports to secure additional CPU (S1960, S1970). CSI reports dropped during this process release CPU occupancy and can be reported in an unupdated state.

[0314] Additionally, in another proposed method, the terminal can release all previously occupied CPUs to ensure sufficient CPU capacity for the event. For example, a specific event can be signaled to the terminal via higher-layer signaling as being of high urgency or priority level.

[0315] Alternatively, the terminal may release only a portion of its previously occupied CPU to secure the CPU required by the event. The CPU released by the terminal may be the CPU already occupied by a CSI report being derived by the terminal. However, if the CSI report (i.e., the CSI report occupying the CPU that is a candidate for release) and the event detection or event-triggered CSI report are closely related, the terminal may not release the CPU. On the other hand, if there is no close relationship, the CPU occupied by the CSI report may be released.

[0316] Here, 'close relationship' may mean that the set of CMRs used to derive the corresponding CSI report (i.e., the CSI report occupying the CPU that is a candidate for release) satisfies the following conditions:

[0317] - The ED-RS resource or its identifier (or a set of ED-RS resources or their identifiers) required to derive the CSI report requested by the event is included in the CSI report.

[0318] - Shares the same QCL-TypeD source RS

[0319] - ED-RS is used as a QCL-TypeD source RS.

[0320] For example, if a terminal already has a significant amount of CPU, it may not have enough CPU to detect a specific event or generate a CSI report for the triggered event. In such cases, the terminal may not detect the event or generate a CSI report for the event. Therefore, the terminal may not consume additional CPU.

[0321]

[0322] A single event may be defined as a reportable event, or more than one event among multiple events may be considered reportable.

[0323] If only one event is defined, the terminal may not be separately instructed by the base station to identify the event. However, the parameters required to detect the event may be instructed to the terminal.

[0324] If more than one of several events is considered, the identifier (or index) of the event as well as the parameters for detecting the event may be additionally indicated from the base station to the terminal.

[0325] According to the proposed method, events may be predefined in the technical specifications, or the event itself or parameters required for event derivation may be indicated to the terminal via RRC signaling.

[0326] Additionally, multiple UCIs may be reported for the same event. Below, we describe the UCIs for each event and how different UCIs may be utilized for the same event.

[0327] For example, an event may be caused by a beam failure. The terminal may interpret the event as detected when the Event Instance (EI) counter, which counts the number of event occurrences using a predefined ED-R, expires or exceeds a threshold value. Alternatively, the terminal may interpret the event as detected when the intensity of the ED-RS exceeds a threshold value for a certain period of time.

[0328] After searching for an alternative beam, the terminal can transmit it to the base station. According to existing technical specifications, the alternative beam can be implicitly derived from the PUCCH or PRACH resources where the LRR is transmitted. According to the proposed method, information about the alternative beam can be explicitly transmitted on the PUCCH via UCI.

[0329] A UE's beam failure indicates a failure of the corresponding ED-RS, which can be distinguished from a failure of the BFD-RS received from the serving cell. In the case of a BFD-RS failure, the PDCCH is not normally received from the serving cell, making it difficult for the UE to receive normal scheduling from the serving cell. Accordingly, the UE must perform a beam recovery procedure and monitor the Type 1-PDCCH CSS set.

[0330] However, in case of ED-RS failure, the terminal can receive normal scheduling from the corresponding serving cell, and it may be sufficient to simply indicate an alternative beam for ED-RS to the base station.

[0331] A new beam can be represented by a TCI state index or an identifier of a DL RS. The TCI state index can be selected from among TCI states (TCI state pool) indicated to the UE via RRC signaling. The selected TCI state index can mean a DL TCI state, a UL TCI state, or a joint TCI state including both a DL TCI state and a UL TCI state. In addition, the TCI state index can be extended and can be interpreted as a TCI state group index. In this case, a TCI state group can be interpreted as two or more TCI state indices, and when the UE communicates with two or more TRPs, the two or more TCI state indices can correspond to the TCI state indices applied to each TRP. In addition, the BWP ID or serving cell index (or serving cell identifier) ​​to which the TCI state index is applied can also be included.

[0332] Here, the TCI state index can correspond to one or two RS indices.

[0333] When corresponding to one RS index (QCL-TypeA source RS), a measured value (e.g. L1-RSRP, RSRQ, SINR, etc.) can be derived using the corresponding RS index.

[0334] When two RS indices correspond, the first RS index (QCL-TypeA source RS) can provide time synchronization and frequency synchronization information of the RS constituting the alternative beam. On the other hand, the second RS index (QCL-TypeD source RS) can provide reception beam information of the RS constituting the alternative beam. Therefore, measured values ​​(e.g., L1-RSRP, RSRQ, SINR, etc.) can be derived using the second RS index.

[0335]

[0336] FIGS. 20 to 23 are conceptual diagrams for explaining procedures in which an event is triggered based on ED-RS and a UCI corresponding to the event is generated according to embodiments of the present invention.

[0337] Referring to Figure 20, when an ED-RS failure (the reception strength of the ED-RS decreases below a reference level) is detected, a UCI explicitly indicating the TCI state of an alternative beam may be generated. This UCI may undergo encoding and modulation processes (polar encoding and rate matching) to be transmitted via PUCCH or PUSCH.

[0338] For example, an event can be defined as a sudden change in quality measured using one or more ED-RSs. The terminal can derive values ​​such as L1-RSRP, RSRQ, and SINR using the ED-RSs, and for this purpose, can receive CMR or IMR instructions from the base station.

[0339] If the values ​​measured from a single ED-RS decrease or increase rapidly within a short period of time, the phenomenon can be considered an event. Alternatively, if the values ​​measured from two or more ED-RSs exhibit a significant relative difference, this can also be considered an event. The criteria for "short period" and "sudden decrease or increase" can be defined in the technical specifications or indicated to the terminal via RRC signaling.

[0340] Therefore, a sudden change in L1-RSRP, RSRQ, SINR values ​​measured using one CMR or IMR or a large difference between L1-RSRP, RSRQ, SINR values ​​measured in two or more CMRs / IMRs (or one CMR pair / IMR pair) may correspond to the event An or event Bn described above. That is, it can be assumed that events that can be interpreted as event An and event Bn may also occur within one TRP or one serving cell.

[0341] The UCI corresponding to an event can take several forms. For example, it can include the activation or deactivation of a TCI state applied in the serving cell (or BWP). Additionally, reporting of L1-RSRP, RSRQ, SINR, etc. using ED-RS can be considered. The identifier (or index) of another PCI or PCI belonging to the same serving cell, or the identifier (or index) of a TRP, can also be included. This information can be used as additional information for the TCI state or L1-RSRP, RSRQ, or SINR.

[0342] Referring to FIG. 21, when one or more CMR / IMR (or CMR / IMR pair) is indicated to the terminal, the terminal can detect a sudden change as an event by measuring the ED-RS.

[0343] The terminal may be directed to a portion (i.e., a subset) of the TCI state pool. For example, this subset may be a set of candidate TCI states, consisting of new TCI states that can replace existing TCI states.

[0344] When the event occurs, the TCI state index belonging to the subset may be updated. For example, a single bit in a bitmap (or bit string) may correspond to a single TCI state belonging to the subset. The length of the bitmap may be equal to the number of elements in the subset. A specific value of a bit may indicate activation, while another value may indicate deactivation.

[0345] In addition, the terminal may utilize a TCI state index belonging to the subset to indicate a kind of fallback beam in a beam-based procedure. The terminal may include explicit information about the specific TCI state in the UCI. For example, the information consisting of a bitmap alone may not be able to determine which candidate TCI state in the set of candidate TCI states is considered as a specific TCI state for fallback purposes. Therefore, the base station may indicate the fallback beam to the terminal by explicitly indicating one specific TCI state index. Here, the specific TCI state index may be referred to as the first TCI state index. Referring to FIGS. 22 and 23, one or more CMR / IMR or CMR / IMR pairs may be indicated to the terminal, and the terminal may measure L1-RSRP, L1-RSRQ, or L1-SINR using ED-RS. The terminal may detect an event when the measured value exceeds a preset boundary. Additionally, the terminal can receive boundary values ​​through higher-layer signaling and utilize them for event detection. The base station can perform beam direction or beam management (e.g., beam refinement) using ED-RS. The terminal can report measured L1-RSRP, L1-RSRQ, or L1-SINR values ​​to the base station to enable the base station to make appropriate decisions.

[0346] Fig. 22 illustrates a case where the identifier of ED-RS is included in UCI, and Fig. 23 illustrates a case where the index of the TCI state associated with ED-RS is included in UCI.

[0347] For example, a terminal may report the identifier of the measured ED-RS and the corresponding measurement value. Conversely, ED-RSs or corresponding measurement values ​​for which no events occurred may not be included in the UCI. Therefore, the terminal may include information about the number of ED-RSs that contain this information in the UCI, and this information can be used to determine the data size of the UCI.

[0348] Additionally, the terminal may employ a method to reduce the number of bits representing the measurement value. For example, the terminal may calculate the difference between the value S measured by the ED-RS and the threshold value T and report the difference (ST or TS). Furthermore, when multiple ED-RSs exist, the terminal may set a reference value S0, calculate the difference with another value S, and report the difference (S0-S or S-S0).

[0349]

[0350] The identifier(s) of the ED-RS that do not satisfy the trigger condition of the event or the identifier(s) / index(s) of the TCI state can also be configured to be included in the UCI. This can prevent the size of the UCI from changing significantly. For example, the upper layer of the terminal can interpret that the event has been triggered and generate UCI, but the time at which the UCI is generated can follow the CSI reference resource. The concept of such CSI reference resource has been explained in FIGS. 8 to 17. Therefore, depending on the fading state of the channel, the event may not satisfy the trigger condition at the time of UCI generation. If L1-RSRP or L1-SINR is reported for only one ED-RS or one TCI state, there is a possibility that invalid information is reported from the serving base station.

[0351] In the proposed method, it is preferable that the number (N) of L1-RSRP values ​​or L1-SINR values ​​for multiple ED-RSs or TCI states that can be included in the UCI be included in the information set to the terminal. For example, if information on four ED-RSs or TCI states is reported, the base station can use this to appropriately manage the current beam. This management can be performed by changing the TCI state corresponding to the current beam, activating some of the deactivated TCI states, or deactivating some of the activated TCI states. By applying this method, the size of the UCI is maintained constant, so that decoding can be facilitated at the base station.

[0352] For example, the number (N) set for the terminal can be instructed via RRC signaling to always include the current beam. In this case, the terminal can adjust the number of ED-RSs or TCI states corresponding to beams other than the current beam to N-1.

[0353] As another example, if N=1 is set, the RRC parameter that instructs that the current beam is always included may not be instructed. This is because if N=1 and the current beam is always included, information about beams other than the current beam cannot be included. In this case, the terminal may not measure L1-RSRP or L1-SINR for ED-RS or TCI states corresponding to beams other than the current beam.

[0354] As another example, the terminal may not be instructed to specify an N value. In this case, the terminal may assume that it is reporting L1-RSRP or L1-SINR for a single ED-RS, and the UCI may not include measurements for the current beam.

[0355] Additionally, the base station may instruct the terminal not to include the current beam in the UCI. Conversely, if the base station instructs the terminal to include the current beam in the UCI but only reports on one ED-RS, reports may be generated for both the current beam and the corresponding ED-RS.

[0356]

[0357] The base station can change the beam using RRC signaling or MAC CE (or MAC subPDU) to update the TCI state of the terminal, and can also change the beam using DCI. At this time, a certain amount of time is required to change the beam, which is referred to as the "beam application time (BAT)" in the existing technical specifications. If the terminal is instructed to change the beam, the current beam may not be clearly defined if the BAT has not yet passed. This may affect the operation of the terminal to measure the ED-RS resource to detect an event.

[0358] For example, the terminal may regard a specific ED-RS belonging to an ED-RS resource set as the current beam and measure L1-RSRP or L1-SINR using it (first measurement value). In addition, the terminal may measure L1-RSRP or L1-SINR using another ED-RS belonging to the same ED-RS resource set (second measurement value). In this case, if the difference between the first measurement value and the second measurement value is greater than a preset offset, the event may be regarded as detected, and the terminal may generate the first UCI accordingly. However, if the terminal is instructed to change the beam, the first UCI may not be reported even if it is generated. In addition, if a beam change is additionally instructed after or during the reporting of the first UCI, the terminal may not report the second UCI.

[0359] According to the proposed method, when a beam change is instructed to a terminal, the terminal can cancel the transmission operation of the first UCI. Here, the time point at which the beam change is instructed to the terminal or the time point at which the BAT has not yet elapsed can be defined as T0, and the processing preparation time point for transmitting the first UCI can be defined as T1. If T0 < T1, the terminal can cancel the transmission of the first UCI. Alternatively, the terminal may not be able to cancel the transmission operation of the first UCI. In this case, since the terminal has been instructed to change the beam, the base station may not need the first UCI and the second UCI. Therefore, the terminal can cancel the transmission of the second UCI even if it cancels the transmission of the first UCI or does not cancel the transmission of the first UCI.

[0360] According to the proposed method, if a beam change is instructed to the terminal, the terminal may cancel the transmission operation of the second UCI. Here, T0 and the processing preparation time T2 for transmitting the second UCI can be compared. If T0 < T2, the terminal may cancel the transmission of the second UCI.

[0361]

[0362] UCI expression

[0363] As previously explained, UCI may include an event identifier (or index) and may also include information indicating the size of the information contained in the UCI. In the case of FIGS. 22 and 23, the number of ED-RS identifier(s) (or the number of TCI state index(es)) to be included in the UCI is variable and can be determined after the event occurs. In such cases, polar encoding applied to UCI requires a distinction between the nominal size of the UCI and the contents size.

[0364] The nominal size of a UCI can be considered as the length of an information word in polar encoding. Conversely, the contents size of a UCI can be determined by the identifier(s) of the ED-RS(s) and / or the measurement(s) corresponding to the ED-RS(s), a bit string representing a set of candidate TCI states, or the length of a TCI state index.

[0365] Since the contents size of a UCI can be larger than the nominal size, a single bit string can be generated by concatenating the contents of the UCI and the known bits. In this case, the length of the generated bit string can be considered the nominal size of the UCI.

[0366] Figures 24 to 26 are conceptual diagrams for explaining a UCI expression method according to embodiments of the present invention.

[0367] The definition of an event may vary depending on technical specifications or base station instructions, and one or more of the events illustrated in FIGS. 24 to 26 may be indicated to a terminal as a single event. Meanwhile, FIGS. 24 to 26 are examples for convenience of explanation, and various embodiments of the present invention are not limited to FIGS. 24 to 26.

[0368] In addition, the contents of FIG. 24 or FIG. 26 may include not only the TCI state index, bitmap, and list of identifiers of ED-RSs, but also the values ​​of RSRP / SINR (or relative values ​​for any of the values) for each content. The terminal may include not only the index or identifier but also the measured values ​​of ED-RS resources as the contents of the UCI. Referring to FIG. 24, the events described above may be expressed in one UCI. The UCI may include not only the contents field, but also a size field indicating the size of the UCI, an event field indicating an event, and a known bit (or padding bit) to satisfy the nominal size of the UCI. Here, the order of the contents field, the size field, the event field, and the known bit may be determined according to the technical specification, and does not necessarily have to follow the structure of FIG. 24. However, the base station may be expected to read the event field, the size field, or the event field and the size field from a already known location.

[0369] Referring to Figure 24, three events can be expressed using a single UCI. The content generated by the terminal for each event may vary.

[0370] When the first event occurs, the terminal can transmit a TCI state index of its own choice to the base station. At this time, the first event can generate only a single TCI state index, and may additionally include the index (or identifier) ​​of the serving cell to which it is applied or the index (or identifier) ​​of the BWP. A single TCI state index may be applied to multiple serving cells (or BWPs), and conversely, multiple TCI state indices may be applied to each serving cell (or BWP). This difference can be distinguished by the event field, and when multiple serving cells or TCI state indices are considered, the number of serving cells or TCI state indices can be expressed in the size field. In addition, the terminal may include the RSRP / SINR of the ED-RS associated with the first event.

[0371] When a second event occurs, the terminal may transmit activation information for a subset of specific TCI state indices to the base station. If the length of the bitstream has been previously indicated to the terminal via higher-layer signaling, the size field may be omitted. The bitstream is provided for each serving cell (or BWP), and these can be concatenated to form the content field. The terminal may also include the RSRP / SINR of the ED-RS associated with the second event.

[0372] When a third event occurs, the terminal may transmit to the base station the identifier (or index) of the ED-RS or TCI state having a measurement value (e.g., L1-RSRP, L1-RSRQ, L1-SINR) exceeding the configured boundary and / or the measurement value associated therewith. In this case, the terminal may express the number of the corresponding ED-RSs and / or measurement values ​​in the size field, and configure the contents field by concatenating the identifier (or index) of the ED-RSs and the measurement value. In addition, the terminal may include the RSRP / SINR of the ED-RS associated with the third event.

[0373]

[0374] Referring to Figure 25, four events can be expressed using a single UCI. The three events described above are similar to the third, but the method for determining the event conditions or the way the ED-RS is expressed may not be uniform. Furthermore, this can be applied when the ED-RS and TCI state are explicitly distinguished and indicated to the UE via higher-layer signaling. For example, the fourth event may not be indicated independently, and may be additionally indicated to the UE via higher-layer signaling only when the third and fourth events need to be distinguished.

[0375] According to the proposed method, a terminal can utilize one or more UL signals or UL channels to transmit UCI.

[0376] For example, the first UCI can be interpreted as a single bit. This is similar to how the existing SR is interpreted as a positive SR when transmitted and a negative SR when not transmitted. That is, the first UCI can indicate whether an event occurs or not depending on whether it is transmitted. Here, the type of event can be derived using the resources of the UL signal or UL channel (e.g., PUCCH) through which the first UCI is transmitted. For example, whether the first event occurs or not can be derived from the presence or absence of the first UCI using the first resource. Similarly, whether the second event occurs or not can be derived from the presence or absence of the first UCI using the second resource. The base station can allocate the resources of the UL signal or UL channel for transmitting the second UCI to the terminal from the resource that received the first UCI. In addition, the base station can also prepare to receive the UL signal or UL channel including the second UCI.

[0377] Referring to FIGS. 20 to 23, examples of how the second UCI is configured can be seen. Here, the first UCI indicates an identifier of an event depending on whether it is transmitted (presence or absence), and only the second UCI can include an identifier of a TCI state or RS related to the event and / or an L1-RSRP or L1-SINR value therefor.

[0378] Referring to FIG. 26, the event field and / or the size field may be considered as the first UCI, and the content field and / or the reserved field may be considered as the second UCI. Here, the same encoding procedure may be applied to the first UCI and the second UCI, or different encoding procedures may be applied. Accordingly, the PUCCH on which the first UCI is transmitted (the first PUCCH) and the PUCCH on which the second UCI is transmitted (the second PUCCH or PUSCH) may be transmitted separately. Alternatively, the codeword encoded with the first UCI and the codeword encoded with the second UCI may be multiplexed (e.g., concatenated) and transmitted on the same PUCCH.

[0379] For example, the size of the first UCI may be indicated via higher layer signaling, and the second UCI may be determined to have one of several variable sizes. In this case, the second UCI may omit the reserved field as it is unnecessary, or a smaller field may be used. Meanwhile, additional bits (known bits or dummy bits) may be inserted (appended or prepended) depending on the target code rate of the second UCI. However, depending on the event being considered, the required number of bits (target payload size), the corresponding target code rate, and / or the PUCCH resources may be indicated differently.

[0380] For example, some information about an event may be included in the first UCI, and other information about the event may be included in the second UCI. That is, the identifier of one event may be expressed in stages and included in different UCIs. When both the first UCI and the second UCI are received, the identification information of the event may be fully known to the base station. In this case, the first UCI may include identification information for two or more events or identification information for a set of events. Thereafter, the second UCI may include an identifier that identifies one event among multiple events, or an identifier that identifies one event among one or more events belonging to a set of events.

[0381] The identification information (some or all) of the event included in the first UCI may be indirectly expressed as resource information of the first PUCCH transmitted by the terminal. In this case, the first PUCCH may be transmitted using PUCCH format 0 or PUCCH format 1, or the first UCI may be multiplexed with other UCIs and transmitted using a separately designated PUCCH.

[0382] Alternatively, the identification information (some or all) of the event included in the first UCI may be expressed as a field of the first UCI (e.g., an event field) as a payload in the first PUCCH transmitted by the terminal.

[0383]

[0384] According to the proposed method, the terminal may not include information and identifier about the event in the first UCI. The serving base station may recognize the existence of an event by receiving the first UCI, but may not know the identifier of the event. On the other hand, the second UCI may include an identifier (or index) corresponding to a specific RS or TCI state and a measurement value (L1-RSRP or L1-SINR) for the identifier. Accordingly, the serving base station may instruct the terminal to perform a necessary action by receiving the second UCI. For example, the serving base station may activate or deactivate a specific TCI state, or update the TCI state to associate it with another RS ​​or channel. In this process, the specific identifier of the event may not be used, and the PUCCH (or PUSCH) resource on which the first UCI is transmitted may be indicated to the terminal as a single resource.

[0385] The first UCI may be used to reserve resources for the second UCI to be transmitted, and the identifiers and measurements associated with the beams included in the second UCI may be transmitted on a PUCCH (or PUSCH) with common settings, regardless of the event. In this case, the second UCI may not include information indicating the event identifier and the size of the second UCI.

[0386]

[0387] In another proposed method, reference may be made to FIGS. 13 and 14. Since the first UCI (1720, 1820) may be composed of an event field, a size field, or a combination thereof, the periodically transmitted PUCCH format may be one of formats 2, 3, or 4. In addition, the first UCI may be considered as CSI part 1 of a CSI report. The second UCI (1730, 1830) may be considered as CSI part 1 of a CSI report, or in another example, as CSI part 2. For transmission of the second UCI, a UL prioritization / multiplexing procedure may be performed, and it may be multiplexed with other UCI types or may not be transmitted according to priority.

[0388] The proposed first UCI can define not only the priority of CSI reports but also a priority index. Following existing technical specifications, this can be utilized to determine priorities in UL prioritization / multiplexing procedures by distinguishing between general data traffic (e.g., eMBB) and high-quality, low-latency traffic (e.g., URLLC). For aperiodic CSI reports, the priority index can be indicated in the UL grant field.

[0389] The priority index of the first UCI can be indicated to the terminal via higher-layer signaling. That is, the terminal may assume that the priority index of the first UCI is either high or low. Alternatively, no separate priority index may be defined for the first UCI. That is, the terminal may assume that the priority index of the first UCI is always low.

[0390] In order for the second UCI to be transmitted, a priority index of the second UCI can be derived. The priority index of the second UCI can be derived independently of the first UCI, or can be considered to have the same priority index as the first UCI.

[0391] For example, the priority index of the second UCI can be indicated to the terminal via higher-layer signaling. That is, the terminal can assume that the priority index of the second UCI can be either high or low. Alternatively, a separate priority index may not be defined for the second UCI. That is, the terminal can assume that the priority index of the second UCI always has a low priority.

[0392] Referring back to FIG. 26, due to the difference in the timing of transmission of the first and second UCIs, the UE may include additional information in the second UCI. The base station may instruct to include this additional information, or may not instruct to include it. In order for the UE to transmit the first UCI, an event must be detected by multiple occurrences of event instances over a predetermined period of time. The event instances measure RSRP / SINR using ED-RS resources. Alternatively, the RSRP / SINR may be derived from the CSI reference resource used to derive the first UCI. The UE may report this RSRP / SINR to the base station, which may then be included in the second UCI. Since the RSRP / SINR included in the second UCI may be derived again from the CSI reference resource associated with the second UCI, it may have a different value from the RSRP / SINR used in the first UCI even if the ED-RS resource is the same. Therefore, the terminal can include additional information in the second UCI. For example, for an ED-RS resource scheduled to be included in the second UCI, whether it still generates an event instance (or satisfies the event detection condition) can be additionally derived. In this case, the terminal can derive the corresponding information as 1 bit from the CSI reference resource that generates the second UCI. The derived 1 bit can be derived for each ED-RS resource and can be included in the second UCI together with RSRP / SINR.

[0393]

[0394] DRX related issues

[0395] A terminal can receive a paging message from a camping base station or a serving base station, whether in an RRC connected state or an RRC disconnected state. To reduce power consumption, the terminal may not receive a PDCCH from the base station. Here, receiving a PDCCH may mean a demodulation and / or decoding process performed to detect DCI. In addition, in order for the terminal to perform descrambling of DCI, blind decoding must be performed in a search space set, which may increase the power consumption of the terminal. To prevent this, the terminal can receive a specific search space set (e.g., a Type 2-PDCCH CSS set) and its associated CORESET only in a time resource (e.g., a radio frame, slot, or symbol) promised to the base station. This time resource may be referred to as active time.

[0396] Paging messages can be dynamically scheduled to UEs within a given search space set, and paging information can be decoded from the PDSCH or directly included in DCI. The time resources, or MOs (monitoring occasions), during which paging messages can be received occur periodically, and are referred to as on-durations. If a UE decodes scheduled data within the on-duration, a separate timer (drx-inactivity timer) is started, which can result in the active time being longer than the on-duration.

[0397] If there is data scheduled for the terminal, an additional timer may be started, and a timer supporting retransmission and a HARQ RTT timer may be combined to allow the active time to increase continuously or discontinuously to have longer time resources.

[0398] In existing technical specifications, the series of operations described above can be referred to as DRX (discontinuous reception). A CSI mask can be set up for a terminal via higher-layer signaling, and if certain conditions are met, the terminal may not transmit CSI reports on the PUCCH.

[0399] Here, the specific condition may be that the on-duration timer set for the terminal is not running, and a specific time has elapsed after receiving upper layer signaling (e.g., DRX command MAC CE or long DRX command MAC CE) instructing to perform DRX operation from the serving base station (e.g., DRX command MAC CE or long DRX command MAC CE) (e.g., at least 4 ms when MAC CE is received).

[0400] Additionally, in a multicast environment, if DRX and related timers or MAC CE (or MAC subPDU) are separately instructed and operated, certain conditions may be derived in the same manner, and the terminal may not transmit CSI reports using PUCCH.

[0401] According to the proposed method, even when the terminal performs DRX, it can transmit a part of the CSI report to the serving base station. At this time, a method in which the first UCI and the second UCI are transmitted separately can be considered. Referring to FIGS. 13 and 14, the first UCI (1720, 1820) can be considered as a part of the CSI report. After receiving the first UCI, the serving base station can perform a procedure for receiving the second UCI. For example, the second UCI can also be transmitted using PUCCH, and the serving base station can indicate to the terminal the resource (PUCCH or PUSCH) on which the second UCI can be transmitted through DCI. The terminal can enter the active time to receive the DCI. Therefore, according to the proposed method, when the terminal detects an event and transmits the first UCI, the serving base station can interpret this as a signal that the terminal should enter the active time.

[0402] Additionally, the DCI may be signaled to the terminal via upper layer signaling with a separate search space set and / or CORESET so that the terminal can receive it even in the DRX state. If the search space set is set per terminal (USS set), transmission of the second UCI may only be performed when the terminal is in an RRC connected state.

[0403]

[0404] In another proposed method, the same method can be applied not only to UCI but also to MAC CE (or MAC subPDU). In this case, the event field can correspond to the (e)LCID of the MAC subheader, or can be expressed in a separate UCI. For example, the UCI can include information in the event field and / or the size field. Alternatively, the size field can be expressed through a specific bit of the MAC CE (or MAC subPDU).

[0405]

[0406] When the first UCI is transmitted, it can be multiplexed with other UL signals or UL channels of the terminal. According to existing technical specifications, when transmitting a positive SR, the terminal may not multiplex it with the PUSCH. However, because the BSR (Buffer Status Report) contains more detailed information than the SR, the upper layer can multiplex the following information and generate it into the same codeword, excluding the SR, when a UL grant is received.

[0407] -HARQ-ACK information

[0408] -CG-UCI

[0409] -LRR

[0410] Here, UL approval can be scheduled in the following manner:

[0411] - Scheduling information may be included via DCI, MAC CE (or MAC subPDU), or RRC.

[0412] -PUSCH, type 1 configured grant PUSCH, or type 2 configured grant PUSCH resources can be allocated.

[0413] Unlike SR, the first UCI can be multiplexed (or piggybacked) onto PUSCH.

[0414] According to the proposed method, the first UCI is considered to be at least 1 bit of information and can undergo the same encoding procedure as the HARQ-ACK information. If multiple events are set and / or activated for a terminal, the first UCI can be extended to two or more pieces of information to express whether multiple events are triggered (presence / absence), and in this case, the same encoding procedure as the HARQ-ACK information can be applied.

[0415] Additionally, a repetition number (or transmission number, or number of transmissions) is set for the PUCCH on which the first UCI is transmitted, so that the corresponding PUCCH can be transmitted more than twice. Since the same encoding procedure is applied to other UCIs multiplexed with the first UCI, the first UCI and the corresponding UCI can be transmitted more than twice using the same PUCCH.

[0416] According to the proposed method, the transmission of the first UCI may be dropped due to the transmission of another UCI during the transmission of the first UCI. The terminal may transmit the first UCI via the first PUCCH, and the transmission may be performed only once or repeatedly two or more times. However, if a second PUCCH (or PUSCH) containing a different UCI type must be transmitted, the terminal may drop the transmission of the first PUCCH and transmit the second PUCCH (or PUSCH).

[0417] Here, the time resources of the first PUCCH and the time resources of the second PUCCH (or PUSCH) may overlap with each other, and considering the time required to prepare the second PUCCH (or PUSCH), even if there is no overlap, some or all symbols of the first PUCCH may not be transmitted while the second PUCCH (or PUSCH) transmits all symbols.

[0418] The following are separate UCI types that can be included in the second PUCCH (or PUSCH):

[0419] -SR (Scheduling Request)

[0420] -HARQ-ACK information

[0421] - Same as the 1st UCI, but derived from a different event

[0422] - UCIs belonging to the same event but derived from different RSs (or TCI states)

[0423]

[0424] In the proposed method, after the terminal generates the first UCI, a separate counter or time window can be applied to generate the first UCI again.

[0425] For example, after a terminal reports the first UCI, it may not transmit the first UCI again for a certain period of time. Here, the counter or time window may have different values ​​for each event or for each combination (or set) of events. Since each event may have different requirements, the reporting interval for the first UCI may be adjusted to maintain a specific time interval.

[0426] However, these restrictions may not apply to different events. Therefore, the first UCIs for different events may overlap and occur more frequently than a specific time interval.

[0427] Additionally, the proposed method can be applied to multiple events by setting a counter or time window to a single value. In this case, the terminal can assume that after generating the first UCI for an event, it will not generate the first UCI again for a certain period of time. Therefore, during this time, the terminal may not determine whether the event is triggered.

[0428]

[0429] In the case where the second UCI is transmitted on the PUCCH, the PUCCH on which the second UCI is transmitted may also be repeatedly transmitted two or more times, and the number of transmissions of the PUCCH on which the second UCI is transmitted may be determined independently from the number of transmissions of the PUCCH on which the first UCI is transmitted.

[0430] If, while the second UCI is being repeatedly transmitted, the terminal satisfies a new trigger condition or needs to retransmit the first UCI based on a different RS (or TCI state) in the same event, the first UCI can be transmitted before the transmission of the second UCI is completed. The PUCCHs mentioned here can correspond to the same priority index, have the same priority as eMBB traffic or the same priority as URLLC traffic, and multiplexing and prioritization can be performed.

[0431] For example, the currently transmitting second UCI and the newly transmitted first UCI can be processed through multiplexing and prioritization of UL resources. In this case, only one of the second PUCCH containing the second UCI and the first PUCCH containing the first UCI can be transmitted, and depending on the priority, some or all of the other PUCCHs may be dropped.

[0432] Here, the first PUCCH and the second PUCCH can be dropped or prioritized only in temporally overlapping PUCCH occasions (or PUCCH repetitions), and non-overlapping PUCCHs can be transmitted with the allocated resources as is.

[0433] Additionally, the PUSCH containing the second UCI and the PUCCH containing the first UCI may be multiplexed. In this case, PUSCH dropping or prioritization may be performed only on temporally overlapping PUCCH occasions (or PUCCH repetitions), while non-overlapping PUCCHs may be transmitted using their allocated resources.

[0434]

[0435] The operations of the method according to an embodiment of the present invention can be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes any type of recording device that stores information readable by a computer system. Furthermore, a computer-readable recording medium can be distributed across network-connected computer systems, allowing the computer-readable program or code to be stored and executed in a distributed manner.

[0436] Additionally, the computer-readable recording medium may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. The program instructions may include not only machine language codes produced by a compiler, but also high-level language codes that can be executed by a computer using an interpreter, etc.

[0437] While some aspects of the present invention have been described in the context of a device, they may also represent a description of a corresponding method, wherein a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method may also be described as a corresponding block or item or a feature of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one or more of the most important method steps may be performed by such a device.

[0438] In embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In embodiments, the field-programmable gate array may operate in conjunction with a microprocessor to perform one of the methods described herein. In general, the methods are preferably performed by some hardware device.

[0439] Although the present invention has been described above with reference to preferred embodiments thereof, it will be understood by those skilled in the art that various modifications and changes may be made to the present invention without departing from the spirit and scope of the present invention as set forth in the claims below.

Claims

1. In the terminal method, A step of receiving configuration information for an ED-RS resource set including at least one ED-RS (event-detection reference signal) resource from a base station; A step of monitoring the occurrence of an event(s) using at least a portion of the ED-RS resources of the at least one ED-RS resource; and If the occurrence of at least one event is monitored, a step of transmitting a first report to the base station for reporting the at least one event that has occurred is included. Terminal method.

2. In claim 1, A step of receiving a first instruction from the base station to change QCL (quasi-co-location) information of at least one ED-RS resource; and Further comprising a step of changing QCL information of at least one ED-RS resource according to the first instruction. Terminal method.

3. In claim 2, The above first instruction is received as included in a MAC (medium access control) CE (control element) or is received through a specific MAC CE (or MAC subPDU) format. Terminal method.

4. In claim 1, Further comprising a step of determining that the occupation of at least one CPU (CSI processing unit) has begun at a time when the occurrence of at least one event is monitored or at a time when the first report is transmitted to the base station. Terminal method.

5. In claim 1, After transmitting the first report, the method further comprises transmitting a second report to the base station, the second report including information about measurement value(s) for at least some ED-RS resources related to the occurrence of the at least one event, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources related to the occurrence of the at least one event. Terminal method.

6. In claim 5, The above measurement value(s) are L1-RSRP (layer 1-reference signal received power) value(s). Terminal method.

7. In claim 5, The first report is transmitted through a physical uplink control channel (PUCCH), and the second report is transmitted through a PUCCH or a physical uplink shared channel (PUSCH). Terminal method.

8. In claim 5, The first report or the second report includes information about at least one event that occurred. Terminal method.

9. In claim 5, Further comprising a step of determining that at least one CPU is occupied from the time the second report is transmitted to the base station. Terminal method.

10. In claim 1, If at least some of the ED-RS resources include a specific RS, the terminal monitors the occurrence of at least one event by measuring a downlink RS corresponding to a reception beam of the terminal derived from a transmission configuration indicator (TCI) state or QCL information of the specific RS on behalf of the specific RS. Terminal method.

11. In claim 10, The above specific RS is a TRS (tracking reference signal), and the downlink RS is a SSB (synchronization signal block) or a CSI-RS (channel state information-reference signal) for beam management. Terminal method.

12. In the method of the base station, A step of transmitting configuration information for a set of ED-RS resources including at least one ED-RS (event-detection reference signal) resource to a terminal; and A step of receiving a first report from the terminal for reporting the occurrence of at least one event among the event(s) monitored using at least a portion of the at least one ED-RS resource, Base station method.

13. In claim 12, Further comprising a step of transmitting a first instruction for changing QCL (quasi-co-location) information of at least one ED-RS resource from the terminal, Base station method.

14. In claim 13, The above first instruction is transmitted in a MAC (medium access control) CE (control element) or transmitted through a specific MAC CE (or MAC subPDU) format. Base station method.

15. In claim 13, After receiving the first report, the method further comprises receiving a second report from the terminal, the second report including information about measurement value(s) for at least some ED-RS resources related to the occurrence of the at least one event, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources related to the occurrence of the at least one event. Base station method.

16. In claim 13, The first report is received via a physical uplink control channel (PUCCH), and the second report is received via a physical uplink shared channel (PUSCH) or a PUCCH. Base station method.

17. At the terminal, At least one processor, wherein the terminal comprises: A step of receiving configuration information for an ED-RS resource set including at least one ED-RS (event-detection reference signal) resource from a base station; A step of monitoring the occurrence of an event(s) using at least a portion of the ED-RS resources of the at least one ED-RS resource; and When the occurrence of at least one event is monitored, a step of transmitting a first report to the base station for reporting the at least one event that has occurred is performed. Terminal.

18. In claim 17, At least one processor of the terminal: A step of receiving a first instruction from the base station to change QCL (quasi-co-location) information of at least one ED-RS resource; and To additionally perform a step of changing the QCL information of at least one ED-RS resource according to the first instruction, Terminal.

19. In claim 17, At least one processor of the terminal: After transmitting the first report, the step of transmitting a second report to the base station, the second report including information about measurement value(s) for at least some ED-RS resources related to the occurrence of the at least one event, or including information about measurement value(s) for at least some ED-RS resources and other RS ​​resources related to the occurrence of the at least one event, is further performed. Terminal.

20. In claim 19, The first report is transmitted through a physical uplink control channel (PUCCH), and the second report is transmitted through a PUCCH or a physical uplink shared channel (PUSCH). Terminal.

Images