User equipment, device for user equipment, base station, and method and storage medium performed thereby

Abstract

This application relates to user equipment, devices for user equipment, base stations, methods for performing the same, and storage media. A method for transmitting PUCCH in a wireless communication system, a de-capped terminal, and a base station are disclosed. The method for transmitting PUCCH according to embodiments of this disclosure may include the following steps: receiving system information from the base station, wherein the system information includes first information regarding additional PRB offsets in a PRB mapping of PUCCH resources and second information regarding whether the PRB indexes in the PRB mapping are counted in ascending order from the lower edge of the initial BWP of the redcap terminal or in descending order from the upper edge of the initial BWP of the redcap terminal; receiving a DCI for scheduling PDSCH from the base station; receiving PDSCH from the base station; and transmitting HARQ-ACK information related to the PDSCH to the base station in the PUCCH.

Description

[0001] This application is a divisional application of the original invention patent application No. 202310144691.1 (filed on February 10, 2023, invention title: Method for transmitting PUCCH in a wireless communication system, reduced capability terminal and base station). Technical Field

[0002] This disclosure relates to a wireless communication system, and more specifically, to a method and apparatus for transmitting and receiving a physical uplink control channel (PUCCH) in a wireless communication system. Background Technology

[0003] A mobile communication system has been developed to provide voice services while ensuring user mobility. However, mobile communication systems have expanded to include data and voice services, and the current explosive growth in these services has led to resource shortages. Users are demanding faster services and therefore require more advanced mobile communication systems.

[0004] The overall requirements for next-generation mobile communication systems should be able to support the capacity for explosive data traffic, significantly increased per-user transmission rates, a significantly increased number of connected devices, very low end-to-end latency, and high energy efficiency. To this end, various technologies such as dual connectivity, massive MIMO, in-band full-duplex, non-orthogonal multiple access (NOMA), ultra-wideband support, and device networking have been investigated. Summary of the Invention

[0005] Technical issues

[0006] The technical objective of this disclosure is to provide methods and apparatus for transmitting and receiving Physical Uplink Control Channels (PUCCHs) for specific types of terminals (e.g., reduced capability terminals).

[0007] Additionally, an additional technical objective of this disclosure is to provide methods and apparatus for sending and receiving messages for a specific type of terminal (e.g., a degraded terminal) to perform a random access procedure.

[0008] The technical objectives to be achieved by this disclosure are not limited to those described above, and other technical objectives not described herein will be clearly understood by those skilled in the art through the following description.

[0009] Technical solution

[0010] A method for transmitting a Physical Uplink Control Channel (PUCCH) in a wireless communication system according to one aspect of this disclosure may include the following steps: receiving system information from a base station, wherein the system information includes first information regarding an additional PRB offset for a Physical Resource Block (PRB) mapping of PUCCH resources and second information regarding whether the PRB index in the PRB mapping is counted in ascending order from the lower edge of the Initial Uplink Bandwidth Part (BWP) of the redcap terminal or in descending order from the upper edge of the initial uplink BWP of the redcap terminal; receiving downlink control information (DCI) for scheduling a Physical Downlink Shared Channel (PDSCH) from the base station; receiving the PDSCH from the base station; and transmitting Hybrid Automatic Repeat Request (HARQ)-Acknowledgement (ACK) information associated with the PDSCH to the base station in the PUCCH. Based on the fact that frequency hopping for PUCCH transmission is disabled, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0011] A method for receiving a Physical Uplink Control Channel (PUCCH) in a wireless communication system according to an additional aspect of this disclosure may include the following steps: sending system information to a redcap terminal, wherein the system information includes first information regarding an additional PRB offset in a Physical Resource Block (PRB) mapping of PUCCH resources and second information regarding whether the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial uplink bandwidth portion (BWP) of the redcap terminal or in descending order from the upper edge of the initial uplink BWP of the redcap terminal; sending downlink control information (DCI) scheduling a Physical Downlink Shared Channel (PDSCH) to the redcap terminal; sending the PDSCH to the redcap terminal; and receiving Hybrid Automatic Repeat Request (HARQ)-Acknowledgement (ACK) information associated with the PDSCH from the redcap terminal in the PUCCH. Based on the fact that frequency hopping for PUCCH transmission is disabled, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0012] Beneficial effects

[0013] According to embodiments of this disclosure, even if the initial uplink bandwidth portion of a standard terminal overlaps with the initial uplink bandwidth portion of a specific type of terminal (e.g., a reduced-capability terminal), the problem of resource fragmentation for uplink transmission of the standard terminal can be prevented.

[0014] Furthermore, according to embodiments of this disclosure, even if the initial uplink bandwidth portion of a standard terminal overlaps with the initial uplink bandwidth portion of a specific type of terminal (e.g., a reduced-capability terminal), conflicts between uplink transmissions of the standard terminal and uplink transmissions of the specific type of terminal can be prevented, thereby preventing interference and performance degradation.

[0015] Furthermore, according to embodiments of this disclosure, operation of random access procedures for specific types of terminals (e.g., reduced-capability terminals) can be smoothly supported.

[0016] The effects achievable by this disclosure are not limited to those described above, and those skilled in the art can clearly understand other effects not described herein through the following description. Attached Figure Description

[0017] The accompanying drawings, included as part of the detailed description for understanding this disclosure, provide embodiments of the disclosure and describe the technical features of the disclosure through detailed description.

[0018] Figure 1 The structure of a wireless communication system to which this disclosure can be applied is illustrated.

[0019] Figure 2 A frame structure in a wireless communication system to which this disclosure can be applied is illustrated.

[0020] Figure 3 An example is shown of a resource grid in a wireless communication system to which this disclosure can be applied.

[0021] Figure 4 Examples of physical resource blocks in wireless communication systems to which this disclosure may be applied are provided.

[0022] Figure 5 The time slot structure in a wireless communication system to which this disclosure can be applied is illustrated.

[0023] Figure 6 Examples are given of physical channels used in wireless communication systems to which this disclosure may be applied, and general methods for transmitting and receiving signals using such physical channels.

[0024] Figure 7 The process of obtaining system information is illustrated.

[0025] Figure 8 An example of a random access procedure that can be applied in a wireless communication system according to this disclosure is illustrated.

[0026] Figure 9 A two-step random access procedure that can be applied to a wireless communication system according to this disclosure is illustrated.

[0027] Figure 10The procedure illustrates a device type for which a reporting redcap device can be applied in a wireless communication system according to this disclosure.

[0028] Figure 11 This is a diagram illustrating the frequency resource allocation of a Msg3 PUSCH without frequency hopping according to an embodiment of the present disclosure.

[0029] Figure 12 This is a diagram illustrating the frequency resource allocation of the Msg3 PUSCH considering frequency hopping according to an embodiment of the present disclosure.

[0030] Figure 13 This is a diagram illustrating the frequency resource allocation of the Msg3 PUSCH considering frequency hopping according to an embodiment of the present disclosure.

[0031] Figure 14 This is a diagram illustrating the frequency resource allocation of the Msg3 PUSCH considering frequency hopping according to an embodiment of the present disclosure.

[0032] Figure 15 This is a diagram illustrating the frequency resource allocation of Msg3 PUSCH using MOD operations according to an embodiment of the present disclosure.

[0033] Figure 16 This is a diagram illustrating the frequency resource allocation of Msg3 PUSCH in an application image according to an embodiment of this disclosure.

[0034] Figure 17 This is a diagram illustrating the configuration of the initial UL BWP of a standard UE and the initial BWP of a redcap UE according to embodiments of the present disclosure.

[0035] Figure 18 An example of PUCCH transmission using a frequency-hopping redcap UE according to an embodiment of this disclosure is illustrated.

[0036] Figure 19 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0037] Figure 20 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0038] Figure 21 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0039] Figure 22 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0040] Figure 23 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0041] Figure 24 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0042] Figure 25 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0043] Figure 26 This is a diagram illustrating the signaling process between a base station and a terminal in a method for transmitting and receiving PUCCH according to an embodiment of the present disclosure.

[0044] Figure 27 This is a diagram illustrating the operation of a UE for transmitting and receiving a PUCCH according to an embodiment of the present disclosure.

[0045] Figure 28 This is a diagram illustrating the operation of a base station for transmitting and receiving PUCCH according to an embodiment of the present disclosure.

[0046] Figure 29 A block diagram illustrating a wireless communication device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0047] In the following, embodiments according to this disclosure will be described in detail with reference to the accompanying drawings. The detailed description disclosed with reference to the drawings is intended to describe exemplary embodiments of this disclosure and not to represent the only embodiments in which this disclosure can be implemented. The following detailed description includes specific details to provide a complete understanding of this disclosure. However, those skilled in the art will recognize that this disclosure can be implemented without these specific details.

[0048] In some cases, known structures and devices may be omitted, or they may be shown in block diagram form based on the core functions of each structure and device in order to prevent ambiguity of the concepts in this disclosure.

[0049] In this disclosure, when an element is referred to as “connected,” “combined,” or “linked” to another element, it can include both indirect and direct connections between the two elements. Furthermore, in this disclosure, the terms “comprising” or “having” specify the presence of the mentioned features, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, stages, operations, components, elements, and / or groups thereof.

[0050] In this invention, terms such as "first" and "second" are used only to distinguish one element from another and are not used to limit the elements. Unless otherwise stated, they do not limit the order or importance of the elements. Therefore, within the scope of this disclosure, a first element in one embodiment may be referred to as a second element in another embodiment, and similarly, a second element in one embodiment may be referred to as a first element in another embodiment.

[0051] The terminology used in this disclosure is for the purpose of describing particular embodiments and not for limiting the claims. As used in the description of embodiments and the appended claims, the singular form is intended to include the plural form unless the context clearly indicates otherwise. The term “and / or” as used in this disclosure may refer to one of the associated enumerations, or is intended to refer to and include any and all possible combinations of two or more of them. Furthermore, unless otherwise stated, the “ / ” between words in this invention has the same meaning as “and / or”.

[0052] This disclosure describes a wireless communication network or wireless communication system, and operations performed in the wireless communication network can be performed in the process of a device (e.g., a base station) controlling the network and transmitting or receiving signals, or in the process of a terminal associated with the corresponding wireless network transmitting or receiving signals with the network or between the terminal.

[0053] In this disclosure, the term "transmit or receive channel" includes the meaning of transmitting or receiving information or signals through a corresponding channel. For example, transmitting a control channel means transmitting control information or control signals through a control channel. Similarly, transmitting a data channel means transmitting data information or data signals through a data channel.

[0054] In the following text, downlink (DL) refers to communication from a base station to a terminal, while uplink (UL) refers to communication from a terminal to a base station. In the downlink, the transmitter can be part of the base station, and the receiver can be part of the terminal. In the uplink, the transmitter can be part of the terminal, and the receiver can be part of the base station. A base station can be referred to as a first communication device, and a terminal can be referred to as a second communication device. A base station (BS) can be replaced by terms such as fixed station, Node B, eNB (evolved Node B), gNB (next-generation Node B), BTS (Base Transceiver System), Access Point (AP), Network (5G network), AI (Artificial Intelligence) system / module, RSU (Roadside Unit), robot, UAV (Unmanned Aerial Vehicle), AR (Augmented Reality) device, VR (Virtual Reality) device, etc. In addition, terminals can be fixed or mobile, and can be replaced by terms such as UE (User Equipment), MS (Mobile Station), UT (User Terminal), MSS (Mobile Subscriber Station), SS (Subscriber Station), AMS (Advanced Mobile Station), WT (Wireless Terminal), MTC (Machine-Type Communication) equipment, M2M (Machine-to-Machine) equipment, D2D (Device-to-Device) equipment, vehicle, RSU (Roadside Unit), robot, AI (Artificial Intelligence) module, UAV (Unmanned Aerial Vehicle), AR (Augmented Reality) equipment, VR (Virtual Reality) equipment, etc.

[0055] The following descriptions can be used for various radio access systems, such as CDMA, FDMA, TDMA, OFDMA, SC-FDMA, etc. CDMA can be implemented using technologies such as UTRA (Universal Terrestrial Radio Access) or CDMA2000. TDMA can be implemented using radio technologies such as GSM (Global System for Mobile Communications) / GPRS (General Packet Radio Service) / EDGE (GSM Evolution with Enhanced Data Rates). OFDMA can be implemented using radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, E-UTRA (Evolved UTRA). UTRA is part of UMTS (Universal Mobile Telecommunications System). 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) is part of E-UMTS (Evolved UMTS) using E-UTRA, and LTE-A (Advanced) / LTE-A pro are advanced versions of 3GPP LTE. 3GPP NR (New Radio or New Radio Access Technology) is an advanced version of 3GPP LTE / LTE-A / LTE-A pro.

[0056] To make the description clearer, it is based on 3GPP communication systems (e.g., LTE-A, NR), but the technical ideas of this disclosure are not limited thereto. LTE refers to technology from 3GPP TS (Technical Specification) version 8 onwards. Specifically, LTE technology in or after 3GPP TS 36.xxx is referred to as LTE-A, and LTE technology in or after 3GPP TS 36.xxx is referred to as LTE-A pro. 3GPP NR refers to technology in or after TS 38.xxx. LTE / NR can be referred to as a 3GPP system. "xxx" refers to the detailed number of the standard document. LTE / NR is generally referred to as a 3GPP system. For background technology, terminology, abbreviations, etc., used to describe this disclosure, reference can be made to the matters described in the standard documents previously published. For example, the following documents can be consulted.

[0057] For 3GPP LTE, you can refer to TS 36.211 (Physical Channels and Modulation), TS 36.212 (Multiplexing and Channel Coding), TS 36.213 (Physical Layer Procedures), TS 36.300 (General Description), and TS 36.331 (Radio Resource Control).

[0058] For 3GPP NR, you can refer to TS 38.211 (Physical Channels and Modulation), TS 38.212 (Multiplexing and Channel Coding), TS 38.213 (Physical Layer Procedures for Control), TS 38.214 (Physical Layer Procedures for Data), TS 38.300 (General Description of NR and NG-RAN (Next Generation Radio Access Network)), and TS 38.331 (Radio Resource Control Protocol Specification).

[0059] The abbreviations of terms that may be used in this disclosure are defined as follows.

[0060] - BM: Beam Management

[0061] - CQI: Channel Quality Indicator

[0062] - CRI: Channel State Information - Reference Signal Resource Indicator

[0063] - CSI: Channel State Information

[0064] - CSI-IM: Channel State Information - Interference Measurement

[0065] - CSI-RS: Channel State Information - Reference Signal

[0066] - DMRS: Demodulation Reference Signal

[0067] - FDM: Frequency Division Multiplexing

[0068] - FFT: Fast Fourier Transform

[0069] - IFDMA: Interleaved Frequency Division Multiple Access

[0070] - IFFT: Inverse Fast Fourier Transform

[0071] - L1-RSRP: Layer 1 Reference Signal Received Power

[0072] - L1-RSRQ: Layer 1 reference signal reception quality

[0073] - MAC: Media Access Control

[0074] - NZP: Non-zero power

[0075] - OFDM: Orthogonal Frequency Division Multiplexing

[0076] – PDCCH: Physical Downlink Control Channel

[0077] - PDSCH: Physical Downlink Shared Channel

[0078] - PMI: Precoding Matrix Indicator

[0079] - RE: Resource Elements

[0080] - RI: Rank Indicator

[0081] - RRC: Radio Resource Control

[0082] - RSSI: Received Signal Strength Indicator

[0083] - Rx: Receive

[0084] - QCL: Quasi-co-location

[0085] - SINR: Signal-to-Interference-Noise Ratio

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

[0087] - TDM: Time Division Multiplexing

[0088] - TRP: Transmitting and Receiving Point

[0089] - TRS: Tracking Reference Signal

[0090] - Tx: Send

[0091] - UE: User Equipment

[0092] - ZP: Zero Power

[0093] Overall System

[0094] With more communication devices requiring higher capacity, there has been a demand for improved mobile broadband communications compared to existing radio access technologies (RATs). Furthermore, massive MTC (machine-type communication) that provides various services anytime, anywhere by connecting multiple devices and things is also one of the main issues to be considered in next-generation communications. In addition, communication system designs considering services / terminals sensitive to reliability and latency are discussed. Therefore, the introduction of next-generation RATs considering eMBB (enhanced mobile broadband communication), mMTC (massive MTC), URLLC (ultra-reliable low-latency communication), etc., is discussed, and for convenience, the corresponding technologies are referred to as NR in this disclosure. NR is an example expression representing 5G RAT.

[0095] New RAT systems, including those for NR, use OFDM or similar transmission methods. These new RAT systems may follow OFDM parameters different from those used in LTE. Alternatively, the new RAT system may follow existing LTE / LTE-A parameters as is, but may support a wider system bandwidth (e.g., 100MHz). Alternatively, a single cell may support multiple parameter sets. In other words, terminals operating according to different parameter sets can coexist in a single cell.

[0096] The parameter set corresponds to a subcarrier spacing in the frequency domain. Different parameter sets can be defined as the reference subcarrier spacing is scaled by an integer N.

[0097] Figure 1 The structure of a wireless communication system to which this disclosure can be applied is illustrated.

[0098] refer to Figure 1 The NG-RAN is configured with gNBs that provide control plane (RRC) protocol support for the NG-RA (NG Radio Access) user plane (i.e., the new AS (Access Layer) sublayer / PDCP (Packet Data Convergence Protocol) / RLC (Radio Link Control) / MAC / PHY) and UE. The gNBs interconnect via the Xn interface. Furthermore, the gNBs are connected to the NGC (Next Generation Core) via the NG interface. More specifically, the gNBs are connected to the AMF (Access and Mobility Management Power) via the N2 interface and to the UPF (User Plane Functions) via the N3 interface.

[0099] Figure 2 A frame structure in a wireless communication system to which this disclosure can be applied is illustrated.

[0100] NR systems can support multiple parameter sets. These parameter sets can be defined by subcarrier spacing and cyclic prefix (CP) overhead. Multiple subcarrier spacings can be derived by scaling the basic (reference) subcarrier spacing by an integer N (or μ). Furthermore, while it is assumed that very low subcarrier spacings are not used at very high carrier frequencies, the parameter set used can be selected independently of the frequency band. Moreover, various frame structures based on multiple parameter sets can be supported in NR systems.

[0101] The OFDM parameter sets and frame structures that can be considered in an NR system are described below. Several OFDM parameter sets supported in an NR system can be defined as shown in Table 1 below.

[0102] [Table 1]

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

[0104] [Table 2]

[0105] Regarding the frame structure in the NR system, the size of various fields in the time domain is expressed as T. c =1 / (Δf max ·N f A multiple of the time unit. Here, Δf max 480·10 3 Hz, and N f The value is 4096. Downlink and uplink transmissions are configured (organized) to have a duration T. f =1 / Δf max N f / 100)·T c A radio frame of 10ms. Here, the radio frame is configured with 10 subframes, each with a T... sf =(Δf max N f / 1000)·T c=1ms duration. In this case, there may be one frame set for the uplink and one frame set for the downlink. Furthermore, the transmission in the i-th uplink frame from the terminal should begin T earlier than the corresponding downlink frame in the corresponding terminal. TA =(N TA +N TA,offset )T c Begin. For the subcarrier spacing configuration μ, the time slots are arranged in n-order within the subframe. s μ ∈{0,...,N slot subframe,μ The numbers are numbered in ascending order from -1, and in the radio frames, they are numbered in n... s , f μ ∈{0,...,N slot frame,μ The time slot is configured with N in ascending order of -1. symb slot N consecutive OFDM symbols, and N symb slot Determined based on CP. Slot n in the subframe s μ The start of the OFDM symbol n in the same subframe s μ N symb slot The start times are arranged chronologically. All terminals may not perform transmission and reception simultaneously, meaning that all OFDM symbols in either the downlink or uplink time slots may not be available. Table 3 shows the number of OFDM symbols (N) per time slot in a normal CP. symb slot ), Number of time slots per radio frame (N) slot frame,μ ) and the number of time slots per subframe (N) slot subframe,μ Table 4 shows the number of OFDM symbols per slot, the number of slots per radio frame, and the number of slots per subframe in the extended CP.

[0106] [Table 3]

[0107] [Table 4]

[0108] Figure 2 This is an example of μ=2 (SCS is 60kHz), see Table 3. One subframe can include 4 time slots. For example... Figure 2The subframe shown as {1,2,4} is an example; the number of time slots that can be included in a subframe is defined in Table 3 or Table 4. Additionally, micro-time slots can include 2, 4, or 7 symbols, or more or fewer symbols. Regarding physical resources in an NR system, antenna ports, resource grids, resource elements, resource blocks, carrier portions, etc., can be considered. The physical resources that can be considered in an NR system will be described in detail below.

[0109] First, regarding antenna ports, an antenna port is defined such that the channel carrying symbols in that antenna port can be inferred from the channels carrying other symbols in the same antenna port. When the large-scale properties of the channel carrying symbols in one antenna port can be inferred from the channel carrying symbols in another antenna port, it can be said that the two antenna ports are in a QC / QCL (quasi-co-located or quasi-co-located) relationship. In this case, the large-scale properties include at least one of delay spread, Doppler spread, frequency shift, average received power, and receive timing.

[0110] Figure 3 An example is shown of a resource grid in a wireless communication system to which this disclosure can be applied.

[0111] refer to Figure 3 This illustratively describes a resource grid configured with N in the frequency domain. RB μ N sc RB There are 14.2 subcarriers, and one subframe is configured with 14.2 μ The number of OFDM symbols is not limited to this. In an NR system, the transmitted signal consists of 2 OFDM symbols. μ N symb （μ） Each OFDM symbol and configuration has N RB μ N sc RB It is described by one or more resource grids of N subcarriers. Here, N RB μ ≤N RB max,μ N RB max,μ This represents the maximum transmission bandwidth, which may differ between uplink and downlink, and between parameter sets. In this case, each μ and antenna port p can be configured with a resource grid. Each element of the resource grid used for μ and antenna port p is called a resource element and is uniquely identified by an index pair (k, l'). Here, k = 0, ..., N RB μ N sc RB -1 is the index in the frequency domain, and l' = 0, ..., 2 μ Nsymb （μ） -1 indicates the symbol position within the subframe. When referencing resource elements in a time slot, index pairs (k, l) are used. Here, l = 0,...,N symb μ -1. The resource element (k, l') used for μ and antenna port p corresponds to the complex value a. k,l' （p,μ） When there is no risk of confusion or when a specific antenna port or parameter set is not specified, the indices p and μ may be discarded, and the complex value may be ak,l'(p) or ak,l'. Furthermore, a resource block (RB) is defined as N in the frequency domain. sc RB =12 consecutive subcarriers.

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

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

[0114] -absoluteFrequencyPointA represents the frequency location of point A, expressed in ARFCN (Absolute Radio Frequency Channel Number).

[0115] For subcarrier spacing configuration μ, common resource blocks are numbered from 0 upwards in the frequency domain. The center of subcarrier 0 of common resource block 0 used for subcarrier spacing configuration μ is the same as "point A". The common resource block number n of subcarrier spacing configuration μ in the frequency domain is... CRB μ The relationship between the resource element (k,l) and the resource element (k,l) is given by Equation 1 below.

[0116] [Equation 1]

[0117] In Equation 1, k is defined relative to point A such that k=0 corresponds to a subcarrier centered at point A. Physical resource blocks range from 0 to N in the bandwidth portion (BWP). BWP,i size,μ -1 is the number and i is the number of the BWP. The physical resource block n in BWPi. PRB and public resource block n CRB The relationship between them is given by the following equation 2.

[0118] [Equation 2] It is a public resource block relative to public resource block 0 in BWP.

[0119] Figure 4 Examples of physical resource blocks in wireless communication systems that can utilize this disclosure are provided. Furthermore, Figure 5 The time slot structure in a wireless communication system to which this disclosure can be applied is illustrated.

[0120] refer to Figure 4 and Figure 5 A time slot comprises multiple symbols in the time domain. For example, for a normal CP, one time slot includes 7 symbols, but for an extended CP, one time slot includes 6 symbols.

[0121] A carrier comprises multiple subcarriers in the frequency domain. An RB (Resource Block) is defined as multiple (e.g., 12) consecutive subcarriers in the frequency domain. A BWP (Bandwidth Component) is defined as multiple consecutive (physical) resource blocks in the frequency domain and can correspond to a set of parameters (e.g., SCS, CP length, etc.). A carrier can include up to N (e.g., 5) BWPs. Data communication can be performed through active BWPs, and only one BWP can be active for a single terminal. In the resource grid, each element is called a resource element (RE) and can be mapped to a complex number of symbols.

[0122] In NR systems, each component carrier (CC) can support up to 400MHz. If a terminal operating in such a wideband CC always operates with the radio frequency (FR) chip turned on for the entire CC, terminal battery consumption may increase. Alternatively, when considering multiple application scenarios operating in a wideband CC (e.g., eMBB, URLLC, Mmtc, V2X, etc.), different sets of parameters (e.g., subcarrier spacing, etc.) can be supported in each frequency band of the corresponding CC. Alternatively, each terminal may have different capabilities for the maximum bandwidth. With this in mind, the base station can instruct the terminal to operate only in a portion of the bandwidth, rather than in the full bandwidth of the wideband CC, and for convenience, the corresponding portion of the bandwidth is defined as the bandwidth portion (BWP). The BWP can be configured with consecutive RBs on the frequency axis and can correspond to a set of parameters (e.g., subcarrier spacing, CP length, slot / microslot duration).

[0123] Simultaneously, even within a single CC configured for a terminal, the base station can configure multiple BWPs. For example, a BWP occupying a relatively small frequency domain can be configured in the PDCCH monitoring slot, and PDSCH indicated by the PDCCH can be scheduled in a larger BWP. Alternatively, when a UE is congested in a particular BWP, other BWPs can be configured for some terminals for load balancing. Alternatively, considering inter-cell interference cancellation in the frequency domain between neighboring cells, some intermediate spectrum of the full bandwidth can be excluded, and two edge BWPs can be configured in the same time slot. In other words, the base station can configure at least one DL / UL BWP for a terminal associated with a broadband CC. The base station can activate at least one DL / UL BWP among the configured DL / UL BWPs at a specific time (via L1 signaling, MAC CE (control element), or RRC signaling, etc.). Furthermore, the base station can instruct a handover to other configured DL / UL BWPs (via L1 signaling, MAC CE, or RRC signaling, etc.). Alternatively, based on a timer, a handover to a specific DL / UL BWP can be performed when the timer value expires. Here, the active DL / UL BWP is defined as the active DL / UL BWP. However, the terminal may not receive the configuration on the DL / UL BWP before performing the initial access procedure or establishing an RRC connection. Therefore, in these cases, the DL / UL BWP assumed by the terminal is defined as the initially active DL / UL BWP.

[0124] Figure 6 Examples are given of physical channels used in wireless communication systems to which this disclosure may be applied, and general methods for transmitting and receiving signals using such physical channels.

[0125] In wireless communication systems, terminals receive information from base stations via downlink and transmit information to base stations via uplink. The information sent and received by base stations and terminals includes data and various control information, and various physical channels exist depending on the type / purpose of the information they send and receive.

[0126] When a terminal is powered on or enters a new cell, it performs an initial cell search (S601), including synchronization with the base station. For the initial cell search, the terminal synchronizes with the base station by receiving the primary synchronization signal (PSS) and secondary synchronization signal (SSS) from the base station, and obtains information such as the cell identifier (ID). Then, the terminal obtains broadcast information within the cell by receiving the physical broadcast channel (PBCH) from the base station. Simultaneously, the terminal checks the downlink channel state by receiving the downlink reference signal (DL RS) during the initial cell search phase.

[0127] Terminals that have completed the initial cell search can obtain more detailed system information by receiving the Physical Downlink Control Channel (PDCCH) and Physical Downlink Shared Channel (PDSCH) based on the information carried in the PDCCH (S602).

[0128] Simultaneously, when a terminal first accesses a base station or when there are no radio resources available for signal transmission, it can perform a random access (RACH) procedure (S603 to S606). For the random access procedure, the terminal can send a specific sequence as a preamble via the Physical Random Access Channel (PRACH) (S603 and S605), and can receive response messages to the preamble via the PDCCH and the corresponding PDSCH (S604 and S606). Contention-based RACH can further execute a contention resolution procedure.

[0129] The terminal that subsequently performs the above process can execute PDCCH / PDSCH reception (S607) and PUSCH (Physical Uplink Shared Channel) / PUCCH (Physical Uplink Control Channel) transmission (S608) as a general uplink / downlink signal transmission process. Specifically, the terminal receives downlink control information (DCI) via PDCCH. Here, DCI includes control information such as resource allocation information for the terminal, and its format varies depending on its intended use.

[0130] Meanwhile, control information sent by the terminal to the base station via the uplink or received by the terminal from the base station includes downlink / uplink ACK / NACK (acknowledgment / non-acknowledgment) signals, CQI (Channel Command Indicator), PMI (Precoding Matrix Indicator), RI (Rank Indicator), etc. For 3GPP LTE systems, the terminal can send the aforementioned control information such as CQI / PMI / RI via PUSCH and / or PUCCH.

[0131] Table 5 shows examples of DCI format in the NR system.

[0132] [Table 5]

[0133] Referring to Table 5, DCI formats 0_0, 0_1, and 0_2 can include resource information (e.g., UL / SUL (Supplemental UL), frequency resource allocation, time resource allocation, frequency hopping, etc.), information related to transport blocks (TBs) (e.g., MCS (Modulation, Coding, and Scheme), NDI (New Data Indicator), RV (Redundancy Version), etc.), information related to HARQ (Hybrid Automatic Repeat and Request) (e.g., process number, DAI (Downlink Assignment Index), PDSCH-HARQ feedback timing, etc.), information related to multiple antennas (e.g., DMRS sequence initialization information, antenna ports, CSI requests, etc.), power control information related to PUSCH scheduling (e.g., PUSCH power control, etc.), and control information included in each DCI format can be predefined. DCI format 0_0 is used to schedule PUSCHs within a cell. The information included in DCI format 0_0 is scrambled with CRC (Cyclic Redundancy Check) by C-RNTI (Cell Radio Network Temporary Identifier), CS-RNTI (Configured Scheduling RNTI), or MCS-C-RNTI (Modulation and Coding Scheme Cell RNTI) and transmitted.

[0134] DCI format 0_1 ​​is used to indicate the scheduling of one or more PUSCHs or to provide downlink feedback information to the Terminal Configuration Grant (CG) in a cell. The information included in DCI format 0_1 ​​is scrambled and transmitted by C-RNTI, CS-RNTI, SP-CSI-RNTI (semi-persistent CSI RNTI), or MCS-C-RNTI.

[0135] DCI format 0_2 is used to schedule PUSCH within a cell. The information included in DCI format 0_2 is scrambled and transmitted using C-RNTI, CS-RNTI, SP-CSI-RNTI, or MCS-C-RNTI.

[0136] Next, DCI formats 1_0, 1_1, and 1_2 may include resource information (e.g., frequency resource allocation, time resource allocation, VRB (Virtual Resource Block) - PRB (Physical Resource Block) mapping, etc.), information related to transport blocks (TB) (e.g., MCS, NDI, RV, etc.), information related to HARQ (e.g., process number, DAI, PDSCH-HARQ feedback timing, etc.), information related to multiple antennas (e.g., antenna port, TCI (Transmission Configuration Indicator), SRS (Sound Reference Signal) request, etc.), PUCCH-related information regarding PDSCH scheduling (e.g., PUCCH power control, PUCCH resource indicator, etc.), and control information included in each DCI format can be predefined.

[0137] DCI format 1_0 is used to schedule PDSCH in a DL cell. The information included in DCI format 1_0 is a CRC scrambled and transmitted by C-RNTI, CS-RNTI, or MCS-C-RNTI.

[0138] DCI format 1_1 is used to schedule PDSCH in a cell. The information included in DCI format 1_1 is a CRC scrambled and transmitted by C-RNTI, CS-RNTI, or MCS-C-RNTI.

[0139] DCI format 1_2 is used to schedule PDSCH in a cell. The information contained in DCI format 1_2 is a CRC scrambled and transmitted by C-RNTI, CS-RNTI, or MCS-C-RNTI.

[0140] System Information Acquisition

[0141] Figure 7 The process of obtaining system information is illustrated.

[0142] The UE can obtain access stratum (AS) / non-access stratum (NAS) information through the system information (SI) acquisition procedure. The SI acquisition procedure can be applied to the UE in the RRC idle (RRC_IDLE) state, the RRC inactive (RRC_INACTIVE) state, and the RRC connected (RRC_CONNECTED) state.

[0143] SIs are divided into the Main Information Block (MIB) and multiple System Information Blocks (SIBs). SIs other than the MIB can be referred to as Residual Minimal System Information (RMSI) and Other System Information (OSI). RMSI corresponds to SIB1, while OSI refers to SIBs that are other than SIB2 and higher than SIB2. For a more detailed explanation, please refer to the following.

[0144] The MIB includes information / parameters related to receiving SIB1 (System Information Block Type 1) and is transmitted via the SSB's PBCH (SS / PBCH block). The MIB information may include the fields shown in Table 6.

[0145] Table 6 illustrates a portion of the MIB.

[0146] [Table 6]

[0147] Table 7 illustrates the descriptions of the MIB fields shown in Table 6.

[0148] [Table 7]

[0149] During initial cell selection, the UE assumes that half-frames with SSBs are repeated in 20 ms intervals. The UE can check the existence of a control resource set (CORESET) for the Type 0-PDCCH common search space based on the MIB. The Type 0-PDCCH common search space is the type of PDCCH search space and is used to send PDCCHs for scheduling SI messages. When the Type 0-PDCCH common search space exists, the UE can determine (i) the multiple consecutive RBs constituting the CORESET and one or more consecutive symbols and (ii) the PDCCH timing (i.e., the time-domain location for PDCCH reception) based on information in the MIB (e.g., pdcch-ConfigSIB1). Specifically, pdcch-ConfigSIB1 is an 8-bit information, (i) determined based on the 4-bit MSB (most significant bit) (refer to Tables 13-1 to 13-10 of 3GPP TS 38.213), and (ii) determined based on the 4-bit LSB (least significant bit) (refer to Tables 13-11 to 13-15 of 3GPP TS 38.213).

[0150] As an example, the information indicated by the MSB 4 bits of pdcch-ConfigSIB1 is shown below.

[0151] The configuration of CORESET in the Type0-PDCCH public search space is as follows: i) Define multiple tables based on subcarrier spacing and minimum channel bandwidth.

[0152] ii) Indicates the multiplexing mode between SS / PBCH blocks and PDCCH / PDSCH.

[0153] - Mode 1: All SCS combinations of FR1, all SCS combinations of FR2

[0154] - Mode 2: Different SCS combinations for FR2 (in addition to the combination of 60 kHz for the initial DL BWP and 240 kHz for the SS / PBCH block)

[0155] - Mode 3: Same SCS combination for FR2 (for 120 kHz SCS)

[0156] iii) Indicates the number of PRB and OFDM symbols for CORESET.

[0157] - N RB CORESET : Number of RBs (i.e., {24, 48, 96})

[0158] - N Symb CORESETThe number of symbols (i.e., {1, 2, 3}).

[0159] iv) Indicates the offset (number of RBs) between the first RB of the SS / PBCH block and the first RB of the RMSI CORESET.

[0160] - The range of the offset (the number of RBs) is determined by the number of PRBs and sync raster0.

[0161] - The design aligns the center of the SS / PBCH block and the center of the RMSI CORESET as closely as possible.

[0162] When the Type0-PDCCH common search space does not exist, pdcch-ConfigSIB1 provides information about the frequency locations where SSB / SIB1 exists and the frequency range where SSB / SIB1 does not exist.

[0163] In the initial cell selection scenario, the UE can assume that a half-frame with an SS / PBCH block occurs within a 2-frame timeframe. Upon detecting the SS / PBCH block, if for FR1 (below 6 GHz; 450 MHz to 6000 MHz) k SSB ≤23 and for FR2 (millimeter wave, 24250 MHz to 52600 MHz) k SSB If ≤11, then the UE determines that a set of control resources exists for the Type0-PDCCH common search space. If for FR1 k SSB >23 and for FR2 k SSB If the value is greater than 11, then the UE determines that there is no control resource set for the Type0-PDCCH common search space. SSB This represents the frequency / subcarrier offset between subcarrier 0 of the SS / PBCH block and subcarrier 0 of the SSB's common resource block. For FR2, a maximum of 11 values ​​can be applied. k can be signaled via the MIB. SSB SIB1 includes information related to the availability and scheduling (e.g., transmission period, SI window size) of the remaining SIBs (hereinafter referred to as SIBx, where x is an integer greater than or equal to 2). For example, SIB1 may indicate whether SIBx is provided on demand at the request of the UE or broadcast periodically. When SIBx is provided on demand, SIB1 may include information required by the UE to execute the SI request. SIB1 is transmitted via PDSCH, the PDCCH that schedules SIB1 is transmitted via the Type 0-PDCCH common search space, and SIB1 is transmitted via PDSCH indicated by the PDCCH.

[0164] SIBx is included in the SI message and sent via PDSCH. Each SI message is sent within a periodically occurring time window (i.e., the SI window).

[0165] Random access operations and related operations

[0166] When there are no PUSCH transmission resources allocated by the base station (i.e., uplink clearance), the UE can perform random access operations. Random access in the NR system can be initiated in the following situations: 1) when the UE requests or restores an RRC connection; 2) when the UE performs a handover to a neighboring cell or adds a secondary cell group (SCG) (i.e., SCG addition); 3) when the UE makes a scheduling request to the base station; 4) when the base station indicates random access with a PDCCH command to the UE; and 5) when a beam fault or RRC connection failure is detected.

[0167] Figure 8 An example of a random access procedure that can be applied in a wireless communication system according to this disclosure is illustrated. Figure 8 (a) illustrates a contention-based random access procedure. Figure 8 Example (b) illustrates a dedicated random access procedure.

[0168] refer to Figure 8 (a) The contention-based random access procedure comprises the following four steps. In the following text, the messages sent in steps 1 to 4 may be referred to as messages (Msg)1 to Msg 4, respectively.

[0169] - Step 1: The UE sends a random access channel (RACH) preamble via the physical random access channel (PRACH).

[0170] - Step 2: The UE receives the Random Access Response (RAR) from the base station via the downlink shared channel (DL-SCH).

[0171] - Step 3: The UE sends Layer 2 / Layer 3 messages to the base station via the uplink shared channel (UL-SCH).

[0172] - Step 4: The UE receives the contention resolution message from the base station via DL-SCH.

[0173] The UE can receive information about random access from the base station through system information.

[0174] If random access is required, the UE sends a RACH preamble to the base station as in step 1. The base station can distinguish each of the random access preambles by sending the time / frequency resources (i.e., RACH timing (RO)) and the random access preamble index (PI).

[0175] When the base station receives a random access preamble from the terminal, it sends a random access response (RAR) message to the terminal as described in step 2. To receive the RAR message, the UE uses the RA-RNTI (Random Access-RNTI) to monitor the CRC-masked L1 / L2 control channel (PDCCH) within a pre-configured time window (e.g., ra-ResponseWindow). This RA-RNTI includes scheduling information for the RAR message. The PDCCH using the RA-RNTI mask can be transmitted only through the common search space. When a scheduling signal using the RA-RNTI mask is received, the UE can receive the RAR message from the PDSCH indicated by the scheduling information. Subsequently, the terminal checks whether the RAR message contains the RAR message indicating the presence of the intended RAR message. The presence of the intended RAR message can be confirmed by the presence of the RAR ID (RAPID) of the preamble sent by the terminal. The index and RAPID of the preamble sent by the UE can be the same. The random access response information includes the corresponding random access preamble index, timing offset information for UL synchronization (e.g., timing advance command (TAC)), UL scheduling information for message 3 transmission (e.g., UL permission), and UE temporary identification information (e.g., TC-RNTI (temporary C-RNTI)).

[0176] The UE receiving the random access response information transmits UL-SCH (Shared Channel) data (message 3) via PUSCH according to the UL scheduling information and timing offset value, as in step 3. The time and frequency resources for mapping / transmitting the PUSCH carrying message 3 are defined as PO (PUSCH Opportunity). Message 3 may include the UE's ID (or the UE's global ID). Alternatively, message 3 may include RRC connection request information for initial access (e.g., an RRCSetupRequest message). Message 3 may also include a buffer status report (BSR) regarding the amount of data available for transmission by the UE.

[0177] After receiving the UL-SCH data, the base station sends a contention resolution message (Message 4) to the UE, as in step 4. When the UE receives the contention resolution message and successfully resolves the contention, the TC-RNTI changes to the C-RNTI. Message 4 may include the UE's ID and / or RRC connection-related information (e.g., an RRCSetup message). If the information sent via Message 3 and the information received via Message 4 do not match, or if Message 4 is not received within a specific time period, the UE can determine that the contention resolution has failed and retransmit Message 3.

[0178] refer to Figure 8(b) The Dedicated Random Access Procedure comprises the following three steps. In the following text, the messages sent in steps 0 through 2 may be referred to as messages (Msg)0 through Msg 2, respectively. The Dedicated Random Access Procedure can be triggered by using a PDCCH (hereinafter referred to as the PDCCH command) to indicate the RACH preamble sent by the base station.

[0179] - Step 0: The base station allocates the RACH preamble to the terminal via dedicated signaling.

[0180] - Step 1: The UE sends the RACH preamble via PRACH.

[0181] - Step 2: The UE receives the Random Access Response (RAR) from the base station via DL-SCH.

[0182] Steps 1 and 2 of the dedicated random access procedure can be performed in the same way as steps 1 and 2 of the contention-based random access procedure.

[0183] In NR, DCI format 1_0 is used to initiate a contention-free random access procedure with a PDCCH command. DCI format 1_0 is also used to schedule PDSCH within a DL cell. Furthermore, when the Cyclic Redundancy Check (CRC) of DCI format 1_0 is scrambled with C-RNTI and all bits of the "Frequency domain resource assignment" field are 1, DCI format 1_0 is used as a PDCCH command to indicate the random access procedure. In this case, the fields of DCI format 1_0 are configured as follows.

[0184] - RA leading index: 6 bits

[0185] - UL / SUL (Supplementary UL) Indicator: 1 bit. The PRACH in the cell indicates the transmitted UL carrier when all bits of the RA preamble index are not 0 and SUL is configured for the UE in the cell. Otherwise, it is not used (reserved).

[0186] - SSB (Synchronization Signal / Physical Broadcast Channel) Index: 6 bits. When all bits of the RA preamble index are not 0, it indicates the SSB used to determine the timing of the RACH transmission. Otherwise, it is unused (reserved).

[0187] - PRACH mask index: 4 bits. When all bits of the RA leading index are not 0, it indicates the timing of the RACH associated with the SSB indicated by the SSB index. Otherwise, it is not used (reserved).

[0188] - Reserved: 10 bits

[0189] When DCI format 1_0 does not correspond to a PDCCH command, DCI format 1_0 is configured with fields for scheduling PDSCH (e.g., Time Domain Resource Assignment (TDRA), Modulation and Coding Scheme (MCS), HARQ Procedure Number, PDSCH-to-HARQ_feedback Timing Indicator, etc.).

[0190] In NR systems, lower latency may be required compared to existing systems. Additionally, if a random access procedure occurs in the U-band, the procedure is terminated, and contention is resolved only if the UE and base station succeed in the LBT sequence across all four random access steps. Failure of the LBT at any step of the four-step random access procedure reduces resource efficiency and increases latency. Specifically, if the LBT fails during the scheduling / transmission process associated with message 2 or message 3, significant reductions in resource efficiency and increases in latency can occur. Even in L-band random access procedures, low-latency random access procedures may be required in various scenarios within NR systems. Therefore, a two-step random access procedure can also be performed on the L-band.

[0191] Figure 9 A two-step random access procedure that can be applied to a wireless communication system according to this disclosure is illustrated.

[0192] like Figure 9 As shown in (a), the two-step random access procedure may include the following two steps: sending an uplink signal (referred to as message A and corresponding to PRACH preamble + Msg3 PUSCH) from the UE to the base station; and sending a downlink signal (referred to as message B and corresponding to RAR + Msg4 PDSCH) from the base station to the UE.

[0193] Furthermore, in non-contention-based random access processes, such as Figure 9 As shown in (b), the random access preamble and the PUSCH portion can be sent together.

[0194] although Figure 9 Not shown, but a PDCCH for scheduling message B can be sent from the base station to the UE, which can be called Msg.B PDCCH.

[0195] Overall capacity reduction (RedCap)

[0196] The terms that may be used in this disclosure are defined as follows.

[0197] - BWP: Bandwidth portion (which can consist of consecutive resource blocks (RBs) on the frequency axis). It can correspond to a set of parameters (e.g., SCS, CP length, slot / microslot duration, etc.). Furthermore, multiple BWPs can be configured on a single carrier (the number of BWPs per carrier can also be limited), but the number of active BWPs can be limited to a portion per carrier (e.g., one).

[0198] - SS: Search Space

[0199] - CORESET: Control Resource Set (meaning the time-frequency resource area where PDCCH can be sent, and the number of CORESETs per BWP can be limited).

[0200] - Type0-PDCCH CSS (Common Search Space) set: Search space set where NR UE monitoring has a DCI-formatted set of PDCCH candidates with CRC scrambled by SI-RNTI.

[0201] - CORESET#0: CORESET for Type 0-PDCCH CSS settings for NR UEs (configured in the MIB)

[0202] - MO: PCCH monitoring timing (e.g., for the Type0-PDCCH CSS collection)

[0203] - SIB1-R: This is the (additional) SIB1 for RedCap UE, and can be limited to the case where it is generated as a TB separate from SIB1 and sent via a separate PDSCH.

[0204] - CORESET#0-R: CORESET#0 for RedCap UE

[0205] - Type0-PDCCH-R CSS set: Search space set, in which RedCap UE monitors a set of PDCCH candidates in DCI format with CRC scrambled by SI-RNTI.

[0206] - MO-R: PCCH monitoring timing (e.g., for the Type0-PDCCH-R CSS set)

[0207] - Cell Definition SSB (CD-SSB): RMSI scheduling information in the NR SSB

[0208] - Non-Cell Defined SSB (Non-CD-SSB): An SSB placed in the NR sync raster but not including RMSI scheduling information for the cell used for measurement. However, information indicating the location of the CD-SSB may be included.

[0209] - SCS: Subcarrier Spacing

[0210] SI-RNTI: System Information Radio-Network Temporary Identifier

[0211] - Camp on: "Camp on" is a UE state in which the UE is ready to remain in the cell and begin potential dedicated services or receive ongoing broadcast services.

[0212] - TB: Transport Block

[0213] - RSA (Redcap Standalone): A cell that only supports Redcap devices or services.

[0214] - IE: Information Elements

[0215] - RO: RACH timing

[0216] - QCL: Quasi-co-location (the QCL relationship between two reference signals (RS)) means that QCL parameters obtained from one RS (such as Doppler shift, Doppler spread, average delay, delay spread, spatial Rx parameters, etc.) can also be applied to another RS ​​(or the antenna port of the corresponding RS). In NR systems, four QCL types are defined as follows: 'typeA': {Doppler shift, Doppler spread, average delay, delay spread}, 'typeB': {Doppler shift, Doppler spread}, 'typeC': {Doppler shift, average delay}, 'typeD': {spatial Rx parameters}. For certain DL RS antenna ports, a first DL RS can be configured as a reference for QCL type X (X=A, B, C, or D), and a second DL RS can be configured as a reference for QCL type Y (Y=A, B, C, or D, but X≠Y)).

[0217] - TCI: Transmission Configuration Indicator (A TCI state includes the QCL relationship between the DM-RS port of the PDSCH, the DM-RS port of the PDCCH, or the CSI-RS port of the CSI-RS resource and one or more DL RSs. For the 'Transmission Configuration Indicator' field in the DCI of the scheduling PDSCH, the TCI state index corresponding to each code point constituting the corresponding field is activated by the MAC control element (CE), and the TCI state configuration for each TCI state index is configured via RRC signaling. In the Rel-16 NR system, the corresponding TCI state is configured between DL RSs, but configuration between DL RSs and UL RSs or between UL RSs may be allowed in future versions. Examples of UL RSs include SRS, PUSCH DM-RS, PUCCH DM-RS, etc.).

[0218] - TRP: Transmitting and Receiving Point

[0219] - RACH: Random Access Channel

[0220] - RAR: Random Access Response

[0221] - Msg3: This is a message sent via the uplink shared channel (UL-SCH) that includes a C-RNTI MAC CE or Common Control Channel (CCCH) Service Data Unit (SDU) provided from a higher layer and is associated with the UE contention resolution identifier as part of the random access procedure.

[0222] - Special Cell: In dual-connectivity operation, depending on whether the MAC entity is associated with the primary cell group (MCG) or the secondary cell group (SCG), the term "special cell" refers to the PCell of the MCG or the PSCell of the SCG. Otherwise, the term "special cell" refers to the PCell. Special cells support PUCCH transmission and contention-based random access and are always active.

[0223] - Serving cells: including PCcell, PSCell and secondary cells (SCell).

[0224] Recently, in addition to the main 5G use cases (mMTC, eMBB, and URLLC), the importance / interest of use case areas spanning mMTC and eMBB or mMTC and URLLC is increasing. Therefore, there is a growing need for UEs to effectively support these use cases in terms of device cost, power consumption, and form factor. In this disclosure, the UE used for this purpose is referred to as an NR-reduced capability (redcap) UE / device, or simply (NR) redcap UE / device. Additionally, a standard NR terminal (distinguished from a redcap device) that supports all or one or more of the main 5G use cases is referred to as an NR (standard) UE / device. An NR UE can be a terminal equipped with all the key 5G capabilities defined in IMT-2020 (peak data rate, user-experienced data rate, latency, mobility, connection density, energy efficiency, spectrum efficiency, regional service efficiency, etc.), while a redcap UE can be a UE that intentionally reduces some capabilities to achieve lower device cost, lower power consumption, and a smaller form factor.

[0225] For the convenience of this disclosure, the 5G use case area spanning mMTC and eMBB or mMTC and URLLC (which is the target use case of the Redcap device) is referred to as a redcap use case. For example, a redcap use case could be: i) Fully Connected Industries - Sensors and actuators are connected to the 5G network and core.

[0226] - Includes use cases and requirements for large-scale industrial wireless sensor networks (IWSN).

[0227] - Requires a small device form factor, relatively low-end services with several years of battery life, and URLLC services with very high requirements.

[0228] These services have higher requirements than Low Power Wireless Area (LPWA) (i.e., LTE-M / NB-IoT), but lower than URLCC and eMBB.

[0229] Devices in this environment include, for example, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, actuators, etc.

[0230] ii) Smart Cities

[0231] - The smart city vertical includes data collection and processing to more effectively monitor and control urban resources and provide services to urban residents.

[0232] Specifically, the deployment of surveillance cameras is not only a major part of smart cities, but also a major part of factories and industries.

[0233] - iii) Wearables

[0234] Wearable use cases include smartwatches, rings, health-related devices, and medical monitoring devices.

[0235] - One characteristic of the use case is the small size of the device.

[0236] Low-power wireless area (LPWA) UEs (e.g., LTE-M, NB-IoT, etc.) may not support Redcap use cases in terms of bit rate, latency, etc. NR UEs may be functionally supported, but may be inefficient in terms of terminal manufacturing cost, form factor, and battery life. Supporting the aforementioned use case areas in 5G networks as a Redcap UE with characteristics such as low cost, low power, and small form factor can reduce the manufacturing and maintenance costs of the UE.

[0237] In this disclosure, redcap use cases have highly diverse requirements in terms of UE complexity, target bit rate, latency, and power consumption. The requirements that a redcap UE should meet are referred to as redcap requirements. Redcap requirements can be divided into general requirements that apply to all redcap use cases and use case-specific requirements that apply only to some use cases.

[0238] Redcap requirements can be met through various features (combinations) provided by the UE and base station. Below are examples of features and sub-features supported by the UE / base station to meet redcap requirements.

[0239] i) Features of reduced complexity

[0240] - Reduce the number of UE RX / TX antennas

[0241] - Reduced UE bandwidth

[0242] - Half-duplex FDD

[0243] - Flexible UE processing time

[0244] - Relaxed UE processing capabilities

[0245] ii) Power saving

[0246] - Reduced PDCCH monitoring with limited blind decoding (BD) and control resource element (CCE) constraints

[0247] - Extended Discontinuous Receiver (DRX) for RRC deactivation / inactivity and / or idle.

[0248] - Radio Resource Management (RRM) for Fixed Installations

[0249] iii) Coverage restoration / enhancement

[0250] The above redcap use cases can define and support one or more UEs, and this disclosure considers the following two cases.

[0251] Case A) Support Redcap use cases as a single UE (in the case of a single device type).

[0252] Case B) Support Redcap use cases in the form of multiple UEs (in the case of multiple device types).

[0253] In scenario A), a redcap UE can be a UE that satisfies all the aforementioned redcap requirements (i.e., both general and use-case-specific requirements) and can also be a UE that supports all redcap use cases. In this case, due to the increased complexity of the UE, there may be an increase in cost due to the need to satisfy various requirements simultaneously; however, the cost reduction impact of mass production based on use case expansion can be expected at the same time. Scenario B) can be a case where a UE type is defined and supported for each redcap use case, taking into account the fact that redcap use case requirements are quite diverse. Even in this case, all general requirements can usually be satisfied. Here, each device type defined for each use case is called a redcap device type. Scenario B) includes the case where several similar use cases are grouped in terms of requirements and they are supported as a single UE. Each of these redcap device types can support some predefined or specific combinations of redcap UE features. If multiple redcap device types are defined and redcap use cases are supported, there are advantages such as the ability to support specific redcap use cases with more optimized redcap UEs in terms of cost and power consumption. For example, IWS use cases can be supported by very small, inexpensive, and power-efficient UEs.

[0254] In this disclosure, reduced capability may include the meaning of reduced / lower complexity / cost, reduced bandwidth, etc.

[0255] In scenario B), that is, when supporting redcap use cases across multiple device types, the following approach can be considered for classifying redcap device types. This approach can also be applied to scenario A), that is, distinguishing redcap devices from NR UEs.

[0256] To support the operation of redcap UEs, which are distinct from NR UEs, redcap UEs may need to report their own device type information to the base station.

[0257] Figure 10A process for reporting the device type of a redcap device in a wireless communication system to which this disclosure may be applied is illustrated.

[0258] exist Figure 10 In this process, the reporting procedure can (re)use the UE capability transmission procedure defined in TS 38.331. The base station can obtain redcap device type information by receiving UE capability information and use the obtained device information when scheduling the corresponding UE.

[0259] refer to Figure 10 In the RRC_CONNECTED state, the base station / network performs a capability query / request for the UE (SH102). The UE includes the redcap device type information in the UE capability information and sends it to the base station / network (SH104).

[0260] - Classification Method 1

[0261] Redcap device types can be categorized based on one of the main requirements. These main requirements could be, for example, the maximum supported data rate (peak bit rate), latency, mobility (stationary / fixed, portable, mobile, etc.), battery life, complexity, coverage, etc. For each category of redcap device type, UE features (combinations) that must be enforced or can be optionally supported can be defined in the specification. This can reduce the overhead of individually signaling whether features are supported for each device type.

[0262] The redcap device type information included in the UE capability information and reported by the UE to the base station / network can be sent to the base station, for example, through a specific field (e.g., RedCapDeviceType) of the UE-NR capability information element (IE). For instance, when classified as redcap device type 1, 2, ..., the value of the RedCapDeviceType field can be expressed as an integer such as 1, 2, ..., or a combination of characters and integers such as r1, r2, ... In this way, the UE reports its associated device type and parameters by including a field in the capability information, thus offering advantages in terms of signaling overhead.

[0263] Example) A method for classifying redcap device types based on the maximum supported data rate and reporting this information to the base station.

[0264] The maximum data rate supported by an NR terminal is determined by the equation shown in Table 8 below in TS 38.306. Table 8 illustrates the TS 38.306 standard.

[0265] [Table 8]

[0266] Here, the UE calculates the parameters required for the equation of the maximum supported data rate by the NR UE in the RRC_CONNECTED state based on the base station's request report.

[0267] The following examples illustrate these parameters and the RRC IE including the corresponding parameters.

[0268] - FeatureSetDownlink IE: Scaling Factor

[0269] - FeatureSetDownlinkPerCCIE: maxNumberMIMO-LayersPDSCH, supportedModulationOrderDL, supportedBandwidthDL, supportedSubCarrierSpacingDL

[0270] - FeatureSetUplink IE: Scaling Factor

[0271] - FeatureSetUplinkPerCC IE: maxNumberMIMO-LayersCB-PUSCH, maxNumberMIMO-LayersNonCB-PUSCH, supportedModulationOrderUL, supportedBandwidthUL, supportedSubCarrierSpacingUL

[0272] In the case of Redcap UEs, where the method of classifying Redcap device types based on the maximum supported data rate predefines the values ​​of the aforementioned parameters for each device type in the standard, the UE sets the value of the RedCapDeviceType field in the UE-NR-Capability IE to a specific value to indicate the aforementioned parameter information along with the Redcap device type information to the base station. Compared to the conventional operation of NR UEs sending the aforementioned parameters to the base station by including them in the UE capability information, the signaling overhead can be expected to be reduced by reporting the device type and its associated parameters through a single field by Redcap UEs. The base station can obtain the device type, the maximum supported data rate, and the values ​​of the parameters listed above through the value of the RedCapDeviceType field and use them for UE scheduling.

[0273] - Classification Method 2

[0274] Alternatively, instead of classifying redcap device types based on primary requirements, they can be classified based on combinations of UE features that must be supported or can be optionally supported. This may be a more appropriate approach when features that need to be supported or can be supported for each use case are clear. The combinations of UE features predefined in the standard for each redcap device type are called feature sets, where the feature sets that must be supported for each device type are called the mandatory feature sets for the corresponding device type or defining device type. In this approach, the definition of redcap device types may not be specified in the standard, which could mean that the aforementioned redcap use cases are supported as separate terminal types supporting different feature sets.

[0275] In the above-described approach, a redcap UE can report the supported redcap device types or use cases to the base station by reporting a predefined set of features. This may be a more suitable approach to support various use cases through a variety of optional features without distinguishing individual UE categories. The aforementioned feature set can be replaced by a combination of capability parameters, i.e., a set of capability parameters. The aforementioned feature set can be a mandatory feature set predefined in the standard for each redcap device type. For the above operations, the candidate feature set (i.e., the feature pool) for the redcap device (type) can be previously defined or set in the standard. The redcap device can report the mandatory feature set defined for each type to the base station based on its own type. In addition to the mandatory feature set, the UE can also additionally report optional feature sets to the base station. The UE can perform additional or more optimized operations for specific use cases by additionally selecting and reporting optional feature sets. For example, in the case of a device type used for a surveillance camera use case, where wired power UEs and power UEs coexist via battery, the mandatory feature set does not include power-saving features and can be designated as optional features. Therefore, it can be selectively supported according to the details of the terminal and reported to the base station when supported. The base station can determine whether a feature is supported by the presence or absence of the corresponding parameter in the feature set reported by the redcap UE, and can reflect the feature when scheduling the corresponding UE.

[0276] - Classification Method 3

[0277] Alternatively, Redcap device types can be classified based on a combination of capability parameters. These capability parameters can be parameters that determine the aforementioned Redcap requirements. For example, capability parameters used to determine the Redcap device type could be the bandwidth, modulation order, number of MIMO layers, etc., that the UE supports to determine the maximum supported data rate requirement. The values ​​of these parameters can be a list of actually supported values, or the maximum value among the supported values.

[0278] Example) Determine the capability parameters for Redcap device type

[0279] Supported bandwidth (N) RB ): (Maximum) UE channel bandwidth or (maximum) UE transmission bandwidth; in RB units

[0280] Supported modulation order (Q) m For QPSK, Q m =2; for 16 QAM, Q m =4; For 64 QAM, Q m =6; etc.

[0281] - Number of supported MIMO layers (N) L ): can be expressed using the number of antennas (N) a )replace.

[0282] The combination of capability parameters that determines a Redcap device type is called the capability parameter set for that device type. For example, a Redcap device type can be defined by categorizing the capability parameter set values ​​in ascending (or descending) order of the maximum supported data rates. The example below illustrates defining M device types in ascending order of the maximum supported data rates.

[0283] Redcap device type classification based on capability parameter set values ​​(example): - Device Type 1: {N L N RB Q m}={1, 25, 2} - Device Type 2: {N L N RB Q m} = {1, 25, 4} or {1, 52, 2} - Device type 3: {N L N RB Q m} = {1, 52, 4} or {1, 106, 2} - Device type 4: {N L N RBQ m} = {1, 106, 4} or {2, 106, 2} - Device type 5: {N L N RB Q m}={1, 106, 6} - Device Type 6: {N L N RB Q m}={2, 106, 4} - Device type 7: {N L N RB Q m}={2, 106, 6} ... - Device type M: {N L N RB Q m} = {X, Y, Z} For example, N RB The value can be one of the values ​​defined in Table 9 below (the maximum number of RBs, which can be configured for each UE channel bandwidth) in the case of NR FR1 (frequency range 1, i.e., 6 GHz or less). The example above is based on the subcarrier spacing (SCS) = 15 kHz criterion. If the redcap device supports SCS = 30 kHz and the cell to be connected uses SCS = 30 kHz for data transmission, then the N value in the example above is based on SCS = 15 kHz. RB The values ​​can be referenced below. Figure 9 Replaced with the value corresponding to SCS=30 kHz.

[0284] Table 9 illustrates the maximum transmission bandwidth configuration for each SCS in NR FR1 (N RB ).

[0285] [Table 9]

[0286] In the device type classification example, device types 2 / 3 / 4 correspond to a device type defined using multiple capability set values. When device types are classified based on the maximum supported data rate as described above, defining multiple capability parameter set values ​​for a device type can mean a combination of maximum supported data rates that are the same or similar.

[0287] The device types that can be supported for each use case can be defined using the device types defined in the examples above, and based on the supported device types, the base station can restrict cell access or perform subscription-based barring.

[0288] Example) Supported device types for each use case.

[0289] - Industrial Wireless Sensors (IWS): Device Types 1 and 2

[0290] - Video surveillance: Device types 2 and 3

[0291] - Wearable devices: Device types 4, 5, 6, 7

[0292] Furthermore, to avoid increased costs due to market segmentation caused by excessive device type division, the number of device types, M, can be limited. As an extreme example, if M=1, the redcap UE is not divided into multiple device types; that is, a single device type can support all the aforementioned target use cases. As another example, if M=3, the device types that can be categorized by device type and supported by use cases can be defined as follows.

[0293] Example) Classification based on device type according to capability set value (Example: in the case of M=3)

[0294] - Device Type 1: {N L N RB Q m} = {1, 25, 2} (or {1, 25, 4} or {1, 52, 2})

[0295] - Device Type 2: {N L N RB Q m} = {1, 52, 4} or {1, 106, 2}

[0296] - Device type 3: {N L N RB Q m}={2, 106, 6}

[0297] Example) Supported device types for each use case (Example: M=3 case)

[0298] - IWS: Device Type 1

[0299] - Video surveillance: Device type 3

[0300] - Wearable devices: Device type 7

[0301] The bandwidth capability of a Redcap UE (i.e., the UE's maximum bandwidth) can be determined as the minimum bandwidth required to meet the bit rate of the target use case. It is anticipated that the maximum UE bandwidth will be reduced to decrease the cost of the radio frequency (RF) device and / or baseband processing, and also to reduce power consumption. Here, the required bit rate can refer to the peak rate or the maximum supported data rate, rather than the average bit rate or reference bit rate, considering that device manufacturing costs are determined by the peak rate or the maximum supported data rate. When determining the maximum bandwidth supporting the required bit rate, other parameters for determining the required bit rate (e.g., the number of antennas (N)) can be considered. L ), modulation order (Q) m (etc.) assuming specific values. For example, in the case of device type 3 in the above example, a peak rate of approximately ~28 MHz can be supported, and here, assuming {N L =1, Q m In the case of {N=2}, the maximum required bandwidth is 20 MHz (106 RBs), and assuming {N... L =1, Q m In the case of {N=2}, the maximum required bandwidth is 10 MHz (52 RBs). Alternatively, in {N... L =2, Q m In the case of 4, it can be 5 MHz (25 RBs).

[0302] - Device type 3: {N L N RB Q m} = {1, 52, 4} or {1, 106, 2}

[0303] Within the maximum UE bandwidth of a Redcap UE, transmission / reception can be performed using the transmission bandwidth allocated by network configurations such as RRC signaling.

[0304] The minimum bandwidth of a UE can be defined as the minimum value among the NR UE channel bandwidths (or transmission bandwidths) that are greater than or equal to the NR SSB bandwidth.

[0305] Example) In FR1, for an NR SSB with SCS=15 kHz and minimum UE bandwidth, 5 MHz; for an NR SSB with SCS=30 kHz, 10 MHz; Example) In FR2, 40 MHz for an NR SSB with SCS=120 kHz and minimum UE bandwidth; 80 MHz for an NR SSB with SCS=240 kHz. This can enable access to NR cells via NRS SB while achieving low power consumption by supporting services with minimal bandwidth and small required bit rates.

[0306] - Classification Method 4

[0307] Considering that the bandwidth capability of a Redcap UE is determined by the required bit rate for each use case, Redcap device types can be classified based on UE bandwidth capability. The bandwidth capability determining a Redcap device type can indicate, for example, the supported bandwidth (NRB), that is, the (maximum) UE channel bandwidth or (maximum) UE transmission bandwidth in RBs. Alternatively, it can be the minimum UE channel bandwidth or the minimum UE transmission bandwidth. More specifically, the following classifications are possible.

[0308] Classification method 4-1) Classify by maximum bandwidth and configure and use actual data transmission / reception bandwidth (<= maximum bandwidth).

[0309] Classification method 4-2) is classified by minimum bandwidth, and the actual data transmission / reception bandwidth (>= minimum bandwidth) is configured and used.

[0310] Classification method 4-3) Define one or more supported bandwidths (sets) for each device type, and configure and use the actual data transmission / reception bandwidth within the corresponding bandwidth (set).

[0311] For classification methods 4-1 / 2 / 3, the maximum bandwidth can be limited to a value less than the NR bandwidth (e.g., 20 MHz), and the minimum bandwidth can be greater than or equal to the SSB bandwidth (e.g., 5 MHz in the case of a 15 kHz SSB).

[0312] Initial access and PUCCH transmission methods for specific types of UEs (e.g., RedCap UEs)

[0313] In the following, this disclosure presents a method for initial access and PUCCH transmission for a Redcap UE. The aforementioned method and sub-contents for classifying Redcap device types and reporting to the base station, as well as the method and sub-contents supporting initial access and UL frequency hopping for Redcap UEs, can be considered the background of the main proposal of this disclosure.

[0314] In the following description of this disclosure, a standard terminal means a terminal that supports all the capabilities required by a wireless communication system (e.g., an NR system), and a specific type of terminal means a terminal that supports specific requirements and / or specific features and / or specific use cases among all the capabilities required by a wireless communication system, such as a redcap UE. Additionally, in the following description of this disclosure, for ease of explanation, it may be referred to as a redcap UE, but this is merely an example, and this disclosure is not limited thereto, and a redcap UE can be interpreted as a specific type of terminal.

[0315] In NR cells that support Redcap UEs—that is, in cells where standard UEs and redcap UEs coexist or can coexist—for resource efficiency, it is preferable to share as many resources as possible between the standard UE and the redcap UE. This is because if the available / scheduling resources for the standard UE and the available / scheduling resources for the redcap UE are completely separated from each other, problems such as reduced resource utilization and limited scheduling flexibility from the base station's perspective may arise. However, in the following situation, conventional methods cannot effectively support resource sharing between the standard UE and the redcap UE during random access procedures for cell access.

[0316] 1. Due to differences in coverage performance between the NR UE and the redcap UE in the Msg2 (i.e., RAR), msg4, or msgB steps, (additional) repetitions may be required for the redcap UE. In this case, the repetitions in the RACH procedure (i.e., random access procedure) of the redcap UE may be applied equivalently to at least one or more of, for example, Msg1 to Msg4 / MsgA to MsgB, or may be applied individually as a separate configuration for each message.

[0317] 2. When considering the impact on traditional NR UEs, the initial UL BWP cannot be configured within the maximum UE bandwidth of the redcap UE.

[0318] 3. When the impact on NR UEs is unavoidable during the random access process due to the relaxed UE processing time of Redcap UEs.

[0319] 4. In the case of configuring and operating a separate initial UL BWP for the redcap UE for reasons 1, 2 and 3 above.

[0320] This disclosure relates to a method for supporting initial access and PUCCH transmission of a redcap UE in an NR cell where standard UEs and redcap UEs coexist. However, this disclosure is not limited to the above scenario and should not be applied to it; rather, it can be equivalently applied to the initial access and PUCCH transmission of NR UEs.

[0321] Implementation Method 1: Random Access Response (RAR) Reception Method for RedCap UEs

[0322] Considering UE complexity, RedCap UEs can support limited UE bandwidth. If RACH timing (RO) (or PRACH timing) is configured in the standard approach for NR UEs, the following situation may occur: the (initial) UL bandwidth of such a RedCap UE may not cover all frequency areas of the configured RO. In this case, after sending an RA preamble (i.e., PRACH preamble) for initial access during the random access (RA) process, the redcap UE may need to receive RAR after performing a frequency retuning operation. Additionally, if the UE is operating in half-duplex FDD in the FDD band (during the initial access process), it may need to receive RAR after frequency retuning.

[0323] In this scenario, DL reception, including PDCCH monitoring, may be impossible during UL-to-DL handovers (accompanied by frequency retuning) or Tx-to-Rx handovers. Therefore, with this in mind, the RAR window of a redcap UE can be configured / defined to start up to X symbols or X' μs later than the standard UE's RAR window. Here, X or X' can be greater than or equal to the transition time (N) defined in the TS 38.211 standard. Rx-Tx or N Tx-Rx The value of the frequency retuning time. Alternatively, it may be redefined in a standard that takes into account the characteristics of the redcap UE, or it may be configured by the base station via higher-level signaling through system information, etc.

[0324] The standard RAR window for NR UEs is defined in the following TS 38.213 specifications (Table 10) and TS 38.321 specifications (Table 11).

[0325] [Table 10]

[0326] Referring to Table 10, the RAR window begins at the first symbol of the earliest CORESET, which is configured for the UE to receive the PDCCH for the type 1-PDCCH common search space (CSS) set after the last symbol of the PRACH timing corresponding to the PRACH transmission (i.e., RO).

[0327] [Table 11]

[0328] Referring to Table 11, when sending the random access preamble, the MAC entity can start from the end of the random access preamble transmission at the first PDCCH timing, according to the ra-ResponseWindow (i.e., the length of the RAR window) configured in RACH-ConfigCommon.

[0329] To define the RAR window of the redcap UE in the same manner as described above, the redcap UE may monitor DCI format 1_0, which has a CRC scrambled from the first symbol of the earliest CORESET via RA-RNTI, the earliest CORESET starting at least X symbols or X' μs after the last symbol of the RO used for the RA preamble transmission. Alternatively, the PDCCH monitoring period for RAR reception (i.e., the start point of the RAR window or the start point of the RAR window counter) may be defined as the first symbol of the earliest CORESET starting at least X symbols or X' μs after the last symbol of the RO used for the RA preamble transmission. The values ​​of X or X' are as described above. Alternatively, the X value in symbol units may be a value greater than a minimum number of symbol durations, which is 1 greater than the transition time and / or frequency retuning time.

[0330] To configure the RAR window for a redcap UE (in addition to the RAR window used for standard UEs), a separate RAR window for the redcap UE can be used. The size of the RAR window can be determined by the configuration value of the RAR window counter. Here, the size of the separate RAR window for the redcap UE can be the same as the existing RAR window (without configuring a separate size) or it can be configured separately. If it has the same size, the RAR window for the redcap UE can have a predetermined time difference (interleaved) form as the regular RAR window.

[0331] Alternatively, the base station can configure the redcap UE to use or share the same RAR window as the standard UE without defining a separate RAR window. In this case, this could mean that the base station implements a guaranteed RAR window, enabling the base station to meet the aforementioned transition time and / or frequency retuning time conditions.

[0332] Implementation Method 2: RedCap UE's Msg3 PUSCH Transmission Method

[0333] During the initial access RA process for NR UEs, Msg3 PUSCH transmission is scheduled via RAR UL license. As shown in Table 12 below, TS 38.213 specifies the field configuration for RAR UL license and the corresponding Msg3 PUSCH frequency domain resource allocation (FDRA) and frequency hopping (FH) information.

[0334] [Table 12]

[0335] As described above, in the standard RA process for initial access, Msg3 FDRA and FH are determined based on the initial UL bandwidth. Here, the initial UL bandwidth means the bandwidth of the initial UL BWP.

[0336] However, if the initial UL BWP is not limited to the maximum UE bandwidth of the redcap UE due to the traditional effects in NR cells that simultaneously support standard UEs and redcap UEs (i.e., when the initial UL bandwidth is greater than the redcap UE bandwidth), the following Msg3 PUSCH transmission method for the redcap UE can be considered.

[0337] In the methods presented below, when a separate initial UL BWP is configured and operated for the redcap UE for the reasons described above, the redcap UE bandwidth may include the meaning of either the separate initial UL BWP for redcap or the bandwidth of a separate initial UL BWP. The bandwidth of the separate initial UL BWP for the redcap UE may be limited to less than the redcap UE bandwidth.

[0338] For the reasons stated above, in this disclosure, the meaning of "the bandwidth of the initial UL BWP or the initial UL bandwidth is greater than the redcap UE bandwidth" or "the base station shall configure the initial UL bandwidth of the standard UE to be greater than the redcap UE bandwidth" may include the meaning of "configured / configured a separate initial UL BWP for redcap" for this reason.

[0339] Implementation Method 2-1: Method for deactivating (disabling or turning off) frequency hopping (FH) when the initial UL bandwidth is greater than the redcap UE bandwidth.

[0340] When the initial UL bandwidth for the standard UE needs to be configured to be greater than the redcap UE bandwidth, the base station can turn off (or disable) the frequency hopping (FH) of the redcap UE's Msg3 PUSCH and schedule the first frequency hopping indicated by the RAR UL-permitted FDRA to be included in the redcap UE bandwidth. Therefore, the base station can receive both the standard UE's and redcap UE's PUSCH transmissions. For this purpose, the base station can configure the value of the RAR UL-permitted FH flag to 0. The RAR UL-permitted FH flag can be configured independently and can be used to enable / disable the redcap UE's FH. Alternatively, if the initial UL bandwidth is greater than the redcap UE bandwidth, the redcap UE can assume that FH is off (or the FH flag value is 0) and transmit the Msg3 PUSCH to the base station via the frequency area indicated by the RAR UL-permitted FDRA in the manner described above.

[0341] Figure 11 This is a diagram illustrating the frequency resource allocation of a Msg3 PUSCH without frequency hopping according to an embodiment of the present disclosure.

[0342] exist Figure 11 In the example, when the initial UL bandwidth of the standard UE is greater than the redcap UE bandwidth, the case of the base station scheduling the Msg3 PUSCH of the redcap UE within the redcap UE bandwidth without having FH is illustrated.

[0343] refer to Figure 11 The redcap UE can perform transmission on the MsgPUSCH via the first frequency hopping (1101) of the frequency area indicated by the FDRA authorized by the RAR UL. Furthermore, the redcap UE can perform transmission on the MsgPUSCH via the second frequency hopping (1102) of the frequency area indicated by the FDRA authorized by the RAR UL without frequency hopping (either by instruction from the base station or by assumption of the UE).

[0344] Implementation Method 2-2: Method for Different Interpreting RAR UL Licensed FDRA and / or FH Marks

[0345] When a base station needs to configure the initial UL bandwidth for a standard UE to be greater than the redcap UE bandwidth, the redcap UE can apply / interpret PUSCH scheduling information / results indicated by the RAR UL-permitted FDRA and / or FH flags, or by field values ​​of FDRA and / or FH flags that differ from those of the standard UE. Here, when the initial UL bandwidth is greater than the redcap UE bandwidth, the PUSCH scheduling information / results indicated by the RAR UL-permitted FDRA and / or FH flags can be as follows.

[0346] [Case 1] When the first frequency hopping belongs to / is included in the redcap UE bandwidth, and the second frequency hopping does not belong to / is not included in the redcap UE bandwidth.

[0347] [Case 2] When the first frequency hopping is not part of / not included in the redcap UE bandwidth, and the second frequency hopping is part of / included in the redcap UE bandwidth.

[0348] [Scenario 3] When both the first and second frequency hopping belong to / are included in the redcap UE bandwidth

[0349] [Case 4] When neither the first frequency hopping nor the second frequency hopping belongs to / is included in the redcap UE bandwidth.

[0350] In cases 1 and 2, when FH is enabled for Msg3 PUSCH and only one of the two frequency hopping frequencies belongs to the redcap UE bandwidth, the base station can use the frequency resources of the frequency hopping frequency belonging to the redcap UE bandwidth to configure / instruct both the first and second frequency hopping frequencies to be transmitted without FH.

[0351] Figures 12 to 14 This is a diagram illustrating the frequency resource allocation of the Msg3 PUSCH considering frequency hopping according to an embodiment of the present disclosure.

[0352] Figure 12 Case 1 is illustrated. (See reference.) Figure 12 The redcap UE can perform transmissions on the first frequency hopping (1201) and the second frequency hopping (1202) within the frequency area indicated by the first frequency hopping or the FDRA authorized by the RAR UL. In other words, the redcap UE can perform transmissions on the first frequency hopping (1201) of MsgPUSCH within the frequency area indicated by the FDRA authorized by the RAR UL. Furthermore, assuming no frequency hopping, the redcap UE can perform transmissions on the second frequency hopping (1202) of MsgPUSCH within the frequency area indicated by the FDRA authorized by the RAR UL or the frequency area of ​​the first frequency hopping.

[0353] Figure 13 Case 2 is illustrated. (See reference.) Figure 13 The redcap UE can perform transmissions for both the first frequency hopping (1301) and the second frequency hopping (1302) within the frequency region of the second frequency hopping frequency belonging to the redcap UE bandwidth without having an FH. In other words, the redcap UE can perform transmissions for both the first frequency hopping (1301) and the second frequency hopping (1302) of the Msg PUSCH within the frequency region of the second frequency hopping (1302) of the Msg PUSCH as determined by the FDRA licensed by RAR UL.

[0354] Figure 14 Case 3 is illustrated. (See reference.) Figure 14 Both the first frequency hopping (1401) and the second frequency hopping (1402) of Msg PUSCH can belong to / be included in the redcap UE bandwidth. In this case, the redcap UE can perform transmissions for the first frequency hopping (1401) and the second frequency hopping (1402) of Msg PUSCH in each frequency area indicated by the RAR UL-permitted FDRA and FH flag (FH enabled).

[0355] In scenario 4, the redcap UE can transmit Msg3 PUSCH via the first frequency hopping (or the second frequency hopping) without having an FH. However, since the first frequency hopping (or the second frequency hopping) is not part of the initial UL bandwidth received by the redcap UE via system information (e.g., SIB1), the redcap UE can perform Msg3 PUSCH transmission after frequency retuning.

[0356] Alternatively, in this case, the redcap UE assumes that the corresponding cell has blocked or does not allow access to the redcap UE, and the redcap UE can continue to perform cell search for other accessible cells.

[0357] Alternatively, the base station can disable the redcap UE by configuring / indicating that some or all of the Msg3PUSCH indicated by the RAR UL-permitted FDRA and / or FH flag values ​​do not belong to the redcap UE bandwidth or the initial UL bandwidth of the redcap UE. Alternatively, the base station can disable the redcap UE by ensuring that the scheduling result of the Msg3 PUSCH indicated by the RAR UL-permitted FDRA and / or FH flag values ​​belongs to one of Case 1, Case 2, or Case 4 above.

[0358] Furthermore, the Msg3 PUSCH scheduling information can be interpreted based on the initial UL bandwidth of Redcap.

[0359] RedCap UEs can determine their final frequency hopping by applying a Modulo-Distribution (MOD) operation based on their own (separate) initial UL bandwidth (for frequency hopping that does not belong to the UE). The initial UL bandwidth of the redcap UE, as a criterion, can be cell-specifically configured by the base station via system information (e.g., SIB1). Otherwise, the initial UL bandwidth information of the redcap UE can be sent to the base station earlier in the Msg1 step. For convenience of MOD operation, it can be restricted to the standard UE initial UL bandwidth = N. (RedCap UE Initial UL Bandwidth) (e.g., N = 1, 2, 4, 8, or a positive integer). For example, a separate initial UL BWP for redcap can be configured with a bandwidth value of floor(initial_UL_bandwidth / N). Here, floor(x) is the largest integer not greater than x. Here, initial_UL_bandwidth means the bandwidth of the initial UL BWP for a standard UE and can be in units of RB.

[0360] Figure 15 This is a diagram illustrating the frequency resource allocation of Msg3 PUSCH using MOD operations according to an embodiment of the present disclosure.

[0361] exist Figure 15 The example illustrates the case where a single initial UL BWP for redcap has a bandwidth of floor(initial_UL_bandwidth / 2) (i.e., N=2). See reference. Figure 15 The redcap UE can perform first frequency hopping (1501) transmission for the Msg PUSCH through the frequency area indicated by the FDRA authorized by the RAR UL. Additionally, the redcap UE can perform second frequency hopping (1502) transmission for the Msg PUSCH through the frequency area determined by applying MOD calculations as described above.

[0362] according to Figure 15 For example, performing modulo operations based on the initial UL bandwidth of the redcap UE can result in no frequency diversity gain. To mitigate these drawbacks, a method could be considered to arrange / determine frequency hopping at the boundaries of the initial UL bandwidth based on the redcap, rather than at frequency locations symmetrical to simple modulo operations.

[0363] Figure 16 This is a diagram illustrating the frequency resource allocation of Msg3 PUSCH in an application image according to an embodiment of this disclosure.

[0364] exist Figure 16 In this context, when the second frequency hopping occurs outside the initial redcap UE bandwidth, it can be deployed by mirroring based on the upper boundary of the initial redcap UL bandwidth. In other words, referencing... Figure 16 The redcap UE can perform first frequency hopping (1601) transmission for the Msg PUSCH through the frequency area indicated by the FDRA authorized by RARUL. Additionally, the redcap UE can perform second frequency hopping (1602) transmission for the Msg PUSCH through the frequency area determined by mirroring the upper boundary of the redcap initial UL bandwidth as described above.

[0365] By doing so, with Figure 15 In contrast to the example, frequency diversity gain can be expected.

[0366] Alternatively, in the case of a redcap UE, Msg3 PUSCH can be transmitted in a different frequency region than that of a standard UE by applying a frequency offset to the FDRA value permitted by the RAR UL license. Compared to some frequency hopping overlap methods, this method may have the advantage that detection at the base station is easy. Alternatively, when FH activation (enabled or on) is indicated in the RAR UL license, the frequency offset value of the second frequency hopping can be interpreted differently from the regular frequency offset value, or it can be configured / defined to apply an additional frequency offset to the regular second frequency hopping frequency offset value.

[0367] When the frequency offset value of the second frequency hopping is interpreted differently than in the prior art, the redcap UE can apply it by multiplying the location value of the second frequency hopping calculated based on Table 8.3-1 of TS 38.213 (see Table 12) by a scaling factor. For example, the scaling factor could be redcap_UE_initial_UL_bandwidth / normal_UE_initial_UL_bandwidth. Alternatively, the location of the second frequency hopping in the frequency domain can be determined by applying the UE bandwidth of the redcap UE or the initial UL bandwidth of the redcap UE instead of the initial UL bandwidth of the standard UE.

[0368] Regarding embodiments 2-1 and 2-2 described above, the redcap UE bandwidth can be interpreted by replacing the RO bandwidth configured for initial access by the Redcap UE. That is, based on the RO bandwidth, it is possible to determine whether FH deactivation (off or disabled), whether FH can be performed, or whether FDRA can be analyzed. Here, the RO can be configured individually for the Redcap UE, or it can be a RO configured for the NR UE without a separate configuration. In this case, the Redcap UE can operate by assuming the RO bandwidth is the initial UL BWP of the Redcap UE.

[0369] Implementation methods 2-3: UE identification via redcap sent through Msg3 PUSCH

[0370] When transmitting Msg3 PUSCH for standard UEs and redcap UEs using resources differentiated in the time / frequency domain or different FH modes via the methods described above, the base station can distinguish the UE (type) (e.g., standard UE or redcap UE) by performing blind detection (BD) on the time / frequency transmission resources of the Msg3 PUSCH or the FH modes classified as described above. This method can be used in the Msg3 step to differentiate from standard UEs when early UE IDs are not supported in Msg1.

[0371] Alternatively, it can be used to provide additional UE (type) information along with the earlier UE ID in Msg1. For example, the additional UE (type) information may include information about the number of Rx antenna branches (or ports) or information indicating whether specific features of a redcap UE are supported.

[0372] Furthermore, this method can be applied to (additional) UE identification even when it is equal to the initial UL bandwidth of the standard UE. The classification of Msg3 PUSCH resources is not limited to the frequency domain. For example, Msg3 PUSCH for standard UEs and redcap UEs can be configured / defined to be transmitted separately by different interpretations of the Time Domain Resource Allocation (TDRA) values ​​indicated by the RAR UL license (e.g., by applying additional offsets) or in the form of TDM.

[0373] Implementation Methods 2-4: After transmitting Msg3 using one of the methods described above, the redcap UE can be instructed to retransmit the Msg3 PUSCH from the base station. In this case, the Msg3 PUSCH retransmission can be indicated using DCI format 0_0 with Cyclic Redundancy Check (CRC) scrambled via Temporary Cell (TC)-RNTI. When instructing Msg3 PUSCH retransmission via DCI, information such as FH and FDRA / TDRA for Msg3 PUSCH retransmission can follow the Msg3 retransmission DCI instruction. If the initial UL bandwidth is greater than the redcap UE bandwidth, the method proposed in the RAR UL license can be applied to the interpretation / operation of FDRA / TDRA and / or FH.

[0374] If a redcap UE fails in the initial Msg3 transmission and is instructed to retransmit, it can use resources distinct from those of the standard UE in a different manner than the initial transmission. For example, when a redcap UE transmits frequency resources (such as FDRA and FH modes) distinct from those of the standard UE in the initial transmission, the redcap UE instructing to retransmit can do so by applying a time offset to the TDRA value or by using resources distinct from those of the standard UE in a TDM manner.

[0375] Implementation Method 3: Initial Access and PUCCH Transmission Method for Redcap UE

[0376] As shown in Table 13 below, the PUCCH transmission method is defined in the TS 38.213 specification before the UE receives the dedicated PUCCH resource configuration.

[0377] [Table 13]

[0378] Referring to Table 13, if the UL BWP (e.g., BWP-UplinkCommon) configuration does not provide a useInterlacePUCCH-PUSCH configuration, the UE transmits PUCCH using frequency hopping. Otherwise, the UE transmits PUCCH without frequency hopping.

[0379] If the UE provides HARQ-ACK information within a PUCCH transmission in response to the detection of a scheduled PDSCH reception or SPS PDSCH release in DCI format, then the UE determines that it has index r PUCCH PUCCH resources, 0≤r PUCCH≤15, such as (Where, floor(x) is the largest integer not greater than x). Here, N CCE It represents the number of CCEs in the CORESET received by the PDCCH carrying the DCI format. This is the index of the first CCE used for PDCCH reception. Δ PRI It is the value of the PUCCH resource indicator field in the DCI format.

[0380] Additionally, if floor(r) PUCCH If / 8) = 0, then the UE will determine the PRB index of the PUCCH sent in the first frequency hopping as And the PRB index of the PUCCH sent in the second frequency hopping is determined as Here, N CS It is the total number of initial CS indices in the initial cyclic shift (CS) index set.

[0381] On the other hand, if floor(r) PUCCH If ( / 8) = 1, then the UE will determine the PRB index of the PUCCH sent in the first frequency hopping as... And the PRB index of the PUCCH sent in the second frequency hopping is determined as Furthermore, the UE determines the total number of initial CS indices in the initial CS index set as (r PUCCH -8) modN CS .

[0382] As specified in Table 13 above, before a UE is configured with dedicated PUCCH resources, the UE is defined / specified to always perform frequency hopping (FH) based on the bandwidth of the initial UL BWP used for PUCCH transmission. The FH issue when the initial UL BWP bandwidth is greater than the redcap UE bandwidth can be applied in the same way as proposed in Msg3 PUSCH. For example, in the above case, the proposed method for PUCCH can be applied by replacing Msg3 PUSCH with PUCCH and interpreting it as previously proposed in Msg3 PUSCH. That is, unlike conventional standard UEs, PUCCH FH disablement can be supported for Redcap UEs when the initial UL BWP bandwidth is greater than the redcap UE bandwidth. When PUCCH FH is disabled, the PUCCH transmission frequency resources can be determined by determining the first (or second) (PRB index) frequency hopping for PUCCH transmission for standard UEs in the same way as for PUSCH. In other words, when random access is performed by configuring a separate initial UL BWP for RedCap, it means that N of the bandwidth of the initial UL BWP used to determine the PUCCH transmission frequency resources BWP size It can be the initial UL BWP of the standard UE or replaced with the bandwidth of the initial UL BWP that is separately configured for the redcap UE.

[0383] Furthermore, as in the Msg3 PUSCH described above, in the case of a redcap UE, a cell-specific frequency offset can be applied and transmitted in the PUCCH transmission frequency resources used for a standard UE. By doing so, it can be configured / defined to transmit the PUCCH in a different frequency domain than the standard UE. Here, the PUCCH transmission frequency resources can be determined by reusing a portion of the settings in Table 9.2.1-1 of Table 13 and adding an additional cell-specific frequency offset. For this purpose, the cell-specific frequency offset can be included in the system information (e.g., the initial UL BWP configuration BWP-UplinkCommon(-R) for SIB1) and transmitted.

[0384] In this disclosure, for ease of description, PUCCH FH has been described based on intra-slot FH, but PUCCH FH can also be applied even when inter-slot FH is supported.

[0385] In this disclosure, PUCCH transmission prior to receiving dedicated PUCCH resource configuration may include Msg4 ACK / NACK PUCCH transmission in the case of 4-step RACH and MsgB ACK / NACK-PUCCH transmission in the case of supporting 2-step RACH.

[0386] To support multiple UE types with different UE bandwidths (e.g., RedCap and non-RedCap), the base station can configure a common initial (DL / UL) BWP that can be used by multiple UE types, or it can configure a separate initial (DL / UL) BWP for each UE type. Here, when configuring separately for each UE type, values ​​such as location on different bandwidths and frequencies can be configured for each initial (DL / UL) BWP.

[0387] For example, in a cell that simultaneously supports both non-RedCap UEs and RedCap UEs, an initial UL BWP (hereinafter referred to as iBWP-UL) for non-RedCap UEs and an initial UL BWP (hereinafter referred to as iBWP-UL-R) for RedCap UEs can be configured separately. Here, due to the reduced UE bandwidth of RedCap UEs, the bandwidth of iBWP-UL-R can be smaller than the bandwidth of iBWP-UL. Furthermore, the base station can configure iBWP-UL-R to include all or part of the frequency of iBWP-UL.

[0388] When iBWP-UL-R is configured to include all or part of iBWP-UL in a cell where RedCap and non-RedCap coexist, UL (especially PUSCH) resource splitting may occur in iBWP-UL because iBWP-UL-R occupies a portion of iBWP-UL resources. Due to this PUSCH resource splitting issue, efficient use of PUSCH transmission resources or scheduling for transmissions may be difficult. To minimize this problem, the base station can configure iBWP-UL-R to be located at the frequency band edge of iBWP-UL (e.g., lower or upper band edge).

[0389] Figure 17 This is a diagram illustrating the configuration of the initial UL BWP of a standard UE and the initial BWP of a redcap UE according to embodiments of the present disclosure.

[0390] Figure 17 An example is shown where iBWP-UL-R is positioned at the upper band edge of iBWP-UL to mitigate the problem of PUSCH resource fragmentation in iBWP-UL.

[0391] like Figure 17As shown in the example, iBWP-UL-R can be configured to reside at the frequency band edge (lower band edge or upper band edge) of iBWP-UL. Furthermore, to further improve the PUSCH resource fragmentation problem, a method for enabling / disabling in-slot FH via base station configuration during common PUCCH transmission in iBWP-UL-R is planned. Based on this, this disclosure proposes the following common PUCCH transmission method and common PUCCH resource determination method in iBWP-UL-R. In this disclosure, common PUCCH transmission can mean PUCCH transmission before the UE receives dedicated PUCCH resource configuration.

[0392] Figure 17 This example illustrates a scenario where frequency hopping is enabled and the PUCCH resources for a redcap UE are hopped within the initial ULBWP for the redcap UE. Additionally, as shown in Table 13 above, a non-redcap UE (i.e., a standard UE) can transmit PUCCH using the PUCCH resources determined by the frequency hopping allocation within the initial ULBWP for the non-redcap UE.

[0393] Example 3-1: PUCCH transmission using frequency hopping (FH) (and redcap-specific (additional) RB offset)

[0394] When transmitting a public PUCCH in iBWP-UL-R, a RedCapUE that is instructed to enable FH (or not instructed to disable FH) can use existing methods to determine the PUCCH transmission resources (including the Physical Resource Block (PRB) index and the initial CS value) (refer to Table 13, described in section 9.2.1 of the TS 38.213 specification) and perform the PUCCH transmission.

[0395] More specifically, when the PUCCH transmission resources of RedCapUE are determined using the method described in section 9.1.1 of TS 38.213 (see Table 13), N BWP size This means the size of iBWP-UL-R (in PRB). Here, N BWP size It can be configured separately by the base station for RedCap, or when sharing the initial UL BWP with a non-RedCap UE, N BWP size This can mean the size of the iBWP-UL (in PRB).

[0396] Additionally, to avoid interference between iBWP-UL's PUCCH transmission resources and the common PUCCH resource set, all 16 regular common PUCCH resource sets are supported (e.g., reusing TS 38.213 Table 9.2.1-1, see Table 13), but a separate (additional) RB offset can be configured for RedCap. Alternatively, a different PUCCH resource set index can be set separately from non-RedCap to avoid overlap with the common PUCCH resource set used for non-RedCap. This can be to prevent interference that may occur due to overlap of some PUCCH resources between RedCap and non-RedCap, or performance degradation due to violation of the orthogonality between RedCap and non-RedCap PUCCH transmission resources, and this method can be applied to the proposed methods in all embodiments of this disclosure.

[0397] In this disclosure, for convenience, the PUCCH resource RB offset value ultimately used by the RedCap UE to determine the PUCCH transmission resource is referred to as RB. BWP,R offset (That is, RB is used to replace the calculation formula described in TS 38.213 specification 9.2.1 in Table 13) BWP offset Here, when a separate RB offset indication is received from the base station, the RedCap UE can determine the separately indicated RB offset as the RB. BWP,R offset The value, rather than the RB indicated by the PUCCH resource set index. BWP offset Alternatively, if the configuration value is a separate additional RB offset for RedCap, it can be achieved by adding RB. BWP offset And the indicated additional RB offset to determine RB BWP,R offset Value. Therefore, such a separate (additional) RB offset can be defined and determined. BWP,R offset The method applies to all methods proposed in this disclosure.

[0398] Figure 18 An example of PUCCH transmission using a frequency-hopping redcap UE according to an embodiment of this disclosure is illustrated.

[0399] Figure 18The time / frequency resources for the PUCCH resource set (1801) for non-RedCap UEs and the PUCCH resource set (1802) for RedCap UEs are illustrated. Additionally, to indicate whether frequency hopping is performed, the symbol (in the time domain) / RB (in the frequency domain) area occupied by a PUCCH resource within a PUCCH transmission slot is illustrated using the same pattern. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS 38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0400] Referring to Table 18, PUCCH resources for non-redcap UEs are determined by using intra-slot frequency hopping within the initial UL BWP (iBWP-UL) for non-redcap UEs. Alternatively, PUCCH resources for redcap UEs are determined within the initial UL BWP (iBWP-UL-R) for redcap UEs using intra-slot frequency hopping (by applying the same PUCCH resource determination method for non-redcap UEs), and a frequency offset may be applied to prevent overlap with PUCCH resources for non-redcap UEs.

[0401] exist Figure 18 In this context, it can be interpreted as configuring the PUCCH resource set index = 12 for both non-RedCap and RedCap resources and configuring (additional) RB offsets (RB) only for RedCap resources. BWP,R offset =2) example. Alternatively, Figure 18 This can be interpreted as an example of configuring PUCCH resource set index=12 for a non-RedCap UE and configuring PUCCH resource set index=13 for a RedCap UE.

[0402] In addition, although Figure 18 The example illustrates the case where iBWP-UL-R is located at the lower frequency band edge of iBWP-UL, but the case where iBWP-UL-R is located at the upper frequency band edge of iBWP-UL can also be explained in the same way.

[0403] Example 3-2: PUCCH transmission without frequency hopping (FH) (and redcap-specific (additional) RB offset)

[0404] When transmitting a public PUCCH in iBWP-UL-R, a RedCap UE that is instructed to disable FH (or is not instructed to enable FH) (see Table 13 described in section 9.2.1 of TS 38.213 specification) may perform a PUCCH transmission without FH at the RB position of the first frequency hopping for PUCCH transmission of a non-RedCap UE (i.e., the second frequency hopping is also at the same RB position after the first frequency hopping).

[0405] Figure 19 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0406] Figure 19 The time / frequency resources for the PUCCH resource set (1901) for non-RedCap UEs and the PUCCH resource set (1902) for RedCap UEs are illustrated. Additionally, to indicate whether frequency hopping is performed, the symbol (in the time domain) / RB (in the frequency domain) area occupied by a PUCCH resource within a PUCCH transmission slot is illustrated using the same pattern. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS 38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0407] Referring to Table 19, PUCCH resources for non-redcap UEs are determined by using in-slot frequency hopping within the initial UL BWP (iBWP-UL) for non-redcap UEs.

[0408] On the other hand, the PUCCH resources for a redcap UE can be determined even without frequency hopping within the initial UL BWP (iBWP-UL-R) for the redcap UE. That is, aside from FH disabling, it corresponds to... Figure 18 The configuration is the same. In other words, compared to implementation 3-1, PUCCH can be transmitted in each PUCCH resource without having an FH at the first frequency hopping position. Here, a frequency offset can be applied additionally to avoid overlapping with the PUCCH resources of non-redcap UEs.

[0409] exist Figure 19 In this context, it can be interpreted as configuring the PUCCH resource set index = 12 for both non-RedCap and RedCap resources and configuring (additional) RB offsets (RB) only for RedCap resources. BWP,R offset=2) example. Alternatively, Figure 19 This can be interpreted as an example of configuring PUCCH resource set index=12 for a non-RedCap UE and configuring PUCCH resource set index=13 for a RedCap UE.

[0410] In addition, although Figure 19 The example illustrates the case where iBWP-UL-R is located at the lower frequency band edge of iBWP-UL, but the case where iBWP-UL-R is located at the upper frequency band edge of iBWP-UL can also be explained in the same way.

[0411] In the implementation method 3-2, the base station can use r as a PUCCH resource index. PUCCH Specific values ​​from 0 to 15 are used to configure the lower band edge, upper band edge, or both band edges of the iBWP-UL-R to be used for PUCCH transmission. For example, as Figure 19 As shown, when iBWP-UL-R is configured at the lower frequency band edge of iBWP-UL, r can be used. PUCCH Values ​​from 0 to 7 control PUCCH transmission to occur only at the lower band edge. Alternatively, when iBWP-UL-R is configured at the upper band edge of iBWP-UL, r can be used. PUCCH Values ​​from 8 to 15 are used to control PUCCH transmission only on the upper band edge. When the base station supports both RedCap and non-RedCap, the method proposed in Implementation 3-2 can be used to minimize the aforementioned PUCCH resource fragmentation problem. Implementation 3-2 has the advantage of minimizing the impact on standard documents by maximizing the reuse of existing methods; however, when only one band edge is intended for PUCCH transmission by the base station configuration, the following disadvantage may exist: available PUCCH resources become insufficient because the base station can only use a limited number of PUCCH resources.

[0412] Implementation 3-3: PUCCH transmission within a single band edge without frequency hopping (FH) (and redcap-specific (additional) RB offset)

[0413] To support maximum PUCCH resources while minimizing the aforementioned PUSCH resource fragmentation problem (e.g., using all 16 PUCCH resource indices identical to the current non-RedCap), the base station can configure the PUCCH resource set only for contiguous frequency resources at the lower or upper band edge (or lower or upper side, even if not an edge) of iBWP-UL-R. Implementation 3-3 can only be applied when RedCap and non-RedCap coexist and iBWP-UL-R is partially or entirely included in iBWP-UL. And / or only when PUCCH FH for RedCap is disabled.

[0414] Method 1: As a method to support Implementation 3-3, when transmitting a public PUCCH in iBWP-UL-R, a RedCap UE that is instructed to disable FH (or not instructed to enable FH) (see Table 13 above, described in section 9.2.1 of the TS 38.213 specification) can perform a PUCCH transmission without FH at the RB position of the first frequency hopping for PUCCH transmission of a non-RedCap UE (i.e., the second frequency hopping follows the first frequency hopping at the same position). In Method 1 of Implementation 3-3, in order to continuously generate PUCCH transmission PRBs at a band edge (or one side of a band), unlike Implementation 3-1 or Implementation 3-2, N can be replaced with a new value instead of the size of iBWP-UL-R or iBWP-UL (in PRBs). BWP size When applying the method for determining the RB location for the first frequency hopping used for PUCCH transmission as described in TS 38.213 specification 9.2.1 in Table 13, in order to continuously generate PUCCH transmission PRBs at a frequency band edge (or one side of a frequency band), in method 1 of implementation 3-3, the base station can indicate the location of N instead of N via system information (e.g., SIB1). BWP size The value of N can be determined, or alternatively, by, for example, the following equation. BWP size The value of .

[0415] [Equation 3]

[0416] In this disclosure, for ease of description, N will be used as a substitute for the term N for the purposes described above. BWP size The value is defined as N, which is the size of the virtual (initial) (UL) BWP. BWP,V size In this case, for example, when calculating the PUCCH transmit RB index, N can be defined as follows: BWP,V size Using N BWP,V size Replace N BWP size .

[0417] [Equation 4]

[0418] In equations 3 and 4 This means the number of consecutive PRBs occupied by the PUCCH resource set configured in a conventional manner for each frequency band edge. This represents the ceiling function (i.e., ceil(x) is the smallest integer not less than x).

[0419] More specifically, the initial CS index and initial CS value used to determine the PUCCH transmission RB index can be determined as follows.

[0420] - If floor(r) PUCCH If / 8) = 0 and the UE is provided with PUCCH resources through a common configuration of PUCCH resources (e.g., pucch-ResourceCommon), and no configuration for interleaving PUCCH and PUSCH in a common configuration for UL BWP (e.g., BWP-UplinkCommon) is provided (e.g., useInterlacePUCCH-PUSCH), then the UE can determine the PRB index of the PUCCH transmission, such as RB. BWP,R offset + floor(r PUCCH / N CS Here, N CS This is the total number of initial CS indices in the initial CS index set. Furthermore, the UE can determine the initial CS indices in the initial CS index set, such as r. PUCCH modN CS .

[0421] - On the other hand, if floor(r PUCCH If / 8) = 1 and the UE is provided with PUCCH resources through a common configuration of PUCCH resources (e.g., pucch-ResourceCommon), and no configuration for interleaving PUCCH and PUSCH in a common configuration for UL BWP (e.g., BWP-UplinkCommon) is provided (e.g., useInterlacePUCCH-PUSCH), then the UE can determine the PRB index of the PUCCH transmission as N. BWP,V size -1-RB BWP,R offset -floor((r PUCCH -8) / N CS Here, the initial CS index in the initial CS index set can be determined as (r) PUCCH -8)modN CS .

[0422] In the above description, the higher-level parameters used to determine the PUCCH transmission RB index and the initial CS index can follow the definitions of TS 38.213 and TS 38.331.

[0423] Figure 20 and Figure 21 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0424] Figure 20 and Figure 21 Examples of time / frequency resources for PUCCH resource sets (2001, 2101) for non-RedCap UEs and PUCCH resource sets (2002, 2102) for RedCap UEs are provided. Additionally, to indicate whether frequency hopping is performed, the same pattern is used to illustrate the (time domain) symbol / (frequency domain) RB area occupied by a PUCCH resource within a PUCCH transmission slot. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0425] Figure 20 This illustrates a scenario where the initial UL BWP (iBWP-UL-R) for a redcap UE is configured at the lower band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE, and... Figure 21 This example illustrates a case where the initial ULBWP (iBWP-UL-R) for a redcap UE is configured at the upper band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE. As in method 1 of embodiments 3-3, this can be done at a band edge (or one side of a band)... Figure 20 The lower frequency band edge, Figure 21 The PUCCH resource set for the redcap UE is continuously determined on the upper frequency band edge.

[0426] More specifically, PUCCH resources for non-redcap UEs are determined by using in-slot frequency hopping within the initial ULBWP (iBWP-UL) for non-redcap UEs.

[0427] On the other hand, according to method 1 of implementation 3-3, the PUCCH resources for the redcap UE can be determined even without frequency hopping within the initial UL BWP (iBWP-UL-R) for the redcap UE. More specifically, RB can be used. BWP,R offset Determine N BWP,V size Furthermore, when floor(r) PUCCH When / 8) = 0, RB can be used.BWP,R offset To determine the RB position of the first frequency hopping for PUCCH transmission for non-RedCap UEs. Additionally, when floor(r PUCCH When / 8) = 1, RB can be used. BWP,R offset and N BWP,V size To determine the RB position of the first frequency hopping for PUCCH transmission for non-RedCap UEs. And, PUCCH transmission can be performed without an FH at the corresponding RB position (i.e., the second frequency hopping follows the first frequency hopping at the same RB position).

[0428] Here, in order to support such Figure 21 The operation of the upper band edge example shown, RB BWP,R offset The value may need to be able to support values ​​from 0 to N. BWP size The range of values ​​for -4.

[0429] Method 2: As another method to support implementation 3-3, a redcap instructed to disable FH (or not instructed to enable FH) during public PUCCH transmission in iBWP-UL-R can perform PUCCH transmission at the determined PUCCH transmission RB position, as the RB index increases in ascending order of the PUCCH resource index, wherein the RB index increases in ascending order of the PUCCH resource index. BWP,R offset Begin (described in section 9.2.1 of the TS 38.213 specification).

[0430] More specifically, the initial CS index and initial CS value used to determine the PUCCH transmission RB index can be determined as follows.

[0431] If the UE is provided with PUCCH resources through a common configuration of PUCCH resources (e.g., pucch-ResourceCommon) and is not provided with a configuration for interleaving PUCCH and PUSCH in a common configuration for UL BWP (e.g., BWP-UplinkCommon) (e.g., useInterlacePUCCH-PUSCH), then the UE can determine the PRB index of the PUCCH transmission, such as RB. BWP,R offset + floor(r PUCCH / N CS Here, N CS This is the total number of initial CS indices in the initial CS index set. Furthermore, the UE can determine the initial CS indices in the initial CS index set, such as r. PUCCH modNCS .

[0432] In the above description, the higher-level parameters used to determine the PUCCH transmission RB index and the initial CS index can follow the definitions of TS 38.213 and TS 38.331.

[0433] Since method 2 in implementation 3-3 does not require N BWP,V size (Different from method 1), so it does not need to be used for N BWP,V size The calculation or individual signaling.

[0434] Figure 22 and Figure 23 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0435] Figure 22 and Figure 23 Examples of time / frequency resources for PUCCH resource sets (2201, 2301) for non-RedCap UEs and PUCCH resource sets (2202, 2302) for RedCap UEs are provided. Additionally, to indicate whether frequency hopping is performed, the same pattern is used to illustrate the (time domain) symbol / (frequency domain) RB area occupied by a PUCCH resource within a PUCCH transmission slot. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0436] Figure 22 This illustrates a scenario where the initial UL BWP (iBWP-UL-R) for a redcap UE is configured at the lower band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE, and... Figure 23 This example illustrates a case where the initial ULBWP (iBWP-UL-R) for a redcap UE is configured at the upper band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE. As in method 2 of embodiments 3-3, this can be done at a band edge (or one side of a band)... Figure 22 The lower frequency band edge, Figure 23 The PUCCH resource set for the redcap UE is continuously determined on the upper frequency band edge.

[0437] More specifically, PUCCH resources for non-redcap UEs are determined by using in-slot frequency hopping within the initial ULBWP (iBWP-UL) for non-redcap UEs.

[0438] On the other hand, according to method 1 of implementation 3-3, the PUCCH resources for the redcap UE can be determined without frequency hopping within the initial UL BWP (iBWP-UL-R) for the redcap UE. More specifically, the location of the PUCCH transmission RB can be determined by the RB index from RB. BWP,R offset The PUCCH resource indexes increase sequentially in ascending order. Furthermore, PUCCH transmission can be performed even without a corresponding FH at the RB position (i.e., the second frequency hopping follows the first frequency hopping at the same RB position).

[0439] Here, in order to support such Figure 23 The operation of the upper band edge example shown, RB BWP,R offset The value may need to be able to support values ​​from 0 to N. BWP size The range of values ​​for -4.

[0440] Implementation methods 3-4: PUCCH transmission within a single frequency band edge without frequency hopping (FH) (including band edge indication).

[0441] To support operation of upper band edge examples, instead of supporting RB values ​​with a large value range as in implementation 3-3, BWP,R offset (For example, 0 to N) BWP size -4), RB BWP,R offset The range is defined / configured within half of iBWP-UL-R and can be indicated by 1 bit of additional information, indicating the upper or lower frequency band.

[0442] Here, adding 1 bit of information can directly notify the RB. BWP,R offset This refers to the RB offset from the upper band edge (i.e., the highest RB index of iBWP-UL-R) or the lower band edge (i.e., the lowest RB index of iBWP-UL-R or RB index = 0). Alternatively, the additional 1 bit of information can help the UE interpret the RB offset by informing whether iBWP-UL-R is set at the upper or lower band edge of iBWP-UL. BWP,R offsetInformation. In this disclosure, for convenience, an additional 1 bit of information is referred to as the Band Edge Indicator (BEI). For example, BEI=0 means lower band edge, BEI=1 means upper band edge (and vice versa), or lower band edge and upper band edge can be distinguished by true / false. In addition, the BEI can be sent to the UE through system information (e.g., SIB1).

[0443] If RB BWP,R offset By shifting the RB from the lower frequency band edge through BEI, it is possible to achieve the same result as Example 1 of Method 2 in Embodiments 3-3 described above (see Example 1). Figure 22 Example 1 of method 1 of implementation method 3-3 (see Figure 20 The PUCCH transmission resources are determined in the same way. For this purpose, please refer to Implementation Method 3-3 above, and its detailed description will be omitted.

[0444] Method 1: When RB BWP,R offset When the RB is shifted from the upper frequency band edge by BEI, the RB BWP,R offset This can indicate the offset from the lowest RB index of the PUCCH transmission resource. In this case, the PUCCH transmission RB index can be determined as follows: the PUCCH transmission RB index follows the PUCCH resource index (i.e., r...). PUCCH ) increases and increases (also by considering N) CS ).

[0445] Here, the initial CS index and initial CS value used to determine the PUCCH transmission RB index can be determined as follows (same as in Implementation 2 of Method P2).

[0446] If the UE is provided with PUCCH resources through a common configuration of PUCCH resources (e.g., pucch-ResourceCommon) and is not provided with a configuration for interleaving PUCCH and PUSCH in a common configuration for UL BWP (e.g., BWP-UplinkCommon) (e.g., useInterlacePUCCH-PUSCH), then the UE can determine the PRB index of the PUCCH transmission, such as RB. BWP,R offset + floor(r PUCCH / N CS Here, N CS This is the total number of initial CS indices in the initial CS index set. Furthermore, the UE can determine the initial CS indices in the initial CS index set, such as r. PUCCH modN CS .

[0447] In the above description, the higher-level parameters used to determine the PUCCH transmission RB index and the initial CS index can follow the definitions of TS 38.213 and TS 38.331.

[0448] Figure 24 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0449] Figure 24 The time / frequency resources for the PUCCH resource set (2401) for non-RedCap UEs and the PUCCH resource set (2402) for RedCap UEs are illustrated. Additionally, to indicate whether frequency hopping is performed, the symbol (in the time domain) / RB (in the frequency domain) area occupied by a PUCCH resource within a PUCCH transmission slot is illustrated using the same pattern. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS 38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0450] Figure 24 Example of RB BWP,R offset The BEI indicates either an RB offset from the upper band edge (i.e., the highest RB index of iBWP-UL-R) or an initial UL BWP (iBWP-UL-R) for a redcap UE configured on the upper band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE. As in embodiments 3-4 above, the PUCCH resource set for a redcap UE can be continuously determined on a band edge (or one side of a band).

[0451] More specifically, PUCCH resources for non-redcap UEs are determined by using in-slot frequency hopping within the initial ULBWP (iBWP-UL) for non-redcap UEs.

[0452] On the other hand, according to method 1 of embodiments 3-4, the PUCCH resources for the redcap UE can be determined without frequency hopping within the initial UL BWP (iBWP-UL-R) for the redcap UE. More specifically, the location of the PUCCH transmission RB can be determined by the RB index from the RB. BWP,R offsetThe PUCCH resource indexes increase sequentially in ascending order. Furthermore, PUCCH transmission can be performed even without a corresponding FH at the RB position (i.e., the second frequency hopping follows the first frequency hopping at the same RB position).

[0453] Method 2: When RB BWP,R offset When the RB is shifted from the upper frequency band edge by BEI, the RB BWP,R offset This can indicate the interval of the highest (i.e., closest to the top edge) RB index of the PUCCH resource sent upwards. In this case, the PUCCH sending RB index can be determined as follows: the PUCCH sending RB index increases with the PUCCH resource index (i.e., r...). PUCCH ) increases and decreases (also by considering N) CS ).

[0454] Here, the initial CS index and initial CS value used to determine the PUCCH transmission RB index can be determined as follows.

[0455] If the UE is provided with PUCCH resources through a common configuration of PUCCH resources (e.g., pucch-ResourceCommon) and is not provided with a configuration for interleaving PUCCH and PUSCH in a common configuration for UL BWP (e.g., BWP-UplinkCommon) (e.g., useInterlacePUCCH-PUSCH), then the UE can determine the PRB index of the PUCCH transmission, such as RB. BWP,R offset - floor(r PUCCH / N CS Here, N CS This is the total number of initial CS indices in the initial CS index set. Furthermore, the UE can determine the initial CS indices in the initial CS index set, such as r. PUCCH modN CS .

[0456] In the above description, the higher-level parameters used to determine the PUCCH transmission RB index and the initial CS index can follow the definitions of TS 38.213 and TS 38.331.

[0457] Figure 25 The PUCCH transmission of a redcap UE without frequency hopping is illustrated according to an embodiment of the present disclosure.

[0458] Figure 25The time / frequency resources for the PUCCH resource set (2501) for non-RedCap UEs and the PUCCH resource set (2502) for RedCap UEs are illustrated. Additionally, to indicate whether frequency hopping is performed, the symbol (in the time domain) / RB (in the frequency domain) area occupied by a PUCCH resource within a PUCCH transmission slot is illustrated using the same pattern. Furthermore, the number in each PUCCH transmission RB represents the PUCCH resource index r. PUCCH The PUCCH resources sent in the same PUCCH transmission RB (defined in Table 9.2.1-1 of TS 38.213) (see Table 13 above) can be sent by N. CS Different CS are used to distinguish them.

[0459] Figure 25 Example of RB BWP,R offset The BEI indicates either an RB offset from the upper band edge (i.e., the highest RB index of iBWP-UL-R) or an initial UL BWP (iBWP-UL-R) for a redcap UE configured on the upper band edge of the initial UL BWP (iBWP-UL) for a non-redcap UE. As in embodiments 3-4 above, the PUCCH resource set for a redcap UE can be continuously determined on a band edge (or one side of a band).

[0460] More specifically, PUCCH resources for non-redcap UEs are determined by using in-slot frequency hopping within the initial ULBWP (iBWP-UL) for non-redcap UEs.

[0461] On the other hand, according to method 2 of embodiments 3-4, the PUCCH resources for the redcap UE can be determined without frequency hopping within the initial UL BWP (iBWP-UL-R) for the redcap UE. More specifically, the location of the PUCCH transmission RB can be determined by the RB index from the RB. BWP,R offset The PUCCH resource index decreases sequentially in ascending order. Furthermore, PUCCH transmission can be performed even without a corresponding FH at the RB position (i.e., the second frequency hopping follows the first frequency hopping at the same RB position).

[0462] Furthermore, in both Method 1 and Method 2 of Examples 3-4 described above, RB BWP,R offset It can indicate the index from the upper band edge to the lowest PUCCH resource index (e.g., r PUCCHThe PUCCH sends the offset of the RB index (i.e., it can be defined as such) when PUCCH = 0.

[0463] Additionally, in the methods proposed in this disclosure (e.g., any or a combination of Embodiments 1, 2, 3, and detailed embodiments of Embodiments 1 to 3), parameters transmitted via the common PUCCH for RedCap UEs configured / indicated by the base station can be sent / configured to the UE via higher-layer signaling (e.g., system information such as SIB1), such as configurations related to the (separate) initial UL BWP for RedCap, and separate (additional) RB offsets (i.e., RB...). BWP,R offset ), separate PUCCH resource set index, FH enable / disable, used to replace N BWP size The value, etc.

[0464] Figure 26 This is a diagram illustrating the signaling process between a base station and a terminal in a method for transmitting and receiving PUCCH according to an embodiment of the present disclosure.

[0465] Figure 26 The signaling process between a terminal (user equipment, UE) and a base station (BS) based on the above method is illustrated. Figure 26 The examples provided are for ease of description and do not limit the scope of this disclosure. Depending on the circumstances and / or configuration, details may be omitted. Figure 26 Some steps are illustrated below. Additionally... Figure 26 The base station and terminal in the example are merely one example and can be implemented as described below. Figure 29 The apparatus illustrated in the example. For example, Figure 29 The processor (102 / 202) can control the use of transceivers (106 / 206) to send / receive channels / signals / data / information, etc., and can control the storage of the sent or received channels / signals / data / information, etc. in memory (104 / 204).

[0466] In addition, Figure 26 In the operation between the base station and the terminal, even if not mentioned separately, the above description can be referenced / used.

[0467] A base station can be a general term for an object that transmits data to and receives data from a terminal. For example, a base station can be a concept that includes one or more transmit points (TPs), one or more transmit and receive points (TRPs), etc. Furthermore, TPs and / or TRPs can include base station panels, transmit and receive units, etc. Additionally, "TRP" refers to a panel, antenna array, cell (e.g., macro cell / small cell / pec cell, etc.). It can be replaced and applied using expressions such as TP (transmit point), base station (base station, gNB, etc.). As mentioned above, TRPs can be categorized based on information about CORESET groups (or CORESET pools) (e.g., indexes, IDs). For example, when a terminal is configured to transmit / receive with respect to multiple TRPs (or cells), this can mean that multiple CORESET groups (or CORESET pools) are configured for one terminal. Such CORESET group (or CORESET pool) configuration can be performed via higher-level signaling (e.g., RRC signaling, etc.).

[0468] refer to Figure 26 For ease of description, we consider signaling between a base station and a terminal; however, the corresponding signaling scheme can be extended and applied to signaling between multiple TRPs and multiple terminals. In the following description, a base station can be interpreted as a single TRP. Alternatively, a base station may include multiple TRPs, or it may be a cell comprising multiple TRPs.

[0469] refer to Figure 26 A specific type of terminal (e.g., a redcap terminal) receives system information (e.g., SIB1) from the base station (S2601).

[0470] Before providing the dedicated PUCCH resource configuration to the redcap endpoint, the system information may include configuration information for the public PUCCH transmission of the redcap endpoint.

[0471] For example, system information may include parameters such as the configuration associated with the (separate) initial UL BWP for RedCap, and the separate (additional) RB offset (i.e., RB). BWP,R offset ), a separate PUCCH resource set index, information indicating FH enable / disable, and a replacement for N. BWP size The value, etc.

[0472] Additionally, the system information may include information about the additional PRB offset in the PRB mapping of the PUCCH resource (hereinafter referred to as the first information) and information about whether the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial uplink bandwidth portion (BWP) of the redcap terminal or in descending order from the upper edge of the initial uplink BWP of the redcap terminal (hereinafter referred to as the second information).

[0473] As described above, the PRB offset (RB) used to determine the cell-specific PUCCH resource set can be used. BWP offset The PRB index for PUCCH transmission used by the redcap terminal is determined by the additional PRB offset. That is, RB... BWP offset The value can be obtained by changing RB BWP offset The PRB offset is determined by adding it to the indicated additional RB offset. In this case, the system information may also include information for configuring the cell-specific PUCCH resource set (hereinafter referred to as third information), and the PRB offset (RB) can be determined based on the third information for configuring the cell-specific PUCCH resource set. BWP offset ).

[0474] The terminal receives the DCI for scheduling PDSCH from the base station (S2602), and the terminal receives the PDSCH from the base station based on the DCI (S2603).

[0475] Here, DCI can be transmitted via PDCCH. Additionally, as described above, when the method proposed in this disclosure is applied during the random access procedure of a redcap terminal, PDSCH can carry MSG2, MSG4, or MSGB. Here, MSG2 can represent the PDCCH and PDSCH for the random access response in a four-step random access procedure, MSG4 can represent the PDSCH for contention resolution in a four-step random access procedure, and MSGB can represent the PUSCH scheduled by the UL permission of the random access response and the PDSCH for contention resolution in a two-step random access procedure.

[0476] Here, when the PDSCH carries MSG2, the redcap terminal can receive the PDSCH according to the method proposed in Implementation 1. Then, although not in Figure 26 As shown in the figure, however, the redcap terminal can send MSG3 to the base station based on the method proposed in Implementation 2.

[0477] The terminal sends HARQ-ACK information related to PDSCH to the base station on PUCCH (S2604).

[0478] Here, the redcap terminal can send PUCCH according to the method proposed in Embodiment 3. Specifically, the PRB index for PUCCH transmission can be determined according to Embodiment 3 (one or a combination of several detailed embodiments of Embodiment 3).

[0479] For example, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0480] Here, when the redcap terminal has not received the dedicated PUCCH resource configuration (e.g., before receiving the dedicated PUCCH resource configuration), the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0481] Furthermore, when frequency hopping for PUCCH transmission is disabled, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information. Here, whether frequency hopping for PUCCH transmission is enabled or disabled can be determined based on the base station's configuration.

[0482] Alternatively, the PRB index for PUCCH transmission can be determined using the PRB offset and the additional PRB offset determined by the third information used to configure the cell-specific PUCCH resource set.

[0483] For example, if the second information indicates that the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial BWP of the redcap terminal, then the PRB index can increase as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying positive values ​​to the PRB offset and the additional PRB offset.

[0484] As another example, if the second information indicates that the PRB index in the PRB mapping is counted in descending order from the top edge of the initial BWP of the redcap terminal, then the PRB index can decrease as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying negative values ​​to the PRB offset and the additional PRB offset.

[0485] Figure 27 This is a diagram illustrating the operation of a UE for transmitting and receiving a PUCCH according to an embodiment of the present disclosure.

[0486] exist Figure 27 The example illustrates the operation of a terminal based on the previously proposed method. Figure 27 The examples provided are for ease of description and do not limit the scope of this disclosure. Depending on the circumstances and / or configuration, details may be omitted. Figure 27 Some steps are illustrated below. Additionally... Figure 27 The terminal in the example is just one example and can be implemented as follows. Figure 29 The apparatus illustrated in the example. For example, Figure 29 The processor (102 / 202) can control the use of transceivers (106 / 206) to send / receive channels / signals / data / information, etc., and can control the storage of the sent or received channels / signals / data / information, etc. in memory (104 / 204).

[0487] refer to Figure 27 A specific type of terminal (e.g., a redcap terminal) receives system information (e.g., SIB1) from the base station (S2701).

[0488] Before providing the dedicated PUCCH resource configuration to the redcap endpoint, the system information may include configuration information for the public PUCCH transmission of the redcap endpoint.

[0489] For example, system information may include parameters such as the configuration associated with the (separate) initial UL BWP for RedCap, and the separate (additional) RB offset (i.e., RB). BWP,R offset ), a separate PUCCH resource set index, information indicating FH enable / disable, and a replacement for N. BWP size The value, etc.

[0490] Additionally, the system information may include information about the additional PRB offset in the PRB mapping of the PUCCH resource (hereinafter referred to as the first information) and information about whether the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial uplink bandwidth portion (BWP) of the redcap terminal or in descending order from the upper edge of the initial uplink BWP of the redcap terminal (hereinafter referred to as the second information).

[0491] As described above, the PRB offset (RB) used to determine the cell-specific PUCCH resource set can be used. BWP offset The PRB index for PUCCH transmission used by the redcap terminal is determined by the additional PRB offset. That is, RB... BWP offset The value can be obtained by changing RB BWP offsetThe PRB offset is determined by adding it to the indicated additional RB offset. In this case, the system information may also include information for configuring the cell-specific PUCCH resource set (hereinafter referred to as third information), and the PRB offset (RB) can be determined based on the third information for configuring the cell-specific PUCCH resource set. BWP offset ).

[0492] A specific type of terminal (e.g., a redcap terminal) receives a DCI for scheduling PDSCH from the base station (S2702), and a specific type of terminal (e.g., a redcap terminal) receives PDSCH from the base station based on the DCI (S2703).

[0493] Here, DCI can be transmitted via PDCCH. Additionally, as described above, when the method proposed in this disclosure is applied during the random access procedure of a redcap terminal, PDSCH can carry MSG2, MSG4, or MSGB. Here, MSG2 can represent the PDCCH and PDSCH for the random access response in a four-step random access procedure, MSG4 can represent the PDSCH for contention resolution in a four-step random access procedure, and MSGB can represent the PUSCH scheduled by the UL permission of the random access response and the PDSCH for contention resolution in a two-step random access procedure.

[0494] Here, when the PDSCH carries MSG2, the redcap terminal can receive the PDSCH according to the method proposed in Implementation 1. Then, although not in Figure 27 As shown in the figure, however, the redcap terminal can send MSG3 to the base station based on the method proposed in Implementation 2.

[0495] Specific types of terminals (e.g., redcap terminals) send HARQ-ACK information related to PDSCH to the base station on the PUCCH (S2704).

[0496] Here, the redcap terminal can send PUCCH according to the method proposed in Embodiment 3. Specifically, the PRB index for PUCCH transmission can be determined according to Embodiment 3 (one or a combination of several detailed embodiments of Embodiment 3).

[0497] For example, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0498] Here, when the redcap terminal has not received the dedicated PUCCH resource configuration (e.g., before receiving the dedicated PUCCH resource configuration), the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0499] Furthermore, when frequency hopping for PUCCH transmission is disabled, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information. Here, whether frequency hopping for PUCCH transmission is enabled or disabled can be determined based on the base station's configuration.

[0500] Alternatively, the PRB index for PUCCH transmission can be determined using the PRB offset and the additional PRB offset determined by the third information used to configure the cell-specific PUCCH resource set.

[0501] For example, if the second information indicates that the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial BWP of the redcap terminal, then the PRB index can increase as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying positive values ​​to the PRB offset and the additional PRB offset.

[0502] As another example, if the second information indicates that the PRB index in the PRB mapping is counted in descending order from the top edge of the initial BWP of the redcap terminal, then the PRB index can decrease as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying negative values ​​to the PRB offset and the additional PRB offset.

[0503] Figure 28 This is a diagram illustrating the operation of a base station for transmitting and receiving PUCCH according to an embodiment of the present disclosure.

[0504] exist Figure 28 The operation of a base station based on the previously proposed method is illustrated in the example. Figure 28 The examples provided are for ease of description and do not limit the scope of this disclosure. Depending on the circumstances and / or configuration, details may be omitted. Figure 28 Some steps are illustrated below. Additionally... Figure 28 The base station in the example is just one example and can be implemented as follows. Figure 29 The apparatus illustrated in the example. For example, Figure 29The processor (102 / 202) can control the use of transceivers (106 / 206) to send / receive channels / signals / data / information, etc., and can control the storage of the sent or received channels / signals / data / information, etc. in memory (104 / 204).

[0505] refer to Figure 28 The base station sends system information (e.g., SIB1) to a specific type of terminal (e.g., a redcap terminal) (S2801).

[0506] Before providing the dedicated PUCCH resource configuration to the redcap endpoint, the system information may include configuration information for the public PUCCH transmission of the redcap endpoint.

[0507] For example, system information may include parameters such as the configuration associated with the (separate) initial UL BWP for RedCap, and the separate (additional) RB offset (i.e., RB). BWP,R offset ), a separate PUCCH resource set index, information indicating FH enable / disable, and a replacement for N. BWP size The value, etc.

[0508] Additionally, the system information may include information about the additional PRB offset in the PRB mapping of the PUCCH resource (hereinafter referred to as the first information) and information about whether the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial uplink bandwidth portion (BWP) of the redcap terminal or in descending order from the upper edge of the initial uplink BWP of the redcap terminal (hereinafter referred to as the second information).

[0509] As described above, the PRB offset (RB) used to determine the cell-specific PUCCH resource set can be used. BWP offset The PRB index for PUCCH transmission used by the redcap terminal is determined by the additional PRB offset. That is, RB... BWP offset The value can be obtained by changing RB BWP offset The PRB offset is determined by adding it to the indicated additional RB offset. In this case, the system information may also include information for configuring the cell-specific PUCCH resource set (hereinafter referred to as third information), and the PRB offset (RB) can be determined based on the third information for configuring the cell-specific PUCCH resource set. BWP offset ).

[0510] The base station sends a DCI for scheduling PDSCH to a specific type of terminal (e.g., a redcap terminal) (S2802), and the base station sends PDSCH to a specific type of terminal (e.g., a redcap terminal) based on the DCI (S2803).

[0511] Here, DCI can be transmitted via PDCCH. Additionally, as described above, when the method proposed in this disclosure is applied during the random access procedure of a redcap terminal, PDSCH can carry MSG2, MSG4, or MSGB. Here, MSG2 can represent the PDCCH and PDSCH for the random access response in a four-step random access procedure, MSG4 can represent the PDSCH for contention resolution in a four-step random access procedure, and MSGB can represent the PUSCH scheduled by the UL permission of the random access response and the PDSCH for contention resolution in a two-step random access procedure.

[0512] Here, when the PDSCH carries MSG2, the base station can send the PDSCH to the redcap terminal according to the method proposed in Implementation 1. Then, although not in Figure 28 As shown in the figure, however, the base station can receive MSG3 from the redcap terminal based on the method proposed in Implementation 2.

[0513] The base station receives HARQ-ACK information related to PDSCH from a specific type of terminal (e.g., a redcap terminal) in the PUCCH (S2804).

[0514] Here, the redcap terminal can send PUCCH according to the method proposed in Embodiment 3. Specifically, the PRB index for PUCCH transmission can be determined according to Embodiment 3 (one or a combination of several detailed embodiments of Embodiment 3).

[0515] For example, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0516] Here, when the redcap terminal has not received the dedicated PUCCH resource configuration (e.g., before receiving the dedicated PUCCH resource configuration), the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information.

[0517] Furthermore, when frequency hopping for PUCCH transmission is disabled, the PRB index for PUCCH transmission can be determined based on the second information using the additional PRB offset provided by the first information. Here, whether frequency hopping for PUCCH transmission is enabled or disabled can be determined based on the base station's configuration.

[0518] Alternatively, the PRB index for PUCCH transmission can be determined using the PRB offset and the additional PRB offset determined by the third information used to configure the cell-specific PUCCH resource set.

[0519] For example, if the second information indicates that the PRB index in the PRB mapping is counted in ascending order from the lower edge of the initial BWP of the redcap terminal, then the PRB index can increase as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying positive values ​​to the PRB offset and the additional PRB offset.

[0520] As another example, if the second information indicates that the PRB index in the PRB mapping is counted in descending order from the top edge of the initial BWP of the redcap terminal, then the PRB index can decrease as the PUCCH resource index increases, taking into account the number of cyclic shifts (CS). In this case, the PRB index used for PUCCH transmission can be determined by applying negative values ​​to the PRB offset and the additional PRB offset.

[0521] The general apparatus disclosed herein can be used

[0522] Figure 29 This is a block diagram illustrating a wireless communication device according to an embodiment of the present disclosure.

[0523] refer to Figure 29 The first wireless device 100 and the second wireless device 200 can transmit and receive wireless signals through various radio access technologies (e.g., LTE, NR).

[0524] The first wireless device 100 may include one or more processors 102 and one or more memories 104, and may additionally include one or more transceivers 106 and / or one or more antennas 108. The processors 102 may control the memories 104 and / or the transceivers 106, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. For example, the processor 102 may transmit a wireless signal including the first information / signal via the transceivers 106 after generating a first information / signal by processing information in the memories 104. Additionally, the processor 102 may receive a wireless signal including a second information / signal via the transceivers 106, and then store information obtained through signal processing of the second information / signal in the memories 104. The memories 104 may be connected to the processor 102 and may store various information related to the operation of the processor 102. For example, the memories 104 may store software code including commands for performing all or part of the processing controlled by the processor 102 or for executing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement wireless communication technologies (e.g., LTE, NR). Transceiver 106 may be connected to processor 102 and may transmit and / or receive wireless signals via one or more antennas 108. Transceiver 106 may include a transmitter and / or a receiver. Transceiver 106 may be used with an RF (radio frequency) unit. In this disclosure, wireless device may refer to a communication modem / circuit / chip.

[0525] The second wireless device 200 may include one or more processors 202 and one or more memories 204, and may additionally include one or more transceivers 206 and / or one or more antennas 208. The processors 202 may control the memories 204 and / or the transceivers 206, and may be configured to implement the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. For example, the processors 202 may generate third information / signals by processing information in the memories 204, and then transmit a wireless signal including the third information / signals via the transceivers 206. Additionally, the processors 202 may receive wireless signals including fourth information / signals via the transceivers 206, and then store information obtained through signal processing of the fourth information / signals in the memories 204. The memories 204 may be connected to the processors 202 and may store various information related to the operation of the processors 202. For example, the memories 204 may store software code including commands for performing all or part of the processing controlled by the processors 202 or for executing the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein. Here, processor 202 and memory 204 may be part of a communication modem / circuit / chip designed to implement wireless communication technologies (e.g., LTE, NR). Transceiver 206 may be connected to processor 202 and may transmit and / or receive wireless signals via one or more antennas 208. Transceiver 206 may include a transmitter and / or a receiver. Transceiver 206 may be used with an RF unit. In this disclosure, wireless device may refer to a communication modem / circuit / chip.

[0526] The hardware components of the wireless devices 100 and 200 will be described in more detail below. However, one or more protocol layers may be implemented by one or more processors 102 and 202. For example, one or more processors 102 and 202 may implement one or more layers (e.g., functional layers such as PHY, MAC, RLC, PDCP, RRC, SDAP). One or more processors 102 and 202 may generate one or more PDUs (Protocol Data Units) and / or one or more SDUs (Service Data Units) according to the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts included in this disclosure. One or more processors 102 and 202 may generate messages, control information, data, or information according to the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure. One or more processors 102, 202 may generate signals (e.g., baseband signals) including PDUs, SDUs, messages, control information, data, or information, in accordance with the functions, processes, suggestions, and / or methods disclosed in this disclosure, to provide them to one or more transceivers 106, 206. One or more processors 102, 202 may receive signals (e.g., baseband signals) from one or more transceivers 106, 206, and obtain PDUs, SDUs, messages, control information, data, or information, in accordance with the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure.

[0527] One or more processors 102, 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102, 202 may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more ASICs (Application-Specific Integrated Circuits), one or more DSPs (Digital Signal Processors), one or more DSPDs (Digital Signal Processing Devices), one or more PLDs (Programmable Logic Devices), or one or more FPGAs (Field-Programmable Gate Arrays) may be included in one or more processors 102, 202. The descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure may be implemented using firmware or software, and the firmware or software may be implemented to include modules, processes, functions, etc. Firmware or software configured to perform the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed in this disclosure may be included in one or more processors 102, 202, or may be stored in one or more memories 104, 204 and driven by one or more processors 102, 202. The descriptions, functions, processes, suggestions, methods and / or operation flowcharts disclosed in this disclosure can be implemented using firmware or software in the form of code, commands and / or command sets.

[0528] One or more memories 104, 204 may be connected to one or more processors 102, 202 and may store data, signals, messages, information, programs, code, instructions, and / or commands in various forms. One or more memories 104, 204 may be configured with ROM, RAM, EPROM, flash memory, hard disk drive, registers, cache memory, computer-readable storage media, and / or combinations thereof. One or more memories 104, 204 may be located internally and / or externally to one or more processors 102, 202. Furthermore, one or more memories 104, 204 may be connected to one or more processors 102, 202 via various technologies such as wired or wireless connections.

[0529] One or more transceivers 106, 206 can transmit user data, control information, wireless signals / channels, etc., mentioned in the methods and / or operation flowcharts, etc., of this disclosure to one or more other devices. One or more transceivers 106, 206 can receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts, etc., disclosed in this disclosure from one or more other devices. For example, one or more transceivers 106, 206 can be connected to one or more processors 102, 202 and can transmit and receive wireless signals. For example, one or more processors 102, 202 can control one or more transceivers 106, 206 to transmit user data, control information, or wireless signals to one or more other devices. Additionally, one or more processors 102, 202 can control one or more transceivers 106, 206 to receive user data, control information, or wireless signals from one or more other devices. Additionally, one or more transceivers 106, 206 may be connected to one or more antennas 108, 208, and one or more transceivers 106, 206 may be configured to transmit and receive user data, control information, wireless signals / channels, etc., mentioned in the descriptions, functions, processes, suggestions, methods, and / or operation flowcharts disclosed herein via one or more antennas 108, 208. In this disclosure, one or more antennas may be multiple physical antennas or multiple logical antennas (e.g., antenna ports). One or more transceivers 106, 206 may convert received wireless signals / channels, etc., from RF band signals to baseband signals for processing using one or more processors 102, 202. One or more transceivers 106, 206 may convert user data, control information, wireless signals / channels, etc., processed using one or more processors 102, 202, from baseband signals to RF band signals. Therefore, one or more transceivers 106, 206 may include (analog) oscillators and / or filters.

[0530] The above embodiments combine the elements and features of this disclosure in a predetermined form. Unless otherwise expressly stated, each element or feature should be considered optional. Each element or feature may be implemented without being combined with other elements or features. Furthermore, embodiments of this disclosure may include combinations of some elements and / or features. The order of operations described in embodiments of this disclosure may be changed. Some elements or features of one embodiment may be included in other embodiments, or may be replaced by corresponding elements or features of other embodiments. Obviously, embodiments may include claims that are not explicitly referenced in the claims, or may be included as new claims after the application has been amended.

[0531] It will be apparent to those skilled in the art that this disclosure may be implemented in other specific forms without departing from its essential characteristics. Therefore, the foregoing detailed description should not be construed as restrictive in every respect, but rather as illustrative. The scope of this disclosure should be determined by a reasonable interpretation of the appended claims, and all variations within the equivalent scope of this disclosure are included within its scope.

[0532] The scope of this disclosure includes software or machine-executable commands (e.g., operating systems, applications, firmware, programs, etc.) that operate in a device or computer according to methods of various embodiments, as well as non-transitory computer-readable media that cause software or commands to be stored and executable in a device or computer. Commands that can be used to program a processing system to perform the features described in this disclosure can be stored in a storage medium or a computer-readable storage medium, and the features described in this disclosure can be implemented by using a computer program product including such a storage medium. The storage medium may include, but is not limited to, high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid-state storage devices, and may include non-volatile memory, such as one or more disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory may optionally include one or more storage devices located remotely from the processor. The memory, or alternatively, the non-volatile memory devices in the memory include non-transitory computer-readable storage media. The features described in this disclosure can be stored in any machine-readable medium to control the hardware of a processing system and can be integrated into software and / or firmware that allows the processing system to interact with other mechanisms using results from embodiments of this disclosure. Such software or firmware may include, but is not limited to, application code, device drivers, operating systems, and execution environments / containers.

[0533] The wireless communication technologies implemented in the wireless devices 100 and 200 of this disclosure may include narrowband Internet of Things (IoT) for low-power communication, as well as LTE, NR, and 6G. For example, NB-IoT technology may be an example of LPWAN (Low Power Wide Area Network) technology, implemented in standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the aforementioned names. Additionally or alternatively, the wireless communication technologies implemented in the wireless devices 100 and 200 of this disclosure may perform communication based on LTE-M technology. For example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (Enhanced Machine-Type Communication). For example, LTE-M technology may be implemented in at least any of various standards, including 1) LTE Cat 0; 2) LTE Cat M1; 3) LTE Cat M2; 4) LTE non-BL (non-bandwidth limited); 5) LTE-MTC; 6) LTE Machine-Type Communication; and / or 7) LTE M, etc., and is not limited to the aforementioned names. Additionally or alternatively, the wireless communication technologies implemented in the wireless devices 100 and 200 of this disclosure may include at least any one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN) considering low-power communication, and are not limited to the aforementioned names. For example, ZigBee technology can generate PANs (Personal Area Networks) associated with small / low-power digital communication based on various standards (e.g., IEEE 802.15.4, etc.) and may be referred to by various names.

[0534] Industrial applicability

[0535] The method presented in this disclosure is primarily illustrated based on examples applied to 3GPP LTE / LTE-A and 5G systems, but it can also be applied to various wireless communication systems other than 3GPP LTE / LTE-A and 5G systems.

Claims

1. A method performed by a user equipment (UE) with RedCap capability, the method comprising the following steps: Receive system information from base station (BS), wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, a PUCCH is sent to the BS based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

2. The method according to claim 1, wherein, The system information includes information related to the specific initial UL BWP of the RedCap.

3. The method according to claim 1, wherein, The steps for sending the PUCCH include the following: The PRB index for the PUCCH is determined based on the first information, the second information, and the third information; and The PUCCH is sent based on the determined PRB index.

4. The method according to claim 1, wherein, Based on the public PUCCH configuration including the third information, frequency hopping for the PUCCH is disabled.

5. The method according to claim 1, wherein, Based on the third information having a first value, the PRB index in the PRB mapping for the PUCCH is counted in ascending order from the lower edge of the RedCap-specific initial UL BWP.

6. The method according to claim 1, wherein, Based on the second value of the third information, the PRB index in the PRB mapping for the PUCCH is counted in descending order from the top edge of the RedCap-specific initial UL BWP.

7. A user equipment (UE) with RedCap capability in a wireless communication system, the UE comprising: At least one processor; as well as At least one computer memory storing instructions that, when executed by the at least one processor, cause RedCap UE to perform operations including: Receive system information from base station (BS), wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, a PUCCH is sent to the BS based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

8. The UE according to claim 7, wherein, The system information includes information related to the specific initial UL BWP of the RedCap.

9. The UE according to claim 7, wherein, Sending the PUCCH includes: The PRB index for the PUCCH is determined based on the first information, the second information, and the third information; and The PUCCH is sent based on the determined PRB index.

10. The UE according to claim 7, wherein, Based on the public PUCCH configuration including the third information, frequency hopping for the PUCCH is disabled.

11. The UE according to claim 7, wherein, The PRB index for the PUCCH is determined by applying positive values ​​to the PRB offset and the additional PRB offset, based on the fact that the PRB index in the PRB mapping for the PUCCH is counted in ascending order from the lower edge of the RedCap-specific initial UL BWP.

12. The UE according to claim 7, wherein, The PRB index for the PUCCH is determined by applying negative values ​​to the PRB offset and the additional PRB offset, based on the fact that the PRB index in the PRB mapping for the PUCCH is counted in descending order from the top edge of the RedCap-specific initial UL BWP.

13. An apparatus for a user equipment (UE) with RedCap capability, the apparatus comprising: At least one processor; as well as At least one computer memory storing instructions that, when executed by the at least one processor, cause RedCap UE to perform operations including: Receive system information from base station (BS), wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, a PUCCH is sent to the BS based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

14. A non-transitory computer-readable storage medium comprising program instructions that, when executed by at least one processor, cause a user equipment (UE) with degraded RedCap capability to perform operations, the operations including: Receive system information from base station (BS), wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, a PUCCH is sent to the BS based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

15. A method performed by a base station (BS), the method comprising the following steps: System information is sent to a user equipment (UE) with RedCap capability, wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, the PUCCH is received from the UE based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

16. A base station (BS) in a wireless communication system, the BS comprising: At least one processor; as well as At least one computer memory storing instructions that, when executed by the at least one processor, cause the BS to perform an operation, the operation including: System information is sent to a user equipment (UE) with RedCap capability, wherein the system information includes information related to the configuration of the common physical uplink control channel (PUCCH); Before receiving the dedicated PUCCH configuration, the PUCCH is received from the UE based on the public PUCCH configuration. The public PUCCH configuration includes: i) First information related to the PUCCH resource set associated with the physical resource block PRB offset; ii) Second information related to the additional PRB offset; and iii) Third information used to determine the PRB index in the PRB mapping for the PUCCH within the RedCap-specific initial uplink UL bandwidth portion BWP.

Images