System and method for early indication and configuration of on-demand system information

Abstract

A system and method performed by a user equipment (UE) in a wireless communication system are disclosed. The method comprises: receiving, from a network node, an indication of a synchronization signal block (SSB) associated with an on-demand system information block 1 (OD-SIB1) cell provided in a master information block (MIB) or provided as a reservation value in a search space configuration; determining whether the SSB corresponds to an OD-SIB1 cell based on a wake-up signal (WUS) configuration from the anchor cell; sending a request for the OD-SIB1 transmission to the network node based on the determination; and receiving the OD-SIB1 from the OD-SIB1 cell.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 645,589, filed May 10, 2024; U.S. Provisional Application No. 63 / 697,090, filed September 20, 2024; and U.S. Non-Provisional Patent Application No. 19 / 201,020, filed May 7, 2025, the disclosures of which are incorporated herein by reference in their entirety as if fully set forth herein. Technical Field

[0003] This disclosure generally relates to the energy efficiency of wireless communication systems and networks. More specifically, the subject matter disclosed herein relates to improving SIB1 transmission in cellular networks by introducing an on-demand System Information Block 1 (SIB1) mechanism for idle and inactive user equipment (UEs) to reduce network power consumption. Background Technology

[0004] Wireless communication networks have evolved to accommodate ever-increasing data demands, leading to denser deployments, greater operational bandwidth, and the widespread use of multi-antenna technologies. While these advancements have improved performance, they have also resulted in significant power consumption, which has become a major operating cost for network operators. Traditionally, power-saving measures have focused primarily on reducing energy consumption at the UE (User Equipment) level, with limited efforts directed towards optimizing network-side energy efficiency.

[0005] To address this challenge, the 3GPP (3rd Generation Partnership Project) introduced network-level power-saving features in Release 18, primarily targeting UEs in RRC_CONNECTED mode. However, a significant gap remains because UEs in RRC_IDLE and RRC_INACTIVE states also periodically access system information, leading to unnecessary energy consumption on the network side. Some network operations rely on periodic transmissions of SIB1 to ensure all idle and inactive UEs receive the necessary system information. While this guarantees seamless connectivity, it also results in continuous energy consumption even when no UE actively requests system information.

[0006] One problem with this periodic broadcasting method is its inefficiency in scenarios where few or no UEs require SIB1 at a given time. The lack of an adaptive mechanism for sending SIB1 only on demand leads to unnecessary power consumption and reduced network energy efficiency. Furthermore, in the absence of an explicit procedure for on-demand SIB1 (also known as OD-SIB1) requests, idle and inactive UEs lack a means to trigger their transmissions, making it difficult to achieve network-side energy savings without negatively impacting connectivity and accessibility. Summary of the Invention

[0007] To overcome these issues, this document describes systems and methods for on-demand SIB1 transmission, allowing UEs to dynamically request system information as needed, rather than relying on continuous network broadcasts. This disclosure provides an early indication mechanism that enables idle and inactive UEs to determine whether a cell is operating on an on-demand SIB1 basis or following a traditional periodic transmission model. An uplink wake-up signal (WUS) configuration is also introduced, allowing UEs to trigger SIB1 transmissions when necessary, thereby reducing unnecessary network broadcasts. Adaptive resource allocation techniques are implemented to efficiently configure the control resource set and search space to manage on-demand SIB1 transmissions while maintaining backward compatibility with legacy UEs. Furthermore, this disclosure includes a network coordination process that enables inter-cell communication between anchor and non-anchor cells, ensuring that SIB1 transmissions occur effectively based on UE requests. Various deployment scenarios are supported to seamlessly integrate on-demand SIB1 into existing cellular networks while maintaining compatibility with standardized processes.

[0008] The described method improves upon previous approaches by reducing network-side energy consumption through the elimination of unnecessary SIB1 transmissions while maintaining reliable access to UEs in idle and inactive states. Through the use of wake-up signaling, intelligent resource allocation, and adaptive network coordination, the proposed techniques enhance the efficiency, flexibility, and scalability of next-generation wireless networks. These improvements contribute to greater sustainability, reduced operating costs for network operators, and improved overall network performance without compromising UE accessibility.

[0009] According to embodiments of this disclosure, a method performed by a UE in a wireless communication system is provided. The method includes: receiving from a network node an indication of a synchronization signal block (SSB) associated with an On-Demand System Information Block 1 (OD-SIB1) cell provided in a Master Information Block (MIB) or as a reserved value in a search space configuration; determining whether the SSB corresponds to the OD-SIB1 cell based on a wake-up signal (WUS) configuration from an anchor cell; based on the determination, sending a request for OD-SIB1 transmission to the network node; and receiving OD-SIB1 from the OD-SIB1 cell.

[0010] According to another embodiment of this disclosure, a UE is provided. The UE includes a processor and a memory storing instructions that, when executed by the processor, cause the UE to: receive from a network node an indication of an SSB associated with an OD-SIB1 cell provided in the MIB or as a reserved value in the search space configuration; determine, based on the WUS configuration from the anchor cell, whether the SSB corresponds to the OD-SIB1 cell; based on the determination, send a request for OD-SIB1 transmission to the network node; and receive OD-SIB1 from the OD-SIB1 cell.

[0011] According to another embodiment of this disclosure, a method performed by a UE in a wireless communication system is provided. The method includes: sending a WUS to a network node to initiate an OD-SIB1 request; receiving from the network node an indication of an OD-SIB1 transmission opportunity corresponding to the sent WUS; and decoding the OD-SIB1 based on the received indication. Attached Figure Description

[0012] In the following sections, aspects of the subject matter disclosed herein will be described with reference to exemplary embodiments shown in the accompanying drawings, wherein:

[0013] Figures 1A-1C Three different deployment scenarios for on-demand SIB1 transmission in a wireless communication system are illustrated according to various embodiments.

[0014] Figure 2 This refers to a network deployment scenario where the anchor cell, according to the embodiment, is used as the main connection point of the UE, rather than the anchor cell, to handle on-demand SIB1 transmissions.

[0015] Figure 3 This is a network deployment scenario where the anchor cell, according to the embodiment, has the ability to trigger non-anchor cells to send on-demand SIB1;

[0016] Figure 4 This is a network deployment scenario where the anchor cell handles the entire on-demand signaling process according to the embodiment.

[0017] Figure 5 This is a network deployment scenario where on-demand SIB1 operation is independent of the anchor cell, according to the embodiment.

[0018] Figure 6 This is a flowchart illustrating a method for a UE to identify, request, and receive OD-SIB1 according to an embodiment;

[0019] Figure 7 This is a flowchart illustrating the NES UE operation when the Network Energy Saving (NES) UE first detects the anchor cell according to an embodiment;

[0020] Figure 8 This is a flowchart illustrating the NES UE operation for determining whether OD-SIB1 is enabled according to an embodiment;

[0021] Figure 9 This is a flowchart illustrating the NES UE operation for determining whether OD-SIB1 is enabled according to an embodiment;

[0022] Figure 10 This is a flowchart illustrating NES UE operation via SSB indication through an asynchronous grid, according to an embodiment;

[0023] Figure 11 This is a flowchart illustrating NES UE operations for detecting and selecting a suitable cell according to an embodiment;

[0024] Figure 12 This is a flowchart illustrating NES UE operations for early identification of OD-SIB1 NES cells according to an embodiment;

[0025] Figures 13A to 13B This is a flowchart illustrating NES UE operation for early indication and configuration of OD-SIB1 according to various embodiments;

[0026] Figure 14 This is a block diagram of an electronic device in a network environment according to an embodiment; and

[0027] Figure 15 This is a block diagram of a system according to an embodiment, including UEs and network nodes communicating with each other. Detailed Implementation

[0028] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of this disclosure. However, those skilled in the art will understand that various aspects of the disclosure may be practiced without these specific details. In other instances, well-known methods, processes, components, and circuits have not been described in detail so as not to obscure the subject matter of this disclosure.

[0029] Throughout this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment disclosed herein. Therefore, the phrases "in one embodiment," "in an embodiment," or "according to an embodiment" (or other phrases with similar meanings) appearing in various places throughout this specification may not necessarily all refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In this regard, as used herein, the word "exemplary" means "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" should not be construed as necessarily preferred or advantageous over other embodiments. Additionally, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Furthermore, depending on the context of the discussion herein, singular terms may include corresponding plural forms, and plural terms may include corresponding singular forms. Similarly, hyphenated terms (e.g., "two-dimensional", "predetermined", "pixel-specific", etc.) may occasionally be used interchangeably with their non-hyphenated counterparts (e.g., "two-dimensional", "predetermined", "pixel-specific", etc.), and uppercase entries (e.g., "counter clock", "row selection", "pixel output", etc.) may be used interchangeably with their non-uppercase counterparts (e.g., "counter clock", "row selection", "pixel output", etc.). This occasional interchangeability should not be considered inconsistent with each other.

[0030] Furthermore, depending on the context of the discussion herein, singular terms may include corresponding plural forms, and plural terms may include corresponding singular forms. It should also be noted that the various figures shown and discussed herein (including component diagrams) are for illustrative purposes only and are not drawn to scale. For example, the dimensions of some elements may be enlarged relative to others for clarity. Additionally, reference numerals are repeated in the figures where deemed appropriate to indicate corresponding and / or similar elements.

[0031] The terminology used herein is for the purpose of describing some exemplary embodiments only and is not intended to limit the claimed subject matter. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprising” and / or “including” as used in this specification specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0032] It will be understood that when an element or layer is referred to as being on, "connected to," or "coupled to" another element or layer, it can be directly on, connected to, or coupled to the other element or layer, or there may be intermediate elements or layers. Conversely, when an element is referred to as being "directly on," "directly connected to," or "directly coupled to" another element or layer, there are no intermediate elements or layers. The same reference numerals always indicate the same element. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0033] The terms “first,” “second,” etc., used herein serve as labels for nouns that follow them and do not imply any kind of ordering (e.g., spatial, temporal, logical, etc.) unless explicitly defined as such. Furthermore, the same reference numerals may be used across two or more figures to indicate parts, components, blocks, circuits, units, or modules having the same or similar functions. However, this usage is merely for simplicity of description and ease of discussion; it does not imply that the construction or architectural details of such components or units are identical across all embodiments, or that such commonly referenced parts / modules are the only way to implement some of the exemplary embodiments disclosed herein.

[0034] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this subject pertains. It will be further understood that terms (such as those defined in common dictionaries) shall be interpreted as having a meaning consistent with their meaning in the context of the relevant field and shall not be interpreted in an idealized or overly formal sense unless expressly defined herein.

[0035] As used herein, the term "module" indicates any combination of software, firmware, and / or hardware configured to provide the functionality described herein in conjunction with modules. For example, software may be embodied as a software package, code, and / or instruction set or instructions, and the term "hardware," as used in any implementation described herein, may include, for example, components, hardwired circuitry, programmable circuitry, state machine circuitry, and / or firmware storing instructions executed by programmable circuitry, either individually or in any combination. Modules may be embodied collectively or individually as circuitry forming part of a larger system, such as, but not limited to, integrated circuits (ICs), system-on-a-chip (SoCs), components, etc.

[0036] As used in this article, "network node" refers to an entity in a wireless communication system that facilitates network operations, including sending and receiving data, managing connections, and coordinating wireless access. Some examples of "network nodes" are base stations, gNBs, eNBs, relay nodes, or network servers.

[0037] The term "On-Demand SIB1" (also known as OD-SIB1) used in this article refers to a system information transmission mechanism in which SIB1 is not broadcast periodically, but is sent in response to requests from the UE. Some examples of "On-Demand System Information Block 1" are OD-SIB1 transmissions triggered by WUS, OD-SIB1 transmissions initiated by Physical Random Access Channel (PRACH) requests, and OD-SIB1 scheduling via System Information Radio Network Temporary Identifier (SI-RNTI)-NE.

[0038] As used in this article, "synchronization signal block" refers to a transmission unit in a wireless network, including synchronization signals and system information, to help the UE detect and synchronize with the cell. Some examples of "synchronization signal blocks" are the primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH), which jointly assist in cell search and initial access.

[0039] As used in this article, "WUS" refers to a signal sent by the UE to indicate that it needs SI or network access, or to signal that the network has become active. Some examples of "WUS" are UL WUS transmissions to OD-SIB1 cells, PRACH-based WUS for requesting OD-SIB1, and contention-free or contention-based wake-up requests.

[0040] As used herein, “cell” refers to a logical radio access entity defined by its transmission configuration, frequency, and identification parameters, through which network nodes provide radio coverage and signaling. Some examples of “cells” are traditional cells that periodically transmit SIB1, OD-SIB1 cells that support OD-SIB1 delivery, and NES cells that operate under energy-saving signaling configurations.

[0041] As used in this article, "anchor cell" (also known as cell A) refers to a cell that serves as the primary reference for the UE and provides auxiliary information (such as WUS configuration and OD-SIB1 configuration) for accessing non-anchor cells. Some examples of "anchor cells" are macro cells that coordinate OD-SIB1 transmissions and legacy cells that provide WUS configuration to NES UEs.

[0042] This disclosure describes procedures and signaling methods for supporting on-demand SSB transmissions for secondary cells (SCells) when a UE is operating in a connected mode with in-band or inter-band configuration using carrier aggregation (CA). The methods include various triggering mechanisms, such as UL WUS transmitted using existing signals or channels, indications for cell activation or deactivation via backhaul communication, or direct signaling for SCell activation and deactivation. This on-demand SSB transmission is supported in both frequency range 1 (FR1) and frequency range 2 (FR2) in a non-shared spectrum environment, allowing the UE to perform time and frequency synchronization, perform Layer 1 and Layer 3 measurements, and activate the SCell.

[0043] To enhance network energy efficiency, this disclosure also provides a process for enabling on-demand SIB1 transmissions for UEs in idle or inactive modes. The process involves triggering SIB1 transmissions via UL WUS transmitted through existing signals or channels, and providing the UE with a predefined WUS configuration. Furthermore, information exchange between gNBs (network nodes or cells) may be included to facilitate WUS configuration management. The proposed solution ensures that UEs in idle or inactive states can effectively request and receive SIB1s without requiring continuous periodic transmissions, thereby reducing network-side energy consumption.

[0044] To further optimize energy efficiency, this disclosure describes adaptations to common signaling and channel transmission processes. These adaptations include modifications to the periodicity of SSB transmissions, adjustments to the timing of PRACH operations, and modifications to the allocation of PRACH resources in the spatial domain. Specifically, this disclosure examines the feasibility of using non-uniform PRACH resources per SSB to optimize resource allocation. Adaptations to paging timing are also considered to ensure that paging signals are confined to a specified time domain without introducing additional delays. These optimizations aim to minimize the impact on legacy UEs while providing significant network energy savings.

[0045] The requirements necessary to implement these features are specified to ensure seamless integration with existing and future cellular network architectures. As part of these developments, this disclosure defines a specific scenario where a UE receives UL WUS configuration from an anchor cell, transmits UL WUS on an NES cell, and subsequently receives on-demand SIB1 from the NES cell. In this scenario, the anchor cell (also known as Cell A) is responsible for periodically transmitting its own SIB1, while the NES cell remains inactive until triggered by UL WUS. Once activated, the NES cell transmits SIB1 upon request by the UE, thereby ensuring minimal power consumption while maintaining accessibility. The system also specifies signaling exchanges between Next-Generation Radio Access Network (NG-RAN) nodes to coordinate the configuration and management of UL WUS, ensuring effective operation and minimal impact on legacy UEs.

[0046] To maintain backward compatibility and minimize disruption to existing network operations, various embodiments ensure that modifications to SSB transmissions are avoided as much as possible. Furthermore, the impact on legacy UEs is minimized, and any necessary changes to existing specifications are carefully managed to ensure a smooth transition to on-demand SIB1 functionality. These implementations result in a more energy-efficient network that reduces unnecessary transmissions while preserving necessary connections for UEs in idle and inactive states.

[0047] Figures 1A-1C Three different deployment scenarios for on-demand SIB1 transmission in wireless communication systems are illustrated according to various embodiments.

[0048] refer to Figures 1A-1C Each scenario represents different approaches to achieving on-demand SIB1 by using NES cells and, in some cases, by using anchor cells (cell A) for coordination.

[0049] In the "Standard Solution" Figure 1A In this scenario, the NES cell operates independently, handling both UL WUS configuration and SIB1 transmission. The UE communicates directly with the NES cell, which remains in a low-power state until triggered by the UE's UL WUS. Once WUS is received, the NES cell sends on-demand SIB1 to the UE. This method minimizes energy consumption by ensuring that the NES cell remains inactive unless the UE requests system information.

[0050] In the multi-cell / carrier solution labeled "with OD-SIB1 on NES cells" Figure 1B In this process, cell A is involved, which is responsible for providing the UL WUS configuration to the UE. The UE first obtains this configuration from cell A and then sends the UL WUS to the NES cell. Upon receiving the WUS, the NES cell sends the requested SIB1 to the UE. This configuration allows for greater flexibility because of the anchor cell management signaling, while the NES cell conserves power until needed.

[0051] In the multi-cell / carrier solution labeled "with OD-SIB1 on the anchor" Figure 1C In this approach, the anchor cell itself is responsible for transmitting SIB1. The UE receives the UL WUS configuration from the anchor cell and sends UL WUS to request system information. Instead of responding to the NES cell, the anchor cell sends on-demand SIB1 to the UE. This method further optimizes energy efficiency through centralized control within the anchor cell, while reducing the need for NES cell activity.

[0052] In New Radio (NR) systems, SIB1 enables the UE to establish and maintain connectivity with the network. This process begins before the UE camps on a cell. During this phase, the UE performs a cell search by scanning available cells and evaluating their signal strength and quality. Once a potential cell is identified, the UE proceeds to cell reselection, which involves reading minimum system information, including MIB and SIB1, to determine if a particular cell meets the necessary criteria for selection. Based on this information, the UE selects a suitable cell and camps on it.

[0053] After successfully camping on a cell, the UE continues to monitor paging messages and other short messages sent by the network. Paging monitoring ensures that the UE maintains accessibility to incoming communications while conserving power. In addition, the UE monitors other relevant system information scheduled by SIB1, which may include parameters used for cell reselection and other operational settings. The UE also performs periodic measurements to assess the signal quality and suitability of its current cell, enabling it to determine whether reselecting a different cell is necessary. These behaviors are described by parameters contained in SIB1 and other relevant system information.

[0054] When a UE initiates a connection to transition from an idle or inactive state to an active state, it participates in the initial access procedure. This procedure begins with the transmission of message 1 (Msg1), which serves as the UE's initial access request to the network. Following this, the UE participates in the Random Access Channel (RACH) procedure to establish a connection with the network. The RACH procedure is managed by parameters defined in SIB1 and other relevant system information.

[0055] Therefore, SIB1 serves three main functions in the NR system. First, it allows the UE to determine whether a particular cell is suitable for camping during cell selection and reselection procedures. Second, it provides necessary system information to UEs operating in idle or inactive modes within the camping cell, enabling them to monitor paging and maintain network awareness. Third, it facilitates the execution of the RACH procedure, allowing the UE to switch to Radio Resource Control (RRC) connection mode and establish a connection with the network.

[0056] In one or more technical specifications (TS), the MIB content (combining "pdcch-ConfigSIB1" and "K") SSBThe "(ssb-SubcarrierOffset)" value (described below) indicates whether an associated SIB1 (Cell Defined Synchronization Signal Block (CD-SSB)) exists or does not exist (non-CD-SSB). In the former case, the MIB can provide the necessary information for monitoring the associated SIB1 Physical Downlink Control Channel (PDCCH), while in the latter case, the MIB can provide the UE with auxiliary information to find another frequency grid that may potentially have a CD-SSB. The MIB field descriptions in TS 38.331 are provided in Table 1 below.

[0057]

[0058]

[0059] In TS 38.213, Table 2-3 is used to map the index to #0 and each of the search space #0.

[0060] Table 2: For a frequency band with a minimum channel bandwidth of 5 MHz or 10 MHz, when the {SS / PBCH block, PDCCH}SCS is {15, 15} kHz, the set of resource blocks and time slot symbols used for the Type 0-PDCCH search space set.

[0061]

[0062]

[0063] Table 3: Parameters for PDCCH monitoring timing for Type 0-PDCCH Common Search Space (CSS) set - SS / PBCH blocks and multiplexing modes 1 and FR1

[0064]

[0065]

[0066] Figure 2 This refers to a network deployment scenario where the anchor cell, according to the embodiment, is used as the main connection point for the UE, rather than the anchor cell, to handle on-demand SIB1 transmissions.

[0067] refer to Figure 2 Anchor cells typically do not support NES features and primarily facilitate the configuration of uplink WUS (UL WUS) for UEs operating in RRC_IDLE or RRC_INACTIVE states. In some embodiments, the anchor cell itself may be an already activated NES cell. However, such configuration is not required. Information related to on-demand signaling is exchanged between anchor and non-anchor cells and can be executed using backhaul signaling, especially if the cells are not co-located.

[0068] Once the UE receives the UL WUS configuration from the anchor cell, it sends the UL WUS to the non-anchor cell, requesting the transmission of SIB1. The non-anchor cell then processes the request and sends the required on-demand SIB1 to the UE. In this configuration, the non-anchor cell must remain active to monitor the WUS, which results in increased energy consumption. Additionally, because the non-anchor cell processes the SIB1 transmission, the UE switches between the anchor and non-anchor cells to receive the requested information.

[0069] Figure 3 This is a network deployment scenario where the anchor cell, according to the embodiment, has the ability to trigger non-anchor cells to send on-demand SIB1.

[0070] refer to Figure 3 In this configuration, the anchor cell manages both the UL WUS configuration and reception from the UE in the RRC_IDLE or RRC_INACTIVE state. When the UE sends UL WUS, the anchor cell receives the request and subsequently triggers a non-anchor cell to send on-demand SIB1.

[0071] The advantage of this method is that non-anchor cells can remain in a completely dormant state until they are explicitly activated by an anchor cell. This reduces network-side energy consumption for non-anchor cells when there are no active SIB1 requests. However, similar to... Figure 2 In this scenario, once a non-anchor cell has been activated, the UE still switches between anchor cells and non-anchor cells to receive the on-demand SIB1.

[0072] Figure 4 This is a network deployment scenario where the anchor cell handles the entire on-demand signaling process according to the embodiment.

[0073] refer to Figure 4 In this configuration, the UE does not necessarily need to interact directly with the non-anchor cell. Here, the anchor cell first provides the UL WUS configuration to the UE. When the UE sends the UL WUS, the anchor cell receives and processes the request. Instead of requiring the non-anchor cell to become active and send on-demand SIB1, the anchor cell retrieves the relevant SIB1 information from the non-anchor cell via backhaul signaling and delivers it to the UE.

[0074] This scenario provides improved network energy efficiency for non-anchor cells because they do not require wake-up or direct SIB1 transmission. Energy consumption associated with non-anchor cells comes from backhaul information exchange, which requires fewer resources. Furthermore, the method reduces the need for UE handover between anchor and non-anchor cells, simplifying UE operation and reducing latency.

[0075] Figure 5 This is a network deployment scenario where on-demand SIB1 operation is independent of the anchor cell, according to the embodiment.

[0076] refer to Figure 5 In this configuration, the non-anchor cell is responsible for handling on-demand signal configuration, receiving UL WUS transmissions, and transmitting on-demand SIB1 to UEs in RRC_IDLE or RRC_INACTIVE states.

[0077] Anchor cells facilitate information exchange and transmission. Figure 4 The situation is different in China. Figure 5 This scenario requires a direct signaling mechanism to guide the UE to the correct non-anchor cell when the UL WUS is sent. Once the UL WUS is sent, the non-anchor cell processes the request and sends the on-demand SIB1 without intervention from the anchor cell. However, this configuration makes it necessary for the UE to switch between anchor and non-anchor cells to obtain the on-demand SIB1.

[0078] This scenario allows for greater flexibility in on-demand SIB1 deployments, but requires additional mechanisms to ensure effective signaling and cell selection.

[0079] One of the main challenges in implementing on-demand SIB1 in an NES environment is how an idle or inactive NES UE can identify whether a given NES cell is operating on on-demand SIB1 or following the conventional SIB1 transmission method. In a legacy network without NES operation, the UE knows where or how to find SIB1 because it is transmitted periodically. However, in an NES operation scenario, the UE may be required to actively request SIB1 transmissions. Since it is not expected that the NES UE will transmit before receiving SIB1, a mechanism is needed that allows the NES UE to determine whether a cell supports on-demand SIB1 or follows the conventional transmission method, and to effectively acquire SIB1 while in idle mode.

[0080] Another issue arises in scenarios with isolated cells supporting a single deployment of On-Demand SIB1. In such cases, it can be difficult to indicate the UL WUS configuration required to trigger On-Demand SIB1 without significant modifications to the existing system architecture. Typically, this information is obtained via the PBCH or MIB. While extending the MIB might be a viable option for some 5G and 6G systems, implementing it in legacy systems is challenging without industry stakeholder resistance. Therefore, an efficient method should be introduced to indicate the UL WUS configuration with minimal or no modification to the MIB.

[0081] Another challenge is how to indicate the controlResourceSetZero and searchSpaceSetZero used for on-demand SIB1. In legacy systems, these parameters can be mapped using predefined tables specified in 3GPP TS 38.213, ensuring the UE can locate the necessary resources for SIB1 acquisition. However, this mapping mechanism cannot be used for on-demand SIB1 because the existence of SIB1 cannot be guaranteed. This necessitates a new method for indicating when on-demand SIB1 is being utilized.

[0082] Another issue concerns how the NES UE can effectively determine which cell A (anchor cell) provides the corresponding UL WUS information necessary to request on-demand SIB1 on that particular NES cell after identifying the NES cell. In a real-world deployment, multiple cell A instances may exist, and each cell A instance may or may not include the UL WUS configuration for a given NES cell. Without a suitable mechanism, the NES UE may be forced to perform inefficient blind searches across multiple cells. Therefore, a method is needed to efficiently inform the NES UE which cell A includes the relevant UL WUS configuration for a specific NES cell, thereby improving system efficiency and reducing unnecessary signaling overhead.

[0083] The various embodiments disclosed herein provide solutions to the challenges described above and offer new methods for improving the efficiency of OD-SIB1 transmission in NES environments.

[0084] According to embodiments, a technique is introduced that enables idle or inactive NES UEs to determine whether a given NES cell is operating in OD-SIB1 mode or following a conventional periodic transmission model. Since NES UEs are not expected to transmit before receiving SIB1, existing methods do not allow them to determine the presence of OD-SIB1. This disclosure provides an enhanced signaling mechanism that allows NES UEs to identify OD-SIB1 operation earlier, ensuring they can effectively request and obtain the necessary system information.

[0085] According to an embodiment, a method is provided for a UE in idle or inactive mode to obtain UL WUS configuration in a single-cell deployment scenario without requiring significant modifications to system-level broadcast. In scenarios where isolated cells support OD-SIB1, traditional methods relying on MIB or PBCH may be unsuitable, especially for legacy systems. This solution introduces an alternative signaling method that enables the UE to retrieve the UL WUS configuration with minimal changes to the existing broadcast structure, thus ensuring compatibility with both legacy and future networks.

[0086] According to embodiments, to address the issues with the indication of controlResourceSetZero and searchSpaceSetZero in OD-SIB1, this disclosure provides a mechanism that allows the UE to locate necessary control resources despite the absence of periodic SIB1 transmissions. In legacy systems, these parameters are mapped via predefined tables in 3GPP TS 38.213, which assumes the existence of periodically broadcast SIB1s. Since OD-SIB1 does not follow this model, different methods are introduced to dynamically indicate control resource allocation in NES deployments.

[0087] According to an embodiment, this disclosure describes a method for using a new RNTI to indicate OD-SIB1 transmissions. Since the conventional SI-RNTI is designed for periodic SIB1 transmissions, this disclosure proposes a modified RNTI (SI-RNTI-NES) for efficient scheduling of OD-SIB1. By using this new RNTI, the network can dynamically allocate resources for OD-SIB1 transmissions while maintaining energy efficiency.

[0088] According to embodiments, this disclosure provides a method for indicating to an NES UE which cell A includes the relevant UL WUS configuration and OD-SIB1 settings for a given NES cell. In practical deployments, multiple anchor cells may exist, and not all anchor cells can store the necessary UL WUS configuration. Without proper signaling, the NES UE may need to blindly search for the correct cell, leading to inefficient network operation. The proposed solution introduces signaling enhancements that allow the NES UE to efficiently locate the correct anchor cell, thereby ensuring minimal signaling overhead and faster OD-SIB1 acquisition.

[0089] In one embodiment, a solution is provided to enable idle or inactive NES UEs to identify whether a cell supports on-demand SIB1 transmission. To maintain backward compatibility, legacy UEs that do not support on-demand SIB1 should not camp on cells operating with on-demand SIB1. Simultaneously, NES UEs should be able to identify whether a cell supports NES features and then apply appropriate behavior. To achieve these objectives, several solutions are proposed in embodiments that rely on modifying existing signaling elements by reusing some existing bits in the MIB, using reserved values ​​in certain fields of the MIB, utilizing specific locations in synchronization signal blocks, or incorporating additional bits into the MIB to indicate on-demand SIB1 support. Different approaches have been developed, each applicable to the various deployment scenarios described in the background section.

[0090] One such solution involves setting the ssbSubcarrierOffset field to a reserved value, specifically 31 for FR1 or 15 for FR2, to indicate that automatically transmitted SIB1 is not present in the cell. A legacy UE, upon encountering an ssbSubcarrierOffset set to 31 or 15, interprets this as meaning the cell does not support SIB1 and therefore will not attempt to camp on it. However, an NES UE, upon receiving the same value, will understand that while automatic SIB1 is absent, the cell can support on-demand SIB1. To further confirm this, an additional field, ODSIB1Enabled, is introduced. The ODSIB1Enabled field is set in reserved bits of the MIB, or provided from the anchor cell via UL WUS configuration or on-demand SIB1 configuration, where a list of NES cell IDs is maintained. If ODSIB1Enabled is set to 1, the NES UE is allowed to request on-demand SIB1. If ODSIB1Enabled is set to zero, the NES UE does not initiate such a request. Since traditional UEs do not attempt to decode SIB1 when ssbSubcarrierOffset is set to 15 or 31, any reserved values ​​in controlResourceSetZero and searchSpaceZero do not affect their operation.

[0091] Figure 6 This is a flowchart illustrating a method for a UE to identify, request, and receive OD-SIB1 according to an embodiment.

[0092] refer to Figure 6 The process begins at step 601, where the NES UE synchronizes with the network and decodes the PBCH to obtain the MIB. In step 602, the NES UE then checks the ssbSubcarrierOffset field to determine if its value is set to 31 in FR1 or 15 in FR2. If the value does not match these reserved amounts, in step 603, the NES UE expects SIB1 to be automatically transmitted. If the value is set to 15 or 31, the NES UE assumes that automatic SIB1 transmission is not possible and continues checking the ODSIB1Enabled flag. In step 604, the NES UE then verifies whether ODSIB1Enabled is set to zero or one. If the flag is set to zero, the NES UE determines in step 605 that the cell does not support on-demand SIB1 and does not proceed further. If the flag is set to one, the NES UE determines that on-demand SIB1 can be requested and continues to obtain ULWUS configuration in step 606.

[0093] If the NES UE has not yet received the UL WUS configuration and OD-SIB1 configuration, it should determine which cell A provides these configurations for the detected NES cell. Since multiple cell A instances can exist, the NES UE should effectively locate the correct cell A instance. To avoid blindly searching for cell A, the NES UE can use pre-configured controlResourceSetZero and searchSpaceZero pairs stored in pdcch-ConfigSIB1. Each pair can correspond to a different Global Synchronization Channel Number (GSCN) offset, indicating the location of cell A's SSB and PBCH. The NES UE can determine the nearest (in the corresponding frequency direction) GSCN of the cell that defines the SS / PBCH block sent by the cell (or cells) including the UL WUS configuration for the detected NES cell. Or as Another value of the function. Here, It is the GSCN of the first SS / PBCH block, in FR1 and FR2-1. In FR2-2 and The GSCN offset value is selected based on the values ​​of the controlResourceSetZero and searchSpaceZero pairs in pdcch-ConfigSIB1. The NES UE can determine the nearest frequency location of cell A that transmits SSB and PBCH, and use it to obtain the UL WUS configuration for the detected NES cell.

[0094] Then, in step 607, the NES UE retrieves the OD-SIB1 configuration, including the allocation of controlResourceSetZero and searchSpaceZero. Once the NES UE has obtained the necessary configuration, it sends a UL WUS request for OD-SIB1 in step 608. After successful request processing, in step 609, the NES UE receives the OD-SIB1 transmission from the NES cell. This method ensures that the NES UE can efficiently determine whether the cell supports OD-SIB1, locate the appropriate configuration source, and request OD-SIB1 without interfering with traditional UE configuration or frequency range, thereby improving network efficiency and energy saving.

[0095] UL WUS configuration and OD-SIB1 configuration can be indicated by the anchor cell via RRC messages, such as newly defined SIB messages that include a list of OD-SIB1 NES cell IDs. Alternatively, existing paging messages from the anchor cell can be used to deliver UL WUS configuration and on-demand SIB1 settings. Since idle or inactive UEs have already received paging messages, embedding WUS configuration in paging allows for power savings on both the anchor cell and the on-demand SIB1 NES cell by sending WUS configuration only when needed.

[0096] In another scenario, the MIB or PBCH of the non-anchor cell itself can indicate the UL WUS configuration and OD-SIB1 configuration, rather than depending on the anchor cell. This ensures that NES UEs can independently determine on-demand SIB1 support in non-anchor deployments.

[0097] In this scenario, once a Rel-19 UE identifies an NES cell that supports On-Demand SIB1, the UL WUS configuration can indicate this to the UE using reused bits from searchSpaceZero and controlResourceSetZero. Other available bits in the MIB or PBCH can also be used to signal the UL WUS configuration. For example, one possibility involves using the subCarrierSpacingCommon bit, which, if selected, ensures that only a single subcarrier spacing value corresponding to the SSB is allowed for the Rel-19 NES UE.

[0098] Another possible approach involves using the dmrs-TypeA-Position bits, where one of the two possible positions—pos2 or pos3—can be defined as the default value for the NES cell. Furthermore, it is possible to reuse the LSB, which includes four bits of the ssb-SubcarrierOffset. If the range of offset values ​​is reduced to eight possible values ​​using three bits, the remaining bits can be used to indicate the UL WUS configuration.

[0099] For example, in the traditional specification, both controlResourceSetZero and searchSpaceZero are four-bit fields. To indicate a UL WUS configuration, one or more bits from either of these fields can be reused. Possible UL WUS configurations can be mapped to various bit combinations and pre-configured for a Rel-19 UE. For example, two methods can be used to signal both the UL WUS configuration and the on-demand SIB1 configuration. The first method could involve using one or more bits from controlResourceSetZero and searchSpaceZero to indicate the UL WUS configuration, while the remaining bits are used to indicate the on-demand SIB1 configuration. The second method can assume that each UL WUS configuration is pre-mapped or linked to a specific on-demand SIB1 configuration. In this case, using one or more bits from controlResourceSetZero and searchSpaceZero to indicate the UL WUS configuration will automatically determine the corresponding on-demand SIB1 configuration.

[0100] Each UL WUS configuration can include various parameters, such as an indication of the WUS type, including contention-based random access (CBRA) or contention-free random access (CFRA) WUS, and whether the WUS is CBRA-based message 1 or message 3. The configuration can also indicate WUS triggering conditions or events, specific frequencies, times, and preamble resource pools allocated to the WUS signal, and uplink transmission timing. In the time domain, the UL WUS signal for OD-SIB1 can have a predefined offset relative to the most recent SSB reception, ensuring that a minimum number of WUS time slots are transmitted after the most recent SSB reception. In the frequency domain, the WUS signal for On-Demand SIB1 can be transmitted at a predefined offset relative to the SS / PBCH location. For example, the UL WUS configuration can be mapped according to Table 4 below.

[0101] Table 4

[0102]

[0103] In addition to the usual UL WUS parameters, this configuration can specify UL WUS-related PRACH settings. The PRACH configuration can include details about which non-anchor cells will receive PRACH transmissions. For example, a mapping can be established between one or more PRACH resources and one or more non-anchor cell IDs to ensure that PRACH is sent on the appropriate non-anchor cells. Similarly, the PRACH configuration can define which non-anchor cells should be triggered for OD-SIB1 transmissions, thus allowing the mapping between PRACH resources and corresponding non-anchor cell IDs. Furthermore, the configuration can define UL WUS PRACH parameters, including search space settings that indicate where the UE can receive Random Access Response (RAR) or Message 4 transmissions from non-anchor cells, particularly in the case of UL WUS based on Message 1 or Message 3. This configuration information is shown in Table 5 below.

[0104] Table 5

[0105]

[0106]

[0107] ULWUS configuration can also be signaled to Rel-19 idle or inactive UEs via extended RRC messages from the anchor cell. This can involve adding new fields or information elements (IEs) to SIB1 or System Information Block 3 or 4 (SIB3 / SIB4). Alternatively, new SIBs can be introduced specifically for NES-related information. Paging messages or RRC connection release messages from the anchor cell can also be used to transmit UL WUS and OD-SIB1 configuration information.

[0108] Upon receiving a PRACH allocated to trigger OD-SIB1, the gNB (cell) can send a RAR as an acknowledgment. Additionally, when PRACH resources are associated with multiple non-anchor cells, the gNB can schedule Physical Uplink Shared Channel (PUSCH) transmissions to request further information from the UE, such as non-anchor cell indices.

[0109] The method used to determine where to send WUS can be based on predefined rules. For example, WUS can be sent in a specific predetermined frequency resource determined based on the frequency location of the SSB within a specific number of time slots after the SSB is received.

[0110] For the OD-SIB1 transport configuration, including its associated controlResourceSetZero and searchSpaceZero, the necessary parameters can be indicated using reused bits within the tables of searchSpaceZero and controlResourceSetZero as defined in the MIB of 3GPP specification 38.213. This method allows the reuse of reserved bits within these fields to efficiently indicate the configuration required for OD-SIB1 transport. In addition to using the bits used for UL WUS configuration, the remaining bits in controlResourceSetZero and searchSpaceZero can be allocated to define CORESET#0 and search space#0 for OD-SIB1. OD-SIB1 transport can be configured as semi-persistent OD-SIB1 transport within a specific time window or as aperiodic OD-SIB1 transport.

[0111] Additional bits in the MIB or PBCH can also be used to indicate the OD-SIB1 configuration. One possible approach is to use the subCarrierSpacingCommon bit, which, if allocated, would allow a single subcarrier spacing value corresponding to the synchronization signal block used for Rel-19 NES UEs. Another option is to use the dmrs-TypeA-Position bit, which, if adopted, would allow position two or three to be defined as the default value for OD-SIB1 in the NES cell. Furthermore, it is possible to use an LSB comprising four bits of ssb-SubcarrierOffset. Depending on the synchronization and channel grid design in Radio Access Network Working Group 4 (RAN4), the range of the offset field can be reduced to eight values ​​by using only three bits for Rel-19 UEs. This frees up one bit within ssb-SubcarrierOffset, which can then be reused to indicate the OD-SIB1 configuration for Rel-19 UEs.

[0112] An example of CORESET#0 for OD-SIB1 is shown in Table 6 below.

[0113] Table 6

[0114]

[0115] An example of searchSpaceZero for OD-SIB1 is shown in Table 7 below.

[0116] Table 7

[0117]

[0118]

[0119] According to embodiments, modifications to the specification include the introduction of additional parameters O_start and O_end to define a time window for providing OD-SIB1 relative to the UE's UL WUS transmission timing. These parameters can be used to configure aperiodic OD-SIB1 transmissions, where O_start represents the start of the OD-SIB1 availability window and O_end represents the end of the availability window. In some embodiments, for semi-persistent OD-SIB1 transmissions, only O_start may be required because the periodic nature of the transmission eliminates the need for defined endpoints. Other parameters related to the search space zero can remain consistent with those in known specifications.

[0120] In some embodiments, the OD-SIB1 configuration may be included as part of the UL WUS configuration and may be sent to a Rel-19 idle or inactive UE via an extended RRC message from the anchor cell. In some embodiments, the anchor cell may transmit this information by introducing a new field or IE in the SIB1, SIB3, or SIB4 message. Alternatively, the OD-SIB1 configuration may be transmitted from the anchor cell via a paging message or an RRC connection release message, thereby enabling efficient delivery of OD-SIB1 configuration parameters to idle and inactive UEs.

[0121] In another embodiment, the UE can be configured to anticipate SIB1 reception during a predefined SIB1 monitoring period, wherein reception occurs T milliseconds (or a time slot) after the UE sends a UL WUS signal (message 1) or receives a downlink random access response (DLRAR) message (message 2). The predefined monitoring period ensures effective OD-SIB1 reception while minimizing unnecessary wake-ups and optimizing network resource utilization.

[0122] In another embodiment, the OD-SIB1 receive configuration for the OD-SIB1 request can be indicated in message 2 or message 4 of the four-step RACH procedure, including its associated CORESET#0 and searchSpaceZero. The specific message providing this configuration may depend on whether UL WUS is sent via message 1 or message 3. In some embodiments, for a contention-free RACH for UL WUS, message 2 may include the OD-SIB1 receive configuration, specifying CORESET#0, searchSpaceZero, and other parameters as described above. This signaling ensures that the UE receives the necessary OD-SIB1 configuration as part of the RACH procedure, thereby enabling efficient access to the requested system information.

[0123] Once the appropriate receive configuration is determined, the UE can continue to request its OD-SIB1 from the NES cell. Once the OD-SIB1 request is successfully processed, the UE can receive its OD-SIB1 transmission from the NES cell.

[0124] In another embodiment, if the NES UE first detects a cell designated as cell A, the NES UE can obtain UL WUS configuration and OD-SIB1 configuration from cell A. These configurations may include information assigning each NES cell or group of NES cells identified by its Physical Cell Identifier (ID) or associating it with specific PRACH resources for UL WUS transmission. PRACH resources may be allocated as dedicated preambles or dedicated random access opportunities (ROs) for a specific NES cell or group of NES cells. By including an indication of which UL WUS signal should be used to wake up a specific NES cell or group of NES cells, the system can avoid waking up all nearby NES cells, thereby reducing unnecessary network power consumption.

[0125] After obtaining the UL WUS and OD-SIB1 configuration from cell A, the NES UE can initiate a process to detect suitable NES cells to camp on, in addition to cell A. If the NES UE identifies an NES cell that meets the cell selection or reselection criteria based on SSB signal strength measurements (such as Reference Received Power (RSRP), Reference Received Quality (RSRQ), or Received Signal Strength Indicator (RSSI)), the NES UE continues UL WUS transmission. The NES UE can use the specific PRACH resource assigned to that NES cell to send the UL WUS. This ensures that the NES UE receives the Random Access Response (RAR) only from the intended NES cell, rather than from multiple NES cells in the surrounding area, thereby optimizing network efficiency.

[0126] Figure 7 This is a flowchart illustrating the NES UE operation when the NES UE first detects the anchor cell according to an embodiment.

[0127] refer to Figure 7 Step 701 represents the cell search operation performed by the NES UE. If cell A is detected, the process moves to step 702, where the NES UE determines whether the detected cell is indeed cell A. If the answer is no, the UE follows an alternative operation path in step 703, which does not involve obtaining the WUS configuration. If the answer is yes, the process proceeds to step 704, where the NES UE obtains the UL WUS configuration from cell A. Subsequently, in step 705, the NES UE retrieves the OD-SIB1 configuration from cell A.

[0128] In step 705, the NES UE selects a suitable NES cell for wake-up based on the SSB measurement results, ensuring that the selected NES cell meets the required signal strength criteria. Once a suitable NES cell is identified, the NES UE proceeds to step 707, where it uses the allocated PRACH resources to send a UL WUS request for the specific NES cell. Then, in step 708, the NES UE receives on-demand SIB1 transmissions from the selected NES cell, completing the process.

[0129] In one embodiment, the ssbSubcarrierOffset field can be set to a reserved value that is not recognized by legacy UEs. Specifically, the ssbSubcarrierOffset in the MIB of an OD-SIB1-supporting cell can be set to 30 in FR1 and 14 in FR2, both of which are reserved values ​​under the current specification. When a legacy UE decodes ssbSubcarrierOffset = 30 (FR1) or 14 (FR2), UE behavior that may not be defined for these values ​​in the specification will prevent the UE from decoding SIB1 and camping on the cell. This ensures that a legacy UE does not mistakenly attempt to access an OD-SIB1 cell. Meanwhile, the use of these reserved values ​​can serve as an early indication of OD-SIB1 support for NES UEs. Additionally, NES cells can be further indicated by using spare bits in the MIB or by reusing one of the reserved values ​​in controlResourceSetZero and / or searchSpaceZero. If this indication is not provided via the MIB, it can be included in the UL WUS configuration or OD-SIB1 configuration provided by the anchor cell, listing the cell IDs of all NES cells.

[0130] Figure 8 This is a flowchart illustrating the NES UE operation for determining whether OD-SIB1 is enabled according to an embodiment.

[0131] refer to Figure 8In step 801, the NES UE performs MIB acquisition, network synchronization, PBCH decoding, and MIB extraction. During this process, the NES UE may retrieve the ssbSubcarrierOffset field. In step 802, the NES UE evaluates whether ssbSubcarrierOffset is set to 14 (FR2) or 30 (FR1). If the offset is not set to these values, in step 803, the NES UE determines that the cell is a legacy cell that does not support OD-SIB1 and follows the legacy SIB1 reception procedure. If ssbSubcarrierOffset is set to 14 (FR2) or 30 (FR1), the NES UE identifies the cell as an NES cell, allowing it to apply the appropriate procedures for requesting and receiving OD-SIB1. In this case, in step 804, the NES UE proceeds to obtain the UL WUS configuration.

[0132] Figure 8 Steps 804-807 can respectively correspond to Figure 6 Steps 606-609 are described in a similar manner for clarity and consistency. However, it should be understood that variations may occur, and the embodiments described herein are not limited to any particular mapping between the steps in the different figures.

[0133] In one embodiment, the ssbSubcarrierOffset field can be set to 30>K in FR1. SSB Values ​​within the range of ≥24, and FR2 is set to 14>K. SSB Values ​​in the range of ≥12 are used to distinguish NES cells that support OD-SIB1 from cells lacking CD-SSBs. This ensures that a traditional UE, which can only distinguish between periodic SIB1 transmissions and those without SIB1 operation, will not attempt to camp on an NES cell. When all SSBs in an NES cell are non-core dedicated (NCD) SSBs, the UE can avoid selecting these cells and will continue searching for the nearest CD-SSB according to the traditional procedure. The pdcch-ConfigSIB1 field in the NES cell's MIB provides auxiliary information to guide this selection process.

[0134] Rel-19 UEs detecting only NCD-SSB cells should also determine whether the cell supports OD-SIB1 or is a traditional less-SIB1 cell. This determination can be made using the UL-WUS configuration provided by cell A, which is detected by the Rel-19 UE after identifying an NES cell. If the carrier frequency and Physical Cell ID (PCI) of the detected NES cell are included in either the UL-WUS configuration or the OD-SIB1 configuration provided by cell A, the UE can identify it as an OD-SIB1-supporting NES cell. Otherwise, the NES cell can be considered a less-SIB1 cell. The OD-SIB1 indication can be confirmed via spare bits in the MIB or via one of the reserved values ​​in controlResourceSetZero and / or searchSpaceZero.

[0135] Figure 9 This is a flowchart illustrating the NES UE operation for determining whether OD-SIB1 is enabled according to an embodiment.

[0136] refer to Figure 9 In step 901, the NES UE performs MIB acquisition, network synchronization, PBCH decoding, and MIB extraction, including the ssbSubcarrierOffset value. In step 902, the NES UE evaluates whether the ssbSubcarrierOffset falls within 30>K in FR1. SSB ≥24 or whether it falls within 14>K in FR2 SSB The value must be within the range of ≥12. If the value does not fall within these ranges, the UE determines in step 903 that the cell is a cell without OD-SIB1 support, and the UE applies the conventional SIB1 reception procedure. If the value falls within the specified range, the NES UE identifies the cell as a potential NES cell with OD-SIB1 or a low-SIB1 cell and proceeds to obtain further information from the anchor cell.

[0137] In step 904, the NES UE obtains the UL WUS configuration from the anchor cell. If the NES UE has not yet obtained the WUS and OD-SIB1 configurations, it should determine from which cell A to obtain these parameters. Since multiple cells can be used as cell A, blindly decoding all potential instances would result in unnecessary power consumption and latency. To address this, the ssbSubcarrierOffset used by the NES UE can be set to a value corresponding to the GSCN offset range where the SSB of cell A resides. The NES UE can determine the nearest GSCN associated with the cell that defines the SS / PBCH block, and the SS / PBCH block sends the UL WUS configuration for the NES cell.

[0138] GSCN can be used To determine, among which, It is the first SS / PBCH block GSCN. It is 1 in FR1 and FR2-1, and 3 in FR2-2. It is the GSCN offset derived from Tables 13-16 (FR1) and 13-17 (FR2) in 3GPP TS38.213 or from a new table defined for NES UE.

[0139] In this new table, each ssbSubcarrierOffset value can be mapped to a (controlResourceSetZero, searchSpaceZero) pair in pdcch-ConfigSIB1, where each pair corresponds to the value in the traditional table. Different If the NES UE detects a second SS / PBCH block that does not provide a UL WUS configuration corresponding to the detected NES cell, the UE can ignore the GSCN information associated with the SS / PBCH block when performing cell search.

[0140] In step 905, once the NES UE obtains the WUS configuration from the corresponding cell A, it determines whether the NES cell supports OD-SIB1 by checking whether its carrier frequency and PCI are listed in the UL-WUS configuration or OD-SIB1 configuration provided by cell A. If the information is not found, the NES UE determines in step 906 that the cell is a traditional cell with less SIB1 and follows the traditional procedure. Otherwise, the NES UE continues the OD-SIB1 procedure in step 907 by obtaining the OD-SIB1 configuration from the anchor cell.

[0141] In step 908, the NES UE sends a request for OD-SIB1 to the NES cell. In step 909, the NES UE receives OD-SIB1 from the NES cell, completing the process.

[0142] Figure 9 Steps 908-909 can respectively correspond to Figure 6 Steps 608-609 are described in a similar manner for clarity and consistency. However, it should be understood that variations may occur, and the embodiments described herein are not limited to any particular mapping between the steps in the different figures.

[0143] In one embodiment, a dedicated synchronization raster or asynchronous raster frequency is used to transmit SSBs in OD-SIB1-enabled cells. This ensures that UEs do not detect or attempt to camp on such cells because they operate only on the standard synchronization raster, which does not transmit SSBs for NES cells. Therefore, these NES cells remain undetectable to legacy UEs. Conversely, Rel-NES UEs will use a dedicated NES raster that includes NES configuration information, but they may also need to scan both legacy and NES raster frequencies to identify both legacy and NES cells.

[0144] To further enhance early identification of NES cells supporting OD-SIB1, SSBs can be transmitted at pre-configured or RRC-configured asynchronous grid frequency locations. Since other SSBs are transmitted at synchronous grid frequency locations, the UE will not be able to detect these NES cells. Version 19 NES UEs, in addition to performing conventional synchronous grid detection, can also detect SSBs at these asynchronous grid frequency locations, allowing them to identify candidate NES cells supporting OD-SIB1 for cell reselection. The feasibility of defining asynchronous grid locations for NES cells supporting OD-SIB1 may require confirmation from RAN4.

[0145] For example, the field "dl-CarrierFreq" in SIB4 can be expanded to include new values ​​beyond 0-3279165, which can define new asynchronous grid frequency locations for the SSB of NES cells supporting OD-SIB1. Alternatively, a new field "dl-CarrierFreq-Off_Raster" can be introduced in SIB4 to specify these new asynchronous grid frequency locations for NES cells supporting OD-SIB1. Furthermore, legacy cells supporting legacy SIB1 can use SIBx messages to notify Rel-19 idle / inactive UEs of the NES cell's SSB center frequency location. This can be done via fields defined in SIB1, reused fields in SIB1, or new / reused fields in the cell reselection configuration of SIB3 or SIB4. By receiving this information, a Rel-19 NES UE can know the asynchronous grid frequency locations for SSB detection in candidate NES cells supporting OD-SIB1. Alternatively, the NES UE may be pre-configured with certain asynchronous grid frequency locations for SSB detection in NES cells that support OD-SIB1.

[0146] Regarding UE behavior, two implementations are possible. In one option, the NES UE prioritizes detecting traditional cells before detecting NES cells. On the other hand, the NES UE detects both traditional and NES cells simultaneously and selects the first cell that meets the cell selection criteria.

[0147] Figure 10 This is a flowchart illustrating NES UE operation via SSB indication through an asynchronous grid, according to an embodiment.

[0148] refer to Figure 10 This process describes an embodiment of a method for determining network entry and selecting NES cells based on SSB detection, ensuring that Rel-19 NES UEs can effectively identify NES cells supporting OD-SIB1, while preventing legacy UEs from inappropriately camping on such cells. The method includes a structured sequence of UE operations, where each step is designed to ensure effective cell detection, reselection, and OD-SIB1 acquisition. Each block is described in detail below.

[0149] Refer again Figure 10 In step 1001, the NES UE initiates a search for a synchronization signal by attempting to detect the SSB on the legacy synchronization grid. This ensures that the UE first attempts to locate a legacy cell operating under the existing specifications. The NES UE follows the standard synchronization procedure, decodes the PBCH, and extracts the MIB, as per the legacy process.

[0150] In step 1002, the NES UE evaluates whether a suitable legacy cell has been detected based on legacy cell reselection criteria. If a suitable legacy cell is detected, the process proceeds to step 1003, where the NES UE acquires SIB1 through a legacy procedure. This allows the UE to complete network registration and operate under standard network conditions.

[0151] If, in step 1002, the NES UE determines that a suitable legacy cell has not been detected, the process proceeds to step 1004, where the NES UE attempts to detect an SSB on an asynchronous grid frequency. This step ensures that the NES UE can search for OD-SIB1-enabled NES cells that transmit their SSBs at dedicated or non-standard frequency locations that cannot be detected by a legacy UE.

[0152] In step 1005, the NES UE evaluates whether a suitable NES cell has been detected based on conventional reselection criteria. If no NES cell is detected, the process proceeds to step 1006, where the NES UE declares "No Service" (e.g., radio link failure) because no compatible network resources have been identified.

[0153] If the NES UE detects a suitable NES cell in step 1005, the process proceeds to step 1007, in which the NES UE obtains the WUS configuration.

[0154] Figure 10 Steps 1007-1010 can respectively correspond to Figure 6 Steps 606-609 are described in a similar manner for clarity and consistency. However, it should be understood that variations may occur, and the embodiments described herein are not limited to any particular mapping between the steps in the different figures.

[0155] Figure 11 This is a flowchart illustrating NES UE operations for detecting and selecting a suitable cell according to an embodiment.

[0156] refer to Figure 11 In step 1101, the NES UE initiates a scan of both the traditional synchronization grid and the asynchronous grid to detect SSBs transmitted by either the traditional cell or the NES cell. The NES UE follows the synchronization process by decoding the PBCH and extracting the MIB, where the MIB provides the information necessary to identify potential serving cells.

[0157] In step 1102, the NES UE determines whether it has detected a suitable traditional or NES cell that meets the cell selection or reselection criteria. If no suitable cell is detected, the process loops back to step 1101, where the NES UE continues scanning both the traditional synchronization grid and the asynchronous grid.

[0158] If a suitable cell is detected in step 1102, the process proceeds to step 1103, where the NES UE determines whether the detected cell is a traditional cell or an NES cell.

[0159] If the cell detected in step 1103 is determined to be a traditional cell, the process proceeds to step 1104, in which the NES UE follows the traditional procedure to obtain SIB1 from the traditional cell.

[0160] If the detected cell is identified as an NES cell, the process moves to step 1105, where the NES UE obtains the UL WUS configuration.

[0161] Figure 11 Steps 1105-1108 can respectively correspond to Figure 6 Steps 606-609 are described in a similar manner for clarity and consistency. However, it should be understood that variations are possible, and the embodiments described herein are not limited to any particular mapping between the steps in the different figures.

[0162] Figure 12 This is a flowchart illustrating NES UE operations for early identification of OD-SIB1 NES cells according to an embodiment.

[0163] refer to Figure 12 This process can be used to prevent legacy UEs from camping on such cells by employing a newly introduced System Information Radio Network Temporary Identifier (SI-RNTI-NES). The SI-RNTI-NES can be used to scramble Downlink Control Information (DCI) 1_0, where DCI 1_0 schedules SIB1 from OD-SIB1 NES cells.

[0164] Refer again Figure 12 In step 1201, the NES UE blindly decodes both SI-RNTI and SI-RNTI-NES while attempting to receive SIB1 from either a traditional cell or an NES cell. The purpose of this step is to ensure that the NES UE can correctly identify whether the detected cell is operating in traditional SIB1 transmission or whether it is an OD-SIB1 NES cell.

[0165] In step 1202, the NES UE determines whether SI-RNTI-NES is detected. If the UE does not detect SI-RNTI-NES, the process moves to step 1203, where the NES UE performs a standard legacy procedure to receive SIB1 from a legacy cell. Since legacy UEs are not designed to recognize SI-RNTI-NES, they will be unable to decode SIB1 from the OD-SIB1NES cell, effectively preventing them from camping on the NES cell.

[0166] If the NES UE detects SI-RNTI-NES in step 1202, the process moves to step 1204. In step 1204, the NES UE verifies whether the detected NES cell meets the predefined cell reselection criteria. If the criteria are not met, the UE defaults to the traditional SIB1 reception behavior from the traditional cell, similar to step 1203.

[0167] If the detected NES cell meets the reselection criteria in step 1204, the NES UE continues to obtain WUS configuration in step 1205.

[0168] Figure 12 Steps 1205-1208 can respectively correspond to Figure 6 Steps 606-609 are described in a similar manner for clarity and consistency. However, it should be understood that variations may occur, and the embodiments described herein are not limited to any particular mapping between the steps in the different figures.

[0169] In addition to the described process, SI-RNTI-NES scrambling can be used for DCI in various deployment scenarios. When an NES UE has requested OD-SIB1, it can monitor the PDCCH and attempt to decode the SI-RNTI-NES scrambled DCI to retrieve SIB1. This ensures that the NES UE can successfully receive OD-SIB1 while preventing legacy UEs from accessing the NES cell.

[0170] In another embodiment, to indicate the OD-SIB1 NES cell and prevent legacy UEs from accessing the OD-SIB1 cell, an anchor cell can be used to provide this information. The anchor cell can include the cell ID of the OD-SIB1 NES cell in the RRC message. This can be achieved by extending existing RRC messages from the anchor cell, such as by adding new fields or IEs to SIB1, SIB3, SIB4, or SIBx messages. Alternatively, paging messages or RRC release messages from the anchor cell can also be used to transmit this information to the NES UE.

[0171] Figure 13A This is a flowchart illustrating NES UE operation for early indication and configuration of OD-SIB1 according to an embodiment. Figure 13A The steps shown can be executed by the processor of an electronic device (e.g., UE) as instructions stored in memory.

[0172] refer to Figure 13A In step 1301a, the UE receives an indication of the SSB associated with the OD-SIB1 cell from the network node. This indication may be provided in the MIB or as a reserved value in the search space configuration. For example, the MIB may include K exceeding a threshold. SSB Values, such as K in FR1 SSB K in >23 or FR2 SSB >11 indicates OD-SIB1 operation.

[0173] In step 1302a, the UE determines whether the SSB corresponds to an OD-SIB1 cell based on the WUS configuration received from the anchor cell. The WUS configuration may include a mapping of PRACH resources to OD-SIB1 cell identifiers (such as physical cell IDs or frequencies).

[0174] In step 1303a, the UE sends a request for OD-SIB1 transmission, which can be sent via PRACH using a preamble associated with the NES cell. The PRACH configuration can be pre-configured or derived from the WUS configuration.

[0175] In step 1304a, the UE receives OD-SIB1. OD-SIB1 may be scheduled by the network and indicated using a DCI message scrambled with SI-RNTI or SI-RNTI-NES. OD-SIB1 may be transmitted by the OD-SIB1 cell over a predefined CORESET and search space, and the timing of the transmission may occur within a predefined offset after the WUS transmission, or as indicated by the DCI. In this regard, the statement "receive OD-SIB1 from the OD-SIB1 cell" may mean that OD-SIB1 is received by the UE and transmitted from the network node. "OD-SIB1 cell" may include information necessary to access OD-SIB1.

[0176] Figure 13B This is a flowchart illustrating NES UE operation for early indication and configuration of OD-SIB1 according to an embodiment. Figure 13A The steps shown can be executed by the processor of an electronic device (e.g., UE) as instructions stored in memory.

[0177] refer to Figure 13B In step 1301b, the UE sends a WUS to the network to initiate a request for OD-SIB1. The WUS can be sent according to the configuration received from the anchor cell and may include a mapping to a pre-configured PRACH resource associated with the target OD-SIB1 cell.

[0178] In step 1302b, the UE receives from the network an indication of an upcoming transmission opportunity for the requested OD-SIB1. This indication may be provided via a DCI scrambled using SI-RNTI-NES. The transmission opportunity may specify timing, frequency domain resources, or other scheduling parameters associated with OD-SIB1 and may reflect a pre-configured or dynamically allocated time slot in which OD-SIB1 is expected to be transmitted.

[0179] In step 1303b, the UE decodes OD-SIB1 (e.g., a received OD-SIB1 transmission) based on the received indication. For example, the UE can use the CORESET and search space configuration parameters provided in the WUS configuration or OD-SIB1 configuration in step 1303b.

[0180] Figure 14 This is a block diagram of an electronic device in a network environment according to an embodiment.

[0181] refer to Figure 14In network environment 1400, electronic device 1401 (e.g., UE) can communicate with electronic device 1402 via a first network 1498 (e.g., a short-range wireless communication network), or with electronic device 1404 or server 1408 via a second network 1499 (e.g., a long-range wireless communication network). Electronic device 1401 can communicate with electronic device 1404 via server 1408. Electronic device 1401 may include processor 1420, memory 1430, input device 1450, sound output device 1455, display device 1460, audio module 1470, sensor module 1476, interface 1477, haptic module 1479, camera module 1480, power management module 1488, battery 1489, communication module 1490, subscriber identity module (SIM) card 1496, or antenna module 1497. In one embodiment, at least one of the components (e.g., display device 1460 or camera module 1480) may be omitted from electronic device 1401, or one or more other components may be added to electronic device 1401. Some components may be implemented as a single integrated circuit (IC). For example, sensor module 1476 (e.g., fingerprint sensor, iris sensor, or illuminance sensor) may be embedded in display device 1460 (e.g., display).

[0182] Processor 1420 can execute software (e.g., program 1440) to control at least one other component (e.g., hardware or software component) of electronic device 1401 coupled to processor 1420, and can perform various data processing or calculations. For example, execution of instructions by processor 1420 can cause hardware components to perform operations such as sending, receiving, decoding, encoding, and / or determining operations based on received signals or configurations.

[0183] The various embodiments disclosed herein provide a structured approach to optimize network efficiency and improve UE performance when identifying and accessing NES cells that support OD-SIB1. Electronic device 1401 is able to implement the described method for detecting and processing OD-SIB1 transmissions by using components such as processor 1420, memory 1430, and communication module 1490. Processor 1420, in conjunction with memory 1430 storing instructions for scanning SSBs across both conventional and asynchronous grid frequencies, enables electronic device to efficiently distinguish between conventional and NES cells. Communication module 1490, in conjunction with antenna module 1497, facilitates SIB1 reception.

[0184] Furthermore, the integration of the power management module 1488 allows the electronic device 1401 to optimize power consumption during the detection and reselection process. By employing the described method, the device is able to avoid unnecessary wake-ups of NES cells and reduce network signaling overhead, thereby enhancing the energy efficiency of both the UE and the network. Additionally, the memory 1430 can store a pre-configured mapping between the UL WUS configuration and the NES cell ID, thereby allowing for rapid association and reduced latency in OD-SIB1 requests.

[0185] As at least part of data processing or computation, processor 1420 can load commands or data received from another component (e.g., sensor module 1476 or communication module 1490) into volatile memory 1432, process the commands or data stored in volatile memory 1432, and store the resulting data in non-volatile memory 1434. Processor 1420 may include a main processor 1421 (e.g., a central processing unit (CPU) or application processor (AP)) and an auxiliary processor 1423 (e.g., a graphics processing unit (GPU), image signal processor (ISP), sensor hub processor, or communication processor (CP)), wherein the auxiliary processor 1423 may operate independently of or in conjunction with the main processor 1421. Additionally or alternatively, the auxiliary processor 1423 may be adapted to consume less power than the main processor 1421 or to perform specific functions. The auxiliary processor 1423 may be implemented separately from or as part of the main processor 1421.

[0186] While the main processor 1421 is inactive (e.g., in sleep) state, the auxiliary processor 1423 may take over from the main processor 1421 to control at least some of the functions or states associated with at least one component of the electronic device 1401 (e.g., display device 1460, sensor module 1476, or communication module 1490). Alternatively, while the main processor 1421 is active (e.g., executing an application), the auxiliary processor 1423 may work with the main processor 1421 to control at least some of the functions or states associated with at least one component of the electronic device 1401 (e.g., display device 1460, sensor module 1476, or communication module 1490). The auxiliary processor 1423 (e.g., an image signal processor or a communication processor) may be implemented as part of another component (e.g., camera module 1480 or communication module 1490) associated with the functions of the auxiliary processor 1423.

[0187] Memory 1430 may store various data used by at least one component of electronic device 1401 (e.g., processor 1420 or sensor module 1476). The various data may include, for example, software (e.g., program 1440) and input or output data for commands associated therewith. Memory 1430 may include volatile memory 1432 or non-volatile memory 1434. Non-volatile memory 1434 may include internal memory 1436 and / or external memory 1438.

[0188] Program 1440 may be stored as software in memory 1430 and may include, for example, an operating system (OS) 1442, middleware 1444, or application 1446.

[0189] Input device 1450 can receive commands or data from outside electronic device 1401 (e.g., a user) to be used by another component of electronic device 1401 (e.g., processor 1420). Input device 1450 may include, for example, a microphone, mouse, or keyboard.

[0190] The sound output device 1455 can output sound signals to the outside of the electronic device 1401. The sound output device 1455 may include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as playing multimedia or recording, and the receiver can be used to receive incoming calls. The receiver can be implemented separately from the speaker or as part of the speaker.

[0191] Display device 1460 can visually provide information to the outside of electronic device 1401 (e.g., to a user). Display device 1460 may include, for example, a display, a holographic device, or a projector, and control circuitry for controlling a corresponding one of the display, holographic device, and projector. Display device 1460 may include touch circuitry adapted to detect touch or sensor circuitry adapted to measure the intensity of the force caused by touch (e.g., a pressure sensor).

[0192] Audio module 1470 can convert sound into electrical signals and vice versa. Audio module 1470 can obtain sound via input device 1450, or output sound via sound output device 1455 or headphones of external electronic device 1402 directly (e.g., wired) or wirelessly coupled to electronic device 1401.

[0193] Sensor module 1476 can detect the operating state of electronic device 1401 (e.g., power or temperature) or the environmental state outside electronic device 1401 (e.g., user state), and then generate an electrical signal or data value corresponding to the detected state. Sensor module 1476 may include, for example, a gesture sensor, gyroscope sensor, barometric pressure sensor, magnetic sensor, accelerometer, grip sensor, proximity sensor, color sensor, infrared (IR) sensor, biosensor, temperature sensor, humidity sensor, or illuminance sensor.

[0194] Interface 1477 may support one or more specified protocols for direct (e.g., wired) or wireless coupling between electronic device 1401 and external electronic device 1402. Interface 1477 may include, for example, a High Definition Multimedia Interface (HDMI), a Universal Serial Bus (USB) interface, a Secure Digital Card (SD) interface, or an audio interface.

[0195] Connection terminal 1478 may include a connector through which electronic device 1401 can be physically connected to external electronic device 1402. Connection terminal 1478 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0196] The haptic module 1479 can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that can be recognized by a user through tactile or kinesthetic sensation. The haptic module 1479 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

[0197] Camera module 1480 can capture still or moving images. Camera module 1480 may include one or more lenses, an image sensor, an image signal processor, or a flash. Power management module 1488 can manage the power supplied to electronic device 1401. Power management module 1488 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

[0198] Battery 1489 can supply power to at least one component of electronic device 1401. Battery 1489 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0199] Communication module 1490 can support the establishment of a direct (e.g., wired) or wireless communication channel between electronic device 1401 and external electronic devices (e.g., electronic device 1402, electronic device 1404, or server 1408), and perform communication via the established communication channel. Communication module 1490 may include one or more communication processors that can operate independently of processor 1420 (e.g., AP) and support direct (e.g., wired) or wireless communication. Communication module 1490 may include wireless communication module 1492 (e.g., cellular communication module, short-range wireless communication module, or Global Navigation Satellite System (GNSS) communication module) or wired communication module 1494 (e.g., local area network (LAN) communication module or power line communication (PLC) module). Corresponding communication modules among these communication modules can communicate via a first network 1498 (e.g., a short-range communication network, such as BLUETOOTH). TM The communication module 1492 communicates with external electronic devices via a second network 1499 (e.g., a long-distance communication network, such as a cellular network, the Internet, or a computer network (e.g., a LAN or a wide area network (WAN)) or a standard of Wi-Fi Direct or Infrared Data Association (IrDA). These various types of communication modules can be implemented as a single component (e.g., a single IC) or as multiple components separate from each other (e.g., multiple ICs). The wireless communication module 1492 can use subscriber information (e.g., International Mobile Subscriber Identity (IMSI)) stored in the subscriber identity module 1496 to identify and authenticate electronic devices 1401 in the communication network (e.g., a first network 1498 or a second network 1499).

[0200] Antenna module 1497 can transmit signals or power to or from the outside of electronic device 1401 (e.g., external electronic device). Antenna module 1497 may include one or more antennas, and at least one antenna suitable for a communication scheme used in a communication network such as first network 1498 or second network 1499 can be selected by communication module 1490 (e.g., wireless communication module 1492), for example. Signals or power can then be transmitted or received between communication module 1490 and external electronic device via the selected at least one antenna.

[0201] Commands or data can be sent or received between electronic device 1401 and external electronic device 1404 via server 1408 coupled to the second network 1499. Each of electronic devices 1402 and 1404 can be a device of the same or different type as electronic device 1401. All or some of the operations to be performed at electronic device 1401 can be performed at one or more of the external electronic devices 1402, 1404, or 1408. For example, if electronic device 1401 is required to automatically perform a function or service, or in response to a request from a user or another device, electronic device 1401 may request one or more external electronic devices to perform at least a portion of that function or service, instead of performing the function or service itself, or electronic device 1401 may request one or more external electronic devices to perform at least a portion of that function or service in addition to performing the function or service. The one or more external electronic devices receiving the request may perform at least a portion of the requested function or service, or additional functions or services related to the request, and transmit the result of the execution to electronic device 1401. Electronic device 1401 can provide the result as at least part of a response to a request, with or without further processing of the result. For this purpose, cloud computing, distributed computing, or client-server computing technologies can be used, for example.

[0202] Figure 15 This is a block diagram of a system according to an embodiment, including UEs and network nodes communicating with each other.

[0203] Figure 15 A system is illustrated comprising a UE 1505 and a gNB 1510 communicating with each other. The UE may include a radio 1515 and processing circuitry (or components for processing) 1520, which can perform various methods disclosed herein, for example, Figure 6 The method shown in -13. For example, the processing circuit 1520 can receive transmissions from the network node (gNB) 1510 via radio 1515, and the processing circuit 1520 can send signals to the gNB 1510 via radio 1515.

[0204] The embodiments of the subject matter and operations described in this specification can be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions can be encoded on artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals, generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium can be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof, or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. Furthermore, although the computer storage medium is not a propagating signal, it can be a source or destination of computer program instructions encoded in artificially generated propagating signals. Computer storage media can also be one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices), or be included in one or more separate physical components or media. Furthermore, the operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0205] While this specification may contain numerous details of specific implementation, these details should not be construed as limiting the scope of any claimed subject matter, but rather as descriptions of features specific to particular embodiments. Certain features described in the context of individual embodiments in this specification may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in certain combinations and even initially claimed in this way, in some cases one or more features from the claimed combination may be removed from the combination, and the claimed combination may be for sub-combinations or variations thereof.

[0206] Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or to perform all shown operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0207] Therefore, specific embodiments of the subject matter have been described herein. Other embodiments are within the scope of the following claims. In some cases, the actions set forth in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific order or sequence shown to achieve the desired result. In some embodiments, multitasking and parallel processing may be advantageous.

[0208] As those skilled in the art will recognize, the innovative concepts described herein can be modified and varied across a wide range of applications. Therefore, the scope of the claimed subject matter should not be limited to any specific exemplary teachings discussed above, but is defined by the appended claims.

Claims

1. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Receive from network nodes an indication of the synchronization signal block (SSB) associated with the On-Demand System Information Block 1 (OD-SIB1) cell, which is provided in the Master Information Block (MIB) or as a reserved value in the search space configuration; Based on the wake-up signal (WUS) configuration from the anchor cell, determine whether the SSB corresponds to the OD-SIB1 cell; Based on the determination, a request for OD-SIB1 transmission is sent to the network node; as well as Receive OD-SIB1 from OD-SIB1 cell.

2. The method according to claim 1, wherein, MIB includes K configured to indicate OD-SIB1 cells. SSB Bit field.

3. The method according to claim 2, wherein, K SSB >23 indicates the OD-SIB1 cell in frequency range 1 (FR1).

4. The method according to claim 2, wherein, K SSB >11 indicates the OD-SIB1 cell in frequency range 2 (FR2).

5. The method according to claim 1, wherein, The WUS configuration received from the anchor cell includes the association between one or more uplink preamble resources and the corresponding OD-SIB1 cell.

6. The method according to claim 5, wherein, The WUS configuration includes a search space for receiving a random access response (RAR) from the OD-SIB1 cell, and if no search space is provided, the UE will use search space zero for the OD-SIB1 cell.

7. The method according to claim 1, wherein, Requests for OD-SIB1 transmissions are executed via the Physical Random Access Channel (PRACH) configured in the WUS configuration.

8. The method according to claim 1, wherein, Receiving OD-SIB1 also includes: monitoring downlink control information (DCI) messages scrambled with the System Information Radio Network Temporary Identifier (SI-RNTI) associated with the OD-SIB1 cell.

9. The method according to claim 1, wherein, OD-SIB1 is received within a pre-configured time offset from the UE's requested transmission.

10. A user equipment (UE), comprising: processor; as well as Memory stores instructions, which cause the UE to execute when the instructions are executed by the processor. Receive from network nodes an indication of the synchronization signal block (SSB) associated with the On-Demand System Information Block 1 (OD-SIB1) cell, which is provided in the Master Information Block (MIB) or as a reserved value in the search space configuration; Based on the wake-up signal (WUS) configuration from the anchor cell, determine whether the SSB corresponds to the OD-SIB1 cell; Based on the determination, a request for OD-SIB1 transmission is sent to the network node; and Receive OD-SIB1 from OD-SIB1 cell.

11. The UE according to claim 10, wherein, MIB includes K configured to indicate OD-SIB1 cells. SSB Bit field.

12. The UE according to claim 11, wherein, K SSB >23 indicates the OD-SIB1 cell in frequency range 1 (FR1).

13. The UE according to claim 11, wherein, K SSB >11 indicates the OD-SIB1 cell in frequency range 2 (FR2).

14. The UE according to claim 10, wherein, The WUS configuration received from the anchor cell includes the association between one or more uplink preamble resources and the corresponding OD-SIB1 cell.

15. The UE according to claim 14, wherein, The WUS configuration includes a search space for receiving a random access response (RAR) from the OD-SIB1 cell, and if no search space is provided, the UE will use search space zero for the OD-SIB1 cell.

16. The UE according to claim 10, wherein, Requests for OD-SIB1 transmissions are executed via the Physical Random Access Channel (PRACH) configured in the WUS configuration.

17. The UE according to claim 10, wherein, Receiving OD-SIB1 also includes: monitoring downlink control information (DCI) messages scrambled with the System Information Radio Network Temporary Identifier (SI-RNTI) associated with the OD-SIB1 cell.

18. The UE according to claim 10, wherein, OD-SIB1 is received within a pre-configured time offset from the UE's requested transmission.

19. A method performed by a user equipment (UE) in a wireless communication system, the method comprising: Send a wake-up signal (WUS) to the network node to initiate an On-Demand System Information Block 1 (OD-SIB1) request; Indications for OD-SIB1 transmission opportunities corresponding to WUS received and transmitted from network nodes; and Decode OD-SIB1 based on the received instructions.

20. The method according to claim 19, wherein, OD-SIB1 is received in the search space indicated in the Master Information Block (MIB) or WUS configuration.

Images