Patent Description:
There are many different types of mobile devices that can be used in connection with a mobile network. Mobile devices have traditionally included smartphones, tablet computers, and laptop computers, but will increasingly include cars, drones, industrial and agricultural machines, robots, home appliances, medical devices, and so on. In the context of mobile networks, mobile devices are often referred to as user equipment (UE).

A mobile network is distributed over geographical areas that are typically referred to as "cells. " Each cell can be served by at least one base station. One or more base stations provide a cell with network coverage, which can be used for transmission of voice, data, and other types of content. When joined together, these cells provide radio coverage over a wide geographic area. In addition, a mobile network is typically connected to the Internet. Thus, a mobile network enables a mobile device to communicate with other mobile devices within the mobile network, as well as other computing devices that are connected to the Internet.

Mobile networks have undergone significant changes over the past several decades. The first two generations of mobile networks supported voice and then text messaging. Third generation (<NUM>) networks initiated the transition to broadband access, supporting data rates typically measured in hundreds of kilobits-per-second. Fourth generation (<NUM>) networks supported data rates that were significantly faster, typically measured in megabits-per-second. Today, the industry is transitioning from <NUM> to fifth generation (<NUM>) networks, with the promise of significant increases in data rates.

The Third Generation Partnership Project (3GPP) is a consortium of a number of standards organizations that develop protocols for mobile telecommunications. 3GPP is responsible for the development of Long-Term Evolution (LTE) and related <NUM> standards, including LTE Advanced and LTE Advanced Pro. 3GPP is also responsible for the development of <NUM> standards. <NUM> systems are already being deployed and are expected to become widespread in the near future. The subject matter in the background section is intended to provide an overview of the overall context for the subject matter disclosed herein. The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art.

<CIT> describes a system and method for push-to-talk (PTT) key one-touch calling. In an embodiment, a client device accesses a discontinuous reception (DRX) mode policy. The DRX mode policy is in accordance with push-to-talk (PTT) usage patterns of at least the client device. The client device selects a DRX cycle time based on the DRX mode policy. The client device applies the DRX cycle time to a cellular network interface of the client device.

<CIT> describes a device, which establishes a quality of service (QoS) framework with a network connected to the device. The device includes a push-to-talk (PTT) application, and the QoS framework assigns priorities to different types of traffic associated with the device. The device utilizes the PTT application to establish a PTT session with another device via the network, and prioritizes, based on the QoS framework, PTT traffic, provided in the PTT session, over best effort traffic during the PTT session with the other device.

<CIT> describes a mobile core network including a non-transitory memory including instructions stored thereon for exposing a service to user equipment on the core network. The processor is operably coupled to the non-transitory memory and configured to execute the instruction of receiving a request from the user equipment for the service and a parameter for configuring the service. The processor is also configured to execute the instruction of determining the user equipment is authorized to access the service. The processor is further configured to execute the instruction of configuring the service on the core network based upon a <NUM> globally unique temporary identifier and subscriber permanent identity of the user equipment. The processor is yet even further configured to execute the instruction of sending a response to the user equipment based upon the configuring instruction. The application is also directed to user equipment communicating with a network exposure function on a network.

In accordance with one aspect of the present disclosure, a method for adjusting discontinuous reception (DRX) behavior of a user equipment (UE) to conserve energy use is disclosed. The UE is in wireless communication with a base station. The method is performed by a radio access network (RAN) controller that is communicatively coupled to the base station. The method includes exposing a DRX application programming interface (API) that enables DRX parameters to be changed. The method also includes creating a conflict resolution policy that controls when requests to change the DRX parameters should be granted. The conflict resolution policy is designed to prevent conflicts between different applications. The method also includes receiving, via the DRX API, a first request from a first application to change a DRX parameter for the UE from a current value to a new value. The first application is external to the UE and is configured to send data to the UE via a mobile network that comprises the base station. The method also includes determining, based at least in part on the conflict resolution policy, that the first request should be granted. The method also includes sending a command to the base station. The command causes the base station to communicate the new value of the DRX parameter to the UE.

The first application may send data packets to the UE at a packet interval. Changing the DRX parameter causes a duration of a DRX cycle for the UE to match the packet interval.

Receiving the first request from the first application may include receiving a function call to a function that is exposed by the DRX API.

The function call may include the new value for the DRX parameter.

The first application may send data packets to the UE at a packet interval. The function call may include the packet interval. The method may further include determining the new value for the DRX parameter based at least in part on the packet interval.

The conflict resolution policy may define a plurality of actions. Each action among the plurality of actions may represent modifying one or more of the DRX parameters associated with a particular UE. The conflict resolution policy may permit only a single owner for each action among the plurality of actions. Determining that the first request should be granted may be based at least in part on ownership of an action corresponding to the first request.

The first request may be received from a third-party application. Determining that the first request should be granted may include identifying an action corresponding to the first request and determining that the action is not owned by another third-party application.

Determining that the first request should be granted may further include determining that at least one additional condition is satisfied. The at least one additional condition may be unrelated to ownership of the action.

The method may further include receiving, via the DRX API, a second request from a second application to change the DRX parameter. The method may further include determining, based at least in part on the conflict resolution policy, that the second request should not be granted. The method may further include sending a response to the second application indicating that the second request is denied.

Determining that the second request should not be granted may include identifying an action corresponding to the second request and determining that the action is owned by the first application.

In accordance with another aspect of the present disclosure, a method for adjusting discontinuous reception (DRX) behavior of a user equipment (UE) to conserve energy use is disclosed. The UE is in wireless communication with a base station. The method is performed by an application that is sending data to the UE via a mobile network that includes the base station. The method includes sending data packets to the UE at a packet interval. The method also includes determining, based at least in part on the packet interval, that the DRX behavior of the UE should be changed. The method also includes causing a DRX parameter for the UE to be changed via a DRX application programming interface (API) exposed by a radio access network (RAN) controller that is communicatively coupled to the base station. Causing the DRX parameter to be changed includes sending a request to the RAN controller to change the DRX parameter. The request is sent via the DRX API. Causing the DRX parameter to be changed also includes providing the RAN controller, via the DRX API, with UE identifying information that enables the UE to be identified and parameter identifying information that enables a new value for the DRX parameter to be determined.

Sending the request to the RAN controller may include making a function call to a function that is exposed by the DRX API. The function call may include the UE identifying information and the parameter identifying information.

The parameter identifying information may include the new value for the DRX parameter.

The parameter identifying information may include the packet interval.

In accordance with another aspect of the present disclosure, a system is disclosed for adjusting discontinuous reception (DRX) behavior of a user equipment (UE) to conserve energy use. The UE is in wireless communication with a base station. The system includes, one or more processors, memory in electronic communication with the one or more processors, and instructions stored in the memory. The instructions are executable by the one or more processors to expose a DRX application programming interface (API) that enables DRX parameters to be changed. The instructions are executable by the one or more processors to create a conflict resolution policy that controls when requests to change the DRX parameters should be granted. The conflict resolution policy is designed to prevent conflicts between different applications. The instructions are executable by the one or more processors to receive, via the DRX API, a first request from a first application to change a DRX parameter for the UE from a current value to a new value. The first application is external to the UE and is configured to send data to the UE via a mobile network that comprises the base station. The instructions are executable by the one or more processors to determine, based at least in part on the conflict resolution policy, that the first request should be granted. The instructions are executable by the one or more processors to send a command to the base station. The command causes the base station to communicate the new value of the DRX parameter to the UE.

The first application may send data packets to the UE at a packet interval. Changing the DRX parameter may cause a duration of a DRX cycle for the UE to match the packet interval. Receiving the first request from the first application may include receiving a function call to a function that is exposed by the DRX API.

The first application may send data packets to the UE at a packet interval. The function call may include the packet interval. The system may further include additional instructions stored in the memory. The additional instructions may be executable by the one or more processors to determine the new value for the DRX parameter based at least in part on the packet interval. The conflict resolution policy may define a plurality of actions. Each action among the plurality of actions may represent modifying one or more of the DRX parameters associated with a particular UE. The conflict resolution policy may permit only a single owner for each action among the plurality of actions. Determining that the first request should be granted is based at least in part on ownership of an action corresponding to the first request.

Additional features and advantages will be set forth in the description that follows. Features and advantages of the disclosure may be realized and obtained by means of the systems and methods that are particularly pointed out in the appended claims. Features of the present disclosure will become more fully apparent from the following description and appended claims, or may be learned by the practice of the disclosed subject matter as set forth hereinafter.

In order to describe the manner in which the above-recited and other features of the disclosure can be obtained, a more particular description will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. For better understanding, the like elements have been designated by like reference numbers throughout the various accompanying figures. Understanding that the drawings depict some example embodiments, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

To conserve energy as much as possible, it is desirable for a UE to keep its receiver circuitry turned off when it is not needed. Discontinuous reception (DRX) is a method that is employed in various wireless technologies to allow a UE to turn its receiver off during periods of inactivity. The UE and the network negotiate phases in which data transfer occurs. During other times the UE turns its receiver off and enters a low power state. With current approaches, a base station configures a UE with a set of DRX parameters that control the UE's DRX behavior.

The present disclosure is generally related to improved techniques for adjusting DRX behavior of a UE to conserve energy use. The techniques disclosed herein enable an application that is sending data to a UE via a mobile network to directly adjust the UE's DRX parameters. Directly adjusting a UE's DRX parameters in this way is not possible with current approaches.

For example, consider a scenario in which an application is sending data to a UE. Further suppose that the UE is wirelessly connected to the Internet via a mobile network, such that the UE is receiving the data via a base station. In this scenario, the frequency at which the application sends data to the UE can be known. For instance, a new data packet can be sent to the UE once every N milliseconds. To maximize energy savings in this situation, the DRX parameters for the UE can be selected so that the UE's DRX behavior is based on the frequency at which data is being sent to the UE. For example, the DRX parameters for the UE can be selected so that the UE turns its receiver circuitry on every N milliseconds to receive a new data packet. If the UE turns its receiver circuitry on more frequently than once every N milliseconds, then energy is likely being wasted (if, for example, the application is the only application that is sending data to the UE via the mobile network).

However, there is not currently a simple way to achieve this result. With known approaches it is not possible for an application that is sending data to a UE to directly adjust the UE's DRX parameters. As noted above, with known approaches a base station configures a UE with a set of DRX parameters. Network operators decide what the values of the DRX parameters should be. Although software can be used to assist with this process, such software does not take into consideration information about the real-time needs of a particular UE that is connected to the network, such as information about the frequency at which a particular application is sending data packets to the UE.

The present disclosure enables an application that is sending data to a UE to directly adjust DRX parameters that control the UE's DRX behavior. In accordance with the present disclosure, DRX parameters can be adjusted via an application programming interface (API) that is exposed by a radio access network (RAN) controller that is communicatively coupled to a base station to which the UE is wirelessly connected. When an application wants to change one or more DRX parameters for a particular UE, the application can send a request to the RAN controller by making a function call to a relevant function that is exposed by the API. In response to receiving the request, the RAN controller can send one or more commands to the base station to which the UE is connected. The command(s) sent by the RAN controller can cause the base station to communicate new value(s) of DRX parameter(s) to the UE.

The techniques disclosed herein enable a plurality of different applications to adjust DRX parameters of a particular UE. This can be beneficial in many ways, but it also creates the possibility of conflicts occurring between different applications. To address this problem, the RAN controller can be configured to implement a conflict resolution policy that prevents such conflicts from occurring. When the RAN controller receives a request to change DRX parameter(s), the RAN controller can determine, based at least in part on the conflict resolution policy, whether the request should be granted.

<FIG> illustrates an example of a system <NUM> in which the techniques disclosed herein can be utilized. The system <NUM> includes a user equipment (UE) <NUM>. The UE <NUM> can be any device that is used directly by an end user to access services via a mobile network <NUM>. There are many different types of UEs that could be utilized in connection with the techniques disclosed herein. For example, the UE <NUM> could be a smartphone, a dedicated cellular telephone, a laptop computer, a tablet computer, a virtual reality (VR) device, an augmented reality (AR) device, a robot, a home appliance, a medical device, a car, a drone, an industrial machine, an agricultural machine, or the like. The UE <NUM> may alternatively be referred to as a mobile device, a mobile terminal, a mobile station, a wireless device, etc..

The UE <NUM> can wirelessly connect to a mobile network <NUM>. A mobile network <NUM> includes a radio access network (RAN) <NUM> and a core network <NUM>. The RAN <NUM> and the core network <NUM> function together to provide UEs <NUM> with access to services available from one or more external packet data networks. At least some services can be provided via the Internet <NUM>.

The RAN <NUM> manages the radio spectrum, making sure it is used efficiently and meets users' quality-of-service (QoS) requirements. The RAN <NUM> includes a plurality of base stations (such as the base station <NUM> shown in <FIG>) that communicate wirelessly with UEs (such as the UE <NUM> shown in <FIG>) and enable them to wirelessly connect to the mobile network <NUM>. The base station <NUM> can provide wireless connectivity for UEs within a particular geographic area, which can be referred to as a "cell. " In <NUM> mobile networks, a base station is referred to as an evolved Node B (which is often shortened to "eNodeB" or "eNB"). In <NUM> mobile networks, a base station is referred to as a next generation Node B (which is often shortened to "gNodeB" or "gNB").

A RAN controller <NUM> can be configured to control various aspects of the RAN <NUM>. The RAN controller <NUM> can be communicatively coupled to the base stations in the RAN <NUM>, such as the base station <NUM> shown in <FIG>. For example, the RAN controller <NUM> can be communicatively coupled to the base stations in the RAN <NUM> via the Internet <NUM>. In some embodiments, the RAN controller <NUM> can be located on an edge server <NUM>-<NUM>. The edge server <NUM>-<NUM> can be strategically deployed to reduce latency for the UE <NUM>. In some embodiments, the RAN controller <NUM> can be implemented as the RAN Intelligent Controller (RIC) developed by the O-RAN Alliance.

The core network <NUM> can perform a variety of functions, including providing Internet protocol (IP) connectivity for both data and voice services, ensuring this connectivity fulfills the promised QoS requirements, ensuring that the UEs are properly authenticated, tracking user mobility to ensure uninterrupted service, tracking subscriber usage for billing and charging, and so forth.

The core network <NUM> can include a control plane and a user plane. The delivery of services to UEs can occur via the user plane. Signaling that supports the establishment and maintenance of the user plane can occur via the control plane. In a <NUM> mobile network the core network <NUM> may be referred to as the Evolved Packet Core (EPC), and in a <NUM> mobile network it may be referred to as the Next Generation Core (NG-Core).

The UE <NUM> can receive data from one or more applications via the mobile network <NUM>. For the sake of simplicity, a single application <NUM> is shown in <FIG>. There are many different types of applications that can utilize the techniques disclosed herein. As one non-limiting example, the application can be a virtual reality (VR) and/or augmented reality (AR) application, and the UE <NUM> can be a VR/AR headset. As another non-limiting example, the application can be a videoconferencing application, and the UE <NUM> can be a type of computing device that includes a camera and a display (e.g., a smartphone, a laptop computer, a tablet computer) for video conferencing. Those skilled in the art will recognize many other types of applications that can be used in accordance with the present disclosure.

The UE <NUM> can include a transmitter <NUM> and a receiver <NUM> to allow transmission and reception of signals to and from base stations (such as the base station <NUM> shown in <FIG>) via one or more antennas <NUM>. The transmitter <NUM> and receiver <NUM> may be collectively referred to as a transceiver <NUM>.

The UE <NUM> can be configured to implement discontinuous reception (DRX) techniques in which the receiver <NUM> is turned off during periods of inactivity. The UE <NUM> can include DRX parameters <NUM> that control the DRX behavior of the UE <NUM>. The techniques disclosed herein enable an application <NUM> that is sending data to a UE <NUM> via a mobile network <NUM> to directly adjust the DRX behavior of the UE <NUM> by changing the DRX parameters <NUM>.

In some embodiments, the DRX parameters <NUM> can be selected so that the DRX behavior of the UE <NUM> is determined based on how frequently data is being sent to the UE <NUM>. For example, if the application <NUM> is sending data to the UE <NUM> at a particular packet interval (e.g., one data packet every N milliseconds), the DRX parameters <NUM> for the UE <NUM> can be selected so that the receiver <NUM> of the UE <NUM> is turned on whenever a new data packet is expected to arrive (e.g., the receiver <NUM> is turned on every N milliseconds). This prevents the UE <NUM> from unnecessarily turning on the receiver <NUM> and thereby increases the energy savings experienced by the UE <NUM>. The DRX parameters <NUM> of the UE <NUM> can be adjusted via an application programming interface (API) that is exposed by the RAN controller <NUM>. This API may be referred to herein as a DRX API <NUM>. The DRX API <NUM> can include a plurality of functions <NUM> that can be called to change the DRX parameters <NUM> used by the UE <NUM>.

When an application <NUM> wants to change one or more DRX parameters <NUM> for the UE <NUM>, the application <NUM> can send a request to the RAN controller <NUM> by making a function call to a relevant function <NUM> that is exposed by the DRX API <NUM>. In response to receiving the request, the RAN controller <NUM> can send one or more commands to the base station <NUM>. The command(s) sent by the RAN controller <NUM> can cause the base station <NUM> to communicate new value(s) of one or more DRX parameter(s) <NUM> to the UE <NUM>.

Although just a single application <NUM> is shown in <FIG>, the techniques disclosed herein enable a plurality of different applications to adjust the DRX parameters <NUM> of the UE <NUM>. This creates the possibility of conflicts occurring between different applications. For example, if a particular application (e.g., the application <NUM> shown in <FIG>) adjusts the DRX parameters <NUM> of the UE <NUM> to increase the amount of time that the receiver <NUM> is turned off, this could negatively affect the latency of another application that is also sending data to the UE <NUM>.

To address this problem, the RAN controller <NUM> can be configured to implement a conflict resolution policy <NUM> that prevents such conflicts from occurring. The conflict resolution policy <NUM> can control when requests to change the DRX parameters <NUM> should be granted. When the RAN controller <NUM> receives a request to change one or more DRX parameters <NUM>, the RAN controller <NUM> can determine, based at least in part on the conflict resolution policy <NUM>, whether the request should be granted. If the conflict resolution policy <NUM> indicates that the request should be granted, then the RAN controller <NUM> can proceed to send command(s) to the base station <NUM> that cause the base station <NUM> to communicate new value(s) of one or more DRX parameters <NUM> to the UE <NUM>. However, if the conflict resolution policy <NUM> indicates that the request should not be granted, then the RAN controller <NUM> can send a response to the requesting application <NUM> indicating that the request has been denied.

In some embodiments, the application <NUM> can be located on an edge server <NUM>-<NUM>. The edge server <NUM>-<NUM> can be strategically deployed to reduce latency for the UE <NUM>. The edge servers <NUM>-<NUM>, <NUM>-<NUM> shown in <FIG> can be located at an edge location that is in relatively close proximity to the UE <NUM>. In some embodiments, the edge servers <NUM>-<NUM>, <NUM>-<NUM> can be located outside of a traditional data center. In the depicted embodiment, the RAN controller <NUM> is shown on a first edge server <NUM>-<NUM>, and the application <NUM> is shown on a second edge server <NUM>-<NUM>. In some embodiments, the first edge server <NUM>-<NUM> and the second edge server <NUM>-<NUM> could be separate edge servers. In alternative embodiments, however, both the RAN controller <NUM> and the application <NUM> could run on the same edge server.

<FIG> illustrates an example of a method <NUM> for adjusting DRX behavior of a UE <NUM> to conserve energy use. The method <NUM> will be described in relation to the system <NUM> shown in <FIG>. The entities that are involved in performing the method <NUM> include the application <NUM>, the RAN controller <NUM>, the base station <NUM>, and the UE <NUM>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> exposes a DRX API <NUM>. As indicated above, the DRX API <NUM> can include a plurality of functions <NUM> that can be called to change the DRX parameters <NUM> used by the UE <NUM>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> defines a conflict resolution policy <NUM>. As indicated above, the conflict resolution policy <NUM> controls when requests to change the DRX parameters <NUM> should be granted. The conflict resolution policy <NUM> is designed to prevent conflicts between different applications.

In act <NUM> of the method <NUM>, the application <NUM> sends data packets to the UE <NUM>. The data packets can be sent at a particular packet interval. For example, a new data packet can be sent once every N milliseconds.

In act <NUM> of the method <NUM>, the application <NUM> determines, based at least in part on the packet interval, that the DRX behavior of the UE <NUM> should be changed. For example, if the application <NUM> is sending a new data packet to the UE <NUM> once every N milliseconds, then the application <NUM> might want to change the DRX behavior of the UE <NUM> so that the UE <NUM> turns its receiver <NUM> on every N milliseconds to receive a new data packet and otherwise keeps its receiver <NUM> turned off.

In act <NUM> of the method <NUM>, the application <NUM> causes one or more DRX parameters <NUM> of the UE <NUM> to be changed via the DRX API <NUM>. Act <NUM> includes acts <NUM> through <NUM>.

In act <NUM> of the method <NUM>, the application <NUM> sends a request to the RAN controller <NUM> to change one or more DRX parameters <NUM> for the UE <NUM>. Sending the request to the RAN controller <NUM> can include making a function call to a function <NUM> that is exposed by the DRX API <NUM>. The application <NUM> can provide, as part of the function call, information that enables the UE <NUM> whose DRX parameter(s) <NUM> should be changed to be identified. Such information may be referred to herein as UE identifying information. The application <NUM> can also provide, as part of the function call, information that enables new value(s) for the DRX parameter(s) <NUM> to be determined. Such information may be referred to herein as parameter identifying information. In some embodiments, the parameter identifying information can include one or more new values for one or more DRX parameters <NUM>. Alternatively, in other embodiments, the parameter identifying information can include an indication of the packet interval at which new data packets are being sent from the application <NUM> to the UE <NUM>. In such embodiments, the RAN controller <NUM> can calculate the new value(s) for the DRX parameter(s) <NUM> based on the packet interval.

In act <NUM> of the method <NUM>, the RAN controller <NUM> determines, based at least in part on the conflict resolution policy <NUM>, whether the request from the application <NUM> should be granted. If the RAN controller <NUM> determines that the request should not be granted, the RAN controller <NUM> can send a response to the application <NUM> indicating that the request is denied. However, in the present example, it will be assumed that the RAN controller <NUM> determines that the request should be granted. Therefore, in act <NUM> of the method <NUM>, the RAN controller <NUM> sends a response to the application <NUM> indicating that the request is granted.

In act <NUM> of the method <NUM>, the RAN controller <NUM> sends one or more commands to the base station <NUM>. The command(s) cause the base station <NUM> to communicate new value(s) of one or more DRX parameter(s) <NUM> to the UE <NUM>.

In act <NUM> of the method <NUM>, the base station <NUM> sends one or more commands to the UE <NUM>. The command(s) cause the UE <NUM> to change one or more of the DRX parameters <NUM> for the UE <NUM>.

<FIG> illustrates an example of a method <NUM> that can be performed by a RAN controller <NUM> for adjusting DRX behavior of a UE <NUM> to conserve energy use. The method <NUM> will be described in relation to the system <NUM> shown in <FIG>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> can receive a request to change one or more DRX parameters <NUM> for a UE <NUM>. The request can be received from an application <NUM> that is sending data to the UE <NUM> via a mobile network <NUM>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> can determine whether the conflict resolution policy <NUM> prohibits the request. For example, the RAN controller <NUM> can determine whether granting the request would cause a conflict with another application <NUM>.

If the RAN controller <NUM> determines that the conflict resolution policy <NUM> prohibits the request, then in act <NUM> of the method <NUM> the RAN controller <NUM> can deny the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the application <NUM> indicating that the request has been denied.

If in act <NUM> the RAN controller <NUM> determines that the conflict resolution policy <NUM> does not prohibit the request, then in act <NUM> of the method <NUM> the core application <NUM> can grant the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the application <NUM> indicating that the request has been granted. In act <NUM> of the method <NUM>, the RAN controller <NUM> can send one or more commands to the base station <NUM>. The command(s) can cause the base station <NUM> to communicate new value(s) of the DRX parameter(s) <NUM> to the UE <NUM>.

<FIG> illustrates an example showing possible DRX behavior of a UE. When a UE implements DRX, the UE can be configured to turn its receiver circuitry on for a first time period and then turn its receiver circuitry off for a second time period. The first time period, during which the UE's receiver circuitry is turned on, may be referred to as the on duration <NUM>. The second time period, during which the UE's receiver circuitry is turned off, may be referred to as the off duration <NUM>. A DRX cycle <NUM> can include an on duration <NUM> followed by an off duration <NUM>. The DRX behavior of a UE can include a plurality of successive DRX cycles <NUM>. In the example shown in <FIG>, a first DRX cycle <NUM>-<NUM> is followed by a second DRX cycle <NUM>-<NUM>.

Referring to both <FIG> and <FIG>, an application <NUM> can send data to a UE <NUM> at a particular packet interval (e.g., one data packet every N milliseconds). Under some circumstances, the packet interval at which data is sent to the UE <NUM> might not be aligned with the DRX cycle <NUM> that the UE <NUM> is implementing. For example, an application <NUM> can send a new data packet to a UE <NUM> once every N milliseconds, but the amount of time between successive DRX cycles <NUM> could be M milliseconds (where N ≠ M). The techniques disclosed herein enable an application <NUM> to adjust DRX parameters of a UE <NUM> so that the DRX behavior of the UE <NUM> is based on the packet interval at which data is sent to the UE <NUM>. For instance, in the present example an application <NUM> could adjust DRX parameters of the UE <NUM> so that the amount of time between successive DRX cycles <NUM> is N milliseconds (to match the packet interval).

<FIG> illustrate another example showing possible DRX behavior of a UE. The example shown in <FIG> corresponds to the DRX behavior of a UE in an LTE system. <FIG> is a state diagram showing radio resource control (RRC) modes for a UE in an LTE system. There are two RRC modes: the RRC_IDLE mode <NUM> and the RRC_CONNECTED mode <NUM>. UEs in the RRC_IDLE mode <NUM> show sporadic activity that mainly involves cell selection and reselection. UEs in the RRC_CONNECTED mode <NUM> have allocated radio resources in shared data channels, specified by dedicated signaling performed via control channels.

In the RRC_CONNECTED mode <NUM>, there are three possible states: a continuous reception state <NUM>, a short DRX state <NUM>, and a long DRX state <NUM>. In the RRC_IDLE mode <NUM>, there is one possible state: a DRX state <NUM>.

In the continuous reception state <NUM> of the RRC _CONNECTED mode <NUM>, the receiver circuitry is always turned on. In the short DRX state <NUM> and the long DRX state <NUM> of the RRC_CONNECTED mode <NUM>, as well as the DRX state <NUM> of the RRC_IDLE mode <NUM>, the UE goes through a DRX cycle (such as the DRX cycle <NUM> shown in <FIG>) in which the receiver circuitry is turned on for a relatively brief period of time and then turned off. A DRX cycle in the short DRX state <NUM> may be referred to as a short DRX cycle, and a DRX cycle in the long DRX state <NUM> may be referred to as a long DRX cycle. The amount of time between successive long DRX cycles is greater than the amount of time between successive short DRX cycles. In other words, the UE turns its receiver circuitry on more frequently in the short DRX state <NUM> than in the long DRX state <NUM>. Similarly, the amount of time between successive DRX cycles in the DRX state <NUM> is greater than the amount of time between successive long DRX cycles in the long DRX state <NUM>.

If a UE is in the continuous reception state <NUM> and a timer (shown as Ti in <FIG>) expires, then the UE transitions to the short DRX state <NUM>. If a UE is in the short DRX state <NUM> and another timer (shown as Tis in <FIG>) expires, then the UE transitions to the long DRX state <NUM>. If a UE is in the long DRX state <NUM> and another timer (shown as Trail in <FIG>) expires, then the UE transitions to the DRX state <NUM> in the RRC_IDLE mode <NUM>. Whenever data is received, the UE transitions into the continuous reception state <NUM>.

Various parameters that can affect DRX behavior in an LTE system are included in Table <NUM>, which is provided immediately below.

<FIG> illustrates an example of UE DRX behavior in the RRC_CONNECTED mode <NUM>.

Several of the parameters that are included in Table <NUM> are also illustrated in <FIG>.

The techniques disclosed herein can be utilized to change any of the parameters listed in Table <NUM>. Referring to <FIG> in connection with <FIG> and Table <NUM>, in some embodiments the DRX API <NUM> can expose a separate function <NUM> for each of the DRX parameters <NUM> listed in Table <NUM>. When an application <NUM> wants to change one of the DRX parameters <NUM>, the application <NUM> can make a function call to the relevant function <NUM>. In some embodiments, one or more of the functions <NUM> exposed by the DRX API <NUM> can be used to change more than one DRX parameter.

Although the example shown in <FIG> corresponds to the DRX behavior of a UE in an LTE system, this should not be interpreted as limiting the scope of the present disclosure. The techniques disclosed herein can, of course, be applied to other types of wireless communication systems. For example, the techniques disclosed herein can be applied to change DRX parameters in a <NUM> system.

DRX behavior in a <NUM> system is similar in many respects to DRX behavior in an LTE system. When a UE is not receiving or sending data transmissions, the UE can stay in a low-power mode state known as "deep sleep. " When data arrives, the UE can enter the connected mode for data transmission. Connected mode DRX provides two levels of monitoring granularity via short and long DRX configurations. Customizing control channel monitoring patterns allows a UE to stay in an intermediate low-power state ("micro sleep") part of the time without any performance loss. The techniques disclosed herein can be utilized to change any parameters that affect DRX behavior in a <NUM> system.

<FIG> illustrates another example of a system <NUM> in which the techniques disclosed herein can be utilized. The system <NUM> shown in <FIG> is similar in many respects to the system <NUM> that was described above in connection with <FIG>. The system <NUM> includes a UE <NUM> that can wireless connect to a mobile network <NUM>. The mobile network <NUM> includes a RAN <NUM> and a core network <NUM>, which provide UEs <NUM> with access to services available from one or more external packet data networks, such as the Internet <NUM>.

The system <NUM> shown in <FIG> includes two different types of applications: a core application <NUM> and a third-party application <NUM>. The core application <NUM> is provided as part of the RAN controller <NUM> and is expected to be used for the general optimization of the RAN <NUM>. For example, the core application <NUM> can be used for the general optimization of all UEs <NUM> that are wirelessly connected to a base station <NUM> within the RAN <NUM>. The core application <NUM> can be a trusted system application that has full visibility to the state of the RAN <NUM>. Conversely, the third-party application <NUM> may not be trusted and may not have visibility to the state of the RAN <NUM>, unless the third-party application <NUM> is explicitly granted permission to particular state information. The core application <NUM> can grant such permission to the third-party application <NUM>.

The third-party application <NUM> can function similarly to the application <NUM> that was described above in connection with <FIG>. In particular, the third-party application <NUM> can send data to the UE <NUM> via the mobile network <NUM>. Under some circumstances, the third-party application <NUM> may want to change one or more DRX parameters <NUM> for the UE <NUM>. When the third-party application <NUM> wants to change one or more DRX parameters <NUM> for the UE <NUM>, the third-party application <NUM> can send a request to the RAN controller <NUM> by making a function call to a relevant function <NUM> that is exposed by the DRX API <NUM>. When the RAN controller <NUM> receives a request to change DRX parameter(s) <NUM>, the RAN controller <NUM> can determine, based at least in part on the conflict resolution policy <NUM>, whether the request should be granted. In the depicted example, the core application <NUM> within the RAN controller <NUM> can be responsible for making this determination.

The core application <NUM> can determine whether a request to change DRX parameter(s) <NUM> for a UE <NUM> should be granted based on one or more rules <NUM> that are defined as part of the conflict resolution policy <NUM>. In some embodiments, a plurality of actions <NUM> can be defined. An action <NUM> can represent modifying DRX parameters <NUM> associated with a particular UE <NUM> that is connected to the RAN <NUM>. Each action <NUM> can have an owner <NUM>. In some embodiments, the conflict resolution policy <NUM> can be designed to permit only a single owner <NUM> for each action <NUM>. The rules <NUM> for granting or denying requests to change DRX parameters <NUM> can be based at least in part on ownership of the actions <NUM>.

In some embodiments, the core application <NUM> can grant a request to change DRX parameter(s) <NUM> for a UE <NUM> as long as another third-party application <NUM> does not own the relevant action <NUM>. More specifically, the request to change DRX parameter(s) <NUM> can correspond to a particular action <NUM>. If the core application <NUM> itself is the owner <NUM> of the action <NUM>, then the request can be granted. However, if another third-party application <NUM> is the owner <NUM> of the action <NUM>, then the request can be denied.

In some embodiments, the core application <NUM> can also take other factors into consideration (e.g., the effect of granting the request on overall network performance) when deciding whether to grant a request to change DRX parameter(s) <NUM> for a UE <NUM>. For example, if the third-party application <NUM> sends a request to change DRX parameter(s) <NUM> for a UE <NUM> and another third-party application <NUM> does not own the corresponding action <NUM>, the core application <NUM> could still deny the request if the core application <NUM> determines that granting the request would adversely affect overall network performance.

For the sake of simplicity, only a single core application <NUM> and a single third-party application <NUM> are shown in the system <NUM> depicted in <FIG>. However, a RAN controller in accordance with the present disclosure could include a plurality of different core applications. In addition, the RAN controller could enable a plurality of different third-party applications to change DRX parameters for a plurality of different UEs.

In some embodiments, the third-party application <NUM> can run on an edge server <NUM>, as shown in <FIG>.

<FIG> illustrates an example of a method <NUM> that can be performed by a RAN controller <NUM> in order to determine whether a request to change DRX parameter(s) <NUM> for a UE <NUM> should be granted. The method <NUM> will be described in relation to the system <NUM> shown in <FIG>. At least some actions of the method <NUM> can be performed by a core application <NUM> in the RAN controller <NUM>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> can receive a request to change one or more DRX parameters <NUM> for a UE <NUM>. The request can be received from a third-party application <NUM>. To distinguish the third-party application <NUM> that sends the request from other third-party applications, the third-party application <NUM> that sends the request may be referred to as a requesting third-party application <NUM>. As discussed above, receiving the request can include receiving a function call to a function <NUM> that is exposed by the DRX API <NUM>.

In act <NUM> of the method <NUM>, the core application <NUM> in the RAN controller <NUM> can identify an action <NUM> that corresponds to the request received in act <NUM>.

In act <NUM> of the method <NUM>, the core application <NUM> can identify an owner <NUM> of the action <NUM> that is identified in act <NUM>.

In act <NUM> of the method <NUM>, the core application <NUM> can determine whether the owner <NUM> of the action <NUM> is a third-party application <NUM>.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the owner <NUM> of the action <NUM> is a third-party application <NUM>, then in act <NUM> of the method <NUM> the core application <NUM> can deny the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the requesting third-party application <NUM> indicating that the request has been denied.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the owner <NUM> of the action <NUM> is not a third-party application <NUM>, then in act <NUM> of the method <NUM> the core application <NUM> can grant the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the requesting third-party application <NUM> indicating that the request has been granted. In act <NUM> of the method <NUM> the RAN controller <NUM> can send one or more commands to the base station <NUM> to which the UE <NUM> is connected. The command(s) sent by the RAN controller <NUM> can cause the base station <NUM> to communicate new value(s) of DRX parameter(s) <NUM> to the UE <NUM>.

<FIG> illustrate an example showing how a core application <NUM> in a RAN controller <NUM> can decide whether to grant or deny requests from third-party applications. The depicted example involves two third-party applications: a first third-party application <NUM>-<NUM> and a second third-party application <NUM>-<NUM>. Two actions have been defined: a first action <NUM>-<NUM> that represents modifying DRX parameters <NUM> associated with a first UE (UE1), and a second action <NUM>-<NUM> that represents modifying DRX parameters associated with a second UE (UE2).

Reference is initially made to <FIG>. For purposes of the present example, it will be assumed that both the first action <NUM>-<NUM> and the second action <NUM>-<NUM> are initially owned by the core application <NUM>. In other words, the core application <NUM> is initially the owner of actions (the first action <NUM>-<NUM> and the second action <NUM>-<NUM>) that the first third-party application <NUM>-<NUM> and the second third-party application <NUM>-<NUM> could potentially want to use, as will be discussed in greater detail below.

The core application <NUM> receives a request <NUM> from the first third-party application <NUM>-<NUM> to modify one or more DRX parameters for UE1. In response to receiving this request <NUM>, the core application <NUM> identifies an action that corresponds to the received request <NUM>. In this case, the first action <NUM>-<NUM> corresponds to the received request <NUM>. The core application <NUM> also determines whether the owner <NUM>-<NUM> of the first action <NUM>-<NUM> is another third-party application. In this case, the first action <NUM>-<NUM> is presently owned by the core application <NUM>, not another third-party application. Therefore, the core application <NUM> grants the request <NUM> and sends a response <NUM> to the first third-party application <NUM>-<NUM> indicating that the request <NUM> has been granted. The core application <NUM> also changes the owner <NUM>-<NUM> of the first action <NUM>-<NUM> to the first third-party application <NUM>-<NUM>. After granting the request <NUM>, the RAN controller <NUM> can send one or more commands to the base station to which UE1 is connected, causing the base station to communicate new value(s) of DRX parameter(s) to UE1.

Referring now to <FIG>, the core application <NUM> receives a request <NUM> from the second third-party application <NUM>-<NUM> to modify one or more DRX parameters for UE1. In response to receiving this request <NUM>, the core application <NUM> identifies the first action <NUM>-<NUM> as corresponding to the received request <NUM>. The core application <NUM> also determines whether the owner <NUM>-<NUM> of the first action <NUM>-<NUM> is another third-party application. In this case, the first action <NUM>-<NUM> is presently owned by another third-party application, namely the first third-party application <NUM>-<NUM>. Therefore, the core application <NUM> denies the request <NUM> and sends a response <NUM> to the second third-party application <NUM>-<NUM> indicating that the request <NUM> has been denied.

Referring now to <FIG>, the core application <NUM> receives a request <NUM> from the second third-party application <NUM>-<NUM> to modify one or more DRX parameters for UE2. In response to receiving this request <NUM>, the core application <NUM> identifies an action that corresponds to the received request <NUM>. In this case, the second action <NUM>-<NUM> corresponds to the received request <NUM>. The core application <NUM> also determines whether the owner <NUM>-<NUM> of the second action <NUM>-<NUM> is another third-party application. In this case, the second action <NUM>-<NUM> is presently owned by the core application <NUM>, not another third-party application. Therefore, the core application <NUM> grants the request <NUM> and sends a response <NUM> to the second third-party application <NUM>-<NUM> indicating that the request <NUM> has been granted. The core application <NUM> also changes the owner <NUM>-<NUM> of the second action <NUM>-<NUM> to the second third-party application <NUM>-<NUM>.

<FIG> illustrates another example of a method <NUM> that can be performed by a RAN controller <NUM> in order to determine whether a request to change DRX parameter(s) <NUM> for a UE <NUM> should be granted. The method <NUM> will be described in relation to the system <NUM> shown in <FIG>. At least some actions of the method <NUM> can be performed by a core application <NUM> in the RAN controller <NUM>.

In the method <NUM> that was previously described in connection with <FIG>, the core application <NUM> grants a request to change DRX parameter(s) <NUM> for a UE <NUM> as long as another third-party application <NUM> does not own the relevant action <NUM>. However, in the method <NUM> shown in <FIG>, in addition to determining ownership of the relevant action <NUM>, the core application <NUM> can also take other factors into consideration (e.g., the effect of granting the request on overall network performance) when deciding whether to grant a request to change DRX parameter(s) <NUM> for a UE <NUM>.

In act <NUM> of the method <NUM>, the RAN controller <NUM> can receive a request to change one or more DRX parameters for a UE <NUM>. The request can be received from a third-party application <NUM>, which may be referred to as a requesting third-party application <NUM>. As discussed above, receiving the request can include receiving a function call to a function <NUM> that is exposed by a DRX API <NUM>.

In act <NUM> of the method <NUM>, the core application <NUM> can identify an owner of the action <NUM> that is identified in act <NUM>. In act <NUM> of the method <NUM>, the core application <NUM> can determine whether the owner of the action <NUM> is a third-party application <NUM>.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the owner of the action <NUM> is a third-party application <NUM>, then in act <NUM> of the method <NUM> the core application <NUM> can deny the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the requesting third-party application <NUM> indicating that the request has been denied.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the owner of the action <NUM> is not a third-party application <NUM>, then in act <NUM> of the method <NUM> the core application <NUM> can determine whether one or more additional conditions for granting the request are satisfied. For example, the core application <NUM> can determine whether granting the request would adversely affect network performance. In some embodiments, determining whether granting the request would adversely affect network performance can include estimating how granting the request would affect one or more metrics that indicate network performance, and then comparing the estimated metrics to one or more pre-defined thresholds.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the additional condition(s) for granting the request are not satisfied, then the core application <NUM> can deny the request. The method <NUM> can then proceed to act <NUM> and continue as described above.

If in act <NUM> of the method <NUM> the core application <NUM> determines that the additional condition(s) for granting the request are satisfied, then in act <NUM> of the method <NUM> the core application <NUM> can grant the request. In act <NUM> of the method <NUM> the RAN controller <NUM> can send a message to the requesting third-party application <NUM> indicating that the request has been granted. In act <NUM> of the method <NUM> the RAN controller <NUM> can send one or more commands to the base station <NUM> to which the UE <NUM> is connected. The command(s) sent by the RAN controller <NUM> can cause the base station <NUM> to communicate new value(s) of DRX parameter(s) <NUM> to the UE <NUM>. <FIG> illustrates certain components that can be included within a computing system <NUM>. The computing system <NUM> can be used to implement the actions and operations that have been described herein in connection with a RAN controller (e.g., the RAN controller <NUM> in <FIG>, the RAN controller <NUM> in <FIG>). In some embodiments, a plurality of computing systems <NUM> can collectively implement the actions and operations that have been described herein in connection with a RAN controller.

The computing system <NUM> includes a processor <NUM> and memory <NUM> in electronic communication with the processor <NUM>. Instructions 1005a and data 1007a can be stored in the memory <NUM>. The instructions 1005a can be executable by the processor <NUM> to implement some or all of the methods, steps, operations, actions, or other functionality disclosed herein related to a RAN controller. Executing the instructions 1005a can involve the use of the data 1007a that is stored in the memory <NUM>. When the processor <NUM> executes the instructions 1005a, various instructions 1005b can be loaded onto the processor <NUM>, and various pieces of data 1007b can be loaded onto the processor <NUM>.

Unless otherwise specified, any of the various examples of modules and components described herein in connection with a RAN controller can be implemented, partially or wholly, as instructions 1005a stored in memory <NUM> and executed by the processor <NUM>. Any of the various examples of data described herein in connection with a RAN controller can be among the data 1007a that is stored in memory <NUM> and used during execution of the instructions 1005a by the processor <NUM>.

Although just a single processor <NUM> and a single memory <NUM> are shown in the computing system <NUM> of <FIG>, in an alternative configuration, a combination of processors and/or a combination of memory devices could be used.

The instructions 1005a in the memory <NUM> can include one or more modules that can be executable by the processor <NUM> to perform some or all aspects of the methods that have been described herein in connection with a RAN controller (e.g., the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>). Such modules can include a DRX API <NUM> (and any functions or methods associated with the DRX API <NUM>) that is exposed by a RAN controller. Such modules can also include a request handler <NUM> for handling requests to change DRX parameters. As discussed above, such requests can be received from applications via the DRX API <NUM>.

The data 1007a stored in the memory <NUM> can include any of the various examples of data described herein in connection with a RAN controller. For example, the data 1007a stored in the memory <NUM> can represent data that is stored, accessed, or otherwise used in connection with the methods that have been described herein in connection with a RAN controller (e.g., the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>, the method <NUM> shown in <FIG>).

For example, the data 1007a stored in the memory <NUM> can include a conflict resolution policy <NUM>. The conflict resolution policy <NUM> shown in <FIG> can represent any of the conflict resolution policies described herein in connection with a RAN controller (e.g., the conflict resolution policy <NUM> shown in <FIG>, the conflict resolution policy <NUM> shown in <FIG>). The specific instructions 1005a and data 1007a shown in <FIG> are provided for purposes of example only and should not be interpreted as limiting the scope of the present disclosure. A computing system <NUM> that implements any of the techniques disclosed herein can include other instructions 1005a and/or other data 1007a in addition to or instead of what is specifically shown in <FIG>.

The computing system <NUM> can also include various other components, including one or more communication interfaces <NUM>, one or more input devices <NUM>, and one or more output devices <NUM>.

The communication interface(s) <NUM> can be configured to communicate with other computing systems and/or networking devices. This includes receiving data transmissions from other computing systems and/or networking devices, and also sending data transmissions to other computing systems and/or networking devices. The communication interface(s) <NUM> can be based on wired communication technology, wireless communication technology, or both.

The various components of the computing system <NUM> can be coupled together by one or more buses, which can include a power bus, a control signal bus, a status signal bus, a data bus, etc. For simplicity, the various buses are illustrated in <FIG> as a bus system <NUM>.

The techniques disclosed herein can be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a specific manner. Any features described as modules, components, or the like can also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques can be realized at least in part by a non-transitory computer-readable medium having computer-executable instructions stored thereon that, when executed by at least one processor, perform some or all of the steps, operations, actions, or other functionality disclosed herein. The instructions can be organized into routines, programs, objects, components, data structures, etc., which can perform particular tasks and/or implement particular data types, and which can be combined or distributed as desired in various embodiments.

The term "processor" should be interpreted broadly to encompass a general-purpose processor, a central processing unit (CPU), a microprocessor, a digital signal processor (DSP), a controller, a microcontroller, a state machine, and so forth. Under some circumstances, a "processor" may refer to an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), etc. The term "processor" may refer to a combination of processing devices, e.g., a combination of a digital signal processor (DSP) and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a digital signal processor (DSP) core, or any other such configuration.

The term "memory" should be interpreted broadly to encompass any electronic component capable of storing electronic information. The term "memory" may refer to various types of processor-readable media such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable PROM (EEPROM), flash memory, magnetic or optical data storage, registers, etc. Memory is said to be in electronic communication with a processor if the processor can read information from and/or write information to the memory. Memory that is integral to a processor is in electronic communication with the processor.

The terms "instructions" and "code" should be interpreted broadly to include any type of computer-readable statement(s). For example, the terms "instructions" and "code" may refer to one or more programs, routines, sub-routines, functions, procedures, etc. "Instructions" and "code" may comprise a single computer-readable statement or many computer-readable statements.

The term "communicatively coupled" refers to coupling of components such that these components are able to communicate with one another through, for example, wired, wireless, or other communications media. The term "communicatively coupled" can include direct, communicative coupling as well as indirect or "mediated" communicative coupling. For example, a component A may be communicatively coupled to a component B directly by at least one communication pathway, or a component A may be communicatively coupled to a component B indirectly by at least a first communication pathway that directly couples component A to a component C and at least a second communication pathway that directly couples component C to component B. In this case, component C is said to mediate the communicative coupling between component A and component B.

The term "determining" (and grammatical variants thereof) can encompass a wide variety of actions. For example, "determining" can include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like.

The terms "comprising," "including," and "having" are intended to be inclusive and mean that there can be additional elements other than the listed elements. For example, any element or feature described in relation to an embodiment herein may be combinable with any element or feature of any other embodiment described herein, where compatible.

The steps, operations, and/or actions of the methods described herein may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps, operations, and/or actions is required for proper functioning of the method that is being described, the order and/or use of specific steps, operations, and/or actions may be modified without departing from the scope of the claims.

In the above description, reference numbers have sometimes been used in connection with various terms. Where a term is used in connection with a reference number, this may be meant to refer to a specific element that is shown in one or more of the Figures. Where a term is used without a reference number, this may be meant to refer generally to the term without limitation to any particular Figure.

Claim 1:
A method for adjusting discontinuous reception 'DRX' behavior of a user equipment 'UE' (<NUM>) to conserve energy use, the UE (<NUM>) being in wireless communication with a base station (<NUM>), the method being performed by a radio access network 'RAN' controller (<NUM>) that is communicatively coupled to the base station (<NUM>), the method comprising:
exposing a DRX application programming interface 'API' (<NUM>) that enables DRX parameters (<NUM>) to be changed;
creating a conflict resolution policy (<NUM>) that controls when requests to change the DRX parameters (<NUM>) should be granted, the conflict resolution policy (<NUM>) being designed to prevent conflicts between different applications;
receiving, via the DRX API (<NUM>), a first request from a first application to change a DRX parameter for the UE (<NUM>) from a current value to a new value, wherein the first application is external to the UE (<NUM>) and is configured to send data to the UE (<NUM>) via a mobile network (<NUM>) that comprises the base station (<NUM>);
determining, based at least in part on the conflict resolution policy (<NUM>), that the first request should be granted; and
sending a command to the base station (<NUM>), the command causing the base station (<NUM>) to communicate the new value of the DRX parameter to the UE (<NUM>).