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

Abstract

Methods performed by a UE in a wireless communication system, according to various embodiments, and apparatuses therefor are disclosed. Apparatuses and methods are disclosed that receive random access channel (RACH) resource configuration information for configuring a default random access channel occasion (RO) and an additional RO related to network energy saving (NES), and transmit a physical random access channel (PRACH) based on the RACH resource 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 following steps: receiving random access channel (RACH) resource configuration information for configuring a default random access channel timing (RO) and additional ROs related to network power saving (NES); and transmitting a physical random access channel (PRACH) based on the RACH resource configuration information, wherein whether additional ROs are activated may be indicated by downlink control information (DCI) in a specific format.

[0010] Alternatively, a particular format DCI may be a group common DCI of DCI format 1_0 with a cyclic redundancy check (CRC) scrambled by a particular paging-radio network temporary identifier (P-RNTI) associated with the activation indication of the additional RO.

[0011] Alternatively, whether to activate the additional RO can be indicated by the reserved bits included in DCI format 1_0.

[0012] Alternatively, based on the overlap between the additional RO and the default RO, the beam direction of the additional RO can be considered to be the same as the beam direction determined for the default RO.

[0013] Alternatively, based on the overlap between additional ROs and the default RO, additional ROs can be considered invalid.

[0014] Alternatively, RACH resource configuration information can be configured for multiple default ROs, including default ROs, and multiple additional ROs, including additional ROs. The UE can perform synchronization signal block (SSB) mapping only for the remaining additional ROs among the multiple additional ROs, excluding those that overlap with the default ROs.

[0015] Alternatively, RACH resource configuration information may include information for configuring the priority between the default RO and additional ROs.

[0016] Alternatively, RACH resource configuration information may include information about specific offsets used to attach ROs based on the default RO configuration.

[0017] Alternatively, the default RO can always be active, regardless of whether it is activated via DCI.

[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 paper provides a method performed by a base station. The method may include the following steps: transmitting Random Access Channel (RACH) resource configuration information for configuring a default Random Access Channel Timing (RO) and additional ROs related to Network Energy Saving (NES); and receiving a Physical Random Access Channel (PRACH) based on the RACH resource configuration information, wherein whether additional ROs are activated may be indicated by downlink control information (DCI) in a specific format.

[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 diagram illustrates a method for a UE to send signals based on RACH resource configuration information.

[0037] Figure 14 This is a diagram illustrating the method by which a BS sends RACH resource configuration information.

[0038] Figures 15 to 18 The communication system 1 and wireless device to which this disclosure applies are illustrated. Detailed Implementation

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

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

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

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

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

[0044] - 38.211: Physical Channels and Modulation

[0045] - 38.212: Multiplexing and Channel Coding

[0046] - 38.213: Physical layer procedures for control

[0047] - 38.214: Physical layer procedures for data

[0048] - 38.215: Physical Layer Measurement

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

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

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

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

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

[0054] - 36.355: LTE positioning protocol

[0055] - 37.355: LTE positioning protocol

[0056] Terms and acronyms

[0057] - 5GC: 5G Core Network

[0058] - 5GS: 5G system

[0059] - NES: Network Energy Saving

[0060] - ES: Energy Saving

[0061] - SSB: Synchronization Signal / PBCH Block

[0062] - FR: Frequency range

[0063] - CC: Component Carrier

[0064] - NCGI: NR Cell Global Identifier

[0065] - SI: System Information

[0066] - PCell: Main Cell

[0067] - SCell: Secondary Cell

[0068] - PDCCH: Physical Downlink Control Channel

[0069] - PDSCH: Physical Downlink Shared Channel

[0070] - PUSCH: Physical Uplink Shared Channel

[0071] - CSI: Channel State Information

[0072] - RRM: Radio Resource Management

[0073] - SCS: Subcarrier Spacing

[0074] - RLM: Radio Link Monitoring

[0075] - DCI: Downlink Control Information

[0076] - CAP: Channel Access Procedure

[0077] - Ucell: License-free cell

[0078] - TBS: Transport Block Size

[0079] - TDRA: Time Domain Resource Allocation

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

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

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

[0083] - REG: Resource Element Group

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

[0085] - COT: Channel Occupancy Time

[0086] - SPS: Semi-persistent scheduling

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

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

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

[0090] - TRP: Transmitting and Receiving Point

[0091] In wireless communication systems, terminals receive information from base stations via the downlink (DL) and transmit information to base stations via the 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.

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

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

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

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

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

[0097] Figure 2 The structure of the 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.

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

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

[0100] [Table 2]

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

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

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

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

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

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

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

[0108] [Table 3]

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

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

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

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

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

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

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

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

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

[0118] [Table 4]

[0119] 1) PUCCH format 0 (PF0)

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

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

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

[0123] 2) PUCCH Format 1 (PF1)

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

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

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

[0127] 3) PUCCH Format 2 (PF2)

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

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

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

[0131] 4) PUCCH Format 3 (PF3)

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

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

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

[0135] 5) PUCCH Format 4 (PF4)

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

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

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

[0139] DRX (Discontinuous Receive) Operation

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

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

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

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

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

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

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

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

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

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

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

[0151] (1) Idle mode DRX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0184] - (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.

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

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

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

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

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

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

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

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

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

[0194] Figure 10 This is a diagram used to illustrate the method of monitoring DCI format 2_6.

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

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

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

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

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

[0200] Network Energy Saving (NES)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0216] [Table 5]

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

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

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

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

[0221] [Table 6]

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

[0223] Enhancements to NR network power efficiency

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

[0225] [Table 7]

[0226] (1) On-demand SSB

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

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

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

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

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

[0232] (2) On-demand SIB1 transmission

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

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

[0235] (1) Scene 1

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

[0237] (2) Scene 2

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

[0239] (3) Scene 3

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

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

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

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

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

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

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

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

[0248] Adaptation for energy-efficient PRACH

[0249] 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 timings (ROs). 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 access latency regarding the cell can lead to scheduling latency for the UE, potentially resulting in a significant degrade in UE performance.

[0250] Additionally, for the BS, depending on the intra-cell situation, 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 PRACH messages sent by UEs in the periodically configured RO. In this case, the BS cannot remain in sleep mode for extended periods, 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 it is a time interval with no data activity), setting a longer RO period may be advantageous for BS energy saving. However, since currently only semi-static methods are available for changing configurations (such as the RO period), changing the RO period configuration (e.g., SI modification) may take a relatively long time, and the BS may struggle to respond quickly to potential energy savings due to the delay in implementing such RO period configuration changes.

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

[0252] 1. Method #1: A method for the UE to receive, separately, the default RO (relatively sparse RO) configuration for a legacy UE (UE that does not support R19 NES features) and the additional NES RO (e.g., additional RO) for an NES UE (UE that supports R19 NES features) from the BS.

[0253] Method #1 allows for the expectation of a certain level of BS energy-saving gain without excessively increasing UE access latency. A method can be considered for configuring a default RO (relatively sparse RO) for legacy UEs and an additional NES RO (i.e., supplementary RO) for NES UEs (UEs supporting R19 NES features). In this case, the NES_RO configuration can be included in and configured together with the default RO configuration, or it can be provided separately from the default RO configuration. Here, the RO (RO configuration) for legacy UEs can represent 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 CE (coverage enhancement). At least one NES RO configuration can exist, and the RO mode / cycle can be configured differently for each NES RO configuration. Additionally, the activation of the NES RO configuration can be indicated to the NES UE via a pre-configured / defined index, or the activated NES RO configuration can be indicated to switch to another NES RO configuration. At least one NES RO configuration can be provided via SIB1, similar to the default RO configuration, or via RRC signaling.

[0254] The NES UE (or NES-aware UE or UE supporting Rel-19 NES) can be configured by the BS regarding whether only the NES RO is available among the configured ROs, or whether both the default RO and the NES RO are available. When no such configuration exists, the NES UE can interpret / assume that both the default RO and the NES RO are configured to be available. For example, the NES UE can be provided with information about the default RO configuration and at least one NES RO configuration (or additional RO configuration), and can receive from the BS an indication of whether only the additional RO (or NES RO) configured according to the NES RO of the two configurations is available, or whether all ROs are available according to the two configurations. Alternatively, if no such indication exists, the NES UE can determine / determine that all ROs configured according to the default RO and NES RO are available. Even when both the default RO and the NES RO are configured / indicated, the NES RO can be activated under normal conditions. In this scenario, all UEs (e.g., both legacy UEs and NES UEs) can use only the RO configured according to the default RO, and the NES RO can be activated by a dynamic indication from the BS (at the request of the UE). Alternatively, when indicating the (de)activation of the NES RO, the (de)activation of the default RO can be indicated together or separately.

[0255] The UE can receive NESRO configurations using time / frequency offsets for each default RO / default RO group (or associated time period). For example, the UE can receive NES ROs corresponding to each default RO based on time / frequency offsets. Here, an associated time period can refer to the time interval {10 ms, 20 ms, 40 ms, 80 ms, 160 ms} at which the SSB is periodically mapped to the RO according to the SSB-RO mapping. When the time / frequency offset for a specific default RO (group) or associated time period is set to 0 (or when no offset is configured), it can be determined / considered that there are no additional NES ROs configured corresponding to the specific default RO or associated time period. The NESROs configured for the NES UE can be adjusted in units of associated mode time periods (e.g., at least one associated time period) or associated time periods. For example, the BS can group multiple associated mode time periods (or multiple associated time periods) together and configure / instruct the UE not to use all NES ROs belonging to a specific group, or it can configure / instruct that some NES ROs belonging to some associated time periods within the group should always be used for RACH transmission, similar to the default ROs. When an NES UE requires an NES RO, the BS / NES cell can indicate whether the NES RO is an available RO within an associated time period group or associated mode time period. For example, the BS can indicate to the UE whether the NES RO is activated or available in an associated time period or at least one associated time period unit.

[0256] The BS can configure ROs in the NES RO configuration so that they do not overlap with ROs in the default RO configuration in time / frequency resources, or it can intentionally configure NES ROs such that a particular NES RO in the NES_RO configuration can include all ROs in the default RO configuration. In this case, as a method for configuring beams between overlapping default ROs and NES ROs, the UE can perform SSB-to-RO mapping independently for the default RO and NES RO respectively. Additionally, the beam directions of the default RO and NES RO configured to overlap can always be configured to be the same. Alternatively, when the beam directions of the default RO and NES RO configured to overlap are different, the default RO configuration can always be configured / defined to have a higher priority than the NES RO. This can be a method to ensure that the SSB index determined by the conventional SSB-to-RO mapping method is mapped to the NES RO (e.g., the NES RO overlapping with the default RO) (e.g., a method that prioritizes conventional SSB-to-RO mapping). Alternatively, the UE can perform separate SSB-to-RO mapping only for the NES RO. Specifically, it can perform SSB-to-RO mapping only for NES ROs that exclude NES ROs configured to overlap with the default RO.

[0257] SSB-to-RO mapping for a NES RO can be performed based on whether the NES RO overlaps with a default RO. After performing SSB-to-RO mapping for an NES RO that includes at least one NES RO configured to overlap with the default RO, the UE can be configured / instructed to use the beam direction of the overlapping default RO for the at least one RO configured to overlap (e.g., this can have the effect of punching a specific beam direction in the NES RO). Alternatively, SSB-to-RO mapping can be performed for the remaining NES ROs in the NES RO configuration that exclude the NES RO configured to overlap with the default RO. Here, the excluded NES ROs can be configured / instructed to use the beam direction of the default RO (e.g., this can have the effect of delaying a specific beam direction in the NES RO). In this case, the associated time period of the 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.

[0258] Alternatively, the overlap between the default RO and the NES RO (e.g., the additional RO) can refer to the case where the two ROs overlap in both time and frequency resources, or they have different frequency resources and overlap only in time resources. Therefore, the above SSB-to-RO mapping method can be applied differently depending on the overlap / pattern between the ROs.

[0259] 1) When the default RO and NES RO overlap in terms of time and frequency resources.

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

[0261] 2) When the default RO and NES RO only overlap in time resources (not in frequency)

[0262] In this scenario, the UE can perform SSB-to-RO mapping for NESROs that include at least one NES RO configured to overlap with the default RO, and can be instructed / configured to set the beam direction of at least one RO to the beam direction of the overlapping default RO (in which case, the specific beam direction can be punched in the NES RO).

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

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

[0265] As in scenario 2), when the beam direction of the NES RO changes to the beam direction of the default RO, multiple SSB indices may exist linking to the default RO (which corresponds to the (time) resource overlapping with the NES RO). In this case, the beam direction of the NES RO can be configured / indicated as a specific SSB index among the SSB indices linking to the default RO (e.g., the lowest / highest SSB index among multiple SSB indices). Alternatively, the specific SSB index among the SSB indices linking to the default RO can be predefined by standard documents, etc., or multiple SSB indices linking to the default RO can be used to perform SSB to (overlapping) NES RO mapping. Alternatively, when the beam direction of the NES RO overlapping with the default RO is different from the beam direction of the default RO, the UE can consider the NES RO as an invalid RO.

[0266] In the methods described above, an SSB-to-RO mapping method that considers overlap with the default RO can also be applied when only some SSB indexes, rather than all SSB indexes, are mapped to NES ROs (e.g., additional ROs). Here, "all SSB indexes" can refer to the SSB indexes configured via the parameter ssb-PositionsInBurst.

[0267] Alternatively, time gaps for beam switching can be defined when the beam directions of the default RO and NES RO are different from each other. For example, when the beam directions of the default RO and NES RO are different from each other and therefore the beam direction of the NES RO needs to be changed to the beam direction of the default RO, it may be necessary to additionally consider the beam switching time gaps for the overlapping default RO and NES RO beam direction configurations (e.g., beam switching between a specific NES RO beam direction overlapping with the default RO and a NES RO beam direction not overlapping with the default RO). Therefore, when determining whether there is overlap between the NES RO and the default RO in the time domain, it may be necessary to additionally consider the size of the pre-configured / defined time gaps. For example, when determining whether the default RO and NES RO overlap in the time domain, the time 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 interval between the default RO and the NES RO is less than the configured time interval, the UE can consider the default RO and the NES RO to overlap in the time domain and apply the above method, or it can consider / determine that the NES RO is an invalid RO. For example, even if the time resources of the default RO and the NES RO do not actually overlap, if the time interval between the time resources of the default RO and the NES RO is less than the pre-configured time interval, the default RO and the NES RO can still be considered / treated as overlapping.

[0268] 2. Method #2: Method for receiving dynamic activation instructions from BS-configured NES RO (or NES RO configuration)

[0269] The UE can receive from the BS a configuration of a specific RNTI / CORESET / SS (search space) set for monitoring the activation of the (GC-)DCI indicating the NES RO (or NES RO configuration / 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 the activation of the NES RO (or NES RO configuration / parameter set). Alternatively, reserved bits of a specific DCI format (e.g., DCI format 1_0) can be used for indications of NES RO (de)activation. For example, a specific RNTI / CORESET / SS set can be configured for the UE to receive a DCI (DCI format 1_0) indicating only the activation / deactivation of the NES RO configuration (or NES RO parameter set) and not the default RO configuration (or default RO parameter set). 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 of whether NES RO is activated or the NES RO configuration is configured based on DCI format 1_0 with a CRC scrambled by the P-RNTI. A default RO configuration or default RO parameter set can be deactivated / inactivated by DCI, and if configured, it can be used for PRACH or PRACH preamble transmission.

[0270] Alternatively, when indicating the (de)activation of a NES RO (or NES RO configuration / parameter set) via (GC-)DCI or MAC-CE, the UE can receive a (de)activation indication for at least one pre-configured NES RO via a specific field / bit within (GC-)DCI. Alternatively, the UE can receive an indication to switch from the (currently active) first NES RO (or NES RO configuration / parameter set) to a second NES RO (or NES RO configuration / parameter set) via DCI (e.g., DCI format 1_0) or MAC-CE. For example, the BS can use a 1-bit field within GC-DCI to indicate the (de)activation of a NES RO (or NES RO configuration / parameter set). For example, when the value of the 1-bit field is 0, activation of the NES RO (or NES RO configuration / parameter set) can be indicated. When the value of the 1-bit field is 1, deactivation of the NES RO (or NES RO configuration / parameter set) can be indicated. In this scenario, each NES RO configuration can have different RO cycles / modes, etc. Switching between RO configurations can be indicated by deactivating the default RO and activating the NES RO. Alternatively, activation indicators, based on a specific state that can be indicated by GC-DCI, can represent the activation of the default RO and the activation of the NES RO (or the deactivation of the default RO and the activation of the NES RO), and deactivation indicators can represent the activation of the default RO and the deactivation of the NES RO.

[0271] The DCI indicating whether NES RO is activated can be configured similarly to the DCI format 2_9 indicating (de)activation of the version 18 NES cell DTX / DRX configuration. 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 NES RO configuration #1, NES RO configuration #2, and NES RO configuration #3, respectively. Alternatively, the bits of the bitmap from left to right can be configured to indicate (de)activation of the default RO, NES RO configuration #1, and NES RO configuration #2, respectively. Alternatively, when considering multiple cells configured for the UE, the bits / fields within the bitmap associated with cell #1 can indicate (de)activation of NES RO configuration #1 and NES RO configuration #2 for cell #1, and the bits / fields associated with cell #2 can indicate (de)activation of NES RO configuration #1 and NES RO configuration #2 for cell #2, respectively.

[0272] When a specific NES RO configuration is (de)activated via (GC-)DCI or MAC CE, additional indication / configuration may be required regarding the time at which the specific NES RO configuration is applied (available) and the effective duration of the configuration. As one approach, taking into account UE application latency (e.g., UE processing time), the indicated specific NES RO configuration can be applied (or the RO according to the specific NES RO configuration can be considered available or usable) when a predefined / configured time point / time (e.g., T symbols / slots) has elapsed after the reception of (GC-)DCI or MAC CE (e.g., in standard documentation). In this case, the UE can perform RACH or PRACH transmissions using the NES RO according to the specific NES RO configuration after a predefined time has elapsed from the time of DCI reception. Specifically, in the case of deactivation, without considering UE application latency, the specific NES RO configuration can be considered immediately deactivated upon reception / indication of (GC-)DCI or MAC CE. Alternatively, the activation / deactivation time point of a specific NES RO configuration indicated by (GC-)DCI or MAC CE can be determined based on an index corresponding to one of the predefined application time points / time candidates indicated by (GC-)DCI or MAC CE. Alternatively, a specific NES RO can be configured / indicated to begin application (or activation) from an associated (pattern) period occurring after the time point / time indicated by (GC-)DCI (or MAC CE).

[0273] For the effective duration of the indicated active NES RO configuration (or when the effective durations of the NES RO configurations are the same, or when the activation of the NES RO configuration is indicated at the same period), the effective duration of the specific NES RO configuration for which the activation indication is given can continue until the next (GC-)DCI or MAC CE indication is received. Alternatively, a predefined / configured timer (or effective duration) can be applied (e.g., in standard documentation). In this case, the activation indication for a specific NES RO configuration can be considered valid while the timer is running (or within its effective duration). One of a plurality of preconfigured timer (or effective duration) candidate values ​​can be directly indicated as the value of the timer (or effective duration) by (GC-)DCI or MAC CE. Alternatively, when the timer expires (or the effective duration has elapsed), the configuration can automatically fall back to the previous NES RO configuration that was active before the (GC-)DCI or MAC CE indication was received. Alternatively, when one of a plurality of pre-configured NES RO configurations is determined / configured as the default NES RO configuration, the expiration of a timer can trigger a switch from the specific NES RO configuration indicated by the activation indicator to the default NES RO configuration (or its activation / deactivation). Alternatively, the effective duration of the specific NES RO configuration indicated by the activation indicator can be configured / indicated based on each associated (mode) period.

[0274] Alternatively, a specific duration (predefined / configured) can be divided into N time intervals, and the UE can be configured to dynamically receive indications of the availability of the NES RO (or NES RO configuration) for each divided time interval. For example, when the default RO configuration and NES RO configuration #1 are provided, a duration of 160 ms can be divided into 20 ms time intervals, and the activation / deactivation of the NES RO configuration or the availability of the NES RO can be indicated for each 20 ms time interval via an 8-bit bitmap included in the (GC-)DCI.

[0275] When a RACH (PRACH, MsgA, or Msg1) retransmission is required, the NES RO or NES RO configuration can be indicated as available. For example, the UE can receive a dynamic indication of the availability of the NES RO and its effective duration / timer via the DCI used to schedule RACH (PRACH, MsgA, or Msg1) retransmissions. For example, the UE can receive an indication of whether the NES RO / NES RO configuration is available for RACH (PRACH, MsgA, or Msg1) retransmissions and information about the effective duration of the NES RO via the DCI used to schedule RACH (PRACH, MsgA, or Msg1) retransmissions. Alternatively, when the UE transmits RACH via the NES RO and the transmission fails, and the NES RO is no longer valid when the UE attempts to retransmit the RACH (or PRACH), the UE can be configured / instructed to retransmit the RACH (or PRACH) via the default RO. Alternatively, when the NES RO is deactivated during RACH (or PRACH) retransmission, the UE can treat the RACH (or PRACH) transmission as failed (e.g., the UE can treat the maximum retransmission count (maximum counter) as reached). Additionally, the NES RO available for RACH (or PRACH) retransmission can become available after a RACH transmission fails via the default RO (e.g., due to an indication that the NES RO configuration is activated via DCI after a RACH transmission failure). In this case, the UE can be configured / indicated to preferentially use the NES RO for RACH (or PRACH) retransmission, or to preferentially use the default RO even when the NES RO is available. Alternatively, the UE can be pre-configured by the BS regarding which of the default RO and NES RO should be preferentially used for RACH (or PRACH) retransmission. When a RACH (or PRACH) transmission fails a predetermined number of times (predefined / set number / maximum counter) via the default RO, the UE can be configured / indicated to switch to the NES RO (or vice versa) and attempt to transmit (retransmit) the RACH (or PRACH). Alternatively, the UE can be configured to perform the initial PRACH transmission using only the default RO, and can be configured / indicated to use both the NES RO and the default RO from the start of PRACH retransmissions. The availability and effective duration (or timer) of the NES RO can be indicated via the CFRA scheduling DCI (PDCCH command RACH procedure). The UE can receive indications of dynamic adaptation of the SSB burst / SSB index / SSB index group period via the (GC-)DCI or MAC CE. The availability of the NES RO can also be dynamically indicated in the indication of SSB transmission period adaptation.

[0276] The BS can determine whether to activate / deactivate NES RO based on communication conditions within its coverage area. For example, when the BS determines that frequent RACH transmission failures from the UE occur based on reports of the UE's PRACH transmission power (or power rise counter), the BS can indicate the activation of NES RO. For example, based on the UE's PRACH transmission power, the BS can determine frequent RACH transmission failures when the number of UEs retransmitting PRACH or the number of collisions between UEs sending RACH (e.g., the number of received PRACHs with the same RAPID) is greater than or equal to a specific threshold. Alternatively, the BS can determine whether to activate NES RO based on RACH congestion levels reported periodically via a specific UL signal / channel. Alternatively, the BS can receive information / signaling from the UE requesting the activation of NES RO via a pre-configured specific UL signal / channel, and can indicate the availability / activation of NES RO in response to such request. For example, an NES UE can request an NES RO when a RACH retransmission is required, or it can request an NES RO along with the transmission of a RACH (or PRACH) for contention-based random access (CBRA) or contention-free random access (CFRA). For example, a request for an NES RO for RACH retransmission can be sent via a separately configured RO / RAPID (Random Access Preamble ID) or via a specific UL signal / channel (e.g., (SR)PUCCH, CG-PUSCH, or P / SP-PUCCH / PUSCH). Alternatively, when SCell activation is indicated via SIB1, SCell configuration (add / modify / release), or MAC CE, the BS can configure / indicate whether an on-demand RO procedure can be performed and the associated resources (e.g., resources for requesting an NES RO).

[0277] The method proposed above can also be applied to the timing of PUSCH for Msg A in the 2-step RACH process.

[0278] 3. Method #3: Configuring the default (or initial) state when an attached RO (or NES RO) is configured.

[0279] As described above, additional ROs (e.g., NES ROs) for the NES can be configured for the UE via higher-layer signaling such as RRC. In this case, the activation of the additional RO (NES RO) configuration can be explicitly indicated / configured to the UE via a separate parameter. Alternatively, when no separate configuration / indication for the default state is provided in the additional RO configuration, the default state of the additional RO can be predefined / agreed upon between the UE and the BS as active (or deactivated). Alternatively, when the default state of the additional RO is configured as deactivated, the additional RO / additional RO configuration can be indicated as active via DCI or MAC CE. Conversely, when the default state of the additional RO is configured as active, the additional RO / additional RO configuration can be indicated as deactivated via additional DCI.

[0280] Furthermore, when multiple additional RO configurations are configured for the UE, the UE can receive an explicit indication of the initially active additional RO configuration among the multiple additional RO configurations. For example, the UE can determine the additional RO configuration with the highest or lowest index among the multiple additional RO configurations as the initially active additional RO configuration, or it can determine the additional RO explicitly indicated by a separate parameter as the initially active additional RO. Alternatively, when all additional RO configurations are set to a deactivated state during the initial configuration operation and a default additional RO configuration is subsequently configured / defined, the default additional RO configuration can be determined / considered to be activated by default, even without a separate indication / configuration for its default state. Alternatively, when there is no separate configuration / indication for the default state of the default additional RO configuration, the default state of the default additional RO configuration can be considered / defined as an active state, and the default additional RO / additional RO configuration can be deactivated by a separate DCI.

[0281] 4. Method #4: Configuring Msg A PUSCH resources when the attached RO (NES RO) supports 2-step RACH.

[0282] The BS can provide the UE (or a UE with NES capability) with a configuration indicating whether only the NES RO is available among the ROs configured by the BS, or both the default RO and the NES RO are available (e.g., default RO configuration and NES RO configuration), and / or a priority configuration indicating which of the default RO and the NES RO will be preferentially available. When the priorities of the ROs (default RO and NES RO) are pre-configured, the BS can predict the ROs on which the UE will transmit PRACH based on the priority configuration. Additionally, when the NES RO also supports a 2-step RACH procedure (e.g., when MsgA PRACH / PUSCH for a 2-step RACH procedure can be transmitted on the NES RO), a separate MsgA PUSCH resource for the NES RO does not need to be configured separately. For example, the NES RO configuration can be configured by an indication of a specific time / frequency offset relative to the default RO configuration (default RO configuration + time / frequency offset), and MsgA PUSCH resources for / about the NES RO can be configured based on the specific time / frequency offset. For example, similar to parameters introduced for Integrated Access and Backhaul (IAB) (e.g., PRACH-ConfigurationPeriodScaling-IAB), the UE can determine / configure the NES RO by applying a specific time / frequency offset (e.g., an offset separately indicated for the NES RO configuration) to the default RO configuration configured by rach-ConfigCommon, and the UE can determine the MsgA PUSCH resource for the NES RO by applying the same specific time / frequency offset to the MsgA PUSCH resource configured for the default RO. Alternatively, the time / frequency offset for configuring / determining the MsgA PRACH / PUSCH to be used for performing the 2-step RACH procedure via the NES RO can be indicated separately from the time / frequency offset applied to the default RO to configure the NES RO.

[0283] Therefore, according to the proposal of this disclosure, by configuring additional NES ROs (e.g., additional ROs) for NES UEs (UEs supporting Rel-19 NES features) in addition to the default RO (relatively sparse RO) for traditional UEs, a certain level of BS power saving gain can be expected while preventing excessive access latency for UEs.

[0284] Figure 13 This diagram illustrates a method for a UE to send signals based on RACH resource configuration information.

[0285] The UE can be an NES-aware UE capable of supporting NES operations performed by the BS / cell. As described above, the UE can be configured with a default RO configured in relation to PRACH (e.g., also configured for conventional UEs that are not NES-aware UEs) and additional NES-related ROs (or PRACH configurations) from the NES BS / NES cell (hereinafter, NES cell) performing NES operations. The method described below relates to the aforementioned "adaptation for energy-efficient PRACH". Therefore, even if not explicitly described below, the combination of Figure 13 Some of the methods described can also be naturally applied to the methods described under "Adaptation for Energy-Saving PRACH".

[0286] Specifically, refer to Figure 13 The UE can receive Random Access Channel (RACH) resource configuration information (S131) ​​for configuring a default RO and additional ROs related to Network Energy Saving (NES). For example, as described above, the RACH resource configuration information can configure at least one default RO and at least one additional RO. The additional RO can be an RO additionally configured for the UE (which is an NES-aware UE) in relation to the NES operation / management of the BS, and can be defined as an NES RO. Alternatively, the RACH resource configuration information can include a first set of parameters for configuring the default RO and a second set of parameters for configuring the additional RO, and the period of the NES RO can be shorter than the period of the default RO.

[0287] Additionally, the activation of an additional RO can be indicated via a specific DCI format. For example, as mentioned above, the activation / deactivation of an additional RO can be indicated via a DCI of group common DCI format 1_0. For instance, the UE can receive an activation indication via reserved bits included in a DCI of DCI format 1_0. Alternatively, the Paging-Radio Network Temporary Identifier (P-RNTI) used to indicate the activation of an additional RO can be configured as a specific RNTI, and the UE can receive an indication of the activation of an additional RO solely via a DCI of DCI format 1_0 with a CRC scrambled by the P-RNTI. Unlike additional ROs, a default RO can always be available regardless of the DCI. In other words, when configured by RACH resource configuration information, the default RO can always be determined as a valid RO, regardless of any activation indication via the DCI.

[0288] Alternatively, the RACH resource configuration information may also include specific offset information (e.g., time offset and / or frequency offset) for configuring additional ROs based on the default RO. For example, the UE may determine the default RO based on the RACH resource configuration information, and may determine additional ROs by applying the specific offsets included in the specific offset information to the determined default RO. Alternatively, the RACH resource configuration information may also include priority information for configuring the priority between the default RO and the additional ROs, and the UE may determine the RO among the default RO and the additional ROs to be used for PRACH transmission based on the priority information.

[0289] Next, the UE can transmit PRACH based on RACH resource configuration information (S133). For example, when the additional RO is active (e.g., activation is indicated by paging-related DCI), the UE can transmit PRACH or a PRACH preamble (a preamble corresponding to the RAPID determined for the UE) from the default RO and the additional RO (or selected according to an indication from the BS). Alternatively, the UE can determine the RO for transmitting PRACH or a PRACH preamble based on the SSB-to-RO mapping result for the default RO and the additional RO. For example, when the reception quality of the SSB with SSB index 1 is the best among multiple SSBs, the UE can transmit PRACH or a PRACH preamble from the default RO and the additional RO mapped to SSB index 1.

[0290] Alternatively, when an additional RO overlaps with a default RO, the UE can use at least one of the SSB-to-RO mapping methods proposed in "Method #1" above to determine the beam direction for the additional RO. For example, the UE can determine / configure multiple default ROs including the default RO and multiple additional ROs including the additional RO based on RACH resource configuration information. In this case, when a specific additional RO among the multiple additional ROs overlaps with a default RO, the UE can consider the specific additional RO invalid and perform SSB-to-RO mapping for the remaining additional ROs. Alternatively, when an additional RO overlaps with a default RO, the UE can perform SSB-to-RO mapping only for the remaining additional ROs among the multiple additional ROs that exclude the specific additional RO. In this case, it can be determined / considered that the beam direction of the specific additional RO is the same as the beam direction of the default RO.

[0291] Figure 14 This is a diagram illustrating the method by which a BS sends RACH resource configuration information.

[0292] according to Figure 14The BS / cell capable of performing NES operations can send RACH resource configuration information to the UE (S141). This RACH resource configuration information is used to configure the default RO (e.g., the RO configured for a traditional UE that is not an NES-aware UE) and the additional RO (or PRACH configuration) for the NES-aware UE, which are typically configured with respect to PRACH. For example, as described above, the RACH resource configuration information can configure at least one default RO and at least one additional RO. The additional RO can be defined as an NES RO, which is additionally configured for the UE (which is an NES-aware UE) in relation to the BS's NES operations / management. Alternatively, the RACH resource configuration information may include a first set of parameters for configuring the default RO and a second set of parameters for configuring the additional RO, and the period of the NES RO may be shorter than the period of the default RO.

[0293] Next, the BS can indicate whether the additional RO is activated via a DCI of a specific format (S143). For example, the BS can indicate the activation of the additional RO to the UE via reserved bits included in the DCI of DCI format 1_0. Alternatively, the Paging-Radio Network Temporary Identifier (P-RNTI) used to indicate the activation of the additional RO can be configured as a specific RNTI, and the BS can indicate the activation / deactivation of the additional RO via a DCI of DCI format 1_0 with a CRC scrambled by the P-RNTI.

[0294] Alternatively, the RACH resource configuration information may also include specific offset information (e.g., time offset and / or frequency offset) for configuring additional ROs based on the default RO. Alternatively, the RACH resource configuration information may also include priority information for configuring the priority between the default RO and the additional ROs.

[0295] Next, the BS can receive PRACH based on the RACH resource configuration information (S145). For example, when the additional RO is active (e.g., activation is indicated by paging-related DCI), the BS can monitor the PRACH or PRACH preamble in both the default RO and the additional RO.

[0296] Alternatively, when the additional RO overlaps with the default RO, the BS can expect to determine the beam direction for the additional RO using at least one of the SSB-to-RO mapping methods proposed in “Method #1” above.

[0297] As described above, according to this disclosure, additional ROs can be configured to dynamically adapt to the NES, thereby allowing the RO period to be quickly adjusted according to BS conditions. Alternatively, according to this disclosure, the activation / deactivation of additional ROs can be efficiently indicated using existing DCI formats without defining separate DCIs. Alternatively, according to this disclosure, the energy-saving gain of the BS can be increased by configuring a long period for the default RO. In addition, additional ROs with relatively short periods can be dynamically adapted according to BS conditions, thereby effectively addressing the UE access latency problem caused by the increased period of the default RO.

[0298] Example of a communication system using this disclosure

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

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

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

[0302] Reference Figure 15The 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.

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

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

[0305] Examples of wireless devices using this disclosure

[0306] Figure 16 Wireless devices applicable to this disclosure are illustrated.

[0307] Reference Figure 16 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 15 {Wireless Device 100x and BS 200} and / or {Wireless Device 100x and Wireless Device 100x}.

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

[0309] 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 14 At least one program related to the operations described in the implementation method.

[0310] Processor 102 can control transceiver 106 to receive Random Access Channel (RACH) resource configuration information for configuring the default RO and additional ROs associated with NES; and to transmit PRACH based on the RACH resource configuration information. Here, the activation of additional ROs can be indicated by a DCI in a specific format.

[0311] Alternatively, a processing device may be configured including a processor 102 and a memory 104 configured to control the UE. 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 random access channel (RACH) resource configuration information for configuring the default random access channel timing (RO) and additional ROs related to network power saving (NES); and transmit physical random access channel (PRACH) based on the RACH resource configuration information. In this document, the activation of additional ROs may be indicated by downlink control information (DCI) in a specific format.

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

[0313] 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 14 At least one program related to the operations described in the implementation method.

[0314] Processor 202 can control transceiver 206 to transmit Random Access Channel (RACH) resource configuration information for configuring the default Random Access Channel Timing (RO) and additional ROs related to Network Energy Saving (NES); and to receive Physical Random Access Channel (PRACH) based on the RACH resource configuration information. In this document, the activation of additional ROs can be indicated by downlink control information (DCI) in a specific format.

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

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

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

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

[0319] Examples of wireless devices using this disclosure

[0320] Figure 17 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 15 ).

[0321] Reference Figure 17 Wireless devices 100 and 200 can correspond to Figure 16The 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 16 One or more processors 102 and 202 and / or one or more memories 104 and 204. For example, transceiver 114 may include Figure 16 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.

[0322] 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 15 100a), vehicles ( Figure 15 100b-1 and 100b-2), XR device ( Figure 15 100c), handheld device ( Figure 15 100d), home appliances ( Figure 15 100e), IoT devices ( Figure 15 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 15 400), BS ( Figure 15 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.

[0323] exist Figure 17In 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.

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

[0325] Figure 18 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.

[0326] Reference Figure 18 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 17 Blocks 110 / 130 / 140.

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

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

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

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

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

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

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

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

[0335] Industrial applicability

[0336] 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) resource configuration information for configuring the default random access channel timing (RO) and additional ROs related to network energy saving (NES); as well as The Physical Random Access Channel (PRACH) is transmitted based on the RACH resource configuration information. Whether the additional RO is activated is indicated by a specific format of downlink control information (DCI).

2. The method according to claim 1, wherein, The DCI of the specific format is a group common DCI of format 1_0 with a cyclic redundancy check (CRC) scrambled by a specific paging-radio network temporary identifier (P-RNTI) associated with the activation indication of the additional RO.

3. The method according to claim 2, wherein, Whether the additional RO is activated is indicated by the reserved bits included in the DCI of the DCI format 1_0.

4. The method according to claim 1, wherein, Based on the overlap between the additional RO and the default RO, the beam direction of the additional RO is considered to be the same as the beam direction determined for the default RO.

5. The method according to claim 1, wherein, Since the additional RO overlaps with the default RO, the additional RO is considered invalid.

6. The method according to claim 1, wherein, The RACH resource configuration information configures multiple default ROs, including the default RO, and multiple additional ROs, including the additional ROs. Specifically, the UE performs synchronization signal block (SSB) mapping only for the remaining additional ROs among the plurality of additional ROs, excluding those that overlap with the default RO.

7. The method according to claim 1, wherein, The RACH resource configuration information includes information for configuring the priority between the default RO and the additional RO.

8. The method according to claim 1, wherein, The RACH resource configuration information includes information about specific offsets used to configure the additional RO based on the default RO.

9. The method according to claim 1, wherein, The default RO is always valid regardless of whether it is activated by the DCI.

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 to perform operations, including: Receive Random Access Channel (RACH) resource configuration information for configuring the default Random Access Channel Timing (RO) and additional ROs related to Network Energy Saving (NES); and The Physical Random Access Channel (PRACH) is transmitted based on the RACH resource configuration information. Whether the additional RO is activated is indicated by a specific format of downlink control information (DCI).

12. The UE according to claim 11, wherein, The DCI of the specific format is a group common DCI of format 1_0 with a cyclic redundancy check (CRC) scrambled by a specific paging-radio network temporary identifier (P-RNTI) associated with the activation indication of the additional RO.

13. 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, The instruction is executed by the at least one processor, and the instruction causes the UE to perform an operation, the operation including: Receive Random Access Channel (RACH) resource configuration information for configuring the default Random Access Channel Timing (RO) and additional ROs related to Network Energy Saving (NES); and The Physical Random Access Channel (PRACH) is transmitted based on the RACH resource configuration information. Whether the additional RO is activated is indicated by a specific format of downlink control information (DCI).

14. A method performed by a base station, the method comprising the following steps: Send random access channel (RACH) resource configuration information for configuring the default random access channel timing (RO) and additional ROs related to network energy saving (NES); as well as The Physical Random Access Channel (PRACH) is received based on the RACH resource configuration information. Whether the additional RO is activated is indicated by a specific format of downlink control information (DCI).

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 to perform operations, including: Send Random Access Channel (RACH) resource configuration information for configuring the default Random Access Channel Timing (RO) and additional ROs related to Network Energy Saving (NES); and The Physical Random Access Channel (PRACH) is received based on the RACH resource configuration information. Whether the additional RO is activated is indicated by a specific format of downlink control information (DCI).

Images