Patent Description:
The present invention provides a method, a system and a UE as set out in the appended claims.

Techniques for determining CDRX parameters to apply to a UE are discussed herein. For example, data (e.g., downlink data) received at a base station may include a particular type of traffic classification. The base station may select CDRX parameters based on the traffic classification of the data in order to maximize performance of the UE (e.g., conserver power) while ensuring that the UE is awake when data is being transmitted from the base station. The base station may send the CDRX parameters to the UE and send the data to the UE based on the CDRX parameters. In some cases, the base station may determine the CDRX parameters based on other types of information, such as UE state data received by the base station, Received Signal Strength Indicator (RSSI) data associated with the UE, a size of the data being sent to the UE, a congestion level associated with the base station, etc..

Conventional operation selects CDRX parameters at the start of a call session without consideration of the type of traffic associated with downlink data, UE state data, RSSI data, data size, or congestion level. CDRX parameters that may be optimal for a first UE receiving a first type of data may not be optimal for a second UE receiving a second type of data. Additionally, CDRX parameters are often sent via Radio Resource Control (RRC) reconfiguration messages that can cause an ongoing call to be dropped when received.

By dynamically adapting CDRX parameters for a UE based on the type of traffic included in downlink data (as well as other types of data), the UE may conserve power by efficiently adjusting sleep cycles and being connected with the base station. For example, a base station may receive downlink data from a computing device that is intended to be transmitted to a UE. The downlink data can include data stored in a transmit buffer associated with the base station. In some examples, the downlink data can represent an amount of data to be transmitted to a UE in a next transmission time interval (TTI) associated with an LTE connection and/or a <NUM> connection. In some examples, the downlink data can include metadata such as a type of data (e.g., voice, video, data, gaming, TCP, UDP, etc.).

In some cases, the base station may determine a traffic classification associated with the downlink data. For example, the base station may determine that the downlink data is associated with at least one of voice traffic, video traffic, data traffic, etc. Once the traffic classification is determined, the base station may determine CDRX parameters that should be applied to the UE based on the traffic classification. For example, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc. The base station may adjust any of and/or all of the CDRX parameters based on the traffic classification of the downlink data in order to improve the efficiency (e.g., to conserve power) of the UE.

In some examples, the base station may determine CDRX parameters based on other types of information, such as but not limited to, UE state data received from the UE, RSSI data associated with the UE, a size of the downlink data, and/or a congestion level associated with the base station. In some cases, the UE state data may include an indication that the UE is associated with a low power mode, an amount of power in a battery associated with the UE, a charge state indication associated with the UE, an application associated with the UE, and/or a temperature associated with the UE.

In some examples, a machine learned model can determine traffic classification parameters such as packet frequency data and/or packet size data. In some examples, a traffic classification can be based on a data source or destination, analyzing traffic patterns over time, deep packet inspection, application(s) operating on a UE, radio frequency conditions, UE state, UE location, etc., in addition to other data, conditions, or parameters discussed herein.

Once the CDRX parameters are determined, the base station may send the CDRX parameters to the UE. For example, the base station may utilize a media access control (MAC) layer of the base station to communicate with a MAC layer of the UE and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station may update CDRX parameters more frequently without having to send an RRC message to the UE, thereby decreasing the potential for dropped calls. In some examples, once the CDRX parameters are sent to the UE and the UE is operating in accordance with the CDRX parameters, the base station may send the downlink data to the UE.

In some examples, the techniques discussed herein can be implemented in the context of protocols associated with one or more of <NUM>, <NUM>, <NUM> LTE, <NUM> protocols. In some examples, the network implementations can support standalone architectures, non-standalone architectures, dual connectivity, carrier aggregation, etc..

For example, CDRX parameters can be enabled and/or determined based on an availability of different radio access technologies (RATs) such as <NUM> and <NUM>. A first set of CDRX parameters may be determined for a <NUM> air interface and a second set of CDRX parameters may be determined for a <NUM> air interface. In some examples, such as when using carrier aggregation, a first set of CDRX parameters can be determined for a first set of frequency resources (e.g., low-band, ~<NUM>) and a second set of CDRX parameters can be determined for a second set of frequency resources (e.g., mid band (~<NUM>) or high band (mmWave)). In some examples, downlink data can be routed to various air interfaces or to use certain frequencies based on the CDRX parameters associated with the various resources.

For example, voice data can be routed through low-band frequency resources, where the CDRX parameters are optimized for voice traffic, while non-voice data can be routed through mid-band frequency resources, where the CDRX parameters are optimized for data traffic. This is just one example implementation and other examples are discussed throughout this disclosure. Example implementations are provided below with reference to the following figures.

<FIG> shows an example network environment <NUM> in which a UE <NUM> can connect to a telecommunication network to engage in communication sessions for voice calls, video calls, messaging, data transfers, and/or any other type of communication. The UE <NUM> can be any device that can wirelessly connect to the telecommunication network. In some examples, the UE <NUM> can be a mobile phone, such as a smart phone or other cellular phone. In other examples, the UE <NUM> can be a personal digital assistant (PDA), a media player, a tablet computer, a gaming device, a smart watch, a hotspot, a personal computer (PC) such as a laptop, desktop, or workstation, or any other type of computing or communication device.

The UE <NUM> can include a battery <NUM> that stores energy used to power the functions of the UE <NUM>. The battery <NUM> can be a lithium-ion (Li-ion) battery, a lithium-ion polymer (LiPo) battery, a nickel cadmium (NiCad) battery, a nickel-metal hydride (NiMH) battery, or other type of battery. In some examples, the battery <NUM> can be rechargeable. For instance, the energy level of the battery <NUM> can increase when the UE <NUM> is connected to a wall outlet, a portable charger, or another external power source. However, operations of the UE <NUM> can also use energy and thus drain the battery <NUM> when the battery <NUM> is not charging.

The telecommunication network can have one or more access networks that include base stations and/or other access points, as well as a core network <NUM> linked to the access network. The access networks and/or the core network <NUM> can be compatible with one or more radio access technologies, wireless access technologies, protocols, and/or standards, such as <NUM> NR technology, LTE/LTE Advanced technology, other Fourth Generation (<NUM>) technology, High-Speed Data Packet Access (HSDPA)/Evolved High-Speed Packet Access (HSPA+) technology, Universal Mobile Telecommunications System (UMTS) technology, Code Division Multiple Access (CDMA) technology, Global System for Mobile Communications (GSM) technology, WiMAX technology, Wi-Fi technology, and/or any other previous or future generation of radio access technology.

The UE <NUM> can wirelessly connect to one or more base stations or other access points of the access networks, and in turn be connected to the core network <NUM> via the base stations or other access points. In some examples, the core network <NUM> can be a packet core network of an LTE network, which may be referred to as an Evolved Packet Core (EPC). In other examples, the core network <NUM> can be a <NUM> core network.

The access networks can include a base station <NUM> that communicates with the UE <NUM>, the core network <NUM>, and a computing device <NUM>, as well as other UEs and other base stations not illustrated in <FIG>. In some cases, the base station <NUM> may be associated with an LTE access network known as an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN). Base stations of the LTE access network can be known as eNBs. In some cases, the base station <NUM> may be associated with a <NUM> access network with base stations known as gNBs.

The base station <NUM> can be connected to the core network <NUM>. For example, the base station <NUM> may be connected to the core network <NUM> via S1 interfaces, or other interfaces, for transmission of user plane data and/or control plane data. The base station <NUM> may also be connected to other base stations over an X2 interface, or other interface, for transmission of user plane data and/or control plane data.

In some examples, the base station <NUM> may receive downlink data <NUM> from the computing device <NUM> and/or the core network <NUM> that is intended to be transmitted to the UE <NUM>. The downlink data <NUM> can include data stored in a transmit buffer associated with the base station <NUM>. In some examples, the downlink data <NUM> can represent an amount of data to be transmitted to the UE <NUM> in a next transmission time interval (TTI) associated with an LTE connection and/or a <NUM> connection. In some examples, the downlink data <NUM> can include metadata such as a type of data (e.g., voice, video, data, gaming, TCP, UDP, etc.).

In some cases, the base station <NUM> may determine a traffic classification associated with the downlink data <NUM>. For example, the base station <NUM> may determine that the downlink data <NUM> is associated with at least one of voice traffic, video traffic, data traffic, etc. Once the traffic classification is determined, a CDRX component <NUM> of the base station <NUM> may determine CDRX parameters that should be applied to the UE <NUM> based on the traffic classification. For example, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc. The CDRX component <NUM> of the base station <NUM> may adjust any of and/or all of the CDRX parameters based on the traffic classification of the downlink data <NUM> in order to improve the efficiency (e.g., to conserve power) of the UE <NUM>.

In some examples, the CDRX component <NUM> of the base station <NUM> may determine CDRX parameters based on other types of information, such as but not limited to, UE state data received from a reporting component <NUM> that reports data from a UE state component <NUM>, radio frequency condition data such as RSSI data associated with the UE <NUM> or encoding schemes (e.g., QAM levels), data bearer types, guaranteed bit rates, a size of the downlink data <NUM>, and/or a congestion level associated with the base station <NUM>. In some cases, the UE state data may include an indication that the UE <NUM> is associated with a low power mode, an amount of power in a battery associated with the UE <NUM>, a charge state indication associated with the UE <NUM>, an application associated with the UE <NUM>, and/or a temperature associated with the UE <NUM>.

Additional conditions and/or parameters that may be considered for determining CDRX parameters include, but are not limited to, one or more of frequency resources available (e.g., low-band, mid-band, high-band), radio access technologies available (e.g., <NUM>, <NUM>, etc.), whether carrier aggregation is available, subscriber level, data history (e.g., an amount of downlink data used over a time period with respect to a threshold), and the like.

Once the CDRX parameters are determined, the base station <NUM> may send the CDRX parameters to a CDRX component <NUM> of the UE <NUM> via a communication link <NUM>. For example, the base station <NUM> may utilize a media access control (MAC) layer of the base station <NUM> to communicate with a MAC layer of the UE <NUM> and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station <NUM> may update CDRX parameters more frequently without having to send an RRC message to the UE <NUM>, thereby decreasing the potential for dropped calls. In some examples, once the CDRX parameters are sent to the UE <NUM> and the UE <NUM> is operating in accordance with the CDRX parameters, the base station <NUM> may send the downlink data <NUM> to the UE <NUM>.

In some examples, once the CDRX parameters are determined, the base station <NUM> may assign data packets to a transmission buffer associated with a Packet Data Convergence Protocol (PDCP) layer based on the CDRX parameters. The UE <NUM> may access the PDCP layer to determine adjustments to the CDRX parameters. In some examples, the MAC layer of the base station may provide an indication of CDRX parameters to the PDCP layer for data routing, as discussed herein.

In some cases, the UE <NUM> can connect to one base station using a Fifth Generation (<NUM>) New Radio (NR) connection and also connect to another base station using a Fourth Generation (<NUM>) Long-Term Evolution (LTE) connection. This type of dual connection can be referred to as an E-UTRAN New Radio - Dual Connectivity (EN-DC) connection. In some cases, the CDRX component <NUM> may instruct the CDRX component <NUM> to apply different CDRX parameters based on the type of base station that the UE <NUM> is communicating with. For example, the CDRX component <NUM> may instruct the CDRX component <NUM> to apply a first set of CDRX parameters when the UE <NUM> is communicating with a <NUM> NR base station and to apply a second set of CDRX parameters when the UE <NUM> is communicating with an LTE base station.

Dynamically adapting CDRX parameters for the UE <NUM> based on the type of traffic included in the downlink data <NUM> (as well as other types of data), enables the UE <NUM> to conserve power by efficiently adjusting sleep cycles and being connected to the base station <NUM>. In one example, the base station <NUM> may determine that an RSSI associated with the UE <NUM> is below or above a threshold amount. In some cases, if the RSSI associated with the UE <NUM> is below the threshold amount, the CDRX component <NUM> may decrease an inactivity time included in the CDRX parameters and increase an on-duration time included in the CDRX parameters. In some cases, if the RSSI associated with the UE <NUM> is above the threshold amount, the CDRX component <NUM> may increase an inactivity time included in the CDRX parameters and decrease an on-duration time included in the CDRX parameters. Applying CDRX parameters based on RSSI data this way enables the UE <NUM> to be more active when signal strength is strong and less active when signal strength is weak.

In some examples, the CDRX component <NUM> can receive data about the UE, downlink data, radio frequency conditions, network condition, and the like, and can input the data into a machine learned model to determine adjusted CDRX parameters for the UE <NUM> to use to optimize an operation of the UE <NUM> and/or of the network in general. Additional details are discussed below in connection with <FIG>, as well as throughout this disclosure.

<FIG> is a block diagram of a device <NUM> including a CDRX component. In some examples, the device <NUM> can be configured to implement the techniques discussed herein.

<FIG> shows only basic, high-level components of the device <NUM>. Generally, the device <NUM> may comprise and/or may be implemented in any of various network components discussed herein, including those components illustrated in <FIG>. For example, the device <NUM> may be implemented in the base station <NUM>, which may include an eNB, a gNB, the core network <NUM>, or other network device.

In various examples, the device <NUM> may include processor(s) <NUM> and memory <NUM>. Depending on the exact configuration and type of computing device, the memory <NUM> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The memory <NUM> may include the CDRX component <NUM>, which may include downlink data for UE <NUM>, base station capability data <NUM>, UE state data <NUM>, UE capability data <NUM>, location data <NUM>, and/or machine learned data <NUM>. In some cases, the CDRX component <NUM> may be implemented in a MAC layer of the device <NUM>.

In some examples, the CDRX component <NUM> can include functionality to determine CDRX parameters for a UE, such as the UE <NUM>, to utilize based on a traffic type associated with downlink data to be sent to the UE and/or conditions associated with the UE. The CDRX component <NUM> can use the data illustrated in <FIG> to receive information from the UE <NUM>, the computing device <NUM>, and/or the core network <NUM>, determine CDRX parameters for the UE <NUM> to utilize based on the information, and send an indication to the UE <NUM> causing the UE <NUM> to operate using the CDRX parameters. For example, the CDRX component <NUM> can adjust CDRX parameters based at least in part on the downlink data for UE <NUM>, the base station capability data <NUM>, the UE state data <NUM>, the UE capability data <NUM>, the location data <NUM>, and/or the machine learned data <NUM>.

In some examples, the downlink data for UE <NUM> can include data received by another UE, data received by the computing device <NUM>, and/or data received by the core network <NUM> that is intended to be transmitted to the UE <NUM>. The downlink data for UE <NUM> can include data stored in a transmit buffer associated with the device <NUM>. In some examples, the downlink data for UE <NUM> can represent an amount of data to be transmitted to the UE <NUM> in a next transmission time interval (TTI) associated with an LTE connection and/or a <NUM> connection. In some examples, the downlink data for UE <NUM> can include metadata such as a type of data (e.g., voice, video, data, gaming, TCP, UDP, etc.). The downlink data for the UE <NUM> may be used to determine adjusted CDRX parameters to be applied to the UE. In some examples, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc..

In some examples, the base station capability data <NUM> can be based at least in part on signal data associated with a connection between the device <NUM> (e.g., a connection associate with the downlink data for UE <NUM>) and a UE (e.g., the UE <NUM>). For example, the base station capability data <NUM> (also referred to as capability data <NUM>) can be based at least in part on signal data comprising one or more of Channel Quality Information (CQI) data, signal-to-noise ratio (SNR) data, signal-to-interference plus noise ratio (SINR) data, and/or signal-to-noise plus distortion ratio (SNDR) data.

By way of example, and without limitation, a low RSSI may indicate that a UE is near a cell edge and may have a relatively low signal strength. In some examples, the CDRX parameters may be adjusted to decrease a sleep time (or adjust other parameters) to allow for additional data to be sent to the UE. Similarly, as the UE moves closer to the device <NUM> and RSSI increases, the sleep time may be increased because more data may be transmitted within the same transmission time period.

The base station capability data <NUM> can also be based at least in part on an amount of traffic and/or congestion at the device <NUM> or associated with an LTE and/or NR connection. For example, as a number of devices and/or connections between the device <NUM> and other UEs increases, an amount of resources to be allocated to a UE may decrease. In some examples, an amount of resources may be based at least in part on subscriber level, device type, location, and the like. Accordingly, the base station capability data <NUM> can be based on a number of factors or data, as discussed herein.

By way of example and without limitation, if a congestion level at the device <NUM> is above a threshold value the device <NUM> may adjust CDRX parameters for one or more UEs connected to the device <NUM> to increase a sleep time (or adjust other parameters). In some examples, sleep time can be adjusted for different UEs based on traffic type, subscriber level, UE state(s), and the like, as discussed herein.

In some examples, the UE state data <NUM> can include data received from the UE representing one or more conditions at the UE. In some examples, the UE state data <NUM> can be received from the UE state component <NUM> of the reporting component <NUM>. In some examples, the UE state data <NUM> can represent data about a display status of the UE, sensor data from the UE, an application type associated with the UE, an indication that the UE is associated with a low power mode, an amount of power in a battery associated with the UE, a charge state indication associated with the UE, as well as other factors.

In some examples, the UE state data <NUM> can include an indication that the UE is associated with a low power mode. For example, a UE may automatically enter a low-power state after a period of inactivity or based on a charge status. In some examples, a UE may enter a low-power state based on a user preference. In any event, the CDRX component <NUM> can determine how to adjust CDRX parameters based at least in part on an indication of whether the UE is associated with a low power state.

Similarly, the CDRX component <NUM> can receive an indication of an amount of power in a battery associated with the UE. In some examples, the indication of an amount of power can be represented as a scalar value, as a percentage, as an amount of time until the UE battery is depleted based on current or estimated usage, and the like. The CDRX component <NUM> can determine how to adjust CDRX parameters based at least in part on an indication of the amount of power in a battery associated with the UE. For example, the CDRX component <NUM> may adjust CDRX parameters based on whether the power in a battery associated with the UE is above or below a threshold. In some cases, if the power level is below the threshold, the CDRX component <NUM> may increase an inactivity time included in the CDRX parameters and decrease an on-duration time included in the CDRX parameters. In some cases, if the power level is above the threshold, the CDRX component <NUM> may decrease an inactivity time included in the CDRX parameters and increase an on-duration time included in the CDRX parameters.

In some examples, a charge state indication associated with the UE can indicate whether the UE is currently being charged and/or an amount of time to a full battery or to a particular charge level. The CDRX component <NUM> can determine how to adjust CDRX parameters based at least in part an indication of the charge state of the UE.

In some cases, the UE state data <NUM> may include RSSI data associated with a UE, such as UE <NUM>. For example, the CDRX component <NUM> may determine that the RSSI associated with the UE <NUM> is below a threshold amount and may decrease an inactivity time included in the CDRX parameters and increase an on-duration time included in the CDRX parameters. In some cases, if the RSSI associated with the UE <NUM> is above the threshold amount, the CDRX component <NUM> may increase an inactivity time included in the CDRX parameters and decrease an on-duration time included in the CDRX parameters. Applying CDRX parameters based on RSSI data this way enables the UE <NUM> to be more active when signal strength is strong and less active when signal strength is weak.

In some examples, the UE capability data <NUM> can include an indication of whether the UE supports an EN-DC connection, an LTE connection, and/or an NR connection. In some examples, the UE capability data <NUM> can include an indication of particular frequency bands that the UE supports so that the CDRX component <NUM> can determine how to adjust CDRX parameters in order to can optimize traffic between multiple devices. In some examples, the UE capability data <NUM> can indicate various modulation schemes (e.g., QAM schemes) supported by the UE, which may factor into the base station capability data <NUM>, as discussed above.

In some examples, the location data <NUM> can include a location of the UE. For example, the location data <NUM> can be based on GPS data, base station triangulation data, and the like. In some examples, the location data <NUM> can include velocity data and heading data, which may be indicative of the UE being at one location for a period of time or on the move (e.g., in a vehicle). In some cases, the CDRX component <NUM> may utilize the location data <NUM> and/or radio signal timing advance (TA) estimation to determine a distance between the UE and the device <NUM>. In some examples, the CDRX component <NUM> may adjust a CDRX parameter based at least in part on the distance being above or below threshold distance.

In some examples, the device <NUM> can estimate or otherwise determine a location associated with a UE in the environment based at least in part on radio signal TA data. In some examples, the device <NUM> can determine an amount of time associated with a signal propagating from the device <NUM> to the UE <NUM>. The device <NUM> can receive timing advance data over time to estimate a position in the environment. In some examples, the device <NUM> can receive timing advance data from other base stations in the environment to triangulate or otherwise determine a location of the UE in the environment.

In some examples, the machine learned data <NUM> can include one or more machine learned models or heuristics that can be used to determine which CDRX parameters the UE should adjust. For example, the machine learned data <NUM> can include weight(s) for various factors that can be used to set threshold(s) or likelihoods and/or determine factors that increase or decrease threshold(s) or likelihoods, and by how much.

In some examples, a machine learned model can determine adjusted CDRX parameters for the UE to use based on a confidence level associated with a predicted outcome being above a threshold level (e.g., such that there is a likelihood above a threshold level that an adjusted CDRX parameter will improve a communication, reduce power consumption, etc.).

In some instances, the machine learned can determine a similarity score between UE state data (e.g., power condition(s), <NUM>/<NUM> capability, carrier aggregation capability, location data, timing advance data, etc.), radio frequency conditions (e.g., transmission power headroom data associated with the UE <NUM>, uplink signal-to-interference-plus-noise ratio (SINR) data as determined by the base station <NUM>, uplink path loss data determined by the base station <NUM>, etc.), network conditions (e.g., load levels, congestions, radio access technologies (e.g., <NUM> / <NUM>), downlink data information (e.g., voice traffic, video traffic, data traffic, etc.) and the like and ground truth conditions representing various conditions and outcomes. Based on a similarity score of input data associated with positive outcomes (e.g., instructing the UE to use an adjusted CDRX parameter resulting in a good quality of service, reduced or optimal power consumption, etc.) or negative outcomes, the machine learned model can instruct the UE to use a particular CDRX parameter.

In some examples, the machine learned data <NUM> can include, but is not limited to, one or more of: neural network(s), convolutional neural network(s), recurrent neural network(s), linear regression algorithm(s), logistic regression algorithm(s), classification and regression tree algorithm(s), Naive Bayes algorithm(s), K-nearest neighbors algorithm(s), learning vector quantization algorithm(s), support vector machine(s), bagging and random forest algorithm(s), boosting and Adaboost algorithm(s), and the like.

In some examples, the machine learned model can determine traffic characteristics such as packet frequency data and/or packet size data to adjust CDRX parameters to optimize the CDRX parameters for the determined traffic characteristics. For example, the machine learned model can determine a sleep time (or other parameter) based on expected arrival times for various voice or data traffic.

In some examples, the processor(s) <NUM> is a central processing unit (CPU), a graphics processing unit (GPU), both CPU and GPU, or other processing unit or component known in the art. Furthermore, the processor(s) <NUM> may include any number of processors and/or processing cores. The processor(s) <NUM> is configured to retrieve and execute instructions from the memory <NUM>.

The memory <NUM> can also be described as non-transitory computer-readable media or machine-readable storage memory, and may include removable and non-removable media implemented in any method or technology for storage of information, such as computer executable instructions, data structures, program modules, or other data.

The memory <NUM> may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information.

The device <NUM> also includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. Tangible computer-readable media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, the removable storage <NUM> and the non-removable storage <NUM> are all examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD), content-addressable memory (CAM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the device <NUM>. Any such tangible computer-readable media can be part of the device <NUM>.

The memory <NUM>, the removable storage <NUM>, and/or the non-removable storage <NUM> may in some cases include storage media used to transfer or distribute instructions, applications, and/or data. In some cases, the memory <NUM>, the removable storage <NUM>, and/or the non-removable storage <NUM> may include data storage that is accessed remotely, such as network-attached storage that the device <NUM> accesses over some type of data communications network.

In various examples, any or all of the memory <NUM>, the removable storage <NUM>, and/or the non-removable storage <NUM> may store programming instructions that, when executed, implement some or all of the function functionality described herein.

The device <NUM> also can include input device(s) <NUM>, such as a keypad, a cursor control, a touch-sensitive display, voice input device, etc., and output device(s) <NUM> such as a display, speakers, printers, etc. These devices are well known in the art and need not be discussed at length here.

As illustrated in <FIG>, the device <NUM> also includes one or more wired or wireless transceiver(s) <NUM>. For example, the transceiver(s) <NUM> can include a network interface card (NIC), a network adapter, a LAN adapter, or a physical, virtual, or logical address to connect to various networks, devices, or components illustrated in figures herein. To increase throughput when exchanging wireless data, the transceiver(s) <NUM> can utilize multiple-input/multiple-output (MIMO) technology. The transceiver(s) <NUM> can comprise any sort of wireless transceivers capable of engaging in wireless, radio frequency (RF) communication. The transceiver(s) <NUM> can also include other wireless modems, such as a modem for engaging in Wi-Fi, WiMAX, Bluetooth, infrared communication, and the like.

In some examples, the device <NUM> can be implemented as the UE <NUM> including the battery <NUM> and/or the reporting component <NUM>.

<FIG> is a block diagram of a UE <NUM> including components for determining attributes for utilizing particular CDRX parameters. In some examples, the UE <NUM> (also referred to as a device <NUM>) can be configured to implement some or all of the techniques discussed herein.

<FIG> shows basic, high-level components of the device <NUM>. Generally, the device <NUM> may comprise and/or may be implemented in any of various network components discussed herein, including those components illustrated in <FIG>.

In various examples, the device <NUM> may include processor(s) <NUM> and memory <NUM>. Depending on the exact configuration and type of computing device, the memory <NUM> may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The memory <NUM> may include the reporting component <NUM>, which may include a location component <NUM>, a CDRX component <NUM>, a downlink data component <NUM>, and/or a UE state component <NUM>, and a machine learned component <NUM>.

In some examples, the reporting component <NUM> can include functionality to gather or otherwise determine data about the UE and to report the data to another computing device (e.g., the base station <NUM>).

In further examples, the reporting component <NUM> can determine and report a user ID (identifier) that can indicate or correspond to a customer or user profile, such as an individual or organization using the device <NUM> or to whom the device <NUM> belongs. As another example, a user ID may indicate or correspond to a particular customer account with which the device <NUM> is associated. As yet another example, a user ID may indicate or correspond to a provider of services with which a data packet is associated.

In some examples, the location component <NUM> may be used to determine location data (e.g., a location) associated with the UE <NUM> and provide the location data to a computing device, such as the base station <NUM>.

In some examples, the CDRX component <NUM> may be used to determine CDRX data associated with the UE <NUM> and provide the CDRX data to a computing device, such as the base station <NUM>. The CDRX data may include data indicating which CDRX parameters are currently being used and/or which CDRX parameters have previously been used. In some cases, the CDRX component <NUM> may cause the UE <NUM> to switch CDRX parameters. For example, the reporting component <NUM> and/or the CDRX component <NUM> may operate in a MAC level of the UE <NUM> (in contrast to operating at an RRC reconfiguration level) and may receive CDRX parameters from the CDRX component <NUM> that operates in a MAC level of the base station <NUM> and/or the computing device <NUM>. By communicating the CDRX parameters via the MAC level of the base station <NUM> and/or the computing device <NUM> and the MAC level of the UE <NUM> and/or UE <NUM>, the CDRX parameters may be update more frequently without having to send an RRC message to the UE <NUM> and/or UE <NUM>, thereby decreasing the potential for dropped calls. In some examples, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc..

In some examples, the downlink data component <NUM> may be used to receive downlink data, such as downlink data <NUM>, from the base station <NUM> and/or the device <NUM>. In some cases, the downlink data <NUM> may include video traffic, voice traffic, data traffic, etc..

In some examples, the UE state component <NUM> can include data representing one or more conditions at the UE. In some examples, the UE state component <NUM> can represent data about a display status of the UE, sensor data from the UE, an indication that the UE is associated with a low power mode, an amount of power in a battery associated with the UE, a charge state indication associated with the UE, an application associated with the UE, a temperature associated with the UE, as well as other factors. The UE state component <NUM> can be input or otherwise provided to the machine learned component <NUM> (or another model or machine learned component discussed herein) to determine a priority level associated with a data request.

In some examples, the machine learned component <NUM> can include one or more machine learned models or heuristics that can be used to determine a priority level of downlink data associated with a data request. For example, the machine learned component <NUM> can include weight(s) for various factors that can be used to set priority level(s) or likelihoods and/or determine factors that increase or decrease a priority level, and by how much.

<FIG> illustrate example processes and sequence diagrams in accordance with examples of the disclosure. These processes are illustrated as logical flow graphs, each operation of which represents a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order, omitted, and/or performed in parallel to implement the processes.

<FIG> shows a sequence diagram <NUM> of example operations and messages a base station can use to determine CDRX parameters to be used by a UE.

At point <NUM>, the base station <NUM> may receive downlink data from the computing device <NUM>. For Example, the base station <NUM> may receive downlink data <NUM> from the computing device <NUM> and/or the core network <NUM> that is intended to be transmitted to the UE <NUM>. The downlink data <NUM> can include data stored in a transmit buffer associated with the base station <NUM>. In some examples, the downlink data <NUM> can represent an amount of data to be transmitted to the UE <NUM> in a next transmission time interval (TTI) associated with an LTE connection and/or a <NUM> connection. In some examples, the downlink data <NUM> can include metadata such as a type of data (e.g., voice, video, data, gaming, TCP, UDP, etc.).

At point <NUM>, the base station <NUM> may determine a traffic classification associated with the downlink data. For example, the base station <NUM> may determine that the downlink data <NUM> is associated with at least one of voice traffic, video traffic, data traffic, etc..

At point <NUM>, the base station <NUM> may determine a CDRX parameter based at least in part on the traffic classification. For example, once the traffic classification is determined, a CDRX component <NUM> of the base station <NUM> may determine CDRX parameters that should be applied to the UE <NUM> based on the traffic classification. For example, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc. The CDRX component <NUM> of the base station <NUM> may adjust any of and/or all of the CDRX parameters based on the traffic classification of the downlink data <NUM> in order to improve the efficiency (e.g., to conserve power) of the UE <NUM>.

At point <NUM> the base station <NUM> may send the CDRX parameters to the UE <NUM>. For example, once the CDRX parameters are determined, the base station <NUM> may send the CDRX parameters to a CDRX component <NUM> of the UE <NUM> via a communication link <NUM>. For example, the base station <NUM> may utilize a media access control (MAC) layer of the base station <NUM> to communicate with a MAC layer of the UE <NUM> and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station <NUM> may update CDRX parameters more frequently without having to send an RRC message to the UE <NUM>, thereby decreasing the potential for dropped calls. In some examples, once the CDRX parameters are determined, the base station <NUM> may assign data packets to a transmission buffer associated with a Packet Data Convergence Protocol (PDCP) layer based on the CDRX parameters. The UE <NUM> may access the PDCP layer to determine adjustments to the CDRX parameters.

At point <NUM> the base station <NUM> may send the downlink data to the UE <NUM>. For example, once the CDRX parameters are sent to the UE <NUM> and the UE <NUM> is operating in accordance with the CDRX parameters, the base station <NUM> may send the downlink data <NUM> to the UE <NUM>.

<FIG> shows a sequence diagram <NUM> of another example operations and messages a base station can use to determine CDRX parameters to be used by a UE.

At point <NUM>, the base station <NUM> may receive UE state data from the UE <NUM>. For example, the UE <NUM> may send data representing one or more conditions at the UE via the UE state component <NUM>. In some examples, the UE state component <NUM> can represent data about a display status of the UE, sensor data from the UE, an indication that the UE is associated with a low power mode, an amount of power in a battery associated with the UE, a charge state indication associated with the UE, an application associated with the UE, a temperature associated with the UE, as well as other factors. The UE state component <NUM> can be input or otherwise provided to the machine learned component <NUM> (or another model or machine learned component discussed herein) to determine a priority level associated with a data request.

At point <NUM>, the base station <NUM> may determine a CDRX parameter based at least in part on the traffic classification. For example, once the traffic classification is determined, a CDRX component <NUM> of the base station <NUM> may determine CDRX parameters that should be applied to the UE <NUM> based on the traffic classification. For example, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc. The CDRX component <NUM> of the base station <NUM> may adjust any of and/or all of the CDRX parameters based on the traffic classification of the downlink data <NUM> in order to improve the efficiency (e.g., to conserve power) of the UE <NUM> while maintaining a quality of service and/or a quality of user experience at the UE <NUM>.

In some examples, the CDRX component <NUM> of the base station <NUM> may determine CDRX parameters based on other types of information, such as but not limited to, UE state data received from a reporting component <NUM> that reports data from a UE state component <NUM>, RSSI data associated with the UE <NUM>, a size of the downlink data <NUM>, and/or a congestion level associated with the base station <NUM>. In some cases, the UE state data may include an indication that the UE <NUM> is associated with a low power mode, an amount of power in a battery associated with the UE <NUM>, a charge state indication associated with the UE <NUM>, an application associated with the UE <NUM>, and/or a temperature associated with the UE <NUM>.

At point <NUM> the base station <NUM> may send the CDRX parameters to the UE <NUM>. For example, once the CDRX parameters are determined, the base station <NUM> may send the CDRX parameters to a CDRX component <NUM> of the UE <NUM> via a communication link <NUM>. For example, the base station <NUM> may utilize a media access control (MAC) layer of the base station <NUM> to communicate with a MAC layer of the UE <NUM> and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station <NUM> may update CDRX parameters more frequently without having to send an RRC message to the UE <NUM>, thereby decreasing the potential for dropped calls.

<FIG> illustrates example process for determining CDRX parameters. The example process <NUM> can be performed by the base station <NUM> and/or by the device <NUM> comprising the CDRX component <NUM>, or another component or device as discussed herein.

At operation <NUM>, the process can include receiving, at a base station, downlink data to send to a user equipment (UE). For example, the base station <NUM> may receive downlink data <NUM> from the computing device <NUM> and/or the core network <NUM> that is intended to be transmitted to the UE <NUM>. The downlink data <NUM> can include data stored in a transmit buffer associated with the base station <NUM>. In some examples, the downlink data <NUM> can represent an amount of data to be transmitted to the UE <NUM> in a next transmission time interval (TTI) associated with an LTE connection and/or a <NUM> connection. In some examples, the downlink data <NUM> can include metadata such as a type of data (e.g., voice, video, data, gaming, TCP, UDP, etc.).

At operation <NUM>, the process can include determining a traffic classification associated with the downlink data. For example, the base station <NUM> may determine that the downlink data <NUM> is associated with at least one of voice traffic, video traffic, data traffic, etc..

At operation <NUM>, the process can include determining, based at least in part on the traffic classification, at least one Connected Mode Discontinuous Reception (CDRX) parameter. For example, once the traffic classification is determined, a CDRX component <NUM> of the base station <NUM> may determine CDRX parameters that should be applied to the UE <NUM> based on the traffic classification. For example, the CDRX parameters may include at least one of an indication to enable CDRX, an indication of a cycle time period, an indication of an on-duration time, an indication of an inactivity time, and indication of a retransmission time, an indication of a short discontinuous reception (DRX) cycle period, and indication of a short DRX cycle time, etc. The CDRX component <NUM> of the base station <NUM> may adjust any of and/or all of the CDRX parameters based on the traffic classification of the downlink data <NUM> in order to improve the efficiency (e.g., to conserve power) of the UE <NUM>.

At operation <NUM>, the process can include sending the at least one CDRX parameter to the UE. For example, once the CDRX parameters are determined, the base station <NUM> may send the CDRX parameters to a CDRX component <NUM> of the UE <NUM> via a communication link <NUM>. For example, the base station <NUM> may utilize a media access control (MAC) layer of the base station <NUM> to communicate with a MAC layer of the UE <NUM> and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station <NUM> may update CDRX parameters more frequently without having to send an RRC message to the UE <NUM>, thereby decreasing the potential for dropped calls. Further, the use of the MAC layer to adjust CDRX parameters reduces signaling and latency in implementing the techniques discussed herein.

At operation <NUM>, the process can include sending a portion of the downlink data based at least in part on the at least one CDRX parameter. For example, once the CDRX parameters are sent to the UE <NUM> and the UE <NUM> is operating in accordance with the CDRX parameters, the base station <NUM> may send the downlink data <NUM> to the UE <NUM>.

<FIG> illustrates another example process for dynamically adjusting CDRX parameters. The example process <NUM> can be performed by the UE <NUM> and/or by the device <NUM> comprising the reporting component <NUM>, or another component or device as discussed herein.

At operation <NUM>, the process can include sending, to a base station, UE state data associated with the UE. For example, the UE <NUM> may send data representing one or more conditions at the UE via the UE state component <NUM>. In some examples, the UE state component <NUM> can represent data about a display status of the UE, sensor data from the UE, an indication that the UE is associated with a low power mode, an amount of power in a battery associated with the UE, a charge state indication associated with the UE, an application associated with the UE, a temperature associated with the UE, as well as other factors. The UE state component <NUM> can be input or otherwise provided to the machine learned component <NUM> (or another model or machine learned component discussed herein) to determine CDRX parameters associated with a data request.

At operation <NUM>, the process can include receiving, via a media access control (MAC) layer of the UE, at least one CDRX parameter. For example, once the CDRX parameters are determined, the base station <NUM> may send the CDRX parameters to a CDRX component <NUM> of the UE <NUM> via a communication link <NUM>. For example, the base station <NUM> may utilize a media access control (MAC) layer of the base station <NUM> to communicate with a MAC layer of the UE <NUM> and provide the CDRX parameters. By utilizing the MAC layer to provide the CDRX parameters, the base station <NUM> may update CDRX parameters more frequently without having to send an RRC message to the UE <NUM>, thereby decreasing the potential for dropped calls.

At operation <NUM>, the process can include receiving downlink data from the base station based at least in part on the at least one CDRX parameter. For example, once the CDRX parameters are sent to the UE <NUM> and the UE <NUM> is operating in accordance with the CDRX parameters, the base station <NUM> may send the downlink data <NUM> to the UE <NUM>.

Claim 1:
A method comprising:
receiving (<NUM>), at a base station (<NUM>), downlink data to send to a user equipment, UE (<NUM>);
determining (<NUM>), at a base station (<NUM>), based at least in part on a machine learned model, a traffic classification associated with the downlink data;
determining (<NUM>), at a base station (<NUM>), based at least in part on the traffic classification, at least one Connected Mode Discontinuous Reception, CDRX, parameter for the UE (<NUM>);
sending (<NUM>), from the base station (<NUM>) to the US (<NUM>), the at least one CDRX parameter; and
sending (<NUM>) , from the base station (<NUM>) to the US (<NUM>), the downlink data based at least in part on the at least one CDRX parameter.