Method and apparatus for beam failure recovery in a wireless communication system

Abstract

To provide a method and a device for performing beam failure recovery in a wireless communication system.SOLUTION: A method for a terminal to perform uplink transmission or downlink reception according to one embodiment of the present disclosure. The method includes the steps of: transmitting a beam failure recovery request (BFRQ) to a base station based on detection of a beam failure from at least one resource group among a plurality of resource groups; receiving a response to the BFRQ from the base station; and transmitting information related to the beam failure to the base station. The information related to the beam failure can indicate a specific resource group in which the beam failure has been detected or the plurality of resource groups in which the beam failure has been detected.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] The present disclosure relates to wireless communication systems, and more particularly to beam failure recovery methods and apparatus in wireless communication systems. [Background technology]

[0002] Mobile communication systems were developed to provide voice services while ensuring user activity. However, the scope of mobile communication systems has expanded beyond voice to include data services, and the explosive growth in traffic is causing resource shortages. Users are also demanding faster services, so there is a demand for more advanced mobile communication systems.

[0003] The requirements for next-generation mobile communication systems are to accommodate large and explosive data traffic, dramatically increase the transmission rate per user, accommodate a significantly increased number of connected devices, support very low end-to-end latency, and high energy efficiency.To achieve this, various technologies are being researched, including dual connectivity, massive multiple input multiple output (MIMO), in-band full duplex, non-orthogonal multiple access (NOMA), super wideband support, and device networking. Summary of the Invention [Problem to be solved by the invention]

[0004] A technical problem of the present disclosure is to provide a method and apparatus for performing beam failure recovery.

[0005] Furthermore, a further technical object of the present disclosure is to provide a method and apparatus for performing beam failure recovery when a beam failure occurs in a specific resource group or multiple resource groups.

[0006] The technical problems to be solved by the present disclosure are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary skill in the art to which the present disclosure pertains from the following description. [Means for solving the problem]

[0007] As one embodiment of the present disclosure, a method for a terminal to perform beam failure recovery (BFR) in a wireless communication system includes the steps of: transmitting a beam failure recovery request (BFRQ) to a base station based on detection of a beam failure in at least one resource group among a plurality of resource groups; receiving a response to the BFRQ from the base station; and transmitting information related to the beam failure to the base station, wherein the information related to the beam failure may indicate a specific resource group in which the beam failure was detected or the plurality of resource groups in which the beam failure was detected.

[0008] As yet another embodiment of the present disclosure, there is provided a method for a base station to perform beam failure recovery (BFR) in a wireless communication system, the method including: receiving a beam failure recovery request (BFRQ) from a terminal based on detection of a beam failure in at least one resource group among a plurality of resource groups; transmitting a response to the BFRQ to the base station; and receiving information related to the beam failure from the terminal, wherein the information related to the beam failure may indicate a specific resource group in which the beam failure is detected or the plurality of resource groups in which the beam failure is detected. [Effects of the Invention]

[0009] According to one embodiment of the present disclosure, a method and apparatus for performing a beam recovery operation in a wireless communication system can be provided.

[0010] According to an embodiment of the present disclosure, a method and apparatus for performing beam failure recovery operations when a beam failure occurs in a specific resource group or multiple resource groups can be provided.

[0011] The effects that can be obtained by the present disclosure are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those having ordinary skill in the art to which the present disclosure pertains from the following description. [Brief explanation of the drawings]

[0012] The accompanying drawings, which are included as part of the detailed description to aid in understanding the present disclosure, provide examples of the present disclosure and, together with the detailed description, explain the technical features of the present disclosure. [Figure 1] 1 illustrates the structure of a wireless communication system to which the present disclosure is applicable. [Figure 2] 1 illustrates a frame structure in a wireless communication system to which the present disclosure is applicable. [Figure 3] 1 illustrates an example of a resource grid in a wireless communication system to which the present disclosure is applicable. [Figure 4] 1 illustrates an example of a physical resource block in a wireless communication system to which the present disclosure is applicable. [Figure 5] 1 illustrates an example slot structure in a wireless communication system to which the present disclosure is applicable. [Figure 6] 1 illustrates examples of physical channels used in a wireless communication system to which the present disclosure is applicable, and a general signal transmission / reception method using the physical channels. [Figure 7] 1 illustrates a multiple TRP transmission method in a wireless communication system to which the present disclosure is applicable. [Figure 8] FIG. 10 is a diagram for explaining the beam failure recovery operation of a terminal according to one embodiment of the present disclosure. [Figure 9] A diagram for explaining the beam failure recovery operation of a base station according to one embodiment of the present disclosure. [Figure 10] FIG. 10 is a diagram for explaining a signaling procedure between a network side and a terminal according to an embodiment of the present disclosure. [Figure 11] 1 illustrates a block diagram of a wireless communication device according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] Preferred embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. The detailed description disclosed below together with the accompanying drawings is intended to describe exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present disclosure can be implemented. The detailed description below includes specific details to provide a complete understanding of the present disclosure. However, it will be understood by those skilled in the art that the present disclosure can be implemented without such specific details.

[0014] In some cases, in order to avoid obscuring the concepts of the present disclosure, known structures and devices may be omitted or shown in block diagram form, focusing on the core functions of each structure and device.

[0015] In this disclosure, when a component is "coupled," "coupled," or "connected" to another component, this may include a direct connection, as well as an indirect connection where there is another component between them. Also, in this disclosure, the terms "comprise" or "have" specify the presence of stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0016] In this disclosure, terms such as "first" and "second" are used only to distinguish one component from another, not to limit the components, and do not limit the order or importance of the components unless otherwise specified. Therefore, within the scope of this disclosure, a first component in one embodiment may be referred to as a second component in another embodiment, and similarly, a second component in one embodiment may be referred to as a first component in another embodiment.

[0017] The terms used in this disclosure are for the purpose of describing particular embodiments and are not intended to limit the scope of the claims. As used in the description of the embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly dictates otherwise. The term "and / or" used in this disclosure means that one of the associated listed items may be used, or that any and all possible combinations of two or more of them may be used. Also, in this disclosure, " / " between words has the same meaning as "and / or" unless otherwise specified.

[0018] The present disclosure is described with respect to a wireless communication network or a wireless communication system, and operations performed in a wireless communication network may be performed in the process in which a device (e.g., a base station) that manages the wireless communication network controls the network and transmits or receives signals, or in the process in which a terminal coupled to the wireless network transmits or receives signals to or from the network or between terminals.

[0019] In this disclosure, transmitting or receiving a channel includes transmitting or receiving information or signals on that channel. For example, transmitting a control channel means transmitting control information or signals on the control channel. Similarly, transmitting a data channel means transmitting data information or signals on the data channel.

[0020] Hereinafter, downlink (DL) refers to communication from a base station to a terminal, and uplink (UL) refers to communication from a terminal to a base station. In the downlink, a transmitter may be part of the base station, and a receiver may be part of the terminal. In the uplink, a transmitter may be part of the terminal, and a receiver may be part of the base station. The base station may be expressed as a first communication device, and the terminal may be expressed as a second communication device. A base station (BS) may be replaced with terms such as a fixed station, Node B, evolved-Node B (eNB), Next Generation Node B (gNB), base transceiver system (BTS), access point (AP), network (5G network), artificial intelligence (AI) system / module, road side unit (RSU), robot, unmanned aerial vehicle (UAV), augmented reality (AR) device, virtual reality (VR) device, etc. Furthermore, a terminal may be fixed or mobile, and may be replaced with terms such as UE (User Equipment), MS (Mobile Station), UT (user terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless terminal), MTC (Machine-Type Communication) device, M2M (Machine-to-Machine) device, D2D (Device-to-Device) device, vehicle, RSU (road side unit), robot, AI (Artificial Intelligence) module, drone (UAV: Unmanned Aerial Vehicle), AR (Augmented Reality) device, VR (Virtual Reality) device, etc.

[0021] The following technologies may be used for various wireless access systems, such as CDMA, FDMA, TDMA, OFDMA, SC-FDMA, etc. CDMA may be implemented by radio technologies such as Universal Terrestrial Radio Access (UTRA) and CDMA2000. TDMA may be implemented by radio technologies such as Global System for Mobile communications (GSM), General Packet Radio Service (GPRS), and Enhanced Data Rates for GSM Evolution (EDGE). OFDMA may be implemented by radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, Evolved UTRA (E-UTRA), etc. UTRA is part of the Universal Mobile Telecommunications System (UMTS). 3GPP (registered trademark) 3rd Generation Partnership Project (LTE) Long Term Evolution (LTE) is a part of E-UMTS (Evolved UMTS) that uses E-UTRA, and LTE-Advanced (LTE-A) / LTE-A pro is an evolved version of 3GPP LTE. 3GPP NR (New Radio or New Radio Access Technology) is an evolved version of 3GPP LTE / LTE-A / LTE-A pro.

[0022] For clarity, the following description will be based on a 3GPP communication system (e.g., LTE-A, NR), but the technical concept of the present disclosure is not limited thereto. LTE refers to technology from 3GPP Technical Specification (TS) 36.xxx Release 8 onward. Specifically, LTE technology from 3GPP TS 36.xxx Release 10 onward is called LTE-A, and LTE technology from 3GPP TS 36.xxx Release 13 onward is called LTE-A pro. 3GPP NR refers to technology from TS 38.xxx Release 15 onward. LTE / NR may be referred to as a 3GPP system. "xxx" refers to the standard document detail number. LTE / NR may be referred to as a 3GPP system. For background technology, terms, abbreviations, etc. used in the description of the present disclosure, please refer to the matters described in standard documents published before the present disclosure. For example, the following documents may be referenced:

[0023] In 3GPP LTE, reference can be made to TS 36.211 (Physical channels and modulation), TS 36.212 (Multiplexing and channel coding), TS 36.213 (Physical layer procedures), TS 36.300 (General description), and TS 36.331 (Radio resource control).

[0024] For 3GPP NR, reference can be made to TS 38.211 (Physical Channels and Modulation), TS 38.212 (Multiplexing and Channel Coding), TS 38.213 (Physical Layer Procedures for Control), TS 38.214 (Physical Layer Procedures for Data), TS 38.300 (General Description of NR and NG-RAN (New Generation-Radio Access Network)), and TS 38.331 (Radio Resource Control Protocol Standard).

[0025] The terminology abbreviations that may be used in this disclosure are defined as follows:

[0026] - BM: Beam management

[0027] - CQI: Channel Quality Indicator

[0028] - CRI: Channel state information-reference signal resource indicator

[0029] - CSI: Channel State Information

[0030] - CSI-IM: Channel state information-interference measurement

[0031] - CSI-RS: Channel state information-reference signal

[0032] - DMRS: Demodulation Reference Signal

[0033] - FDM: Frequency Division Multiplexing

[0034] - FFT: Fast Fourier transform

[0035] - IFDMA: Interleaved frequency division multiple access

[0036] - IFFT: Inverse fast Fourier transform

[0037] - L1-RSRP: Layer 1 reference signal received power

[0038] - L1-RSRQ: Layer 1 reference signal received quality

[0039] - MAC: Medium Access Control

[0040] - NZP: Non-zero power

[0041] - OFDM: Orthogonal frequency division multiplexing

[0042] - PDCCH: Physical downlink control channel

[0043] - PDSCH: Physical downlink shared channel

[0044] - PMI: Precoding matrix indicator

[0045] - RE: resource element

[0046] - RI: Rank indicator

[0047] - RRC: Radio resource control

[0048] - RSSI: received signal strength indicator

[0049] - Rx: Reception

[0050] - QCL: quasi co-location

[0051] - SINR: Signal to interference and noise ratio

[0052] - SSB (or SS / PBCH block): Synchronization signal block (including primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH))

[0053] - TDM: time division multiplexing

[0054] - TRP: transmission and reception point

[0055] - TRS: Tracking reference signal

[0056] - Tx: transmission

[0057] - UE: User equipment

[0058] - ZP: Zero power

[0059] System in general

[0060] As more communication devices require greater communication capacity, there is a growing need for improved mobile broadband communication compared to existing radio access technologies (RATs). Massive Machine Type Communications (MTC), which connects multiple devices and objects to provide a variety of services anytime, anywhere, is also one of the key issues being considered for next-generation communications. In addition, communication system designs that take into account reliability- and latency-sensitive services / terminals are also being discussed. Thus, the introduction of next-generation RATs that take into account technologies such as enhanced mobile broadband communication (eMBB), massive MTC (MMTC), and ultra-reliable and low latency communication (URLLC) is being discussed. For convenience, these technologies will be referred to as NR in this disclosure. NR is an example of a 5G RAT.

[0061] New RAT systems, including NR, use an OFDM transmission scheme or a similar transmission scheme. A new RAT system may follow OFDM parameters different from those of LTE. Alternatively, a new RAT system may follow the existing LTE / LTE-A numerology but support a larger system bandwidth (e.g., 100 MHz). Alternatively, one cell may support multiple numerologies. That is, terminals operating with different numerologies may coexist within one cell.

[0062] A numerology corresponds to a subcarrier spacing in the frequency domain. Different numerologies can be defined by scaling the reference subcarrier spacing by an integer N.

[0063] FIG. 1 illustrates the structure of a wireless communication system to which the present disclosure can be applied.

[0064] Referring to FIG. 1, the NG-RAN is composed of gNBs that provide the NG-RA (NG-Radio Access) user plane (i.e., new access stratum (AS) sublayer / Packet Data Convergence Protocol (PDCP) / Radio Link Control (RLC) / MAC / PHY) and control plane (RRC) protocol termination for the UE. The gNBs are interconnected via an Xn interface. The gNBs are also connected to an NGC (New Generation Core) via an NG interface. More specifically, the gNBs are connected to an AMF (Access and Mobility Management Function) via an N2 interface and to a UPF (User Plane Function) via an N3 interface.

[0065] FIG. 2 illustrates a frame structure in a wireless communication system to which the present disclosure can be applied.

[0066] An NR system can support multiple numerologies. Here, a numerology may be defined by subcarrier spacing and cyclic prefix (CP) overhead. In this case, multiple subcarrier spacings may be derived by scaling the base (reference) subcarrier spacing by an integer N (or μ). Furthermore, even if it is assumed that very low subcarrier spacings are not used at very high carrier frequencies, the numerology used may be selected independently of the frequency band. Furthermore, an NR system may support various frame structures based on multiple numerologies.

[0067] The following describes OFDM numerologies and frame structures that can be considered in an NR system. A number of OFDM numerologies supported in an NR system may be defined as shown in Table 1 below.

[0068] [Table 1]

[0069] NR supports multiple numerologies (or subcarrier spacing (SCS)) to support various 5G services. For example, a 15 kHz SCS supports wide areas in traditional cellular bands, a 30 kHz / 60 kHz SCS supports dense urban areas, lower latency, and wider carrier bandwidths, and a 60 kHz or higher SCS supports bandwidths greater than 24.25 GHz to overcome phase noise. NR frequency bands are defined as two types of frequency ranges (FR1 and FR2). FR1 and FR2 may be configured as shown in Table 2 below. FR2 can also refer to millimeter wave (mmW).

[0070] [Table 2]

[0071] In relation to the frame structure in an NR system, the size of the various fields in the time domain is T c =1 / (Δf max N f ) where Δf max =480 10 3 Hz and N f= 4096. Downlink and uplink transmission is T f =1 / (Δf max N f / 100)·T c The radio frame is organized into radio frames each having a duration of T = 10 ms. sf =(Δf max N f / 1000)·T c In this case, there may be one set of frames for the uplink and one set of frames for the downlink. In addition, transmission from a terminal in uplink frame number i begins T TA =(N TA +N TA,offset )T c For a subcarrier spacing configuration μ, a slot is allocated within a subframe. s μ ∈{0,...,N slot subframe,μ -1}, and n s,f μ ∈{0,...,N slot frame,μ The slots are numbered in increasing order {N -1}. symb slot It consists of N consecutive OFDM symbols, symb slot is determined by the CP. s μ The start of OFDM symbol n s μ N symb slotNot all terminals can transmit and receive at the same time, which means that not all OFDM symbols in a downlink slot or an uplink slot can be used. Table 3 shows the number of OFDM symbols per slot (N symb slot ), the number of slots per radio frame (N slot frame,μ ), the number of slots per subframe (N slot subframe,μ ) and Table 4 shows the number of OFDM symbols per slot, the number of slots per radio frame, and the number of slots per subframe in the extended CP.

[0072] [Table 3]

[0073] [Table 4]

[0074] FIG. 2 shows an example where μ=2 (SCS is 60 kHz). Referring to Table 3, one subframe can include four slots. The {1, 2, 4} slots shown in FIG. 2 are an example, and the number of slots that can be included in one subframe is defined as shown in Table 3 or Table 4. Also, a mini-slot can include 2, 4, or 7 symbols, or more or fewer symbols. Regarding physical resources in an NR system, antenna ports, resource grids, resource elements, resource blocks, carrier parts, and the like may be considered. The physical resources that can be considered in an NR system will now be described in detail. First, regarding antenna ports, the antenna ports are defined so that the channel on which symbols on an antenna port are carried can be inferred from the channel on which other symbols on the same antenna port are carried. Two antenna ports are said to be in a QC / QCL (quasi co-located) relationship when the large-scale properties of the channel through which symbols on one antenna port are carried can be inferred from the channel through which symbols on the other antenna port are carried. Here, the large-scale properties include one or more of delay spread, Doppler spread, frequency shift, average received power, and received timing. FIG. 3 illustrates a resource grid in a wireless communication system to which the present disclosure can be applied. Referring to FIG. 3, the resource grid is divided into N RB μ N sc RB It consists of subcarriers, and one subframe is 14.2 μIn the NR system, a transmitted signal is composed of OFDM symbols, for example, but not limited to, RB μ N sc RB One or more resource grids consisting of subcarriers and two μ N symb (μ) OFDM symbols, where N RB μ ≦N RB max,μ The above N RB max,μ represents the maximum transmission bandwidth, which may vary not only depending on the numerology but also between the uplink and downlink. In this case, one resource grid may be configured for each μ and antenna port p. Each element of the resource grid for μ and antenna port p is called a resource element, and is represented by an index pair. JPEG0007736887000005.jpg788, where k=0,...,N RB μ N sc RB -1 is the index in the frequency domain, JPEG0007736887000006.jpg886 represents the position of the symbol within a subframe. When referring to resource elements within a slot, the index pair (k, l) is used, where l = 0,...,N symb μ μ and the resource element for antenna port p. JPEG0007736887000007.jpg880 is a complex value JPEG0007736887000008.jpg811. If there is no risk of confusion or if a specific antenna port or numerology is not specified, the indices p and μ may be dropped, so that the complex value is JPEG0007736887000009.jpg912 or JPEG0007736887000010.jpg912. Also, a resource block (RB) is a set of N sc RB = 12 consecutive subcarriers.

[0075] Point A serves as a common reference point for the resource block grid and is obtained as follows:

[0076] - offsetToPointA for the primary cell (PCell) downlink indicates the frequency offset between point A and the lowest subcarrier of the lowest resource block that overlaps with the SS / PBCH block used by the terminal for initial cell selection. It is expressed in resource block units assuming 15 kHz subcarrier spacing for FR1 and 60 kHz subcarrier spacing for FR2.

[0077] - absoluteFrequencyPointA indicates the frequency-location of point A expressed as in ARFCN (absolute radio-frequency channel number).

[0078] Common resource blocks are numbered from 0 upwards in the frequency domain for a subcarrier spacing setting μ. The center of subcarrier 0 of common resource block 0 for a subcarrier spacing setting μ coincides with 'point A'. In the frequency domain, common resource block number n CRB μ The relationship between the resource elements (k, l) for the subcarrier spacing setting μ is given by the following equation 1.

[0079]

number

[0080] In Equation 1, k is defined relative to point A so that k=0 corresponds to the subcarrier centered at point A. The physical resource blocks are numbered from 0 to N within the bandwidth part (BWP). BWP,i size,μ Physical resource block n in BWP i is numbered from -1 to i. PRB and common resource block n CRB The relationship between is given by Equation 2 below.

[0081]

number

[0082] N BWP,i start,μ is the common resource block where the BWP starts relative to common resource block 0.

[0083] Fig. 4 illustrates a physical resource block in a wireless communication system to which the present disclosure can be applied, and Fig. 5 illustrates a slot structure in a wireless communication system to which the present disclosure can be applied.

[0084] 4 and 5, a slot includes multiple symbols in the time domain. For example, in the general CP, one slot includes seven symbols, while in the extended CP, one slot includes six symbols.

[0085] A carrier wave includes multiple subcarriers in the frequency domain. A resource block (RB) is defined as multiple (e.g., 12) consecutive subcarriers in the frequency domain. A bandwidth part (BWP) is defined as multiple consecutive (physical) resource blocks in the frequency domain, and may correspond to one numerology (e.g., SCS, CP length, etc.). A carrier wave can include up to N (e.g., 5) BWPs. Data communication is performed using activated BWPs, and only one BWP may be activated for one terminal. Each element in the resource grid is called a resource element (RE), and one complex symbol may be mapped to it.

[0086] The NR system may support up to 400 MHz per component carrier (CC). If a terminal operating on such a wideband CC keeps the radio frequency (RF) chip for the entire CC on at all times, battery consumption may increase. Considering various application cases (e.g., eMBB, URLLC, MMTc, V2X, etc.) operating within a single wideband CC, different numerologies (e.g., subcarrier spacing, etc.) may be supported for each frequency band within the CC. Each terminal may have different capabilities for maximum bandwidth. In consideration of this, a base station may instruct a terminal to operate only with a portion of the bandwidth of a wideband CC, rather than the entire bandwidth. For convenience, this portion of the bandwidth is defined as a bandwidth part (BWP). A BWP may consist of contiguous RBs on the frequency axis and correspond to one numerology (e.g., subcarrier spacing, CP length, slot / minislot duration).

[0087] Meanwhile, a base station can configure multiple BWPs within one CC configured for a terminal. For example, a BWP occupying a relatively small frequency region can be configured in a PDCCH monitoring slot, and the PDSCH indicated by the PDCCH can be scheduled on a larger BWP. Alternatively, when UEs are concentrated in a specific BWP, other BWPs can be configured for some terminals for load balancing. Alternatively, both BWPs can be configured within the same slot by excluding a portion of the spectrum from the entire bandwidth, taking into account frequency domain inter-cell interference cancellation between neighboring cells. That is, a base station can configure at least one DL / UL BWP for a terminal associated with a wideband CC. The base station can activate at least one DL / UL BWP configured at a specific time (through L1 signaling, MAC Control Element (CE), RRC signaling, etc.). In addition, the base station can instruct switching to another configured DL / UL BWP (by L1 signaling, MAC CE, RRC signaling, etc.). Alternatively, the base station may switch to a predetermined DL / UL BWP when a timer value expires on a timer basis. In this case, the activated DL / UL BWP is defined as an active DL / UL BWP. However, in situations where the UE is performing an initial access procedure or before an RRC connection is set up, the UE may not be able to receive the configuration for the DL / UL BWP. Therefore, the DL / UL BWP assumed by the UE in such a situation is defined as the initially active DL / UL BWP.

[0088] FIG. 6 illustrates physical channels used in a wireless communication system to which the present disclosure is applicable, and a general signal transmission / reception method using the physical channels.

[0089] In a wireless communication system, a terminal receives information from a base station through a downlink and transmits information to the base station through an uplink. Information exchanged between the base station and the terminal includes data and various control information, and various physical channels exist depending on the type / purpose of the information exchanged.

[0090] When a terminal is powered on or newly enters a cell, it performs an initial cell search, such as synchronizing with a base station (S601). To do this, the terminal receives a primary synchronization signal (PSS) and a secondary synchronization signal (SSS) from the base station to synchronize with the base station and acquire information such as a cell identifier (ID). The terminal then receives a physical broadcast channel (PBCH) from the base station to acquire broadcast information within the cell. Meanwhile, the terminal can receive a downlink reference signal (DL RS) during the initial cell search phase to check the downlink channel status.

[0091] After completing the initial cell search, the terminal receives a Physical Downlink Control Channel (PDCCH) and a Physical Downlink Shared Channel (PDSCH) based on the information carried on the PDCCH, thereby obtaining more specific system information (S602).

[0092] Meanwhile, when the terminal first connects to the base station or when there are no radio resources for signal transmission, the terminal can perform a random access procedure (RACH) with the base station (steps S603 to S606). To this end, the terminal transmits a specific sequence as a preamble on a physical random access channel (PRACH) (steps S603 and S605) and can receive a response message to the preamble on a PDCCH and a corresponding PDSCH (steps S604 and S606). In the case of a contention-based RACH, a contention resolution procedure can also be performed.

[0093] After performing the above-described procedures, the UE can then perform PDCCH / PDSCH reception (S607) and Physical Uplink Shared Channel (PUSCH) / Physical Uplink Control Channel (PUCCH) transmission (S608) as a general uplink / downlink signal transmission procedure. In particular, the UE receives Downlink Control Information (DCI) through the PDCCH. Here, DCI includes control information such as resource allocation information for the UE, and its format varies depending on its purpose.

[0094] Meanwhile, control information that a terminal transmits to a base station on the uplink or that the terminal receives from a base station includes downlink / uplink ACK / NACK (Acknowledgement / Non-Acknowledgement) signals, CQI (Channel Quality Indicator), PMI (Precoding Matrix Indicator), RI (Rank Indicator), etc. In a 3GPP LTE system, a terminal can transmit the above-mentioned control information such as CQI / PMI / RI on a PUSCH and / or a PUCCH.

[0095] Table 5 shows an example of a DCI format in an NR system.

[0096] [Table 5]

[0097] Referring to Table 5, DCI formats 0_0, 0_1, and 0_2 may include resource information related to PUSCH scheduling (e.g., UL / SUL (Supplementary UL), frequency resource allocation, time resource allocation, frequency hopping, etc.), transport block (TB)-related information (e.g., MCS (Modulation Coding and Scheme), NDI (New Data Indicator), RV (Redundancy Version), etc.), HARQ (Hybrid-Automatic Repeat and request)-related information (e.g., process number, DAI (Downlink Assignment Index), PDSCH-HARQ feedback timing, etc.), multiple antenna-related information (e.g., DMRS sequence initialization information, antenna port, CSI request, etc.), and power control information (e.g., PUSCH power control, etc.), and the control information included in each DCI format may be predefined.

[0098] DCI format 0_0 is used for PUSCH scheduling in one cell. Information included in DCI format 0_0 is CRC (cyclic redundancy check) scrambled using a Cell Radio Network Temporary Identifier (C-RNTI), a Configured Scheduling RNTI (CS-RNTI), or a Modulation Coding Scheme Cell RNTI (MCS-C-RNTI) before being transmitted.

[0099] DCI format 0_1 ​​is used to indicate scheduling of one or more PUSCHs in one cell or downlink feedback information of configured grants (CGs) to a terminal. The information included in DCI format 0_1 ​​is CRC-scrambled using C-RNTI, CS-RNTI, SP-CSI-RNTI (Semi-Persistent CSI RNTI), or MCS-C-RNTI and then transmitted.

[0100] DCI format 0_2 is used for PUSCH scheduling in one cell. Information included in DCI format 0_2 is CRC scrambled using C-RNTI, CS-RNTI, SP-CSI-RNTI, or MCS-C-RNTI and then transmitted.

[0101] Next, DCI formats 1_0, 1_1, and 1_2 may include resource information related to PDSCH scheduling (e.g., frequency resource allocation, time resource allocation, VRB (virtual resource block)-PRB (physical resource block) mapping, etc.), transmission block (TB) related information (e.g., MCS, NDI, RV, etc.), HARQ related information (e.g., process number, DAI, PDSCH-HARQ feedback timing, etc.), multiple antenna related information (e.g., antenna port, TCI (transmission configuration indicator), SRS (sounding reference signal) request, etc.), and PUCCH related information (e.g., PUCCH power control, PUCCH resource indicator, etc.), and the control information included in each DCI format may be pre-defined.

[0102] DCI format 1_0 is used for PDSCH scheduling in one DL cell. Information included in DCI format 1_0 is CRC scrambled using C-RNTI, CS-RNTI, or MCS-C-RNTI and then transmitted.

[0103] DCI format 1_1 is used for scheduling PDSCH in one cell. Information included in DCI format 1_1 is CRC scrambled using C-RNTI, CS-RNTI, or MCS-C-RNTI and then transmitted.

[0104] DCI format 1_2 is used for scheduling PDSCH in one cell. Information included in DCI format 1_2 is CRC scrambled using C-RNTI, CS-RNTI, or MCS-C-RNTI and then transmitted.

[0105] Multi-TRP related operations

[0106] The Coordinated Multipoint (CoMP) technique is a method of effectively controlling interference by having multiple base stations mutually exchange (e.g., using the X2 interface) or utilize channel information (e.g., RI / CQI / PMI / LI (layer indicator)) fed back from terminals and then transmit coordinated data to the terminal. Depending on the method used, CoMP can be categorized into joint transmission (JT), coordinated scheduling (CS), coordinated beamforming (CB), dynamic point selection (DPS), dynamic point blocking (DPB), etc.

[0107] The M-TRP transmission method, in which M TRPs transmit data to one terminal, can be broadly divided into i) eMBB M-TRP transmission, which is a method for increasing the transmission rate, and ii) URLLC M-TRP transmission, which is a method for increasing the reception success rate and reducing latency.

[0108] In terms of DCI transmission, the M-TRP transmission method can be divided into i) M-DCI (multiple DCI)-based M-TRP transmission in which each TRP transmits different DCI, and ii) S-DCI (single DCI)-based M-TRP transmission in which one TRP transmits DCI. For example, in the case of S-DCI-based M-TRP transmission, all scheduling information for data transmitted by the M TRP needs to be transmitted to the UE in one DCI, and it can be used in an ideal backhaul (ideal BH) environment in which dynamic coordination between both TRPs is possible.

[0109] For TDM-based URLLC M-TRP transmission, schemes 3 and 4 are currently under standardization discussion. Specifically, scheme 4 refers to a scheme in which one TRP transmits a transmission block (TB) in one slot, which has the effect of increasing the probability of data reception by using the same TB received from multiple TRPs in multiple slots. In contrast, scheme 3 refers to a scheme in which one TRP transmits a TB in several consecutive OFDM symbols (i.e., symbol groups), and multiple TRPs in one slot may be configured to transmit the same TB in different symbol groups.

[0110] In addition, the UE can recognize PUSCHs (or PUCCHs) scheduled by DCIs received in different control resource sets (CORESETs) (or CORESETs belonging to different CORESET groups) as PUSCHs (or PUCCHs) transmitted in different TRPs or as PDSCHs (or PDCCHs) in different TRPs. In addition, the schemes for UL transmissions (e.g., PUSCHs / PUCCHs) transmitted in different TRPs, which will be described later, can also be applied to UL transmissions (e.g., PUSCHs / PUCCHs) transmitted in different panels belonging to the same TRP.

[0111] Hereinafter, multiple DCI-based non-coherent JT (NCJT) / single DCI-based NCJT will be described.

[0112] NCJT (Non-coherent joint transmission) is a method in which multiple TPs (Transmission Points) transmit data to one terminal using the same time-frequency resource, and transmits data using different layers (i.e., different DMRS ports) using different DMRS (Demodulation Multiplexing Reference Signal) ports between the TPs.

[0113] The TP transmits data scheduling information to the UE receiving the NCJT via DCI. A scheme in which each TP participating in the NCJT transmits scheduling information for its own transmission data via DCI is called 'multi-DCI-based NCJT'. Since N TPs participating in NCJT transmission each transmit DL grant DCI and PDSCH to the UE, the UE receives N DCIs and N PDSCHs from the N TPs. In contrast, a scheme in which one representative TP transmits scheduling information for its own transmission data and data transmitted by other TPs (i.e., TPs participating in the NCJT) via a single DCI is called 'single DCI-based NCJT'. In this case, N TPs transmit one PDSCH, but each TP transmits only some of the multiple layers that make up one PDSCH. For example, if four-layer data is being transmitted, TP1 can transmit two layers and TP2 can transmit the remaining two layers to the UE.

[0114] The multiplexed TRP (MTRP) that transmits the NCJT can transmit DL data to the terminal using one of the following two methods.

[0115] First, we will explain the 'single DCI based MTRP' scheme. In MTRP, a common PDSCH is jointly transmitted in a coordinated manner, and each TRP participating in the coordinated transmission spatially divides the PDSCH and transmits it in different layers (i.e., different DMRS ports) using the same time-frequency resource. In this case, scheduling information for the PDSCH is indicated to the UE by a single DCI, which indicates which DMRS (group) port uses which QCL RS and QCL type information (this differs from the existing DCI, which indicates the QCL RS and type commonly applied to all DMRS ports). That is, M TCI states are indicated in a Transmission Configuration Indicator (TCI) field in the DCI (e.g., M=2 in the case of two-TRP coordinated transmission), and the QCL RS and type may be indicated using different M TCI states for each of the M DMRS port groups. DMRS port information may also be indicated by a new DMRS table.

[0116] Next, a 'multiple DCI based MTRP' scheme will be described. MTRP transmits different DCIs and PDSCHs, and these PDSCHs are transmitted while overlapping (partially or completely) with each other on frequency-time resources. These PDSCHs may be scrambled with different scrambling identifiers, and the DCIs may be transmitted by Coresets belonging to different Coreset groups. (Here, Coreset groups may be identified by an index defined in the Coreset configuration of each Coreset. For example, if index=0 is set for Coresets 1 and 2 and index=1 is set for Coresets 3 and 4, Coresets 1 and 2 belong to Coreset group 0, and Coresets 3 and 4 belong to Coreset group 1. Also, if no index is defined in a Coreset, it can be interpreted as index=0.) If multiple scrambling IDs are configured in one serving cell or two or more Coreset groups are configured, it can be seen that the UE receives data in a multiple DCI-based MTRP operation.

[0117] Alternatively, whether the MTRP scheme is single DCI-based or multiple DCI-based may be indicated to the UE by separate signaling. For example, multiple CRS (cell reference signal) patterns for MTRP operation for one serving cell may be indicated to the UE. In this case, PDSCH rate matching for CRS may vary depending on whether the MTRP scheme is single DCI-based or multiple DCI-based (since the CRS patterns are different).

[0118] Hereinafter, the CORESET group ID described / mentioned in this specification may refer to an index / identification information (e.g., ID) for distinguishing a CORESET for each TRP / panel. A CORESET group may be a group / union of CORESETs distinguished by an index / identification information (e.g., ID) for distinguishing a CORESET for each TRP / panel / the CORESET group ID. As an example, the CORESET group ID may be specific index information defined in the CORESET configuration. In this case, the CORESET group may be set / indicated / defined by an index defined in the CORESET configuration for each CORESET. And / or, the CORESET group ID may refer to an index / identification information / indicator for distinguishing / identifying CORESETs set in / associated with each TRP / panel. Hereinafter, the CORESET group ID described / mentioned in this disclosure may be expressed as a specific index / specific identification information / specific indicator for distinguishing / identifying CORESETs set in / associated with each TRP / panel. The CORESET group ID, i.e., a specific index / specific identification information / specific indicator for distinguishing / identifying between CORESETs set to / associated with each TRP / panel, may be set / instructed to the UE by higher layer signaling (e.g., RRC signaling), Layer 2 signaling (L2 signaling, e.g., MAC-CE), Layer 1 signaling (L1 signaling, e.g., DCI), etc. For example, it may be set / instructed to perform PDCCH detection for each TRP / panel (i.e., for each TRP / panel belonging to the same CORESET group) in units of the CORESET group.And / or, it may be configured / instructed that uplink control information (e.g., CSI, HARQ-A / N (ACK / NACK), SR (scheduling request)) and / or uplink physical channel resources (e.g., PUCCH / PRACH / SRS resources) are separately managed / controlled for each TRP / panel (i.e., for each TRP / panel belonging to the same CORESET group) in the CORESET group unit. And / or, HARQ A / N (process / retransmission) for PDSCH / PUSCH, etc. scheduled for each TRP / panel (i.e., for each TRP / panel belonging to the same CORESET group) may be managed.

[0119] Below, we will explain the partially overlapped NCJP.

[0120] Furthermore, NCJT can be classified into fully overlapped NCJT, in which the time-frequency resources transmitted by each TP completely overlap, and partially overlapped NCJT, in which only some of the time-frequency resources overlap. That is, in the case of partially overlapped NCJT, both TP1 and TP2 data are transmitted in some time-frequency resources, and only one of the TP data (TP1 or TP2) is transmitted in the remaining time-frequency resources.

[0121] A method for improving reliability in multi-TRP will be described below.

[0122] The following two methods can be considered as transmission and reception methods for improving reliability using transmission with multiple TRPs.

[0123] FIG. 7 illustrates a multiple TRP transmission scheme in a wireless communication system to which the present disclosure is applicable.

[0124] 7A shows a case where layer groups transmitting the same codeword (CW) / transport block (TB) correspond to different TRPs. In this case, a layer group may refer to a predetermined layer set consisting of one or more layers. In this case, the number of layers increases the amount of transmission resources, which has the advantage of allowing robust channel coding with a low code rate to be used for the TB. In addition, since the channels are different from each other across multiple TRPs, it is possible to expect improved reliability of the received signal based on diversity gain.

[0125] FIG. 7(b) shows an example in which different CWs are transmitted in layer groups corresponding to different TRPs. In this case, it can be assumed that the TBs corresponding to CW #1 and CW #2 in the figure are identical. That is, CW #1 and CW #2 mean that the same TB is converted into different CWs by channel coding, etc., according to different TRPs. Therefore, it can be considered an example of repeated transmission of the same TB. Compared to FIG. 7(a), FIG. 7(b) may have a disadvantage in that the code rate corresponding to the TB is higher. However, it has an advantage in that the code rate can be adjusted by specifying different redundancy version (RV) values ​​for encoded bits generated from the same TB according to the channel environment, or the modulation order of each CW can be adjusted.

[0126] According to the schemes illustrated in Figures 7(a) and 7(b), the same TB is repeatedly transmitted in different layer groups, and each layer group is transmitted by a different TRP / panel, thereby increasing the probability of data reception by the terminal. This is called an SDM (Spatial Division Multiplexing)-based M-TRP URLLC transmission scheme. Layers belonging to different layer groups are transmitted by DMRS ports belonging to different DMRS CDM groups.

[0127] Furthermore, although the above-mentioned content related to multiple TRPs has been described based on the SDM (spatial division multiplexing) scheme using different layers, it goes without saying that this may also be extended and applied to the FDM (frequency division multiplexing) scheme based on different frequency domain resources (e.g., RB / PRB (set), etc.) and / or the TDM (time division multiplexing) scheme based on different time domain resources (e.g., slots, symbols, sub-symbols, etc.).

[0128] In relation to the method for multiple TRP-based URLLC scheduled by a single DCI, the following method is discussed.

[0129] 1) Scheme 1 (SDM): Time and frequency resource allocation overlap, and n (n <= Ns) TCI states are allocated within a single slot.

[0130] 1-a) Method 1a

[0131] - At each transmission occasion, the same TB is transmitted on one layer or set of layers, and each layer or set of layers is associated with one TCI and one set of DMRS ports.

[0132] A single codeword with one RV is used for all spatial layers or a set of all layers. From the UE's perspective, different coded bits are mapped to different layers or sets of layers according to the same mapping rule.

[0133] 1-b) Method 1b

[0134] - At each transmission occasion, the same TB is transmitted on one layer or set of layers, and each layer or set of layers is associated with one TCI and one set of DMRS ports.

[0135] A single codeword with one RV is used for each spatial layer or set of layers, and the RVs corresponding to each spatial layer or set of layers may be the same or different.

[0136] 1-c) Method 1c

[0137] - At one transmission occasion, the same TB having one DMRS port associated with multiple TCI state indices is transmitted on one layer, or the same TB having multiple DMRS ports associated one-to-one with multiple TCI state indices is transmitted on one layer.

[0138] In the previous methods 1a and 1c, the same MCS is applied to all layers or to all sets of layers.

[0139] 2) Method 2 (FDM): Frequency resource allocation does not overlap, and n (n <= Nf) TCI states are allocated within a single slot.

[0140] - Each non-overlapping frequency resource allocation is associated with one TCI state.

[0141] The same single / multiple DMRS ports are associated with all non-overlapping frequency resource allocations.

[0142] 2-a) Method 2a

[0143] - A single codeword with one RV is used for all resource allocations. From the UE perspective, a common RB matching (mapping of codewords to layers) is applied across all resource allocations.

[0144] 2-b) Method 2b

[0145] A single codeword with one RV is used for each non-overlapping frequency resource allocation, and the RVs corresponding to each non-overlapping frequency resource allocation may be the same or different.

[0146] As with the previous method 2a, the same MCS is applied to all non-overlapping frequency resource allocations.

[0147] 3) Method 3 (TDM): Time resource allocation does not overlap, and n (n <= Nt1) TCI states are allocated within a single slot.

[0148] Each transmission occasion of the TB has a time granularity of a minislot and has one TCI and one RV.

[0149] A common MCS is used for a single or multiple DMRS ports at all transmission occasions within a slot.

[0150] - RV / TCI may be the same or different at different transmission occasions.

[0151] 4) Method 4 (TDM): n (n <= Nt2) TCI states in K (n <= K) different slots

[0152] Each transmission occasion of the TB has one TCI and one RV.

[0153] All transmission occasions over K slots use a common MCS for single or multiple DMRS ports.

[0154] - RV / TCI may be the same or different at different transmission occasions.

[0155] Basic beam failure recovery (BFR) A UE and / or a base station may perform uplink / downlink beam management (BM) for data transmission and reception, where BM may refer to the process of acquiring and maintaining a set of beams available for downlink and uplink transmission / reception.

[0156] Specifically, the BM can include a beam measurement process that measures the characteristics of a beamformed signal received from a base station or a terminal, a beam determination process in which the base station or terminal determines its own transmit beam (Tx beam) and receive beam (Rx beam), a beam sweeping process that covers a spatial region using a transmit beam and / or receive beam in a predetermined manner for a certain time interval, and a beam reporting process in which the terminal reports beam signal information to the base station based on the beam measurement results.

[0157] During the above-mentioned uplink / downlink BM procedure, a beam mismatch problem may occur due to various factors. For example, when a terminal moves or rotates, or when the wireless channel environment changes due to the movement of surrounding objects (e.g., when a line-of-sight (LoS) environment changes to a non-LoS environment due to beam blocking), the optimal uplink / downlink beam pair may change. In this case, if the terminal or base station fails to track the changed optimal uplink / downlink beam pair (i.e., BM tracking), it can be considered that a beam failure has occurred.

[0158] A terminal can determine whether a beam failure has occurred based on the reception quality of a downlink reference signal (RS). The terminal must then report a report message regarding whether a beam failure has occurred or a message for a beam recovery request (beam failure recovery request message, BFRQ message) to the base station. The base station that receives the message can perform a beam recovery process through various processes, such as transmitting a beam RS or requesting a beam report, for beam recovery. This series of beam recovery processes is called a beam failure recovery (BFR) process.

[0159] The basic BFR operation includes a BFR process for a special cell (SpCell) (i.e., a primary cell (PCell) or a primary secondary cell (PScell)) where a contention-based PRACH resource exists. The BFR process includes a beam failure detection (BFD) process, a BFRQ transmission process, and a process of monitoring the base station's response to the BFRQ, and each process may be performed in a serving cell.

[0160] Beam failure detection (BFD)

[0161] When the quality values ​​(Q_out) of all PDCCH beams fall below a predefined value, it can be considered that one beam failure instance has occurred. Here, the quality value may be determined based on a hypothetical block error rate (BLER). That is, the theoretical BLER may refer to the probability of failing to demodulate control information when the control information is transmitted on a specific PDCCH.

[0162] In addition, one or more search spaces for monitoring the PDCCH may be configured in the UE, and different PDCCH beams may be configured for each search space. In this case, the quality values ​​of all PDCCH beams falling below a predefined value means that the quality values ​​of all PDCCH beams are lower than a BLER threshold.

[0163] The following two methods can be supported as a method for the BFD-RS to be instructed / configured by the base station so that the terminal can determine whether a beam failure instance has occurred.

[0164] As a first scheme, an implicit configuration scheme of BFD-RS may be supported. A control resource set (CORESET) ID, which is a resource region in which PDCCH transmission is possible, is configured in each search space, and for each CORESET ID, RS information (e.g., CSI-RS resource ID, SSB ID) that is QCL'd in terms of spatial reception (spatial RX) parameters may be indicated / configured. The RS that is QCL'd in terms of spatial reception parameters may be indicated or configured by transmit configuration information (TCI). That is, BFD-RS may be implicitly configured / instructed to a terminal based on the QCL information indicated or configured by the TCI.

[0165] Here, when the base station indicates or configures an RS that is QCLed in terms of spatial reception parameters (i.e., a QCL Type D RS) to a terminal, the terminal can use the beam used to receive the RS that is QCLed in terms of spatial reception parameters when receiving a specific PDCCH DMRS. That is, signals may be transmitted between antenna ports that are spatially QCLed through the same transmission beam or similar transmission beams (e.g., with the same / similar beam directions and different beam widths).

[0166] As a second method, an explicit configuration method of BFD-RS may be supported. The base station can explicitly configure or instruct the terminal to use BFD beam RS. In this case, the beam RS may correspond to the 'all PDCCH beams'.

[0167] The UE physical layer can notify the MAC sublayer that a beam failure instance (BFI) has occurred whenever an event occurs in which the theoretical BLER measured based on the configured (or instructed) BFD-RS deteriorates to a specific threshold or more. If a BFI occurs a certain number of times (e.g., 'beamFailureInstanceMaxCount') within a certain time period (e.g., 'BFD timer'), the UE MAC sublayer can determine that a beam failure has occurred and initiate the associated RACH operation.

[0168] The following describes the operation of the MAC layer in relation to BFD.

[0169] A MAC entity:

[0170] 1> If a beam failure instance indication is received at lower layers:

[0171] 2> Start or restart the beamFailureDetectionTimer

[0172] 2> Increase BFI_COUNTER by 1

[0173] 2> If BFI_COUNTER>=beamFailureInstanceMaxCount:

[0174] 3> Initiate random access procedure in SpCell

[0175] 1> beamFailureDetectionTimer expires; or

[0176] 1> When beamFailureDetectionTimer, beamFailureInstanceMaxCount, or any of the reference signals used for beam failure detection are reset by higher layers:

[0177] 2> Set BFI_COUNTER to 0

[0178] 1> If the random access procedure is completed successfully:

[0179] 2> Set BFI_COUNTER to 0

[0180] 2> Abort the (configured) beamFailureRecoveryTimer

[0181] 2> The beam failure recovery procedure is considered to have been successfully completed.

[0182] BFRQ (PRACH based): new beam identification and PRACH transmission

[0183] As described above, when a certain number of BFIs or more occur, the terminal determines that a beam failure has occurred and can perform a beam failure recovery operation. As an example of the beam failure recovery operation, the terminal can perform a BFRQ process based on a RACH (i.e., a PRACH). The BFRQ process will be described in detail below.

[0184] The base station can configure a candidate beam RS list ('candidateBeamRSList') including candidate beam RSs that can be substituted in the event of a beam failure, to the terminal through RRC signaling. The base station can then configure dedicated PRACH resources for the candidate beam RSs. In this case, the dedicated PRACH resources may be non-contention based PRACH resources (or contention-free PRACH resources). If no substituted beam RS is found from the candidate beam RS list, the terminal can select at least one from the pre-configured SSB resources. The terminal can then transmit a contention-based PRACH to the base station based on the selected at least one. A specific procedure for transmitting the contention-based PRACH is as follows.

[0185] The terminal may search for a beam RS having a quality value (Q_in) equal to or greater than a predefined value among a plurality of beam RSs included in a candidate beam RS list configured by the base station (step 1). Here, the quality value of the beam RS may be determined based on RSRP (reference signal received power).

[0186] The candidate beam RS list configured by the base station for the terminal may consist entirely of SSBs, entirely of CSI-RS resources, or a combination of SSBs and CSI-RS resources.

[0187] If the quality value of one of the beam RSs included in the candidate beam RS list exceeds a threshold (i.e., a predefined value), the terminal can select the beam RS. If the quality values ​​of multiple beam RSs in the candidate beam RS list exceed a threshold, the terminal can select any one of the multiple beam RSs.

[0188] If there is no beam RS among the multiple beam RSs included in the candidate beam RS list whose quality value exceeds the threshold, the terminal may perform the operation according to step 2 described below.

[0189] The terminal can search for a beam RS from the SSB (concatenated with contention-based PRACH resources) that has a quality value (Q_in) greater than or equal to a predefined value (Step 2).

[0190] If the quality value of one of the SSBs exceeds a threshold, the terminal can select the SSB, and if the quality values ​​of multiple SSBs exceed a threshold, the terminal can select any one of the multiple SSBs.

[0191] If there is no SSB whose quality value exceeds the threshold value among the SSBs, the terminal may perform an operation according to step 3 described below.

[0192] The terminal can select any SSB from the SSBs (associated with contention-based PRACH resources) (step 3).

[0193] The terminal can then transmit to the base station a PRACH resource and a preamble configured to be directly or indirectly linked to the beam RS (CSI-RS or SSB) selected in the above-mentioned step (step 1 or step 2).

[0194] For example, when a contention-free PRACH resource and preamble are configured for a beam RS in a candidate beam RS list for BFR, or when a contention-based PRACH resource and preamble are configured for a universally configured SSB such as random access, the terminal can transmit the PRACH resource and preamble configured to be directly linked to the selected beam RS to the base station.

[0195] As another example, if a non-conflicting PRACH resource and a preamble are not configured for a CSI-RS in a candidate beam RS list for BFR, the UE may transmit to the base station a PRACH resource and a preamble configured to be indirectly linked to the selected beam RS. Specifically, the UE may select a non-conflicting PRACH resource and a preamble linked to an SSB indicated as receivable in a receiving beam corresponding to the CSI-RS (i.e., QCL-qualified for spatial reception parameters) and transmit the PRACH resource and a preamble to the base station.

[0196] Monitoring of gNB's response to the BFRQ

[0197] The terminal may monitor the base station's response to the PRACH and preamble transmissions.

[0198] If the UE transmits a contention-free PRACH resource and preamble to the base station, the base station can transmit a response to the UE via a PDCCH masked with the C-RNTI. The UE receives the response in a search space configured (by RRC signaling) for BFR use. In this case, the search space is configured to a specific CORESET for BFR use.

[0199] Then, when the terminal transmits a contention-based PRACH and a preamble to the base station, the base station can transmit a response to the terminal by reusing the CORESET (e.g., CORESET0 or CORESET1) and search space configured for the random access procedure based on the contention-based PRACH.

[0200] If there is no response from the base station for a certain period of time (i.e., the base station response is not monitored for a certain period of time), the terminal performs a new candidate beam identification and selection process and repeats the process of monitoring the BFRQ and base station response.

[0201] The above-described new candidate beam identification and selection process may be performed until the PRACH transmission is performed a preset maximum number of times N_max or until a preset timer (BFR timer) expires. When the timer expires, the UE can either stop contention-free PRACH transmission or perform contention-based PRACH transmission using SSB selection until N_max is reached.

[0202] Improved beam failure recovery

[0203] When carrier aggregation (CA) is applied, a specific SCell may not have an uplink carrier (UL carrier). That is, uplink transmission is not possible in an SCell that has only a downlink carrier. Furthermore, even if an SCell has an uplink carrier, a collision-based PRACH may not be configured. Therefore, the PRACH-based BFR procedure in which CA is applied may only be applied to an SpCell (PCell or PSCell), and the BFR procedure may not be supported in an SCell. Therefore, according to the basic BFR operation, the PRACH-based BFR operation in an SpCell may not be supported in an SCell.

[0204] Specifically, when a high frequency band requiring BFR is configured as an SCell, the PRACH-based BFR procedure may not be supported in the high frequency band. For example, when a PCell is operated in a low frequency band (e.g., 6 GHz or less) and an SCell is operated in a high frequency band (e.g., 30 GHz), a problem occurs in that the PRACH-based BFR procedure is not supported in the high frequency band that more strongly requires BFR support.

[0205] To solve the above-mentioned problems, the improved BFR operation includes an operation for BFR of the SCell. For example, the UE can perform BFRQ for the SCell using a dedicated PUCCH resource for BFRQ configured for the SpCell. Hereinafter, for convenience of explanation, the 'dedicated PUCCH resource' will be referred to as BFR-PUCCH.

[0206] The role of the BFR-PRACH introduced in basic BFR is to report both 'beam failure (BF) occurrence information and new candidate beam RS (set) information' to the base station. On the other hand, the BFR-PUCCH serves to report only 'BF occurrence information for SCells' to the base station. Then, detailed information related to the occurred BF may be transmitted to the base station via the BFR MAC-CE or UCI as a subsequent report.

[0207] Here, the detailed information transmitted as the subsequent report may include information regarding the SCell in which the BF occurs (e.g., CC (component carrier) index information), whether or not a new candidate beam exists for the SCell in which the BF occurs, and if a new candidate beam exists, the beam RS ID.

[0208] The BFR-PUCCH may use the same PUCCH format as a scheduling request (SR) and may be defined by the ID of a specific SR for BFR. If a UL-SCH allocated by the base station exists when the terminal detects a BFR for an SCell, the terminal may omit the BFR-PUCCH transmission procedure, as in the SR transmission procedure, and may immediately transmit a BFR MAC-CE to the base station via the allocated UL-SCH.

[0209] A method for performing TRP-specific BFR in an MTRP environment

[0210] When a PRACH-based BFR operation is performed in a multiple DCI-based NCJT environment in an MTRP environment, if BF occurs in all CORESETs belonging to a specific TRP, but there are CORESETs belonging to other TRPs in which BF does not occur, the UE may determine that the current situation is not a BF situation.

[0211] In this case, if the TRP in which BF occurs in all CORESETs is a TRP (e.g., a primary TRP) responsible for transmitting important control information (e.g., SIB, RA, paging information, etc.), a problem may occur in which the terminal cannot receive the important control information even if no beam failure occurs in a specific beam of another TRP (e.g., a secondary TRP).

[0212] To solve the above problem, a method of performing BFR only for a specific TRP may be applied. The operation of performing BFR only for a specific TRP may include a TRP-specific BFD operation, a TRP-specific BFRQ operation, an operation of receiving a response to the BFRQ from the base station, a BFR MAC-CE transmission operation, an operation of receiving a response to the BFR MAC-CE from the base station, and an operation of resetting the beam of the specific TRP to a new candidate beam.

[0213] First, a terminal can perform BFD operations only for a specific TRP (i.e., TRP-specific BFD operations).

[0214] The UE can perform BFD for a CORESET group (or a BFD RS set) associated with a specific TRP that transmits important information along with system information. In this case, the CORESET group (or a BFD RS set) associated with the specific TRP may be a previously configured CORESET group (e.g., a CORESET group whose CORESET group ID is 0) or a CORESET group (or a BFD RS set) that the base station separately configures to perform BFD.

[0215] Specifically, the base station can implicitly configure the BFD RS to the terminal. That is, if the base station does not explicitly configure the BFD RS, the terminal can perform BFD only on the QCL RS (type D) indicated by the TCI state corresponding to the CORESET group associated with a specific TRP.

[0216] Additionally or alternatively, the base station may explicitly configure one or more CORESET groups (or BFD RS sets) associated with a specific TRP for which BFD is to be performed in the terminal. The terminal may perform BFD in units of one or more configured CORESET groups (or BFD RS sets).

[0217] When detecting that a BF has occurred from a specific TRP (or one of the CORESET groups associated with a specific TRP), the terminal can transmit a TRP-specific BFRQ to the base station.

[0218] Specifically, the base station can configure a BFRQ resource (e.g., a scheduling request (SR) PUCCH resource) for the terminal. That is, when a BF occurs in a specific TRP, the terminal can transmit the configured BFRQ (e.g., an SR PUCCH) to the base station. In this case, the terminal can transmit a BFRQ to a TRP in which no BF occurs. When transmitting a BFRQ, the terminal can explicitly or implicitly report to the base station which BFD RS set (or CORESET group) the BFRQ is associated with.

[0219] The base station may configure separate BFRQ resources for each TRP, but is not limited thereto, and multiple TRPs may be configured to share one BFRQ resource. For example, when BFR is performed for an SCell, each TRP may share a BFRQ resource based on multiple spatial relation parameters.

[0220] The terminal may receive a response to the BFRQ from the base station. Specifically, the terminal may receive a response to the BFRQ including an uplink grant DCI from the base station that has received the BFRQ.

[0221] Then, the terminal can transmit the BFR MAC-CE to the base station. Specifically, the terminal can transmit the BFR MAC-CE to the base station via a PUSCH scheduled by the received uplink grant DCI. At this time, the BFR MAC-CE may include an ID of a component carrier (CC) on which the BF occurs, information on whether a new candidate beam has been searched for from the CC, an ID of the searched new candidate beam, and TRP ID information on which the BF occurs (e.g., a CORESET group ID or a BFD RS set ID, etc.).

[0222] The terminal may receive a response to the BFR MAC-CE from the base station. Specifically, the response to the BFR MAC-CE may be a DCI indicating that the BFR MAC-CE has been successfully received. In this case, the DCI is a DCI transmitted by the base station when the base station successfully decodes a PUSCH, and may include at least one of a HARQ process ID, a new data indicator (NDI), a redundancy version (RV), and a CGG transmission information (CBGTI).

[0223] The UE may reset a new candidate beam RS as a beam associated with a TRP in which the BFR occurred. Specifically, after a certain time (e.g., 28 symbols) has elapsed since receiving DCI from the base station indicating successful reception of the BFR MAC-CE, the UE may reset a beam (e.g., a PDCCH beam) associated with the TRP that transmitted the DCI or the TRP that reported new candidate beam information in the BFR MAC-CE as the new candidate beam RS.

[0224] BFR behavior when BFR occurs on a specific TRP or all TRPs

[0225] The improved BFR operation as described above includes a BFR operation for one or more CC / BWPs. While the BFR operation for one or more CC / BWPs is being performed, the BFR MAC-CE transmitted by the UE to the base station may include information indicating whether the BFR operation is a BFR operation for an SpCell (i.e., a PCell or a PSCell) (e.g., a BFR operation based on a collision-based RACH for an SpCell) or a BFR operation for an SCell, a CC / BWP list in which BF occurred (beam failed CC / BWP list), information on whether a new candidate beam RS has been found from each CC / BWP in which BF occurred, and, if a new candidate beam RS has been found from the CC / BWP, an RS ID of the found new candidate beam RS.

[0226] Here, if the size of the UL-SCH allocated to the terminal is insufficient to transmit the BFR MAC-CE, the terminal may transmit a BFR MAC-CE with some information omitted (i.e., a truncated BFR MAC-CE) to the base station. For example, the truncated BFR MAC-CE may omit information on whether a new candidate beam RS has been found from the CC / BWP list in which the BFR occurred, but is not limited thereto, and the type of omitted information may be set differently.

[0227] Additionally or alternatively, as described above, the UE may perform a BFR operation for each TRP (i.e., a TRP-specific BFR operation). The present disclosure includes an example of a BFR scheme applicable to both a case where a BF occurs for a specific TRP (e.g., a specific CORESET group or a specific BFD RS group) in a specific frequency band (e.g., CC / BWP) (hereinafter, 'event 1 occurs') and a case where a BF occurs for all TRPs (hereinafter, 'event 2 occurs'). Here, event 2 can be considered a BF event defined in existing UE operation (e.g., Rel-15 / 16) in that a BF occurs for the CC / BWP (i.e., a BF occurs for all TRPs in the CC / BWP).

[0228] Example 1

[0229] When event 1 or event 2 occurs, the terminal can use the BFRQ resource commonly configured for event 1 and event 2. Then, the terminal can report information regarding whether event 1 and / or event 2 has occurred to the base station.

[0230] Here, the BFRQ resource configured commonly for event 1 and event 2 may be a resource used for BFR for one or more CC / BWPs. For example, the BFRQ resource may include a PUCCH resource configured for BFRQ (i.e., a BFRQ-PUCCH resource). In this case, the BFRQ-PUCCH resource may use the same PUCCH format as a scheduling request (SR) included in uplink control information (UCI), and an SR ID for BFRQ may be configured.

[0231] By using the BFRQ resource set in common for event 1 and event 2, the terminal can reduce the overhead of reserved uplink resources.

[0232] Here, Event 1 may be divided into sub-events according to the index of the TRP (e.g., CORESET group or BFD RS group) where the BF occurred. For example, Event 1 may be divided into Event 1-1, where a BF occurs for TRP1, and Event 1-2, where a BF occurs for TRP2. That is, information regarding whether Event 1 occurred may be reported by dividing it into sub-events according to the BF occurrence for each TRP.

[0233] And, information about whether or not event 2 has occurred may be omitted based on the information configuration about whether or not event 1 has occurred. For example, when BF occurs in both two TRPs, the terminal may omit information about whether or not event 2 has occurred by reporting information that event 1-1 and event 1-2 have occurred.

[0234] Additionally or alternatively, the information regarding the occurrence of event 1 and / or event 2 may include an indicator indicating that both event 1 and event 2 have occurred when event 1 occurs for a specific CC / BWP and event 2 occurs for another specific CC / BWP.

[0235] For example, if the indicator is included in the information regarding whether event 1 or / and event 2 occurred, the terminal may separately report to the base station at least one of information regarding the CC / BWP in which event 1 and event 2 occurred, information regarding whether a new candidate beam RS was found from the CC / BWP in which BF occurred, or information regarding the new candidate beam RS ID.

[0236] Information regarding whether Event 1 and / or Event 2 has occurred may be included in a predefined BFR MAC-CE and reported. That is, the terminal can include information regarding whether Event 1 and / or Event 2 has occurred in a MAC-CE for BFR and report it to the base station.

[0237] Additionally or alternatively, separate MAC-CEs may be defined for Event 1 (or a sub-event due to Event 1) and Event 2. Thus, when a specific event occurs, the terminal can report to the base station a MAC-CE corresponding to the specific event that occurred (i.e., a MAC-CE defined for the specific event). The base station can then determine which event occurred from the format / header of the reported MAC-CE.

[0238] For example, when event 2 occurs, the terminal can report a predefined BFR MAC-CE to the base station, or can report a MAC-CE defined separately for event 2 to the base station.

[0239] Furthermore, when a MAC-CE is defined separately for each event, the TRP that reports the MAC-CE for a specific event may be limited (or configured) separately. For example, when a MAC-CE is reported to a TRP in which a BF occurs, there is a high probability that the TRP cannot decode the MAC-CE. Therefore, the UE may be limited (or configured) to report the MAC-CE only to a TRP in which a BF does not occur.

[0240] The (TRP-specific) MAC-CE generation / triggering method may be changed so that the TRPs to which the UE reports the (TRP-specific) MAC-CE are limited (configured).

[0241] For example, a (TRP-specific) BFR MAC-CE may be generated / triggered only if a UL-SCH for a non-occurring TRP of the BF is present (ie, available).

[0242] As yet another example, a (TRP-specific) BFR MAC-CE may be generated / triggered when a scheduling DCI / grant is received from a TRP (e.g., a CORESET group, etc.) where the BF does not occur (i.e., when the BF is implicitly detected), or when a PDCCH / PDSCH TCI is included in a DL RS on a TRP where the BF does not occur (i.e., when the BF is explicitly detected).

[0243] When reporting information regarding the occurrence of event 1 and / or event 2 to the base station, the terminal can define the occurrence of each event as an individual state (i.e., BF state).The terminal can then report to the base station the BF state corresponding to each CC / BWP in which BF has occurred among CCs / BWPs (which perform BFR using the same BFRQ resource).

[0244] Here, the bit width of the BF status may vary depending on the number of TRPs. For example, if the number of TRPs is 3, the BF status may be configured with 2 bits as shown in Table 6 below. In Table 6, the occurrence of BF in TRP #X may mean that BF has occurred in CORESET group #x or BFD RS group #x.

[0245] [Table 6]

[0246] As another example, the terminal may indicate whether each event occurs using a BF bitmap instead of the BF status. Specifically, the terminal may map a value indicating whether a BF occurs to each bit of the BF bitmap in the order of the TRP IDs of a specific CC / BWP. For example, if a bit corresponding to TRP #1 in the BF bitmap is 1, it means that a BF has occurred for TRP #1, and if the bit is 0, it means that a BF has not occurred for TRP #1. In addition, if a BF occurs for all TRPs (i.e., if event 2 occurs), it is sufficient to map 1 to all bits included in the BF bitmap, so there is no need for a separate divisor to indicate whether event 2 occurs.

[0247] Additionally or alternatively, the terminal can map a value indicating whether or not a BF has occurred to each bit of the BF bitmap in the order of the CORESET pool index value associated with the CORESET of a particular CC / BWP, and report the BF bitmap to the base station.

[0248] As described above, when reporting the BF status or BF bitmap for each CC / BWP (or, among CC / BWPs, the CC BWP in which the BF occurred), the BFR MAC-CE reported to the base station may include information on whether the BFR operation is a BFR operation for an SpCell or a BFR operation for an SCell, a list of CC / BWPs in which the BF occurred, the BF status or BF bitmap for the CC / BWP in which the BF occurred, information on whether a new candidate beam RS has been found from each CC / BWP in which the BF occurred, and, if a new candidate beam RS has been found from the CC / BWP, the RS ID of the found new candidate beam RS.

[0249] In this case, in relation to the CC / BWP list in which the BF has occurred, the terminal can report that a beam failure has occurred for the CC / BWP in which event 1 has occurred as well as for the CC / BWP in which event 2 has occurred.

[0250] Additionally or alternatively, the BF status and BF bitmap may not be reported for each CC / BWP, but may be information indicating whether or not a BF has occurred in all CC / BWPs reported by the terminal.

[0251] In this case, the BFR MAC-CE reported to the base station may include information on whether the BFR operation is for an SpCell or an SCell, a BF status or BF bitmap, a CC / BWP list in which the BF occurred, information on whether a new candidate beam RS has been searched for from each of the CC / BWPs in which the BF occurred, and, if a new candidate beam RS has been searched for from the CC / BWP, the RS ID of the new candidate beam RS found.

[0252] In this case, the list of CC / BWPs where the BF occurred can include only the list of CC / BWPs where the event reported in the BF status or BF bitmap occurred. For example, if the BF status or BF bitmap is used to report that a BF occurred for TRP #0, the list of CC / BWPs where the BF occurred can include only the list of CC / BWPs where a BF occurred for TRP #0.

[0253] Additionally or alternatively, the BF status or BF bitmap can be extended to report multiple BF statuses or BF bitmaps indicating whether or not a BF has occurred for each CC / BWP. For example, the BF status can be extended to include a status indicating that event 1 has occurred in a particular CC / BWP and event 2 has occurred in another CC / BWP.

[0254] In this case, the BFR MAC-CE reported to the base station may include information on whether the BFR operation is for an SpCell or an SCell, a BF status or BF bitmap, a CC / BWP list in which the BF occurred, information on whether a new candidate beam RS has been searched for from each of the CC / BWPs in which the BF occurred, and, if a new candidate beam RS has been searched for from the CC / BWP, the ID of the new candidate beam RS found.

[0255] Here, the size of the BF status or BF bitmap may be variable, so a field indicating the size of the BF status or BF bitmap may be added to the BFR MAC-CE.

[0256] As yet another example, the size of the BF status or BF bitmap may be fixed according to the number of events that can occur / report, and in this case, when no event occurs (or no BF occurs), a field in the BFR MAC-CE indicating the BF status or BF bitmap may be set to include a predefined value indicating that no event occurs.

[0257] The CC / BWP list where the BF occurred may be determined according to the number of events reported by the BF status or BF bitmap information. For example, if a situation of 'BF occurred in TRP#0 and BF occurred in all TRPs' is reported using the BF status or BF bitmap, the CC / BWP list where the BF occurred may include a CC / BWP list where the BF occurred in TRP#0 and a CC / BWP list where the BF occurred in all TRPs.

[0258] Furthermore, the field size of the information regarding whether a new candidate beam RS was found from each CC / BWP in which the BF occurred, and the field size of the new candidate beam RS ID may be set to the number of CC / BWPs that occurred in one event, or may be set separately depending on the event that occurred.

[0259] For example, assume that CC#0 to CC#4 are configured by applying carrier aggregation (CA), BF for TRP#0 occurs in CC#0 and CC#3, and BF for all TRPs occurs in CC#1. Information on whether a new candidate beam RS has been found from each CC / BWP where the BF occurred and the new candidate beam RS ID may be configured in the order of CC#0, CC#1, and CC#3, or configured for each event. Here, configuring the information for each event may mean configuring and reporting information on CC#0 and CC#3 corresponding to event 1 (i.e., information on whether a new candidate beam RS has been found from CC#0 and CC#3 and the new candidate beam RS ID), and configuring and reporting information on CC#1 corresponding to event 2.

[0260] Example 1-1

[0261] The size of the CC / BWP list reported by the terminal may be set to the number of CC / BWPs in which an event can occur among all CC / BWPs performing BFD while sharing BFRQ resources.

[0262] When CA is applied, all CCs may be configured as either MTRPs or STRPs, but some CCs may be configured as MTRPs and the remaining CCs may be configured as STRPs. If a BF occurs for all TRPs configured as the latter (i.e., some CCs are configured as MTRPs and the remaining CCs are configured as STRPs), the BF occurrence on some CCs configured as STRPs may be considered as a BF occurring on a specific TRP (i.e., the occurrence of Event 1) or as a BF occurring on all TRPs (i.e., the occurrence of Event 2). In other words, the size of the CC / BWP list reported by the UE may vary depending on whether the BF occurrence on some CCs configured as STRPs is considered as a BF occurrence on a specific TRP or as a BF occurrence on all TRPs. Therefore, embodiment 1-1 includes a scheme in which the size of the entire CC / BWP list reported by the UE is set to the number of CCs / BWPs in which a specific event can occur.

[0263] Specifically, when a BF occurs in a specific TRP (e.g., a BFD RS set), the size of the CC / BWP list reported by the terminal may be determined as the number of CC / BWPs including the specific TRP ID (or BFD RS set ID) among all CCs / BWPs in which BFD is performed / configured while sharing BFRQ resources.

[0264] When BF occurs in all TRPs, the size of the CC / BWP list reported by the terminal may be determined as 1) the total number of CCs / BWPs in which BFD is performed / configured while sharing BFRQ resources, or 2) the number of CCs / BWPs among the total CCs / BWPs that include all BFD RS set IDs (i.e., include BFD RS sets commonly configured for each TRP).

[0265] The occurrence of a BF (event 1 occurrence) for a specific TRP in a CC / BWP configured for only a specific TRP (i.e., STRP) may be interpreted as the same as the occurrence of a BF (event 2 occurrence) for all TRPs in the CC / BWP. Therefore, the size of the CC / BWP list reported by the terminal may be determined depending on whether 'BF occurrence for all TRPs' is interpreted in a narrow sense (method 2) or a broad sense (method 1).

[0266] For example, it is assumed that, among CC#0 to CC#5, CC#0 to CC#4 are configured with a BFD RS set for TRP#0, and CC#3 to CC#5 are configured with a BFD RS set for TRP#1.

[0267] When the size of the CC list reported by the terminal is determined based on the total number of CCs for which BFD is performed / configured (i.e., in the case of method 1), the size of the CC list for event 2 may be configured as 6 (CC#0 to CC#5). When the size of the CC list reported by the terminal is determined as the number of CCs including all BFD RS set IDs among the total CCs (i.e., in the case of method 2), the size of the CC list for event 2 may be configured as 2 (CC#3 and CC#4).

[0268] When method 1) is applied, the CC size for Event 1 may be configured as 2 (CC#3 and CC#4). In this case, the occurrence of BF in CCs (CC#0, CC#1, CC#2, and CC#5) operating as STRPs can be interpreted as the occurrence of Event 2.

[0269] When method 2) is applied, the CC size for event 1 may be configured as 6 (CC#0 to CC#5). In this case, the BF report for the CC acting as a STRP can be interpreted as a TRP-specific BF report. For example, the CC list size for the BF of TRP#0 in event 1 may be 5 (CC#0 to CC#4), and the CC list size for the BF of TRP#1 in event 1 may include 3 (CC#3 to CC#5).

[0270] In Example 1 and Example 1-1, a case has been described in which the UE uses a BFRQ resource that is configured in common for Event 1 and Event 2. However, this is merely an example, and the UE may also use BFRQ resources (e.g., PUCCH resources / sequences) that are configured separately for Event 1 and Event 2. Even when the scheme of using BFRQ resources that are configured separately for Event 1 and Event 2 is applied, the above-described Example 1-1 may be applied in order to reduce the size of the CC / BWP list reported by the UE.

[0271] Example 2

[0272] The UE may use different BFRQ resources for Event 1 (or a subevent of Event 1) and Event 2. The size of the CC / BWP list for each BFRQ resource may be defined as the number of CCs / BWPs in which a specific event can occur among all CCs / BWPs in which BFD is performed / configured while sharing the BFRQ resource.

[0273] As described in Example 1-1, the size of the CC / BWP list reported using the BFRQ resources for event 2 may be determined as 1) the total number of CCs / BWPs for which BFD is performed / configured while sharing the BFRQ resources, or 2) the number of CCs / BWPs among the total CCs / BWPs that include all BFD RS set IDs (i.e., include BFD RS sets commonly configured for each TRP).

[0274] For example, it is assumed that, among CC#0 to CC#5, CC#0 to CC#4 are configured with a BFD RS set for TRP#0, and CC#3 to CC#5 are configured with a BFD RS set for TRP#1.

[0275] When the size of the CC list reported by the terminal is determined based on the total number of CCs for which BFD is performed / configured (i.e., in the case of method 1), the size of the CC list for event 2 may be configured as 6 (CC#0 to CC#5). When the size of the CC list reported by the terminal is determined as the number of CCs including all BFD RS set IDs among the total CCs (i.e., in the case of method 2), the size of the CC list for event 2 may be configured as 2 (CC#3 and CC#4).

[0276] When method 1) is applied, the CC size for Event 1 may be configured as 2 (CC#3 and CC#4). In this case, the occurrence of BF in CCs (CC#0, CC#1, CC#2, and CC#5) operating as STRPs can be interpreted as the occurrence of Event 2.

[0277] When method 2) is applied, the CC size for event 1 may be configured as 6 (CC#0 to CC#5). In this case, the BF report for the CC operating as a STRP can be interpreted as a TRP-specific BF report. For example, the size of the CC list for the BF of TRP#0 in event 1 is 5 (CC#0 to CC#4), and the size of the CC list for the BF of TRP#1 in event 1 can include 3 (CC#3 to CC#5).

[0278] Although the first and second embodiments have been described based on multiple TRPs, they may also be applied to transmissions via multiple panels. Furthermore, the first and second embodiments may be applied independently or in combination with the BFR operation described above.

[0279] FIG. 8 is a diagram for explaining a beam failure recovery operation of a terminal according to an embodiment of the present disclosure.

[0280] When a beam failure (BF) is detected from at least one resource group among a plurality of resource groups, the terminal may transmit a beam failure recovery request (BFRQ) to the base station (S810).

[0281] Here, the resource group may include at least one of a control resource set (CORESET) group or a beam failure detection (BFD) reference signal (RS) group. Each of the CORESET group or the BFD RS group may correspond to a TRP. For example, CORESET group 1 or BFD RS group 1 may correspond to TRP1, and CORESET group 2 or BFD RS group 2 may correspond to TRP2.

[0282] Here, the CORESET group may include one or more CORESETs, and a resource group may be configured based on a transmission configuration indicator (TCI) state configured for the one or more CORESETs. That is, a BFD RS for detecting beam failure may be implicitly configured based on a TCI state configured for the CORESET. Then, the UE can detect beam failure from at least one resource group using the configured BFD RS.

[0283] Transmitting a BFRQ to a base station may mean transmitting the BFRQ to the base station using a BFRQ resource. In this case, the BFRQ resource may be configured commonly in at least one frequency band (e.g., a component carrier (CC) or a bandwidth part). Specifically, based on detection of a beam failure from a specific resource group or multiple resource groups, the terminal may transmit a BFRQ to the base station using a BFRQ resource configured commonly for beam failures in the specific resource group and beam failures in multiple resource groups.

[0284] In yet another embodiment of the present disclosure, the BFRQ resources corresponding to the case where a beam failure is detected in a specific resource group and the case where a beam failure is detected in multiple resource groups may be different from each other. For example, a first BFRQ resource may be configured for a beam failure in a specific resource group, and a second BFRQ resource may be configured for a beam failure in multiple resource groups. Then, based on the occurrence of a beam failure in a specific resource group, the terminal may transmit a first BFRQ of the BFRQs to the base station using the first BFRQ resource of the BFRQ resources. Then, based on the occurrence of beam failures in multiple resource groups, the terminal may transmit a second BFRQ of the BFRQs to the base station using a second BFRQ resource of the BFRQ resources that is different from the first BFRQ resource.

[0285] Then, available uplink resources (e.g., UL-SCH resources, PUSCH resources, etc.) may be configured (or allocated) to the terminal. Based on the existence of available uplink resources, the terminal can transmit information related to beam failure to the base station using the available uplink resources without performing the operation of transmitting a BFRQ to the base station and the operation of receiving a response to the BFRQ from the base station. In other words, if available uplink resources have already been allocated to the terminal, the terminal can omit the operation of transmitting a BFRQ and the operation of receiving a response to the BFRQ and transmit information related to beam failure to the base station using the allocated available uplink resources.

[0286] The terminal may receive a response to the BFRQ from the base station (S820). The response to the BFRQ may include an uplink grant. The terminal may transmit a PUSCH scheduled by the DCI including the uplink grant to the base station.

[0287] The terminal may transmit information related to beam failure to the base station (S830). Here, the information related to beam failure may indicate a specific resource group in which beam failure is detected or multiple resource groups in which beam failure is detected. For example, the information related to beam failure may include information on whether beam failure is detected from a specific TRP or multiple TRPs including the specific TRP.

[0288] Then, whether a beam failure is detected from a specific TRP or from multiple TRPs may be defined by a separate BF state. The bit width of the BF state may vary depending on the number of TRPs. As yet another example, whether a beam failure is detected from a specific TRP or from multiple TRPs may be defined by a separate BF bitmap.

[0289] The information related to the beam failure may include at least one of the following: the type of cell in which the beam failure was detected, index information of at least one frequency band in which the beam failure was detected, information regarding whether a new candidate beam RS exists in the at least one frequency band in which the beam failure was detected, or information indicating the new candidate beam RS rule based on the existence of the candidate beam RS.

[0290] Here, the type of the cell in which the beam failure is detected may indicate whether the cell in which the beam failure is detected is an SpCell or an SCell, and the information on the new candidate beam RS may include ID information of the new candidate beam RS if a new candidate beam RS exists in at least one frequency band in which the beam failure is detected.

[0291] The size of at least one frequency band in which the beam failure is detected may be determined based on the size of the entire frequency band in which BFD is performed, or the size of a frequency band including IDs (identifications) of multiple resource groups among the entire frequency band in which BFD is performed, based on the detection of beam failure from multiple resource groups.

[0292] For example, among CC#0 to CC#5, CC#0 to CC#4 are configured with BFD RS sets for TRP#0, and CC#3 to CC#5 are configured with BFD RS sets for TRP#1, and it is assumed that beam failure occurs across the entire TRP.

[0293] When the size of the frequency band (e.g., CC or BWP) in which a beam failure is detected and reported by the terminal is determined based on the total number of CCs for which BFD is performed, the size of the CC in which a beam failure is detected may be configured as 6 (CC#0 to CC#5). When the size of the CC in which a beam failure is detected and reported by the terminal is determined as the number of CCs including multiple resource group IDs among the total CCs for which BFD is performed, the size of the CC in which a beam failure is detected may be configured as 2 (CC#3 and CC#4).

[0294] Additionally or alternatively, the information related to beam failure may indicate a specific resource group in which beam failure was detected or multiple resource groups in which beam failure was detected, for at least one frequency band in which beam failure was detected.

[0295] Specifically, the information related to the beam failure may indicate a specific resource group or multiple resource groups in which a beam failure is detected from a first frequency band among at least one frequency band, and may indicate a specific resource group or multiple resource groups in which a beam failure is detected from a second frequency band among at least one frequency band.

[0296] For example, assume that beam failures are detected from component carriers (CC) 1 and CC2. In this case, the beam failure-related information may indicate whether beam failures are detected from a specific TRP or multiple TRPs including the specific TRP on each of CC1 and CC2. Whether beam failures are detected from a specific TRP or multiple TRPs including the specific TRP may be indicated by the BF status or BF bitmap, as described above.

[0297] Information related to beam failure may be included in one MAC-CE (e.g., BFR MAC-CE) or multiple MAC-CEs configured for BFR use and transmitted to the base station. Specifically, information indicating a specific resource group in which beam failure is detected or multiple resource groups in which beam failure is detected may be included in one MAC-CE and transmitted to the base station.

[0298] Here, at least one of 1) the type of cell in which beam failure is detected, 2) index information of at least one frequency band in which beam failure is detected, 3) information on whether a new candidate beam RS exists in at least one frequency band in which beam failure is detected, or 4) information indicating the new candidate beam RS based on the existence of the candidate beam RS (e.g., ID of the new candidate beam RS) may be included in and transmitted in the single MAC-CE. However, without being limited thereto, the single MAC-CE may include only information indicating a specific resource group in which beam failure is detected or multiple resource groups in which beam failure is detected, and the above 1) to 4) may be transmitted separately to the base station.

[0299] Additionally or alternatively, information related to beam failure may be included in multiple MAC-CEs and transmitted to the base station. Specifically, MAC-CEs corresponding to a case where a beam failure is detected from a specific resource group and a case where a beam failure is detected from multiple resource groups may be defined separately.

[0300] For example, the plurality of MAC-CEs may include a first MAC-CE and a second MAC-CE, and upon detection of a beam failure from a specific resource group, information related to the beam failure may be included in the first MAC-CE and transmitted to the base station, and upon detection of a beam failure from a plurality of resource groups, information related to the beam failure may be included in the second MAC-CE and transmitted to the base station.

[0301] Additionally or alternatively, information related to beam failure may be transmitted to a resource group in which beam failure is not detected. For example, based on the information related to beam failure being included in one MAC-CE (e.g., a BFR MAC-CE) or multiple MAC-CEs (e.g., a first MAC-CE or a second MAC-CE), the terminal may transmit the one MAC-CE or multiple MAC-CEs to a resource group in which beam failure is not detected. A resource group in which beam failure is detected may not be able to decode the information included in the MAC-CE. Therefore, the terminal may transmit one MAC-CE or multiple MAC-CEs including information related to beam failure to a resource group in which beam failure is not detected.

[0302] FIG. 9 is a diagram illustrating a beam failure recovery operation of a base station according to an embodiment of the present disclosure.

[0303] Based on the detection of a beam failure (BF) from at least one resource group among a plurality of resource groups, the base station may receive a beam failure recovery request (BFRQ) from the terminal (S910).

[0304] Here, specific examples of the resource group and the BFRQ resource are the same as those described for step S810 of FIG. 8, and therefore, the overlapping description will be omitted.

[0305] The base station may transmit a response to the BFRQ to the terminal (S920). The response to the BFRQ may include an uplink grant. The base station may receive a PUSCH scheduled by the DCI including the uplink grant from the terminal.

[0306] The base station may receive beam failure-related information from the terminal (S930). Here, examples of the beam failure-related information are the same as those described for step S820 of FIG. 8, and therefore, the same description will be omitted.

[0307] Specifically, the base station may receive from the terminal one MAC-CE (e.g., BFR MAC-CE) or multiple MAC-CEs configured for BFR use that include information related to beam failure.

[0308] Here, examples related to one MAC-CE or multiple MAC-CEs are the same as the examples described for step S830 of FIG. 8, and therefore, redundant descriptions thereof will be omitted.

[0309] FIG. 10 is a diagram for explaining a signaling procedure on the network side and the terminal according to the present disclosure.

[0310] FIG. 10 illustrates an example of signaling between a network side and a terminal (UE) in an MTRP situation to which the above-described examples of the present disclosure (e.g., one or more combinations of Example 1, Example 1-1, Example 2, or detailed examples thereof) are applicable. Here, the UE / network side is exemplary and may be alternatively applied to various devices as described with reference to FIG. 11. FIG. 10 is provided for convenience of explanation and does not limit the scope of the present disclosure. Also, some steps illustrated in FIG. 10 may be omitted depending on the situation and / or settings. Also, the above-described uplink transmission / reception operations, MTRP-related operations, etc. may be referenced or used in the operation of the network side / UE in FIG. 10.

[0311] In the following description, the network side may be a base station including multiple TRPs or a cell including multiple TRPs. Alternatively, the network side may include multiple remote radio heads (RRHs) / remote radio units (RRUs). As an example, an ideal / non-ideal backhaul may be established between TRP1 and TRP2 constituting the network side. Furthermore, although the following description is based on multiple TRPs, this may be equally extended and applied to transmissions by multiple panels / cells, or may be equally extended and applied to transmissions by multiple RRHs / RRUs, etc.

[0312] Also, although the following description will be based on "TRP", as described above, "TRP" may be applied as an alternative to expressions such as panel, antenna array, cell (e.g., macro cell / small cell / pico cell, etc.), TP (transmission point), and base station (gNB, etc.). As described above, TRP may be distinguished by information (e.g., CORESET index, ID) related to a CORESET group (or CORESET pool). For example, if one UE is configured to transmit and receive data with multiple TRPs (or cells), this may mean that multiple CORESET groups (or CORESET pools) are configured for one UE. Such configuration of a CORESET group (or CORESET pool) may be performed by higher layer signaling (e.g., RRC signaling, etc.). In addition, a base station may collectively refer to an object that transmits and receives data to and from a UE. For example, the base station may be a concept including one or more TPs (Transmission Points), one or more TRPs (Transmission and Reception Points), etc. Furthermore, the TPs and / or TRPs may include a panel of the base station, a transmission and reception unit, etc.

[0313] The UE may receive configuration information from the network side via / using TRP1 and / or TRP2 (S105). The configuration information may include system information (SI), scheduling information, CSI-related configuration (e.g., CSI reporting configuration, CSI-RS resource configuration), etc. The configuration information may include information related to the network side configuration (i.e., TRP configuration), resource allocation information related to MTRP-based transmission and reception, etc. The configuration information may be transmitted via a higher layer (e.g., RRC, MAC CE). Also, if the configuration information is predefined or preconfigured, this step may be omitted.

[0314] For example, as in the above-described embodiments (e.g., a combination of one or more of Example 1, Example 1-1, Example 2, or detailed examples thereof), the configuration information may include CORESET-related configuration information (e.g., ControlResourceSet IE). The CORESET-related configuration information may include a CORESET-related ID (e.g., controlResourceSetID), an index of a CORESET pool for the CORESET (e.g., CORESETPoolIndex), time / frequency resource configuration of the CORESET, TCI information related to the CORESET, etc. For example, the configuration information may include information related to beam management / BFR, etc., as described in the above-described embodiments (e.g., a combination of one or more of Example 1, Example 1-1, Example 2, or detailed examples thereof).

[0315] For example, the operation of the UE (100 or 200 in FIG. 11) receiving the configuration information from the network side (200 or 100 in FIG. 11) in step S105 described above may be implemented by the apparatus of FIG. 11 described below. For example, referring to FIG. 11, one or more processors 102 can control one or more transceivers 106 and / or one or more memories 104 to receive the configuration information, and one or more transceivers 106 can receive the configuration information from the network side.

[0316] The UE may transmit a reference signal for UL transmission to the network side via / using TRP1 and / or TRP2 (S110). For example, the UE may transmit RS1 and / or RS2 for beam management / BFD to the network side via / using TRP1 and / or TRP2.

[0317] For example, the operation of transmitting the reference signal from the UE (100 or 200 in FIG. 11) to the network side (200 or 100 in FIG. 11) in step S110 may be implemented by the apparatus of FIG. 11 described below. For example, referring to FIG. 11, one or more processors 102 may control one or more transceivers 106 and / or one or more memories 104 to transmit the reference signal, and the one or more transceivers 106 may transmit the reference signal to the network side.

[0318] The UE may perform beam management / BFR based on RS 1 and / or RS 2 via / using TRP 1 and / or TRP 2 from the network side (S115). For example, the method of performing beam management / BFR may be performed based on the above-described embodiments (e.g., embodiment 1, embodiment 1-1, embodiment 2, or a combination of one or more of their detailed examples). For example, the UE may measure / estimate a hypothetical BLER based on the reception quality of RS 1 and / or RS 2, and determine whether or not BF is performed based on the measurement / estimation.

[0319] For example, the operation of the UE (100 or 200 in FIG. 11) performing beam management / BFR in step S115 described above may be implemented by the following apparatus in FIG. 11. For example, referring to FIG. 11, one or more processors 102 may control one or more memories 104, etc. to perform the beam management / BFR operation.

[0320] The UE may transmit the beam management / BFR report (e.g., BFRQ) to the network side via / using TRP1 and / or TRP2 (S120). In this case, the beam management / BFR report (e.g., BFRQ, etc.) for TRP1 and the beam management / BFR report (e.g., BFRQ, etc.) for TRP2 may be transmitted separately or combined into one. Alternatively, the UE may be configured to transmit the beam management / BFR report (e.g., BFRQ, etc.) to a representative TRP (e.g., TRP1) and omit transmission of the beam management / BFR report (e.g., BFRQ, etc.) to other TRPs (e.g., TRP2). Alternatively, the UE may be configured to transmit the BFR report (e.g., BFRQ, etc.) to the same TRP as the TRP in which the beam failure occurred. Alternatively, the UE may be configured to transmit the BFR report (e.g., BFRQ, etc.) to a TRP other than the TRP in which the beam failure occurred.

[0321] For example, the beam management / BFR report (e.g., BFRQ, etc.) may be performed based on the above-described embodiments (e.g., Example 1, Example 1-1, Example 2, or a combination of one or more of their detailed examples). For example, a report may be performed when a BFR occurs for a specific TRP (e.g., event 1) and when a BF occurs for all TRPs (e.g., event 2). Also, a BFR may be performed for multiple serving cells / BWPs. For example, the beam management / BFR report (e.g., BFRQ, etc.) may be transmitted based on a BFR MAC CE.

[0322] For example, the BFR MAC CE may include indication information on whether the BFR is for an SpCell or an SCell(s), a CC / BWP list in which beam failure occurred, whether a new candidate beam RS has been found from the CC / BWP in which the BF occurred, a new candidate beam RS ID found from the CC / BWP in which the BF occurred, when a BF has occurred for a specific TRP (e.g., event 1) and / or when a BF has occurred for all TRPs (e.g., event 2), etc. For example, the indication information may be configured in the form of a bitmap or a form indicating any one of predefined states.

[0323] For example, the network side that receives a report / BFRQ for BF from the UE via / using TRP 1 and / or TRP 2 can transmit new BM / BFR-related RS information for beam recovery to the UE.

[0324] For example, the operation of the UE (100 / 200 in FIG. 11) transmitting a report (e.g., BFRQ, etc.) for beam management / BFR to the network side (100 / 200 in FIG. 11) in step S120 described above may be implemented by the apparatus of FIG. 11 described below. For example, referring to FIG. 11, one or more processors 102 can control one or more transceivers 106 and / or one or more memories 104, etc. to transmit a report (e.g., BFRQ, etc.) for beam management / BFR, and the one or more transceivers 106 can transmit the report (e.g., BFRQ, etc.) for beam management / BFR to the network side.

[0325] Through the beam determined based on the above process, the UE can receive DCI 1 and Data 1 scheduled by DCI 1 from the network side via / using TRP1. In addition, the UE can receive DCI 2 and Data 2 scheduled by DCI 2 from the network side via / using TRP2. DCIs (e.g., DCI 1, DCI 2) and data (e.g., Data 1, Data 2) may be transmitted on a control channel (e.g., PDCCH, etc.) and a data channel (e.g., PDSCH, etc.), respectively. For example, DCI 1 may be received based on a first CORESET in which CORESETPoolindex is set to 0 or not set, and DCI 2 may be received based on a second CORESET in which CORESETPoolindex is set to 1. For example, the DCI (e.g., DCI 1, DCI 2) and / or data (e.g., Data 1, Data 2) may include control information / data related to the operations described in the above-described methods (e.g., one or more combinations of Example 1, Example 1-1, Example 2, or detailed examples thereof).

[0326] As mentioned above, the above-described network side / UE signaling and embodiments (e.g., Example 1, Example 1-1, Example 2, or a combination of any one or more of the detailed examples thereof) may be implemented by the apparatus described with reference to Fig. 11. For example, the network side (e.g., TRP1 / TRP2) may correspond to the first device 100, and the UE may correspond to the second device 200, and vice versa may also be considered in some cases.

[0327] For example, the above-described network side / UE signaling and operations (e.g., a combination of one or more of Example 1, Example 1-1, Example 2, or detailed examples thereof) may be processed by one or more processors (e.g., 102, 202) of FIG. 11, and the above-described network side / UE signaling and operations (e.g., a combination of one or more of Example 1, Example 1-1, Example 2, or detailed examples thereof) may be stored in a memory (e.g., one or more memories (e.g., 104, 204) of FIG. 11) in the form of instructions / programs (e.g., instructions, executable code) for driving at least one processor (e.g., 102, 202) of FIG. 11.

[0328] General devices to which the present disclosure can be applied

[0329] FIG. 11 illustrates a block diagram of a wireless communication device according to an embodiment of the present disclosure.

[0330] Referring to FIG. 11, a first device 100 and a second device 200 can transmit and receive wireless signals using various wireless access technologies (e.g., LTE, NR).

[0331] The first device 100 includes one or more processors 102 and one or more memories 104, and may further include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may be configured to control the memory 104 and / or the transceiver 106 to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure. For example, the processor 102 may process information in the memory 104 to generate first information / signal, and then transmit a wireless signal including the first information / signal from the transceiver 106. The processor 102 may also receive a wireless signal including second information / signal from the transceiver 106, and then store information obtained from signal processing of the second information / signal in the memory 104. The memory 104 may be coupled to the processor 102 and may store various information related to the operation of the processor 102. For example, the memory 104 may store software code including instructions for performing some or all of the processes controlled by the processor 102 or for implementing the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure. Here, the processor 102 and the memory 104 may be part of a communications modem / circuit / chip designed to implement a wireless communication technology (e.g., LTE, NR). The transceiver 106 may be coupled to the processor 102 and may transmit and / or receive wireless signals via one or more antennas 108. The transceiver 106 may include a transmitter and / or a receiver. The transceiver 106 may also be referred to as an RF (Radio Frequency) unit. In the present invention, a device may refer to a communications modem / circuit / chip.

[0332] The second device 200 may include one or more processors 202, one or more memories 204, and may further include one or more transceivers 206 and / or one or more antennas 208. The processor 202 may be configured to control the memory 204 and / or the transceiver 206 to implement the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure. For example, the processor 202 may process information in the memory 204 to generate third information / signal, and then transmit a wireless signal including the third information / signal from the transceiver 206. The processor 202 may also receive a wireless signal including fourth information / signal from the transceiver 206, and then store information obtained from signal processing of the fourth information / signal in the memory 204. The memory 204 may be coupled to the processor 202 and may store various information related to the operation of the processor 202. For example, the memory 204 may store software code including instructions for performing some or all of the processes controlled by the processor 202 or for implementing the descriptions, functions, procedures, suggestions, methods, and / or operational flow charts disclosed in this disclosure. Here, the processor 202 and the memory 204 may be part of a communications modem / circuit / chip designed to implement a wireless communication technology (e.g., LTE, NR). The transceiver 206 may be coupled to the processor 202 and may transmit and / or receive wireless signals via one or more antennas 208. The transceiver 206 may include a transmitter and / or a receiver. The transceiver 206 may also be referred to as an RF unit. In the present invention, a device may refer to a communications modem / circuit / chip.

[0333] The hardware elements of the devices 100 and 200 are described in more detail below. Without limitation, one or more protocol layers may be implemented by one or more processors 102 and 202. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, and SDAP). The one or more processors 102 and 202 may generate one or more protocol data units (PDUs) and / or one or more service data units (SDUs) according to the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed in this disclosure. The one or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operational flow diagrams disclosed in this disclosure. The one or more processors 102, 202 can generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information according to the functions, procedures, suggestions, and / or methods disclosed in this disclosure and provide them to the one or more transceivers 106, 206. The one or more processors 102, 202 can receive signals (e.g., baseband signals) from the one or more transceivers 106, 206 and obtain the PDUs, SDUs, messages, control information, data, or information according to the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure.

[0334] The one or more processors 102, 202 may be referred to as a controller, microcontroller, microprocessor, or microcomputer. The one or more processors 102, 202 may be implemented using hardware, firmware, software, or a combination thereof. As an example, the one or more processors 102, 202 may include one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field programmable gate arrays (FPGAs). The descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure may be implemented using firmware or software, and the firmware or software may be implemented to include modules, procedures, functions, etc. Firmware or software configured to execute the descriptions, functions, procedures, suggestions, methods and / or operational flow diagrams disclosed in this disclosure may be included in one or more processors 102, 202 or stored in one or more memories 104, 204 and executed by one or more processors 102, 202. The descriptions, functions, procedures, suggestions, methods and / or operational flow diagrams disclosed in this disclosure may be embodied by firmware or software in the form of code, instructions and / or collections of instructions.

[0335] One or more memories 104, 204 may be coupled to one or more processors 102, 202 and may store various forms of data, signals, messages, information, programs, code, instructions, and / or commands. The one or more memories 104, 204 may be comprised of ROM, RAM, EPROM, flash memory, hard drives, registers, cache memory, computer-readable storage media, and / or combinations thereof. The one or more memories 104, 204 may be located internal and / or external to the one or more processors 102, 202. Additionally, the one or more memories 104, 204 may be coupled to the one or more processors 102, 202 via various techniques, such as wired or wireless connections.

[0336] One or more transceivers 106, 206 may transmit user data, control information, wireless signals / channels, etc., as referred to in the methods and / or operational flowcharts of the present disclosure, to one or more other devices. One or more transceivers 106, 206 may receive user data, control information, wireless signals / channels, etc., as referred to in the descriptions, functions, procedures, suggestions, methods and / or operational flowcharts of the present disclosure, from one or more other devices. For example, one or more transceivers 106, 206 may be coupled to one or more processors 102, 202 and may transmit and receive wireless signals. For example, one or more processors 102, 202 may control one or more transceivers 106, 206 to transmit user data, control information, or wireless signals to one or more other devices. Also, one or more processors 102, 202 may control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. Furthermore, one or more transceivers 106, 206 may be coupled to one or more antennas 108, 208, and the one or more transceivers 106, 206 may be configured to transmit and receive user data, control information, wireless signals / channels, etc., referred to in the descriptions, functions, procedures, suggestions, methods, and / or operational flowcharts disclosed in this disclosure, via the one or more antennas 108, 208. In this disclosure, the one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). The one or more transceivers 106, 206 may convert the received user data, control information, wireless signals / channels, etc., from RF band signals to baseband signals for processing using one or more processors 102, 202. The one or more transceivers 106, 206 may convert the user data, control information, wireless signals / channels, etc., processed using one or more processors 102, 202, from baseband signals to RF band signals. To that end, one or more of the transceivers 106, 206 may include (analog) oscillators and / or filters.

[0337] The embodiments described above are combinations of the components and features of the present disclosure in a predetermined form. Each component or feature should be considered optional unless otherwise explicitly stated. Each component or feature may be implemented without being combined with other components or features. It is also possible to combine some components and / or features to form embodiments of the present disclosure. The order of operations described in the embodiments of the present disclosure may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced with corresponding components or features of another embodiment. It is clear that claims that do not have an explicit reference relationship in the claims may be combined to form embodiments, or may be included as new claims by amendment after filing.

[0338] It is obvious to those skilled in the art that the present disclosure can be embodied in other specific forms without departing from the essential features of the present disclosure. Therefore, the above detailed description should not be interpreted as limiting in any respect, but should be considered as illustrative. The scope of the present disclosure should be determined by reasonable interpretation of the appended claims, and any modifications within the equivalent scope of the present disclosure are included in the scope of the present disclosure.

[0339] The scope of the present disclosure includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) that cause a device or computer to perform operations according to the methods of various embodiments, as well as non-transitory computer-readable media on which such software or instructions are stored and executable on a device or computer. Instructions usable for programming a processing system to perform features described in this disclosure may be stored on or in a storage medium or computer-readable storage medium, and computer program products including such storage media may be used to embody features described in this disclosure. Storage media may include high-speed random access memory such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices, but are not limited to, non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory optionally includes one or more storage devices located remotely from the processor. Memory, or alternatively, non-volatile memory devices within memory, comprise non-transitory computer-readable storage media. The features described in this disclosure may be embodied in software and / or firmware stored on any one of a number of machine-readable media and capable of controlling the hardware of a processing system and allowing the processing system to interact with other mechanisms that utilize the results of embodiments of the present disclosure. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, and execution environments / containers.

[0340] Here, the wireless communication technology implemented in the devices 100 and 200 of the present disclosure may include LTE, NR, 6G, and also Narrowband Internet of Things (NB-IoT) for low-power communication. Here, for example, the NB-IoT technology may be an example of a Low Power Wide Area Network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the above-mentioned names. Additionally or alternatively, the wireless communication technology implemented in the devices 100 and 200 of the present disclosure may perform communication based on the LTE-M technology. Here, for example, the LTE-M technology may be an example of an LPWAN technology and may be referred to by various names such as enhanced Machine Type Communication (eMTC). For example, LTE-M technology may be implemented by at least one of various standards, such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-Bandwidth Limited), 5) LTE-MTC, 6) LTE Machine Type Communication, and / or 7) LTE M, and is not limited to the above names. Additionally or alternatively, wireless communication technologies implemented in devices 100 and 200 of the present disclosure may include at least one of ZigBee (registered trademark), Bluetooth (registered trademark), and Low Power Wide Area Network (LPWAN), which consider low-power communication, and are not limited to the above names. As an example, ZigBee technology may create personal area networks (PANs) related to small / low-power digital communication based on various standards, such as IEEE 802.15.4, and may be referred to by various names. [Industrial Applicability]

[0341] The method proposed in this disclosure has been described mainly as being applied to 3GPP LTE / LTE-A and 5G systems, but it can also be applied to various other wireless communication systems in addition to 3GPP LTE / LTE-A and 5G systems.

Claims

1. A method performed by a user-equipment (UE) in a wireless communication system, the method comprising: receiving, from a base station, radio resource control (RRC) signaling related to a beam failure recovery (BFR) procedure for each of a plurality of serving cells to which two beam failure detection (BFD)-reference signal (RS) sets are configured; triggering the BFR procedure for at least one of the two BFD-RS sets based on the RRC signaling based on a beam failure detected for at least one of the two BFD-RS sets configured for at least one serving cell among the plurality of serving cells; transmitting an improved BFR media access control (MAC)-control element (CE) to the base station; The improved BFR MAC CE is i) at least one first field corresponding to each of the at least one serving cell, indicating whether the beam failure is detected for one of the two BFD-RS sets or for all of the two BFD-RS sets; ii) a second field indicating the identity of at least one of the two BFD-RS sets; iii) a third field indicating whether the beam failure is detected for at least one of two BFD-RS sets configured for a special cell (SpCell) among the plurality of serving cells; iv) at least one fourth field corresponding to at least one SCell (secondary cell) among the plurality of serving cells; The method, wherein each of the at least one fourth field indicates whether the beam failure is detected for each of the at least one SCell.

2. 2. The method of claim 1, wherein the improved BFR MAC CE includes a fifth field indicating whether a sixth field related to an index of a candidate beam RS is present in the improved BFR MAC CE.

3. Configuration information relating to at least one candidate beam is transmitted from the base station to the UE; The method of claim 2 , wherein the candidate beam RSs include RSs among the at least one candidate beam that have a quality value equal to or greater than a predefined value.

4. 2. The method of claim 1, wherein each of the two BFD-RS sets includes at least one BFD-RS associated with at least one transmission configuration indicator (TCI) state configured for each of two control resource sets (CORESETs).

5. The method of claim 1 , wherein the RRC signaling includes information related to a beam failure recovery timer and information related to a candidate beam RS list.

6. A user equipment (UE) in a wireless communication system, the UE comprising: at least one transceiver for transmitting and receiving wireless signals; at least one processor for controlling the at least one transceiver; The at least one processor: receiving, from a base station via the at least one transceiver unit, radio resource control (RRC) signaling related to a beam failure recovery (BFR) procedure for each of a plurality of serving cells to which two beam failure detection (BFD)-reference signal (RS) sets are configured; triggering the BFR procedure for the at least one of the two BFD-RS sets based on the RRC signaling based on a beam failure detected for at least one of the two BFD-RS sets configured for at least one serving cell among the plurality of serving cells; configured to transmit an improved BFR media access control (MAC)-control element (CE) to the base station via the at least one transceiver unit; The improved BFR MAC CE is i) at least one first field corresponding to each of the at least one serving cell, indicating whether the beam failure is detected for one of the two BFD-RS sets or for all of the two BFD-RS sets; ii) a second field indicating the identity (ID) of at least one of the two BFD-RS sets; iii) a third field indicating whether the beam failure is detected for at least one of two BFD-RS sets configured for a special cell (SpCell) among the plurality of serving cells; iv) at least one fourth field corresponding to at least one SCell (secondary cell) among the plurality of serving cells; Each of the at least one fourth field indicates whether the beam failure is detected for each of the at least one SCell, UE.

Images