WO2025008044A1

WO2025008044A1 - Ue-autonomous cdrx iat control

Info

Publication number: WO2025008044A1
Application number: PCT/EP2023/068243
Authority: WO
Inventors: Andres Reial; Ali Nader; Ilmiawan SHUBHI; Gang ZOU; Sina MALEKI
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2023-07-03
Filing date: 2023-07-03
Publication date: 2025-01-09

Abstract

Systems and methods are disclosed that relate to User Equipment (UE) autonomous connected-mode Discontinuous Reception (cDRX) inactivity timer control. In one embodiment, a method performed by a UE in a wireless communications system comprises receiving first scheduling or control messages from one or more network nodes and obtaining a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based thereon. The method further comprises, during an active state of a cDRX mode of operation, receiving a second scheduling or control message from a network node while an inactivity timer is running and performing one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message.

Description

UE-AUTONOMOUS cDRX IA T CONTROL

Technical Field

The present disclosure relates to a cellular communications system and, more specifically, Discontinuous Reception (DRX) mode operation of a User Equipment (UE) in a cellular communications system.

Background

In the 3^rd Generation Partnership Project (3GPP) New Radio (NR), connected mode Discontinuous Reception (cDRX) is a key feature for reducing energy consumption at the User Equipment (UE). cDRX allows the UE to only monitor for scheduling messages (i.e., scheduling Physical Downlink Control Channel (PDCCHs)) during well-defined monitoring intervals, which are referred to as "on-durations". For example, the on- durations may be 10 millisecond (ms) periods that occur every 160 ms in the case of long cDRX. Outside of these on-durations, the UE can remain in a sleep mode, thereby reducing the energy consumption of the UE.

In cDRX operation, when a UE receives a scheduling PDCCH, for most scheduling PDCCH types, the UE starts an Inactivity Timer (IAT) and continues monitoring for an additional PDCCH(s) in the configured Search Space (SS) until the IAT expires. Each new scheduling PDCCH restarts the IAT. Only after the IAT expires, i.e., when no new data arrives for the full duration of the IAT, does the UE return to cDRX and enter deep sleep for maximum power saving.

An example timeline illustrating the IAT function is shown in Figure 1, where the numbers in parentheses in Figure 1 correspond to example UE power levels in the different operational stages. As illustrated, the UE starts in a deep sleep state. During an on-duration of the cDRX mode, the UE wakes up and, in this example, detects a paging message, starts the IAT, and starts PDCCH monitoring. In this example, the UE detects multiple scheduling PDCCHs before the IAT expires. Each time a scheduling PDCCH is detected, the IAT is restarted. Once the IAT expires, the UE enters a sleep state. Figure 1 also illustrates a data IAT, including a number of full cDRX periods before the UE is released to IDLE/inactive state.

Systems and methods are disclosed that relate to User Equipment (UE) autonomous connected-mode Discontinuous Reception (cDRX) inactivity timer control. In one embodiment, a method performed by a UE in a wireless communications system comprises receiving a plurality of first scheduling or control messages from one or more network nodes and obtaining a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based on the plurality of first scheduling or control messages. The method further comprises, during an active state of a cDRX mode of operation, receiving a second scheduling or control message from a network node while an inactivity timer is running and performing one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message. In this manner, the UE is enabled to further conserve energy and extend its battery lifetime between charges due to omitting long intervals of unnecessary monitoring for scheduling or control messages.

In one embodiment, performing the one or more actions may comprise deciding to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running based on the second scheduling or control message being a non-data transmission related scheduling or control message and the transmission pattern being indicative of a data transmission related scheduling or control message not being expected and refraining from monitoring for an additional scheduling or control message while the inactivity timer is running, in accordance with deciding to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running. In one embodiment, deciding to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running may be further based on an energy or power consumption status of the UE, a Quality of Service (QoS) desired for data transmissions to or from the UE, or both.

In one embodiment, performing the one or more actions may comprise deciding to continue monitoring for an additional scheduling or control message while the inactivity timer is running in response to the second scheduling or control message being a non- data transmission related scheduling or control message and the transmission pattern being indicative of a data transmission related scheduling or control message being expected and continuing to monitor for an additional scheduling or control message while the inactivity timer is running, in accordance with deciding to continue monitoring for an additional scheduling or control message while the inactivity timer is running. In one embodiment, deciding to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running may be further based on an energy or power consumption status of the UE, a QoS desired for data transmissions to or from the UE, or both.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, determining that a data-related scheduling or control message is expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and continuing to monitor for an additional scheduling or control message while the inactivity timer is running in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message being expected within the determined or configured amount of time.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, determining that a data-related scheduling or control message is not expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and refraining from monitoring for an additional scheduling or control message while the inactivity timer is running in response to determining that the second scheduling or control message a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is not expected within the determined or configured amount of time.

In one embodiment, performing the one or more actions may comprises deciding to restart the inactivity timer in response to the second scheduling or control message being a data transmission related scheduling or control message, and restarting the inactivity timer, in accordance with deciding to restart the inactivity timer. In one embodiment, deciding to restart the inactivity timer is further based on an energy or power consumption status of the UE, a QoS desired for data transmissions to or from the UE, or both.

In one embodiment, performing the one or more actions may comprise deciding to refrain from restarting the inactivity timer in response to the second scheduling or control message being a non-data transmission related scheduling or control message, and refraining from restarting the inactivity timer, in accordance with deciding to refrain from restarting the inactivity timer.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, determining that a data-related scheduling or control message is expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and restarting the inactivity timer in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is expected within the determined or configured amount of time.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, determining that a data-related scheduling or control message is not expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and refraining from restarting the inactivity timer in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is not expected within the determined or configured amount of time.

In one embodiment, performing the one or more actions may comprise deciding to adjust the inactivity timer in response to the second scheduling or control message being a non-data transmission related scheduling or control message, and adjusting the inactivity timer, in accordance with deciding to adjust the inactivity timer. In one embodiment, deciding to adjust the inactivity timer may be further based on an energy or power consumption status of the UE, a QoS desired for data transmissions to or from the UE, or both. In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, estimating a probability that a data-related scheduling or control message will occur within an amount of time after receiving the second scheduling or control message, based on the transmission pattern, and, responsive to the second scheduling or control message being a non-data transmission related scheduling or control message, adjusting the inactivity timer or not, based on the estimated probability.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, estimating a probability that a data-related scheduling or control message will occur within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and, responsive to the second scheduling or control message being a non-data transmission related scheduling or control message, restarting the inactivity timer in response to the estimated probability of a data-related scheduling or control message within the determined or configured amount of time being greater than a threshold.

In one embodiment, performing the one or more actions may comprise determining that the second scheduling or control message is a non-data transmission related scheduling or control message, estimating a probability that a data-related scheduling or control message will occur within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern, and, responsive to the second scheduling or control message being a non-data transmission related scheduling or control message, increasing the inactivity timer to a predetermined, configured, or determined value that is less than a configured starting value of the inactivity timer in response to the estimated probability of a data-related scheduling or control message within the determined or configured amount of time is less than a threshold.

Corresponding embodiments of a UE are also disclosed. In one embodiment, a UE for a wireless communication system comprises one or more receivers and processing circuitry associated with the one or more receivers. The processing circuitry is configured to cause the UE to receive a plurality of first scheduling or control messages from one or more network nodes and obtain a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based on the plurality of first scheduling or control messages. The processing circuitry is further configured to cause the UE to, during an active state of a cDRX mode of operation, receive a second scheduling or control message from a network node while an inactivity timer is running and perform one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message.

Brief Description of the Drawings

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figure 1 illustrates an example timeline showing the Inactivity Timer (IAT) function for connected mode Discontinuous Reception (cDRX) operation;

Figure 2 illustrates a wireless network including a User Equipment (UE) and a network node in accordance with one embodiment of the present disclosure;

Figure 3 is a flow chart that illustrates the operation of the UE of Figure 2 in accordance with embodiments of the present disclosure;

Figures 4, 5, and 6 illustrate steps 306 in more detail in accordance with example embodiments of the present disclosure;

Figure 7 illustrates one example of a cellular communications system according to some embodiments of the present disclosure;

Figure 8 is a schematic block diagram of a radio access node according to some embodiments of the present disclosure;

Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node of Figure 8 according to some embodiments of the present disclosure;

Figure 10 is a schematic block diagram of the radio access node of Figure 8 according to some other embodiments of the present disclosure;

Figure 11 is a schematic block diagram of a User Equipment (UE) according to some embodiments of the present disclosure; Figure 12 is a schematic block diagram of the UE of Figure 11 according to some other embodiments of the present disclosure;

Figure 13 illustrates a telecommunication network connected via an intermediate network to a host computer in accordance with some embodiments of the present disclosure;

Figure 14 is a generalized block diagram of a host computer communicating via a base station with a UE over a partially wireless connection in accordance with some embodiments of the present disclosure;

Figure 15 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure;

Figure 16 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure;

Figure 17 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure; and

Figure 18 is a flowchart illustrating a method implemented in a communication system in accordance with one embodiment of the present disclosure.

Detailed Description

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Radio Node: As used herein, a "radio node" is either a radio access node or a wireless communication device.

Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

User Equipment (UE) or Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Note that the terms "UE" and "wireless communication device" are used herein interchangeably. Some examples of a wireless communication device or UE include, but are not limited to: a UE in a 3GPP network (i.e., a 3GPP UE), a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

There are certain challenges with the existing connected mode Discontinuous Reception (cDRX) solution defined in 3GPP specifications. UE energy consumption in connected mode, related to downlink operation, depends predominantly on the receiver (RX) on time. When the UE receiver is ON, the UE monitors for a PDCCH in the configured Search Space (SS), usually continuously or frequently. In practice, in a significant amount of the PDCCH monitoring instances, nothing is scheduled for the UE and, as a result, a considerable amount of energy may be spent while the UE does not receive any data.

When the UE is configured with cDRX, the UE performs PDCCH monitoring during the active time or on-duration and during a period of time defined by the Inactivity Timer (IAT). Specifically, the current 3GPP specifications (see, e.g., 3GPP Technical Specification (TS) 38.321 V17.4.0) states:

2> if the PDCCH indicates a new transmission (DL, UL or SL) on a Serving Cell in this DRX group:

3> start or restart drx-InactivityTimerfor this DRX group in the first symbol after the end of the PDCCH reception.

Thus, any PDCCH starting a new Medium Access Control (MAC) Protocol Data Unit (PDU) that the UE would recognize as a new transmission leads to starting or restarting the IAT. Nevertheless, the specification does not define how the MAC should define a new transmission. Therefore, the UE triggers restarting of the IAT for any PDCCH starting any new MAC PDU.

In some scenarios, however, a MAC PDU transmission by the network is not associated with ongoing or expected data transmission. For example, the network may request a Buffer Status Report (BSR). In this example, the network asks the UE for a BSR. In response, the UE first triggers the IAT for the request, and then the UE also restarts the IAT after sending the report, even if the report is BSRO, i.e., UE's uplink (UL) buffer is empty. As a consequence, the UE keeps monitoring for PDCCH throughout the whole IAT while no higher layer control or user-plane data might be scheduled. This has been observed as a major contributor to high energy consumption in practical Evolved Universal Terrestrial Radio Access (E-UTRAN)/New Radio (NR) Dual Connectivity (EN- DC) operation in UEs currently on the market.

The same applies to some other MAC CE commands, e.g., Transmission Configuration Indication (TCI) States Activation/ Deactivation for UE-specific PDSCH MAC CE, TCI State Indication for UE-specific PDCCH MAC CE, Timing Advance Command MAC CE, etc. In most of these cases, the network does not intend to schedule anything after the command is implemented by the UE.

In an existing solution to the aforementioned problem, additional signaling has been proposed whereby the network can indicate in conjunction with individual transmissions whether the IAT should be restarted, or additional criteria for restarting the IAT that are mutually aligned between the UE and the network. However, this approach, even if adopted into the 3GPP specifications, will only apply to later-release UEs but not to earlier-release UEs or UEs that do not implement later-release features.

Since instances of unnecessarily triggering restarting of the IAT lead to extended PDCCH monitoring by the UE and additional energy consumption, there is a need for further solutions for controlling PDCCH monitoring when the UE receives a scheduling PDCCH that does not rely on new standardized features.

Systems and methods are disclosed that address the aforementioned and/or other challenges with the existing cDRX solution. In one embodiment, while in an active state of a cDRX mode of operation, the UE receives a scheduling or control message (e.g., a PDCCH) from a network node while an IAT is running and, in response, performs one or more actions related to continued monitoring (e.g., restarting the IAT timer, refraining from restarting the IAT timer, adjusting the IAT timer, etc.) based on: (a) an obtained transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages and (b) whether the received scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message. For example, in one embodiment, the UE does not restart the cDRX IAT if the received scheduling or control message is a PDCCH carrying certain MAC PDU types related to non-data transmission (e.g., BSR MAC CE, TCI states activation/deactivation for UE- specific PDSCH MAC CE, TCI state indication for UE-specific PDCCH MAC CE, Timing Advance Command (TAC) MAC CE, or the like). In another embodiment, the UE restarts the cDRS IAT with a reduced duration if the received scheduling or control message (e.g., a PDCCH carrying certain MAC PDU types) for which data scheduling during the IAT has a low probability (e.g., less than a predefined or configured threshold probability), e.g., as determined based on the obtained transmission pattern. In one embodiment, decisions about whether and with what setting to restart the IAT may be based on learning network behavior regarding non-data scheduling or control message transmissions (e.g., PDCCH transmissions such as, e.g., MAC CE commands and requests) and any following data transmissions. This network behavior is referred to herein as a "transmission pattern". Note that separate transmission patterns may be learned separately for different commands/requests, and optionally including different UE's responses to those commands, for different network load conditions, etc.

In one embodiment, decisions about whether and with what setting to restart the IAT may also be based on the nominal IAT length, which is related to the amount of energy expended, and the energy and latency cost of re-establishing a network connection.

In some embodiments, recovery mechanisms in case the UE is released by the network due to missing transmissions during the IAT duration that the UE missed may also be considered.

In one embodiment, the UE may activate (e.g., restart) the IAT only when the received PDCCH transmission is a likely indicator of an ongoing data arrival process and/or if a probability (or other cost metric) of missing a data transmission due to not restarting the IAT exceeds a threshold (e.g., a predefined or configured probability threshold). In one embodiment, a UE configured with cDRX may operate as follows for data reception. The UE receives multiple first PDCCH transmissions and obtains (e.g., determines) a transmission pattern for non-data transmission related PDCCH transmissions and/or data transmission related PDCCH transmissions. While an IAT is running, the UE receives a second PDCCH transmission, determines an IAT setting (e.g., restart the IAT, not restart the IAT, adjust the IAT, or the like) based on a PDCCH type of the second PDCCH transmission and the obtained transmission pattern, and applies the IAT setting for PDCCH monitoring. In one embodiment, determining the IAT setting is further based on UE energy/power consumption status, current Quality of Service (QoS), and/or the like.

In one embodiment, a UE configured with DRX may operate as follows for data reception. The UE receives a PDCCH transmission and then performs PDCCH monitoring for the duration of a configured cDRX IAT if the second PDCCH transmission is data arrival-related or terminates PDCCH monitoring before the end of the duration of the configured cDRX IAT if the second PDCCH transmission is not data arrival-related. It should be noted that while the description herein focuses on the cDRX IAT, similar principles may be applied to the data IAT.

Embodiments of the present disclosure may provide a number of advantages over the existing cDRX solution. For example, embodiments of the present disclosure enable the UE to further conserve energy and extend its battery lifetime between charges due to omitting long intervals of unnecessary PDCCH monitoring. In some embodiments, performance impact and loss of robustness is avoided by applying the approach adaptively and matching the actual network behavior.

Figure 2 illustrates a wireless network 200 including a UE 202 and a network node 204 in accordance with one embodiment of the present disclosure. In the preferred embodiments described herein, the wireless network 200 is a NR RAN, and the network node 204 is a gNB; however, the embodiments described herein may be used in other types of wireless networks that utilize cDRX or an analogous feature such as, e.g., a 6^th Generation (6G) network.

Figure 3 is a flow chart that illustrates the operation of the UE 202 in accordance with embodiments of the present disclosure. Optional steps or features are represented by dashed lines/boxes. As illustrated, the UE 202 receives a cDRX configuration from the network node 204 and applies the cDRX configuration (step 300). While applying the cDRX configuration, the UE 202 receives a first set of scheduling or control messages from the network node 204 (301). In one embodiment, the first set of scheduling or control messages is a first set of PDDCHs, where the PDCCHs are related to MAC commands and data transmission in connected mode. The network node 204 may transmit scheduling or control messages for various purposes such as, e.g., to schedule data transmissions (e.g., PDSCH or PUSCH transmissions), to request status information (e.g., BSR), to provide commands (e.g., TAC), etc. The scheduling or control messages are described herein as falling into either of two categories:

1. Data Transfer-Related (DTR) Scheduling or Control Messages (e.g., DTR PDCCHs): DTR scheduling or control messages are scheduling or control messages (e.g., PDCCHs) related to data transmission or arrival, whereby receiving a DTR scheduling or control message may have a relation to upcoming data. For example, the DTR scheduling or control message may schedule a downlink data transmission (e.g., a PDSCH transmission), request a Channel State Information (CSI) report, etc. The network node 204 may also transmit a DTR scheduling or control message to schedule an uplink data transmission (e.g., a PUSCH transmission). Without losing generality, "DTR" is used herein to refer to all the data transmission related scheduling in both downlink and uplink directions.

2. Non-Data-Transfer-Related (NDTR) Scheduling or Control messages (e.g., NDTR PDCCHs): NDTR scheduling or control messages are scheduling or control messages (e.g., PDCCHs) that are not related to the data transmission or arrival process, whereby receiving the NDTR scheduling or control message is not providing prior information regarding an upcoming data transmission, i.e. it is not an indication of an event in the presumed Poisson data arrival process. Examples of NDTR scheduling or control messages include PDCCH including BSR requests, other MAC commands, etc.

In step 301, the UE 202 operates in cDRX mode (e.g., the existing or conventional cDRX mode) in which the IAT is restarted with the configured IAT duration upon reception of each of the first scheduling or control messages. During operation, the UE 301 collects data about scheduling patterns of the network node 204 in regard to DTR scheduling or control messages and/or NDTR scheduling or control messages. In particular, in one embodiment, the UE 202 determines and stores time intervals from the time of reception of NDTR scheduling or control messages to subsequent DTR scheduling or control messages. For these observations, in one embodiment, the UE 202 further determines and stores any one or more of the following: • NDTR message type of the NDTR scheduling or control message (e.g., MAC CE command type such as, e.g., BSR request MAC CE, Transmission Configuration Indication (TCI) States Activation/ Deactivation for UE-specific PDSCH MAC CE, TCI State Indication for UE-specific PDCCH MAC CE, Timing Advance Command (TAC) MAC CE, etc.);

• if the scheduling or control message includes a MAC command, the UE response to the MAC command (e.g., the buffer size in case of a BSR), where applicable; o e.g., if the scheduling or control message is a BSR request MAC command, the UE stores information that indicates whether the UE reports a 0 BSR indicating the uplink buffer is empty, in which case the UE does not expect an uplink scheduling, or the UE reports a non-zero BSR; in which case the UE expects to an additional PDCCH(s) scheduling an uplink data transmission(s) in relatively short amount of time after receiving the BSR request;

• whether a DTR scheduling or control message is received before the IAT, which was reset in response to reception of a NDTR scheduling or control message, has expired;

• ongoing traffic type, packet or burst arrival rates (e.g., Poisson inter-arrival time), service, active application(s), and/or corresponding QoS in the UE; o E.g., the UE 202 may note that the upcoming traffic is sparse, and the data arrival time is larger than the IAT duration or data IAT duration for example;

• on-going traffic predictions, e.g., if the UE 202 expects to receive a scheduling PDCCH. o E.g., the UE 202 may have requested an uplink scheduling and therefore expect to receive a corresponding scheduling PDCCH in a short amount time; o E.g., the UE 202 expects a downlink transmission to start or go on for a while, e.g., for a scheduled software update or other types of downloads;

• network load, which may be inferred, e.g., from paging rates, PDCCH transmissions to other UEs, or the like.

As described below in detail, the UE 202 obtains (e.g., determines) a transmission pattern(s) of DTR scheduling or control messages and/or NDTR scheduling or control messages, based on (e.g., based on an analysis of) the set of first scheduling or control messages (step 302). Note that the transmission pattern may be a combined pattern for both DTR PDCCHs and NDTR PDCCHs. Alternatively, the transmission pattern may be a pattern of DTR PDCCHs or a pattern of NDTR PDCCHs. In this case, the UE 202 may obtain both a DTR PDCCH transmission pattern and a NDTR PDCCH transmission pattern.

In step 302, the UE 202 uses the information collected in step 301 to determine one or more transmission, or scheduling, patterns of the network node 204 in relation to DTR scheduling or control messages and/or NDTR scheduling or control messages. In one embodiment, the transmission pattern(s) include any one or more of the following:

• Probability of a DTR scheduling or control message arriving within X ms after a NDTR scheduling or control message, where X is, e.g., predefined or configured. In one example, X is equal to the nominal IAT duration, which may be separately defined or configured for different NDTR message types and/or response categories.

• Expected time from a NDTR scheduling or control message to a DTR scheduling or control message. This expected time is, in one embodiment, separately determined for different NDTR message types via a statistical NTDR-to-DTR interval distribution for time values for selected percentiles of the distribution (median, 10%, 5%, 1% etc.)

Any one or more of the above for different traffic scenarios, network loads, etc. In one embodiment, the transmission pattern(s) may be determined using a parameter estimation technique (e.g., averaging observations for different categories) or by training an Artificial Intelligence (Al) or Machine Learning (ML) network. The training of an AI/ML model may include reinforcement learning where, for a given scenario, a predetermined set of criteria are applied, and the decisions are provided as training input. (See examples in the description of step 306.) Thereafter, while operating in cDRX mode and while the IAT is running, the UE 202 receives a second scheduling or control message (e.g., a second PDCCH) (step 304). In step 304, the UE 202 receives the second scheduling or control message. In addition, in some embodiments, if the second scheduling or control message is NDTR scheduling or control message, the UE 202 may further identify the NDTR message type and, in some embodiments, also collect associated parameters mentioned above in the description of step 301.

The UE 202 performs one or more actions related to continued monitoring for an additional scheduling or control message(s) (e.g., restarting the IAT, not restarting the IAT, adjusting the IAT, or the like), based on the obtained transmission pattern(s) from step 302 and the type of scheduling or control message received (i.e., whether the second scheduling or control message is a DTR scheduling or control message or NDTR scheduling or control message) (step 306). In one embodiment, the one or more actions may include determining whether to continue monitoring for an additional scheduling or control message based on the type of the second scheduling or control message and the transmission pattern(s) obtained in step 302 (step 306A-1). In another embodiment, the one or more actions may include determining whether to restart the IAT or refrain from restarting the IAT based on the type of the second scheduling or control message and the transmission pattern(s) (step 306A-2). In another embodiment, the one or more actions may include determining whether to adjust the IAT timer (e.g., restart the IAT timer with an adjusted (e.g., shorter) duration) based on the type of the second scheduling or control message and the transmission pattern(s) (step 306A-3). The one or more actions may then further include operating in accordance with the result of step 306A-1, 306A-2, or 306A-3 (step 306B).

In one specific example of step 306A, if the second scheduling or control message is a NDTR scheduling or control message, the UE 202 may use the NDTR scheduling or control message and the collected parameters (see above) along with the corresponding transmission obtained in step 302 to determine whether to activate (e.g., whether to restart) the IAT and, in some embodiments, the setting (e.g., IAT duration) with which to restart the IAT. The transmission pattern may be applied to reach a decision, e.g. as a Look-Up Table (LUT), or as an inference process based on an AI/ML model trained in 302. Some additional factors may also be used to make the decision. Some examples of decision principles include the following:

• If the mean, median, or selected percentile (e.g., 5%) of the NDTR-to-DTR interval distribution (e.g., for the NDTR message type of the second scheduling or control message, UE response, and/or traffic parameters) exceeds the IAT length, the IAT is not restarted; otherwise, the IAT is restarted with the nominal IAT duration. o In one embodiment, the above action may be taken if a UE energy/power metric (e.g., battery save urgency or thermal urgency) is above a threshold, for example, if the remaining charge in the battery is below a threshold or chip temperature is above a threshold. The threshold(s) may be predefined or configured. o In one embodiment, the above action may be taken if the difference of energy expended due to re-connecting to the network in case a scheduling instance is missed minus energy saved due to skipping the IAT is below a threshold. For example, if the energy cost of reconnecting, including the Random Access Channel (RACH) procedure and Radio Resource Control (RRC) connection establishment, scaled with the probability of missing multiple scheduling instances leading to logical release to by the network is less than the energy saved by skip IAT monitoring, the UE may decide to skip it. o In one embodiment, the above action is taken if the performance cost (e.g., excess latency, reduced transmission power, and/or QoS impact) in case a scheduling instance is missed minus energy saved due to skipping the IAT is below a threshold. The Key Performance Indictor (KPI) degradation may be deemed acceptable if any missed scheduling instance is acceptable, or if such missed scheduling instances occurring during the expected fraction of the time are acceptable. o In one embodiment, the above action is taken only for a subset of traffic scenarios. The action may not be taken for latency- and transmission powersensitive use cases, e.g., Ultra-Reliable Low-Latency Communication (URLLC), Augmented or Virtual Reality (XR), gaming, interactive voice or video, etc. Alternatively, the UE 202 may decide to take the above action if the UE 202 is of a particular type or one of a particular set of UE types (e.g., if the UE 202 is a NR Reduced Capability (RedCap) UE). o In another example, if the UE is additionally configured with one or more Secondary Cells (SCells) and one or more of those SCells are active, the UE 202 may decide to take the above action in one or more of the active SCells and not the Primary Cell (PCell).

• The IAT is set to the smaller of the nominal IAT and a selected percentile (e.g., 5% or 1%) of the NDTR-to-DTR interval distribution. o The percentile value is selected based on the energy or thermal urgency level, the potential energy gains in relation to additional energy expended for reconnection, and/or expected KPI degradation.

Combinations and variations of the above options may be used. Then, in step 306B, the UE 202 operates in accordance with a result of step 306A. In particular, if the UE 202 has decided to restart the IAT, the UE 202 restarts the IAT and proceeds to monitor for an additional scheduling or control message at least for the duration of the IAT. If UE 202 decided not to restart the IAT, the IAT is not restarted (or restarted with duration 0) in response to receiving the second scheduling or control message in step 304, and the UE 202 exits active time and enters cDRX until the next onDuration.

Figure 4 is a flow chart that illustrates steps 304 and 306 of Figure 3 in more detail, in accordance with one example embodiment of the present disclosure. As illustrated, the UE 202 receives the second scheduling or control message (step 304). In step 306A-1, the UE 202 determines whether the second scheduling or control message is a NDTR scheduling or control message (step 400). If so (step 400, YES), the UE 202 determines whether a DTR scheduling or control message is expected (e.g., within a predefined or configured amount of time after receiving the second scheduling or control message), based on the transmission pattern or a corresponding one of the transmission patterns obtained in step 302 (see Figure 3) (step 402). If so (step 402, YES), in step 306B, the UE continues monitoring for an additional scheduling or control message (step 404). This continued monitoring may include, e.g., restarting the IAT timer to the nominal, or configured, IAT timer duration or restarting the IAT timer to an adjusted IAT timer duration, where this adjusted IAT timer duration may be, e.g., a shorter IAT timer duration than the nominal IAT timer duration or a IAT timer duration determined based on the corresponding transmission pattern (e.g., a time duration during which the probability of receiving a subsequent DTR scheduling or control message is above a predefined or configured threshold probability). If, in step 402, the UE 202 determines that a DTR scheduling or control message is not expected (step 402, NO), the UE 202 refrains from continued monitoring for an additional scheduling or control message (step 406). This refraining from continued monitoring may be performed by ceasing monitoring for additional scheduling or control messages even if the IAT time has not expired, refraining from resetting the IAT timer such that the monitoring ceases once the IAT timer has expired, resetting the IAT timer to a duration of 0, or the like. Returning to step 400, if the second scheduling or control message is not a NDTR scheduling or control message (i.e., if the second scheduling or control message is a DTR scheduling or control message), the UE 202 may, for example, restart the IAT with the nominal, or configured, IAT duration (step 408) and continue monitoring, e.g., in the conventional manner.

Figure 5 is a flow chart that illustrates steps 304 and 306 of Figure 3 in more detail, in accordance with another example embodiment of the present disclosure. As illustrated, the UE 202 receives the second scheduling or control message (step 304). In step 306A-1, the UE 202 determines whether the second scheduling or control message is a NDTR scheduling or control message (step 500). If so (step 500, YES), the UE 202 determines whether a DTR scheduling or control message is expected (e.g., within a predefined or configured amount of time after receiving the second scheduling or control message), based on the transmission pattern or a corresponding one of the transmission patterns obtained in step 302 (see Figure 3) (step 502). If so (step 502, YES), in step 306B, the UE restarts the IAT with, e.g., the nominal or configured IAT duration and continues monitoring for an additional scheduling or control message (step 504). If, in step 502, the UE 202 determines that a DTR scheduling or control message is not expected (step 502, NO), the UE 202 refrains from restarting the IAT such that monitoring for additional scheduling or control messages will cease once the IAT timer expires (step 506). Returning to step 500, if the second scheduling or control message is not a NDTR scheduling or control message (i.e., if the second scheduling or control message is a DTR scheduling or control message), the UE 202 may, for example, restart the IAT with the nominal, or configured, IAT duration (step 508) and continue monitoring, e.g., in the conventional manner.

Figure 6 is a flow chart that illustrates steps 304 and 306 of Figure 3 in more detail, in accordance with another example embodiment of the present disclosure. As illustrated, the UE 202 receives the second scheduling or control message (step 304). In step 306A-1, the UE 202 determines whether the second scheduling or control message is a NDTR scheduling or control message (step 600). If so (step 600, YES), the UE 202 estimates a probability that a DTR scheduling or control message will be received within a defined or configured amount of time, based on the transmission pattern or a corresponding one of the transmission patterns obtained in step 302 (see Figure 3) (step 602). Then, in step 306B, the UE 202 adjusts the IAT based on the estimated probability and continues monitoring for an additional scheduling or control message while the IAT is running (step 604). In one example embodiment, the UE 202 adjusts the IAT by restarting the IAT with an IAT duration that is a function of the estimated probability. For example, if the estimated probability is above a threshold, the IAT is restarted to the nominal IAT duration; otherwise, the IAT is restarted to a different IAT duration that is less than the nominal IAT duration. In another embodiment, using the obtained transmission pattern(s), the UE 202 determines a duration of time during which the estimated probability of receiving a DTR scheduling or control message is greater than a threshold probability. This duration of time is preferably less than or equal to the nominal IAT duration. If there is no such duration of time for which the threshold probability is exceeded, the IAT is restarted with a value of 0 (or monitoring is otherwise ceased). However, if there is such a duration of time for which the threshold probability is exceeded, the UE 202 resets the IAT to that duration of time. Returning to step 600, if the second scheduling or control message is not a NDTR scheduling or control message (i.e., if the second scheduling or control message is a DTR scheduling or control message), the UE 202 may, for example, restart the IAT with the nominal, or configured, IAT duration (step 408) and continue monitoring, e.g., in the conventional manner.

In addition to the embodiments above, the UE 202 may apply one or more robustness features. For instance, in one embodiment, the UE 202 may apply the process of Figure 3 only if previous network behavior observations indicate that incorrect decisions (e.g., data being scheduled during the nominal IAT not monitored by the UE 202) would occur less frequently than a threshold, and/or that such decisions have a tolerable KPI impact. Furthermore, if the UE is expected to satisfy a minimum performance metric, e.g., the number of missed PDCCHs, etc., e.g., by standardization documentations, the UE 202 should make sure those requirements are satisfied. Nevertheless, it is desirable to improve the robustness of the solution in instances where such scheduling takes place. In one embodiment, the UE 202 may revert to nominal IAT operation when data scheduling patterns change, new application(s) are activated, etc. The UE 202 may then redo step 301 and 302 of Figure 3 to update the transmission pattern(s) before again applying steps 304 and 306.

The UE 202 may also occasionally revert to nominal IAT operation to repeat steps 301 and 302 to verify the validity of the current transmission pattern(s).

In some situations, the UE 202 may, when it omits or shortens its IAT after an NDTR reception, experience that it has been released by the network without a release command. In this case, in one embodiment, the UE 202 may assume that this was due to missing scheduling during the nominal IAT, and the UE may then revert to conventional operation or adjust decision thresholds described with respect to step 306 to reduce the probability of such instances.

In addition to the above, the UE 202 may also keep the relation with other functionalities by assuming the nominal IAT is running. For example, for the case where the UE 202 is configured with short-DRX, the UE 202 may count the short-DRX cycle timer based on the expiration of the nominal IAT value configured by the network, i.e. to keep the UE 202 aligned with the network during the cDRX cycle.

In another example, the UE 202 may also avoid monitoring PDCCH that should not be monitored during active time (e.g., Downlink Control Information (DCI) 2-6) when the nominal IAT has not yet expired.

In another set of embodiments, the UE 202 may not totally skip the IAT, i.e., the UE 202 may use e.g., two receiver modes, a full receiver, or normal mode, and a power saving mode receiver, which may be implemented via separate hardware or a special configuration of the regular receiver. Under such embodiments, if the UE 202 notes that, according to the conditions disclosed herein, the IAT can be skipped, the UE 202 may decide to turn the normal receiver to the DRX OFF duration mode, e.g., deep sleep, light sleep, etc. (according to the available time), and instead turn on the power saving receiver. The responsibility of the power saving receiver is to monitor PDCCH as long as the IAT is running but at a much lower power consumption with respect to the normal receiver. For example, the power saving receiver may just apply an energy detector (e.g., on PDCCH Demodulation Reference Signal (DM RS)), or other types of detectors to detect a PDCCH. In one embodiment, if a PDCCH (particularly a grantbased PDCCH) is detected, then the power saving receiver can turn ON the normal receiver to decode PDCCH and follow-up the scheduled actions. In another embodiment, the low-power receiver may be sufficient for PDCCH detection but not PDSCH detection. If the UE 202 detects the DTR PDCCH, it may not attempt PDSCH decoding but it may send a NACK and it will activate the full receiver and the start the IAT to process the retransmission and receive the PDSCH in the next transmission. In another set of embodiments, the UE 202 may undertake configured operations that would be performed if the IAT were running although PDCCH is not monitored per step 306, e.g., a CSI measurements, Radio Link Monitoring (RLM)/Beam Failure Detection (BFD) measurements, etc. The UE 202 may also undertake the configured operations using a power saving mode receiver instead of full receiver as in e.g., above. In alternative embodiment, the UE 202 may skip these support functions while it is decided to terminate or skip the IAT.

While the description here focuses on the cDRX IAT, similar principles may be applied to the data IAT. For instance, the UE 202 may return to idle mode, using a previously provided DRX configuration before the nominal data IAT expires using network behavior observations and suitable decision criteria, such as . if a new data transmission is typically much less frequent that the length of the data IAT.

In one embodiment, the UE 202 may apply the obtained transmission pattern(s) only in the current cell in which case the UE 202 obtains new transmission pattern(s) after each cell change. In another embodiment, the UE 202 may apply the obtained transmission pattern(s) only in a part of the network (i.e., in a set of cells) where cells exhibit similar behavior.

Similar embodiments may be applied for a UE to learn the distribution of the time gap between two DTRs so that the UE can omit or shorten the IAT when the time gap is larger than the nominal IAT, e.g. if the UE is receiving strictly periodic traffic with period longer than the configured IAT.

Similar embodiments may be applied for a UE to learn the distribution of the time gap between two NDTRs so that the UE can omit or shorten IAT when the time gap is reliably larger than the nominal IAT.

In one embodiment, the network (e.g., the network node 204) may check whether the UE 202 is employing the procedure of Figure 3 by, one or more times, attempting data transmission during the nominal IAT after a NDTR transmission. If no Acknowledgement (ACK) /Negative ACK (NACK) feedback is received, the network may attempt re-transmitting in the next OnDuration. If the second attempt(s) are successful, the network may modify the scheduling principle to delay data scheduling transmission until the next onDuration for non-latency-sensitive traffic.

Figure 7 illustrates one example of a cellular communications system 700 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 700 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, the present disclosure is not limited thereto. Embodiments of the present disclosure may be applied in other types of wireless networks (e.g., 4^th Generation (4G) or 6G network or beyond) that utilize cDRX or an analogous feature. In this example, the RAN includes base stations 702-1 and 702-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 704-1 and 704-2. The base stations 702- 1 and 702-2 are generally referred to herein collectively as base stations 702 and individually as base station 702. Likewise, the (macro) cells 704-1 and 704-2 are generally referred to herein collectively as (macro) cells 704 and individually as (macro) cell 704. The RAN may also include a number of low power nodes 706-1 through 706-4 controlling corresponding small cells 708-1 through 708-4. The low power nodes 706-1 through 706-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 708-1 through 708-4 may alternatively be provided by the base stations 702. The low power nodes 706-1 through 706-4 are generally referred to herein collectively as low power nodes 706 and individually as low power node 706. Likewise, the small cells 708-1 through 708-4 are generally referred to herein collectively as small cells 708 and individually as small cell 708. The cellular communications system 700 also includes a core network 710, which in the 5G System (5GS) is referred to as the 5GC. The base stations 702 (and optionally the low power nodes 706) are connected to the core network 710.

The base stations 702 and the low power nodes 706 provide service to UEs 712-1 through 712-5 in the corresponding cells 704 and 708. The UEs 712-1 through 712-5 are generally referred to herein collectively as UEs 712 and individually as UE 712. Note that, in one example embodiment, the UE 202 of Figure 2 corresponds to one of the UEs 712, and the network node 204 of Figure 2 corresponds to one of the base stations 702. Figure 8 is a schematic block diagram of a network node 800 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 800 may be, for example, a base station 702 or 706 or a network node that implements all or part of the functionality of the base station 702 or gNB described herein. In one example, the network node 800 corresponds to the network node 204 of Figure 2.

As illustrated, the network node 800 includes a control system 802 that includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. In addition, if the network node 800 is a radio access node (e.g., a base station 702, gNB, or network node that implements at least some of the functionality of the base station 702 or gNB), the network node 800 may include one or more radio units 810 that each includes one or more transmitters 812 and one or more receivers 814 coupled to one or more antennas 816. The radio units 810 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 810 is external to the control system 802 and connected to the control system 802 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 810 and potentially the antenna(s) 816 are integrated together with the control system 802. The one or more processors 804 operate to provide one or more functions of the network node 800 as described herein (e.g., one or more functions of a base station 702 or gNB described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804. Figure 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes. As used herein, a "virtualized" network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, if the network node 800 is a radio access node, the network node 800 may include the control system 802 and/or the one or more radio units 810, as described above. The control system 802 may be connected to the radio unit(s) 810 via, for example, an optical cable or the like. The network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902. If present, the control system 802 or the radio unit(s) are connected to the processing node(s) 900 via the network 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908.

In this example, functions 910 of the network node 800 described herein (e.g., one or more functions of a base station 702 or gNB described herein) are implemented at the one or more processing nodes 900 or distributed across the one or more processing nodes 900 and the control system 802 and/or the radio unit(s) 810 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network node 800 described herein may be implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 900 and the control system 802 may be used in order to carry out at least some of the desired functions 910. Notably, in some embodiments, the control system 802 may not be included, in which case the radio unit(s) 810 may communicate directly with the processing node(s) 900 via an appropriate network interface(s).

In some embodiments, a computer program may including instructions which, when executed by at least one processor, cause the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product may be provided. The carrier may be one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 10 is a schematic block diagram of the network node 800 according to some other embodiments of the present disclosure. The network node 800 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the network node 800 described herein. This discussion is equally applicable to the processing node 900 of Figure 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900 and/or distributed across the processing node(s) 900 and the control system 802.

Figure 11 is a schematic block diagram of a UE 712 (e.g., the UE 202 of Figure 2) according to some embodiments of the present disclosure. As illustrated, the UE 712 includes one or more processors 1102 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1104, and one or more transceivers 1106 each including one or more transmitters 1108 and one or more receivers 1110 coupled to one or more antennas 1112. The transceiver(s) 1106 includes radio-front end circuitry connected to the antenna(s) 1112 that is configured to condition signals communicated between the antenna(s) 1112 and the processor(s) 1102, as will be appreciated by one of ordinary skill in the art. The processors 1102 are also referred to herein as processing circuitry. The transceivers 1106 are also referred to herein as radio circuitry. In some embodiments, the functionality of the UE 712 described above may be fully or partially implemented in software that is, e.g., stored in the memory 1104 and executed by the processor(s) 1102. Note that the UE 712 may include additional components not illustrated in Figure 11 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the UE 712 and/or allowing output of information from the UE 712), a power supply (e.g., a battery and associated power circuitry), etc.

In some embodiments, a computer program is provided whichmay include instructions which, when executed by at least one processor, cause the at least one processor to carry out the functionality of the UE 712 according to any of the embodiments described herein. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 12 is a schematic block diagram of the UE 712 according to some other embodiments of the present disclosure. The UE 712 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of the UE 712 described herein. With reference to Figure 13, in accordance with an embodiment, a communication system includes a telecommunication network 1300, such as a 3GPP-type cellular network, which comprises an access network 1302, such as a RAN, and a core network 1304. The access network 1302 comprises a plurality of base stations 1306A, 1306B, 1306C, such as Node Bs, eNBs, gNBs, or other types of wireless Access Points (APs), each defining a corresponding coverage area 1308A, 1308B, 1308C. Each base station 1306A, 1306B, 1306C is connectable to the core network 1304 over a wired or wireless connection 1310. A first UE 1312 located in coverage area 1308C is configured to wirelessly connect to, or be paged by, the corresponding base station 1306C. A second UE 1314 in coverage area 1308A is wirelessly connectable to the corresponding base station 1306A. While a plurality of UEs 1312, 1314 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1306. The telecommunication network 1300 is itself connected to a host computer 1316, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server, or as processing resources in a server farm. The host computer 1316 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. Connections 1318 and 1320 between the telecommunication network 1300 and the host computer 1316 may extend directly from the core network 1304 to the host computer 1316 or may go via an optional intermediate network 1322. The intermediate network 1322 may be one of, or a combination of more than one of, a public, private, or hosted network; the intermediate network 1322, if any, may be a backbone network or the Internet; in particular, the intermediate network 1322 may comprise two or more sub-networks (not shown).

The communication system of Figure 13 as a whole enables connectivity between the connected UEs 1312, 1314 and the host computer 1316. The connectivity may be described as an Over-the-Top (OTT) connection 1324. The host computer 1316 and the connected UEs 1312, 1314 are configured to communicate data and/or signaling via the OTT connection 1324, using the access network 1302, the core network 1304, any intermediate network 1322, and possible further infrastructure (not shown) as intermediaries. The OTT connection 1324 may be transparent in the sense that the participating communication devices through which the OTT connection 1324 passes are unaware of routing of uplink and downlink communications. For example, the base station 1306 may not or need not be informed about the past routing of an incoming downlink communication with data originating from the host computer 1316 to be forwarded (e.g., handed over) to a connected UE 1312. Similarly, the base station 1306 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1312 towards the host computer 1316.

Example implementations, in accordance with an embodiment, of the UE, base station, and host computer discussed in the preceding paragraphs will now be described with reference to Figure 14. In a communication system 1400, a host computer 1402 comprises hardware 1404 including a communication interface 1406 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1400. The host computer 1402 further comprises processing circuitry 1408, which may have storage and/or processing capabilities. In particular, the processing circuitry 1408 may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The host computer 1402 further comprises software 1410, which is stored in or accessible by the host computer 1402 and executable by the processing circuitry 1408. The software 1410 includes a host application 1412. The host application 1412 may be operable to provide a service to a remote user, such as a UE 1414 connecting via an OTT connection 1416 terminating at the UE 1414 and the host computer 1402. In providing the service to the remote user, the host application 1412 may provide user data which is transmitted using the OTT connection 1416. The communication system 1400 further includes a base station 1418 provided in a telecommunication system and comprising hardware 1420 enabling it to communicate with the host computer 1402 and with the UE 1414. The hardware 1420 may include a communication interface 1422 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1400, as well as a radio interface 1424 for setting up and maintaining at least a wireless connection 1426 with the UE 1414 located in a coverage area (not shown in Figure 14) served by the base station 1418. The communication interface 1422 may be configured to facilitate a connection 1428 to the host computer 1402. The connection 1428 may be direct or it may pass through a core network (not shown in Figure 14) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 1420 of the base station 1418 may further include processing circuitry 1430, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The base station 1418 further has software 1432 stored internally or accessible via an external connection.

The communication system 1400 further includes the UE 1414 already referred to. The UE's 1414 hardware 1434 may include a radio interface 1436 configured to set up and maintain a wireless connection 1426 with a base station serving a coverage area in which the UE 1414 is currently located. The hardware 1434 of the UE 1414 further includes processing circuitry 1438, which may comprise one or more programmable processors, ASICs, FPGAs, or combinations of these (not shown) adapted to execute instructions. The UE 1414 further comprises software 1440, which is stored in or accessible by the UE 1414 and executable by the processing circuitry 1438. The software 1440 includes a client application 1442. The client application 1442 may be operable to provide a service to a human or non-human user via the UE 1414, with the support of the host computer 1402. In the host computer 1402, the executing host application 1412 may communicate with the executing client application 1442 via the OTT connection 1416 terminating at the UE 1414 and the host computer 1402. In providing the service to the user, the client application 1442 may receive request data from the host application 1412 and provide user data in response to the request data. The OTT connection 1416 may transfer both the request data and the user data. The client application 1442 may interact with the user to generate the user data that it provides.

It is noted that the host computer 1402, the base station 1418, and the UE 1414 illustrated in Figure 14 may be similar or identical to the host computer 1316, one of the base stations 1306A, 1306B, 1306C, and one of the UEs 1312, 1314 of Figure 13, respectively. This is to say, the inner workings of these entities may be as shown in Figure 14 and independently, the surrounding network topology may be that of Figure 13.

In Figure 14, the OTT connection 1416 has been drawn abstractly to illustrate the communication between the host computer 1402 and the UE 1414 via the base station 1418 without explicit reference to any intermediary devices and the precise routing of messages via these devices. The network infrastructure may determine the routing, which may be configured to hide from the UE 1414 or from the service provider operating the host computer 1402, or both. While the OTT connection 1416 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 1426 between the UE 1414 and the base station 1418 is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to the UE 1414 using the OTT connection 1416, in which the wireless connection 1426 forms the last segment. More precisely, the teachings of these embodiments may reduce power consumption and thereby provide benefits such as extended battery lifetime.

A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 1416 between the host computer 1402 and the UE 1414, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 1416 may be implemented in the software 1410 and the hardware 1404 of the host computer 1402 or in the software 1440 and the hardware 1434 of the UE 1414, or both. In some embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1416 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which the software 1410, 1440 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 1416 may include message format, retransmission settings, preferred routing, etc.; the reconfiguring need not affect the base station 1418, and it may be unknown or imperceptible to the base station 1418. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer's 1402 measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software 1410 and 1440 causes messages to be transmitted, in particular empty or 'dummy' messages, using the OTT connection 1416 while it monitors propagation times, errors, etc. Figure 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 15 will be included in this section. In step 1500, the host computer provides user data. In sub-step 1502 (which may be optional) of step 1500, the host computer provides the user data by executing a host application. In step 1504, the host computer initiates a transmission carrying the user data to the UE. In step 1506 (which may be optional), the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1508 (which may also be optional), the UE executes a client application associated with the host application executed by the host computer.

Figure 16 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 16 will be included in this section. In step 1600 of the method, the host computer provides user data. In an optional sub-step (not shown) the host computer provides the user data by executing a host application. In step 1602, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1604 (which may be optional), the UE receives the user data carried in the transmission.

Figure 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 17 will be included in this section. In step 1700 (which may be optional), the UE receives input data provided by the host computer. Additionally or alternatively, in step 1702, the UE provides user data. In sub-step 1704 (which may be optional) of step 1700, the UE provides the user data by executing a client application. In sub-step 1706 (which may be optional) of step 1702, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in sub-step 1708 (which may be optional), transmission of the user data to the host computer. In step 1710 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Figure 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station, and a UE which may be those described with reference to Figures 13 and 14. For simplicity of the present disclosure, only drawing references to Figure 18 will be included in this section. In step 1800 (which may be optional), in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In step 1802 (which may be optional), the base station initiates transmission of the received user data to the host computer. In step 1804 (which may be optional), the host computer receives the user data carried in the transmission initiated by the base station.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure. While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

1. A method performed by a User Equipment, UE, in a wireless communications system, the method comprising: receiving (301) a plurality of first scheduling or control messages from one or more network nodes; obtaining (302) a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based on the plurality of first scheduling or control messages; during an active state of a connected-mode Discontinuous Reception, cDRX, mode of operation: receiving (304) a second scheduling or control message from a network node while an inactivity timer is running; and performing (306) one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message.

2. The method of claim 1 wherein performing (306) the one or more actions comprises: deciding (306A-1; 400-402) to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running based on the second scheduling or control message being a non-data transmission related scheduling or control message and the transmission pattern being indicative of a data transmission related scheduling or control message not being expected; and refraining (306B; 406) from monitoring for an additional scheduling or control message while the inactivity timer is running..

3. The method of claim 2 wherein deciding (306A-1) to refrain from monitoring for an additional scheduling or control message is further based on an energy or power consumption status of the UE, a Quality of Service, QoS, desired for data transmissions to or from the UE, or both.

4. The method of claim 1 wherein performing (306) the one or more actions comprises: deciding (306A-1; 400-402) to continue monitoring for an additional scheduling or control message while the inactivity timer is running in response to the second scheduling or control message being a non-data transmission related scheduling or control message and the transmission pattern being indicative of a data transmission related scheduling or control message being expected; and continuing (306B; 406) to monitor for an additional scheduling or control message while the inactivity timer is running.

5. The method of claim 4 wherein deciding (306A-1) to refrain from monitoring for an additional scheduling or control message while the inactivity timer is running is further based on an energy or power consumption status of the UE, a Quality of Service, QoS, desired for data transmissions to or from the UE, or both.

6. The method of claim 1 wherein performing (306) the one or more actions comprise: determining (400, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; determining (402) that a data-related scheduling or control message is expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and continuing (404) to monitor for an additional scheduling or control message while the inactivity timer is running in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and that a data-related scheduling or control message is expected within the determined or configured amount of time.

7. The method of claim 1 wherein performing (306) the one or more actions comprise: determining (400, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; determining (402) that a data-related scheduling or control message is not expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and refraining (406) from monitoring for an additional scheduling or control message while the inactivity timer is running in response to determining that the second scheduling or control message a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is not expected within the determined or configured amount of time.

8. The method of claim 1 wherein performing (306) the one or more actions comprises: deciding (306A, 500-502) to restart the inactivity timer in response to the second scheduling or control message being a data transmission related scheduling or control message; and restarting (306B; 504) the inactivity timer, in accordance with deciding to restart the inactivity timer.

9. The method of claim 8 wherein deciding to restart the inactivity timer is further based on an energy or power consumption status of the UE, a Quality of Service, QoS, desired for data transmissions to or from the UE, or both.

10. The method of claim 1 wherein performing (306) the one or more actions comprises: deciding (306A, 500-502) to refrain from restarting the inactivity timer in response to the second scheduling or control message being a non-data transmission related scheduling or control message; and refraining (306B; 506) from restarting the inactivity timer, in accordance with deciding to refrain from restarting the inactivity timer.

11. The method of claim 1 wherein performing (306) the one or more actions comprise: determining (500, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; determining (502, YES) that a data-related scheduling or control message is expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and restarting (504) the inactivity timer in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is expected within the determined or configured amount of time.

12. The method of claim 1 wherein performing (306) the one or more actions comprise: determining (500, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; determining (502, NO) that a data-related scheduling or control message is not expected within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and refraining (506) from restarting the inactivity timer in response to determining that the second scheduling or control message is a non-data transmission related scheduling or control message and determining that a data-related scheduling or control message is not expected within the determined or configured amount of time.

13. The method of claim 1 wherein performing (306) the one or more actions comprises: deciding (306A-3; 600-602) to adjust the inactivity timer in response to the second scheduling or control message being a non-data transmission related scheduling or control message; and adjusting (306B; 602-604) the inactivity timer, in accordance with deciding to adjust the inactivity timer.

14. The method of claim 13 wherein deciding (306A-3) to adjust the inactivity timer is further based on an energy or power consumption status of the UE, a Quality of Service, QoS, desired for data transmissions to or from the UE, or both.

15. The method of claim 1 wherein performing (306) the one or more actions comprises: determining (600, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; estimating (602) a probability that a data-related scheduling or control message will occur within an amount of time after receiving the second scheduling or control message, based on the transmission pattern; and responsive to the second scheduling or control message being a non-data transmission related scheduling or control message, adjusting the inactivity timer or not, based on the estimated probability.

16. The method of claim 1 wherein performing (306) the one or more actions comprises: determining (600, YES) that the second scheduling or control message is a nondata transmission related scheduling or control message; estimating (602) a probability that a data-related scheduling or control message will occur within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and responsive to the second scheduling or control message being a non-data transmission related scheduling or control message: restarting (604) the inactivity timer in response to the estimated probability of a data-related scheduling or control message within the determined or configured amount of time being greater than a threshold.

17. The method of claim 1 wherein performing (306) the one or more actions comprises: determining (600, YES) that the second scheduling or control message is a non- data transmission related scheduling or control message; estimating (602) a probability that a data-related scheduling or control message will occur within a determined or configured amount of time after receiving the second scheduling or control message, based on the transmission pattern; and responsive to the second scheduling or control message being a non-data transmission related scheduling or control message: increasing (604) the inactivity timer to a predetermined, configured, or determined value that is less than a configured starting value of the inactivity timer in response to the estimated probability of a data-related scheduling or control message within the determined or configured amount of time is less than a threshold.

18. A User Equipment, UE, (712; 1100) for a wireless communications system, the UE (712; 1100) adapted to perform the method of any of claims 1 to 17.

19. A User Equipment, UE, (712; 1100) for a wireless communications system (700), the UE (712; 1100) comprising: one or more receivers (1110); and processing circuitry (1102) associated with the one or more receivers (1110), the processing circuitry (1102) configured to cause the UE (712; 1100) to: receive (301) a plurality of first scheduling or control messages from one or more network nodes; obtain (302) a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based on the plurality of first scheduling or control messages; during an active state of a connected-mode Discontinuous Reception, cDRX, mode of operation: receive (304) a second scheduling or control message from a network node while an inactivity timer is running; and perform (306) one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message.

20. The UE (712; 1100) of claim 19 wherein the processing circuitry (502) is further configured to cause the UE (712; 1100) to perform the method of any of claims 2 to 17.

21. A computer program comprising instructions which, when executed on at least one processor, cause the processor to carry out the method according to any of claims 1 to 17.

22. A carrier containing the computer program of claim 21, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium.

23. A non-transitory computer-readable medium comprising instructions executable by processing circuitry of a User Equipment, UE, whereby the UE is operable to: receive (301) a plurality of first scheduling or control messages from one or more network nodes; obtain (302) a transmission pattern for data transmission related scheduling or control messages and/or non-data transmission related scheduling or control messages, based on the plurality of first scheduling or control messages; during an active state of a connected-mode Discontinuous Reception, cDRX, mode of operation: receive (304) a second scheduling or control message from a network node while an inactivity timer is running; and perform (306) one or more actions related to continued monitoring for an additional scheduling or control message, based on the transmission pattern and whether the second scheduling or control message is a data transmission related scheduling or control message or a non-data transmission related scheduling or control message.