Method and apparatus for performing ueibr in wireless communication system

WO2026206026A1PCT designated stage Publication Date: 2026-10-01HYUNDAI MOTOR CO LTD +2
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/KR2026/004857
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2025-03-28
Filing Date
2026-03-27
Publication Date
2026-10-01

Smart Images

  • Figure KR2026004857_01102026_PF_FP_ABST
    Figure KR2026004857_01102026_PF_FP_ABST
Patent Text Reader

Abstract

The present disclosure relates to a method and an apparatus for performing UEIBR in a wireless communication system. An operation method of a terminal in a wireless communication system comprises the steps of: receiving configuration information from a base station; detecting at least one event on the basis of the configuration information; incrementing an event instance counter associated with the detected event, on the basis of the detection of the at least one event; transmitting signaling via a PUCCH resource, on the basis of the event instance counter reaching a predefined value; and transmitting at least one beam report via a PUSCH resource, wherein the configuration information includes information on a time window, and the detection of the at least one event is performed within the time window.
Need to check novelty before this filing date? Find Prior Art

Description

Method and apparatus for performing UEIBR in a wireless communication system

[0001] The present disclosure relates to initial access in a wireless communication system, and more specifically, to a method and apparatus for performing a user-initiated / event-driven beam report (UEIBR).

[0002] Communication networks (e.g., 5G communication networks, 6G communication networks, etc.) are being developed to provide communication services that are improved over existing communication networks (e.g., LTE (long term evolution), LTE-A (advanced), etc.). 5G communication networks (e.g., NR (new radio) communication networks) can support frequency bands above 6 GHz as well as frequency bands below 6 GHz. That is, 5G communication networks can support the FR1 band and / or FR2 band. 5G communication networks can support a wider variety of communication services and scenarios compared to LTE communication networks. For example, usage scenarios for 5G communication networks may include eMBB (enhanced Mobile BroadBand), URLLC (Ultra Reliable Low Latency Communication), mMTC (massive Machine Type Communication), etc.

[0003] 6G communication networks can support a wider variety of communication services and scenarios compared to 5G communication networks. 6G communication networks can meet the requirements for ultra-high performance, ultra-bandwidth, ultra-spatial, ultra-precision, ultra-intelligence, and / or ultra-reliability. 6G communication networks can support a wide range of frequency bands and can be applied to various usage scenarios (e.g., terrestrial communication, non-terrestrial communication, sidelink communication, sensing, etc.).

[0004] Meanwhile, the technology forming the background of the invention is written to enhance understanding of the background of the invention and may include content that is not prior art already known to a person with ordinary knowledge in the field to which this technology belongs.

[0005] The disclosure may provide a method and apparatus for performing a UEIBR (user initiated / event-driven beam report) operation.

[0006] The present disclosure may provide a method and apparatus for triggering UEIBR operation.

[0007] The present disclosure may provide a method and apparatus for counting event instances for triggering UEIBR operations.

[0008] The present disclosure may provide a method and apparatus for resetting an event instance counter for triggering a UEIBR operation.

[0009] The present disclosure may provide a method and apparatus for setting a condition for resetting an event instance counter in UEIBR operation.

[0010] The present disclosure may provide a method and apparatus for setting a time window, a time offset, or a timer for triggering a UEIBR operation.

[0011] The present disclosure may provide a method and apparatus for resetting a time window in UEIBR operation.

[0012] The present disclosure may provide a method and apparatus for multiplexing beam reporting in UEIBR operation.

[0013] The present disclosure may provide a method and apparatus for indicating whether beam reporting is multiplexed in UEIBR operation.

[0014] The present disclosure may provide a method and apparatus for providing a format of beam reporting in UEIBR operation.

[0015] The technical objectives to be achieved in this disclosure are not limited to those mentioned above, and other unmentioned technical problems may be considered by those skilled in the art to which the technical configuration of this disclosure applies, based on the embodiments of this disclosure described below.

[0016] According to one embodiment of the present disclosure, a method of operation of a terminal in a wireless communication system comprises: receiving configuration information from a base station; detecting at least one event based on the configuration information; increasing an event instance counter associated with the detected event based on the detection of the at least one event; transmitting a signaling through a PUCCH resource based on the event instance counter reaching a predefined value; and transmitting at least one beam report through a PUSCH resource, wherein the configuration information includes information regarding a time window, and the detection of the at least one event is performed within the time window.

[0017] According to one embodiment of the present disclosure, a method of operation of a terminal in a wireless communication system comprises: transmitting configuration information including information about at least one event to the terminal; receiving signaling from the terminal via a PUCCH resource; and transmitting at least one beam report via a PUSCH resource, wherein the signaling is transmitted by the terminal based on an event instance counter reaching a predefined value, the event instance counter is incremented based on the detection of at least one event, the configuration information includes information about a time window, and the detection of the at least one event is performed within the time window.

[0018] According to one embodiment of the present disclosure, a terminal in a wireless communication system comprises: at least one transceiver; at least one processor; and at least one memory connected to the at least one processor to be operable and storing instructions that control the terminal to perform operations when executed by the processor, wherein the operations include: receiving configuration information from a base station; detecting at least one event based on the configuration information; increasing an event instance counter associated with the detected event based on the detection of the at least one event; transmitting a signaling through a PUCCH resource based on the event instance counter reaching a predefined value; and transmitting at least one beam report through a PUSCH resource, wherein the configuration information includes information regarding a time window, and the detection of the at least one event is performed within the time window.

[0019] According to one embodiment of the present disclosure, a base station in a wireless communication system comprises: at least one transceiver; at least one processor; and at least one memory connected to the at least one processor to be operable and storing instructions that control the base station to perform operations when executed by the processor, wherein the operations include: transmitting configuration information to a terminal that includes information about at least one event; receiving signaling from the terminal via a PUCCH resource; and transmitting at least one beam report via a PUSCH resource, wherein the signaling is transmitted by the terminal based on an event instance counter reaching a predefined value, the event instance counter is incremented based on the detection of at least one event, the configuration information includes information about a time window, and the detection of the at least one event is performed within the time window.

[0020] The proposed technology enables the reset of the time window associated with the reset of the event instance counter.

[0021] The effects obtainable from the embodiments of the present disclosure are not limited to those mentioned above, and other unmentioned effects can be clearly derived and understood by a person skilled in the art to which the technical configuration of the present disclosure applies from the description of the embodiments of the present disclosure below. That is, unintended effects resulting from implementing the configuration described in the present disclosure can also be derived by a person skilled in the art from the embodiments of the present disclosure.

[0022] FIG. 1 illustrates a communication system according to an embodiment of the present disclosure.

[0023] FIG. 2 illustrates a block diagram of a communication node according to an embodiment of the present disclosure.

[0024] FIG. 3 illustrates a block diagram of devices performing communication according to one embodiment of the present disclosure.

[0025] FIGS. 4a and 4b illustrate block diagrams of a transmission path and a reception path of a communication node according to an embodiment of the present disclosure.

[0026] FIG. 5 illustrates an example of a system frame in a wireless communication system according to an embodiment of the present disclosure.

[0027] FIG. 6 illustrates an example of a subframe in a wireless communication system according to an embodiment of the present disclosure.

[0028] FIG. 7 illustrates an example of a slot in a wireless communication system according to an embodiment of the present disclosure.

[0029] FIG. 8 illustrates an example of a time-frequency resource in a wireless communication system according to an embodiment of the present disclosure.

[0030] FIG. 9 illustrates an example of a UEIBR procedure in Mode A according to one embodiment of the present disclosure.

[0031] FIG. 10 illustrates an example of a UEIBR procedure in Mode B according to one embodiment of the present disclosure.

[0032] FIG. 11 illustrates a terminal procedure of UEIBR operation according to one embodiment of the present disclosure.

[0033] FIG. 12 illustrates a base station procedure of UEIBR operation according to one embodiment of the present disclosure.

[0034] FIG. 13 illustrates a beam reporting procedure based on a plurality of beam reporting triggerings according to one embodiment of the present disclosure.

[0035] FIG. 14 illustrates an example of transmitting a plurality of beam reporting information in UEIBR Mode A according to one embodiment of the present disclosure.

[0036] FIG. 15 illustrates an example of a multiplexing beam reporting procedure in Mode A according to one embodiment of the present disclosure.

[0037] FIG. 16 illustrates a beam reporting procedure using a plurality of PUSCHs in Mode A according to one embodiment of the present disclosure.

[0038] FIG. 17 illustrates a beam reporting procedure using a plurality of DCIs according to one embodiment of the present disclosure.

[0039] FIG. 18 illustrates an event detection and time window initialization procedure according to one embodiment of the present disclosure.

[0040] The present disclosure is capable of various modifications and may have various embodiments, and specific embodiments are illustrated in the drawings and described in detail. However, this is not intended to limit the present disclosure to specific embodiments and should be understood to include all modifications, equivalents, and substitutions that fall within the spirit and scope of the present disclosure.

[0041] Terms such as "first," "second," etc., may be used to describe various components, but said components should not be limited by said terms. Such terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present disclosure, the first component may be named the second component, and similarly, the second component may be named the first component. The term "and / or" may mean a combination of a plurality of related described items or any of a plurality of related described items.

[0042] In the present disclosure, "at least one of A and B" may mean "at least one of A or B" or "at least one of one or more combinations of A and B". Additionally, in the present disclosure, "at least one of A and B" may mean "at least one of A or B" or "at least one of one or more combinations of A and B".

[0043] In the present disclosure, (re)transmission may mean "transmission," "retransmission," or "transmission and retransmission"; (re)setting may mean "setting," "resetting," or "setting and resetting"; (re)connection may mean "connection," "reconnection," or "connection and reconnection"; and (re)connection may mean "connection," "reconnection," or "connection and reconnection".

[0044] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0045] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit this disclosure. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this disclosure, terms such as “comprising” or “having” are intended to specify the existence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

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

[0047] Hereinafter, preferred embodiments of the present disclosure will be described in more detail with reference to the attached drawings. To facilitate overall understanding in describing the present disclosure, the same reference numerals are used for identical components in the drawings, and redundant descriptions of identical components are omitted. Operations according to combinations of embodiments, extensions of embodiments, and / or modifications of embodiments may be performed, as well as the embodiments explicitly described in the present disclosure. The performance of some operations may be omitted, and the order of operations may be changed.

[0048] In the embodiments, even when a method performed at a first communication node among the communication nodes (e.g., transmission or reception of a signal) is described, the corresponding second communication node may perform a method corresponding to the method performed at the first communication node (e.g., reception or transmission of a signal). That is, when the operation of a UE (user equipment) is described, the corresponding base station may perform an operation corresponding to the operation of the UE. Conversely, when the operation of a base station is described, the corresponding UE may perform an operation corresponding to the operation of the base station.

[0049] A base station may be referred to as Node B, evolved Node B, gNode B (next generation node B), gNB, device, apparatus, node, communication node, BTS (base transceiver station), RRH (radio remote head), TRP (transmission reception point), RU (radio unit), RSU (road side unit), radio transceiver, access point, access node, etc. A UE may be referred to as terminal, device, apparatus, node, communication node, end node, access terminal, mobile terminal, station, subscriber station, mobile station, portable subscriber station, OBU (on-broad unit), etc.

[0050] In the present disclosure, signaling may be at least one of upper-layer signaling, MAC signaling, or PHY (physical) signaling. A message used for upper-layer signaling may be referred to as an "upper-layer message" or an "upper-layer signaling message." A message used for MAC signaling may be referred to as a "MAC message" or a "MAC signaling message." A message used for PHY signaling may be referred to as a "PHY message" or a "PHY signaling message." Upper-layer signaling may refer to the transmission and reception operations of system information (e.g., MIB (master information block), SIB (system information block)) and / or RRC messages. MAC signaling may refer to the transmission and reception operations of MAC CE (control element). PHY signaling may refer to the transmission and reception operations of control information (e.g., DCI (downlink control information), UCI (uplink control information), SCI (sidelink control information)).

[0051] In the present disclosure, "setting an operation (e.g., a transmission operation)" may mean that "setting information for said operation (e.g., an information element, a parameter)" and / or "information directing the performance of said operation" is signaled. "Setting an information element (e.g., a parameter)" may mean that said information element is signaled. In the present disclosure, "signal and / or channel" may mean a signal, a channel, or "signal and channel," and "signal" may be used to mean "signal and / or channel."

[0052] The communication networks to which the embodiments are applied are not limited to those described below, and the embodiments may be applied to various communication networks (e.g., 4G communication networks, 5G communication networks, and / or 6G communication networks). Here, the term "communication network" may be used interchangeably with "communication system."

[0053] FIG. 1 illustrates a communication system according to an embodiment of the present disclosure.

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

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

[0056] FIG. 2 illustrates a block diagram of a communication node according to an embodiment of the present disclosure. The structure exemplified in FIG. 2 may be understood as the structure of at least part of a communication node, base station, satellite, or core network entity. The communication node (200) exemplified in FIG. 2 may be a mobile terminal such as a smartphone, tablet PC, or wearable device, but is not limited thereto.

[0057] Referring to FIG. 2, the wireless device (200) may include at least one control unit (210), at least one memory (220), at least one power supply unit (230), at least one transceiver unit (240), at least one input unit (250), at least one output unit (260) and / or at least one antenna (270).

[0058] The control unit (210) can control the memory (220) and / or the transmission / reception unit (240) and may be configured to implement the descriptions, functions, procedures, proposals, methods, and / or operation sequences disclosed in this disclosure. The memory (220) may be connected to the control unit (210) and may store various information related to the operation of the control unit (210). For example, the memory (220) may store software code including instructions for performing some or all of the controls controlled by the control unit (210) or for performing the descriptions, functions, procedures, proposals, methods, and / or operation sequences disclosed in this disclosure. The configuration of the memory is not limited in a particular way. For example, it may be configured as at least one of read-only memory (ROM) and random access memory (RAM).

[0059] At least one control unit (210) may be referred to as a controller, microcontroller, microprocessor, or microcomputer. The descriptions, functions, procedures, proposals, methods, and / or flowcharts of operations disclosed in this disclosure may be implemented using firmware or software in the form of code, instructions, and / or sets of instructions. Here, the firmware or software may execute other programs stored in memory (220), such as an OS. The control unit (210) may be implemented to support differently weighted beamforming or directional routing operations to effectively control the outgoing signal from at least one antenna (270) to a desired direction.

[0060] Additionally, at least one control unit (210) may be coupled with a backhaul or network interface. The wireless device (200) may communicate with other wireless devices through the backhaul or network interface. The control unit (210) may include at least one processor. The processor may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which the methods according to embodiments of the present disclosure are performed.

[0061] At least one transceiver (240) may be connected to a control unit (210) and may transmit and / or receive a wireless signal through at least one antenna (270). The transceiver (240) may include a transmitter and / or a receiver. At least one transceiver (240) may transmit user data, control information, wireless signals / channels, etc., as described in the methods and / or operation flowcharts of the present disclosure to at least one other device. For example, at least one transceiver (240) may be connected to at least one control unit (210) and may transmit and receive wireless signals. Additionally, at least one control unit (210) may control at least one transceiver (240) to transmit user data, control information, or wireless signals to at least one other device. At least one transmitter (240) may receive a signal transmitted by another wireless device from at least one antenna (270). Additionally, at least one transceiver (24) can down-convert or up-convert the received signal to generate a baseband signal. At least one antenna (270) may be a plurality of physical antennas or a plurality of logical antennas (e.g., antenna ports).

[0062] The input unit (250) can acquire information such as user input, video, and audio, and may include various input means such as various mechanical / electronic input means, cameras, and microphones. The output unit (260) is intended to provide information to a user by generating output related to sight, hearing, or touch, and may include a display, speaker, vibration module, etc. The wireless device (200) supplies power through the power unit (230), and the power unit (230) may include a wired / wireless charging circuit, battery, etc.

[0063] A more detailed example of the structure of the control unit (210) and / or the transceiver unit (240) is shown in FIG. 3. FIG. 3 illustrates a block diagram of devices performing communication according to an embodiment of the present disclosure. FIG. 3 illustrates the structure of a first communication node (300a) and a second communication node (300b) that transmit and / or receive a signal. In FIG. 3, each of the first communication node (300a) and the second communication node (300b) may be a base station or a UE.

[0064] Referring to FIG. 3, the first communication node (300a) and the second communication node (300b) may each be a base station or a UE. The first communication node (300a) may transmit a signal to the second communication node (300b). A transmission processor (311) included in the first communication node (300a) may receive data (e.g., a data unit) from a data source (310). The transmission processor (311) may receive control information from a controller (316). The control information may include at least one of system information, RRC setting information (e.g., information set by RRC signaling), MAC control information (e.g., MAC CE), or PHY control information (e.g., DCI, SCI).

[0065] The transmitting processor (311) can generate data symbol(s) by performing processing operations on data (e.g., encoding operations, symbol mapping operations, etc.). The transmitting processor (311) can generate control symbol(s) by performing processing operations on control information (e.g., encoding operations, symbol mapping operations, etc.). Additionally, the transmitting processor (311) can generate synchronization / reference symbol(s) for synchronization signals and / or reference signals.

[0066] The Tx MIMO processor (312) can perform spatial processing operations (e.g., precoding operations) on data symbol(s), control symbol(s), and / or synchronization / reference symbol(s). The output of the Tx MIMO processor (312) (e.g., a symbol stream) can be provided to modulators (MODs) included in transceivers (313a to 313t). The modulators (MODs) can perform processing operations on the symbol stream to generate modulated symbols and perform additional processing operations on the modulated symbols (e.g., analog conversion operations, amplification operations, filtering operations, up-conversion operations) to generate signals. The signals generated by the modulators (MODs) of the transceivers (313a to 313t) can be transmitted through antennas (314a to 314t).

[0067] Signals transmitted by the first communication node (300a) can be received at the antennas (364a to 364r) of the second communication node (300b). Signals received at the antennas (364a to 364r) can be provided to demodulators (DEMODs) included in the transceivers (363a to 363r). The demodulators (DEMODs) can obtain samples by performing processing operations on the signals (e.g., filtering, amplification, down-conversion, digital conversion). The demodulators (DEMODs) can obtain symbols by performing additional processing operations on the samples. The MIMO detector (362) can perform MIMO detection operations on the symbols. The receiving processor (361) can perform processing operations on the symbols (e.g., deinterleaving, decoding). The output of the receiving processor (361) can be provided to the data sink (360) and the controller (366). For example, data can be provided to the data sink (360), and control information can be provided to the controller (366).

[0068] Meanwhile, the second communication node (300b) can transmit a signal to the first communication node (300a). The transmission processor (368) included in the second communication node (300b) can receive data (e.g., a data unit) from a data source (367) and can generate data symbol(s) by performing a processing operation on the data. The transmission processor (368) can receive control information from a controller (366) and can generate control symbol(s) by performing a processing operation on the control information. Additionally, the transmission processor (368) can generate reference symbol(s) by performing a processing operation on a reference signal.

[0069] The Tx MIMO processor (369) can perform spatial processing operations (e.g., precoding operations) on data symbol(s), control symbol(s), and / or reference symbol(s). The output of the Tx MIMO processor (369) (e.g., a symbol stream) can be provided to modulators (MODs) included in the transceivers (363a to 363t). The modulators (MODs) can perform processing operations on the symbol stream to generate modulated symbols and perform additional processing operations on the modulated symbols (e.g., analog conversion operations, amplification operations, filtering operations, up-conversion operations) to generate signals. The signals generated by the modulators (MODs) of the transceivers (363a to 363t) can be transmitted through the antennas (364a to 364t).

[0070] Signals transmitted by the second communication node (300b) can be received at the antennas (314a to 314r) of the first communication node (300a). Signals received at the antennas (314a to 314r) can be provided to demodulators (DEMODs) included in the transceivers (313a to 313r). The demodulators (DEMODs) can obtain samples by performing processing operations on the signals (e.g., filtering operation, amplification operation, down-conversion operation, digital conversion operation). The demodulators (DEMODs) can obtain symbols by performing additional processing operations on the samples. The MIMO detector (320) can perform MIMO detection operations on the symbols. The receiving processor (319) can perform processing operations on the symbols (e.g., deinterleaving operation, decoding operation). The output of the receiving processor (319) can be provided to the data sink (318) and the controller (316). For example, data can be provided to the data sink (318), and control information can be provided to the controller (316).

[0071] The memories (315 and 365) may store data, control information, and / or program code. The scheduler (317) may perform scheduling operations for communication. The processors (311, 312, 319, 361, 368, 369) and controllers (316, 366) shown in FIG. 3 may be the processor (210) shown in FIG. 2 and may be used to perform the methods described in this disclosure.

[0072] FIGS. 4a and 4b illustrate block diagrams of a transmission path and a reception path of a communication node according to an embodiment of the present disclosure.

[0073] Referring to FIGS. 4a and 4b, a transmission path (410) may be implemented at a communication node that transmits a signal, and a reception path (420) may be implemented at a communication node that receives a signal. The transmission path (410) may include a channel coding and modulation block (411), an S-to-P (serial-to-parallel) block (412), an N IFFT (Inverse Fast Fourier Transform) block (413), a P-to-S (parallel-to-serial) block (414), a CP (cyclic prefix) addition block (415), and an UC (up-converter) (UC) (416). The reception path (420) may include a DC (down-converter) (421), a CP removal block (422), an S-to-P block (423), an N FFT block (424), a P-to-S block (425), and a channel decoding and demodulation block (426). Here, N can be a natural number.

[0074] Information bits in the transmission path (410) can be input to the channel coding and modulation block (411). The channel coding and modulation block (411) can perform coding operations (e.g., LDPC (low-density parity check) coding operations, polar coding operations, etc.) and modulation operations (e.g., QPSK (Quadrature Phase Shift Keying), QAM (Quadrature Amplitude Modulation), etc.) on the information bits. The output of the channel coding and modulation block (411) may be a sequence of modulation symbols.

[0075] The S-to-P block (412) can convert modulated symbols in the frequency domain into parallel symbol streams to generate N parallel symbol streams. N can be the IFFT size or the FFT size. The N IFFT block (413) can generate signals in the time domain by performing an IFFT operation on the N parallel symbol streams. The P-to-S block (414) can convert the output of the N IFFT block (413) (e.g., parallel signals) into a serial signal to generate a serial signal.

[0076] The CP addition block (415) can insert CP into the signal. The UC (416) can up-convert the frequency of the output of the CP addition block (415) to an RF (radio frequency) frequency. Additionally, the output of the CP addition block (415) can be filtered in the baseband before up-conversion.

[0077] A signal transmitted from the transmission path (410) can be input to the reception path (420). The operation in the reception path (420) may be the inverse operation of the operation in the transmission path (410). The DC (421) may down-convert the frequency of the received signal to a baseband frequency. The CP removal block (422) may remove CP from the signal. The output of the CP removal block (422) may be a serial signal. The S-to-P block (423) may convert the serial signal into parallel signals. The NFFT block (424) may generate N parallel signals by performing an FFT algorithm. The P-to-S block (425) may convert the parallel signals into a sequence of modulation symbols. The channel decoding and demodulation block (426) may perform a demodulation operation on the modulation symbols and restore data by performing a decoding operation on the result of the demodulation operation.

[0078] In FIGS. 4a and 4b, Discrete Fourier Transform (DFT) and Inverse DFT (IDFT) may be used instead of FFT and IFFT. In FIGS. 4a and 4b, each of the blocks (e.g., components) may be implemented by at least one of hardware, software, or firmware. For example, in FIGS. 4a and 4b, some blocks may be implemented by software, and the remaining blocks may be implemented by hardware or a "combination of hardware and software." In FIGS. 4a and 4b, one block may be subdivided into multiple blocks, multiple blocks may be integrated into one block, some blocks may be omitted, and blocks supporting other functions may be added.

[0079] FIG. 5 illustrates an example of a system frame in a wireless communication system according to an embodiment of the present disclosure.

[0080] Referring to FIG. 5, time resources in a communication system can be divided into frames. For example, system frames can be set consecutively in the time domain of the communication system. The length of a system frame can be 10 ms (millisecond). The system frame number (SFN) can be set from #0 to #1023. In this case, 1024 system frames can be repeated in the time domain of the communication system. For example, the SFN of a system frame after system frame #1023 can be #0.

[0081] A single system frame may contain two half frames. The length of a single half frame may be 5ms. A half frame located at the beginning of the system frame may be referred to as "Half Frame #0", and a half frame located at the end of the system frame may be referred to as "Half Frame #1". A system frame may contain 10 subframes. The length of a single subframe may be 1ms. Within a single system frame, the 10 subframes may be referred to as "Subframe #0-9".

[0082] FIG. 6 illustrates an example of a subframe in a wireless communication system according to an embodiment of the present disclosure.

[0083] Referring to FIG. 6, one subframe may contain n slots, where n is a natural number. Thus, one subframe may consist of one or more slots.

[0084] FIG. 7 illustrates an example of a slot in a wireless communication system according to an embodiment of the present disclosure.

[0085] Referring to FIG. 7, a slot may contain one or more symbols. A slot illustrated in FIG. 7 may contain 14 symbols. The length of the slot may vary depending on the number of symbols included in the slot and the length of the symbols. Alternatively, the length of the slot may vary depending on the numerology.

[0086] Numerals applied to physical signals and channels in a communication system may be variable. Numerals may be variable to meet various technical requirements of the communication system. In a communication system where CP (cyclic prefix) based OFDM waveform technology is applied, numerals may include subcarrier spacing and CP length (or CP type). Table 1 may be an example of a method for configuring numerals for a CP-OFDM based communication system. Depending on the frequency band in which the communication system operates, at least some of the numerals in Table 1 may be supported. Additionally, numerals not listed in Table 1 may be further supported in the communication system.

[0087] Subcarrier Spacing 15kHz 30kHz 60kHz 120kHz 240kHz 480kHz OFDM Symbol Length [μs] 66.733.316.78.34.22.1 CP Length [μs] 4.762.381.190.600.300.151 Number of OFDM Symbols in ms 142856112224448

[0088] When the subcarrier spacing is 15 kHz (e.g., (=0), the slot length can be 1ms. In this case, one system frame can contain 10 slots. When the subcarrier spacing is 30kHz (e.g., =1), the length of the slot can be 0.5ms. In this case, one system frame can contain 20 slots.

[0089] When the subcarrier spacing is 60 kHz (for example, =2), the slot length can be 0.25ms. In this case, one system frame can contain 40 slots. When the subcarrier spacing is 120kHz (e.g., =3), the slot length can be 0.125ms. In this case, one system frame can contain 80 slots. When the subcarrier spacing is 240kHz (e.g., =4), the length of the slot can be 0.0625ms. In this case, one system frame can contain 160 slots.

[0090] These frame structures can be configured in various ways. For example, the number of OFDM symbols per slot, the number of slots per frame, and the number of slots per subframe in the numeral can be configured as shown in Table 2 below.

[0091] μ Symbols per slot Number of slots per frame Number of slots per subframe 0 1 4 1 0 1 1 1 4 2 2 1 4 4 0 4 3 1 4 8 0 8 4 1 4 1 6 0 1 6 5 1 4 3 2 0 3 2 6 1 4 6 4 0 6 4

[0092] This frame structure is not limited to a specific method. Therefore, unlike Table 2 above, other numerals may be configured or additional numerals may be supported.

[0093] FIG. 8 illustrates an example of a time-frequency resource in a wireless communication system according to an embodiment of the present disclosure.

[0094] Referring to FIG. 8, a resource consisting of one symbol (e.g., an OFDM symbol) in the time domain and one subcarrier in the frequency domain can be defined as a "RE (resource element)." A resource consisting of one OFDM symbol in the time domain and K subcarriers in the frequency domain can be defined as a "REG (resource element group)." A REG can include K REs. A REG can be used as the basic unit of resource allocation in the frequency domain. K can be a natural number. For example, K can be 12. N can be a natural number. In the slot illustrated in FIG. 7, N can be 14. N OFDM symbols can be used as the basic unit of resource allocation in the time domain.

[0095] In the present disclosure, RB may mean a common RB (CRB). Alternatively, RB may mean a PRB or a virtual RB (VRB). In a communication system, a CRB may mean an RB that constitutes a set of consecutive RBs (e.g., a common RB grid) based on a reference frequency (e.g., point A). A carrier and / or bandwidth portion may be placed on the common RB grid. That is, the carrier and / or bandwidth portion may be composed of CRB(s). An RB or CRB constituting the bandwidth portion may be referred to as a PRB, and within the bandwidth portion, a CRB index may be appropriately converted to a PRB index.

[0096] Downlink data may be transmitted via PDSCH. A base station may transmit configuration information of the PDSCH (e.g., scheduling information) to a terminal via PDCCH. A terminal may obtain the configuration information of the PDSCH by receiving the PDCCH (e.g., downlink control information (DCI)). For example, the configuration information of the PDSCH may include a modulation coding scheme (MCS) used for transmitting and receiving the PDSCH, time resource information of the PDSCH, frequency resource information of the PDSCH, feedback resource information for the PDSCH, etc. PDSCH may refer to a radio resource where downlink data is transmitted and received. Alternatively, PDSCH may refer to the downlink data itself. PDCCH may refer to a radio resource where downlink control information (e.g., DCI) is transmitted and received. Alternatively, PDCCH may refer to the downlink control information itself.

[0097] The terminal may perform a monitoring operation for the PDCCH to receive the PDSCH transmitted from the base station. The base station may notify the terminal of configuration information for the monitoring operation of the PDCCH using a higher-layer message (e.g., a radio resource control (RRC) message). The configuration information for the monitoring operation of the PDCCH may include CORESET (control resource set) information and search space information.

[0098] CORESET information may include PDCCH DMRS (demodulation reference signal) information, PDCCH precoding information, PDCCH occasion information, etc. The PDCCH DMRS may be a DMRS used to demodulate the PDCCH. A PDCCH occasion may be an area where the PDCCH can exist. That is, a PDCCH occasion may be an area where the DCI can be transmitted. A PDCCH occasion may be referred to as a PDCCH candidate. PDCCH occasion information may include time resource information and frequency resource information of the PDCCH occasion. In the time domain, the length of the PDCCH occasion may be indicated in units of symbols. In the frequency domain, the size of the PDCCH occasion may be indicated in units of RBs (e.g., units of physical resource block (PRB) or common resource block (CRB)).

[0099] The search space information may include a CORESET ID (identifier) ​​associated with the search space, the period of PDCCH monitoring, and / or an offset. The period and offset of PDCCH monitoring may each be specified in slot units. Additionally, the search space information may further include the index of the symbol where the PDCCH monitoring operation begins.

[0100] A base station may configure a Bandwidth Part (BWP) for downlink communication. BWPs may be configured differently for each terminal. The base station may notify the terminal of the BWP configuration information using upper-layer signaling. Upper-layer signaling may refer to "transmission operations of system information" and / or "transmission operations of Radio Resource Control (RRC) messages." The number of BWPs configured for a single terminal may be one or more. The terminal may receive BWP configuration information from the base station and identify the BWP(s) configured by the base station based on the BWP configuration information. If multiple BWPs are configured for downlink communication, the base station may activate one or more of the multiple BWPs. The base station may transmit the configuration information of the activated BWP(s) to the terminal using at least one of upper-layer signaling, a Medium Access Control (MAC) Control Element (CE), or a DCI. The base station may perform downlink communication using the activated BWP(s). The terminal can identify the activated BWP(s) by receiving configuration information of the activated BWP(s) from the base station, and can perform a downlink reception operation on the activated BWP(s).

[0101] The structure of the resources for communication described with reference to FIGS. 5 through 8 is described as an example. A wireless communication system according to an embodiment of the present disclosure may adopt a different frame structure, a different slot structure, and / or a different symbol structure, and may use resource units with names other than frame, slot, and / or symbol. Here, a difference in structure may be understood as a difference in the numerator applied to the resource unit or a difference in the hierarchical structure. In addition, although described on the premise of an OFDM waveform, it is also possible to use waveforms other than OFDM.

[0102] ISAC (integrated sensing and communication) technology

[0103] ISAC is a technology that can simultaneously achieve maximum spectrum efficiency and reduce hardware costs by combining sensing and communication functions to be realized on a single integrated platform. ISAC is attracting attention as one of the key element technologies of 6G systems.

[0104] The ISAC system is divided into stages based on the level of integration between sensing and communication functions. In the initial integration stage, both functions share the same physical location (site), but frequency resources and hardware can be operated independently. In subsequent advanced integration stages, sensing and communication share the same frequency band and hardware platform, which can significantly improve the efficiency of system resource utilization and the level of integration. This resource-sharing structure is implemented by integrating sensing functions into existing communication infrastructure without the need for additional equipment, thereby enabling real-time environmental awareness and data collection. Consequently, various benefits are expected, including minimized redundant resource usage, reduced operating costs, decreased system complexity, and improved service quality.

[0105] The ultimate technical goal of ISAC is the reuse of waveforms and signals. In the waveform reuse phase, simultaneous data communication and environmental sensing are possible without additional spectrum resources by utilizing the same waveform for both communication and sensing. In the signal reuse phase, transmitted signals intended for communication are reused for sensing purposes, thereby minimizing system overhead and energy consumption while maximizing resource efficiency.

[0106] In particular, 6G systems are closely integrated with ISAC technology in the following aspects. First, regarding the enhancement of spatial precision, 6G aims to provide sub-centimeter positional accuracy through high-resolution sensing capabilities utilizing the mmWave / THz band, which is one of ISAC's core competencies. In terms of intelligent network operations, ISAC-based environmental awareness information is utilized for network resource allocation, link adaptation, and beamforming control, enabling intelligent autonomous network operations. Regarding service convergence, the simultaneous provision of sensing and communication is essential for major 6G application services such as autonomous driving, digital twins, and extended reality (XR), and ISAC can provide the key means to achieve this. In terms of energy and cost efficiency, 6G places emphasis on sustainability and efficiency, and ISAC's signal and hardware reuse structure directly meets these requirements. In conclusion, ISAC is establishing itself as a core technology for achieving functional scalability and infrastructure efficiency in 6G systems; accordingly, active theoretical and experimental research is underway in academia as well as in the industry for commercialization. ISAC technology is expected to serve as the foundation for realizing intelligent networks that combine communication and environmental awareness in the 6G era.

[0107] Various use cases for ISAC technology are being discussed. ISAC technology is recognized as having high potential for application, particularly in Unmanned Aerial Vehicles (UAVs) and industrial automation environments. Representative examples include drone tracking and positioning, real-time positioning of autonomous mobile robots, collision avoidance, and environmental monitoring for autonomous driving. These use cases require high-precision localization and dynamic object detection, demonstrating the potential to efficiently integrate sensing functions onto existing communication infrastructure through ISAC technology.

[0108] Furthermore, the application of ISAC technology in areas of daily life and public services, such as healthcare, transportation, and consumer services, is discussed. In the healthcare sector, contactless sleep monitoring, health monitoring, and sensing-assisted accessibility services are included. In the transportation sector, use cases applicable to V2X-based Intelligent Transportation Systems (ITS), such as surrounding object detection, intersection monitoring, blind spot detection, and parking space detection, are discussed. In addition, services aimed at enhancing next-generation consumer experiences, such as gesture recognition-based interaction, sports movement monitoring, and XR-based immersive streaming, are also mentioned.

[0109] Finally, environmental monitoring and security are also discussed as application areas for ISAC technology. Representative applications include real-time environmental detection based on smart cities, such as rainfall detection and urban flood monitoring, as well as intrusion detection systems in smart homes and public infrastructure. In particular, intrusion detection near critical infrastructure, such as power grids, and pedestrian / animal intrusion detection on highways demonstrate the feasibility of utilizing ISAC to ensure public safety. In addition, advanced application methods, such as sensor group formation that configures multiple sensor nodes to perform joint detection functions, are also being discussed.

[0110] The various sensing methods described above can be applied to devices such as base stations and terminals. Devices that perform transmission and reception operations for sensing may be base stations or terminals, and accordingly, a total of six sensing modes can be defined as follows.

[0111] [Mode #1] TRP monostatic: The same base station (or transmission point) acts as both the transmitter and receiver for sensing.

[0112] [Mode #2) UE monostatic: The same terminal acts as both the transmitter and receiver for sensing.

[0113] [Mode #3] TRP-TRP bistatic: Different base stations or transmission points each perform the roles of transmitter and receiver for sensing.

[0114] [Mode #4] UE-UE bistatic: Different terminals each perform the roles of transmitter and receiver for sensing.

[0115] [Mode #5] TRP-UE bistatic: The base station acts as the transmitter for sensing, and the terminal acts as the receiver for sensing.

[0116] [Mode #6] UE-TRP bistatic: The terminal acts as the transmitter for sensing and the base station acts as the receiver for sensing.

[0117] In the following, a procedure is described in which a terminal performs beam reporting that is triggered based on the detection of events, etc. In the following operations, PUCCH transmission or transmission via PUCCH includes transmission via resources allocated for PUCCH or resources allocated to PUCCH. PUSCH transmission or transmission via PUSCH includes transmission via resources allocated for PUSCH or resources allocated to PUSCH.

[0118] In the present disclosure, the operation of performing beam reporting when the UE satisfies a triggering condition set by the gNB may be referred to as UE-initiated / event-driven beam reporting (UEIBR). Here, the triggering condition of the UEIBR may be referred to as an event. The UEIBR operation may be performed based on the method illustrated in FIGS. 9 and 10.

[0119] FIG. 9 illustrates an example of a UEIBR procedure in Mode A according to one embodiment of the present disclosure. FIG. 10 illustrates an example of a UEIBR procedure in Mode B according to one embodiment of the present disclosure. In other words, in the present disclosure, the method of FIG. 9 may be expressed or referred to as Mode A, and the method of FIG. 10 may be expressed or referred to as Mode B.

[0120] For UEIBR operation, the gNB can configure a specific event, which is a triggering condition for UEIBR, to the terminal by using at least one or more combinations of higher layer signaling such as RRC (radio resource control) and SIB (system information block) or low layer signaling such as MAC-CE and DCI. Additionally, these events may be configured by association with at least one of a specific reference signal (RS) that the UE must measure for UEIBR execution or a specific PUCCH resource to be used for the 1st PUCCH in UEIBR operation. In the case of Mode B, the PUCCH resource configuration information may be configured by association with a predefined specific PUCCH resource to be used as the 2nd uplink (UL) channel. That is, the CSI resource / reporting configuration information required for UEIBR may be configured based on or associated with configuration information that includes at least one of a specific RS set, event, PUCCH resource, or predefined PUSCH resource (e.g., in the case of Mode B).

[0121] For convenience of explanation, the RRC parameter for configuring PUCCH resources for the UEIBR in this disclosure is referred to as firstPUCCHResourceConfig-UEIBR. The RRC parameter may include configuration information for PUCCH resources used for the UEIBR. Additionally, it may include some or all of the event configuration information for the UEIBR, or be associated with the event configuration information. In the case of Mode B, the firstPUCCHResourceConfig-UEIBR may include some or all of the PUCCH resource information, or be associated with such information. Furthermore, firstPUCCHResourceConfig-UEIBR may be configured in association with RS configuration information and CSI resource / report configuration information for the UEIBR. The aforementioned configuration information can be set by the gNB using at least one or more combinations of upper-layer signaling such as RRC and SIB, or lower-layer signaling such as MAC-CE and DCI, prior to the time of the 1st PUCCH transmission as shown in FIGS. 9 and 10. Subsequently, when the set event is satisfied, the UEIBR operation is triggered.

[0122] In the Mode A method of Fig. 9, the 1st PUCCH (e.g., Signaling A1 in Fig. 9) is a PUCCH requesting the allocation of a 2nd UL channel for UE-BR execution. Subsequently, the gNB can allocate a UL channel to be used for UEIBR via the DCI (e.g., Signaling A2 in Fig. 9). The UE performs UEIBR using the corresponding 2nd UL channel (e.g., Signaling A3 in Fig. 9). In other words, the UE 2 ndBeam reporting can be performed through a UL channel. Herein, the 2nd UL channel may include at least one of PUCCH or PUSCH. In the following, the operation of transmitting or receiving a signal, information, data, or report using a channel such as PUCCH or PUSCH, or the operation of the channel being transmitted or received, may be understood as the operation of transmitting or receiving a signal, information, data, or report using or on the resources allocated for the channel such as PUCCH or PUSCH.

[0123] In the Mode B method of Fig. 10, the 1st PUCCH (e.g., signaling B1 in Fig. 10) is transmitted to notify the gNB that the UE intends to use the previously allocated or defined 2nd UL channel for UEIBR execution. Subsequently, UEIBR is executed using the previously allocated or defined 2nd UL channel (e.g., signaling B2 in Fig. 10). In other words, the terminal 2 nd Beam reporting can be performed through the UL channel. Here, the 2nd UL channel may include at least one of PUCCH or PUSCH.

[0124] For convenience of explanation, PUSCH is described below as an example of a 2nd UL channel. However, the contents of the present disclosure may be applied in a simple, modified, extended, or combined form even when the 2nd UL channel is PUCCH.

[0125] PUCCH resources for UEIBR can be configured and operated as dedicated resources, separate from PUCCH resources based on existing resource allocation methods. Here, firstPUCCHResourceConfig-UEIBR can be operated as dedicated PUCCH configuration information for Mode A and Mode B, or as a single PUCCH configuration information without distinction between modes. If dedicated PUCCH resources are configured for each mode of UEIBR, for the sake of convenience of explanation, the PUCCH configuration information for Mode A may be referred to as firstPUCCHResourceConfig-ModeA-UEIBR, and the PUCCH configuration information for Mode B may be referred to as firstPUCCHResourceConfig-ModeB-UEIBR.

[0126] When multiple events for UEIBR are configured for a single terminal, the UE can determine whether the event is satisfied by measuring the RSs associated with each event. The RSs configured for each event may differ from one another. Alternatively, some or all of the configured RSs may be identical. Difference or identicalness of RSs may refer to differences or identicality in the TCI states associated with each RS, or differences or identicality in the beams applied to each RS transmission and reception.

[0127] In the following, procedures for performing UEIBR operations are described. These operations may be performed in combination with the embodiments described below. Alternatively, some or all of the operations may be replaced by the embodiments described below.

[0128] FIG. 11 illustrates a terminal procedure of UEIBR operation according to one embodiment of the present disclosure. FIG. 11 illustrates a procedure performed by a terminal.

[0129] Referring to FIG. 11, in step S1101, the terminal receives configuration information from the base station. The configuration information may be received by at least one of RRC signaling, MAC CE, or DCI. The configuration information may include information about a reference signal, information about an event, and information related to a resource. Here, the reference signal may include CSI-RS. The information about the event may include the type of event or a threshold value based on the type of event. For example, the type of event may include at least one of Event #1, Event #2, or Event #3.

[0130] Event #1: When the current beam quality is worse than a specific threshold

[0131] (Or, if the current beam quality is lower or worse than the standard quality.)

[0132] (Or, if an indicator indicating the quality of the current beam is lower or higher than a specific threshold, indicating that the quality of the current beam is lower or worse than the reference quality. Here, the indicator indicating the quality of the current beam may represent, for example, at least one of RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), SINR (Signal to Interference plus Noise Ratio), CQI (Channel Quality Indicator), PMI (Precoding Matrix Indicator), or RI (Rank Indicator).)

[0133] Event #2: When there is at least one new beam with better beam quality than the beam currently in use

[0134] Event #3: If there is at least one new beam with a better beam quality than the beam corresponding to the RS associated with the TCI state having the Kth best beam quality among the activated TCI states

[0135] For reference, in this specification, Event #1 may be referred to in various ways such as "first event," "a first event," or "Event 1," Event #2 may be referred to in various ways such as "second event," "a second event," or "Event 2," and Event #3 may be referred to in various ways such as "third event," "a third event," or "Event 3."

[0136] In one embodiment, information related to resources may include information related to PUCCH resources. For example, PUCCH resources may include resources dedicated to UEIBR operation. In other words, they may include PUCCH resources that are available in common for Mode A and Mode B. Alternatively, PUCCH resources may include at least one of resources for Mode A or resources for Mode B. Information related to resources may further include information regarding PUCCH resources for Mode B.

[0137] In step S1103, the terminal detects an event and triggers a beam report based on the event detection. The terminal may count event instances based on the event detection and trigger a beam report when the event instance counter reaches a defined number of times. For example, event instances may be counted only within a measurement window. In one example, at least one of the event instance counter or the measurement window may be initialized when a specific condition is satisfied. For example, the measurement window (or parameters associated with the measurement window) may be initialized after a beam report. When a beam report is triggered, the terminal may determine an operation mode for UEIBR operation. For example, the operation mode may include Mode A or Mode B. The operation mode may be determined based on configuration information associated with the detected event. For example, the operation mode may be determined as the mode indicated by the configuration information associated with the detected event.

[0138] In step S1105, the terminal performs a UEIBR operation based on the operation mode. Here, the UEIBR operation may include the operation illustrated in FIG. 9 or FIG. 10. In other words, the UEIBR operation may include at least one of beam reporting, signaling for performing beam reporting, or receiving DCI for resource allocation. The UEIBR operation may be performed based on configuration information. For example, if Mode A is determined as the operation mode in step S1103, the terminal may request resources for beam reporting from the base station based on information regarding resources included in the configuration information. As another example, if Mode B is determined as the operation mode in step S1103, the terminal may notify the base station to perform beam reporting based on information regarding resources included in the configuration information. If the operation mode is Mode A, the terminal may perform beam reporting based on resources allocated by the DCI. If the operation mode is Mode B, the terminal may perform beam reporting using resources configured by the configuration information. Multiple UEIBR triggerings occur, and during the execution of the corresponding UEIBR, in Mode A, the DCI may include information indicating which event corresponds to the beam reporting information. In Mode B, a multiplexing method for one or more beam reports can be determined based on the size of the pre-configured PUSCH resource.

[0139] FIG. 12 illustrates a base station procedure of UEIBR operation according to one embodiment of the present disclosure. FIG. 12 illustrates a procedure performed by a base station.

[0140] Referring to FIG. 12, in step S1201, the base station transmits configuration information to the terminal. The configuration information may be transmitted by at least one of RRC signaling, MAC CE, or DCI. The configuration information may include information about a reference signal, information about an event, and information related to resources. Here, the reference signal may include CSI-RS. The information about the event may include the type of event or a threshold value based on the type of event. For example, the type of event may include at least one of Event #1, Event #2, or Event #3. The information related to resources may include information related to PUCCH resources. For example, the PUCCH resources may include resources dedicated to UEIBR operation. In other words, they may include PUCCH resources that are available in common for Mode A and Mode B. Alternatively, the PUCCH resources may include at least one of resources for Mode A or resources for Mode B. The information related to resources may further include information regarding PUCCH resources for Mode B.

[0141] In step S1203, the base station receives signaling according to the operation mode. Here, the signaling according to the operation mode may include a resource request message for beam reporting based on Mode A or a beam reporting notification based on Mode B. The signaling according to the operation mode may be received via PUCCH. Here, the PUCCH resource for signaling may be a resource indicated by information related to the resource included in the configuration information. The PUCCH resource may include a resource for Mode A, a resource for Mode B, or a dedicated resource for UEIBR operation common to the modes. If a resource request message based on Mode A is received, the base station may allocate a resource for beam reporting to the terminal. For example, the base station may transmit a DCI indicating a resource for beam reporting to the terminal.

[0142] In step S1205, the base station receives a beam report. The beam report may be received based on resources allocated by the base station using DCI or resources pre-configured by the base station using configuration information. In other words, the beam report may be received based on the terminal's operating mode. For example, if a resource request message based on Mode A is received, the base station may receive a beam report based on resources allocated using DCI. As another example, if a resource request message based on Mode B is received, the base station may receive a beam report based on resources pre-configured using configuration information.

[0143] Detailed embodiments for performing UEIBR operations are described below. The embodiments described below may be performed as part of the aforementioned procedures. For example, each embodiment may be performed as part of the operation of receiving the configuration information of FIGS. 11 and FIGS. 12. Each embodiment may be performed alone, or alternatively, in combination with other embodiments or other methods.

[0144] FIG. 13 illustrates a beam reporting procedure based on a plurality of beam reporting triggerings according to one embodiment of the present disclosure.

[0145] FIG. 13 includes steps S1301 to S1305, but some embodiments of the present invention may be performed with some steps S1301 to S1305 omitted or with some operation methods added.

[0146] A terminal according to one embodiment may receive configuration information from a base station. The configuration information may include, for example, information indicating a beam reporting method when beam reporting triggering occurs based on a plurality of events. The configuration information may be transmitted to the terminal based on upper layer signaling. Upper layer signaling may mean, for example, the transmission of control information through an upper protocol layer (L2 or L3). The reception of the configuration information may occur before step S1301 is performed, or may occur in connection with at least one of steps S1301 to S1303.

[0147] Referring to FIG. 13, in step S1301, the terminal triggers a plurality of beam reports. Here, the operation of the terminal triggering the beam reports may include the operation of the terminal confirming, acknowledging, recognizing, judging, or deciding that a beam report is triggered because a plurality of events are satisfied. The triggering of the beam report may be performed based on an event instance counter. The triggering of the beam report may be referred to as event triggering.

[0148] In step S1303, the terminal obtains information indicating the beam reporting method. As previously described, the reception of the information indicating the beam reporting method may be performed prior to step S1301, performed in step S1303, or omitted. Here, the beam reporting method may include at least one of the number of beam reports, the priority of events, or whether the beam reports are multiplexed. The information indicating the beam reporting method may be obtained by an explicit or implicit method. In other words, the beam reporting method may be explicitly indicated or implicitly indicated. For example, the information indicating the beam reporting method may be obtained from the size or number of PUSCH resources indicated by at least one DCI. As another example, the information indicating the beam reporting method may be implicitly obtained from at least one of the pre-configured size or number of PUSCH resources.

[0149] With respect to step S1303, in one example, some embodiments of the present invention may be performed without instructions regarding the beam reporting method.

[0150] In step S1305, the terminal transmits beam reports based on the specified beam reporting method. The terminal may determine the number of beam reports to transmit based on the beam reporting method. For example, if two PUSCH resources are allocated by one DCI, the terminal may decide to transmit two beam reports. As another example, the number of beam reports may be explicitly specified by one DCI. As yet another example, the terminal may determine the number of beam reports or whether to multiplex based on the size of the PUSCH resources. Among multiple beam reports, a beam report with a higher priority may be transmitted preferentially over other beam reports. Alternatively, among multiple beam reports, a beam report with an earlier triggering time may be transmitted preferentially over other beam reports.

[0151] Hereinafter, detailed embodiments for carrying out the procedure of FIG. 13 are described. The following embodiments may be included in some steps of the procedure of FIG. 13 or may be extensions of some steps of the procedure of FIG. 13. For example, Method #1 may be part of step S1303 or may be a detailed description of step S1303. As another example, Method #1-1 may be part of step S1303 or may be a detailed description of step S1303.

[0152] Example #1

[0153] FIG. 14 illustrates an example of transmitting a plurality of beam reporting information in UEIBR Mode A according to an embodiment of the present disclosure. Referring to FIG. 14, when the same 1st PUCCH resource is set or allocated for a plurality of events, if the plurality of events are satisfied simultaneously, the terminal may need to use the 1st PUCCH at the same time (e.g., PUCCH #2 of FIG. 14). In FIG. 14, two events are satisfied at a time between the predefined 1st PUCCH resources (e.g., PUCCH #1 and PUCCH #2 of FIG. 14), and the UEIBR corresponding to each event is triggered. In this case, the terminal must use PUCCH #2 for 1st PUCCH transmission.

[0154] In contrast, there may be cases where multiple beam report information needs to be transmitted via the 2nd PUSCH. In this case, operation can be performed in the following manner.

[0155] Method #1: In UEIBR Mode A, if multiple bits can be transmitted via the 1st PUCCH, information regarding multiple triggered events can be transmitted through the multi-bit PUCCH. That is, at least one of the following can be transmitted: information regarding which of the configured events has been triggered, or a request for a resource allocation for a 2nd UL channel to perform beam reporting corresponding to each triggered event. For the sake of convenience of explanation, it is assumed that two events have been triggered.

[0156] When two events are triggered, the gNB can allocate and operate PUSCH through DCI in the following ways.

[0157] Method #1-1: FIG. 15 illustrates an example of a multiplexing beam reporting procedure in Mode A according to one embodiment of the present disclosure. Referring to FIG. 15, one PUSCH is assigned using one DCI, and one or two beam reporting information can be transmitted through the PUSCH. Here, the DCI may include instruction information regarding which event(s) correspond to the beam information(s) to transmit through the PUSCH.

[0158] For example, an explicit instruction method may include instructions to perform UEIBR for specific events via a bit field within the DCI. When UEIBR performance corresponding to two events is commanded, beam reporting for one or both of the two events may be instructed as shown in Table 3. In the example in Table 1, '11' is marked as reserved, but alternatively, '11' may indicate that no beam reporting is performed. The example in Table 3 is for the case where two events are triggered, but alternatively, when at least one of the set number of triggering events, the maximum number of set triggering events, the number of triggered events, or the maximum allowable number of concurrent beam reports is set, the bit field within the DCI may be set in various ways other than the method shown in Table 3, and instructions may be given to perform beam reporting corresponding to specific events.

[0159] Bit Indicator Instruction Content 00 Perform beam reporting corresponding to Event #1 01 Perform beam reporting corresponding to Event #2 10 Perform beam reporting corresponding to Event #1 and #2 11 Reserved

[0160] As another example, the implicit instruction method may include instructions regarding whether to multiplex multiple beam reports based on the size of the PUSCH resources allocated within the DCI. For instance, an implicit instruction regarding the transmission of a single beam report or the multiplexing of one or more beam reports may be performed using a scheduled PUSCH based on the size of the time and frequency PUSCH resources allocated within the DCI and MCS (Modulation and coding scheme) information. That is, the UE can determine whether it can send only one beam report or is allocated to send one or more beam reports based on a comparison of the maximum payload size required for a beam report for each event and the time and frequency resources of the scheduled PUSCH. In other words, the terminal can determine the number of beam reports that can be transmitted based on a comparison of the maximum payload size for a beam report associated with a single event and the allocated PUSCH resources.

[0161] Since the implicit indication via the PUSCH resource size above is an indication of whether to multiplex beam reporting for specific events rather than a multiplexing indication, the above DCI may additionally include indication information indicating specific events. Such indication information may include simple, modified, or extended forms such as those in Table 1.

[0162] Alternatively, the UE may prioritize and report specific events based on at least one of event priority or the time of event triggering. For example, if the PUSCH resource is allocated to multiplex two beam reports and three events are triggered, beam reports corresponding to the two events may be multiplexed and transmitted in order of highest priority. Alternatively, events may be selected based on the order of most recently triggered events or the order of the earliest time of event triggering, rather than event priority, and beam reports corresponding to those events may be multiplexed and transmitted.

[0163] Additionally, if multiple events are triggered and the size of the PUSCH resource allocated through the DCI can only transmit a single beam report, then among the multiple events, only the beam report corresponding to a single event can be transmitted via PUSCH based on the event directed by the DCI, the priority between events, or the time at which the event was triggered.

[0164] Additionally, if a PUSCH resource is allocated for a single beam report transmission, the gNB can configure the PUSCH resource to support the largest payload size per beam report format corresponding to the triggered event directed via PUCCH.

[0165] Alternatively, if PUSCH resource allocation is assigned for a single beam report transmission, the gNB may allocate PUSCH resources to support the largest payload size during beam reporting among the configured or configurable events for the UEIBR.

[0166] The reason for setting the size of the resource with the largest payload among the beam reporting formats when allocating a single PUSCH resource in the above operation is to enable the UE to perform beam reporting for a specific event according to defined settings or instructions, even in a situation where it is unknown which event-related beam reporting will be performed by the UE until the gNB allocates the PUSCH resource via the DCI.

[0167] The above method #1-1 is proposed in a form where, in cases where multiple bits can be transmitted via the 1st PUCCH, triggering information for specific events is transmitted to the gNB, and the DCI subsequently transmitted by the gNB may include instruction information regarding which event(s) correspond to the beam information(s) to transmit via PUSCH. However, method #1-1 can also be applied even when the 1st PUCCH can only transmit 1 bit of information. However, in this case, since the gNB cannot know how many events have been triggered when allocating the PUSCH resource via the DCI, if the gNB intends to allow multiplexing when multiple events are triggered, it may allocate the size of the PUSCH resource to enable two or more beam reports. At this time, since the gNB can at least know the information regarding the multiple events configured for the UE, it can perform allocation of the PUSCH resource with a size capable of supporting all beam reports by considering the beam reporting format for each event.

[0168] Additionally, the gNB can set the maximum number of multiplexable beam reports via PUSCH resources. This setting can be performed using higher-layer signaling such as RRC.

[0169] In addition, at least one of the instruction information or setting information regarding which event the beam report information is for may be transmitted through each 2nd UL channel, PUSCH, or the MAC-CE corresponding to the PUSCH.

[0170]

[0171] Method #1-2: FIG. 16 illustrates a beam reporting procedure using a plurality of PUSCHs in Mode A according to one embodiment of the present disclosure. Referring to FIG. 16, two PUSCHs are assigned to a single DCI, and beam information corresponding to each event can be transmitted to the corresponding PUSCHs. Here, the DCI may include instruction information regarding which event each PUSCH transmits beam information corresponding to.

[0172] The indication method using DCI can define and operate a bit field that indicates which event each of the two PUSCH resource scheduling information corresponds to. When two events are configured and operated, and both events are triggered, the corresponding event can be indicated through a 1-bit indicator mapped to each PUSCH scheduling resource. The bit field can be defined and operated in various forms and sizes depending on the number of configurable events, the number of configured events, the number of triggered events, or the maximum number of PUSCH schedulings allowed through a single DCI.

[0173] Alternatively, the UE may prioritize and report specific events based on at least one of event priority or the time of event triggering. For example, if 2 PUSCHs are allocated and 3 events are triggered, beam reports corresponding to the 2 events in order of highest priority may be sent sequentially through the 2 PUSCHs. Alternatively, events may be selected based on the order of most recently triggered events or the order of the earliest time of event triggering, rather than event priority, and beam reports corresponding to those events may be sent sequentially through the 2 PUSCHs.

[0174] Additionally, when multiple events are triggered and only one PUSCH is allocated via the DCI, only the beam report corresponding to one event among the multiple events may be reported via the PUSCH based on at least one of the event directed by the DCI, the priority between events, or the time at which the event was triggered. Alternatively, when multiple events are triggered and only one PUSCH is allocated via the DCI, Method #1-1 may be applied based on the size of the PUSCH resource allocated via the DCI. That is, based on the size of the PUSCH resource, the multiplexing of beam reports within the PUSCH can be implicitly indicated. In this case, the DCI may include instruction information regarding specific high-priority events or events subject to multiplexing.

[0175] Additionally, when allocating PUSCH resources for a single beam report transmission, the gNB can configure the PUSCH resources to support the largest payload size per beam report format corresponding to the triggered event directed via PUCCH.

[0176] Alternatively, when allocating PUSCH resources for a single beam report transmission, the gNB may allocate PUSCH resources to support the largest payload size during beam reporting among the configured events for UEIBR or the configurable events.

[0177] The reason for setting the size of the resource with the largest payload among the beam reporting formats when allocating a single PUSCH resource in the above operation is to enable the UE to perform beam reporting for a specific event according to defined settings or instructions, even in a situation where the gNB does not know which event-related beam reporting will be performed by the UE until the time of PUSCH resource allocation via DCI.

[0178] The above method #1-2 is proposed in a form where, in the case where multiple bits can be transmitted via the 1st PUCCH, triggering information for specific events is transmitted to the gNB, and the DCI subsequently transmitted by the gNB may include instruction information regarding which event(s) correspond to beam information(s) to transmit via each PUSCH. However, method #1-2 can also be applied even when the 1st PUCCH can only transmit 1 bit of information. However, in this case, since the gNB cannot know how many events have been triggered when allocating PUSCH resources via the DCI, if the gNB intends to allow multiplexing when multiple events are triggered, it may schedule two or more PUSCHs. Here, since the gNB can know information about the multiple events configured for the UE at least, it can allocate PUSCH resources of a size capable of supporting all beam reporting by considering the beam reporting format for each event.

[0179] In addition, the gNB can set the maximum number of scheduleable PUSCHs via DCI. This setting can be performed using higher-layer signaling such as RRC.

[0180] In addition, at least one of the instruction information or setting information regarding which event the beam report information is for may be transmitted through each 2nd UL channel, PUSCH, or the MAC-CE corresponding to the PUSCH.

[0181]

[0182] Method #1-3: FIG. 17 illustrates a beam reporting procedure using a plurality of DCIs according to one embodiment of the present disclosure. Referring to FIG. 17, two PUSCH channels may be allocated and operated through two DCI transmissions for two triggered events. That is, each DCI may include resource allocation information for each PUSCH. Additionally, each DCI may include instruction information indicating which event corresponds to the beam reporting information. That is, instruction information regarding which triggered event corresponds to the PUSCH scheduled through the DCI may be included.

[0183] When two events are configured and operated, and both events are triggered, the corresponding event among the two can be indicated through a 1-bit indicator mapped to a PUSCH resource scheduled through each DCI. Here, the bit field can be defined and operated in various forms and sizes depending on the number of configurable events, the number of configured events, the number of triggered events, etc.

[0184] Alternatively, the UE may prioritize a specific event and perform beam reporting based on at least one of event priority or the time of event triggering. For example, if two PUSCHs are allocated and three events are triggered, beam reports corresponding to the two events in order of highest priority may be transmitted sequentially through two DCIs and each PUSCH scheduled through those DCIs. In other words, a beam report corresponding to a higher priority event may be transmitted through the DCI that is transmitted first and the PUSCH scheduled by it. Alternatively, events may be selected based on the order of most recent event triggering or the order of the time of event triggering, rather than event priority, and beam reports corresponding to those events may be transmitted sequentially through two DCIs and each PUSCH scheduled through those DCIs.

[0185] Additionally, if multiple events are triggered and only one PUSCH is assigned through a single DCI, among the multiple events, only the beam report corresponding to the event directed by the said DCI, or the beam report corresponding to a single event based on the priority between events or the time at which the event was triggered, may be reported through the PUSCH.

[0186] Additionally, when allocating PUSCH resources for a single beam report transmission, the gNB can configure the PUSCH resources to support the largest payload size per beam report format corresponding to the triggered event directed via PUCCH.

[0187] Alternatively, when allocating PUSCH resources for a single beam report transmission, the gNB may allocate PUSCH resources to support the largest payload size during beam reporting among the configured events for the UEIBR or the configurable events.

[0188] The reason for setting the size of the resource with the largest payload among the beam reporting formats when allocating a single PUSCH resource in the above operation is to enable the UE to perform beam reporting for a specific event according to defined settings or instructions, even in a situation where the gNB does not know which event-related beam reporting will be performed by the UE until the time of PUSCH resource allocation via DCI.

[0189] The above method #1-3 is proposed in a form where, when multiple bits can be transmitted via the 1st PUCCH, triggering information for specific events is transmitted to the gNB, and each DCI subsequently transmitted by the gNB may include instruction information regarding which event(s) correspond to beam information(s) to transmit via PUSCH. However, method #1-3 can also be applied even when only 1 bit information transmission is possible via the 1st PUCCH. However, in this case, since the gNB cannot know how many events have been triggered when allocating PUSCH resources via the DCI, if the gNB intends to allow multiplexing when multiple events are triggered, it may schedule two or more PUSCHs. At this time, since the gNB can at least know the information regarding the multiple events configured for the UE, it can allocate PUSCH resources in a size capable of supporting all beam reporting by considering the beam reporting format for each event.

[0190] In addition, at least one of the instruction information or setting information regarding which event the beam report information is for may be transmitted through each 2nd UL channel, PUSCH, or the MAC-CE corresponding to the PUSCH.

[0191] In the procedure of FIG. 17, if the UE fails to receive one of the two DCIs or fails to decode it, it may be possible to transmit a single beam report through the PUSCH assigned via the successful DCI. In this case, the single beam report may be a beam report corresponding to an event indicated by the DCI, or a beam report corresponding to a higher priority event among multiple events.

[0192]

[0193] In the above methods #1-1 to #1-3, DCI may use DCI 0_0, 0_1 for PUSCH resource configuration, and a new field may be set within the corresponding DCI field or an existing field may be reused. Alternatively, a new DCI format may be defined and operated. Here, DCI 0_0, 0_1 may refer to DCI formats 0_0, 0_1, respectively.

[0194] The above methods #1-1 to #1-3 can be operated in modified, extended, or combined forms, and each method is an example of a case where two events are triggered, but can also be applied in a simple, modified, extended, or combined form when two or more two events are triggered.

[0195]

[0196] Method #2: Operational method for transmitting multiple beam report information in UEIBR Mode B

[0197] In the case of UEIBR Mode B, the 1st UL channel PUCCH and the 2nd UL channel pre-configured PUSCH can be configured with a one-to-one mapping. In this case, to support multiple beam reports, the pre-configured PUSCH resource can be allocated and configured to a size capable of supporting multiple beam reports, taking into account the number of events associated with the PUCCH resource.

[0198] The UE can determine whether to multiplex based on the size of the pre-configured PUSCH resource. When selecting beam reports to be multiplexed, the UE can prioritize and report specific events based on event priority or the time of event triggering. In other words, the terminal can select the event to be multiplexed or the beam reports associated with the event based on event priority or the time of event triggering. For example, if the PUSCH resource is allocated to multiplex transmit information for two beam reports, and three events are triggered, beam reports corresponding to the two events can be multiplexed and transmitted in order of highest priority. Alternatively, events can be selected based on the order of most recent triggering or the order of the time of event triggering, rather than event priority, and beam reports corresponding to those events can be multiplexed and transmitted.

[0199] Additionally, if multiple events are triggered and the size of the PUSCH resource can only transmit one beam report, only the beam report corresponding to one event can be reported via PUSCH based on at least one of the priority between the multiple events or the time at which the event was triggered.

[0200] Additionally, when allocating PUSCH resources for a single beam report transmission, the gNB can configure the PUSCH resources to support the largest payload size per beam report format corresponding to the triggered event directed via PUCCH.

[0201] Alternatively, when allocating PUSCH resources for a single beam report transmission, the gNB may allocate PUSCH resources to support the largest payload size during beam reporting among the configured events for the UEIBR or the configurable events.

[0202] The reason for setting the size of the resource with the largest payload among the beam reporting formats when allocating a single PUSCH resource in the above operation is to enable the UE to perform beam reporting for a specific event according to defined settings or instructions, even in a situation where the gNB does not know which event-related beam reporting will be performed by the UE until the time of PUSCH resource allocation via DCI.

[0203] Additionally, the gNB can set and manage the maximum number of multiplexable beam reports via PUSCH resources. This setting can be performed using higher-level signaling such as RRC.

[0204] In addition, at least one of the instruction information or setting information regarding which event the beam report information is for may be transmitted through each 2nd UL channel, PUSCH, or the MAC-CE corresponding to the PUSCH.

[0205]

[0206] Example #2

[0207] When performing multiple UEIBRs using a single 2nd PUSCH, the terminal may remove redundant information from the report information to efficiently multiplex the report information corresponding to each event. Table 2 is an example of a report format. When a UEIBR is triggered by a specific event, the report information may include at least one of the following: ID information of the highest quality beam, e.g., CRI (CSI-RS resource indicator) or SSBRI (synchronization signal block resource indicator) information, L1-RSRP information obtained through the corresponding RS measurement, or information regarding whether the beam satisfied the event. In this case, the event satisfaction can be indicated by a 1-bit indication. In other words, event satisfaction can be indicated using 1 bit. In Table 2, '1' indicates that the beam satisfied the event condition.

[0208] UEIBR triggering is performed when instances satisfying a configured event occur a certain number of times or more. Here, the counting of instances satisfying the event is referred to as event instance counting. The bit indicating whether the event is satisfied above may indicate that the event instance for the corresponding beam has been counted a number of times or more. In other words, if the bit value indicating whether the event is satisfied is 1, it may indicate that the event instance counting has reached a configured number. Conversely, if the bit value indicating whether the event is satisfied is 0, it may indicate that the event instance counting has reached a configured number.

[0209] Table 4 is an example in which information for a total of N beams is reported, and the L1-RSRP of the beams after the first beam is transmitted as the differential value with respect to the L1-RSRP of the first beam. Additionally, if the RRC is configured to send the L1-RSRP for the current beam, the L1-RSRP information of the current beam can be sent.

[0210] Beam ID(RS resource index)Beam qualityEventSatisfiedCRI or SSBRI #1L1-RSRP #1'1'CRI or SSBRI #2Differential L1-RSRP #2'1'… CRI or SSBRI #NDifferential L1-RSRP #N'0'N / ADifferential L1-RSRP for current beamN / A

[0211] Table 4 is an example of sending the event satisfaction status of the first beam. However, if the first beam sends the best quality beam, the beam is the one that triggered the UEIBR, so the instruction regarding the event satisfaction status may not be included in the UEIBR.

[0212] The following methods can be applied for efficient multiplexing of multiple beam reports.

[0213] Method #3: When the transmission of current beam information is enabled for multiple events, only one piece of current beam information may be included and transmitted during multiplexing via PUSCH. In this case, the corresponding current beam information may be included in the first beam report among the multiple beam reports and transmitted. Alternatively, the current beam report may be transmitted via a resource at a specific location within PUSCH, and that location may follow mapping rules for the multiple beam report information.

[0214] Method #4: If all or part of the RS settings configured for multiple events are identical, duplicate beam information may be excluded or omitted during multiplexing via PUSCH.

[0215] Method #5: When transmitting multiple beam report information, a single reference L1-RSRP may be selected for differential L1-RSRP transmission, and this L1-RSRP may be the highest quality beam among the beams transmitted through the multiple beam reports. Additionally, information regarding the beam report containing the highest quality beam may be mapped first within the PUSCH resource.

[0216] For the sake of convenience of explanation, let us assume that two UEIBRs with the reporting format shown in Table 2 are multiplexed through a single PUSCH. Table 3 is an example where each UEIBR contains information for four beams, and each UEIBR is configured to transmit information for the current beam. Each differential L1-RSRP represents a differential value relative to the L1-RSRP of the first beam in each beam report. The L1-RSRP of the first beam in each beam report may be the highest quality beam in that beam report.

[0217] Beam ID(RS resource index)Beam qualityEventSatisfiedCRI or SSBRI #1L1-RSRP #1'1'CRI or SSBRI #2Differential L1-RSRP #2 for L1-RSRP #1'1'CRI or SSBRI #3Differential L1-RSRP #3 for L1-RSRP #1'0'CRI or SSBRI #4Differential L1-RSRP #4 for L1-RSRP #1'0'N / ADifferential L1-RSRP for current beam for L1-RSRP #1N / ACRI or SSBRI #5L1-RSRP #5'1'CRI or SSBRI #6Differential L1-RSRP #6 for L1-RSRP #5'0'CRI or SSBRI #7Differential L1-RSRP #7 for L1-RSRP #5'0'CRI or SSBRI #8Differential L1-RSRP #8 for L1-RSRP #5'0'N / ADifferential L1-RSRP for current beam for L1-RSRP #5N / A

[0218] Table 5 is an example of a format for sending all information for two UEIBRs. If Method #3 is applied in Table 3, the values ​​"Differential L1-RSRP for current beam for L1-RSRP #1" or "Differential L1-RSRP for current beam for L1-RSRP #5" may be excluded.

[0219] In Table 5, if CRI or SSBRI #2 and CRI or SSBRI #6 have the same ID and Method #4 applies, information for a single beam may be excluded. For example, "CRI or SSBRI #6" and "Differential L1-RSRP #6 for L1-RSRP #5", "0" may be excluded. Alternatively, bit information indicating whether an event has been satisfied may not be excluded and may be included in the beam report. This is an example for a single beam, but it may be applied equally to multiple beams.

[0220] When Method #5 is applied in Table 5 and L1-RSRP #5 is greater than L1-RSRP #1, beam reporting can be performed in the form of a report format as shown in Table 6. Table 4 is an example of the case where Method #3 is applied. In Table 6, as in Table 5, all differential L1-RSRPs are determined based on the highest quality L1-RSRP #5, and it is an example where beam reporting containing "CRI or SSBRI #5" within PUSCH is mapped first.

[0221] CRI or SSBRI #5L1-RSRP #5'1'CRI or SSBRI #6Differential L1-RSRP #6 for L1-RSRP #5'1'CRI or SSBRI #7Differential L1-RSRP #7 for L1-RSRP #5'0'CRI or SSBRI #8Differential L1-RSRP #8 for L1-RSRP #5'0'N / ADifferential L1-RSRP for current beam for L1-RSRP #5N / ACRI or SSBRI #1Differential L1-RSRP #1 for L1-RSRP #5'1'CRI or SSBRI #2Differential L1-RSRP #2 for L1-RSRP #5'0'CRI or SSBRI #3Differential L1-RSRP #3 for L1-RSRP #5'0'CRI or SSBRI #4Differential L1-RSRP #4 for L1-RSRP #5'0'N / AN / AN / A

[0222] Tables 2 through 4 are examples to show the types of information transmitted via PUSCH and their relative mapping locations. The mapping of actual information within PUSCH can be performed in various ways. For example, among multiple beam report information, beam ID information may be mapped first, followed by L1-RSRP values ​​corresponding to the beam ID information, and then event satisfaction indicator information corresponding to the beam ID information. Alternatively, beam ID information, L1-RSRP values, and event satisfaction for one beam report may be mapped in that order, followed by beam ID information, L1-RSRP values, and event satisfaction for another beam report.

[0223] Based on Table 4, the mapping method described above is a column-based mapping method; however, unlike this, the entire mapping can be performed row-based, by mapping the beam ID, L1-RSRP, and event satisfaction indicator information for one beam, and then mapping the beam ID, L1-RSRP, and event satisfaction indicator information for the next beam. In other words, information can be mapped to resources by field, or alternatively, by beam.

[0224] The above methods #3, #4, and #5 may be applied in simple, modified, extended, or combined forms, and depending on the form of the multiplexed report, information related to the applied multiplexing method may be indicated through the corresponding PUSCH or the MAC-CE of the PUSCH. The information related to the applied multiplexing method may include necessary information for the gNB to decode the multiplexed information and distinguish information regarding multiple beam reports without ambiguity, such as the form of a specific format among the report formats set for multiplexing of beam reports, what event the report is about, the order of the multiplexed events, the specific method applied during multiplexing (i.e., what duplicate information has been removed), the number of beams finally transmitted in each report, whether the L1-RSRP serving as the basis for differential L1-RSRP has been changed as in method #5, and the beam information serving as the basis for differential L1-RSRP.

[0225] When operating UEIBR Mode A of the present embodiment, if a reporting format is set and operated to perform multiplexing of multiple beam reports of the form of methods #3, #4, and #5, the DCI (e.g., signaling A2 in FIG. 9) may include instruction information indicating a specific reporting format.

[0226] When operating UEIBR Mode B of this embodiment, if a reporting format is set and operated to perform multiplexing of multiple beam reports of the form of methods #3, #4, and #5, the corresponding reporting format information can be operated in a form associated with a pre-set PUSCH.

[0227] FIG. 18 illustrates an event detection and time window initialization procedure according to one embodiment of the present disclosure. The procedure of FIG. 18 may be performed by a terminal. The procedure of FIG. 18 may be part of the procedure of FIG. 11 or may be performed in addition to the procedure of FIG. 11.

[0228] Referring to FIG. 18, at step S1801, the terminal may receive configuration information. Here, the configuration information may include a measurement window for event detection. The measurement window may be referred to as a time window. The time window may be associated with an event instance counter. The time window may be associated with an evaluation cycle. The time window may be configured per event. Alternatively, the time window may be common to the events.

[0229] In step S1803, the terminal can detect an event and increment the event instance counter. The terminal can increment the event instance counter based on the type of event. The event instance counter can be incremented only when the event is detected within a time window. Alternatively, the event instance counter can be incremented even when the event is detected outside the time window.

[0230] In step S1805, the terminal may initialize a time window. The initialization of the time window may be associated with the initialization of an event instance counter. For example, the time window may be initialized when the event instance counter is initialized. As another example, the time window may be initialized based on a timer. As yet another example, the time window may be initialized based on an evaluation cycle. As yet another example, the time window may be initialized based on an event type.

[0231] Example #3

[0232] A measurement window can be set and operated to perform UEIBR operations. Within the interval set by the measurement window, the terminal performs event instance counting based on the measurement results for the RSs set for UEIBR, and if the counting count exceeds the set number, UEIBR can be triggered and executed. That is, a 1st PUCCH transmission is performed.

[0233] For the sake of convenience of explanation, the set number of times is referred to as M. The start time of the measurement window may be the time of the initial RS transmission for the UEIBR, and the indication for the measurement window start time may be based on the evaluation periodicity of the event. That is, the measurement window may start in units of an evaluation period. Additionally, if an event is satisfied and the UEIBR is triggered, the measurement window may be terminated and restarted. The start time of the measurement window may be the earliest time of the RS transmission for the UEIBR since the window initialization point. Alternatively, the start time may be determined in units of an evaluation period. The measurement window may be performed as a timer-based operation, and the start and end of the timer may be interpreted as the start and end times of the measurement window.

[0234] The initialization of the above measurement window can be operated so that, in addition to UEIBR triggering upon event achievement, the window is also initialized and restarted upon event instance counting initialization. Alternatively, the window can be configured and operated to be initialized and restarted only under some of the event instance counting initialization conditions. In other words, the measurement window can be operated so that it is not initialized under certain event instance counting initialization conditions. Below is an example of event instance counting initialization conditions.

[0235] The conditions for initializing event instance counting may include cases where RS or beam reporting-related information configured for UEIBR is reconfigured, where the TCI pool or TCI list configured by RRC or MAC-CE is reconfigured, where a new TCI state is indicated by DCI and the current beam is updated, where a window expires without UEIBR triggering within a configured measurement window of a specific size, where a specific signaling procedure is initiated during the UEIBR operation procedure, or where configuration information related to the event (e.g., specific threshold values) is changed.

[0236] The size of the measurement window set above, or the expiry time of the timer when operating the timer for the measurement window, can be set and indicated by a combination of M, which is the number of event instance satisfactions set per event, and the evaluation period value. The size of the measurement window must be set to at least M * evaluation period so that it can be determined whether an event has been achieved through M measurements within a given window. Therefore, the size of the measurement window or the expiry time of the timer when operating the timer for the measurement window can be set and operated in the form of a multiple of M * evaluation period value. This value can be set using higher-level signaling such as RRC, and this setting information can be included as part of the CSI reporting setting information or set and operated in a form associated with the CSI reporting setting information.

[0237] Example #4

[0238] When multiple events are configured, the event instance counting initialization conditions may be configured and operated differently for each event. Alternatively, a common initialization condition for all events may be configured and operated. Alternatively, an event instance counting initialization condition for each event and an event instance counting initialization condition that applies commonly to all events may be configured and operated, respectively. The multiple events may include at least one of Event #1, Event #2, or Event #3 described above in the description of FIG. 11.

[0239] Since the aforementioned multiple configured events are operated under conditions associated with the current beam or the current TCI state configuration, the event instance counting corresponding to each event can be initialized as a common initialization condition applicable to the configured events when RS or beam reporting-related information configured for UEIBR is reset, when the TCI pool or TCI list configured by RRC or MAC-CE is reset, or when a new TCI state is indicated by DCI and the current beam is updated. At this time, these conditions can be operated in a manner that initializes all instance countings for each currently ongoing event together.

[0240] On the other hand, cases where the measurement window expires without UEIBR triggering can serve as an initialization condition applicable to all events. However, when the measurement window is configured and operated individually for each event, it can be operated in a way that initializes only the event instance count corresponding to the event corresponding to the expired measurement window.

[0241] In addition to the conditions commonly applicable to events as described above, event-specific initialization conditions may be utilized. For example, if the threshold setting value changes, the event instance counting of Event #1 may be initialized.

[0242] Therefore, for multiple events, event instance counting conditions can be configured and operated by separating them into event-specific conditions and common conditions. Additionally, some of the common conditions can be configured and operated as conditions to initialize the instance counting for all events. Other initialization conditions can be operated to initialize only the instance counting corresponding to the event that satisfies each condition.

[0243] Example #5

[0244] In order to efficiently and simply operate the setting and operation of at least one of the evaluation cycle, event instance counting, or measurement window for UEIBR by RRC, a single UE can set and operate the same evaluation cycle and measurement window size information.

[0245] In other words, a common evaluation cycle and measurement window can be set and applied to multiple events configured for a single UE. In this case, to maintain the same evaluation cycle and measurement window for each of the multiple events, when the initialization of a single event instance count occurs, all event instance counts are initialized, and a new measurement window can be created after the measurement window ends.

[0246] For example, if a single event is triggered within a commonly operated measurement window, the UEIBR corresponding to that event is executed, and the counting of all other event instances can be reset. In other words, it is possible to configure multiple events and operate them in a way that only one event can be triggered at a time.

[0247] Alternatively, if a single event is triggered within a measurement window, multiple events can be triggered depending on the settings and operation regarding the expiration time of the measurement window. That is, if a single event is triggered and subsequently another event is triggered before the expiration time of the measurement window or before the initialization time of event instance counting, UEIBR operations can be performed in response to the triggering of multiple events.

[0248] In the above example, the expiration time of the measurement window can be set and operated at the same time as the initialization time of the event instance counting.

[0249] In the above embodiments #3, #4, and #5, the event instance counting initialization point based on event satisfaction can be set to various points based on UEIBR operation standards, and accordingly, changes may occur in the reported beam information. If RS is measured up to the latest point in time, beam reporting may be possible including the most recent information. The event instance counting initialization point can be operated at the time when the measurement window ends, the start or end time of the evaluation period, the time of the 1st PUCCH transmission, the time of DCI reception (e.g., UL grant allocation DCI in Mode A), or the time of the 2nd PUSCH transmission.

[0250] For example, it can be operated to initialize instance counting and terminate the measurement window after measurement up to the evaluation cycle that includes the RS measurement point where the event is satisfied.

[0251] Alternatively, it can be operated to initialize instance counting and terminate the measurement window after RS ​​measurement up to the evaluation cycle prior to the PUCCH transmission point.

[0252] Alternatively, it can be operated to initialize instance counting and terminate the measurement window after RS ​​measurement up to the evaluation cycle prior to the PUSCH transmission point.

[0253] In the above example, the expiration time of the measurement window can be set and operated at the same time as the initialization time of the event instance counting.

[0254] The operation of the method according to the present disclosure can be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes all types of recording devices in which information that can be read by a computer system is stored. Additionally, a computer-readable recording medium may be distributed across networked computer systems, and a computer-readable program or code may be stored and executed in a distributed manner.

[0255] In addition, computer-readable recording media may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Program instructions may include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter.

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

[0257] A programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described in this disclosure. A field-programmable gate array may operate with a microprocessor to perform one of the methods described in this disclosure. In general, it is preferable that the methods be performed by some hardware device.

[0258] Although the present disclosure has been described with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the present disclosure without departing from the spirit and scope of the present disclosure as set forth in the following claims.

Claims

1. In a method of operation of a terminal in a wireless communication system, Step of receiving configuration information from a base station; A step of detecting at least one event based on the above setting information; Based on the detection of at least one event, a step of increasing an event instance counter associated with the detected event; A step of transmitting signaling through a PUCCH (physical uplink control channel) resource based on the event instance counter reaching a predefined value; and The method includes the step of transmitting at least one beam report via a PUSCH (physical uplink shared channel) resource, The above setting information includes information about the time window, and A method in which the detection of at least one event is performed within the time window.

2. In Paragraph 1, A method comprising the step of resetting the above time window.

3. In Paragraph 2, A method in which the above time window is initialized based on the initialization of the above event instance counter.

4. In Paragraph 3, A method wherein the above event instance counter is initialized based on the fulfillment of an initialization condition, wherein the initialization condition is initialized based on at least one of the reception of a reconfiguration message, an update of a TCI (transmission configuration indicator) state, the expiration of the time window, a change in the configuration information, or the transmission of the signaling.

5. In Paragraph 4, The above initialization condition is a method specific to the type of the above event.

6. In Paragraph 1, The method further includes the step of receiving DCI (downlink control information) based on the above signaling, and A method in which the above DCI includes information indicating the above PUSCH resource.

7. In Paragraph 1, A method in which at least one beam report is multiplexed based on the size of the PUSCH resource or the indication of the DCI.

8. In Paragraph 1, A method in which, when multiple event instance counters reach a predefined value, the signaling is transmitted based on the priority among the events.

9. In Paragraph 1, A method in which, when a plurality of event instance counters reach a predefined value, the signaling is transmitted based on the time order in which the plurality of event instance counters reach the predefined value.

10. In Paragraph 1, The above beam report is a method comprising measurement results for a plurality of beams.

11. In Paragraph 10, A method in which the beam report includes at least one of a beam index of each of the plurality of beams, a beam quality, or an event satisfaction.

12. In Paragraph 11, A method in which the quality of the beam described above includes the difference between the current beam quality value and the measured beam quality value.

13. In Paragraph 1, A method comprising information regarding the time window, including information indicating the size of the time window.

14. In a method of operation of a base station in a wireless communication system, A step of transmitting configuration information to a terminal that includes information about at least one event; A step of receiving signaling from a terminal via a PUCCH resource; and The step of transmitting at least one beam report through a PUSCH resource, wherein The above signaling is transmitted by the terminal based on the event instance counter reaching a predefined value, and The above event instance counter is incremented based on the detection of at least one event, and The above setting information includes information about the time window, and A method in which the detection of at least one event is performed within the time window.

15. In Paragraph 14, A method further comprising the step of initializing the above time window.

16. In Paragraph 15, A method in which the above time window is initialized based on the initialization of the above event instance counter.

17. In Paragraph 16, A method wherein the above event instance counter is initialized based on the fulfillment of an initialization condition, wherein the initialization condition is initialized based on at least one of the reception of a reset message, an update of a TCI state, the expiration of the time window, a change in the setting information, or the transmission of the signaling.

18. In Paragraph 17, The above initialization condition is a method specific to the type of the above event.

19. In a terminal of a wireless communication system, At least one transmitter / receiver; At least one processor; and It includes at least one memory connected to the above-mentioned at least one processor to enable operation and storing instructions that control the terminal to perform operations when executed by the processor, and The above operations are, Step of receiving configuration information from a base station; A step of detecting at least one event based on the above setting information; Based on the detection of at least one event, a step of increasing an event instance counter associated with the detected event; A step of transmitting a signaling through a PUCCH resource based on the event instance counter reaching a predefined value; and The step of transmitting at least one beam report through a PUSCH resource, wherein The above setting information includes information about the time window, and A terminal in which the detection of at least one event is performed within the time window.

20. In a base station of a wireless communication system, At least one transmitter / receiver; At least one processor; and It includes at least one memory connected to operately with the above-mentioned at least one processor and storing instructions that control the base station to perform operations when executed by the processor, and The above operations are, A step of transmitting configuration information to a terminal that includes information about at least one event; A step of receiving signaling from a terminal via a PUCCH resource; and The step of transmitting at least one beam report through a PUSCH resource, wherein The above signaling is transmitted by the terminal based on the event instance counter reaching a predefined value, and The above event instance counter is incremented based on the detection of at least one event, and The above setting information includes information about the time window, and A base station in which the detection of at least one event is performed within the time window.