Method and apparatus for handling critical events in wireless communication systems

Abstract

Methods and apparatuses for handling critical events in wireless communication systems are provided. The method includes receiving a Wake-Up Signaling (WUS) configuration, determining that a critical event has occurred, the critical event including at least one of initiating an emergency service, or receiving a public warning alert, and in response to determining that the critical event has occurred, performing, based on the WUS configuration, one of initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and interrupting an ongoing on-demand SIB1 request procedure.

Description

METHOD AND APPARATUS FOR HANDLING CRITICAL EVENTS IN WIRELESS COMMUNICATION SYSTEMS

[0001] The present disclosure is related to wireless communication and, more specifically, to methods and apparatuses for handling critical events in wireless communication systems.

[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) system, 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 increase, however, there exists a need for further improvements in the art.Summery of Invention

[0003] The present disclosure is related to methods and apparatuses for handling critical events in wireless communication systems.

[0004] According to a first aspect of the present disclosure, a User Equipment (UE) is provided. The UE includes at least one processor, and at least one non-transitory computer-readable medium coupled to the 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 a Wake-Up Signaling (WUS) configuration, determine that a critical event has occurred, the critical event including at least one of initiating an emergency service, or receiving a public warning alert, and in response to determining that the critical event has occurred, perform, based on the WUS configuration, one of initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and interrupting an ongoing on-demand SIB1 request procedure.

[0005] In some implementations of the first aspect of the present disclosure, the WUS configuration includes an indicator indicating whether a cell, which is associated with a physical cell identity, supports the emergency service.

[0006] In some implementations of the first aspect of the present disclosure, the WUS configuration includes an indicator indicating whether a Public Land Mobile Network (PLMN) associated with a first PLMN identity, a Standalone Non-Public Network (SNPN) associated with a second PLMN identity, or an area identify associated with a system information area or a tacking area, supports the emergency service.

[0007] In some implementations of the first aspect of the present disclosure, the WUS configuration is associated with at least one cell configured with an on-demand SIB1 function, and the WUS configuration is received by the UE via system information.

[0008] In some implementations of the first aspect of the present disclosure, the WUS configuration includes priority information of carrier frequencies.

[0009] In some implementations of the first aspect of the present disclosure, the on-demand SIB1 request procedure includes transmitting an on-demand SIB request to a cell, and monitoring for an on-demand SIB response from the cell.

[0010] In some implementations of the first aspect of the present disclosure, the WUS configuration includes a cell Discontinuous Reception (DRX) configuration associated with a cell, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to, after initiating the on-demand SIB1 request procedure, transmit, within a cell DRX active duration of a cell DRX cycle of the cell, a WUS to the cell based on the cell DRX configuration.

[0011] In some implementations of the first aspect of the present disclosure, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to, after initiating the on-demand SIB1 request procedure, forgo transmitting, within a Discontinuous Reception (DRX) non-active duration of a cell DRX cycle of a cell, a WUS to the cell.

[0012] In some implementations of the first aspect of the present disclosure, the WUS configuration includes a timer, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to start the timer in a case that the UE initiates the on-demand SIB1 request procedure, and release the timer in a case that the UE interrupts the ongoing on-demand SIB1 request procedure.

[0013] In some implementations of the first aspect of the present disclosure, the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to reselect a cell to camp on after determining that the critical event has occurred, and interrupt the ongoing on-demand SIB1 request procedure after reselecting the cell to camp on.

[0014] According to a second aspect of the present disclosure, a method, performed by a User Equipment (UE), for handling critical services in a wireless communication system is provided. The method includes receiving a Wake-Up Signaling (WUS) configuration, determining that a critical event has occurred, the critical event including at least one of initiating an emergency service, or receiving a public warning alert, and in response to determining that the critical event has occurred, performing, based on the WUS configuration, one of initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and interrupting an ongoing on-demand SIB1 request procedure.

[0015] According to a third aspect of the present disclosure, a Base Station (BS) is provided. The BS includes at least one processor, and at least one non-transitory computer-readable medium coupled to the 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 a Wake-Up Signaling (WUS) configuration to a User Equipment (UE), where the WUS configuration enables the UE, after determining that a critical event has occurred, to perform one of initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and interrupting an ongoing on-demand SIB1 request procedure, and the critical event includes at least one of the UE initiating an emergency service, or the UE receiving a public warning alert.

[0016] In some implementations of the third aspect of the present disclosure, the WUS configuration includes an indicator indicating whether a cell of the BS supports the emergency service.

[0017] In some implementations of the third aspect of the present disclosure, the WUS configuration includes priority information of carrier frequencies.

[0018] In some implementations of the third aspect of the present disclosure, the WUS configuration includes a cell Discontinuous Reception (DRX) configuration.

[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 schematic diagram illustrating a multi-carrier scenario, according to an example implementation of the present disclosure.

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

[0022] FIG. 3 is a schematic diagram illustrating a WUS configuration signaling flow for an emergency call service, according to an example implementation of the present disclosure.

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

[0024] FIG. 5 is a flowchart illustrating method / process 500 for handling critical services in a wireless communication system, according to an example implementation of the present disclosure.

[0025] FIG. 6 is a block diagram illustrating node for wireless communications, in accordance with various aspects of the present disclosure.

[0026] Some of the abbreviations in the present application are defined as follows and, unless otherwise specified, the abbreviations have the following meanings: Abbreviation　　　　　　　　Full name 3GPP　　　　　　　　3rd Generation Partnership Project 5G　　　　　　　　　　　　5th Generation 5GC　　　　　　　　　　　　5G Core ACK　　　　　　　　Acknowledgement AN-PDB　　　　　　　　Access Network Packet Delay Budget ARFCN　　　　　　　　Absolute Radio Frequency Channel Number AS　　　　　　　　　　　　Access Stratum ASN.1　　　　　　　　Abstract Syntax Notation One BFRQ　　　　　　　　Beam Failure Recovery Request BS　　　　　　　　　　　　Base Station BSR　　　　　　　　　　　　Buffer Status Report BWP　　　　　　　　Bandwidth Part C-RNTI　　　　　　　　Cell Radio Network Temporary Identifier CA　　　　　　　　　　　　Carrier Aggregation CAG　　　　　　　　Closed Access Group CB　　　　　　　　　　　　Codebook-Based CC　　　　　　　　　　　　Component Carrier CG　　　　　　　　　　　　Configured Grant CIF　　　　　　　　　　　　Carrier Indicator Field CJT　　　　　　　　　　　　Coherent Joint Transmission CN　　　　　　　　　　　　Core Network CN-PDB　　　　　　　　Core Network Packet Delay Budget CORESET　　　　Control Resource Set CPE　　　　　　　　　　　　Customer Premises Equipment CQI　　　　　　　　　　　　Channel Quality Indication CRC　　　　　　　　Cyclic Redundancy Check CSI　　　　　　　　　　　　Channel State Information CSI-RS　　　　　　　　Channel State Information Reference Signal CS-RNTI　　　　　　　　Configured Scheduling Radio Network Temporary Identifier CSS　　　　　　　　　　　　Common Search Space CU　　　　　　　　　　　　Central Unit DAPS　　　　　　　　Dual Active Protocol Stack DC　　　　　　　　　　　　Dual Connectivity DCI　　　　　　　　　　　　Downlink Control Information DG　　　　　　　　　　　　Dynamic Grant DI　　　　　　　　　　　　Delay Information DL　　　　　　　　　　　　Downlink DL-SCH　　　　　　　　Downlink Shared Channel DMRS　　　　　　　　Demodulation Reference Signal DR　　　　　　　　　　　　Delay Report DRB　　　　　　　　Data Radio Bearer DRX　　　　　　　　Discontinuous Reception DTCH　　　　　　　　Dedicated Traffic Channel DTX　　　　　　　　Discontinuous Transmission DU　　　　　　　　　　　　Distributed Unit ETSI　　　　　　　　European Telecommunications Standards Institute E-UTRA　　　　　　　　Evolved Universal Terrestrial Radio Access EN-DC　　　　　　　　E-UTRA NR Dual Connectivity EPC　　　　　　　　　　　　Evolved Packet Core eMBB　　　　　　　　Enhanced Mobile BroadBand eMTC　　　　　　　　Enhanced Machine Type Communication eNB　　　　　　　　　　　　Evolved Node B FDD　　　　　　　　Frequency Division Duplexing FDRA　　　　　　　　Frequency Domain Resource Allocation FR　　　　　　　　　　　　Frequency Range FR1　　　　　　　　　　　　Frequency Range 1 FR2　　　　　　　　　　　　Frequency Range 2 FWA　　　　　　　　Fixed Wireless Access GEO　　　　　　　　Geostationary Equatorial Orbit gNB　　　　　　　　　　　　Next Generation Node B GNSS　　　　　　　　Global Navigation Satellite System GPS　　　　　　　　　　　　Global Positioning System GW　　　　　　　　　　　　Gateway HARQ　　　　　　　　Hybrid Automatic Repeat Request HO　　　　　　　　　　　　Handover FR　　　　　　　　　　　　Frequency Range IAB　　　　　　　　　　　　Integrated Access and Backhaul ID　　　　　　　　　　　　Identity IE　　　　　　　　　　　　Information Element IoT　　　　　　　　　　　　Internet of Things ITS　　　　　　　　　　　　Intelligent Transportation System ITU　　　　　　　　　　　　International Telecommunication Union L1　　　　　　　　　　　　Layer 1 L2　　　　　　　　　　　　Layer 2 L3　　　　　　　　　　　　Layer 3 LAN　　　　　　　　Local Area Network LCH　　　　　　　　Logical Channel LCID　　　　　　　　Logical Channel Identity LEO　　　　　　　　　　　　Low Earth Orbit LTE 　　　　　　　　Long Term Evolution LSB　　　　　　　　　　　　Least Significant Bit MAC　　　　　　　　Medium Access Control MAC CE　　　　　　　　MAC Control Element MCG　　　　　　　　Master Cell Group MCS　　　　　　　　Modulation and Coding Scheme MEO　　　　　　　　Medium Earth Orbit MIB　　　　　　　　　　　　Master Information Block MIMO　　　　　　　　Multi-Input Multi-Output mMTC　　　　　　　　Massive Machine Type Communications MN　　　　　　　　　　　　Master Node MSG　　　　　　　　Message MTC　　　　　　　　Machine Type Communication NACK　　　　　　　　Negative Acknowledgement NAS　　　　　　　　Non-Access Stratum NB-IoT　　　　　　　　Narrow Band Internet of Things NCB　　　　　　　　Non-Codebook-Based NDI　　　　　　　　　　　　New Data Indicator NES　　　　　　　　　　　　Network Energy Saving NPN　　　　　　　　Non-Public Network NR　　　　　　　　　　　　New Radio NR-U　　　　　　　　NR Unlicensed NTN　　　　　　　　Non-Terrestrial Network OD-SIB1　　　　　　　　On-Demand System Information Block 1 OD-SSB　　　　　　　　On-Demand Synchronization Signal Block PA　　　　　　　　　　　　Power Amplifier PBCH　　　　　　　　Physical Broadcast Channel PCell　　　　　　　　Primary Cell PCI　　　　　　　　　　　　Physical Cell Identity PDB　　　　　　　　　　　　Packet Delay Budget PDCCH　　　　　　　　Physical Downlink Control Channel PDCP　　　　　　　　Packet Data Convergence Protocol PDSCH　　　　　　　　Physical Downlink Shared Channel PDU　　　　　　　　Protocol Data Unit PHY　　　　　　　　Physical PLMN 　　　　　　　　Public Land Mobile Network PMI　　　　　　　　　　　　Precoding Matrix indicator PNI-NPN　　　　　　　　Public Network Integrated Non-Public Network PRACH　　　　　　　　Physical Random Access Channel PSDB　　　　　　　　PDU Set Delay Budget PUCCH　　　　　　　　Physical Uplink Control Channel PUSCH　　　　　　　　Physical Uplink Shared Channel QCL　　　　　　　　Quasi-CoLocation QoS　　　　　　　　　　　　Quality of Service RA　　　　　　　　　　　　Random Access RACH　　　　　　　　Random Access Channel RAN　　　　　　　　Radio Access Network RAR　　　　　　　　Random Access Response RAT　　　　　　　　　　　　Radio Access Technology RE　　　　　　　　　　　　Resource Element Rel-15　　　　　　　　Release 15 Rel-16　　　　　　　　Release 16 Rel-17 　　　　　　　　Release 17 Rel-18　　　　　　　　Release 18 RF　　　　　　　　　　　　Radio Frequency RLC　　　　　　　　　　　　Radio Link Control RS　　　　　　　　　　　　Reference Signal RLF　　　　　　　　　　　　Radio Link Failure RSTD　　　　　　　　Reference Signal Time Difference Measurement RNTI　　　　　　　　Radio Network Temporary Identifier RO　　　　　　　　　　　　RACH Occasion RRC　　　　　　　　Radio Resource Control RRM　　　　　　　　Radio Resource Management RS　　　　　　　　　　　　Reference Signal RSRP　　　　　　　　Reference Signal Received Power RSRQ　　　　　　　　Reference Signal Receiving Quality RV　　　　　　　　　　　　Redundancy Version RX　　　　　　　　　　　　Reception SCell　　　　　　　　Secondary Cell SCG　　　　　　　　　　　　Secondary Cell Group SDT　　　　　　　　　　　　Small Data Transmission SI　　　　　　　　　　　　System Information SIB　　　　　　　　　　　　System Information Block SL　　　　　　　　　　　　Sidelink SLIV　　　　　　　　Start and Length Indicator Value SN　　　　　　　　　　　　Secondary Node SNPN　　　　　　　　Stand-alone Non-Public Network SpCell　　　　　　　　Special Cell SR　　　　　　　　　　　　Scheduling Request SRB　　　　　　　　　　　　Signaling Radio Bearer SRS　　　　　　　　　　　　Sounding Reference Signal SRI　　　　　　　　　　　　SRS Resource Indicator SSB　　　　　　　　　　　　Synchronization Signal Block SSS　　　　　　　　　　　　Secondary Synchronization Signal SUL　　　　　　　　　　　　Supplementary Uplink TA　　　　　　　　　　　　Timing Advance TAG　　　　　　　　　　　　Timing Advance Group TAT 　　　　　　　　Time Alignment Timer TAU　　　　　　　　　　　　Tracking Area Update TB　　　　　　　　　　　　Transport Block TCI　　　　　　　　　　　　Transmission Configuration Indication TDD　　　　　　　　Time Division Duplexing TDRA　　　　　　　　Time Domain Resource Allocation TN　　　　　　　　　　　　Terrestrial Network TPC　　　　　　　　　　　　Transmission Power Control TPMI　　　　　　　　Transmit Precoder Matrix Indication TRP　　　　　　　　　　　　Transmission Reception Point TRS 　　　　　　　　Tracking Reference Signal TRX　　　　　　　　Transmission / Reception TS　　　　　　　　　　　　Technical Specification TX　　　　　　　　　　　　Transmission UCI　　　　　　　　　　　　Uplink Control Information UE　　　　　　　　　　　　User Equipment UL　　　　　　　　　　　　Uplink UL-CG　　　　　　　　Uplink-Configured Grant UPF　　　　　　　　　　　　User Plane Function URLLC　　　　　　　　Ultra-Reliable and Low-Latency Communications USIM　　　　　　　　Universal Subscriber Identity Module USS 　　　　　　　　UE-specific Search Space UTC　　　　　　　　Coordinated Universal Time V2X　　　　　　　　　　　　Vehicle-to-Everything VSAT　　　　　　　　Very Small Aperture Terminal WUS　　　　　　　　Wake-Up Signaling XR　　　　　　　　　　　　Extended Reality

[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 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 shall 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 one implementation,” 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.

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

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

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

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

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

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

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

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

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

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

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

[0042] Each cell (often referred to as a serving cell) may provide services to serve one or more UEs within its 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 plurality of cells.

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

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

[0045] As described above, the frame structure for NR supports 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.

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

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

[0048] Any two or more 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.

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

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

[0051] “A and / or B” in the present disclosure may refer to either A or B, both A and B, or at least one of A and B.

[0052] In this disclosure, “X / Y” may encompass the meanings of “X or Y,” “X and Y,” and “X and / or Y,” as indicated by two or more of the sentences, paragraphs, sub-bullets, points, actions, behaviors, terms, alternatives, aspects, examples, embodiments, or claims described in the following invention(s).

[0053] One aspect of the present disclosure may be applied in various contexts, including communications, communication equipment (such as mobile telephone apparatus, base station apparatus, wireless LAN apparatus, and / or sensor devices), integrated circuits (such as communication chips), and software programs, among others.

[0054] The terms “an antenna port” and “antenna ports,” as discussed in the present disclosure, may refer to “an antenna port used for transmission of PUSCH(s) / PUCCH(s)” and “antenna ports used for transmission of PUSCH(s) / PUCCH(s),” respectively.

[0055] Some of the terms, definitions, and / or abbreviations included in the present disclosure may either be sourced from existing documents (such as those from ETSI, ITU, or other sources) or may be newly created by experts from the 3GPP whenever there was a need for a precise vocabulary.

[0056] Examples of some selected terms in the present disclosure are provided as follows.

[0057] Antenna Panel: A conceptual term for a UE antenna implementation. It may be assumed that a panel may be an operational unit for controlling a transmit spatial filter (beam). A panel may typically include multiple antenna elements. In some implementations, a beam may be formed by a panel, and in order to form two beams simultaneously, two panels may be needed. Such simultaneous beamforming by multiple panels may be subject to the UE capability. A similar definition for “panel” may be applicable by applying spatial receiving filtering characteristics.

[0058] Beam: A beam may include a spatial (domain) filtering. In one example, the spatial filtering may be applied in the analog domain by adjusting a phase and / or amplitude of the signal before being transmitted by a corresponding antenna element. In another example, the spatial filtering may be applied in the digital domain by the Multi-Input Multi-Output (MIMO) technique in the wireless communication system. For example, “a UE made a PUSCH transmission by using a specific beam” may mean that the UE made the PUSCH transmission by using the specific spatial / digital domain filter. The “beam” may also be, but is not limited to be, represented as an antenna, an antenna port, an antenna element, a group of antennas, a group of antenna ports, or a group of antenna elements. The beam may also be formed by a certain reference signal resource. In short, the beam may be equivalent to a spatial domain filter through which the EM wave is radiated. Beam information may include details about the selected or utilized beam or spatial filter. In some implementations, the individual beams (e.g., spatial filters) may be used to transmit individual reference signals. Consequently, a beam or beam information may be represented by one or more reference signal resource indices.

[0059] DCI: DCI may include downlink control information, and there may be various DCI formats used in a PDCCH. The DCI format may be a predefined format in which the downlink control information may be packed / formed and transmitted in a PDCCH.

[0060] TCI state: a TCI state may include parameters for configuring a QCL relationship between one or more DL reference signals and a target reference signal set. For example, a target reference signal set may be the DMRS ports of a PDSCH or a PDCCH.

[0061] HARQ: A functionality that ensures the delivery between peer entities at Layer 1 (e.g., Physical Layer). A single HARQ process may support one Transport Block (TB) when the physical layer is not configured for the downlink / uplink spatial multiplexing, and when the physical layer is configured for downlink / uplink spatial multiplexing, a single HARQ process may support one or more TBs. There may be one HARQ entity per serving cell. Each HARQ entity may support a parallel (number of) DL and UL HARQ process.

[0062] In the present disclosure, although the term “gNB” may have been used throughout the document, it should be understood that the term “gNB” may be replaced by any other type of BS (e.g., an eNB). Additionally, unless specifically noted otherwise, the terms “SSB” and “OD-SSB” may be used interchangeably in the present disclosure.

[0063] A Synchronization Signal Block (SSB) may include, or consist of, a Primary Synchronization Signal (PSS), a Secondary Synchronization Signal (SSS), and a Physical Broadcast Channel (PBCH) payload. The PSS and the SSS may be pseudo-random sequences with a length equal to 127. The PBCH payload may include a Master Information Block (MIB) (24 bits in total) and an 8 bits payload. The information in the MIB may include: a System Frame Number (SFN), a sub-carrier space (SCS), a DeModulation Reference Signal (DMRS) configuration, an Access Control, and mainly a configuration for a System Information Block 1 (SIB1) acquisition. By decoding the PSS and the SSS, a User Equipment (UE) may be able to identify a Physical Cell Identity (PCI) for a corresponding cell and may determine the symbol boundary. Consequently, with the decoding of the PBCH, the UE may determine the frame boundary and may try to decode the Physical Downlink Control Channel (PDCCH).

[0064] In New Radio (NR), to enable beamforming, the SSB patterns may be introduced such that the respective SSBs (with the corresponding space direction) may be transmitted in a time domain (as a transmission pattern). An SSB index may be used to distinguish the SSB and may help the UE determine the frame boundary as well. The next generation NodeB (gNB) may perform beam sweeping across different SSBs and the UE may choose the best SSB (e.g., with the best Reference Signal Receiving Power (RSRP)) to acquire the System Information (SI), the paging reception and may perform a Random Access Channel (RACH) procedure when the UE would like to make a Radio Resource Control (RRC) connection establishment. When decoding the MIB, the UE may know the configuration of the PDCCH which may include a Control Resource Set #0 (CORESET#0) and a Search Space #0 (SS#0), and then the UE may derive an entry of a default table to identify the time / frequency resource where the SIB1 is transmitted. Upon the SIB1 reception, the UE may get the cell (re)selection information, the Public Land Mobile Network Identifier (PLMN ID), the Cell Identifier (ID), and the common serving cell information for upcoming operations.

[0065] In a multi-carrier scenario for an on-demand SIB1 design, an anchor cell may play a pivotal role. FIG. 1 is a schematic diagram illustrating a multi-carrier scenario, according to an example implementation of the present disclosure. As illustrated in FIG. 1, the Cell#1 may serve as the anchor cell, referred to as Cell A in the present disclosure. The Cell A may be defined as a cell that periodically broadcasts the system information, such as the SIB1, the SIB2 through the SIB5, or other system information. In the same figure, the Cell#2 through the Cell#4 may be designated as NES cells, each implemented on different Component Carriers (CCs), such as the CC#2 through the CC#4 respectively. In some implementations, the downlink and uplink radio coverage of the NES cells, such as the Cell#2 through the Cell#4, may partially overlap with the coverage of the Cell A. In other implementations, the radio coverage of the NES cells may not overlap with the coverage of the Cell A, enabling a UE to support an on-demand SIB1 request procedure. In certain implementations, an NES cell may also be referred to as a non-anchor cell, indicating that the cell may not periodically transmit the system information, such as the MIB, the SIB1, the SIB2 through the SIB5, or other system information, or that the broadcasting of the system information may be limited to a one-shot time period or a periodic time pattern or cycle.

[0066] In a stand-alone scenario, the Cell A may function differently with respect to an NES cell. FIG. 2 is a schematic diagram illustrating a stand-alone scenario, according to an example implementation of the present disclosure. As shown in FIG. 2, the Cell#A, acting as the anchor cell, and a Cell#B, functioning as a non-anchor NES cell, may support a network energy-saving function. In some implementations, the coverage of the Cell#A may not overlap with the coverage of the NES cell, or the overlapped area between the Cell#A and the Cell#B may be negligible. Under such conditions, the UE may (only) camp on both the Cell#A and the Cell#B within the overlapped area, or the UE may switch the camped cell from the Cell#A to the Cell#B or from the Cell#B to the Cell#A.

[0067] In some implementations, an NES cell may be configured to support an on-demand SIB1 request procedure associated with neighbor cells or other cells within the same RAN. The present disclosure defines an NES cell that also supports the SIB1 transmission of other cells as the Cell A’. In certain implementations, the Cell A’ may transmit the SIB1 in an on-demand manner, following the NES cell behavior as proposed in the present disclosure. Additionally, the Cell A’ may support the on-demand SIB1 service of other cells in the RAN.

[0068] The designs disclosed herein may be based on the Cell A, though the proposed designs may also apply to the Cell A’. In some implementations, both the Cell A and the Cell A’ may be deployed or configured in the RAN to provide the on-demand SIB1 service. Based on the deployment described above, system-level issues may be addressed for the Core Network (CN), the RAN, and the UE.

[0069] For emergency call services and the delivery of emergency support information, the UE may initiate specific procedures. In some implementations, the UE may be enabled or allowed to initiate an on-demand SIB1 request procedure or a WUS transmission with a target NES cell directly, without prior knowledge or information about the networks supported by the NES cell, if the UE initiates an emergency call, such as through the NAS layer of the UE. In other implementations, the UE may initiate an on-demand SIB1 request procedure or WUS transmission with the target NES cell directly, without knowledge of whether the target NES cell supports emergency call services, such as whether the ims-EmergencySupport IE is enumerated as “true” or the imsEmergencySupportForSNPN IE is enumerated as “true” in the SIB1 of the target NES cell. Alternatively, the UE may need to receive information indicating whether the camped cell supports emergency call services, such as the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE from the target NES cell, before initiating an on-demand SIB1 request procedure.

[0070] In some implementations, the UE may be permitted to initiate emergency call services with an NES cell based on stored information, such as the ims-EmergencySupport IE, the imsEmergencySupportForSNPN IE, or an EmergencySupport_NES IE, derived from a pre-configured, pre-installed, or stored, and valid, SIB1 associated with the NES cell. Conversely, the UE may not be allowed to initiate emergency call services with the NES cell if the stored SIB1 becomes invalid. In certain implementations, the target NES cell may broadcast information indicating whether emergency call services are supported or whether emergency call services through the IP Multimedia Subsystem (IMS) are supported, with such information potentially included in the MIB broadcasted by the UE via the Physical Broadcast Channel (PBCH). For instance, the ims-EmergencySupportMIB IE, enumerated as “true,” or the imsEmergencySupportForSNPNMIB IE, enumerated as “true,” may be provided in the MIB by utilizing one or more reserved or spare bits or by reinterpreting the information elements in the MIB. In other implementations, an EmergencySupport_NESMIB IE may be presented as a single bit in the PBCH or MIB transmitted by the target NES cell to indicate whether the NES cell supports emergency call services. In some cases, the information elements related to emergency service support, such as the ims-EmergencySupportMIB IE, the imsEmergencySupportForSNPNMIB IE, or the EmergencySupport_NESMIB IE, may be provided in the SIB1, allowing the UE to make a decision when, or only when, the UE has stored a valid SIB associated with the camped NES cell.

[0071] By reading the MIB broadcasted by the target NES cell, such as by detecting whether the ims-EmergencySupportMIB IE, the imsEmergencySupportForSNPNMIB IE, or the EmergencySupport_NESMIB IE is provided in the MIB, or whether the ims-EmergencySupport IE, the imsEmergencySupportForSNPN IE, or the EmergencySupport_NES IE is provided in the SIB1, the UE may determine whether an emergency call service can be initiated with the target NES cell or whether the UE should reselect to another cell for emergency call service initiation. In some implementations, the UE may read the MIB broadcasted by the target NES cell to decide whether to initiate an on-demand SIB1 request procedure for an emergency call service, if (or only if) the MIB of the target NES cell indicates that emergency call services are supported. If the ims-EmergencySupportMIB IE, the imsEmergencySupportForSNPNMIB IE, or the EmergencySupport_NESMIB IE is absent or configured as “false,” the UE may trigger a cell selection procedure or a cell reselection procedure to identify a cell that supports emergency call services.

[0072] In some implementations, the UE may attempt to interpret the ims-EmergencySupportMIB IE, the EmergencySupport_NESMIB IE, or the EmergencySupport_NES IE, if (or only if) the UE is an NES-capable UE, the cell is an NES cell, and the UE is not operating in an SNPN access mode. If the UE is not an NES-capable UE, the cell is not an NES cell, or the UE is operating in the SNPN access mode, the UE may ignore these bits in the received MIB. Similarly, the UE may attempt to interpret the imsEmergencySupportForSNPNMIB IE if (or only if) the UE is an NES-capable UE, the cell is an NES cell, and the UE is operating in the SNPN access mode. If these conditions are not met, the UE may ignore the bit in the received MIB.

[0073] The UE may verify whether the camped or selected NES cell supports emergency call services by checking the imsEmergencySupportForSNPNMIB IE when (or only when) operating in the SNPN access mode, or by checking the ims-EmergencySupportMIB IE when (or only when) not operating in the SNPN access mode. In some implementations, the UE may read the EmergencySupport_NESMIB IE to determine whether the camped NES cell supports emergency call services, with the result applicable to both the UE operating in the SNPN access mode and the UE not operating in the SNPN access mode. In certain implementations, the UE may be triggered to transmit a WUS to the target NES cell for SIB1 reception due to specific services, such as an emergency call service or a Public Warning Service. Additionally, the UE may transmit the WUS to the target NES cell for these specific services either before or after deciding to camp on the target NES cell.

[0074] In some implementations, the UE may interrupt, stop, or terminate an on-demand SIB1 request procedure when an emergency call is initiated by the upper layers of the UE. In such cases, an on-demand SIB1 request timer, referred to as T3XX and defined in an appendix, may be released, stopped, or dropped after the upper layers of the UE initiate the emergency call service. Furthermore, an emergency call service with a target Cell A, such as the Cell#1 operating on the frequency carrier CC#1, may interrupt or terminate one or more ongoing on-demand SIB1 request procedures associated with other NES cells on different frequency carriers, such as the Cell#2, the Cell#3, or the Cell#4 operating on the CC#2, the CC#3, or the CC#4 respectively, while the UE is implementing multiple on-demand SIB1 request procedures.

[0075] In some implementations, an emergency call service with a target NES cell, such as the Cell#2 operating on the frequency carrier CC#2, may also interrupt or terminate one or more ongoing on-demand SIB1 request procedures associated with other NES cells on different frequency carriers, such as the Cell#2 or the Cell#3 operating on the CC#2 or the CC#3 respectively, while the UE is implementing multiple on-demand SIB1 request procedures. Additionally, an on-demand SIB1 request procedure may be interrupted or terminated due to the implementation of a cell selection procedure or a cell reselection procedure by the UE. In some cases, the cell selection procedure or the cell reselection procedure may be triggered by the UE due to the initiation of an emergency call service.

[0076] In some implementations, an NES cell may not support an emergency service as a default setting, definition, or configuration established for the NES cell. Under such conditions, a UE may be configured to reselect to another cell, such as a Cell A, to initiate an emergency service call. Consequently, the UE may rule out, skip, or ignore all NES cells during a cell selection procedure or a cell reselection procedure. In some implementations, the UE may assign a low or the lowest priority to a frequency carrier if the highest-ranked cell observed by the UE is an NES cell and the UE is triggered to implement a critical service, such as an emergency call service. The UE may assign the frequency carrier a low or the lowest priority because the NES cell may not support the critical service, such as the emergency call service, according to a default network setting. In certain implementations, the UE may assign a frequency carrier a low or the lowest priority if the highest-ranked cell observed by the UE is an NES cell and an intra-frequency cell selection procedure or cell reselection procedure is prohibited, disabled, or not allowed by a serving RAN via downlink control signaling or indication, such as through system information or UE-specific RRC signaling.

[0077] In some implementations, the UE may obtain knowledge regarding whether an NES cell supports an emergency call service through NES information or configuration provided by the serving RAN, such as from the Cell A or the NES cell. The NES information or configuration may be transmitted via broadcasting system information, such as from the SIB1 or other system information broadcasted by the Cell A, or from the MIB broadcasted by the NES cell. Alternatively, the NES information or configuration may be transmitted as part of a WUS configuration or through one or more UE-specific control signaling, such as an RRC Reconfiguration message or an RRC Release message. In some implementations, the UE may assign a frequency carrier a low or the lowest priority if the highest-ranked cell observed by the UE is an NES cell, the UE is triggered to implement a critical service, such as an emergency call service or a Public Warning Service (PWS), and the NES cell does not support the critical service.

[0078] In some implementations, an NES cell may not support a critical service, such as an emergency call service, as a default or defined setting pre-specified in a technical specification or pre-configured by the serving RAN. In certain implementations, whether an NES cell supports a critical service may vary depending on the networks supported by the NES cell. For each supported network, such as a PLMN or a SNPN, one or more NES_emergency_support indicators may be transmitted by the serving RAN, such as by the Cell A or the NES cell, via broadcasting control signaling or UE-specific control signaling. Each indicator may be associated with one or more network identities supported by the NES cell. In some implementations, the Cell A, which enables UEs to obtain SIBs of one or more NES cells, may have the highest cell selection priority or cell reselection priority, or the frequency carrier on which the Cell A operates may have the highest cell selection priority or cell reselection priority, when the UE decides to initiate an emergency service. In additional implementations, the Cell A or a Cell A’ may have higher or the highest priorities compared to NES cells during a cell selection procedure or a cell reselection procedure when the procedure is triggered due to a critical service, such as an emergency call service.

[0079] In some implementations, the UE may not be allowed or enabled to initiate an on-demand SIB1 request procedure associated with a target Cell A or a target NES cell during a PDU session of a critical service, such as an emergency call PDU session, with the serving RAN and a serving CN. In contrast, the UE may be allowed or enabled to initiate an on-demand SIB1 request procedure while the UE is implementing one or more PDU sessions, which may or may not include PDU sessions of critical services, with the serving RAN and the serving CN. The critical service, as defined in the present disclosure, may include, but is not limited to, an emergency call service, an URLLC service, an Earthquake and Tsunami Warning System (ETWS) or Commercial Mobile Alert System (CMAS) service, and a mission-critical service defined by the RAN and / or the CN. Additionally or altarnatively, each mission-critical service may be associated with one or only one critical event.

[0080] In some implementations, the UE may not be allowed to transmit a WUS to a serving cell, such as the Cell A or an NES cell, during a Cell DRX period of the serving cell. In other implementations, the UE may be allowed to transmit a WUS to the serving cell without being impacted by the Cell DRX period. In certain conditions, one or more additional indicators, such as those included as part of the WUS configuration, may be provided to further configure NES-capable UEs regarding whether the UE is allowed to transmit the WUS to the serving cell. In some implementations, the UE may be allowed to transmit a WUS, preamble, MSG1, MSG3, or MSGA, such as for a 2-step or 4-step random access procedure, to the serving cell when (or only when) the transmission is triggered due to an emergency call service. In additional implementations, an on-demand SIB1 request procedure triggered for a specific critical service with a target cell, such as the Cell A or an NES cell, may be terminated, interrupted, or stopped if the UE can initiate, trigger, or implement an RRC connection or a 2-step or 4-step random access procedure with another cell or the same target cell for the critical service or for other purposes.

[0081] In some implementations, an NES-capable UE compliant with Release 19 may support Cell DTX or Cell DRX operation as a pre-defined or default setting within the UE capability or UE feature set. The mechanisms proposed in the present disclosure may be applied to a multi-carrier scenario and / or a standalone scenario. In some implementations, the UE may interrupt or terminate an on-demand SIB1 request procedure when receiving messages or indications related to a public warning message, such as an ETWS or CMAS warning message, from the serving RAN. Additionally, the UE may receive the SIB1 broadcasted by a target NES cell, the Cell A, or the Cell A’ while implementing an on-demand SIB1 request procedure and may also receive a short message broadcasted by the target NES cell, the Cell A, or the Cell A’, which includes an ETWS or CMAS indication in the broadcasting short messages.

[0082] In some implementations, the UE may monitor or record short messages, paging records, or paging messages associated with a target NES cell, the Cell A, or the Cell A’ while implementing an on-demand SIB1 request procedure with the same target cell. In additional implementations, the UE may monitor or record short messages, paging records, or paging messages associated with a target NES cell, the Cell A, or the Cell A’ while implementing an on-demand SIB1 request procedure with a different Cell A, NES cell, or Cell A’. Under such conditions, an on-demand SIB1 request timer, referred to as T3XX and defined in an appendix, may be released, stopped, or dropped after the UE receives the target SIB1 from the serving RAN. In some implementations, the UE may receive an ETWS or CMAS indication from the serving RAN, such as via short message reception from the serving Cell A or NES cell, leading the UE to stop, interrupt, or terminate the on-demand SIB1 request procedure, with the T3XX timer also being released, stopped, or dropped.

[0083] In some implementations, the UE may interrupt or terminate an on-demand SIB1 request procedure, with the associated T3XX timer being released or stopped, when the UE is triggered to monitor short messages and / or paging records scheduled by short messages. In additional implementations, the UE may interrupt or terminate an on-demand SIB1 request procedure if the UE initiates an RRC procedure, such as an RRC establishment procedure or an RRC resume procedure, after identifying the UE’s own identity in one or more received paging records. In certain implementations, the UE may or may not interrupt or terminate one or more ongoing on-demand SIB1 request procedures while transitioning from an RRC inactive state to an RRC idle state due to paging record reception, such as when receiving a CN paging message. In other implementations, the UE may restart an on-demand SIB1 request procedure during such a transition. The paging monitoring activity may encompass RAN paging and / or Core Network paging.

[0084] When the UE receives short messages and / or monitors paging records transmitted by a camped NES cell or the Cell A based on a stored valid SIB1 containing configurations, such as a DRX cycle configuration for receiving short messages or paging messages, the UE may expect the NES cell to begin broadcasting SIBs and scheduling information of the system information related to a public warning service, such as the SIB6, the SIB7, the SIB8, or the SIB9, immediately upon receiving one or more short messages with the etwsAndCmasIndication bit or indication set to ‘1’. Under such conditions, the UE may also implement an SIB1 update procedure to receive the PWS message accordingly. In some implementations, the target NES cell may broadcast information indicating whether system information related to a public safety service is transmitted, with such information included in the MIB broadcasted by the UE via the Physical Broadcast Channel (PBCH). By reading the MIB broadcasted by the target NES cell, the UE may receive the SIB1 and subsequent system information, such as the SIB6, the SIB7, the SIB8, or the SIB9, immediately. The PWS reception may include the reception of the SIB6, the SIB7, or the SIB8.

[0085] In some implementations, the UE may not need to obtain the SIB1 associated with a target NES cell before initiating an emergency call with the target NES cell, and the UE may camp on the target NES cell without a valid SIB1 of the target NES cell. Instead, the UE may transmit a WUS to the target NES cell to initiate an emergency call service. In certain implementations, one or more WUSs designated for a specific service, such as an emergency call service, may be included as part of the WUS configuration of the NES cell. The UE may obtain the WUS configuration for the emergency call service through assistance from the Cell A, the Cell A’, or an anchor cell via broadcasting system information, such as an NES-SIB configured and broadcasted by the Cell A, the Cell A’, or the NES cell, or via UE-specific control signaling, such as an RRC reconfiguration message or an RRC Release message instructing the UE to transition from an RRC Connected state to an RRC Inactive or Idle state.

[0086] In some implementations, a WUS configuration associated with an emergency call service may not be configured with a specific validity time period. In contrast, a WUS configuration not associated with an emergency service may be configured with a specific validity time period, such as a T320 counting period in an RRC Release message reception. Additionally, a WUS configuration or an on-demand SIB1 request configuration may be associated with one or more specific valid areas, which may be defined by any combination of one or more Physical Cell Identities (PCIs), one or more global cell identities that are globally unique in an associated specific PLMN or SNPN, one or more system information area IDs, one or more zone IDs based on zone configuration for sidelink resource allocation, or one or more physical areas defined by reference to Global Navigation Satellite System (GNSS) point indications. The UE may be enabled to apply the WUS configuration or on-demand SIB1 request configuration when located within the given specific valid areas associated with the configuration, but may not be enabled or allowed to apply the configuration if the UE is not located within those areas or networks.

[0087] In some implementations, a WUS configuration associated with one or more critical services may be explicitly associated with one network, such as by including a network identity in the WUS configuration, where the network may be a PLMN, an SNPN, or a Closed Access Group (CAG), or implicitly associated based on the sequence of networks provided by the serving RAN via a PLMN list or SNPN list. One or more WUS configurations may be associated with the first network identity presented in a network identity list, such as a PLMN-ID list or an SNPN-ID list, provided by the serving RAN. In other implementations, a WUS configuration may be shared among multiple networks explicitly, such as by providing an explicit network ID list in the WUS configuration, or implicitly. A WUS configuration not associated with an emergency call service may be configured with a specific valid area defined similarly to the above, while a WUS configuration associated with an emergency call service may not be configured with a specific valid area and may thus be applicable across the RAN associated with a specific network, such as a PLMN or SNPN.

[0088] In some implementations, a WUS configuration may be applicable to one or more networks, such as a PLMN or SNPN. A WUS configuration specific to an emergency call service may also be applicable to one or more networks. Additionally, one or more specific WUS sequences, such as a preamble defined in a 3GPP technical specification, may be reserved and configured by the serving RAN or defined in the technical specification for emergency services. In some implementations, specific physical uplink resources, such as those referring to a Random Access Channel (RACH) resource configuration or an uplink configured grant configuration in a 3GPP specification, may be pre-configured for the UE as part of the WUS configuration or on-demand SIB1 request configuration. One or more specific physical uplink resources, such as a Physical Random Access Channel (PRACH), may be reserved and configured by the serving RAN or defined in the technical specification for emergency services. Consequently, the UE may transmit an emergency service-specific preamble on the emergency service-specific uplink resources.

[0089] A cell may indicate whether the cell supports an emergency call service. The ims-EmergencySupportMIB IE, included within the MIB, may indicate whether the cell supports IP Multimedia Subsystem (IMS) emergency bearer services for UEs in a limited service mode. If the ims-EmergencySupportMIB IE is absent, the IMS emergency call may not be supported by the network in the cell for UEs in the limited service mode. The ims-EmergencySupportMIB IE, as a bit or indicator, may be transmitted via the MIB of an NES cell or by a Cell A, such as through broadcasting system information or UE-specific RRC control signaling.

[0090] To support an emergency call service within an NES-RAN, the Cell A, a Cell A’, or an anchor cell may transmit the ims-EmergencySupport_NES IE bit associated with one or more NES cells supported by the Cell A, the Cell A’, or the anchor cell for network energy saving or on-demand SIB1 transmission. The ims-EmergencySupport_NES IE, as a bit or indicator, may be transmitted by the Cell A or an NES cell, such as via broadcasting system information or UE-specific RRC control signaling, along with one or more associated NES cells identified by a global cell identity or a Physical Cell Identity (PCI). In some implementations, an ims-EmergencySupport_NES bitmap may be transmitted by the Cell A, with each bit further associated with the NES cells, such as each bit corresponding to a specific NES cell in a list of NES cells supported by the Cell A. The CellBarredNES IE may serve as an indicator configured to inform NES-capable UEs that a specific cell, which may be an NES cell, is barred from UE access, such as for all access attempts or specific service types like normal services. The CellBarredNES IE may be transmitted via the MIB or the SIB1 of the NES cell.

[0091] In some implementations, a UE may initially camp on a cell, such as an anchor cell, the Cell A, a Cell_A, or the Cell A’. In some implementations, an NES Cell which also supports the SIB1 transmission of other cells may be defined as Cell A’ (for the simplification of discussion, the “Cell A’” may be used in the present disclosure). In some additional implementations, the Cell A’ may transmit its own SIB1 via an on-demand manner (e.g., based on the NES Cell behavior as described in the present disclosure) in some periods. Furthermore, the Cell A’ may transmit its own SIB1 continuously without on-demand manner in some other periods. The Cell A’ may also support the on-demand SIB1 service of neighbor NES cells in the RAN by broadcasting the WUS configurations associated with neighbor NES cells. In some implementations, the Cell A’ may broadcast the WUS configurations associated with the neighbor cells while (or only while) the cell A’ is broadcasting the SIB1 of itself. The WUS configuration of the neighbor cells may be provided as other SI (e.g., a SIB_X) by the Cell A / A’. The Cell_A / Cell A’ may be capable of providing system information of neighbor cells observed, detected, or found by the UE. FIG. 1 is a schematic diagram illustrating a multi-carrier scenario, according to an example implementation of the present disclosure. FIG. 2 is a schematic diagram illustrating a stand-alone scenario, according to an example implementation of the present disclosure. The Cell A or the Cell A’, such as the Cell#1 in FIG. 1 or the Cell#A in FIG. 2, may be an accessible cell to the UE, meaning the Cell_A may transmit, deliver, or broadcast the system information to the UE even if the Cell_A is merely an accessible cell. In some implementations, the UE may be allowed to initiate an on-demand SIB1 request procedure, transmit a WUS, or initiate a WUS transmission with an acceptable cell, such as the Cell A or the Cell A’. The UE may be enabled or allowed to initiate the on-demand SIB1 request procedure with an acceptable cell, such as an acceptable Cell A or an acceptable NES cell, under (or only under) special or specified conditions, such as when the UE is configured by the NAS layer to initiate an emergency call service. Otherwise, the UE may not be allowed or enabled to initiate the on-demand SIB1 request procedure with an acceptable cell if the UE is not under such special or specified conditions.

[0092] In some implementations, the UE may determine the cell type of a serving NES cell by referring to a supported network list provided by the Cell A. The Cell A may also provide information regarding whether an NES cell, supported by the Cell A for the on-demand SIB1 request procedure, supports emergency call services. The Cell_A may need to be a suitable cell to the UE for the on-demand SIB1 delivery service. In some implementations, the UE may not be allowed to transmit an on-demand SIB1 request message, such as by using a wake-up signaling waveform identical to a preamble used for a random access procedure in NR / E-UTRA protocols or signaling transmitted via the PUCCH, the PUSCH, or an SR configured by the serving RAN, to a camped cell if the cell is an accessible cell. In additional implementations, the UE may be allowed to transmit the on-demand SIB1 request message to the camped cell if (or only if) the cell is a suitable cell.

[0093] In some implementations, the Cell A or the Cell A’ may be an acceptable cell to the UE, and the UE may still be enabled or allowed to initiate an on-demand SIB1 request procedure associated with the Cell A or the Cell A’. The on-demand SIB1 request procedure may be considered a service that can be supported by an acceptable cell. In certain implementations, the UE may be allowed to initiate the on-demand SIB1 request procedure with an acceptable cell for an emergency call service, and the UE may not be allowed to initiate the on-demand SIB1 request procedure with an acceptable cell for services other than emergency call services. The Cell A may support one or more PLMNs, and an NES cell may also support one or more PLMNs. Both the Cell A or the Cell A’ and the NES cell may deliver, transmit, or broadcast network identities, such as PLMN IDs, supported by the Cell A or the Cell A’ and the NES cell, respectively. However, the UE may not know the networks supported by the NES cell unless the UE obtains the system information of the target NES cell.

[0094] In some implementations, the UE may need to confirm the network supported by a target NES cell before initiating the on-demand SIB1 procedure to request the SIB1 of the target NES cell. To achieve this, the Cell A or the Cell A’ may need to broadcast the network ID, such as a PLMN ID, an SNPN ID, or a Closed Access Group (CAG) ID, supported by one or more NES cells to UEs. In other implementations, the UE may not need to obtain the network IDs, such as the PLMN ID or the SNPN ID, to initiate an on-demand SIB1 request procedure if the UE is triggered to initiate an emergency call service. The ims-EmergencySupport_NES IE bit or indicator may be associated with one or more networks, indicating whether the NES cell(s) belong to a specific network, such as a PLMN or an SNPN. An ims-EmergencySupport_NES bitmap may be transmitted by the Cell A, with each bit further associated with the networks, such as each bit corresponding to a specific PLMN or SNPN in a PLMN ID list or SNPN ID list supported by the Cell A.

[0095] In some implementations, an SNPN access mode on the UE side may refer to a mode of operation where the UE (only) selects SNPNs. The UE may not interrupt or terminate an on-demand SIB1 request procedure upon moving to the SNPN access mode or leaving the SNPN access mode if the on-demand SIB1 request procedure is triggered for emergency services. In some implementations, the Cell A or the Cell A’ may support (only) PLMNs and may not support SNPNs, while at least one or more NES cells may support one or more SNPNs. A UE implementing the SNPN access mode may still be able, configured, allowed, or enabled to camp on the Cell A or the Cell A’ for the on-demand SIB1 request procedure if the Cell A or the Cell A’ does not support SNPNs but supports one or more NES cells that support one or more SNPNs. The Cell A or the Cell A’ may transmit the SNPN ID(s) supported by the one or more NES cells to the UE(s) via broadcasting system information, such as part of a WUS configuration or an on-demand SIB1 configuration associated with one or more NES cells, or via UE-specific control signaling, such as an RRC reconfiguration message or an RRC Release message instructing the UE to move from an RRC Connected state to an RRC Inactive or Idle state. This capability may apply when (or only when) the UE is triggered to initiate an emergency call service.

[0096] In some implementations, a UE not implementing the SNPN access mode may still be able, configured, allowed, or enabled to camp on the Cell A or the Cell A’ for the on-demand SIB1 request procedure if the Cell A or the Cell A’ supports SNPNs but also supports one or more NES cells that support one or more PLMNs. The Cell A or the Cell A’ may transmit the PLMN ID(s) supported by the one or more NES cells to the UE(s) via broadcasting system information, such as part of a WUS configuration or an on-demand SIB1 configuration associated with one or more NES cells, or via UE-specific control signaling, such as an RRC reconfiguration message or an RRC Release message. This capability may apply when (or only when) the UE is triggered to initiate an emergency call service. In some implementations, the UE may temporarily ignore whether the UE is implementing the SNPN access mode during the on-demand SIB1 request procedure if the UE is triggered to initiate an emergency call service. The mechanisms proposed in the present disclosure may be applicable for an emergency call service.

[0097] In some implementations, the Cell A may have a higher cell selection priority or cell reselection priority than an NES cell if the UE is triggered to initiate an emergency call service. Cells A that support emergency call services via IMS and assist the UE in implementing the on-demand SIB1 request procedure may have a higher cell selection priority or cell reselection priority if the UE needs to implement a cell selection procedure or a cell reselection procedure for an emergency call service. NES cells that support emergency call services, whether via IMS or not, may have a higher cell selection priority or cell reselection priority if the UE needs to implement a cell selection procedure or a cell reselection procedure for the on-demand SIB1 request procedure and emergency call services. In some implementations, the UE may need to implement an access control mechanism, such as the Unified Access Control (UAC) mechanism, to the Cell A before transmitting WUS signaling to the Cell A or initiating an on-demand SIB1 request procedure. The emergency call service may be further associated with one or more specific access categories and access identities for UAC when the UAC mechanism is implemented for the on-demand SIB1 request procedure.

[0098] In some implementations, the UE may not know the cell type, such as whether the cell is an accessible cell or a suitable cell, of an NES cell before successfully obtaining the system information, such as the SIB1. In such conditions, the UE may automatically consider the NES cell as an acceptable cell before obtaining the target SIB1 associated with the target NES cell. In other implementations, the UE may obtain the networks supported by an NES cell via the assistance of another cell, such as the Cell#1 as an anchor cell in FIG. 1, allowing the UE to understand or decide the cell type of the NES cell relative to the UE. The UE may initiate an SIB1 on-demand request procedure associated with the target NES cell, such as by transmitting WUS directly to the NES cell, if (or only if) the target NES cell is a suitable cell to the UE, requiring the UE to know the networks supported by the NES cell, such as PLMN ID(s), SNPN ID(s), or CAG ID(s), beforehand.

[0099] In some implementations, the UE may initiate an on-demand SIB1 request procedure associated with the target NES cell, such as by transmitting WUS directly to the NES cell, when the target NES cell is an acceptable cell to the UE, regardless of whether the UE knows the networks supported by the NES cell beforehand. This mechanism may be configured, enabled, or allowed (only) for emergency call services. In certain implementations, the UE may initiate the on-demand SIB1 request procedure without information about the networks supported by the target NES cell, and this mechanism may be configured, enabled, or allowed (only) for emergency call services. After obtaining the SIB1 associated with the target NES cell, the UE may decide or identify whether the target NES cell is an acceptable cell or a suitable cell to the UE. The UE may initiate the SIB1 on-demand request procedure associated with the Cell A or the Cell A’, such as the Cell#1 in FIG. 1, and may subsequently determine that the UE is barred by the NES cell for a time period after receiving the SIB1.

[0100] In some implementations, the UE may be allowed or configured to transmit an on-demand SIB1 request to the Cell_A and / or an NES cell. The NES cell may be an acceptable cell to the UE, and the UE may still be enabled or allowed to initiate an on-demand SIB1 request procedure associated with the NES cell directly or via the assistance of the Cell A or the Cell A’. The on-demand SIB1 request procedure may be considered a service that can be supported by an acceptable cell, and this mechanism may be configured, enabled, or allowed (only) for emergency call services. The mechanisms proposed in the present disclosure may be applicable (only) for an emergency call service.

[0101] In some implementations, a UE may need to obtain the SIB1 associated with a target NES cell before the UE initiates an emergency call with the target NES cell. In other implementations, the UE may be enabled or allowed to initiate an on-demand SIB1 request procedure with the target NES cell directly, without prior knowledge or information about the networks supported by the NES cell, if the UE initiates an emergency call, such as through a Non-Access-Stratum layer of the UE. In certain implementations, the UE may not need to obtain the SIB1 associated with the target NES cell before initiating the emergency call with the target NES cell. Instead, the UE may transmit a WUS designated for an emergency call service to the target NES cell to initiate the emergency call service.

[0102] In some implementations, one or more WUSs may be designated for a specific service, such as the emergency call service, as part of a WUS configuration of the NES cell. The UE may obtain the WUS configuration for the emergency call service through assistance from a Cell A, a Cell A’, or an anchor cell. The UE may acquire the WUS configuration specific to the emergency call service via broadcasting system information, such as an NES-SIB configured and broadcasted by the Cell A, the Cell A’, or the NES cell, or via UE-specific control signaling, such as an RRC reconfiguration message or an RRC Release message, which instructs the UE to transition from an RRC Connected state to an RRC Inactive or Idle state. The SIB1 may be broadcasted immediately by a serving RAN if the serving RAN receives a WUS for the emergency call.

[0103] FIG. 3 is a schematic diagram illustrating a WUS configuration signaling flow for an emergency call service, according to an example implementation of the present disclosure. As shown in FIG. 3, in action 302, the UE may first receive a WUS configuration configured for the emergency call service from the NES cell. In some implementations, the NES cell may transmit the WUS configuration for the emergency call service. The emergency call service proposed in the present disclosure may encompass an emergency call service that may or may not be configured via an IP Multimedia Subsystem (IMS). In action 304, the UE may perform an emergency call initiation. In action 306, the UE may then transmit one or more WUSs specified for the emergency call service to the serving RAN (e.g., including the NES cell). In action 308, the UE may receive a WUS Response message from the NES cell. In action 310, the UE may then transmit an RRC establishment request to the NES cell. In action 312, the UE may perform the emergency call service with the NES cell.

[0104] In some implementations, the UE may expect to monitor a MIB and obtain a target SIB1 immediately without waiting for a WUS Response message from the serving RAN or without monitoring the WUS Response message from the serving RAN. In some implementations, the UE may need to monitor the WUS Response message from the serving RAN if the procedure is not triggered by the emergency call service, such as for a normal mobile-originated service.

[0105] In some implementations, a WUS transmission may be implemented by the UE via an MSG1 transmission, such as by referring to a conventional 4-step random access procedure. The UE may transmit a preamble, which may be configured by the serving RAN and / or selected by the UE as a wake-up signal for an on-demand SIB1 request procedure and / or a critical service, in the MSG1 for the on-demand SIB1 request. After receiving the preamble (MSG1) from the UE, a serving cell, such as the Cell A or the NES cell, may reply with an acknowledgment (ACK) response message to the UE for the on-demand SIB1 request message. The ACK response message may be scrambled by a Random Access Radio Network Temporary Identifier (RA-RNTI), reusing the conventional random access procedure for ACK response message reception. In other implementations, the ACK response message may be transmitted via a Downlink Control Information (DCI) scrambled by an On-Demand-SIB1-RNTI, which may be defined by a technical specification for the on-demand SIB1 request procedure.

[0106] In some implementations, the ACK response message for the on-demand SIB1 request procedure may further include information such as a time instance, referred to as Time Instance A, at which the UE may expect the NES cell to start broadcasting the SIB1, such as the location of a symbol, subframe, mini-slot, slot, or radio frame in a time domain. The Time Instance A may be pre-defined by the technical specification, such as the first symbol, radio frame, subframe, or slot that the UE may receive after receiving the ACK response message. The ACK response message may also include a time instance, referred to as Time Instance B, at which the UE may expect the target NES cell to continue broadcasting the requested SIB1, and a time span, such as the duration between the Time Instance A and the Time Instance B, during which the UE may expect the target NES cell to maintain broadcasting the requested SIB1, expressed in units of N symbol(s), subframe(s), mini-slot(s), slot(s), radio frame(s), or hyperframe(s) in the time domain.

[0107] In some implementations, the UE may not receive the ACK response message, such as after a Random Access Response (RAR) window monitoring period. Under this condition, the UE may be enabled to transmit the preamble again or transmit another preamble for the on-demand SIB1 request procedure. A maximum number of failure attempts, such as a threshold Thre.SIB1, may be limited by the serving RAN via a dedicated configuration, and the UE may consider itself barred by the target NES cell or the Cell A for WUS transmission or the on-demand SIB1 request procedure after the accumulated number of failure attempts reaches the Thre.SIB1. After receiving the ACK response message from the serving RAN, the UE may attempt to monitor and decode the MIB broadcasted by the serving cell, which may indicate the presence of the broadcasting SIB1, such as the location of coreset_0 in a Physical Resource Block (PRB) domain associated with the SIB1 transmission. The RAR message or ACK response message may also include uplink grant information for the UE to transmit an RRCSetupRequest message or an RRCResumeRequest message for the critical service, such as the emergency call service, and the UE may transmit such a message after receiving the RAR message.

[0108] In some implementations, the WUS transmission may be implemented by the UE via an MSG3 transmission, such as by referring to a conventional 4-step random access procedure. The UE may transmit a preamble, configured by the serving RAN and / or selected by the UE as a wake-up signal for the on-demand SIB1 request procedure and / or a critical service, in the MSG1 for the on-demand SIB1 request. After receiving the preamble (MSG1) from the UE, the serving cell, such as the Cell A or the NES cell, may reply with an RAR message to the UE as a response to the preamble transmission. The RAR message may include uplink grant information for the UE to transmit an RRCSetupRequest message or an RRCResumeRequest message for the critical service, such as the emergency call service. Alternatively, the RAR message may include uplink grant information for the UE to transmit an On-demand SIB1 Request message, such as an MSG3-based WUS transmission, for the on-demand SIB1 request procedure. The UE may transmit the On-demand SIB1 Request message to the serving RAN via the received uplink grant, implementing an MSG3-based on-demand SIB1 request procedure.

[0109] After receiving the On-demand SIB1 Request message (MSG3) from the UE, the serving cell, such as the Cell A or the NES cell, may reply with an ACK response message to the UE for the on-demand SIB1 request message, such as by referring to an MSG4 reception step in a 4-step random access procedure. The ACK response message may be scrambled by the RA-RNTI, reusing the conventional random access procedure, or transmitted via a DCI scrambled by the On-Demand-SIB1-RNTI defined by the technical specification. The UE may include a UE-autonomously-selected random value as a temporary Cell Radio Network Temporary Identifier (C-RNTI) in the on-demand SIB1 request message. The serving RAN may include the received temporary C-RNTI in the ACK response message, enabling the UE to implement contention resolution by comparing the transmitted temporary C-RNTI at MSG3 transmission with the received temporary C-RNTI at MSG4 reception. The UE may consider the on-demand SIB1 request attempt unsuccessful if the two RNTI values do not match, and successful if the values match.

[0110] In some implementations, the ACK response message for the on-demand SIB1 request procedure may include the Time Instance A, the Time Instance B, and the time span as described earlier. If the UE does not receive the ACK response message, such as after the RAR window monitoring period, the UE may consider the current on-demand SIB1 request attempt unsuccessful and may be enabled to transmit the preamble again or transmit another preamble for the on-demand SIB1 request procedure. After receiving the ACK response message from the serving RAN, the UE may attempt to monitor and decode the MIB broadcasted by the serving cell, indicating the presence of the broadcasting SIB1.

[0111] In some implementations, the serving RAN may configure whether the UE should implement an MSG1-based or an MSG3-based on-demand SIB1 request procedure for a target NES cell. Different NES cells may support the MSG1-based and / or the MSG3-based on-demand SIB1 request procedure, and the serving RAN may need to provide a cell ID, such as a Physical Cell Identity (PCI) or a global cell identity, along with the supported on-demand SIB1 request procedure type. The association information may be transmitted via system information, such as the SIB1 or other system information of the Cell A, or via UE-specific control signaling, such as an RRCRelease message or an RRCReconfiguration message, or as part of the WUS configuration. The UE may initiate an MSG1-based or an MSG3-based on-demand SIB1 request procedure associated with the Cell A or the NES cell. In additional implementations, the choice between the MSG1-based and the MSG3-based on-demand SIB1 request procedure may be decided or triggered based on an event, such as whether the procedure is for an emergency call service.

[0112] In some implementations, a 2-step on-demand SIB1 request procedure may be configured by the serving RAN for SIB1 delivery. The UE may transmit an MSGA, which includes the WUS and one or more uplink control signalings, such as an RRC Resume Request message, an RRC Setup Request message, an RRC Re-establishment Request message, or an on-demand SIB1 request message, in a single uplink transmission to the serving RAN for the SIB1 request. After receiving the MSGA from the UE, the serving RAN may reply with an MSGB to the UE. The MSGB may include any combination of the requested SIB1 and an MSGA Response message, such as an RRC message including an RRC Setup message, an RRC Re-establishment message, or an RRC Resume message, to the UE. The WUS and uplink resources specified for the 2-step on-demand SIB1 request procedure may also be configured by the serving RAN as part of the WUS configuration.

[0113] In some implementations, the 2-step on-demand SIB1 request procedure may be enabled by the serving RAN via the WUS configuration, and UEs not configured with the WUS configuration associated with the 2-step on-demand SIB1 request procedure may not be allowed or enabled to implement the 2-step on-demand SIB1 request procedure. The 2-step on-demand SIB1 request procedure may be configured (only) for a specific service, such as the emergency call service. The requested SIB1 and the MSGA Response message may be transmitted by the serving RAN in a single downlink transmission occasion, such as via a single downlink UE-specific control signaling. Alternatively, the requested SIB1 may be transmitted via a broadcasting approach, while the MSGA Response message may be transmitted in a UE-specific downlink assignment to the UE.

[0114] An eCall Only Mode may refer to a configuration option for a UE that allows the UE to register at a 5G Core (5GC) and register in an IP Multimedia Subsystem (IMS) to perform only an eCall Over IMS, as well as a non-emergency IMS call for test and / or terminal reconfiguration services. In some implementations, an NES cell may support UEs operating in the eCall Only Mode, such as through a default setting pre-defined in a technical specification or pre-configured by a serving RAN. A UE may transmit a WUS, such as a preamble, to a target NES cell directly for an emergency call service via the IMS.

[0115] In some implementations, an NES cell may or may not support the eCall Only Mode, and a serving network may further configure or transmit the information to the UE via broadcasting signaling, such as through the SIB1, other system information, or a WUS configuration, or via UE-specific control signaling. An eCall Only Mode support indicator may be configured by the serving RAN with one or more associated NES cell identities, such as a Physical Cell Identity (PCI) or a cell identity. In certain implementations, the UE may be enabled or allowed to initiate an emergency call service with a target NES cell even when the UE is in any cell selection state while camping on the NES cell.

[0116] In some implementations, the UE may transition from an RRC inactive state to an RRC idle state before initiating an emergency call service or an emergency Protocol Data Unit (PDU) session with a target NES cell. In other implementations, a UE in the RRC inactive state may be able to initiate an emergency call service with the target NES cell while remaining in the RRC inactive state. In some implementations, an NES-capable UE may receive a barring indication from an NES cell, such as the CellBarred IE set to ‘barred’, which may be transmitted via a MIB transmission. Under this condition, the NES-capable UE may still consider the NES cell as a campable cell before obtaining the SIB1 of the NES cell. The UE may decide or may be enabled to initiate a random access (RA) procedure, such as by a Medium Access Control (MAC) layer, associated with the NES cell for a mobile-originated (mo) service, which may be limited to an emergency call service.

[0117] In some implementations, the UE may obtain the SIB1 of the target NES cell, such as via an on-demand SIB1 request procedure, and may find that the NES cell is barred to NES-capable UEs, as indicated by an additional indicator, the CellBarredNES IE, transmitted by the NES cell via the SIB1 transmission with the CellBarredNES IE set to ‘barred’ for NES-capable UEs. Under this condition, the UE may cancel a running RA procedure associated with the target NES cell. However, the UE may not cancel a pending RA procedure if the RA procedure is initiated for a specific purpose, such as an emergency call service. The UE may further check whether the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE is provided in the received SIB1, and may cancel a pending RA procedure initiated or triggered for an emergency service if the EmergencySupport IE or the imsEmergencySupportForSNPN IE is absent in the received SIB1.

[0118] In some implementations, the MAC entity of the UE may determine that a triggered or pending RA procedure is for an emergency call service based on UE implementation. In other implementations, an RRC entity in the UE may inform the MAC entity that an RA procedure is associated with an emergency call service. In certain implementations, an NES-capable UE may receive a barring indication from an NES cell, such as the CellBarredNES IE set to ‘Not barred’, transmitted via the SIB1 transmission. Under this condition, the NES-capable UE may consider the NES cell as a campable, acceptable, or suitable cell for an emergency call (eCall) service, and may not refer to the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE in the SIB1, even if both are absent or provided.

[0119] In some implementations, only a non-NES-capable UE may decide whether a cell is barred from an emergency call service by jointly considering the CellBarred IE from the MIB reception and the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE from the SIB1 reception. An NES-capable UE may receive a barring indication from an NES cell, such as the CellBarredNES IE set to ‘barred’, transmitted via the SIB1 transmission. Under this condition, the NES-capable UE may consider the emergency call service as barred by the NES cell and may not refer to the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE in the SIB1, even if both are absent or provided. In additional implementations, the NES cell, base station, eNB, or gNB may not transmit the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE if the CellBarredNES IE is provided and indicates ‘barred’, meaning the UE may not expect to receive these IEs in the SIB1 reception under such conditions.

[0120] In some implementations, an NES-capable UE may ignore the CellBarred IE transmitted by an NES cell and may decide whether the cell is barred based on the decoding result of the CellBarredNES IE, the ims-EmergencySupport IE, or the imsEmergencySupportForSNPN IE during the SIB1 reception. Conversely, a non-NES-capable UE may decide that the NES cell is barred to the UE, even for the emergency call service, based on the CellBarred IE transmitted via the MIB. The UE may be pre-defined or configured, such as in a technical specification, to attempt decoding or receiving the CellBarredNES IE first, followed by the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE, during the SIB1 decoding, such as when the UE is triggered to initiate an emergency call service.

[0121] In some implementations, an NES-capable UE may receive a barring indication from an NES cell, such as the CellBarredNES IE set to ‘barred’, indicating that the NES cell is barred from normal services, with the CellBarredNES IE transmitted via the SIB1 transmission. If the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE is provided in the SIB1, indicating that the emergency call service is supported and not barred, the NES-capable UE may still consider the NES cell as a campable or acceptable cell for the emergency call (eCall) service, though the NES cell may be barred from normal or non-emergency call services. In other scenarios, if the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE is absent or indicates “not supported” or “barred”, the NES-capable UE may consider both normal services and the emergency call service as barred by the NES cell.

[0122] In some implementations, an NES-capable UE may receive a barring indication from an NES cell, such as the CellBarredNES IE set to ‘not barred’, transmitted via the SIB1 transmission. If the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE is absent or indicates “not supported” or “barred”, the NES-capable UE may still consider the emergency call service as barred by the NES cell. Conversely, if the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE is provided in the SIB1, indicating that the emergency call service is supported and not barred, the NES-capable UE may consider the emergency call service as not barred by the NES cell. The UE may refer to the ims-EmergencySupport IE when the NES cell supports a PLMN or the imsEmergencySupportForSNPN IE when the NES cell supports a Stand-alone Non-Public Network (SNPN), based on whether the UE is implementing SNPN access mode, as per 3GPP NR protocols.

[0123] In some implementations, an NES-capable UE may receive a barring indication from an NES cell, such as the CellBarredNES IE set to ‘barred’, transmitted via the SIB1 transmission, and may consider the NES cell as a campable or acceptable cell for the emergency call (eCall) service. The UE may decide or may be enabled to initiate an RA procedure, such as by the MAC layer, associated with the NES cell for a mobile-originated service, which may be limited to the emergency call service. After obtaining the SIB1 of the target NES cell via an on-demand SIB1 request procedure and finding that the NES cell is barred to NES-capable UEs via the CellBarredNES IE, the UE may cancel a running RA procedure associated with the target NES cell. However, the UE may not cancel a pending RA procedure if initiated for the emergency call service, and may further check the presence of the ims-EmergencySupport IE or the imsEmergencySupportForSNPN IE in the received SIB1, canceling the procedure if these IEs are absent.

[0124] In some implementations, a non-NES-capable UE may not succeed in establishing or resuming an RRC connection to a target RAT, such as a new radio, or a target RAN due to the target RAT or RAN implementing an NES mode, such as when a serving cell is an NES cell, and / or because the UE is non-NES-capable. A fallback mechanism may be triggered by the UE directly or instructed by the serving RAN via UE-specific control signaling or broadcasting control signaling, such as broadcasting system information, an SI on-demand procedure, or a group PDCCH transmission. Under this condition, the UE may receive a MobilityFromNRCommand message set to E-UTRA, prompting the UE to start a cell selection procedure or a cell reselection procedure aimed at finding a suitable E-UTRA cell.

[0125] In some implementations, a UE, such as a non-NES-capable UE, may not succeed in establishing, resuming, or maintaining a RRC connection to a target RAT, such as an NR, or a target RAN due to the target RAT or RAN implementing or preparing to operate in an NES mode, such as when a serving cell may switch to the NES mode, and / or the UE may become a non-NES-capable UE. This condition may occur when a non-NES-capable UE establishes an RRC connection with a serving cell that is not operating in the NES mode, and subsequently, the serving cell may switch the operation mode from non-NES mode to NES mode. Under such circumstances, the UE may receive a MobilityFromNESCommand message, which may be set to a target RAT, such as E-UTRA and / or NR. After receiving the MobilityFromNESCommand message, the UE may initiate a cell selection procedure or a cell reselection procedure aimed at identifying a suitable E-UTRA cell of the RAT indicated by the MobilityFromNESCommand message.

[0126] If a suitable E-UTRA cell is selected, or if no suitable E-UTRA cell is available and an acceptable E-UTRA cell supporting an emergency call is selected while the UE has an ongoing emergency call, the UE may perform actions upon transitioning to an E-UTRA RRC idle state with an NR RRC Release cause, such as ‘RRC Connection Failure’, ‘RRC Connection Failure due to NES mode switch of serving RAN and of UE’, or ‘NES’. However, if the UE does not find a suitable E-UTRA cell, the UE may revert to a configuration used in an original source Primary Cell (PCell) and then may initiate an NR RRC connection re-establishment procedure with a re-establishment cause, such as ‘NES mode switch of RAN / UE’. In some implementations, a non-NES-capable UE may fail to maintain an RRC connection, such as while the UE remains in an RRC Connected state, or resume an RRC connection, such as while the UE remains in an RRC inactive state, associated with a suitable serving cell or serving RAN due to an R-19 NES mode operation switch. The UE may release the NR RRC connection with a release cause, such as ‘RRC Connection Failure’, ‘R-19 NES failure’, ‘on-demand SIB1 failure’, or ‘on-demand SSB failure’, and may trigger an RRC re-establishment procedure with another NR or E-UTRA cell, including a re-establishment cause in an RRCRe-establishmentRequest message, such as ‘RRC Connection Failure’, ‘R-19 NES failure’, ‘on-demand SIB1 failure’, or ‘on-demand SSB failure’.

[0127] In some implementations, a non-NES-capable UE may fail to maintain an RRC connection, such as while remaining in the RRC Connected state, or resume an RRC connection, such as while remaining in the RRC inactive state, associated with a suitable serving cell or serving RAN due to the R-19 NES mode operation switch. The UE may record and report a ‘Radio Link Failure Report’, such as ‘NES operation switch’, in such cases.

[0128] FIG. 4 is a schematic diagram illustrating an on-demand SIB1 request procedure, according to an example implementation of the present disclosure. As shown in FIG. 4, the on-demand SIB1 request procedure may be divided into several steps, starting with Step A. This step may include WUS configuration_NES transmission from an NES cell and WUS configuration_NES reception at the UE side in action 402, as well as WUS configuration_A transmission from a Cell A and WUS configuration_A reception at the UE side in action 404. The UE may be capable of receiving WUS configurations from the NES cell via WUS configuration_NES reception and from the Cell A via WUS configuration_A reception, storing both configurations. Alternatively, the UE may store (only) one WUS configuration, received either via WUS configuration_NES reception or WUS configuration_A reception, despite being capable of receiving both. The UE may opt to store (only) the latest or most up-to-date WUS configuration, allowing a new WUS configuration reception to overwrite a previously stored WUS configuration, or may always store the WUS configuration from a single network node, such as the NES cell or the Cell A, with different priorities potentially assigned to WUS configurations from different network nodes as detailed in subsequent paragraphs.

[0129] Step B of the on-demand SIB1 request procedure may involve an On-Demand SIB1 Request. For example, Step B may include WUS Transmission_NES transmission from the UE and WUS Transmission_NES reception at the NES cell in action 408, as well as WUS configuration_A transmission from the Cell A and WUS configuration_A reception at the UE side in action 410. The UE may transmit one or more WUSs to the NES cell via a WUS Transmission_NES procedure and one or more WUSs to the Cell A. In some implementations, a single WUS transmission on a common uplink radio resource from the UE may be detectable by both the NES cell and the Cell A.

[0130] Step C may involve an On-Demand SIB1 Response. For example, Step C may include WUS Response_NES transmission from the NES cell and WUS Response_NES reception at the UE side in action 410, alongside WUS Response_A transmission from the Cell A and WUS Response_A reception at the UE side in action 412.

[0131] Step D may involve an On-Demand SIB1 Transmission. For example, Step D may include SIB1 Transmission_NES transmission from the NES cell and SIB1 Transmission_NES reception at the UE side in action 414, as well as SIB1 Transmission_A transmission from the Cell A and SIB1 Transmission_A reception at the UE side in action 416. An on-demand SIB1 procedure may not include all indicated steps shown in FIG. 4. For instance, the NES cell or the Cell A may not reply with an On-Demand SIB1 Response to the UE after receiving an On-Demand SIB1 Request message, instead directly transmitting the On-Demand SIB1 to the UE. Alternatively, the NES cell or the Cell A may reply with a negative acknowledgment (NACK) message to the UE if the On-Demand SIB1 Request message is not received successfully, preventing the On-Demand SIB1 Transmission in such conditions.

[0132] In some implementations, the UE may be configured with an on-demand SIB1 request timer, referred to as T3XX, and may start counting the T3XX timer to zero upon or after transmitting a WUS to the Cell A or a target NES cell, such as initiating the timer upon a first WUS transmission when retransmission, repetition, or multiple WUS transmissions occur during an on-demand SIB1 request procedure. The UE may continue counting the T3XX timer to zero unless the UE receives one or more ACK or NACK responses or the target SIB1 from the Cell A or the NES cell. Alternatively, the UE may keep counting the T3XX timer to zero unless the UE receives one or more MIBs from the target NES cell indicating that the SIB1 will be or is already being broadcasted, such as by decoding information elements like the value of Kssb contained in the MIB transmitted by the target NES cell, or the MIB contains scheduling information of the SIB1. The initial value of the T3XX timer may be pre-configured by the Cell A, the Cell A’, or the NES cell as part of a WUS configuration or on-demand SIB1 configuration, transmitted via broadcasting signaling, such as broadcasting system information from the Cell A or the Cell A’, or via UE-specific control signaling, such as an RRCRelease or RRCReconfiguration message from the serving RAN.

[0133] In some implementations addressing emergency call service support, if the UE supports voice services, is not in a Stand-alone Non-Public Network (SNPN) access mode, and a current cell does not support IMS emergency calls as indicated by the ims-EmergencySupport IE in the SIB1, the UE may perform a cell selection procedure or a cell reselection procedure to an acceptable cell supporting emergency calls in any supported RAT, regardless of priorities provided in system information from the current cell, if no suitable cell is found. If the UE supports voice services, is in the SNPN access mode, and the current cell does not support IMS emergency calls for any SNPNs as indicated by the imsEmergencySupportForSNPN IE in the SIB1, the UE may perform a cell selection procedure or a cell reselection procedure to an acceptable cell of any available SNPN supporting emergency calls, if no suitable cell is found.

[0134] Regarding Cell DTX / DRX operations, a UE may be configured with a periodic cell DTX or DRX pattern, including active and non-active periods, to facilitate reducing a gNB’s downlink transmission and uplink reception active time. The pattern configuration for cell DTX / DRX may be common for UEs configured with this feature in a cell, with cell DTX and cell DRX patterns configurable and activatable separately. A maximum of two cell DTX / DRX patterns may be configured per MAC entity for different serving cells. When cell DTX is configured and activated for a concerned cell, the UE may not monitor a PDCCH in selected cases or may not monitor Semi-Persistent Scheduling (SPS) occasions during a cell DTX non-active duration. When cell DRX is configured and activated for the concerned cell, the UE may not transmit on Configured Grant (CG) resources or may not transmit a Scheduling Request (SR) during a cell DRX non-active duration. This feature may apply (only) to UEs in an RRC_CONNECTED state, without impacting a Random Access procedure, SSB transmission, paging, or system information broadcasting. Cell DTX / DRX operation may be supported (only) for a single Transmission Reception Point (TRP) scenario and may be activated or deactivated by RRC signaling or Layer 1 group common signaling. The active duration may define a period during which the UE waits to receive PDCCHs or SPS occasions and transmit SR or CG, with gNB transmission and reception of PDCCH, SPS, SR, CG, and periodic or semi-persistent Channel State Information (CSI) reports unaffected for network energy saving purposes. A cycle may specify a periodic repetition of the active duration followed by a non-active duration, with active duration and cycle parameters common between cell DTX and cell DRX when both are configured.

[0135] Once a gNB recognizes an emergency call or public safety-related service, such as a Multimedia Priority Service (MPS) or Mission Critical Service (MCS), a network may ensure no impact to that service, such as by releasing or deactivating a cell DTX / DRX configuration, and may ensure at least partial overlapping between a UE’s connected mode DRX on-duration and a cell DTX / DRX active duration, where the UE’s connected mode DRX periodicity is a multiple of the cell DTX / DRX periodicity or vice versa.

[0136] FIG. 5 is a flowchart illustrating method / process 500 for handling critical services in a wireless communication system, according to an example implementation of the present disclosure. Although actions 502, 504, and 506 are illustrated, as separate actions, represented as independent blocks in FIG. 5, these separately illustrated actions should not be construed as to be necessarily order-dependent. The order in which the actions are performed in FIG. 5 is not intended to be construed as a limitation, and any number of the disclosed blocks may be combined in any order to implement the method, or an alternative method. Each of actions 502, 504, and 506 may be performed independent of the other actions, and may be omitted in some implementations of the present disclosure. Moreover, method / process 500 may be combined with other procedures / methods described in the present disclosure. Process 500 may be performed by a UE, with each action of process 500 corresponding to an operation executed by the UE.

[0137] In action 502, process 500 may start by receiving a WUS configuration. In action 504, process 500 may determine that a critical event has occurred. The critical event may include at least one of the following: (a) initiating an emergency service or (b) receiving a public warning alert. In action 506, in response to determining that the critical event has occurred, process 500 may perform, based on the WUS configuration, one of (a) initiating an on-demand SIB1 request procedure and (b) interrupting an ongoing on-demand SIB1 request procedure.

[0138] In some implementations, the WUS configuration may include an indicator indicating whether a cell, which is associated with a physical cell identity, supports the emergency service and / or a specific (mission) critical service.

[0139] In some implementations, the WUS configuration may include an indicator indicating whether a PLMN, which is associated with a first PLMN identity, or an SNPN, which is associated with a second PLMN ID, supports the emergency service and / or a specific (mission) critical service.

[0140] In some implementations, the WUS configuration may include an indicator indicating whether at least one of the following supports the emergency service and / or a specific (mission) critical service: an area associated with a system information area identity (ID) of other SI or a tracking area, or another area ID independent with the system information area ID.

[0141] In some additional implementations, one specific (mission) critical service would be pre-configured with one (mission) critical service ID (e.g., pre-configured by NAS layer or RRC layer). In addition, WUS configuration of one NES cell may also include one or more (mission) critical service ID supported by the NES cell itself.

[0142] In some additional implementations, a specific network slice service may be pre-configured with a network slice ID (e.g., single network slice selection assistance information, S-NSSAI, which may be pre-configured by the NAS layer or the RRC layer). In addition, the WUS configuration of an NES cell may include one or more network slice IDs supported by the NES cell itself.

[0143] In some implementations the WUS configuration may be associated with at least one cell configured with an on-demand SIB1 function, and the WUS configuration is received by the UE via system information.

[0144] In some implementations, the WUS configuration may include priority information of carrier frequencies.

[0145] In some implementations, the on-demand SIB1 request procedure may include transmitting an on-demand SIB request to a cell and monitoring for an on-demand SIB response from the cell.

[0146] In some implementations, the WUS configuration may include a cell DRX configuration associated with a cell. After initiating the on-demand SIB1 request procedure, the UE may transmit, within a cell DRX active duration of a cell DRX cycle of the cell, a WUS to the cell based on the cell DRX configuration.

[0147] In some implementations, after initiating the on-demand SIB1 request procedure, the UE may forgo transmitting, within a DRX non-active duration of a cell DRX cycle of a cell, a WUS to the cell.

[0148] In some implementations, the WUS configuration may include a timer. The UE may initiate the on-demand SIB1 request procedure, and release the timer in a case that the UE interrupts the ongoing on-demand SIB1 request procedure.

[0149] In some implementations, the UE may reselect a cell to camp on after determining that the critical event has occurred, and interrupt the ongoing on-demand SIB1 request procedure after reselecting the cell to camp on.

[0150] Process 500 may enable a UE to efficiently manage critical services, such as emergency calls or public warning alerts, within a wireless communication system by leveraging a WUS configuration to dynamically initiate or interrupt an on-demand SIB1 request procedure. This capability may enhance the responsiveness of the UE to critical events, ensuring timely access to necessary system information for emergency services while minimizing unnecessary signaling overhead during non-critical periods. By incorporating indicators within the WUS configuration, process 500 may allow the UE to determine the support status of emergency services across cells, PLMNs, or SNPNs, thereby improving the reliability and adaptability of the UE in diverse network environments. Furthermore, the integration of cell DRX configurations and timers may optimize resource utilization and power efficiency, enabling the UE to align WUS transmissions with active durations and avoid redundant operations, which may reduce latency in critical scenarios and conserve battery life. The flexibility to reselect cells and interrupt ongoing procedures may further ensure that the UE can swiftly adapt to changing network conditions, maintaining robust connectivity for critical services even in energy-saving network modes.

[0151] It should also be noted that the BS may perform methods / actions corresponding to those performed by the UE. For example, the receiving actions performed by the UE may correspond to the transmitting / configuring actions of the BS; the transmitting actions performed by the UE may correspond to the receiving actions of the BS. That is, the BS and the UE may have reciprocally aligned roles in transmission and reception. For example, the BS may transmit a WUS configuration to a UE. The WUS configuration may enable the UE, after determining that a critical event has occurred, to perform one of: (a) initiating an on-demand SIB1 request procedure and (b) interrupting an ongoing on-demand SIB1 request procedure. The critical event may include at least one of: (a) the UE initiating an emergency service or (b) the UE receiving a public warning alert.

[0152] FIG. 6 is a block diagram illustrating node 600 for wireless communications, in accordance with various aspects of the present disclosure. As illustrated in FIG. 6, node 600 may include transceiver 620, processor 628, memory 634, one or more presentation components 638, and at least one antenna 636. 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).

[0153] Each of the components may directly or indirectly communicate with each other over one or more buses 640. Node 600 may be a UE or a BS that performs various functions disclosed with reference to FIGs. 1 to 5.

[0154] Transceiver 620 has transmitter 622 (e.g., transmitting / transmission circuitry) and receiver 624 (e.g., receiving / reception circuitry) and may be configured to transmit and / or receive time and / or frequency resource partitioning information. 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. Transceiver 620 may be configured to receive data and control channels.

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

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

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

[0158] 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 aforementioned listed components should also be included within the scope of computer-readable media.

[0159] Memory 634 may include computer-storage media in the form of volatile and / or non-volatile memory. 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, memory 634 may store a computer-readable and / or computer-executable instructions 632 (e.g., software codes) that are configured to, when executed, cause processor 628 to perform various functions disclosed herein, for example, with reference to FIGs. 1 to 5. Alternatively, instructions 632 may not be directly executable by processor 628 but may be configured to cause node 600 (e.g., when compiled and executed) to perform various functions disclosed herein.

[0160] 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. Processor 628 may include memory. Processor 628 may process data 630 and instructions 632 received from memory 634, and information transmitted and received via transceiver 620, the baseband communications module, and / or the network communications module. Processor 628 may also process information to send to transceiver 620 for transmission via antenna 636 to the network communications module for transmission to a CN.

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

[0162] 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), the UE comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to the 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 a Wake-Up Signaling (WUS) configuration; 　　　　determine that a critical event has occurred, the critical event comprising at least one of 　　　　　　　　　　　　initiating an emergency service, or 　　　　　　　　　　　　receiving a public warning alert; and 　　　　in response to determining that the critical event has occurred, perform, based on the WUS configuration, one of: 　　　　　　　　initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and 　　　　　　　　interrupting an ongoing on-demand SIB1 request procedure.

2. The UE of claim 1, wherein the WUS configuration comprises an indicator indicating whether a cell, which is associated with a physical cell identity, supports the emergency service.

3. The UE of claim 1, wherein the WUS configuration comprises an indicator indicating whether a Public Land Mobile Network (PLMN) associated with a first PLMN identity, a Standalone Non-Public Network (SNPN) associated with a second PLMN identity, or an area identify associated with a system information area or a tacking area, supports the emergency service.

4. The UE of claim 1, wherein the WUS configuration is associated with at least one cell configured with an on-demand SIB1 function, and the WUS configuration is received by the UE via system information.

5. The UE of claim 1, wherein the WUS configuration comprises priority information of carrier frequencies.

6. The UE of claim 1, wherein the on-demand SIB1 request procedure comprises: 　　　　transmitting an on-demand SIB request to a cell; and 　　　　monitoring for an on-demand SIB response from the cell.

7. The UE of claim 1, wherein the WUS configuration comprises a cell Discontinuous Reception (DRX) configuration associated with a cell, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　after initiating the on-demand SIB1 request procedure, transmit, within a cell DRX active duration of a cell DRX cycle of the cell, a WUS to the cell based on the cell DRX configuration.

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: 　　　　after initiating the on-demand SIB1 request procedure, forgo transmitting, within a Discontinuous Reception (DRX) non-active duration of a cell DRX cycle of a cell, a WUS to the cell .

9. The UE of claim 1, wherein the WUS configuration comprises a timer, and the one or more computer-executable instructions, when executed by the at least one processor, further cause the UE to: 　　　　start the timer in a case that the UE initiates the on-demand SIB1 request procedure; and 　　　　release the timer in a case that the UE interrupts the ongoing on-demand 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: 　　　　reselect a cell to camp on after determining that the critical event has occurred; and 　　　　interrupt the ongoing on-demand SIB1 request procedure after reselecting the cell to camp on.

11. A method, performed by a User Equipment (UE), for handling critical services in a wireless communication system, the method comprising: 　　　　receiving a Wake-Up Signaling (WUS) configuration; 　　　　determining that a critical event has occurred, the critical event comprising at least one of 　　　　　　　　initiating an emergency service, or 　　　　　　　　receiving a public warning alert; and 　　　　in response to determining that the critical event has occurred, performing, based on the WUS configuration, one of: 　　　　　　　　initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and 　　　　　　　　interrupting an ongoing on-demand SIB1 request procedure.

12. A Base Station (BS), the BS comprising: 　　　　at least one processor; and 　　　　at least one non-transitory computer-readable medium coupled to the 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 a Wake-Up Signaling (WUS) configuration to a User Equipment (UE), wherein: 　　　　the WUS configuration enables the UE, after determining that a critical event has occurred, to perform one of: 　　　　　　　　initiating an on-demand System Information Block Type 1 (SIB1) request procedure, and 　　　　　　　　interrupting an ongoing on-demand SIB1 request procedure, and 　　　　the critical event comprises at least one of 　　　　　　　　the UE initiating an emergency service, or 　　　　　　　　the UE receiving a public warning alert.

13. The BS of claim 12, wherein the WUS configuration comprises an indicator indicating whether a cell of the BS supports the emergency service.

14. The BS of claim 12, wherein the WUS configuration comprises priority information of carrier frequencies.

15. The BS of claim 12, wherein the WUS configuration comprises a cell Discontinuous Reception (DRX) configuration.

Images