Method for transmitting and receiving pucch in wireless communication system and apparatus therefor

Abstract

The present invention relates to a method for transmitting and receiving a PUCCH in a wireless communication system and an apparatus therefor. A method of transmitting and receiving a PUCCH in a wireless communication system is disclosed. The method performed by a RedCap terminal may comprise the steps of: transmitting a random access preamble to a base station; receiving a random access response from the base station based on the random access preamble; sending the Msg3 PUSCH to the base station based on the random access response; receiving Msg4 from the base station on the basis of the Msg3 PUSCH; and transmitting the PUCCH for the Msg4 to the base station.

Description

[0001] This application is a divisional application of patent application No. 202280005757.2 (International Application No. PCT / KR2022 / 000737), filed on February 24, 2023, with an international application date of January 14, 2020, entitled "Method and Apparatus for Transmitting and Receiving PUCCH in a Wireless Communication System".

[0002] Cross-reference to related applications

[0003] This application is a national phase application filed on January 14, 2022, under 35 USC371, International Application No. PCT / KR2022 / 000737, which claims priority to Korean Application No. 10-2021-0006895, filed January 18, 2021; Korean Application No. 10-2021-0044843, filed April 6, 2021; and Korean Application No. 10-2021-0151784, filed November 5, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0004] 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). Background Technology

[0005] Mobile communication systems have been developed to ensure user activity while providing voice services. These systems are expanding their services from voice-only to data. The current surge in data traffic is exhausting resources, and user demand for higher data rates is creating a need for more advanced mobile communication systems.

[0006] Next-generation mobile communication systems need to meet requirements such as handling explosively increasing data traffic, significantly increased per-user transmission rates, working with a large number of connected devices, and supporting very low end-to-end latency and high energy efficiency. To this end, various research efforts are underway on a range of technologies, including dual connectivity, massive MIMO, in-band full-duplex, non-orthogonal multiple access (NOMA), ultra-wideband support, and device networking.

[0007] Reduced bandwidth is considered a key characteristic of Reduced Cap (RedCap) user equipment (UE). Specifically, when a RedCap UE has this characteristic, the PUSCH / PUCCH frequency hopping in the initial UL BWP may exceed the UE's reduced bandwidth. Summary of the Invention

[0008] Technical issues

[0009] This disclosure provides a method and apparatus for performing a random access procedure (or initial access procedure) when the initial UL BWP is greater than the bandwidth of the RedCap UE.

[0010] This disclosure also provides a method and apparatus for performing a random access procedure by a RedCap UE in a communication environment where RedCap UEs and ordinary UEs (e.g., UEs other than RedCap UEs) coexist.

[0011] This disclosure also provides a method and apparatus for transmitting and receiving Msg3 PUSCH without frequency hopping when the initial UL BWP is greater than the bandwidth of the RedCap UE.

[0012] This disclosure also provides a method and apparatus for transmitting and receiving PUCCH (or HARQ-ACK information) for Msg4 without frequency hopping when the initial UL BWP is greater than the bandwidth of the RedCap UE.

[0013] The technical problem to be solved by this disclosure is not limited to the above-mentioned technical problem, and those skilled in the art to which this disclosure pertains can clearly understand other technical problems not mentioned above from the following description.

[0014] Technical solution

[0015] In one aspect of this disclosure, a method is provided for transmitting a Physical Uplink Control Channel (PUCCH) in a wireless communication system by a Reduced Cap (RedCap) User Equipment (UE), the method comprising: transmitting a random access preamble to a base station; receiving a random access response from the base station based on the random access preamble; transmitting a message (Msg)3 Physical Uplink Shared Channel (PUSCH) to the base station based on the random access response; receiving a Msg4 from the base station based on the Msg3 PUSCH; and transmitting a PUCCH to the base station for the Msg4, wherein at least one of the Msg3 PUSCH and / or the PUCCH is transmitted based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE, without frequency hopping.

[0016] The initial uplink bandwidth may be the bandwidth of the initial uplink bandwidth portion (BWP).

[0017] The bandwidth of the RedCap UE can be the maximum bandwidth supported by the RedCap UE.

[0018] Frequency hopping for the PUCCH can be configured to be "disabled".

[0019] The random access response may include a frequency hopping flag for the Msg3 PUSCH, and the frequency hopping flag may be set to "0".

[0020] Since the resources for the random access response are not included in the bandwidth of the RedCap UE, the random access response can be received based on frequency retuning.

[0021] The starting position of the random access response window can be configured using system information.

[0022] The PUCCH may include Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) information for the Msg4.

[0023] In another aspect of this disclosure, a Reduced Capability (RedCap) User Equipment (UE) configured to transmit a Physical Uplink Control Channel (PUCCH) in a wireless communication system is provided. The RedCap UE includes: at least one transceiver; at least one processor; and at least one memory operatively connected to the at least one processor and storing instructions that perform operations based on execution by the at least one processor. The operations include: transmitting a random access preamble to a base station; receiving a random access response from the base station based on the random access preamble; transmitting a message (Msg)3 Physical Uplink Shared Channel (PUSCH) to the base station based on the random access response; receiving Msg4 from the base station based on the Msg3 PUSCH; and transmitting a PUCCH to the base station for the Msg4, wherein at least one of the Msg3 PUSCH and / or the PUCCH is transmitted based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE, without frequency hopping.

[0024] In another aspect of this disclosure, a method is provided for a base station to receive a Physical Uplink Control Channel (PUCCH) in a wireless communication system, the method comprising: receiving a random access preamble from a Reduced Capability (RedCap) User Equipment (UE); sending a random access response to the RedCap UE based on the random access preamble; receiving a message (Msg)3 Physical Uplink Shared Channel (PUSCH) from the RedCap UE based on the random access response; sending Msg4 to the RedCap UE based on the Msg3 PUSCH; and receiving a PUCCH for the Msg4 from the RedCap UE, wherein at least one of the Msg3 PUSCH and / or the PUCCH is received based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE, without frequency hopping.

[0025] The initial uplink bandwidth may be the bandwidth of the initial uplink bandwidth portion (BWP).

[0026] The bandwidth of the RedCap UE can be the maximum bandwidth supported by the RedCap UE.

[0027] Frequency hopping for the PUCCH can be configured to be "disabled".

[0028] The random access response may include a frequency hopping flag for the Msg3 PUSCH, and the frequency hopping flag may be set to "0".

[0029] Since the resources for the random access response are not included in the bandwidth of the RedCap UE, the random access response can be transmitted based on frequency retuning.

[0030] The starting position of the random access response window can be configured using system information.

[0031] The PUCCH may include Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) information for the Msg4.

[0032] In another aspect of this disclosure, a base station configured to receive a Physical Uplink Control Channel (PUCCH) in a wireless communication system is provided. The base station includes: at least one transceiver; at least one processor; and at least one memory operatively connected to the at least one processor and storing instructions to perform operations based on execution by the at least one processor. The operations include: receiving a random access preamble from a Reduced Capability (RedCap) User Equipment (UE); sending a random access response to the RedCap UE based on the random access preamble; receiving a message (Msg)3 Physical Uplink Shared Channel (PUSCH) from the RedCap UE based on the random access response; sending Msg4 to the RedCap UE based on the Msg3 PUSCH; and receiving a PUCCH from the RedCap UE for the Msg4, wherein at least one of the Msg3 PUSCH and / or the PUCCH is received based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE, without frequency hopping.

[0033] In another aspect of this disclosure, a processing apparatus is provided, configured to control a Reduced Capability (RedCap) User Equipment (UE) in a wireless communication system to transmit a Physical Uplink Control Channel (PUCCH). The processing apparatus includes: at least one processor; and at least one memory operatively connected to the at least one processor and storing instructions that perform operations based on execution by the at least one processor. The operations include: transmitting a random access preamble to a base station; receiving a random access response from the base station based on the random access preamble; transmitting a message (Msg)3 Physical Uplink Shared Channel (PUSCH) to the base station based on the random access response; receiving a Msg4 from the base station based on the Msg3 PUSCH; and transmitting a PUCCH to the base station for the Msg4, wherein at least one of the Msg3 PUSCH and / or the PUCCH is transmitted based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE, without frequency hopping.

[0034] In another aspect of this disclosure, a computer-readable storage medium is provided storing at least one instruction, the at least one instruction being executed by at least one processor to allow the at least one processor to control operations, the operations including: sending a random access preamble to a base station; receiving a random access response from the base station based on the random access preamble; sending a message (Msg)3 Physical Uplink Shared Channel (PUSCH) to the base station based on the random access response; receiving Msg4 from the base station based on the Msg3 PUSCH; and sending a Physical Uplink Control Channel (PUCCH) to the base station for the Msg4, wherein at least one of the Msg3 PUSCH and / or the PUCCH is sent based on an initial uplink bandwidth greater than the bandwidth of a Reduced Capability (RedCap) User Equipment (UE), without frequency hopping.

[0035] Beneficial effects

[0036] This disclosure has the effect of performing a random access procedure (or initial access procedure) by minimizing the impact of the NR network (or base station) configuration when the initial UL BWP is greater than the bandwidth of the RedCap UE.

[0037] This disclosure also improves resource efficiency and enables low-latency and high-reliability communication systems in communication environments where RedCap UEs and ordinary UEs coexist.

[0038] This disclosure also has the following effect: when the initial UL BWP is greater than the bandwidth of the RedCap UE, the random access procedure can be performed efficiently without delay by sending and receiving Msg3 PUSCH without frequency hopping.

[0039] This disclosure also has the following effect: when the initial UL BWP is greater than the bandwidth of the RedCap UE, the random access procedure can be effectively performed without delay by sending and receiving PUCCH (or HARQ-ACK information) for Msg4 without frequency hopping.

[0040] The effects that can be obtained from this disclosure are not limited to the effects described above, and those skilled in the art to which this disclosure pertains can clearly understand from the following description other effects not mentioned above. Attached Figure Description

[0041] The accompanying drawings, which are included to provide a further understanding of the disclosure and form part of this specification, illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0042] Figure 1 This is a diagram illustrating an example of the overall system architecture of an NR to which the methods proposed in this disclosure can be applied.

[0043] Figure 2 The diagram illustrates the relationship between uplink frames and downlink frames in a wireless communication system to which the methods proposed in this disclosure can be applied.

[0044] Figure 3 An example of a frame structure in an NR system is illustrated.

[0045] Figure 4 An example of a resource grid supported by a wireless communication system is illustrated, to which the methods proposed in this disclosure can be applied.

[0046] Figure 5 The illustration shows the time slot structure of the NR frame to which the method described in this disclosure applies.

[0047] Figure 6 An example of a resource grid for each antenna port and parameter set to which the method described in this disclosure applies is illustrated.

[0048] Figure 7 The diagram illustrates the physical channels and general signal transmission used in the 3GPP system.

[0049] Figure 8 The diagram illustrates the SSB structure.

[0050] Figure 9 The diagram illustrates SSB transmission.

[0051] Figure 10 An example of a random access procedure is illustrated.

[0052] Figure 11 The diagram illustrates the two-step RACH process.

[0053] Figure 12 The diagram illustrates a flowchart of the process of reporting device type information to a base station.

[0054] Figure 13 The diagram illustrates a method for a base station to schedule Msg3 PUSCH within the RedCap UE bandwidth when the initial UL bandwidth is greater than the RedCap UE bandwidth, without FH.

[0055] Figure 14 The illustration shows method 2-2 in case 1 when the initial UL bandwidth is greater than the RedCap UE bandwidth.

[0056] Figure 15 The illustration shows method 2-2 in case 2 when the initial UL bandwidth is greater than the RedCap UE bandwidth.

[0057] Figure 16 The illustration shows an example of method 2-2 in case 3 when the initial UL bandwidth is greater than the RedCap UE bandwidth.

[0058] Figure 17 The illustration shows an example of applying modular arithmetic in case 1.

[0059] Figure 18 The illustration shows an example of applying mirroring in case 1.

[0060] Figure 19 This is a flowchart illustrating the operation method of the UE described in this disclosure.

[0061] Figure 20 This is a flowchart illustrating the operation method of the base station described in this disclosure.

[0062] Figure 21 The diagram illustrates a communication system (1) applied to this disclosure.

[0063] Figure 22 The illustrations can be applied to wireless devices disclosed herein.

[0064] Figure 23 The illustration shows another example of a wireless device applied to this disclosure.

[0065] Figure 24 The illustration is applied to the portable device of this disclosure. Detailed Implementation

[0066] Reference will now be made in detail to embodiments of this disclosure, examples of which are illustrated in the accompanying drawings. The following will be discussed in conjunction with the accompanying drawings. Figure 1 The detailed description provided herein is intended to describe exemplary embodiments of the present disclosure and not to describe the only embodiments for carrying out the present disclosure. The following detailed description includes details to provide a complete understanding of the present disclosure. However, those skilled in the art will recognize that the present disclosure can be performed without these details.

[0067] In some cases, to prevent the concepts of this disclosure from being unclear, known structures and devices may be omitted or illustrated in block diagram form based on the core functions of each structure and device.

[0068] 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. The following terms can be used instead of base station (BS): fixed station, Node B, evolved Node B (eNB), next-generation Node B (gNB), base transceiver system (BTS), access point (AP), network (5G network), AI system, roadside unit (RSU), vehicle, robot, unmanned aerial vehicle (UAV), AR (augmented reality) device, VR (virtual reality) device, etc. In addition, the terminal can be fixed or mobile, and can be replaced by the following terms, including: User Equipment (UE), Mobile Station (MS), User Terminal (UT), Mobile Subscriber Station (MSS), Subscriber Station (SS), Advanced Mobile Station (AMS), Wireless Terminal (WT), Machine Type Communication (MTC) equipment, Machine-to-Machine (M2M) equipment and Device-to-Device (D2D) equipment, vehicle, robot, AI module, Unmanned Aerial Vehicle (UAV), AR (Augmented Reality) equipment, VR (Virtual Reality) equipment, etc.

[0069] The following technologies can be used in various radio access systems, including CDMA, FDMA, TDMA, OFDMA, and SC-FDMA. CDMA can be implemented as radio technologies such as Universal Terrestrial Radio Access (UTRA) or CDMA2000. TDMA can be implemented as radio technologies such as Global System for Mobile Communications (GSM) / General Packet Radio Service (GPRS) / Enhanced Data Rate for GSM Evolution (EDGE). OFDMA can be implemented as radio technologies such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, and Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). 3GPP Long Term Evolution (LTE) is part of Evolved UMTS (E-UMTS) using E-UTRA, while Advanced LTE(A) / LTE-A pro is an evolved version of 3GPP LTE. 3GPP NR (New Radio or New Radio Access Technology) is an evolution of 3GPP LTE / LTE-A / LTE-A pro.

[0070] For clarity, the technical spirit of this disclosure is described based on 3GPP communication systems (e.g., LTE-A or NR), but the technical spirit of this disclosure is not limited thereto. LTE refers to technology after 3GPP TS 36.xxx version 8. Specifically, LTE technology after 3GPP TS 36.xxx version 10 is referred to as LTE-A, and LTE technology after 3GPP TS 36.xxx version 13 is referred to as LTE-A pro. 3GPP NR refers to technology after TS 38.xxx version 15. LTE / NR may be referred to as a 3GPP system. "xxx" refers to the detailed standard document number. Background information, terms, abbreviations, etc., used to describe this disclosure may refer to matters disclosed in the standard documents opened in this disclosure. For example, the following documents may be referenced.

[0071] 3GPP LTE

[0072] -36.211: Physical Channels and Modulation

[0073] -36.212: Multiplexing and Channel Coding

[0074] -36.213: Physical Layer Process

[0075] -36.300: Overall Description

[0076] -36.331: Radio Resource Control (RRC)

[0077] 3GPP NR

[0078] -38.211: Physical Channel and Modulation

[0079] -38.212: Multiplexing and Channel Coding

[0080] -38.213: Physical layer process used for control

[0081] -38.214: Physical layer procedures for data

[0082] -38.300: General Description of NR and NG-RAN

[0083] -36.331: Radio Resource Control (RRC) Protocol Specification

[0084] With an increasing number of communication devices requiring greater communication capacity, there is a need for improved mobile broadband communications compared to existing radio access technologies (RATs). Furthermore, massive machine-type communication (MTC), which provides various services anytime, anywhere by connecting numerous devices and objects, is one of the main issues to be considered in next-generation communications. Additionally, communication system designs considering reliability and latency-sensitive services / UEs are being discussed. The introduction of next-generation radio access technologies considering enhanced mobile broadband communication (eMBB), massive MTC (mMTC), and ultra-reliable low-latency communication (URLLC) is discussed, and in this disclosure, for convenience, this technology is referred to as the new RAT. NR is an example expression representing 5G radio access technology (RAT).

[0085] The three main demand areas for 5G include: (1) enhanced mobile broadband (eMBB), (2) massive machine-type communications (mMTC) and (3) ultra-reliable low-latency communications (URLLC).

[0086] Some use cases may require optimization across multiple domains, while others may focus on only one key performance indicator (KPI). 5G supports a wide range of use cases in a flexible and reliable manner.

[0087] eMBB extends far beyond basic mobile internet access, encompassing a wide range of media and entertainment applications in two-way tasks, cloud, or augmented reality. Data is one of the main drivers of 5G, and dedicated voice services may not be available in the 5G era for the first time. In 5G, it is expected that voice will be processed as an application using data connections simply provided by the communication system. The main reasons for increased traffic include increased content size and an increased number of applications requiring high data transmission rates. As more devices connect to the internet, streaming services (audio and video), conversational video, and mobile internet connections will be used more extensively. Such a large number of applications require always-on connectivity to push real-time information and notifications to users. Cloud storage and applications are rapidly increasing on mobile communication platforms, and this can be applied to both business and entertainment. Furthermore, cloud storage is a specific use case driving uplink data transmission rates. 5G is also used for remote services in the cloud. Lower end-to-end latency is needed when using haptic interfaces to maintain a good user experience. Entertainment, such as cloud gaming and video streaming, are other key elements increasing the demand for mobile broadband capabilities. Entertainment is essential in any highly mobile environment, including on smartphones and tablets, and on smartphones and tablets. Another use case is augmented reality and information retrieval for entertainment. In this case, augmented reality requires extremely low latency and instantaneous data volumes.

[0088] Furthermore, one of the most anticipated 5G use cases involves a capability that allows for seamless connectivity of embedded sensors across all sectors, known as mMTC. By 2020, the potential number of Internet of Things (IoT) devices is projected to reach 20.4 billion. The Industrial Internet of Things (IIoT) is one of the areas where 5G plays a major role, enabling smart cities, asset tracking, smart utilities, agriculture, and security infrastructure.

[0089] URLLC includes new services that will transform industries such as autonomous vehicles through remote control of critical infrastructure and links with ultra-high reliability and low latency. Levels of reliability and latency are critical for smart grid control, industrial automation, robotics engineering, and drone control and regulation.

[0090] Describe multiple use cases in more detail.

[0091] 5G can complement Fiber to the Home (FTTH) and cable-based broadband (or DOCSIS) as a means of delivering measured streams ranging from gigabits per second to hundreds of megabits per second. Beyond virtual reality and augmented reality, this high speed is also necessary for transmitting televisions with resolutions of 4K or higher (6K, 8K, or higher). Virtual reality (VR) and augmented reality (AR) applications include immersive sports games. Specific applications may require special network configurations. For example, in the case of VR gaming, to minimize latency for gaming companies, it may be necessary to integrate core servers with the network operator's edge network servers.

[0092] Alongside numerous use cases for automotive mobile communications, automobiles are expected to be a significant and dynamic driver of 5G. For example, passenger entertainment requires both high-capacity and high-mobility mobile broadband. This is because future users will continue to expect high-quality connectivity regardless of their location and speed. Another example of automotive use is augmented reality dashboards. Augmented reality dashboards overlay and display information on what the driver sees through the windshield, identify objects in the dark, and inform the driver of the object's distance and movement. In the future, wireless modules will enable communication between vehicles, information exchange between vehicles and supporting infrastructure, and information exchange between vehicles and other connected devices, such as devices accompanying pedestrians. Safety systems will guide alternative behavioral processes so that drivers can drive more safely, thereby reducing the risk of accidents. The next step will be remotely controlled or autonomous vehicles. This requires highly reliable and extremely fast communication between different autonomous vehicles and between vehicles and infrastructure. In the future, autonomous vehicles may perform all driving activities, and the driver will focus on things outside of traffic that the car itself cannot perceive. The technological requirements of autonomous vehicles demand ultra-low latency and ultra-high-speed reliability, increasing traffic safety to levels unattainable by humans.

[0093] The smart cities and smart homes mentioned in the smart society will be embedded as high-density wireless sensor networks. This distributed network of smart sensors will identify the cost and energy-saving maintenance status of cities or homes. A similar configuration can be implemented for each home. All temperature sensors, window and heating controllers, burglar alarms, and home appliances will be wirelessly connected. Many of these sensors are typically low data transmission rates, low power consumption, and low cost. However, certain types of monitoring equipment, for example, may require real-time high-definition video.

[0094] The consumption and distribution of energy, including heat or gases, are highly decentralized, thus necessitating automated control of distributed sensor networks. Smart grids collect information and interconnect these sensors using digital information and communication technologies, enabling the sensors to operate based on that information. This information can include the behavior of suppliers and consumers, and therefore smart grids can improve fuel distribution, such as electricity, in an efficient, reliable, economical, sustainable, and automated manner. A smart grid can be considered another sensor network with low latency.

[0095] The healthcare sector has numerous applications that benefit from mobile communications. Communication systems can support telemedicine, providing clinical care in remote locations. This helps reduce distance barriers and can improve access to healthcare services that are not readily available in remote agricultural areas. Furthermore, it can be used to save lives in critical treatments and emergencies. Mobile communication-based wireless sensor networks can provide remote monitoring and sensing of parameters such as heart rate and blood pressure.

[0096] Radio and mobile communications are becoming increasingly important in industrial applications. Cabling incurs high installation and maintenance costs. Therefore, the possibility of replacing cables with reconfigurable radio links presents an attractive opportunity in many industrial sectors. However, realizing this possibility requires radio connections to operate with latency, reliability, and capacity similar to cables, while management is simplified. Low latency and low error probability are new requirements for 5G connectivity.

[0097] Logistics and freight tracking are important use cases for mobile communications, enabling the tracking of inventory and packages anywhere using location-based information systems. Logistics and freight tracking use cases typically require lower data speeds but demand wide coverage and reliable location information.

[0098] In addition, use cases spanning regions of mMTC and eMBB or mMTC and URLLC are considered important.

[0099] In new RAT systems including NR, OFDM or similar transmission schemes are used. The new RAT system may follow OFDM parameters different from those of LTE. Alternatively, the new RAT system may follow the conventional LTE / LTE-A parameter set as is or have a larger system bandwidth (e.g., 100MHz). Alternatively, a single cell may support multiple parameter sets. In other words, UEs operating with different parameter sets can coexist in a single cell.

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

[0101] Definition of terminology

[0102] eLTE eNB: eLTE eNB is an evolution of eNB that supports connectivity to EPC and NGC.

[0103] gNB: A node that supports NR and connectivity to NGC.

[0104] New RAN: A radio access network that supports NR or E-UTRA or interfaces with NGC.

[0105] Network slicing: Network slicing refers to a network customized by an operator to provide an optimized solution for specific market scenarios with specific requirements across the end-to-end range.

[0106] Network functions: Network functions are logical nodes in the network architecture, which have well-defined external interfaces and well-defined functional behaviors.

[0107] NG-C: The control plane interface used at the NG2 reference point between the new RAN and NGC.

[0108] NG-U: User plane interface used at the NG3 reference point between the new RAN and NGC.

[0109] Non-standalone NR: A deployment configuration in which the gNB requires an LTE eNB as an anchor for control plane connectivity to the EPC, or requires an eLTE eNB as an anchor for control plane connectivity to the NGC.

[0110] Non-standalone E-UTRA: A deployment configuration in which the eLTE eNB requires the gNB as the anchor for control plane connectivity to the NGC.

[0111] User plane gateway: the endpoint of the NG-U interface.

[0112] System Overview

[0113] Figure 1 An example of the overall structure of an NR system to which the method proposed in this disclosure can be applied is illustrated.

[0114] refer to Figure 1 NG-RAN is composed of gNBs, which provide NG-RAN user plane (new AS sublayer / PDCP / RLC / MAC / PHY) and control plane (RRC) protocol terminals for user equipment (UE).

[0115] The gNBs are interconnected via the Xn interface.

[0116] The gNB is also connected to the NGC via the NG interface.

[0117] More specifically, the gNB is connected to the Access and Mobility Management Function (AMF) via the N2 interface and to the User Plane Function (UPF) via the N3 interface.

[0118] New RAT (NR) parameter set and frame structure

[0119] In NR systems, multiple parameter sets can be supported. Parameter sets can be defined by subcarrier spacing and CP (cyclic prefix) overhead. They can also be defined by scaling the basic subcarrier spacing to an integer N (or...). This allows us to derive the spacing between multiple subcarriers. Furthermore, although it is assumed that very low subcarrier spacing is not used at very high subcarrier frequencies, the set of parameters to be used can be selected independently of the frequency band.

[0120] In addition, the NR system can support multiple frame structures based on multiple parameter sets.

[0121] The following section describes the set of orthogonal frequency division multiplexing (OFDM) parameters and frame structures that can be considered in NR systems.

[0122] The multiple OFDM parameter sets supported by the NR system can be defined as shown in Table 1.

[0123] [Table 1]

[0124]

[0125] NR supports multiple parameter sets (or subcarrier spacing (SCS)) to support a variety of 5G services. For example, a 15kHz SCS supports a wide area in 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 greater than 24.25 GHz to overcome phase noise.

[0126] The NR band is defined as frequency ranges of two types (FR1 and FR2). FR1 and FR2 can be configured as shown in Table 2 below. Furthermore, FR2 can refer to millimeter wave (mmW).

[0127] [Table 2]

[0128]

[0129] Regarding the frame structure in the NR system, the size of each field in the time domain is expressed as: Multiples of the time unit. In this case... and DL and UL transmissions are configured to have A radio frame is a portion of a radio frame. A radio frame consists of ten subframes, each subframe having... This is part of a larger context. In this case, there may be both UL frame sets and DL frame sets.

[0130] Figure 2 The diagram illustrates the relationship between uplink frames and downlink frames in a wireless communication system to which the method proposed in this disclosure can be applied.

[0131] like Figure 2 As illustrated, the uplink frame number i used for transmission from the user equipment (UE) should begin before the start of the corresponding downlink frame at the corresponding UE. .

[0132] Regarding parameter sets The time slots are in ascending order within the subframe. Numbered, and in ascending order within the radio frame. Numbering. A time slot is composed of... Composed of consecutive OFDM symbols, and The time slot is determined by the parameter set and time slot configuration used. (Time slot in subframe) The start of OFDM symbols in the same subframe The beginnings are aligned in time.

[0133] Not all UEs can transmit and receive simultaneously, and this means that not all OFDM symbols in the downlink or uplink time slots are available.

[0134] Table 3 shows the number of OFDM symbols in each time slot during normal CP. Number of time slots per radio frame and the number of time slots in each subframe Table 4 shows the number of OFDM symbols in each slot of the extended CP, the number of slots in each radio frame, and the number of slots in each subframe.

[0135] [Table 3]

[0136]

[0137] [Table 4]

[0138]

[0139] Figure 3 An example of a frame structure in an NR system is illustrated. Figure 3 This is for ease of explanation only and does not limit the scope of this disclosure.

[0140] In Table 4, In the case of 2, that is, as an example with a subcarrier spacing (SCS) of 60 kHz, referring to Table 3, a subframe (or frame) can include four time slots, and Figure 3 A subframe shown here consists of {1, 2, 4} time slots. For example, the number of time slots that can be included in a subframe is defined in Table 3.

[0141] Furthermore, microslots can consist of 2, 4, or 7 symbols, or they can consist of more or fewer symbols.

[0142] Regarding physical resources in an NR system, one can consider antenna ports, resource grids, resource elements, resource blocks, carrier components, etc.

[0143] The physical resources mentioned above that can be considered in an NR system are described in more detail below.

[0144] First, regarding antenna ports, an antenna port is defined such that a channel on which a symbol of that antenna port can be transmitted can be inferred from a channel on which another symbol of the same antenna port is transmitted. When the large-scale properties of a channel transmitting a symbol of one antenna port can be inferred from a channel transmitting a symbol of another antenna port, the two antenna ports can be considered to have a quasi-co-located or quasi-co-located (QC / QCL) relationship. In this case, the large-scale properties include at least one of the following: delay spread, Doppler spread, frequency shift, average received power, and receive timing.

[0145] Figure 4 An example of a resource grid supported in a wireless communication system to which the method proposed in this disclosure can be applied is illustrated.

[0146] refer to Figure 4 The resource grid is composed of frequency domain Each subframe consists of 14.2 subcarriers. μ It consists of OFDM symbols, but this disclosure is not limited thereto.

[0147] In an NR system, the transmitted signals are described by one or more resource grids, which are... Subcarriers and It consists of OFDM symbols, among which . This represents the maximum transmission bandwidth, and it can be changed not only between parameter sets, but also between uplink and downlink.

[0148] In this case, such as Figure 6 Each parameter set is illustrated in the diagram. Antenna port p can be configured with a resource grid.

[0149] Figure 5 The illustration shows the time slot structure of the NR frame to which the method described in this disclosure applies.

[0150] A time slot comprises multiple symbols in the time domain. For example, in a normal CP, a time slot comprises 7 symbols, and in an extended CP, a time slot comprises 6 symbols. A carrier comprises multiple subcarriers in the frequency domain. A resource block (RB) can be defined as multiple consecutive subcarriers in the frequency domain (e.g., 12 subcarriers). A bandwidth portion (BWP) can be defined as multiple consecutive (physical) RBs ((P)RBs) in the frequency domain, and a BWP can correspond to a set of parameters (e.g., SCS, CP length, etc.). A carrier can include up to N BWPs (e.g., 5 BWPs). Data communication can be performed via an active BWP, and only one BWP can be activated for a UE. Each element in the resource grid can be called a resource element (RE), and a complex symbol can be mapped to each element.

[0151] Figure 6 An example of a resource grid to which the method proposed in this disclosure can be applied for each antenna port and parameter set is illustrated.

[0152] For parameter sets Each element of the resource grid for antenna port p is called a resource element, and is indexed by... Unique identifier, among which It is an index in the frequency domain, and This refers to the position of the symbol within a subframe. Index pair Used to reference resource elements in a time slot, where .

[0153] Parameter set and resource elements of antenna port p Corresponding to complex values If there is no risk of confusion, or when a specific antenna port or parameter set is not specified, index p and may be discarded. And as a result, complex values ​​may be or .

[0154] Furthermore, physical resource blocks are defined in the frequency domain. A series of consecutive subcarriers.

[0155] Point A is used as a common reference point for the resource block grid, and can be obtained as follows.

[0156] - offsetToPointA for PCell downlink represents the frequency offset between point A and the lowest subcarrier of the lowest resource block, which overlaps with the SS / PBCH block used by the UE for initial cell selection, and is expressed in units of resource blocks, where it is assumed that the subcarrier spacing of FR1 is 15 kHz and the subcarrier spacing of FR2 is 60 kHz.

[0157] -absoluteFrequencyPointA represents the frequency location of point A, expressed in absolute radio frequency channel number (ARFCN).

[0158] Common resource blocks are numbered from 0 upwards in the frequency domain and are used for subcarrier spacing configuration. .

[0159] Used for subcarrier spacing configuration The center of subcarrier 0 of common resource block 0 coincides with "point A". The common resource block number in the frequency domain can be given by the following equation 1. and for subcarrier spacing configuration The resource elements (k,l).

[0160] [Equation 1]

[0161]

[0162] Here, It can be defined relative to point A, such that This corresponds to the subcarrier centered at point A. The physical resource block is defined within the bandwidth portion (BWP) and ranges from 0 to... Number, among which This is the BWP's serial number. (In BWP) Physical resource blocks in and public resource blocks The relationship between them can be given by the following equation 2.

[0163] [Equation 2]

[0164]

[0165] Here, It can be a public resource block that BWP starts with relative to public resource block 0.

[0166] Bandwidth Component (BWP)

[0167] NR systems can support up to 400 MHz per component carrier (CC). If a UE operating in a wideband CC operates with RF continuously enabled for all CCs, UE battery consumption may increase. Alternatively, when considering several use cases operating in a wideband CC (e.g., eMBB, URLLC, mMTC, V2X, etc.), different sets of parameters (e.g., subcarrier spacing) can be supported for each band within the corresponding CC. Alternatively, the maximum bandwidth capability for each UE can vary. By taking this into account, the BS can instruct the UE to operate only in a portion of the wideband CC's bandwidth, rather than the entire bandwidth, and for convenience, the corresponding portion of the bandwidth is intended to be defined as the Bandwidth Part (BWP). The BWP can consist of consecutive resource blocks (RBs) on the frequency axis and can correspond to a set of parameters (e.g., subcarrier spacing, CP length, slot / micro-slot duration).

[0168] Simultaneously, the base station can configure multiple BWPs even within a single CC assigned to a UE. As an example, a BWP occupying a relatively small frequency domain can be configured in the PDCCH monitoring slot, and the PDSCH indicated in the PDCCH can be scheduled to a larger BWP. Alternatively, when UEs are concentrated on a specific BWP, some UEs can be configured with other BWPs for load balancing. Alternatively, considering frequency domain inter-cell interference cancellation between neighboring cells, a portion of the spectrum across the entire bandwidth can be excluded, and even two BWPs can be configured in the same time slot. That is, the base station can configure at least one DL / UL BWP for a UE associated with a broadband CC and can activate at least one DL / UL BWP among the configured DL / UL BWPs at a specific time (via L1 signaling, MAC CE, or RRC signaling), and can indicate a handover to another configured DL / UL BWP (via L1 signaling, MAC CE, or RRC signaling), or, based on a timer, switch to a fixed DL / UL BWP when the timer value expires. In this case, the activated DL / UL BWP is defined as the active DL / UL BWP. However, when the UE is in the initial access process or before the RRC connection is established, the UE may not be able to receive the configuration for the DL / UL BWP, and in such cases, the DL / UL BWP assumed by the UE is defined as the initial active DL / UL BWP.

[0169] Physical channels and general signal transmission

[0170] Figure 7The diagram illustrates the physical channels and general signal transmission used in a 3GPP system. In a wireless communication system, the UE receives information from the eNB via the downlink (DL) and transmits information from the eNB via the uplink (UL). The information transmitted and received by the eNB and UE includes data and various control information, and various physical channels exist depending on the type / purpose of the information transmitted and received by the eNB and UE.

[0171] When the UE is powered on or enters a new cell, it performs an initial cell search operation (S701), such as synchronizing with the eNB. To do this, the UE can receive the primary synchronization signal (PSS) and secondary synchronization signal (SSS) from the eNB, synchronize with the eNB, and obtain information such as the cell ID. Subsequently, the UE can receive the physical broadcast channel (PBCH) from the eNB and obtain intra-cell broadcast information. Simultaneously, the UE receives a downlink reference signal (DL RS) during the initial cell search step to check the downlink channel status.

[0172] After completing the initial cell search, the UE obtains more specific system information by receiving the physical downlink control channel (PDCCH) and the physical downlink shared channel (PDSCH) based on the information loaded on the PDCCH (S702).

[0173] Meanwhile, when there are no available radio resources for initial access to the eNB or for signal transmission, the UE can perform a random access procedure (RACH) to the eNB (S703 to S706). To do this, the UE can send a specific sequence to the preamble via the Physical Random Access Channel (PRACH) (S703 and S705), and receive a response message (Random Access Response (RAR) message) for that preamble via the PDCCH and the corresponding PDSCH. In the case of a contention-based RACH, a contention resolution procedure can be performed separately (S706).

[0174] Then, the UE performing the above process can execute PDCCH / PDSCH reception (S707) and Physical Uplink Shared Channel (PUSCH) / Physical Uplink Control Channel (PUCCH) transmission (S708) as a general uplink / downlink signal transmission process. Specifically, the UE can receive downlink control information (DCI) via PDCCH. Here, DCI may include control information such as resource allocation information for the UE, and the format may vary depending on the intended use.

[0175] Meanwhile, control information sent by the UE to the eNB via the uplink or received by the UE from the eNB may include downlink / uplink ACK / NACK signals, channel quality indicator (CQI), precoding matrix index (PMI), rank indicator (RI), etc. The UE can send control information such as CQI / PMI / RI via PUSCH and / or PUCCH.

[0176] Initial Access (IA) and Random Access (RA) Procedures

[0177] Synchronization Signal Block (SSB) transmission and related operations

[0178] Figure 8 The diagram illustrates the SSB structure. The UE can use the SSB to perform cell search, system information acquisition, beam alignment for initial access, DL measurements, and more. The SSB can be used interchangeably with the Synchronization Signal / Physical Broadcast Channel (SS / PBCH) block.

[0179] refer to Figure 8 The SSB comprises the PSS, SSS, and PBCH. The SSB consists of four consecutive OFDM symbols, and each OFDM symbol transmits either the PSS, PBCH, SSS / PBCH, or PBCH. Each of the PSS and SSS consists of one OFDM symbol and 127 subcarriers, and the PBCH consists of three OFDM symbols and 576 subcarriers. The PBCH is encoded / decoded based on polar codes and modulated / demodulated according to Quadrature Phase Shift Keying (QPSK). The PBCH in an OFDM symbol includes the data resource elements (REs) to which the complex modulation values ​​of the PBCH are mapped, and the DMRS REs to which the demodulation reference signal (DMRS) used for the PBCH is mapped. Each resource block of an OFDM symbol contains three DMRS REs, and there are three data REs between the DMRS REs.

[0180] Community search

[0181] Cell search refers to the process by which a UE obtains time / frequency synchronization for a cell and detects the cell identifier (ID) (e.g., physical layer cell ID (PCI)). The PSS is used to detect the cell ID from a group of cell IDs, and the SSS is used to detect the cell ID group. The PBCH is used to detect the SSB (time) index and half-frames.

[0182] The UE's cell search process can be summarized as shown in Table 5 below.

[0183] [Table 5]

[0184]

[0185] There are 336 cell ID groups, and each cell ID group contains 3 cell IDs. There are a total of 1008 cell IDs. Information about the cell ID group to which a cell ID belongs is provided / obtained via the cell's SSS, and information about the cell IDs among the 336 cells in the cell ID group is provided / obtained via the PSS. Figure 9 The diagram illustrates SSB transmission.

[0186] SSBs are transmitted periodically according to the SSB periodicity. The default SSB period, assumed by the UE during initial cell search, is defined as 20 ms. After cell access, the SSB periodicity can be set by the network (e.g., BS) to one of {5 ms, 10 ms, 20 ms, 40 ms, 80 ms, 160 ms}. An SSB burst set is configured at the beginning of the SSB periodicity. An SSB burst set consists of a 5 ms time window (i.e., half a frame), and an SSB can be transmitted up to N times within an SSB burst set. The maximum number of SSB transmissions L can be given according to the carrier's frequency band as follows. One time slot includes up to two SSBs.

[0187] - For the frequency range up to 3 GHz, L=4

[0188] - For the frequency range of 3GHz to 6GHz, L=8

[0189] - For the frequency range of 6GHz to 52.6GHz, L=64

[0190] The temporal position of an SSB candidate within an SS burst set can be defined based on the subscriber interval. The temporal position of an SSB candidate is indexed sequentially from 0 to L-1 within the SSB burst set (i.e., half-frame) (SSB index).

[0191] Multiple SSBs can be transmitted within the frequency span of a carrier. The physical layer cell identifiers of these SSBs do not need to be unique, and other SSBs can have different physical layer cell identifiers.

[0192] The UE can obtain DL synchronization by detecting SSBs. The UE can identify the structure of the SSB burst set based on the detected SSB (time) index, and thereby detect symbol / slot / half-frame boundaries. The system frame number (SFN) information and half-frame indication information can be used to identify the frame / half-frame number to which the detected SSB belongs.

[0193] Specifically, the UE can obtain the 10-bit SFN of the frame to which the PBCH belongs from the PBCH. Next, the UE can obtain 1 bit of half-frame indication information. For example, if the UE detects a PBCH with a half-frame indication bit set to 0, the UE can determine that the SSB to which the PBCH belongs belongs to the first half-frame of the frame, and if the UE detects a PBCH with a half-frame indication bit set to 1, the UE can determine that the SSB to which the PBCH belongs belongs to the second half-frame of the frame. Finally, the UE can obtain the SSB index of the SSB to which the PBCH belongs based on the DMRS sequence and the PBCH payload carried by the PBCH.

[0194] System Information Acquisition

[0195] System information (SI) is divided into the main information block (MIB) and multiple system information blocks (SIB). SIs other than those in the MIB can be referred to as residual minimal system information (RMSI). For details, please refer to the following.

[0196] - The MIB includes information / parameters for monitoring and scheduling the PDCCH carrying System Information Block 1 (SIB1), and is transmitted by the BS via the SSB's PBCH. For example, the UE can use the MIB to check for the existence of a Control Resource Set (CORESET) for the Type 0-PDCCH Common Search Space. The Type 0-PDCCH Common Search Space is a PDCCH search space used to transmit PDCCHs for scheduling SI messages. If the Type 0-PDCCH Common Search Space exists, the UE can determine (i) the multiple consecutive resource blocks and one or more consecutive symbols constituting the CORESET, and (ii) the PDCCH timing (e.g., the time-domain location for PDCCH reception) based on information within the MIB (e.g., pdcch-ConfigSIB1). If the Type 0-PDCCH Common Search Space does not exist, pdcch-ConfigSIB1 provides information on the frequency locations where SSB / SIB1 exists and the frequency ranges where SSB / SIB1 does not exist.

[0197] - SIB1 contains 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 of 2 or greater). For example, SIB1 may indicate whether SIBx is periodically broadcast or whether SIBx is provided by a request from the UE, depending on the on-demand scheme. If SIBx is provided by the on-demand scheme, SIB1 may include information required by the UE to perform an SI request. SIB1 is transmitted via PDSCH, the PDCCH used to schedule SIB1 is transmitted through the Type 0-PDCCH common search space, and SIB1 is transmitted via the PDSCH indicated by the PDCCH.

[0198] - 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).

[0199] Channel measurement and rate matching

[0200] Up to L SSBs can be transmitted within an SSB burst set, and the actual number / location of SSBs transmitted can vary per BS / cell. The actual number / location of SSBs transmitted is used for rate matching and measurement, and information about the actual transmitted SSBs is provided to the UE.

[0201] Random access procedure

[0202] The UE's random access process can be summarized as shown in Table 6 and... Figure 10 As shown in the image.

[0203] [Table 6]

[0204]

[0205] Random access procedures are used for various purposes. For example, they can be used for initial network access, handover, and UE-triggered UL data transmission. UEs can use random access procedures to obtain UL synchronization and UL transmission resources. Random access procedures are classified into contention-based and contention-free random access procedures.

[0206] Figure 10 An example of a random access procedure is illustrated. Specifically, Figure 10 The diagram illustrates a contention-based random access process.

[0207] First, the UE can transmit the random access preamble as Msg1 of the random access procedure in the UL on the PRACH (e.g., see [link]). Figure 10 (1701 in (a)).

[0208] It supports random access preamble sequences with two different lengths. The long sequence length of 839 is used for subcarrier spacings of 1.25 kHz and 5 kHz, and the short sequence length of 139 is used for subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, and 120 kHz.

[0209] Multiple preamble formats are defined by one or more RACH OFDM symbols and different cyclic prefixes (and / or guard times). The RACH configuration for the cell is included in the cell's system information and provided to the UE. The RACH configuration includes information about the PRACH subcarrier spacing, available preambles, preamble formats, etc. The RACH configuration includes association information between SSBs and RACH (time-frequency) resources. The UE transmits the random access preamble in the RACH time-frequency resources associated with the detected or selected SSB.

[0210] The threshold for the SSB used for RACH resource association can be set by the network, and the RACH preamble is transmitted or retransmitted based on the SSB, wherein the reference signal received power (RSRP) measured based on the SSB satisfies the threshold. For example, the UE can select one of the SSBs that satisfies the threshold, and can transmit or retransmit the RACH preamble based on the RACH resource associated with the selected SSB.

[0211] When the BS receives the random access preamble from the UE, the BS sends a random access response (RAR) message (Msg2) to the UE (see, for example, see...). Figure 10 (1703 in (a)). The PDCCH carrying the RAR is CRC masked with the Random Access (RA) Radio Network Temporary Identifier (RNTI) (RA-RNTI) and transmitted. The UE that detects the PDCCH masked with RA-RNTI can receive the RAR from the PDSCH scheduled by the DCI carried by the PDCCH. The UE checks whether the RAR includes random access response information (i.e., Msg1) for the preamble sent by the UE. The presence or absence of random access information for Msg1 sent by the UE can be determined based on the presence or absence of the random access preamble ID for the preamble sent by the UE. If there is no response to Msg1, the UE can retransmit the RACH preamble less than a predetermined number of times during power ramping, such as Figure 10 As shown in (b), the UE calculates the PRACH transmission power for preamble retransmission based on the most recent path loss and power gradient counter.

[0212] The random access response information includes timing advance information for UL synchronization, UL clearance, and the UE temporary cell RNTI (C-RNTI). If the temporary UE receives the random access response information for itself on the PDSCH, the UE is aware of the timing advance information for UL synchronization, the initial UL clearance, and the UE temporary cell RNTI (C-RNTI). The timing advance information is used to control the uplink signal transmission timing. To ensure better alignment between the UE's PUSCH / PUCCH transmission and the subframe timing at the network end, the network (e.g., BS) can measure the time difference between PUSCH / PUCCH / SRS reception and the subframe and send the timing advance information based on this time difference. The UE can perform UL transmission as Msg3 of the random access procedure on the physical uplink shared channel based on the random access response information (e.g., see [link to random access procedure]). Figure 10 (1705 in (a)). Msg3 may include an RRC connection request and a UE identifier. The network may send Msg4 as a response to Msg3, and Msg4 may be processed as a contention resolution message on the DL (e.g., see [link to relevant documentation]). Figure 10 (1707 in (a)). The UE can enter the RRC connection state by receiving Msg4.

[0213] When a UE hands over to another cell or BS, or when a contention-free random access procedure is requested by a command from the BS, a contention-free random access procedure can be used or executed. The basic procedure of a contention-free random access procedure is similar to that of a contention-based random access procedure. However, unlike a contention-based random access procedure where the UE randomly selects a preamble from multiple random access preambles, in a contention-free random access procedure, the preamble to be used by the UE (hereinafter referred to as a dedicated random access preamble) is assigned to the UE by the BS. Information about the dedicated random access preamble can be included in an RRC message (e.g., a handover command) or can be provided to the UE via a PDCCH command. When initiating a random access procedure, the UE sends the dedicated random access preamble to the BS. The random access procedure is completed when the UE receives the random access procedure from the BS.

[0214] As described above, the UL license in the RAR is scheduled to the UE's PUSCH transmission. The PUSCH carrying the initial UL transmission based on the UL license in the RAR is also referred to as the Msg3 PUSCH. The contents of the RAR UL license begin with the MSB and end with the LSB, and are given in Table 7.

[0215] [Table 7]

[0216]

[0217] The TPC command is used to determine the transmission power of Msg3 PUSCH and is interpreted, for example, based on Table 8.

[0218] [Table 8]

[0219]

[0220] During contention-free random access, the CSI request field in the RAR UL license indicates whether the UE includes an aperiodic CSI report in the corresponding PUSCH transmission. The subcarrier spacing for Msg3 PUSCH transmission is provided by the RRC parameter. The UE will transmit PRACH and Msg3 PUSCH on the same uplink carrier in the same serving cell. The UL BWP for Msg3 PUSCH transmission is indicated by SIB1 (SystemInformationBlock1).

[0221] Figure 11 The diagram illustrates the two-step RACH process. More specifically, Figure 11 Figure (a) illustrates Contention-Based Random Access (CBRA), and Figure 11 (b) illustrates contention-free random access (CFRA).

[0222] exist Figure 11 In the message, message A (MSGA) includes a preamble and a PUSCH payload. The preamble and PUSCH payload are multiplexed using a time-division multiplexing (TDM) scheme. Message B (MSGB) is a response to message A (MSGA) and can be sent for contention resolution, backoff indication, and / or avoidance indication.

[0223] Technical terms used in this disclosure

[0224] UE: User Equipment

[0225] SSB: Synchronization Signal Block

[0226] MIB: Master Information Block

[0227] RMSI: Residual Minimum System Information

[0228] FR1: Frequency domain with a frequency range of less than or equal to 1.6 GHz (e.g., 450 MHz to 6,000 MHz).

[0229] FR2: Millimeter wave (mmWave) domain, which has a frequency range greater than or equal to 2.24 GHz (e.g., 24,250 MHz to 52,600 MHz).

[0230] BW: Bandwidth

[0231] BWP: Bandwidth section

[0232] RNTI: Temporary Identifier for Radio Networks

[0233] CRC: Cyclic Redundancy Check

[0234] SIB: System Information Block

[0235] SIB1: For NR devices, SIB1 = RMSI (Remaining Minimum System Information). It broadcasts information required for NR UE cell access, etc.

[0236] CORESET (Control Resource Set): The time / frequency resources for the NR UE to attempt candidate PDCCH decoding.

[0237] CORESET#0: (Configured at the MIB) CORESET for the Type 0-PDCCH CSS set of NR devices.

[0238] Type 0-PDCCH CSS set: Search space set, where NR UEs monitor the PDCCH candidate set for DCI formats with CRC scrambled by SI-RNTI.

[0239] MO: PDCCH monitoring timing for Type 0-PDCCH CSS set

[0240] SIB1-R: (Additional) SIB1 for NR devices with reduced capabilities. It may be limited when it is generated using a separate TB from SIB1 and transmitted on a separate PDSCH.

[0241] CORESET#0-R: CORESET#0 for NR devices with reduced capability.

[0242] Type 0-PDCCH-R CSS set: Search space set, where RedCap UE monitors the PDCCH candidate set for DCI formats with CRC scrambled by SI-RNTI.

[0243] MO-R: PDCCH monitoring timing for Type 0-PDCCH CSS set

[0244] Cell-defined SSB (CD-SSB): An SSB that includes RMSI scheduling information among the NR SSBs.

[0245] Non-Cell Defined SSB (Non-CD-SSB): An SSB that has been deployed on the NR synchronization grid but does not include RMSI scheduling information for the corresponding cell used for measurement. However, this SSB may include information notifying the location of the cell defined SSB.

[0246] SCS: Subcarrier Spacing

[0247] SI-RNTI: System Information - Temporary Identifier for Radio Networks

[0248] "Stay": "Stay" is a UE state in which the UE remains in the cell and is ready to initiate a potential dedicated service or receive an ongoing broadcast service.

[0249] TB: Transport Block

[0250] RSA (Standalone Redcap): Only Redcap devices or cells that support services.

[0251] SIB1(-R)-PDSCH: Sending the PDSCH of SIB1(-R)

[0252] SIB1(-R)-DCI: DCI that schedules SIB1(-R)-PDSCH. DCI format 1_0 with cyclic redundancy check (CRC) scrambled by SI-RNTI.

[0253] SIB1(-R)-PDCCH: PDCCH for sending SIB1(-R)-DCI

[0254] FDRA: Frequency Domain Resource Allocation

[0255] TDRA: Time Domain Resource Allocation

[0256] RA: Random Access

[0257] MSGA: Used for preamble and payload transmission in a 2-step RA type random access procedure.

[0258] MSGB: Response to MSGA in the two-step random access procedure. MSGB includes responses to contention resolution, backoff instructions, and backoff instructions.

[0259] RO-N: RACH timing (RO) for normal UE 4-step RACH and 2-step RACH (if configured).

[0260] RO-N1, RO-N2: If a separate RO is configured for a normal UE 2-step RACH, it is divided into RO-N1 (4 steps) and RO-N2 (2 steps).

[0261] RO-R: RACH timing (RO) configured separately from RO-N for RedCap UE 4-step RACH and 2-step RACH (if configured).

[0262] RO-R1, RO-R2: If a separate RO is configured for RedCap UE 2-step RACH, it is divided into RO-R1 (4 steps) and RO-R2 (2 steps).

[0263] PG-R: MsgA-Preamble for RedCap UE

[0264] RAR: Random Access Response

[0265] RAR window: Time window for monitoring RA response

[0266] FH: Frequency Hopping

[0267] In addition to the main 5G use cases (mMTC, eMBB, and URLLC), the importance / interest in mMTC and eMBB or mMTC and URLLC within the use case domains has recently increased. Consequently, there is an increased demand for UEs that effectively support these use cases in terms of device cost, power consumption, and form factor.

[0268] In this disclosure, the UE used for the aforementioned purposes is referred to as a (NR) Reduced Capability UE / device, or simply (NR) RedCap UE / device. Furthermore, unlike RedCap devices, a general NR UE that supports all or one of the major 5G use cases is referred to as a NR (Normal) UE / device or a non-redcap UE / device. A RedCap UE can be a UE that intentionally reduces some of the capabilities of 5G key capabilities (peak data rate, user experience data rate, latency, mobility, connection density, energy efficiency, spectrum efficiency, and regional traffic efficiency) as defined in IMT-2020 in order to achieve all or some of them, such as low device cost / complexity, low power consumption, and small form factor.

[0269] For ease of explanation in this disclosure, the 5G use case domains on mMTC and eMBB or mMTC and URLLC that are the target use cases for RedCap devices are referred to as RedCap use cases.

[0270] For example, RedCap use cases could be as follows.

[0271] [RedCap Use Cases]

[0272] Related industries

[0273] - Sensors and actuators connect to the 5G network and core

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

[0275] - Not only does it require very demanding URLLC services, but it also requires relatively low-end services for small devices with a battery life of several years.

[0276] - The requirements for these services are higher than those for Low Power Wide Area (LPWA) (i.e., LTE-M / NB-IoT), but lower than those for URLCC and eMBB.

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

[0278] Smart City

[0279] - Smart cities encompass data collection and processing to more effectively monitor and control urban resources and provide services to urban residents.

[0280] - In particular, the deployment of surveillance cameras is an important part of smart cities, as well as factories and industries.

[0281] wearable devices

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

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

[0284] Low-power wireless area (LPWA) UEs (e.g., LTE-M, NB-IoT, etc.) cannot support RedCap use cases due to limitations in bit rate and latency. NR UEs can functionally support RedCap use cases, but this support may be ineffective due to limitations in UE manufacturing cost, form factor, and battery life.

[0285] The fact that RedCap UEs, with features such as low cost, low power consumption, and small form factor, support use case areas in 5G networks can reduce the manufacturing and maintenance costs of UEs.

[0286] RedCap use cases have highly diverse requirements in terms of UE complexity, target bit rate, latency, and power consumption. RedCap requirements can be divided into general requirements applicable to all RedCap use cases and use case-specific requirements applicable only to specific use cases.

[0287] For example, some typical general and use case-specific requirements may be as follows.

[0288] [RedCap Requirements]

[0289] General Requirements

[0290] - Equipment Complexity / Cost: Compared to high-end eMBB and URLLC equipment in the Rel-15 / Rel-16 series, the primary motivation for using the new equipment type is to reduce equipment cost and complexity. This is especially true for industrial sensors.

[0291] - Device size: For most use cases, the requirement is that the standard can enable device designs with a compact form factor.

[0292] - Deployment scenario: The system should support all FR1 / FR2 bands for FDD and TDD.

[0293] Use case specific requirements

[0294] Industrial wireless sensors

[0295] Reference bit rate: <2Mbps (potentially heavy UL traffic)

[0296] End-to-end latency: <100ms; ~5-10ms for safety-related sensors.

[0297] Battery: at least several years

[0298] - Communication service availability: 99.99%

[0299] - fixed

[0300] Video surveillance

[0301] - Reference bitrate: <2-4Mbps for budget video; ~7.5-25Mbps for high-end video (UL busy service).

[0302] - Latency: <500ms

[0303] - Reliability: 99%-99.9%.

[0304] wearable devices

[0305] - Reference bitrate: 10-50Mbps in DL and >=5Mbps in UL for smart wearable applications.

[0306] - Peak bit rate: 150Mbps in DL and 50Mbps in UL

[0307] - Battery life: Multiple days (up to 1-2 weeks)

[0308] Examples of illustrative use case-specific requirements for the three typical RedCap use cases are the same as those in Table 9.

[0309] [Table 9]

[0310]

[0311] 1) Safety-related sensors

[0312] 2) Lower complexity compared to normal NR equipment

[0313] RedCap requirements can be met through a combination of various features provided by the UE and BS. Below are examples of features and sub-features supported by the UE / BS for meeting RedCap requirements.

[0314] [Redcap UE Features]

[0315] Reduced complexity features

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

[0317] - UE bandwidth reduced

[0318] - Half-duplex FDD

[0319] - Flexible UE processing time

[0320] - Relaxed UE processing capabilities

[0321] Energy saving

[0322] - Reduce PDCCH monitoring by limiting the number of BD and CCE.

[0323] - Extended DRX for RRC inactivity and / or idle

[0324] - RRM relaxation for fixed equipment

[0325] - Coverage recovery / enhancement

[0326] RedCap use cases can define and support one or more UEs. This disclosure considers both of the following scenarios (Scenario A / Scenario B).

[0327] Scenario A: Supporting RedCap use cases in the case of a single device type

[0328] Scenario B: Supporting RedCap use cases in scenarios with multiple device types

[0329] In Scenario A, the RedCap UE can be a UE that meets all RedCap requirements (i.e., general requirements and use case-specific requirements), and / or a UE that supports all RedCap use cases. In this case, because the UE will meet various requirements simultaneously, there may be factors that increase costs due to the increased complexity of the UE. However, at the same time, cost reduction effects can be expected from mass production based on the expansion of use cases.

[0330] In Scenario B, given the considerable diversity of RedCap use case requirements, a device type can be defined and supported for each RedCap use case. Even in this case, all common requirements can be met collectively. In this example, the corresponding device type defined for each use case is referred to as a RedCap device type. Scenario B includes situations where several use cases that are similar in requirements are grouped within a single device type. These RedCap device types can support some or specific combinations of features previously defined in the RedCap UE characteristics. As mentioned above, when multiple RedCap device types are defined and support RedCap use cases, there are advantages such as the ability to support specific RedCap use cases through RedCap UEs that are optimized for cost, power consumption, etc. For example, IWS use cases can be supported through very small, inexpensive, and power-efficient dedicated UEs.

[0331] It is not necessarily supported or met the RedCap use cases and general or use case-specific requirements mentioned in this disclosure, and factors such as cost / complexity, power consumption, and the form factor or device type of the RedCap device may be considered to determine whether they are supported or met in a compromise manner.

[0332] In this disclosure, reduced capabilities may include the meanings of reduced / lower complexity / lower cost / reduced bandwidth, etc.

[0333] RedCap equipment type classification and reporting methods to BS

[0334] For situations where multiple device types support RedCap use cases (i.e., Case B), the following methods can be considered for classifying RedCap device types. These methods can even be applied to Case A to distinguish RedCap devices from NR UEs.

[0335] To support the operation of RedCap devices that are distinct from NR UEs, RedCap devices may need to report RedCap device type information to the base station. Figure 12 The diagram illustrates a flowchart of the process of reporting device type information to the base station. This reporting process can reuse the UE capability transmission process defined in predefined standards (e.g., 3GPP TS 38.331), as described below. The base station can obtain RedCap device type information through UE capability information reception and can also use UE information obtained when scheduling the corresponding UE.

[0336] For example, the base station / network can request UE capabilities from a UE in the RRC_CONNECTED state (SH102). And / or, the UE can send RedCap device type information to the UE capability information (SH104).

[0337] [Classification Method 1]

[0338] Redcap device types can be categorized based on one of the main requirements. Examples of main requirements that can serve as a basis for classification may include maximum supported data rate (peak bit rate), latency, mobility (stationary / fixed, portable, mobile, etc.), battery life, complexity, coverage, etc. The UE features (combinations) that Redcap device types for each category must or can selectively support can be defined in predefined standards (e.g., 3GPP specifications). This can be to reduce the overhead of individually signaling whether features are supported for each device type. In this disclosure, "defined in a predefined standard" can mean that it is predefined / pre-configured / pre-committed between the UE and the base station.

[0339] The RedCap device type information included in the UE capability information and reported by the UE to the base station / network can be a specific field (e.g., RedCapDeviceType) of the UE-NR-Capability Information Element (IE). For example, when the RedCap device type is classified as RedCap device type 1, 2, ..., the value of the RedCapDeviceType field can be represented by integer values ​​such as 1, 2, ... or a combination of characters and integers such as r1, r2, ... As mentioned above, the UE has the advantage of signaling overhead by including the device type and its associated parameters as a field in the capability information and reporting it.

[0340] For example, RedCap device types can be classified based on the maximum supported data rate, and the UE can report the RedCap device type to the base station based on this classification.

[0341] The maximum data rate supported by an NR UE can be defined / determined as the following equation in a predefined standard (e.g., 3GPP TS38.306).

[0342] Maximum supported data rate

[0343] General

[0344] The maximum DL and UL data rates supported by the UE can be calculated using the bands or combinations of bands supported by the UE. UEs supporting NR (e.g., NR SA, MR-DC) should support the calculated maximum DL and UL data rates as defined below.

[0345] Maximum supported data rate

[0346] For NR, the approximate data rate of a given number of aggregated carriers in a frequency band or combination of frequency bands can be calculated using the following Equation 3.

[0347] [Equation 3]

[0348] Data rate (in Mbps) =

[0349] Where J is the number of aggregated component carriers in a band or band combination.

[0350]

[0351] For the j-th CC, The maximum number of supported layers is given by the higher-layer parameter maxNumberMIMO-LayersPDSCH used for downlink or the higher-layer parameters maxNumberMIMO-LayersCB-PUSCH and maxNumberMIMO-LayersNonCB-PUSCH used for uplink.

[0352] The maximum supported modulation order is given by the higher-layer parameter supportedModulationOrderDL for downlink and the higher-layer parameter supportedModulationOrderUL for uplink.

[0353] It is a scaling factor given by the higher-level parameter scalingFactor, and can take values ​​of 1, 0.8, 0.75, and 0.4.

[0354] It is a parameter set.

[0355] It is the average OFDM symbol duration in the subframe used for parameter set µ, i.e. Assume a normal cyclic prefix.

[0356] It is the bandwidth with parameter set µ. The maximum RB allocation in, where It is the maximum bandwidth supported by the UE in a given band or band combination.

[0357] It is an expense, and takes the following values.

[0358] For the frequency range FR1 of DL, take 0.14.

[0359] For the frequency range FR2 of DL, take 0.18.

[0360] For the frequency range FR1 of UL, take 0.08.

[0361] For the frequency range FR2 of UL, take 0.10.

[0362] For cells operating SUL, only one of the UL or SUL carriers is counted.

[0363] It is possible to calculate the approximate maximum data rate as the maximum approximate data rate calculated for each supported band or band combination using the above equation.

[0364] For single-carrier NR SA operation, the UE should support a data rate for a carrier that is not less than the data rate calculated using the above equation, wherein... and components Not less than 4.

[0365] For example, the value 4 in the above components can correspond to , and .

[0366] For EUTRA in the case of MR-DC, the approximate data rate of a given number of aggregated carriers in a band or combination of bands can be calculated by the following Equation 4.

[0367] [Equation 4]

[0368] Data rate (in Mbps) =

[0369] Where J is the number of EUTRA component carriers aggregated in the MR-DC band combination.

[0370] It is the total maximum number of DL-SCH transport block bits received or the total maximum number of UL-SCH transport block bits transmitted within a 1ms TTI for the j-th CC, such as based on the maximum MIMO layer supported by the UE for the j-th CC, and based on the maximum modulation order for the j-th CC and the number of PRBs based on the bandwidth of the j-th CC according to the indicated UE capabilities, derived from a predefined standard (e.g., 3GPP TS36.213).

[0371] The approximate maximum data rate can be calculated as the maximum approximate data rate calculated for each supported band or band combination using Equation 4 above.

[0372] For MR-DC, the approximate maximum data rate can be calculated as the sum of the approximate maximum data rates from NR and EUTRA.

[0373] In this scenario, the parameters required to calculate the formula for the maximum supported data rate that the NR UE should support can be reported by the UE through a request from a base station in the RRC_CONNECTED state. The parameters are as follows. Higher elements refer to the higher RRC information element (IE) to which the parameters belong.

[0374] FeatureSetDownlink

[0375] - scalingFactor

[0376] FeatureSetDownlinkPerCC

[0377] - maxNumberMIMO-LayersPDSCH

[0378] - Supported ModulationOrderDL

[0379] - Supported BandwidthDL

[0380] - supportedSubCarrierSpacingDL

[0381] FeatureSetUplink

[0382] - scalingFactor

[0383] FeatureSetUplinkPerCC

[0384] - maxNumberMIMO-LayersCB-PUSCH

[0385] - maxNumberMIMO-LayersNonCB-PUSCH

[0386] - supportedModulationOrderUL

[0387] - Supported BandwidthUL

[0388] - supportedSubCarrierSpacingUL

[0389] For RedCap UEs, in methods that classify RedCap device types based on the maximum supported data rate, parameter values ​​for each device type are defined in predefined standards (e.g., 3GPP specifications). The UE can indicate RedCap device type information and parameter information to the base station by setting the value of the RedCapDeviceType field in the UE-NR-Capability IE to a specific value. Compared to the NR UE's approach of including parameters in the UE capability information and sending it to the base station, the RedCap UE can expect reduced signaling overhead by reporting the device type and associated parameters through a single field. The base station can obtain the device type, maximum supported data rate, and the values ​​of the aforementioned parameters through the RedCapDeviceType field and use them for UE scheduling, etc.

[0390] [Classification Method 2]

[0391] Alternatively, RedCap device types can be categorized based on a combination of UR features that should be mandatory or can be selectively supported, rather than on primary requirements. This may be a more appropriate approach when the features that should or can be supported for each use case are clear.

[0392] The combination of UR features predefined for each RedCap device type in a predefined standard (e.g., a 3GPP specification) can be referred to as a feature set. The feature set that each device type must force to support for each of the UR features can be referred to as the mandatory feature set for the corresponding device type or a specified device type.

[0393] In this approach, the definition of RedCap device types may not be specified in predefined standards (e.g., 3GPP specifications), and this may refer to supporting RedCap use cases in separate device types that support different feature sets.

[0394] In the above method, the RedCap UE can report the RedCap device type or use case supported by the RedCap UE to the base station by reporting a predefined set of features. This can be seen as a method that more closely conforms to the fundamental principles of NR to support various use cases through a variety of optional features without distinguishing individual UE categories. The feature set can be replaced by a combination of capability parameters (i.e., a set of capability parameters). The feature set can be a mandatory set of features defined in a predefined standard (e.g., a 3GPP specification) according to the RedCap device type.

[0395] For the operations described above, candidate feature sets (i.e., feature pools) for RedCap devices (types) can be defined or configured in predefined standards (e.g., 3GPP specifications), and RedCap devices can report mandatory feature sets defined for each type based on the RedCap device type to the base station. In addition to the mandatory feature sets, UEs can additionally report optional feature sets to the base station. UEs can perform additional or more optimized operations for specific use cases by separately selecting and reporting optional feature sets. For example, for device types targeting surveillance camera use cases, when wired-powered UEs and battery-powered UEs coexist, the mandatory feature set does not include power-saving features, and optional features can be specified or included. Therefore, when a feature is selectively supported based on the detailed device type, the UE can report that feature to the base station.

[0396] The base station can determine whether a feature is supported based on the presence of the corresponding parameter in the feature set reported by the RedCap UE, and reflect this when scheduling the corresponding UE.

[0397] [Classification Method 3]

[0398] Alternatively, RedCap device types can be classified based on a combination of capability parameters. This combination of capability parameters for classifying RedCap device types can be parameters that determine RedCap requirements. Examples of capability parameters for determining RedCap device types can include determining the bandwidth, modulation order, and number of MIMO layers supported by the UE to support the maximum data rate requirement. The parameter values ​​can be a list of actually supported values ​​or the maximum value among the supported values.

[0399] For example, the capability parameters for determining the RedCap device type can be as follows.

[0400] - Supported bandwidth (NRB): (Maximum) UE channel bandwidth or (Maximum) UE transmission bandwidth; in RBs

[0401] - Supported modulation order (Qm): Qm=2 for QPSK; Qm=4 for 16 QAM; Qm=6 for 64 QAM, etc.

[0402] - Number of MIMO layers supported (NL): can be replaced with the number of antennas (Na)

[0403] The combination of capability parameters that determines a RedCap device type can be referred to as 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 following example defines M device types in ascending order of the maximum supported data rates.

[0404] RedCap device type classification based on capability parameter set values ​​(example):

[0405] - Device Type 1: {NL, NRB, Qm}={1, 25, 2}

[0406] - Equipment type 2: {NL, NRB, Qm}={1, 25, 4}, or {1, 52, 2}

[0407] - Equipment type 3: {NL, NRB, Qm}={1, 52, 4}, or {1, 106, 2}

[0408] - Equipment type 4: {NL, NRB, Qm}={1, 106, 4}, or {2, 106, 2}

[0409] - Device type 5: {NL, NRB, Qm}={1, 106, 6}

[0410] - Device Type 6: {NL, NRB, Qm}={2, 106, 4}

[0411] - Equipment type 7: {NL, NRB, Qm}={2, 106, 6}

[0412] - …

[0413] - Device type M: {NL, NRB, Qm} = {X, Y, Z}

[0414] For example, for NR frequency range 1 (FR1) (i.e., a band of 6 GHz or less), the NRB value can be one of the values ​​defined in Table 10 (the maximum configurable number of RBs per UE channel bandwidth). The example above is based on a subcarrier spacing (SCS) of 15 kHz. If the RedCap device supports SCS=30 kHz, and the cell the RedCap device wants to access uses SCS=30 kHz for data transmission, then referring to Table 10, the NRB value based on SCS=15 kHz in the example above can be replaced with the value corresponding to SCS=30 kHz.

[0415] Table 10 shows the maximum transmission bandwidth configuration N for each subcarrier spacing (SCS) at NR FR1. RB .

[0416] [Table 10]

[0417]

[0418] In the device type classification example, device types 2 / 3 / 4 are cases where a device type is defined using multiple capability set values. As mentioned above, when classifying device types based on the maximum supported data rate, the multiple capability parameter set values ​​defining a device type can refer to combinations that support the same or similar maximum supported data rates.

[0419] The supported device types for each use case, using the device types defined in the examples above, can be defined as follows. Based on the supported device types, the base station can restrict cell access or implement subscription-based blocking.

[0420] Supported device types for each use case (example)

[0421] - IWS: Device Type 1, 2

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

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

[0424] To avoid increased costs due to excessive market segmentation based on device type, the number of device types M can be limited. For example, when M=1, RedCap UE is not classified into multiple device types and can support all target use cases within a single device type.

[0425] As another example, when M=3, the device type classification and supported device types for each use case can be defined as follows.

[0426] Device type classification based on capability set values ​​(e.g., when M=3):

[0427] - Equipment type 1: {NL, NRB, Qm}={1, 25, 2} (or {1, 25, 4} or {1, 52, 2})

[0428] - Equipment Type 2: {NL, NRB, Qm}={1, 52, 4} or {1, 106, 2}

[0429] - Device Type 3: {NL, NRB, Qm}={2, 106, 6}

[0430] Supported device types for each use case (e.g., when M=3)

[0431] - IWS: Device Type 1

[0432] - Video surveillance: Device type 3

[0433] - Wearable devices: Device type: Device type 7

[0434] The maximum bandwidth of the UE (i.e., the bandwidth capability of the RedCap UE) can be determined as the minimum bandwidth required to meet the bit rate in the target use case. Reducing the maximum bandwidth of the UE can reduce the cost of RF components and / or baseband processing, and is expected to have a power consumption reduction effect. In this paper, the required bit rate can refer to the peak rate or the maximum supported data rate, rather than the average bit rate and reference bit rate, considering that the device manufacturing cost is determined by the peak rate or the maximum supported data rate.

[0435] When determining the maximum bandwidth to support the required bit rate, specific values ​​can be assumed for other parameters that determine the required bit rate, such as the number of antennas (NL), modulation order (Qm), etc. For example, in the example above, a peak rate of approximately ~28 MHz can be supported for device type 3. In this example, when assuming {NL=1, Qm=2}, the required maximum bandwidth could be 20 MHz (106 RBs), and when assuming {NL=1, Qm=4}, the required maximum bandwidth could be 10 MHz (52 RBs). Alternatively, when assuming {NL=2, Qm=4}, the required maximum bandwidth could be 5 MHz (25 RBs).

[0436] - Equipment type 3: {NL, NRB, Qm}={1, 52, 4} or {1, 106, 2}

[0437] Within the maximum UE bandwidth of a RedCap UE, RRC signaling and other network configurations can be used to allocate and send / receive transmission bandwidth.

[0438] 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.

[0439] For example, at FR1, the minimum bandwidth of the UE can be 5MHz for an NR SSB with SCS=15kHz and 10MHz for an NR SSB with SCS=30kHz.

[0440] As another example, at FR2, the minimum UE bandwidth can be 40MHz for an NR SSB with SCS=120kHz and 80MHz for an NR SSB with SCS=240kHz.

[0441] This can enable low power consumption while simultaneously supporting access via NR SSB on NR cells by supporting services with small required bit rates with minimal bandwidth.

[0442] [Classification Method 4]

[0443] Given that the bandwidth capability of a RedCap UE is determined by the required bit rate for the corresponding use case, RedCap device types can be classified based on UE bandwidth capability. For example, the bandwidth capability determining a RedCap device type can be expressed in units of RBs (maximum) UE channel bandwidth or (maximum) UE transmission bandwidth (i.e., supported bandwidth (NRB)). Alternatively, the bandwidth capability can be the minimum UE channel bandwidth or the minimum UE transmission bandwidth. More specifically, the following classifications are possible.

[0444] - Classification Method 4-1) RedCap device types are classified according to maximum bandwidth and used by configuring actual data transmission / reception bandwidth (<= maximum bandwidth).

[0445] - Classification Method 4-2) RedCap device types are classified according to minimum bandwidth and used by configuring actual data transmission / reception bandwidth (>= minimum bandwidth).

[0446] - Classification Method 4-3) One or more supported bandwidths (sets) are defined for each device type and used by configuring the actual data transmission / reception bandwidth within the corresponding bandwidth (set).

[0447] For classification method 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 for a 15 kHz SSB).

[0448] Initial access and UL frequency hopping support methods for RedCap UEs

[0449] In new radio (NR) cells supporting RedCap user equipment (UEs), it may be preferable in terms of resource efficiency to have normal UEs and RedCap UEs share as many resources as possible. That is, in cells where normal UEs and RedCap UEs coexist or are capable of coexisting, it may be preferable in terms of resource efficiency to have normal UEs and RedCap UEs share as many resources as possible. If the available / scheduling resources for normal UEs and the available / scheduling resources for RedCap UEs are completely separated from each other, there may be problems with reduced resource utilization and limited scheduling flexibility from the base station's perspective.

[0450] However, in the following cases (1) to (4), the existing technology may not be able to effectively support resource sharing between normal UEs and RedCap UEs during random access for cell access.

[0451] (1) If the RedCap UE needs to repeat (additionally) due to the difference in coverage performance between the NRUE and the RedCap UE at the Msg 2 (e.g., Random Access Response (RAR)) step, Msg 4, or Msg B step,

[0452] (2) If the impact on traditional NR UEs is taken into account, the initial uplink (UL) bandwidth portion (BWP) cannot be configured within the maximum UE bandwidth of the RedCap UE.

[0453] (3) If the impact on NR UEs during random access is unavoidable due to factors such as the relaxation of UE processing time for RedCap UEs, then the impact on NR UEs is unavoidable.

[0454] (4) For the reasons stated in (1) / (2) / (3) above, configure and manage a separate initial UL BWP for RedCap UE.

[0455] For example, in (1) above, the repetition in the random access channel (RACH) process of the RedCap UE can be applied equivalently to at least one of Msgs 1-4 / Msgs AB, or applied separately in the independent configuration of each message.

[0456] This disclosure proposes a method for initial access and UL frequency hopping support for RedCap UEs in NR cells where normal UEs and RedCap UEs coexist.

[0457] More specifically, this disclosure provides a method for receiving a random access response from a RedCap UE (hereinafter, the first embodiment), a method for sending a Msg3 PUSCH from a RedCap UE (hereinafter, the second embodiment), and a method for sending a Msg4 ACK / NACK PUCCH from a RedCap UE (hereinafter, the third embodiment).

[0458] The embodiments described below in this disclosure are distinguished merely for ease of explanation. Therefore, it will be apparent that portions of the methods and / or configurations of any embodiment can be replaced or combined with portions of the methods and / or configurations of another embodiment.

[0459] The time slots, subframes, frames, etc., described in the embodiments of this disclosure can be examples of predetermined time units used in wireless communication systems. That is, when the methods described in this disclosure are applied, the time unit can be replaced by other time units applied to other wireless communication systems.

[0460] The above-mentioned content (3GPP system, frame structure, NR system, etc.) can be combined with and / or supplemented with the methods proposed in this disclosure as described below to clarify the technical features of the methods proposed in this disclosure.

[0461] In this disclosure, “()” can be interpreted as both when the content within the parentheses is excluded and when the content is included within the parentheses. And / or, in this disclosure, “()” can refer to a group of elements (or content) within the parentheses, or it can refer to an abbreviation / full name of a term preceding the parentheses, and / or it can refer to the written content preceding the parentheses in English.

[0462] In this disclosure, “ / ” can be interpreted as both when including all content separated by “ / ” (and) and when including only a portion (or) of the separated content.

[0463] First Embodiment

[0464] This embodiment describes a method for receiving a Random Access Response (RAR) from a RedCap UE.

[0465] Given the complexity of UEs, RedCap UEs can support limited UE bandwidth. If the Random Access Channel (RACH) timing (RO) is configured in existing methods for NR UEs, there may be cases where the (initial) UL bandwidth of the NR UE does not include all frequency domains of the RO. In this case, the RedCap UE may need to perform a frequency retuning operation after sending a Random Access (RA) preamble during the RA process for initial access and receive a Random Access Response (RAR). Furthermore, UEs operating in the FDD band as half-duplex frequency division duplex (FDD) during initial access may also need to receive a RAR after performing frequency retuning.

[0466] In this scenario, because DL reception, including Physical Downlink Control Channel (PDCCH) monitoring, may not be permitted during uplink (UL) to downlink (DL) or transmit (Tx) to receive (Rx) handovers (accompanied by frequency retuning), the RAR window for a RedCap UE may start X symbols or X' µs later than that of a normal UE. For example, X or X' may be a value greater than or equal to the transition time (NRx-Tx or NTx-Rx) and / or frequency retuning time defined in a predefined standard (e.g., 3GPP TS 38.211). Alternatively, X or X' may be a newly defined value in a predefined standard (e.g., a 3GPP specification) taking into account the characteristics of the RedCap UE, or a value configured by the base station via a higher layer of system information.

[0467] For example, the existing RAR window for NR UEs is specified in predefined standards (e.g., 3GPP TS 38.213, 3GPP TS 38.321) as follows.

[0468] Regarding the Type 1 random access procedure, in response to a Physical Random Access Channel (PRACH) transmission, the UE may attempt to detect DCI format 1_0 with a Cyclic Redundancy Check (CRC) scrambled by the corresponding Random Access-Radio Network Temporary Identifier (RA-RNTI) during a window controlled by a higher layer. The window begins at the first symbol of the earliest control resource set (CORESET) of the PDCCH for a Type 1-PDCCH CSS set, after the last symbol of the PRACH timing corresponding to the PRACH transmission. In this document, the symbol duration corresponds to the subcarrier spacing (SCS) for the Type 1-PDCCH CSS set. Based on the SCS for the Type 1-PDCCH CSS set, the window length, in units of slots, can be provided by ra-ResponseWindow.

[0469] And / or, regarding random access response reception, once the random access preamble is sent and regardless of any potential measurement gaps, the MAC entity may need to perform the following actions.

[0470] If a contention-free random access preamble for a beam failure recovery request is sent by the MAC entity, the MAC entity may begin the ra-ResponseWindow configured in BeamFailureRecoveryConfig at the first PDCCH timing specified in a predefined standard (e.g., 3GPP TS 38.213) from the end of the random access preamble transmission. While the ra-ResponseWindow is running, the MAC entity can monitor PDCCH transmissions on the search space indicated by the recoverySearchSpaceId of the SpCell identified by the C-RNTI.

[0471] Otherwise, the MAC entity may begin the ra-ResponseWindow configured in RACH-ConfigCommon at the first PDCCH timing specified in a predefined standard (e.g., 3GPP TS38.213) after the end of the random access preamble transmission. While the ra-ResponseWindow is running, the MAC entity can monitor the PDCCH of the SpCell for random access responses identified by RA-RNTI.

[0472] To define the RAR window of the RedCap UE in the above method (i.e., the predefined standard), after the RA preamble transmission, the RedCap UE can monitor the first symbol of the earliest control resource set (CORESET) starting at least X symbols or X' µs after the last symbol of the RO used for the RA preamble transmission, using DCI format 1_0 with cyclic redundancy check (CRC) scrambled by the random access-radio network temporary identifier (RA-RNTI). And / or, the duration of monitoring the physical downlink control channel (PDCCH) for RAR reception (i.e., the start point of the RAR window or the start time of the RAR window counter) can 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.

[0473] The values ​​of X or X' are the same as described above. Alternatively, the value of X in symbols may be a value that is one greater than the number of minimum symbol durations, which is greater than the transition time and / or the frequency retuning time.

[0474] A separate RAR window for RedCap UEs can be used for the RAR window of RedCap UEs (in addition to the RAR window used for normal UEs). The size of the RAR window can be determined by the configuration value of the RAR window counter. And / or, the size of the separate RAR window for RedCap UEs can be the same as the existing RAR window (without separate size configuration), or it can be configured separately. If they are the same size, the RAR window of RedCap UEs can be an interleaved form of related technology RAR windows.

[0475] And / or, the base station does not define a separate RAR window for the RedCap UE, and may allow the RedCap UE to use the same RAR window as the normal UE or share the RAR window with the normal UE. In this case, the base station implementation can ensure that the base station meets the aforementioned transition time and / or frequency retuning time conditions.

[0476] Second Embodiment

[0477] This embodiment describes a method for sending Msg3 PUSCH to a RedCap UE.

[0478] Msg3 Physical Uplink Shared Channel (PUSCH) transmissions during the RA process for initial access to an NR UE can be scheduled via RAR UL license. The RAR UL license field configuration, Msg3 PUSCH Frequency Domain Resource Allocation (FDRA), and frequency hopping (FH) information configured according to the RAR UL license field are specified in predefined standards (e.g., 3GPP TS 38.213) as follows.

[0479] Regarding the Type-1 random access procedure, the RAR UL license schedules the PUSCH transmission from the UE. Table 11 shows the contents of the RAR UL license, which begins with the most significant bit (MSB) and ends with the least significant bit (LSB).

[0480] If the frequency hopping flag is 0, the UE sends a PUSCH without frequency hopping; otherwise, the UE sends a PUSCH with frequency hopping.

[0481] The UE determines the MCS for PUSCH transmission from the first sixteen indices of the available MCS index table used for PUSCH.

[0482] The TPC command value is used to set the power of PUSCH transmission, as explained in Table 12.

[0483] Reserve a field for CSI requests.

[0484] The ChannelAccess-CPext field indicates the channel access type and cyclic prefix (CP) extension used for operations utilizing shared spectrum channel access.

[0485] Table 11 shows the size of the random access response license content field.

[0486] [Table 11]

[0487]

[0488] Table 12 shows the TPC commands used for PUSCH. .

[0489] [Table 12]

[0490]

[0491] Regarding PUSCHs scheduled by RAR UL license, the active ULBWP for PUSCH transmissions scheduled by RAR UL license is indicated by a higher layer.

[0492] If useInterlace-PUCCH-PUSCH is not provided by BWP-UplinkCommon and BWP-UplinkDedicated, in order to determine the frequency domain resource allocation for PUSCH transmission within the active UL BWP,

[0493] - If the active UL BWP and the initial UL BWP have the same SCS and the same CP length, and the active UL BWP includes all the RBs of the initial UL BWP, or the active UL BWP is the initial UL BWP, then the initial UL BWP is used.

[0494] - Otherwise, the RB numbering starts from the first RB of the active UL BWP, and the maximum number of RBs used for frequency domain resource allocation is equal to the number of RBs in the initial UL BWP.

[0495] Frequency domain resource allocation is based on uplink resource allocation type 1. For The initial UL BWP size of each RB is determined by the frequency domain resource allocation field processed by the UE as follows.

[0496] - if Or for operations that utilize shared spectrum channels for access, if Then the UE should truncate the frequency domain resource allocation field to its... The least significant bit is used to interpret the truncated frequency resource allocation field as the frequency resource allocation field in DCI format 0_0.

[0497] Otherwise, the UE should insert The most significant bit, or for operations using shared spectrum channel access, will be Each bit is followed by a value set to "0". The most significant bit is inserted into the frequency domain resource allocation field.

[0498] If the frequency hopping flag is set to "0"... =0, and if the frequency hopping flag is set to "1", then it is provided in Table 13. The UE should interpret the extended frequency resource allocation field as the frequency resource allocation field in DCI format 0_0.

[0499] For PUSCH transmissions with frequency hopping scheduled by RAR UL license or for Msg3 PUSCH retransmissions, the frequency offset for the second hop is given in Table 13.

[0500] Table 13 shows the frequency offset of the second hop for PUSCH transmissions or Msg3 PUSCH retransmissions with frequency hopping scheduled by RAR UL license.

[0501] [Table 13]

[0502]

[0503] As specified above (i.e., the predefined standard), in the RA process used for initial access to related technologies, the Msg3 FDRA and frequency hopping (FH) can be determined based on the initial UL bandwidth. The initial UL bandwidth can refer to the bandwidth of the initial UL BWP.

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

[0505] In the following methods, for the reasons described above, if a separate initial UL BWP is configured and managed for the RedCap UE, the RedCap UE bandwidth may include the meaning of a separate initial UL BWP for the RedCap UE or the bandwidth of a separate initial UL BWP. And / or, the bandwidth of a separate initial UL BWP for the RedCap UE may be limited to the RedCap UE bandwidth or less. For the reasons described 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 should set the initial UL bandwidth for the normal UE to be greater than the RedCap UE bandwidth" may include the meaning of "setting / has been set for a separate initial UL BWP for RedCap."

[0506] The methods described below in this disclosure are distinguished only for ease of explanation. Therefore, it will be apparent that any configuration of one method can be replaced or combined with a configuration of another method.

[0507] (Method 2-1)

[0508] This method is used to perform FH shutdown when the initial UL bandwidth is greater than the RedCap UE bandwidth.

[0509] When a base station needs to set the initial UL bandwidth for a normal UE to be greater than the RedCap UE bandwidth, the base station can perform Msg3 PUSCH FH shutdown and scheduling so that the first frequency hopping indicated by the FDRA permitted by the RAR UL falls within the RedCap UE bandwidth. Therefore, the base station can receive all PUSCH transmissions from both the normal UE and the RedCap UE. For example, in this disclosure, the initial UL bandwidth may refer to the initial uplink bandwidth portion (initial UL BWP).

[0510] And / or, for this purpose, the base station may set the value of the RAR UL-permitted FH flag to 0. And / or, the RAR UL-permitted FH flag may be configured separately and used to enable / disable FH for the RedCap UE. And / or, when the initial UL bandwidth is greater than the RedCap UE bandwidth, the UE may assume FH is off (or the FH flag value is 0) and transmit Msg3 PUSCH in the above method via the frequency domain indicated by the RAR UL-permitted FDRA.

[0511] Figure 13 The diagram illustrates a method for a base station to schedule Msg3 PUSCH within the RedCap UE bandwidth when the initial UL bandwidth is greater than the RedCap UE bandwidth, without FH (Free Handling). (Reference) Figure 13 RedCap UE does not perform frequency hopping and can send PUSCH via resources included in the RedCap UE bandwidth.

[0512] (Method 2-2)

[0513] This method is a way of interpreting RAR UL-licensed FDRA and / or FH marks differently.

[0514] When a base station needs to set the initial UL bandwidth for a normal UE to be greater than the bandwidth for a RedCap UE, the RedCap UE may apply / interpret the PUSCH scheduling results indicated by the RAR UL-permitted FDRA and / or FH flags or the field values ​​of the FDRA and / or FH flags differently from the normal UE. If the initial UL bandwidth is greater than the RedCap UE bandwidth, the PUSCH scheduling results indicated by the RAR UL-permitted FDRA and / or FH flags may have the following characteristics.

[0515] [Case 1] In this case, the first frequency hopping falls within the RedCap UE bandwidth, and the second frequency hopping falls outside the RedCap UE bandwidth.

[0516] [Scenario 2] In this scenario, the first frequency hopping occurs outside the RedCap UE bandwidth, while the second frequency hopping occurs within the RedCap UE bandwidth.

[0517] [Scenario 3] Both the first and second frequency hopping fall within the RedCap UE bandwidth.

[0518] [Scenario 4] Both the first and second frequency hopping fall outside the RedCap UE bandwidth.

[0519] In cases 1 and 2, if FH is enabled for Msg3 PUSCH and only one of the two frequency hopping hops falls within the RedCap UE bandwidth, the base station can send the first and second hops on the frequency resources of the hopping frequency that fall within the RedCap UE bandwidth without FH.

[0520] Figure 14 The diagram illustrates method 2-2 when the initial UL bandwidth is greater than the RedCap UE bandwidth in case 1.

[0521] refer to Figure 14 When the bandwidth of the initial UL bandwidth portion (BWP) is greater than the RedCap UE bandwidth in case 1, an FDRA instruction authorized by RAR UL or Msg3PUSCH in the frequency domain of the first hop frequency 1410 (or the first hop 1410 and the second hop 1420) can be transmitted without FH.

[0522] Figure 15 The diagram illustrates method 2-2 when the initial UL bandwidth is greater than the RedCap UE bandwidth in case 2.

[0523] refer to Figure 15 When the bandwidth of the initial UL BWP is greater than the RedCap UE bandwidth in Case 2, Msg3 PUSCH (or the first hop 1510 and the second hop 1520) can be sent in the frequency domain of the second hop 1520, which falls within the RedCap UE bandwidth, without FH.

[0524] Figure 16 The illustration shows an example of method 2-2 in case 3 when the initial UL bandwidth is greater than the RedCap UE bandwidth.

[0525] refer to Figure 16 In case 3, since both the first hop 1610 and the second hop 1620 fall within the RedCap UE bandwidth, Msg3 PUSCH can be sent in the first hop 1610 and the second hop 1620 (with FH enabled) as indicated by the FDRA and FH flags permitted by RAR UL.

[0526] In scenario 4, Msg3 PUSCH can be transmitted in the first hop (or second hop) without FH (Frequency Handling). In this case, since the first hop (or second hop) is when the RedCap UE does not fall within the initial UL bandwidth received via system information, the RedCap UE can perform Msg3 PUSCH transmission after frequency retuning. For example, the system information could be System Information Block 1 (SIB1). And / or, the RedCap UE can treat this situation as the corresponding cell blocking or disallowing access for the RedCap UE, and continue the cell search process for other accessible cells.

[0527] And / or, the base station may disable the RedCap UE such that part or all of the Msg3 PUSCH indicated by the RAR UL-permitted FDRA and / or FH flag values ​​does not fall within the RedCap UE bandwidth or the initial UL bandwidth of the RedCap UE. Alternatively, the base station may disable the RedCap UE such that scheduling the Msg3PUSCH indicated by the RAR UL-permitted FDRA and / or FH flag values ​​results in one of Case 1, Case 2, or Case 4.

[0528] And / or, the RedCap UE can interpret the Msg3 PUSCH scheduling information based on the RedCap initial UL bandwidth. The RedCap UE can apply modulo operations based on the RedCap UE's (individual) initial UL bandwidth (for hops falling outside the initial UL bandwidth) to determine the final hop. And / or, the base station can configure the RedCap initial UL bandwidth, i.e., the base, specifically via system information (e.g., SIB1). Otherwise, the RedCap UE's initial UL bandwidth information can be sent to the base station in advance during the Msg1 step.

[0529] And / or, for the convenience of modulo operations, the initial UL bandwidth for a normal UE can be limited to N * the initial UL bandwidth for a RedCap UE (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). In this document, initial_UL_bandwidth refers to the bandwidth of the initial UL BWP for a normal UE and can be expressed in resource blocks (RBs). Figure 17 The illustration shows an example when N=2. Figure 17 The diagram illustrates method 2-2 when the initial UL bandwidth is greater than the RedCap UE bandwidth in case 1. That is, Figure 17 The illustration shows an example of applying modular arithmetic in case 1.

[0530] refer to Figure 17 The initial UL BWP is twice the initial UL bandwidth (or RedCap UE bandwidth) of the RedCap UE (N=2). The RedCap UE can apply modulo operation to determine the final second hop 1730 based on the RedCap UE's initial UL bandwidth (or RedCap UE bandwidth) since the second hop 1720 falls outside the RedCap UE's initial UL bandwidth (or RedCap UE bandwidth). The RedCap UE can send PUSCH in both the first hop 1710 and the final second hop 1730.

[0531] And / or, Figure 17 The example illustrates that performing a modulo operation based on the initial RedCap UE UL bandwidth may result in no frequency diversity gain being achieved. To overcome this drawback, a method of deploying hops at symmetrical locations based on the boundaries of the initial RedCap UL bandwidth, rather than simple modulo operations, can be considered.

[0532] Figure 18 The diagram illustrates method 2-2 when the initial UL bandwidth is greater than the RedCap UE bandwidth in case 1. That is, Figure 18 An example of applying mirroring in case 1 is shown.

[0533] refer to Figure 18 If the second hop 1820 falls outside the RedCap UE initial bandwidth (or RedCap UE bandwidth), the second hop 1820 can be mirrored based on the upper boundary of the RedCap initial UL bandwidth. The RedCap UE can send PUSCH in the first hop 1810 and the mirrored second hop 1830.

[0534] and Figure 17 Compared to the example, Figure 18 The mirroring method can predict frequency diversity gain.

[0535] And / or, when the RedCap UE applies the frequency offset to the FDRA value of the RAR UL license and transmits it, Msg3 PUSCH can be transmitted in a frequency domain distinct from that of the normal UE. This method has the advantage of being easier to detect in the base station compared to some frequency hopping overlap methods. And / or, when FH is indicated to be enabled in the RAR UL license, the frequency offset value of the second frequency hopping can be interpreted differently from the prior art, or an additional frequency offset can be applied to the prior art frequency offset value of the second hop. In the former case, the RedCap UE can apply a scaling factor (e.g., redcap_UE_initial_UL_bandwidth / normal_UE_initial_UL_bandwidth) multiplied by the second hop location value calculated based on a predefined standard (e.g., Table 13), or the UE bandwidth of the RedCap UE or the initial UL bandwidth of the RedCap UE instead of the initial UL bandwidth of the normal UE can be applied to determine the frequency location of the second hop.

[0536] For methods 2-1 and 2-2, the RedCap UE bandwidth can be replaced by the RO bandwidth configured for initial access by the RedCap UE. That is, based on the RO bandwidth, it can be determined whether FH is disabled, whether FH can be performed, or whether FDRA can be interpreted. In this example, the RO can be configured separately for the RedCap UE, or it can refer to the RO configured for the NR UE without separate configuration. In this case, the RedCap UE can assume the RO bandwidth as the initial ULBWP of the RedCap UE and operate accordingly.

[0537] (Method 2-3)

[0538] This method identifies RedCap UEs via Msg3 PUSCH transmission.

[0539] Using the method described above, the Msg3 PUSCH for normal UEs and RedCap UEs are time-domain / frequency-domain distinguishable resources, but can be transmitted with different FH patterns. In this example, the base station can identify the UE (type) (e.g., whether it is a normal UE or a RedCap UE) by performing blind decoding (BD) (blind detection) on the distinguished Msg3 PUSCH time / frequency transmission resources or FH patterns. When the early UE ID is not supported in Msg1, this method can be used to distinguish it from a normal UE in the Msg3 step. And / or, this method can be used to provide additional UE (type) information and the early UE ID in Msg1.

[0540] For example, additional UE (type) information could be about the number of Rx antenna branches (or ports), or it could indicate whether specific features of a RedCap UE are supported. And / or, this method can be applied to (additional) UE identification even when the normal UE and the initial UL bandwidth size are the same. The differentiation of Msg3 PUSCH resources is not limited to the frequency domain. For example, the TDRA value indicated in the RAR UL license can be interpreted differently (e.g., with the application of additional offsets) or in time-division multiplexing (TDM) form to differentiate and transmit Msg3 PUSCH for normal UEs and RedCap UEs.

[0541] (Methods 2-4)

[0542] This method is used to retransmit Msg3 PUSCH.

[0543] After the RedCap UE transmits the Msg3 PUSCH using one of the methods described above, the base station can instruct the RedCap UE to retransmit the Msg3 PUSCH. This retransmission can be indicated via DCI format 0_0 scrambled with Temporary Cell (TC)-RNTI CRC. When a retransmission via DCI is indicated, the information for the Msg3 PUSCH retransmission, such as FDRA / Time Domain Resource Allocation (TDRA) and FH, can follow the instructions of the Msg3 retransmission DCI. When the initial UL bandwidth is greater than the RedCap UE bandwidth, the interpretation / operation of FDRA / TDRA and / or FH can be performed using the methods described above in the RAR UL license.

[0544] When a RedCap UE fails in the initial transmission of Msg3 and receives a retransmission instruction, the RedCap UE can use resources that are distinct from those of a normal UE in a different manner than in the initial transmission. For example, when a RedCap UE distinguishes frequency resources in FDRA, FH patterns, etc., from those of a normal UE and transmits them in the initial transmission, the RedCap UE receiving the retransmission instruction can transmit Msg3PUSCH by applying a time offset to the TDRA value or by using resources in the TDM scheme that are distinct from those of a normal UE.

[0545] Third Embodiment

[0546] This embodiment describes a method for sending a Msg4 ACK / NACK PUCCH to a RedCap UE.

[0547] The method for sending a PUCCH before receiving a dedicated PUCCH resource configuration is specified in a predefined standard (e.g., 3GPP TS38.213) as follows.

[0548] Regarding PUCCH resource sets, if the UE does not have a dedicated PUCCH resource configuration provided by PUCCH-ResourceSet in PUCCH-Config, then the PUCCH resource set is provided by pucch-ResourceCommon through the index of the row in Table 14, for use in... HARQ-ACK information is transmitted on the PUCCH in the initial UL BWP of each PRB.

[0549] The PUCCH resource set includes sixteen resources, each corresponding to the PUCCH format, first symbol, duration, and PRB offset. And a cyclic shift index set used for PUCCH transmission.

[0550] If `useInterlacePUCCH-PUSCH` is not provided in BWP-UplinkCommon, the UE uses frequency hopping to transmit the PUCCH. Otherwise, the UE transmits the PUCCH without frequency hopping.

[0551] The orthogonal overlay code with index 0 was used for the PUCCH resource with PUCCH format 1 in Table 14.

[0552] The UE uses the same spatial domain transmission filter as the PUSCH transmission scheduled by the RAR UL license to transmit PUCCH.

[0553] If the UE is not provided with a pdsch-HARQ-ACK-Codebook, the UE generates at most one HARQ-ACK information bit.

[0554] If the UE provides HARQ-ACK information in the PUCCH transmission in response to the detection of a scheduled PDSCH reception or a semi-persistent scheduling (SPS) PDSCH release in DCI format, then the UE will have an index. The PUCCH resource has been determined as ,in, It is the number of CCEs in the CORESET received by the PDCCH with DCI format. It is the index of the first CCE used for PDCCH reception, and It is the value of the PUCCH resource indicator field in the DCI format.

[0555] if Furthermore, the UE is provided with PUCCH resources through pucch-ResourceCommon, and useInterlacePUCCH-PUSCH-r16 is not provided in BWP-UplinkCommon:

[0556] - The UE can determine the PRB index of the PUCCH transmission in the first hop as And the PRB index of the PUCCH transmission in the second hop is determined as ,in It is the total number of initial circular shift indices in the initial circular shift index set.

[0557] - The UE determines the initial cyclic shift index in the initial cyclic shift index set as: .

[0558] if Furthermore, the UE is provided with PUCCH resources through pucch-ResourceCommon, and is not provided with useInterlacePUCCH-PUSCH in BWP-UplinkCommon.

[0559] - The UE determines the PRB index of the PUCCH transmission in the first hop as And determine the PRB index of the PUCCH transmission in the second hop as .

[0560] - The UE determines the initial cyclic shift index in the initial cyclic shift index set as: .

[0561] Table 14 shows the PUCCH resource set before the dedicated PUCCH resource configuration.

[0562] [Table 14]

[0563]

[0564] As specified in the predefined standard, PUCCH transmissions prior to dedicated PUCCH resource configuration are configured to always perform FH based on the initial UL bandwidth. If the initial UL bandwidth is greater than the RedCap UE bandwidth, the FH issue can be applied in the same manner as described in Msg3 PUSCH. That is, at least one of methods 2-1 to 2-4 of the second embodiment can be applied to PUCCH transmissions.

[0565] For example, by replacing Msg3 PUSCH with PUCCH and interpreting it, the proposed method for PUCCH in the above case can be applied to the method proposed in Msg3 PUSCH. That is, unlike normal UEs in related technologies, if the bandwidth of the initial UL BWP is greater than the RedCap UE bandwidth, PUCCH FH disabling can be supported for RedCap UEs. When PUCCH FH is disabled, the PUCCH transmission frequency resources can be determined using the same principle / method as PUSCH to determine the first (or second) frequency hopping (PRB index) for PUCCH transmission for normal UEs. In other words, if the separate initial UL BWP for RedCap is configured to perform random access, it refers to the bandwidth of the initial UL BWP used to determine the PUCCH transmission frequency resources. It can be replaced by the bandwidth of the initial UL BWP of a normal UE or the bandwidth of the initial UL BWP of a separately configured RedCap UE.

[0566] In related technologies, user multiplexing via time-domain orthogonal coverage codes (OCCs) is not supported during PUCCH transmissions in the initial access process. To ensure additional Physical Uplink Control Channel (PUCCH) transmission resources and the introduction of RedCap, time-domain OCC can be supported for PUCCH transmissions via dedicated PUCCH resources. In this example, the user multiplexing capability by time-domain OCC can be determined by the coverage code's extension factor NSF. If user multiplexing via time-domain OCC is supported during PUCCH transmissions in the initial access process, NSF may need to be considered in addition to the method for determining PUCCH transmission resources. For example, NSF can be applied in the method for determining the first (or second) frequency hopping (PRB index) used for PUCCH transmissions.

[0567] if Furthermore, if the UE is provided with PUCCH resources through pucch-ResourceCommon and is not provided with useInterlacePUCCH-PUSCH-r16 in BWP-UplinkCommon, then the UE can determine the PRB index of the PUCCH transmission in the first hop as follows: And determine the PRB index of the PUCCH transmission in the second hop as In this article, This can be the total number of initial circular shift indices. Within the initial circular shift index set, It can be an extension factor of the time-domain OCC.

[0568] And / or, in the same manner as Msg3 PUSCH, a RedCap UE can transmit PUCCH in a frequency domain distinct from that of a normal UE by applying a cell-specific frequency offset to the PUCCH transmission frequency resources used for normal UEs and transmitting it. In this example, the PUCCH transmission frequency resources can be determined by reusing a portion of the configuration in Table 14 and adding an additional cell-specific frequency offset. For this purpose, the cell-specific frequency offset can be included in the SIB (e.g., the initial ULBWP configuration BWP-UplinkCommon(-R) of SIB1) and transmitted.

[0569] PUCCH FH has been described based on intra-slot FH, but PUCCH FH can be applied in the same way even if inter-slot FH is supported.

[0570] If two-step RACH is supported, then the method for sending Msg4 ACK / NACK PUCCH according to this disclosure (i.e., the third embodiment) can be equivalently applied to the method for sending MsgB ACK / NACK PUCCH.

[0571] Figure 19 This is a flowchart illustrating the operation method of the UE described in this disclosure.

[0572] refer to Figure 19 First, in step S1901, the capability (RedCap) UE ( Figures 21 to 24 (100 / 200) can send a random access preamble to the base station. For example, a RedCap UE can refer to a UE with a (maximum) bandwidth less than the NR bandwidth (or initial UL BWP). For example, the (maximum) bandwidth of a RedCap UE can be 20MHz.

[0573] And / or, Figure 19 The operation can be performed by both normal UE and RedCap UE.

[0574] For example, the operation of RedCap UE sending random access preamble in step S1901 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to transmit a random access preamble.

[0575] And / or, in step S1902, RedCap UE ( Figures 21 to 24 (100 / 200) can receive a random access response from the base station based on the random access preamble.

[0576] And / or, since the resources (or ROs) used for random access responses are not included in the bandwidth of the RedCap UE, random access responses can be received based on frequency retuning. That is, the RedCap UE can change the starting frequency of the RedCap UE's bandwidth so that the resources used for random access responses are included in the bandwidth.

[0577] And / or, the Random Access Response (RAR) window can be configured to start X symbols or X' microseconds later than the RAR window of a normal UE. For example, X or X' can be a value greater than or equal to the transition time (NRx-Tx or NTx-Rx) and / or frequency retuning time defined in a predefined standard (e.g., 3GPP TS 38.211). And / or, X or X' can be a value defined taking into account the characteristics of RedCap UEs. And / or, the starting (time) position of the RAR window can be configured by system information. That is, X or X' can be a value configured via a higher level of system information. For example, a normal UE can refer to a UE other than a RedCap UE.

[0578] Furthermore / or, the operation of receiving a random access response can be referred to the content of the first embodiment. That is, the details of the above operations or alternative / modifiable operations can be referred to the content of the first embodiment.

[0579] For example, the operation of RedCap UE receiving random access response in step S1902 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to receive random access responses.

[0580] And / or, in step S1903, RedCap UE ( Figures 21 to 24 The 100 / 200) can send a message (Msg)3 Physical Uplink Shared Channel (PUSCH) to the base station based on the random access response. In this disclosure, Msg3 PUSCH may also be referred to as Msg3 or PUSCH.

[0581] For example, the operation of RedCap UE sending Msg3 PUSCH in step S1903 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to transmit Msg3 PUSCH.

[0582] And / or, in step S1904, RedCap UE ( Figures 21 to 24 (100 / 200) can receive Msg4 from the base station based on Msg3PUSCH.

[0583] For example, the operation of RedCap UE receiving Msg4 in step S1904 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to receive Msg4.

[0584] And / or, in step S1905, RedCap UE ( Figures 21 to 24 (100 / 200) can send a PUCCH for Msg4 to the base station.

[0585] Specifically, at least one of Msg3 PUSCH and / or PUCCH can be transmitted without frequency hopping, based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE. And / or, the initial uplink bandwidth can be the bandwidth of the initial uplink bandwidth portion (BWP). And / or, the bandwidth of the RedCap UE can be the maximum bandwidth supported by the RedCap UE.

[0586] And / or, frequency hopping for PUCCH can be configured to be "disabled". For example, a RedCap UE can receive information to deactivate or disable frequency hopping for PUCCH via Radio Resource Control (RRC) signaling (e.g., higher-layer parameter disable-FH-PUCCH). For example, a base station can configure frequency hopping for PUCCH to be "disabled" based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE.

[0587] And / or, the random access response may include a frequency hopping flag for Msg3 PUSCH (Table 11). And / or, the frequency hopping flag may be set to "0". For example, the information (or fields) included in the random access response and the information size may be the same as in Table 11. For example, the base station may set the frequency hopping flag for Msg3PUSCH to "0" based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE.

[0588] And / or, PUCCH may include Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) information for Msg4.

[0589] And / or, the operation of sending Msg3 PUSCH can refer to the content of the second embodiment. And / or, the operation of sending Msg4 PUCCH can refer to the content of the third embodiment. That is to say, the details or alternative / changeable operations for the above operations can refer to the content of the second and third embodiments.

[0590] For example, the operation of RedCap UE sending PUCCH in step S1905 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 in order to transmit PUCCH.

[0591] And / or, more details regarding the random access procedure / process can be found in the references. Figure 10 The content described.

[0592] The above-described UE operations have focused on a 4-step RACH operation, but the method proposed in this disclosure can also be applied to a 2-step RACH operation. For example, the method proposed in this disclosure can also be applied to MsgAPUSCH / PUCCH for MsgB. And / or, the 2-step RACH can be referenced... Figure 11 The content described.

[0593] Due to reference Figure 19 Description of UE operation and reference Figures 1 to 18 The operation of the UE described (e.g., the first to third embodiments) is the same, so its detailed operation is omitted.

[0594] The aforementioned signaling and operations can be performed by the devices described below (e.g., Figures 21 to 24 This can be achieved through [method / mechanism]. For example, the aforementioned signaling and operations can be implemented by [method / mechanism]. Figures 21 to 24 One or more processors process the above signaling and operations, and the above signaling and operations can be used for execution. Figures 21 to 24 It is stored in the form of commands / programs (e.g., instructions, executable code) for one or more processors.

[0595] For example, a processing device configured to control a RedCap UE to transmit PUSCH in a wireless communication system may include: at least one processor; and at least one memory operatively connected to the at least one processor and storing instructions to perform operations based on execution by the at least one processor, wherein the operations may include: transmitting a random access preamble to a base station, receiving a random access response from the base station based on the random access preamble, transmitting Msg3 PUSCH to the base station based on the random access response, receiving Msg4 from the base station based on Msg3 PUSCH, and transmitting a PUCCH for Msg4 to the base station, wherein at least one of Msg3 PUSCH and / or PUCCH may be transmitted without frequency hopping, based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE.

[0596] For example, in a computer-readable storage medium storing at least one instruction, the at least one instruction being executed by at least one processor to allow at least one processor to control an operation, said operation may include: sending a random access preamble to a base station, receiving a random access response from the base station based on the random access preamble, sending Msg3 PUSCH to the base station based on the random access response, receiving Msg4 from the base station based on Msg3 PUSCH, and sending a PUCCH to the base station for Msg4, wherein at least one of Msg3 PUSCH and / or PUCCH may be sent without frequency hopping, based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE.

[0597] Figure 20 This is a flowchart illustrating the operation method of the base station described in this disclosure.

[0598] refer to Figure 20 First, in step S2001, the base station ( Figures 21 to 24 (100 / 200) can receive random access preambles from a Reduced Cap (RedCap) UE. And / or, a RedCap UE can refer to a UE with a (maximum) bandwidth less than the NR bandwidth (or initial UL BWP). For example, the (maximum) bandwidth of a RedCap UE can be 20MHz.

[0599] And / or, in Figure 20 During operation, the RedCap UE can be replaced by a normal UE.

[0600] For example, the operation of the base station receiving the random access preamble in step S2001 can be performed by... Figures 21 to 24 This is achieved using equipment. For example, refer to... Figure 22One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to receive random access preambles.

[0601] And / or, in step S2002, the base station ( Figures 21 to 24 (100 / 200) can send a random access response based on the random access pre-guided RedCap UE.

[0602] And / or, since the resources (or ROs) used for random access responses are not included in the bandwidth of the RedCap UE, random access responses can be transmitted based on frequency retuning. In other words, the RedCap UE can change the starting frequency of its bandwidth so that the resources used for random access responses are included in the bandwidth.

[0603] And / or, the Random Access Response (RAR) window can be configured to start X symbols or X' microseconds later than the RAR window of a normal UE. For example, X or X' can be a value greater than or equal to the transition time (NRx-Tx or NTx-Rx) and / or frequency retuning time defined in a predefined standard (e.g., 3GPP TS 38.211). And / or, X or X' can be a value defined taking into account the characteristics of RedCap UEs. And / or, the starting (time) position of the RAR window can be configured by system information. That is, X or X' can be a value configured via a higher level of system information. For example, a normal UE can refer to a UE other than a RedCap UE.

[0604] And / or, the operation of sending a random access response can refer to the content of the first embodiment. That is, the details or alternative / changeable operations for the above operations can refer to the content of the first embodiment.

[0605] For example, the operation of the base station sending a random access response in step S2002 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to send random access responses.

[0606] And / or, in step S2003, the base station ( Figures 21 to 24 The 100 / 200) can receive message (Msg)3 Physical Uplink Shared Channel (PUSCH) from the RedCap UE based on the random access response. In this disclosure, Msg3 PUSCH may also be referred to as Msg3 or PUSCH.

[0607] For example, the operation of the base station receiving Msg3 PUSCH in step S2003 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to receive Msg3 PUSCH.

[0608] And / or, in step S2004, the base station ( Figures 21 to 24 (100 / 200) can send Msg4 to RedCap UE based on Msg3 PUSCH.

[0609] For example, the operation of the base station sending Msg4 in step S2004 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to transmit Msg4.

[0610] And / or, in step S2005, the base station ( Figures 21 to 24 (100 / 200) can receive PUCCH for Msg4 from RedCap UE.

[0611] Specifically, at least one of Msg3 PUSCH and / or PUCCH can be received without frequency hopping, based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE. And / or, the initial uplink bandwidth can be the bandwidth of the initial uplink bandwidth portion (BWP). And / or, the bandwidth of the RedCap UE can be the maximum bandwidth supported by the RedCap UE.

[0612] And / or, frequency hopping for PUCCH can be configured to be "disabled". For example, a RedCap UE can receive information to deactivate or disable frequency hopping for PUCCH via Radio Resource Control (RRC) signaling (e.g., higher-layer parameter disable-FH-PUCCH). For example, a base station can configure frequency hopping for PUCCH to be "disabled" based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE.

[0613] And / or, the random access response may include a frequency hopping flag for Msg3 PUSCH (Table 11). And / or, the frequency hopping flag may be set to "0". For example, the information (or fields) included in the random access response and the information size may be the same as in Table 11. For example, the base station may set the frequency hopping flag for Msg3PUSCH to "0" based on the initial uplink bandwidth being greater than the bandwidth of the RedCap UE.

[0614] And / or, PUCCH may include Hybrid Automatic Repeat Request Acknowledgment (HARQ-ACK) information for Msg4.

[0615] And / or, the operation of receiving Msg3 PUSCH can refer to the content of the second embodiment. And / or, the operation of receiving Msg4 PUCCH can refer to the content of the third embodiment. That is to say, the details or alternative / changeable operations for the above operations can refer to the content of the second and third embodiments.

[0616] For example, the base station receiving PUCCH operation in step S2005 can be performed by... Figures 21 to 24 The device implementation. For example, refer to Figure 22 One or more processors 102 / 202 can control one or more memories 104 / 204 and / or one or more transceivers 106 / 206 to receive PUCCH.

[0617] And / or, more details regarding the random access procedure / process can be found in the references. Figure 10 The content described.

[0618] The operation of the aforementioned base station has been described focusing on a 4-step RACH operation; however, the method proposed in this disclosure can also be applied to a 2-step RACH operation. For example, the method proposed in this disclosure can also be applied to MsgAPUSCH / PUCCH for MsgB. And / or, the 2-step RACH can be referenced... Figure 11 The content described.

[0619] Due to reference Figure 20 Description of base station operation and reference Figures 1 to 19 The operation of the base stations described (e.g., the first to third embodiments) is the same, so detailed operation is omitted.

[0620] The aforementioned signaling and operations can be performed by the devices described below (e.g., Figures 21 to 24 This can be achieved through [method / mechanism]. For example, the aforementioned signaling and operations can be implemented by [method / mechanism]. Figures 21 to 24 One or more processors process the above signaling and operations, and the above signaling and operations can be used for execution. Figures 21 to 24It is stored in the form of commands / programs (e.g., instructions, executable code) for one or more processors.

[0621] For example, a processing device configured to control a base station to receive a PUSCH in a wireless communication system may include at least one processor and at least one memory operatively connected to the at least one processor and storing instructions to perform operations based on execution by the at least one processor, said operations may include: receiving a random access preamble from a RedCap UE, sending a random access response to the RedCap UE based on the random access preamble, receiving a Msg3 PUSCH from the RedCap UE based on the random access response, sending a Msg4 to the RedCap UE based on the Msg3 PUSCH, and receiving a PUCCH for Msg4 from the RedCap UE, wherein at least one of the Msg3 PUSCH and / or PUCCH may be received without frequency hopping, based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE.

[0622] For example, in a computer-readable storage medium storing at least one instruction, the at least one instruction is based on an operation executed by at least one processor to allow at least one processor to control an operation, said operation may include: receiving a random access preamble from a RedCap UE, sending a random access response to the RedCap UE based on the random access preamble, receiving Msg3 PUSCH from the RedCap UE based on the random access response, sending Msg4 to the RedCap UE based on Msg3 PUSCH, and receiving a PUCCH for Msg4 from the RedCap UE, wherein at least one of Msg3 PUSCH and / or PUCCH may be received without frequency hopping based on an initial uplink bandwidth greater than the bandwidth of the RedCap UE.

[0623] Examples of communication systems applied in this disclosure

[0624] The various descriptions, functions, processes, proposals, methods, and / or operation flowcharts of this disclosure described in this document can be applied to, but are not limited to, various fields requiring wireless communication / connectivity between devices (e.g., 5G).

[0625] The following description will be made with reference to the accompanying drawings. In the following drawings / descriptions, unless otherwise stated, the same reference numerals may denote the same or corresponding hardware blocks, software blocks, or functional blocks.

[0626] Figure 21 The diagram illustrates a communication system applied to this disclosure.

[0627] refer to Figure 21The communication systems applied in this disclosure include wireless devices, base stations (BSs), and networks. Here, a wireless device refers to a device that performs communication using a radio access technology (RAT) (e.g., 5G New RAT (NR)) or Long Term Evolution (LTE), and may be referred to as a communication / radio / 5G device. Wireless devices may include, but are not limited to, robots 1010a, vehicles 1010b-1 and 1010b-2, extended reality (XR) devices 1010c, handheld devices 1010d, home appliances 1010e, Internet of Things (IoT) devices 1010f, and artificial intelligence (AI) devices / servers 400. For example, a vehicle may include a vehicle with wireless communication capabilities, an autonomous vehicle, and a vehicle capable of communicating with each other. Here, a vehicle may include an unmanned aerial vehicle (UAV) (e.g., a drone). XR devices can include augmented reality (AR) / virtual reality (VR) / mixed reality (MR) devices, and can be implemented in the form of head-mounted displays (HMDs), head-up displays (HUDs) installed in vehicles, televisions, smartphones, computers, wearable devices, home appliances, digital signage, vehicles, robots, etc. Handheld devices can include smartphones, smart tablets, wearable devices (e.g., smartwatches or smart glasses) and computers (e.g., laptops). Home appliances can include televisions, refrigerators, and washing machines. IoT devices can include sensors and smart meters. For example, the BS and network can be implemented as wireless devices, and a specific wireless device 200a can operate as a BS / network node relative to other wireless devices.

[0628] Wireless devices 1010a to 1010f can connect to network 300 via BS 1020. AI technology can be applied to wireless devices 1010a to 1010f, and wireless devices 1010a to 1010f can connect to AI server 400 via network 300. Network 300 can be configured using a 3G network, a 4G (e.g., LTE) network, or a 5G (e.g., NR) network. Although wireless devices 1010a to 1010f can communicate with each other via BS 1020 / network 300, wireless devices 1010a to 1010f can also perform direct communication with each other without going through the BS / network (e.g., sidelink communication). For example, vehicles 1010b-1 and 1010b-2 can perform direct communication (e.g., vehicle-to-vehicle (V2V) / vehicle-to-everything (V2X) communication). IoT devices (e.g., sensors) can perform direct communication with other IoT devices (e.g., sensors) or other wireless devices 1010a to 1010f.

[0629] Wireless communication / connections 150a, 150b, or 150c can be established between wireless devices 1010a to 1010f / BS 1020 or BS 1020 / BS 1020. Here, the wireless communication / connection can be established via various RATs (e.g., 5G NR) such as uplink / downlink communication 150a, sidelink communication 150b (or D2D communication), or inter-BS communication (e.g., relay, integrated access backhaul (IAB)). The wireless devices and BS / wireless devices can transmit / receive radio signals to / from each other via wireless communication / connections 150a and 150b. For example, wireless communication / connections 150a and 150b can transmit / receive signals via various physical channels. For this purpose, at least a portion of the various configuration information configuration processes, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, and resource mapping / demapping), and resource allocation processes used for transmitting / receiving radio signals can be performed based on various suggestions of this disclosure.

[0630] Examples of wireless devices applicable to this disclosure

[0631] Figure 22 The illustrations are applicable to wireless devices disclosed herein.

[0632] refer to Figure 22 The first wireless device 100 and the second wireless device 200 can transmit radio signals via various RATs (e.g., LTE and NR). Here, {first wireless device 100 and second wireless device 200} can correspond to Figure 21 {Wireless Device 1010x and BS 1020} and / or {Wireless Device 1010x and Wireless Device 1010x}.

[0633] The first wireless device 100 may include one or more processors 102 and one or more memories 104, and may also include one or more transceivers 106 and / or one or more antennas 108. The processor 102 may control the memory 104 and / or the transceiver 106, and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document. For example, the processor 102 may process information in the memory 104 to generate a first information / signal, and then transmit a radio signal including the first information / signal via the transceiver 106. The processor 102 may receive a radio signal including a second information / signal via the transceiver 106, and then store the information obtained by processing the second information / signal in the memory 104. The memory 104 may be connected to the processor 102 and may store various information relating to the operation of the processor 102. For example, the memory 104 may store software code including commands for performing some or all of the processes controlled by the processor 102, or for executing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document. Here, processor 102 and memory 104 may be part of a communication modem / circuit / chip designed to implement RAT (e.g., LTE or NR). Transceiver 106 may be connected to processor 102 and transmit and / or receive radio signals via one or more antennas 108. Each transceiver 106 may include a transmitter and / or a receiver. Transceiver 106 may be used interchangeably with a radio frequency (RF) unit. In this disclosure, a wireless device may represent a communication modem / circuit / chip.

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

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

[0636] One or more processors 102 and 202 may be referred to as controllers, microcontrollers, microprocessors, or microcomputers. One or more processors 102 and 202 may be implemented by hardware, firmware, software, or a combination thereof. For example, one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), one or more digital signal processing devices (DSPDs), one or more programmable logic devices (PLDs), or one or more field-programmable gate arrays (FPGAs) may be included in one or more processors 102 and 202. The descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in this document may be implemented using firmware or software, and the firmware or software may be configured to include modules, procedures, or functions. Firmware or software configured to execute the descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in this document may be included in one or more processors 102 and 202, or stored in one or more memories 104 and 204, such that they are driven by one or more processors 102 and 202. The descriptions, functions, procedures, proposals, methods, and / or operational flowcharts disclosed in this document may be implemented using firmware or software in the form of code, commands, and command sets.

[0637] One or more memories 104 and 204 may be connected to one or more processors 102 and 202 and store various types of data, signals, messages, information, programs, code, instructions, and / or commands. One or more memories 104 and 204 may be configured with read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EPROM), flash memory, hard disk drive, registers, buffer memory, computer-readable storage media, and / or combinations thereof. One or more memories 104 and 204 may be located internally and / or externally to one or more processors 102 and 202. One or more memories 104 and 204 may be connected to one or more processors 102 and 202 via various technologies such as wired or wireless connections.

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

[0639] Examples of wireless devices applied to this disclosure

[0640] Figure 23 The illustration shows another example of a wireless device applied to this disclosure. Wireless devices can be implemented in various forms depending on the use case / service.

[0641] refer to Figure 23 Wireless devices 100 and 200 can correspond to Figure 22The wireless devices 100 and 200 can be configured from various elements, components, units / parts, and / or modules. For example, each of the wireless devices 100 and 200 may include a communication unit 110, a control unit 120, a memory unit 130, and an additional component 140. The communication unit may include a communication circuit 112 and a transceiver 114. For example, the communication circuit 112 may include... Figure 22 One or more processors 102 and 202 and / or one or more memories 104 and 204 are included. For example, transceiver 114 may include... Figure 22 One or more transceivers 106 and 206 and / or one or more antennas 108 and 208. Control unit 120 is electrically connected to communication unit 110, memory 130, and add-on components 140, and controls the overall operation of the wireless device. For example, control unit 120 can control the electrical / mechanical operation of the wireless device based on programs / code / commands / information stored in memory unit 130. Control unit 120 can transmit information stored in memory unit 130 to an external source (e.g., other communication devices) via communication unit 110 through a wireless / wired interface, or store information received from an external source (e.g., other communication devices) via communication unit 110 in memory unit 130.

[0642] The additional component 140 can be configured differently depending on the type of wireless device. For example, the additional component 140 may include at least one of a power unit / battery, an input / output (I / O) unit, a drive unit, and a computing unit. The wireless device is capable of, but is not limited to, […]. Figure 21 Robot 100a Figure 21 Vehicles 100b-1 and 100b-2, Figure 21 XR equipment 100c, Figure 21 Portable device 100d, Figure 21 Home appliances 100e, Figure 21 IoT devices 100f, digital broadcasting terminals, holographic devices, public safety equipment, MTC devices, medical devices, fintech devices (or financial devices), security devices, climate / environmental devices, Figure 21 AI server / device 400, Figure 21 It can be implemented in the form of BS 200, network nodes, etc. Depending on the use case / service, wireless devices can be used in mobile or fixed locations.

[0643] exist Figure 23In wireless devices 100 and 200, the various elements, components, units / parts, and / or modules thereof can be interconnected via wired interfaces, or at least a portion thereof can be wirelessly connected via communication units. For example, in each of wireless devices 100 and 200, control unit 120 and communication unit 110 can be wired connected, and control unit 120 and first units (e.g., 130 and 140) can be wirelessly connected via communication unit 110. Each element, component, unit / part, and / or module within wireless devices 100 and 200 may further include one or more elements. For example, control unit 120 may be configured by a collection of one or more processors. As an example, control unit 120 may be configured by a collection of communication control processors, application processors, electronic control units (ECUs), graphics processing units, and memory control processors. As another example, memory 130 may be configured by random access memory (RAM), dynamic RAM (DRAM), read-only memory (ROM), flash memory, volatile memory, non-volatile memory, and / or combinations thereof.

[0644] Examples of handheld devices applied to this disclosure

[0645] Figure 24 The illustration applies to a handheld device disclosed herein. This handheld device may include a smartphone, smartpad, wearable device (e.g., a smartwatch or smart glasses), or portable computer (e.g., a laptop). The handheld device may be referred to as a mobile station (MS), user terminal (UT), mobile subscriber station (MSS), subscriber station (SS), advanced mobile station (AMS), or wireless terminal (WT).

[0646] refer to Figure 24 The handheld device 1010 may include an antenna unit 108, a communication unit 110, a control unit 120, a memory unit 130, a power supply unit 140a, an interface unit 140b, and an I / O unit 140c. The antenna unit 108 may be configured as part of the communication unit 110. Blocks 110 to 130 / 140a to 140c correspond to... Figure 23 The frame is 110 to 130 / 140.

[0647] Communication unit 110 can send signals (e.g., data and control signals) to other wireless devices or BSs and receive signals (e.g., data and control signals) from other wireless devices or BSs. Control unit 120 can perform various operations by controlling the components of handheld device 1010. Control unit 120 may include an application processor (AP). Memory unit 130 can store data / parameters / programs / codes / commands required to drive handheld device 1010. Memory unit 130 can store input / output data / information. Power supply unit 140a can power handheld device 1010 and includes wired / wireless charging circuitry, a battery, etc. Interface unit 140b can support connection of handheld device 1010 to other external devices. Interface unit 140b may include various ports for connecting to external devices (e.g., audio I / O ports and video I / O ports). I / O unit 140c can input or output video information / signals, audio information / signals, data, and / or information input by the user. I / O unit 140c may include a camera, microphone, user input unit, display unit 140d, speaker and / or haptic module.

[0648] As an example, in the case of data communication, I / O unit 140c can acquire information / signals input by the user (e.g., touch, text, voice, image, or video) and can store the acquired information / signals in memory unit 130. Communication unit 110 can convert the information / signals stored in memory into radio signals and transmit the converted radio signals directly to other wireless devices or to the BS. Communication unit 110 can receive radio signals from other wireless devices or the BS and then recover the received radio signals into the original information / signals. The recovered information / signals can be stored in memory unit 130 and can be output as various types (e.g., text, voice, image, video, or haptic) through I / O unit 140c.

[0649] In this context, in addition to LTE, NR, and 6G, the wireless communication technologies implemented in the wireless devices 100 and 200 of this disclosure may also include narrowband Internet of Things (IoT) for low-power communication. In this context, for example, NB-IoT technology may be an example of low-power wide-area network (LPWAN) technology and may be implemented by standards such as LTE Cat NB1 and / or LTE Cat NB2, and this disclosure is not limited to the aforementioned names. Additionally or alternatively, the wireless communication technologies implemented in the wireless devices (100, 200) of this disclosure may perform communication based on LTE-M technology. In this context, for example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names, such as enhanced machine-type communication (eMTC). For example, LTE-M technology may be implemented by at least any of various standards, such as 1) LTE Cat 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE machine-type communication, and / or 7) LTE M, and this disclosure is not limited to the aforementioned names. Additionally or alternatively, the wireless communication technologies implemented in the wireless devices (100, 200) of this disclosure may include at least any one of ZigBee, Bluetooth, and low-power wide area networks (LPWANs) that take into account low-power communication, and this disclosure is not limited to the names mentioned above. For example, ZigBee technology may be based on various standards such as IEEE 802.15.4 to generate personal area networks (PANs) associated with small / low-power digital communication, and may be referred to by various names.

[0650] The above embodiments are implemented by combining the components and features of this disclosure in a predetermined manner. Unless otherwise specified, each component or feature should be considered selectively. Each component or feature may be implemented without combination with another component or feature. Furthermore, some components and / or features may be combined with each other and may implement embodiments of this disclosure. The order of operations described in the embodiments of this disclosure may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced by corresponding components or features of another embodiment. It is apparent that some claims referencing a particular claim may be combined with other claims referencing claims other than the particular claim to form an embodiment, or new claims may be added by amendment after filing the application.

[0651] Embodiments of this disclosure can be implemented by various means, such as hardware, firmware, software, or a combination thereof. When an embodiment is implemented in hardware, an embodiment of this disclosure can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, etc.

[0652] When an embodiment is implemented via firmware or software, an embodiment of this disclosure can be implemented by modules, processes, functions, etc., that perform the above-described functions or operations. Software code can be stored in memory and can be driven by a processor. The memory is located inside or outside the processor and can exchange data with the processor in various well-known ways.

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

[0654] Industrial availability

[0655] Although the method for transmitting and receiving PUCCH in the wireless communication system disclosed herein has been described with reference to examples applied to 3GPP LTE / LTE-A systems or 5G systems (new RAT systems), the method is also applicable to various wireless communication systems such as Beyond 5G, 6G and Beyond 6G.

Claims

1. A method comprising: receiving, by a reduced capability (RedCap) user equipment (UE), a system information block (SIB) including uplink (UL) bandwidth part (BWP) configuration information; and transmitting, by the RedCap UE, a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein frequency hopping (FH) of the PUCCH is disabled, dedicated PUCCH configuration information is not configured in the RedCap UE, and the RedCap UE determines frequency resources of the PUCCH based on a first frequency offset and a second frequency offset, wherein the UL BWP configuration information includes: i) first information related to a first PUCCH resource set among a plurality of PUCCH resource sets, each PUCCH resource set of the plurality of PUCCH resource sets including PUCCH format information, symbol information, and physical resource block (PRB) offset information (RB BWP offset ), and ii) second information related to the second frequency offset, wherein the first frequency offset is a RB offset in the first PUCCH resource set related to the first information BWP offset values, and wherein the second frequency offset is to the RB BWP offset additional frequency offset of the value.

2. The method of claim 1, wherein, The RedCap UE determines the frequency resources of the PUCCH based on the RB BWP offset a value and the additional frequency offset to determine the frequency resources of the FH- disabled PUCCH.

3. The method of claim 1, wherein, the additional frequency offset is a cell-specific PUCCH parameter for RedCap.

4. The method of claim 1, wherein, the first information and the second information are used to determine the frequency resources of the PUCCH based on the dedicated PUCCH configuration information not being configured in the RedCap UE and the FH of the PUCCH being disabled.

5. The method of claim 1, wherein, the first information and the second information are used by the RedCap UE until the RedCap UE is configured with the dedicated PUCCH configuration information.

6. The method of claim 1, wherein, the disabled FH is intra-slot FH.

7. The method of claim 1, further comprising: receiving, by the RedCap UE, a physical downlink shared channel (PDSCH), wherein the HARQ-ACK information is related to the PDSCH reception.

8. The method of claim 1, further comprising: transmitting, by the RedCap UE, a random access preamble; and receiving, by the RedCap UE, a physical downlink control channel (PDCCH) in response to the random access preamble.

9. The method of claim 8, further comprising: transmitting, by the RedCap UE, a physical uplink shared channel (PUSCH) based on the PDCCH, wherein the PDSCH is related to contention resolution in a random access procedure.

10. The method of claim 1, wherein, a size of an initial BWP is greater than a maximum size supported by the RedCap UE.

11. A processor-readable medium configured to store instructions that, when executed by at least one processor of a reduced capability (RedCap) user equipment (UE), cause the RedCap UE to perform the method of claim 1.

12. A reduced capability (RedCap) user equipment (UE) comprising: at least one processor; and at least one memory configured to store instructions that, when executed by the at least one processor, cause the RedCap UE to perform operations comprising: receiving a system information block (SIB) including uplink (UL) bandwidth part (BWP) configuration information; and transmitting a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein frequency hopping (FH) of the PUCCH is disabled, dedicated PUCCH configuration information is not configured in the RedCap UE, and a frequency resource of the PUCCH is determined based on a first frequency offset and a second frequency offset, wherein the UL BWP configuration information includes: i) first information related to a first PUCCH resource set among a plurality of PUCCH resource sets, each PUCCH resource set of the plurality of PUCCH resource sets including PUCCH format information, symbol information, and physical resource block (PRB) offset information (RB BWP offset ), and ii) second information related to the second frequency offset, wherein the first frequency offset is a RB in the first PUCCH resource set related to the first information BWP offset values, and wherein the second frequency offset is to the RB BWP offset additional frequency offset of the value.

13. A method comprising: transmitting, by a base station (BS), a system information block (SIB) including uplink (UL) bandwidth part (BWP) configuration information; and receiving, by the BS from a reduced capability (RedCap) user equipment (UE), a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein frequency hopping (FH) of the PUCCH is disabled, dedicated PUCCH configuration information is not configured in the RedCap UE, and a frequency resource of the PUCCH is determined based on a first frequency offset and a second frequency offset, 14. A base station (BS) comprising: wherein the UL BWP configuration information includes: i) first information related to a first PUCCH resource set among a plurality of PUCCH resource sets, each PUCCH resource set of the plurality of PUCCH resource sets including PUCCH format information, symbol information, and physical resource block (PRB) offset information (RB BWP offset ), and ii) second information related to the second frequency offset, wherein the first frequency offset is a RB in the first PUCCH resource set related to the first information BWP offset values, and wherein the second frequency offset is to the RB BWP offset an additional frequency offset of the value. at least one processor; and at least one memory configured to store instructions that, when executed by the at least one processor, cause the BS to perform operations comprising: transmitting a system information block (SIB) including uplink (UL) bandwidth part (BWP) configuration information; and receiving, by the BS from a reduced capability (RedCap) user equipment (UE), a physical uplink control channel (PUCCH) including hybrid automatic repeat request-acknowledgement (HARQ-ACK) information, wherein frequency hopping (FH) of the PUCCH is disabled, dedicated PUCCH configuration information is not configured in the RedCap UE, and a frequency resource of the PUCCH is determined based on a first frequency offset and a second frequency offset, ​ wherein the UL BWP configuration information includes: i) first information related to a first PUCCH resource set among a plurality of PUCCH resource sets, each PUCCH resource set of the plurality of PUCCH resource sets including PUCCH format information, symbol information, and physical resource block (PRB) offset information (RB BWP offset ), and ii) second information related to the second frequency offset, wherein the first frequency offset is a RB in the first PUCCH resource set related to the first information BWP offset values, and wherein the second frequency offset is to the RB BWP offset an additional frequency offset of the value.

Images