Enhanced user equipment state transitions and dynamic discontinuous reception procedures

Abstract

Methods, systems, and devices are described for wireless communication. A user equipment (UE) can operate in a first state and transmit, to a network entity, a request to transition from the first state to a second state based on data activity between the UE and the network entity. The UE can transition from the first state to the second state based on transmitting the request to the network entity. The UE can perform the state transition based on a configuration from the network entity. The network entity can configure the UE to transition the state autonomously based on transmitting the request or can configure the UE to receive a response message from the network before transitioning the state. The UE can request to transition to a particular state, which can be selected by the UE.

Description

[0001] Cross-referencing

[0002] This patent application claims priority to U.S. Non-Provisional Patent Application No. 19 / 173,309, filed April 8, 2025, entitled “Enhanced User Equipment State Transitions and Dynamic Discontinuous Reception Process,” which claims the benefit of U.S. Provisional Patent Application No. 63 / 633,034, filed April 11, 2024, entitled “Enhanced User Equipment State Transitions,” which has been assigned to the assignee of this application and is expressly incorporated herein by reference. This patent application claims the benefit of U.S. Provisional Patent Application No. 63 / 632,987, filed April 11, 2024, entitled “DYNAMICDISCONTINUOUS RECEPTION PROCEDURES”, which has been assigned to the assignee of this application and is expressly incorporated herein by reference. Technical Field

[0003] The following pertains to wireless communications, including enhanced user equipment (UE) state transitions and dynamic discontinuous reception processes. Background Technology

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, message sending and receiving, and broadcasting. These systems can support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth-generation (4G) systems (such as Long Term Evolution (LTE) systems, LTE-A Advanced (LTE-A) systems, or LTE-A Pro systems) and fifth-generation (5G) systems (which may be referred to as New Radio (NR) systems). These systems may employ technologies such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), or Discrete Fourier Transform Extended Orthogonal Frequency Division Multiplexing (DFT-S-OFDM). A wireless multiple access communication system may include one or more base stations, each supporting wireless communication for communication devices, which may be referred to as User Equipment (UE). Summary of the Invention

[0005] The described technology relates to improved methods, systems, devices, and apparatuses for supporting enhanced user equipment (UE) state transitions. For example, the described technology enables a UE to operate in a first state and send a request to a network entity for a transition from the first state to a second state based on data activity between the UE and the network entity. Thus, the UE can transition from the first state to the second state based on sending the request to the network entity. In some examples, the UE can perform the state transition based on configuration from the network. For example, the network can configure the UE to proactively transition the state based on sending the request, or the UE can be configured to receive a response message from the network before transitioning the state. Additionally, the UE can determine the state transition request based on a machine learning model, and can also train the model based on feedback from the network entity.

[0006] A method for wireless communication by a UE is described. The method may include: when operating in a first state, sending a request to a network entity to transition from the first state to a second state based on data activity between the UE and the network entity; and transitioning from the first state to the second state based on sending the request.

[0007] A UE for wireless communication is described. The UE may include one or more memories storing processor-executable code and one or more processors coupled to the one or more memories. The one or more processors may be able to operate individually or jointly to execute the code so that the UE: when operating in a first state, sends a request to the network entity for a transition from the first state to a second state based on data activity between the UE and the network entity; and transitions from the first state to the second state based on sending the request.

[0008] Another UE for wireless communication is described. The UE may include: components for sending a request to a network entity to transition from the first state to a second state based on data activity between the UE and the network entity when operating in a first state; and components for transitioning from the first state to the second state based on sending the request.

[0009] A non-transitory computer-readable medium storing code for wireless communication is described. The code may include instructions executable by one or more processors to: when operating in a first state, send a request to the network entity for a transition from the first state to a second state based on data activity between the UE and the network entity; and transition from the first state to the second state based on sending the request.

[0010] In some examples of the methods, UEs, and nontransitory computer-readable media described herein, the request for transition from the first state to the second state includes a request value for an inactivity timer at the UE, and the UE transitions from the first state to the second state based on the expiration of the inactivity timer.

[0011] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving from the network entity an indication of a set of inactive timer values ​​associated with a transition from the first state to the second state, wherein the request includes an indication of a first inactive timer value in the set of inactive timer values, the first inactive timer value being selected by the UE based on receiving the indication of the set of inactive timer values.

[0012] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving a response message from the network entity based on receiving the indication and sending the request, wherein the response message indicates that: the request may be accepted by the network entity; an indication of a second inactive timer value, different from the first inactive timer value, which the UE may use to transition from the first state to the second state; or any combination thereof, wherein the transition from the first state to the second state may be further based on receiving the response message.

[0013] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state based on data activity between the UE and the network entity; receiving a response message from the network entity based on sending the second request, wherein the response message indicates that the second request may be rejected by the network entity; and avoiding a transition from the third state to the fourth state based on receiving the response message.

[0014] The methods described herein, some examples of UEs and nontransitory computer-readable media may also include operations, features, components or instructions for sending an indication of a request state for the second state via the request, wherein the request state may be associated with: a sleep state, a wake-up state, a state associated with a target bandwidth portion, a radio resource control (RRC) state, a state associated with the deactivation of a secondary cell, or any combination thereof.

[0015] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving a control message from the network entity, the control message configuring whether the UE may transition from the first state to the second state based on the expiration of a timer, or may avoid transitioning from the first state to the second state based on the expiration of the timer, wherein the timer may be associated with receiving a response message from the network entity; and starting the timer based on sending the request.

[0016] The methods described herein, UEs, and some examples of non-transitory computer-readable media may also include operations, features, components, or instructions for transitioning from the first state to the second state based on the control message, on the basis that the response message was not received from the network entity before the timer expires.

[0017] The methods described herein, UEs, and some examples of non-transitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving the response message from the network entity before the timer expires; and, based on receiving the response message, transitioning from the first state to the second state according to the control message.

[0018] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving a response message from the network entity before the timer expires, wherein the response message includes an indication state that the UE may use for the second state; and, based on receiving the response message, transitioning from the first state to the second state according to the indication state.

[0019] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state based on data activity between the UE and the network entity; receiving an indication via the response message that the network entity rejects the second request from the UE; and avoiding a transition from the third state to the fourth state based on receiving the response message.

[0020] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: determining predicted data activity between the UE and the network entity based on a machine learning model at the UE, wherein sending the request may be based on the predicted data activity satisfying a threshold; receiving a feedback message associated with the request from the network entity based on sending the request; and training the machine learning model based on the feedback message received from the network entity.

[0021] The methods described herein, examples of UEs, and non-transitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving a control message configuring a timer associated with sending the request; starting the timer based on sending the request; and avoiding sending a second request for transition from the third state to the fourth state before the timer expires.

[0022] The described technology further relates to improved methods, systems, devices, and apparatuses supporting Dynamic Discontinuous Reception (DRX) procedures. For example, the described technology enables a User Equipment (UE) to operate during the active duration of a DRX cycle and send a request to a network entity for transitioning to an inactive period of the DRX cycle based on data activity between the UE and the network entity. Thus, the UE can transition to the inactive period of the DRX cycle based on sending the request to the network entity. In some examples, the UE can perform the transition based on configuration from the network. For example, the network entity can configure the UE to proactively transition to the inactive period based on sending the request, or the UE can be configured to receive a response message from the network before transitioning to the inactive period. Additionally, the UE can determine the sending request based on a machine learning model, and can also train the model based on feedback from the network entity.

[0023] A method for wireless communication by a UE is described. The method may include: during an active period of a DRX cycle, sending a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity; and transitioning to the inactive period of the DRX cycle based on sending the request.

[0024] A UE for wireless communication is described. The UE may include one or more memories storing processor-executable code and one or more processors coupled to the one or more memories. The one or more processors may be able to operate individually or jointly to execute the code so that the UE: during an active period of a DRX cycle, sends a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity; and transitions to the inactive period of the DRX cycle based on sending the request.

[0025] Another UE for wireless communication is described. The UE may include: components for sending a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity during an active period of the DRX cycle; and components for transitioning to the inactive period of the DRX cycle based on sending the request.

[0026] A non-transitory computer-readable medium storing code for wireless communication is described. The code may include instructions executable by one or more processors to: during an active period of a DRX cycle, send a request for transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity; and transition to the inactive period of the DRX cycle based on sending the request.

[0027] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving from the network entity an indication of a set of DRX inactive timer values ​​associated with an inactive period transitioning to the DRX cycle, wherein the request includes an indication of a first DRX inactive timer value in the set of DRX inactive timer values, the first DRX inactive timer value being selected by the UE based on receiving the indication of the set of DRX inactive timer values.

[0028] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving a response message from the network entity based on receiving the indication and sending the request, wherein the response message indicates that: the request may be accepted by the network entity; an indication of a second DRX inactivity timer value, which the UE may use to transition to the inactivity period of the DRX cycle, from a set of DRX inactivity timer values, the second DRX inactivity timer value being different from the first DRX inactivity timer value; or both, and wherein the transition to the inactivity period of the DRX cycle may be further based on receiving the response message.

[0029] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: during a second active period of a second DRX cycle, sending a second request for transition to a second inactive period of the second DRX cycle based on data activity between the UE and the network entity; receiving a second response message from the network entity based on sending the second request, wherein the second response message indicates that the second request may be rejected by the network entity; and avoiding transition to the second inactive period of the second DRX cycle based on receiving the second response message.

[0030] The methods described herein, examples of UEs, and non-transitory computer-readable media may also include operations, features, components, or instructions for sending an indication of the duration of the inactivity period associated with the DRX cycle via the request.

[0031] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving a control message from the network entity, the control message configuring whether the UE may transition to the inactive period of the DRX cycle based on the expiration of a timer, or may avoid transitioning to the inactive period of the DRX cycle based on the expiration of the timer, wherein the timer may be associated with receiving a response message from the network entity; and starting the timer based on sending the request.

[0032] The methods described herein, examples of UEs, and non-transitory computer-readable media may also include operations, features, components, or instructions for transitioning to the inactive period of the DRX cycle based on the control message, provided that the response message was not received from the network entity before the timer expires.

[0033] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving a response message from the network entity before the timer expires, wherein the response message includes an indication of the duration of the inactive period that the UE may use in the DRX cycle; and, based on receiving the response message, transitioning to the inactive period of the DRX cycle according to the control message.

[0034] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: during a second active period of a second DRX cycle, sending a second request for transition to a second inactive period of the second DRX cycle based on data activity between the UE and the network entity; receiving an indication via a second response message regarding the network entity's rejection of the second request from the UE; and avoiding transition to the second inactive period of the second DRX cycle based on receiving the second response message.

[0035] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for receiving an indication of a set of DRX periodic configurations from the network entity, wherein the request includes a first DRX periodic configuration of the set of DRX periodic configurations, the first DRX periodic configuration being selected by the UE based on receiving the indication of the set of DRX periodic configurations.

[0036] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for receiving from the network entity an indication of a DRX period configuration comprising a set of active periods and a set of inactive periods, wherein the request includes a parameter identifying a subgroup of active periods in which the UE may be active.

[0037] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for determining an inactive period of the DRX cycle based on the presence of an active timer value in the configuration of the DRX cycle.

[0038] The methods described herein, examples of UEs, and non-transitory computer-readable media may also include operations, features, components, or instructions for performing the following: determining a second inactive period to avoid transitioning to the DRX period based on the absence of an active timer value in the configuration of the DRX period, until a second request to transition to the second inactive period is sent, or until a command is received from the network entity.

[0039] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for receiving a response message based on sending the request before transitioning to the inactive period, wherein the response message indicates whether the UE may transition to the inactive period of the DRX cycle according to an activity timer value, or may avoid transitioning to the inactive period of the DRX cycle until the request is sent.

[0040] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: determining predicted data activity between the UE and the network entity based on a machine learning model at the UE, wherein sending the request may be based on the predicted data activity satisfying a threshold; receiving a feedback message associated with the request from the network entity based on sending the request; and training the machine learning model based on the feedback message received from the network entity.

[0041] The methods described herein, examples of UEs, and nontransitory computer-readable media may also include operations, features, components, or instructions for performing the following: receiving a control message configuring a timer associated with sending the request; starting the timer based on sending the request; and, based on receiving the control message, avoiding sending a second request for a second inactive period transitioning to the DRX cycle before the timer expires.

[0042] Some examples of the methods, UEs, and nontransitory computer-readable media described herein may also include operations, features, components, or instructions for performing the following: receiving a control message that configures a default duration for the UE to use for the inactive period of the DRX cycle, and wherein the UE uses the default duration for the inactive period based on the absence of a duration in the request.

[0043] In some examples of the methods, UEs, and nontransitory computer-readable media described herein, for the inactivity period and at least a second inactivity period of the DRX cycle, the UE uses a first duration that can be indicated via the request or via a response message from the network entity, based on the absence of a second duration in a second request to transition to the second inactivity period. Attached Figure Description

[0044] Figure 1 Examples of wireless communication systems supporting enhanced user equipment (UE) state transitions and dynamic discontinuous reception (DRX) procedures according to one or more aspects of this disclosure are shown.

[0045] Figure 2 Examples of wireless communication systems supporting enhanced UEs and dynamic DRX process state transitions according to one or more aspects of this disclosure are shown.

[0046] Figure 3 An example of a process flow supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown.

[0047] Figure 4 An example of a DRX cycle supporting a dynamic DRX process is shown according to one or more aspects of this disclosure.

[0048] Figure 5 An example of a process flow supporting a dynamic DRX process is shown according to one or more aspects of this disclosure.

[0049] Figure 6 A block diagram of an apparatus supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown.

[0050] Figure 7 A block diagram of a communication manager supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown.

[0051] Figure 8 A block diagram of an apparatus supporting a dynamic DRX process according to one or more aspects of this disclosure is shown.

[0052] Figure 9 A block diagram of a communication manager supporting dynamic DRX procedures according to one or more aspects of this disclosure is shown.

[0053] Figure 10 A diagram of a system including an apparatus supporting enhanced UE state transitions and dynamic DRX procedures, according to one or more aspects of this disclosure, is shown.

[0054] Figures 11 to 13 A flowchart illustrating a method for supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown.

[0055] Figures 14 to 16 A flowchart illustrating a method for supporting a dynamic DRX process according to one or more aspects of this disclosure is shown. Detailed Implementation

[0056] In some wireless communication systems, user equipment (UE) can operate according to various states. For example, a UE can operate according to various discontinuous communication states (e.g., active state of discontinuous reception (DRX), inactive state of DRX), bandwidth configuration states (e.g., bandwidth portion (BWP) state), data inactivity states (e.g., radio resource control (RRC) state, RRC inactive, RRC idle), and secondary cell (SCell) states (e.g., SCell active, SCell deactivated), etc. In some cases, the UE can be configured to trigger a transition from one state to another using various inactivity timers (e.g., DRX inactivity timer, BWP inactivity timer, data inactivity timer, SCell deactivated timer). An inactivity timer can be activated (e.g., initiated) in response to an event such as identifying that no data is being actively transmitted between the UE and a network entity. In some cases, if the UE fails to identify any data for communication within the duration of an inactivity timer (e.g., before the timer expires), the UE may transition from a first state to a second state (e.g., from an active state to a sleep state, or from a first active BWP to a second active BWP). However, such inactivity timers can be configured statically or semi-statically by higher-layer signaling (e.g., RRC signaling) and may be relatively difficult to reconfigure (e.g., due to increased signaling overhead). Furthermore, a single inactivity timer can be applied to a wide range of applications (e.g., associated with various service conditions, or with different power state change modes) and may be relatively inefficient for at least some applications.

[0057] According to one or more aspects described herein, a UE can be configured to support dynamic state transitions based on data activity. For example, a UE can operate in a first state and can send a message to a network entity requesting a transition from the first state to a second state based on data activity (e.g., a level of data inactivity) between the UE and the network entity. The UE can transition from the first state to the second state based on sending the request. By sending a request and transitioning states based on that request, the UE can perform dynamic state transitions, which can support more efficient resource utilization. For example, the UE can adjust the duration of a given state in real time, which can support reduced power consumption, increased battery life, improved data rates, and other benefits.

[0058] Additionally, in some examples, the network entity may configure a set of inactive timer values, and the UE may indicate a requested value for subsequent inactive timer periods. Additionally or alternatively, the UE may send a direct indication of the requested value or the next state of the request. In some examples, the network entity may send a control message indicating a dynamic state transition configuration at the UE. The network entity may also send a response to the UE to accept, partially accept (e.g., accept the request for a transition but reject the requested value for the timer duration), or reject the UE's request. Additionally, in some examples, the UE may be configured using machine learning models (e.g., artificial intelligence (AI) algorithms, neural networks) that support determining when to send a request. By sending a request with selected values, the UE can further reduce power consumption based on dynamically adjusting (e.g., optimizing) its inactive timer to adapt to various operating conditions. Furthermore, by using machine learning models, the UE can predict when an adjustable inactive timer will save power, increase data rates, or achieve other benefits, which can further improve efficiency in wireless communication systems.

[0059] According to one or more aspects described herein, wireless communication systems can utilize signaling mechanisms to support dynamic configuration of DRX cycles based on data activity between the UE and network entities. For example, when operating during an active period of a DRX cycle, the UE can send a request message (e.g., a sleep request or sleep indication) to the network entity, requesting a transition to an inactive period of the DRX cycle based on data activity (e.g., a data inactivity level) between the UE and the network entity. Thus, the UE can transition to an inactive period of the DRX cycle based on sending the request. By sending the request and transitioning to an inactive period of the DRX cycle, the UE can switch to an inactive period on demand (e.g., before a pre-configured timer expires), thereby supporting more efficient resource utilization. For example, the UE can enter an inactive period for a relatively long duration, thereby supporting reduced power consumption, increased battery life, reduced network traffic, and other benefits.

[0060] Additionally, in some examples, a network entity may configure (e.g., pre-configure) a set of DRX inactivity timer values, and the UE may request a DRX inactivity timer value from that set for a subsequent inactivity period (e.g., a value for the DRX inactivity timer). Additionally or alternatively, the UE may request a direct indication of the duration of the request for a subsequent inactivity period (e.g., a requested sleep duration). In some examples, the network may send one or more control messages configuring dynamic DRX cycle transitions (such as based on UE behavior that sends the request). The network entity may also send a response to the UE to accept, partially accept (e.g., accept the request to enter sleep but reject the requested sleep duration), or reject the UE request. Additionally, in some examples, a machine learning model (e.g., an artificial intelligence (AI) algorithm, a neural network) may be used to configure the UE to support determining (e.g., predicting) when the UE should enter an inactivity period and how long the UE should remain inactive during the inactivity period.

[0061] The various aspects of this disclosure are first described in the context of a wireless communication system. These aspects are further illustrated and described with reference to DRX cycles, process flows, apparatus diagrams, system diagrams, and flowcharts relating to enhanced UE state transitions.

[0062] Figure 1 An example of a wireless communication system 100 supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown. The wireless communication system 100 may include one or more devices, such as one or more network devices (e.g., network entity 105), one or more UEs 115, and a core network 130. In some examples, the wireless communication system 100 may be a Long Term Evolution (LTE) network, an Advanced LTE (LTE-A) network, an LTE-A Pro network, a New Radio (NR) network, or a network operating under other systems and radio technologies, including future systems and radio technologies not explicitly mentioned herein.

[0063] Network entity 105 may be distributed across a geographical area to form wireless communication system 100, and may include devices employing different forms or having different capabilities. In various examples, network entity 105 may be referred to as a network element, mobility element, radio access network (RAN) node, or network equipment, etc. In some examples, network entity 105 and UE 115 may wirelessly communicate via communication link 125 (e.g., a radio frequency (RF) access link). For example, network entity 105 may support coverage area 110 (e.g., a geographical coverage area) within which UE 115 and network entity 105 may establish communication link 125. Coverage area 110 may be an example of a geographical area within which network entity 105 and UE 115 may support the transmission of signals according to one or more radio access technologies (RATs).

[0064] UE 115 can be distributed throughout the coverage area 110 of wireless communication system 100, and each UE 115 can be stationary or mobile, or stationary and mobile at different times. UE 115 can be devices in different forms or with different capabilities. Figure 1 Examples of UE 115 are illustrated herein. The UE 115 described herein may be able to support communication with various types of devices in the wireless communication system 100 (e.g., other wireless communication devices, including UE 115 or network entity 105), such as... Figure 1 As shown.

[0065] As described herein, a node in the wireless communication system 100 (which may be referred to as a network node or wireless node) may be a network entity 105 (e.g., any network entity described herein), a UE 115 (e.g., any UE described herein), a network controller, apparatus, device, computing system, one or more components, or another suitable processing entity configured to perform any of the techniques described herein. For example, a node may be UE 115. As another example, a node may be network entity 105. As another example, a first node may be configured to communicate with a second node or a third node. In one aspect of this example, the first node may be UE 115, the second node may be network entity 105, and the third node may be UE 115. In another aspect of this example, the first node may be UE 115, the second node may be network entity 105, and the third node may be network entity 105. In other aspects of this example, the first node, the second node, and the third node may be different from these examples. Similarly, references to UE 115, network entity 105, device, equipment, computing system, etc., may include disclosures of UE 115, network entity 105, device, equipment, computing system, etc., as nodes. For example, a disclosure that UE 115 is configured to receive information from network entity 105 also discloses that a first node is configured to receive information from a second node.

[0066] In some examples, network entity 105 may communicate with core network 130, communicate with each other, or both. For example, network entity 105 may communicate with core network 130 via backhaul communication link 120 (e.g., according to S1, N2, N3, or other interface protocols). In some examples, network entities 105 may communicate with each other directly (e.g., directly between network entities 105) or indirectly (e.g., via core network 130) via backhaul communication link 120 (e.g., according to X2, Xn, or other interface protocols). In some examples, network entities 105 may communicate with each other via midhaul communication link 162 (e.g., according to midhaul interface protocol) or fronthaul communication link 168 (e.g., according to fronthaul interface protocol) or any combination thereof. The backhaul communication link 120, midhaul communication link 162, or fronthaul communication link 168 may be one or more wired links (e.g., electrical links, fiber optic links) or one or more wireless links (e.g., radio links, wireless optical links), etc., or various combinations thereof, or may include one or more wired links (e.g., electrical links, fiber optic links) or one or more wireless links (e.g., radio links, wireless optical links), etc., or various combinations thereof. UE 115 may communicate with the core network 130 via communication link 155.

[0067] One or more network entities or network equipment described herein as network entity 105 or network equipment may include or be referred to as base station 140 (e.g., transceiver base station, radio base station, NR base station, access point, radio transceiver, node B, eNodeB (eNB), next-generation node B or gigabit node B (any of which may be referred to as gNB), 5G NB, next-generation eNB (ng-eNB), home node B, home evolution node B, or other suitable terms). In some examples, network entity 105 (e.g., base station 140) may be implemented in an aggregated (e.g., monolithic, standalone) base station architecture that may be configured to utilize a protocol stack physically or logically integrated within a single network entity (e.g., network entity 105 or a single RAN node, such as base station 140).

[0068] In some examples, network entity 105 may be implemented in a decomposed architecture (e.g., a decomposed base station architecture, a decomposed RAN architecture) that can be configured to utilize protocol stacks physically or logically distributed across multiple network entities (e.g., network entity 105) such as an Integrated Access Backhaul (IAB) network, an Open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance), or a Virtualized RAN (vRAN) (e.g., a Cloud RAN (C-RAN)). For example, network entity 105 may include one or more of the following: a Central Unit (CU) such as CU 160, a Distributed Unit (DU) such as DU 165, a Radio Unit (RU) such as RU 170, a RAN Intelligent Controller (RIC) such as RIC 175 (e.g., a near real-time RIC (near RT RIC), a non-real-time RIC (non-RT RIC)), a Service Management and Orchestration (SMO) system such as SMO system 180, or any combination thereof. RU 170 may also be referred to as a radio headend, intelligent radio headend, remote radio headend (RRH), remote radio unit (RRU), or transmit / receive point (TRP). One or more components of network entity 105 in a decomposed RAN architecture may be co-located, or one or more components of network entity 105 may be located in distributed locations (e.g., separate physical locations). In some examples, one or more network entities in network entity 105 of a decomposed RAN architecture may be implemented as virtual units (e.g., virtual CU (VCU), virtual DU (VDU), virtual RU (VRU)).

[0069] The functional splitting among CU 160, DU 165, and RU 170 is flexible and can support different functionalities depending on which functions (e.g., network layer functions, protocol layer functions, baseband functions, RF functions, or any combination thereof) are performed at CU 160, DU 165, or RU 170. For example, a protocol stack functional splitting can be used between CU 160 and DU 165, allowing CU 160 to support one or more layers of the protocol stack, and DU 165 to support one or more different layers of the protocol stack. In some examples, CU 160 can host higher protocol layer (e.g., Layer 3 (L3), Layer 2 (L2)) functionalities and signaling (e.g., Radio Resource Control (RRC), Serving Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP)). CU 160 (e.g., one or more CUs) may connect to DU 165 (e.g., one or more DUs) or RU 170 (e.g., one or more RUs) or a combination thereof, and DU 165, RU 170, or both may host lower protocol layers, such as Layer 1 (L1) (e.g., Physical (PHY) layer) or L2 (e.g., Radio Link Control (RLC) layer, Medium Access Control (MAC) layer) functionality and signaling, and may each be at least partially controlled by CU 160. Additionally or alternatively, a protocol stack functional split may be employed between DU 165 and RU 170, such that DU 165 may support one or more layers of the protocol stack, and RU 170 may support one or more different layers of the protocol stack. DU 165 may (e.g., via one or more different RUs, such as RU 170) support one or more different cells. In some cases, functional decomposition between CU 160 and DU 165, or between DU 165 and RU 170, can be performed within the protocol layer (e.g., some functions of the protocol layer can be performed by one of CU 160, DU 165, or RU 170, while other functions of the protocol layer can be performed by a different one of CU 160, DU 165, or RU 170). CU 160 can be further functionally decomposed into CU control plane (CU-CP) functions and CU user plane (CU-UP) functions. CU 160 can be connected to DU 165 via midhaul communication link 162 (e.g., F1, F1-c, F1-u), and DU 165 can be connected to RU 170 via fronthaul communication link 168 (e.g., open fronthaul (FH) interface). In some examples, the midhaul communication link 162 or the fronthaul communication link 168 may be implemented based on the interfaces (e.g., channels) between the layers of the protocol stack, which are supported by corresponding network entities (e.g., one or more network entities in network entity 105) that communicate via such communication links.

[0070] In some wireless communication systems (e.g., wireless communication system 100), the infrastructure and spectrum resources for radio access can support wireless backhaul link capabilities to supplement wired backhaul connections, thereby providing an IAB network architecture (e.g., to core network 130). In some cases, in an IAB network, one or more network entities of network entity 105 (e.g., network entity 105 or IAB node 104) may be partially controlled by each other. IAB node 104 may be referred to as a donor entity or IAB donor. DU 165 or RU 170 may be partially controlled by CU 160 associated with network entity 105 or base station 140 (such as a donor network entity or donor base station). One or more donor entities (e.g., IAB donors) may communicate with one or more additional devices (e.g., IAB node 104) via supported access and backhaul links (e.g., backhaul communication link 120). IAB node 104 may include an IAB mobile terminal (IAB-MT) controlled (e.g., scheduled) by one or more DUs (e.g., DU 165) of a coupled IAB donor. The IAB-MT may be equipped with a separate set of antennas for relaying communication with UE 115, or may share the same antennas (e.g., those of RU 170) for access to IAB node 104 via DU 165 of IAB node 104. (e.g., referred to as a virtual IAB-MT (vIAB-MT)). In some examples, IAB node 104 may include one or more DUs (e.g., DU 165) that support communication links with additional entities (e.g., IAB node 104, UE 115) within a relay chain or configuration (e.g., downstream) of the access network. In such cases, one or more components of the decomposed RAN architecture (e.g., IAB node 104, or components of IAB node 104) may be configured to operate according to the techniques described herein.

[0071] For example, the access network (AN) or RAN may include communication between an access node (e.g., an IAB donor), IAB node 104, and one or more UEs 115. The IAB donor may facilitate connectivity between the core network 130 and the AN (e.g., via a wired or wireless connection to the core network 130). That is, an IAB donor may refer to a RAN node having a wired or wireless connection to the core network 130. The IAB donor may include one or more of CU 160, DU 165, and RU 170, in which case CU 160 may communicate with the core network 130 via an interface (e.g., a backhaul link). The IAB donor and IAB node 104 may communicate via an F1 interface according to a protocol defining the signaling messages (e.g., the F1 AP protocol). Additionally or alternatively, CU 160 may communicate with core network 130 via an interface (which may be part of a backhaul link) and may communicate with other CUs (e.g., including CU 160 associated with an alternative IAB donor) via an Xn-C interface (which may be another part of a backhaul link).

[0072] IAB node 104 may refer to a RAN node that provides IAB functionality (e.g., access for UE 115, radio self-backhaul capability, etc.). DU 165 may act as a distributed scheduling node toward child nodes associated with IAB node 104, and IAB-MT may act as a scheduled node toward a parent node associated with IAB node 104. That is, an IAB donor may be referred to as a parent node communicating with one or more child nodes (e.g., an IAB donor may be relayed by other IAB nodes 104 for UE transmission). Additionally or alternatively, IAB node 104 may also be referred to as a parent or child node of other IAB nodes 104, depending on the AN's relay chain or configuration. The IAB-MT entity of IAB node 104 can provide a Uu interface for child IAB nodes (e.g., IAB node 104) to receive signaling from parent IAB nodes (e.g., IAB node 104), and the DU interface (e.g., DU 165) can provide a Uu interface for parent IAB nodes to send signals to child IAB nodes or UE 115.

[0073] For example, IAB node 104 may be referred to as a parent node supporting communication to child IAB nodes, or as a child IAB node associated with an IAB donor, or both. An IAB donor may include a CU 160 having a wired or wireless connection to core network 130 (e.g., backhaul communication link 120) and may act as a parent node of IAB node 104. For example, an IAB donor's DU 165 may relay transmissions to UE 115 via IAB node 104, or may signal transmissions directly to UE 115, or both. An IAB donor's CU 160 may signal the establishment of a communication link to IAB node 104 via an F1 interface, and IAB node 104 may schedule transmissions (e.g., transmissions relayed from the IAB donor to UE 115) via one or more DUs (e.g., DU 165). In other words, data can be relayed to and from IAB node 104 via signaling through the NR Uu interface of the MT to IAB node 104 (e.g., other IAB nodes). Communication with IAB node 104 can be scheduled by the DU 165 of the IAB donor or the DU 165 of IAB node 104.

[0074] When the techniques described herein are applied in the context of a decomposed RAN architecture, one or more components of the decomposed RAN architecture can be configured to support the tests described herein. For example, some operations described as being performed by UE 115 or network entity 105 (e.g., base station 140) may additionally or alternatively be performed by one or more components of the decomposed RAN architecture (e.g., components such as IAB node, DU 165, CU 160, RU 170, RIC 175, SMO system 180).

[0075] UE 115 may include or be referred to as a mobile device, wireless device, remote device, handheld device, or subscriber device, or any other suitable term, wherein "device" may also be referred to as a cell, station, terminal, or client, etc. UE 115 may also include or be referred to as a personal electronic device, such as a cellular phone, personal digital assistant (PDA), tablet computer, laptop computer, or personal computer. In some examples, UE 115 may include or be referred to as a wireless local loop (WLL) station, Internet of Things (IoT) device, Internet of Everything (IoE) device, or machine-type communication (MTC) device, etc., which may be implemented in various objects such as appliances, vehicles, or meters.

[0076] The UE 115 described herein may be able to communicate with various types of devices, such as other UEs 115 that may sometimes operate as repeaters, as well as network entities 105 and network equipment including macro eNBs or gNBs, small cell eNBs or gNBs, or relay base stations, etc. Figure 1 As shown.

[0077] UE 115 and network entity 105 can wirelessly communicate with each other via communication link 125 (e.g., one or more access links) using resources associated with one or more carriers. The term "carrier" can refer to a set of RF spectrum resources having a defined PHY layer structure for supporting communication link 125. For example, a carrier for communication link 125 may include a portion of an RF spectrum band (e.g., BWP) operating according to one or more PHY layer channels for a given RAT (e.g., LTE, LTE-A, LTE-A Pro, NR). Each PHY layer channel may carry acquisition signaling (e.g., synchronization signals, system information), control signaling coordinating operation for the carrier, user data, or other signaling. Wireless communication system 100 can support communication with UE 115 using carrier aggregation or multi-carrier operation. Depending on the carrier aggregation configuration, UE 115 can be configured using multiple downlink component carriers and one or more uplink component carriers. Carrier aggregation can be used in conjunction with both frequency division duplex (FDD) component carriers and time division duplex (TDD) component carriers. Communication between network entity 105 and other devices can refer to communication between these devices and any part of network entity 105 (e.g., entity, sub-entity). For example, the terms “send,” “receive,” or “communicate” when referring to network entity 105 can refer to any part of the RAN’s network entity 105 (e.g., base station 140, CU 160, DU 165, RU 170) communicating with another device (e.g., directly or via one or more other network entities, such as one or more network entities in network entity 105).

[0078] The communication link 125 of the wireless communication system 100 may include downlink transmission (e.g., forward link transmission) from network entity 105 to UE 115, uplink transmission (e.g., return link transmission) from UE 115 to network entity 105, or both, as well as other transmission configurations. The carrier may carry downlink communication or uplink communication (e.g., in FDD mode), or may be configured to carry both downlink and uplink communication (e.g., in TDD mode).

[0079] A carrier may be associated with a specific bandwidth of the RF spectrum, and in some examples, the carrier bandwidth may be referred to as the carrier or the “system bandwidth” of the wireless communication system 100. For example, the carrier bandwidth may be one of a set of bandwidths for a carrier for a specific RAT (e.g., 1.4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, 20 MHz, 40 MHz, or 80 MHz). Devices of the wireless communication system 100 (e.g., network entity 105, UE 115, or both) may have hardware configurations that support communication using a specific carrier bandwidth, or may be configured to support communication using one of a set of carrier bandwidths. In some examples, the wireless communication system 100 may include network entity 105 or UE 115 that supports concurrent communication using carriers associated with multiple carrier bandwidths. In some examples, each served UE 115 may be configured to operate using a portion (e.g., subband, BWP) or all of the carrier bandwidth.

[0080] The signal waveform transmitted via a carrier may include multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques, such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform extended OFDM (DFT-S-OFDM)). In a system employing MCM, a resource element may refer to a resource of one symbol period (e.g., the duration of one modulation symbol) and one subcarrier, where the symbol period and subcarrier spacing may be inversely related. The number of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme, the decoding rate of the modulation scheme, or both), such that a relatively high number of resource elements (e.g., in the transmission duration) and a relatively high modulation scheme order correspond to a relatively high communication rate. Wireless communication resources may refer to a combination of RF spectrum resources, temporal resources, and spatial resources (e.g., spatial layers or beams), and the use of multiple spatial resources may increase the data rate or data integrity used for communication with UE 115.

[0081] It can support one or more parameter sets for a carrier, and the parameter sets may include subcarrier spacing ( (and cyclic prefix). A carrier can be divided into one or more BWPs with the same or different sets of parameters. In some examples, UE 115 can be configured to utilize multiple BWPs. In some examples, a single BWP of a carrier can be active at a given time, and communication for UE 115 can be constrained to one or more active BWPs.

[0082] The time interval for network entity 105 or UE 115 can be expressed as a multiple of a basic time unit, such as the sampling period. seconds, in response This can represent the supported subcarrier spacing, while It can represent the supported Discrete Fourier Transform (DFT) size. Time intervals for communication resources can be organized according to radio frames, each with a specified duration (e.g., 10 milliseconds (ms)). Each radio frame can be identified by a System Frame Number (SFN) (e.g., ranging from 0 to 1023).

[0083] Each frame may include multiple consecutively numbered subframes or time slots, and each subframe or time slot may have the same duration. In some examples, a frame may (e.g., in the time domain) be divided into subframes, and each subframe may be further divided into a number of time slots. Alternatively, each frame may include a variable number of time slots, and the number of time slots may depend on the subcarrier spacing. Each time slot may include a number of symbol periods (e.g., depending on the length of the cyclic prefix appended to each symbol period). In some wireless communication systems, such as wireless communication system 100, time slots may be further divided into multiple micro-time slots associated with one or more symbols. Excluding the cyclic prefix, each symbol period may be associated with one or more (e.g., The duration of a symbol period is associated with a (number) sampling period. The duration of a symbol period can depend on the subcarrier spacing or the operating frequency band.

[0084] A subframe, time slot, micro-time slot, or symbol can be the smallest scheduling unit of the wireless communication system 100 (e.g., in the time domain) and can be referred to as a transmission time interval (TTI). In some examples, the duration of the TTI (e.g., the number of symbol periods in the TTI) can be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 can be dynamically selected (e.g., in a burst of shortened TTIs (sTTIs)).

[0085] Depending on the technology, carriers can be used to multiplex physical channels for communication. One or more of Time Division Multiplexing (TDM), Frequency Division Multiplexing (FDM), or hybrid TDM-FDM techniques can be used, for example, to multiplex physical control channels and physical data channels for signaling via a downlink carrier. The control region (e.g., control resource set (CORESET)) of the physical control channel can be defined by a set of symbol periods and can extend across the system bandwidth of the carrier or a subset of that bandwidth. One or more control regions (e.g., CORESET) can be configured for a set of UEs 115. For example, one or more UEs in UE 115 can monitor or search for control regions to obtain control information based on one or more search space sets, and each search space set can include one or more control channel candidates in one or more aggregation levels arranged in a concatenated manner. The aggregation level of control channel candidates can refer to the amount of control channel resources (e.g., control channel elements (CCEs)) associated with coded information for a control information format having a given payload size. The search space set may include a common search space set configured to transmit control information to UE 115 (e.g., one or more UEs), or it may include a UE-specific search space set configured to transmit control information to UE 115 (e.g., a particular UE).

[0086] Network entity 105 may provide communication coverage via one or more cells (e.g., macro cells, small cells, hotspots, or other types of cells, or any combination thereof). The term "cell" may refer to a logical communication entity used (e.g., using a carrier) to communicate with network entity 105 and may be associated with an identifier used to distinguish adjacent cells (e.g., Physical Cell Identifier (PCID), Virtual Cell Identifier (VCID)). In some examples, a cell may also refer to a coverage area 110 or a portion of coverage area 110 (e.g., a sector) in which a logical communication entity operates. Depending on various factors such as the capabilities of network entity 105, the range of such cells may be from smaller areas (e.g., structures, subsets of structures) to larger areas. For example, a cell may be a building, a subset of buildings, or external space between or overlapping coverage areas 110, or may include buildings, subsets of buildings, or external space between or overlapping coverage areas.

[0087] Macro cells typically cover a relatively large geographic area (e.g., a radius of several kilometers) and allow unrestricted access to UE 115 that has a service subscription with a network provider supporting the macro cell. Small cells may be associated with network entities 105 (e.g., base stations 140 operating at lower power) that operate relative to macro cells, and small cells may operate using the same or different (e.g., licensed, unlicensed) frequency bands as macro cells. Small cells may provide unrestricted access to UE 115 that has a service subscription with a network provider, or restricted access to UE 115 associated with a small cell (e.g., UE 115 in a closed subscriber group (CSG), UE 115 associated with a user in a home or office). Network entity 105 may support one or more cells and may also use one or more component carriers to support communication via one or more cells.

[0088] In some examples, a carrier can support multiple cells and can be configured with different cells based on different protocol types that can provide access for different types of devices (e.g., MTC, Narrowband IoT (NB-IoT), Enhanced Mobile Broadband (eMBB)).

[0089] In some examples, network entity 105 (e.g., base station 140, RU 170) may be mobile, and thus provide communication coverage to mobile coverage areas (such as coverage area 110). In some examples, coverage areas 110 associated with different technologies (e.g., different coverage areas) may overlap, but coverage areas 110 (e.g., different coverage areas) may be supported by the same network entity (e.g., network entity 105). In some other examples, overlapping coverage areas (such as coverage area 110) associated with different technologies may be supported by different network entities (e.g., network entity 105). The wireless communication system 100 may include, for example, a heterogeneous network in which different types of network entities 105 use the same or different RATs to support communication to coverage areas 110 (e.g., different coverage areas).

[0090] Some UE 115 devices (such as MTC or IoT devices) can be relatively low-cost or low-complexity devices and can provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC can refer to data communication technologies that allow devices to communicate with each other or with network entity 105 (e.g., base station 140) without human intervention. In some examples, M2M communication or MTC may include communication from devices with integrated sensors or instruments to measure or acquire information and relay such information to a central server or application that uses the information or presents it to people interacting with the application. Some UE 115 devices may be designed to collect information or enable automated behavior of machines or other devices. Examples of applications for MTC devices include smart metering, inventory monitoring, water level monitoring, equipment monitoring, healthcare monitoring, wildlife monitoring, weather and geological event monitoring, fleet management and tracking, remote security sensing, physical access control, and transaction-based business charging.

[0091] Some UE 115s can be configured to operate in a power-saving mode, such as half-duplex communication (e.g., a mode that supports unidirectional communication via transmission or reception but does not transmit and receive concurrently). In some examples, half-duplex communication can be performed at a reduced peak rate. Other power-saving techniques for UE 115 may include entering a power-saving deep sleep mode when not engaged in active communication, operating with limited bandwidth (e.g., according to narrowband communication), or a combination of these techniques. For example, some UE 115s can be configured to operate using a narrowband protocol type associated with a defined portion or range (e.g., a set of subcarriers or resource blocks (RBs)) within a carrier, within a carrier's guard band, or outside a carrier.

[0092] Wireless communication system 100 may be configured to support ultra-reliable communication or low-latency communication, or various combinations thereof. For example, wireless communication system 100 may be configured to support ultra-reliable low-latency communication (URLLC). UE 115 may be designed to support ultra-reliable, low-latency, or critical functions. Ultra-reliable communication may include private or group communication and may be supported by one or more services, such as push-to-talk, video, or data. Support for ultra-reliable, low-latency functions may include prioritizing services, and such services may be used for public safety or general business applications. The terms “ultra-reliable,” “low-latency,” and “ultra-reliable low-latency” are used interchangeably herein.

[0093] In some examples, UE 115 may be configured to support direct communication with other UEs (e.g., one or more UEs in UE 115) via a device-to-device (D2D) communication link (such as D2D communication link 135) (e.g., according to a peer-to-peer (P2P), D2D, or sidelink protocol). In some examples, one or more UEs 115 in a group performing D2D communication may be within the coverage area 110 of network entity 105 (e.g., base station 140, RU 170), which may support aspects of such D2D communication configured (e.g., scheduled by network entity 105). In some examples, one or more UEs 115 in this group may be outside the coverage area 110 of network entity 105, or may otherwise be unable or not configured to receive transmissions from network entity 105. In some examples, a group of UEs 115 communicating via D2D communication can support a one-to-many (1:M) system, in which each UE 115 transmits to one or more UEs in the group. In some examples, network entity 105 can facilitate the scheduling of resources used for D2D communication. In some other examples, D2D communication can be performed between UEs 115 without involving network entity 105.

[0094] In some systems, the D2D communication link 135 may be an example of a communication channel (such as a sidelink communication channel) between vehicles (e.g., UE 115). In some examples, vehicles may communicate using vehicle-to-vehicle (V2X) communication, vehicle-to-vehicle (V2V) communication, or some combination of these. Vehicles may signal information related to traffic conditions, signaling, weather, safety, emergencies, or any other information relevant to the V2X system. In some examples, vehicles in a V2X system may communicate with roadside infrastructure (such as roadside units), or communicate with the network via one or more network nodes (e.g., network entity 105, base station 140, RU 170) using vehicle-to-network (V2N) communication, or both.

[0095] Core network 130 provides user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. Core network 130 can be an evolved packet core (EPC) or a 5G core (5GC), which may include at least one control plane entity (e.g., a Mobility Management Entity (MME), Access and Mobility Management Function (AMF)) for managing access and mobility, and at least one user plane entity (e.g., a Serving Gateway (S-GW), Packet Data Network (PDN) Gateway (P-GW), or User Plane Function (UPF)) for routing packets or interconnecting to external networks. The control plane entity manages non-access stratum (NAS) functions, such as mobility, authentication, and bearer management of UE 115 served by network entity 105 (e.g., base station 140) associated with core network 130. User IP packets can be delivered through the user plane entity, which provides IP address allocation and other functions. The user plane entity may connect to one or more network operator IP services 150. IP services 150 may include access to the Internet, intranets, IP Multimedia Subsystem (IMS), or packet-switched streaming services.

[0096] Wireless communication system 100 can operate using one or more frequency bands in the range of 300 MHz to 300 GHz. Generally, the area from 300 MHz to 3 GHz is referred to as the Ultra High Frequency (UHF) band or decimeter band because the wavelength range is approximately one decimeter to one meter in length. UHF waves may be blocked or redirected by buildings and environmental features (which may be referred to as clusters), but these waves are sufficient to penetrate structures so that macrocells can provide service to UE 115 located indoors. Compared to communication using smaller frequencies and longer wavelengths in the lower frequency (HF) or very high frequency (VHF) portions of the spectrum below 300 MHz, communication using UHF waves can be associated with smaller antennas and shorter ranges (e.g., less than one hundred kilometers).

[0097] The wireless communication system 100 can also operate in the ultra-high frequency (SHF) region (also known as the centimeter band) in the range of 3 GHz to 30 GHz or in the extremely high frequency (EHF) region (e.g., 30 GHz to 300 GHz) (also known as the millimeter band) using the spectrum. In some examples, the wireless communication system 100 can support millimeter-wave (mmW) communication between the UE 115 and network entity 105 (e.g., base station 140, RU 170), and the EHF antennas of the corresponding devices can be smaller and closer together than UHF antennas. In some examples, such techniques facilitate the use of antenna arrays within the device. However, compared to SHF or UHF transmission, EHF transmission may experience even greater attenuation and shorter distances. The techniques disclosed herein can be adopted for transmission across one or more different frequency regions, and the frequency band usage specified across these frequency regions may vary by country or regulatory authority.

[0098] Wireless communication system 100 may utilize both licensed and unlicensed RF spectrum bands. For example, wireless communication system 100 may employ licensed assisted access (LAA), LTE-Unlicensed (LTE-U) RAT, or NR technology using unlicensed frequency bands (such as the 5 GHz Industrial, Scientific, and Medical (ISM) band). When operating with unlicensed RF spectrum, devices such as network entity 105 and UE 115 may employ carrier sensing for collision detection and avoidance. In some examples, operation using unlicensed frequency bands may be based on carrier aggregation configurations combined with component carriers operating with licensed frequency bands (e.g., LAA). Operation using unlicensed spectrum may include downlink transmission, uplink transmission, P2P transmission, or D2D transmission, etc.

[0099] Network entity 105 (e.g., base station 140, RU 170) or UE 115 may be equipped with multiple antennas that can be used to employ techniques such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communication, or beamforming. The antennas of network entity 105 or UE 115 may be located within one or more antenna arrays or antenna panels, which can support MIMO operation or transmit or receive beamforming. For example, one or more base station antennas or antenna arrays may be co-located at an antenna assembly (such as an antenna tower). In some examples, the antennas or antenna arrays associated with network entity 105 may be located at different geographical locations. Network entity 105 may include an antenna array having a collection of multiple rows and columns of antenna ports that network entity 105 can use to support beamforming for communication with UE 115. Similarly, UE 115 may include one or more antenna arrays that can support various MIMO or beamforming operations. Additionally or alternatively, the antenna panel may support RF beamforming for signals transmitted via the antenna ports.

[0100] Network entity 105 or UE 115 can use MIMO communication to leverage multipath signal propagation and improve spectral efficiency by transmitting or receiving multiple signals via different spatial layers. This technique is known as spatial multiplexing. The multiple signals can be transmitted, for example, by a transmitting device via different antennas or different combinations of antennas. Similarly, the multiple signals can be received by a receiving device via different antennas or different combinations of antennas. Each of the multiple signals can be referred to as a separate spatial stream and can carry information associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords). Different spatial layers can be associated with different antenna ports used for channel measurement and reporting. MIMO techniques include: single-user MIMO (SU-MIMO), where multiple spatial layers are transmitted to the same receiving device; and multi-user MIMO (MU-MIMO), where multiple spatial layers are transmitted to multiple devices.

[0101] Beamforming (also known as spatial filtering, directional transmission, or directional reception) is a signal processing technique that can be used at a transmitting or receiving device (e.g., network entity 105, UE 115) to shape or guide an antenna beam (e.g., a transmit beam, a receive beam) along a spatial path between the transmitting and receiving devices. Beamforming can be achieved by combining signals transmitted via antenna elements of an antenna array such that some signals propagating along a specific orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to the signals transmitted via the antenna elements may include applying amplitude shifts, phase shifts, or both to the signals carried via the antenna elements associated with the device. The adjustments associated with each of these antenna elements may be defined by a beamforming weight set associated with a specific orientation (e.g., relative to the antenna array of the transmitting or receiving device or relative to some other orientation).

[0102] Network entity 105 or UE 115 may use beam scanning technology as part of beamforming operations. For example, network entity 105 (e.g., base station 140, RU 170) may use multiple antennas or antenna arrays (e.g., antenna panels) to perform beamforming operations for directional communication with UE 115. Some signals (e.g., synchronization signals, reference signals, beam selection signals, or other control signals) may be transmitted multiple times by network entity 105 in different directions. For example, network entity 105 may transmit signals according to different beamforming weight sets associated with different transmission directions. Beam directions may be identified (e.g., by a transmitting device (such as network entity 105) or by a receiving device (such as UE 115)) by transmission along different beam directions for later transmission or reception by network entity 105.

[0103] Some signals (such as data signals associated with a specific receiving device) may be transmitted by a transmitting device (e.g., network entity 105 or UE 115) along a single beam direction (e.g., the direction associated with a receiving device (such as another network entity 105 or UE 115). In some examples, the beam direction associated with transmission along a single beam direction may be determined based on the signals transmitted along one or more beam directions. For example, UE 115 may receive one or more signals transmitted by network entity 105 in different directions and may report to network entity 105 an indication of signals received by UE 115 with the highest signal quality or other acceptable signal quality.

[0104] In some examples, transmissions performed by a device (e.g., network entity 105 or UE 115) may be performed using multiple beam directions, and the device may use a combination of digital pre-decoding or beamforming to generate a combined beam for transmission (e.g., from network entity 105 to UE 115). UE 115 may report feedback indicating pre-decoding weights for one or more beam directions, and this feedback may correspond to a configured set of beams across the system bandwidth or one or more sub-bands. Network entity 105 may transmit reference signals (e.g., cell-specific reference signals (CRS), channel state information reference signals (CSI-RS)) that may or may not be pre-decoded. UE 115 may provide feedback for beam selection, which may be a pre-decoding matrix indicator (PMI) or codebook-based feedback (e.g., multi-panel codebook, linear combination codebook, port selection codebook). Although these techniques are described with reference to signals transmitted by network entity 105 (e.g., base station 140, RU 170) along one or more directions, UE 115 may use similar techniques to transmit signals multiple times along different directions (e.g., to identify the beam direction used by UE 115 for subsequent transmission or reception), or to transmit signals along a single direction (e.g., to transmit data to a receiving device).

[0105] A receiving device (e.g., UE 115) may perform reception operations according to multiple reception configurations (e.g., directional listening) when receiving various signals (such as synchronization signals, reference signals, beam selection signals, or other control signals) from a transmitting device (e.g., network entity 105). For example, the receiving device may perform reception according to multiple reception directions by: receiving via different antenna subarrays; processing the received signal according to different antenna subarrays; receiving according to different sets of reception beamforming weights applied to signals received at multiple antenna elements of the antenna array (e.g., different directional listening weight sets); or processing the received signal according to different sets of reception beamforming weights applied to signals received at multiple antenna elements of the antenna array. Any of these operations may be referred to as “listening” according to different reception configurations or reception directions. In some examples, the receiving device may use a single reception configuration to receive along a single beam direction (e.g., when a data signal is received). A single receiver configuration can be aligned along a beam direction determined by listening according to different receiver configuration directions (e.g., a beam direction determined to have the highest signal strength, highest signal-to-noise ratio (SNR), or other acceptable signal quality based on listening according to multiple beam directions).

[0106] The wireless communication system 100 can be a packet-based network operating according to a layered protocol stack. In the user plane, communication at the bearer or PDCP layer can be IP-based. The RLC layer performs packet segmentation and reassembly for transmission via logical channels. The MAC layer performs priority processing and multiplexing of logical channels to transport channels. The MAC layer can also implement error detection, error correction, or both to support retransmission and improve link efficiency. In the control plane, the RRC layer can provide the establishment, configuration, and maintenance of RRC connections between the UE 115 and network entity 105 or core network 130 supporting user plane data radio bearers. The PHY layer maps transport channels to physical channels.

[0107] UE 115 and network entity 105 can support data retransmission to increase the likelihood of successful data reception. Hybrid Automatic Repeat Request (HARQ) feedback is a technique used to increase the likelihood of correctly receiving data via communication links (e.g., communication link 125, D2D communication link 135). HARQ may include a combination of error detection (e.g., using Cyclic Redundancy Check (CRC)), forward error correction (FEC), and retransmission (e.g., Automatic Repeat Request (ARQ)). HARQ can improve throughput at the MAC layer under relatively poor radio conditions (e.g., low signal-to-noise ratio conditions). In some examples, the device may support same-slot HARQ feedback, in which case the device can provide HARQ feedback in a specific time slot for data received via a previous symbol in that time slot. In some other examples, the device may provide HARQ feedback in subsequent time slots or according to a different time interval.

[0108] In some cases, UE 115 can operate according to various DRX states, BWP states, RRC inactive states, and SCell states, etc. UE 115 can be configured to utilize various inactive timers to transition from one state to another. However, reconfiguring such inactive timers can be associated with relatively high signaling overhead, which may increase latency in the wireless communication system 100 and degrade the user experience. Furthermore, a single inactive timer can be applied to a wide range of applications (e.g., associated with various service conditions, associated with different power state change modes), which may be relatively inefficient for some applications.

[0109] According to one or more aspects described herein, UE 115 can be configured to support dynamic state transitions based on data activity. In some examples, "data activity" may refer to a metric of data communication between UE 115 and network entity 105. For example, data activity may refer to a metric of data transfer rate (e.g., data rate), the amount of data transferred (e.g., data usage), or the amount of resources allocated for data communication (e.g., data scheduling). For example, UE 115 may operate in a first state and may send a request message to network entity 105 requesting a transition from the first state to a second state based on data activity between UE 115 and network entity 105 (e.g., data activity level, data rate metric, data usage metric, or data scheduling metric not meeting a threshold). UE 115 may transition from the first state to the second state based on sending the request. In some examples, network entity 105 may configure a set of inactivity timer values, and UE 115 may indicate a requested value for subsequent inactivity timer periods. Additionally or alternatively, UE 115 may send a direct indication of the requested value or the next state requested. In some examples, network entity 105 may send control messages to configure one or more dynamic state transition parameters at UE 115. Network entity 105 may also send responses to UE 115 to accept, partially accept (e.g., accept the request for a transition but reject the requested value for the timer duration), or reject the UE 115 request. Additionally, in some examples, UE 115 may be configured using a machine learning model (e.g., an artificial intelligence algorithm, a neural network) that supports determining when to send a request, and the UE may receive feedback from network entity 105 to train the machine learning model. Therefore, devices within wireless communication system 100 (e.g., UE 115) can operate with increased efficiency by dynamically adapting state transition configurations (e.g., via lower-level signaling and machine learning models). For example, this could enable UE 115 to achieve increased power savings, higher data rates, reduced latency, and other benefits for wireless communication system 100.

[0110] In some cases, UE 115 may operate according to a DRX configuration that includes DRX cycles for active periods (e.g., DRX active periods) and inactive periods (e.g., DRX inactive periods). However, the parameters associated with the DRX configuration can be configured via higher-layer signaling such as RRC signaling, which can be relatively difficult to reconfigure. Furthermore, a single DRX configuration can be applied to a wide range of applications (e.g., those associated with various service conditions and different power state change modes), which may be relatively inefficient for at least some applications (e.g., potentially increasing power consumption in the wireless communication system 100).

[0111] According to one or more aspects described herein, wireless communication system 100 may utilize signaling mechanisms to support dynamic configuration of DRX cycles based on data activity between UE 115 and network entity 105 (e.g., data activity levels not meeting thresholds). In some examples, "data activity" may refer to a metric of data communication between UE 115 and network entity 105. For example, data activity may refer to a metric of data transmission rate (e.g., data rate), the amount of data transmitted (e.g., data usage), or the amount of resources allocated for data communication (e.g., data scheduling). For example, when operating during an active period of a DRX cycle, UE 115 may send a request message (e.g., sleep request, sleep indication) to network entity 105 requesting a transition to an inactive period of the DRX cycle, which may be based on the failure of data activity (e.g., data rate metric, data usage metric, data scheduling metric) between UE 115 and network entity 105 to meet thresholds. Therefore, UE 115 may transition to an inactive period of the DRX cycle based on sending the request. Additionally, in some examples, network entity 105 may configure (e.g., pre-configure) a set of DRX inactivity timer values, and UE 115 may request a DRX inactivity timer value (e.g., for a DRX inactivity timer value) from that set (e.g., or not from that set) for a subsequent inactivity period.

[0112] In some examples, the network may send one or more control messages to the UE to configure dynamic DRX cycle transitions. Network entity 105 may also send responses to UE 115 to accept, partially accept (e.g., accept the request to enter sleep but reject the requested sleep duration), or reject the UE 115 request. Additionally, in some examples, a machine learning model (e.g., AI algorithm, neural network) may be used to configure UE 115, which supports determining (e.g., predicting) when UE 115 should enter an inactive period and how long the UE should remain inactive. Therefore, devices within the wireless communication system 100 (e.g., UE 115) can increase power savings and reduce data traffic congestion by dynamically adapting to DRX cycle transitions in the wireless communication system 100 (e.g., via lower-level signaling and machine learning models).

[0113] Figure 2 An example of a wireless communication system 200 supporting enhanced UE state transitions and dynamic DRX procedures according to one or more aspects of this disclosure is shown. The wireless communication system 200 may implement as referenced... Figure 1 The described aspects of the wireless communication system 100, or those implemented therein. For example, the wireless communication system 200 may include a UE 115 and a network entity 105, which may be as described in reference... Figure 1Examples of the corresponding devices described may include such corresponding devices. Network entity 105 may communicate with UE 115 via communication link 205-a (e.g., a downlink communication channel) and communication link 205-b (e.g., an uplink communication channel). Communication link 205 may be an example of a downlink communication interface, an uplink communication interface, or other communication interfaces, or may include such communication interfaces. In some examples, UE 115 and network entity 105 may exchange signaling, such as request 210, response 215, control message 220, or other signaling, via communication link 205, which may enable state transition 225 at UE 115 (e.g., dynamic configuration of state transition). Although network entity 105 and UE 115 are shown as example devices of wireless communication system 200, the techniques described herein (including references) may vary. Figure 1 The application may be made using one or more other devices (e.g., UE 115, CU 160, DU 165, RU 170 or other network nodes) as described in the description.

[0114] In some cases, one or more state transitions 225 (e.g., associated with one or more state machines of UE 115 in various upper-layer processes) may be controlled by one or more inactivity timers. One or more state transitions 225 may be associated with DRX states (e.g., DRX active periods, DRX inactive periods, DRX periodic configuration), BWP states (e.g., type of active BWP, narrow BWP, wide BWP), data activity states (e.g., RRC connected state, RRC idle state, RRC inactive state), secondary cell states (e.g., active secondary cell, deactivated secondary cell), or some other communication state. One or more state transitions 225 may be based on one or more inactivity timers at UE 115 (e.g., DRX inactivity timer, BWP inactivity timer, data inactivity timer, secondary cell deactivation timer). UE 115 may initiate (e.g., initiate) an inactivity timer based on (e.g., in response to) a specified event (e.g., a trigger event, receiving an indication of scheduled data transmission, identifying inactivity in data communication between network entity 105 and UE 115). In some cases, if UE 115 does not detect any data activity (e.g., or any scheduling of data activity) before the inactivity timer expires, UE 115 (e.g., a higher-level procedure of UE 115) may switch to a different state when the inactivity timer expires.

[0115] However, in some cases, one or more inactive timers can be configured via higher-layer signaling (e.g., RRC signaling) and can be static or semi-static. Additionally, a single value for the inactive timer may not be efficient (e.g., optimized) for all scenarios experienced by UE 115. For example, data traffic, power state changes, and other operating conditions at UE 115 can be dynamic (e.g., based on the application used by UE 115), and using a single value for the inactive timer may be relatively inefficient for at least some of the operating scenarios. Furthermore, reconfiguration of inactive timer values ​​can be associated with relatively high signaling overhead and can be updated accordingly on a relatively infrequent basis.

[0116] According to one or more techniques described herein, UE 115 and network entity 105 may support dynamic configuration (e.g., via relatively low-level signaling) of one or more state transitions 225 at UE 115, which may improve the efficiency associated with one or more state transitions 225. One or more state transitions 225 may be associated with data activity or data inactivity (e.g., triggered based on data activity not meeting a threshold). In some examples, dynamic state transitions may include a determination by UE 115 to perform a state transition 225. UE 115 may indicate such a determination (e.g., UE 115 instructs network entity 105 when it wants to change its state) by sending a request 210 (e.g., a state transition request message) to network entity 105. This request may be a request to transition from a first state (e.g., active state, narrow BWP state, SCell active state) to a second state (e.g., inactive state, wide BWP state, SCell deactivated state).

[0117] In some examples, UE 115 may receive one or more control messages 220 that can configure UE 115 to support dynamic state transitions. For example, network entity 105 may configure (e.g., or pre-configure) a set of multiple values ​​for a given inactive timer via control message 220 (e.g., or via an indication therein). Based on receiving control message 220, UE 115 may send request 210 that may indicate that UE 115 selects an applied inactive timer value (e.g., a requested value, a selected value) when the associated inactive timer is subsequently started or restarted (e.g., in response to a subsequent triggering event). In some examples, such request 210 may be sent via Layer 1 (L1) signaling (e.g., Uplink Control Information (UCI)), Layer 2 (L2) signaling (e.g., Media Access Control Element (MAC CE)), Layer 3 (L3) signaling (e.g., UE Assistance Information), or a combination thereof.

[0118] Network entity 105 may send (e.g., output, transmit) response 215 (e.g., response message, downlink MAC CE) in response to receiving request 210 (e.g., based on receiving the request, after receiving the request). Response 215 may acknowledge request 210 or reject request 210. In some examples, network entity 105 may also use response 215 (e.g., MAC CE) to configure an inactivity timer value that is different from the value requested by UE 115 (e.g., different from the inactivity timer value included in request 210 if network entity 105 disagrees with the requested value).

[0119] In some examples, request 210 may include an explicit indication made by UE 115. In such examples, request 210 may be sent via L1 signaling (e.g., UCI) or L2 signaling (e.g., MAC CE). Request 210 may include a binary indication of state transition 225. Request 210 may additionally include an indication of the next state selected for UE 115 (e.g., preferred state, for a selected value of an inactivity timer associated with a particular state). The next state (e.g., the content of the indication included in request 210) may be associated with various parameters (e.g., various inactivity timer values) based on the type of state transition 225 (e.g., state context). For example, for a DRX state transition, the parameter of the next state may refer to the sleep duration (e.g., sleep state, duration the UE has remained in a sleep state, DRX inactivity state) or otherwise indicate when UE 115 will wake up from the sleep state (e.g., wake-up state, DRX active state). For BWP state transitions, the next state may refer to the target BWP that UE 115 can switch to (e.g., narrow BWP state, wide BWP state) (e.g., if network entity 105 grants request 210). For data inactivity state transitions (e.g., data inactivity for RRC release), the next state may refer to the RRC state (e.g., RRC idle state, RRC inactive state, state after UE 115 is released from the RRC connected state). For SCell active state, the next state may refer to the SCell deactivated state, or in some examples, the next state may not be specified for SCell deactivated scenarios.

[0120] After UE 115 sends request 210 (e.g., an indication of the next state), UE 115 may start a timer to wait for a response 215 from network entity 105. In some examples, the timer may be associated with the same duration as a HARQ retransmission timer. Network entity 105 may (e.g., via one or more control messages 220) configure UE 115 to autonomously perform a state transition 225 (e.g., a state transition requested by request 210) if UE 115 does not receive a response 215 (e.g., or any other response) before the timer expires. For example, UE 115 may be located near the cell center of network entity 105 (e.g., associated with relatively high communication quality), and the probability that request 210 will be successfully received at network entity 105 may be relatively high. Alternatively, network entity 105 may configure UE 115 to cancel the requested state transition 225 if UE 115 does not receive a response 215 (e.g., or any other response) from network entity 105 before the timer expires. For example, UE 115 may be located near the cell edge of network entity 105 (e.g., associated with relatively low communication quality), and the probability that request 210 will be successfully received at network entity 105 may be relatively low.

[0121] In some examples, network entity 105 may agree to or partially agree to request 210. If network entity 105 agrees to request 210 and network entity 105 configures UE 115 to autonomously perform state transition 225 (e.g., in the absence of response 215), then network entity 105 may not send response 215 (e.g., before the timer expires). Alternatively, if network entity 105 configures UE 115 to cancel the requested state transition 225 if response 215 is not received, then network entity 105 may use response 215 to indicate to UE 115 (e.g., before the timer expires) whether network entity 105 agrees to request 210. For example, if network entity 105 agrees to request 210 to perform one or more state transitions 225 and also agrees to an indication of the next state (e.g., an inactivity timer value for the next state), then network entity 105 may send response 215 via a MAC CE without content to acknowledge request 210. Such a response 215 may be compatible with L1 or L2 signaling (e.g., L1 or L2 signaling used to send request 210). Alternatively, response 215 may be sent via a scheduled downlink control information (DCI) message having the same HARQ process as the physical uplink shared channel (PUSCH) in which request 210 (e.g., a sleep indication) is sent. In such an example, response 215 may be the same HARQ process but with a new data indicator (NDI) after switching to acknowledge request 210. Such a DCI may be a DCI without a payload (e.g., a dummy DCI) and may be compatible with L2 signaling (e.g., L2 signaling used to send request 210).

[0122] If network entity 105 agrees to request 210 to perform state transition 225 but disagrees with the indicated next state (e.g., network entity 105 partially agrees to request 210), network entity 105 may (e.g., via MAC CE) send a response 215 that includes a next state different from the state requested by UE 115 (e.g., a different inactivity timer value). Therefore, based on receiving such a response 215, UE 115 may comply with the next state as indicated by network entity 105. If network entity 105 disagrees with request 210, network entity 105 may send response 215 via a scheduling DCI for new transmission (e.g., the scheduling DCI may not match the HARQ process associated with request 210). Such a DCI may not include a payload (e.g., a dummy DCI). Based on receiving such a response 215, UE 115 may cancel its request to perform state transition 225.

[0123] In some examples, control message 220 may configure a timer that controls the frequency at which UE 115 may send request 210 (e.g., a state transition request). When configured, such a timer may be started when UE 115 sends request 210 to network entity 105. UE 115 may not send another request 210 to perform state transition 225 until the timer expires.

[0124] In some examples, UE 115 may determine when to send request 210 (e.g., when to perform state transition 225) based on machine learning models (e.g., AI engines, AI models, neural networks). For example, the AI ​​engine at UE 115 may collect information such as uplink traffic arrivals (e.g., arrival intervals), the type of each Protocol Data Unit (PDU) (e.g., control and data), or other information, and may predict when data bursts may end. The AI ​​engine may also perform the same predictions for downlink traffic. In some examples, UE 115 may request state transition 225 when the AI ​​engine detects a change in traffic characteristics that can be handled more efficiently under different states. For example, for DRX inactivity, data inactivity, or SCell deactivation, etc., the AI ​​engine may instruct UE 115 to send request 210 when the arrival interval of the next data is greater than (e.g., longer than) a threshold (e.g., long enough for UE 115 to have meaningful sleep). In another example, when the BWP is inactive, the AI ​​engine may instruct the UE 115 to send request 210 when the data rate increases above a threshold (e.g., a preset threshold) or decreases below a threshold.

[0125] Additionally, network entity 105 may provide one or more feedback messages 230 to UE 115 to improve (e.g., train) a machine learning model. In some examples, network entity 105 may collect statistics about one or more requests 210 received from UE 115. For example, network entity 105 may monitor the frequency with which requests 210 are sent too late or too early (e.g., relative to a threshold) and may indicate the distribution of such errors in the feedback message 230. In particular, for DRX procedures, network entity 105 may monitor the frequency with which UE 115 wakes up too early or too late and may indicate the distribution of such errors. For BWP handover scenarios, network entity 105 may monitor and instruct UE 115 on the frequency with which it selects the correct (e.g., or incorrect) next BWP (e.g., based on whether the selected BWP matches or does not match the corresponding data service characteristics, such as traffic volume or data rate). For RRC state transitions, network entity 105 may monitor and instruct UE 115 on the frequency with which it makes correct (e.g., or incorrect) decisions between RRC inactive and RRC idle states. Therefore, network entity 105 can provide such statistics back to UE 115 via one or more feedback messages 230, which UE 115 can use to train its AI engine.

[0126] Therefore, by conveying one or more control messages 220, requests 210, responses 215, and one or more feedback messages 230, the wireless communication system 200 can support increased energy savings, improved coordination between devices, and increased data rates, among other things. For example, it can enable the UE 115 to respond more quickly to changes in its environment and service conditions, thereby allowing the UE 115 to save more power or increase data rates over a longer duration.

[0127] In some cases, DRX configuration can control when UE 115 operates in an active state (e.g., monitoring Physical Downlink Control Channel (PDCCH) messages or Physical Downlink Shared Channel (PDSCH) messages) and when UE 115 operates in an inactive state (e.g., how long UE 115 remains in a sleep state). In other words, DRX configuration can control the time resources when the UE transitions to a sleep state and the duration for which UE 115 remains in a sleep state (e.g., the time resources when UE 115 is to wake up). In some cases, such DRX configuration can be static or semi-static, which may be associated with relatively high signaling overhead for configuration (e.g., reconfiguration).

[0128] Specifically, the DRX inactivity timer parameters configured in the DRX configuration (e.g., configured via RRC and / or semi-static configuration) control when UE 115 transitions to an inactive period of the DRX (e.g., when it enters sleep). Additionally, the DRX cycle parameters configured in the DRX configuration (e.g., configured via RRC and / or semi-static configuration) control the duration of one or more inactive periods of the DRX cycle (e.g., how long UE 115 remains in sleep). The timer parameters configured in the DRX configuration (e.g., a short DRX cycle timer, also configured via RRC and / or semi-static configuration) control which DRX cycle UE 115 uses. However, such cases of DRX configuration and DRX parameters may be associated with relatively higher-level configurations of the wireless communication system 200 (e.g., RRC configuration).

[0129] Therefore, adjusting DRX configurations and parameters can be associated with relatively high signaling overhead, which may increase data traffic and latency. Furthermore, a single DRX configuration (e.g., a single value for a DRX timer) applied to a wide range of applications may be relatively inefficient for at least some applications. For example, data traffic levels can be dynamic (e.g., resulting in relatively high or low activity for UE 115), and UE 115 may experience various power state changes, and a single DRX configuration may not be suitable for all the conditions experienced by UE 115 within the wireless communication system 200.

[0130] According to one or more techniques described herein, UE 115 and network entity 105 can support a more dynamic DRX configuration mechanism to improve power efficiency and enable wireless communication system 200 to be relatively more reliable (e.g., stable) across various communication conditions. For example, UE 115 can send (e.g., transmit, output, indicate) request 210 (e.g., sleep request, DRX transition request message) and can receive (e.g., obtain, identify) one or more control messages 220 (e.g., control indication), response 215 (e.g., response message), and one or more feedback messages 230, which can enable one or more DRX transitions (e.g., entering a sleep state) at UE 115.

[0131] In some examples, network entity 105 may configure (e.g., pre-configure via indication to one or more control messages 220) one or more DRX inactive timer values ​​for UE 115 to select (e.g., pick). UE 115 may then use various signaling mechanisms to indicate a specific DRX inactive timer value to be applied to subsequent DRX inactive timers (e.g., when starting or restarting the next timer). For example, UE 115 may indicate the requested DRX inactive timer value via Layer 1 (L1) signaling (e.g., Uplink Control Information (UCI)), Layer 2 (L2) signaling (e.g., Media Access Control Control Element (MACCE)), Layer 3 (L3) signaling (e.g., UE Assistance Information), or other signaling. If UE 115 uses L1 or L2 signaling, network entity 105 may send a response 215 via a downlink MAC CE (e.g., after receiving request 210). Response 215 may acknowledge, partially acknowledge, or reject request 210. For example, network entity 105 may indicate a different DRX inactivity timer value (e.g., different from that indicated in request 210) via response 215. In such an example, UE 115 may apply the value indicated by network entity 105 via response 215. Alternatively, if UE 115 uses L3 signaling, network entity 105 may send response 215 via RRC reconfiguration, which sets a new timer value for UE 115.

[0132] In some examples, request 210 may include an explicit indication made by UE 115. For example, request 210 may include an indication that UE 115 will transition to an inactive period of the DRX cycle (e.g., DRX inactivity period, entering sleep). Request 210 may also include the duration of the inactive period, determined (e.g., preferably) by UE 115, via L1 or L2 signaling. In some examples, after UE 115 sends request 210, UE 115 may start a timer to wait for a response 215 from network entity 105. In some examples, the timer may be the same as a HARQ retransmission timer (e.g., DRX configured). Network entity 105 may configure UE 115 via one or more control messages 220 to perform a state transition 225 (e.g., DRX transition) to an inactive period (e.g., entering sleep) if UE 115 does not receive a response 215 before the timer expires (e.g., autonomously). For example, UE 115 may be relatively close to the cell center, and UE 115 may assume that request 210 was successfully received by network entity 105. Alternatively, network entity 105 may configure UE 115 to avoid performing state transition 225 (e.g., remain active) if UE 115 does not receive a response 215 from network entity 105 before the timer expires.

[0133] If network entity 105 agrees to request 210 and UE 115 is configured to proactively perform state transition 225 based on the request, network entity 105 may not send response 215. Alternatively, if network entity 105 agrees to request 210 and UE 115 is configured to wait for response 215 before performing state transition 225, network entity 105 may send response 215 to acknowledge request 210 (e.g., via MAC CE). In some examples, if the MAC CE of response 215 does not include anything, response 215 may indicate that network entity 105 agrees to request 210. In some examples, if response 215 includes a sleep duration different from the sleep duration requested by UE 115, response 215 may indicate that network entity 105 agrees to request 210 for DRX transition but wants UE 115 to apply a different sleep duration. In such examples, UE 115 may comply with the sleep duration indicated by network entity 105.

[0134] If network entity 105 disagrees with request 210, it may send a scheduled downlink control information (DCI) message for a new HARQ transmission. If network entity 105 has no new data to transmit, such a DCI may schedule a transport block (TB) without a payload (e.g., a dummy TB). Based on receiving such a response 215 (e.g., after receiving the DCI), UE 115 may cancel its request 210 (e.g., its DRX transition request).

[0135] In some examples, network entity 105 may configure (e.g., pre-configure) several values ​​from which UE 115 can select a DRX cycle via one or more control messages 220. In such examples, UE 115 may (e.g., via request 210) indicate which DRX cycle value to use when entering a sleep state (e.g., an inactive period of the DRX cycle) (e.g., before). For example, UE 115 may wake up at a time location (e.g., a time resource) determined based on a DRX configuration (e.g., a DRX formula) using an indicated (e.g., indicated via UE 115 or network entity 105) DRX cycle value. Additionally or alternatively, UE 115 may directly indicate the duration of an inactive period of the DRX cycle. For example, UE 115 may wake up at a time resource (e.g., time location) equal to the time when request 210 was sent (e.g., the current time) plus the duration included in request 210 (e.g., the requested sleep duration, the sleep duration indicated by network entity 105 via response 215). In such an example, the requested sleep duration may be included in each request 210 from UE 115.

[0136] Additionally or alternatively, UE 115 may be configured using a DRX cycle comprising a set of active and inactive periods (e.g., via one or more control messages 220). UE 115 can use the DRX cycle configuration to determine the starting point of each subsequent on-time (e.g., active period) of the DRX cycle. In such an example, UE 115 may indicate via request 210 which active periods (e.g., on-time) the UE will wake up. UE 115 may indicate a parameter identifying a subgroup of active periods in which UE 115 will be active during the DRX cycle (e.g., which may be less than the total number of active periods in the DRX cycle). For example, UE 115 may indicate active periods that are integer multiples of the current time (e.g., a second on-time starting from the current time). Therefore, network entity 105 may not need to configure separate short and long DRX cycles. Additionally, such examples may eliminate the transition mechanism between short and long DRX cycles. Furthermore, in such examples, if the default sleep duration is not included in request 210, network entity 105 may configure the default sleep duration (e.g., via RRC).

[0137] UE 115 can support several options for operation after transitioning to an active period of DRX. In a first option, UE 115 can start a DRX activity timer (e.g., a DRX start duration timer) after its wake-up (e.g., transitioning to an active period of the DRX cycle). If downlink or uplink data is transmitted during the DRX active period, UE 115 can enter an active period (e.g., UE 115 remains active and continuously monitors the PDCCH) until UE 115 requests to enter sleep (e.g., sends request 210) and is put to sleep by network entity 105 (e.g., via a response or no response). If there is no uplink or downlink data when the activity timer (e.g., the start duration timer) expires, UE 115 can transition back to an inactive period (e.g., return to sleep). In some examples, the UE can use a default sleep duration as configured by network entity 105. In some examples, when UE 115 is operating during an active period (e.g., during an on-duration period), UE 115 may determine (e.g., select) to transmit a request 210 with a selected sleep duration (e.g., an initiation to sleep instruction). In such examples, the requested sleep duration may begin after the current active period has ended (e.g., UE 115 may not request early termination of the current on-duration period).

[0138] Alternatively, in the second option, UE 115 may not use an activity timer. For example, upon UE 115 wake-up, UE 115 may remain in the active period of the DRX (e.g., and monitor the PDCCH) until UE 115 determines that it should transition to the inactive period of the DRX (e.g., and sends request 210), or until network entity 105 sends response 215 (e.g., DRX MACCE) to transfer the UE to the inactive period. In such an example, UE 115 may send request 210 for each transition to the inactive period (e.g., even when UE 115 has no uplink data to communicate with network entity 105 and therefore will not otherwise send uplink transmissions).

[0139] In some examples, if network entity 105 configures an active timer in the DRX configuration (e.g., enables a duration timer), UE 115 may operate according to the first option. In some examples, if network entity 105 does not configure an active timer in the DRX configuration, UE 115 may operate according to the second option. Additionally or alternatively, network entity 105 may indicate via response 215 (e.g., or UE 115 may indicate via request 210) whether UE 115 should operate according to the first or second option when transitioning to an active period.

[0140] Additionally, in some examples, UE 115 may be configured to omit request 210 to reduce signaling traffic. To further reduce signaling traffic, network entity 105 may configure (e.g., RRC configuration) a default sleep duration (e.g., if the default sleep duration is not included in request 210). Additionally or alternatively, the sleep duration acknowledged or provided by network entity 105 may be persistent. That is, if subsequent requests 210 do not include the requested sleep duration, the sleep duration may be used (e.g., UE 115 may apply the previously indicated sleep duration to multiple DRX inactivity periods).

[0141] UE 115 can use machine learning models (e.g., AI engines, neural networks) to help determine (e.g., make decisions) when to transition to an inactive period and how long the UE should remain inactive during that period. For example, the AI ​​engine at UE 115 can collect information on uplink traffic arrivals, such as arrival intervals and the type of each PDU (e.g., control and data), and predict when data bursts are likely to end. The AI ​​engine can perform the same predictions for downlink traffic. When the AI ​​engine has a relatively high confidence (e.g., determines a relatively high probability) that both downlink and uplink traffic have stopped or are likely to stop within a threshold duration, UE 115 can send request 210 (e.g., request to enter sleep). For example, the arrival interval of the next data (e.g., or the prediction of the next data) may be longer than a threshold (e.g., long enough for the UE to have meaningful sleep), and the AI ​​engine can trigger UE 115 to send request 210. In some examples, the AI ​​engine can also predict when the next downlink data burst will arrive. Such predictions can allow UE 115 to determine how long it can remain inactive during the DRX's inactive period. This prediction can be based on one or more statistics of past arrival intervals of downlink data bursts.

[0142] In some examples, network entity 105 may send one or more feedback messages 230 to improve the machine learning model at UE 115. For example, network entity 105 may collect statistics about one or more requests 210 and may report the statistics to UE 115. The statistics may include an error distribution of the frequency of requests 210 being made too late or too early (e.g., defined by one or more thresholds). The statistics may also include an error distribution associated with the duration of the requested inactivity period (e.g., the frequency of UE wake-up being too early or too late, defined by one or more thresholds). Therefore, network entity 105 may provide such statistics back to UE 115 via one or more feedback messages 230, which UE 115 can use to train its machine learning model (e.g., an AI engine). The one or more feedback messages 230 may also include statistics associated with the scheduling behavior of network entity 105.

[0143] Therefore, by conveying one or more control messages 220, requests 210, responses 215, and one or more feedback messages 230, the wireless communication system 200 can support state transitions 225 (e.g., dynamic DRX transitions), which can increase energy savings and improve coordination between devices. For example, it can enable UE 115 to respond more quickly to data traffic fluctuations, thereby allowing UE 115 to remain inactive during DRX periods for a relatively long duration and increasing energy savings.

[0144] Figure 3Examples of a process flow 300 supporting enhanced UE state transitions according to one or more aspects of this disclosure are shown. In some examples, process flow 300 may implement aspects of wireless communication system 100 and wireless communication system 200. For example, process flow 300 may support signaling between UE 115 and network entity 105 to enable dynamic state transitions of UE 115. UE 115 and network entity 105 of process flow 300 may be as described herein (including references). Figure 1 and Figure 2 Examples of corresponding devices are provided. In the following description of process flow 300, operations between UE 115 and network entity 105 may be performed in a different order than shown, or other operations may be added to or removed from process flow 300. For example, some operations may also be omitted from process flow 300, or may be performed in a different order or at different times. Furthermore, although some operations or signaling are shown to occur at different times for discussion purposes, these operations may actually occur simultaneously. Although UE 115 and network entity 105 are shown as performing operations of process flow 300, some aspects of some operations may also be performed by one or more other wireless or network devices.

[0145] At 305, UE 115 may receive from network entity 105 an indication (e.g., control message 220) of a set of inactive timer values ​​associated with a transition from a first state to a second state at UE 115. For example, this set of inactive timer values ​​may be pre-configured and may be indicated to UE 115 via one or more control messages. In some examples, UE 115 may receive a control message (e.g., control message 220) from network entity 105 configuring UE 115 to transition from the first state to the second state based on timer expiration (e.g., UE 115 may autonomously transition), or to avoid transitioning from the first state to the second state based on timer expiration (e.g., waiting until a response is received before transitioning). Additionally or alternatively, UE 115 may receive a control message configuring a timer associated with sending a state transition request (e.g., request 210) or a timer associated with receiving a response from network entity 105 (e.g., response 215).

[0146] At 310, in some examples, UE 115 may determine predicted data activity between UE 115 and network entity 105. The predicted data activity may be based on a machine learning model (e.g., an AI engine, a neural network) at UE 115. For example, UE 115 may collect service arrival times, PDU types, or other metrics, and may use such metrics to predict future data activity. In some examples, UE 115 may determine to send a state transition request message based on a machine learning model.

[0147] At 315, when operating in the first state, UE 115 may send a request to network entity 105 for a transition from the first state to the second state (e.g., a state transition request, request 210) based on data activity between UE 115 and network entity 105. In some examples, the request for a transition from the first state to the second state may include a requested value for an inactive timer at UE 115 (e.g., a request from UE 115 for a DRX inactive timer, BWP inactive timer, data inactive timer, SCell deactivation timer). Alternatively, the request may include an indication of an inactive timer value selected from a set of inactive timer values ​​indicated (e.g., configured) in one or more control messages (e.g., at 305). That is, UE 115 may select an inactive timer value based on receiving an indication of that set of inactive timer values.

[0148] In some examples, UE 115 may send an indication of a request status for a second state via a request. The request status may be associated with various states, such as a sleep state, a wake-up state, a state associated with a target BWP, an RRC state, a state associated with the deactivation of an SCell, some other state, or any combination thereof. In some examples, UE 115 may send the request based on a threshold met by predicted data activity (e.g., from a machine learning model).

[0149] In some examples, UE 115 may send multiple subsequent state transition requests (e.g., one or more operations of process flow 300 may be applied multiple times). For example, UE 115 may operate in a third state and send a second request for transition from the third state to a fourth state based on data activity between UE 115 and network entity 105. In some examples, UE 115 may avoid sending a second request for state transition before a timer associated with the sending request (e.g., sending a subsequent request) expires.

[0150] At 320, UE 115 may initiate one or more timers based on a transmission request. In some examples, a first timer may be associated with receiving a response message from network entity 105 (e.g., the duration for which UE 115 anticipates receiving the response message). Additionally or alternatively, UE 115 may initiate a second timer associated with sending the transmission request (e.g., the duration for which UE 115 waits before sending a subsequent state transition request).

[0151] At 325, UE 115 may receive a response message (e.g., response 215) from network entity 105. In some examples, the UE may receive the response message based on receiving one or more control messages, sending a request to network entity 105, or both. In some examples, the response message may indicate that the request was accepted by network entity 105. Additionally or alternatively, the response message may indicate an inactive timer value from a set of inactive timer values ​​(e.g., pre-configured values) that differs from the inactive timer value requested by the UE. In such examples, UE 115 may use the inactive timer value from the response to transition from a first state to a second state. In some examples, the response message may indicate a specific state to which the UE wants to transition (e.g., indicating a second state). In some examples, UE 115 may receive a response message indicating that the request was rejected by network entity 105. UE 115 may receive the response message from network entity 105 before the timer associated with the response message expires.

[0152] At 330, UE 115 may transition from the first state to the second state based on sending a request, based on the expiration of an inactivity timer, based on UE 115 being able to receive a response message, or any combination thereof (e.g., performing state transition 225). Alternatively, UE 115 may avoid transitioning from the first state to the second state based on receiving a response message that denies UE 115's request.

[0153] In some examples, UE 115 may transition from a first state to a second state (e.g., an autonomous state transition) based on a control message (e.g., indicating a first configuration) that fails to receive a response message from network entity 105 before a timer expires. Alternatively, UE 115 may transition from a first state to a second state based on receiving a response message (e.g., UE 115 may wait to perform the requested transition until a response is received) based on a control message (e.g., indicating a second configuration). Additionally, UE 115 may transition from a first state to a second state based on a target state indicated by network entity 105, upon receiving a response message.

[0154] At 335, UE 115 may receive a feedback message (e.g., feedback message 230) associated with a request from network entity 105 based on sending a request. In some examples, the feedback message may include an error distribution associated with an incorrectly executed state transition (e.g., earlier than a time threshold, later than a time threshold, incorrect state). The given error distribution of the feedback message may be based on the type of state transition the UE is executing.

[0155] At 340, UE 115 can train a machine learning model based on feedback messages received from network entity 105. For example, UE 115 can update the model using error distribution statistics associated with its state transition request, which allows UE 115 to improve its predictions and send state transition requests to network entity 105 more accurately.

[0156] Figure 4 An example of a DRX cycle 400 supporting a dynamic DRX process is shown according to one or more aspects of this disclosure. The DRX cycle 400 may be exemplified according to this document (including references). Figure 1 and 2 The above describes a non-limiting example of the signaling sequence between UE 115 and network entity 105 using the technology described. For example, DRX cycle 400 may show multiple active periods 430 of the DRX cycle, and various messages on the time axis (e.g., along the horizontal axis) (e.g., at 405, at 410, etc.). Additionally, although Figure 4 A non-limiting example signaling sequence is shown, but DRX cycle 400 can occur at any time duration (e.g., including more or less time than shown) and can include any number of requests, responses, data, and other signaling, which can occur at different times and sequences than shown.

[0157] At 405, UE 115 may send a request (e.g., request 210, sleep request) to network entity 105. This request may be sent during the active period 430-a of DRX cycle 400 (e.g., before the inactivity timer expires). In some examples, UE 115 may initiate a timer associated with duration 440 (e.g., a HARQ round-trip time (RTT) timer, a timer associated with receiving a response from network entity 105). At 410, UE 115 may receive a response (e.g., response 215, MAC CE) from network entity 105 (e.g., within active period 430-a) that acknowledges the request. Based on the received response, UE 115 may transition to the inactivity period 435 of DRX cycle 400, which may be associated with duration 445 (e.g., sleep duration). In the example of DRX cycle 400, UE 115 may have already indicated duration 445 via a request, or may have already received indication of duration 445 via a response from network entity 105. Duration 445 can be a different duration (e.g., a longer duration) relative to the duration configured for DRX cycle 400 (e.g., via higher-layer signaling). Therefore, UE 115 can avoid activating (e.g., skip) the active period 450 of DRX cycle 400 based on sending a request, receiving a response, or both.

[0158] After duration 445, UE 115 may transition to the active period 430-b of DRX cycle 400. At 415, UE 115 may receive data that triggers a DRX inactivity timer, and UE 115 may continue to monitor additional downlink signaling (e.g., PDCCH, PDSCH). After data exchange, UE 115 may (e.g., based on a machine learning model) determine that there is no more uplink or downlink data to be transmitted. Therefore, at 420, UE 115 may send a second request to transition to the inactivity period of DRX cycle 400. In some examples, the second request may include a duration different from duration 445, or may not include any indication of duration. If the second request does not include an indication of duration, UE 115 may be configured to use (e.g., reuse) duration 445 for subsequent inactivity periods of the DRX cycle. At 425, UE 115 may receive a second response from network entity 105 accepting, partially accepting, or rejecting the second request.

[0159] Figure 5Examples of a process flow 500 supporting a dynamic DRX procedure according to one or more aspects of this disclosure are shown. In some examples, process flow 500 may implement aspects of wireless communication system 100, wireless communication system 200, and DRX cycle 400. For example, process flow 500 may support signaling between UE 115 and network entity 105 to enable dynamic DRX transitions.

[0160] UE 115 and network entity 105 in process flow 500 can be those described in this document (including references). Figures 1 to 3 Examples of corresponding devices are provided. In the following description of process flow 500, operations between UE 115 and network entity 105 may be performed in a different order than those shown, or additional operations may be added to or removed from process flow 500. For example, some operations may also be omitted from process flow 500, or may be performed in a different order or at different times. Furthermore, although some operations or signaling are shown to occur at different times for discussion purposes, these operations may actually occur simultaneously. Although UE 115 and network entity 105 are shown as performing operations of process flow 500, some aspects of some operations may also be performed by one or more other wireless or network devices.

[0161] At 505, UE 115 may receive one or more control messages from network entity 105 (e.g., one or more control messages 220 configuring the UE using one or more information elements). In some examples, the control messages may include indications of a set of DRX inactivity timer values ​​associated with an inactivity period of the DRX cycle transitioned by UE 115. In some examples, UE 115 may receive control messages from network entity 105 that configure UE 115 to transition to an inactivity period of the DRX cycle based on timer expiration, or to avoid transitioning to an inactivity period of the DRX cycle based on timer expiration. In some examples, such timers may be associated with a response message received from network entity 105 (e.g., response 215) (e.g., a response timer).

[0162] In some examples, UE 115 may receive, for example, an indication of one or more DRX cycle configurations from network entity 105 via a control message. The indication of DRX cycle configurations may include a set of active periods (e.g., on duration) and a set of inactive periods (e.g., sleep duration). In some examples, UE 115 may receive a control message that configures a timer associated with a transmission request (e.g., request 210, enter sleep request). In some examples, UE 115 may receive a control message that configures a default duration (e.g., default sleep duration, default timer value) for inactive periods used by UE 115 for DRX cycles.

[0163] At 510, in some examples, UE 115 may determine predicted data activity between UE 115 and network entity 105. The predicted data activity may be based on a machine learning model (e.g., an AI engine, a neural network) at UE 115. For example, UE 115 may collect service arrival times, PDU types, or other metrics, and may use such metrics to predict future data activity. In some examples, UE 115 may determine whether to send a request for DRX transition based on a machine learning model.

[0164] At point 515, UE 115 may, during an active period of the DRX cycle, send a request to network entity 105 for transitioning to an inactive period (e.g., sleep state) of the DRX cycle based on data activity between UE 115 and network entity 105 (e.g., based on data activity not meeting a threshold). In some examples, the request may include an indication of a first DRX inactive timer value from a set of DRX inactive timer values ​​(e.g., configured via control messages). The first DRX inactive timer value may be selected (e.g., picked) by UE 115 based on receiving an indication of a set of DRX inactive timer values ​​from network entity 105.

[0165] In some examples, UE 115 may send an indication via a request for the duration associated with an inactive period of a DRX cycle (e.g., a requested sleep duration). In some examples, the request may include (e.g., indicated by network entity 105) a first DRX cycle configuration from a set of DRX cycle configurations. The first DRX cycle configuration may be selected by UE 115 based on receiving an indication for a set of DRX cycle configurations. In some examples, the request may include a parameter identifying an active period subgroup within a set of active periods in which UE 115 is active (e.g., woken up) (e.g., indicated by network entity 105 via the DRX cycle configuration). In some examples, UE 115 may send the request based on (e.g., a threshold being met by a predicted data activity from a machine learning model).

[0166] In some examples, UE 115 may send multiple follow-up requests (e.g., one or more operations of procedure 500 may be applied multiple times). For example, UE 115 may send a second request to transition to a second inactive period of the DRX cycle during a second active period, based on data activity between UE 115 and network entity 105. In some examples, UE 115 may avoid sending a second request to transition to a second inactive period of the DRX cycle before the timer associated with the sending request (e.g., sending a follow-up request) expires based on a received control message.

[0167] At 520, UE 115 may start one or more timers based on a transmission request. In some examples, the first timer may be associated with receiving a response message from network entity 105 (e.g., the first timer may be the same as a HARQ retransmission timer or a HARQ RTT timer). Additionally or alternatively, UE 115 may start a second timer associated with sending the transmission request (e.g., the duration UE 115 waits before sending a subsequent request).

[0168] At 525, UE 115 may receive a response message (e.g., response 215) from network entity 105. In some examples, UE 115 may receive the response message based on receiving one or more control messages, sending a request, or both. In some examples, the response message may indicate that the request was accepted by network entity 105. Additionally or alternatively, the response message may indicate a second DRX inactivity timer value from a set of DRX inactivity timer values ​​(e.g., pre-configured values), which may differ from the DRX inactivity timer value indicated by the UE. UE 115 may use the second inactivity timer value to transition to an inactive period of the DRX cycle. In some examples, UE 115 may receive a response message from network entity 105 indicating that the request was rejected by network entity 105. In some examples, UE 115 may receive the response message from network entity 105 before the timer expires, and the response message may include an indication of the duration of the inactive period that UE 115 will use for the DRX cycle.

[0169] In some examples, UE 115 may receive a response message based on a send request before transitioning to an inactive period. The response message may indicate (e.g., configure) whether UE 115 should transition to an inactive period of the DRX cycle based on an activity timer value (e.g., the expiration of an enabled duration timer) or avoid transitioning to an inactive period of the DRX cycle until a send request is made.

[0170] At 530, UE 115 may transition to an inactive period of the DRX cycle (e.g., perform state transition 225, such as a DRX transition) based on sending a request, receiving a response message, or both. In some examples, UE 115 may avoid transitioning to an inactive period of the DRX cycle (e.g., cancel the transition) based on receiving a rejection via a response message. In some examples, UE 115 may transition to an inactive period of the DRX cycle based on a control message based on failing to receive a response message from network entity 105 before a timer expires (e.g., associated with waiting for a response message, UE 115 may be configured to transition autonomously in the absence of a response). Alternatively, UE 115 may transition to an inactive period of the DRX cycle based on a control message based on receiving a response message.

[0171] In some examples, UE 115 may determine to transition to an inactive period of the DRX period based on the presence of an active timer value in the DRX period configuration (e.g., the configured duration of an active period). Alternatively, UE 115 may determine to avoid transitioning to an inactive period of the DRX period based on the absence of an active timer value in the DRX period configuration until UE 115 sends a request to transition to an inactive period or until UE 115 receives a transition command from network entity 105. In some examples, UE 115 may use a default duration for inactive periods based on the absence of a duration in the request. In some examples, for a first inactive period and at least a second inactive period of the DRX period, UE 115 may use a first duration indicated via the request or via a response message from network entity 105. UE 115 may use a first duration for multiple inactive periods based on the absence of a duration in the request to transition to an inactive period.

[0172] At 535, UE 115 may receive a feedback message (e.g., feedback message 230) associated with a request from network entity 105 based on sending a request. In some examples, the feedback message may include an error distribution associated with the request (e.g., errors earlier than a time threshold, later than a time threshold, and errors associated with waking up and / or entering sleep outside the threshold).

[0173] At 540, UE 115 can train a machine learning model based on feedback messages received from network entity 105. For example, UE 115 can use error distribution statistics associated with the request to update the model, which allows UE 115 to improve its predictions and send requests to network entity 105 more accurately.

[0174] Figure 6 A block diagram 600 of a device 605 supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown. Device 605 may be an example of aspects of a UE 115 as described herein. Device 605 may include a receiver 610, a transmitter 615, and a communication manager 620. Device 605 or one or more components of device 605 (e.g., receiver 610, transmitter 615, communication manager 620) may include at least one processor that may be coupled to at least one memory to support the described techniques. Each of these components may communicate with each other (e.g., via one or more buses).

[0175] Receiver 610 may provide components for receiving information (such as packets, user data, control information, or any combination thereof) associated with various information channels (e.g., control channels, data channels, information channels associated with enhanced UE state transitions). The information may be delivered to other components of device 605. Receiver 610 may utilize a single antenna or a collection of antennas.

[0176] Transmitter 615 may provide components for transmitting signals generated by other components of device 605. For example, transmitter 615 may transmit information associated with various information channels (e.g., control channels, data channels, information channels associated with enhanced UE state transitions), such as packets, user data, control information, or any combination thereof. In some examples, transmitter 615 may be co-located with receiver 610 in a transceiver module. Transmitter 615 may utilize a single antenna or a collection of multiple antennas.

[0177] Device 605 or its various components may be examples of parts used to perform various aspects of enhanced UE state transitions as described herein. For example, communication manager 620 may include state transition request component 625, state transition component 630, or any combination thereof. In some examples, communication manager 620 or its various components may be configured to use receiver 610, transmitter 615, or both, or otherwise cooperate with them to perform various operations (e.g., receive, acquire, monitor, output, transmit). For example, communication manager 620 may receive information from receiver 610, transmit information to transmitter 615, or integrate with receiver 610, transmitter 615, or both to acquire information, output information, or perform various other operations as described herein.

[0178] Communication manager 620 can support wireless communication according to the examples disclosed herein. State transition request component 625 is capable of, configured to, or operable to support components that, when operating in a first state, send a request to a network entity for a transition from the first state to a second state based on data activity between the UE and the network entity. State transition component 630 is capable of, configured to, or operable to support components that transition from the first state to the second state based on sending a request.

[0179] Figure 7A block diagram 700 is shown of a communication manager 720 supporting enhanced UE state transitions according to one or more aspects of this disclosure. The communication manager 720 may be an example of aspects of the communication manager 620 as described herein. The communication manager 720 or its various components may be examples of parts for performing various aspects of enhanced UE state transitions as described herein. For example, the communication manager 720 may include a state transition request component 725, a state transition component 730, a state transition configuration component 735, a state transition response component 740, a timer component 745, a machine learning model 750, a feedback component 755, a model training component 760, a state transition response component 765, or any combination thereof. Each of these components, or its components or sub-components (e.g., one or more processors, one or more memories), may communicate directly or indirectly with each other (e.g., via one or more buses).

[0180] The communication manager 720 can support wireless communication according to the examples disclosed herein. The state transition request component 725 is capable of, configured to, or operable to support components that, when operating in the first state, send a request to a network entity for a transition from the first state to the second state based on data activity between the UE and the network entity. The state transition component 730 is capable of, configured to, or operable to support components that transition from the first state to the second state based on sending a request.

[0181] In some examples, the request to transition from the first state to the second state includes a request value for an inactivity timer at the UE. In some examples, the UE transitions from the first state to the second state based on the expiration of the inactivity timer.

[0182] In some examples, the state transition configuration component 735 is capable of, configured to, or operable to support components that receive from a network entity an indication of a set of inactive timer values ​​associated with a transition from a first state to a second state. In some examples, the request includes an indication of a first inactive timer value in the set of inactive timer values, the first inactive timer value being selected by the UE based on the received indication of the set of inactive timer values.

[0183] In some examples, the state transition response component 765 is capable of, configured to, or operable to support receiving a response message from a network entity based on receiving an indication and sending a request. In some examples, the response message indicates that: the request is accepted by the network entity; an indication of a second inactive timer value from a set of inactive timer values ​​for the UE to use in transitioning from a first state to a second state, the second inactive timer value being different from the first inactive timer value; or any combination thereof. In some examples, the transition from the first state to the second state is further based on receiving the response message.

[0184] In some examples, the state transition request component 725 is capable of, configured to, or operable to support the following: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state based on data activity between the UE and the network entity. In some examples, the state transition response component 740 is capable of, configured to, or operable to support the following: receiving a response message from the network entity based on sending the second request. In some examples, the response message indicates that the second request was rejected by the network entity. In some examples, the state transition component 730 is capable of, configured to, or operable to support the following: avoiding a transition from the third state to the fourth state based on receiving a response message.

[0185] In some examples, the state transition request component 725 is capable of, configured to, or operable to support components that send an indication of a request state for a second state via a request. In some examples, the request state is associated with: a sleep state, a wake-up state, a state associated with a target bandwidth portion, a radio resource control state, a state associated with the deactivation of a secondary cell, or any combination thereof.

[0186] In some examples, the state transition configuration component 735 is capable of, configured to, or operable to support components that receive control messages from a network entity, configuring whether the UE transitions from a first state to a second state based on the expiration of a timer, or avoids transitioning from the first state to the second state based on the expiration of a timer. In some examples, the timer is associated with receiving response messages from a network entity. In some examples, the timer component 745 is capable of, configured to, or operable to support components that initiate a timer based on a transmission request.

[0187] In some examples, the state transition component 730 is capable of, configured to, or can operate to support a transition from a first state to a second state based on a control message, provided that a response message has not been received from a network entity before a timer expires.

[0188] In some examples, the state transition response component 740 is capable of, configured to, or operable to support the following: receiving a response message from a network entity before a timer expires. In some examples, the state transition component 730 is capable of, configured to, or operable to support the following: transitioning from a first state to a second state based on a control message received from a response message.

[0189] In some examples, the state transition response component 740 is capable of, configured to, or operable to support components that receive a response message from a network entity before a timer expires. In some examples, the response message includes an indication state for which the UE will use a second state. In some examples, the state transition component 730 is capable of, configured to, or operable to support components that transition from a first state to a second state based on the indicated state upon receiving the response message.

[0190] In some examples, the state transition request component 725 is capable of, configured to, or operable to support the following: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state based on data activity between the UE and the network entity. In some examples, the state transition response component 740 is capable of, configured to, or operable to support the following: receiving an indication via a response message that the network entity has rejected the second request from the UE. In some examples, the state transition component 730 is capable of, configured to, or operable to support the following: avoiding a transition from the third state to the fourth state based on receiving a response message.

[0191] In some examples, machine learning model 750 is capable of, configured to, or operable to support components for: determining predicted data activity between the UE and a network entity based on the machine learning model at the UE. In some examples, sending a request is based on the predicted data activity meeting a threshold. In some examples, feedback component 755 is capable of, configured to, or operable to support components for: receiving a feedback message associated with a request from a network entity based on the sent request. In some examples, model training component 760 is capable of, configured to, or operable to support components for: training a machine learning model based on feedback messages received from a network entity.

[0192] In some examples, the state transition configuration component 735 is capable of, configured to, or operable to support the following component: receiving control messages configuring a timer associated with a send request. In some examples, the timer component 745 is capable of, configured to, or operable to support the following component: starting a timer based on a send request. In some examples, the state transition request component 725 is capable of, configured to, or operable to support the following component: preventing the sending of a second request for a transition from a third state to a fourth state before the timer expires.

[0193] Figure 8 A block diagram 800 of a device 805 supporting a dynamic DRX procedure according to one or more aspects of this disclosure is shown. Device 805 may be an example of aspects of device 605 or UE 115 as described herein. Device 805 may include a receiver 810, a transmitter 815, and a communication manager 820. Device 805 or one or more components of device 805 (e.g., receiver 810, transmitter 815, communication manager 820) may include at least one processor that may be coupled to at least one memory to support the described techniques. Each of these components may communicate with each other (e.g., via one or more buses).

[0194] Receiver 810 may provide components for receiving information (such as packets, user data, control information, or any combination thereof) associated with various information channels (e.g., control channels, data channels, information channels related to dynamic DRX processes). The information may be delivered to other components of device 805. Receiver 810 may utilize a single antenna or a collection of antennas.

[0195] Transmitter 815 may provide components for transmitting signals generated by other components of device 805. For example, transmitter 815 may transmit information associated with various information channels (e.g., control channels, data channels, information channels related to dynamic DRX processes), such as packets, user data, control information, or any combination thereof. In some examples, transmitter 815 may be co-located with receiver 810 in a transceiver module. Transmitter 815 may utilize a single antenna or a collection of multiple antennas.

[0196] Device 805 or its various components may be examples of parts for performing various aspects of the dynamic DRX process as described herein. For example, communication manager 820 may include DRX transition request component 825, DRX transition component 830, or any combination thereof. Communication manager 820 may be examples of aspects of communication manager 620 as described herein. In some examples, communication manager 820 or its various components may be configured to use receiver 810, transmitter 815, or both, or otherwise cooperate with them to perform various operations (e.g., receiving, acquiring, monitoring, outputting, transmitting). For example, communication manager 820 may receive information from receiver 810, transmit information to transmitter 815, or be integrated in combination with receiver 810, transmitter 815, or both to acquire information, output information, or perform various other operations as described herein.

[0197] Communication Manager 820 can support wireless communication according to the examples disclosed herein. DRX transition request component 825 is capable of, configured to, or operable to support components that, during an active period of the DRX cycle, send a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity. DRX transition component 830 is capable of, configured to, or operable to support components that, based on a transmission request, transition to an inactive period of the DRX cycle.

[0198] Figure 9 A block diagram 900 is shown of a communication manager 920 supporting a dynamic DRX process according to one or more aspects of this disclosure. The communication manager 920 may be an example of aspects of the communication manager 720 described herein. The communication manager 920 or its various components may be examples of components for performing various aspects of the dynamic DRX process described herein. For example, the communication manager 920 may include a DRX transition request component 925, a DRX transition component 930, a DRX transition configuration component 935, a DRX transition response component 940, a timer component 945, a data activity prediction component 950, a feedback component 955, a model training component 960, or any combination thereof. Each of these components, or its components or sub-components (e.g., one or more processors, one or more memories), may communicate directly or indirectly with each other (e.g., via one or more buses).

[0199] Communication Manager 920 can support wireless communication according to the examples disclosed herein. DRX transition request component 925 is capable of, configured to, or operable to support components that, during the active period of a DRX cycle, send a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity. DRX transition component 930 is capable of, configured to, or operable to support components that, based on sending a request, transition to an inactive period of the DRX cycle.

[0200] In some examples, the DRX transition configuration component 935 is capable of, configured to, or able to operate to support the following: receiving from a network entity an indication of a set of DRX inactivity timer values ​​associated with an inactivity period transitioning to a DRX cycle, wherein the request includes an indication of a first DRX inactivity timer value in the set of DRX inactivity timer values, the first DRX inactivity timer value being selected by the UE based on receiving the indication of the set of DRX inactivity timer values.

[0201] In some examples, the DRX transition response component 940 is capable of, configured to, or able to operate to support components for: receiving a response message from a network entity based on receiving an indication and sending a request, wherein the response message indicates that: the request is accepted by the network entity; an indication of a second DRX inactivity timer value from a set of DRX inactivity timer values ​​for the UE to use for transitioning to an inactivity period of the DRX cycle, the second DRX inactivity timer value being different from the first DRX inactivity timer value; or both, and wherein the transition to an inactivity period of the DRX cycle is further based on receiving the response message.

[0202] In some examples, the DRX transition request component 925 is capable of, configured to, or operable to support the following: during a second active period of a second DRX cycle, sending a second request for transition to a second inactive period of the second DRX cycle based on data activity between the UE and a network entity. In some examples, the DRX transition response component 940 is capable of, configured to, or operable to support the following: receiving a second response message from a network entity based on sending the second request, wherein the second response message indicates that the second request was rejected by the network entity. In some examples, the DRX transition component 930 is capable of, configured to, or operable to support the following: avoiding transition to a second inactive period of the second DRX cycle based on receiving the second response message.

[0203] In some examples, the DRX transition request component 925 can be, configured, or operated to support components that send an indication of the duration of an inactive period associated with a DRX cycle via a request.

[0204] In some examples, the DRX transition configuration component 935 is capable of, configured to, or operable to support the following: receiving a control message from a network entity that configures whether the UE should transition to an inactive period of the DRX cycle based on the expiration of a timer, or avoid transitioning to an inactive period of the DRX cycle based on the expiration of a timer, wherein the timer is associated with receiving a response message from a network entity. In some examples, the timer component 945 is capable of, configured to, or operable to support the following: starting a timer based on a transmission request.

[0205] In some examples, the DRX transition component 930 is capable of, configured to, or can operate to support components that transition to an inactive period of the DRX cycle based on a control message, if a response message is not received from a network entity before a timer expires.

[0206] In some examples, the DRX transition response component 940 is capable of, configured to, or operable to support components that receive a response message from a network entity before a timer expires, wherein the response message includes an indication of the duration of an inactive period for which the UE will use the DRX cycle. In some examples, the DRX transition component 930 is capable of, configured to, or operable to support components that, based on the received response message, transition to an inactive period of the DRX cycle according to a control message.

[0207] In some examples, the DRX transition request component 925 is capable of, configured to, or operable to support the following: sending a second request for transitioning to a second inactive period of the second DRX cycle based on data activity between the UE and a network entity during a second active period of the second DRX cycle. In some examples, the DRX transition response component 940 is capable of, configured to, or operable to support the following: receiving an indication via a second response message that a network entity has rejected the second request from the UE. In some examples, the DRX transition component 930 is capable of, configured to, or operable to support the following: avoiding transitioning to a second inactive period of the second DRX cycle based on receiving a second response message.

[0208] In some examples, the DRX transition configuration component 935 is capable of, configured to, or able to operate to support the following: receiving from a network entity an indication of a set of DRX periodic configurations, wherein the request includes a first DRX periodic configuration in the set of DRX periodic configurations, the first DRX periodic configuration being selected by the UE based on the received indication of the set of DRX periodic configurations.

[0209] In some examples, the DRX transition configuration component 935 is capable of, configured to, or able to operate to support the following: receiving from a network entity an indication of a DRX period configuration comprising a set of active periods and a set of inactive periods, wherein the request includes a parameter that identifies the active period subgroup in which the UE is active within the set of active periods.

[0210] In some examples, the DRX transition component 930 is capable of, can be configured to, or can operate to support components that determine inactive periods of the DRX cycle based on the presence of an active timer value in the DRX cycle configuration.

[0211] In some examples, the DRX transition component 930 is capable of, configured to, or can operate to support components that determine a second inactive period to avoid transitioning to the DRX period based on the absence of an active timer value in the DRX period configuration, until a second request to transition to the second inactive period is sent, or until a command is received from a network entity.

[0212] In some examples, the DRX transition response component 940 is capable of, configured to, or can operate to support components that receive a response message based on a send request before transitioning to an inactive period, wherein the response message indicates whether the UE should transition to an inactive period of the DRX cycle based on an activity timer value, or avoid transitioning to an inactive period of the DRX cycle until a send request is received.

[0213] In some examples, the data activity prediction component 950 is capable of, configured to, or operable to support components for: determining predicted data activity between the UE and a network entity based on a machine learning model at the UE, wherein sending a request is based on the predicted data activity meeting a threshold. In some examples, the feedback component 955 is capable of, configured to, or operable to support components for: receiving a feedback message associated with a request from a network entity based on a sending request. In some examples, the model training component 960 is capable of, configured to, or operable to support components for: training a machine learning model based on feedback messages received from a network entity.

[0214] In some examples, the DRX transition configuration component 935 is capable of, configured to, or operable to support the following: receiving control messages configuring a timer associated with a send request. In some examples, the timer component 945 is capable of, configured to, or operable to support the following: starting a timer based on a send request. In some examples, the DRX transition request component 925 is capable of, configured to, or operable to support the following: based on receiving a control message, preventing the sending of a second request to transition to a second inactive period of the DRX cycle before the timer expires.

[0215] In some examples, the DRX transition configuration component 935 is capable of, can be configured to, or can operate to support the following: receiving a control message that configures a default duration for the inactive period of the DRX cycle for the UE, wherein the UE uses the default duration for the inactive period based on the absence of a duration in the request.

[0216] In some examples, for at least a second inactive period and a DRX cycle, the UE uses a first duration indicated by a request or by a response message from a network entity based on the absence of a second duration in a second request to transition to the second inactive period.

[0217] Figure 10 A diagram of a system 1000 including device 1005 supporting enhanced UE state transitions and dynamic DRX procedures, according to one or more aspects of this disclosure, is shown. Device 1005 may be an example of device 605 or UE 115 as described herein, or a component including a device or UE. Device 1005 may communicate with one or more other devices (e.g., network entity 105, UE 115, or a combination thereof) (e.g., wirelessly). Device 1005 may include components for bidirectional voice and data communication, including components for transmitting and receiving communications, such as a communication manager 1020, an input / output (I / O) controller (e.g., I / O controller 1010), a transceiver 1015, one or more antennas 1025, at least one memory 1030, code 1035, and at least one processor 1040. These components may communicate electronically or otherwise (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 1045).

[0218] I / O controller 1010 manages the input and output signals of device 1005. I / O controller 1010 can also manage peripheral devices not integrated into device 1005. In some cases, I / O controller 1010 may represent a physical connection or port to an external peripheral device. In some cases, I / O controller 1010 may utilize an operating system such as iOS.® ANDROID ® MS-DOS ® MS-WINDOWS ® OS / 2 ® UNIX ® LINUX ® Alternatively, the I / O controller 1010 may represent or interact with a modem, keyboard, mouse, touchscreen, or similar device. In some cases, the I / O controller 1010 may be implemented as part of one or more processors, such as at least one processor 1040. In some cases, a user may interact with the device 1005 via the I / O controller 1010 or via hardware components controlled by the I / O controller 1010.

[0219] In some cases, device 1005 may include a single antenna. However, in other cases, device 1005 may have more than one antenna, which may be capable of concurrently transmitting or receiving multiple wireless transmissions. Transceiver 1015 may communicate bidirectionally via one or more antennas 1025 using a wired or wireless link as described herein. For example, transceiver 1015 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. Transceiver 1015 may also include a modem for: modulating packets; providing the modulated packets to one or more antennas 1025 for transmission; and demodulating packets received from one or more antennas 1025. Transceiver 1015, or transceiver 1015 and one or more antennas 1025, may be an example of transmitter 615, receiver 610, or any combination thereof or components thereof as described herein.

[0220] At least one memory 1030 may include random access memory (RAM) and read-only memory (ROM). At least one memory 1030 may store computer-readable code, computer-executable code, or processor-executable code, such as code 1035. Code 1035 may include instructions that, when executed by at least one processor 1040, cause device 1005 to perform the various functions described herein. Code 1035 may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some cases, code 1035 may not be directly executable by at least one processor 1040, but may (e.g., when compiled and executed) cause the computer to perform the functions described herein. In some additional cases, at least one memory 1030 may also include a basic I / O system (BIOS) that controls basic hardware or software operations, such as interaction with peripheral components or devices.

[0221] At least one processor 1040 may include one or more intelligent hardware devices (e.g., one or more general-purpose processors, one or more DSPs, one or more CPUs, one or more graphics processing units (GPUs), one or more neural processing units (NPUs) (also referred to as neural network processors or deep learning processors (DLPs)), one or more microcontrollers, one or more ASICs, one or more FPGAs, one or more programmable logic devices, discrete gate or transistor logic units, one or more discrete hardware components, or any combination thereof). In some cases, at least one processor 1040 may be configured to use a memory controller to operate a memory array. In some other cases, the memory controller may be integrated into at least one processor 1040. At least one processor 1040 may be configured to execute computer-readable instructions stored in memory (e.g., at least one memory 1030) to cause device 1005 to perform various functions (e.g., functions or tasks supporting enhanced UE state transitions or dynamic DRX procedures). For example, device 1005 or components thereof may include at least one processor 1040 and at least one memory 1030 coupled to or coupled to the at least one processor 1040, wherein the at least one processor 1040 and the at least one memory 1030 are configured to perform the various functions described herein.

[0222] In some examples, at least one processor 1040 may include multiple processors, and at least one memory 1030 may include multiple memories. One or more of the multiple processors may be coupled to one or more of the multiple memories, which may be configured individually or collectively to perform the various functions described herein. In some examples, at least one processor 1040 may be a component of a processing system, which may refer to a system of machines (such as a series of machines), circuitry (including, for example, one or both of processor circuitry (which may include at least one processor 1040) and memory circuitry (which may include at least one memory 1030)) or components that receive or receive input and process the input to produce, generate, or obtain a set of outputs. The processing system may be configured to perform one or more of the functions described herein. For example, at least one processor 1040 or a processing system including at least one processor 1040 may be configured, configured to, or operable to cause device 1005 to perform one or more of the functions described herein. Furthermore, as described herein, “configured to,” “capable of being configured to,” and “capable of operating to” can be used interchangeably and can be associated with the ability to perform one or more of the functions described herein when executing code 1035 (e.g., processor-executable code) stored in at least one memory 1030 or otherwise.

[0223] The communication manager 1020 can support wireless communication according to the examples disclosed herein. For example, the communication manager 1020 is capable of, configured to, or operable to support components that, when operating in a first state, send a request to a network entity for a transition from the first state to a second state based on data activity between the UE and the network entity. The communication manager 1020 is capable of, configured to, or operable to support components that transition from the first state to the second state based on sending a request.

[0224] The communication manager 1020 can support wireless communications according to the examples disclosed herein. For example, the communication manager 1020 can, is configured, or is operable to support components that, during an active period of a DRX cycle, transmit a request to transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity. The communication manager 1020 can, is configured, or is operable to support components that, based on a transmission request, transition to an inactive period of the DRX cycle.

[0225] By including or configuring a communication manager 1020 according to an example as described herein, device 1005 can support technologies for reducing latency, lowering power consumption, utilizing communication resources more efficiently, improving coordination between devices, extending battery life, and enhancing processing power.

[0226] In some examples, the communication manager 1020 may be configured to perform various operations (e.g., receiving, monitoring, transmitting) using transceiver 1015, one or more antennas 1025, or any combination thereof, or otherwise cooperating with them. Although the communication manager 1020 is illustrated as a separate component, in some examples, one or more functions described with reference to the communication manager 1020 may be supported or executed by at least one processor 1040, at least one memory 1030, code 1035, or any combination thereof. For example, code 1035 may include instructions that can be executed by at least one processor 1040 to cause device 1005 to perform various aspects of the enhanced UE state transition and dynamic DRX procedures as described herein, or at least one processor 1040 and at least one memory 1030 may be otherwise configured to perform or support such operations individually or jointly.

[0227] Figure 11 A flowchart illustrating a method 1100 for supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown. The operation of method 1100 can be implemented by a UE or its components as described herein. For example, the operation of method 1100 can be implemented by, as referenced... Figures 1 to 10The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0228] At 1105, the method may include: when operating in the first state, sending a request to the network entity for a transition from the first state to the second state based on data activity between the UE and the network entity. The operation at 1105 may be performed according to examples as disclosed herein. In some examples, aspects of the operation at 1105 may be provided by reference to... Figure 7 The described state transition request component 725 is to perform it.

[0229] At 1110, the method may include: transitioning from a first state to a second state based on sending a request. The operation of 1110 may be performed according to examples disclosed herein. In some examples, aspects of the operation of 1110 may be derived from references... Figure 7 The described state transition component 730 is used to perform this.

[0230] Figure 12 A flowchart illustrating a method 1200 for supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown. The operation of method 1200 can be implemented by a UE or its components as described herein. For example, the operation of method 1200 can be implemented by, as referenced... Figures 1 to 10 The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0231] At 1205, the method may include: receiving from a network entity an indication of a set of inactive timer values ​​associated with a transition from a first state to a second state. The operation of 1205 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1205 may be provided by reference to [reference needed]. Figure 7 The described state transition configuration component 735 is used to perform this.

[0232] At 1210, the method may include: when operating in a first state, sending a request to a network entity for a transition from the first state to a second state based on data activity between the UE and the network entity, wherein the request includes an indication of a first inactive timer value from a set of inactive timer values, the first inactive timer value being selected by the UE based on receiving the indication of the set of inactive timer values. The operation of 1210 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1210 may be provided by reference to [reference needed]. Figure 7 The described state transition request component 725 is to perform it.

[0233] At point 1215, the method may include: transitioning from a first state to a second state based on sending a request. The operation at 1215 may be performed according to examples disclosed herein. In some examples, aspects of the operation at 1215 may be derived from references... Figure 7 The described state transition component 730 is used to perform this.

[0234] Figure 13 A flowchart illustrating a method 1300 for supporting enhanced UE state transitions according to one or more aspects of this disclosure is shown. Operation of method 1300 may be implemented by a UE or its components as described herein. For example, operation of method 1300 may be performed by, as referenced... Figures 1 to 10 The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0235] At 1305, the method may include: receiving a control message from a network entity, the control message configuring whether the UE should transition from a first state to a second state based on the expiration of a timer, or avoid transitioning from the first state to the second state based on the expiration of a timer, wherein the timer is associated with receiving a response message from the network entity. The operation of 1305 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1305 may be provided by reference to [reference needed]. Figure 7 The described state transition configuration component 735 is used to perform this.

[0236] At 1310, the method may include: when operating in the first state, sending a request to the network entity for a transition from the first state to the second state based on data activity between the UE and the network entity. The operation of 1310 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1310 may be provided by reference to [reference needed]. Figure 7 The described state transition request component 725 is to perform it.

[0237] At 1315, the method may include: starting a timer based on a request to be sent. The operation of 1315 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1315 may be derived from references... Figure 7 The timer component 745 described is used for execution.

[0238] At 1320, the method may include: transitioning from a first state to a second state based on sending a request. The operation of 1320 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1320 may be derived from references... Figure 7 The described state transition component 730 is used to perform this.

[0239] Figure 14 A flowchart illustrating a method 1400 supporting a dynamic DRX procedure according to one or more aspects of this disclosure is shown. Operation of method 1400 may be implemented by a UE or its components as described herein. For example, operation of method 1400 may be performed by, as referenced... Figures 1 to 13 The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0240] At 1405, the method may include: during an active period of a DRX cycle, sending a request for transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity. The operation at 1405 may be performed according to examples as disclosed herein. In some examples, aspects of the operation at 1405 may be provided by reference to... Figure 9 The described DRX transformation request component 925 is used to perform this.

[0241] At 1410, the method may include: transitioning to an inactive period of the DRX cycle based on a sending request. The operation of 1410 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1410 may be derived from references... Figure 9 The described DRX transformation component 930 is used to perform this.

[0242] Figure 15 A flowchart illustrating a method 1500 supporting a dynamic DRX procedure according to one or more aspects of this disclosure is shown. Operation of method 1500 may be implemented by a UE or its components as described herein. For example, operation of method 1500 may be performed by, as referenced... Figures 1 to 14 The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0243] At 1505, the method may include: receiving from a network entity an indication of a set of DRX inactivity timer values ​​associated with an inactivity period transitioning to a DRX cycle. The operation of 1505 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1505 may be provided by reference to... Figure 9 The described DRX transformation configuration component 935 is used to perform this.

[0244] At 1510, the method may include: during an active period of a DRX cycle, sending a request for transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity, wherein the request includes an indication of a first DRX inactive timer value from a set of DRX inactive timer values, the first DRX inactive timer value being selected by the UE based on receiving the indication of the set of DRX inactive timer values. The operation of 1510 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1510 may be provided by reference to [reference needed]. Figure 9 The described DRX transformation request component 925 is used to perform this.

[0245] At point 1515, the method may include: transitioning to an inactive period of the DRX cycle based on a sending request. The operation of point 1515 may be performed according to examples disclosed herein. In some examples, aspects of the operation of point 1515 may be derived from references... Figure 9 The described DRX transformation component 930 is used to perform this.

[0246] Figure 16 A flowchart illustrating a method 1600 supporting a dynamic DRX procedure according to one or more aspects of this disclosure is shown. Operation of method 1600 may be implemented by a UE or its components as described herein. For example, operation of method 1600 may be performed by, as referenced... Figures 1 to 15 The UE 115 described herein is used to perform this function. In some examples, the UE can execute a set of instructions to control the functional elements of the UE to perform the described function. Additionally or alternatively, the UE may use dedicated hardware to perform aspects of the described function.

[0247] At 1605, the method may include: during an active period of a DRX cycle, sending a request for transition to an inactive period of the DRX cycle based on data activity between the UE and a network entity. The operation of 1605 may be performed according to the examples disclosed herein. In some examples, aspects of the operation of 1605 may be provided by reference to [reference needed]. Figure 9 The described DRX transformation request component 925 is used to perform this.

[0248] At 1610, the method may include: sending an indication of the duration of an inactive period associated with a DRX cycle via a request. The operation of 1610 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1610 may be provided by reference to... Figure 9 The described DRX transformation request component 925 is used to perform this.

[0249] At 1615, the method may include: transitioning to an inactive period of the DRX cycle based on a sending request. The operation of 1615 may be performed according to examples as disclosed herein. In some examples, aspects of the operation of 1615 may be derived from references... Figure 9 The described DRX transformation component 930 is used to perform this.

[0250] The following provides an overview of the various aspects of this disclosure: Aspect 1: A method for wireless communication by a UE, the method comprising: when operating in a first state, sending a request to the network entity for a transition from the first state to a second state based at least in part on data activity between the UE and the network entity, wherein the transition from the first state to the second state is associated with an inactivity timer at the UE; and, based at least in part on sending the request, transitioning from the first state to the second state according to the state of the inactivity timer.

[0251] Aspect 2: According to the method of aspect 1, wherein the request for transition from the first state to the second state includes a request value for the inactivity timer at the UE; and the UE transitions from the first state to the second state at least in part based on the expiration of the inactivity timer.

[0252] Aspect 3: The method according to any one of Aspects 1 to 2, the method further comprising: receiving from the network entity an indication of a set of inactive timer values ​​for the inactive timer, wherein the request includes an indication of a first inactive timer value in the set of inactive timer values, the first inactive timer value being selected by the UE at least in part based on receiving the indication of the set of inactive timer values.

[0253] Aspect 4: The method according to aspect 3, the method further comprising: receiving a response message from the network entity based at least in part on receiving the indication and sending the request, wherein the response message indicates that: the request is accepted by the network entity; an indication of a second inactive timer value of the set of inactive timer values ​​for the UE to use to transition from the first state to the second state, the second inactive timer value being different from the first inactive timer value; or any combination thereof, and wherein the transition from the first state to the second state is further based at least in part on receiving the response message.

[0254] Aspect 5: The method according to any one of Aspects 1 to 2, the method further comprising: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state based at least in part on data activity between the UE and the network entity; receiving a response message from the network entity based at least in part on sending the second request, wherein the response message indicates that the second request was rejected by the network entity; and avoiding a transition from the third state to the fourth state based at least in part on receiving the response message.

[0255] Aspect 6: The method according to any one of Aspects 1 to 5, the method further comprising: sending an indication of a request state for the second state via the request, wherein the request state is associated with: a sleep state, a wake-up state, a state associated with a target BWP, an RRC state, a state associated with the deactivation of a secondary cell, or any combination thereof.

[0256] Aspect 7: The method according to any one of Aspects 1 to 6, the method further comprising: receiving a control message from the network entity, the control message configuring whether the UE is to transition from the first state to the second state at least in part based on the expiration of a timer, or to avoid transitioning from the first state to the second state at least in part based on the expiration of the timer, wherein the timer is associated with receiving a response message from the network entity; and starting the timer at least in part based on sending the request.

[0257] Aspect 8: The method according to aspect 7 further includes: transitioning from the first state to the second state based on the control message, at least in part, based on the failure to receive the response message from the network entity before the timer expires.

[0258] Aspect 9: The method according to aspect 7, the method further comprising: receiving the response message from the network entity before the timer expires; and transitioning from the first state to the second state based on the control message, at least in part, based on the receipt of the response message.

[0259] Aspect 10: The method according to any one of Aspects 7 and 9, the method further comprising: receiving the response message from the network entity before the timer expires, wherein the response message includes an indication state for the UE to use in the second state; and transitioning from the first state to the second state based at least in part on the indication state, based on the receipt of the response message.

[0260] Aspect 11: The method according to any one of Aspects 7 and 9, the method further comprising: when operating in a third state, sending a second request to the network entity for a transition from the third state to a fourth state, at least in part based on data activity between the UE and the network entity; receiving, via the response message, an indication that the network entity rejects the second request from the UE; and avoiding a transition from the third state to the fourth state, at least in part based on receiving the response message.

[0261] Aspect 12: The method according to any one of Aspects 1 to 11, the method further comprising: determining, at least in part, a predicted data activity between the UE and the network entity based on a machine learning model at the UE, wherein sending the request is at least in part based on the predicted data activity satisfying a threshold; receiving, at least in part, a feedback message associated with the request from the network entity based on sending the request; and training the machine learning model at least in part based on the feedback message received from the network entity.

[0262] Aspect 13: The method according to any one of Aspects 1 to 12, the method further comprising: receiving a control message configuring a timer associated with sending the request; starting the timer at least in part based on sending the request; and avoiding sending a second request for a transition from a third state to a fourth state before the timer expires.

[0263] Aspect 14: A UE for wireless communication, the UE comprising: one or more memories storing processor-executable code; and one or more processors coupled to the one or more memories and capable of operating individually or jointly to execute the code, so that the UE performs a method according to any one of Aspects 1 to 13.

[0264] Aspect 15: A UE for wireless communication, the UE comprising at least one component for performing a method according to any one of aspects 1 to 13.

[0265] Aspect 16: A non-transitory computer-readable medium storing code for wireless communication, said code including instructions executable by one or more processors to perform the method according to any one of aspects 1 to 13.

[0266] Aspect 17: A method for wireless communication by a UE, the method comprising: during an active period of a DRX cycle, sending a request to transition to an inactive period of the DRX cycle based at least in part on data activity between the UE and a network entity; and transitioning to the inactive period of the DRX cycle based at least in part on sending the request.

[0267] Aspect 18: The method according to aspect 17, the method further comprising: receiving from the network entity an indication of a set of DRX inactivity timer values ​​associated with the inactivity period transitioning to the DRX cycle, wherein the request includes an indication of a first DRX inactivity timer value in the set of DRX inactivity timer values, the first DRX inactivity timer value being selected by the UE at least in part based on receiving the indication of the set of DRX inactivity timer values.

[0268] Aspect 19: The method according to aspect 18, the method further comprising: receiving a response message from the network entity based at least in part on receiving the indication and sending the request, wherein the response message indicates that: the request is accepted by the network entity; an indication of a second DRX inactivity timer value of the set of DRX inactivity timer values ​​for the UE to transition to the inactivity period of the DRX cycle, the second DRX inactivity timer value being different from the first DRX inactivity timer value; or both, and wherein the transition to the inactivity period of the DRX cycle is further based at least in part on receiving the response message.

[0269] Aspect 20: The method according to aspect 17, the method further comprising: during a second active period of a second DRX cycle, sending a second request to transition to a second inactive period of the second DRX cycle based at least in part on data activity between the UE and the network entity; receiving a second response message from the network entity based at least in part on sending the second request, wherein the second response message indicates that the second request was rejected by the network entity; and avoiding transition to the second inactive period of the second DRX cycle based at least in part on receiving the second response message.

[0270] Aspect 21: The method according to any one of aspects 17 to 20, the method further comprising: sending an indication of the duration associated with the inactive period of the DRX cycle via the request.

[0271] Aspect 22: The method according to any one of Aspects 17 to 21, the method further comprising: receiving a control message from the network entity, the control message configuring whether the UE is to transition to the inactive period of the DRX cycle at least in part based on the expiration of a timer, or to avoid transitioning to the inactive period of the DRX cycle at least in part based on the expiration of the timer, wherein the timer is associated with receiving a response message from the network entity; and starting the timer at least in part based on sending the request.

[0272] Aspect 23: The method according to aspect 22, the method further comprising: transitioning to the inactive period of the DRX cycle based on the control message, at least in part, based on the failure to receive the response message from the network entity before the timer expires.

[0273] Aspect 24: The method according to aspect 22, the method further comprising: receiving the response message from the network entity before the timer expires; wherein the response message includes an indication duration of the inactivity period for which the UE will use the DRX cycle; and transitioning to the inactivity period of the DRX cycle based on the control message, at least in part based on receiving the response message.

[0274] Aspect 25: The method according to aspect 22, the method further comprising: during a second active period of a second DRX cycle, sending a second request to transition to a second inactive period of the second DRX cycle based at least in part on data activity between the UE and the network entity; receiving an indication via a second response message that the network entity rejects the second request from the UE; and avoiding transition to the second inactive period of the second DRX cycle based at least in part on receiving the second response message.

[0275] Aspect 26: The method according to any one of Aspects 17 to 25, the method further comprising: receiving from the network entity an indication of a set of DRX periodic configurations, wherein the request includes a first DRX periodic configuration of the set of DRX periodic configurations, the first DRX periodic configuration being selected by the UE at least in part based on receiving the indication of the set of DRX periodic configurations.

[0276] Aspect 27: The method according to any one of Aspects 17 to 26, the method further comprising: receiving from the network entity an indication of a DRX period configuration including a set of active periods and a set of inactive periods, wherein the request includes parameters identifying an active period subgroup in which the UE is active within the set of active periods.

[0277] Aspect 28: The method according to any one of Aspects 17 to 27, the method further comprising: determining, at least in part, the inactive period of the DRX cycle that transitions to the DRX cycle based on the presence of an active timer value in the configuration of the DRX cycle.

[0278] Aspect 29: The method according to any one of Aspects 17 to 27, the method further comprising: determining, at least in part, a second inactive period to avoid transitioning to the DRX period based on the absence of an active timer value in the configuration of the DRX period, until a second request to transition to the second inactive period is sent, or until a command is received from the network entity.

[0279] Aspect 30: The method according to any one of Aspects 17 to 29, the method further comprising: receiving a response message at least in part based on sending the request before transitioning to the inactive period, wherein the response message indicates whether the UE wants to transition to the inactive period of the DRX cycle according to an activity timer value, or to avoid transitioning to the inactive period of the DRX cycle until the request is sent.

[0280] Aspect 31: The method according to any one of Aspects 17 to 30, the method further comprising: determining, at least in part, a predicted data activity between the UE and the network entity based on a machine learning model at the UE, wherein sending the request is at least in part based on the predicted data activity satisfying a threshold; receiving, at least in part, a feedback message associated with the request from the network entity based on sending the request; and training the machine learning model at least in part based on the feedback message received from the network entity.

[0281] Aspect 32: The method according to any one of Aspects 17 to 31, the method further comprising: receiving a control message configuring a timer associated with sending the request; starting the timer at least in part based on sending the request; and avoiding sending a second request for a second inactive period transitioning to the DRX cycle before the timer expires, at least in part based on receiving the control message.

[0282] Aspect 33: The method according to any one of Aspects 17 to 32, the method further comprising: receiving a control message, the control message configuring a default duration for the UE to use for the inactive period of the DRX cycle, wherein the UE uses the default duration for the inactive period at least in part based on the absence of duration in the request.

[0283] Aspect 34: The method according to any one of Aspects 17 to 33, wherein for the inactivity period and at least a second inactivity period of the DRX cycle, the UE uses a first duration indicated by the request or by a response message from the network entity, at least in part based on the absence of a second duration in a second request to transition to the second inactivity period.

[0284] Aspect 35: A UE for wireless communication, the UE comprising: one or more memories storing processor-executable code; and one or more processors coupled to the one or more memories and capable of operating individually or jointly to execute the code, so that the UE performs a method according to any one of aspects 17 to 34.

[0285] Aspect 36: A UE for wireless communication, the UE including at least one component for performing a method according to any one of aspects 17 to 34.

[0286] Aspect 37: A non-transitory computer-readable medium storing code for wireless communication, said code including instructions executable by one or more processors to perform a method according to any one of aspects 17 to 34.

[0287] Additional example implementations of the techniques discussed herein are described in the appendix.

[0288] It should be noted that the methods described herein describe possible specific implementations. Operations and steps may be rearranged or otherwise modified, and other specific implementations are also possible. Furthermore, aspects from two or more of these methods may be combined.

[0289] While aspects of LTE, LTE-A, LTE-A Pro, or NR systems may be described for illustrative purposes, and the terms LTE, LTE-A, LTE-A Pro, or NR may be used in most of the description, the techniques described herein are also applicable to networks outside of LTE, LTE-A, LTE-A Pro, or NR networks. For example, the techniques described are applicable to a variety of other wireless communication systems, such as Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, and other systems and radio technologies not explicitly mentioned herein.

[0290] The information and signals described herein can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout the description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or optical particles, or any combination thereof.

[0291] The various exemplary blocks and components described herein can be implemented or performed using general-purpose processors, DSPs, ASICs, CPUs, graphics processing units (GPUs), neural processing units (NPUs), FPGAs or other programmable logic devices, discrete gate or transistor logic units, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in alternatives, a processor may be any processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration). Any function or operation described herein that can be performed by a processor may be performed by multiple processors capable of performing the described functions or operations individually or jointly.

[0292] The functions described herein can be implemented using hardware, software executed by a processor, firmware, or any combination thereof. When implemented using software executed by a processor, the functions can be stored as one or more instructions or code on a computer-readable medium or transmitted using one or more instructions or code on a computer-readable medium. Other examples and specific implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described herein can be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination of these. Features implementing the functions can also be physically located in various locations, including portions distributed such that the functions are implemented in different physical locations.

[0293] Computer-readable media includes both non-transitory computer storage media and communication media, encompassing any medium that facilitates the transfer of a computer program from one location to another. Non-transitory storage media can be any available medium accessible by a general-purpose or special-purpose computer. By way of example, and not limitation, non-transitory computer-readable media may include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compressed optical disc (CD) ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code components in the form of instructions or data structures, and accessible by a general-purpose or special-purpose computer or a general-purpose or special-purpose processor. Furthermore, any connection is appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included within the definition of computer-readable media. As used herein, disks and optical discs include CDs, laser discs, optical discs, digital multifunction discs (DVDs), floppy disks, and Blu-ray discs. Disks can magnetically reproduce data, and optical discs can optically reproduce data using lasers. Combinations of the above are also included within the scope of computer-readable media. Any function or operation described herein that can be performed by memory can be performed by multiple memories capable of performing the described function or operation individually or jointly.

[0294] As used herein, the word "or" in a list of items (e.g., a list of items accompanied by phrases such as "at least one of" or "one or more of") in the claims indicates an inclusive list, such that a list of at least one of, for example, A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). Furthermore, as used herein, the phrase "based on" should not be construed as a reference to a closed set of conditions. For example, an example step described as "based on condition A" could be based on both condition A and condition B without departing from the scope of this disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "at least partially based on".

[0295] As used herein, including in claims, the article “a” preceding a noun is open-ended and is understood to refer to “at least one” or “one or more” of those nouns. Therefore, the terms “a,” “at least one,” “one or more,” and “at least one of one or more” are interchangeable. For example, where a claim enumerates “components” performing one or more functions, each of the individual functions may be performed by a single component or by any combination of multiple components. Thus, the term “component” having a characteristic or performing a function may refer to “at least one of one or more components” having a particular characteristic or performing a particular function. Subsequent references to a component introduced with the article “a” using the terms “the” or “the” can refer to any or all of the one or more components. For example, a component introduced with the article “a” can be understood to mean “one or more components,” and subsequent reference to “the component” in a claim can be understood as equivalent to referring to “at least one of the one or more components.” Similarly, subsequent references to a component introduced with the terms “the” or “the” as “one or more components” can refer to any or all of the one or more components. For example, reference to "the one or more components" in the subsequent claims can be understood as equivalent to reference to "at least one of the one or more components".

[0296] As used in this article, depending on the context, "meeting the threshold" can mean a value greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, etc.

[0297] The term "determine" encompasses a variety of actions, and therefore, "determine" can include calculation, computation, processing, derivation, investigation, searching (such as by searching in a table, database, or other data structure), ascertainment, etc. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data stored in memory), etc. Moreover, "determine" can include parsing, acquiring, selecting, choosing, creating, and other similar actions.

[0298] In the accompanying drawings, similar components or features may have the same reference numerals. Furthermore, various components of the same type can be distinguished by adding a dash after the reference numeral and a second reference numeral to differentiate between similar components. If only the first reference numeral is used in the description, the description applies to any of the similar components having the same first reference numeral, regardless of the second reference numeral or other subsequent reference numerals.

[0299] The description herein, illustrated with reference to the accompanying drawings, describes an example configuration and does not represent all achievable examples or those within the scope of the claims. The term "example" as used herein means "serving as an example, instance, or illustration," not "preferred" or "advantageous over other examples." The detailed description includes specific details used to provide an understanding of the described techniques. However, these techniques can be practiced without these specific details. In some of the drawings, known structures and devices are shown in block diagram form to avoid obscuring the concept of the described examples.

[0300] The description herein is provided to enable those skilled in the art to implement or use this disclosure. Various modifications to this disclosure will be apparent to those skilled in the art, and the general principles defined herein may be applied to other variations without departing from the scope of this disclosure. Therefore, this disclosure is not limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A user equipment (UE), the user equipment (UE) comprising: One or more memories, wherein the one or more memories store processor-executable code; and One or more processors, coupled to one or more memories and capable of operating individually or jointly to execute the code to enable the UE: When operating in the first state, a request to transition from the first state to the second state is sent to the network entity at least in part based on data activity between the UE and the network entity, wherein the transition from the first state to the second state is associated with an inactivity timer at the UE; as well as The transition from the first state to the second state is based at least in part on sending the request, depending on the state of the inactive timer.

2. The UE according to claim 1, wherein: The request to transition from the first state to the second state includes a request value for the inactivity timer at the UE; and The UE transitions from the first state to the second state at least in part based on the expiration of the inactivity timer.

3. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: Receive an indication of a set of inactive timer values ​​for the inactive timer from the network entity. The request includes an indication of a first inactive timer value from the set of inactive timer values, the first inactive timer value being selected by the UE at least in part based on receiving the indication of the set of inactive timer values.

4. The UE of claim 3, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The response message is received from the network entity at least in part based on receiving the indication and sending the request, wherein the response message indicates that: the request is accepted by the network entity; an indication of a second inactive timer value, which is different from the first inactive timer value, for the UE to use in transitioning from the first state to the second state; or any combination thereof, and wherein the transition from the first state to the second state is further at least in part based on receiving the response message.

5. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: When operating in the third state, a second request to transition from the third state to the fourth state is sent to the network entity, at least in part, based on data activity between the UE and the network entity. Receiving a response message from the network entity is based at least in part on sending the second request. The response message indicates that the second request was rejected by the network entity; as well as The transition from the third state to the fourth state is avoided at least in part based on receiving the response message.

6. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The request is used to send an indication of the request status for the second state. The requested state is associated with the following: sleep state, wake-up state, state associated with the target bandwidth portion, radio resource control state, state associated with the deactivation of the secondary cell, or any combination thereof.

7. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The UE receives a control message from the network entity, the control message configuring whether the UE should transition from the first state to the second state at least in part based on the expiration of a timer, or avoid transitioning from the first state to the second state at least in part based on the expiration of the timer. The timer is associated with receiving a response message from the network entity; and The timer is started at least in part based on sending the request.

8. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The predicted data activity between the UE and the network entity is determined at least in part based on a machine learning model at the UE. The request is sent at least in part based on the predicted data activity meeting a threshold; At least in part, the network entity receives a feedback message associated with the request based on sending the request. as well as The machine learning model is trained based at least in part on the feedback messages received from the network entity.

9. The UE of claim 1, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: Receive control messages that configure the timer associated with sending the request; The timer is started at least in part based on sending the request; and Avoid sending a second request to transition from the third state to the fourth state before the timer expires.

10. The UE according to claim 1, wherein operating in the first state includes: Operates during the active period of a discontinuous reception cycle, wherein the transition from the first state to the second state includes: transitioning to the inactive period of the discontinuous reception cycle.

11. A user equipment (UE), the user equipment (UE) comprising: One or more memories, wherein the one or more memories store processor-executable code; and One or more processors, coupled to one or more memories and capable of operating individually or jointly to execute the code to enable the UE: During the active period of a discontinuous reception cycle, a request to transition to an inactive period of the discontinuous reception cycle is sent, at least in part, based on data activity between the UE and the network entity. as well as The transition to the inactive period of the discontinuous reception cycle is based at least in part on sending the request.

12. The UE of claim 11, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The request is used to send an indication of the duration associated with the inactivity period of the discontinuous reception cycle.

13. The UE of claim 11, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The UE receives a control message from the network entity, the control message configuring whether to transition to the inactive period of the discontinuous reception cycle based at least in part on the expiration of a timer, or to avoid transitioning to the inactive period of the discontinuous reception cycle based at least in part on the expiration of the timer. The timer is associated with receiving a response message from the network entity; and The timer is started at least in part based on sending the request.

14. The UE of claim 13, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: Based at least in part on the failure to receive the response message from the network entity before the timer expires, the system transitions to the inactive period of the discontinuous reception cycle according to the control message.

15. The UE of claim 13, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: Receive the response message from the network entity before the timer expires; The response message includes an indication duration of the inactivity period that the UE wants to use for the discontinuous reception cycle; as well as At least in part based on receiving the response message, the system transitions to the inactive period of the discontinuous reception cycle according to the control message.

16. The UE of claim 13, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: During the second active period of the second discontinuous reception cycle, a second request to transition to the second inactive period of the second discontinuous reception cycle is sent, at least in part based on the data activity between the UE and the network entity. Receive an indication via a second response message regarding the network entity's rejection of the second request from the UE; as well as At least in part, the transition to the second inactive period of the second discontinuous reception cycle is avoided based on receiving the second response message.

17. The UE of claim 11, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: The decision to avoid transitioning to a second inactive period of the discontinuous reception period is determined at least in part based on the absence of an active timer value in the configuration of the discontinuous reception period, until a second request to transition to the second inactive period is sent, or until a command is received from the network entity.

18. The UE of claim 11, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: Prior to transitioning to the inactive period, a response message is received at least in part based on sending the request. The response message indicates whether the UE should transition to the inactive period of the discontinuous reception cycle based on the activity timer value, or avoid transitioning to the inactive period of the discontinuous reception cycle until the request is sent.

19. The UE of claim 11, wherein the one or more processors are further capable of operating individually or jointly to execute the code to cause the UE to: A control message is received, which configures the default duration for the inactive period during the discontinuous reception cycle for the UE. The UE uses the default duration for the inactive period at least in part based on the absence of duration in the request.

20. A method for wireless communication by a user equipment (UE), the method comprising: When operating in the first state, a request to transition from the first state to the second state is sent to the network entity at least in part based on data activity between the UE and the network entity, wherein the transition from the first state to the second state is associated with an inactivity timer at the UE; as well as The transition from the first state to the second state is based at least in part on sending the request, depending on the state of the inactive timer.

Images