Method and apparatus for UE temperature management

Abstract

A method of a user equipment (UE) is disclosed. The method comprises: detecting a service type of a current activity at a UE based on a traffic history of the UE; determining a UE state and sensor information; determining a current communication configuration for the UE; predicting a risk of UE overheating based on the service type, the UE status and the sensor information, and the current communication configuration; and identifying a communication configuration suggested for use by the UE based on the predicted risk of UE overheating; and transmitting information indicating the identified communication configuration to a base station (BS).

Description

Technical Field

[0001] The present disclosure relates generally to wireless networks and more particularly to traffic-aware UE temperature management. Background Art

[0002] The demand for wireless data traffic is growing rapidly as smartphones and other mobile data devices (e.g., tablets, "notebook" computers, netbooks, e-book readers, and machine-like devices) become increasingly popular among consumers and enterprises. In order to meet the high growth in mobile data traffic and support new applications and deployments, improving radio interface efficiency and coverage is critical.

[0003] Fifth Generation (5G) or New Radio (NR) mobile communications have been gaining momentum recently, with global technical activities on various candidate technologies from industry and academia. Candidate enablers for 5G / NR mobile communications include: massive antenna technology from traditional cellular bands to high frequencies to provide beamforming gain and support increased capacity, new waveforms (e.g., new radio access technologies (RATs)) that can flexibly adapt to various services / applications with different requirements, new multiple access schemes to support massive connectivity, etc. Summary of the invention

[0004] [Solution to the problem]

[0005] The present disclosure provides an apparatus and method for traffic-aware UE temperature management.

[0006] In an embodiment, a method of a user equipment (UE) is provided. The method may include: determining a UE state and sensor information. The method may include: determining a current communication configuration for the UE. The method may include: predicting a risk of UE overheating based on a service type, UE state and sensor information, and a current communication configuration. The method may include: identifying a communication configuration recommended for the UE based on the predicted risk of UE overheating. The method may include: sending information indicating the identified communication configuration to a base station (BS).

[0007] Predicting the risk of UE overheating may include determining whether the service type is real-time or non-real-time. Predicting the risk of UE overheating may include determining whether the current temperature of the UE is greater than a start threshold associated with the determined service type. Identifying a communication configuration recommended for the UE to use may include determining a new communication configuration based on parameters associated with the determined service type if the current temperature of the UE is greater than or equal to the start threshold associated with the determined service type. Identifying a communication configuration recommended for the UE to use may include determining a new communication configuration based on parameters configured by the base station if the current temperature of the UE is less than the start threshold associated with the determined service type.

[0008] Predicting the risk of UE overheating may include determining whether the service type is real-time or non-real-time. Predicting the risk of UE overheating may include predicting the future temperature of the UE. Predicting the risk of UE overheating may include determining whether the future temperature of the UE is greater than a start threshold associated with the determined service type. If the future temperature of the UE is greater than or equal to the start threshold associated with the determined service type, identifying the communication configuration recommended for the UE to use may include determining the communication configuration based on parameters associated with the determined service type. If the future temperature of the UE is less than the start threshold associated with the determined service type, identifying the communication configuration recommended for the UE to use may include determining the communication configuration based on parameters configured by the base station.

[0009] Predicting the future temperature of the UE may include selecting a time series model based on the determined service type. Predicting the future temperature of the UE may include predicting the future temperature of the UE based on the selected time series model.

[0010] Predicting the risk of overheating of the UE may include determining whether the current traffic of the UE includes substantial new radio (NR) activity. Predicting the risk of overheating of the UE may include determining the relationship between the current temperature of the UE and the optimal temperature if the current traffic of the UE includes substantial NR activity. Identifying the communication configuration recommended for use by the UE may include determining the communication configuration based on parameters associated with index i+1 if the relationship between the current temperatures of the UE is greater than the optimal temperature plus a threshold temperature, where i is the current index. Identifying the communication configuration recommended for use by the UE may include determining the communication configuration based on parameters associated with index i-1 if the relationship between the current temperatures of the UE is less than the optimal temperature minus the threshold temperature.

[0011] The method may include receiving an acknowledgment (ACK) corresponding to the communication configuration from the BS. If the ACK is received from the BS within a first predetermined period, the UE may operate based on the communication configuration within a second predetermined period. If the ACK is not received from the BS within the first predetermined period, the UE may resend information indicating the new communication configuration to the BS.

[0012] The identified communication configuration may include a plurality of power saving parameters.The method may include receiving, from the BS, a communication configuration including a plurality of bandwidth portions corresponding to the power saving parameters.

[0013] If the UE does not receive a response from the BS regarding the proposed new communication configuration, the UE may fall back to a Long Term Evolution (LTE) mode of operation.

[0014] The method may include determining whether a temperature change of the UE within a time window is higher than a threshold. The method may include determining whether the UE is performing temperature forecasting and RF parameter prediction. The method may include performing temperature forecasting and RF parameter prediction if the temperature change is higher than a threshold and the UE is not performing temperature forecasting and RF parameter prediction. The method may include stopping performing temperature forecasting and RF parameter prediction if the temperature change is not higher than a threshold and the UE is performing temperature forecasting and RF parameter prediction.

[0015] The method may include: determining whether a temperature change of the UE within a time window is higher than a threshold. The method may include: if the temperature change is higher than the threshold, reducing a period for predicting a risk of overheating of the UE. The method may include: if the temperature change is not higher than the threshold, increasing a period for predicting a risk of overheating of the UE.

[0016] In an embodiment, a user equipment (UE) is provided. The UE includes a memory storing instructions, and a processor operably coupled to the memory. When the processor executes the instructions, the processor causes the UE to perform an operation. The operation may include: determining the UE state and sensor information. The operation may include: determining the current communication configuration of the UE. The operation may include: predicting the risk of UE overheating based on the service type, the UE state and sensor information, and the current communication configuration. The operation may include: identifying a communication configuration recommended for the UE to use based on the predicted risk of UE overheating. The operation may include: sending information indicating the identified communication configuration to a base station (BS).

[0017] In an embodiment, a method of a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores instructions that, when executed by a processor of a user equipment (UE), cause the UE to perform an operation. The operation may include: determining a UE state and sensor information. The operation may include: determining a current communication configuration of the UE. The operation may include: predicting a risk of UE overheating based on a service type, UE state and sensor information, and a current communication configuration. The operation may include: identifying a communication configuration recommended for the UE to use based on the predicted risk of UE overheating. The operation may include: sending information indicating the identified communication configuration to a base station (BS). BRIEF DESCRIPTION OF THE DRAWINGS

[0018] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description in conjunction with the accompanying drawings, in which:

[0019] Figure 1 An example wireless network according to an embodiment of the present disclosure is shown;

[0020] Figure 2 An example gNB according to an embodiment of the present disclosure is shown;

[0021] Figure 3 An example UE according to an embodiment of the present disclosure is shown;

[0022] Figure 4 A block diagram illustrating an example procedure 400 for traffic-aware UE temperature management according to an embodiment of the present disclosure is shown;

[0023] Figure 5 A method for predicting and selecting based on current temperature according to an embodiment of the present disclosure is shown;

[0024] Figure 6 A method for predicting future temperature according to an embodiment of the present disclosure is shown;

[0025] Figure 7 A method for predicting future temperature according to an embodiment of the present disclosure is shown;

[0026] Figure 8 A method for predicting and selecting based on predicted future temperatures according to an embodiment of the present disclosure is shown;

[0027] Fig. 9 A method for predicting and selecting based on desired temperature according to an embodiment of the present disclosure is shown;

[0028] Fig.10 A method for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown;

[0029] Fig.11 A method for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown;

[0030] Fig.12 and Fig.13 A method for configuring a UE using different temperature management parameters according to an embodiment of the present disclosure is shown;

[0031] Fig.14 A method for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown;

[0032] Fig.15 A method for performing gating according to an embodiment of the present disclosure is shown;

[0033] Fig.16 A method for adjusting a prediction period according to an embodiment of the present disclosure is shown; and

[0034] Fig.17 A method for traffic-aware UE temperature management according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0035] Before the detailed description below, it may be advantageous to elaborate on the definitions of specific words and phrases used in the entire patent document.The term "coupling" and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are in physical contact with each other.The terms "send", "receive" and "communication" and their derivatives include both direct communication and indirect communication.The terms "include" and "include" and their derivatives represent inclusion without limitation.The term "or" is inclusive, representing and / or.The phrase "associated with..." and its derivatives represent including, included, interconnected with..., including, included, connected to or connected with..., coupled to or coupled with..., can communicate with..., collaborate with..., interweave, juxtapose, approach..., be bound to... or bound with..., have, have the property of..., have to... or have to... or have to... The relationship of... or the relationship of... etc.The term "controller" represents any device, system or part thereof that controls at least one operation.Such a controller can be implemented with hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, whether local or remote. The phrase "at least one of..." when used with a list of items means that different combinations of one or more of the listed items may be used, and only one of the items in the list may be required. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C.

[0036] In addition, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed by a computer-readable program code and implemented in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, related data or parts thereof suitable for implementation in appropriate computer-readable program codes. The phrase "computer-readable program code" includes any type of computer code including source code, object code and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as a read-only memory (ROM), a random access memory (RAM), a hard drive, a compact disk (CD), a digital video disk (DVD), or any other type of memory. "Non-transitory" computer-readable media does not include wired, wireless, optical or other communication links that transmit temporary electrical signals or other signals. Non-transitory computer-readable media include media in which data can be permanently stored, and media in which data can be stored and subsequently rewritten (e.g., rewritable optical disks or erasable storage devices).

[0037] Definitions for certain other words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

[0038] The following discussion Figures 1 to 17 The various embodiments used to describe the principles of the disclosure in this patent document are merely illustrative and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will appreciate that the principles of the disclosure can be implemented in any appropriately arranged wireless communication system.

[0039] In order to meet the increasing demand for wireless data traffic since the deployment of 4G communication systems and to realize various vertical applications, 5G / NR communication systems have been developed and are being deployed. 5G / NR communication systems are considered to be implemented in higher frequency bands (millimeter wave bands) (e.g., 28 GHz or 60 GHz bands) to achieve higher data rates, or in lower frequency bands (e.g., 6 GHz) to achieve robust coverage and mobility support. In order to reduce the propagation loss of radio waves and increase the transmission distance, beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and massive antenna technology are discussed in 5G / NR communication systems.

[0040] In addition, in 5G / NR communication systems, development is underway for system network improvements based on advanced small cells, cloud radio access networks (RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, mobile networks, cooperative communications, coordinated multi-point (CoMP), and receiving-side interference cancellation.

[0041] Since certain embodiments of the present disclosure may be implemented in a 5G system, the discussion of the 5G system and the frequency bands associated therewith is provided for reference. However, the present disclosure is not limited to the 5G system or the frequency bands associated therewith, and embodiments of the present disclosure may be used in conjunction with any frequency band. For example, aspects of the present disclosure may also be applied to 5G communication systems, 6G, or even higher versions of deployments that may use terahertz (THz) frequency bands.

[0042] The following Figure 1-Figure 3 Various embodiments are described for implementing and using Orthogonal Frequency Division Multiplexing (OFDM) or Orthogonal Frequency Division Multiple Access (OFDMA) communication techniques in a wireless communication system. Figure 1-Figure 3 The description does not imply physical or architectural limitations to the manner in which different embodiments may be implemented. Different embodiments of the present disclosure may be implemented in any suitably arranged communications system.

[0043] Figure 1An example wireless network according to an embodiment of the present disclosure is shown. Figure 1 The embodiment of the wireless network shown is for illustration only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

[0044] like Figure 1 As shown, the wireless network includes gNB 101 (e.g., base station, BS), gNB 102, and gNB 103. gNB 101 communicates with gNB 102 and gNB 103. gNB 101 also communicates with at least one network 130 (e.g., the Internet, a proprietary Internet Protocol (IP) network, or other data network).

[0045] gNB 102 provides wireless broadband access to network 130 for a first plurality of user equipment (UE) within coverage area 120 of gNB 102. The first plurality of UEs includes UE 111, which may be located in a small business; UE 112, which may be located in an enterprise; UE 113, which may be a WiFi hotspot; UE 114, which may be located in a first residence; UE 115, which may be located in a second residence; and UE 116, which may be a mobile device (e.g., a cell phone, a wireless laptop, a wireless PDA, etc.). gNB 103 provides wireless broadband access to network 130 for a second plurality of UEs within coverage area 125 of gNB 103. The second plurality of UEs includes UE 115 and UE 116. In some embodiments, one or more of gNBs 101-103 may communicate with each other and with UEs 111-116 using 5G / NR, Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A), WiMAX, WiFi, or other wireless communication technologies.

[0046] Depending on the network type, the term "base station" or "BS" may refer to any component (or collection of components) configured to provide wireless access to a network (e.g., a transmission point (TP), a transmit-receive point (TRP), an enhanced base station (eNodeB or eNB), a 5G / NR base station (gNB), a macro cell, a micro cell, a WiFi access point (AP), or other wirelessly enabled devices). A base station may provide wireless access according to one or more wireless communication protocols (e.g., 5G / NR Third Generation Partnership Project (3GPP) NR, Long Term Evolution (LTE), Advanced LTE (LTE-A), High Speed ​​Packet Access (HSPA), Wi-Fi 802.11a / b / g / n / ac, etc.). For convenience, the terms "BS" and "TRP" are used interchangeably in this patent document to refer to network infrastructure components that provide wireless access to remote terminals. In addition, depending on the network type, the term "user equipment" or "UE" may refer to any component such as a "mobile station", "subscriber station", "remote terminal", "wireless terminal", "reception point" or "user equipment". For convenience, the terms "user equipment" and "UE" are used in this patent document to refer to a remote wireless device that wirelessly accesses a BS, whether the UE is a mobile device (e.g., a mobile phone or smartphone) or a device that is generally considered to be a fixed device (e.g., a desktop computer or a vending machine).

[0047] The dashed lines illustrate the approximate extents of coverage areas 120 and 125, which are shown as approximately circular for illustration and explanation purposes only. It should be clearly understood that the coverage areas associated with a gNB (e.g., coverage areas 120 and 125) may have other shapes, including irregular shapes, depending on the configuration of the gNB and changes in the radio environment associated with natural and man-made obstacles.

[0048] As described in more detail below, one or more of the UEs 111-116 include circuitry, programming, or a combination thereof for traffic-aware UE thermal management. In certain embodiments, one or more of the gNBs 101-103 include circuitry, programming, or a combination thereof to support traffic-aware UE thermal management in a wireless communication system.

[0049] although Figure 1 An example of a wireless network is shown, but Figure 1Various changes may be made. For example, the wireless network may include any number of gNBs and any number of UEs in any suitable arrangement. In addition, gNB 101 may communicate directly with any number of UEs and provide wireless broadband access to network 130 for these UEs. Similarly, each gNB 102-103 may communicate directly with network 130 and provide direct wireless broadband access to network 130 for the UEs. In addition, gNBs 101, 102, and / or 103 may provide access to other or additional external networks (e.g., an external telephone network or other type of data network).

[0050] Figure 2 An example gNB 102 is shown according to an embodiment of the present disclosure. Figure 2 The embodiment of gNB 102 shown is for illustration only, and Figure 1 gNBs 101 and 103 may have the same or similar configurations. However, gNBs have a variety of configurations, and Figure 2 The scope of the present disclosure is not limited to any particular implementation of the gNB.

[0051] like Figure 2 As shown, the gNB 102 includes multiple antennas 205a-205n, multiple transceivers 210a-210n, a controller / processor 225, a memory 230, and a backhaul or network interface 235.

[0052] The transceivers 210a-210n receive incoming RF signals (e.g., signals transmitted by UEs in the network 100) from the antennas 205a-205n. The transceivers 210a-210n downconvert the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are processed by receive (RX) processing circuits in the transceivers 210a-210n and / or the controller / processor 225 (by filtering, decoding, and / or digitizing the baseband or IF signals to generate processed baseband signals). The controller / processor 225 may further process the baseband signals.

[0053] The transmit (TX) processing circuitry in the transceivers 210a-210n and / or the controller / processor 225 receives analog or digital data (e.g., voice data, network data, email, or interactive video game data) from the controller / processor 225. The TX processing circuitry encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The transceivers 210a-210n up-convert the baseband or IF signal to an RF signal that is transmitted via the antennas 205a-205n.

[0054] The controller / processor 225 may include one or more processors or other processing devices that control the overall operation of the gNB 102. For example, the controller / processor 225 may control the reception of UL channel signals and the transmission of DL channel signals by the transceivers 210a-210n in accordance with well-known principles. The controller / processor 225 may also support other functions (e.g., more advanced wireless communication functions). For example, the controller / processor 225 may support beamforming or directional routing operations, in which outgoing / incoming signals from / to multiple antennas 205a-205n are weighted differently to effectively steer the outgoing signals in a desired direction. The controller / processor 225 may support a variety of other functions in the gNB 102.

[0055] The controller / processor 225 is also capable of executing programs and other processes (e.g., the OS, and processes such as those supporting traffic-aware UE thermal management as discussed in more detail below) that reside in the memory 230. The controller / processor 225 can move data into or out of the memory 230 as required by the executing process.

[0056] The controller / processor 225 is also coupled to a backhaul or network interface 235. The backhaul or network interface 235 allows the gNB 102 to communicate with other devices or systems via a backhaul connection or via a network. The interface 235 may support communication via any appropriate wired or wireless connection. For example, when the gNB 102 is implemented as part of a cellular communication system (e.g., a cellular communication system supporting 5G / NR, LTE, or LTE-A), the interface 235 may allow the gNB 102 to communicate with other gNBs via a wired or wireless backhaul connection. When the gNB 102 is implemented as an access point, the interface 235 may allow the gNB 102 to communicate with a larger network (e.g., the Internet) via a wired or wireless local area network, or via a wired or wireless connection. The interface 235 includes any appropriate structure (e.g., Ethernet or a transceiver) that supports communication via a wired or wireless connection.

[0057] Memory 230 is coupled to controller / processor 225. A portion of memory 230 may include RAM, and another portion of memory 230 may include flash memory or other ROM.

[0058] although Figure 2 An example of a gNB 102 is shown, but the Figure 2 For example, gNB 102 may include Figure 2 Any number of each component shown. In addition, the Figure 2 There are various components in it, and additional components can be added according to specific needs.

[0059] Figure 3 An example UE 116 is shown in accordance with an embodiment of the present disclosure. Figure 3 The embodiment of UE 116 shown is for illustration only, and Figure 1 UEs 111-115 may have the same or similar configurations. However, UEs have a variety of configurations, and Figure 3 The scope of the present disclosure is not limited to any particular implementation of the UE.

[0060] like Figure 3 As shown, UE 116 includes antenna 305, transceiver 310, and microphone 320. UE 116 also includes speaker 330, processor 340, input / output (I / O) interface (IF) 345, input 350, display 355, and memory 360. Memory 360 includes operating system (OS) 361 and one or more applications 362.

[0061] Transceiver 310 receives incoming RF signals from antenna 305 transmitted by a gNB of network 100. Transceiver 310 down-converts the incoming RF signals to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is processed by RX processing circuitry and / or processor 340 in transceiver 310 (by filtering, decoding, and / or digitizing the baseband or IF signal to generate a processed baseband signal). The RX processing circuitry transmits the processed baseband signal to speaker 330 (e.g., for voice data) or is processed by processor 340 (e.g., for web browsing data).

[0062] The TX processing circuitry and / or processor 340 in the transceiver 310 receives analog or digital voice data from the microphone 320, or receives other outgoing baseband data (e.g., web page data, email, or interactive video game data) from the processor 340. The TX processing circuitry encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The transceiver 310 up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna 305.

[0063] The processor 340 may include one or more processors or other processing devices and execute the OS 361 stored in the memory 360 to control the overall operation of the UE 116. For example, the processor 340 may control the reception of DL channel signals and the transmission of UL channel signals by the transceiver 310 according to well-known principles. In some embodiments, the processor 340 includes at least one microprocessor or microcontroller.

[0064] The processor 340 is also capable of executing other processes and programs resident in the memory 360 (e.g., processes for traffic-aware UE temperature management discussed in more detail below). The processor 340 can move data into or out of the memory 360 as required by the executing process. In some embodiments, the processor 340 is configured to execute applications 362 based on the OS 361 or in response to signals received from the gNB or operator. The processor 340 is also coupled to the I / O interface 345, which provides the UE 116 with the ability to connect to other devices (e.g., laptops and handheld computers). The I / O interface 345 is the communication path between these accessories and the processor 340.

[0065] Processor 340 is also coupled to input 350, including, for example, a touch screen, a keyboard, etc., and display 355. An operator of UE 116 can use input 350 to enter data into UE 116. Display 355 can be a liquid crystal display, a light emitting diode display, or other display capable of presenting text (e.g., from a website) and / or at least limited graphics.

[0066] Memory 360 is also coupled to processor 340. A portion of memory 360 may include random access memory (RAM), and another portion of memory 360 may include flash memory or other read-only memory (ROM). Memory 360 may store instructions that, when executed by the processor, may cause UE 116 to perform the operations described herein.

[0067] although Figure 3 An example of UE 116 is shown, but the Figure 3 For example, they can be combined, further subdivided, or omitted Figure 3 , and other components may be added as needed. As a specific example, processor 340 may be divided into multiple processors (e.g., one or more central processing units (CPUs) and one or more graphics processing units (GPUs)). In another example, transceiver 310 may include any number of transceivers and signal processing chains and may be connected to any number of antennas. In addition, although Figure 3 The UE 116 is shown configured as a mobile phone or smartphone, but the UE may be configured to operate as other types of mobile or stationary devices.

[0068] Typically, the network / BS / gNB configures the UE with RF parameters (BW, MIMO layers, component carriers, and DRX parameters) that enable the UE to support a wide variety of applications. Since the UE may only use a few of these applications at any given time, this means that most of the time the UE may be over-configured by the network. This over-configuration not only results in high power consumption at the UE (power consumption from keeping components on (e.g., keeping multiple antennas on), processing power consumption for handling signals from larger bandwidths, multiple antennas, component carriers, etc.), but also results in higher device temperatures. Device overheating can negatively impact the user experience in a number of ways (e.g., discomfort holding a device that is getting hotter, eventual service interruption because the overheated device will eventually shut down, etc.). Therefore, effective device temperature management during 5G operation is critical.

[0069] The UE may be over-configured by the network to enable a wide variety of applications. However, the UE itself is aware of the current traffic and can therefore suggest a configuration to the BS that can help the UE perform thermal management while minimizing the impact on the Quality of Service (QoS) requirements (in terms of throughput and / or delay) of the current traffic.

[0070] Figure 4 A block diagram of an example procedure 400 for flow-aware UE temperature management according to an embodiment of the present disclosure is shown. Figure 4 The embodiment of the procedure 400 for traffic-aware UE temperature management is for illustration only. Different embodiments of the procedure 400 for traffic-aware UE temperature management may be used without departing from the scope of the present disclosure.

[0071] exist Figure 4In the example of , the IP traffic history 402 at the terminal is provided to a service type detector module 404, which classifies the service type into one of multiple categories (e.g., real-time or non-real-time). The UE state or sensor information 406 includes, for example, the device battery level, screen brightness, device temperature (which may include the temperature of the communication processor, the application processor temperature, the temperature of the device itself, etc.), etc. The communication configuration 408 includes RF parameters configured by the network for terminal use (e.g., bandwidth, the number of MIMO layers, the number of component carriers, etc.). The next module is an overheating prediction and appropriate parameter selection module 410. Note that this module can also be divided into multiple modules (e.g., one module for overheating prediction and another module for parameter selection). The module receives three inputs (UE state / sensor information 406, service type 404, and communication configuration 408) and determines whether the device (within a certain time span in the future) is likely to become overheated. Based on this determination, an appropriate communication configuration is determined that can avoid overheating while minimizing the impact on user QoS as much as possible. The proposed communication configuration is then sent to the BS (which may be based on the UE assistance information feature defined in 3GPP Release 16 or other releases), where the BS may decide whether to configure the terminal with the requested configuration.

[0072] The functionality of each block is described in more detail below.

[0073] Service Type Detector (404): This first block is a service type detector that classifies the service type of the currently active application at the UE. The service type detector takes an IP traffic history 402 as input. The IP traffic history 402 may be a set of features related to IP traffic, including but not limited to the inter-arrival time of UL and DL packets within a predefined interval T (e.g., 0.5-5 seconds), the size of the UL and DL packets (e.g., the maximum / minimum / average size within T), and the number of UL and DL packets within T. The service type detector may classify the service type into a coarse classification (e.g., real-time or non-real-time), or further into subclasses (e.g., audio calls, video calls, and mobile gaming for real-time applications, and browsing, video streaming, or background traffic for non-real-time applications). ML classifiers such as convolutional neural networks (CNNs) or gradient boosting classifiers such as extreme gradient boosting (XGBoost) may be used for service type detection. Since different service types have different requirements on devices, such predictions help in selecting appropriate device behavior. For example, if the service is real-time (e.g., an audio call or video call with a regular traffic pattern), the RF circuit of the UE device may not be turned off immediately, otherwise there may be increased latency or event data loss. For non-real-time applications with irregular traffic patterns and long periods of inactivity, the RF circuit of the UE device can be turned off to help reduce the device temperature. Based on the above discussion, it can be inferred that the device may heat up faster when the service type is real-time compared to non-real-time service types. In addition to considering the required data traffic pattern, different types of applications may use other device resources in different ways, which may have different effects on the temperature of the device. For example, for online mobile gaming applications, the requirements for video rendering and local load on the processor may be high. High display requirements may cause the device temperature as a baseline to be relatively high. In this case, the communication chip may be more likely to overheat than other applications that may not use other device resources. Based on this observation, the classification of service types can be based on the local resource usage required by the application that may affect the device baseline temperature. The prediction of the service detector implemented at the UE should be accessible to the application processor (AP) that may implement the proposed overheating prediction and appropriate communication configuration selection module.

[0074] UE State and Sensor Information (406): Device temperature is affected by several UE behaviors that can be inferred through UE state and sensor information 406. For example, screen brightness and screen-on time can be positively correlated with device temperature. The activity level of the mobile device CPU / GPU can also be positively correlated with device temperature. Trends in device temperature are also useful predictors of future device temperatures, for example, a recent increase in temperature can indicate further temperature increases unless some corrective activities are performed, and vice versa. The ambient temperature of the environment is another piece of information that can be positively correlated with the likelihood of overheating. All of the foregoing information (and other appropriate information) is categorized under the general term UE state and sensor information. The outputs from the various sensors at the UE should be accessible to an application processor (AP) that may implement the proposed overheat prediction and appropriate communication configuration selection module.

[0075] Communication configuration (408): Communication-related power consumption and processing come from both RF operations and baseband operations. Power consumption and processing are positively correlated with device temperature. Therefore, the UE communication configuration 408 affects the device temperature. Specifically, the parameters that may affect the device temperature are the communication bandwidth (the larger the bandwidth, the more processing, the higher the temperature), the maximum number of MIMO layers (the more MIMO layers means more processing in UL / DL, and the total transmission power in UL may be higher, and the more active antennas / RF chains, which may lead to higher temperatures), the number of component carriers (the more component carriers means more processing, and therefore higher power consumption, for example, due to the tracking of reference signals for each component carrier, resulting in higher temperatures), etc. All of the aforementioned information (and other appropriate information) is collectively referred to as the communication configuration. The communication configuration should be accessible by an application processor (AP) that may implement the proposed overheating prediction and appropriate communication configuration selection module.

[0076] Overheat prediction and selection of appropriate parameters to avoid overheat (410): This module receives input from UE status / sensor information 406, service type detector 404, and communication configuration 408 to predict whether the device is prone to overheating. Several embodiments in this disclosure relate to the design of this module and will be discussed in detail later. Based on the determination of whether the device is prone to overheating, an appropriate communication configuration is selected that the device considers suitable for temperature management.

[0077] Sharing the proposed communication configuration with the BS (412): The UE shares the proposed communication configuration with the BS, and the BS then decides whether to configure the UE with the proposed communication configuration. If the UE is configured with the proposed parameters, the UE starts operating with the new communication configuration, otherwise the UE continues operating with the previously configured communication configuration. Since the BS behavior is not controlled by the UE, in subsequent embodiments, we will focus on the case where the BS respects the UE's suggestion and configures the UE with the requested parameters. Multiple embodiments in the present disclosure relate to an effective mechanism for the BS to configure the UE with the configuration parameters proposed by the UE.

[0078] although Figure 4 An example of a process 400 for flow-aware UE temperature management is shown, but may be used for Figure 4 For example, they can be combined, further subdivided, or omitted Figure 4 There are various components in , and other components can be added according to specific needs.

[0079] In one embodiment, Figure 4 The module 410 can be related to Figure 5 The above is implemented similarly.

[0080] Figure 5 A method 500 of predicting and selecting based on current temperature according to an embodiment of the present disclosure is shown. Figure 5 The illustrated method embodiments are for illustration only. Figure 5 One or more components shown may be implemented in a dedicated circuit configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of predicting and selecting based on current temperature may be used without departing from the scope of the present disclosure.

[0081] Figure 5 The prediction and selection of solutions based on the current temperature are shown. Figure 5 In the example, suppose that the service type detector (for example, Figure 4 The service type detector 404 ) classifies the current service type into two categories (ie, real-time and non-real-time applications).

[0082] exist Figure 5In the example of , different configurations are applied based on the operating temperature range. For example, when the service type (block 502) is real-time (RT) (block 504) and the temperature t_c (block 506) is greater than the start threshold th_start_RT (block 508), a communication configuration suitable for RT applications is applied (block 510), and when the temperature is less than the stop threshold th_stop_RT (block 512), the configuration is restored to the NW default configuration (block 520). In addition, when the service type is non-real-time (NRT) (block 504) and the temperature t_c is greater than the start threshold th_start_NRT (block 522), a communication configuration suitable for NRT is applied (block 530), and when the temperature is less than the stop threshold th_stop_NRT (block 532), the configuration is restored to the NW default configuration (block 540). If the temperature t_c remains below th_stop_RT for RT services (block 512 ) and below th_stop_NRT for NRT services (block 522 ), the device may continue to operate with the communication configuration configured by the network (block 550 ).

[0083] To understand the process, let's consider an example where the device is operational and the current service type is RT. In the case of continuous operation, the device temperature may start to rise until it can reach the point th_start_RT. At this stage, if no action is taken, the device may easily overheat in the future if the RT service continues. As a result, the device recommends a communication configuration suitable for RT applications to the BS. If the BS grants the communication configuration recommended by the device, the device may start to cool down until it reaches the point th_stop_RT, at which point the device is cool enough to resume operation using the communication configuration originally selected by the BS. The same idea applies to the NRT service type. For the case of mixed service types, when the UE uses RT and NRT applications, an application category with conservative requirements should be used for parameter selection. Typically, the delay requirements for RT applications are more stringent, so if the service type is both RT and NRT (for mixed traffic), temperature management should be based on RT applications.

[0084] When the device resumes operating with the parameters configured by the BS, the device may start heating up again. In another embodiment, once the device has cooled to the point th_stop_RT, the device will not request the communication configuration initially selected by the BS (e.g., using the UE auxiliary information feature). Instead, the device requests the following communication configuration: the communication configuration is lower than the communication configuration originally set by the BS (the parameters configured by the BS) but higher than the communication application (params_RT) selected for temperature reduction. The terms "lower than" and "higher than" here respectively represent a communication configuration that can cause a "slower" temperature rise within a given time period, and a communication configuration that can cause a "faster" temperature rise within a given time period. The communication configuration may be referred to as an intermediate communication configuration. The benefit of operating with an intermediate communication configuration rather than the parameters configured by the BS is that the device is unlikely to start heating up again immediately. In another embodiment, once the configuration is switched to an embodiment based on params_RT, it will not be restored back to the parameters configured by the BS. This is because the temperature of the device is unlikely to drop below a certain point (e.g., ambient temperature), and the device can successfully operate with params_RT while maintaining QoS services. This helps save the RRC reconfiguration overhead associated with switching back to BS-configured parameters, and may also minimize the risk of re-warming after the device has cooled down. Note that while terms such as "switching configuration" are used to simplify the explanation, this should be understood as meaning that the UE may follow typical standard-specified procedures (e.g., the UE may first request a new configuration, which may or may not be granted to the UE). In particular, a request to use a higher configuration after cooling down (typically requiring more resources) may or may not be granted by the BS, depending on its current load. When a request to use a higher configuration is rejected, the UE may wait for a period of time or a prohibit timing period and try again. This rejection of a higher configuration has no negative impact on temperature control.

[0085] The appropriate threshold value can be determined by experiments. Specifically, experiments can be conducted to observe the temperature changes of devices with different service types and different communication configurations to determine the appropriate threshold values ​​for different service types. As an example, since RT applications require the device to continuously send and receive, th_start_RT can be less than th_start_NRT, and th_stop_RT can be less than th_stop_RT.

[0086] For a 45°C overheat threshold, example values ​​for [th_start_RT, th_stop_RT] may be [35, 30], and example values ​​for [th_start_NRT, th_stop_RT] may be [38, 34].

[0087] although Figure 5An example of a method 500 for predicting and selecting based on current temperature is shown, but Figure 5 Make various changes. For example, although Figure 5 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0088] Above Figure 5 Based on current temperature. However, if the temperature itself can be accurately forecasted and predicted, overheating predictions can be made more accurately.

[0089] Figure 6 A method 600 for predicting future temperature according to an embodiment of the present disclosure is shown. Figure 6 The illustrated method embodiments are for illustration only. Figure 6 One or more components shown may be implemented in a dedicated circuit configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of predicting and selecting based on current temperature may be used without departing from the scope of the present disclosure.

[0090] One approach to temperature forecasting is to consider past and present temperatures as a time series and predict future temperatures based on the time series forecasts, e.g. Figure 6 As shown. Figure 6 As shown, method 600 starts at step 610. First, based on the output of the current service type at step 610, a corresponding time series model is selected at step 620. For example, if the service type is RT or NRT, a time series model corresponding to RT or NRT is selected. In the offline stage, a separate time series model is fitted to the RT data or the NRT data. Autoregression (AR), moving average (MA), autoregressive moving average (ARMA), autoregressive integrated moving average (ARIMA), etc. can be used according to the exact characteristics of the observed time series data. For example, if the data is stationary in the mean sense, ARMA can be used, and if the data is non-stationary in the mean sense, ARIMA can be used. Solutions based on machine learning techniques (e.g., RNN, LSTM, GRU, 1D CNN, etc.) can also be used. At step 630, during online operation, a time series model corresponding to the currently detected service type is selected, at step 640, past and present values ​​of the device temperature are fed to the model, and at step 650, the model predicts temperature values ​​in the future, e.g., T seconds in the future (example values ​​of T are 1, 2, and 5 seconds). It is conceivable that accurate predictions over larger time spans would be more useful for UE temperature management, but such predictions may be more difficult to achieve.

[0091] although Figure 6 One example of a method 600 for predicting future temperature is shown, but may be used for Figure 6 Make various changes. For example, although Figure 6 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0092] In alternative embodiments, in addition to the temperature time series, various other inputs are given to the model for accurate prediction over longer time spans. Figure 7 An example of this strategy is shown.

[0093] Figure 7 A method 700 for predicting future temperature according to an embodiment of the present disclosure is shown. Figure 7 The illustrated method embodiments are for illustration only. Figure 7 One or more components shown may be implemented in a dedicated circuit configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of predicting and selecting based on current temperature may be used without departing from the scope of the present disclosure.

[0094] exist Figure 7 In the example of , the current service type 720 is used to select the corresponding time series model at step 720. However, the time series model is Figure 6 The example of is more complex. The time series forecast is not only based on the current and past temperature 740, but also on several explanatory or exogenous variables 760-790. These variables are not exactly temperature, but several other factors that indirectly affect the temperature. At step 730, this purpose can be achieved using a right autoregressive integrated moving average (ARIMAX) using exogenous variables or their seasonal counterpart seasonal ARIMAX (SARIMAX), depending on whether the variables are seasonal. The exogenous variables include NR activity 760 (i.e., the number of PHY layer packets per second in the past few seconds), the history of screen brightness 770, CPU / GPU activity 780, and ambient temperature 790. An example of a seasonal exogenous variable is ambient temperature, which can show seasonality (rising during the day and falling at night) over a duration of 24 hours. Since all of these factors affect the temperature, considering all of these variables can achieve more accurate predictions over a potentially longer span. Figure 6 Examples and Figure 7 The relative differences between the examples are in complexity and accuracy. Figure 6 The method may not be as good as Figure 7 The method is accurate, but Figure 6The method has lower complexity in offline training and online development stages. In another embodiment, to reduce complexity, the temperature forecast module is activated only when the current temperature is above a threshold (e.g., 35°C). In another embodiment, the temperature forecast module is activated if the temperature change within a time window (5-10 seconds) is above a threshold (e.g., 1 degree within 5 seconds).

[0095] In another embodiment, in order to utilize various UE context information (including UE status, information of various sensors, and NR configuration status) and service type, a binary prediction classifier can be trained, where the two categories are "high overheating risk" and "no overheating risk" occurring within a certain prediction span. In one solution, at a high level, the baseline power consumption of the device (excluding the power consumption of the NR module) and the power consumption of the NR module are used. As an example, in order to provide a baseline power consumption, the main power consumption modules are used (e.g., screen brightness, current device temperature, processing requirements (possibly related to the application type)). For NR module power consumption estimation (and therefore possible temperature increase), channel quality indicators, uplink utilization, and UE configuration (e.g., bandwidth, number of MIMO layers, etc.) are used.

[0096] although Figure 7 One example of a method 700 for predicting future temperature is shown, but may be used for Figure 7 Make various changes. For example, although Figure 7 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0097] based on Figure 6 and Figure 7 The future temperature prediction can be used for equipment temperature management, such as Figure 8 shown.

[0098] Figure 8 A method 800 of predicting and selecting based on predicted future temperatures according to an embodiment of the present disclosure is shown. Figure 8 The illustrated method embodiments are for illustration only. Figure 8 One or more components shown may be implemented in a dedicated circuit configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of predicting and selecting based on predicted future temperatures may be used without departing from the scope of the present disclosure.

[0099] exist Figure 8 In the example, Figure 5 The example defines a temperature threshold that is compared to a future prediction of the temperature rather than the current temperature.

[0100] exist Figure 8 In the example of , different configurations are applied based on the operating temperature range. For example, when the service type (block 802) is real-time (RT) (block 804) and the future temperature t_f (block 806) is greater than th_start_RT (block 808), a communication configuration suitable for RT applications is applied (block 810), and when the future temperature is less than th_stop_RT (block 812), the configuration is restored to the NW default configuration (block 820). In addition, when the service type is non-real-time (NRT) (block 804) and the future temperature t_f is greater than th_start_NRT (block 822), a communication configuration suitable for NRT is applied (block 850), and when the future temperature is less than th_stop_NRT (block 832), the configuration is restored to the NW default configuration (block 840). If the future temperature t_f remains below th_stop_RT for RT services (block 812 ), and below th_stop_NRT for NRT services (block 822 ), the device may continue to operate with the communication configuration configured by the network (block 850 ).

[0101] and Figure 5 Compared with the method Figure 8 The benefit of the approach based on future temperature predictions is that the risk of overheating can be determined well in advance of an actual overheating event due to the temperature predictions. Therefore, the parameters suggested for RT / NRT applications do not need to be as Figure 5 Conservative parameters here mean parameters that may result in less temperature rise or faster cooling of the device (e.g., lower BW and fewer number of antennas). Therefore, less conservative parameters will cool the device slowly, while more conservative parameters will cool the device faster. Due to this advantage, the device can operate with less conservative RT / NRT parameter options for a longer period of time, which means better QoS for the user, compared to the case where the device needs to operate with more conservative parameters for a shorter duration. In other words, less rapid transitions in QoS are more beneficial to the user experience. Figure 8 The trade-off of the approach is that it increases the computational complexity of temperature prediction. Furthermore, since temperature forecasting is an estimation / prediction problem, the predictions are inherently prone to error. Figure 8 The example uses the current service type, alternatively based on the history of service type detection, some service type forecast may also be used.

[0102] and Figure 5Similar to the alternative implementation of the method, an alternative implementation for prediction based on future temperature is defined. Specifically, in another embodiment, once the device cools to the point th_stop_RT, the device will not revert to operation using the communication configuration initially selected by the BS. Instead, the device starts operating with a communication configuration that is lower than the communication configuration originally set by the BS (BS-configured parameters) but higher than the communication application (params_RT) selected for temperature reduction. This communication configuration may be referred to as an intermediate communication configuration. The benefit of operating with an intermediate communication configuration rather than BS-configured parameters is that the device will not immediately start heating up again. In another embodiment, once the configuration is switched to a configuration based on params_RT, it will not revert back to the parameters configured by the BS. This is because the temperature of the device is unlikely to drop below a certain point (e.g., ambient temperature), and the device can successfully operate using params_RT while maintaining QoS services. This helps save the RRC reconfiguration overhead associated with switching back to the parameters configured by the BS, and can also minimize the risk of reheating after the device cools down.

[0103] although Figure 8 One example of a method 800 for predicting and selecting based on predicted future temperatures is shown, but may be used for Figure 8 Make various changes. For example, although Figure 8 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0104] The solutions described so far (i.e., Figure 5 and Figure 8 An example of this is to change parameters based on the risk of overheating, where the UE determines the best configuration offline and applies it during online operation until the current temperature or a future temperature forecast drops below a certain predefined threshold. Fig. 9 An alternative is shown where the device attempts to maintain the temperature close to a desired temperature (which may be the ambient temperature). The desired temperature may also be referred to as a target temperature, an optimal temperature, etc.

[0105] Fig. 9 A method 900 of predicting and selecting based on desired temperature is shown according to an embodiment of the present disclosure. Fig. 9 The illustrated method embodiments are for illustration only. Fig. 9 One or more components shown may be implemented in a dedicated circuit configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of predicting and selecting based on predicted future temperatures may be used without departing from the scope of the present disclosure.

[0106] exist Fig. 9 In the example of , the method starts at block 902 by first checking whether substantial new radio (NR) activity is occurring. If there is no NR activity, the NR operation is independent of the device temperature and no parameter selection is required. In contrast, if substantial NR activity is occurring, the parameters to be recommended are selected from the parameters in the table. The index of the parameter is the row index of the table. The table is populated so that operation with the parameters at row i may generate more heat than with the parameters at row i+1. The table can be populated offline by configuring the UE with different parameters and noting the impact on the temperature. During online operation, at block 912, if substantial NR activity is occurring, if the current temperature is threshold_1 (e.g., 5°C) higher than the expected temperature (e.g., 30°C) and the device is operating with the current parameters at index i, then at block 914, the device will recommend the parameters at index i+1. The time interval between two consecutive recommendations is at least equal to the SR prohibit timer configured by the network in the UE assistance framework. Additionally, at block 922, if the current temperature is lower than the desired temperature by a threshold value threshold_2 (which may be equal to threshold_1, e.g., 5°C), and the device is operating with the parameters at index i, then at block 924, the device may suggest parameters at index i-1. In this way, by continually changing parameters as temperature changes, and observing the effect of these choices on the device temperature, the device may remain fairly close to the desired temperature over a longer period of time. The tradeoff of this strategy compared to an open-loop solution is that the RRC configuration load may be higher as the device continuously optimizes the parameters of its operation.

[0107] Since the goal is to maintain a certain QoS, in another embodiment, the index i is not always reduced when the current temperature is below the ambient temperature threshold_1. Instead, it is checked whether the current set of parameters can meet the QoS requirements. This can be done based on the service type detector, and depending on the service type (real-time or non-real-time) and the current index i, the index i can be reduced or kept unchanged. In another embodiment, temperature changes are monitored instead of absolute changes, that is, if the temperature change within a certain time window (5 seconds) is greater than the threshold, the parameter with a larger index i is used, and vice versa. In another embodiment, if the binary prediction classifier indicates "high overheating risk", the parameter with index i+1 can be used. On the other hand, if the classifier indicates "low overheating risk", the parameter with index i-1 or index i can be used depending on whether the QoS for the current service type is met.

[0108] although Fig. 9 One example of a method 900 for predicting and selecting based on desired temperature is shown, but other methods may be used. Fig. 9Make various changes. For example, although Fig. 9 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0109] After the UE determines the communication configuration, the configuration determined by the UE is communicated to the BS.

[0110] Fig.10 A method 1000 for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown. Fig.10 The illustrated method embodiments are for illustration only. Fig.10 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions, or one or more components may be implemented by one or more processors executing instructions to perform the functions.Other embodiments of conveying the communication configuration to the BS may be used without departing from the scope of the present disclosure.

[0111] like Fig.10 As shown, method 1000 starts at step 1002. At step 1002, the UE operates with the parameters configured by the BS. At step 1022, the UE determines the recommended heat reduction parameters. At step 1032, the UE sends the recommended heat reduction parameters to the BS. At step 1042, the BS decides whether to configure the UE with the recommended parameters. At step 1052, the BS configures the UE with the modified parameters. Finally, at step 1002, the UE operates with the modified parameters configured by the BS.

[0112] exist Fig.10 In the example of , the BS configures the UE with the suggested configuration based on the UE suggestion. However, there are multiple trade-offs with this approach. First, it is up to the BS to decide whether or not the BS will configure the UE with the requested / suggested configuration. This is true even though the UE may only request a reduction in resources that have already been configured by the BS. Second, the reconfiguration of the UE is done via RRC reconfiguration, which incurs a significant overhead (i.e., 45KB in the worst case). This is why it is desirable to avoid frequent RRC reconfigurations. Furthermore, even if frequent RRC reconfigurations can be tolerated, this will result in further activity on the UE side, which may lead to exacerbated overheating issues.

[0113] although Fig.10 One example of a method 1000 for communicating a communication configuration to a BS is shown, but may be used for Fig.10 Make various changes. For example, although Fig.10 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0114] Fig.11 An alternative embodiment is shown, where the BS only needs to confirm the UE selection.

[0115] Fig.11 A method 1100 for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown. Fig.11 The illustrated method embodiments are for illustration only. Fig.11 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions, or one or more components may be implemented by one or more processors executing instructions to perform the functions.Other embodiments of conveying the communication configuration to the BS may be used without departing from the scope of the present disclosure.

[0116] It is conceivable that the BS can always grant the UE the choice, since in the context of temperature management the UE will not request parameters higher than those initially configured by the BS (BW, layers, maximum number of MIMO layers, and DRX parameters). Therefore, granting the UE request does not cause any problems from a resource limitation perspective. However, always granting the UE's request may complicate the implementation of the BS scheduler. From this perspective, such an implementation can be seen as a trade-off between the communication overhead for the BS (sending the RRC reconfiguration to the UE) and the implementation overhead (a more complex scheduler).

[0117] like Fig.11 As shown, method 1100 starts at step 1102. At step 1102, the UE operates with the parameters configured by the BS. At step 1122, the UE determines the recommended heat reduction parameters. At step 1032, the UE sends the recommended heat reduction parameters to the BS. The UE sends its preferred parameters to the BS. Even if the BS expects to grant the UE the right to choose, the UE needs to wait for confirmation from the BS. This is because the request may not be correctly decoded at the BS. At step 1142, if there is no confirmation within a specific time period p1 (e.g., a predetermined period), the UE can resend the preferred parameters to the BS at step 1132. The period p1 represents the delay in the transmission and BS decoding of the message, which is about a few milliseconds. At step 1142, if the UE receives a confirmation from the BS, the UE continues to operate with the recommended parameters within the period p2, and then the UE determines the preferred parameters again at step 1122. Since the period p2 can prevent the UE from reconfiguring quite frequently, the period p2 is a prohibition timer in the UE auxiliary framework. The motivation for introducing the inhibit timer here is to ensure that the UE does not send the preferred parameters too frequently, which would require the BS scheduler to adjust frequently and be more dynamic.

[0118] although Fig.11One example of a method 1100 for communicating a communication configuration to a BS is shown, but may be used for Fig.11 Make various changes. For example, although Fig.11 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0119] Fig.12 and Fig.13 Alternative embodiments are shown for configuring a UE with different temperature management parameters.

[0120] Fig.12 and Fig.13 Methods 1200 and 1300 of configuring a UE with different temperature management parameters according to embodiments of the present disclosure are shown. Fig.12 and Fig.13 The illustrated method embodiments are for illustration only. Fig.12 and Fig.13 One or more components shown may be implemented in dedicated circuits configured to perform the functions, or one or more components may be implemented by one or more processors executing instructions to perform the functions. Other embodiments of configuring a UE with different temperature management parameters may be used without departing from the scope of the present disclosure.

[0121] The connection establishment phase is the phase where the UE connects with the NW. This can be when the UE is turned on. During the connection establishment phase, the UE shares all UE capability information with the NW. In the present disclosure, during the connection establishment phase, the UE sends multiple temperature management parameters to the BS, such as Fig.12 As shown in block 1202 of . In one embodiment, sharing the thermal management parameters to the network (NW) can be done as part of UE capability information sharing - 3GPP standards may support such information sharing in the future. In order for the NW to know the UE capabilities, the NW sends a UE capability query, and the UE responds to it with all the requested information. In another embodiment, the NW itself configures multiple bandwidth parts (BWPs) for the UE, but the UE ranks these BWPs according to the risk of overheating. At block 1222, the BS configures the UE with multiple BWPs (one BWP corresponds to one thermal management parameter) and an additional default BWP (the MIMO layer is also configured in the BWP framework). Note that the UE can be configured with up to 4 BWPs in the UL and 4 BWPs in the DL. Thereafter, the BS indicates the active BWP to the UE via DCI, which is exchanged over the PDCCH. Since PDCCH messages are sent frequently to the UE, they do not bring any additional overhead from the UE thermal management perspective. After the connection is established, when the UE is in Fig.13When the operation starts at block 1302 of , it starts with a default BWP. Then at block 1322, the UE predicts a heat reduction parameter (e.g., a power saving parameter) and sends the preferred parameter to the BS at block 1332. Then at block 1342, the BS switches the active BWP to the BWP corresponding to the preferred parameter via DCI (sent in the PDCCH). Since the active BWP is indicated via the BWP indicator within the DCI, this way of switching the BWP does not bring additional signaling overhead and can avoid the RRC reconfiguration overhead of the traditional method. The limitation of this process is that the UE can configure up to 4 BWPs, so this process can allow the UE to utilize up to 3 (excluding the default BWP) temperature saving configurations.

[0122] although Fig.12 and Fig.13 An example of methods 1200 and 1300 for configuring a UE with different temperature management parameters is shown, but the same may be applied to the method 1200 and 1300. Fig.12 and 13 Make various changes. For example, although Fig.12 and Fig.13 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0123] In another embodiment, in order to utilize various UE context information (including UE status, information of various sensors, and NR configuration status) and service type, a binary prediction classifier can be trained, where the two categories are "high overheating risk" and "no overheating risk" occurring within a certain prediction horizon. If there is a "high overheating risk", the recommended configuration is sent to the BS, such as Fig.14 shown.

[0124] Fig.14 A method 1400 for communicating a communication configuration to a BS according to an embodiment of the present disclosure is shown. Fig.14 The illustrated method embodiments are for illustration only. Fig.14 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions, or one or more components may be implemented by one or more processors executing instructions to perform the functions.Other embodiments of conveying the communication configuration to the BS may be used without departing from the scope of the present disclosure.

[0125] like Fig.14As shown, method 1400 starts at step 1402. At step 1402, the UE operates with the parameters configured by the BS. At step 1404, the UE determines the risk of overheating of the UE. If there is no risk of overheating, no action is required (step 1406). Otherwise, at step 1408, the UE sends the recommended heat reduction parameters to the BS. At step 1410, if the BS accepts the recommended configuration, at step 1402, the UE operates with the recommended configuration. Otherwise, at step 1412, the UE initiates fallback to LTE. In another embodiment, once a "high risk of overheating" is detected, the UE initiates a transition to LTE and allows the NR chip to cool down before switching back. In another embodiment, if the UE is currently operating on FR2 (millimeter wave), it can fall back to FR1 (below 6GHz).

[0126] although Fig.14 One example of a method 1400 for communicating a communication configuration to a BS is shown, but may be used for Fig.14 Make various changes. For example, although Fig.14 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0127] Multiple embodiments in the present disclosure are based on temperature prediction and overheating risk classification based on machine learning. The computational complexity associated with these methods can be reduced by following a simple gating procedure, for example, in one embodiment, the temperature prediction and appropriate RF parameter determination modules are activated only after some gating conditions are met (e.g., the current temperature is greater than a threshold temperature (e.g., 35°C), or the temperature change within a time window T (5-10 seconds) is higher than a threshold th_1 (e.g., 1 degree within 5 seconds)).

[0128] Fig.15 A method 1500 for performing gating according to an embodiment of the present disclosure is shown. Fig.15 The illustrated method embodiments are for illustration only. Fig.15 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of gating may be used without departing from the scope of the present disclosure.

[0129] like Fig.15As shown, method 1500 starts at step 1502. At step 1502, the UE determines whether the temperature change of the UE is higher than a threshold value th_1 within a time window T. If the temperature change is higher than the threshold value (step 1522), and the temperature forecast and RF parameter prediction module is not in an active state, the UE activates the temperature forecast and RF parameter prediction module (step 1524). Otherwise, no action is required (step 1526). If the temperature change is not higher than the threshold value (step 1532), and the temperature forecast and RF parameter prediction module is in an active state, the UE deactivates the temperature forecast and RF parameter prediction module (step 1534). Otherwise, no action is required (step 1536).

[0130] although Fig.15 One example of a method 1500 for performing gating is shown, but may be used for Fig.15 Make various changes. For example, although Fig.15 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0131] Multiple embodiments of the present disclosure continuously forecast temperature and / or perform overheating risk classification based on machine learning. In order to reduce the associated computational complexity, the temperature overheating prediction period can be adjusted. For example, when the temperature is low (e.g., ≤25°C), the prediction period can be increased to p_large (e.g., 1 prediction per second) so that fewer predictions are made within a given period (e.g., 5 seconds), thereby reducing complexity. Similarly, if the temperature is high (e.g., ≥40°C), more frequent (i.e., a period of p_small, e.g., 1 prediction every 200ms) temperature predictions are made. In another embodiment, if the temperature change within a time window (5-10 seconds) is higher than a threshold (e.g., 1 degree within 5 seconds), the forecast period is reduced.

[0132] Fig.16 A method 1600 for adjusting a prediction period according to an embodiment of the present disclosure is shown. Fig.16 The illustrated method embodiments are for illustration only. Fig.16 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described.Other embodiments of adjusting the prediction period may be used without departing from the scope of the present disclosure.

[0133] like Fig.16As shown, method 1600 starts at step 1602. At step 1602, the UE determines whether the temperature change of the UE is higher than a threshold th_1 within a time window T. If the temperature change is higher than the threshold, the UE uses a prediction period p_small (step 1604). Otherwise, the UE uses a prediction period p_large (step 1606).

[0134] although Fig.16 An example of a method 1600 for adjusting the prediction period is shown, but may be used for Fig.16 Make various changes. For example, although Fig.16 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0135] Fig.17 A method 1700 for traffic-aware UE temperature management according to an embodiment of the present disclosure is shown. Fig.17 The illustrated method embodiments are for illustration only. Fig.17 One or more of the components shown may be implemented in dedicated circuits configured to perform the functions described, or one or more components may be implemented by one or more processors executing instructions to perform the functions described. Other embodiments of traffic-aware UE temperature management may be used without departing from the scope of the present disclosure.

[0136] like Fig.17 As shown, method 1700 starts at step 1710. At step 1710, the UE detects the service type currently active at the UE. The detection of the service type can be based on the traffic history of the UE. At step 1720, the UE determines the UE state and sensor information. At step 1730, the UE determines the current communication configuration of the UE. At step 1740, the UE predicts the risk of UE overheating. The prediction can be based on the service type, the UE state and sensor information, and the current communication configuration. At step 1750, the UE identifies a new communication configuration recommended for the UE. The identification can be based on the predicted risk of UE overheating. A "new" communication configuration can refer to a newly identified communication configuration. In some cases, the new communication configuration may include a communication configuration that is the same as a previously used communication configuration. Finally, at step 1760, the UE sends information indicating the new communication configuration to the BS.

[0137] although Fig.17 An example of a method 1700 for flow-aware UE temperature management is shown, but may be used for Fig.17 Make various changes. For example, although Fig.17 The various steps in are shown as a series of steps, but the steps may overlap, occur in parallel, occur in a different order, or occur any number of times.

[0138] Any of the above variant embodiments may be used independently or in combination with at least one other variant embodiment. The above flow charts illustrate example methods that may be implemented according to the principles of the present disclosure, and various changes may be made to the methods shown in the flow charts herein. For example, although shown as a series of steps, the various steps in each figure may overlap, occur in parallel, occur in different orders, or occur multiple times. In another example, these steps may be omitted or replaced with other steps.

[0139] Although the present disclosure has been described using exemplary embodiments, various changes and modifications may be suggested to those skilled in the art. The present disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims. The description in this application should not be interpreted as implying that any particular element, step or function is an essential element that must be included in the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A method of a user equipment UE (116), the method comprising: Based on the traffic history of the UE, detecting (1710) a service type currently active at the UE; Determine (1720) UE status and sensor information; determining (1730) a current communication configuration for the UE; predicting (1740) a risk of UE overheating based on the service type, the UE state and the sensor information, and the current communication configuration; Based on the predicted risk of UE overheating, identifying (1750) a communication configuration recommended for use by the UE; and Information indicative of the identified communication configuration is sent (1760) to the base station BS (102).

2. The method according to claim 1, wherein: Predicting the risk of overheating of the UE includes: determining whether the service type is real-time or non-real-time; and determining whether a current temperature of the UE is greater than a start threshold associated with the determined service type, and Identifying a communication configuration recommended for use by the UE includes: If the current temperature of the UE is greater than or equal to the start threshold associated with the determined service type, determining a new communication configuration based on parameters associated with the determined service type; and If the current temperature of the UE is less than the start threshold associated with the determined service type, the new communication configuration is determined based on parameters configured by a base station.

3. The method according to claim 1, wherein: Predicting the risk of overheating of the UE includes: Determining whether the service type is real-time or non-real-time; predicting a future temperature of the UE; and determining whether a future temperature of the UE is greater than a start threshold associated with the determined service type, and Identifying a communication configuration recommended for use by the UE includes: If the future temperature of the UE is greater than or equal to the start threshold associated with the determined service type, determining the communication configuration based on parameters associated with the determined service type; and If the future temperature of the UE is less than the start threshold associated with the determined service type, the communication configuration is determined based on parameters configured by a base station.

4. The method according to claim 3, wherein: Predicting the future temperature of the UE includes: selecting a time series model based on the determined service type; and The future temperature of the UE is predicted based on the selected time series model.

5. The method according to claim 1, wherein: Predicting the risk of overheating of the UE includes: determining whether current traffic of the UE includes substantial New Radio (NR) activity; and If the current traffic of the UE includes substantial NR activity, determining a relationship between a current temperature of the UE and an optimal temperature, and Identifying a communication configuration recommended for use by the UE includes: If the relationship between the current temperatures of the UEs is greater than the optimal temperature plus a threshold temperature, determining the communication configuration based on parameters associated with index i+1, where i is a current index; and If the relationship between the current temperatures of the UEs is less than the optimal temperature minus the threshold temperature, the communication configuration is determined based on parameters associated with index i-1.

6. The method according to claim 1, further comprising: receiving an acknowledgement ACK corresponding to the communication configuration from the BS, wherein if the ACK is received from the BS within a first predetermined period, the UE operates based on the communication configuration within a second predetermined period, and If the ACK is not received from the BS within the first predetermined period, the UE resends information indicating a new communication configuration to the BS.

7. The method according to claim 1, wherein: The identified communication configuration includes a plurality of power saving parameters, and The method further includes: receiving, from the BS, a communication configuration including a plurality of bandwidth parts corresponding to the power saving parameter.

8. The method according to claim 1, wherein: If the UE does not receive a response from the BS regarding the proposed new communication configuration, the UE falls back to a Long Term Evolution (LTE) mode of operation.

9. The method according to claim 1, further comprising: Determining whether a temperature change of the UE within a time window is greater than a threshold; determining whether the UE is performing temperature forecasting and RF parameter prediction; If the temperature change is greater than the threshold and the UE is not performing temperature prediction and RF parameter prediction, performing temperature prediction and RF parameter prediction; as well as If the temperature change is not higher than the threshold, and the UE is performing temperature prediction and RF parameter prediction, the temperature prediction and RF parameter prediction are stopped.

10. The method according to claim 1, further comprising: Determining whether a temperature change of the UE within a time window is greater than a threshold; If the temperature change is higher than the threshold, reducing the period of predicting the risk of UE overheating; as well as If the temperature change is not higher than the threshold, the period of predicting the risk of UE overheating is increased.

11. A user equipment UE (116), comprising: a memory for storing instructions (360); as well as A processor (340) is operably coupled to a memory (360), wherein when the processor (360) executes the instructions, the processor (360) causes the UE to perform operations, the operations comprising: Based on the traffic history of the UE, detecting (1710) a service type currently active at the UE; Determine (1720) UE status and sensor information; determining (1730) a current communication configuration for the UE; predicting (1740) a risk of UE overheating based on the service type, the UE state and the sensor information, and the current communication configuration; Based on the predicted risk of UE overheating, identifying (1750) a communication configuration recommended for use by the UE; and Information indicative of the identified communication configuration is sent to a base station BS (102).

12. The UE according to claim 11, wherein: The operations further comprise at least one operation of the method according to one of claims 2 to 10.

13. A non-transitory computer-readable storage medium storing instructions, the instructions, when executed by a processor (340) of a user equipment (UE) (116), causing the UE to perform operations, the operations comprising: Based on the traffic history of the UE, detecting (1710) a service type currently active at the UE; Determine (1720) UE status and sensor information; determining (1730) a current communication configuration for the UE; predicting (1740) a risk of UE overheating based on the service type, the UE state and the sensor information, and the current communication configuration; Based on the predicted risk of UE overheating, identifying (1750) a communication configuration recommended for use by the UE; and Information indicative of the identified communication configuration is sent to a base station BS (102).

14. The non-transitory computer-readable storage medium of claim 11, wherein: The operations further comprise at least one operation of the method according to one of claims 2 to 10.

Images