Fast On-Demand System Information Block 1 Acquisition

Abstract

An apparatus configured to process, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising a RACH preamble for requesting system information block (SIB) information from a cell, determine that on-demand system information block 1 (SIB1) information is desired, generate, for transmission to the cell, the RACH preamble to request the on-demand SIB1 information, start a configured window for monitoring SIB1 information and monitor, during the configured window, information from the cell for the on-demand SIB1 information.

Description

Fast On-Demand System Information Block 1 AcquisitionTechnical Field

[0001] This application relates generally to wireless communication systems, including wireless communication systems using transmissions of system information (SI) .Background

[0002] Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G) , 3GPP New Radio (NR) (e.g., 5G) , and Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard for Wireless Local Area Networks (WLAN) (commonly known to industry groups as ) .

[0003] A NR network may support devices that use network energy savings ( "NES" ) features. These types of features provide cost and / or complexity reduction benefits. However, the NES systems may still need to provide positioning and / or location services that may be impacted because of the network energy saving capabilities of the devices. For example, there are multiple mechanisms to reduce power consumption. Such mechanisms can enhance the user experience by not exhausting a battery of a UE at an inappropriate rate.

[0004] There have been efforts in the relevant standards bodies to support on-demand System Information Block 1 (SIB1) for User Equipment (UE) in idle / inactive mode or power-saving mode. These efforts typically involve a triggering method by an uplink wake-up signal (WUS) using an  existing signal / channel. The WUS configuration provisioning is provided to the UE and there may be information exchanged between network nodes (e.g., gNBs) for the configuration of the WUS. As part of NES techniques, the UE may request or demand SIB1 information.

[0005] Improved methods and techniques for on-demand acquisition of the SIB1 information for UEs in idle or inactive mode are desirable. In particular, methods and techniques for more quickly acquiring the on-demand SIB1 information without using too many resources or power might be beneficial.Summary

[0006] Some example embodiments are related to an apparatus having processing circuitry configured to process, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising a RACH preamble for requesting system information block (SIB) information from a cell, determine that on-demand system information block 1 (SIB1) information is desired, generate, for transmission to the cell, the RACH preamble to request the on-demand SIB1 information, start a configured window for monitoring SIB1 information and monitor, during the configured window, information from the cell for the on-demand SIB1 information.

[0007] Other example embodiments are related to an apparatus having processing circuitry configured to process, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS  configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell, generate, for transmission to the cell, the RACH preamble to request on-demand system information block 1 (SIB1) information for entering a radio resource control (RRC) connected state, process, based on signals received from the cell, a random access response (RAR) in response to the RACH preamble and monitor, based on information in the RAR, information from the cell for the on-demand SIB1 information.

[0008] Still further example embodiments are related to an apparatus having processing circuitry configured to process, based on signaling received from a user equipment (UE) , a request for System Information Block 1 (SIB1) information and generate, for transmission to the UE, configuration information in response to the request for SIB1 information, the configuration information including uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell.

[0009] Additional example embodiments are related to an apparatus having processing circuitry configured to process, based on signaling received from a user equipment (UE) , a request for on-demand System Information Block 1 (SIB1) information for entering a radio resource control (RRC) connected state, generate, for transmission to the UE, configuration information in response to the request for SIB1 information, the configuration information including uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting  system information block (SIB) information from a cell and in response to receiving the RACH preamble from the UE, generate, for transmission to the UE, a random access response (RAR) comprising an indication on whether the cell agrees to transmit the on-demand SIB1 information and to allow the UE to camp in the cell.Brief Description of the Drawings

[0010] Fig. 1 illustrates an example network arrangement according to various example embodiments.

[0011] Fig. 2 illustrates an example user equipment (UE) according to various example embodiments.

[0012] Fig. 3 illustrates an example base station according to various example embodiments.

[0013] FIG. 4 illustrates an example wireless communication system according to various example embodiments.

[0014] FIG. 5 illustrates an example wireless communication system according to various example embodiments.

[0015] FIG. 6 illustrates an example flow diagram for an example procedure for a "Msg1" on-demand SI request RACH procedure and a corresponding configuration for a Msg1 request, according to various example embodiments.

[0016] FIG. 7 illustrates an example flow diagram for an example procedure for a "Msg3" on-demand SI request RACH procedure, according to various example embodiments.

[0017] FIG. 8 illustrates an example flow diagram corresponding to communications between a UE, an anchor cell, and an NES cell, according to various example embodiments discussed herein.

[0018] FIG. 9 illustrates an example flow diagram corresponding to communications between a UE, an anchor cell, and an NES cell, according to various example embodiments discussed herein.

[0019] FIG. 10 illustrates an example diagram showing a timeline for signaling between a UE, an anchor cell, and an NES cell corresponding to the use of a "Msg1" on-demand SI request RACH procedure between the UE and the NES cell that includes a SIB1 request for the NES cell, according to various example embodiments discussed herein.

[0020] FIG. 11 illustrates an example flow diagram corresponding to communications between a UE and an NES cell, according to various example embodiments discussed herein.

[0021] FIG. 12 illustrates an example diagram showing a timeline for signaling between a UE and an NES cell corresponding to the use of a "Msg1" on-demand SI request RACH procedure between the UE and the NES cell that includes a SIB1 request for the NES cell, according to various example embodiments discussed herein.

[0022] FIG. 13 is an example flow diagram illustrating an example procedure for acquiring on-demand SIB1 information according to various example embodiments.

[0023] FIG. 14A is an example flow diagram that illustrates an example procedure for fast acquisition of on-demand SIB1 information for SIB1 update according to various example embodiments.

[0024] FIG. 14B is an example flow diagram that illustrates another example procedure for fast acquisition of on-demand SIB1 information for entering a RRC CONNECTED state according to various example embodiments.

[0025] FIG. 15A is an example flow diagram that illustrates an example procedure for a UE initiating an on-demand SIB1 acquisition and / or update in a first scenario based on certain trigger conditions according to various example embodiments.

[0026] FIG. 15B is an example flow diagram that illustrates an example procedure for a UE initiating an on-demand SIB1 acquisition and / or update in a second scenario based on certain trigger conditions according to various example embodiments.

[0027] FIGS. 16A and 16B are example flow diagrams illustrating an example procedure for an on-demand SIB1 request for updating SIB1 according to various example embodiments.

[0028] FIG. 17 is an example flow diagram that illustrates another example procedure for fast acquisition of on-demand SIB1 information for entering a RRC CONNECTED state according to various example embodiments.

[0029] FIG. 18 is an example format for an example Medium Access Control (MAC) Random Access Response (RAR) according to various example embodiments.Detailed Description

[0030] The example embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The example embodiments relate to systems, devices, methods and techniques for fast on-demand SIB1 acquisition by UEs. Each of these example embodiments will be described in greater detail below.

[0031] The example embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example embodiments may be utilized with any electronic component that may establish a connection to an accessory device and is configured with the hardware, software, and / or firmware to exchange information and data with accessory devices. Therefore, the UE as described herein is used to represent any electronic component.

[0032] The example embodiments are also described with reference to a 5G New Radio (NR) network. However, the example embodiments may also be implemented in other types of networks, including but not limited to LTE networks, future evolutions of the cellular protocol (e.g., 5G-advanced networks, 6G networks, etc. ) , or any other type of network.

[0033] Fig. 1 shows an example network arrangement 100 according to various example embodiments. The example network arrangement 100 includes a UE 110. The UE 110 may  be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, embedded devices, wearables, Internet of Things (IoT) devices, etc. An actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of one UE 110 is merely provided for illustrative purposes.

[0034] The UE 110 may be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 may wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 may also communicate with other types of networks (e.g., 5G cloud RAN, a next generation RAN (NG-RAN) , a legacy cellular network, etc. ) and the UE 110 may also communicate with networks over a wired connection. With regard to the example embodiments, the UE 110 may establish a connection with the 5G NR RAN 120. Therefore, the UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0035] The 5G NR RAN 120 may be portions of a cellular network that may be deployed by a network carrier (e.g., Verizon, AT&T, T-Mobile, etc. ) . The RAN 120 may include cells or base stations that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set. In this example, the 5G NR RAN 120 includes the gNB 120A and the gNB 120B. However, reference to a gNB is merely provided for illustrative purposes, any appropriate base station or cell may be deployed (e.g., Node Bs, eNodeBs, HeNBs, eNBs, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc. ) .

[0036] Any association procedure may be performed for the UE 110 to connect to the 5G NR RAN 120. For example, as discussed above, the 5G NR RAN 120 may be associated with a particular network carrier where the UE 110 and / or the user thereof has a contract and credential information (e.g., stored on a SIM card) . Upon detecting the presence of the 5G NR RAN 120, the UE 110 may transmit the corresponding credential information to associate with the 5G NR RAN 120. More specifically, the UE 110 may associate with a specific cell (e.g., gNB 120A) .

[0037] The network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 manages the traffic that flows between the cellular network and the Internet 140. The IMS 150 may be generally described as an architecture for delivering multimedia services to the UE 110 using the IP protocol. The IMS 150 may communicate with the cellular core network 130 and the Internet 140 to provide the multimedia services to the UE 110. The network services backbone 160 is in communication either directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 may be generally described as a set of components (e.g., servers, network storage arrangements, etc. ) that implement a suite of services that may be used to extend the functionalities of the UE 110 in communication with the various networks.

[0038] Fig. 2 shows an example UE 110 according to various example embodiments. The UE 110 will be described with regard to the network arrangement 100 of Fig. 1. The UE 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device  215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a battery that provides a limited power supply, a data acquisition device, ports to electrically connect the UE 110 to other electronic devices, sensors to detect conditions of the UE 110, etc.

[0039] The processor 205 may be configured to execute a plurality of engines for the UE 110. For example, the engines may include an On-demand SIB 1 Acquisition Engine 240 and may also include an Additional Condition Engine 235 for performing operations related to on-demand SIB1 acquisition. The engines 235 and 240 for example may perform the operations necessary to decide when to request SIB1 information and from where. For example, the On-demand SIB1 Acquisition Engine 240 may include logic and / or circuitry that selects and transmits a random access preamble to a base station to request specific SIB information. The On-demand SIB1 Acquisition Engine 240 may include logic and / or circuitry that establishes a monitoring window and offset for an on-demand SIB1 procedure, and that monitors the cell defined Synchronization Signal Block (SSB) for the SIB1. The On-demand SIB 1 Acquisition Engine 240 may also include logic and / or circuitry that requests RRC setup. The Additional Condition Engine 240 may include logic and / or circuitry that monitors conditions that may trigger the UE to initiate an on-demand SIB1 procedure. Each of these example operations will be described in more detail below.

[0040] The above referenced engines 235 and 240 being applications (e.g., programs) executed by the processor 205 is only an example. The functionality associated with the  engines may also be represented as a separate incorporated component of the UE 110 or may be a modular component coupled to the UE 110, e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engines may also be embodied as one application or separate applications. In addition, in some UEs, the functionality described for the processor 205 is split among two or more processors such as a baseband processor and an applications processor. The example embodiments may be implemented in any of these or other configurations of a UE.

[0041] The memory arrangement 210 may be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 may be a hardware component configured to show data to a user while the I / O device 220 may be a hardware component that enables the user to enter inputs. The display device 215 and the I / O device 220 may be separate components or integrated together such as a touchscreen.

[0042] The transceiver 225 may be a hardware component configured to establish a connection with the 5G NR-RAN 120, an LTE-RAN (not pictured) , a legacy RAN (not pictured) , a WLAN (not pictured) , etc. Accordingly, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 225 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive from and / or transmit signals to  the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any one of the methods described herein.

[0043] Fig. 3 shows an example base station 300 according to various example embodiments. The base station 300 may represent the gNB 120A, the gNB 120B or any other access node through which the UE 110 may establish a connection and manage network operations.

[0044] The base station 300 may include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. The other components 325 may include, for example, an audio input device, an audio output device, a battery, a data acquisition device, ports to electrically connect the base station 300 to other electronic devices and / or power sources, etc.

[0045] The processor 305 may be configured to execute a plurality of engines for the UE 110. For example, the engines may include an On-Demand SIB Configuration Engine 335 for performing operations related to on-demand SIB1 acquisition. For example, the On-Demand SIB Configuration Engine 335 may include logic and / or circuitry that creates and transmits new configurations as part of an uplink wake-up signal (UL WUS) configuration. For example, the UL WUS configuration may include an offset, monitoring window length, and OD-SIB1 retransmission threshold related to on-demand SIB1 acquisition. In addition, the On-Demand SIB Configuration Engine 335 may include logic and / or circuitry that sends a "stop" indication to a UE if the base station does not want to wake up (e.g., because it is a power  savings mode or has a low battery) to send SIB1 information. Each of these example operations will be described in further detail below. The Additional Condition Engine 330 may include logic and / or circuitry that monitors conditions and sends information regarding the conditions to a UE that may trigger the UE to initiate an on-demand SIB1 procedure. Each of these example operations will be described in more detail below. Though engines 330 and 335 are shown as separate engines, in some embodiments, engines 330 and 335 may be combined into a single engine.

[0046] The memory arrangement 310 may be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 may be a hardware component or ports that enable a user to interact with the base station 300.

[0047] The transceiver 320 may be a hardware component configured to exchange data with the UE 110 and any other UE in the network arrangement 100. The transceiver 320 may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies) . The transceiver 320 includes circuitry configured to transmit and / or receive signals (e.g., control signals, data signals) . Such signals may be encoded with information implementing any one of the methods described herein. The processor 305 may be operably coupled to the transceiver 320 and configured to receive from and / or transmit signals to the transceiver 320. The processor 305 may be configured to encode and / or decode signals (e.g., signaling from a UE) for implementing any one of the methods described herein.

[0048] With respect to various wireless communication systems, mechanisms for system information (SI) management  in the context of network energy saving (NES) may be considered. These may include a mechanism for a wake-up signal (WUS) sent from a UE to a base station. In such cases, the UE may send an uplink WUS to request that a cell transition from a no or reduced transmission and / or reception activity level to an active transmission and / or reception activity level (e.g., corresponding to a channel and / or a signal) . The technique can be applied to UEs in various radio resource control (RRC) states.

[0049] Another contemplated mechanism for SI management in the context of NES includes on-demand system information block (SIB) 1 (SIB1) transmission. Note that, in a broader context, various useable on-demand mechanisms may include on-demand synchronization signal block (SSB) transmission and / or on-demand SIB1 transmission.

[0050] Within this context, some embodiments may contemplate the use of on-demand SIB1 and / or SSB transmission for idle UEs. Additionally or alternatively, some embodiments may contemplate the use of on-demand SSBs (and possibly other downlink (DL) signals) for secondary cell (s) (SCell s) ) for connected UEs.

[0051] Within such contexts, various triggering methods for the on-demand signaling are possible. In some cases, the triggering method may be based on an UE uplink WUS (e.g., in a non-carrier aggregation (CA) case) . In such cases, such a WUS may be based on an existing signal (e.g., as a starting point, if possible) , or the WUS may be a new signal.

[0052] In some cases, the triggering method may be based on a cell on / off indication that arrives at the applicable  base station via a backhaul of the wireless communication system.

[0053] In some cases, the triggering method may be based on SCell activation and / or deactivation signaling.

[0054] FIG. 4 illustrates a wireless communication system 400 according to various embodiments. The wireless communication system 400 includes the anchor cell 402, the UE 404, and the (non-anchor) NES cell 406. The NES cell 406 is not configured to regularly (e.g., periodically per a configuration) broadcast a SIB1 of the NES cell 406. Prior to the RACH procedure 408, the UE 404 is in an RRC idle or RRC inactive mode with respect to the NES cell 406.

[0055] As illustrated in FIG. 4, the UE 404 is enabled to perform a RACH procedure 408 with the non-anchor NES cell 406 (and thereby connect to the NES cell 406) by receiving 410 and subsequently using SI of a SIB1 of the NES cell 406 that is received from the anchor cell 402. Note that in some such cases, paging is transmitted / handled by the anchor cell 402.

[0056] Assuming that one anchor cell provides piggybacked SIB1 of the NES cell without SIB1, in a first situation, the complete SIB1 may be piggybacked for the UE′sinitial access in the NES cell without SIB1. The UE can use an on-demand SIB1 (ODS) procedure in case of SIB1 update as discussed herein. Assuming that one anchor cell provides piggybacked SIB1 of the NES cell without SIB1, in a second situation, at least part of the SIB1 (at least RACH config) is piggybacked. The UE may use the SIB1 ODS procedure described herein for both initial access and SIB1 update -Existing Msg 1 / Msg 3 ODS procedures can be extended for SIB1 acquisition with RACH configuration from the piggybacked  SIB1 from the anchor cell. The WUS configuration can be regarded as the RACH config since there is no new signal.

[0057] In a third situation, where no anchor cell is used, the main difference is that the UE does not have the RACH configuration to initiate the on-demand SIB1 procedure. Thus, the RACH configuration needs to be integrated into the MIB of the NES cell without SIB1.

[0058] FIG. 5 illustrates a wireless communication system 500 according to various embodiments. The wireless communication system 500 includes the UE 502 and the NES cell 504. The NES cell 504 is not configured to regularly (e.g., periodically per configuration information) broadcast an SIB1 of the NES cell 504. Prior to the RACH procedure 506, the UE 502 is in an RRC idle or RRC inactive mode with respect to the NES cell 504.

[0059] FIG. 5 illustrates the use of a triggering method by uplink WUS using an existing signal / channel, whereby the WUS as transmitted by the UE 502 triggers the NES cell 504 to transmit an SIB1 of the NES cell 504. Upon receiving this SIB1, the UE 202 is enabled to perform a RACH procedure 506 with the NES cell 504 (and thereby connect to the NES cell 504) .

[0060] In such cases, the WUS configuration / provisioning to the UE may (e.g., previously) occur via an anchor cell (not illustrated) , thereby enabling the use of the on-demand SIB1 transmission from the non-anchor NES cell. In other words, embodiments corresponding to FIG. 5 relate to cases without anchor cell provisioning of the SIB1 of the NES cell 504 to the UE 502 (e.g., cases where the UE 502 does not  rely on an anchor cell to provide SI for a usable RACH configuration for accessing the NES cell 504) .

[0061] In various wireless communication systems, it may be that a master information block (MIB) and / or SIB1 are regularly (e.g., periodically, according to corresponding configuration (s) ) broadcasted. In such circumstances, it may be that the MIB is transmitted via a broadcast control channel (BCCH) at, for example, an 80 millisecond (ms) periodicity, while the SIB1 is transmitted via a downlink shared channel (DL-SCH) at, for example, a 160 ms periodicity.

[0062] It may be in such cases that other SIBs (e.g., other than SIB1) can be acquired on-demand via a message 1 ( "Msg1" ) on-demand SI request RACH procedure or a message 3 ( "Msg3" ) on-demand SI request RACH procedure.

[0063] FIG. 6 illustrates a flow diagram 600 for a procedure for a "Msg1" on-demand SI request RACH procedure and a corresponding configuration 602 for a "Msg1" request, according to some embodiments.

[0064] The flow diagram 300 illustrates that the "Msg1" on-demand SI request procedure occurs between a UE 304 and a base station 306. The UE 304 selects 308 a physical random access channel (PRACH) preamble and / or resource (e.g., RACH occasion (RO) ) that is specific to the SIB (s) that it wants to request the base station 306 to transmit. As shown, in some cases, such a preamble may be a dedicated preamble 310 that corresponds to the desired SIB (s) . Additionally or alternatively, in some cases, the RO chosen for the preamble may correspond to particular SIB (s) .

[0065] The UE 304 then sends 312 the selected random access preamble to the base station 306. The sending 312 of this random access preamble may represent the "Msg1" of the "Msg1" on-demand SI request RACH procedure.

[0066] The random access preamble may be arranged according to the configuration 302 (which may be a configuration in terms of content and / or RO that is dedicated to the SIB (s) ) being requested by the random access preamble) .

[0067] In response to the random access preamble, the base station 306 sends 314 a random access response to the UE. As shown, the random access response may include a random access preamble identifier (RAPID) 316 identifying the random access preamble, which confirms to the UE 304 that the random access preamble was received at the base station and that thus that the base station will transmit 318 the requested SIB (s) .

[0068] The base station 306 then proceeds to transmit 318 the requested SIB (s) as requested by the UE (such that the UE can accordingly receive them) . As illustrated, this represents the culmination of an on-demand SI reception 320.

[0069] FIG. 4 illustrates a flow diagram 400 for a procedure for a Msg3 on-demand SI request RACH procedure, according to some embodiments.

[0070] The flow diagram 400 illustrates that the "Msg3" on-demand SI request RACH procedure occurs between a UE 402 and a base station 404. The UE 402 sends 406 a random access preamble to the base station 404. In response, the base  station 404 sends 408 a random access response having an uplink (UL) grant for the UE 402.

[0071] Using the UL grant, the UE 402 then sends 410 an SI request to the base station 404. The sending 410 of this SI request may represent the "Msg3" of the "Msg3" on-demand SI request RACH procedure. The SI request may include a bitmap that indicates one or more SIB (s) which the UE 402 would like the base station 404 to transmit. As illustrated, the SI request may be in the form of an RRC message 412 that may not include a UE identifier (ID) .

[0072] The base station 404 in reply sends 414 an SI response to the UE 402. As illustrated, the SI response may include a contention resolution (CR) medium access control control element (MAC CE) 416 that indicates that the request for SI was received in the "Msg3, " which confirms to the UE 402 that the "Msg3" was received at the base station and that the base station will transmit 418 the requested SIB(s) .

[0073] The base station 404 then proceeds to transmit 418 the requested SIB (s) as requested by the UE (such that the UE can accordingly receive them) . As illustrated, this represents the culmination of an on-demand SI reception 420.

[0074] Embodiments disclosed herein discuss procedures and signaling of on-demand SIB1 acquisition for multiple scenarios.

[0075] In a first scenario, an on-demand SIB1 acquisition procedure between a UE and an NES cell is supplemented by communications between a UE and an anchor cell. Under this first scenario, the UE acquires information for performing a random access procedure with the NES cell (that is, e.g.,  that is not regularly broadcasting an SIB1) from the anchor cell.

[0076] In some such cases under the first scenario, the anchor cell provides the UE with essential SIB (ESIB) information of the NES cell in a SIB that is broadcasted by the anchor cell. The UE retunes to the NES cell using the ESIB information of the NES cell as received from the anchor cell, and proceeds to then use an on-demand SIB procedure with the NES cell to request the NES cell to transmit its SIB1 (note that a request to transmit a SIB1 is sometimes referred to herein as a "SIB1 request" ) . The new on-demand SIB procedure is based on (e.g., uses / incorporates) a RACH procedure and leverages RRC signaling changes that make it possible for a request for an SIB1 transmission is supported. Such on-demand SIB procedures may be of a "Msg1" on-demand SI request RACH procedure or of a "Msg3" on-demand SI request RACH procedure, as is discussed herein. As will be discussed, in some embodiments, a previously reserved kSSB value (e.g., kSSB = 30 for FRi or kSSB = 14 for FR2) may be used by the NES cell to indicate that that the NES cell does not regularly transmit its SIB1 but is configured to transmit its SIB1 in response to a SIB1 request.

[0077] In some such embodiments, if the network agrees to transmit the SIB1 per the UE′srequest, it uses a paging short message to notify the UE. Upon being so notified, the UE starts to monitor the SIB1 in a next BCCH modification period.

[0078] In some cases under the first scenario involving communications between the anchor cell and the UE, the anchor cell provides the UE with a full SIB1 of the NES cell. The UE then retunes to the NES cell using the SIB1 of  the NES cell as received from the anchor cell. In some cases, the UE then proceeds to monitor whether the SIB1 as received from the anchor cell is out of date, and to request a new (up-to-date) SIB1 from the NES cell if this is the case.

[0079] In a second scenario, an on-demand SIB1 acquisition procedure between a UE and an NES cell may occur without a preliminary transfer of ESIB information of the NES cell / aSIB1 of the NES cell to the UE from an anchor cell. In such cases, a procedure as described above in relation to the first scenario may be modified. Corresponding to the situation where the SIB1 is not regularly broadcast by the NES cell, an 8-bit field PDCCH-ConfigSIB1 in an MIB of the NES cell may reused to indicate a concise RACH (including a CORESET and a SS for a RACH response (RAR) ) and a paging configuration for an SIB1 request. It may be that this mechanism supports "Msg1" on-demand SI request RACH procedures to make a SIB1 request, as described herein.

[0080] The network configures control resource set (CORESET) zero (CORESET #0) and search space (SS) zero (SS #0) information (e.g., using 8 bits) in the PDCCH-ConfigSIB1 field 602 in an MIB. The UE monitors a downlink control information (DCI) format 1_0 with cyclic redundancy code (CRC) scrambled with a SI radio network temporary identifier (SI-RNTI) in the SS #0. A DCI may schedule the SIB1 transmission. Under this configuration, there may be limited flexibility for time and frequency domain locations for CORESET#0 and SS#0. Further, the search space associated with a given SSB #i may be derivable from this configuration.

[0081] Embodiments for Scenario 1--On-demand SIB1 Acquisition Supplemented by UE-Anchor Cell Communication

[0082] FIG. 8 illustrates a flow diagram 800 corresponding to communications between a UE 802, an anchor cell 804, and an NES cell 806, according to embodiments discussed herein.

[0083] Preliminarily, it is noted that the anchor cell 804 and the NES cell 806 may each be configured to transmit SSBs. The anchor cell 804 and the NES cell 806 can be synchronized or not synchronized in this regard.

[0084] The anchor cell 804 may transmit one of its SIBs 808 (e.g., SIB1, or another SIB) . The UE 802 may correspondingly receive this SIB. This SIB may include "piggybacked" ESIB information of the (non-anchor) NES cell 806. The "piggybacked" ESIB information for the NES cell 806 as found in the SIB of the anchor cell 804 may include a RACH configuration for the NES cell 806. This RACH configuration may enable the UE 802 to communicate with the NES cell 806 in order to request its full SIB1, as will be described.

[0085] The UE 802 may use the information for the anchor cell 804 (e.g., as found in a SIB1 that is broadcast by the anchor cell 804) to perform a RACH procedure 810 with the anchor cell 804 such that the UE 802 may initially register / camp 812 to the anchor cell 804 (at this stage, paging may be monitored in the anchor cell 804, as illustrated) .

[0086] The UE 802 then undergoes a trigger 814 for communications with the NES cell 806. As illustrated,  examples of such a trigger 814 may include, for example, the arrival of mobile originated (MO) uplink (UL) data for the NES cell 806 at the UE 802 (e.g., from an application layer of the UE 802) or a reception of paging (e.g., from the anchor cell 804) corresponding to DL data at the NES cell 806 that is for the UE 802. In response to the trigger 814, the UE retunes 816 to NES cell 806 (including carrier selection corresponding to the NES cell 806) .

[0087] The UE 802 then performs a RACH procedure 818 with the NES cell 806. The UE 802 performs this RACH procedure based on the ESIB information of the NES cell 806 previously received from the anchor cell 804. As illustrated, the RACH procedure 818 may include a request for a full SIB1 from the NES cell 806. The RACH procedure 818 may be a "Msg1" type on-demand SI request RACH procedure or a "Msg3" type on-demand SI request RACH procedure, as is discussed herein.

[0088] In response to the RACH procedure 818 (e.g., in response to the SIB1 request in the RACH procedure 818) , the NES cell 806 transmits its SIB1 820 (and, in some cases, other SIBs) for reception by the UE 802, which the UE 802 accordingly receives.

[0089] Then, with the acquired full SIB1, the UE accesses 822 the NES cell 806 (e.g., the UE 802 performs unified access control (UAC) and initial access procedures with the NES cell 806) . The UE 802 then enters an RRC connected state 824 with the NES cell 806. Accordingly, data transmission 826 (e.g., including (but not limited to) transmissions corresponding to the nature of the trigger 814) may then occur between the UE 802 and the NES cell 806.

[0090] Embodiments for contents of ESIB information for an NES cell that may be "piggybacked" in a SIB of an anchor cell are now discussed.

[0091] In some embodiments, ESIB information of an NES cell includes a RACH configuration for performing a RACH procedure with the NES cell and some useful IEs. In such cases, it may be that the ESIB information may not be a full SIB1 of the NES cell. The use of part of the information otherwise found in the SIB1 within the ESIB information may reduce the overhead cost of the SIB of the anchor cell that includes the "piggybacked" ESIB information (and note that this consideration is particularly relevant when the SIB of the anchor cell carries / piggybacks ESIB information for multiple NES cells, as may be the case) .

[0092] ESIB information for the NES cell may include a RACH configuration to use for a RACH procedure with the NES cell. This RACH configuration may be a 4-step RACH configuration for a 4-step RACH procedure or a 2-step RACH configuration for a 2-step RACH procedure, as the case may be. Related IEs include

[0093] ● rach-ConfigCommon SetupRelease {RACH-ConfigCommon}

[0094] ● msgA-ConfigCommon-r16 SetupRelease {MsgA-ConfigCommon-r16 }

[0095] ESIB information for the NES cell may further include DL and / or UL initial bandwidth part (BWP) information. For example, an UplinkConfigCommonSIB IE defining the location of a UL BWP may be included. This information may be useful in cases where the RACH configuration defines the frequency location of the  associated RACH in a relative manner to an UL BWP boundary (e.g., using a msg1-FrequencyStart IE) .

[0096] As another example, a DownlinkConfigCommonSIB IE defining the location of a DL BWP may be included. This information may be used by the UE to understand where to perform RAR reception for the RACH procedure within an initial DL BWP. The DownlinkConfigCommonSIB IE may include bcch-Config and pcch-Config values. In some embodiments, other values for the DownlinkConfigCommonSIB IE (e.g., pei-Config-r17 and initialDownlinkBWP-RedCap-r17 values) may be omitted.

[0097] ESIB information for the NES cell may further include a SI-SchedulingInfo IE that includes a SI-RequestConfig IE that provides a configuration for requesting a SIB from the NES cell. It may be that in some cases, to support "Msg1" and / or "Msg3" on-demand SI request RACH procedures that request a SIB1, the wireless communication system is configured to allow a SIB-TypeInfo that includes a "type" field which can take the value "sibType1. " For example, a definition for such a type field may be represented as:

[0098] Type-r19 ENUMERATED {sibType1, spare15, spare14, spare13, spare12, spare11, spare10, spare9, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1, ... } .

[0099] The availability of the "sibType1" value for the "type" field of the SIB-TypeInfo IE enables a request according to the SI-RequestConfig IE in the SI-SchedulingInfo IE to indicate that the on-demand SI request RACH procedure is requesting a SIB1 from the NES cell.

[0100] In some embodiments, the ESIB information for the NES cell is included in a SIB of the anchor cell that is  designated for purposes of transmitting the ESIB information of NES cells. This SIB of the anchor cell can itself be transmitted on-demand.

[0101] Within the SIB of the anchor cell that carries ESIB information for one or more NES cells, it may be that for each set of ESIB information for each NES cell, a frequency and / or a physical cell identity (PCI) of the corresponding NES cell are included, thereby enabling the UE to identify that received ESIB information is for a particular NES cell.

[0102] Inter-node signaling between an anchor cell and an NES cell corresponding to the use of "piggybacked" ESIB information for the NES cell is now discussed. To support operations where the NES cell does not regularly transmit its SIB1, inter-node signaling may be used to exchange the ESIB information of the NES cell between the anchor cell and the NES cell.

[0103] Various alternatives for triggering this transaction are contemplated. In a first alternative, the NES cell initiates the exchange. In such cases, the NES cell may proactively ask the anchor cell to piggyback its ESIB information. In a second alternative, the anchor cell initiates the exchange. In such cases, the anchor cell may first solicit the NES cell for its ESIB information.

[0104] Various alternative with respect to the node that most directly generates the ESIB information of the NES cell are contemplated. In one alternative, the NES cell generates the ESIB information based on its SIB1, and shares the ESIB information (e.g., as such) with the anchor cell. In a second alternative, the anchor cell generates the ESIB  information for the NES cell based on a SIB1 of the NES cell that the NES cells shares with anchor cell.

[0105] Various alternatives are contemplated with respect to inter-node signaling for the ESIB information. In cases where the inter-node signaling is between different control units (CUs) , ESIB information may be included as a new IE in a XnAP message corresponding to that case (such as a setup request and / or response message or an NG-RAN node configuration update request and / or acknowledge message) . In cases where the inter-node signaling is within / beneath a same single CU (e.g., between the CU and its distributed unit (DU) ) , it can be included as part of a new IE in an XnAP message corresponding to that case (such as a GNB-CU CONFIGURATION UPDATE message) .

[0106] FIG. 9 illustrates a flow diagram 900 corresponding to communications between a UE 902, an anchor cell 904, and an NES cell 906, according to embodiments discussed herein. As opposed to the use of ESIB information as discussed in FIG. 8, the flow diagram 900 of FIG. 9 corresponds to a case where the UE 902 receives a full SIB1 of the NES cell 906 from the anchor cell 904.

[0107] The anchor cell 904 may broadcast 908 one of its SIBs (e.g., SIB1, or another SIB) . The UE 902 may correspondingly receive this SIB.

[0108] This SIB may include a "piggybacked" (full) SIB1 of the non-anchor NES cell 906 to enable initial access in the NES cell 906 by the UE 902. The UE 902 may use information from the SIB1 of the NES cell 906 as found in this SIB of the anchor cell 904 to retune 910 to the NES  cell 906 (including carrier selection corresponding to the NES cell 906) .

[0109] Then, the UE accesses 912 the NES cell 906 (e.g., the UE 902 performs UAC and initial access procedures with the NES cell 906) using the information from the SIB1. Upon a successful access, the UE 902 is camped 914 on the NES cell 906.

[0110] In scenarios corresponding to FIG. 9, is may be that the UE triggers an on-demand SI request RACH procedure for a SIB1 in the event that it is informed of an update to the SIB1 of the NES cell 906 (e.g., with respect to the SIB1 of the NES cell 906 that was previously received from the anchor cell 904. For example, as shown in FIG. 9, after the UE 902 is camped 914 to the NES cell 906, the NES cell 906 transmits 916 an indication of an SIB1 change or updated to the UE 902. In response, the UE 902 performs a RACH procedure 918 with the NES cell 906. The UE 902 performs this RACH procedure based on the SIB1 of the NES cell 906 previously received from the anchor cell 904. As illustrated, the RACH procedure 918 may include a request for an (updated) SIB1 from the NES cell 906. The RACH procedure 918 may be a "Msg1" on-demand SI request RACH procedure or a "Msg3" on-demand SI request RACH procedure, as is discussed herein.

[0111] In response to the RACH procedure 918, the NES cell 906 transmits 920 the requested SIB1 (and potentially other SIB (s)) .

[0112] It is noted that in the alternative scenarios discussed in relation to FIG. 8, where ESIB information is used, the UE triggers an on-demand SI request RACH procedure  corresponding to both the case of initial access to the NES cell 806 and in the case that the NES cell 806 were to have / communicate a SIB1 update, similarly to that just described. Accordingly, embodiments corresponding to FIG. 9 that transmit a full SIB1 for the NES cell 906 from the anchor cell 904 to the UE 902 to enable the initial access of the UE 902 to the NES cell 906 may be considered to use relatively fewer signaling steps.

[0113] Other procedures and aspects (e.g., with respect to RACH configurations and / or IEs as may relate to enabling a UE to perform an on-demand SI request RACH procedure that requests an SIB1 from an NES cell and / or with respect to the nature of the SIB of the anchor cell) as used in relation to embodiments for FIG. 9 may have corresponding uses as those described elsewhere herein.

[0114] With respect to inter-node messaging aspects, in the FIG. 9 context it may be that the NES cell shares its SIB1 with anchor cell. Such inter-node messaging may be NES-cell-initiated or anchor-cell-initiated. The particular nature of this inter-node signaling (e.g., across inter-CU nodes cases versus intra-CU nodes) may follow the mechanisms described elsewhere herein.

[0115] Embodiments with respect to the use of a "Msg1" on-demand SI request RACH procedure in cases where on-demand SIB1 acquisition is supplemented by UE-anchor cell communication are now discussed.

[0116] As is discussed elsewhere herein, a "sibType1" value for a "type" field of a SIB-TypeInfo IE may be defined such that a request according to a SI-RequestConfig IE of an SI-SchedulingInfo IE can ultimately indicate that an on- demand SI request RACH procedure is requesting a SIB1 from an NES cell.

[0117] The network may provide, in the SI-RequestConfig IE, an SI-RequestResources IE that is associated with the "sibType1" value / the SIB1 of the NES cell.

[0118] Finally, note that some UE behaviors corresponding to one or more of these IEs also use one or more of an si-WindowLength IE and / or an si-Periodicity IE within the SI-RequestConfig IE.

[0119] FIG. 10 illustrates a diagram 1100 showing a timeline for signaling between a UE 1002, an anchor cell 1004, and an NES cell 1006 corresponding to the use of a "Msg1" on-demand SI request RACH procedure 1008 between the UE 1002 and the NES cell 1006 that includes a SIB1 request for the NES cell 1006, according to embodiments discussed herein.

[0120] Preliminarily, the UE 1002 synchronizes with the anchor cell 1004 based on one or more of the anchor cell SSBs 1010 that is detected at the UE. The anchor cell 1004 regularly broadcasts its anchor cell SIB1 1012 (along with a corresponding CORESET #0 1014) . Accordingly, the UE receives the anchor cell SIB1 1012. Based on the information in the anchor cell SIB1 1012, the UE is enabled to further receive a SIB N 1016 of the anchor cell that contains "piggybacked" ESIB information of the NES cell 1006.

[0121] Using the ESIB information of the NES cell 1006 received from the anchor cell 1004, the UE 1002 retunes 1018 to the NES cell 1006, and starts to monitor the NES cell 1006 for one or more NES cell SSBs 1020. The NES cell SSBs  1020 may use a value of kSSB = 30 in an FRi case (as illustrated) or a value of kSSB = 14 in an FR2 case (not illustrated) in order to indicate that the NES cell 1006 is an NES cell 1006 that does not regularly transmit its SIB1 but is configured to transmit its SIB1 in response to a SIB1 request. Upon detecting the relevant value for kSSB, the UE is made aware that it should use an on-demand SI request RACH procedure to request a SIB1 transmission from the NES cell 1006 (as without such a request, the NES cell 1006 may not ever transmit its SIB1) .

[0122] The diagram 1000 then illustrates the use of the "Msg1" on-demand SI request RACH procedure 1008 between the UE 1002 and the NES cell 1006. The UE 1002 transmits a preamble 1026 that includes the SIB1 request (e.g., where the SIB1 request is represented by the particular preamble 1026 used in this transmission and / or by the RO used for the transmission of the preamble 1026, as is discussed in additional detail elsewhere herein) . Upon receiving the preamble 1026, the NES cell 1006 understands that it is to transmit an NES cell SIB1 1022 and responds to the UE 1002 with a RAR 1028 that acts as an indication to the UE 1002 that the preamble 1026 was received.

[0123] The diagram 1000 corresponds to cases where an eventual NES cell SIB1 1022 is transmitted by the NES cell 1006 at a time that is determined relative to a defined BCCH modification period boundary 1024. This situation may correspond to embodiments where MIB / SIB1 contents are not changed at a cell until a new BCCH modification period (e.g., as defined by the BCCH modification period boundary 1024, as illustrated) .

[0124] In other cases, an eventual NES cell SIB1 may be transmitted by the NES cell at a time that is determined relative to a defined SI window for the NES cell SIB1 (a window of "sibType1" ) in a current / existing BCCH modification period.

[0125] Embodiments for Scenario 2--On-demand SIB1 Acquisition at UE from NES Cell Without Using Anchor Cell Communication

[0126] FIG. 11 illustrates a flow diagram 1100 corresponding to communications between a UE 1102 and an NES cell 1104, according to embodiments discussed herein.

[0127] For embodiments corresponding to FIG. 11, the UE 1102 may access the NES cell 1104 without the use of ESIB information and / or an NES cell SIB1 as provided from an anchor cell. In some embodiments, paging and paging short messages can be transmitted by the NES cell 1104.

[0128] The NES cell 1104 may broadcast a MIB 1106 (without broadcasting an SIB1) . It may be that a reserved value is set in kSSB (e.g., kSSB = 30 for FR1 or kSSB = 14 for FR2) to indicate that the NES cell 1104 does not regularly transmit its SIB1 but is configured to transmit its SIB1 in response to a SIB1 request. Within the MIB 1106, a PDCCH-ConfigSIB1 field (which may be an eight bit field in some cases) may be used / repurposed to indicate a concise RACH and paging configuration for the UE 1102 to use with a "Msg1" on-demand SI request RACH procedure 1108 that includes a request for an SIB1 of the NES cell 1304.

[0129] Based on RACH configuration indicated by the PDCCH-ConfigSIB1 field, the UE 1102 transmits a preamble 1110 ( "Msg1" ) that includes / represents the SIB1 request  (e.g., where the SIB1 request is represented by the particular preamble 1110 used in this transmission and / or by the RO used for the transmission of the preamble 1110, as is discussed elsewhere herein) .

[0130] Upon receiving the preamble 1110, the NES cell 1104 understands that it is to transmit an NES cell SIB1 and responds to the UE 1102 with a RAR 1112 that acts as an indication to the UE 1102 that the preamble 1110 was received.

[0131] The flow diagram 1100 corresponds to cases where an eventual NES cell SIB1 is transmitted by the NES cell 1104 at a time that is determined relative to a defined BCCH modification period boundary 1114. This situation may correspond to embodiments where MIB / SIB1 contents are not changed at a cell until a new BCCH modification period (e.g., as defined by the BCCH modification period boundary 1114, as illustrated) .

[0132] Once the relevant BCCH modification period begins, the UE monitors for a (second) MIB 1118 of the NES cell 1104 (e.g., by monitoring for SSB (s) of the NES cell 1304 that carry the MIB 1118) . Note that this instance of the MIB 1118 includes a value of kSSB = 10, indicating that the NES cell SIB1 is transmitted corresponding to this instance of the MIB 1118. The MIB 1118 also includes configuration information for a CORESET #0 and a SS corresponding to the SIB 1 of the NES cell 1104 such that the UE is enabled to monitor for the upcoming SIB1.

[0133] The UE 1102 then performs the corresponding reception 1120 of the SIB1 as transmitted by the NES cell 1104.

[0134] Then, with the acquired full SIB1, the UE accesses 1122 the NES cell 1104 (e.g., the UE 1102 performs UAC and initial access procedures with the NES cell 1104) . The UE 1102 then enters an RRC connected state 1124 with the NES cell 1104. Accordingly, data transmission 1126 may then occur between the UE 1102 and the NES cell 1104.

[0135] Trigger conditions for the SIB1 request for embodiments where the UE accesses the NES cell directly (without relying on an anchor cell) are now discussed. In some such circumstances, the UE may trigger an on-demand SI request RACH procedure for a SIB1 of the NES cell when pending UL traffic is greater than an amount threshold. In other cases, the trigger may occur based upon a reception of paging corresponding to available DL traffic.

[0136] Note that in some wireless communications systems, if pending data is less than the amount threshold, the UE can trigger the use of a small data transmission (SDT) procedure (e.g., in place of the on-demand SI request RACH procedure for a SIB1 for access purposes) .

[0137] FIG. 12 illustrates a diagram 1200 showing a timeline for signaling between a UE 1202 and an NES cell 1204 corresponding to the use of a "Msg1" on-demand SI request RACH procedure 1206 between the UE 1202 and the NES cell 1204 that includes a SIB1 request for the NES cell 1204, according to embodiments discussed herein.

[0138] The NES cell 1204 transmits NES cell SSBs 1208 that use a reserved value for kSSB (e.g., kSSB = 30 for FRi or kSSB = 14 for FR2) to indicate that the NES cell SSBs 1208 does not regularly transmit its SIB1 but is configured to  transmit its SIB1 in response to a SIB1 request. Upon receiving one or more of the NES cell SSBs 1208, the UE 1202 decodes a PDCCH-ConfigSIB1 IE therefrom that contains a concise RACH configuration 1210 for the UE 1202 to use to perform the "Msg1" on-demand SI request RACH procedure 1206 with the NES cell 1204.

[0139] Once the UE 1202 identifies (1212) a need for the SIB1 of the NES cell 1204 (e.g., because it needs to enter RRC connected state with the NES cell 1204 in order to satisfy a trigger for UL and / or DL data transmission) , the UE proceeds to perform the "Msg1" on-demand SI request RACH procedure 1206 with the NES cell 1204. Based on a RACH configuration indicated by the PDCCH-ConfigSIB1 field, the UE 1202 transmits a preamble 1214 ( "Msg1" ) that includes / represents the SIB1 request (e.g., where the SIB1 request is represented by the particular preamble 1214 used in this transmission and / or by the RO used for the transmission of the preamble 1214, as is discussed elsewhere herein) . Upon receiving the preamble 1214, the NES cell 1204 understands that it is to transmit an NES cell SIB1 1218 and responds to the UE 1202 with a RAR 1216 that acts as an indication to the UE 1202 that the preamble 1214 was received.

[0140] The flow diagram 1200 corresponds to cases where an eventual NES cell SIB1 1218 is transmitted by the NES cell 1204 at a time that is determined relative to a defined BCCH modification period boundary 1220. This situation may correspond to embodiments where MIB / SIB1 contents are not changed at a cell until a new BCCH modification period (e.g., as defined by the BCCH modification period boundary 1220, as illustrated) .

[0141] At this juncture, various options exist corresponding to the behavior of the UE 1202 for triggering the monitoring 1224 for NES cell SSBs corresponding to the expected NES cell SIB1 1218 / its associated CORESET #0 1222.

[0142] In a first option, the UE 1202 simply performs the monitoring 1224 during a next BCCH modification period that begins after the "Msg1" on-demand SI request RACH procedure 1206. This option does not need to introduce specification changes on any paging message, at the cost of potentially wasted UE power consumption, as the UE may waste its power on performing the monitoring if the NES cell 1204 doesn′t actually broadcast the NES cell SIB1 in the next BCCH modification period (e.g., due to timing constraints in a case where the "Msg1" on-demand SI request RACH procedure 1206 occurs very close to the BCCH modification period boundary 1220) .

[0143] In a second option, the UE 1202 performs the monitoring during a next BCCH modification period that begins after the reception of a paging short message 1226 that arrives after the "Msg1" on-demand SI request RACH procedure 1206 and confirms to the UE 1202 that the expected SIB1 broadcasting status change will occur in the next BCCH modification period (e.g., that NES cell SIB1 1218 will actually be transmitted during that next BCCH modification period) . This procedure may avoid any timing-related mis-assumptions by the UE with respect to the relevant BCCH modification period, at the cost of the use of additional signaling resources and potentially additional corresponding latency.

[0144] In a third option, it may be that the NES cell 1204 includes a bit in the RAR 1216 of the "Msg1" on-demand  SI request RACH procedure 1206 that indicates / confirms to the UE 1202 that the NES cell SIB1 1218 will be transmitted during a next BCCH modification period that begins after the end of the "Msg1" on-demand SI request RACH procedure 1206. This procedure may avoid any timing-related mis-assumptions by the UE with respect to the relevant BCCH modification period, at the cost of the use of additional signaling resources.

[0145] Once the relevant BCCH modification period begins, the UE monitors for a (second) MIB of the NES cell 1204 (e.g., by monitoring for (instances of) SSB (s) of the NES cell 1204 that carry the MIB) . Note that this instance of the SSB (s) after the BCCH modification period boundary 1220 includes a value of kSSB = 10, indicating that the NES cell SIB1 1218 is transmitted corresponding to this instance of the SSB (s) . The SSB (s) also include configuration information for a CORESET #0 and a SS corresponding to the NES cell SIB1 1218 such that the UE is enabled to monitor for the upcoming NES cell SIB1 1218.

[0146] The UE 1202 then performs the corresponding reception of the NES cell SIB1 1218 as transmitted by the NES cell 1204.

[0147] Improved methods and techniques for on-demand acquisition of the SIB1 information for UEs in idle or inactive mode are desirable. In particular, methods and techniques for more quickly acquiring the on-demand SIB1 information without using too many resources or power might be beneficial. Example embodiments relate to systems, devices, methods and techniques for fast on-demand SIB1 acquisition by UEs will now be discussed.

[0148] FIG. 13 is an example flow diagram illustrating an example procedure for acquiring on-demand SIB1 information according to various example embodiments. In the procedure 1300, the UE obtains the uplink wake-up signal configuration of the non-anchor cell and carrier selection as previously discussed (1310) . After sending the preamble to the non-anchor cell (1312) , the UE may receive a RAR from the non-anchor cell (1314) . The UE may monitor for SIB1 (1316) . The UE may need the full SIB1 or updated SIB1 or receive the full or updated SIB1 (1318) and thus may perform a RACH procedure which may include transmitting another preamble (1320) and receiving a second RAR (1322) before the UE may transmit a Msg3 to the non-anchor cell (1324) or receive a Msg4 from the non-anchor cell (1326) in order to enter the RRC CONNECTED State (1328) and be able to receive additional messaging (such as Msg5) or data from the non-anchor cell (1330) .

[0149] In the embodiments disclosed above, it may be difficult to obtain the SIB1 information quickly. For example, in the first scenario discussed above in FIGS. 8-10 (the piggybacked / anchor cell assisted scenario) , the UE obtains CORESET#0 from the Synchronization System Block (SSB) in the next BCCH modification period. However, this may result in some latency since the UE has to wait until the next BCCH modification period.

[0150] Likewise, in another alternative, the UE obtains CORESET#0 from the SSB in a configured SI window of SIB1. In yet another alternative, a new RAR or DCI format scrambled with RA-RNTI may be used which includes scheduling info of CORESET#0. In the second and third alternatives (and as seen in FIG. 13) , the UE has to receive the RAR before monitoring SIB1. This may also introduce and / or  increase latency. In addition, when the UE needs to enter the RRC CONNECTED state, the preamble / RAR pairs are duplicated (see FIG. 13) , which also may increase latency.

[0151] In order to reduce and / or avoid this latency, additional solutions are proposed to speed up the UE′son-demand SIB1 (OD-SIB1) acquisition in at least two situations. FIG. 14A is an example flow diagram that illustrates an example procedure for fast acquisition of on-demand SIB1 information according to various example embodiments. In a first case, as seen in FIG. 14A, the OD-SIB1 procedure 1400 is for SIB1 update. The UE obtains the uplink wake-up signal configuration of the non-anchor cell and carrier selection as previously discussed (1402) . After sending the preamble to the non-anchor cell (1404) , the UE may monitor SIB1 without need of reception of RAR. The UE may start a configured window for the OD-SIB1 (1408) . There may be an offset between the sending of the preamble and the start of the window (1406) . The UE may then monitor during the configured window for the SIB1 from the non-anchor cell (1410) .

[0152] FIG. 14B is an example flow diagram that illustrates another example procedure for fast acquisition of on-demand SIB1 information according to various example embodiments. In a second case, as seen in FIG. 14B, the OD-SIB1 procedure 1450 is for entering a RRC CONNECTED state. In particular, there may be introduced changes to the RACH procedure and the RAR format to avoid the duplicated preamble  / RAR pair seen in FIG. 13. In FIG. 14B, the UE obtains the uplink wake-up signal configuration of the non-anchor cell and carrier selection as previously discussed (1452) . After sending the preamble to the non-anchor cell (1454) , the UE may receive the RAR from the non-anchor cell  (1456) . The UE may start a configured window for the OD-SIB1 (1458) and can then monitor for SIB1 (1460) during the configured monitor window. The UE may transmit a Msg3 in the form of Msg3 (RRCSetupRequest / RRCResume Request) to the non-anchor cell (1462) . The non-anchor cell may then send a Msg4 in the form of Msg4 (RRCSetup / RRCResume) to the UE (1464) . The UE may then enter the RRC CONNECTED State (1466) and may receive additional messaging (such as Msg5) from the non-anchor cell (1468) .

[0153] Different trigger conditions may apply for the UE initiating OD-SIB1, depending upon the scenario. FIG. 15A is an example flow diagram that illustrates an example procedure for a UE initiating an on-demand SIB1 acquisition and / or update in a first scenario according to various example embodiments. For example, in the first scenario, where an anchor cell is providing piggybacked SIB1 of a NES cell without SIB1, certain conditions may trigger the UE to initiate acquisition and / or update of the OD-SIB1. As seen in FIG. 15A, after the UE has been provided the SIB of the anchor cell with the piggybacked SIB1 of the non-anchor cell (1502) , the UE checks to see if certain condition (s) are met (1504) . When the condition (s) are met, the UE may initiate the OD-SIB1 procedure (1506) . In the case where multiple conditions are configured, all of the conditions need to be met in order to trigger the OD-SIB1 procedure. The UE may use the SIB information to perform a RACH procedure (1508) to gain initial access such that the UE camps in the non-anchor cell without SIB1 (1510) .

[0154] The trigger conditions for the first scenario as seen in FIG. 15A may include or more of the following: Condition 1: a radio condition of the non-anchor cell (e.g., Reference Signal Received Power (RSRP) ) is greater than a  first threshold; Condition 2: a radio condition of the non-anchor cell is greater than the first threshold and a radio condition of the anchor cell is less than a second threshold; Condition 3: a radio condition of the non-anchor cell is better than the radio condition of the anchor cell by a third threshold; Condition 4: uplink (UL) traffic and / or signaling has arrived; Condition 5: upon reception of downlink (DL) indication (e.g. paging or DL DCI in the anchor cell) ; Condition 6: SIB1 needs update, or no valid SIB1 is stored; and / or Condition 7: After recovery from Radio Link Failure (RLF) (e.g., after RRC re-establishment) .

[0155] FIG. 15B is an example flow diagram that illustrates an example procedure for a UE initiating an on-demand SIB1 acquisition and / or update in a second scenario according to various example embodiments. For example, in the second scenario, where a standalone NES cell is providing the SIB1, different conditions may trigger the UE to initiate acquisition and / or update of the OD-SIB1. As seen in FIG. 15B, the UE may obtain UL WUS configuration from the MIB of the standalone NES cell (1552) . The UE then checks to see if certain condition (s) are met (1554) . When the condition (s) are met, the UE may initiate the OD-SIB1 procedure (1556) . In the case where multiple conditions are configured, all of the conditions need to be met in order to trigger the OD-SIB1 procedure. The UE may use the SIB information to perform a RACH procedure (1558) to gain initial access such that the UE camps in the standalone NES cell without SIB1 (1560) .

[0156] The trigger conditions for the second scenario as seen in FIG. 15B may include or more of the following: Condition 1: a radio condition of the NES cell (e.g. RSRP) is greater than a first threshold; Condition 2: UL traffic  and / or signaling has arrived; Condition 3: upon reception of DL indication (e.g., paging or DL DCI in anchor cell) ; Condition 4: SIB1 needs update, or no valid SIB1 is stored; and / or Condition 5: after recovery from RLF (e.g., after RRC re-establishment) .

[0157] FIGS. 16A and 16B are example flow diagrams illustrating an example procedure for an on-demand SIB1 request for updating the SIB1 according to various example embodiments. Looking at both Fig. 16A and Fig. 16B, once the UE has obtained the UL WUS configuration (1610, 1652) , and determines which NES cell to request OD-SIB1, the UE may send the preamble to the non-anchor cell (1612, 1654) . In addition, the UE may take certain additional steps in the OD-SIB1 procedure. These steps apply to both the piggybacked / anchor cell assisted scenario (first scenario above) and the standalone NES cell scenario (second scenario above) . The approach described herein uses a reserved preamble and RACH occasion (RO) for the OD-SIB1 request, i.e. a msg 1 based solution.

[0158] According to the proposed procedure, as seen in FIGS. 16A and 16B, the UE may perform new functionality. For example, after sending the preamble, the UE starts a configured window for OD-SIB1. There may be an offset period between sending preamble and the starting of the window. In a first embodiment, as seen in FIG. 16A, the offset 1614 may be a fixed value, or it may be configurable as part of the UL WUS configuration. It is assumed that the network configures RO locations close to time location of next CORESET#0. In a second alternative (see FIG. 16B) , the offset 1656 may start from the time location of the next CORESET#0. The time / frequency location of CORESET#0 is still acquired via PDCCH-ConfigSIB1 in MIB as previously  discussed. In either alternative, a length of the window is configurable as part of the UL WUS configuration. The UE may monitor the window (1616, 1658) for cell defined SSB (CD-SSB) (1618, 1660) for CORESET#0 (1620, 1662) and its associated SIB1 (1622, 1664) before the window expires. The time / frequency location of CORESET#0 is still acquired via PDCCH-ConfigSIB1 in MIB as previously discussed.

[0159] If the monitoring window expires but the OD-SIB1 is not detected, the UE will trigger retransmission of the preamble to request the OD-SIB1 again. This may occur, for example, if there are poor signal conditions at the UE, or if the network does not receive the SIB request for some reason. In one embodiment, if the number of retransmission attempts exceeds a configured threshold, or if the UE receives an explicit "stop" indication from the network, the UE may be triggered to perform certain functions. For example, the UE may perform one or more of the following: trigger cell reselection procedure with the current cell as the lowest priority; bar this cell for up to a predetermined period of time (e.g., 300 seconds) ; and / or abort the attempt to send the UL WUS signal.

[0160] In the above described on-demand SIB1 acquisition procedures, a network node, such as a base station or gNB, may be configured in a new or different way and may have certain functionalities. For example, a gNB or other network node will have to be able to configure new configurations as part of the UL WUS configuration. For example, the UL WUS configuration may include the offset, monitoring window length, and OD-SIB1 retransmission threshold discussed above. In addition, if the gNB does not want to wake up (e.g., because it is a power savings mode or has a iow battery) , it may send a new explicit "stop"  indication to the UE. In this instance, the new configuration may include a periodicity and an offset for the "stop" indication. The "stop" indication may be a new UE group common DCI in one embodiment, where the UE monitors this new UE group common DCI in time location of CORESET#0. In an alternative, the gNB may use a reserved bit of a paging short message to send the "stop" indication. In another embodiment, one spare bit in the MIB may be used for the "stop" indication. In yet another embodiment, one bit of reserved Kssb values may be used for the "stop" indication.

[0161] FIG. 17 is an example flow diagram that illustrates another example procedure for fast acquisition of on-demand SIB1 information for entering a RRC CONNECTED state according to various example embodiments. Once the UE has obtained the UL WUS configuration (1702) , and determines which NES cell to request OD-SIB1, the UE may send the preamble to the non-anchor cell (1704) . In addition, the UE may take certain additional steps in the OD-SIB1 procedure. The approach described herein, different preambles and ROs are reserved for the procedure for obtaining OD-SIB1 for entering the RRC CONNECTED state as opposed to the procedure for obtaining OD-SIB1 for updates (Figs. 16A and 16B above) .

[0162] Referring again to Fig. 17, after sending the preamble, the network (e.g., the non-anchor cell) provides a RAR as previously done (1706) , but new fields are introduced in the RAR, so that the UE can send msg3 messages without needing to send duplicated preamble and RAR information. For example, a one bit "allow" indication may be included in the RAR which indicates whether the network agrees to send OD-SIB1 and allow the UE to camp. If the UE receives "not allowed" , it performs one or more of the following steps:  trigger cell reselection procedure with the current cell as the lowest priority; bar this cell for up to a predetermined time period (e.g., 300s) ; and / or abort the attempt to send UL WUS signal.

[0163] If the UE receives an "allowed" indication, it will monitor OD-SIB1 and prepare to transmit msg3. There are various ways for the UE to obtain OD-SIB1 and send msg3. In a first embodiment, the RAR may include both a DL grant for a Physical Downlink Shared Channel (PDSCH) carrying the SIB1 and a UL grant for msg3 transmission (1708) . One example of a MAC RAR format 1800 may be seen in FIG. 18. In a second embodiment, the RAR may only include an UL grant for msg3 transmission as legacy. A one-bit "allow" indication can be applied in MAC RAR format. The UE then monitors for OD-SIB1 as previously discussed. If the RAR includes the DL grant carrying the SIB1 and a UL grant for msg3 transmission, the UE may transmit a msg3 (RRCSetupRequest / RRCResume Request) to the non-anchor cell (1710) . The non-anchor cell may then send a Msg4 in the form of Msg4 (RRCSetup / RRCResume) to the UE (1712) . The UE may then enter the RRC CONNECTED State and may receive additional messaging (such as Msg5) or other data from the non-anchor cell (1716) .

[0164] If the UE cannot obtain OD-SIB1 when the resource indicated by UL grant comes, the UE will skip msg3 transmission. In this case, the gNB will treat it as a discontinuous transmission (DTX) , and will trigger an UL hybrid automatic retransmission request (HARQ) procedure for the UE to retransmit msg3. If the monitor window expires before the OD-SIB1 is obtained, the UE discards the UL grant, and retransmits the preamble.

[0165] In this procedure, with respect to the gNB, new configurations will need to be supported. In particular, different preambles and / or ROs are assigned for this procedure to obtain OD-SIB1 to enter the RRC CONNECTED state as part of the UL WUS configuration.

[0166] Examples

[0167] In a first example embodiment, a method comprising processing, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising a RACH preamble for requesting system information block (SIB) information from a cell, determining that on-demand system information block 1 (SIB1) information is desired, generating, for transmission to the cell, the RACH preamble to request the on-demand SIB1 information, starting a configured window for monitoring SIB1 information and monitoring, during the configured window, information from the cell for the on-demand SIB1 information.

[0168] In a second example, the method of the first example further comprising monitoring, during the configured window, cell-defined Synchronization Signal Block (SSB) information from the cell for CORESET#0 and associated SIB1 information.

[0169] In a third example, the method of the first example, wherein there is an offset between transmitting the RACH preamble and the start of the configured window.

[0170] In a fourth example, the method of the third example, wherein the offset is one of a fixed value or a  configurable value based on the UL WUS configuration information.

[0171] In a fifth example, the method of the third example, wherein the offset is configured to start from a time location of a next CORESET#0 received in the configuration information.

[0172] In a sixth example, the method of the first example, wherein a length of the configured window is based on the UL WUS configuration information.

[0173] In a seventh example, the method of the second example, wherein a time / frequency location of CORESET#0 is acquired via a Physical Downlink Control Channel (PDCCH) field in a Master Information Block (MIB) received in the configuration information.

[0174] In an eighth example, the method of the first example, wherein the monitoring of information from the cell for the on-demand SIB1 information during the configured window occurs before any random access response (RAR) is received from the cell.

[0175] In a ninth example, the method of the first example, wherein the base station is an anchor cell and the cell from which SIB information is being requested is a non-anchor cell, wherein the UL WUS configuration information comprises information for requesting SIB1 information from the non-anchor cell, and wherein the method further comprises initiating an on-demand SIB1 acquisition procedure upon an occurrence of a trigger condition.

[0176] In a tenth example, the method of the ninth example, wherein the trigger condition comprises one or more of a radio condition of the non-anchor cell being greater than a first threshold, a radio condition of the non-anchor cell being greater than the first threshold and a radio condition of the anchor cell being less than a second threshold, a radio condition of the non-anchor cell being better than the radio condition of the anchor cell by a third threshold, arrival of uplink (UL) traffic or signaling, reception of a downlink (DL) indication in the anchor cell, the SIB1 needs an update, no valid SIB1 is stored or recovery from Radio Link Failure (RLF) .

[0177] In an eleventh example, the method of the ninth example, wherein, to initiate the on-demand SIB1 acquisition procedure upon an occurrence of the trigger condition, the method further comprises performing a random access channel (RACH) procedure with the non-anchor cell, the RACH procedure comprising a SIB1 request, processing, based on signals received from the non-anchor cell, a SIB1 of the non-anchor cell in response to the SIB1 request and accessing the non-anchor cell based on system information (SI) of the SIB1 of the non-anchor cell.

[0178] In a twelfth example, the method of the first example, wherein the cell is a standalone network energy savings (NES) cell, wherein the UL WUS configuration information is obtained from a Master Information Block (MIB) of the NES cell, and wherein the method further comprises initiating an on-demand SIB1 acquisition procedure upon an occurrence of a trigger condition.

[0179] In a thirteenth example, the method of the twelfth example, wherein the trigger condition comprises one or more  of a radio condition of the NES cell being greater than a first threshold, arrival of uplink (UL) traffic or signaling, reception of a downlink (DL) indication the SIB1 needs an update, no valid SIB1 is stored or recovery from Radio Link Failure (RLF) .

[0180] In a fourteenth example, the method of the twelfth example, wherein, to initiate the on-demand SIB1 acquisition procedure upon an occurrence of the trigger condition, the method further comprises performing a random access channel (RACH) procedure with the NES cell, the RACH procedure comprising a SIB1 request, processing, based on signals received from the NES cell, a SIB1 of the NES cell in response to the SIB1 request and accessing the NES cell based on system information (SI) of the SIB1 of the NES cell.

[0181] In a fifteenth example, the method of the first example, further comprising generating, for transmission to the cell, a retransmission of the RACH preamble to request the on-demand SIB1 information if no on-demand SIB1 information is detected during the configured window.

[0182] In a sixteenth example, the method of the fifteenth example, wherein if a number of retransmissions exceeds a preconfigured threshold, the method further comprises performing one or more of the following: triggering cell reselection procedure with the cell as the lowest priority, barring the cell for up to a predetermined period of time or aborting attempting to send a UL WUS signal.

[0183] In a seventeenth example, the method of the first example, wherein if a stop indication from a network node is  processed, the method further comprises performing one or more of the following: triggering cell reselection procedure with the cell as the lowest priority, barring the cell for up to a predetermined period of time, or aborting attempting to send a UL WUS signal.

[0184] In an eighteenth example, the method of the seventeenth example, wherein the configuration information received from the base station includes one or more of a periodicity and an offset for sending the stop indication.

[0185] In a nineteenth example, the method of the third example, wherein the configuration received from the base station includes one or more of a value of the offset, a length of the configured window, and a preconfigured threshold for a maximum number of retransmission attempts if no on-demand SIB1 information is detected during the configured window.

[0186] In a twentieth example, a processor configured to perform any of the methods of the first through nineteenth examples.

[0187] In a twenty first example, a user equipment (UE) comprising a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the first through nineteenth examples.

[0188] In a twenty second example, a method comprising processing, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH  preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell, generating, for transmission to the cell, the RACH preamble to request on-demand system information block 1 (SIB1) information for entering a radio resource control (RRC) connected state, processing, based on signals received from the cell, a random access response (RAR) in response to the RACH preamble and monitoring, based on information in the RAR, information from the cell for the on-demand SIB1 information.

[0189] In a twenty third example, the method of the twenty second example, wherein the RAR comprises an indication on whether the cell agrees to transmit the on-demand SIB1 information and to allow a user equipment (UE) to camp in the cell.

[0190] In a twenty fourth example, the method of the twenty third example, wherein if the RAR comprises an indication that the UE is not allowed to camp in the cell, the method further comprises performing one or more of the following: triggering cell reselection procedure with the cell as the lowest priority, barring the cell for up to a predetermined period of time, or aborting attempting to send a UL WUS signal.

[0191] In a twenty fifth example, the method of the twenty third example, wherein if the RAR comprises an indication that the UE is allowed to camp in the cell, the method further comprises monitoring for the on-demand SIB1 information to transmit a message based on the on-demand SIB1 information to the cell to request information to allow the UE to enter the RRC connected state.

[0192] In a twenty sixth example, the method of the twenty second example, wherein the RAR includes at least one downlink (DL) grant for a Physical Downlink Shared Channel (PDSCH) carrying SIB1 information for the cell and an uplink (UL) grant for a msg3 transmission.

[0193] In a twenty seventh example, the method of the twenty second example, wherein the RAR includes only an uplink (UL) grant for a msg3 transmission.

[0194] In a twenty eighth example, the method of the twenty fourth example, further comprising starting a configured window for monitoring SIB1 information and monitoring, during the configured window, information from the cell for the on-demand SIB1 information.

[0195] In a twenty ninth example, the method of the twenty eighth example, wherein the if the configured window expires before the on-demand SIB1 information is obtained, the method further comprises discarding the UL grant and to retransmit the RACH preamble.

[0196] In a thirtieth example, a processor configured to perform any of the methods of the twenty second through twenty ninth examples.

[0197] In a thirty first example, a user equipment (UE) comprising a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the twenty second through twenty ninth examples.

[0198] In a thirty second example, a method comprising processing, based on signaling received from a user  equipment (UE) , a request for System Information Block 1 (SIB1) information and generating, for transmission to the UE, configuration information in response to the request for SIB1 information, the configuration information including uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell.

[0199] In a thirty third example, the method of the thirty second example, wherein the configuration information includes a Physical Downlink Control Channel (PDCCH) field in a Master Information Block (MIB) , the PDCCH field including CORESET#0 information.

[0200] In a thirty fourth example, the method of the thirty second example, wherein the configuration information includes a RACH preamble for the UE to use in requesting system information block (SIB) information from the cell, information for the UE to start a configured window for monitoring SIB1 information, where there is an offset between the UE transmitting the RACH preamble to the cell and the start of the configured window and information relating to one or more of a value of the offset, a length of the configured window, and a preconfigured threshold for a maximum number of retransmission attempts if no on-demand SIB1 information is detected during the configured window.

[0201] In a thirty fifth example, the method of the thirty second example, further comprising generating, for transmission to the UE, a stop indication configured to indicate to the UE to perform one or more of the following: trigger cell reselection procedure with the cell as the  lowest priority, bar the cell for up to a predetermined period of time or abort attempting to send a UL WUS signal.

[0202] In a thirty sixth example, the method of the thirty fifth example, wherein the stop indication is transmitted via a UE group common downlink control information (DCI) .

[0203] In a thirty seventh example, the method of the thirty fifth example, wherein the stop indication is transmitted via one or more of a reserved bit of a paging short message, a spare bit in a Master Information Block (MIB) or one bit of reserved Kssb values.

[0204] In a thirty eighth example, the method of the thirty fifth example, wherein the configuration information includes one or more of a periodicity and an offset for sending the stop indication.

[0205] In a thirty ninth example, a processor configured to perform any of the methods of the thirty second through thirty eighth examples.

[0206] In a fortieth example, a base station comprising a transceiver configured to communicate with a user equipment (UE) and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the thirty second through thirty eighth examples.

[0207] In a forty first example, a method comprising processing, based on signaling received from a user equipment (UE) , a request for on-demand System Information Block 1 (SIB1) information for entering a radio resource control (RRC) connected state, generating, for transmission  to the UE, configuration information in response to the request for SIB1 information, the configuration information including uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell and, in response to receiving the RACH preamble from the UE, generating, for transmission to the UE, a random access response (RAR) comprising an indication on whether the cell agrees to transmit the on-demand SIB1 information and to allow the UE to camp in the cell.

[0208] In a forty second example, the method of the forty first example, wherein the RAR comprises an indication that the UE is not allowed to camp in the cell.

[0209] In a forty third example, the method of the forty first example, wherein if the RAR comprises an indication that the UE is allowed to camp in the cell.

[0210] In a forty fourth example, the method of the forty first example, wherein the RAR includes at least one downlink (DL) grant for a Physical Downlink Shared Channel (PDSCH) carrying SIB1 information for the cell and an uplink (UL) grant for a msg3 transmission.

[0211] In a forty fifth example, the method of the forty first example, wherein the RAR includes only an uplink (UL) grant for a msg3 transmission.

[0212] In a forty sixth example, the method of the forty fifth example, wherein if the UE is unable to obtain the on-demand SIB1 information in order to transmit the msg3, the processing circuitry is further configured to trigger an UL  hybrid automatic retransmission request (HARQ) procedure for the UE to retransmit msg3.

[0213] In a forty seventh example, a processor configured to perform any of the methods of the forty first through forty sixth examples.

[0214] In a forty eighth example, a base station comprising a transceiver configured to communicate with a user equipment (UE) and a processor communicatively coupled to the transceiver and configured to perform any of the methods of the forty first through forty sixth examples.

[0215] Those skilled in the art will understand that the above-described example embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An example hardware platform for implementing the example embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The example embodiments described above may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor.

[0216] In some embodiments, a non-transitory computer-readable memory medium (e.g., a non-transitory memory element) may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, e.g., any of a method embodiments described herein, or, any combination of the method embodiments described herein, or, any subset of any of the  method embodiments described herein, or, any combination of such subsets.

[0217] In some embodiments, a device (e.g., a UE) may be configured to include a processor (or a set of processors) and a memory medium (or memory element) , where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets) . The device may be realized in any of various forms.

[0218] Embodiments of the present invention may be realized in any of various forms. For example, in some embodiments, the present invention may be realized as a computer-implemented method, a computer-readable memory medium, or a computer system. In other embodiments, the present invention may be realized using one or more custom-designed hardware devices such as ASICs. In other embodiments, the present invention may be realized using on1e or more programmable hardware elements such as FPGAs.

[0219] Although this application described various embodiments each having different features in various combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments.

[0220] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0221] It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Claims

1.An apparatus comprising processing circuitry configured to:process, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising a RACH preamble for requesting system information block (SIB) information from a cell;determine that on-demand system information block 1 (SIB1) information is desired;generate, for transmission to the cell, the RACH preamble to request the on-demand SIB1 information;start a configured window for monitoring SIB1 information; andmonitor, during the configured window, information from the cell for the on-demand SIB1 information.2.The apparatus of claim 1, wherein the processing circuitry is configured to monitor, during the configured window, cell-defined Synchronization Signal Block (SSB) information from the cell for CORESET#0 and associated SIB1 information.3.The apparatus of claim 1, wherein there is an offset between transmitting the RACH preamble and the start of the configured window.4.The apparatus of claim 3, wherein the offset is one of a fixed value or a configurable value based on the UL WUS configuration information.5.The apparatus of claim 3, wherein the offset is configured to start from a time location of a next CORESET#0 received in the configuration information.6.The apparatus of claim 1, wherein a length of the configured window is based on the UL WUS configuration information.7.The apparatus of claim 2, wherein a time / frequency location of CORESET#0 is acquired via a Physical Downlink Control Channel (PDCCH) field in a Master Information Block (MIB) received in the configuration information.8.The apparatus of claim 1, wherein the monitoring of information from the cell for the on-demand SIB1 information during the configured window occurs before any random access response (RAR) is received from the cell.9.The apparatus of claim 1, wherein the base station is an anchor cell and the cell from which SIB information is being requested is a non-anchor cell, wherein the UL WUS configuration information comprises information for requesting SIB1 information from the non-anchor cell, and wherein the processing circuitry is configured to initiate an on-demand SIB1 acquisition procedure upon an occurrence of a trigger condition.10.The apparatus of claim 9, wherein the trigger condition comprises one or more of:a radio condition of the non-anchor cell being greater than a first threshold;a radio condition of the non-anchor cell being greater than the first threshold and a radio condition of the anchor cell being less than a second threshold;a radio condition of the non-anchor cell being better than the radio condition of the anchor cell by a third threshold;arrival of uplink (UL) traffic or signaling;reception of a downlink (DL) indication in the anchor cell;the SIB1 needs an update;no valid SIB1 is stored; orrecovery from Radio Link Failure (RLF) .11.The apparatus of claim 9, wherein, to initiate the on-demand SIB1 acquisition procedure upon an occurrence of the trigger condition, the processing circuitry is further configured to:perform a random access channel (RACH) procedure with the non-anchor cell, the RACH procedure comprising a SIB1 request;process, based on signals received from the non-anchor cell, a SIB1 of the non-anchor cell in response to the SIB1 request; andaccess the non-anchor cell based on system information (SI) of the SIB1 of the non-anchor cell.12.The apparatus of claim 1, wherein the cell is a standalone network energy savings (NES) cell, wherein the UL WUS configuration information is obtained from a Master Information Block (MIB) of the NES cell, and wherein the processing circuitry is configured to initiate an on-demand SIB1 acquisition procedure upon an occurrence of a trigger condition.13.The apparatus of claim 12, wherein the trigger condition comprises one or more of:a radio condition of the NES cell being greater than a first threshold;arrival of uplink (UL) traffic or signaling;reception of a downlink (DL) indication;the SIB1 needs an update;no valid SIB1 is stored; orrecovery from Radio Link Failure (RLF) .14.The apparatus of claim 12, wherein, to initiate the on-demand SIB1 acquisition procedure upon an occurrence of the trigger condition, the processing circuitry is further to:perform a random access channel (RACH) procedure with the NES cell, the RACH procedure comprising a SIB1 request;process, based on signals received from the NES cell, a SIB1 of the NES cell in response to the SIB1 request; andaccess the NES cell based on system information (SI) of the SIB1 of the NES cell.15.The apparatus of claim 1, wherein the processing circuitry is configured to generate, for transmission to the cell, a retransmission of the RACH preamble to request the on-demand SIB1 information if no on-demand SIB1 information is detected during the configured window.16.The apparatus of claim 15, wherein if a number of retransmissions exceeds a preconfigured threshold, the processing circuitry is further configured to perform one or more of the following: trigger cell reselection procedure with the cell as the lowest priority; bar the cell for up to a predetermined period of time; or abort attempting to send a UL WUS signal.17.The apparatus of claim 1, wherein if the processing circuitry processes a stop indication from a network node,  the processing circuitry is further configured to perform one or more of the following: trigger cell reselection procedure with the cell as the lowest priority; bar the cell for up to a predetermined period of time; or abort attempting to send a UL WUS signal.18.The apparatus of claim 17, wherein the configuration information received from the base station includes one or more of a periodicity and an offset for sending the stop indication.19.The apparatus of claim 3, wherein the configuration received from the base station includes one or more of a value of the offset, a length of the configured window, and a preconfigured threshold for a maximum number of retransmission attempts if no on-demand SIB1 information is detected during the configured window.20.An apparatus comprising processing circuitry configured to:process, based on signaling received from a base station, configuration information that includes uplink (UL) wake-up signal (WUS) configuration information, the UL WUS configuration information comprising one or more of a RACH preamble and a RACH occasion (RO) for requesting system information block (SIB) information from a cell;generate, for transmission to the cell, the RACH preamble to request on-demand system information block 1 (SIB1) information for entering a radio resource control (RRC) connected state;process, based on signals received from the cell, a random access response (RAR) in response to the RACH preamble; andmonitor, based on information in the RAR, information from the cell for the on-demand SIB1 information.

Images