Energy saving - RRC inactive enhancement

Abstract

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE sends a request message to a network node, and the request message includes at least one of: a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, or a request for a value for a periodic RAN-based Notification Area (RNA) update timer. The UE receives an RRC Release message from the network node instructing the UE to enter the RRC Inactive state, the RRC Release message including configuration information responsive to the request message. The UE operates in the RRC Inactive state according to the configuration information.

Description

ENERGY SAVING - RRC INACTIVE ENHANCEMENTCROSS-REFERENCE TO RELATED APPLICATION (S)

[0001] This application claims the benefits of U.S. Provisional Application Serial No. 63 / 739,712, entitled “Energy Saving -RRC INACTIVE Enhancement” and filed on December 30, 2024, which is expressly incorporated by reference herein in its entirety.BACKGROUNDField

[0002] The present disclosure relates generally to wireless communications, and more particularly, to techniques of energy saving -RRC Inactive enhancement. Background

[0003] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0004] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. Typical wireless communication systems may employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple-access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0005] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate on a municipal, national, regional, and even global level. An example telecommunication standard is 5G New Radio (NR) . 5G NR is part of a continuous mobile broadband evolution promulgated by Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., with Internet of Things (IoT) ) , and other requirements. Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. There exists a need for further improvements in 5G NR technology. These improvements may also be applicable to other multi-access technologies and the telecommunication standards that employ these technologies.SUMMARY

[0006] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0007] In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a UE. The UE sends a request message to a network node, and the request message includes at least one of: a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, or a request for a value for a periodic RAN-based Notification Area (RNA) update timer. The UE receives an RRC Release message from the network node instructing the UE to enter the RRC Inactive state, the RRC Release message including configuration information responsive to the request message. The UE operates in the RRC Inactive state according to the configuration information.

[0008] In another aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a network node. The network node receives a request message from a user equipment (UE) . The request message comprises at least one of a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, or a request for a value for a periodic RAN-based Notification Area (RNA) update timer. The network node determines configuration information for the RRC Inactive state based on the request message. The network node sends an RRC Release message to the UE instructing the UE to enter the RRC Inactive state. The RRC Release message includes the determined configuration information.

[0009] To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed, and this description is intended to include all such aspects and their equivalents.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network.

[0011] FIG. 2 is a diagram illustrating a base station in communication with a UE in an access network.

[0012] FIG. 3 illustrates an example logical architecture of a distributed access network.

[0013] FIG. 4 illustrates an example physical architecture of a distributed access network.

[0014] FIG. 5 is a diagram illustrating a procedure for disabling RAN paging.

[0015] FIG. 6 is a diagram illustrating a procedure for requesting a particular value for the RNA update timer.

[0016] FIG. 7 is a diagram illustrating another procedure for disabling RAN paging.

[0017] FIG. 8 is a diagram illustrating a procedure for requesting a specific value for the periodic registration timer.

[0018] FIG. 9 is a diagram illustrating an example of RRC Reconfiguration.

[0019] FIG. 10 is a diagram illustrating an example of UE Assistance Information.

[0020] FIG. 11 is a diagram illustrating an example of an RRC Release message.

[0021] FIG. 12 is a diagram illustrating an example of the MICO Indication IE in REGISTRATION REQUEST and REGISTRATION ACCEPT messages.

[0022] FIG. 13 is a diagram illustrating the procedure flow for a UE to request the disabling of RAN paging and configure a specific value for the periodic RNA update timer.

[0023] FIG. 14 illustrates a flow chart of a process for RRC Inactive enhancement.

[0024] FIG. 15 illustrates a flow chart of another process for RRC Inactive enhancement.DETAILED DESCRIPTION

[0025] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0026] Several aspects of telecommunications systems will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0027] By way of example, an element, or any portion of an element, or any combination of elements may be implemented as a “processing system” that includes one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs) , central processing units (CPUs) , application processors, digital signal processors (DSPs) , reduced instruction set computing (RISC) processors, systems on a chip (SoC) , baseband processors, field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. One or more processors in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0028] Accordingly, in one or more example aspects, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored on or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can comprise a random-access memory (RAM) , a read-only memory (ROM) , an electrically erasable programmable ROM (EEPROM) , optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the aforementioned types of computer-readable media, or any other medium that can be used to store computer executable code in the form of instructions or data structures that can be accessed by a computer.

[0029] FIG. 1 is a diagram illustrating an example of a wireless communications system and an access network 100. The wireless communications system (also referred to as a wireless wide area network (WWAN) ) includes base stations 102, UEs 104, an Evolved Packet Core (EPC) 160, and another core network 190 (e.g., a 5G Core (5GC) ) . The base stations 102 may include macrocells (high power cellular base station) and / or small cells (low power cellular base station) . The macrocells include base stations. The small cells include femtocells, picocells, and microcells.

[0030] The base stations 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) ) may interface with the EPC 160 through backhaul links 132 (e.g., SI interface) . The base stations 102 configured for 5G NR (collectively referred to as Next Generation RAN (NG-RAN) ) may interface with core network 190 through backhaul links 184. In addition to other functions, the base stations 102 may perform one or more of the following functions: transfer of user data, radio channel ciphering and deciphering, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity) , inter cell interference coordination, connection setup and release, load balancing, distribution for non-access stratum (NAS) messages, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS) , subscriber and equipment trace, RAN information management (RIM) , paging, positioning, and delivery of warning messages. The base stations 102 may communicate directly or indirectly (e.g., through the EPC 160 or core network 190) with each other over backhaul links 134 (e.g., X2 interface) . The backhaul links 134 may be wired or wireless.

[0031] The base stations 102 may wirelessly communicate with the UEs 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, the small cell 102’ may have a coverage area 110’ that overlaps the coverage area 110 of one or more macro base stations 102. A network that includes both small cell and macrocells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (eNBs) (HeNBs) , which may provide service to a restricted group known as a closed subscriber group (CSG) . The communication links 120 between the base stations 102 and the UEs 104 may include uplink (UL) (also referred to as reverse link) transmissions from a UE 104 to a base station 102 and / or downlink (DL) (also referred to as forward link) transmissions from a base station 102 to a UE 104. The communication links 120 may use multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication links may be through one or more carriers. The base stations 102 / UEs 104 may use spectrum up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400, etc. MHz) bandwidth per carrier allocated in a carrier aggregation of up to a total of Yx MHz (x component carriers) used for transmission in each direction. The carriers may or may not be adjacent to each other. Allocation of carriers may be asymmetric with respect to DL and UL (e.g., more or fewer carriers may be allocated for DL than for UL) . The component carriers may include a primary component carrier and one or more secondary component carriers. A primary component carrier may be referred to as a primary cell (PCell) and a secondary component carrier may be referred to as a secondary cell (SCell) .

[0032] Certain UEs 104 may communicate with each other using device-to-device (D2D) communication link 158. The D2D communication link 158 may use the DL / UL WWAN spectrum. The D2D communication link 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH) , a physical sidelink discovery channel (PSDCH) , a physical sidelink shared channel (PSSCH) , and a physical sidelink control channel (PSCCH) . D2D communication may be through a variety of wireless D2D communications systems, such as for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0033] The wireless communications system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 via communication links 154 in a 5 GHz unlicensed frequency spectrum. When communicating in an unlicensed frequency spectrum, the STAs 152 / AP 150 may perform a clear channel assessment (CCA) prior to communicating in order to determine whether the channel is available.

[0034] The small cell 102’ may operate in a licensed and / or an unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102’ may employ NR and use the same 5 GHz unlicensed frequency spectrum as used by the Wi-Fi AP 150. The small cell 102’ , employing NR in an unlicensed frequency spectrum, may boost coverage to and / or increase capacity of the access network.

[0035] A base station 102, whether a small cell 102’ or a large cell (e.g., macro base station) , may include an eNB, gNodeB (gNB) , or another type of base station. Some base stations, such as gNB 180 may operate in a traditional sub 6 GHz spectrum, in millimeter wave (mmW) frequencies, and / or near mmW frequencies in communication with the UE 104. When the gNB 180 operates in mmW or near mmW frequencies, the gNB 180 may be referred to as an mmW base station. Extremely high frequency (EHF) is part of the RF in the electromagnetic spectrum. EHF has a range of 30 GHz to 300 GHz and a wavelength between 1 millimeter and 10 millimeters. Radio waves in the band may be referred to as a millimeter wave. Near mmW may extend down to a frequency of 3 GHz with a wavelength of 100 millimeters. The super high frequency (SHF) band extends between 3 GHz and 30 GHz, also referred to as centimeter wave. Communications using the mmW / near mmW radio frequency band (e.g., 3 GHz -300 GHz) has extremely high path loss and a short range. The mmW base station 180 may utilize beamforming 182 with the UE 104 to compensate for the extremely high path loss and short range.

[0036] The base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 108a. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 108b. The UE 104 may also transmit a beamformed signal to the base station 180 in one or more transmit directions 108c. The base station 180 may receive the beamformed signal from the UE 104 in one or more receive directions 108c’ . The base station 180 / UE 104 may perform beam training to determine the best receive and transmit directions for each of the base station 180 / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same.

[0037] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may be in communication with a Home Subscriber Server (HSS) 174. The MME 162 is the control node that processes the signaling between the UEs 104 and the EPC 160. Generally, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are transferred through the Serving Gateway 166, which itself is connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to the IP Services 176. The IP Services 176 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services. The BM-SC 170 may provide functions for MBMS user service provisioning and delivery. The BM-SC 170 may serve as an entry point for content provider MBMS transmission, may be used to authorize and initiate MBMS Bearer Services within a public land mobile network (PLMN) , and may be used to schedule MBMS transmissions. The MBMS Gateway 168 may be used to distribute MBMS traffic to the base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and may be responsible for session management (start / stop) and for collecting eMBMS related charging information.

[0038] The core network 190 may include a Access and Mobility Management Function (AMF) 192, other AMFs 193, a location management function (LMF) 198, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may be in communication with a Unified Data Management (UDM) 196. The AMF 192 is the control node that processes the signaling between the UEs 104 and the core network 190. Generally, the SMF 194 provides QoS flow and session management. All user Internet protocol (IP) packets are transferred through the UPF 195. The UPF 195 provides UE IP address allocation as well as other functions. The UPF 195 is connected to the IP Services 197. The IP Services 197 may include the Internet, an intranet, an IP Multimedia Subsystem (IMS) , a PS Streaming Service, and / or other IP services.

[0039] The base station may also be referred to as a gNB, Node B, evolved Node B (eNB) , an access point, a base transceiver station, a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , a transmit reception point (TRP) , or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or core network 190 for a UE 104. Examples of UEs 104 include a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA) , a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player) , a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small kitchen appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similar functioning device. Some of the UEs 104 may be referred to as IoT devices (e.g., parking meter, gas pump, toaster, vehicles, heart monitor, etc. ) . The UE 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0040] Although the present disclosure may reference 5G New Radio (NR) , the present disclosure may be applicable to other similar areas, such as LTE, LTE-Advanced (LTE-A) , Code Division Multiple Access (CDMA) , Global System for Mobile communications (GSM) , or other wireless / radio access technologies.

[0041] FIG. 2 is a block diagram of a base station 210 in communication with a UE 250 in an access network. In the DL, IP packets from the EPC 160 may be provided to a controller / processor 275. The controller / processor 275 implements layer 3 and layer 2 functionality. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The controller / processor 275 provides RRC layer functionality associated with broadcasting of system information (e.g., MIB, SIBs) , RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release) , inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting; PDCP layer functionality associated with header compression  / decompression, security (ciphering, deciphering, integrity protection, integrity verification) , and handover support functions; RLC layer functionality associated with the transfer of upper layer packet data units (PDUs) , error correction through ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs) , re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto transport blocks (TBs) , demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0042] The transmit (TX) processor 216 and the receive (RX) processor 270 implement layer 1 functionality associated with various signal processing functions. Layer 1, which includes a physical (PHY) layer, may include error detection on the transport channels, forward error correction (FEC) coding / decoding of the transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The TX processor 216 handles mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK) , quadrature phase-shift keying (QPSK) , M-phase-shift keying (M-PSK) , M-quadrature amplitude modulation (M-QAM) ) . The coded and modulated symbols may then be split into parallel streams. Each stream may then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to produce a physical channel carrying a time domain OFDM symbol stream. The OFDM stream is spatially precoded to produce multiple spatial streams. Channel estimates from a channel estimator 274 may be used to determine the coding and modulation scheme, as well as for spatial processing. The channel estimate may be derived from a reference signal and / or channel condition feedback transmitted by the UE 250. Each spatial stream may then be provided to a different antenna 220 via a separate transmitter 218TX. Each transmitter 218TX may modulate an RF carrier with a respective spatial stream for transmission.

[0043] At the UE 250, each receiver 254RX receives a signal through its respective antenna 252. Each receiver 254RX recovers information modulated onto an RF carrier and provides the information to the receive (RX) processor 256. The TX processor 268 and the RX processor 256 implement layer 1 functionality associated with various signal processing functions. The RX processor 256 may perform spatial processing on the information to recover any spatial streams destined for the UE 250. If multiple spatial streams are destined for the UE 250, they may be combined by the RX processor 256 into a single OFDM symbol stream. The RX processor 256 then converts the OFDM symbol stream from the time-domain to the frequency domain using a Fast Fourier Transform (FFT) . The frequency domain signal comprises a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are recovered and demodulated by determining the most likely signal constellation points transmitted by the base station 210. These soft decisions may be based on channel estimates computed by the channel estimator 258. The soft decisions are then decoded and deinterleaved to recover the data and control signals that were originally transmitted by the base station 210 on the physical channel. The data and control signals are then provided to the controller / processor 259, which implements layer 3 and layer 2 functionality.

[0044] The controller / processor 259 can be associated with a memory 260 that stores program codes and data. The memory 260 may be referred to as a computer-readable medium. In the UL, the controller / processor 259 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, and control signal processing to recover IP packets from the EPC 160. The controller / processor 259 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0045] Similar to the functionality described in connection with the DL transmission by the base station 210, the controller / processor 259 provides RRC layer functionality associated with system information (e.g., MIB, SIBs) acquisition, RRC connections, and measurement reporting; PDCP layer functionality associated with header compression  / decompression, and security (ciphering, deciphering, integrity protection, integrity verification) ; RLC layer functionality associated with the transfer of upper layer PDUs, error correction through ARQ, concatenation, segmentation, and reassembly of RLC SDUs, re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through HARQ, priority handling, and logical channel prioritization.

[0046] Channel estimates derived by a channel estimator 258 from a reference signal or feedback transmitted by the base station 210 may be used by the TX processor 268 to select the appropriate coding and modulation schemes, and to facilitate spatial processing. The spatial streams generated by the TX processor 268 may be provided to different antenna 252 via separate transmitters 254TX. Each transmitter 254TX may modulate an RF carrier with a respective spatial stream for transmission. The UL transmission is processed at the base station 210 in a manner similar to that described in connection with the receiver function at the UE 250. Each receiver 218RX receives a signal through its respective antenna 220. Each receiver 218RX recovers information modulated onto an RF carrier and provides the information to a RX processor 270.

[0047] The controller / processor 275 can be associated with a memory 276 that stores program codes and data. The memory 276 may be referred to as a computer-readable medium. In the UL, the controller / processor 275 provides demultiplexing between transport and logical channels, packet reassembly, deciphering, header decompression, control signal processing to recover IP packets from the UE 250. IP packets from the controller / processor 275 may be provided to the EPC 160. The controller / processor 275 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0048] New radio (NR) may refer to radios configured to operate according to a new air interface (e.g., other than Orthogonal Frequency Divisional Multiple Access (OFDMA) -based air interfaces) or fixed transport layer (e.g., other than Internet Protocol (IP) ) . NR may utilize OFDM with a cyclic prefix (CP) on the uplink and downlink and may include support for half-duplex operation using time division duplexing (TDD) . NR may include Enhanced Mobile Broadband (eMBB) service targeting wide bandwidth (e.g. 80 MHz beyond) , millimeter wave (mmW) targeting high carrier frequency (e.g. 60 GHz) , massive MTC (mMTC) targeting non-backward compatible MTC techniques, and / or mission critical targeting ultra-reliable low latency communications (URLLC) service.

[0049] A single component carrier bandwidth of 100 MHz may be supported. In one example, NR resource blocks (RBs) may span 12 sub-carriers with a sub-carrier bandwidth of 60 kHz over a 0.25 ms duration or a bandwidth of 30 kHz over a 0.5 ms duration (similarly, 50MHz BW for 15kHz SCS over a 1 ms duration) . Each radio frame may consist of 10 subframes (10, 20, 40 or 80 NR slots) with a length of 10 ms. Each slot may indicate a link direction (i.e., DL or UL) for data transmission and the link direction for each slot may be dynamically switched. Each slot may include DL / UL data as well as DL / UL control data.

[0050] The NR RAN may include a central unit (CU) and distributed units (DUs) . A NR BS (e.g., gNB, 5G Node B, Node B, transmission reception point (TRP) , access point (AP) ) may correspond to one or multiple BSs. NR cells can be configured as access cells (ACells) or data only cells (DCells) . For example, the RAN (e.g., a central unit or distributed unit) can configure the cells. DCells may be cells used for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or handover. In some cases DCells may not transmit synchronization signals (SS) in some cases DCells may transmit SS. NR BSs may transmit downlink signals to UEs indicating the cell type. Based on the cell type indication, the UE may communicate with the NR BS. For example, the UE may determine NR BSs to consider for cell selection, access, handover, and / or measurement based on the indicated cell type.

[0051] FIG. 3 illustrates an example logical architecture of a distributed RAN 300, according to aspects of the present disclosure. A 5G access node 306 may include an access node controller (ANC) 302. The ANC may be a central unit (CU) of the distributed RAN. The backhaul interface to the next generation core network (NG-CN) 304 may terminate at the ANC. The backhaul interface to neighboring next generation access nodes (NG-ANs) 310 may terminate at the ANC. The ANC may include one or more TRPs 308 (which may also be referred to as BSs, NR BSs, Node Bs, 5G NBs, APs, or some other term) . As described above, a TRP may be used interchangeably with “cell. ”

[0052] The TRPs 308 may be a distributed unit (DU) . The TRPs may be connected to one ANC (ANC 302) or more than one ANC (not illustrated) . For example, for RAN sharing, radio as a service (RaaS) , and service specific ANC deployments, the TRP may be connected to more than one ANC. A TRP may include one or more antenna ports. The TRPs may be configured to individually (e.g., dynamic selection) or jointly (e.g., joint transmission) serve traffic to a UE.

[0053] The local architecture of the distributed RAN 300 may be used to illustrate fronthaul definition. The architecture may be defined that support fronthauling solutions across different deployment types. For example, the architecture may be based on transmit network capabilities (e.g., bandwidth, latency, and / or jitter) . The architecture may share features and / or components with LTE. According to aspects, the next generation AN (NG-AN) 310 may support dual connectivity with NR. The NG-AN may share a common fronthaul for LTE and NR.

[0054] The architecture may enable cooperation between and among TRPs 308. For example, cooperation may be preset within a TRP and / or across TRPs via the ANC 302. According to aspects, no inter-TRP interface may be needed / present.

[0055] According to aspects, a dynamic configuration of split logical functions may be present within the architecture of the distributed RAN 300. The PDCP, RLC, MAC protocol may be adaptably placed at the ANC or TRP.

[0056] FIG. 4 illustrates an example physical architecture of a distributed RAN 400, according to aspects of the present disclosure. A centralized core network unit (C-CU) 402 may host core network functions. The C-CU may be centrally deployed. C-CU functionality may be offloaded (e.g., to advanced wireless services (AWS) ) , in an effort to handle peak capacity. A centralized RAN unit (C-RU) 404 may host one or more ANC functions. Optionally, the C-RU may host core network functions locally. The C-RU may have distributed deployment. The C-RU may be closer to the network edge. A distributed unit (DU) 406 may host one or more TRPs. The DU may be located at edges of the network with radio frequency (RF) functionality.

[0057] In modern wireless communication networks, the Radio Resource Control (RRC) protocol layer manages radio resources and the connection state between a User Equipment (UE) and a base station. A UE operates in one of three primary states: RRC Connected, RRC Idle, or RRC Inactive. The management of transitions between these states is a fundamental aspect of balancing network resource efficiency with UE power consumption.

[0058] The RRC Idle state is a power-saving mode where the UE releases its RRC connection and does not maintain dedicated radio resources. The network tracks the UE’s location at a broader Tracking Area level consisting of multiple cells. While this state minimizes power consumption, the UE must perform complex procedures to transition to the RRC Connected state before transmitting or receiving user data.

[0059] The RRC Connected state is an active mode for service execution. In this state, the UE maintains a stable RRC connection with the base station, which allocates dedicated signaling and data resources. The network tracks the UE at the specific cell level, enabling direct uplink and downlink data transmission. This state consumes significant power as the UE must continuously maintain the connection and respond to network scheduling.

[0060] The RRC Inactive state represents a hybrid approach that balances the power efficiency of Idle mode with reduced connection resumption latency. In this state, the UE’s RRC connection is suspended but not released. The Core Network (CN) maintains the UE’s logical connection while the Radio Access Network (RAN) retains the UE’s context information. The network tracks the UE at a RAN-based Notification Area (RNA) level, which is typically smaller than a Tracking Area but larger than a single cell. When data arrives or needs to be sent, the UE can quickly resume the connection without the full setup procedures required from Idle state, significantly reducing signaling overhead and latency.

[0061] Mobile Initiated Connection Only (MICO) is a power-saving feature designed for devices that primarily initiate communication rather than receiving network-initiated traffic. When MICO mode is enabled, the UE does not monitor CN paging, which is the procedure used by the network to locate and alert a UE in RRC Idle state when downlink data arrives. This allows the UE to remain in deep sleep for extended periods without periodic wake-ups to check for paging messages, significantly reducing power consumption.

[0062] CN paging and RAN paging serve distinct purposes in the network architecture. CN paging is triggered by the CN when downlink data arrives for a UE in RRC Idle state. Since the network only knows the UE’s location at the Tracking Area or Registration Area level, paging messages must be broadcast across all cells within that area. UEs in RRC Idle state must periodically wake up to monitor for these CN paging messages.

[0063] RAN paging operates differently, being initiated by the RAN to reach a UE in RRC Inactive state. Since the RAN retains the UE’s context and tracks its position at the RNA level, RAN paging is only transmitted within that specific RNA. The paging message includes an Inactive-Radio Network Temporary Identifier (I-RNTI) that uniquely identifies the target UE. Upon receiving a RAN paging message, the UE checks whether the included I-RNTI matches its own to determine if it is being paged.

[0064] The MICO feature is negotiated during the Non-Access Stratum (NAS) registration procedure between the UE and CN. During this procedure, the UE can request to enable MICO, and the network decides whether to accept or reject this request based on its policies and the UE’s subscription data. This negotiation establishes whether the UE can operate without monitoring CN paging.

[0065] An important aspect of network registration is the periodic registration update mechanism. After successful registration, a UE must periodically update its registration status with the CN to maintain network connectivity. This process is controlled by the T3512 timer. When this timer expires, the UE must re-register with the network or risk being de-registered, requiring a full registration procedure for subsequent communication.

[0066] Under current specifications, a UE can request a preferred T3512 timer value, but this capability is restricted to scenarios where the UE is also requesting MICO mode. If the UE is not requesting MICO, it cannot suggest a T3512 value and must accept whatever value the network assigns. When the UE does request a T3512 value as part of a MICO request, the network makes the final decision on the actual timer value to be used.

[0067] For UEs in RRC Inactive state, maintaining network reachability requires two essential procedures. First, the UE must continuously monitor RAN paging messages within its RNA. This monitoring is mandatory and cannot be disabled under current specifications. Second, the UE must perform periodic RNA updates (RNAU) to inform the network that it remains within the current RNA. This update process is controlled by the t380 timer, whose value is configured by the network through the PeriodicRNAU-TimerValue Information Element in the RRCRelease message that transitions the UE to Inactive state.

[0068] The current RRC Inactive state implementation presents significant limitations when compared to the power-saving capabilities available in RRC Idle state through MICO. Most notably, while MICO allows a UE in RRC Idle to completely disable CN paging monitoring, no equivalent mechanism exists for a UE in RRC Inactive to disable RAN paging monitoring. This creates a fixed power consumption overhead, as the UE must regularly wake up to check for RAN paging messages even when it primarily initiates communication and rarely receives network-initiated traffic.

[0069] Additionally, the UE lacks any control over the RNAU timer configuration in RRC Inactive state. The t380 timer value is exclusively determined by the network, with no mechanism for the UE to request a different value that might better align with its traffic patterns or power-saving requirements. This contrasts sharply with the T3512 timer for periodic registration, where the UE can at least request a preferred value when requesting MICO mode.

[0070] While UE Assistance Information (UAI) messages theoretically allow a UE to request transition to RRC Idle state to avoid RAN paging, this approach has fundamental limitations. The network retains complete discretion over whether to honor such requests, providing no guarantee that the UE’s preference will be accommodated. More importantly, even if the network grants the transition to RRC Idle, the UE loses the primary benefit of RRC Inactive state: rapid connection resumption with minimal signaling overhead. A UE transitioning from RRC Idle must exchange significantly more messages to return to Connected state compared to resuming from Inactive state.

[0071] These limitations prevent optimal power efficiency for UEs operating in RRC Inactive state. The inability to disable RAN paging forces continuous power consumption for paging monitoring, while the lack of RNAU timer negotiation prevents UEs from optimizing their update frequency based on their specific usage patterns. The absence of mechanisms comparable to those available through MICO for RRC Idle state creates an asymmetry in power-saving capabilities across different RRC states, particularly affecting devices that would benefit from the fast resumption capability of RRC Inactive while requiring extended battery life.

[0072] FIG. 5 is a diagram 500 illustrating a procedure for disabling RAN paging monitoring in RRC Inactive state. This example shows a mechanism that allows a UE to request that it not be required to monitor RAN paging messages while operating in RRC Inactive state. This capability provides power-saving benefits by eliminating the need for the UE to periodically wake up to check for RAN paging messages, particularly benefiting devices that primarily initiate communications rather than receive network-initiated traffic.

[0073] The procedure operates through a three-step handshake between the UE and the RAN, without requiring involvement from the CN. This RAN-centric approach provides a direct negotiation mechanism for RAN paging behavior while maintaining the CN’s independence from RAN-specific power optimization features.

[0074] At Step 51, the RAN initiates the procedure by sending an RRCReconfiguration message to the UE. This message contains an RRCInactive-AssistanceConfig information element that serves as an authorization mechanism. By including this configuration element, the RAN grants the UE permission to subsequently send UE Assistance Information (UAI) requests related to RRC Inactive state behavior, specifically including the capability to request disabling of RAN paging monitoring. This authorization step acts as a control mechanism, allowing the RAN to selectively enable this feature for appropriate UEs based on network policies, device capabilities, or service requirements. The RAN retains complete discretion over whether to include this configuration for any particular UE.

[0075] Following authorization, at Step 52, the UE that has received the RRCInactive-AssistanceConfig may send a UEAssistanceInformation message to the RAN. This UAI message includes a specific request to disable RAN paging, identified by the RANPagingDisable parameter. The request signals the UE’s preference to conserve power by not monitoring RAN paging messages when in RRC Inactive state. The UAI message containing the RAN paging disable request may be transmitted as part of a broader assistance information message that also requests transition to RRC Inactive state, allowing the UE to communicate multiple preferences in a single transmission.

[0076] At Step 53, when the RAN determines to release the RRC connection and transition the UE to RRC Inactive state, it sends an RRCRelease message to the UE. If the RAN decides to grant the UE’s request from Step 52, it includes a disableRANPaging parameter within the RRCRelease message. This parameter serves as the actual command that implements the RAN paging disable feature. Upon receiving an RRCRelease message containing this parameter, the UE transitions to RRC Inactive state and operates without monitoring RAN paging messages for mobile-terminated calls.

[0077] The RAN makes the final decision whether to grant or deny the UE’s request based on various factors including network policies, current network load conditions, the UE’s service profile, and overall system optimization considerations. If the RAN chooses not to include the disableRANPaging parameter in the RRCRelease message, the UE understands that its request has been denied and must continue to monitor RAN paging messages in RRC Inactive state according to standard procedures. This maintains backward compatibility and allows the network to override UE preferences when necessary for network management purposes.

[0078] When a UE operates in RRC Inactive state with RAN paging monitoring disabled through this mechanism, it does not need to wake up periodically to receive and decode RAN paging messages that contain Inactive-Radio Network Temporary Identifiers (I-RNTIs) . The UE avoids the power consumption associated with activating its receiver, processing broadcast paging channels, and checking whether received I-RNTI values match its own assigned identifier. This power saving occurs while the UE maintains its RRC Inactive state, preserving the UE context in the RAN and maintaining the ability to rapidly resume the RRC connection with reduced signaling overhead compared to connection establishment from RRC Idle state.

[0079] The mechanism addresses deployment scenarios where UEs primarily initiate traffic rather than receive network-initiated services. Such devices can optimize their power efficiency through this negotiated RAN paging disable feature while remaining in RRC Inactive state, ready for quick connection resumption when the UE needs to transmit data. The three-step handshake provides a structured approach where the RAN first enables the capability through configuration, the UE then expresses its power-saving preference through assistance information, and finally the RAN makes an informed decision that balances the UE’s power optimization needs with network management requirements.

[0080] FIG. 6 is a diagram 600 illustrating a procedure for requesting a particular value for the periodic RNA update timer. This mechanism addresses the current limitation where UEs have no control over the t380 timer configuration when operating in RRC Inactive state. The procedure enables a UE to request a specific periodic RNAU timer value that better aligns with its traffic patterns, mobility characteristics, and power consumption requirements.

[0081] The procedure implements a three-step handshake between the UE and the RAN without requiring CN involvement. This RAN-centric approach allows direct negotiation of RAN-specific timing parameters while maintaining independence from core network procedures.

[0082] At Step 61, the RAN initiates the procedure by sending an RRCReconfiguration message to the UE. This message contains the RRCInactive-AssistanceConfig information element, which serves as an authorization mechanism. By including this configuration element, the RAN grants the UE permission to subsequently send UAI requests related to RRC Inactive state timing parameters. The RAN retains complete discretion over whether to include this configuration element for any particular UE. When the RAN includes this information element, it enables the UE to send UAI with specific timer requests. Conversely, if the RAN does not include this information element, the UE should not send UAI requests for timer configuration. This provides the RAN with a control mechanism to selectively enable the timer negotiation capability based on network policies, device capabilities, or service requirements.

[0083] At Step 62, after receiving the RRCInactive-AssistanceConfig authorization from the RAN, the UE may send a UEAssistanceInformation message to the RAN. This UAI message includes the requestedPeriodicRNAU-TimerValue parameter that specifies the UE’s preferred value for the periodic RNAU timer. The requested timer value reflects the UE’s assessment of its optimal update frequency based on factors such as expected mobility patterns, power budget constraints, or application requirements. This UAI message containing the timer request may be transmitted as part of a broader assistance information message that also requests transition to RRC Inactive state, allowing the UE to communicate multiple preferences in a single transmission.

[0084] At Step 63, when the RAN determines to release the RRC connection and transition the UE to RRC Inactive state, it sends an RRCRelease message to the UE. Within this message, the RAN configures the periodicRNAU-TimerValue parameter, which sets the actual t380 timer value that the UE will use for periodic RNA updates in RRC Inactive state. The RAN makes the final decision on this timer value, taking into consideration the UE’s requested value from Step 62 along with other factors including current network load conditions, the characteristics of the RNA, mobility management requirements, and overall system optimization policies.

[0085] The RAN maintains ultimate authority over the timer configuration while considering the UE’s preference. For example, if the UE requests 10 minutes in Step 62 and the RAN would normally configure 20 minutes, the RAN may accommodate the UE’s request and configure 10 minutes instead. Alternatively, the RAN may assign a different value based on network constraints or retain its default configured value if network conditions do not permit the requested configuration. This flexibility allows the network to maintain control over radio resource management while enabling UE input into configuration parameters that affect power consumption.

[0086] The mechanism particularly benefits UEs that can predict their behavior patterns in RRC Inactive state. A UE expecting to remain relatively stationary might request a longer RNAU timer to reduce the frequency of update procedures and associated power consumption. Conversely, a UE anticipating higher mobility might request a shorter timer to provide more frequent location updates to the network. By allowing UEs to express these preferences through the negotiation mechanism, the system can optimize the balance between network tracking accuracy and UE power efficiency on a per-device basis. The three-step handshake provides a structured approach where the RAN first enables the capability through configuration, the UE then expresses its timer preference through assistance information, and finally the RAN makes an informed decision that balances the UE’s power optimization needs with network management requirements.

[0087] FIG. 7 is a diagram 700 illustrating an alternative procedure for disabling RAN paging through NAS signaling. Unlike the RAN-centric mechanism shown in FIG. 5 that employs UAI messages between the UE and RAN, this procedure utilizes the NAS registration procedure to negotiate RAN paging disable directly with the CN. This CN-centric approach enables the CN to be aware of and control the UE’s RAN paging monitoring preference, allowing the CN to make appropriate data handling decisions when the UE subsequently enters RRC Inactive state.

[0088] The mechanism employs the MICO Indication IE within NAS registration messages as a container for the RAN paging control parameter. A new “Disable RAN Paging” bit is added to this existing IE structure. While the MICO Indication IE is utilized as the signaling container, the mechanism does not require MICO mode itself to be requested or activated. The IE simply provides a convenient and structurally appropriate location within the registration messages to carry the RAN paging disable parameter.

[0089] At Step 71, the UE initiates the procedure by sending a REGISTRATION REQUEST message to the CN. Within this message, the UE includes the MICO Indication IE containing the new “Disable RAN Paging” bit. Setting this bit to 1 indicates the UE’s request to disable RAN paging when operating in RRC Inactive state. Setting the bit to 0 indicates no such request. This registration procedure may occur during initial network attachment, periodic registration update, or mobility registration update scenarios.

[0090] At Step 72, the CN evaluates the UE’s request based on network policies, the UE’s subscription profile, and current network conditions. The CN responds with a REGISTRATION ACCEPT message that also contains the MICO Indication IE with the “Disable RAN Paging” bit. When the CN grants the request, it sets this bit to 1, indicating approval of the RAN paging disable. When the CN rejects the request, it sets the bit to 0, indicating denial. The CN retains this negotiated status in the UE’s context for use in subsequent procedures. Through this two-step exchange, the UE and CN establish a mutual understanding regarding whether RAN paging will be disabled when the UE operates in RRC Inactive state.

[0091] Following the registration procedure, the UE may establish and release RRC connections for various services. The registration negotiation and the transition to RRC Inactive state are temporally independent events. At some point after the registration, when the RAN determines to release an RRC connection and transition the UE to RRC Inactive state, the RAN must inform the CN of this state change. At Step 73, the RAN sends a Suspend Request message to the CN, indicating that the UE is entering a suspended state, which corresponds to the RRC Inactive state from the RAN perspective. In this suspended state, the RAN maintains the UE’s context information but releases active radio resources. At Step 74, the CN acknowledges receipt of this state transition notification by sending a Suspend Response message back to the RAN.

[0092] Upon receiving the Suspend Request, the CN becomes aware that the UE has transitioned to RRC Inactive state. At this point, the CN possesses two critical pieces of information: first, the UE’s current state is RRC Inactive as indicated by the suspend notification from the RAN; second, the CN’s own records show whether it previously granted or denied the UE’s request to disable RAN paging during the registration procedure. When these two conditions align-the UE is in RRC Inactive state and RAN paging has been disabled per the earlier negotiation-the CN must modify its data forwarding behavior for this specific UE.

[0093] At Step 75, when the CN receives downlink data from external networks such as the Internet destined for this UE, the CN recognizes that standard data forwarding procedures cannot be applied. Under normal operations with RAN paging enabled, the CN would forward the data to the RAN, triggering the RAN to page the UE in RRC Inactive state using the I-RNTI identifier. However, since the CN has granted the disable RAN paging request and knows the UE is not monitoring RAN paging messages, initiating such a paging procedure would be futile. The UE would not receive or respond to the paging message because it has disabled its RAN paging monitoring functionality based on the negotiated configuration. Therefore, the CN must buffer the incoming downlink data rather than forwarding it to the RAN.

[0094] The buffered data remains stored within the CN until the UE initiates communication with the network through a mobile-originated procedure. Since the UE is not monitoring RAN paging, the network has no mechanism to notify the UE about pending downlink data through network-initiated procedures. Data delivery becomes dependent on the UE performing actions such as connection resumption for uplink data transmission or periodic RNA updates. When the UE initiates such procedures and establishes RRC connectivity, the CN can then deliver the buffered downlink data.

[0095] This CN-centric mechanism provides distinct operational characteristics compared to the RAN-centric UAI approach. By maintaining direct awareness of the RAN paging disable status at the CN level, the network can make immediate and appropriate data handling decisions upon receiving downlink traffic. The negotiation through NAS registration procedures allows the RAN paging preference to be established or modified during any registration update without requiring the UE to be in RRC Connected state. The mechanism addresses deployment scenarios where devices primarily initiate communications and rarely receive network-terminated traffic, allowing such devices to achieve significant power savings by avoiding periodic wake-ups for RAN paging monitoring while the CN manages data delivery appropriately.

[0096] FIG. 8 is a diagram 800 illustrating a procedure for requesting a specific periodic registration timer (T3512) value without requiring MICO mode activation. This mechanism addresses a limitation in current specifications where a UE can only request a preferred T3512 timer value when simultaneously requesting MICO mode during the NAS registration procedure. The present mechanism removes this restriction, allowing a UE to negotiate its T3512 timer value independently of MICO mode activation.

[0097] The T3512 timer controls the periodicity of registration updates between the UE and CN. This timer operates at the NAS layer and determines how frequently a UE must re-register with the network to maintain its registration status. When the T3512 timer expires without the UE performing a registration update, the network may de-register the UE, requiring a complete registration procedure for subsequent communications. The T3512 timer serves a different purpose from the t380 timer that controls periodic RNA updates in RRC Inactive state. While t380 governs RAN location tracking for UEs in RRC Inactive state, T3512 governs CN registration periodicity regardless of the UE’s RRC state.

[0098] At Step 81, the UE initiates the procedure by sending a REGISTRATION REQUEST message to the CN. The UE includes a requested T3512 timer value within this message to indicate its preferred periodicity for registration updates. Critically, the UE does not include the MICO Indication IE in the registration request, thereby signaling that it is not requesting MICO mode activation. The absence of the MICO Indication IE combined with the presence of a requested T3512 value represents the core enhancement of this mechanism. The UE’s requested timer value reflects its assessment of optimal registration frequency based on factors such as expected network attachment duration, mobility patterns, and power consumption requirements.

[0099] At Step 82, the CN processes the registration request and recognizes that the UE has provided a preferred T3512 timer value without requesting MICO mode. The CN evaluates the requested timer value against its network policies, current network conditions, the UE’s subscription profile, and regulatory requirements. The CN responds with a REGISTRATION ACCEPT message that includes the configured T3512 timer value. The CN may accept the UE’s requested value and configure the T3512 timer accordingly, or it may assign a different value based on its evaluation criteria. The network retains final authority over the timer configuration while considering the UE’s preference.

[0100] This mechanism operates independently from and complementarily to the previously described proposals for managing RRC Inactive state behavior. The RAN paging disable mechanisms and RNAU timer negotiation procedures address RAN-layer operations specific to the RRC Inactive state, while this T3512 timer negotiation addresses NAS-layer periodic registration applicable across all RRC states. A UE may simultaneously utilize this mechanism to negotiate its T3512 timer value with the CN while also employing UAI or NAS procedures to request RRC Inactive configurations such as disabled RAN paging or a specific RNAU timer value. These mechanisms collectively provide UEs with comprehensive control over their power-saving configurations across different protocol layers.

[0101] The removal of the coupling between T3512 timer negotiation and MICO mode activation represents a relaxation of existing limitations in the standard. Previously, UEs that did not require or desire MICO mode functionality had no mechanism to influence their periodic registration timer configuration. This enhancement provides all UEs, regardless of their MICO mode status, with the flexibility to request timer values that align with their operational characteristics and power optimization requirements. The mechanism particularly benefits UEs that require regular network registration but do not need the complete disconnection from CN paging that MICO mode provides.

[0102] FIG. 9 is a diagram 900 illustrating enhancements to the RRC Reconfiguration message structure to support UE assistance capabilities for RRC Inactive state operations. The RRC Reconfiguration message is transmitted by the RAN to the UE and serves as the mechanism through which the RAN controls the UE’s ability to send UE Assistance Information (UAI) requests related to RRC Inactive state behavior.

[0103] The enhancement introduces a hierarchical structure following standard RRC message design patterns. At the top level, the RRCReconfiguration-vxyz-IEs structure contains an otherConfig-vxyz field, which in turn contains the RRCInactive-AssistanceConfig-vxyz information element. The version suffix "-vxyz" indicates this represents a future version of the specification, while individual parameters within the structure carry release indicators such as "-r18" denoting Release 18 functionality as an example. In general, it can be applicable for any future 3GPP Release rxyz functionality.

[0104] The RRCInactive-AssistanceConfig-vxyz IE employs a SetupRelease wrapper structure, a standard pattern in RRC specifications that allows the RAN to either establish a new configuration through a setup indication or remove an existing configuration through a release indication. When the RAN transmits an RRCReconfiguration message with this IE set to setup, it grants the UE authorization to subsequently send UAI messages containing specific requests for RRC Inactive state optimizations. Conversely, when the RAN sends a release indication, it revokes the UE’s authorization to send such requests.

[0105] Within the RRCInactive-AssistanceConfig-vxyz structure, two optional parameters control distinct aspects of UE assistance authorization. The RANPagingDisable-r18 parameter, defined as ENUMERATED true, serves as an authorization flag. When this parameter is included in the configuration, regardless of its enumerated value being set to true, the RAN grants the UE permission to send UAI messages requesting the disabling of RAN paging monitoring. The single enumerated value of true indicates that when present, this authorization is always affirmative. The PeriodicRNAUTimerRequest-r18 parameter, defined as ENUMERATED enable, operates similarly. When included in the configuration with its value set to enable, it authorizes the UE to send UAI messages requesting specific values for the periodic RNAU timer. The RAN may include either parameter individually or both parameters simultaneously within a single RRCReconfiguration message, providing granular control over which types of assistance requests the UE is permitted to send.

[0106] Both parameters are marked as OPTIONAL with the "Need M" (Need to Maintain) rule, which governs parameter persistence across multiple RRCReconfiguration messages. The "Need M" rule specifies that once a parameter has been explicitly configured in an RRCReconfiguration message, its configuration remains active even if subsequent RRCReconfiguration messages omit that parameter. This behavior applies independently to each parameter within the RRCInactive-AssistanceConfig-vxyz IE.

[0107] To illustrate this persistence mechanism, consider a scenario where the RAN sends an initial RRCReconfiguration message that includes both the RANPagingDisable-r18 and PeriodicRNAUTimerRequest-r18 parameters. This configuration authorizes the UE to send UAI messages requesting both RAN paging disable and specific RNAU timer values. If the RAN subsequently transmits another RRCReconfiguration message for unrelated configuration purposes and omits the RRCInactive-AssistanceConfig-vxyz IE entirely, the "Need M" rule dictates that the UE maintains the previously established authorizations. The UE continues to be authorized to send both types of UAI requests despite their absence in the subsequent message.

[0108] The "Need M" rule eliminates the need for the RAN to repeatedly include unchanged configuration parameters in every RRCReconfiguration message, reducing signaling overhead while maintaining configuration stability. The authorization granted through these parameters persists until the RAN explicitly modifies or revokes it. Revocation occurs only when the RAN sends an RRCReconfiguration message that includes the RRCInactive-AssistanceConfig-vxyz IE with a release indication through the SetupRelease wrapper, or when the RAN sends a new setup configuration that explicitly modifies the included parameters. This mechanism allows the UE’s assistance authorization to remain consistent across multiple reconfiguration procedures that may be addressing unrelated aspects of UE operation, providing operational efficiency while maintaining precise RAN control over UE assistance capabilities.

[0109] FIG. 10 is a diagram 1000 illustrating enhancements to the UE Assistance Information message structure that enable the UE to request specific configurations for RRC Inactive state operations. The UAI message represents the primary mechanism through which the UE communicates its preferences to the RAN regarding power-saving configurations when operating in RRC Inactive state.

[0110] The enhanced UAI message structure introduces the UEAssistanceInformation-vxyz-IEs sequence at the top level, which contains an RRCInactive-Assistance-rxyz field. The version suffixes "-vxyz" and "-rxyz" indicate future releases of the specification where these enhancements will be incorporated. This RRCInactive-Assistance-rxyz field serves as the container for all parameters related to RRC Inactive state assistance requests.

[0111] Within the RRCInactive-Assistance-rxyz structure, two optional parameters provide the UE with mechanisms to request specific RRC Inactive state behaviors. The first parameter, RANPagingDisable-rxyz, is defined as an ENUMERATED type with two possible values: enable and disabled. Despite the potentially confusing nomenclature, this parameter operates as follows: when set to "enable, " the UE requests that the RAN disable its requirement to monitor RAN paging messages while in RRC Inactive state, thereby enabling the RAN paging disable feature. When set to "disabled, " the UE requests that any previously disabled RAN paging monitoring be re-enabled, effectively disabling the RAN paging disable feature and returning to normal paging monitoring operations. This bidirectional capability allows the UE to dynamically adjust its paging monitoring behavior based on changing operational requirements or traffic patterns.

[0112] The second parameter, requestedPeriodicRNAU-TimerValue-rxyz, provides the UE with a mechanism to request a specific value for the periodic RNAU timer (t380) . This parameter is defined as an ENUMERATED type with eight predefined values: min5, min10, min20, min30, min60, min120, min360, and min720, corresponding to timer durations of 5, 10, 20, 30, 60, 120, 360, and 720 minutes respectively. The selection of timer value represents a trade-off between power consumption and network tracking accuracy. Shorter timer values such as min5 or min10 result in more frequent RNA updates, providing the network with more current location information but consuming more UE power and generating higher signaling overhead. Longer timer values such as min360 or min720 significantly reduce the frequency of RNA updates, conserving UE battery life and reducing signaling load on the network, though potentially resulting in less accurate network knowledge of the UE’s current RNA location.

[0113] Both parameters are marked as OPTIONAL within the RRCInactive-Assistance-rxyz structure, providing the UE with complete flexibility in constructing its assistance request. The UE may include only the RANPagingDisable-rxyz parameter when its sole concern is modifying paging monitoring behavior, only the requestedPeriodicRNAU-TimerValue-rxyz parameter when its focus is on optimizing the RNA update frequency, or both parameters simultaneously when requesting comprehensive RRC Inactive state configuration. The absence of both parameters is also valid, though it would result in an empty assistance request.

[0114] The transmission of this enhanced UAI message is contingent upon prior authorization from the RAN. The UE may only send UAI messages containing RRC Inactive assistance parameters after receiving explicit permission through the RRCInactive-AssistanceConfig-vxyz IE in an RRCReconfiguration message, as described in FIG. 9. This authorization mechanism provides the RAN with granular control over which UEs are permitted to request these power-saving features. The RAN may grant authorization based on factors such as the UE’s subscription profile, current network conditions, or device capabilities. Without such authorization, the UE should not transmit UAI messages containing these RRC Inactive assistance parameters.

[0115] The UAI message represents a request or preference from the UE rather than a command that the RAN must follow. Upon receiving a UAI message containing RRC Inactive assistance parameters, the RAN evaluates the request considering multiple factors including current network load, the characteristics of the RNA where the UE is located, mobility management policies, and overall system optimization objectives. The RAN retains complete discretion to accept the UE’s request as-is, modify the requested parameters based on network constraints, or reject the request entirely. The RAN’s decision is subsequently communicated to the UE through the RRCRelease message when transitioning the UE to RRC Inactive state, as will be described in FIG. 11.

[0116] This UAI-based negotiation mechanism addresses diverse deployment scenarios and UE types. Stationary or low-mobility devices such as smart meters or fixed sensors can request long RNAU timer values and disabled RAN paging to maximize battery life. Devices with predictable traffic patterns can align their RNA update frequency with their communication needs. Mobile devices can request shorter timer values when expecting higher mobility to maintain network tracking accuracy. The mechanism provides a standardized framework for UEs to communicate their operational characteristics and power-saving requirements to the network while maintaining network control over final configuration decisions.

[0117] FIG. 11 is a diagram 1100 illustrating enhancements to the RRC Release message structure that enable the network to configure RRC Inactive state behavior. The RRC Release message is transmitted by the RAN to command the UE to release its RRC connection and transition to RRC Inactive state. This message serves as the RAN’s final response mechanism through which it grants or denies the UE’s assistance requests that were previously sent via the UEAssistanceInformation message described in FIG. 10.

[0118] The RRC Release message structure maintains the existing RRCRelease-IEs sequence at the top level, which contains a suspendConfig field of type SuspendConfig. This suspend configuration is marked as OPTIONAL with a "Need R" rule and provides parameters that govern the UE’s behavior when operating in RRC Inactive state. Within the SuspendConfig structure, two parameters control key aspects of RRC Inactive state operation.

[0119] The first parameter, t380, specifies the PeriodicRNAU-TimerValue that controls the periodicity of RNA updates. This parameter already exists in current specifications and is not part of the present enhancement. When included, the t380 parameter configures the timer duration that determines how frequently the UE must perform periodic RNA updates while in RRC Inactive state. The network may set this timer value based on the UE’s requested value from the requestedPeriodicRNAU-TimerValue-rxyz parameter that was sent in a prior UAI message. The network retains final authority over the configured value and may set it to match the UE’s request, modify it based on network constraints, or ignore the request entirely.

[0120] The second parameter, disableRANPaging, represents the primary enhancement introduced by this disclosure. This new parameter is defined as ENUMERATED true and serves as a command to the UE to disable its RAN paging monitoring functionality while operating in RRC Inactive state. The semantics of this parameter operate on a presence basis: when the network includes the disableRANPaging parameter in the SuspendConfig, it instructs the UE to operate without monitoring RAN paging messages, regardless of the enumerated value being set to true. When the network omits this parameter from the SuspendConfig, the UE must continue normal RAN paging monitoring operations according to standard procedures.

[0121] The disableRANPaging parameter represents the network’s response to the UE’s earlier request sent via the RANPagingDisable-rxyz parameter in the UEAssistanceInformation message. Including this parameter grants the UE’s request to disable RAN paging monitoring, while omitting it denies the request. The network makes this decision based on various factors including network policies, current network load conditions, the UE’s service profile, mobility characteristics, and overall system optimization considerations.

[0122] Both the t380 and disableRANPaging parameters within SuspendConfig are marked as OPTIONAL with the "Need R" rule. The "Need R" designation specifies a release behavior that differs fundamentally from the "Need M" rule used in RRCReconfiguration messages. Under the "Need R" rule, if a parameter was configured in a previous RRCRelease message but is omitted in a subsequent RRCRelease message, the UE must release the previously configured value and revert to default behavior for that parameter. This rule applies independently to each parameter within the SuspendConfig.

[0123] This release mechanism provides the network with dynamic control over the UE’s RRC Inactive state behavior across multiple connection cycles. For example, if an initial RRCRelease message includes the disableRANPaging parameter, the UE disables RAN paging monitoring during that RRC Inactive period. If the UE later resumes its connection for data transmission and then receives another RRCRelease message that omits the disableRANPaging parameter, the UE must release the previous paging disable configuration and resume normal RAN paging monitoring in the subsequent RRC Inactive period. Similarly, the network can dynamically adjust the t380 timer value in each RRCRelease message or revert to default timing by omitting the parameter.

[0124] The "Need R" rule provides clean state management where each transition to RRC Inactive state establishes a fresh configuration based solely on the parameters present in that specific RRCRelease message. This eliminates ambiguity about whether previous configurations remain in effect and allows the network to adapt the UE’s power-saving configuration to changing network conditions, load patterns, or service requirements without requiring explicit revocation procedures.

[0125] The RRCRelease message with these enhancements completes the negotiation cycle for RRC Inactive state power optimization. After the UE receives authorization through the RRCInactive-AssistanceConfig in an RRCReconfiguration message, it can send its preferences through the UEAssistanceInformation message. The network then provides its final configuration decision through this enhanced RRCRelease message. This structured handshake maintains network control over radio resource management while accommodating the UE’s power-saving requirements where network conditions permit. The mechanism allows the network to grant power-saving configurations such as disabled RAN paging during periods of low network load or for specific UE types, then revoke them when network conditions change by simply modifying the parameters included in subsequent RRCRelease messages.

[0126] FIG. 12 is a diagram 1200 illustrating the structure and usage of the MICO Indication information element within REGISTRATION REQUEST and REGISTRATION ACCEPT messages for controlling RAN paging behavior. The MICO Indication IE provides a mechanism for the UE and network to negotiate the disabling of RAN paging through the addition of a new bit field within the existing IE structure.

[0127] The MICO Indication IE structure occupies a single octet within the NAS registration messages. Bits 8 through 5 contain the MICO indication Information Element Identifier (IEI) that identifies this particular IE type within the message structure. Bit 4 is designated as spare and set to 0. Bits 3 through 1 contain three distinct flag fields: DRP (Disable RAN Paging) at bit 3, SPRTI at bit 2, and RAAI at bit 1. The present disclosure introduces the DRP bit at position 3 as an enhancement to control RAN paging disable functionality.

[0128] The DRP bit operates bidirectionally with different semantic meanings depending on the direction of message transmission. In the UE-to-network direction, which corresponds to the REGISTRATION REQUEST message transmitted from the UE to the CN, the DRP bit functions as a request flag. When the UE sets this bit to a value of 1, it signals a request to disable RAN paging monitoring while in RRC Inactive state. When the UE sets this bit to 0, it indicates that the UE is not requesting to disable RAN paging, meaning normal RAN paging monitoring should continue to apply.

[0129] In the network-to-UE direction, which corresponds to the REGISTRATION ACCEPT message transmitted from the CN to the UE, the same DRP bit at position 3 functions as a grant or denial indicator. When the network sets this bit to 1 in the REGISTRATION ACCEPT message, it grants the UE’s request to disable RAN paging, thereby authorizing the UE to operate without monitoring RAN paging messages when in RRC Inactive state. When the network sets this bit to 0, it denies the request, requiring the UE to maintain normal RAN paging monitoring operations.

[0130] This bidirectional usage of a single bit field provides signaling efficiency by eliminating the need for separate request and response parameters. The REGISTRATION REQUEST and REGISTRATION ACCEPT messages already contain the MICO Indication IE for negotiating MICO mode features. By adding the DRP bit within this existing structure, the RAN paging disable feature integrates seamlessly into the established MICO indication framework without requiring new IE definitions or expanded message structures. The same IE and the same bit position serve both the request and response functions, with the interpretation depending solely on the message direction.

[0131] The network retains complete authority over the granting or denial of the RAN paging disable request. Upon receiving a REGISTRATION REQUEST with the DRP bit set to 1, the network evaluates the request based on its policies, current network conditions, the UE’s subscription profile, and / or operational requirements before setting the DRP bit value in the corresponding REGISTRATION ACCEPT message. This negotiation occurs during the NAS registration procedure, establishing the RAN paging monitoring configuration that will apply when the UE subsequently enters RRC Inactive state.

[0132] The negotiated DRP status becomes part of the UE’s context maintained by the CN. When the UE later transitions to RRC Inactive state, the CN utilizes this stored DRP status to make appropriate data handling decisions. As illustrated in FIG. 7, when the CN has granted the disable RAN paging request through this DRP bit negotiation and subsequently receives notification that the UE has entered RRC Inactive state, the CN recognizes that standard RAN paging procedures cannot be used to reach the UE. Consequently, the CN must buffer any incoming downlink data rather than attempting to trigger RAN paging, since the UE has been authorized to disable its RAN paging monitoring functionality based on the negotiated DRP configuration.

[0133] FIG. 13 is a diagram 1300 illustrating a consolidated procedure flow from the UE perspective for requesting RRC Inactive state configuration to optimize power efficiency. This flow diagram presents a high-level view that encompasses the various detailed mechanisms previously described in FIGs. 5 through 8, showing how a UE can request modifications to its RRC Inactive state behavior regardless of which specific signaling path is employed.

[0134] At Operation 1302, the UE initiates the procedure by sending a request message to a network node. This request message conveys the UE’s preferences for RRC Inactive state configuration and may include one or both of two distinct request types: a request to disable RAN paging monitoring while operating in RRC Inactive state, and a request for a specific value for the periodic RNA update timer. These two request types are independent, allowing the UE to include either request individually or both simultaneously based on its power optimization requirements.

[0135] The request message may be conveyed through different signaling mechanisms. When following the RAN-centric approach detailed in FIGs. 5 and 6, the request is carried in a UEAssistanceInformation message transmitted to the RAN, which requires prior authorization through an RRCReconfiguration message containing the RRCInactive-AssistanceConfig information element. Alternatively, when following the CN-centric approach illustrated in FIGs. 7 and 8, the request is carried in a REGISTRATION REQUEST message transmitted to the CN through NAS signaling, where the requests are negotiated during the registration procedure using the MICO Indication IE with the Disable RAN Paging bit.

[0136] At Operation 1304, the UE receives an RRCRelease message from the network node. This message commands the UE to transition from RRC Connected state to RRC Inactive state and conveys the network’s configuration decisions regarding the UE’s earlier requests. If the network grants the request to disable RAN paging, the RRCRelease message includes a disableRANPaging indication within the SuspendConfig. If the network accommodates the request for a specific periodic RNA update timer value, the RRCRelease message includes a periodicRNAU-TimerValue parameter that specifies the t380 timer duration. The network retains complete authority over whether to grant, modify, or deny the UE’s requests. The configured timer value may match the value requested by the UE, may be adjusted to a different value based on network constraints, or may be omitted if the network denies the request.

[0137] At Operation 1306, upon receiving the RRCRelease message, the UE executes the commanded state transition and enters RRC Inactive state. The UE releases active radio resources while the RAN retains the UE context, and the UE applies the configuration parameters received in the RRCRelease message to govern its subsequent behavior in RRC Inactive state.

[0138] At Operation 1308, while operating in RRC Inactive state, the UE implements the configured behavior according to the parameters received in Operation 1304. If the network granted the disable RAN paging request, the UE does not monitor RAN paging messages broadcast within its RNA. This eliminates the power consumption associated with periodically activating the receiver, decoding paging channels, and checking for matching I-RNTI values. Additionally, the UE performs periodic RNA update procedures using the configured periodic RNA update timer value. If the network granted the UE’s timer request, the configured value reflects the UE’s preference, allowing optimization of update frequency according to anticipated mobility patterns and power constraints.

[0139] This procedure demonstrates the complete negotiation cycle for RRC Inactive state power optimization from the UE perspective. The UE expresses its preferences through request messages using either RAN or CN signaling paths, receives the network’s configuration decisions through the RRCRelease message, and operates according to the granted configuration while in RRC Inactive state. The mechanism accommodates diverse deployment scenarios where different UE types may have varying requirements for RAN paging monitoring and RNA update frequency. UEs that primarily initiate communications can request to disable RAN paging monitoring to maximize battery life, while maintaining the rapid connection resumption capability that distinguishes RRC Inactive state from RRC Idle state. The network maintains control over granting such optimizations based on system-wide considerations, balancing individual UE power-saving requirements against broader network management objectives.

[0140] FIG. 14 illustrates a flow chart 1400 of a process for RRC Inactive enhancement. This process involves interactions between a network node (e.g., the base station 102) and a UE (e.g., the UE 104) .

[0141] At block 1402, the UE sends a request message to a network node, and the request message includes at least one of: a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, or a request for a value for a periodic RAN-based Notification Area (RNA) update timer.

[0142] At block 1404, the UE receives an RRC Release message from the network node instructing the UE to enter the RRC Inactive state, the RRC Release message including configuration information responsive to the request message.

[0143] At block 1406, the UE operates in the RRC Inactive state according to the configuration information.

[0144] In certain configurations, the request message may include a UE Assistance Information (UAI) message sent to a RAN node.

[0145] In certain configurations, prior to sending the UAI message, the UE may further receive an RRC Reconfiguration message from the RAN node including an RRC Inactive Assistance Configuration that authorizes the UE to send the UAI message with the at least one request.

[0146] In certain configurations, the RRC Inactive Assistance Configuration may include at least one of: a RAN Paging Disable authorization parameter, or a Periodic RNAU Timer Request authorization parameter.

[0147] In certain configurations, the RRC Inactive Assistance Configuration received in a first RRC Reconfiguration message may remain in effect when omitted from a subsequent RRC Reconfiguration message according to a maintain rule.

[0148] In certain configurations, the request message may include a Non-Access Stratum (NAS) Registration Request message sent to a Core Network (CN) node.

[0149] In certain configurations, the request to disable monitoring of RAN paging may be indicated by a Disable RAN Paging bit within a Mobile Initiated Connection Only (MICO) Indication Information Element of the NAS Registration Request message.

[0150] In certain configurations, the UE may further receive a Registration Accept message from the CN node, the Registration Accept message including the MICO Indication Information Element with the Disable RAN Paging bit indicating whether the request is granted.

[0151] In certain configurations, the NAS Registration Request message may include a requested value for a periodic registration timer without requesting MICO mode activation.

[0152] In certain configurations, the configuration information may include a disable RAN paging indication, and operating in the RRC Inactive state may include not monitoring RAN paging messages.

[0153] In certain configurations, the configuration information may include a configured value for the periodic RNA update timer, and operating in the RRC Inactive state may include performing periodic RNA updates according to the configured value.

[0154] In certain configurations, configuration information received in a first RRC Release message may be released when omitted from a subsequent RRC Release message according to a release rule.

[0155] FIG. 15 illustrates a flow chart 1500 of another process for RRC Inactive enhancement. This process involves interactions between a network node (e.g., the base station 102) and a UE (e.g., the UE 104) .

[0156] At block 1502, the network node receives a request message from a user equipment (UE) , and the request message includes at least one of: a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, or a request for a value for a periodic RAN-based Notification Area (RNA) update timer.

[0157] At block 1504, the network node determines configuration information for the RRC Inactive state based on the request message.

[0158] At block 1506, the network node sends an RRC Release message to the UE instructing the UE to enter the RRC Inactive state, the RRC Release message including the determined configuration information.

[0159] In certain configurations, the network node may be a RAN node, and the request message may include a UE Assistance Information (UAI) message.

[0160] In certain configurations, prior to receiving the UAI message, the RAN node may further send an RRC Reconfiguration message to the UE including an RRC Inactive Assistance Configuration that authorizes the UE to send the UAI message.

[0161] In certain configurations, the RRC Inactive Assistance Configuration may include at least one of: a RAN Paging Disable authorization parameter, or a Periodic RNAU Timer Request authorization parameter.

[0162] In certain configurations, the RRC Inactive Assistance Configuration sent in a first RRC Reconfiguration message may remain in effect when omitted from a subsequent RRC Reconfiguration message according to a maintain rule.

[0163] In certain configurations, the determining may include evaluating at least one of: current network load conditions, the UE's subscription profile, mobility management policies, or system optimization requirements.

[0164] In certain configurations, the network node may be a Core Network (CN) node, the request message may include a Non-Access Stratum (NAS) Registration Request message, and the process may further include forwarding configuration decisions to a RAN node for inclusion in the RRC Release message.

[0165] In certain configurations, the request to disable monitoring of RAN paging may be indicated by a Disable RAN Paging bit within a Mobile Initiated Connection Only (MICO) Indication Information Element of the NAS Registration Request message.

[0166] In certain configurations, the CN node may further send a Registration Accept message to the UE, the Registration Accept message including the MICO Indication Information Element with the Disable RAN Paging bit indicating whether the request is granted.

[0167] In certain configurations, the CN node may further receive a suspend indication from a RAN node indicating the UE has entered the RRC Inactive state; and when the request to disable monitoring of RAN paging was granted, buffer downlink data destined for the UE instead of triggering RAN paging.

[0168] In certain configurations, the NAS Registration Request message may include a requested value for a periodic registration timer without requesting MICO mode activation, and the process may further include sending a Registration Accept message with a configured value for the periodic registration timer.

[0169] In certain configurations, the configuration information may include at least one of: a disable RAN paging indication instructing the UE not to monitor RAN paging in the RRC Inactive state, or a configured value for the periodic RNA update timer.

[0170] In certain configurations, configuration information included in a first RRC Release message may be released when omitted from a subsequent RRC Release message according to a release rule.

[0171] The UE implementing the RRC Inactive state enhancement procedures illustrated in FIGs. 5-15 may comprise hardware components similar to those of the UE 250 described in FIG. 2. Specifically, the UE may include one or more antennas 252 coupled to receivers 254RX and transmitters 254TX for wireless communication with network nodes. The UE may further include an RX processor 256 and TX processor 268 implementing physical layer functionality for signal processing, modulation, and demodulation of the messages exchanged in the procedures of FIGs. 5-15, such as the RRCReconfiguration messages, UEAssistanceInformation messages, RRCRelease messages, and NAS Registration messages. A controller / processor 259, associated with memory 260 storing program codes and data, may implement the higher layer protocols including the RRC layer functionality for processing the RRCInactive-AssistanceConfig authorization (FIGs. 5-6, 9) , generating UAI messages with RANPagingDisable and requestedPeriodicRNAU-TimerValue parameters (FIGs. 5-6, 10) , and the NAS layer functionality for sending Registration Request messages with the Disable RAN Paging bit in the MICO Indication IE (FIGs. 7-8, 12) .

[0172] When operating according to the enhanced RRC Inactive state procedures, the controller / processor 259 may execute stored program codes to determine whether to request disabling of RAN paging monitoring and / or specific periodic RNA update timer values based on the UE's traffic patterns and power optimization requirements. Upon receiving the RRCRelease message with configuration information (FIGs. 11, 13-15) , the controller / processor 259 may configure the UE's behavior in RRC Inactive state, including controlling whether the receivers 254RX are activated for RAN paging monitoring and managing the timers for periodic RNA updates. The memory 260 may store the received configuration parameters, including the disableRANPaging indication and periodicRNAU-TimerValue, maintaining or releasing these configurations according to the ``Need M" and ``Need R" rules respectively as described in the enhanced message structures.

[0173] The network entities implementing the RRC Inactive enhancement procedures of FIGs. 5-15 may include both RAN nodes and CN nodes with specialized hardware configurations. The RAN nodes, such as base stations 102 or 210, may comprise antennas 220 coupled to receivers 218RX and transmitters 218TX for wireless communication with UEs. These RAN nodes may include an RX processor 270 and TX processor 216 for physical layer processing of the control messages exchanged in the procedures, including RRCReconfiguration messages containing the RRCInactive-AssistanceConfig (FIG. 9) , receiving and processing UEAssistanceInformation messages (FIG. 10) , and transmitting RRCRelease messages with SuspendConfig parameters (FIG. 11) . A controller / processor 275 associated with memory 276 may implement the RRC layer functionality to evaluate UAI requests, determine whether to grant RAN paging disable and specific RNAU timer values based on network policies and conditions, and generate appropriate RRCRelease configurations. The controller / processor 275 may also manage interfaces with the CN for exchanging suspend requests and responses (FIG. 7) .

[0174] The CN nodes involved in these procedures, such as the AMF 192 for NAS signaling or other CN entities managing data forwarding, may comprise specialized processing hardware including processors executing network function software, memory systems storing UE context information including negotiated RAN paging disable status, and network interface hardware for communication with RAN nodes and external data networks. When implementing the CN-centric approach (FIGs. 7-8) , the CN node processors may evaluate Registration Request messages containing the Disable RAN Paging bit, make authorization decisions based on subscription profiles and network policies, and generate Registration Accept messages with appropriate MICO Indication IE settings (FIG. 12) . Upon receiving suspend indications from RAN nodes, the CN processors may determine whether to buffer incoming downlink data based on the stored RAN paging disable status, implementing the data handling logic shown in FIG. 7. These CN nodes may include high-capacity memory systems for buffering downlink data when RAN paging is disabled, and high-speed network interfaces for eventual data delivery when the UE initiates communication from RRC Inactive state.

[0175] It is understood that the specific order or hierarchy of blocks in the processes  / flowcharts disclosed is an illustration of exemplary approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes  / flowcharts may be rearranged. Further, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0176] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” The word “exemplary” is used herein to mean “serving as an example, instance, or illustration. ” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Unless specifically stated otherwise, the term “some” refers to one or more. Combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” and “A, B, C, or any combination thereof” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any such combinations may contain one or more member or members of A, B, or C. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. The words “module, ” “mechanism, ” “element, ” “device, ” and the like may not be a substitute for the word “means. ” As such, no claim element is to be construed as a means plus function unless the element is expressly recited using the phrase “means for. ”

Claims

1.A method of wireless communication performed by a user equipment (UE) , comprising:sending a request message to a network node, wherein the request message comprises at least one of:a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, ora request for a value for a periodic RAN-based Notification Area (RNA) update timer;receiving an RRC Release message from the network node instructing the UE to enter the RRC Inactive state, the RRC Release message including configuration information responsive to the request message; andoperating in the RRC Inactive state according to the configuration information.2.The method of claim 1, wherein the request message comprises a UE Assistance Information (UAI) message sent to a RAN node.3.The method of claim 2, further comprising:prior to sending the UAI message, receiving an RRC Reconfiguration message from the RAN node including an RRC Inactive Assistance Configuration that authorizes the UE to send the UAI message with the at least one request.4.The method of claim 3, wherein the RRC Inactive Assistance Configuration comprises at least one of:a RAN Paging Disable authorization parameter, ora Periodic RNAU Timer Request authorization parameter.5.The method of claim 3, wherein the RRC Inactive Assistance Configuration received in a first RRC Reconfiguration message remains in effect when omitted from a subsequent RRC Reconfiguration message according to a maintain rule.6.The method of claim 1, wherein the request message comprises a Non-Access Stratum (NAS) Registration Request message sent to a Core Network (CN) node.7.The method of claim 6, wherein:the request to disable monitoring of RAN paging is indicated by a Disable RAN Paging bit within a Mobile Initiated Connection Only (MICO) Indication Information Element of the NAS Registration Request message.8.The method of claim 7, further comprising:receiving a Registration Accept message from the CN node, the Registration Accept message including the MICO Indication Information Element with the Disable RAN Paging bit indicating whether the request is granted.9.The method of claim 6, wherein:the NAS Registration Request message includes a requested value for a periodic registration timer without requesting MICO mode activation.10.The method of claim 1, wherein:the configuration information includes a disable RAN paging indication, andoperating in the RRC Inactive state comprises not monitoring RAN paging messages.11.The method of claim 1, wherein:the configuration information includes a configured value for the periodic RNA update timer, andoperating in the RRC Inactive state comprises performing periodic RNA updates according to the configured value.12.The method of claim 1, wherein configuration information received in a first RRC Release message is released when omitted from a subsequent RRC Release message according to a release rule.13.A method of wireless communication performed by a network node, comprising:receiving a request message from a user equipment (UE) , wherein the request message comprises at least one of:a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, ora request for a value for a periodic RAN-based Notification Area (RNA) update timer;determining configuration information for the RRC Inactive state based on the request message; andsending an RRC Release message to the UE instructing the UE to enter the RRC Inactive state, the RRC Release message including the determined configuration information.14.The method of claim 13, wherein:the network node is a RAN node, andthe request message comprises a UE Assistance Information (UAI) message.15.The method of claim 14, further comprising:prior to receiving the UAI message, sending an RRC Reconfiguration message to the UE including an RRC Inactive Assistance Configuration that authorizes the UE to send the UAI message.16.The method of claim 15, wherein the RRC Inactive Assistance Configuration comprises at least one of:a RAN Paging Disable authorization parameter, ora Periodic RNAU Timer Request authorization parameter.17.The method of claim 15, wherein the RRC Inactive Assistance Configuration sent in a first RRC Reconfiguration message remains in effect when omitted from a subsequent RRC Reconfiguration message according to a maintain rule.18.The method of claim 14, wherein the determining comprises evaluating at least one of:current network load conditions,the UE's subscription profile,mobility management policies, orsystem optimization requirements.19.The method of claim 13, wherein:the network node is a Core Network (CN) node,the request message comprises a Non-Access Stratum (NAS) Registration Request message, andthe method further comprises forwarding configuration decisions to a RAN node for inclusion in the RRC Release message.20.The method of claim 19, wherein:the request to disable monitoring of RAN paging is indicated by a Disable RAN Paging bit within a Mobile Initiated Connection Only (MICO) Indication Information Element of the NAS Registration Request message.21.The method of claim 20, further comprising:sending a Registration Accept message to the UE, the Registration Accept message including the MICO Indication Information Element with the Disable RAN Paging bit indicating whether the request is granted.22.The method of claim 19, further comprising:receiving a suspend indication from a RAN node indicating the UE has entered the RRC Inactive state; andwhen the request to disable monitoring of RAN paging was granted, buffering downlink data destined for the UE instead of triggering RAN paging.23.The method of claim 19, wherein:the NAS Registration Request message includes a requested value for a periodic registration timer without requesting MICO mode activation, andthe method further comprises sending a Registration Accept message with a configured value for the periodic registration timer.24.The method of claim 13, wherein the configuration information comprises at least one of:a disable RAN paging indication instructing the UE not to monitor RAN paging in the RRC Inactive state, ora configured value for the periodic RNA update timer.25.The method of claim 13, wherein configuration information included in a first RRC Release message is released when omitted from a subsequent RRC Release message according to a release rule.26.An apparatus for wireless communication, the apparatus being a user equipment (UE) , comprising:a memory; andat least one processor coupled to the memory and configured to:send a request message to a network node, wherein the request message comprises at least one of:a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, ora request for a value for a periodic RAN-based Notification Area (RNA) update timer;receive an RRC Release message from the network node instructing the UE to enter the RRC Inactive state, the RRC Release message including configuration information responsive to the request message; andoperate in the RRC Inactive state according to the configuration information.27.An apparatus for wireless communication, the apparatus being a network node, comprising:a memory; andat least one processor coupled to the memory and configured to:receive a request message from a user equipment (UE) , wherein the request message comprises at least one of:a request to disable monitoring of Radio Access Network (RAN) paging when the UE operates in a Radio Resource Control (RRC) Inactive state, ora request for a value for a periodic RAN-based Notification Area (RNA) update timer;determine configuration information for the RRC Inactive state based on the request message; andsend an RRC Release message to the UE instructing the UE to enter the RRC Inactive state, the RRC Release message including the determined configuration information.

Images