Method and apparatus for transmitting and receiving wireless signals in a wireless communication system

Abstract

A method performed by a UE in a wireless communication system according to various embodiments and an apparatus therefor are disclosed. An apparatus and method thereof are disclosed, the apparatus: receiving, from a base station, random access channel (RACH) configuration information including a first set of parameters for configuring a default RACH occasion (RO) and a second set of parameters for configuring an additional RO, activation or deactivation of the additional RO being indicated; and transmitting a physical random access channel (PRACH) based on the RACH configuration information.

Description

Technical Field

[0001] This disclosure relates to wireless communication systems, and more specifically, to methods and apparatus for transmitting and receiving wireless signals. Background Technology

[0002] Wireless communication systems are widely deployed to provide various communication services, such as voice and data. Typically, a wireless communication system is a multiple access system that can support communication with multiple users by sharing available system resources (bandwidth, transmission power, etc.). Examples of multiple access systems include Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiple Access (OFDMA), and Single Carrier Frequency Division Multiple Access (SC-FDMA).

[0003] With an increasing number of communication devices requiring larger communication services, and given current trends, the next-generation fifth-generation (5G) system is needed to provide enhanced wireless broadband communication compared to traditional LTE systems. In the next-generation 5G system, communication scenarios include enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine-type communication (mMTC).

[0004] In this paper, eMBB is a next-generation mobile communication scenario characterized by high spectral efficiency, high user experience data rate, and high peak data rate; URLLC is a next-generation mobile communication scenario characterized by ultra-high reliability, ultra-low latency, and ultra-high availability (e.g., vehicle-to-everything (V2X), emergency services, and remote control); and mMTC is a next-generation mobile communication scenario characterized by low cost, low energy, short packet size, and massive connectivity (e.g., Internet of Things (IoT)). Summary of the Invention

[0005] Technical issues

[0006] The purpose of this disclosure is to provide methods and apparatus for transmitting and receiving signals more accurately and efficiently.

[0007] Those skilled in the art will understand that the objectives that can be achieved by various embodiments of this disclosure are not limited to those specifically described above, and that the above and other objectives that can be achieved by various embodiments of this disclosure will become clearer from the following detailed description.

[0008] Technical solution

[0009] In one aspect, this document provides a method performed by a user equipment (UE). The method may include the steps of: receiving random access channel (RACH) configuration information from a base station; and transmitting a physical random access channel (PRACH) based on the RACH configuration information, wherein the RACH configuration information may include: a first set of parameters for configuring a default RACH timing (RO) and a second set of parameters for configuring an additional RO, the activation or deactivation of which is indicated.

[0010] Alternatively, the first parameter set may include a first PRACH configuration index, and the second parameter set may include a second PRACH configuration index that is different from the first PRACH configuration index.

[0011] Alternatively, if the additional RO is not activated, the PRACH may be transmitted on a RO of the first period having a first parameter set based on RACH configuration information. If the additional RO is activated, the PRACH may be transmitted on a RO of the second period having a first parameter set and a second parameter set based on RACH configuration information, which is shorter than the first period.

[0012] Alternatively, whether the second parameter set is activated can be indicated by downlink control information (DCI) or media access control element (MAC-CE).

[0013] Alternatively, the DCI or MAC-CE indicating the activation of the second parameter set may include information about the duration of the activation.

[0014] Alternatively, the second parameter set may be activated during the activation time duration after a first time elapses from the time point when the DCI or MAC-CE is received.

[0015] Alternatively, the DCI or MAC-CE may include a bitmap comprising bits corresponding to multiple durations. The UE may determine the activation duration of the second set of parameters based on the bitmap within the durations.

[0016] Alternatively, whether to activate the second set of parameters can be indicated by the base station based on the number of UEs connected to the base station and the amount of data activity.

[0017] Alternatively, the second set of parameters can be configured with additional ROs for UEs that support base stations associated with Network Energy Saving (NES).

[0018] On the other hand, a non-transitory computer-readable recording medium may be provided, which stores a program for the UE to perform the above-described method.

[0019] On the other hand, a UE for performing the above methods can be provided.

[0020] On the other hand, a processing apparatus for controlling a UE that performs the above-described method can be provided.

[0021] On the other hand, this document provides a method performed by a base station. The method may include the following steps: sending random access channel (RACH) configuration information, the RACH configuration information including a first set of parameters for configuring a default RACH timing (RO) and a second set of parameters for configuring an additional RO, the activation or deactivation of which is indicated; and receiving a physical random access channel (PRACH) from a user equipment (UE) based on the RACH configuration information.

[0022] Beneficial effects

[0023] According to embodiments of this disclosure, signals can be transmitted or received more accurately and more efficiently in a wireless communication system.

[0024] Alternatively, it can more efficiently control the power usage of the network and / or UE in a wireless communication system.

[0025] The effects to be achieved by the implementation method are not limited to those specifically described above, and those skilled in the art to which the implementation method pertains will gain a clearer understanding of other effects not mentioned herein based on the following detailed description. Attached Figure Description

[0026] The accompanying drawings, which are included to provide a further understanding of this disclosure and are incorporated into and constitute a part of this application, illustrate embodiments of this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0027] Figure 1 This diagram illustrates the physical channels used in a 3GPP NR system and the typical signal transmission methods that use them.

[0028] Figure 2 The structure of an NR radio frame to which this disclosure applies is illustrated.

[0029] Figure 3 The time slot structure of the NR frame to which this disclosure applies is illustrated.

[0030] Figure 4 This is a diagram illustrating an exemplary mapping of the physical channel in a time slot to which the implementation method is applicable.

[0031] Figure 5 and Figure 6 This is a diagram illustrating Discontinuous Receive (DRX) operation in idle mode.

[0032] Figures 7 to 9 This is a diagram illustrating DRX operation in Radio Resource Control (RRC) connection mode.

[0033] Figure 10 This is a diagram illustrating a method for monitoring DCI format 2_6.

[0034] Figure 11 This diagram illustrates a method for communication between the BS and UE based on cell DRX / DTX.

[0035] Figure 12 This is a diagram illustrating on-demand SIB1 transmission.

[0036] Figure 13 This is a diagram illustrating a method for determining time resources for PRACH based on configuration information.

[0037] Figure 14 This diagram illustrates the method by which the UE determines the RO based on RACH configuration information.

[0038] Figure 15 This diagram illustrates a method by which the BS communicates with the UE based on RACH configuration information.

[0039] Figures 16 to 19 The communication system 1 and wireless device to which this disclosure applies are illustrated. Detailed Implementation

[0040] The embodiments disclosed herein are applicable to various radio access technologies such as Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiple Access (OFDMA), and Single Carrier Frequency Division Multiple Access (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 GSM Evolution (EDGE). OFDMA can be implemented as radio technologies such as IEEE 802.11 (Wireless Fidelity (Wi-Fi)), IEEE 802.16 (Global Microwave Access Interoperability (WiMAX)), IEEE 802.20, and Evolved UTRA (E-UTRA). UTRA is part of the Universal Mobile Telecommunications System (UMTS). The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) is part of Evolved UMTS using E-UTRA (E-UMTS), and LTE-Advanced (A) is an evolution of 3GPP LTE. 3GPP NR (New Radio or New Radio Access Technology) is an evolution of 3GPP LTE / LTE-A.

[0041] As more and more communication devices require greater communication capacity, there is a need for enhanced mobile broadband communications compared to traditional radio access technologies (RATs). Furthermore, the ability to provide various services anytime, anywhere by connecting multiple devices and objects is another important consideration for next-generation communications. Communication system designs considering reliability and latency-sensitive services / UEs are also being discussed. Therefore, the introduction of new radio access technologies that consider enhanced mobile broadband (eMBB), massive MTC, and ultra-reliable low-latency communication (URLLC) is being discussed. In this disclosure, for simplicity, this technology will be referred to as NR (New Radio or New RAT).

[0042] The term "base station" as used in this document can be replaced with terms such as fixed station, node B, gNode B (gNB), access point (AP), cell, or transmit and receive point (TRP). "Relay" can be replaced with terms such as relay node (RN), relay station, etc. Additionally, the term "terminal" can be replaced with terms such as user equipment (UE), mobile station (MS), mobile subscriber station (MSS), subscriber station (SS), etc.

[0043] For the sake of brevity, the description focuses on 3GPP NR, but the technical concepts disclosed herein are not limited thereto.

[0044] For background information, definitions of terms, abbreviations, etc. related to this disclosure, the following documents may be referenced and incorporated herein by reference.

[0045] - 38.211: Physical Channels and Modulation

[0046] - 38.212: Multiplexing and Channel Coding

[0047] - 38.213: Physical layer procedures for control

[0048] - 38.214: Physical layer procedures for data

[0049] - 38.215: Physical Layer Measurement

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

[0051] - 38.304: User Equipment (UE) Procedures in Idle Mode and RRC Inactive State

[0052] - 38.321: Media Access Control (MAC) Protocol Specification

[0053] - 38.331: Radio Resource Control (RRC) Protocol Specification

[0054] - 37.213: Introduces channel access procedures for unlicensed spectrum for NR-based access.

[0055] - 36.355: LTE positioning protocol

[0056] - 37.355: LTE positioning protocol

[0057] Terms and acronyms

[0058] - 5GC: 5G Core Network

[0059] - 5GS: 5G system

[0060] - NES: Network Energy Saving

[0061] - ES: Energy Saving

[0062] - SSB: Synchronization Signal / PBCH Block

[0063] - FR: Frequency range

[0064] - CC: Component Carrier

[0065] - NCGI: NR Cell Global Identifier

[0066] - SI: System Information

[0067] - PCell: Main Cell

[0068] - SCell: Secondary Cell

[0069] - PDCCH: Physical Downlink Control Channel

[0070] - PDSCH: Physical Downlink Shared Channel

[0071] - PUSCH: Physical Uplink Shared Channel

[0072] - CSI: Channel State Information

[0073] - RRM: Radio Resource Management

[0074] - SCS: Subcarrier Spacing

[0075] - RLM: Radio Link Monitoring

[0076] - DCI: Downlink Control Information

[0077] - CAP: Channel Access Procedure

[0078] - Ucell: Unlicensed Cell

[0079] - TBS: Transport Block Size

[0080] - TDRA: Time Domain Resource Allocation

[0081] - SLIV: Start and Length Indicator Value (SLIV is a field that indicates the start symbol index and the number of symbols in the slot for the PDSCH and / or PUSCH, and SLIV is carried on the PDCCH that schedules the corresponding PDSCH and / or PUSCH).

[0082] - BWP: Bandwidth component (A BWP can consist of consecutive resource blocks (RBs) in the frequency domain, which can correspond to a set of parameters (e.g., subcarrier spacing, cyclic prefix (CP) length, slot / mini-slot duration, etc.). Additionally, multiple BWPs can be configured on a single carrier (the number of BWPs per carrier can be finite), but the number of active BWPs per carrier can be limited (e.g., one).

[0083] - CORESET: Control Resource Set (CORESET refers to the time-frequency resource area that can transmit PDCCH, and the number of CORESETs per BWP can be limited.)

[0084] - REG: Resource Element Group

[0085] - SFI: Slot Format Indicator (SFI is an indicator that indicates the DL / UL direction at the symbol level in a specific time slot, and SFI is transmitted via the group common PDCCH.)

[0086] - COT: Channel Occupancy Time

[0087] - SPS: Semi-persistent scheduling

[0088] - QCL: Quasi-colocation (The QCL relationship between two reference signals can represent that QCL parameters such as Doppler shift, Doppler spread, average delay, delay spread, and spatial Rx parameter obtained from one reference signal can be applied to another reference signal (or the antenna port of that RS). In NR systems, four QCL types are defined as follows: "Type A": {Doppler shift, Doppler spread, average delay, delay spread}, "Type B": {Doppler shift, Doppler spread}, "Type C": {Doppler shift, average delay}, "Type D": {spatial Rx parameter}. For any DL RS antenna port, the first DL RS can be set to reference QCL type X (X=A, B, C, or D), and the second DL RS can be set to reference QCL type Y (Y=A, B, C, or D, but X≠Y).)

[0089] - TCI: Transmission Configuration Indicator (A TCI state contains the QCL relationship between one or more DL RSs, such as the DM-RS port of PDSCH, the DM-RS port of PDCCH, or the CSI-RS port of CSI-RS resources. For the "Transmission Configuration Indicator" field in the DCI of the scheduling PDSCH, the TCI state index corresponding to each code point including this field is activated via MAC CE, and the TCI state setting for each TCI state index is set via RRC signaling. In the Rel-16 NR system, the corresponding TCI state is set between DL RSs, but future versions may allow setting between DL RSs and UL RSs or between UL RSs. Examples of UL RSs are SRS, PUSCH DM-RS, PUCCH DM-RS, etc.)

[0090] - SRI: SRS Resource Indicator (Indicates one of the SRS resource index values ​​set in the "SRS Resource Indicator" field of the DCI for scheduling PUSCH. When transmitting PUSCH, the terminal may use the same spatial domain transmission filter used for transmitting and receiving reference signals associated with the corresponding SRS resource. In this case, the reference RS is set by RRC signaling via the SpatialRelationInfo parameter for each SRS resource, and SS / PBCH blocks, CSI-RS, or SRS can be set as the reference RS.)

[0091] - TRP: Transmitting and Receiving Point

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

[0093] Figure 1 This is a diagram illustrating the physical channels used in a 3GPP NR system and the typical signal transmission methods using them.

[0094] Upon power-on or when the UE initially enters a cell, the UE performs an initial cell search involving synchronization with the BS in step S101. For the initial cell search, the UE receives a Synchronization Signal Block (SSB). The SSB includes a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), and a Physical Broadcast Channel (PBCH). The UE synchronizes with the BS and obtains information such as the cell identifier (ID) based on the PSS / SSS. The UE can then receive broadcast information from the cell on the PBCH. Furthermore, the UE can check the downlink channel state by receiving a Downlink Reference Signal (DL RS) during the initial cell search.

[0095] After the initial cell search, in step S102, the UE can obtain more specific system information by receiving the Physical Downlink Control Channel (PDCCH) and receiving the Physical Downlink Shared Channel (PDSCH) based on the information in the PDCCH.

[0096] Subsequently, to establish a connection with the eNB, the UE can perform a random access procedure with the eNB (S103 to S106). During the random access procedure, the UE can transmit a preamble on the Physical Random Access Channel (PRACH) (S103) and receive the PDCCH and the Random Access Response (RAR) for the preamble on the PDSCH associated with the PDCCH (S104). The UE can transmit the Physical Uplink Shared Channel (PUSCH) using the scheduling information in the RAR (S105) and perform a contention resolution procedure including receiving the PDCCH signal and the corresponding PDSCH signal (S106).

[0097] Following the above process, during general UL / DL signal transmission, the UE can receive PDCCH and / or PDSCH from the BS (S107) and send PUSCH and / or Physical Uplink Control Channel (PUCCH) to the BS (S108). The control information sent by the UE to the BS is typically called Uplink Control Information (UCI). UCI includes Hybrid Automatic Repeat and Request Acknowledgment / Negative Acknowledgment (HARQ-ACK / NACK), Scheduling Request (SR), Channel Quality Indicator (CQI), Precoding Matrix Index (PMI), Rank Indicator (RI), etc. UCI is usually sent periodically on the PUCCH. However, if control information and service data should be sent simultaneously, they can be sent on the PUSCH. Additionally, UCI can be sent aperiodically on the PUSCH when a request / command is received from the network.

[0098] Figure 2 The structure of an NR radio frame to which this disclosure applies is illustrated. (Refer to...) Figure 2Radio frames can be used for UL and DL transmissions in NR. A radio frame is 10 ms long and can be defined by two 5 ms half-frames. HF can include five 1 ms subframes. Subframes can be divided into one or more time slots, and the number of time slots in SF can be determined based on the subcarrier spacing (SCS). Depending on the cyclic prefix (CP), each time slot can include 12 or 14 OFDM (A) symbols.

[0099] Table 1 shows how the number of symbols per slot, the number of slots per frame, and the number of slots per subframe vary with SCS when using normal CP.

[0100] [Table 1] N slot symb Number of symbols in a time slot N frame,u slot Number of time slots in a frame N subframe,u slot Number of time slots in a subframe Table 2 below lists the number of symbols per slot, the number of slots per frame, and the number of slots per subframe under the SCS in the ECP case.

[0101] [Table 2]

[0102] The frame structure is just an example, and the number of subframes, time slots, and symbols in a frame can vary.

[0103] In NR systems, different OFDM(A) parameter sets (e.g., SCS, CP length, etc.) can be configured for multiple cells aggregated for a single UE. Therefore, the (absolute) duration of time resources (e.g., SF, time slots, or TTI) comprising the same number of symbols can differ between aggregated cells (for ease of description, such time resources are often referred to as time units (TUs)).

[0104] Figure 3 The slot structure of the NR frame to which this disclosure applies is illustrated. (Refer to...) Figure 3A time slot comprises multiple symbols in the time domain. For example, a time slot may include 14 symbols in a normal CP and 12 symbols in an extended CP. Alternatively, a time slot may include 7 symbols in a normal CP and 6 symbols in an extended CP. A carrier may include multiple subcarriers in the frequency domain. A resource block (RB) is defined as multiple consecutive subcarriers (e.g., 12 subcarriers) in the frequency domain. A bandwidth portion (BWP) may be defined as multiple consecutive (P) RBs in the frequency domain, and a BWP may correspond to a set of parameters (e.g., SCS, CP length, etc.). A carrier may include up to N (e.g., 5) BWPs. Data communication can take place in an active BWP. In the resource grid, each element may be called a resource element (RE) and may be mapped to a complex symbol.

[0105] Figure 4 This is a diagram illustrating an exemplary mapping of physical channels in a time slot to which the implementation method applies. A time slot may include all DL control channels, DL or UL data, and UL control channels. For example, the first N symbols of a time slot may be used to transmit DL control channels (hereinafter referred to as the DL control area), and the last M symbols of the time slot may be used to transmit UL control channels (hereinafter referred to as the UL control area). Each of N and M is an integer equal to or greater than 0. The resource area between the DL control area and the UL control area (hereinafter referred to as the data area) may be used to transmit DL data or UL data. There may be time gaps between the control area and the data area for DL-to-UL or UL-to-DL handover. PDCCH can be transmitted in the DL control area, and PDSCH can be transmitted in the DL data area. Some symbols at the DL-to-UL handover time in a time slot may be used as time gaps.

[0106] The PDCCH transmits the DCI. For example, the PDCCH (i.e., the DCI) may carry information about the transmission format and resource allocation of the DL-SCH, resource allocation information for the Uplink Shared Channel (UL-SCH), paging information for the PCH, system information for the DL-SCH, resource allocation information for higher-layer control messages (e.g., RARs transmitted on the PDCCH), transmission power control commands, information about enabling / releasing configured schedules, etc. The DCI includes Cyclic Redundancy Check (CRC). The CRC is masked using various identifiers (IDs) (e.g., Radio Network Temporary Identifiers (RNTIs)) depending on the owner or purpose of the PDCCH. For example, if the PDCCH is used for a specific UE, the CRC is masked using the UE ID (e.g., Cell-RNTI (C-RNTI)). If the PDCCH is used for paging messages, the CRC is masked using the Paging-RNTI (P-RNTI). If the PDCCH is used for system information (e.g., System Information Block (SIB)), the CRC is masked by the System Information RNTI (SI-RNTI). When the PDCCH is used for RAR, the CRC is masked by the Random Access-RNTI (RA-RNTI).

[0107] To receive PDCCH, a terminal can monitor (e.g., blindly decode) the PDCCH candidate set in a CORESET. A PDCCH candidate represents a CCE monitored by the terminal for PDCCH reception / detection. PDCCH monitoring can be performed on one or more CORESETs on the active DL BWP of each active cell where PDCCH monitoring is enabled. The PDCCH candidate set monitored by the terminal is defined as a PDCCH search space (SS) set. The SS set can be a common search space (CSS) set or a UE-specific search space (USS) set.

[0108] Table 3 shows the characteristics of each SS.

[0109] [Table 3]

[0110] SS sets can be established via system information (e.g., MIB) or terminal-specific upper-layer (e.g., RRC) signaling. Each DL BWP in the serving cell can establish no more than S (e.g., 10) SS sets. For example, the following parameters / information can be provided for each SS set. Each SS set is associated with one CORESET, and each CORESET configuration can be associated with one or more SS sets.

[0111] - searchSpaceId: Represents the ID of the SS set.

[0112] - controlResourceSetId: Indicates the CORESET associated with the SS set.

[0113] - monitoringSlotPeriodicityAndOffset: Indicates the PDCCH monitoring period interval (in time slots) and the PDCCH monitoring interval offset (in time slots).

[0114] - monitoringSymbolsWithinSlot: Indicates the first OFDMA symbol used for PDCCH monitoring within a slot where PDCCH monitoring is enabled. It is indicated via a bitmap, where each bit corresponds to each OFDMA symbol within the slot. The MSB of the bitmap corresponds to the first OFDMA symbol in the slot. The OFDMA symbol corresponding to a bit with a value of 1 corresponds to the first symbol in the CORESET of the slot.

[0115] - nrofCandidates: Indicates the number of PDCCH candidates per AL = {1, 2, 4, 8, 16} (e.g., one of the values ​​0, 1, 2, 3, 4, 5, 6, 8).

[0116] - searchSpaceType: Indicates whether the SS type is CSS or USS.

[0117] - DCI format: Indicates the DCI format of the PDCCH candidate.

[0118] Based on the CORESET / SS set settings, the terminal can monitor PDCCH candidates in one or more SS sets within a time slot. The timing (e.g., time / frequency resources) used to monitor PDCCH candidates is defined as a PDCCH (monitoring) opportunity. One or more PDCCH (monitoring) opportunities can be configured within a time slot.

[0119] [Table 4]

[0120] 1) PUCCH format 0 (PF0)

[0121] - Supported UCI payload size: up to K bits (e.g., K=2)

[0122] - The number of OFDM symbols that make up a single PUCCH: 1 to X symbols (e.g., X=2)

[0123] - Transmission structure: Consists only of UCI signals, without DM-RS, and the UCI state is transmitted by selecting and transmitting one of multiple sequences.

[0124] 2) PUCCH Format 1 (PF1)

[0125] - Supported UCI payload size: up to K bits (e.g., K=2)

[0126] - Number of OFDM symbols that make up a single PUCCH: Y to Z symbols (e.g., Y=4, Z=14)

[0127] - Transmission Structure: UCI and DM-RS are composed of different OFDM symbols in TDM form, where UCI multiplies certain sequences with modulation (e.g., QPSK) symbols. Cyclic Shift (CS) / Orthogonal Cover Code (OCC) is applied to both UCI and DM-RS to support CDM (following PUCCH Format 1) between multiple PUCCH resources (within the same RB).

[0128] 3) PUCCH Format 2 (PF2)

[0129] - Supported UCI payload size: more than K bits (e.g., K=2)

[0130] - The number of OFDM symbols that make up a single PUCCH: 1 to X symbols (e.g., X=2)

[0131] - Transmission Structure: DMRS and UCI are configured / mapped in FDM form within the same symbol and transmitted by applying an IFFT without DFT to only the encoded UCI bits.

[0132] 4) PUCCH Format 3 (PF3)

[0133] - Supported UCI payload size: more than K bits (e.g., K=2)

[0134] - Number of OFDM symbols that make up a single PUCCH: Y to Z symbols (e.g., Y=4, Z=14)

[0135] - Transmission Structure: DMRS and UCI are configured / mapped to different symbols in TDM form and transmitted by applying a DFT to the enhanced UCI bits. Multiplexing is supported for multiple terminals by applying the OCC in the DFT preamble to the UCI and applying the CS (or IFDM mapping) to the DMRS.

[0136] 5) PUCCH Format 4 (PF4)

[0137] - Supported UCI payload size: more than K bits (e.g., K=2)

[0138] - Number of OFDM symbols that make up a single PUCCH: Y to Z symbols (e.g., Y=4, Z=14)

[0139] - Transmission Structure: DMRS and UCI are configured / mapped to different symbols in TDM format and transmitted without multiplexing between terminals by applying DFT to the encoded UCI bits.

[0140] DRX (Discontinuous Receiver) Operation

[0141] The UE uses Discontinuous Reception (DRX) in the RRC_IDLE and RRC_INACTIVE states to reduce power consumption. When DRX is configured, the UE performs DRX operations according to the DRX configuration information.

[0142] When the UE operates based on DRX, the UE repeatedly turns on / off to receive data. For example, when DRX is configured, the UE only attempts to receive / detect PDCCH (e.g., PDCCH monitoring) during a predetermined time interval (e.g., on), and does not attempt to receive PDCCH during the remaining time period (e.g., off / sleep).

[0143] The period during which the UE should attempt to receive the PDCCH is called the on-duration, and this on-duration is defined once per DRX cycle. The UE can receive DRX configuration information from the gNB via RRC signaling, and the reception of the (long) DRX command MAC CE is considered as DRX operation.

[0144] DRX configuration information can be included in MAC-CellGroupConfig. MAC-CellGroupConfig is used to configure MAC parameters for cell groups, including DRX.

[0145] DRX (Discontinuous Receive) refers to an operating mode that enables the UE (User Equipment) to reduce battery consumption by discontinuously receiving / monitoring the downlink channel. In other words, a UE configured with DRX can reduce power consumption by discontinuously receiving DL signals. DRX operation is performed in a DRX cycle that is periodically repeated for an indicated on-duration period. The DRX cycle includes an on-duration period and a sleep-duration period (or an opportunity for DRX). The on-duration period indicates the time interval during which the UE monitors the PDCCH in order to receive the PDCCH. DRX can be performed in the RRC (Radio Resource Control)_IDLE state (or mode), RRC_INACTIVE state (or mode), or RRC_CONNECTED state (or mode). In the RRC_IDLE and RRC_INACTIVE states, DRX is used for discontinuous reception of paging signals.

[0146] - RRC_Idle state: The state in which no radio connection (RRC connection) has been established between the base station and the UE.

[0147] - RRC inactive state: A radio connection (RRC connection) has been established between the base station and the UE, but the radio connection is deactivated.

[0148] - RRC_Connected status: The status of a radio connection (RRC connection) established between the base station and the UE.

[0149] DRX is basically divided into Idle Mode DRX, Connected DRX (C-DRX), and Extended DRX. DRX used in the RRC idle state is called Idle Mode DRX, and DRX used in the RRC connected state is called Connected Mode DRX (C-DRX).

[0150] eDRX (Extended / Enhanced DRX) is a mechanism that extends the loop of Idle Mode DRX and C-DRX. In Idle Mode DRX, whether eDRX is allowed can be configured based on system information (e.g., SIB1).

[0151] SIB1 can include the eDRX enable parameter. The eDRX enable parameter is a parameter that indicates whether idle mode extended DRX is allowed.

[0152] (1) Idle mode DRX

[0153] In idle mode, the UE can use DRX to reduce power consumption. A paging opportunity (PO) can be a time interval (e.g., a time slot or subframe) during which a Physical Downlink Control Channel (PDCCH) based on a Paging-Radio Network Temporary Identifier (P-RNTI) can be transmitted. The P-RNTI-based PDCCH can address / schedule paging messages. For P-RNTI-based PDCCH transmissions, the PO can indicate the first subframe used for PDCCH repetition.

[0154] A paging frame (PF) is a radio frame that may include one or more paging opportunities. When DRX is used, the UE can be configured to monitor only one PO per DRX cycle. The PF, PO, and / or PNB can be determined based on DRX parameters provided via network signaling (e.g., system information).

[0155] In the following text, “PDCCH” may refer to MPDCCH, NPDCCH, and / or normal PDCCH. In the following text, “UE” may refer to MTC UE, BL (Bandwidth Reduction Low Complexity) / CE (Coverage Enhancement) UE, NB-IoT UE, RedCap UE, normal UE, and / or IAB-MT (Mobile Terminal).

[0156] Figure 5 This is a flowchart illustrating an example of a method for performing an idle mode DRX operation.

[0157] The UE receives idle mode DRX configuration information from the base station via higher-layer signaling (e.g., system information) (S110).

[0158] Furthermore, the UE determines the PF (paging frame) and PO (paging opportunity) for monitoring the physical downlink control channel (e.g., PDCCH) during the paging DRX cycle based on the idle mode DRX configuration information (S120). In this case, the DRX cycle includes an on duration and a sleep duration (or an opportunity for DRX).

[0159] In addition, the UE monitors the PDCCH (S130) within the determined PO of the PF. For each paging DRX cycle, the UE monitors only one time interval (PO). For example, the time interval can be a time slot or a subframe.

[0160] Additionally, if the UE receives a PDCCH scrambled by P-RNTI (more precisely, the CRC of the PDCCH) during the on-time duration (i.e., if paging is detected), the UE can switch to connected mode and send or receive data with the base station.

[0161] Figure 6 This is a diagram illustrating an example of DRX operation in idle mode.

[0162] Reference Figure 6 If there is service (data) directed to a UE in the RRC_Idle state (hereinafter referred to as "idle state"), then a paging will be performed on the corresponding UE.

[0163] Therefore, the UE wakes up and monitors the PDCCH in each (paging) DRX cycle.

[0164] If paging is present, the UE switches to connected state and receives data. Otherwise, the UE can re-enter sleep mode.

[0165] (2) Connectivity Mode DRX (C-DRX)

[0166] C-DRX is a DRX used in RRC connection mode. C-DRX DRX cycles can be configured with short DRX cycles and / or long DRX cycles. Short DRX cycles are optional.

[0167] If C-DRX is configured, the UE performs PDCCH monitoring during the on-duration period. If a PDCCH is successfully detected during PDCCH monitoring, the UE operates (or runs) an inactivity timer and remains awake. Conversely, if a PDCCH is not successfully detected during PDCCH monitoring, the UE enters a sleep state after the on-duration period ends.

[0168] If C-DRX is configured, PDCCH reception timing can be configured discontinuously based on the C-DRX configuration (e.g., time slots with a PDCCH search space / candidate). Conversely, if C-DRX is not configured, PDCCH reception timing can be configured continuously based on the PDCCH search space configuration (e.g., time slots with a PDCCH search space / candidate). Furthermore, PDCCH monitoring can be restricted to time intervals configured as measurement gaps, regardless of the C-DRX configuration.

[0169] Figure 7 This is a flowchart illustrating an example of a method for performing a C-DRX operation.

[0170] The UE receives RRC signaling (e.g., MAC-MainConfig IE) from the base station, which includes DRX configuration information (S310). The DRX configuration information may include the following information.

[0171] - on-duration: The duration for which the UE waits to receive the PDCCH after waking up. If the UE successfully decodes the PDCCH, the UE remains awake and starts the drx-inactivity timer.

[0172] - onDurationTimer: The duration at which the DRX cycle begins. For example, the duration can refer to the time interval to be continuously monitored at the beginning of the DRX cycle, which can be expressed in milliseconds (ms).

[0173] - drx-InactivityTimer: PDCCH indicates the duration following the PDCCH timing of a new UL or DL ​​transmission for a MAC entity. For example, the duration can be a time interval in milliseconds after the UE decodes a PDCCH that includes scheduling information. In other words, the duration refers to the time the UE waits for another PDCCH to be successfully decoded after decoding the first one. If no other PDCCH is detected within the corresponding duration, the UE transitions to sleep mode.

[0174] Apart from the PDCCH used for retransmission, the UE restarts the drx-inactivity timer only after successfully decoding the PDCCH used for the initial transmission.

[0175] - drx-RetransmissionTimer: For DL, the maximum duration before a DL retransmission is received; for UL, the maximum duration before a permission to retransmit a UL is received. For example, for UL, drx-RetransmissionTimer indicates the number of time slots in the bandwidth portion (BWP) of the transport block (TB) to be retransmitted. For DL, drx-RetransmissionTimer indicates the number of time slots in the BWP of the TB to be retransmitted.

[0176] - longDRX-Cycle: Enables the duration of the event.

[0177] - drxStartOffset: The subframe number at which the DRX loop begins.

[0178] - drxShortCycleTimer: The UE should follow the duration of the short DRX cycle; - shortDRX-Cycle: The number of times the DRX loop operates up to the number of drxShortCycleTimers when Drx-InactivityTimer terminates. - drx-SlotOffset: The delay before drx-onDurationTimer starts. For example, the delay can be expressed in milliseconds (ms), and more specifically, in multiples of 1 / 32 ms.

[0179] - Activity time: The total duration for which the UE monitors the PDCCH, which may include (a) the "on-duration" of the DRX cycle, (b) the time during which the UE performs continuous reception while the drx-inactivity timer has not expired, and (c) the time during which the UE performs continuous reception while waiting for a retransmission opportunity.

[0180] Specifically, when DRX cyclic is configured, the active time of the serving cell in a DRX group includes the following items.

[0181] - (a) drx-onDurationTimer configured for the DRX group or (b) drx-InactivityTimer is running; or

[0182] - (c) Running drx-RetransmissionTimerDL or drx-RetransmissionTimerUL on any serving cell in the DRX group; or

[0183] - (d) Ra-ContentionResolutionTimer or msgB-ResponseWindow is running; or

[0184] - (e) The scheduling request was sent on the PUCCH and is pending; or

[0185] - (f) After successfully receiving a random access response for a contention-based random access preamble that was not selected by the MAC entity, a PDCCH indicating a new transmission addressing to the MAC entity has not yet been received.

[0186] In addition, if DRX “on” is configured via DRX command of MAC CE (command element) (S320), the UE monitors PDCCH during the on duration of the DRX cycle based on the DRX configuration (S330).

[0187] Figure 8 This is a diagram illustrating an example of C-DRX operation.

[0188] Reference Figure 8 When the UE receives scheduling information (e.g., DL assignment or UL permission) in the RRC_Connected state (hereinafter referred to as the connected state), the UE runs the DRX inactivity timer and the RRC inactivity timer.

[0189] DRX mode begins after the DRX inactivity timer expires. The UE wakes up during the DRX cycle and monitors the PDCCH for a predetermined time (duration timer).

[0190] In this scenario, if short DRX is configured, when the UE initiates DRX mode, it first starts with a short DRX cycle and then transitions to a long DRX cycle after the short DRX cycle terminates. The long DRX cycle is a multiple of the short DRX cycle. During the short DRX cycle, the UE wakes up more frequently. After the RRC inactivity timer expires, the UE transitions to an idle state and performs idle mode DRX operations.

[0191] Figure 9 An example of a DRX cycle is provided. To conserve UE power, C-DRX operation has been introduced. If the UE does not receive a PDCCH within the on-duration defined for each DRX cycle, the UE enters sleep mode until the next DRX cycle and does not perform any transmit / receive operations.

[0192] On the other hand, when the UE receives the PDCCH during the on-duration period, the active time can continue (or be extended) based on the operation of the inactivity timer, retransmission timer, etc. If the UE does not receive additional data during the active time, the UE can operate in sleep mode until the next DRX operation.

[0193] In NR, a Wake-up Signal (WUS) has been introduced to provide additional power-saving gains beyond existing C-DRX operations. The WUS can be used to notify the UE whether PDCCH monitoring needs to be performed on-duration in each DRX cycle (or multiple DRX cycles). If the UE does not detect the WUS at the specified or indicated WUS timing, the UE can remain in sleep mode for one or more DRX cycles associated with the corresponding WUS without performing PDCCH monitoring.

[0194] (3) Wake-up signal (DCI format 2_6)

[0195] Figure 10 This is a diagram illustrating a method for monitoring DCI format 2_6.

[0196] According to the power-saving technology of the Rel-16 NR system, when performing DRX operation, the UE can be notified via DCI format 2_6 whether the UE needs to be woken up for each DRX cycle.

[0197] Reference Figure 10 For DCI format 2_6, the timing of PDCCH monitoring can be determined by the ps offset indicated by the network and the time interval reported by the UE. In this case, the time interval reported by the UE can be interpreted as the preparation period required for operation after the UE is woken up.

[0198] Reference Figure 10 The base station (BS) can provide the UE with a search space (SS) set configuration capable of monitoring DCI format 2_6. Based on the corresponding SS set configuration, DCI format 2_6 can be monitored in consecutive time slots, as long as the duration falls within the monitoring period interval.

[0199] In the DRX configuration, the monitoring window used to monitor DCI format 2_6 can be determined by the start time of the DRX cycle (e.g., the time when the on-duration timer starts) and the ps offset configured by the BS. Additionally, PDCCH monitoring may not be required during the time intervals reported by the UE. Therefore, the timing of the SS set monitoring that the UE actually performs can be determined as the first complete duration within the monitoring window (i.e., Figure 10 (Actual monitoring timing).

[0200] If the UE detects DCI format 2_6 in the monitoring window based on the ps offset configuration, the BS can notify the UE whether to wake up in the next DRX cycle.

[0201] Network Energy Saving (NES)

[0202] Network energy efficiency (BS) can help build environmentally friendly networks by reducing carbon emissions and can help reduce the operating expenses (OPEX) of communication operators, and is considered important in wireless communication systems (including 3GPP). Specifically, due to the need for high transmission rates due to the introduction of 5G communications, BS needs to include a greater number of antennas and provide services through wider bandwidth and frequency bands. Therefore, according to recent studies, the energy cost of BS reaches up to 20% of the total OPEX. Due to this increased interest in BS energy efficiency, a new research project entitled "Research on Network Energy Efficiency" was approved in 3GPP NR Release 18.

[0203] In detail, in the corresponding project, the following enhancement technologies have been considered to improve the energy-saving capabilities of the BS in both transmission and reception.

[0204] - Methods for more precisely adjusting transmission and / or reception dynamically and / or semi-statically, and methods for achieving more efficient operation through potential UE support / feedback and potential UE support information in one or more network power-saving techniques in the time, frequency, spatial, and power domains.

[0205] The BS identifies the NES solution to be applied. The NES solution may involve control over signal transmission and reception (e.g., its on / off state), beam operation, handover procedures, channel measurement and reporting, etc. The NES solution to be applied can be adaptively selected based on current conditions (e.g., cell load level and characteristics of connected UEs), or it may be predefined. The BS that has identified the NES solution can execute signaling for the NES. Specific signaling procedures can vary depending on the identified NES solution. For example, the BS can send common information related to the NES solution, send configuration information required for NES operation to at least one UE, or send control information related to the progress of NES operation to at least one UE. Additionally, the BS can receive NES-related capability information from at least one UE. Subsequently, the BS executes operations for the NES. At this time, the BS can perform operations for the NES based on the executed signaling. That is, based on the system information, configuration information, and control information delivered via signaling, the BS can set the transmission / reception of specific signals to an on / off state, set elements in the spatial domain to an on / off state, or adjust resources used for transmitting / receiving measurement signals.

[0206] Examples of applicable NES solutions are as follows.

[0207] - In-system energy saving scheme: RAN nodes can request neighboring RAN nodes to switch at least one SSB beam to its deactivated cell, or they can use a limited set of beams to perform paging for inactive UEs (e.g., stationary UEs).

[0208] - Inter-system energy saving solution: NG-RAN nodes with capacity-enhancing cells can autonomously switch cells to an inactive state.

[0209] - SSB-less SCell Solution: If no SSB configuration or SSB-based RRM measurement timing configuration (SMTC) is provided for the SCell, the UE can obtain timing references and AGC sources from another serving cell. In FR1 or FR2, the BS can configure in-band CA or inter-band CA including the SCell without SSB transmission. In this case, SSB / SIB transmission can be triggered by the UE's wake-up signal (WUS). Therefore, the period of common channels / signals (such as SSB) can be increased, allowing the BS to remain in sleep mode for a longer period.

[0210] - Cell DTX / DRX Solution: To reduce the BS's DL transmission / UL reception activity time, periodic cell DTX / DRX modes (e.g., active and inactive durations) can be jointly configured for UEs within cells with corresponding characteristics. Here, cell DTX mode and cell DRX mode can be configured and activated separately. Up to two cell DTX / DRX modes can be configured per MAC entity. When cell DTX is configured and activated, at least one of monitoring SPS timing and monitoring PDCCH can be suspended during the cell DTX inactive duration. When cell DRX is configured and activated, at least one of transmissions on CG resources or SR transmissions can be suspended during the cell DRX inactive duration. Cell DTX / DRX can be activated / deactivated via RRC signaling or L1 group common signaling.

[0211] -- Parameters such as activity duration and cycle can be configured for cell DTX / DRX. Activity duration is the period during which the UE waits to receive a PDCCH or SPS and sends an SR or CG, and cycle specifies the periodic repetition of active and inactive durations. Parameters such as activity duration and cycle are common when both cell DTX and cell DRX are configured. In cases where the BS identifies emergency calls or public safety-related services (e.g., MPS or MCS), the network can release or deactivate the cell DTX / DRX configuration without affecting service. Additionally, the activity duration of the UE's connection mode DRX needs to at least partially overlap with the activity duration of the cell DTX / DRX. For example, the UE's connection mode DRX cycle can be a multiple of the cell DTX / DRX cycle, or vice versa.

[0212] - Conditional Handover (CHO) Solution: When applying NES technology (e.g., when a cell is activated or deactivated via DTX / DRX), a CHO procedure is used to determine the handover execution by the UE. In this case, the UE can use an NES-specific CHO event to execute a CHO for a candidate cell. For this purpose, receiving an activation DCI indicating the CHO conditions configured by the NES event can be used as an additional triggering condition.

[0213] - Spatial and Power Domain Adaptation Solution: To assist gNBs in transceiver silence and / or transmit power adaptation, the UE can be configured to report multiple CSI entries in multiple sub-configuration CSI reports. Each sub-configuration corresponds to the spatial domain adaptation mode (e.g., a subset of available spatial elements) and / or the power offset between the data channel (e.g., PDSCH) and the CSI-RS. Depending on the application of the spatial and power domain adaptation solution, CSI configuration, measurement, and / or reporting operations may be affected.

[0214] Figure 11 This diagram illustrates a method for communication between the BS and UE based on cell DRX / DTX.

[0215] To enable BS to operate in sleep mode for relatively long periods without frequent wake-ups, BS DTX / DRX has been proposed for NES purposes. Under low system load conditions, the BS can reduce energy consumption by using DTX transmissions by configuring cell DTX and configuring the duration of UE C-DRX activation during the cell DTX activity period.

[0216] Reference Figure 11The BS sends system information to the UE (S111), and the UE identifies information related to cell DTX / DRX. For example, the system information may include a Master Information Block (MIB) and System Information Block 1 (SIB1). Regarding NES technology, as shown in Table 5 below, the MIB may include information related to cell prohibition (e.g., cellBarred), and SIB1 may include information related to cell prohibition status (e.g., cellBarredNES). Specifically, when cellBarred included in the MIB is set to a value indicating that the cell is not prohibited (e.g., notBarred), the UE can determine that the cell is not prohibited, regardless of whether it supports NES cell DTX / DRX. On the other hand, when cellBarred included in the received MIB is set to a value indicating that the cell is prohibited (e.g., prohibited), a UE that does not support NES cell DTX / DRX can determine that the cell is prohibited. However, when the UE has the capability to support NES cell DTX / DRX, the UE can check SIB1 to determine the cell prohibition status. If cellBarred is set to disabled in the MIB and cellBarredNES does not exist in SIB1, a UE supporting NES cell DTX / DRX can treat the cell as disabled and perform cell reselection to another cell. On the other hand, if cellBarred is set to disabled in the MIB and cellBarredNES is included in SIB1, a UE supporting NES cell DTX / DRX can determine that the cell is not disabled.

[0217] [Table 5]

[0218] Assume the UE has the capability to support NES cell DTX / DRX, and cellBarred in the MIB is set to... notBarred Or set to barred Furthermore, cellBarredNES is included in SIB1. In this case, the UE can perform a random access procedure to access the BS (S112), and then can communicate with the BS. At this time, the BS performs cell DTX / DRX operation and sends configuration information related to the cell DTX / DRX operation to the UE (S113). Configuration information related to the cell DTX / DRX operation (e.g., CellDTXDRX-Config This includes at least one parameter related to cell DTX / DRX. For example, configuration information related to cell DTX / DRX operation (e.g., CellDTXDRX-ConfigThis may include at least one of the following: start duration timer, cycle start offset, time slot offset, configuration type (e.g., DTX, DRX, or DTX-DRX), and DTX / DRX activation status (e.g., active, inactive). Additionally, the configuration information may also include information for receiving and interpreting control information related to cell DRX / DRX (e.g., DCI-related information) (refer to TS 38.331). CellDTXDRX- Config ).

[0219] Subsequently, the BS sends control information related to cell DTX / DRX to the UE (S115). The control information related to cell DTX / DRX may include a DCI with a specified format (e.g., format 2_9). When an operation against the serving cell is performed based on at least one of cell DTX operation and cell DRX operation, configuration information (e.g., ...) is provided. cellDTXDRX-Config During configuration, the UE can use higher-layer parameters (e.g., SearchSpace This can be used to identify the search space set (e.g., the Type3-PDCCH CSS set) for monitoring PDCCHs carrying control information in a specified format during the activity period, and can be done through higher-level parameters (e.g., positionInDCI-cellDTRX The UE can then obtain information about the serving cell within the control information. The UE can then obtain the control information based on the identified search space set and location.

[0220] Control information related to cell DTX / DRX can be used to indicate the activation or deactivation of cell DTX and / or cell DRX, and / or to provide NES mode indication, and may include at least one block including, for example, cell DTX / DRX indication and NES mode indication. In this case, when the serving cell is configured with a Supplementary Uplink (SUL) carrier, the indication of cell DTX / DRX activation or deactivation of cell DRX by the cell DTX / DRX indicator can be applied to both the UL carrier and the SUL carrier.

[0221] The DCI format 2_9 associated with this scheme can be defined as shown in Table 6 below.

[0222] [Table 6]

[0223] Subsequently, the UE and BS can perform communication based on cell DTX / DRX. Specifically, the BS can set signal transmission / reception to on / off states according to the configuration associated with cell DTX / DRX, and correspondingly, the UE can selectively monitor signals from the BS. During DTX off, the BS enters sleep mode to reduce power consumption. At this time, the BS DTX cycle can be aligned with the UE DRX cycle. The BS's DTX on can completely cover the UE's DRX on. In addition, for NES purposes, the BS can align Xn / NG transmissions and Uu transmissions. The DTX / DRX mechanism triggers the handover of the reference signal resource set, and the BS can perform sparse transmission or non-transmission of SSB, SIB, and CSI-RS quasi-sleep behavior to reduce power consumption. The UE can sparsely receive or not receive DL signals / channels according to the BS configuration. Once the BS DTX / DRX operation is triggered, the UE can discontinuously receive the corresponding CSI-RS, SSB, or PDCCH during the DTX / DRX off period.

[0224] Enhancements to NR network power efficiency

[0225] In the designated scenario (3GPP NR Release 19), an additional work item (WI) entitled "Enhancing Network Power Efficiency for NR" was approved. Specifically, as shown in Table 7, the following enhancement techniques are considered in the designated scenario.

[0226] [Table 7]

[0227] (1) On-demand SSB

[0228] Methods to reduce energy consumption can be discussed by having the BS transmit SSBs on a specific cell via an on-demand SSB procedure and suppressing SSB transmission on that cell when the on-demand SSB procedure is not involved. In existing NR systems, SSBs are always required to be transmitted periodically for purposes such as time / frequency synchronization and RRM measurements, which can make it difficult to reduce energy consumption even when the BS has no data to transmit or receive. In this regard, the BS can reduce energy consumption by suppressing SSB transmission and only transmitting SSBs when the on-demand SSB procedure is involved. The on-demand SSB procedure can be triggered by one of the following methods.

[0229] 1) The UE can send UL signals / channels (e.g., PRACH, PUCCH, PUSCH, SRS, etc. in an NR system) to request SSB transmission from the BS.

[0230] 2) BS (or TRP) #1 can request SSB transmission from BS (or TRP) #2 through the interface between BSs (e.g., the Xn interface in the NR system), backhaul signaling, etc.

[0231] 3) The SCell activation / deactivation signaling can be used to signal whether to send an SSB for the corresponding SCell.

[0232] Considering coexistence with existing NR UEs, the predetermined scenario (3GPP NR Release 19) is limited to on-demand SSB operations for connected mode UEs and SCells. However, in future versions or next-generation communication systems, on-demand SSB operations (for SSB transmissions on PCells) can be defined to consider inactive or idle mode UEs or initial access UEs. Furthermore, carrier aggregation (CA) including the corresponding SCell can be applied to both intra-band CA and inter-band CA, and SSBs transmitted on the corresponding SCell via the on-demand SSB procedure can be used for functions including time / frequency synchronization, L1 / L3 measurement, and SCell activation.

[0233] (2) On-demand SIB1 transmission

[0234] Figure 12 This is a diagram illustrating on-demand SIB1 transmission.

[0235] In existing NR systems, SIB1, containing system information and random access information for initial access or idle mode UE access to the cell, is always required periodically. Therefore, even when the BS has no data to send or receive, it is difficult to reduce power consumption. To address this issue, a method has been introduced whereby the BS suppresses SIB1 transmission and only transmits SIB1 during on-demand SIB1 procedures, which reduces BS power consumption. During on-demand SIB1 procedures, the BS's SIB1 transmission can be triggered by a UE sending a UL signal / channel (e.g., PRACH in an NR system). The following scenarios can be considered in this regard.

[0236] (1) Scene 1

[0237] Reference Figure 12 (a) The UE may receive an SSB (and / or other DL signals / channels) on cell #1 and recognize that SIB1 has not been transmitted on cell #1. In this case, the UE may send a signal requesting SIB1 (hereinafter, for ease of description, this signal is defined as a Wake-up Signal (WUS)) based on the information provided in the SSB (and / or other DL signals / channels) and / or predefined information to trigger the transmission of SIB1 associated with cell #1. The BS or cell #1 that has received the WUS may, in response to the WUS, transmit a specific DL signal / channel on cell #1 (or may not transmit a specific DL signal / channel), and may transmit SIB1 on cell #1.

[0238] (2) Scene 2

[0239] Reference Figure 12 (b) The UE may receive an SSB (and / or other DL signals / channels such as SIB1) on cell #1, identify that SIB1 is not being transmitted on cell #2, and attempt to camp on cell #2. In this case, the UE may, based on the information provided in the received SSB (and / or other DL signals / channels, such as SIB1) and / or predefined information, transmit a signal (e.g., WUS) on cell #1 requesting SIB1 related to cell #2, to trigger the transmission of SIB1 for cell #2. The BS that has received the WUS may, in response to the WUS (on cell #1 or cell #2), transmit a specific DL signal / channel (or may not transmit a specific DL signal / channel), and may transmit SIB1 for cell #2 on cell #1 or cell #2.

[0240] (3) Scene 3

[0241] Reference Figure 12 (c) The UE may receive an SSB (and / or other DL signals / channels such as SIB1) on cell #1, identify that SIB1 is not being transmitted on cell #2, and attempt to camp on cell #2. The UE may, based on information provided in the received SSB (and / or other DL signals / channels, such as SIB1) and / or predefined information, transmit a WUS (which is a request for SIB1 signal) on cell #2 to trigger the transmission of SIB1 for cell #2. The BS may, in response to the WUS, transmit a specific DL signal / channel on cell #2 (or may not transmit a specific DL signal / channel), and may transmit SIB1 for cell #2 on cell #2.

[0242] As mentioned above, methods to reduce BS / cell power consumption by decreasing the transmission frequency of common signals / channels (such as SSB, PRACH, and paging) can be discussed. As mentioned above, completely disabling SSB transmission can significantly reduce BS power consumption. However, from the UE's perspective, if there is no SSB available for performing functions such as time / frequency synchronization or RRM measurements, stable operation for cells that do not transmit SSBs may not be guaranteed. Considering this, it may be more appropriate to reduce BS / cell power consumption by changing the SSB transmission mode as needed, rather than completely disabling SSB transmission. Here, the SSB transmission mode can involve transmission periods, periods for each SSB candidate index, SSB candidate indices (indexes) transmitted within a transmission period, transmission power, etc.

[0243] Alternatively, in the case of contention-based random access related to PRACH resources, the BS may not know when the UE will send a PRACH. Therefore, the BS may need to continuously attempt to receive / monitor PRACH on the configured PRACH resources, which may increase the BS's energy consumption. Therefore, to promote energy saving for the BS, methods for adjusting the amount of PRACH resources can be considered. Here, the amount of PRACH resources can be adjusted by: adjusting the time period of the PRACH resources, pre-configuring PRACH resource sets #1 and #2, and then adjusting the resource amount by indicating whether to activate at least one set or by providing RACH (or PRACH) resources corresponding to each SSB index in a uniform or non-uniform manner.

[0244] Alternatively, in the case of paging, typically, paging frames (PF) and / or paging opportunities (PO) are distributed along the time axis within a DRX cycle (or paging cycle), and the UE attempts to receive the paging at a specific PF / PO derived from the formula based on its own ID. From the BS's perspective, if the BS aims to send paging messages to multiple UEs simultaneously, it must wake up frequently to send paging messages. In this case, to reduce BS power consumption, the PF and / or PO for paging reception can be arranged as close as possible together on the time axis, or they can be arranged on different frequency domain resources within the same time period.

[0245] As base stations (BSs) are required to support increasingly higher data rates, they must be equipped with more antennas and operate over wider bandwidths and frequency bands. According to recent research, the energy cost of BSs has reached 20% of total operating expenditures (OPEX). To build environmentally sustainable networks by reducing carbon emissions and to lower OPEX for telecom operators, energy efficiency for BSs has become a crucial consideration in wireless communication systems, including 3GPP systems.

[0246] Due to increased interest in network power saving, a new research project entitled "Research on Network Power Saving" was approved in the predetermined scenario (3GPP NR Release 18). The technologies specified through subsequent work projects include SSB-free SCell operation for FR1 and co-located cells with inter-band CA, improvements to the cell DTX / DRX mechanism (including alignment of cell DTX / DRX and UE DRX in RRC_CONNECTED mode), and inter-node information exchange for cell DTX / DRX. Additionally, these technologies include spatial and power domain techniques to achieve efficient adaptation of spatial elements, efficient adaptation of power offset values ​​between PDSCH and CSI-RS, mechanisms to prevent legacy UEs from camping in cells using NES technology in the predetermined scenario (Rel-18), improvements to the CHO procedure, inter-node beam activation and enhancement for limiting paging in confined areas, and compliance with RRM / RF core requirements.

[0247] Some technologies have been identified as beneficial through research, but have not yet been specified in 3GPP Rel-18. Therefore, 3GPP Rel-19 WI aims to employ additional technologies that can achieve network power-saving gains, targeting beneficial technologies researched in 3GPP Rel-18 but not yet adopted in the specification (e.g., on-demand SSB and on-demand SIB1 transmission, adaptation of common signal / channel transmission, etc.).

[0248] The following sections will describe in detail the dynamic RO adjustment method for BS energy saving, the method for indicating and / or configuring RO, and the method for determining the effectiveness of RO under dynamic RO adaptation.

[0249] PRACH adaptation in the time domain

[0250] Figure 13 This is a diagram illustrating a method for determining time resources for PRACH based on configuration information.

[0251] The UE can be configured with the necessary configuration information (e.g., time / frequency resources associated with PRACH) for PRACH transmission via UE-specific RRC signaling or SIB1 from the BS, and can transmit PRACH at RACH timing (RO). In this case, the BS may need to wake up at each RO to monitor for PRACH from the UE in order to receive the PRACH that the UE can transmit. Therefore, when the period of the RO configured for the UE is short, the BS's power consumption may be relatively greater than when the RO period is configured to be longer. However, if the RO period is configured to be too long for BS power saving, there may be no available RO resources near the time when the UE needs to transmit PRACH for cell access. In this case, because the UE may need to wait until the next RO resource becomes available before transmitting PRACH, the access latency when the UE accesses the cell may increase significantly. This cell access latency can lead to UE scheduling delays, potentially resulting in a significant degrade in UE performance.

[0252] Additionally, for the BS, depending on the cell conditions, there may be time intervals where the number of UEs in connected mode (or RRC connected mode) is small or there is temporarily no data activity. In this case, the BS can switch to sleep mode to save energy. However, it must frequently wake up to check for and monitor the presence of PRACHs sent by UEs in the periodically configured RO. In this situation, the BS cannot remain in sleep mode for an extended period, and therefore significant energy-saving gains may be difficult to anticipate. Therefore, in such cases (e.g., when the number of UEs in RRC connected mode is less than a certain threshold, or when data activity is less than or equal to a predetermined threshold), setting a longer RO period may be advantageous for BS energy saving. However, since only semi-static methods are currently available for changing configurations (such as the RO period), changing the RO period configuration (e.g., SI modification) may take a relatively long time. Due to the latency associated with performing such RO period reconfiguration (e.g., because the RO period must only be changed after the SI modification period), the BS may find it difficult to respond promptly to situations where energy saving can be achieved.

[0253] The following section proposes specific methods to solve these problems.

[0254] Method #1: Adjusting RO by configuring multiple PRACH configurations for the UE or configuring multiple RO configuration-related parameter sets within a single PRACH configuration and dynamically indicating handover (e.g., activation / deactivation) via (GC-)DCI and / or MAC-CE.

[0255] The UE can be configured to communicate with SIB1 ( rach-ConfigCommon ) or UE-specific RRC signaling ( RACH- ConfigGeneric This information pertains to the resources required for RACH transmission. For energy-saving purposes, the BS can configure one or more PRACH configurations for the UE, or multiple parameter sets within a single PRACH configuration to determine multiple RO configurations (hereinafter, for ease of description, PRACH configuration is simply referred to as RO configuration). Here, among multiple RO configurations, one RO configuration (or one parameter set among the RO configuration-related parameter sets) can be the default RO configuration for a legacy UE (UE that does not support R19 NES features). The UE can be configured with a sparse RO with a relatively long period using the default RO configuration, and can also be configured with a dense additional RO with a relatively short period using another RO configuration (or another parameter set). In this case, the BS can gain energy-saving benefits under normal conditions using the default RO configuration, and when congestion conditions are identified (such as RACH collisions and / or an increase in UE RACH retransmissions), it can dynamically instruct a switch to an RO configuration or parameter set (or its activation / deactivation) with a relatively dense additional RO with a shorter period via (GC-)DCI or MAC-CE.

[0256] Alternatively, the default RO configuration (or default parameter set) can be configured with relatively sparse ROs with short periods, while another RO configuration (or another parameter set) can be configured with additional sparse ROs with relatively long periods. In this case, the BS can operate normally based on the default RO configuration (or default parameter set) and, during periods when the number of connected mode UEs in the cell is small (e.g., less than a predetermined threshold) and / or data activity is low, can dynamically instruct a switch to another RO configuration (or another parameter set) with relatively sparse ROs with longer periods (or its activation / deactivation) via (GC-)DCI or MAC-CE, thereby achieving energy-saving gains.

[0257] For example, the BS can activate or deactivate another RO configuration (hereinafter, additional RO configuration or additional RO parameter set) based on the number of connected UEs and / or data activity. When the number of connected UEs is greater than or equal to a predetermined threshold (and / or when data activity is greater than or equal to a predetermined threshold), the BS can activate an additional RO configuration (or additional RO parameter set) with a relatively short period of additional RO. Conversely, when the number of connected UEs is less than a predetermined threshold (and / or when data activity is less than a predetermined threshold), the BS can deactivate the additional RO configuration or additional RO parameter set.

[0258] Here, an additional RO configuration (or additional RO parameter set) can be configured to have an additional RO with a shorter period than the default RO configuration. An additional RO can be an additional RO whose activation can be dynamically indicated for NES operations as described above. ROs associated with NES operations can be defined as additional ROs or NES ROs. For ease of description, they are referred to below as additional ROs (e.g., ROs configured by additional RO configuration / parameter set).

[0259] Specifically, sparse additional RO configurations or additional parameter sets with relatively long periods can have indexes different from the default RO configuration (or default RO parameter set). prach-Configuration Index. Depending on the predetermined scenario (Article 6.3.3.2 of TS 38.211), the random access preamble can be transmitted only in the time resources defined according to whether the operation is in FR1 or FR2 and according to the spectrum type (e.g., Tables 6.3.3.2-2 to 6.3.3.2-4 of TS 38.211). In this case, the time resource (e.g., RO) can be determined by the PRACH configuration index.

[0260] For example, when the PRACH configuration index is 9, it can be like this: Figure 13 The configuration shown targets time resources for ROs. Specifically, the SFNs that may have RACH slots (or slots configured with PRACH) can first be determined by "nSFNmodx=y", and the RACH slots (or slot numbers configured with PRACH) can be determined / specified by the slot number. Additionally, the number of RACH slots and the number of ROs within a slot can be set based on the 60-kHz subcarrier spacing (SCS). Therefore, the UE can have different PRACH configuration indices configured for multiple RO configurations (or for the corresponding RO configuration-related parameter set within a single RO configuration). For example, using the PRACH configuration index, the BS can configure different RO densities (e.g., RO periods) for the default RO configuration (or default RO parameter set) and additional RO configurations (or additional RO parameter sets). In this case, the appropriate RO configuration or RO configuration-related parameter set can be indicated via (GC-)DCI or MAC-CE based on conditions within the cell / BS. For example, a switch (or activation / deactivation) of an RO configuration with a relatively dense PRACH configuration index can be indicated to a RO configuration with a relatively sparse PRACH configuration index. Alternatively, the BS can indicate activation / deactivation of an additional RO configuration with a relatively dense PRACH configuration index based on the communication environment (e.g., the number of UEs, the frequency of RACH collisions, etc.).

[0261] For example, refer to Figure 13x can be 2 and y can be 1. In this case, since "nSFNmodx=y", an SFN with a RACH slot can exist with a period of 20 ms and can instruct the UE to switch to (or activate / deactivate) an RO with a PRACH configuration index corresponding to x=16 and y=1. In this case, since an SFN with a RACH slot exists with a period of 160 ms, a sparse RO configuration with a relatively long period can be indicated. Alternatively, even with the same values ​​of x and y, the RO period / mode can be adjusted by: multiple different RO configurations (or sets of RO configuration-related parameters) with different RO periods / modes, such as an RO configuration with a PRACH configuration index having fewer RACH slots in the slot number, or an RO configuration with fewer PRACH slots in the 60-kHz slot (e.g., a configuration where the RO exists only in one slot based on 120kHz), and dynamic indication of switching (or activating / deactivating) between multiple different RO configurations. Alternatively, the RO cycle / mode can be adjusted by the activation / deactivation indication of at least one of multiple RO configurations (or sets of RO configuration-related parameters) with different RO cycles / modes.

[0262] The UE can be configured via the BS with a specific set of RNTI / CORESET / Search Space (SS) for monitoring a (GC-)DCI indicating a specific RO configuration or a specific RO configuration-related parameter set. Here, the DCI can be a group common (GC) DCI of the DCI format 2_x series, or it can be a UE-specific DCI. Additionally, the (group common) MAC-CE can be used to indicate a specific RO configuration or a specific RO configuration-related parameter set. Alternatively, reserved bits of a specific DCI format (e.g., DCI format 1_0) can be used to indicate the (de)activation of the NES RO. For example, the UE can be configured with a specific set of RNTI / CORESET / SS for receiving a DCI (DCI format 1_0) indicating activation / deactivation only for the default RO configuration (or default RO parameter set) and additional RO configurations (or additional RO parameter sets) within additional RO configurations. The default RO configuration or default RO parameter set may not be activated / deactivated via DCI.

[0263] Alternatively, (GC-)DCI or MAC-CE can be used to indicate the (de)activation of a specific RO configuration or a parameter set associated with a specific RO configuration. In this case, the UE can receive an indication of at least one pre-configured (de)activation of a specific RO configuration or a parameter set associated with a specific RO configuration via a specific field / bit within (GC-)DCI. Alternatively, the UE can receive an indication via DCI or MAC-CE for switching from a (currently active) specific RO configuration (or a parameter set associated with a specific RO configuration) to another specific RO configuration (or a parameter set associated with another RO configuration). For example, when the BS uses a 2-bit field in GC-DCI to indicate the (de)activation of a specific RO configuration, the value can be configured such that 00 indicates the (de)activation of RO configuration #1, 01 indicates the (de)activation of RO configuration #2, 10 indicates the (de)activation of RO configurations #3 and #4, and 11 indicates the (de)activation of NES RO configuration #5 (or the default RO configuration). In this case, the RO configurations (RO configuration #1 to RO configuration #5) can have different RO cycles / modes, and the default RO configuration can be a pre-configured / defined / indicated RO configuration (e.g., the default RO configuration can always remain active without any indication of its activation / deactivation).

[0264] Using the methods described above, the activation of additional RO configurations can be indicated while maintaining the existing RO configuration (e.g., the default RO configuration). For example, when indicating (or activating) a change in the RO period from 160 ms to 40 ms, an additional RO with a 40 ms period can be configured while maintaining the existing RO configuration with a 160 ms period (e.g., the default RO configuration). Alternatively, when dynamically indicating an RO configuration with a specific period, the existing RO configuration can be deactivated or indicated to be deactivated. For example, when the UE is configured with an RO configuration (or a set of RO configuration-related parameters) that can be indicated by a (group) bitmap in (GC-)DCI or MAC-CE, it is also possible to configure whether to deactivate the existing RO configuration. For example, when an additional RO is activated according to an indication of activation of the additional RO configuration, the ROs available for PRACH transmission can include not only the default RO but also the additional RO. In this case, due to the addition of the additional RO, the RO period of the ROs used for PRACH transmission can be reduced. As described above, when the additional RO is not activated and the default RO period is 160 ms, the RO period of the UE can be 160 ms. However, activating the additional RO can shorten the UE's RO period to less than 160 ms. For example, according to the scheme proposed in this disclosure, the distribution of the overall RO in the time domain can be controlled by activating / deactivating the additional RO, thereby effectively adjusting the overall RO period.

[0265] Alternatively, in the above example, at least one existing RO (or default RO) with a period of 160 ms according to the existing RO configuration (or default RO parameter set) may overlap with an RO with a period of 40 ms according to the additional RO configuration (or additional RO parameter set). In this case, rules / processing for SSB-to-RO mapping may be required. As a method for configuring the beam between overlapping ROs (e.g., default RO and additional RO), SSB-to-RO mapping can be performed independently for each pre-configured RO configuration (or RO configuration-related parameter set). Furthermore, the beam direction for overlapping ROs (e.g., default RO and additional RO) can always be configured to be the same. Alternatively, when the beam directions for overlapping ROs (e.g., default RO and additional RO) are different, the configuration of a specific pre-configured RO among the overlapping ROs can always be configured / defined with higher priority. When the beam directions for overlapping ROs (e.g., the default RO and the additional RO) are different, the UE can align the beam direction for the overlapping RO with the beam direction mapped to the higher-priority RO of the two ROs (e.g., the default RO and the additional RO). For example, for ROs configured to overlap, the SSB index determined by the conventional SSB to RO mapping method can be mapped (e.g., conventional SSB to RO mapping is preferred). Alternatively, separate SSB to RO mapping can be performed only for RO configurations other than the default RO configuration (e.g., the additional RO configuration). For example, SSB to RO mapping can be performed for ROs configured according to the remaining RO configurations, other than the RO configured to overlap with the default RO.

[0266] Alternatively, one could consider whether an additional RO (e.g., a NES RO) overlaps with the default RO to perform an SSB-to-RO mapping for that additional RO.

[0267] For example, SSB-to-RO mapping can be performed on additional ROs (e.g., NES ROs) that include additional ROs configured to overlap with the default RO. Then, the beam direction for at least one additional RO overlapping the default RO can be configured / indicated as the beam direction for the default RO. In this case, a specific beam direction can be punched in the dynamically indicated ROs (NES ROs or additional ROs). Alternatively, SSB-to-RO mapping can be performed on additional ROs that exclude at least one additional RO overlapping the default RO, according to the additional RO configuration (e.g., NES RO configuration). Here, the excluded at least one additional RO can be configured / indicated to use the beam direction of the default RO (e.g., a specific beam direction can be delayed in the dynamically indicated ROs). In this case, the associated time period of the dynamically indicated additional RO (or NES RO) can be defined / configured to follow the associated time period of the default RO, or can be defined / configured to be less than or equal to the associated time period of the default RO.

[0268] Alternatively, the overlap between the default RO and the additional RO can refer to the overlap of both the time resources and frequency resources of the two ROs, or the overlap of only their time resources while their frequency resources differ. Therefore, the above SSB to RO mapping method can be applied according to the different overlap patterns between ROs.

[0269] 1) Cases where the default RO and additional ROs overlap in terms of time and frequency resources.

[0270] In this scenario, a separate SSB-to-RO mapping can be performed only for the additional ROs. Specifically, the UE can perform SSB-to-RO mapping only for the remaining additional ROs that exclude those configured to overlap with the default RO. Alternatively, the UE can determine that an additional RO configured to overlap with the default RO is an invalid RO and perform SSB-to-RO mapping only for the remaining additional ROs that exclude those configured to overlap with the default RO.

[0271] 2) The case where the default RO and the additional RO only overlap in time resources (and do not overlap in frequency resources).

[0272] In this scenario, the UE can perform SSB-to-RO mapping for additional ROs, including those configured to overlap with the default RO. In this case, the beam direction for the additional RO configured to overlap with the default RO can be indicated / configured to be the beam direction of the overlapping default RO (in which case, a specific beam direction can be punched within the additional RO).

[0273] Alternatively, the UE may perform SSB-to-RO mapping for the remaining additional ROs that exclude at least one additional RO configured to overlap with the default RO. Here, the excluded at least one additional RO may be configured / indicated to use the beam direction of the overlapping default RO (in which case, a specific beam direction may be deferred in the additional ROs).

[0274] Alternatively, the UE can determine that at least one of the additional ROs configured to overlap with the default RO is an invalid RO, and can perform SSB-to-RO mapping only for the remaining additional ROs that exclude at least one additional RO.

[0275] Here, as in case "2), when the beam direction for an additional RO (e.g., an additional RO overlapping with the default RO) changes to the beam direction for the default RO, multiple SSB indices may exist linking to the default RO corresponding to the (time) resource overlapping with the additional RO. In this case, the beam direction for the additional RO can be configured / indicated as a specific SSB index (e.g., the lowest / highest SSB index among multiple SSB indices) linking to the default RO. Alternatively, the specific SSB index linking to the default RO can be predefined in standards, etc., or multiple SSB indices linking to the default RO can be used to perform SSB to (overlapping) additional RO mapping. Alternatively, when the beam direction for an additional RO overlapping with the default RO is different from the beam direction of the default RO, the UE may treat the additional RO as an invalid RO.

[0276] In the methods described above, when only some SSB indexes, rather than all SSB indexes, are mapped to additional ROs, an overlapping SSB-to-RO mapping method can also be applied. Here, all SSB indexes can be referred to via parameters. ssb- PositionsInBurst Configured SSB index.

[0277] Alternatively, when the beam directions of the default RO and the additional RO are different from each other, a time gap for beam switching may be required. For example, when the beam directions for the default RO and the additional RO are different from each other and therefore the beam direction for the additional RO is changed to the beam direction for the default RO, the time gap for beam switching may need to be considered separately for the beam direction configuration of the overlapping default RO and the additional RO. Therefore, when determining whether the additional RO and the default RO overlap in the time domain, the size of the pre-configured / defined time gap may need to be considered separately. For example, when determining whether the default RO and the additional RO overlap in the time domain, the time gap between them can be compared with the size of the time gap pre-defined / configured / indicated by the BS (e.g., in the standard). If the time gap between the default RO and the additional RO is smaller than the configured time gap, the UE can consider the default RO and the additional RO to overlap in the time domain and apply the above method, or it can determine that the additional RO is an invalid RO. For example, even if the time resources of the default RO and the additional RO do not overlap, if the time interval between the time resources of the default RO and the additional RO is smaller than the pre-configured time interval, it can be determined that the default RO and the additional RO overlap.

[0278] The DCI indicating activation / deactivation of the RO configuration / parameter set can be configured similarly to the (de)activation DCI format 2_9 indicating the DTX / DRX configuration of an R18 NES cell. For example, each bit of the bitmap included in the DCI can be associated with a specific RO configuration. For example, the bits of the bitmap from left to right can be configured to indicate (de)activation of the default RO, RO configuration #1, and RO configuration #2, respectively. Alternatively, considering multiple cells configured for the UE, the bits / fields in the bitmap associated with cell #1 can indicate the default RO and (de)activation of RO configuration #1 for cell #1, and the bits / fields associated with cell #2 can indicate the default RO and (de)activation of RO configuration #2 for cell #2, respectively. Alternatively, where the default RO is configured to always remain active without requiring activation / deactivation indication, the bitmap can consist of bits indicating activation / deactivation of the corresponding additional RO configuration / parameter set.

[0279] When a specific RO configuration (e.g., an additional RO configuration) is (de-activated) via (GC-)DCI or MAC-CE, additional indication / configuration and / or effective duration for the time when the specific RO configuration becomes available may be required. As one approach, considering UE application latency, when a predefined / configured time (e.g., T symbols / slots) has elapsed (e.g., in standard documentation) after receiving (GC-)DCI or MAC-CE, the RO based on the already indicated activated specific RO configuration can be considered available or usable. In this case, the available RO can be used to perform RACH or PRACH transmissions. Alternatively, when a specific RO configuration (e.g., an additional RO configuration) is de-activated via (GC-)DCI or MAC-CE, the BS / UE can immediately consider the specific RO configuration de-activated upon receipt / indication of (GC-)DCI or MAC-CE, regardless of UE application latency. Alternatively, the activation / deactivation time of a specific RO configuration that has been activated / deactivated by (GC-)DCI or MAC-CE can be determined based on an index corresponding to an application time candidate indicated by (GC-)DCI or MAC-CE in a pre-configured application time candidate list. Alternatively, activation / deactivation can be indicated / configured to begin application from an associated (pattern) period following the time point indicated by (GC-)DCI (or MAC-CE).

[0280] Alternatively, the effective duration of a specific RO configuration (or additional RO configuration) that has been indicated as (de)activated can be considered valid until the next (GC-)DCI or MAC-CE indication is received. Alternatively, a predefined / configured timer (or effective duration) (e.g., from a standard document) can be applied. In this case, the indication of activation / deactivation of a specific RO configuration can be considered valid while the timer is running (or within the effective duration). The BS can directly indicate the value of the timer (or effective duration) via (GC-)DCI or MAC-CE using an index corresponding to one of several pre-configured candidate values ​​for the timer (or effective duration). Alternatively, when the timer expires (or the effective duration has elapsed), the UE can automatically fall back to the RO configuration previously activated before receiving the (GC-)DCI or MAC-CE indication, or can (always) switch to (or activate / deactivate) the RO configuration designated / configured as the default RO configuration among several pre-configured RO configurations. Alternatively, the effective period can be configured / indicated based on associated (mode) periods.

[0281] Alternatively, the UE can be configured to divide a specific time duration (predefined / configured) into N time intervals and receive a dynamic indication of whether a specific RO configuration (or additional RO configuration / parameter set) is available in each time interval. For example, when a default RO and RO configuration #1 (e.g., additional RO configuration #1) are configured, a 160 ms duration can be divided into 20 ms time intervals, and the availability / activation of RO configuration #1 can be indicated for each 20 ms time interval via an 8-bit bitmap included in the (GC-)DCI.

[0282] 2. Method #2: When the UE transmits PRACH on a RO that is dynamically enabled / disabled (activated / deactivated) according to (GC-)DCI or MAC-CE, a method is used to determine whether the RO is valid and whether partial cancellation is applicable based on DL reception or SFI (slot format indicator).

[0283] Referring to Table 8 below (Section 11.1 of TS 38.213), the first paragraph relates to a method for determining whether a symbol allocated to the RO within a time slot should be partially cancelled when the UE intends to receive a DL during PRACH transmission. According to the predetermined scenario (TS 38.213), for PRACH configured via higher layers, the UE does not expect to cancel PRACH transmission via DCI within a specific timeline. Furthermore, according to the second paragraph, the UE may perform PRACH transmission configured via higher layers when the UL is indicated by the SFI.

[0284] Referring to "Method #1" above, since RO configurations (or sets of RO-related configuration parameters) can be dynamically activated / deactivated via (GC-)DCI or MAC-CE (e.g., since the number of RO configurations or ROs can be dynamically adjusted), additional conditions can be defined such that the conditions for PRACH configured via higher-layer signaling in the above scenario and Table 8 are extended to also include ROs that have been activated (or enabled) by indication via (GC-)DCI or MAC-CE. Alternatively, the BS can instruct / configure whether the UE operates solely based on ROs configured via higher layers (i.e., the UE does not expect to cancel PRACH transmissions via DCI within a specific timeline), as in the general cases in the above scenario and Table 8, or whether the UE should consider dynamically (de)activated ROs for operation.

[0285] [Table 8]

[0286] Referring to the aforementioned pre-defined scenario (clause 11.1 of TS 38.213), Table 9 below specifies that the UE will not receive PDCCH / PDSCH / CSI-RS during the effective RO and the Ngap symbols preceding the effective RO. Additionally, the UE does not expect the duration corresponding to the effective RO and the Ngap symbols to be indicated as downlink by the SFI.

[0287] [Table 9]

[0288] However, when applying “Method #1” above, even ROs configured via RRC signaling can be indicated as deactivated via (GC-)DCI or MAC-CE. In this case, the rules in Table 9 need not be applied to ROs indicated as deactivated. Therefore, it is necessary to define an exception where, according to Table 9, no PDCCH / PDSCH / CSI-RS is received within Ngap symbols prior to the valid RO and no DL indication via SFI is expected. This exception applies only to ROs configured according to ROs activated (i.e., enabled) via dynamic indication. (Alternatively, an exception may be required such that no PDCCH / PDSCH / CSI-RS is received within Ngap symbols prior to the effective RO and no DL indication is expected via SFI, only for ROs activated (i.e., enabled) by dynamic indication.) Even in this case, the UE can be configured by the BS to determine whether it should operate solely based on effective ROs pre-configured as shown in Table 9 (i.e., the UE does not receive PDCCH / PDSCH / CSI-RS within Ngap symbols prior to the RO), or whether it should even consider dynamically (de)activated ROs.

[0289] The above method can also be applied to the timing of msgA PUSCH in a two-step random access process.

[0290] As described above, a UE can be configured with multiple PRACH configurations or multiple RO-related parameter sets within a single PRACH configuration. In this case, the RO resources or RO period for RACH transmission can be dynamically adjusted for the UE via (GC-)DCI or MAC-CE. The BS and UE can reduce the power consumption associated with PRACH transmission / reception by adjusting the RO period. Furthermore, even when transmitting PRACH in a RO corresponding to an RO configuration dynamically enabled / disabled according to (GC-)DCI or MAC-CE, it is possible to effectively and clearly determine whether the RO is a valid RO and / or whether partial cancellation is applied.

[0291] Figure 14 This diagram illustrates the method by which the UE determines the RO based on RACH configuration information.

[0292] The UE can be an NES-aware UE capable of supporting the operation of a BS / cell performing NES operations. As described above, the UE can be configured with a default RO configured in relation to PRACH (e.g., an RO even for a legacy UE that is not NES-aware) and additional ROs (or PRACH configurations) related to NES from the NES BS / NES cell (hereinafter referred to as the NES cell) performing NES operations. The method described below refers to... Figure 13 The description is of "PRACH adaptation in the time domain". Therefore, even if references are not explicitly repeated below... Figure 13 Some of the methods described can also be naturally applied to the methods described in "Adaptation of PRACH in the Time Domain".

[0293] Specifically, the UE can receive RACH configuration information from the BS (S141). The RACH configuration information may include parameters for determining at least one RO as a transmission resource for PRACH. The UE can receive this information via the BS's SIB1 or UE-specific RRC signaling. RACH-ConfigGeneric ) Receive configuration information for determining at least one RO required for PRACH transmission.

[0294] RACH configuration information may include a first set of parameters for determining the default Resource Allocation (RO) for legacy UEs (e.g., UEs that do not support Rel-19 NES features) and a second set of parameters for determining additional ROs for NES-aware UEs (e.g., UEs that support Rel-19 NES features). Here, the RO (or RO configuration) for legacy UEs may refer to RO resources for Rel-15 4-step RACH, RO resources for Rel-16 2-step RACH, RO resources for Rel-17 RedCap UEs, or RO resources for Rel-18 Coverage Enhancement (CE).

[0295] For example, when the UE is an NES-aware UE, additional ROs can even be configured based on a second parameter set. The second parameter set may include parameters for determining additional ROs with shorter periods than the default ROs determined based on the first parameter set. For example, the second parameter set may include a second PRACH configuration index that is different from the first PRACH configuration index. Additional ROs based on the second PRACH configuration index may have shorter periods than the default ROs based on the second PRACH configuration index.

[0296] Alternatively, even if the period of the additional RO is not shorter than the period of the default RO, the RO period for the NES cell can be adjusted by the activation / deactivation indication of the additional RO configuration. For example, when the additional RO is not activated, the UE can be configured with an RO (default RO) with a first period having a first parameter set based on RACH configuration information. When the additional RO is activated, the UE can be configured with an RO (default RO and additional RO) with a second period shorter than the first period having a first parameter set and a second parameter set based on RACH configuration information. For example, when the additional RO is not activated and the period of the default RO is 160 ms, the UE's RO period can be 160 ms. However, since the UE's ROs may be distributed more frequently due to the activation of the additional RO, the period of all ROs of the UE may become shorter than 160 ms. For example, an appropriately distributed additional RO can be activated, causing the UE's RO period to be adjusted from 160 ms to 40 ms. In this way, according to this disclosure, the distribution of all ROs in the time domain can be controlled by the activation / deactivation of the additional ROs, thereby effectively adjusting the period of all ROs.

[0297] Additionally, a second parameter set for an additional RO can be activated / deactivated based on an activation / deactivation indication carried by the DCI or MAC CE. For example, when the UE receives a DCI or MAC CE indicating activation of the second parameter set from the BS / NES cell, the UE can activate the second parameter set and make the additional RO available for use. Alternatively, when the UE receives a DCI or MAC CE indicating deactivation of the second parameter set from the BS / NES cell, the UE can deactivate the second parameter set, disallowing the use of the additional RO. Upon receiving configuration information, the second parameter set may initially be in a deactivated or activated state. Whether the second parameter set is initially activated or deactivated can be pre-configured / defined or indicated by the configuration information. On the other hand, the first parameter set may be a parameter set that is not activated / deactivated via DCI or MAC CE; therefore, regardless of any activation / deactivation indication via DCI or MAC CE, the default RO configured by the first parameter set can be used.

[0298] Alternatively, the DCI or MAC CE indicating the activation / deactivation of the second parameter set may also include information about the duration of the activation time for which the second parameter set is activated. In this case, the UE may activate the second parameter set after a first time elapses from the reception time of the DCI or MAC CE, and may use additional RO during the activation time duration. When the activation time duration expires, the second parameter set may be deactivated. Here, the first time may be a preset value related to the UE processing time. Alternatively, the duration of the second parameter set may be predefined / configured as being divided into multiple time intervals, and the DCI or MAC CE indicating the activation / deactivation of the second parameter set may include a bitmap consisting of bits indicating the activation / deactivation of each time interval. In this case, the UE may determine / configure the activation / deactivation of the second parameter set for each time interval based on the bitmap.

[0299] For example, the activation of the second parameter set can be indicated by a DCI with a specific format of CRC scrambled with a specific RNTI. For example, the Paging-Radio Network Temporary Identifier (P-RNTI) used to indicate whether NES RO is activated can be configured as a specific RNTI, and the UE can receive an indication related to whether the second parameter set is activated based on DCI format 1_0 with CRC scrambled with P-RNTI.

[0300] Next, the UE can transmit a PRACH or PRACH preamble for initial access on at least one RO configured based on the RACH configuration information (S143). For example, when the second parameter set is activated (e.g., when activated by DCI or MAC-CE indication, or when the second parameter set is indicated / configured to be activated during the initial configuration phase), the UE can use either the default RO configured by the first parameter set or the additional RO configured by the second parameter set (e.g., an RO arbitrarily selected from multiple ROs) to transmit a PRACH or PRACH preamble to the NES cell. Alternatively, for example, when the second parameter set is deactivated (e.g., when deactivated by DCI or MAC-CE indication, or when the set is indicated / configured to be deactivated during the initial configuration phase), the UE can use only the default RO configured by the first parameter set to transmit a PRACH or PRACH preamble to the NES cell. Alternatively, the UE can determine the RO for transmitting the PRACH or PRACH preamble based on the SSB-to-RO mapping result of the default RO and the additional ROs. For example, when an SSB with SSB index 1 has the best reception quality among multiple SSBs, the UE can send PRACH or PRACH preamble on the RO mapped to SSB index 1 in the default RO and the additional RO.

[0301] Figure 15 This diagram illustrates a method by which the BS communicates with the UE based on RACH configuration information.

[0302] Reference Figure 15 The BS can send RACH configuration information (S151) to the UE. This RACH configuration information includes a first set of parameters for configuring the default RO and a second set of parameters for configuring the activation or deactivation of the indicated additional RO. The BS can do this via SIB1 or UE-specific RRC signaling. RACH-ConfigGeneric Send configuration information to the UE.

[0303] Specifically, the RACH configuration information may include a first set of parameters for determining a default RO for a legacy UE (e.g., a UE that does not support Rel-19 NES features) and a second set of parameters for determining additional ROs for an NES-aware UE (e.g., a UE that supports Rel-19 NES features). For example, the second set of parameters may include parameters for determining additional ROs with shorter periods than the default ROs determined based on the first set of parameters. For example, as referenced... Figure 13 The second parameter set described herein may include a second PRACH configuration index that is different from the first PRACH configuration index. Additional ROs based on the second PRACH configuration index may have shorter periods than the default ROs based on the second PRACH configuration index.

[0304] Next, the BS can send a DCI or MAC-CE indicating whether the second parameter set is activated to the UE (S153). For example, as described above, the BS of the NES BS / NES cell performing NES operation can indicate whether the second parameter set is activated based on the number of UEs connected to it and / or the amount of data activity. Specifically, when the number of UEs is greater than or equal to a specific threshold, the frequency of RACH signal collisions is greater than or equal to a specific collision threshold, or the amount of data activity is greater than or equal to a specific threshold, the BS can send a DCI or MAC-CE indicating the activation of the second parameter set to the UE. Conversely, when the number of UEs is less than a specific threshold, the frequency of RACH signal collisions is less than a specific collision threshold, and / or the amount of data activity is less than a specific threshold, the BS can send a DCI or MAC-CE indicating the deactivation of the second parameter set to the UE. In this case, the BS only needs to wake up the default RO with a relatively long period and monitor whether a PRACH is received. Therefore, energy saving consistent with NES operation can be achieved.

[0305] For example, a BS / NES cell can send a DCI or MAC-CE indicating the activation of a second parameter set to the UE, thereby configuring the UE to use an additional RO based on the second parameter set. Alternatively, the BS / NES cell can send a DCI or MAC-CE indicating the deactivation of the second parameter set to the UE, thereby restricting the use of additional ROs based on the second parameter set. When configured via configuration information, the second parameter set can initially be in a deactivated or activated state. Whether the second parameter set is initially activated or deactivated can be pre-configured / defined, or can be indicated by the configuration information. The first parameter set is the parameter set that is not indicated as activated via DCI or MAC-CE; therefore, regardless of whether activation is indicated via DCI or MAC-CE, the default RO configured via the first parameter set can be used.

[0306] Alternatively, the DCI or MAC CE indicating the activation / deactivation of the second parameter set may also include information about the duration of the activation time for which the second parameter set is activated. In this case, the UE may activate the second parameter set after a first time elapses from the reception time of the DCI or MAC CE, and may use additional RO during the activation time duration. When the activation time duration expires, the second parameter set may be deactivated. Here, the first time may be a preset value related to the UE processing time. Alternatively, the duration of the second parameter set may be predefined / configured as being divided into multiple time intervals, and the DCI or MAC CE indicating the activation / deactivation of the second parameter set may include a bitmap consisting of bits indicating the activation / deactivation of each time interval. In this case, the UE may determine / configure the activation / deactivation of the second parameter set for each time interval based on the bitmap.

[0307] Next, the BS can receive PRACH from the UE based on the RACH configuration information (S155). For example, when the second parameter set is activated (e.g., when activated by DCI or MAC CE indication, or when the second parameter set is indicated / configured to be activated during the initial configuration phase), the BS can monitor PRACH or PRACH preamble on either the default RO configured by the first parameter set or the additional RO configured by the second parameter set. Alternatively, when the second parameter set is deactivated (e.g., when deactivated by DCI or MAC CE indication, or when the second parameter set is indicated / configured to be deactivated during the initial configuration phase), the BS can monitor PRACH or PRACH preamble only on the default RO configured by the first parameter set.

[0308] As described above, according to this disclosure, the RO cycle can be quickly adjusted by additionally configuring the parameter set of the additional RO dynamically controlled by the NES and by indicating the activation or deactivation of the parameter set of the additional RO according to the BS. Furthermore, according to this disclosure, additional ROs with cycles different from the default RO can be clearly and efficiently configured by indicating different PRACH configuration indexes for the default RO and the additional RO.

[0309] Example of a communication system using this disclosure

[0310] Although not limited thereto, the various descriptions, functions, processes, proposals, methods and / or operation flowcharts disclosed in this document can be applied to various fields requiring wireless communication / connectivity (5G) between devices.

[0311] In the following description, it will be illustrated in more detail with reference to the accompanying drawings. In the following drawings / description, unless otherwise specified, the same reference numerals may refer to the same or corresponding hardware blocks, software blocks, or functional blocks.

[0312] Figure 16 An example of a communication system applied to this disclosure is shown.

[0313] Reference Figure 16The communication system 1 applied to this disclosure includes wireless devices, base stations (BS), and networks. Herein, 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 100a, vehicles 100b-1 and 100b-2, extended reality (XR) devices 100c, handheld devices 100d, home appliances 100e, Internet of Things (IoT) devices 100f, 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 performing communication between vehicles. Herein, 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 TVs, 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 particular wireless device 200a can operate as a BS / network node relative to other wireless devices.

[0314] Wireless devices 100a to 100f can connect to network 300 via BS 200. AI technology can be applied to wireless devices 100a to 100f, and wireless devices 100a to 100f 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 100a to 100f can communicate with each other via BS 200 / network 300, wireless devices 100a to 100f can also perform direct communication (e.g., sidelink communication) without going through the BS / network. For example, vehicles 100b-1 and 100b-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 100a to 100f.

[0315] Wireless communication / connections 150a, 150b, or 150c can be established between wireless devices 100a to 100f / BS 200 or between BS 200 and BS 200. In this document, wireless communication / connections 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)). 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 configuration information for configuring the process of transmitting / receiving radio signals, various signal processing processes (e.g., channel coding / decoding, modulation / demodulation, and resource mapping / demapping), and resource allocation processes can be performed based on various proposals of this disclosure.

[0316] Examples of wireless devices using this disclosure

[0317] Figure 17 Wireless devices applicable to this disclosure are illustrated.

[0318] Reference Figure 17 The first wireless device 100 and the second wireless device 200 can transmit radio signals via various RATs (e.g., LTE and NR). In this document, {first wireless device 100 and second wireless device 200} can correspond to... Figure 16 {Wireless Device 100x and BS 200} and / or {Wireless Device 100x and Wireless Device 100x}.

[0319] The first wireless device 100 may include one or more processors 102 and one or more memories 104, and additionally include one or more transceivers 106 and / or one or more antennas 108. The processors 102 may control the memories 104 and / or the transceivers 106, and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. 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 transceivers 106. The processor 102 may receive a radio signal including a second information / signal via the transceivers 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 performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed herein. In this document, 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 radio frequency (RF) units. In this disclosure, a wireless device may refer to a communication modem / circuit / chip.

[0320] Specifically, the first wireless device or UE 100 may include a processor 102 and a memory 104 connected to the transceiver 106. The memory 104 may include components for performing and referencing... Figures 11 to 15 At least one program related to the operations described in the implementation method.

[0321] Processor 102 can control transceiver 106 to receive RACH configuration information from BS and send PRACH based on the RACH configuration information. Here, RACH configuration information may include a first set of parameters for configuring the default RACH timing (RO) and a second set of parameters for configuring the activation or deactivation of the indicated additional RO.

[0322] Alternatively, a processing device may be configured including a processor 102 configured to control the UE and a memory 104. In this case, the processing device may include at least one processor and at least one memory connected to the at least one processor and storing instructions, wherein, based on the instructions executed by the at least one processor, the instructions may cause the UE to: receive RACH configuration information from the BS and send PRACH based on the RACH configuration information. Here, the RACH configuration information may include a first set of parameters for configuring a default RO and a second set of parameters for configuring the activation or deactivation of an indicated additional RO.

[0323] 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 processors 202 may control the memories 204 and / or the transceivers 206, and may be configured to implement the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document. For example, the processors 202 may process information in the memories 204 to generate a third information / signal, and then transmit a radio signal including the third information / signal via the transceivers 206. The processors 202 may receive a radio signal including a fourth information / signal via the transceivers 206, and then store the information obtained by processing the fourth information / signal in the memories 204. The memories 204 may be connected to the processors 202 and may store various information relating to the operation of the processors 202. For example, the memories 204 may store software code including commands for performing some or all of the processes controlled by the processors 202 or for performing the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document. In this document, 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.

[0324] Specifically, the second wireless device or BS 200 may include a processor 202 and a memory 204 connected to the transceiver or RF transceiver 206. The memory 204 may include components for performing operations and referencing... Figures 11 to 15 At least one program related to the operations described in the implementation method.

[0325] Processor 202 can control transceiver 206 to: send RACH configuration information, which includes a first set of parameters for configuring the default RO and a second set of parameters for configuring the activation or deactivation of the indicated additional RO; and receive PRACH based on the RACH configuration information.

[0326] The hardware elements of wireless devices 100 and 200 will be described in more detail below. One or more protocol layers may be implemented by (but are 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, processes, 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, processes, 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) and acquire PDUs, SDUs, messages, control information, data, or information from one or more transceivers 106 and 206, according to the descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document.

[0327] 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. As an 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, processes, proposals, methods, and / or operation flowcharts disclosed in this document may be implemented using firmware or software, and the firmware or software may be configured to include modules, processes, or functions. Firmware or software configured to execute the descriptions, functions, processes, proposals, methods, and / or operation 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 to be driven by one or more processors 102 and 202. The descriptions, functions, processes, proposals, methods, and / or operation flowcharts disclosed in this document can be implemented using firmware or software in the form of code, commands, and / or command sets.

[0328] 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, cache 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.

[0329] One or more transceivers 106 and 206 may transmit user data, control information, and / or radio signals / channels mentioned in the methods and / or operation flowcharts of this document to one or more other devices. One or more transceivers 106 and 206 may 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 may 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 may perform control to enable one or more transceivers 106 and 206 to transmit user data, control information, or radio signals to one or more other devices. One or more processors 102 and 202 may perform control to enable one or more transceivers 106 and 206 to 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 through 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 so that the received user data, control information, radio signals / channels, etc., may be processed using 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.

[0330] Examples of wireless devices using this disclosure

[0331] Figure 18 Another example of a wireless device applied to this disclosure is shown. The wireless device can be implemented in various forms depending on the use case / service (see reference). Figure 16 ).

[0332] Reference Figure 18 Wireless devices 100 and 200 can correspond to Figure 17The 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 17 One or more processors 102 and 202 and / or one or more memories 104 and 204. For example, transceiver 114 may include Figure 17 The device comprises 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 unit 130, and add-on components 140, and controls the overall operation of the wireless device. For example, control unit 120 may control the electrical / mechanical operation of the wireless device based on programs / code / commands / information stored in memory unit 130. Control unit 120 may 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 via a wireless / wired interface.

[0333] 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 supply unit / battery, an input / output (I / O) unit, a drive unit, and a computing unit. The wireless device can be configured according to (but is not limited to) a robot ( Figure 16 100a), vehicles ( Figure 6 100b-1 and 100b-2), XR device ( Figure 16 100c), handheld device ( Figure 16 100d), home appliances ( Figure 16 100e), IoT devices ( Figure 16 100f), digital broadcasting terminals, holographic devices, public safety devices, MTC devices, medical devices, fintech devices (or financial devices), security devices, climate / environment devices, AI servers / devices ( Figure 16 400), BS ( Figure 16 This can be achieved through 200 network nodes, etc. Wireless devices can be used in mobile or fixed locations depending on the use case / service.

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

[0335] Examples of vehicles or autonomous vehicles using this disclosure

[0336] Figure 19 The illustration shows a vehicle or autonomous vehicle applicable to this disclosure. The vehicle or autonomous vehicle may be a mobile robot, car, train, manned / unmanned aerial vehicle (AV), vessel, etc.

[0337] Reference Figure 19 The vehicle or autonomous vehicle 100 may include an antenna unit 108, a communication unit 110, a control unit 120, a drive unit 140a, a power supply unit 140b, a sensor unit 140c, and an autonomous driving unit 140d. The antenna unit 108 may be configured as part of the communication unit 110. Blocks 110 / 130 / 140a to 140d respectively correspond to... Figure 18 Blocks 110 / 130 / 140.

[0338] Communication unit 110 can send and receive signals (e.g., data and control signals) to and from external devices such as other vehicles, BSs (e.g., gNBs and roadside units), and servers. Control unit 120 can perform various operations by controlling the components of the vehicle or autonomous vehicle 100. Control unit 120 may include electronic control unit (ECU). Additionally, drive unit 140a enables the vehicle or autonomous vehicle 100 to move on a road. Drive unit 140a may include an engine, motor, powertrain, wheels, brakes, steering mechanism, etc. Power supply unit 140b supplies power to the vehicle or autonomous vehicle 100 and includes wired / wireless charging circuitry, battery, etc. Sensor unit 140c can acquire vehicle status, surrounding environment information, user information, etc. Sensor unit 140c may include inertial measurement unit (IMU) sensors, collision sensors, wheel sensors, speed sensors, slope sensors, weight sensors, heading sensors, position modules, vehicle forward / reverse sensors, battery sensors, fuel sensors, tire sensors, steering sensors, temperature sensors, depth sensors, ultrasonic sensors, lighting sensors, pedal position sensors, etc. Autonomous driving unit 140d can implement technologies for maintaining the vehicle within its lane, technologies for automatically adjusting speed (e.g., adaptive cruise control), technologies for autonomously driving along a determined path, and technologies for automatically setting a route if a destination is set, etc.

[0339] For example, communication unit 110 can receive map data, traffic information data, etc., from an external server. Autonomous driving unit 140d can generate an autonomous driving path and driving plan from the acquired data. Control unit 120 can control drive unit 140a, enabling the vehicle or autonomous vehicle 100 to move along the autonomous driving path according to the driving plan (e.g., speed / direction control). During autonomous driving, communication unit 110 can periodically or non-periodically acquire recent traffic information data from an external server and acquire surrounding traffic information data from neighboring vehicles. During autonomous driving, sensor unit 140c can acquire vehicle status and / or surrounding environment information. Autonomous driving unit 140d can update the autonomous driving path and driving plan based on newly acquired data / information. Communication unit 110 can transmit information about vehicle location, autonomous driving path, and / or driving plan to an external server. The external server can predict traffic information data using AI technology, etc., based on information collected from the vehicle or autonomous vehicle, and provide the predicted traffic information data to the vehicle or autonomous vehicle.

[0340] Here, the wireless communication technologies implemented in the wireless devices (XXX, YYY) of this specification may include, in addition to narrowband IoT for low-power communication, LTE, NR, and 6G. For example, NB-IoT technology may be an example of low-power wide-area network (LPWAN) technology and may be implemented according to standards such as LTE Cat NB1 and / or LTE Cat NB2, and is not limited to the aforementioned names. Alternatively, the wireless communication technologies implemented in the wireless devices (XXX, YYY) of this specification may perform communication based on LTE-M technology. In this case, as an example, LTE-M technology may be an example of LPWAN technology and may be referred to by various names such as eMTC (enhanced machine-type communication). For example, LTE-M technology may be implemented according to at least one of various standards such as 1) LTE CAT 0, 2) LTE Cat M1, 3) LTE Cat M2, 4) LTE non-BL (non-bandwidth limited), 5) LTE-MTC, 6) LTE machine-type communication, and / or 7) LTE M, and is not limited to the aforementioned names. Alternatively, considering low-power communication, the wireless communication technology implemented in the wireless devices (XXX, YYY) of this specification is at least one of ZigBee, Bluetooth, and Low Power Wide Area Network (LPWAN), and is not limited to the aforementioned names. As an example, ZigBee technology can be used to generate personal area networks (PANs) related to low / low power digital communication based on various standards such as IEEE 802.15.4, and can be referred to by various names.

[0341] The above embodiments are implementations in which the components and features of this disclosure are combined in a predetermined form. Unless otherwise expressly stated, each component or feature should be considered optional. Each component or feature may be implemented without being combined with other components or features. Additionally, embodiments of this disclosure may be constructed by combining some components and / or features. The order of operations described in the embodiments of this disclosure may be changed. Some configurations or features of one embodiment may be included in other embodiments, or may be replaced by corresponding configurations or features of other embodiments. Clearly, embodiments may be constructed by combining claims that are not expressly referenced in the claims, or may be included as new claims by amendments made after filing.

[0342] In this document, the embodiments of the present disclosure are described primarily based on the signal transmission / reception relationship between the terminal and the base station. Such a transmission / reception relationship is extended in the same / similar manner to signal transmission / reception between the terminal and a repeater or between the base station and a repeater. In some cases, specific operations described in this document as being performed by the base station can be performed by its upstream nodes. That is, obviously, various operations performed by the base station or by network nodes other than the base station for communicating with the terminal in a network including multiple network nodes containing the base station can be performed. The base station can be replaced by terms such as fixed station, node B, eNode B (eNB), access point, etc. Additionally, the terminal can be replaced by terms such as user equipment (UE), mobile station (MS), mobile subscriber station (MSS).

[0343] In the hardware configuration, the embodiments 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.

[0344] In firmware or software configuration, the methods according to embodiments of this disclosure can be implemented in the form of modules, processes, functions, etc. Software code can be stored in memory units and executed by a processor. The memory is located internally or externally to the processor and can send data to and receive data from the processor via various known means.

[0345] As described above, a detailed description of preferred embodiments of this disclosure has been provided to enable those skilled in the art to implement and perform this disclosure. Although reference has been made to preferred embodiments of this disclosure, those skilled in the art will understand that various modifications and alterations can be made to this disclosure within its scope.

[0346] Industrial applicability

[0347] The embodiments described above are applicable to various mobile communication systems.

Claims

1. A method performed by a user equipment (UE), the method comprising the following steps: Receive Random Access Channel (RACH) configuration information from the base station; as well as The Physical Random Access Channel (PRACH) is transmitted based on the RACH configuration information. The RACH configuration information includes: The first set of parameters used to configure the default RACH timing (RO); and A second set of parameters is used to configure the additional RO, indicating whether the additional RO is activated.

2. The method according to claim 1, wherein, The first parameter set includes a first PRACH configuration index, and The second parameter set includes a second PRACH configuration index that is different from the first PRACH configuration index.

3. The method according to claim 1, wherein, Since the additional RO is not activated, the PRACH is transmitted on the RO of the first period having the first parameter set based on the RACH configuration information, and Wherein, based on the activation of the additional RO, the PRACH is transmitted on a second RO with a shorter period than the first period, having the first parameter set and the second parameter set based on the RACH configuration information.

4. The method according to claim 1, wherein, Whether the second parameter set is activated is indicated by downlink control information (DCI) or media access control-control element (MAC-CE).

5. The method according to claim 4, wherein, The DCI or MAC-CE indicating the activation of the second parameter set includes information about the duration of the activation time.

6. The method according to claim 5, wherein, After a first time elapses from the time point when the DCI or MAC-CE is received, the second parameter set is activated during the activation time duration.

7. The method according to claim 4, wherein, The DCI or the MAC-CE includes a bitmap, the bitmap comprising bits corresponding to the plurality of durations respectively, and The UE determines the activation time duration of the second parameter set based on the bitmap within the duration.

8. The method according to claim 1, wherein, Whether the second parameter set is activated is indicated by the base station based on the number of UEs connected to the base station and the amount of data activity.

9. The method according to claim 1, wherein, The second set of parameters configures the additional RO for the UE of the base station that supports Network Energy Saving (NES).

10. A non-transitory computer-readable recording medium storing a program for performing the method according to claim 1.

11. A user equipment (UE), the UE comprising: Radio frequency (RF) transceivers; as well as The processor is connected to the RF transceiver. The processor controls the RF transceiver: Receive Random Access Channel (RACH) configuration information from the base station; and The Physical Random Access Channel (PRACH) is transmitted based on the RACH configuration information. The RACH configuration information includes: The first set of parameters used to configure the default RACH timing (RO); and A second set of parameters is used to configure the additional RO, indicating whether the additional RO is activated.

12. A processing apparatus for controlling a user equipment (UE), the processing apparatus comprising: At least one processor; as well as At least one memory, connected to the at least one processor and storing instructions, Wherein, the instruction is executed by the at least one processor, and the instruction causes the UE to: Receive Random Access Channel (RACH) configuration information from the base station; and The Physical Random Access Channel (PRACH) is transmitted based on the RACH configuration information. The RACH configuration information includes: The first set of parameters used to configure the default RACH timing (RO); and A second set of parameters is used to configure the additional RO, indicating whether the additional RO is activated.

13. A method performed by a base station, the method comprising the following steps: Send Random Access Channel (RACH) configuration information, which includes: The first set of parameters used to configure the default RACH timing (RO); and A second set of parameters is used to configure the additional RO, indicating whether the additional RO is activated; and Based on the RACH configuration information, the Physical Random Access Channel (PRACH) is received from the User Equipment (UE).

14. The method according to claim 13, wherein, The base station determines whether to activate the second parameter set based on the number of UEs connected to the base station and the amount of data activity.

15. A base station, the base station comprising: Radio frequency (RF) transceivers; as well as The processor is connected to the RF transceiver. The processor controls the RF transceiver: Send Random Access Channel (RACH) configuration information, which includes: The first set of parameters used to configure the default RACH timing (RO); and A second set of parameters is used to configure the additional RO, indicating whether the additional RO is activated; and The Physical Random Access Channel (PRACH) is received based on the RACH configuration information.

Images