Method and apparatus for managing on-demand-system information block 1 request procedure

Abstract

A method performed by a user equipment (UE) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure is provided. The method receives, from a first cell, a wake-up signal (WUS) configuration including a threshold. The method initiates, based on the WUS configuration, the OD-SIB1 request procedure. The OD-SIB1 request procedure includes: transmitting, to a second cell, a WUS for requesting an SIB1; determining whether a response associated with the WUS is received from the second cell; receiving, from the second cell, the SIB1 after determining that the response is received from the second cell; retransmitting, to the second cell, the WUS after determining that the response is not received from the second cell; determining whether the OD-SIB1 request procedure has failed; and determining that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

Description

METHOD AND APPARATUS FOR MANAGING ON-DEMAND-SYSTEM INFORMATION BLOCK 1 REQUEST PROCEDURE

[0001] The present disclosure is related to wireless communication and, more specifically, to a User Equipment (UE), Base Station (BS), and method for managing an on-demand (OD)-system information block 1 (SIB1) request procedure in the wireless communication networks.

[0002] Various efforts have been made to improve different aspects of wireless communication for the cellular wireless communication systems, such as the 5thGeneration (5G) New Radio (NR), by improving data rate, latency, reliability, and mobility. The 5G NR system is designed to provide flexibility and configurability to optimize network services and types, accommodating various use cases, such as enhanced Mobile Broadband (eMBB), massive Machine-Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC). As the demand for radio access continues to grow, however, there exists a need for further improvements in the next-generation wireless communication systems.

[0003] The present disclosure is related to a UE, a BS, and a method for managing an on-demand (OD)-system information block 1 (SIB1) request procedure in the wireless communication networks.

[0004] In a first aspect of the present disclosure, a UE for managing an on-demand (OD)-system information block 1 (SIB1) request procedure is provided. The UE includes at least one processor and at least one non-transitory computer-readable medium that is coupled to the at least one processor and that stores one or more computer-executable instructions. The computer-executable instructions, when executed by the at least one processor, cause the UE to: receive, from a first cell, a wake-up signal (WUS) configuration including a threshold; and initiate, based on the WUS configuration, the OD-SIB1 request procedure. The OD-SIB1 request procedure includes: transmitting, to a second cell, a WUS for requesting an SIB1; determining whether a response associated with the WUS is received from the second cell; receiving, from the second cell, the SIB1 after determining that the response is received from the second cell; retransmitting, to the second cell, the WUS after determining that the response is not received from the second cell; determining whether the OD-SIB1 request procedure has failed; and determining that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

[0005] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: forgo initiating a second OD-SIB1 request procedure for a time period after determining that the OD-SIB1 request procedure has failed.

[0006] In some implementations of the first aspect, the OD-SIB1 request procedure further includes: starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell; and stopping the timer upon receiving the response from the second cell.

[0007] In some implementations of the first aspect, the OD-SIB1 request procedure further includes: determining, based on the timer, whether the OD-SIB1 request procedure has failed; and determining that the OD-SIB1 request procedure has failed upon the timer expires.

[0008] In some implementations of the first aspect, the WUS configuration configures one or more network energy saving (NES) cells for the UE, the second cell is selected by the UE from the one or more NES cells, and the threshold or the timer is applied to the one or more NES cells.

[0009] In some implementations of the first aspect, the WUS configuration configures one or more network energy saving (NES) cells for the UE, the second cell is selected by the UE from the one or more NES cells, and each of the one or more NES cells is configured with a different threshold or a different timer.

[0010] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: notify, by a lower layer of the UE, an upper layer of the UE that the number of retransmissions of the WUS is equal to the threshold; and interrupt, by the upper layer of the UE, the OD-SIB1 request procedure.

[0011] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: camp on a third cell during the OD-SIB1 request procedure; and interrupt the OD-SIB1 request procedure upon camping on the third cell.

[0012] In some implementations of the first aspect, the OD-SIB1 request procedure further includes: starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell; and stopping the timer upon interrupting the OD-SIB1 request procedure.

[0013] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: forgo initiating a cell reselection procedure during the OD-SIB1 request procedure.

[0014] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: forgo initiating a random access procedure or a second OD-SIB1 request procedure after transmitting the WUS and before receiving the response.

[0015] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: initiate, based on the WUS configuration, the OD-SIB1 request procedure while the UE is in a radio resource control (RRC) connected state; stay in the RRC connected state during the OD-SIB1 request procedure; and transition from the RRC connected state to an RRC idle state after determining that the OD-SIB1 request procedure has failed.

[0016] In some implementations of the first aspect, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: record a failure event associated with the OD-SIB1 request procedure after determining that the OD-SIB1 request procedure has failed; and report the failure event to a serving radio access network (RAN).

[0017] In a second aspect of the present application, a method performed by a user equipment (UE) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure is provided. The method includes receiving, from a first cell, a wake-up signal (WUS) configuration including a threshold; and initiating, based on the WUS configuration, the OD-SIB1 request procedure. The OD-SIB1 request procedure includes: transmitting, to a second cell, a WUS for requesting an SIB1; determining whether a response associated with the WUS is received from the second cell; receiving, from the second cell, the SIB1 after determining that the response is received from the second cell; retransmitting, to the second cell, the WUS after determining that the response is not received from the second cell; determining whether the OD-SIB1 request procedure has failed; and determining that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

[0018] In a third aspect of the present disclosure, a base station (BS) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure is provided. The BS includes at least one processor and at least one non-transitory computer-readable medium that is coupled to the at least one processor and that stores one or more computer-executable instructions. The computer-executable instructions, when executed by the at least one processor, cause the BS to: transmit, via a first cell, a wake-up signal (WUS) configuration that configures a user equipment (UE) to initiate the OD-SIB1 request procedure and includes a threshold for determining whether the OD-SIB1 request procedure has failed; and during the OD-SIB1 request procedure: receive, via a second cell, a WUS for requesting an SIB1; determine whether to transmit a response associated with the WUS via the second cell; transmit, via the second cell, the SIB1 after transmitting the response via the second cell; and monitor, on the second cell, the WUS retransmitted by the UE.

[0019] Aspects of the present disclosure are best understood from the following detailed disclosure when read with the accompanying drawings. Various features are not drawn to scale. Dimensions of various features may be arbitrarily increased or reduced for clarity of discussion.

[0020] FIG. 1 is a diagram illustrating a multi-carrier scenario, according to an example implementation of the present disclosure.

[0021] FIG. 2 is a diagram illustrating a stand-alone scenario, according to an example implementation of the present disclosure.

[0022] FIG. 3 is a diagram illustrating an on-demand SIB1 request procedure, according to an example implementation of the present disclosure.

[0023] FIG. 4 is a flowchart illustrating a method / process performed by a UE for managing an OD- SIB1 request procedure, according to an example implementation of the present disclosure.

[0024] FIG. 5 is a flowchart illustrating a method / process performed by a BS for managing an OD- SIB1 request procedure, according to an example implementation of the present disclosure.

[0025] FIG. 6 is a block diagram illustrating a node for wireless communication, according to an example implementation of the present disclosure.

[0026] Some of the abbreviations used in the present disclosure include: Abbreviation　　　　Full name 3GPP　　　　3rdGeneration Partnership Project 5G　　　　5thGeneration 5GC　　　　5G Core ARFCN　　　　Absolute Radio-Frequency Channel Number AS　　　　Access Stratum BS　　　　Base Station BWP　　　　Bandwidth Part CA　　　　Carrier Aggregation CAG　　　　Closed Access Group CN　　　　Core Network CU　　　　Central Unit DAPS　　　　Dual Active Protocol Stack DC　　　　Dual Connectivity DCI　　　　Downlink Control Information DL　　　　Downlink DU　　　　Distributed Unit E-UTRA(N)　　　　Evolved Universal Terrestrial Radio Access (Network) EN-DC　　　　E-UTRA NR Dual Connectivity EPC　　　　Evolved Packet Core FR　　　　Frequency Range IAB　　　　Integrated Access and Backhaul ID　　　　Identifier IE　　　　Information Element LAN　　　　Local Area Network LTE　　　　Long Term Evolution MAC　　　　Medium Access Control MAC CE　　　　MAC Control Element MCG　　　　Master Cell Group MIB　　　　Master Information Block MN　　　　Master Node MSG　　　　Message MT　　　　Mobile Termination NAS　　　　Non-Access Stratum NE-DC　　　　NR - E-UTRA Dual Connectivity NES　　　　Network Energy Saving NPN　　　　Non-Public Network NR　　　　New Radio NR-U　　　　NR Unlicensed NW　　　　Network NSSAI　　　　Network Slice Selection Assistance Information PCell　　　　Primary Cell PCI　　　　Physical Cell Identity PDCCH　　　　Physical Downlink Control Channel PDSCH　　　　Physical Downlink Shared Channel PDU　　　　Protocol Data Unit PHY　　　　Physical (layer) PLMN　　　　Public Land Mobile Network PNI-NPN　　　　Public Network Integrated Non-Public Network PRACH　　　　Physical Random Access Channel PSCell　　　　Primary SCG Cell / Primary Secondary Cell PUCCH　　　　Physical Uplink Control Channel PUSCH　　　　Physical Uplink Shared Channel RA　　　　Random Access RAN　　　　Radio Access Network RAR　　　　Random Access Response RAT　　　　Radio Access Technology RF　　　　Radio Frequency RNTI　　　　Radio Network Temporary Identifier RRC　　　　Radio Resource Control RS　　　　Reference Signal RSRP　　　　Reference Signal Received Power SCell　　　　Secondary Cell SCG　　　　Secondary Cell Group SI　　　　System Information SIB　　　　System Information Block SL　　　　Sidelink SN　　　　Secondary Node SNPN　　　　Stand-alone Non-Public Network SSB　　　　Synchronization Signal Block TS　　　　Technical Specification UE　　　　User Equipment UL　　　　Uplink V2X　　　　Vehicle-to-Everything WUS　　　　Wake-Up-Signal / Wake-Up-Signaling

[0027] The following contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed disclosure are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art.

[0028] Unless noted otherwise, like or corresponding elements among the drawings may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present disclosure are generally not to scale and are not intended to correspond to actual relative dimensions.

[0029] For the purposes of consistency and ease of understanding, like features may be identified (although, in some examples, not illustrated) by the same numerals in the drawings. However, the features in different implementations may be different in other respects and may not be narrowly confined to what is illustrated in the drawings.

[0030] References to “one implementation,” “an implementation,” “example implementation,” “various implementations,” “some implementations,” “implementations of the present application,” etc., may indicate that the implementation(s) of the present application so described may include a particular feature, structure, or characteristic, but not every possible implementation of the present application necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase “In some implementations,” or “in an example implementation,” “an implementation,” do not necessarily refer to the same implementation, although they may. Moreover, any use of phrases like “implementations” in connection with “the present application” are never meant to characterize that all implementations of the present application must include the particular feature, structure, or characteristic, and should instead be understood to mean “at least some implementations of the present application” includes the stated particular feature, structure, or characteristic. The term “coupled” is defined as connected, whether directly or indirectly through intervening components, and is not necessarily limited to physical connections. The term “comprising,” when utilized, means “including, but not necessarily limited to”; it specifically indicates open-ended inclusion or membership in the so-described combination, group, series, and the equivalent.

[0031] The expression “at least one of A, B and C” or “at least one of the following: A, B and C” means “only A, or only B, or only C, or any combination of A, B and C.” The terms “system” and “network” may be used interchangeably. The term “and / or” is only an association relationship for describing associated objects and represents that three relationships may exist such that A and / or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character “ / ” generally represents that the associated objects are in an “or” relationship.

[0032] For the purposes of explanation and non-limitation, specific details, such as functional entities, techniques, protocols, and standards, are set forth for providing an understanding of the disclosed technology. In other examples, detailed disclosure of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the present disclosure with unnecessary details.

[0033] Persons skilled in the art will immediately recognize that any network function(s) or algorithm(s) disclosed may be implemented by hardware, software, or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof.

[0034] A software implementation may include computer executable instructions stored on a computer-readable medium, such as memory or other type of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function(s) or algorithm(s).

[0035] The microprocessors or general-purpose computers may include Application-Specific Integrated Circuits (ASICs), programmable logic arrays, and / or one or more Digital Signal Processor (DSPs). Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware, as hardware, or as a combination of hardware and software are well within the scope of the present disclosure. The computer-readable medium includes but is not limited to Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, Compact Disc Read-Only Memory (CD-ROM), magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions.

[0036] A radio communication network architecture such as a Long-Term Evolution (LTE) system, an LTE-Advanced (LTE-A) system, an LTE-Advanced Pro system, or a 5G NR Radio Access Network (RAN) typically includes at least one base station (BS), at least one UE, and one or more optional network elements that provide connection within a network. The UE communicates with the network such as a Core Network (CN), an Evolved Packet Core (EPC) network, an Evolved Universal Terrestrial RAN (E-UTRAN), a 5G Core (5GC), or an internet via a RAN established by one or more BSs.

[0037] A UE may include, but is not limited to, a mobile station, a mobile terminal or device, or a user communication radio terminal. The UE may be a portable radio equipment that includes, but is not limited to, a mobile phone, a tablet, a wearable device, a sensor, a vehicle, or a Personal Digital Assistant (PDA) with wireless communication capability. The UE is configured to receive and transmit signals over an air interface to one or more cells in a RAN.

[0038] The BS may be configured to provide communication services according to at least a Radio Access Technology (RAT) such as Worldwide Interoperability for Microwave Access (WiMAX), Global System for Mobile communications (GSM) that is often referred to as 2G, GSM Enhanced Data rates for GSM Evolution (EDGE) RAN (GERAN), General Packet Radio Service (GPRS), Universal Mobile Telecommunication System (UMTS) that is often referred to as 3G based on basic wideband-code division multiple access (W-CDMA), high-speed packet access (HSPA), LTE, LTE-A, evolved LTE (eLTE) that is LTE connected to 5GC, NR (often referred to as 5G), and / or LTE-A Pro. However, the scope of the present disclosure is not limited to these protocols.

[0039] The BS may include, but is not limited to, a node B (NB) in the UMTS, an evolved node B (eNB) in LTE or LTE-A, a radio network controller (RNC) in UMTS, a BS controller (BSC) in the GSM / GERAN, an ng-eNB in an Evolved Universal Terrestrial Radio Access (E-UTRA) BS in connection with 5GC, a next generation Node B (gNB) in the 5G-RAN, or any other apparatus capable of controlling radio communication and managing radio resources within a cell. The BS may serve one or more UEs via a radio interface. Although the gNB is used as an example in some implementations within the present disclosure, it should be noted that the disclosed implementations may also be applied to other types of base stations.

[0040] The BS may be operable to provide radio coverage to a specific geographical area using multiple cells forming the RAN. The BS may support the operations of the cells. Each cell may be operable to provide services to at least one UE within its radio coverage.

[0041] Each cell (may often referred to as a serving cell) may provide services to one or more UEs within the cell’s radio coverage, such that each cell schedules the DL (and optionally UL resources) to at least one UE within its radio coverage for DL (and optionally UL packet transmissions from the UE). The BS may communicate with one or more UEs in the radio communication system via the cells.

[0042] A cell may allocate sidelink (SL) resources for supporting the Proximity Services (ProSe) or Vehicle to Everything (V2X) services. Each cell may have overlapped coverage areas with other cells.

[0043] In Multi-RAT Dual Connectivity (MR-DC) cases, the primary cell of a Master Cell Group (MCG) or a Secondary Cell Group (SCG) may be referred to as a Special Cell (SpCell). A Primary Cell (PCell) may include the SpCell of an MCG. A Primary SCG Cell (PSCell) may include the SpCell of an SCG. MCG may include a group of serving cells associated with the Master Node (MN), including the SpCell and optionally one or more Secondary Cells (SCells). An SCG may include a group of serving cells associated with the Secondary Node (SN), including the SpCell and optionally one or more SCells.

[0044] As discussed above, the frame structure for NR may support flexible configurations for accommodating various next generation (e.g., 5G) communication requirements, such as Enhanced Mobile Broadband (eMBB), Massive Machine Type Communication (mMTC), and Ultra-Reliable and Low-Latency Communication (URLLC), while fulfilling high reliability, high data rate, and low latency requirements. The Orthogonal Frequency-Division Multiplexing (OFDM) technology in the 3GPP may serve as a baseline for an NR waveform. The scalable OFDM numerology, such as adaptive sub-carrier spacing, channel bandwidth, and Cyclic Prefix (CP), may also be used.

[0045] Two coding schemes may be considered for NR, specifically, Low-Density Parity-Check (LDPC) code and Polar Code. The coding scheme adaption may be configured based on channel conditions and / or service applications.

[0046] At least the DL transmission data, a guard period, and UL transmission data should be included in a transmission time interval (TTI) of a single NR frame. The respective portions of the DL transmission data, the guard period, and the UL transmission data should also be configurable based on, for example, the network dynamics of NR. SL resources may also be provided in an NR frame to support ProSe services or V2X services.

[0047] Any two or more than two of the following paragraphs, (sub)-bullets, points, actions, behaviors, terms, or claims described in the present disclosure may be combined logically, reasonably, and properly to form a specific method.

[0048] Any sentence, paragraph, (sub)-bullet, point, action, behaviors, terms, or claims described in the present disclosure may be implemented independently and separately to form a specific method.

[0049] Dependency, e.g., “based on”, “more specifically”, “preferably”, “in one embodiment”, “in some implementations”, etc., in the present disclosure is just one possible example which would not restrict the specific method.

[0050] In some implementations, all the designs / embodiment / implementations introduced within this disclosure are not limited to be applied for dealing with the problems discussed within this disclosure. For example, the described embodiments may be applied to solve other problems that exist in the RAN of wireless communication systems. In some implementations, all of the numbers listed within the designs / embodiment / implementations introduced within this disclosure are just examples and for illustration, for example, of how the described methods are executed.

[0051] The term “A and / or B” within the present disclosure means “A”, “B”, or “A and B”. The term “A and / or B and / or C” within the present disclosure means “A”, “B”, “C”, “A and B”, “A and C”, “B and C”, or “A and B and C”. The term “A / B” within the present disclosure means “A” or “B”.

[0052] FIG. 1 is a diagram illustrating a multi-carrier scenario, according to an example implementation of the present disclosure. In FIG. 1, the Cell#1 may work as an anchor cell / Cell A in the multi-carrier scenario. In the present disclosure, the Cell A may be defined as the cell which may broadcast its system information (e.g., SIB1, SIB2-SIB5, or other system information) periodically. The Cell#2-Cell#4 may be defined as Network Energy Saving (NES) cells in the present disclosure. The Cell#2-Cell#4 may be operated on different component carriers (e.g., the Cell#2-Cell#4 may operate on the CC#2-CC#4 respectively).

[0053] In some implementations, the (DL / UL) radio coverage of the NES Cells (e.g., Cell#2-Cell#4) may (partially) overlap with the Cell A (e.g., the Cell#1). In some implementations, the (DL / UL) radio coverage of the NES Cells may not overlap with the Cell A for the UE to support the on-demand SIB1 request procedure. In some implementations, the NES Cell may also be known as non-anchor cell, which may mean that the cell may not transmit its system information (e.g., MIB, SIB1, SIB2-SIB5, or other SI) periodically or its system information broadcasting may be limited in a (one shot) time period or a periodical time pattern / cycle.

[0054] FIG. 2 is a diagram illustrating a stand-alone scenario, according to an example implementation of the present disclosure. In some implementations, the Cell A (e.g., the Cell#A) may not overlap with the NES Cell (e.g., the Cell#B) or the overlapped area between the Cell#A and the Cell#B may be neglectable (e.g., in this condition, the UE may only be capable to camp on both the Cell#A and the Cell#B in the overlapped area. In contrast, the UE may need to switch its camped cell from Cell#A to Cell#B or vice versa). In FIG. 2, the Cell#A (e.g., which acts as an anchor cell) and the Cell#B (e.g., which acts as an (non-anchor) NES Cell) may also support network energy saving function.

[0055] In some implementations, the NES Cell may also be configured to support the on-demand SIB1 request procedure associated with the neighbor cells or other cells in the same radio access network. In some implementations, the NES Cell which also supports the SIB1 transmission of other cells (and the SIB1 broadcasting of the NES cell itself) may be defined as a Cell A (for the simplification of discussion, the “Cell A’” may be used in the following discussion). In some implementations, the Cell A’ may also transmit its SIB1 via an on-demand manner (e.g., based on the NES Cell behavior as described in the present disclosure). The Cell A’ may also support the on-demand SIB1 service of other cells in the RAN.I In some implementations, a “NES cell” may be configured as a mode or type to a cell and so the UE may switch between a “NES mode” or “cell A” mode at different timing. In some implementations, both modes may not be activated / implemented to one cell simultaneously.

[0056] In some implementations, both Cell A and Cell A’ may be deployed / configured in a RAN to support on-demand SIB1 service. Some system-level issues may be addressed for the Core Network (CN), the Radio Access Network (RAN), and the User Equipment (UE).

[0057] In some implementations, the UE may need to perform the cell selection procedure (as specified in the 3GPP TS 38.304). In some implementations, the UE may stop performing the cell (re)selection procedure while the UE is performing the on-demand SIB1 request procedure with a target Cell A / NES Cell.

[0058] In some implementations, the UE may stop monitoring high priority frequency carriers (e.g., which have a higher priority than the operating frequency carrier of the camped cell) while performing the on-demand SIB1 request procedure. In some implementations, the UE may apply relaxed measurement rules during the on-demand SIB1 request procedure.

[0059] In some implementations, the UE may interrupt the on-demand SIB1 request procedure if UE re-selects another cell after performing a cell (re)selection procedure. In some implementations, the on-demand SIB1 request timer T3XX may be released after the on-demand SIB1 request procedure is interrupted.

[0060] In a multi-carrier scenario, the UE may initiate the on-demand SIB1 request procedure or may transmit WUS signaling with the Cell#1 (e.g., as illustrated in FIG. 1) for SIB1 reception from the Cell#2-4 (e.g., as illustrated in FIG. 1).

[0061] In some implementations, the UE may stop monitoring the original higher-priority frequency (e.g., the frequency carrier which has a higher priority than the camped Cell A / A’ or the camped NES Cell) for the cell (re)selection procedure during the on-demand SIB1 procedure. In some implementations, the UE may stop monitoring the original higher-priority frequency for the cell (re)selection procedure while requesting the SIB1 of the target NES Cell from the Cell A / A’ or from the target NES Cell itself. In some implementations, UE may not be allowed / enabled to initiate the on-demand SIB1 request procedure during the cell (re)selection procedure. In some implementations, the UE may not be allowed / enabled to initiate the on-demand SIB1 request procedure while monitoring the high-priority (or equivalent-priority) frequency carrier(s) or during the cell (re)selection procedure.

[0062] In some implementations, the serving RAN (e.g., the Cell#1 as illustrated in FIG. 1) may configure the frequency priority or sub-priority values specific to the on-demand SIB1 request procedure or the (Release-19) Network Energy Saving mechanism (e.g., within a part of the on-demand SIB1 request procedure or within the WUS configuration). For example, the specific frequency priority value or sub-priority values associated with the CC#1, CC#2, CC#3, or CC#4 (as illustrated in FIG. 1) may be configured for the on-demand SIB1 request procedure.

[0063] In some implementations, the UE may obtain the frequency priority or sub-priority values for frequency carriers involved in the on-demand SIB1 request procedure via broadcasting system information. The system information may be broadcasted by the Cell A (e.g., the Cell#1 as illustrated in FIG. 1) or by the NES Cell). In some implementations, the UE may obtain the frequency priority or sub-priority values for frequency carriers involved in the on-demand SIB1 request procedure via UE-specific control signaling (e.g., the RRCRelease message or the RRCReconfiguration message).

[0064] Regarding the (Release-19) NES / on-demand SIB1 request procedure (e.g., parameters related to frequency priority or sub-priority values provided via the RRCRelease messages, such as the cellReselectionPriorities), a specific validity timer may also be configured within the same RRCRelease message. The specific validity timer may define the validity time period for the configurations related to the (Release-19) NES functionality or on-demand SIB1 request procedure.

[0065] In some implementations, the UE may stop the cell reselection procedure while performing the on-demand SIB1 request procedure (e.g., while the on-demand SIB1 request timer (T3XX) is counting or before the on-demand SIB1 request timer expires).

[0066] In some implementations, the UE may need to camp on the Cell_A / A’ before transmitting the on-demand SIB1 request message or during the on-demand SIB1 request procedure. In some implementations, the UE may consider the frequency of a concerned Cell A / A’ as having the highest frequency priority while performing the on-demand SIB1 request procedure with the concerned Cell A / A’.

[0067] In some additional implementations, the UE may resume / recover / reuse the original frequency prioritization rules after the on-demand SIB1 request procedure is terminated (e.g., after the expiration of the on-demand SIB1 request timer).

[0068] In some implementations, the UE may perform the measurement relaxation procedure (e.g., based on the RAN configuration or the technical specification definition or the UE implementation) during the on-demand SIB1 request procedure.

[0069] In some implementations, the serving RAN may provide an explicit NES_SIB1 modification instruction to the UE to further define UE behavior when the stored SIB1 becomes invalid. In some implementations, the NES_SIB1 modification instruction may include a state (e.g., “pending” state or “update” state). In some implementations, the UE may stay in the RRC idle / inactive state without initiating the on-demand SIB1 request procedure if the UE is configured with “pending” state. The UE may initiate the on-demand SIB1 request procedure after the stored SIB1 becomes invalid if the UE is configured with “update” state by the NES_SIB1 modification instruction.

[0070] In some implementations, after receiving the NES_SIB1 modification instruction from the serving RAN, UE may determine the timing of the WUS transmission within a given time period (e.g., the UE may perform a random selection within the given time period).

[0071] In some implementations, the SIB1 modification instruction may be provided and transmitted by the NES Cell via the PBCH (e.g., via one or more IEs contained in the MIB). In some implementations, the SIB1 modification instruction may be provided and transmitted by the Cell A via broadcasting control signaling (e.g., via broadcasting system information), UE-specific control signaling, or groupcast control signaling.

[0072] In some implementations, the UE may initiate the on-demand SIB1 request procedure to the serving RAN immediately after the stored SIB1 becomes invalid. In some implementations, the UE may initiate the on-demand SIB1 request procedure to the serving RAN within a gap time period before the stored SIB1 becomes invalid. In such a case, the UE may know the valid period of the stored SIB1. For example, the valid period may be a default period, and it may start upon the UE receives the target SIB1 from the serving RAN. In some implementations, the UE may initiate the on-demand SIB1 request procedure to the serving RAN within gap time period before / after the stored SIB1 becomes invalid. In this case, the gap time period may be (randomly) determined by the UE or serving RAN within a duration.

[0073] FIG. 3 is a diagram illustrating an on-demand SIB1 request procedure, according to an example implementation of the present disclosure. The on-demand SIB1 request procedure may be divided into several steps (e.g., as illustrated in FIG. 3).

[0074] Step A: WUS configuration, which may include combinations of Step A-1 and Step A-2. Step A-1: WUS configuration_NES transmission (from the NES Cell) and WUS configuration_NES reception (at the UE side). Step A-2: WUS configuration_A transmission (from the Cell A) and WUS configuration_A reception (at the UE side).

[0075] In some implementations, the UE may be able to receive the WUS configurations from the NES Cell (e.g., via the WUS configuration_NES reception) and WUS configuration from the Cell A (e.g., via the WUS configuration_A reception). The UE may store both the WUS configuration from the NES Cell and the WUS configuration from the Cell A. In some implementations, the UE may only store a WUS configuration received via the WUS configuration_NES reception or the WUS configuration_A reception even if the UE is capable of receiving both WUS configurations. In some implementations, the UE may only choose to store the latest / up to date WUS configuration, and a new WUS configuration (e.g., received via the WUS configuration_NES reception or the WUS configuration_A reception) may overwrite a stored WUS configuration (e.g., received via the WUS configuration_NES or the WUS configuration_A). In some implementations, the UE may always only receive and store the WUS configuration from a network node (e.g., the NES Cell or the Cell A). In some implementations, different priorities may be provided to the WUS configuration from different network nodes.

[0076] Step B: On-Demand SIB1 Request, which may include combinations of Step B-1 and Step B-2. Step B-1: WUS Transmission_NES transmission (from the UE to the NES Cell) and WUS Transmission_NES reception (at the NES Cell). Step B-2: WUS Transmission_A transmission (from the UE to Cell A) and WUS Transmission_A reception (at Cell A).

[0077] In some implementations, the UE may be able to transmit one or more WUSs to the NES Cell (e.g., via the WUS Transmission_NES transmission) and / or one or more WUSs to the Cell A (e.g., via the WUS Transmission_A transmission). In some implementations, a WUS transmission (e.g., on a common uplink radio resource) from the UE may be detectable by both NES Cell and Cell A. In addition, both nodes may exchange their detection results via a backhaul connection to support / trigger NES Cells in broadcasting the SIB after receiving a UE’s request. In some implementations, one common configuration may be shared among more than one Cell A / Cell A’ / NES Cell.

[0078] In some implementations, the WUS configuration may include the Wake-Up-Signal configuration (e.g., which may be referred to as one or more preambles as specified in the 3GPP specifications) and / or uplink resource configuration (e.g., which may be referred to as the RACH configuration as specified in the 3GPP specifications).

[0079] Step C: On-Demand SIB1 Response, which may include combinations of Step C-1 and Step C-2. Step C-1: WUS Response_NES transmission (from the NES Cell to the UE) and WUS Response_NES reception (at the UE side). Step C-2: WUS Response_A transmission (from the Cell A to the UE) and WUS Response_A reception (at the UE side).

[0080] In some implementations, the UE may be configured with the DL resource (e.g., based on the Random Access Response message reception during a (2-step / 4-step) RA procedure as specified in the 3GPP TS) to receive the WUS message. The WUS message may be part of the WUS Response_NES reception or WUS Response_A reception.

[0081] In some implementations, the UE may monitor the WUS Response based on the Random Access Response (RAR) reception (e.g., the UE may try to monitor and decode DCI within a given time period TWUS after transmitting the WUS. The DCI may be scrambled by a RA-RNTI or another WUS-RNTI, which may be specified for the on-demand SIB1 request procedure. In some implementations, the UE may determine the duration of the TWUS based on the Random Access Response window time period).

[0082] Step D: On-Demand SIB1 Transmission, which may include combinations of Step D-1 and Step D-2. Step D-1: SIB1 Transmission_NES_transmission (from the NES Cell to UE) and SIB1 Transmission_NES reception (at the UE side). Step D-2: SIB1 Transmission_A transmission (from the Cell A to the UE) and SIB1 Transmission _A reception (at the UE side).

[0083] In some implementations, an on-demand SIB1 procedure may (not) include all of the indicated steps as illustrated in FIG. 3. For example, the NES Cell / Cell A may not transmit the on-demand SIB1 response to the UE after receiving the on-demand SIB1 request message from the UE. In some implementations, the NES Cell / Cell A may transmit the on-demand SIB1 to the UE directly (e.g., via broadcasting system information of the NES Cell / Cell A).

[0084] In some other implementations, the NES Cell / Cell A may transmit a NACK message to the UE if the on-demand SIB1 request message is not successfully received. In such a case, the on-demand SIB1 transmission may not occur.

[0085] In some implementations, the UE may be configured with an “on-demand SIB1 request timer (T3XX)”. In addition, the UE may start counting the “on-demand SIB1 request timer (T3XX)” down to zero while / upon / after the UE transmits the WUS to the Cell A or the (target) NES Cell (e.g., as illustrated in Step B of FIG. 3). The timer may be started upon the first WUS transmission while retransmissions, repetitions, or multiple WUS transmissions are performed during the on-demand SIB1 request procedure. In some implementations, the UE may continue counting the “on-demand SIB1 request timer (T3XX)” down to zero unless the UE receives one (or more) ACK response or receives the target SIB1 from the serving RAN (e.g., the Cell A / NES Cell). The T3XX may be stopped upon performing Step C or Step D). Otherwise, the UE may determine that the ongoing on-demand SIB1 request procedure has failed upon the T3XX expires.

[0086] In some implementations, after the UE has transmitted one (or more) WUS(s) (e.g., the WUS#1) to a target Cell A (e.g., the Cell#1 as illustrated in FIG. 1) or a target NES Cell (e.g., the NES Cell#2 as illustrated in FIG. 1) to request the SIB1 (of the target NES Cell#2) transmission, the UE may be allowed / enabled to transmit one (or more) WUS(s) (e.g., the WUS#2) to the target Cell A (e.g., the Cell#1 as illustrated in FIG. 1) or another NES Cell (e.g., the NES Cell#3 as illustrated in FIG. 1) to request the SIB1 (of the target NES Cell#3) before the UE receives a WUS response for the WUS#1 or before the UE receives the SIB1 of NES Cell#2. In other words, the UE may be enabled to initiate two (or more) on-demand SIB1 request procedures associated with different target NES Cells in parallel. Multiple on-demand SIB1 request procedures may be (partially) overlapped in time domain (e.g., more than one T3XX may be counting independently and in parallel). In some implementations, the UE may only be enabled to perform an on-demand SIB1 request procedure associated with a target Cell A / NES Cell, while multiple on-demand SIB1 request procedures towards different Cell A(s) / NES Cell(s) may be enabled / allowed. In some implementations, the maximum number of independent on-demand SIB1 request procedures may be pre-defined by the technical specification or be configured by the RAN.

[0087] In some implementations, while the UE initiates an on-demand SIB1 request procedure associated with a target NES Cell#2, the UE may also trigger an on-demand SIB1 request timer to prevent the UE from transmitting too many WUS for the same target NES SIB1 request (e.g., a Prohibit Timer#1 associated with the Cell#2 may be triggered by the UE upon the first WUS#1 is transmitted by the UE to prevent the UE from requesting the SIB1 of the Cell#2 too frequently within a short time period). In some implementations, while the UE initiates an on-demand SIB1 request procedure associated with another target NES Cell#3, the UE may also trigger an on-demand SIB1 request timer to prevent the UE from transmitting too many WUS for the same target NES SIB1 request (e.g., a Prohibit Timer#2 associated with the Cell#3 may be triggered by the UE upon the first WUS#2 is transmitted by the UE). The UE may re-initiate another on-demand SIB1 request procedure for the SIB1 of the Cell#2 only after the Prohibit Timer#1 expires.

[0088] The prohibit timer may be released when a cell reselection occurs (e.g., the UE reselects its serving cell from a first serving cell to a second serving cell, where the first serving cell may be the Cell A or the NES Cell involved in the on-demand SIB1 request procedure).

[0089] In some implementations, the UE may not be allowed / enabled to initiate more than one on-demand SIB1 request procedure if they overlap in time domain. In other words, the UE may only be enabled to initiate a WUS transmission or an on-demand SIB1 request procedure only when no other pending on-demand SIB1 request procedure is ongoing (e.g., if there is a pending on-demand SIB1 request procedure, the timer T3XX or the prohibit timer may still be counting).

[0090] In some implementations, after the UE has transmitted one (or more) WUS(s) (e.g., the WUS#1) to a target Cell A (e.g., the Cell#1 as illustrated in FIG. 1) or a target NES Cell (e.g., the NES Cell#2 as illustrated in FIG. 1) to request the SIB1 (of the target NES Cell#2) transmission, the UE may not be allowed / enabled to transmit one (or more) WUS(s) (e.g., the WUS#2) to the same target Cell A (e.g., the Cell#1 as illustrated in FIG. 1) or another NES Cell (e.g., the NES Cell#2 as illustrated in FIG. 1) to request the SIB1 (of another target NES Cell#2) before the UE receives a WUS response for the WUS#1 or before the UE receives the SIB1 of NES Cell#2.

[0091] In some implementations, the UE may be triggered by the NAS layer / NAS entity of the UE to initiate the on-demand SIB1 request procedure / WUS transmission. For example, while the NAS layer determines to initiate a mobile originated (mo) call / service / traffic / slice (e.g., associated with one or more specific NSSAIs), the UE may be triggered by the NAS layer / NAS entity of the UE to initiate the on-demand SIB1 request procedure / WUS transmission. In some implementations, the NAS layer may trigger the AS layer to initiate a Proximity Service, an LTE V2X service (e.g., configured based on the SIB13 transmission from an NR Cell), a NR Sidelink service (e.g., configured based on the SIB12 transmission from an NR Cell), or a (new radio) multi-cast broadcast service (MBS). In such case, the AS layer (e.g., the RRC entity) may be requested / triggered by the NAS layer to initiate the on-demand SIB1 request procedure / WUS transmission.

[0092] In some implementations, the UE may be triggered by the Access Stratum (AS) layer / AS entity (e.g., the Radio Resource Control (RRC) Layer or Radio Resource Control (RRC) entity of the UE) to initiate the on-demand SIB1 request procedure / WUS transmission. For example, while the RRC layer determines to initiate an RRC establishment, an RRC resume procedure, an on-demand SI procedure (e.g., for other SI), or a small data transmission procedure (e.g., CG-SDT or RA-SDT procedure), the RRC layer may initiate the on-demand SIB1 request procedure on RRC entity. In some implementations, the RRC layer may instruct the lower layers (e.g., the MAC layer or the Physical layer) to initiate the on-demand SIB1 request procedure. In some implementations, the MAC entity may trigger an on-demand SIB1 procedure by the UE itself (e.g., when a procedure, such as an SDT procedure, is triggered by the upper layer to the MAC layer but essential configuration is still absent). In this condition, the MAC entity has the responsibility to initiate a (2-step / 4-step) random access procedure for the SIB1 request. The MAC entity may also receive an indicator to stop an OD-SIB1 request procedure if the RRC entity has received the target SIB1 successfully.

[0093] In some implementations, the UE (e.g., the RRC / NAS layer) may be defined / pre-configured (e.g., as specified in the 3GPP technical specification) to initiate the on-demand SIB1 request procedure every time while the UE camps on the NES Cell / Cell and the UE is a NES-capable UE. In addition, the RRC entity may initiate the on-demand SIB1 request procedure without traffic / service requirement. In some implementations, the UE may initiate the on-demand SIB1 request procedure (with NES Cell or Cell A) only while mobile originated traffic / service is triggered in the UE side and the UE is an NES-capable UE.

[0094] To the (Release-19) NES / on-demand SIB1 request procedure (e.g., parameters about frequency priority / sub-priority values provided via RRCRelease messages, such as the cellReselectionPriorities), a specific validity timer may also be configured within the same RRCRelease message to define the validity time period for the (WUS / on-demand SIB1) configurations related to (Release-19) NES functionality or the on-demand SIB1 request procedure. In some implementations, the timer T320 in the 3GPP technical specification may be reused to define the validity timer. The UE may start counting the validity timer down to zero upon / after the UE transitions to the RRC inactive / idle state. Then, the UE may release / remove / drop the stored (WUS / on-demand SIB1) configuration upon the validity timer expires. In some implementations, the initial value of the validity timer may also be configured in (the same) RRCRelease message to the UE. In some implementations, another timer may be provided by the serving RAN to indicate the validity time period of the stored parameters.

[0095] In some implementations, the UE may release the stored configurations related to the (Release-19) NES functionality or the on-demand SIB1 request procedure when the validity timer (e.g., T320) expires.

[0096] In some implementations, the UE may be configured with an “on-demand SIB1 request timer (T3XX)”. In addition, the UE may start counting the “on-demand SIB1 request timer (T3XX)” down to zero while / upon / after the UE transmits the WUS to the Cell A or the (target) NES Cell (e.g., the timer may be started upon the first WUS transmission while retransmissions, repetitions, or multiple WUS transmissions are performed during the on-demand SIB1 request procedure). In some implementations, the UE may continue counting the “on-demand SIB1 request timer (T3XX)” down to zero unless the UE receives one (or more) ACK response or receives the target SIB1 from the serving RAN (e.g., the Cell A / NES Cell).

[0097] The UE may determine that an ongoing on-demand SIB1 request procedure has failed if the T3XX is counted to zero without receiving an ACK / NACK response / SIB1 from the serving RAN. After an on-demand SIB1 request procedure failure event is considered (e.g., due to T3XX expiration), the UE may not re-apply the on-demand SIB1 request procedure (e.g., for a given time period). The duration of the given time period may be configured by the RAN or determined by the UE itself within a value range. In some implementations, the UE may also record the on-demand SIB1 request failure event and report to the serving RAN upon the next connection to the serving RAN (e.g., when the UE transitions to the RRC Connected state).

[0098] In some implementations, the UE may continue counting the “on-demand SIB1 request timer (T3XX)” down to zero unless the UE receives one (or more) MIB(s) from the target NES Cell. The MIB may indicate that the SIB1 will be or is already being broadcast by the target NES Cell (e.g., by decoding the information elements, such as the value of Kssb, contained in the MIB transmitted by the target NES Cell).

[0099] In some implementations, the initial value of the “on-demand SIB1 request timer (T3XX)” may be pre-configured by the Cell A / Cell A’ / NES Cell as part of the WUS configuration / on-demand SIB1 configuration. In some implementations, the initial value of the “on-demand SIB1 request timer (T3XX)” may be configured via broadcasting signaling (e.g., broadcasting system information from Cell A / Cell A’) or via UE-specific control signaling (e.g., via the RRCRelease message transmitted by the serving RAN).

[0100] In some implementations, the UE may interrupt the on-demand SIB1 request procedure when an emergency call is initiated by the upper layers of the UE.

[0101] In some implementations, the counting Timer T3XX may be released upon the cell reselection occurs (e.g., the UE may reselect its serving cell from a first serving cell to a second serving cell, where the first serving cell may be the Cell A or the NES Cell involved in the on-demand SIB1 request procedure) during the on-demand SIB1 request procedure. The Cell#2 may be the NR cell or the E-UTRA cell. In addition, the cell reselection procedure may include an intra-frequency / inter-frequency / inter-RAT / inter-system cell reselection procedure.

[0102] In some implementations, the counting timer T3XX may be released when the UE initiates an RRC procedure (e.g., an RRC Resume procedure, an RRC establishment procedure, an RNAU procedure, or a TAU procedure) with the serving RAN.

[0103] The Timer T3XX may be released upon the cell reselection occurs (e.g., the UE may reselect its serving cell from a first serving cell to a second serving cell, where the first serving cell may be the Cell A or the NES Cell involved in the on-demand SIB1 request procedure) during the on-demand SIB1 request procedure.

[0104] In some implementations, the WUS may be configured as one of the preambles based on the 3GPP technical specification. The UE may count the PREAMBLE_TRANSMISSION_COUNTER+1 for each WUS transmission. If the PREAMBLE_TRANSMISSION_COUNTER reaches preambleTransMax+1 (if preambleTransMax is configured and applied in the RACH configuration / WUS configuration), the UE may report a random access problem to upper layers of the UE. In some implementations, the UE may also report a random access problem (e.g., via an RA failure report with or without an additional indicator reflecting that the failure is related to the on-demand SIB1 request / WUS transmission failure) to the serving RAN upon the next successful connection to the serving RAN.

[0105] In some implementations, the WUS transmission may not be considered as a random access procedure. In this situation, (e.g., based on the 3GPP technical specifications), the UE may not update the PREAMBLE_Transmission_counter+1 for each WUS transmission even if the preamble is used for the WUS transmission. In some implementations, the UE may also not report the random access failure to upper layers even after multiple WUS transmissions have been performed but the UE still fails to obtain the request SIB1 from the NES Cell / Cell A). In other words, the WUS transmission and / or the on-demand SIB1 request procedure may not influence the random access problem reporting to the serving RAN.

[0106] In some implementations, the UE may count a WUS_transmission_counter (with an initial value=0) every time while the UE transmits the WUS (e.g., preamble) to the serving RAN. The UE may determine the on-demand SIB1 request procedure failure when the WUS_transmission_counter reaches a given threshold (e.g., WUS_MAXTransmission) and no WUS response (and / or no requested SIB1) is received by the UE from the serving RAN. In this case, the UE may determine that the on-demand SIB1 request procedure has failed. The UE may stop re-initiating the on-demand SIB1 request procedure / WUS transmission (e.g., for a time period) after the on-demand SIB1 request failure is determined by the UE. The duration of the time period may be determined by the UE or be configured by the RAN within a given value range. In some implementations, the UE may also report the on-demand SIB1 request problem (e.g., via a WUS failure report / on-demand SIB1 failure report) to the serving RAN upon the next successful connection to the serving RAN. The WUS failure report / on-demand SIB1 failure report may be separate from a random access failure report. In some implementations, the UE may report the on-demand SIB1 request problem via UE Assistance Information (UAI). In some implementations, the UE may indicate the availability of the on-demand SIB1 request problem report (e.g., via the UAI transmission or in the RRC message transmission, such as an RRCSetupRequest message / RRCSetupComplete message or an RRCResume message / RRCResumeComplete message). The serving RAN may then request the UE to transmit the on-demand SIB1 request problem report.In some implementations, different NES cells (or each of the NES cells) configured in a WUS configuration may be associated with the same WUS_MAXTransmission value in the WUS configuration. In some implementations, different NES cells (or each of the NES cells) configured in a WUS configuration may be associated with different WUS_MAXTransmission values in the WUS configuration. In some l implementations, a common WUS_MAXTransmission value may be configured (or pre-configured) in the WUS configuration but a specific NES cell may be configured with a different value to overwrite the common WUS_MAXTransmission value.

[0107] In some implementations, a UE may receive a new WUS configuration from the serving RAN while the UE is performing an OD-SIB1 request procedure. In some implementations, the UE may not interrupt the ongoing OD-SIB1 request procedure upon / after the UE has received the new WUS configuration (and so the WUS_transmission_counter may be kept after the UE receives the WUS configuration). In some implementations, the UE may interrupt the ongoing OD-SIB1 request procedure upon / after the UE has received the new WUS configuration (and so the WUS_transmission_counter may be reset to zero after the UE receives the WUS configuration, regardless of whether a new WUS_MAXTransmission is included in the new WUS configuration). In addition, the reset OD-SIB1 request procedure may not be determined as an OD-SIB1 request failure (or RA failure / random access problem) event.

[0108] In some implementations, the WUS failure report or the on-demand SIB1 request failure report may be further associated with other information. Such information may include at least one of the UE ID, the Cell identity, the Physical Cell Identity, the UE location (e.g., the UE positioning information based on 3GPP NR protocols or the non-3GPP technique, such as the GNSS information), and the time stamp.

[0109] In some implementations, the number of WUS_MAXTransmission may also be configured by the serving RAN as part of the WUS configuration or the on-demand SIB1 request configuration.

[0110] In some implementations, the WUS failure report or the on-demand SIB1 request failure report may not be released / removed / dropped due to RRC state transitions (e.g., when the UE transitions from the RRC inactive state to the RRC idle state, from the RRC inactive state to the RRC connected, from the RRC idle state to the RRC connected state, from the RRC connected state to the RRC idle state, or from the RRC connected state to the RRC inactive state). In other words, the UE may keep the stored WUS failure report or the on-demand SIB1 request failure report after the RRC state transitions.

[0111] In some implementations, the UE may inform the serving RAN that the WUS failure report or theon-demand SIB1 failure report is available (e.g., in the RRC message, such as the RRCSetupComplete message, or in the uplink control signaling, such as the UE Assistance Information). The serving RAN may then transmit “a WUS failure report / on-demand SIB1 failure report enquiry message” to request the UE to transmit the WUS failure report or the on-demand SIB1 failure report to the serving RAN. The UE may release the stored WUS failure report or the on-demand SIB1 failure report after the UE transmits the report to the serving RAN.

[0112] In some implementations, the WUS failure report or the on-demand SIB1 failure report may contain the cell identity or the PCI of the concerned NES Cell (e.g., Cell A) where the UE fails to request the SIB1 via the on-demand SIB1 request procedure.

[0113] In some implementations, the UE may not report the random access problem when the on-demand SIB1 request failure event is considered / determined by the UE. In some implementations, the UE may count the number of WUS transmissions (e.g., by adding PREAMBLE_TRANSMISSION_COUNTER+1 for each WUS transmission) and report the random access problem when the on-demand SIB1 request failure even is considered / determined by the UE.

[0114] In some implementations, the MAC entity / PHY layer of the UE may initiate the WUS transmission (e.g., the preamble transmission) when the RA procedure is initiated or during the (2-step / 4-step) RA procedure. In some implementations, the UE may be enabled to initiate the RA procedure during the on-demand SIB1 request procedure.

[0115] In some implementations, the on-demand SIB1 request procedure may not be determined as the RA procedure. In some implementations, the UE may not be allowed / enabled to initiate the on-demand SIB1 request procedure during the active (2-step / 4-step) RA procedure (e.g., a RA procedure for legacy UE behavior, such as initial access).

[0116] In some implementations, the WUS transmission or the on-demand SIB1 request procedure may be determined as the random access procedure. In some implementations, the UE may be able to initiate the RA procedure to replace / overwrite the ongoing on-demand SIB1 request procedure. In this case, the running timer T3XX may also be released / interrupted by the RA procedure.

[0117] In some implementations, the WUS transmission may not be determined as the random access procedure. Therefore, if the on-demand SIB1 request procedure is not terminated successfully (e.g., if the UE fails to obtain at least one ACK / NACK message after transmitting a WUS, if UE fails to obtain at least one ACK / NACK message before the timer T3XX expires, or if the UE fails to receive the target SIB1 before the timer T3XX expires), UE may not count this event as part of the random access problem.

[0118] In some implementations, the UE may record the on-demand SIB1 failure event in its records.

[0119] The UE may count the number of on-demand SIB1 request procedure failure events associated with a target NES Cell. In addition, the UE may abandon the attempt to obtain the SIB1 of the target NES Cell (e.g., for a given time period T) if the number of on-demand SIB1 request procedure failure events reaches a given maximum threshold value.

[0120] In some implementations, the (RRC Inactive) UE may initiate the RAN notification area update procedure. The UE may be triggered to initiate the on-demand SIB1 request procedure for the RANU with the target NES Cell (e.g., when the RNAU timer T380 expires) and the UE may not have the valid SIB1 associated with the target NES Cell.

[0121] In some implementations, the UE may be pre-defined / configured to initiate the on-demand SIB1 request procedure before the T380 expires. In some implementations, the UE may be defined / pre-configured to obtain the valid SIB1 earlier than a given offset time period (T_delta) before the T380 expires. The value T_delta may be configured by the serving RAN or pre-defined in the 3GPP TS.

[0122] In some implementations, the UE may not be required to perform the RNAU with the NES Cell (e.g., even if the timer T380 expires while the UE is camping on the NES Cell or leaves the stored RAN Notification Area) if the UE does not obtain the SIB1 of the NES Cell yet (or even if the UE has a stored valid version of its camping NES Cell). In contrast, the UE may perform the RNAU procedure the next time while the UE reselects another Cell (e.g., the another cell may be the Cell A or the NES Cell which the UE has stored a valid SIB1 of the NES Cell).

[0123] In some implementations, the UE may be triggered to initiate the on-demand SIB1 request procedure for the RNAU only if the UE does not have the valid SIB1. In contrast, the UE may not initiate the on-demand SIB1 request procedure for the RNAU. The UE may determine whether to initiate the RNAU (e.g., with the associated NES Cell) based on the stored SIB1.

[0124] In some implementations, the RNAU may be triggered by the RRC entity, and the on-demand SIB1 request procedure may be initiated by the MAC entity or the RRC entity.

[0125] In some implementations, if the UE fails to perform the RNAU procedure because the UE cannot obtain the valid SIB1 (e.g., due to the on-demand SIB1 request procedure failure or the UE does not obtain the valid on-demand SIB1 configuration / WUS configuration), the UE may transition from the RRC Inactive state to the RRC idle state. In some implementations, the UE (inactive) context may also be released accordingly.

[0126] In some implementations, the NES Cell may not support the RNAU (e.g., by default). Therefore, the RANU timer may be stopped / released if the UE moves to or reselects a NES Cell. In some implementations, the UE may stop or postpone (a one-shot or periodical) RNAU procedure while camping on the NES Cell (where the NES Cells may be pre-defined not to support the RNAU functionality). In this case, the UE may suspend the RNAU until next selection to another cell that supports the RNAU (e.g., which may be the Cell A or the NES Cell). In addition, if a periodical PNAU procedure is stopped by the UE (or the UE determines not to trigger / start a periodical RNAU timer), the periodical timer associated with periodical RNAU procedure may also be stopped (or may not be started) by the UE.

[0127] In some implementations, the (RRC Idle) UE may initiate a Tracking area update (TAU) procedure. The UE may be triggered to initiate the on-demand SIB1 request procedure for the TAU procedure with the target NES Cell.

[0128] In some implementations, the UE may be triggered to initiate the on-demand SIB1 request procedure for the TAU only if the UE does not have a valid SIB1. In contrast, the UE may not initiate the on-demand SIB1 request procedure for the TAU if the UE already has stored a valid SIB1 (e.g., while the UE moves from the Cell A to the target NES Cell, and the UE may already obtain the SIB1 of the target NES Cell from the serving RAN). The UE may determine whether to initiate the TAU (e.g., with a NES Cell) based on the stored SIB1.

[0129] In some implementations, the TAU may be triggered by the NAS layer, and the on-demand SIB1 request procedure may be initiated by the MAC entity or the RRC entity.

[0130] In some implementations, if the UE fails to perform the TAU procedure due to the lack of a valid SIB1 (e.g., the on-demand SIB1 request procedure failure or the UE does not obtain the valid on-demand SIB1 configuration / WUS configuration), the UE may transition from the RRC Inactive state to the RRC idle state after the UE determines to initiate the TAU. In some implementations, the UE (inactive) context may also be released accordingly.

[0131] In some implementations, the NES Cell may not support the TAU. Therefore, the UE may not initiate the TAU procedure with NES Cells.

[0132] In some implementations, the UE (e.g., the AS layer of the UE) may report a “TAU failure event” to the NAS layer if the UE cannot perform the TAU with the NES Cell due to the absence of a valid SIB1 of the NES Cell. In some implementations, the UE may further indicate a cause of the TAU failure event as “No Valid SIB1” in the report to the NAS layer.

[0133] In some implementations, the failure cause “No Valid SIB1” may also be (re)used in other scenarios, such as the RA failure report, the RNAU failure report, or the mobility failure report.

[0134] FIG. 4 is a flowchart illustrating a method / process 400 performed by a UE for managing an on-demand (OD)-system information block 1 (SIB1) request procedure, according to an example implementation of the present disclosure.

[0135] In the action 402, the process 400 may start by receiving, from a first cell, a wake-up signal (WUS) configuration including a threshold. In the action, 404, the process 400 may initiate, based on the WUS configuration, the OD-SIB1 request procedure. The OD-SIB1 request procedure may include the action 406 to the action 416. In the action 406, the process 400 may transmit, to a second cell, a WUS for requesting an SIB1. In the action 408, the process 400 may determine whether a response associated with the WUS is received from the second cell. In the action 410, the process 400 may receive, from the second cell, the SIB1 after determining that the response is received from the second cell. In the action 412, the process 400 may retransmit, to the second cell, the WUS after determining that the response is not received from the second cell. In the action 414, the process 400 may determine whether the OD-SIB1 request procedure has failed. In the action 416, the process 400 may determine that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

[0136] In some implementations, the UE may forgo initiating a second OD-SIB1 request procedure for a time period after determining that the OD-SIB1 request procedure has failed. In some implementations, the UE may forgo initiating a cell reselection procedure during the OD-SIB1 request procedure. In some implementations, the UE may forgo initiating a random access procedure or a second OD-SIB1 request procedure after transmitting the WUS and before receiving the response.

[0137] In some implementations, the OD-SIB1 request procedure may include starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell, and stopping the timer upon receiving the response from the second cell. In some implementations, the OD-SIB1 request procedure may include determining, based on the timer, whether the OD-SIB1 request procedure has failed, and determining that the OD-SIB1 request procedure has failed upon the timer expires.

[0138] In some implementations, the WUS configuration may configure one or more network energy saving (NES) cells for the UE, the second cell may be selected by the UE from the one or more NES cells, and the threshold or the timer may be applied to the one or more NES cells. In some implementations, the WUS configuration may configure one or more network energy saving (NES) cells for the UE, the second cell may be selected by the UE from the one or more NES cells, and each of the one or more NES cells may be configured with a different threshold or a different timer.

[0139] In some implementations, the UE may notify, by a lower layer of the UE, an upper layer of the UE that the number of retransmissions of the WUS is equal to the threshold, and interrupt, by the upper layer of the UE, the OD-SIB1 request procedure. In some implementations, the UE may camp on a third cell during the OD-SIB1 request procedure, and interrupt the OD-SIB1 request procedure upon camping on the third cell. In some implementations, the OD-SIB1 request procedure may include starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell, and stopping the timer upon interrupting the OD-SIB1 request procedure.

[0140] In some implementations, the UE may initiate, based on the WUS configuration, the OD-SIB1 request procedure while the UE is in a radio resource control (RRC) connected state, stay in the RRC connected state during the OD-SIB1 request procedure, and transition from the RRC connected state to an RRC idle state after determining that the OD-SIB1 request procedure has failed.

[0141] In some implementations, the UE may record a failure event associated with the OD-SIB1 request procedure after determining that the OD-SIB1 request procedure has failed, and then report the failure event to a serving radio access network (RAN).

[0142] The steps / actions shown in FIG. 4 should not be construed as necessarily order dependent. The order in which the process is described is not intended to be construed as a limitation. Moreover, some of the actions shown in FIG. 4 may be omitted in some implementations and one or more actions shown in FIG. 4 may be combined.

[0143] The technical problem addressed by the method illustrated in FIG. 4 is how to efficiently manage the OD- SIB1 request procedure in a UE while ensuring reliable acquisition of SIB1 information from a second cell, particularly in scenarios where an initial request may not be successfully received or acknowledged. Conventional approaches may lead to excessive signaling overhead or unnecessary energy consumption if the UE persistently retries without an effective mechanism to determine failure conditions. The method provides an advantageous technical effect by introducing a wake-up signal (WUS) configuration with a threshold-based retransmission mechanism, which allows the UE to systematically retry the OD-SIB1 request while limiting unnecessary retransmissions. This improves the efficiency of the procedure by reducing redundant signaling and optimizing energy consumption, ensuring that the UE can reliably obtain SIB1 while minimizing network and device resource usage.

[0144] FIG. 5 is a flowchart illustrating a method / process 500 performed by a BS for managing an on-demand (OD)-system information block 1 (SIB1) request procedure, according to an example implementation of the present disclosure.

[0145] In the action 502, the process 500 may start by transmitting, via a first cell, a wake-up signal (WUS) configuration that configures a user equipment (UE) to initiate the OD-SIB1 request procedure and includes a threshold for determining whether the OD-SIB1 request procedure has failed. During the OD-SIB1 request procedure, the process 500 may include the action 504 to the action 510. In the action, 504, the process 500 may receive, via a second cell, a WUS for requesting an SIB1. In the action 506, the process 500 may determine whether to transmit a response associated with the WUS via the second cell. In the action 508, the process 500 may transmit, via the second cell, the SIB1 after transmitting the response via the second cell. In the action 510, the process 500 may monitor, on the second cell, the WUS retransmitted by the UE. In some implementation, the BS may monitor, on the second cell, the WUS retransmitted by the UE after determining not to transmit the response.

[0146] The method illustrated in FIG. 5 is similar to that in FIG. 4, except that it is described from the perspective of the BS (instead of the UE).

[0147] FIG. 6 is a block diagram illustrating a node 600 for wireless communication in accordance with various aspects of the present disclosure. As illustrated in FIG. 6, a node 600 may include a transceiver 620, a processor 628, a memory 634, one or more presentation components 638, and at least one antenna 636. The node 600 may also include a radio frequency (RF) spectrum band module, a BS communications module, a network communications module, and a system communications management module, Input / Output (I / O) ports, I / O components, and a power supply (not illustrated in FIG. 6).

[0148] Each of the components may directly or indirectly communicate with each other over one or more buses 640. The node 600 may be a UE or a BS that performs various functions disclosed with reference to FIGS. 4 through 5.

[0149] The transceiver 620 has a transmitter 622 (e.g., transmitting / transmission circuitry) and a receiver 624 (e.g., receiving / reception circuitry) and may be configured to transmit and / or receive time and / or frequency resource partitioning information. The transceiver 620 may be configured to transmit in different types of subframes and slots including, but not limited to, usable, non-usable, and flexibly usable subframes and slot formats. The transceiver 620 may be configured to receive data and control channels.

[0150] The node 600 may include a variety of computer-readable media. Computer-readable media may be any available media that may be accessed by the node 600 and include volatile (and / or non-volatile) media and removable (and / or non-removable) media.

[0151] The computer-readable media may include computer-storage media and communication media. Computer-storage media may include both volatile (and / or non-volatile media), and removable (and / or non-removable) media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or data.

[0152] Computer-storage media may include RAM, ROM, EPROM, EEPROM, flash memory (or other memory technology), CD-ROM, Digital Versatile Disks (DVD) (or other optical disk storage), magnetic cassettes, magnetic tape, magnetic disk storage (or other magnetic storage devices), etc. Computer-storage media may not include a propagated data signal. Communication media may typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanisms and include any information delivery media.

[0153] The term “modulated data signal” may mean a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Communication media may include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above listed components should also be included within the scope of computer-readable media.

[0154] The memory 634 may include computer-storage media in the form of volatile and / or non-volatile memory. The memory 634 may be removable, non-removable, or a combination thereof. Example memory may include solid-state memory, hard drives, optical-disc drives, etc. As illustrated in FIG. 6, the memory 634 may store a computer-readable and / or computer-executable instructions 632 (e.g., software codes) that are configured to, when executed, cause the processor 628 to perform various functions disclosed herein, for example, with reference to FIGS. 4 through 5. Alternatively, the instructions 632 may not be directly executable by the processor 628 but may be configured to cause the node 600 (e.g., when compiled and executed) to perform various functions disclosed herein.

[0155] The processor 628 (e.g., having processing circuitry) may include an intelligent hardware device, e.g., a Central Processing Unit (CPU), a microcontroller, an ASIC, etc. The processor 628 may include memory. The processor 628 may process the data 630 and the instructions 632 received from the memory 634, and information transmitted and received via the transceiver 620, the baseband communications module, and / or the network communications module. The processor 628 may also process information to send to the transceiver 620 for transmission via the antenna 636 to the network communications module for transmission to a CN.

[0156] One or more presentation components 638 may present data indications to a person or another device. Examples of presentation components 638 may include a display device, a speaker, a printing component, a vibrating component, etc.

[0157] In view of the present disclosure, it is obvious that various techniques may be used for implementing the disclosed concepts without departing from the scope of those concepts. Moreover, while the concepts have been disclosed with specific reference to certain implementations, a person of ordinary skill in the art may recognize that changes may be made in form and detail without departing from the scope of those concepts. As such, the disclosed implementations are to be considered in all respects as illustrative and not restrictive. It should also be understood that the present disclosure is not limited to the particular implementations disclosed and many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.

Claims

1. A user equipment (UE) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure, the UE comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to at least one processor and storing one or more computer-executable instructions that, when executed by the at least one processor, cause the UE to: 　　　　　　　　receive, from a first cell, a wake-up signal (WUS) configuration comprising a threshold; and 　　　　　　　　initiate, based on the WUS configuration, the OD-SIB1 request procedure, wherein the OD-SIB1 request procedure comprises: 　　　　　　　　　　　　transmitting, to a second cell, a WUS for requesting an SIB1; 　　　　　　　　　　　　determining whether a response associated with the WUS is received from the second cell; 　　　　　　　　　　　　receiving, from the second cell, the SIB1 after determining that the response is received from the second cell; 　　　　　　　　　　　　retransmitting, to the second cell, the WUS after determining that the response is not received from the second cell; 　　　　　　　　　　　　determining whether the OD-SIB1 request procedure has failed; and 　　　　　　　　　　　　determining that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

2. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　forgo initiating a second OD-SIB1 request procedure for a time period after determining that the OD-SIB1 request procedure has failed.

3. The UE of claim 1, wherein the OD-SIB1 request procedure further comprises: 　　　　starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell; and 　　　　stopping the timer upon receiving the response from the second cell.

4. The UE of claim 3, wherein the OD-SIB1 request procedure further comprises: 　　　　determining, based on the timer, whether the OD-SIB1 request procedure has failed; and 　　　　determining that the OD-SIB1 request procedure has failed upon the timer expires.

5. The UE of claim 3, wherein: 　　　　the WUS configuration configures one or more network energy saving (NES) cells for the UE, 　　　　the second cell is selected by the UE from the one or more NES cells, and 　　　　the threshold or the timer is applied to the one or more NES cells.

6. The UE of claim 3, wherein: 　　　　the WUS configuration configures one or more network energy saving (NES) cells for the UE, 　　　　the second cell is selected by the UE from the one or more NES cells, and 　　　　each of the one or more NES cells is configured with a different threshold or a different timer.

7. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　notify, by a lower layer of the UE, an upper layer of the UE that the number of retransmissions of the WUS is equal to the threshold; and 　　　　interrupt, by the upper layer of the UE, the OD-SIB1 request procedure.

8. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　camp on a third cell during the OD-SIB1 request procedure; and 　　　　interrupt the OD-SIB1 request procedure upon camping on the third cell.

9. The UE of claim 8, wherein the OD-SIB1 request procedure further comprises: 　　　　starting a timer configured by the WUS configuration upon transmitting the WUS to the second cell; and 　　　　stopping the timer upon interrupting the OD-SIB1 request procedure.

10. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　forgo initiating a cell reselection procedure during the OD-SIB1 request procedure.

11. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　forgo initiating a random access procedure or a second OD-SIB1 request procedure after transmitting the WUS and before receiving the response.

12. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　initiate, based on the WUS configuration, the OD-SIB1 request procedure while the UE is in a radio resource control (RRC) connected state; 　　　　stay in the RRC connected state during the OD-SIB1 request procedure; and 　　　　transition from the RRC connected state to an RRC idle state after determining that the OD-SIB1 request procedure has failed.

13. The UE of claim 1, wherein the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　 record a failure event associated with the OD-SIB1 request procedure after determining that the OD-SIB1 request procedure has failed; and 　　　　 report the failure event to a serving radio access network (RAN).

14. A method performed by a user equipment (UE) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure, the method comprising: 　　　　receiving, from a first cell, a wake-up signal (WUS) configuration comprising a threshold; and 　　　　initiating, based on the WUS configuration, the OD-SIB1 request procedure, wherein the OD-SIB1 request procedure comprises: 　　　　transmitting, to a second cell, a WUS for requesting an SIB1; 　　　　determining whether a response associated with the WUS is received from the second cell; 　　　　receiving, from the second cell, the SIB1 after determining that the response is received from the second cell; 　　　　retransmitting, to the second cell, the WUS after determining that the response is not received from the second cell; 　　　　determining whether the OD-SIB1 request procedure has failed; and 　　　　determining that the OD-SIB1 request procedure has failed in a case that a number of retransmissions of the WUS is equal to the threshold.

15. A base station (BS) for managing an on-demand (OD)-system information block 1 (SIB1) request procedure, the BS comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to at least one processor and storing one or more computer-executable instructions that, when executed by the at least one processor, cause the BS to: 　　　　　　　　transmit, via a first cell, a wake-up signal (WUS) configuration that configures a user equipment (UE) to initiate the OD-SIB1 request procedure and comprises a threshold for determining whether the OD-SIB1 request procedure has failed; and 　　　　　　　　during the OD-SIB1 request procedure: 　　　　　　　　　　　　receive, via a second cell, a WUS for requesting an SIB1; 　　　　　　　　　　　　determine whether to transmit a response associated with the WUS via the second cell; 　　　　　　　　　　　　transmit, via the second cell, the SIB1 after transmitting the response via the second cell; and 　　　　　　　　　　　　monitor, on the second cell, the WUS retransmitted by the UE.

Images