Power consumption control method of multi-mode communication module and electronic device

Abstract

This application discloses a power consumption control method and electronic device for a multi-standard communication module, relating to the field of communication technology. The method is applied to a terminal and includes: determining the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module; determining a matching target scenario based on the service characteristics of the current service; determining a corresponding standard switching decision based on the target scenario; detecting whether preset switching conditions are met; and performing standard switching on the communication module according to the standard switching decision if the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. The technical solution provided by this application dynamically determines the standard switching decision of a multi-standard communication module based on one-dimensional or multi-dimensional service characteristics, which can improve the accuracy and flexibility of power consumption control of the communication module.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a power consumption control method and electronic device for a multi-standard communication module. Background Technology

[0002] According to the 3rd Generation Partnership Project (3GPP) protocol, terminals can use various modes to classify different sleep levels and periodically sleep and wake up the communication module, thereby controlling the power consumption of the communication module. The various modes specified by 3GPP include: Connected-mode Discontinuous Reception (C-DRX), Idle-mode Discontinuous Reception (I-DRX), Extended Discontinuous Reception (eDRX), and Power Saving Mode (PSM). C-DRX mode periodically opens the receiver window to listen for network signals while connected to the network, and shuts down the receiver to enter sleep mode at other times, suitable for services requiring immediate response but with small data volumes. I-DRX mode periodically wakes up in idle mode to receive paging information, and there is no data transmission during sleep. eDRX mode significantly extends the paging cycle, and its sleep period is much longer than that of I-DRX mode. After completing the task, the terminal under PSM enters the chip-level ultra-low power state, and the wake-up cycle can be requested by the Tracking Area Update (TAU) signaling.

[0003] Currently, for multi-standard communication modules, 3GPP sets thresholds for signal quality, such as Reference Signal Received Power (RSRP) and Signal to Interference plus Noise Ratio (SINR), for switching between different standards. Specifically, the communication module performs standard switching by determining whether the signal quality meets the threshold. This standard switching method for multi-standard communication modules involves predefined thresholds, is statically managed, and has a fixed and relatively simple control method, resulting in low precision and poor flexibility in power consumption control. Summary of the Invention

[0004] The purpose of this application is to provide a power consumption control method and electronic device for multi-standard communication modules, so as to improve the accuracy and flexibility of power consumption control for multi-standard communication modules.

[0005] In a first aspect, embodiments of this application provide a power consumption control method for a multi-standard communication module, applied to a terminal, the method comprising: Based on the power consumption requirements of multi-standard communication modules, determine the service characteristics of the current service; Based on the business characteristics of the current business, a matching target scenario is determined, and based on the target scenario, a corresponding system switching decision is determined. Check whether the preset switching conditions are met; If the switching conditions are met, the communication module is switched according to the switching standard decision. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

[0006] Secondly, embodiments of this application provide a power consumption control device for a multi-standard communication module, applied to a terminal, the device comprising: The service characteristics module is used to determine the service characteristics of the current service based on the power consumption requirements of the multi-standard communication modules. The system switching decision module is used to determine the matching target scenario based on the business characteristics of the current service, and to determine the corresponding system switching decision based on the target scenario. The detection module is used to detect whether the preset switching conditions are met; A standard switching module is used to perform standard switching on the communication module according to the standard switching decision when the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

[0007] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps of the power consumption control method for the multi-standard communication module described in the first aspect.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the power consumption control method for the multi-standard communication module described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the power consumption control method for the multi-standard communication module described in the first aspect.

[0010] The technical solution provided in this application, based on the power consumption requirements of a multi-standard communication module, determines the service characteristics of the current service, determines a matching target scenario based on the service characteristics of the current service, determines a corresponding standard switching decision based on the target scenario, detects whether preset switching conditions are met, and performs standard switching on the communication module according to the standard switching decision if the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. This process, based on one-dimensional or multi-dimensional service characteristics, dynamically determines the standard switching decision for a multi-standard communication module, which can improve the accuracy and flexibility of power consumption control for multi-standard communication modules. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A schematic diagram of the architecture of a multi-standard communication module provided in the embodiments of this application; Figure 2 A flowchart illustrating a power consumption control method for a multi-standard communication module provided in an embodiment of this application; Figure 3 A flowchart illustrating the process of determining the service characteristics of the current service based on the power consumption requirements of a multi-standard communication module, as provided in an embodiment of this application. Figure 4 A flowchart illustrating the process of determining the service level of the current service based on task monitoring and protocol parsing, provided in an embodiment of this application; Figure 5 This is another schematic diagram illustrating a process for determining the service level of the current service based on task monitoring and protocol parsing, as provided in an embodiment of this application. Figure 6 A flowchart illustrating the process of determining the business level or business level range of the current task based on a triggering event, as provided in an embodiment of this application. Figure 7 A schematic diagram illustrating the process of determining the service level of the current service based on the parsing of transport layer protocols and application layer protocols, provided for embodiments of this application; Figure 8 A schematic diagram illustrating the process of feature scoring calculation based on IP packet header parsing provided in this application embodiment; Figure 9A schematic diagram illustrating the process of adjusting the service level of the current service based on sensor type, provided in an embodiment of this application; Figure 10 A schematic diagram illustrating the process of adjusting the service level of the current service based on the network registration status, provided in an embodiment of this application; Figure 11 A flowchart illustrating the process of determining the rate level of a current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service, provided in an embodiment of this application. Figure 12 A flowchart illustrating the process of determining the rate level of the current service based on the degree of matching between the predicted rate and the protocol rate level, as provided in this application embodiment. Figure 13 A schematic diagram illustrating the process of determining the rate level of the current service and adjusting it based on the service level and data transmission frequency, provided for an embodiment of this application; Figure 14 A flowchart illustrating the process of determining the corresponding system switching decision based on the target scenario, provided in an embodiment of this application; Figure 15 A schematic diagram illustrating the process of calculating and correcting the matching degree of business features provided in the embodiments of this application; Figure 16 A schematic diagram illustrating the intelligent fallback strategy in the standard switching decision provided in the embodiments of this application; Figure 17 This is a schematic diagram illustrating the process of performing neighbor cell measurement and optimization first, and then performing system switching on the communication module according to the system switching decision, provided for an embodiment of this application. Figure 18 A flowchart illustrating the process of using a decision engine to determine various decisions based on business characteristics, provided for embodiments of this application; Figure 19 A schematic diagram illustrating the process of performing neighbor cell measurement during the waiting period for an ACK message in a TCP service scenario provided in this application embodiment; Figure 20 A schematic diagram of the power consumption control device for a multi-standard communication module provided in the embodiments of this application; Figure 21 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] This application provides a power consumption control method, apparatus, and electronic device for multi-standard communication modules.

[0014] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0015] The power consumption control method and apparatus for multi-standard communication modules provided in this application can be applied to electronic devices, specifically terminals that include multi-standard communication modules. In this application, the terminal can also be referred to as a terminal device, user equipment (UE), mobile station, or mobile terminal, etc. Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities, etc. Terminals can be mobile phones, tablet computers, laptop computers, laptops, personal digital assistants (PDAs), handheld computers, netbooks, ultra-mobile personal computers (UMPCs), mobile internet devices (MIDs), augmented reality (AR) devices, virtual reality (VR) devices, robots, robot dogs, robotic arms, wearable devices, flight vehicles, drones, vehicle user equipment (VUEs), shipboard equipment, pedestrian user equipment (PUEs), smart home devices (home appliances with wireless communication capabilities, such as refrigerators, televisions, washing machines, or furniture), game consoles, personal computers (PCs), ATMs, or self-service machines, etc. Wearable devices include: smartwatches, smart bracelets, smart earphones, smart glasses, smart jewelry (smart bracelets, smart necklaces, smart anklets, smart ankle chains, etc.), smart wristbands, and smart clothing. In-vehicle user equipment can also be referred to as in-vehicle terminals, in-vehicle controllers, in-vehicle modules, in-vehicle components, in-vehicle chips, or in-vehicle units. This application does not specifically limit the specific technology or device form used in the terminal embodiments.

[0016] In this embodiment, the communication module within the terminal can communicate with connected peripheral devices via a wired connection, and / or wirelessly with the network side. The communication module can wirelessly communicate with the network-side device. This network-side device can be a base station (BS), a transmission and reception point (TRP), a next-generation NodeB (gNB) in a 5G mobile communication system, a next-generation base station in a 6G mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system; it can also be a module or unit that performs some of the functions of a base station, for example, a central unit (CU) or a distributed unit (DU). This embodiment does not specifically limit the specific technology or device form used by the network-side device.

[0017] The power consumption control method, apparatus, and electronic device for multi-standard communication modules provided in this application involve multiple protocol layers, including the transport layer and application layer. Descriptions of underlying communication protocols (such as the physical layer and data link layer) can be found in the relevant technical specifications of the 3rd Generation Partnership Project (3GPP); descriptions of the transport and application layer protocols can be found in relevant documents from the Internet Engineering Task Force (IETF).

[0018] The power consumption control method, apparatus, and electronic equipment for multi-standard communication modules provided in this application can be applied to various scenarios, including complex and variable application scenarios such as communication modules in fixed positions or in mobile states. For example, it can be used for power consumption control of communication modules in terminals such as smart water meters, smart electricity meters, smart gas meters, smart streetlights, smoke detectors, smart wearables, and vehicle-mounted devices. The aforementioned power consumption control method, apparatus, and electronic equipment for multi-standard communication modules dynamically determine the standard switching decision for multi-standard communication modules based on one-dimensional or multi-dimensional business characteristics, thereby improving the accuracy and flexibility of power consumption control for multi-standard communication modules.

[0019] Figure 1 This is a schematic diagram of the architecture of a multi-standard communication module provided in an embodiment of this application. Figure 1As shown in the embodiments of this application, the multi-standard communication module may include a core processor, a radio frequency module, a power supply module, a peripheral interface, random access memory (RAM), and flash memory (FLASH). The core processor may include: an intelligent service perception layer, a power consumption decision layer, a system software power consumption scheduling layer, power management, clock management, task management, and standard switching management.

[0020] The intelligent service awareness layer can determine the service characteristics of the current service based on the power consumption requirements of the communication module. These characteristics include one or more of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. These service characteristics serve as input to the power consumption decision layer, guiding subsequent power management strategies. For example, the intelligent service awareness layer performs in-depth analysis and quantification of features for protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Message Queuing Telemetry Transport (MQTT), and Constrained Application Protocol (CoAP) to determine the service level of the current service.

[0021] Among them, the power consumption decision layer determines the matching target scenario based on the service characteristics of the current service, determines the corresponding standard switching decision based on the target scenario, and can further determine the sleep decision of the communication module, i.e., the clock decision, the system task operation decision, the power module decision, etc.

[0022] The system software power scheduling layer, acting as the execution center of the power decision layer, translates power decision instructions into underlying hardware operations for system scheduling. It enables multi-dimensional collaborative control, including standard switching, a task scheduling engine, clock tree management, and power domain control. Standard switching allows for dynamic migration of communication standards. The task scheduling engine enables dynamic management of the operating status. Clock tree management allows for hierarchical control of the system's clock frequency. Power domain control enables fine-grained switching of power supplies to hardware modules.

[0023] Specifically, the switching of standards can be achieved by using zero-power service gap measurement technology, inserting neighbor cell measurements into the TCP acknowledgment (ACK) window, and using a dual-stack session migration mechanism to achieve seamless switching of standards.

[0024] Task management allows for task monitoring and scheduling. Clock tree management enables hierarchical control of the clock tree, managing clock domains based on business levels and hibernation decisions. Different hibernation levels have different clock frequencies; the higher the hibernation level, the lower the clock frequency.

[0025] The power module can manage power supply and dynamically control the power supply of peripheral interfaces, core processor, RAM, FLASH, and RF modules according to system software scheduling. It can also manage power consumption at different sleep levels through power switches and perform fine-grained power domain control, thereby reducing the power consumption of multi-standard communication modules.

[0026] The peripheral interfaces include, but are not limited to, high-speed and low-speed interfaces such as Reduced Gigabit Media Independent Interface (RGMII), Universal Serial Bus (USB), Universal Asynchronous Receiver / Transmitter (UART), and Inter-Integrated Circuit (I2C) to meet the different data transmission needs of the external devices of the communication module.

[0027] The aforementioned RAM provides the memory environment required for system operation. The aforementioned FLASH provides data storage. The RF module performs multi-standard RF conversion.

[0028] The communication module provided in this application embodiment can achieve dynamic power consumption management of the communication module through the collaborative cooperation of its internal layers and modules. While ensuring the real-time performance of emergency services, it can significantly reduce the overall power consumption of multi-standard communication modules in complex scenarios.

[0029] like Figure 2 As shown in the figure, this application provides a power consumption control method for a multi-standard communication module, applied to a terminal, which may include the following steps: Step S202: Determine the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module.

[0030] The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

[0031] In this application embodiment, the communication module may be of a standard including but not limited to: 5G network, Narrow Band Internet of Things (NB-IoT) network, Long Term Evolution (LTE) network, 2G, 3G, etc. This application embodiment does not specifically limit this.

[0032] Step S204: Determine the matching target scenario based on the business characteristics of the current business, and determine the corresponding system switching decision based on the target scenario.

[0033] In this application embodiment, the above-mentioned target scenarios can be various, such as smart medical emergency scenarios, agricultural sensor reporting scenarios, shared bicycle unlocking scenarios, security sensor alarm scenarios, etc. This application embodiment does not specifically limit them.

[0034] Step S206: Check whether the preset switching conditions are met.

[0035] In this embodiment of the application, the above-mentioned handover conditions can be preset as needed. For example, whether the RRC connection state is in the RRC_CONNECTED state, whether the RSRP of the serving cell is greater than -110dBm, whether the SINR of the serving cell is greater than 3dB, whether the number of active TCP or UDP sessions is greater than or equal to 2, whether the uplink buffer data volume is less than 512 bytes, whether the cell handover frequency is less than 1 time / 10s, whether VBAT is greater than 3.6V, whether the temperature Tj is less than 85℃, etc. This embodiment of the application does not make specific limitations on these.

[0036] Step S208: If the switching conditions are met, perform a standard switching on the communication module according to the standard switching decision.

[0037] For example, if the standard switching decision is to switch to a 5G network, the communication module will be switched from the current standard to the 5G network; or, if the standard switching decision is to switch to an NB-IoT network, the communication module will be switched from the current standard to the NB-IoT network.

[0038] like Figure 3 As shown in the embodiment of this application, the above step S202, based on the power consumption requirements of the multi-standard communication module, determines the service characteristics of the current service, and may include at least one of the following steps: Step S302: Determine the service level of the current business based on task monitoring and protocol parsing.

[0039] In this embodiment, the service level of the current service may include multiple levels, including but not limited to at least one of the following: emergency service, important service, secondary service, general service, and low-priority service. The power consumption requirements of the communication module corresponding to each service level are different, as shown in Table 1 below, where service levels A, B, C, D, and E represent different power consumption requirements.

[0040]

[0041] like Figure 4 As shown in the embodiment of this application, the above step S302, based on task monitoring and protocol parsing, determines the service level of the current service. This can be implemented and optimized using the following process: During initialization, service levels are categorized and set, such as the various service levels shown in Table 1. Then, based on the task monitoring module and deep protocol parsing, the current service of the communication module is judged to determine the preliminary service level. Next, based on the sensor and / or peripheral interface data of the communication module, the preliminary service level is adjusted. Furthermore, based on the modem of the communication module, the service level is adjusted again, thereby outputting the final service level.

[0042] Step S304: Determine the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service.

[0043] In this embodiment of the application, the above-mentioned rate levels can be preset as needed, including but not limited to at least one of the following: extremely low, low, medium, high, and extremely high. Specifically, an extremely low rate level can be a rate level less than 1 kbps, a low rate level can be a rate level from 1 kbps to 10 kbps, a medium rate level can be a rate level from 10 kbps to 100 kbps, a high rate level can be a rate level from 100 kbps to 1 Mbps, and an extremely high rate level can be a rate level greater than 1 Mbps. This embodiment of the application does not specifically limit this.

[0044] Step S306: Determine the latency level of the current service based on application layer behavior, network probe messages, or a preset correspondence.

[0045] In this embodiment, the aforementioned latency levels can be preset as needed, including but not limited to at least one of the following: high tolerance, medium tolerance, low tolerance, and real-time. Specifically, a high tolerance latency level can be a second-level latency level, a medium tolerance latency level can be a hundred-millisecond-level latency level, a low tolerance latency level can be a ten-millisecond-level latency level, and a real-time latency level can be a millisecond-level latency level. This embodiment does not specifically limit these values.

[0046] In this embodiment, the network probe message can be used to calculate the round-trip time (RTT) of the communication module under the current standard. The preset correspondence refers to the preset correspondence between different time periods and latency levels under various network standards, which is used to determine the latency level corresponding to the time period to which the current moment belongs under the current standard of the communication module.

[0047] In this embodiment of the application, step S306 above determines the latency level of the current service based on application layer behavior, network probe packets, or a preset correspondence, and may specifically include one of the following steps: 1) Analyze the application layer behavior of the current business, estimate the current business's tolerance for latency, and determine the latency level of the current business based on the current business's tolerance for latency.

[0048] Specifically, it can analyze parameters such as application layer ACK timeout settings, retransmission count, and QoS level to estimate the current service's tolerance for latency.

[0049] 2) Send network probe messages to obtain the round-trip time (RTT) under the current standard, and determine the latency level of the current service based on the RTT.

[0050] Among these features, probe messages can be periodically sent to the server to obtain the RTT value under the current network standard, which can be used to dynamically update the latency level.

[0051] 3) In the preset correspondence between different time periods and latency levels under various network standards, find the time period to which the current time belongs under the current standard of the communication module, and determine the latency level corresponding to the time period as the service level of the current service.

[0052] The pre-defined correspondence between different time periods and latency levels under various network standards can be stored in a database and used to train a latency level determination model.

[0053] In one embodiment of this application, after determining the latency level of the current service based on application layer behavior, network probe packets, or a preset correspondence in step S306, the following steps may also be included: 1) When a specified event is detected, determine the corresponding delay level adjustment strategy according to the preset correspondence between event type and delay level adjustment strategy, and adjust the delay level of the current service according to the delay level adjustment strategy.

[0054] 2) Determine whether the current service is an urgent service. If the current service is an urgent service, adjust the latency level of the current service to real-time or low latency.

[0055] If the current service is classified as a non-urgent service, the latency level of the current service can be flexibly adjusted according to the actual network conditions.

[0056] Step S308: Determine the traffic level of the current business based on the predicted total data volume requirement of the current business.

[0057] In this embodiment of the application, the above-mentioned flow rate levels can be preset as needed, including but not limited to at least one of the following: small, medium, large, and huge. This embodiment of the application does not specifically limit this.

[0058] In one implementation of this application embodiment, step S308, which determines the traffic level of the current service based on the predicted total data volume requirement of the current service, may specifically include the following steps: 1) Predict the total data volume requirement of the current business in the future period, and determine the traffic level of the current business based on the predicted total data volume requirement of the current business.

[0059] One approach is to use a periodic business modeling mechanism to establish mathematical models for businesses with fixed upload cycles, such as businesses that regularly report sensor data, and predict the total amount of data in the future.

[0060] 2) Adjust the traffic level of the current business according to the distribution of total data volume demand in uplink and / or downlink traffic.

[0061] For example, in video upload services where uplink traffic is high, the traffic level can be increased to optimize network resource allocation.

[0062] 3) Use a sliding window to identify sudden increases in traffic for the current service. If a sudden increase in traffic for the current service is detected, increase the traffic level of the current service.

[0063] The above-mentioned method of identifying burst traffic based on a sliding window can avoid performance degradation of the communication module due to misjudgment.

[0064] Step S310: Determine the mobility level of the current service based on the moving speed of the communication module.

[0065] In this embodiment of the application, the above-mentioned mobility level can be preset as needed, including but not limited to at least one of the following: stationary, low-speed movement, medium-speed movement, and high-speed movement. This embodiment of the application does not specifically limit this. Among them, low-speed movement can be movement with a speed of less than 30 km / h, medium-speed movement can be movement with a speed between 30 km / h and 60 km / h, and high-speed movement can be movement with a speed greater than 60 km / h.

[0066] In one embodiment of this application, the above step S310, which determines the mobility level of the current service based on the moving speed of the communication module, may specifically include the following steps: 1) Monitor whether cell handover occurs in the communication module. Obtain the cell handover frequency and signal strength changes of the communication module through the modem interface of the communication module to determine whether the communication module is in a mobile state. If the communication module is in a mobile state, calculate the mobile speed of the communication module based on the cell handover frequency and signal strength changes, and determine the mobility level of the current service based on the mobile speed of the communication module.

[0067] The cell handover frequency and signal strength changes of the communication module can be obtained through the AT commands of the communication module or the Modem interface, which can then be used to determine whether the communication module is in a mobile state. This will not be elaborated further here.

[0068] 2) When the communication module is connected to an accelerometer, determine whether the communication module is in motion based on the data output by the accelerometer. If the communication module is in motion, calculate the movement speed of the communication module and determine the mobility level of the current service based on the movement speed of the communication module.

[0069] The data output by the accelerometer can be XYZ axis acceleration, etc., which will not be elaborated here.

[0070] 3) When the communication module is connected to the Global Navigation Satellite System (GNSS) module, determine the mobility level of the current service based on the speed output by the GNSS module.

[0071] In one embodiment of this application, after determining the mobility level of the current service based on the moving speed of the communication module, step S310 may further include the following steps: 1) Obtain the type of device where the communication module is located.

[0072] 2) If the device type is vehicle-mounted, adjust the mobility level of the current service to high-speed mobility.

[0073] 3) If the device type is a wearable device, adjust the current service mobility level to medium speed or low speed.

[0074] This method of adjusting the mobility level of the current service based on the device type can further improve the efficiency of judgment.

[0075] Step S312: Determine the data interval level of the current business based on the predicted data interval of the current business.

[0076] In this embodiment, the data interval levels can be preset as needed, including but not limited to at least one of the following: continuously active, high frequency, medium frequency, low frequency, and occasional. This embodiment does not specifically limit these levels. Specifically, the high-frequency data interval level can be a second-level data interval level, the medium-frequency data interval level can be a minute-level data interval level, the low-frequency data interval level can be an hour-level data interval level, and the occasional data interval level can be a day-level data interval level.

[0077] In one embodiment of this application, the above step S312, which determines the data interval level of the current service based on the predicted data interval of the current service, may specifically include one of the following steps: 1) Use time series forecasting methods to predict the data interval of the current business, and determine the data interval level of the current business based on the predicted data interval of the current business.

[0078] The aforementioned time series forecasting method can specifically be an exponential smoothing method or an ARIMA model for forecasting. Of course, other methods can also be used, and this application does not specifically limit them.

[0079] 2) When the current business is an IoT business, obtain the data interval corresponding to the current business according to the preset correspondence between IoT business and data interval, and determine the data interval level of the current business based on the data interval of the current business.

[0080] Among them, a business model matching library can be pre-set, with built-in data interval models for common IoT businesses, such as temperature and humidity collection once per hour, and heart rate reporting once per day, which can quickly identify and match the current business type.

[0081] 3) If no data activity of the communication module is detected in multiple consecutive time windows, the data interval level of the current service is adjusted to occasional transmission or low-frequency transmission, and the sleep control process is entered, thus realizing the identification of the silent period.

[0082] In the embodiments of this application, all the above-mentioned implementation methods can adopt a dynamic update mechanism to dynamically update the data interval level prediction model according to the actual business execution, so as to ensure that the communication module can adapt to the interval fluctuations caused by business changes.

[0083] In the embodiments of this application, the above-mentioned intelligent interval identification mechanism based on time series prediction, service pattern matching and quiet period identification has multiple implementation methods, which can improve the communication module's ability to identify idle periods and its energy-saving efficiency.

[0084] It should be noted that there is no fixed execution order for steps S302 to S312 in the embodiments of this application. They can be executed in any order, either in parallel or sequentially. The embodiments of this application do not impose any specific limitations on this.

[0085] like Figure 5 As shown in the embodiments of this application, in one implementation, the above step S302, based on task monitoring and protocol parsing, determines the service level of the current service, and may specifically include the following steps: Step S502: If a triggering event for the current task is detected, determine the business level or business level range of the current task based on the triggering event.

[0086] Step S504: For cases where the service level range of the current task is determined, or where the service level of the current task cannot be determined based on the triggering event, the service level of the current service is determined based on the parsing of the transport layer protocol and the application layer protocol.

[0087] like Figure 6 As shown in the embodiments of this application, in one implementation, the above step S502, when a triggering event of the current task is detected, determines the business level or business level range of the current task based on the triggering event, which may specifically include the following steps a~e: a) If the triggering event is receiving an Attention (AT) command, determine the business level or business level range of the current task based on the keywords in the AT command.

[0088] Specifically, if the AT command is determined to be an emergency command based on the keyword in the AT command, then the current task's service level is determined to be an emergency service, and the service level can be marked as level A; if the AT command is determined to be a non-emergency command based on the keyword in the AT command, then the current task's service level is determined to be a non-emergency service, and the service level range can be marked as level CE.

[0089] b) If the triggering event is an OpenCPU Application Programming Interface (API) call by another task, determine the business level or business level range of the current task based on whether the OpenCPU API is a critical API.

[0090] Specifically, it can be determined whether the aforementioned OpenCPU API is a critical API. If it is a critical API, the current business is determined to be an important business and can be marked as level B. If it is not a critical API, the current business is determined to be a non-important business and can be marked as level CE.

[0091] c) If the triggering event is receiving sensor data, determine the business level or business level range of the current task based on whether the sensor data was collected by a security sensor.

[0092] Specifically, if the aforementioned sensor data is collected by security sensors, the current service is determined to be an emergency service and can be marked as Level A; if the aforementioned sensor data is not collected by security sensors, such as when gas meters, water meters, electricity meters, smoke detectors, etc., alarm, the current service is determined to be a non-emergency service and can be marked as Level CE.

[0093] d) If the triggering event is the receipt of uplink or downlink data, and the uplink or downlink data is transmitted based on a protocol other than a Quality of Service (QoS) sensitive protocol, then determine the service level range of the current task.

[0094] Specifically, if uplink or downlink data is transmitted based on a QoS-sensitive protocol, the service level of the current task cannot be determined based on the triggering event, and further determination of the service level is required based on protocol parsing; if uplink or downlink data is transmitted based on a protocol other than a QoS-sensitive protocol, the service level range of the current service can be determined to be DE level.

[0095] e) If the triggering event is receiving a Firmware Over-The-Air (FOTA) command, and the FOTA command is a command other than a download command, then determine the service level of the current task.

[0096] Specifically, if the FOTA command is a download command, the service level of the current task cannot be determined based on the triggering event. It is necessary to determine the service level based on the parsing of the transport layer protocol and the application layer protocol. If the FOTA command is a verification, backup, or upgrade command, these processes are not suitable for hibernation, i.e., hibernation is prohibited. The service level of the current task is determined to be an urgent task, and the service level can be marked as Level A.

[0097] like Figure 7 As shown in the embodiments of this application, in one implementation, the process of determining the service level of the current service based on the parsing of the transport layer protocol and the application layer protocol in step S504 above may include the following steps: Step S702: Identify the transport layer protocol used by the current service, determine the feature score of the transport layer protocol, and obtain the power consumption sensitivity coefficient of the transport layer protocol.

[0098] In this embodiment of the application, the power sensitivity coefficient of the above-mentioned transport layer protocol can be preset as needed, and the numerical value is not specifically limited in this embodiment of the application.

[0099] In this embodiment of the application, determining the feature score of the transport layer protocol in step S702 above may specifically include the following steps a~c: a) When the transport layer protocol is Transmission Control Protocol (TCP), the TCP characteristic score is determined based on the TCP state. Furthermore, the TCP characteristic score can also be determined based on the TCP state and retransmission rate.

[0100] In this embodiment, determining the TCP characteristic score based on the TCP state can specifically include: If the TCP state is SYN_SENT (synchronization sent), the TCP characteristic score can be the highest (+2.0), because at this time the communication module needs to frequently perform handshake interactions, the RF module is continuously active, and the power consumption reaches its peak, such as 300% higher than the idle state. If the TCP state is ESTAB (connection established), the TCP characteristic score can be medium (+1.5), at this time, maintaining data transmission requires the RF module and baseband processing unit to work continuously, and the power consumption increases significantly, such as 150% higher than the idle state. If the TCP state is FIN_WAIT (termination waiting), the TCP characteristic score can be the lowest (+0.5), at this time, resources are gradually released, and the power consumption is low.

[0101] In addition, TCP's feature score can also be calculated based on the retransmission rate. For example, when the retransmission rate is >20%, i.e., a high retransmission rate, the TCP feature score can be the highest (+1.5), and when the retransmission rate is <5%, i.e., a low retransmission rate, the TCP feature score can be the lowest (+0.3).

[0102] Furthermore, idle period optimization can be performed. When the TCP state is ESTAB and there is no data transmission for more than 3 times the timeout retransmission time, the TCP feature score can be reduced by 0.8.

[0103] For example, if the current service of the communication module is the TCP connection establishment process, the initial feature score is 0 → entering the SYN_SENT state results in a feature score of (+2.0) → entering the ESTAB state results in a feature score of (+1.5) → entering the idle state and the duration is greater than 3 times the timeout retransmission time results in a feature score of (-0.8) → entering the FIN_WAIT state results in a feature score of (+0.5).

[0104] In this embodiment of the application, when the transport layer protocol is TCP, the power sensitivity coefficient K_trans of the above-mentioned transport layer protocol can be set to 0.90 to increase the basic power consumption for maintaining the connection state and ACK mechanism. Of course, the power sensitivity coefficient K_trans of the above-mentioned transport layer protocol can also be set to other values. This embodiment of the application does not make specific limitations on this.

[0105] b) When the transport layer protocol is User Datagram Protocol (UDP), determine the UDP feature score based on the UDP port type and payload mode.

[0106] In this embodiment, determining the UDP characteristic score based on the UDP port type and payload mode can specifically include: If the UDP port type is a designated port or a well-known port, such as DNS port 53, the UDP characteristic score can be medium (+0.5). These system-level services require real-time response, and the communication module must maintain a receiving state to ensure service availability. For example, DNS query response latency is required to be <100ms. If the UDP port type is a dynamic port, the UDP characteristic score is 0. Application layer data can be optimized through service scheduling to reduce power consumption, such as batch data aggregation and transmission. If the UDP payload mode is VoIP payload mode, the UDP characteristic score can be highest (+1.8) because the communication module needs to continuously transmit voice packets, for example, transmitting a data packet every 20-50ms, forcing the RF module to work continuously and preventing it from entering sleep mode. If the UDP payload mode is sensor reporting mode, the UDP characteristic score can be lowest (+0.3). Bursting small data packets, such as data packets smaller than 100 bytes, allow the communication module to enter deep sleep during transmission intervals, such as PSM mode.

[0107] In this embodiment, when the transport layer protocol is UDP, the power sensitivity coefficient K_trans of the aforementioned transport layer protocol can be set to 0.4. UDP has no connectionless state maintenance and retransmission mechanism, resulting in minimal header overhead and minimal impact on the power consumption of the communication module. For example, the UDP header overhead is only 8 bytes, 80% smaller than the TCP header, making it particularly suitable for low-frequency data transmission scenarios. Of course, the power sensitivity coefficient K_trans of the aforementioned transport layer protocol can also be set to other values; this embodiment does not specifically limit this.

[0108] c) When the transport layer protocol is Internet Control Message Protocol (ICMP), determine the ICMP feature score based on the ICMP message type.

[0109] In this embodiment of the application, determining the ICMP feature score based on the ICMP message type can specifically include: if the ICMP message type is a request message or a response message, the ICMP feature score is increased by 0.8. For example, a ping request requires real-time response processing by the kernel protocol stack and is sensitive to latency. If the ICMP message type is an error report type, the ICMP feature score is increased by 0.3. For example, a destination unreachable message can be processed with a delay and does not affect the continuity of services.

[0110] In this embodiment of the application, when the transport layer protocol is ICMP, the power sensitivity coefficient K_trans of the above transport layer protocol can be set to 0.40. Although the protocol is simple, the kernel protocol stack processing requires CPU interrupt resources and still needs to be optimized on low-power devices. Of course, the power sensitivity coefficient K_trans of the above transport layer protocol can also be set to other values. This embodiment of the application does not make specific limitations on this.

[0111] Step S704: Identify the application layer protocol used by the current service, determine the feature score of the application layer protocol, and obtain the power sensitivity coefficient of the application layer protocol.

[0112] In this embodiment, the power sensitivity coefficient of the above application layer protocol can be preset as needed, and the numerical value is not specifically limited in this embodiment.

[0113] In one embodiment of this application, the determination of the feature score of the application layer protocol in step S704 may specifically include the following steps a~e: a) When the application layer protocol is Hypertext Transfer Protocol (HTTP), determine the feature score of HTTP according to the HTTP method.

[0114] In this embodiment, determining the HTTP feature score based on the HTTP method can specifically include: If the HTTP method is POST or PUT, the HTTP feature score can be the highest (+1.2), typically used for scenarios with large payload transmissions such as file uploads, image or video transmissions, requiring the communication module to maintain a high power consumption state for an extended period, such as an average high power consumption state lasting more than 5 seconds. If the HTTP method is HEAD, the HTTP feature score can be the lowest (+0.5), only obtaining TCP header information, with a typical payload of less than 1KB, extremely small data volume, and can be completed quickly. If the HTTP method is Content-Type, the HTTP feature score can include: video stream type, with the highest feature score (+1.5), high bitrate continuous transmission, such as 1-5Mbps, requiring forced maintenance of high power consumption standards such as 5G networks, or maintaining LTE Cat.4 or higher standards, etc. If the HTTP method is JSON type, the HTTP feature score can be medium (+0.8), structured data can be optimized through compression and batch processing.

[0115] In this embodiment, when the application layer protocol is HTTP, the power sensitivity coefficient K_app of the aforementioned application layer protocol can be set to 0.70. Although it is based on TCP, the request-response pattern has a defined idle period, such as a typical request interval greater than 10 seconds, which can optimize power consumption through a sleep strategy. Of course, the power sensitivity coefficient K_app of the aforementioned application layer protocol can also be set to other values, and this embodiment does not specifically limit this.

[0116] b) When the application layer protocol is Message Queuing Telemetry Transport (MQTT) protocol, determine the feature score of the MQTT protocol based on the QoS level and will flag of the MQTT protocol.

[0117] In this embodiment, determining the characteristic score of the MQTT protocol based on its QoS level and will flag can specifically include: If the QoS level of the MQTT protocol is QoS2, the characteristic score can be the highest (+1.5), requiring a four-way handshake interaction: PUBLISH→PUBREC→PUBREL→PUBCOMP, doubling the message volume and increasing the load by 100% compared to QoS0. If the QoS level of the MQTT protocol is QoS1, the characteristic score can be medium (+1.2). If the QoS level of the MQTT protocol is QoS0, the characteristic score can be the lowest (+0.3), with no acknowledgment mechanism, such as a single transmission, significantly reducing the power consumption of the communication module. If the will flag is enabled in MQTT (WILL=1), the characteristic score can be the highest (+1.8), requiring continuous maintenance of message status and increased heartbeat frequency, such as shortening the typical heartbeat interval from 10 minutes to 5 minutes.

[0118] In this embodiment, the power sensitivity coefficient K_app of the aforementioned application layer protocol can be set to 0.75. The MQTT protocol is an IoT protocol optimized for the Internet of Things (IoT). The MQTT header is only 2 bytes, but the will mechanism adds 15-20% extra power consumption. Of course, the power sensitivity coefficient K_app of the aforementioned application layer protocol can also be set to other values, and this embodiment does not specifically limit this.

[0119] c) When the application layer protocol is the Restricted Application Protocol (CoAP), determine the CoAP feature score based on the CoAP message type and observation tag.

[0120] In this embodiment, determining the CoAP feature score based on the CoAP message type and observation flag can specifically include: If the CoAP message type is CON (requires acknowledgment), the CoAP feature score can be relatively high (+1.5), similar to TCP which requires maintaining a retransmission timer, such as a default maximum of 4 retransmissions. If the CoAP message type is NON (does not require acknowledgment), the CoAP feature score can be relatively low (+0.7), similar to UDP which is simple, efficient, and requires zero state maintenance. If the CoAP includes an Observe flag, the CoAP feature score can be relatively high (+1.5), requiring long-term maintenance of the subscription state and periodic refresh, such as sending an update every 30 seconds.

[0121] In this embodiment, the power sensitivity coefficient K_app of the aforementioned application layer protocol can be set to 0.50. Based on the simplified CoAP protocol, the CoAP header is only 4 bytes, resulting in the lowest basic power consumption. However, observation mode increases persistent overhead. Of course, the power sensitivity coefficient K_app of the aforementioned application layer protocol can also be set to other values; this embodiment does not specifically limit this.

[0122] d) When the application layer protocol is a Lightweight Machine-to-Machine (LwM2M) protocol, determine the feature score of the LwM2M protocol based on the operation type and object path of the LwM2M protocol.

[0123] In this embodiment, determining the LwM2M protocol feature score based on the LwM2M protocol operation type and object path can specifically include: If the LwM2M protocol operation type is Write / Execute device control, the LwM2M protocol feature score can be the highest (+1.8), requiring real-time response, such as a delay of less than 1 second, and prohibiting sleep, such as for device restart commands. If the LwM2M protocol operation type is Read data reading, the LwM2M protocol feature score can be medium (+1.0), allowing appropriate delays, such as greater than 5 seconds. If the LwM2M protocol object path is the firmware update path ( / 5 / 0 / 3), the LwM2M protocol feature score can be the highest (+2.0), requiring large-volume data transfers greater than 10MB, uninterrupted transmission, and additional storage overhead for power-off resumption. If the LwM2M protocol object path is the battery status path ( / 3 / 0 / 11), the LwM2M protocol feature score can be lower (+0.6), allowing for optimization of small data volume reads, such as data volumes less than or equal to 100 bytes.

[0124] In this embodiment, when the application layer protocol is LwM2M, the power sensitivity coefficient K_app of the aforementioned application layer protocol can be set to 0.85. Device management operations directly affect the integrity of system functions; for example, a firmware update failure could brick the device. Therefore, the highest sensitivity requires reliable transmission guarantees. Of course, the power sensitivity coefficient K_app of the aforementioned application layer protocol can also be set to other values; this embodiment does not specifically limit this.

[0125] e) When the application layer protocol is File Transfer Protocol (FTP), determine the feature score of FTP based on the FTP transfer mode and file size.

[0126] In this embodiment, determining the FTP characteristic score based on the FTP transfer mode and file size can specifically include: If the FTP transfer mode is active, the FTP characteristic score can be high (+1.5), requiring the client to open ports, such as through the PORT command, increasing NAT traversal attempts and additional handshake rounds, such as extending connection establishment time by 40%. If the FTP transfer mode is passive, the FTP characteristic score can be medium (+1.0), with the server undertaking more work, such as through the PASV command, reducing client resource consumption. If the FTP file size is greater than 10MB, the FTP characteristic score can be highest (+2.0), and for long transfers exceeding 30 seconds, the communication module needs to disable sleep mode to prevent disconnection. If the FTP file size is less than 1MB, the FTP characteristic score can be lowest (+0.8), and for short transfers less than 3 seconds, the communication module can be in deep sleep mode, such as eDRX mode.

[0127] In this embodiment, when the application layer protocol is FTP, the power sensitivity coefficient K_app of the aforementioned application layer protocol can be set to 0.85. Large file transfers directly affect the continuous working time of the communication module and are a key point for power consumption optimization. Of course, the power sensitivity coefficient K_app of the aforementioned application layer protocol can also be set to other values, and this embodiment does not specifically limit this.

[0128] It should be noted that the feature scores in this embodiment are quantitative evaluation values ​​of specific protocol behaviors, without a base score concept. The initial score = 0, and each feature is scored independently, with each being an independent addition or subtraction item. The addition and subtraction operations reflect the degree of its impact on power consumption. Among them, a positive score (+) indicates increased power consumption, such as the handshake in TCP, where the feature score is +2.0. A negative score (-) indicates decreased power consumption, such as the idle state in TCP, where the feature score is -0.8.

[0129] In this embodiment, the feature score of the transport layer protocol and the power sensitivity coefficient K_trans of the transport layer protocol can be set according to Table 2 below, and the feature score of the application layer protocol and the power sensitivity coefficient K_app of the application layer protocol can be set according to Table 3 below. This embodiment does not impose specific limitations on these settings.

[0130]

[0131]

[0132] In this embodiment, the mechanism of independent scoring of the transport layer protocol and the application layer protocol, as well as the combination of multiple service characteristics, are implemented using a multi-dimensional service perception and dynamic classification model. This solves the defects of relying on a single network signal or simple service classification. Through multi-source data fusion, the accuracy of service classification is improved, and the probability of errors is reduced, such as avoiding misjudging video streams as low-priority services.

[0133] Step S706: Calculate the fusion coefficient based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol.

[0134] In one embodiment of this application, step S706 may specifically include the following steps: The fusion coefficient is calculated based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol according to the following formula; K_final=α×K_trans+β×K_app; Where K_final represents the fusion coefficient, K_trans represents the power sensitivity coefficient of the transport layer protocol, K_app represents the power sensitivity coefficient of the application layer protocol, α represents the weight of the power sensitivity coefficient K_trans of the transport layer protocol, and β represents the weight of the power sensitivity coefficient K_app of the application layer protocol.

[0135] In this embodiment, the weight α of the power sensitivity coefficient K_trans of the transport layer protocol and the weight β of the power sensitivity coefficient K_app of the application layer protocol can be set as needed, and the numerical values ​​are not specifically limited in this embodiment. For example, α=0.4 and β=0.6 can be set.

[0136] For example, in the three scenarios of TCP bare transmission, HTTP service and CoAP observation mode, the power sensitivity coefficient K_trans of the transport layer protocol and the power sensitivity coefficient K_app of the application layer protocol are weighted and summed according to the weights α and β respectively to obtain the fusion coefficient K_final. The specific values ​​are shown in Table 4.

[0137]

[0138] In this embodiment, a layered power sensitivity coefficient fusion mechanism is adopted for transport layer protocols and application layer protocols. This can overcome the misjudgment problem of single-layer protocol parsing, such as ignoring application layer video stream features by only detecting the TCP layer. Through the layered power sensitivity coefficient fusion mechanism, the accuracy of feature score calculation is improved, and complex business scenarios can be accurately identified. For example, the HTTP video stream business score reaches 4.2 (A level), while the traditional single-layer model can only output 2.8 (C level).

[0139] Step S708: Calculate the comprehensive protocol score based on the feature scores of the transport layer protocol, the feature scores of the application layer protocol, and the fusion coefficient.

[0140] In one embodiment of this application, step S708 may specifically include the following steps: Based on the feature scores of transport layer protocols, the feature scores of application layer protocols, and the fusion coefficient, the comprehensive protocol score is calculated according to the following formula: S=[Σ(Fi×Wi)]×K_final×Cenv; Where S represents the protocol comprehensive score, i represents the index of the feature score in the feature score set, the feature score set includes the feature scores of the transport layer protocol and the feature scores of the application layer protocol, Fi represents the i-th feature score in the feature score set, Wi represents the weight of the i-th feature score Fi, Σ(Fi×Wi) represents the total feature score, K_final represents the fusion coefficient, and Cenv represents the environmental compensation factor.

[0141] In this embodiment of the application, the weights Wi of each feature score Fi can be initially set to default values, such as Wi=0.5, indicating that all features are equally important. Then, they can be adjusted according to the actual situation, such as adjusting W1=0.5 to W1=0.3 and W2=0.5 to W2=0.8 according to real-time requirements.

[0142] For example, if the current service of the communication module is security sensor reporting, the characteristic of the transport layer protocol UDP is sensor reporting, corresponding to a feature score of (+0.3), and the characteristic of the application layer protocol CoAP is that the message type is NON, corresponding to a feature score of (+0.7). The weights of these two features are W1 and W2, respectively, and both weights are initially set to the default value of 0.5. The total feature score for the current service is calculated as follows: The total feature score Σ(Fi×Wi) = (0.5×0.3) + (0.5×0.7) = 0.5.

[0143] Based on the real-time requirements of the current business, the weights W1 and W2 can be adjusted respectively, such as decreasing W1 and increasing W2. After the adjustment, W1=0.4 and W2=0.8. The total feature score of the current business can then be updated as follows: The adjusted feature total score Σ(Fi×Wi) = (0.4×0.3) + (0.8×0.7) = 0.65.

[0144] In this embodiment, the environmental compensation factor Cenv may include multiple reference values, and this embodiment does not specifically limit them. For example, the environmental compensation factor Cenv can be set in one of the following ways: 1) High temperature, such as a temperature greater than 45℃, then the environmental compensation factor Cenv = 1.2; 2) Low voltage, such as voltage less than 3.3V, then the environmental compensation factor Cenv=1.1; 3) If the ambient temperature is stable, then the environmental compensation factor Cenv = 1.0; 4) Low temperature, such as temperature less than -20℃, then the environmental compensation factor Cenv=0.9.

[0145] In this embodiment, the comprehensive score of the protocol calculated using the aforementioned environmental compensation factor can take into account the influence of factors such as temperature and voltage, resulting in more accurate calculations and improved reliability under extreme operating conditions. Furthermore, increasing the environmental compensation factor under high-temperature conditions and decreasing it under low-temperature conditions avoids risks such as equipment overheating and shutdown in high-temperature environments.

[0146] The following examples illustrate the specific applications of the above formulas.

[0147] For example, if the current service of the communication module is HTTP video streaming, the transport layer protocol and application layer protocol involve three features: ESTAB, POST, and video stream. The corresponding weights W1, W2, and W3 are initially set to their default values ​​of 1 / 3. The power sensitivity coefficient of the transport layer protocol is K_trans = 0.9, the power sensitivity coefficient of the application layer protocol is K_app = 0.7, the weight of the power sensitivity coefficient K_trans of the transport layer protocol is α = 0.4, and the weight of the power sensitivity coefficient K_app of the application layer protocol is β = 0.6. The specific calculation of the total feature score for the current service is as follows: Σ(Fi×Wi) = W1×ESTAB(+1.5) + W2×POST(+1.2) +W3×videostream(+1.5) =4.2; The fusion coefficient is calculated as follows: K_final=α×K_trans+β×K_app = (0.4×0.90) + (0.6×0.70) = 0.78; The overall score for the agreement is calculated as follows: S = [Σ(Fi×Wi)]×K_final×Cenv = 4.2 × 0.78 × Cenv.

[0148] K_final = 0.4×K_trans + 0.6×K_app.

[0149] Step S710: According to the preset mapping rules, determine the business level corresponding to the protocol comprehensive score as the business level of the current business.

[0150] In this embodiment, the preset mapping rules can take various forms, and this embodiment does not specifically limit them. For example, setting the protocol comprehensive score S with the corresponding business level A / B / C / D / E can be done as follows: 1) S>4.0 corresponds to a business level of A; 2) 3.0 3) 2.0 4) 1.0 5) S ≤ 1.0 corresponds to business level E.

[0151] In the application embodiments, in the scenario of determining the service level of the current service based on protocol parsing, the process of calculating the feature scores of the transport layer protocol and the application layer protocol can be as follows: Figure 8 As shown in the diagram. First, the header of the IP packet for the current task is extracted to identify the transport layer protocol as TCP, UDP, or ICMP. If it's TCP, its state machine flags are extracted or retransmission rate is parsed for feature scoring. If it's UDP, the port type and payload mode are analyzed for feature scoring. If it's ICMP, type parsing is performed for feature scoring. Then, the application layer protocol is identified as HTTP, MQTT, CoAP, LwM2M, or FTP. If it's HTTP, the HTTP method is obtained for feature scoring. If it's MQTT, the QoS level and will flag are obtained for feature scoring. If it's CoAP, the message type and Observe flag are obtained for feature scoring. If it's LwM2M, the operation type and object path are obtained for feature scoring. If it's FTP, the FTP transfer mode and file size are obtained for feature scoring.

[0152] In one embodiment of this application, after determining the service level of the current service based on task monitoring and protocol parsing, step S302 may further include the following steps: If a trigger event for the current business is detected and the trigger event is the receipt of sensor data, identify the type of sensor that collects the sensor data; Determine the current power consumption requirements of the communication module based on the type of sensor; Adjust the service level of the current service according to the current power consumption requirements of the communication module.

[0153] ​​​In this application embodiment, the types of sensors are varied, including but not limited to: accelerometers, ambient light sensors, position sensors, image sensors, and temperature sensors. Among these, position sensors include, for example, Global Navigation Satellite System (GNSS) modules.

[0154] like Figure 9 As shown, when the communication module receives sensor data for its current service, the sensor interface reveals whether the connected sensor is via I2C bus, SPI bus, or UART serial port. This allows the module to read sensor status and obtain corresponding sensor data, such as acceleration, ambient light level, and location information, and to determine the sensor type. Based on the sensor data or sensor type, the functional requirements of the communication module can be evaluated, and the service level can be adjusted according to the module's current power consumption requirements. For example, if the accelerometer sensor detects an impact, the service level of the communication module is upgraded to Level A, i.e., emergency service level. If the ambient light sensor detects a dark environment, the service level is downgraded to Level E, i.e., low priority service level. If the acceleration obtained from the accelerometer or the speed obtained from the GNSS module indicates that the communication module is currently in a high-speed moving state (e.g., a speed greater than 60 km / h), the service level can be upgraded by one level. If the communication module is determined to be stationary, the service level can be downgraded by one level. Furthermore, based on the obtained sensor data, the starting and stopping of the communication module's sensing peripherals can be controlled, such as controlling the opening or closing of the GNSS module.

[0155] In this embodiment of the application, the current power consumption requirements of the communication module are analyzed according to the peripheral type of the communication module, and then the service level of the current service is adjusted. Specific examples are shown in Table 5 below.

[0156]

[0157] like Figure 10 As shown in the embodiment of this application, after determining the service level of the current service based on task monitoring and protocol parsing, step S302 may further include the following steps a~e: a) Detect network registration status through the modem of the communication module.

[0158] b) If the network registration status is unregistered, adjust the current business level to the important business level, i.e., level B.

[0159] c) If the network registration status is already registered, detect the Packet Data Protocol (PDP) context and obtain the Quality of Service Class Identifier (QCI) from the PDP context.

[0160] d) If QCI is less than or equal to level 4, adjust the current business level to emergency business level (level A) or important business level (level B).

[0161] In this embodiment of the application, one of the QoS parameters, QCI, typically ranges from 1 to 9. When QCI is 1 to 4, the service level can be forcibly marked as level A or level B. Specifically, it can be marked according to the following rules: 1) QCI 1, voice call service, service level A; 2) QCI 2, video call service, service level A; 3) QCI 3, real-time service, service level B; 4) QCI 4, video stream, business level B.

[0162] e) If the QCI is greater than 4, determine whether an anomaly has occurred. If an anomaly has occurred, increase the business level of the current business. If no anomaly has occurred, keep the business level of the current business unchanged.

[0163] In this embodiment of the application, the above-mentioned abnormality can occur in various ways, such as RRC reconstruction failure, TAU timeout, handover failure, etc. Correspondingly, it can trigger a temporary upgrade or downgrade of the service level. Specific examples are shown in Table 6 below.

[0164]

[0165] like Figure 11 As shown in the embodiments of this application, in one implementation, the above step S304, based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service, determines the rate level of the current service, and may specifically include the following steps: Step S1102: Estimate the predicted rate of the current service based on the historical rate of the communication module.

[0166] In this embodiment, future rate trends can be predicted based on time series analysis technology by analyzing the historical transmission behavior of the communication module. For example, an Autoregressive Integrated Moving Average (ARIMA) model can be used for time series forecasting. This adaptive windowing mechanism effectively balances prediction accuracy and real-time requirements, making it particularly suitable for industrial scenarios with abrupt changes in transmission patterns. The dynamic windowing mechanism used can calculate the window size according to the following formula: Window size = max (60s, 2 × historical average interval); Furthermore, the analysis window can be set to contain at least 60 seconds of data, and no less than twice the historical average interval, thereby improving the accuracy of predictions.

[0167] The prediction period can be calculated using the following formula: Forecast period = min(300s, business interval × 3); Furthermore, the prediction range can be limited to no more than 5 minutes and no more than 3 times the transmission interval of the service itself.

[0168] Step S1104: Based on the preset correspondence between application layer protocols and rate levels, obtain the rate level corresponding to the application layer protocol used by the current service, adjust the rate level based on the characteristics of the application layer protocol, and obtain the protocol rate level.

[0169] In this embodiment, the core purpose and technical characteristics of network protocol design can be analyzed, and in combination with the actual application mode in the Internet of Things field, data size, transmission frequency and interaction mode can be considered to set the correspondence between protocol type and rate level, and an adjustment mechanism that can change with business characteristics can be established.

[0170] For example, multiple rate levels can be preset, each rate level corresponds to a rate range, and each rate level corresponds to a protocol type. The corresponding rate level can be dynamically adjusted according to the characteristics of the protocol, as shown in Table 7 below.

[0171]

[0172] Step S1106: Determine the current service rate level based on the degree of matching between the predicted rate and the protocol rate level.

[0173] like Figure 12 As shown in the embodiments of this application, in one implementation, the above step S1106, which determines the rate level of the current service based on the degree of matching between the predicted rate and the protocol rate level, may specifically include the following steps: Step S1202: Compare the predicted rate with the rate intervals corresponding to each rate level in the correspondence relationship, and determine the rate level corresponding to the rate interval into which the predicted rate falls as the temporary rate level.

[0174] Step S1204: Determine whether the temporary rate level is the same as the protocol rate level. If the temporary rate level is the same as the protocol rate level, proceed to step S1206. If they are different, proceed to step S1208.

[0175] Step S1206: Determine the protocol rate level as the rate level of the current service, and the process ends.

[0176] Step S1208: Determine whether the difference between the temporary rate level and the protocol rate level exceeds one level. If the difference between the temporary rate level and the protocol rate level exceeds one level, proceed to step S1210. If the difference between the temporary rate level and the protocol rate level does not exceed one level, proceed to step S1212.

[0177] Step S1210: Based on historical matching degree, calculate the intermediate rate within the rate interval corresponding to the predicted rate and the protocol rate level to obtain the optimized rate. Determine the rate level corresponding to the rate interval into which the optimized rate falls as the rate level of the current service, and the process ends.

[0178] In one embodiment of this application, the calculation of the intermediate rate within the rate range corresponding to the predicted rate and the protocol rate level in step S1210 to obtain the optimized rate may specifically include: For the intermediate rate within the rate range corresponding to the predicted rate and the protocol rate level, the following formula is used to perform a confidence-weighted calculation to obtain the optimized rate: Optimization rate = w1 × prediction rate + (1 - w1) × intermediate rate; Where w1 represents the historical matching degree.

[0179] Step S1212: Determine the maximum value between the temporary rate level and the protocol rate level as the rate level of the current service, and the process ends.

[0180] In one embodiment of this application, step S1212 can be represented by the following formula: Rate class = max(temporary rate class, protocol rate class).

[0181] In this embodiment of the application, the above process constructs a dynamic rate optimization engine, which achieves intelligent optimization of rate levels by deeply analyzing historical transmission patterns and protocol characteristics and combining them with business scenario requirements.

[0182] In one embodiment of this application, after determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service in step S304, the following steps a~b may be further included: a) If the current service level is an emergency service level, then the maximum value between the current service rate level and the higher rate level is taken as the adjusted current service rate level.

[0183] For example, if the current service level is A, the current service rate level can be adjusted according to the following formula: Adjusted rate level = max(current service rate level, high).

[0184] b) If the current service's service level is a low priority service level, then the minimum value between the current service's rate level and the current service's rate level will be used as the adjusted rate level for the current service.

[0185] For example, if the current service level is E, the current service rate level can be adjusted according to the following formula: Adjusted speed rate = min (current service speed level, medium).

[0186] In another implementation of this application embodiment, after determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service in step S304, it may further include the following steps a~d: a) Determine the data transmission frequency for the current service.

[0187] b) If the current service uses a low-frequency transmission frequency, then the current service rate level remains unchanged.

[0188] c) If the data transmission frequency of the current service is high-frequency transmission, then the maximum value between the current service's rate level and the rate level shall be taken as the adjusted rate level of the current service.

[0189] d) If the data transmission frequency of the current service is intermittent, then adjust the rate level of the current service to extremely low.

[0190] For example, determine the data transmission frequency of the current service, and adjust the rate level of the current service according to the following rules: 1) Data transmission frequency is low-frequency: maintain the current service rate level unchanged; 2) Data transmission frequency is high-frequency transmission: Adjusted rate level = max(rate level, medium); 3) Data transmission frequency is occasional: Adjusted rate level = extremely low.

[0191] like Figure 13 As shown in the embodiments of this application, the above-mentioned determination of the current service rate level based on the predicted rate and protocol rate level of the communication module, and the adjustment of the current service rate level based on the service level and data transmission frequency, can be used in combination to further improve the accuracy of the current service rate level.

[0192] In this embodiment of the application, the network probe packets involved in step S306 above can be configured in various ways, such as setting the network probe packets according to the method in Table 8 below, and adjusting the latency level according to the mechanism in Table 9 below.

[0193]

[0194]

[0195] like Figure 14 As shown in the embodiment of this application, step S204, which determines the matching target scenario based on the business characteristics of the current business and determines the corresponding standard switching decision based on the target scenario, may specifically include the following steps: Step S1402: Determine the current scenario of the communication module based on the business characteristics of the current service.

[0196] Step S1404: Compare the business characteristics of the current business with the business characteristics of each scenario in the preset scenario-based decision knowledge base, and calculate the matching degree of business characteristics of each scenario.

[0197] In one embodiment of this application, step S1404 may specifically include the following steps: The business characteristics of the current business are compared with the business characteristics of various scenarios in the pre-set scenario-based decision knowledge base, and the matching degree of business characteristics for each scenario is calculated according to the following formula: ; in, This represents the business feature matching degree for any scenario within each scenario, where i represents the index of the business feature, and n represents the total number of business features, n≤6. This represents the weight of the i-th business feature. This represents the value of the i-th business feature in any scenario. This represents the value of the i-th service feature in the current scenario. Specifically, there are six service features: service level, rate level, latency level, traffic level, mobility level, and data interval level, with indices i=1,…,6, and corresponding weights respectively. , , , , and The weights of each business feature can be adaptively and dynamically adjusted according to preset rules. Specifically, the preset adjustment range and mechanism are shown in Table 10 below.

[0198]

[0199] To further improve accuracy, in one embodiment of this application, after calculating the business feature matching degree of each scenario in step S1404, the business feature matching degree of each scenario can be corrected. The specific steps are as follows: The matching degree of business features for each scenario is corrected according to the following formula: ; in, This represents the degree of matching of business features in any scenario within each scenario, while Confidence represents the confidence level based on historical decision accuracy. This indicates the degree of matching of business features for any scenario after correction.

[0200] In this embodiment of the application, the process of calculating and correcting the business feature matching degree described above can be as follows: Figure 15 As shown. The preset scenario-based decision knowledge base may include multiple scenarios, such as 200 scenario templates, etc., and this application embodiment does not specifically limit this. For example, typical scenarios in the scenario-based decision knowledge base can be shown in Table 11 below.

[0201]

[0202] In this embodiment, the above-mentioned calculation method based on six business characteristics realizes a six-dimensional dynamic decision engine, breaking through the limitations of the existing static rule base. The adaptive adjustment mechanism of dynamic weights adjusts the weights in real time according to the business characteristics. Combined with the scenario-based decision knowledge base (200+ IoT templates), adaptive decision-making is realized, and the accuracy of sleep window configuration is improved in sudden traffic scenarios such as shared bicycle unlocking.

[0203] Step S1406: Compare the business feature matching degree of each scenario, and determine the scenario with the highest business feature matching degree as the target scenario that matches the current scenario.

[0204] If the matching degree of business features in each scenario has been corrected, then the comparison is made based on the corrected matching degree of business features in each scenario.

[0205] Step S1408: In the scenario-based decision knowledge base, find the standard switching decision corresponding to the target scenario, and use the standard switching decision as the standard switching decision for the current business.

[0206] In this embodiment of the application, the system switching decision involved in either step S204 or step S1408 can specifically include at least one of the following: 1) The system switching decision includes the preferred system and the alternative system.

[0207] 2) If the detected uplink traffic increase exceeds the preset first threshold, the communication module's standard will be switched to 5G within a specified first time period.

[0208] For example, if a sudden increase of more than 250% in uplink traffic of the communication module is detected, the communication module's standard will be upgraded to 5G within 50ms.

[0209] 3) If the downlink traffic is detected to be continuously lower than the preset second threshold, the communication module will be switched to Narrowband Internet of Things (NB-IoT) after a specified second time period.

[0210] For example, if the downlink traffic of the communication module is detected to be consistently less than 1kbps, the communication module's standard will be downgraded to NB-IoT after 120 seconds.

[0211] 4) Under the condition that the preset fallback conditions are met, the communication module is switched to a lower standard according to the preset fallback strategy.

[0212] 5) The system switching decision includes the minimum system dwell time and the reference signal received power (RSRP) hysteresis margin.

[0213] For example, the minimum network dwell time can be set in the network switching decision as: 2 minutes for 5G network, 10 minutes for LTE network, 60 minutes for NB-IoT network, etc. This application embodiment does not make specific limitations on this.

[0214] For example, setting the RSRP hysteresis margin to be greater than 6dB in the system switching decision, but this application does not specifically limit this.

[0215] The aforementioned method of setting minimum standard dwell time and RSRP hysteresis margin in standard switching decisions, through a double-insurance anti-jitter strategy, can prevent power consumption surges during standard ping-pong switching of the communication module. Furthermore, the traffic surge response mechanism, such as upgrading the communication module to 5G network within 50ms when uplink traffic suddenly increases by more than 250%, ensures zero interruption for high-priority services.

[0216] In this embodiment of the application, when the target scene cannot be matched in the current scene, the system switching decision can be determined according to the preset system matching rules. For example, it can be shown in Table 12 below.

[0217]

[0218] In addition, in one implementation of this application, the system switching decision may also include an intelligent fallback strategy, for example, such as... Figure 16 As shown, the embodiments in this application do not impose specific limitations on this.

[0219] In this embodiment of the application, step S208, which performs a standard switching on the communication module according to the standard switching decision when the switching conditions are met, may specifically include the following steps a~b: a) If the handover conditions are met and the current service level is an emergency service level, then the neighbor cell measurement is suspended, and the communication module is switched according to the system switching decision based on the historical database.

[0220] This implementation avoids the need for additional RF module wake-up, measures the inherent latency of the fully embedded network, achieves zero latency increase, shares the activated RF module and baseband processing unit, and achieves power consumption optimization without increasing additional power consumption.

[0221] b) If the current service is a TCP service and the service level is a non-urgent service level, then while waiting for the network side's positive ACK message after sending uplink data, neighbor cell measurement is performed; if the neighbor cell measurement is completed before the ACK message arrives, then continue waiting for the ACK message; if the ACK message arrives before the neighbor cell measurement is completed, then the neighbor cell measurement is stopped; and the communication module is switched according to the system switching decision.

[0222] In this embodiment, when the handover conditions are met, neighbor cell measurement and optimization can be performed first, followed by dual-stack session migration, and then the communication module can be switched according to the switching standard decision, as well as service interruption compensation can be performed. The specific process can be as follows: Figure 17 As shown. Service interruption compensation can include: forward error correction, such as sending 20% ​​more redundant data packets before switching; or, tail retransmission, intelligent compensation retransmission based on historical traffic; or, application collaboration, sending a "SWITCH_COMPLETE" event to trigger keyframe retransmission, etc.

[0223] This implementation method establishes a new data channel and dynamically maps service quality parameters to achieve dual-stack session migration, smoothly switch between data types, and ensure uninterrupted business continuity as much as possible.

[0224] In this embodiment, before performing neighbor cell measurements, a differentiated frequency band scanning strategy can be adopted to dynamically adjust the scanning range based on the characteristics of the target standard, thereby avoiding unnecessary power consumption. Specifically, the operator can be identified, and based on the frequency bands supported by the operator, only the bands supported by the operator can be scanned, skipping the bands not supported by the operator. Furthermore, based on different target scenarios, priority frequencies and cells can be selected for scanning.

[0225] For example, in the target scenario of 5G network, millimeter-wave collaborative detection is carried out, and 28GHz scanning is only initiated when line-of-sight propagation (LOS) environment is detected.

[0226] For example, in the target scenario of NB-IoT network, coverage enhancement detection is performed, prioritizing the scanning of cells that support CE Level 0-1, in ultra-strong coverage mode.

[0227] For example, in the target scenario of LTE Cat.1, carrier aggregation prediction is performed, and CA capability detection is initiated for cells with signal strength greater than -95dBm.

[0228] like Figure 19 As shown in this embodiment, in a scenario where the current service is a TCP service, if the service level of the current service is non-urgent, then during the uplink data transmission phase, the application layer sends data packets to the communication module, and the communication module transmits the data packets to the base station. After the uplink data transmission is completed, during the period of waiting for the base station's acknowledgment (ACK) response, such as a typical 3-20ms period, this period can be used as a natural service gap window to insert measurement time slots and perform neighbor cell measurements. If the neighbor cell measurement is completed before the ACK response arrives, then the wait for the ACK response continues. If the ACK response arrives before the neighbor cell measurement is completed, then the neighbor cell measurement is aborted. Then, according to the system switching decision, the communication module performs a system switching.

[0229] The neighbor cell measurement performed in the above process can eliminate the additional power consumption of the activated RF module and baseband processing unit during neighbor cell scanning, reuse the inherent gaps in TCP services and the already activated RF hardware, and achieve zero-power service gap measurement and zero RF hardware wake-up overhead, generating only a trace amount of additional power consumption. If the ACK response arrives early, the measurement is immediately stopped to ensure that the service is completed first, and the application layer is notified after receiving the ACK response.

[0230] In this embodiment, the RRC link is in a connected state during service operations. Measurement time slots are inserted using natural service gaps, achieving zero additional power consumption overhead. This reduces the additional power consumption required for measurements such as RF wake-up, frequency synthesis, and baseband wake-up. Furthermore, by utilizing a scenario-adaptive hierarchical measurement mechanism, through dynamic frequency band focusing and service-aware measurement window scheduling, measurement power consumption is reduced while ensuring switching accuracy.

[0231] In one embodiment of this application, after determining the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module, step S202 may further include the following steps: Based on the current service priority, the sleep decision of the communication module is determined according to the following rules: a) If the current service level is emergency service level, then the sleep mode of the communication module is set to disable sleep.

[0232] b) If the current service is classified as an important service, then the sleep mode of the communication module is determined to be inter-service level 1 sleep.

[0233] c) If the current service level is a secondary service level, then the sleep mode of the communication module is determined to be Level 2 sleep mode allowed.

[0234] d) If the current service level is a general service level or a low priority service level, then the sleep mode of the communication module is determined to be deep sleep.

[0235] In one embodiment of this application, the above method may further include the following steps: If the current business belongs to one of the verification, backup, and upgrade phases of the FOTA process, then the communication module must be prohibited from hibernation. If the current service is in the download phase of the FOTA process, the communication module is allowed to enter either Level 1 or Level 2 sleep mode.

[0236] In this embodiment, the above-mentioned processing method is a phased sleep control for FOTA scenarios, which solves the sleep security problem of firmware upgrade. Compared with the processing method of prohibiting sleep throughout the FOTA process, it can avoid the surge in power consumption, realize phased dynamic control of the verification stage, backup stage, upgrade stage and download stage, improve the precision of power consumption control in the FOTA process, and avoid the risk of device bricking caused by forced sleep.

[0237] In this embodiment, after determining the hibernation level of the communication module based on the service level of the current service, a task scheduling engine can be used to manage each hibernation level and the corresponding task process. For example, it can be shown in Table 13 below. Specifically: 1) In the case of service level A (urgent service), all hibernation is prohibited to ensure the communication module can respond in real time, with only low-priority log processes suspended. 2) In the case of service level B (important service), real-time response is maintained during service processing, with first-level hibernation during service intervals, suspending diagnostic or debugging processes. 3) In the case of service level C (minor service), real-time response is maintained during service processing, with second-level hibernation during service intervals, suspending non-real-time background services, disabling software timers, and retaining only the Real-Time Clock (RTC) wake-up timer. 4) In the case of service level D (general service) or E (low-priority service), real-time response is maintained during service processing, with deep hibernation during service intervals, suspending all unnecessary processes, retaining only the hardware watchdog, disabling software timers, and retaining only the RTC wake-up timer.

[0238]

[0239] like Figure 18 As shown in the embodiments of this application, a decision engine can be used to determine various decisions based on business characteristics. The weights of each business characteristic can be selected or adjusted as needed, and the final output decisions include system switching decisions, hibernation control decisions, and power management decisions.

[0240] In this embodiment of the application, the above method may further include the following steps: Assuming the communication module is allowed to sleep, the sleep time of the communication module is calculated using the following formula: ; in, Indicates the sleep time of the communication module. Indicates the historical interval exponential smoothing value. Indicates the TAU update time in the tracking area. Indicates the moving compensation coefficient. Indicates the previous hibernation time. This represents the flow attenuation factor.

[0241] In this embodiment of the application, the historical interval exponential smoothing value The timing of TAU updates can be determined based on the business cycle statistics using a sliding window. This can be obtained by retrieving the time set in the protocol stack. Traffic attenuation factor. It can be preset as needed; for example, in the case of huge traffic, a traffic attenuation factor can be set. =0.6, setting the flow attenuation factor for very low flow rates. =1.8, etc., but this application does not specifically limit this in its embodiments. Mobility compensation coefficient It can be preset as needed; for example, setting a motion compensation coefficient when the communication module is stationary. =1.0, setting the motion compensation coefficient when the communication module moves at high speed. =0.6, etc., but this application does not specifically limit this in its embodiments. Previous sleep time This is historical statistical information.

[0242] In one embodiment of this application, the method may further include the following step: performing triple anomaly protection on the communication module according to a preset hierarchical protection system. For example, the triple anomaly protection mechanism may be specifically shown in Table 14 below.

[0243]

[0244] In this embodiment of the application, step S206 detects whether the preset switching conditions are met. Specifically, it can detect whether multiple preset switching conditions are met. For example, it can be shown in Table 15 below.

[0245]

[0246] For example, when the decision-making layer issues the "5G→NB-IoT" standard switching command, if it detects that the uplink FTP transmission is not completed, for example, if the traffic burst is greater than 1MB, the switch will be automatically delayed until the transmission is completed, and the application layer will be notified via API: "SWITCH_DELAYED(Code=0x05)".

[0247] The method provided in this application embodiment determines the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module, determines the matching target scenario based on the service characteristics of the current service, determines the corresponding standard switching decision based on the target scenario, detects whether the preset switching conditions are met, and performs standard switching on the communication module according to the standard switching decision if the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. The above process dynamically determines the standard switching decision of the multi-standard communication module based on one-dimensional or multi-dimensional service characteristics, which can improve the accuracy and flexibility of power consumption control of the multi-standard communication module.

[0248] Furthermore, event-driven optimization is combined with power consumption decision layer, and global scheduling is performed based on mobility and service levels, covering multiple stages such as power-on network search and data transmission. A traffic level prediction and dynamic threshold mechanism is adopted, updating thresholds in real time based on historical patterns and network probe measurements, improving scenario flexibility. Through a six-dimensional dynamic decision model encompassing service level, rate level, latency level, traffic level, mobility level, and data interval level, thresholds and mode switching strategies are adjusted in real time to achieve adaptive optimization.

[0249] The above describes a power consumption control method for a multi-standard communication module provided in this application. Based on the same idea, this application also provides a power consumption control device for a multi-standard communication module, applied to a terminal, such as... Figure 20 As shown, the device may specifically include: The service characteristics module 2001 is used to determine the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module.

[0250] The system switching decision module 2002 is used to determine the matching target scenario based on the business characteristics of the current business, and to determine the corresponding system switching decision based on the target scenario.

[0251] The detection module 2003 is used to detect whether the preset switching conditions are met.

[0252] The standard switching module 2004 is used to perform standard switching on the communication module according to the standard switching decision when the switching conditions are met.

[0253] In this application embodiment, the service features include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

[0254] In one embodiment of this application, the service characteristic module 2001 determines the service characteristics of the current service based on the power consumption requirements of the communication module, which may specifically include at least one of the following: Based on task monitoring and protocol parsing, the business level of the current service is determined; The rate level of the current service is determined based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service. Determine the latency level of the current service based on application layer behavior, network probe packets, or preset correspondences. Based on the predicted total data volume requirement of the current business, determine the traffic level of the current business; Based on the mobile speed of the communication module, determine the mobility level of the current service; Based on the predicted data interval of the current business, determine the data interval level of the current business.

[0255] In one implementation of this application, the business characteristic module 2001 determines the business level of the current business based on task monitoring and protocol parsing, which may specifically include: If a triggering event for the current task is detected, the business level or business level range of the current task is determined based on the triggering event. For cases where the service level range of the current task can be determined, or where the service level of the current task cannot be determined based on the triggering event, the service level of the current service is determined based on the parsing of the transport layer protocol and the application layer protocol.

[0256] In one embodiment of this application, the business feature module 2001 determines the business level or business level range of the current task based on the triggering event, which may specifically include: If the triggering event is receiving an Attention AT command, determine the business level or business level range of the current task based on the keywords in the AT command; When the triggering event is that the OpenCPU application programming interface API is called by other tasks, the business level or business level range of the current task is determined based on whether the OpenCPU API is a critical API. If the triggering event is receiving sensor data, determine the business level or business level range of the current task based on whether the sensor data was collected by a security sensor. If the triggering event is the receipt of uplink or downlink data, and the uplink or downlink data is transmitted based on a protocol other than a QoS-sensitive protocol, then the service level range of the current task is determined. If the triggering event is receiving a firmware over-the-air (FOTA) upgrade command, and the FOTA command is a command other than a download command, then the service level of the current task is determined.

[0257] In one implementation of this application, the service feature module 2001 determines the service level of the current service based on the parsing of transport layer protocols and application layer protocols, which may specifically include: Identify the transport layer protocol used by the current service, determine the feature score of the transport layer protocol, and obtain the power sensitivity coefficient of the transport layer protocol; Identify the application layer protocols used by the current business, determine the feature scores of the application layer protocols, and obtain the power sensitivity coefficients of the application layer protocols. The fusion coefficient is calculated based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol. A comprehensive protocol score is calculated based on the feature scores of transport layer protocols, the feature scores of application layer protocols, and the fusion coefficient. According to the preset mapping rules, the business level corresponding to the comprehensive score of the protocol is determined as the business level of the current business.

[0258] In one embodiment of this application, the service feature module 2001 determines the feature score of the transport layer protocol, which may specifically include: When the transport layer protocol is Transmission Control Protocol (TCP), the characteristic score of TCP is determined based on the TCP state. When the transport layer protocol is User Datagram Protocol (UDP), the characteristic score of UDP is determined based on the UDP port type and payload mode. When the transport layer protocol is Internet Control Message Protocol (ICMP), the ICMP feature score is determined based on the ICMP message type.

[0259] In one implementation of this application embodiment, the business feature module 2001 determines the feature score of the application layer protocol, which may specifically include: When the application layer protocol is Hypertext Transfer Protocol (HTTP), determine the HTTP feature score based on the HTTP device. When the application layer protocol is Message Queuing Telemetry Transport (MQTT), the feature score of the MQTT protocol is determined based on the QoS level and will flag of the MQTT protocol. When the application layer protocol is the restricted application protocol CoAP, the feature score of CoAP is determined based on the message type and observation tag of CoAP. When the application layer protocol is the lightweight machine-to-machine (LwM2M) protocol, the feature score of the LwM2M protocol is determined based on the operation type and object path of the LwM2M protocol. When the application layer protocol is the File Transfer Protocol (FTP), the characteristic score of FTP is determined based on the FTP transfer mode and file size.

[0260] In one embodiment of this application, the service feature module 2001 calculates the fusion coefficient based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol, which may specifically include: The fusion coefficient is calculated based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol according to the following formula; K_final=α×K_trans+β×K_app; Where K_final represents the fusion coefficient, K_trans represents the power sensitivity coefficient of the transport layer protocol, K_app represents the power sensitivity coefficient of the application layer protocol, α represents the weight of the power sensitivity coefficient K_trans of the transport layer protocol, and β represents the weight of the power sensitivity coefficient K_app of the application layer protocol.

[0261] In one embodiment of this application, the service feature module 2001 calculates a comprehensive protocol score based on the feature scores of the transport layer protocol, the feature scores of the application layer protocol, and the fusion coefficient. This may specifically include: Based on the feature scores of transport layer protocols, the feature scores of application layer protocols, and the fusion coefficient, the comprehensive protocol score is calculated according to the following formula: S=[Σ(Fi×Wi)]×K_final×Cenv; Where S represents the protocol comprehensive score, i represents the index of the feature score in the feature score set, the feature score set includes the feature scores of the transport layer protocol and the feature scores of the application layer protocol, Fi represents the i-th feature score in the feature score set, Wi represents the weight of the i-th feature score Fi, Σ(Fi×Wi) represents the total feature score, K_final represents the fusion coefficient, and Cenv represents the environmental compensation factor.

[0262] In one embodiment of this application, after determining the service level of the current service based on task monitoring and protocol parsing, the aforementioned service feature module 2001 can also be specifically used for: If a trigger event for the current business is detected and the trigger event is the receipt of sensor data, identify the type of sensor that collects the sensor data; Determine the current power consumption requirements of the communication module based on the type of sensor; Adjust the service level of the current service according to the current power consumption requirements of the communication module.

[0263] In one embodiment of this application, after determining the service level of the current service based on task monitoring and protocol parsing, the aforementioned service feature module 2001 can also be specifically used for: The network registration status is detected through the modem of the communication module. If the network registration status is "unregistered", adjust the current business level to "important business level". If the network registration status is "registered", detect the Packet Data Protocol (PDP) context and obtain the Quality of Service (QCI) identifier from the PDP context; If QCI is less than or equal to 4, adjust the current business level to emergency business level or important business level; If the QCI level is greater than 4, determine whether an anomaly has occurred. If an anomaly has occurred, increase the business level of the current business. If no anomaly has occurred, keep the business level of the current business unchanged.

[0264] In one embodiment of this application, the service characteristic module 2001 determines the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service. This may specifically include: The predicted rate of the current service is obtained by estimating the historical rate of the communication module. Based on the preset correspondence between application layer protocols and rate levels, the rate level corresponding to the application layer protocol currently used by the service is obtained, and the rate level is adjusted based on the characteristics of the application layer protocol to obtain the protocol rate level. The current service rate level is determined based on the degree of matching between the predicted rate and the protocol rate level.

[0265] In one embodiment of this application, the service characteristic module 2001 determines the rate level of the current service based on the degree of matching between the predicted rate and the protocol rate level, which may specifically include: The predicted rate is compared with the rate intervals corresponding to each rate level in the correspondence, and the rate level corresponding to the rate interval into which the predicted rate falls is determined as the temporary rate level. Determine whether the temporary rate class is the same as the protocol rate class; If the temporary rate level is the same as the protocol rate level, then the protocol rate level is determined as the rate level of the current service. If the temporary rate level and the protocol rate level are different and the difference does not exceed one level, the maximum value between the temporary rate level and the protocol rate level will be determined as the rate level of the current service. If the temporary rate level differs from the protocol rate level and the difference exceeds one level, the intermediate rate within the rate range corresponding to the predicted rate and the protocol rate level is calculated based on the historical matching degree to obtain the optimized rate. The rate level corresponding to the rate range into which the optimized rate falls is determined as the rate level of the current service.

[0266] In one embodiment of this application, after determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service, the service feature module 2001 can also be specifically used for: If the current service level is an emergency service level, then the maximum value between the current service rate level and the highest rate level will be used as the adjusted current service rate level. If the current service's service level is low priority, then the minimum value between the current service's rate level and the current service's rate level will be used as the adjusted rate level for the current service.

[0267] In one embodiment of this application, after determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service, the service feature module 2001 can also be specifically used for: Determine the data transmission frequency for the current service; If the current service uses a low-frequency transmission frequency, then the current service's rate level will remain unchanged. If the data transmission frequency of the current service is high-frequency transmission, then the maximum value between the current service's rate level and the rate level is taken as the adjusted rate level of the current service. If the data transmission frequency of the current service is intermittent, then the rate level of the current service will be adjusted to extremely low.

[0268] In one implementation of this application, the service feature module 2001 determines the latency level of the current service based on application layer behavior, network probe packets, or a preset correspondence, which may specifically include one of the following: Analyze the application layer behavior of the current business, estimate the latency tolerance of the current business, and determine the latency level of the current business based on the latency tolerance. Send network probe packets to obtain the round-trip time (RTT) under the current standard, and determine the latency level of the current service based on the RTT; In the preset correspondence between different time periods and latency levels under various network standards, find the time period to which the current moment belongs under the current standard of the communication module, and determine the latency level corresponding to the time period as the service level of the current service.

[0269] In one embodiment of this application, after determining the latency level of the current service based on application layer behavior and network probe packets, the service feature module 2001 can also be specifically used for: Upon detecting a specified event, the corresponding delay level adjustment strategy is determined according to the preset correspondence between event types and delay level adjustment strategies. Based on the delay level adjustment strategy, the delay level of the current service is adjusted. Determine if the current service is an urgent service. If it is, adjust the latency level to real-time or low latency.

[0270] In one implementation of this application, the service characteristic module 2001 determines the traffic level of the current service based on the predicted total data volume requirement of the current service, which may specifically include: Predict the total data volume demand of the current business in the future period, and determine the traffic level of the current business based on the predicted total data volume demand of the current business; Based on the distribution of total data volume demand across uplink and downlink traffic, adjust the traffic level of the current business. A sliding window is used to identify sudden increases in traffic for the current service. If a sudden increase in traffic for the current service is detected, the traffic level for the current service is increased.

[0271] In one embodiment of this application, the service feature module 2001 determines the mobility level of the current service based on the moving speed of the communication module, which may specifically include: The system monitors whether cell handover has occurred in the communication module. Through the modem interface of the communication module, it obtains the cell handover frequency and signal strength changes of the communication module to determine whether the communication module is in a mobile state. If the communication module is in a mobile state, it calculates the mobile speed of the communication module based on the cell handover frequency and signal strength changes, and determines the mobility level of the current service based on the mobile speed of the communication module. When the communication module is connected to an accelerometer, the system determines whether the communication module is in motion based on the data output by the accelerometer. If the communication module is in motion, the system calculates the speed of the communication module and determines the mobility level of the current service based on the speed of the communication module. When the communication module is connected to the Global Navigation Satellite System (GNSS) module, the mobility level of the current service is determined based on the speed output by the GNSS module.

[0272] In one embodiment of this application, after determining the mobility level of the current service based on the moving speed of the communication module, the service feature module 2001 can also be specifically used for: Obtain the type of device where the communication module is located; If the device type is vehicle-mounted, adjust the current service mobility level to high-speed mobility; If the device is a wearable device, adjust the current mobility level of the service to medium-speed or low-speed mobility.

[0273] In one implementation of this application embodiment, the above-mentioned service feature module 2001 determines the data interval level of the current service based on the predicted data interval of the current service, which may specifically include one of the following: Using time series forecasting methods, predict the data interval for the current business, and determine the data interval level for the current business based on the predicted data interval. When the current business is an IoT business, the data interval corresponding to the current business is obtained according to the preset correspondence between IoT business and data interval, and the data interval level of the current business is determined based on the data interval of the current business. If no data activity is detected in the communication module within several consecutive time windows, the data interval level of the current service will be adjusted to intermittent transmission or low-frequency transmission.

[0274] In one embodiment of this application, the above-mentioned standard switching decision module 2002 determines the matching target scenario based on the business characteristics of the current service, and determines the corresponding standard switching decision based on the target scenario, which may specifically include: Determine the current scenario of the communication module based on the business characteristics of the current business; The business characteristics of the current business are compared with the business characteristics of each scenario in the pre-set scenario-based decision knowledge base, and the matching degree of business characteristics of each scenario is calculated. Compare the degree of matching of business features in each scenario, and determine the scenario with the highest degree of matching of business features as the target scenario that matches the current scenario; In the contextualized decision knowledge base, search for the corresponding standard switching decision for the target scenario, and use the standard switching decision as the standard switching decision for the current business.

[0275] In one embodiment of this application, the above-mentioned standard switching decision module 2002 compares the business characteristics of the current service with the business characteristics of each scenario in the preset scenario-based decision knowledge base, and calculates the business characteristic matching degree of each scenario, which may specifically include: The business characteristics of the current business are compared with the business characteristics of various scenarios in the pre-set scenario-based decision knowledge base, and the matching degree of business characteristics for each scenario is calculated according to the following formula: ; in, This represents the business feature matching degree for any scenario within each scenario, where i represents the index of the business feature, and n represents the total number of business features, n≤6. This represents the weight of the i-th business feature. This represents the value of the i-th business feature in any scenario. This represents the value of the i-th business feature in the current scenario.

[0276] In one embodiment of this application, the above-mentioned standard switching decision module 2002 compares the business characteristics of the current service with the business characteristics of each scenario in the preset scenario-based decision knowledge base, and calculates the matching degree of the business characteristics of each scenario. It can also be specifically used for: The matching degree of business features for each scenario is corrected according to the following formula: ; in, This represents the degree of matching of business features in any scenario within each scenario, while Confidence represents the confidence level based on historical decision accuracy. This indicates the degree of matching of business features for any scenario after correction.

[0277] In one embodiment of this application, the above-mentioned system switching decision may specifically include at least one of the following: Standard switching decisions include preferred standard and alternative standard; If the detected increase in uplink traffic exceeds a preset first threshold, the communication module will be switched to 5G within a specified first time period. If the downlink traffic is detected to be consistently below a preset second threshold, the communication module will be switched to Narrowband Internet of Things (NB-IoT) after a specified second time period has elapsed. Under the condition that the preset fallback conditions are met, the communication module is switched to a lower standard according to the preset fallback strategy. The switching decision includes minimum system dwell time and reference signal received power (RSRP) hysteresis margin.

[0278] In one embodiment of this application, the above-mentioned standard switching decision module 2002 performs standard switching on the communication module according to the standard switching decision, which may specifically include: If the current service level is an emergency service level, then neighbor cell measurement is suspended, and the communication module is switched according to the standard switching decision based on the historical database. If the current service is a TCP service and the service level is a non-urgent service level, then while waiting for the network side's positive ACK message after sending uplink data, neighbor cell measurement is performed; if the neighbor cell measurement is completed before the ACK message arrives, then the wait for the ACK message continues; if the ACK message arrives before the neighbor cell measurement is completed, then the neighbor cell measurement is stopped; and the communication module is switched according to the system switching decision.

[0279] In one embodiment of this application, the above-mentioned apparatus may further include: The sleep module, after the aforementioned service characteristic module 2001 determines the service characteristics of the current service based on the power consumption requirements of the communication module, determines the sleep decision of the communication module according to the following rules based on the service level of the current service: If the current service level is an emergency service level, then the sleep mode of the communication module is set to disable sleep. If the current service is classified as an important service, then the communication module's sleep mode is determined to be inter-service level 1 sleep. If the current service level is secondary service level, then the sleep mode of the communication module is determined to be Level 2 sleep mode allowed; If the current service level is a general service level or a low priority service level, then the communication module's sleep mode is set to deep sleep.

[0280] In another embodiment of this application, the above-mentioned apparatus may further include: The hibernation module is used to force the communication module to disable hibernation if the current service belongs to one of the verification, backup, or upgrade phases of the FOTA process; and to allow the communication module to hibernate at level one or level two if the current service belongs to the download phase of the FOTA process.

[0281] In one embodiment of this application, the above-described apparatus can also be used for: If it is determined that the communication module is allowed to sleep, the sleep time of the communication module is calculated according to the following formula: ; in, Indicates the sleep time of the communication module. Indicates the historical interval exponential smoothing value. Indicates the TAU update time in the tracking area. Indicates the moving compensation coefficient. Indicates the previous hibernation time. This represents the flow attenuation factor.

[0282] The apparatus provided in this application embodiment can execute the method provided in any of the above method embodiments. For detailed process, please refer to the description in the method embodiments, which will not be repeated here.

[0283] The apparatus provided in this application embodiment is applied to a terminal. It determines the service characteristics of the current service based on the power consumption requirements of a multi-standard communication module, determines a matching target scenario based on the service characteristics of the current service, determines a corresponding standard switching decision based on the target scenario, detects whether preset switching conditions are met, and performs standard switching on the communication module according to the standard switching decision if the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. The above process dynamically determines the standard switching decision for the multi-standard communication module based on one-dimensional or multi-dimensional service characteristics, which can improve the accuracy and flexibility of power consumption control for the multi-standard communication module.

[0284] Furthermore, event-driven optimization is combined with power consumption decision layer, and global scheduling is performed based on mobility and service levels, covering multiple stages such as power-on network search and data transmission. A traffic level prediction and dynamic threshold mechanism is adopted, updating thresholds in real time based on historical patterns and network probe measurements, improving scenario flexibility. Through a six-dimensional dynamic decision model encompassing service level, rate level, latency level, traffic level, mobility level, and data interval level, thresholds and mode switching strategies are adjusted in real time to achieve adaptive optimization.

[0285] Figure 21 This is a schematic diagram of the hardware structure of an electronic device to implement the various embodiments of this application. The electronic device 2100 includes, but is not limited to: a radio frequency unit 2101, a network module 2102, an audio output unit 2103, an input unit 2104, a sensor 2105, a display unit 2106, a user input unit 2107, an interface unit 2108, a memory 2109, a processor 2110, and a power supply 2111, etc. Those skilled in the art will understand that... Figure 21 The electronic device structures shown are not intended to limit the electronic device. An electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. In the embodiments of this application, the electronic device includes, but is not limited to, mobile phones, tablets, laptops, PDAs, in-vehicle terminals, wearable devices, and pedometers.

[0286] The processor 2110 is configured to determine the service characteristics of the current service based on the power consumption requirements of the multi-mode communication module; determine a matching target scenario based on the service characteristics of the current service; determine a corresponding mode switching decision based on the target scenario; detect whether a preset switching condition is met; and, if the switching condition is met, perform mode switching on the communication module according to the mode switching decision.

[0287] The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

[0288] This application provides an electronic device applied to a terminal. Based on the power consumption requirements of a multi-standard communication module, it determines the service characteristics of the current service, determines a matching target scenario based on the service characteristics, determines a corresponding standard switching decision based on the target scenario, detects whether preset switching conditions are met, and performs standard switching on the communication module according to the standard switching decision if the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. The above process, based on one-dimensional or multi-dimensional service characteristics, dynamically determines the standard switching decision for the multi-standard communication module, which can improve the accuracy and flexibility of power consumption control for the multi-standard communication module.

[0289] Furthermore, event-driven optimization is combined with power consumption decision layer, and global scheduling is performed based on mobility and service levels, covering multiple stages such as power-on network search and data transmission. A traffic level prediction and dynamic threshold mechanism is adopted, updating thresholds in real time based on historical patterns and network probe measurements, improving scenario flexibility. Through a six-dimensional dynamic decision model encompassing service level, rate level, latency level, traffic level, mobility level, and data interval level, thresholds and mode switching strategies are adjusted in real time to achieve adaptive optimization.

[0290] It should be understood that, in this embodiment, the radio frequency unit 2101 can be used for receiving and transmitting signals during information transmission or calls. Specifically, it receives downlink data from the base station and processes it with the processor 2110; additionally, it transmits uplink data to the base station. Typically, the radio frequency unit 2101 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low-noise amplifier, a duplexer, etc. Furthermore, the radio frequency unit 2101 can also communicate with networks and other electronic devices via a wireless communication system.

[0291] Electronic devices provide users with wireless broadband internet access through network module 2102, such as helping users send and receive emails, browse web pages, and access streaming media.

[0292] The audio output unit 2103 can convert audio data received by the radio frequency unit 2101 or the network module 2102 or stored in the memory 2109 into audio signals and output them as sound. Furthermore, the audio output unit 2103 can also provide audio output related to specific functions performed by the electronic device 2100 (e.g., call signal reception sound, message reception sound, etc.). The audio output unit 2103 includes a speaker, a buzzer, and a receiver, etc.

[0293] Input unit 2104 is used to receive audio or video signals. Input unit 2104 may include a graphics processing unit (GPU) 21041 and a microphone 21042. The GPU 21041 processes image data of still images or videos acquired by an image capture device (such as a camera) in video capture mode or image capture mode. The processed image frames can be displayed on display unit 2106. The image frames processed by GPU 21041 can be stored in memory 2109 (or other storage medium) or transmitted via radio frequency unit 2101 or network module 2102. Microphone 21042 can receive sound and process such sound into audio data. The processed audio data can be converted into a format that can be transmitted to a mobile communication base station via radio frequency unit 2101 in telephone call mode.

[0294] The electronic device 2100 also includes at least one sensor 2105, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor includes an ambient light sensor and a proximity sensor. The ambient light sensor can adjust the brightness of the display panel 21061 according to the ambient light level, and the proximity sensor can turn off the display panel 21061 and / or backlight when the electronic device 2100 is moved to the ear. As a type of motion sensor, an accelerometer sensor can detect the magnitude of acceleration in various directions (generally three axes). When stationary, it can detect the magnitude and direction of gravity and can be used to identify the posture of the electronic device (such as landscape / portrait switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc. The sensor 2105 may also include a fingerprint sensor, pressure sensor, iris sensor, molecular sensor, gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc., which will not be described in detail here.

[0295] The display unit 2106 is used to display information input by the user or information provided to the user. The display unit 2106 may include a display panel 21061, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0296] User input unit 2107 can be used to receive input numerical or character information, and to generate key signal inputs related to user settings and function control of electronic devices. Specifically, user input unit 2107 includes touch panel 21071 and other input devices 21072. Touch panel 21071, also known as a touch screen, can collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near touch panel 21071). Touch panel 21071 may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch position and the signal generated by the touch operation, and transmits the signal to the touch controller; the touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to processor 2110, which receives and executes commands from processor 2110. In addition, touch panel 21071 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel 21071, the user input unit 2107 may also include other input devices 21072. Specifically, other input devices 21072 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, joysticks, etc., which will not be described in detail here.

[0297] Furthermore, the touch panel 21071 can cover the display panel 21061. When the touch panel 21071 detects a touch operation on or near it, it transmits the information to the processor 2110 to determine the type of touch event. Subsequently, the processor 2110 provides corresponding visual output on the display panel 21061 based on the type of touch event. Although in Figure 21 In this embodiment, the touch panel 21071 and the display panel 21061 are two independent components to realize the input and output functions of the electronic device. However, in some embodiments, the touch panel 21071 and the display panel 21061 can be integrated to realize the input and output functions of the electronic device. The specific implementation is not limited here.

[0298] Interface unit 2108 serves as an interface for connecting external devices to electronic device 2100. For example, external devices may include a wired or wireless headphone port, an external power supply (or battery charger) port, a wired or wireless data port, a memory card port, a port for connecting a device with an identification module, an audio input / output (I / O) port, a video I / O port, a headphone port, and so on. Interface unit 2108 can be used to receive input from external devices (e.g., data, power, etc.) and transmit the received input to one or more components within electronic device 2100, or it can be used to transmit data between electronic device 2100 and external devices.

[0299] The memory 2109 can be used to store software programs and various data. The memory 2109 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, image playback, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the memory 2109 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0300] Processor 2110 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 2109, and by calling data stored in memory 2109, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 2110 may include one or more processing units; preferably, processor 2110 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 2110.

[0301] The electronic device 2100 may also include a power supply 2111 (such as a battery) for supplying power to various components. Preferably, the power supply 2111 can be logically connected to the processor 2110 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system.

[0302] Preferably, this application embodiment also provides an electronic device, including a processor 2110, a memory 2109, and a computer program stored in the memory 2109 and executable on the processor 2110. When the computer program is executed by the processor 2110, it implements the various processes of the above method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0303] This application also provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the various processes of the above method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0304] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0305] The computer-readable storage medium provided in this application embodiment determines the service characteristics of the current service based on the power consumption requirements of the multi-standard communication module, determines the matching target scenario based on the service characteristics of the current service, determines the corresponding standard switching decision based on the target scenario, detects whether the preset switching conditions are met, and performs standard switching on the communication module according to the standard switching decision when the switching conditions are met. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level. The above process dynamically determines the standard switching decision of the multi-standard communication module based on one-dimensional or multi-dimensional service characteristics, which can improve the accuracy and flexibility of power consumption control of the multi-standard communication module.

[0306] Furthermore, event-driven optimization is combined with power consumption decision layer, and global scheduling is performed based on mobility and service levels, covering multiple stages such as power-on network search and data transmission. A traffic level prediction and dynamic threshold mechanism is adopted, updating thresholds in real time based on historical patterns and network probe measurements, improving scenario flexibility. Through a six-dimensional dynamic decision model encompassing service level, rate level, latency level, traffic level, mobility level, and data interval level, thresholds and mode switching strategies are adjusted in real time to achieve adaptive optimization.

[0307] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0308] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0309] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0310] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0311] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0312] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0313] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0314] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0315] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0316] It should be noted that all formulas and models involved in the embodiments of this application can be implemented using AI models. The training and prediction processes of each AI model adhere to multiple legal and compliant principles, including legal data sources, compliant data content, compliant data governance, compliant training objectives and schemes, compliant training processes, compliant training environments and tools, and compliant ethical verification of training results, thus meeting the requirements of Article 5 of the Patent Law. Specifically: 1. Legality of data source: All datasets used for AI model training were obtained through legal means, covering three categories: publicly authorized data, data authorized by partners, and self-collected compliant data. Publicly authorized data comes from compliant data sources following open-source licenses such as Apache 2.0, with complete copyright attribution and authorization scope clearly marked, and no unauthorized open-source code or data reuse. Data authorized by partners has been subject to formal data usage agreements, clearly defining the scope, duration, and confidentiality obligations, and possessing a complete authorization chain. For self-collected data involving personal information, strict informed consent procedures have been followed, and anonymization processes (including but not limited to field masking, feature anonymization, and differential privacy technology applications) have been implemented to remove personally identifiable information, fully complying with the requirements of relevant laws and regulations such as the "Interim Measures for the Administration of Generative Artificial Intelligence Services" and the "Personal Information Protection Law."

[0317] 2. Data content compliance: The AI ​​model's dataset undergoes multiple screenings and cleaning processes to remove all content that may violate social morality or harm public interests. It contains no obscene, pornographic, violent, discriminatory, or information that endangers national or public safety, nor does it involve the illegal acquisition or use of genetic resources. For data in sensitive fields (such as healthcare and finance), an additional privacy-preserving computation module (including federated learning and secure multi-party computation technologies) ensures that the data is "usable but not visible," avoiding compliance risks during the original data transmission process and ensuring that the data application scenarios and uses comply with public order and good morals and industry regulatory requirements.

[0318] 3. Data governance standards: A complete data traceability system is established during the AI ​​model training process to automatically record the source, collection time, annotation process, cleaning rules, and permission allocation of training data, generating traceable compliance reports to ensure that the data is verifiable throughout its entire lifecycle. The dataset annotation process for AI models is completed by a professional human R&D team, clearly defining the proportion of human creative contributions and avoiding reliance on AI-generated data that has not undergone substantial human modification, thus meeting the examination requirements for "human main contributions" in AI patent applications.

[0319] 4. Training objectives and plans are compliant: The AI ​​model training objective focuses on power consumption control of multi-standard communication modules. The training scheme and final output results do not violate any mandatory provisions of laws and administrative regulations, do not harm the public interest or the legitimate rights and interests of others, and do not pose any potential risks of being used for illegal activities, infringing on privacy, or undermining public safety. It strictly adheres to the ethical principle of "intelligent for good".

[0320] 5. Training process compliance: A closed-loop training framework is adopted to ensure compliance and controllability of the training process. The specific process is as follows: First, training samples are obtained through compliant data sources. After the aforementioned data cleaning and desensitization, they are input into the neural network model to generate preliminary training results. Second, an expert system is introduced to verify the preliminary results. Based on preset rules and human expert experience, the feasibility of the results is evaluated, and outputs that may pose ethical risks or compliance hazards are corrected (such as removing decision-making logic that violates public order and good morals, and adjusting model parameters that do not comply with safety regulations). Finally, the loss function weights are dynamically optimized based on expert system feedback to strengthen the model's learning of compliant results, avoid overfitting errors or non-compliant labels, and form a closed-loop control of "data input - model training - expert verification - parameter optimization - result feedback" to ensure that the entire training process complies with A5 ethical review requirements.

[0321] 6. Compliance of training environment and tools: AI model training is implemented using nationally licensed chips and a compliant training platform. All open-source frameworks and components used in the training process have obtained their corresponding licenses, and copyright statements and patent citation information are fully retained, with no instances of infringement or reuse. The training environment is built using virtual devices (containers / virtual machines) with fixed random seeds and initial parameter configurations to ensure the reproducibility of the training process. Furthermore, through access control and operation log recording, risks such as data leakage and parameter tampering during training are prevented, ensuring the security and compliance of the training process.

[0322] 7. Training results ethical verification complies with regulations: After the model is trained, it undergoes additional third-party ethical compliance assessment and algorithm filing review to verify that the model output does not violate social morality or harm public interests. For potentially sensitive scenarios (such as public services and intelligent decision-making), a special result verification mechanism is established to ensure that the model always complies with Article 5 of the Patent Law and relevant laws and regulations in practical applications.

[0323] In summary, the data and training process used in the AI ​​model of this application strictly comply with the relevant provisions of Article 5 of the Patent Law and the Patent Examination Guidelines (2023 Edition), and there is no violation of laws, social ethics, public interests, or illegal use of genetic resources. It fully meets the compliance requirements for patent authorization.

Claims

1. A power consumption control method for a multi-standard communication module, characterized in that, Applied to a terminal, the method includes: Based on the power consumption requirements of multi-standard communication modules, determine the service characteristics of the current service; Based on the business characteristics of the current business, a matching target scenario is determined, and based on the target scenario, a corresponding system switching decision is determined. Check whether the preset switching conditions are met; If the switching conditions are met, the communication module is switched according to the switching standard decision. The service characteristics include at least one of the following: service level, rate level, latency level, traffic level, mobility level, and data interval level.

2. The method of claim 1, wherein, The power consumption requirements based on the communication module are used to determine the service characteristics of the current service, including at least one of the following: Based on task monitoring and protocol parsing, the service level of the current service is determined; The rate level of the current service is determined based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service. The latency level of the current service is determined based on application layer behavior, network probe packets, or a preset correspondence. Based on the predicted total data volume requirement of the current service, the traffic level of the current service is determined; Based on the moving speed of the communication module, the mobility level of the current service is determined; Based on the predicted data interval of the current service, the data interval level of the current service is determined.

3. The method of claim 2, wherein, The process of determining the service level of the current service based on task monitoring and protocol parsing includes: If a triggering event for the current task is detected, the business level or business level range of the current task is determined based on the triggering event. For cases where the service level range of the current task can be determined, or where the service level of the current task cannot be determined based on the triggering event, the service level of the current service is determined based on the parsing of the transport layer protocol and the application layer protocol.

4. The method of claim 3, wherein, Determining the business level or business level range of the current task based on the triggering event includes: When the triggering event is receiving an Attention AT command, the business level or business level range of the current task is determined based on the keywords in the AT command. In the case where the triggering event is that the OpenCPU application programming interface API is called by other tasks, the business level or business level range of the current task is determined based on whether the OpenCPU API is a critical API. When the triggering event is receiving sensor data, the business level or business level range of the current task is determined based on whether the sensor data is collected by a security sensor. If the triggering event is the receipt of uplink or downlink data, and if the uplink or downlink data is transmitted based on a protocol other than a QoS-sensitive protocol, then the service level range of the current task is determined. If the triggering event is receiving a firmware over-the-air (FOTA) upgrade command, and if the FOTA command is a command other than a download command, then the service level of the current task is determined.

5. The method of claim 3, wherein, The process of determining the service level of the current service based on the parsing of transport layer and application layer protocols includes: Identify the transport layer protocol used by the current service, determine the feature score of the transport layer protocol, and obtain the power sensitivity coefficient of the transport layer protocol; Identify the application layer protocol used by the current service, determine the feature score of the application layer protocol, and obtain the power sensitivity coefficient of the application layer protocol; The fusion coefficient is calculated based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol. A comprehensive protocol score is calculated based on the feature scores of the transport layer protocol, the feature scores of the application layer protocol, and the fusion coefficient. According to the preset mapping rules, the business level corresponding to the comprehensive score of the protocol is determined as the business level of the current business.

6. The method of claim 5, wherein, Determining the feature score of the transport layer protocol includes: When the transport layer protocol is Transmission Control Protocol (TCP), the characteristic score of the TCP is determined based on the TCP state. In the case where the transport layer protocol is User Datagram Protocol (UDP), the feature score of the UDP is determined based on the UDP port type and payload mode. When the transport layer protocol is Internet Control Message Protocol (ICMP), the feature score of ICMP is determined according to the message type of ICMP. Determining the feature score of the application layer protocol includes: When the application layer protocol is Hypertext Transfer Protocol (HTTP), the feature score of HTTP is determined according to the HTTP method. When the application layer protocol is Message Queuing Telemetry Transport (MQTT) protocol, the feature score of the MQTT protocol is determined based on the QoS level and will flag of the MQTT protocol. When the application layer protocol is the Restricted Application Protocol CoAP, the feature score of CoAP is determined based on the message type and observation tag of CoAP; When the application layer protocol is the Lightweight Machine-to-Machine (LwM2M) protocol, the feature score of the LwM2M protocol is determined based on the operation type and object path of the LwM2M protocol. When the application layer protocol is the File Transfer Protocol (FTP), the feature score of the FTP is determined based on the FTP transfer mode and file size.

7. The method of claim 5, wherein, The calculation of the fusion coefficient based on the power sensitivity coefficient of the transport layer protocol and the power sensitivity coefficient of the application layer protocol includes: The fusion coefficient is calculated based on the power sensitivity coefficients of the transport layer protocol and the application layer protocol according to the following formula; K_final=α×K_trans+β×K_app; Wherein, K_final represents the fusion coefficient, K_trans represents the power sensitivity coefficient of the transport layer protocol, K_app represents the power sensitivity coefficient of the application layer protocol, α represents the weight of the power sensitivity coefficient K_trans of the transport layer protocol, and β represents the weight of the power sensitivity coefficient K_app of the application layer protocol. The calculation of the protocol comprehensive score based on the feature score of the transport layer protocol, the feature score of the application layer protocol, and the fusion coefficient includes: Based on the feature scores of the transport layer protocol, the feature scores of the application layer protocol, and the fusion coefficient, the comprehensive protocol score is calculated according to the following formula: S=[Σ(Fi×Wi)]×K_final×Cenv; Where S represents the protocol comprehensive score, i represents the index of the feature score in the feature score set, the feature score set includes the feature scores of the transport layer protocol and the feature scores of the application layer protocol, Fi represents the i-th feature score in the feature score set, Wi represents the weight of the i-th feature score Fi, Σ(Fi×Wi) represents the total feature score, K_final represents the fusion coefficient, and Cenv represents the environmental compensation factor.

8. The method according to any one of claims 2-7, characterized in that, After determining the service level of the current service based on task monitoring and protocol parsing, the process also includes at least one of the following: If a trigger event for the current service is detected and the trigger event is the receipt of sensor data, the type of sensor that collects the sensor data is identified; based on the type of sensor, the current power consumption requirement of the communication module is determined; and the service level of the current service is adjusted according to the current power consumption requirement of the communication module. The network registration status is detected through the modem of the communication module; If the network registration status is unregistered, adjust the service level of the current service to the important service level; if the network registration status is registered, detect the Packet Data Protocol (PDP) context and obtain the Quality of Service (QCI) identifier from the PDP context. If the QCI is less than or equal to 4, adjust the service level of the current service to emergency service level or important service level; if the QCI is greater than 4, determine whether an anomaly has occurred. If an anomaly has occurred, increase the service level of the current service. If no anomaly has occurred, keep the service level of the current service unchanged.

9. The method according to claim 2, characterized in that, Determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service includes: The predicted rate of the current service is obtained by estimating the historical rate of the communication module. Based on the preset correspondence between application layer protocols and rate levels, the rate level corresponding to the application layer protocol used by the current service is obtained, and the rate level is adjusted based on the characteristics of the application layer protocol to obtain the protocol rate level. The predicted rate is compared with the rate intervals corresponding to each rate level in the correspondence, and the rate level corresponding to the rate interval into which the predicted rate falls is determined as the temporary rate level. Determine whether the temporary rate level is the same as the protocol rate level; If the temporary rate level is the same as the protocol rate level, then the protocol rate level is determined as the rate level of the current service; If the temporary rate level is different from the protocol rate level and the difference is no more than one level, then the maximum value between the temporary rate level and the protocol rate level shall be determined as the rate level of the current service. If the temporary rate level is different from the protocol rate level and the difference exceeds one level, then based on the historical matching degree, the intermediate rate within the rate interval corresponding to the predicted rate and the protocol rate level is calculated to obtain the optimized rate, and the rate level corresponding to the rate interval into which the optimized rate falls is determined as the rate level of the current service.

10. The method according to claim 9, characterized in that, After determining the rate level of the current service based on the predicted rate and the rate level corresponding to the application layer protocol used by the current service, the method further includes at least one of the following: If the current service's service level is an emergency service level, then the maximum value between the current service's rate level and the highest rate level is taken as the adjusted rate level of the current service; if the current service's service level is a low priority service level, then the minimum value between the current service's rate level and the highest rate level is taken as the adjusted rate level of the current service. Determine the data transmission frequency of the current service; if the data transmission frequency of the current service is low-frequency transmission, then keep the rate level of the current service unchanged. If the data transmission frequency of the current service is high-frequency transmission, then the maximum value between the current service's rate level and the rate level is taken as the adjusted rate level of the current service. If the data transmission frequency of the current service is intermittent, then the rate level of the current service will be adjusted to an extremely low level.

11. The method of claim 2, wherein, The latency level of the current service is determined based on application layer behavior, network probe packets, or a preset correspondence, including one of the following: Analyze the application layer behavior of the current service, estimate the latency tolerance of the current service, and determine the latency level of the current service based on the latency tolerance of the current service; Send network probe packets to obtain the round-trip time (RTT) under the current standard, and determine the latency level of the current service based on the RTT; In the preset correspondence between different time periods and latency levels under various network standards, the time period to which the current time belongs under the current standard of the communication module is found, and the latency level corresponding to the time period is determined as the service level of the current service.

12. The method of claim 2, wherein, The determination of the traffic level of the current service based on the predicted total data volume requirement of the current service includes: Predict the total data volume requirement of the current service over a future period, and determine the traffic level of the current service based on the predicted total data volume requirement of the current service; Based on the distribution of the total data volume demand in upstream and downstream traffic, the traffic level of the current service is adjusted. A sliding window is used to identify sudden increases in traffic for the current service. If a sudden increase in traffic for the current service is detected, the traffic level of the current service is increased.

13. The method of claim 2, wherein, Determining the mobility level of the current service based on the movement speed of the communication module includes: The system monitors whether cell handover has occurred in the communication module. Through the modem interface of the communication module, it obtains the cell handover frequency and signal strength changes of the communication module to determine whether the communication module is in a mobile state. If the communication module is in a mobile state, it calculates the mobile speed of the communication module based on the cell handover frequency and signal strength changes, and determines the mobility level of the current service based on the mobile speed of the communication module. When the communication module is connected to an accelerometer, the system determines whether the communication module is in motion based on the data output by the accelerometer. If the communication module is in motion, the system calculates the movement speed of the communication module and determines the mobility level of the current service based on the movement speed of the communication module. When the communication module is connected to a Global Navigation Satellite System (GNSS) module, the mobility level of the current service is determined based on the speed output by the GNSS module.

14. The method of claim 2 or 13, wherein, After determining the mobility level of the current service based on the movement speed of the communication module, the method further includes: Obtain the type of the device where the communication module is located; If the device is a vehicle-mounted device, then adjust the mobility level of the current service to high-speed mobility; If the device is a wearable device, then the mobility level of the current service is adjusted to medium-speed or low-speed mobility.

15. The method of claim 2, wherein, The determination of the data interval level for the current service based on the predicted data interval includes one of the following: Using time series forecasting methods, the data interval of the current service is predicted, and the data interval level of the current service is determined based on the predicted data interval of the current service; When the current service is an Internet of Things (IoT) service, the data interval corresponding to the current service is obtained according to the preset correspondence between IoT services and data intervals, and the data interval level of the current service is determined according to the data interval of the current service. If no data activity is detected in the communication module for several consecutive time windows, the data interval level of the current service will be adjusted to intermittent transmission or low-frequency transmission.

16. The method of claim 1, wherein, The step of determining the matching target scenario based on the business characteristics of the current service, and determining the corresponding system switching decision based on the target scenario, includes: Based on the business characteristics of the current service, determine the current scenario of the communication module; The business characteristics of the current business are compared with the business characteristics of each scenario in the preset scenario-based decision knowledge base, and the matching degree of the business characteristics of each scenario is calculated. The business feature matching degree of each scenario is compared, and the scenario with the highest business feature matching degree is determined as the target scenario that matches the current scenario. In the contextualized decision knowledge base, the system switching decision corresponding to the target scenario is searched, and the system switching decision is used as the system switching decision for the current business.

17. The method of claim 16, wherein, The step of comparing the business characteristics of the current business with the business characteristics of various scenarios in a preset scenario-based decision knowledge base, and calculating the matching degree of the business characteristics of each scenario, includes: The business characteristics of the current business are compared with the business characteristics of various scenarios in the preset scenario-based decision knowledge base, and the matching degree of the business characteristics of each scenario is calculated according to the following formula: ； in, This represents the business feature matching degree of any scenario in each of the aforementioned scenarios, where i represents the index of the business feature, n represents the total number of business features, and n≤6. This represents the weight of the i-th business feature. This represents the value of the i-th business feature in any given scenario. This represents the value of the i-th business feature of the current business in the current scenario; The business feature matching degree for each scenario is corrected according to the following formula: ； in, This represents the degree of matching of business features in any of the various scenarios, and Confidence represents the confidence level based on historical decision accuracy. This indicates the corrected business feature matching degree for any of the scenarios.

18. The method of claim 1, wherein, The system switching decision includes at least one of the following: The system switching decision includes the preferred system and alternative systems; If the detected increase in uplink traffic exceeds a preset first threshold, the communication module will be switched to 5G mode within a specified first time period. If the downlink traffic is detected to be continuously lower than a preset second threshold, the communication module will be switched to Narrowband Internet of Things (NB-IoT) after a specified second time period has elapsed. Under the condition of meeting the preset fallback, the communication module is switched to a lower standard according to the preset fallback strategy. The switching decision includes minimum system dwell time and reference signal received power (RSRP) hysteresis margin. The step of performing a standard switching on the communication module according to the standard switching decision includes: If the current service level is an emergency service level, then neighbor cell measurement is suspended, and the communication module is switched according to the switching decision based on the historical database. If the current service is a TCP service and the service level is a non-urgent service level, then during the period of waiting for the network side's acknowledgment (ACK) message after sending uplink data, neighbor cell measurement is performed; if the neighbor cell measurement is completed before the ACK message arrives, then the wait for the ACK message continues; if the ACK message arrives before the neighbor cell measurement is completed, then the neighbor cell measurement is terminated; and the communication module is switched according to the switching decision.

19. The method of claim 1, wherein, After determining the service characteristics of the current service based on the power consumption requirements of the communication module, the following is also included: If the service level of the current service is an emergency service level, then the sleep mode of the communication module is determined to be sleep-disabled; If the current service is classified as an important service, then the sleep mode of the communication module is determined to be service gap level one sleep. If the service level of the current service is a secondary service level, then the sleep mode of the communication module is determined to be Level 2 sleep mode allowed; If the service level of the current service is a general service level or a low priority service level, then the sleep mode of the communication module is determined to be deep sleep; If the current service belongs to one of the verification, backup, and upgrade phases of the FOTA process, then the communication module is forced to be prohibited from sleeping. If the current service is in the download phase of the FOTA process, the communication module is allowed to enter either Level 1 or Level 2 sleep mode.

20. The method of claim 1, wherein, The method further includes: If it is determined that the communication module is allowed to sleep, the sleep time of the communication module is calculated according to the following formula: ； in, This indicates the sleep time of the communication module. Indicates the historical interval exponential smoothing value. Indicates the TAU update time in the tracking area. Indicates the moving compensation coefficient. Indicates the previous hibernation time. This represents the flow attenuation factor.

21. An electronic device, comprising: The device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the power consumption control method for a multi-standard communication module as described in any one of claims 1 to 20.

22. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the power consumption control method for a multi-standard communication module as described in any one of claims 1 to 20.

23. A computer program product, characterised in that, The method includes a computer program that, when executed by a processor, implements the steps of the power consumption control method for a multi-standard communication module as described in any one of claims 1 to 20.

Images