Network optimization method, electronic equipment, readable storage medium and program product

Abstract

The invention relates to the field of communication, in particular to a network optimization method, an electronic device, a readable storage medium and a program product, in the method, a terminal device can predict the fault time when the terminal device may have a network fault in one day based on historical use feature information and historical fault time of the terminal device, and the terminal device can optimize the network. And obtaining a network optimization time before each fault time. And in the running process of the terminal equipment, when the current time is matched with a certain network optimization time, performing network optimization by adopting a corresponding network optimization operation. On the basis, the network optimization operation can be adopted before the network fault possibly occurs, so that the terminal equipment can avoid the network fault which is the same as the historical network fault subsequently as far as possible. And the proportion of the change process from the network access card experience to the recovery of the user is reduced.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular to a network optimization method, electronic device, readable storage medium, and program product. Background Technology

[0002] During network data transmission, various factors can cause network problems in the service units involved (such as terminal devices, network infrastructure, and servers), leading to network failures when terminal devices access the internet and a poor user experience. For example, weak signal coverage and data transmission congestion in network infrastructure, excessive server load and connection drops, and weak network signal strength in terminal devices can all cause network lag or inability to connect, affecting the user's internet experience.

[0003] Currently, terminal devices can improve network conditions by performing network optimization operations (such as switching from cellular to Wi-Fi, changing the cellular network standard, or resetting the cellular network) after detecting a network failure. However, during the time between when the terminal device detects a network failure and when it restores the network through network priority operations, the terminal device's network may still be faulty, affecting the user's internet experience. Summary of the Invention

[0004] To address the aforementioned issues, this application proposes a network optimization method, electronic device, readable storage medium, and program product that avoids performing network optimization after a network failure occurs on the terminal device, thereby reducing the user experience of poor network performance.

[0005] In a first aspect, this application provides a network optimization method applied to a terminal device. The method includes: detecting that the current time of the terminal device matches a first network optimization time, wherein the first network optimization time includes a moment corresponding to a first predicted fault time and preceding the first predicted fault time, and the first predicted fault time and the first network optimization time are obtained based on historical usage characteristic information and historical fault times of the terminal device in multiple historical time periods; and performing a first network optimization operation corresponding to the first network optimization time.

[0006] Understandably, a terminal device can predict the potential network failure time (i.e., the predicted failure time), the corresponding network optimization time, and the corresponding network optimization operation based on its historical usage characteristics and the historical failure times of network failures within the same time period. The network optimization time is before the predicted potential failure time. When the terminal device detects a match between its current time and a network optimization time (i.e., the first network optimization time), it performs network optimization using the corresponding network optimization operation. Since the first network optimization time is before the first predicted failure time, network optimization can be performed before the predicted failure time, minimizing the likelihood of subsequent network failures recurring. This reduces the need for network optimization to restore network connectivity after a failure, thus reducing the proportion of users experiencing network lag and subsequent recovery.

[0007] In one possible implementation of the first aspect above, the historical usage characteristic information includes at least the usage time characteristics of the terminal device within a historical time period; and the first network optimization time is predicted based on the usage time characteristics and historical failure time; and the first network optimization time is the time when the terminal device is in an idle state before the first predicted failure time, or the first network optimization time is the time when the terminal device is in a recent service state before the first predicted failure time.

[0008] Understandably, when network optimization occurs during idle periods, it avoids impacting services used by terminal devices, ensuring a better user experience. When network optimization occurs during active periods, since these periods are closer to the predicted failure time, network optimization operations may be more effective in preventing predicted failures from occurring.

[0009] In one possible implementation of the first aspect above, detecting that the current time of the terminal device matches the first network optimization time includes: during the operation of the terminal device, detecting that the current time is the first network optimization time.

[0010] Understandably, detecting a match between the terminal device's current time and the first network optimization time can mean that the current time and the first network optimization time are the same, or that the time interval between the current time and the first network optimization time is less than a preset time threshold (e.g., 1 second). Using the detection that the terminal device's current time is the first network optimization time during operation as the method for detecting a match between the terminal device's current time and the first network optimization time is scientific and reasonable.

[0011] In one possible implementation of the first aspect above, the method further includes: stopping the execution of the first network optimization operation after the first predicted failure time.

[0012] Understandably, when a terminal device detects that the current time matches the first network optimization time during operation, it executes the first network optimization operation. This first network optimization operation can continue for a relatively long time, for example, until after the first predicted fault time. In this case, the first network optimization operation can cover as much of the time and space areas where the user's internet experience is poor as possible. Furthermore, during the execution of the first network optimization operation, it can also adaptively adjust the network optimization operation for any unresolved network faults, ensuring smooth network connectivity and preventing lag as much as possible.

[0013] In one possible implementation of the first aspect described above, the first network optimization operation includes a lossy optimization operation and / or a lossless optimization operation.

[0014] Understandably, network optimization operations can be divided into lossy optimization operations and lossless optimization operations. Lossy optimization operations are those that significantly impact the internet access services of terminal devices during the optimization process, such as causing internet access interruptions or prolonged periods of degraded network quality (e.g., network quality degradation or interruption lasting longer than 1 second). Lossless optimization operations are those that have a minimal impact on the internet access services of terminal devices during the optimization process, such as causing internet access interruptions or prolonged periods of degraded network quality (e.g., less than 1 second). The first approach to network optimization, which includes both lossy and / or lossless optimization operations, is reasonable and scientific.

[0015] In one possible implementation of the first aspect above, performing a first network optimization operation corresponding to a first network optimization time includes: the first network optimization operation includes a lossy optimization operation and a lossless optimization operation, and the lossless optimization operation is used to optimize the network of the terminal device.

[0016] Understandably, when the first network optimization operation includes both lossy and lossless optimization operations, lossless optimization operations are preferred to optimize the network of the terminal device, thereby avoiding the impact of network optimization operations on Internet access services.

[0017] In one possible implementation of the first aspect mentioned above, it further includes: if the network of the terminal device has a network fault after the lossless optimization operation is performed, a lossy optimization operation is performed to optimize the network of the terminal device.

[0018] It is understandable that network faults may still exist in the terminal device's network after lossless optimization. Detrimental optimization can effectively resolve these network faults by optimizing the terminal device's network.

[0019] In one possible implementation of the first aspect above, the first network optimization operation includes optimization operations involving multiple network layers, the network layers including at least two of the application layer, data transmission layer, and chip layer; and, executing the first network optimization operation corresponding to the first network optimization time during the first network optimization time includes: executing optimization operations involving multiple network layers according to a preset network layer order.

[0020] Understandably, when the first network optimization operation involves optimization operations across multiple network layers, it is scientific and reasonable to execute the network optimization operations in a pre-defined order, prioritizing the operations across multiple network layers.

[0021] In one possible implementation of the first aspect above, before executing the first network optimization operation corresponding to the first network optimization time, the method further includes: obtaining the current device state of the terminal device and the expected device state corresponding to the first network optimization time, wherein the expected device state corresponding to the first network optimization time is obtained based on the historical usage characteristic information and historical fault time of the terminal device; and executing the first network optimization operation corresponding to the first network optimization time when the current device state and the expected device state satisfy the first matching condition.

[0022] In one possible implementation of the first aspect above, it further includes: under the condition that the current device state and the expected device state do not satisfy the first matching condition, re-predicting the second network optimization time based on the current device state.

[0023] Understandably, when the current device state and the expected device state do not meet the first matching condition, the second network optimization time is re-predicted based on the current device state, so as to adapt to various user situations.

[0024] Furthermore, if the current device state does not meet the first matching condition with the expected device state, the terminal device may also choose not to perform the first network optimization operation, thereby saving power consumption.

[0025] In one possible implementation of the first aspect above, the first matching condition includes: the degree of overlap between the current device state of the terminal device and the expected device state corresponding to the first network optimization time satisfies a first overlap threshold.

[0026] It is understandable that using the degree of overlap between the current device status of the terminal device and the expected device status at the corresponding first network optimization time as the first matching condition is scientific and reasonable.

[0027] In one possible implementation of the first aspect above, obtaining the current device state of the terminal device and the expected device state corresponding to the first network optimization time includes: when the first network optimization operation includes a lossy optimization operation, obtaining the current device state of the terminal device and the expected device state corresponding to the first network optimization time.

[0028] Understandably, when the first network optimization operation includes a lossy optimization operation, the current device state of the terminal device and the expected device state for the corresponding first network optimization time are obtained. Under the condition that the current device state and the expected device state satisfy the first matching condition, the first network optimization operation corresponding to the first network optimization time is executed in the first network optimization time to avoid wasting device resources to predict the device state.

[0029] In one possible implementation of the first aspect above, the device state includes at least one of the following: the on / off state of the terminal device during use, the network state, the specific information of the application being used, the specific operation performed when using the application, and the location of the terminal device.

[0030] Understandably, device status includes information such as the screen's on / off state, network status, specific information about the applications being used, specific operations performed while using the applications, and the location of the terminal device, providing a comprehensive understanding of the current usage of the device.

[0031] In one possible implementation of the first aspect above, the lossless optimization operation includes at least one of the following: synchronization of the application processor and the modem chip on the IP or DNS server, four-network operation, resource scheduling acceleration operation, switching of network standard according to the corresponding handover method, downgrading of the HTTP protocol version corresponding to the IP without change, and operation corresponding to application self-healing retry; the lossy optimization operation includes at least one of the following: downgrading of network standard according to the corresponding redirection or reselection method, downgrading of network protocol version corresponding to 3GPP protocol access information change, packet data network activation operation under cellular network, reconnection of base station or core network under cellular network, flight mode reset operation under cellular network, replacement of domain name system server under Wi-Fi network, use operation of multi-dynamic host configuration protocol server under Wi-Fi network, Wi-Fi reassociation operation, and Wi-Fi chip reset operation.

[0032] In one possible implementation of the first aspect mentioned above, the use of feature information further includes: device location features of the terminal device within a historical time period, network requirement features of each application during use, application usage preference features, and device usage degree features. The usage time features include one of the following: device screen-on time, device network connection time, usage time of each application, and usage time of each type of application within the historical time period. The device location features include at least one of the following: the location of the terminal device when the screen is on, the location of the terminal device when it is connected to the network, and the location of the terminal device when using different applications within the historical time period.

[0033] Understandably, the usage feature information includes the device location features of the terminal device within a historical time period, the network requirement features of each application, the usage preference features of the application, and the usage level features of the device. Among them, the usage time features include the following: the device screen-on time, the device network connection time, the usage time of each application, and the usage time of each type of application, thereby enabling a comprehensive prediction of network optimization time and network optimization operations.

[0034] In one possible implementation of the first aspect above, the first network optimization time is obtained by matching the historical usage characteristic information of the terminal device in multiple historical time periods and the historical failure time of the corresponding historical usage characteristic information with the first time period according to a preset rule, thereby determining at least one network optimization time in the first time period and / or the expected device state, wherein at least one network optimization time includes the first network optimization time.

[0035] Understandably, the first time period can be the date to be predicted or a specific time period set by the user. Rule-based matching can effectively predict at least one network optimization time within the first time period, and this at least one network optimization time includes the first network optimization time.

[0036] In one possible implementation of the first aspect above, a hit analysis and / or validity analysis is performed on the execution result of the first network optimization operation; based on the analysis results of the hit analysis and / or validity analysis, as well as historical usage characteristic information and historical failure time, the network optimization time within the second time period is predicted.

[0037] Understandably, the second time period is the time period that needs to be predicted subsequently, such as a specific date or a user-defined time period. Using hit analysis and / or validity analysis of the execution results of the first network optimization operation as prediction factors improves the accuracy of predicting the network optimization time for the subsequent second time period.

[0038] In one possible implementation of the first aspect above, the historical fault time includes a first historical fault time in which a network fault was detected in the terminal device during a historical time period, and a second historical fault time in which a user operation indicating poor network quality was detected in the terminal device during a historical time period.

[0039] Understandably, using the time when a user operation indicating poor network quality is detected as the historical fault time can ensure the completeness of the identification of scenarios requiring network optimization.

[0040] In one possible implementation of the first aspect above, the user operation indicating poor network quality includes at least one of the following: the user launches, exits, fast-forwards, swipes up and down, repeatedly clicks, or re-enters the application; the user turns on, turns off, or resets at least one of the following: Wi-Fi network control, cellular network control, airplane mode control, 5G switch control, primary SIM card control, and secondary SIM card control; the user changes the data limit setting; or the user queries the data usage.

[0041] It's understandable that user actions such as launching, exiting, fast-forwarding, swiping up and down, repeatedly clicking, or re-entering applications; turning on, off, or resetting at least one of the following controls: Wi-Fi, cellular, airplane mode, 5G, primary SIM, or secondary SIM; changing data limits; and checking data usage are all actions that reflect user experience. Therefore, using these actions to indicate poor network quality is scientifically reasonable. In this case, because network optimization can be implemented before a potential network failure occurs, the terminal device can avoid repeating past network failures as much as possible, and the number of times users manually perform actions to improve the network can be reduced, thus improving the user experience.

[0042] In a second aspect, this application provides an electronic device, including: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to perform the network optimization method provided in the first aspect and various possible implementations described above.

[0043] Thirdly, this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the network optimization method provided in the first aspect and various possible implementations described above.

[0044] Fourthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to execute the network optimization method provided in the first aspect and various possible implementations described above.

[0045] Understandably, the beneficial effects of the second to fourth aspects mentioned above refer to the first aspect and various possible implementations, which will not be elaborated here. Attached Figure Description

[0046] Figure 1 According to some embodiments of this application, a schematic diagram of a network data transmission architecture is shown;

[0047] Figure 2A According to some embodiments of this application, a schematic diagram of an interface 101 in which a user's mobile phone 100 experiences a refresh delay when browsing the Internet is shown;

[0048] Figure 2B According to some embodiments of this application, a screen 102 is shown where a mobile phone 100 cannot connect to the network when a user is browsing the Internet.

[0049] Figure 3A According to some embodiments of this application, a schematic diagram of network optimization time is shown;

[0050] Figure 3B According to some embodiments of this application, a schematic diagram of a network optimization method is shown;

[0051] Figure 4A According to some embodiments of this application, a flowchart of a network optimization method is shown;

[0052] Figure 4B According to some embodiments of this application, a schematic diagram of network optimization time corresponding to usage characteristic information and fault characteristic information of historical working days is shown;

[0053] Figure 4C According to some embodiments of this application, a schematic diagram of a network optimization operation is shown;

[0054] Figure 5 According to some embodiments of this application, a schematic diagram of the interaction process of a network optimization method is shown;

[0055] Figure 6AAccording to some embodiments of this application, a schematic diagram is shown based on specific usage information of a user's mobile phone usage 100% per day over the past 5 working days.

[0056] Figure 6B According to some embodiments of this application, a user classification diagram is shown;

[0057] Figure 6C According to some embodiments of this application, a schematic diagram of a user profile related to the time dimension is shown;

[0058] Figure 6D According to some embodiments of this application, a schematic diagram of a user profile related to the location dimension is shown;

[0059] Figure 7A According to some embodiments of this application, a schematic diagram of a network optimization system architecture is shown;

[0060] Figure 7B According to some embodiments of this application, a schematic diagram of information interaction between a mobile phone 100 and a cloud device 200 and a peripheral device 300 is shown.

[0061] Figure 8 According to some embodiments of this application, a schematic diagram of the hardware structure of a mobile phone 100 is shown. Detailed Implementation

[0062] The illustrative embodiments of this application include, but are not limited to, a network optimization method, an electronic device, a readable storage medium, and a program product.

[0063] The embodiments of this application will now be described with reference to the accompanying drawings.

[0064] Figure 1 According to some embodiments of this application, a schematic diagram of a network data transmission architecture is shown. As shown in the figure, network data transmission involves multiple service units, such as mobile phone 100, base station 01A, Wi-Fi router 01B, core network 02, backbone network 03, and server 04 shown in the figure. Specifically, when mobile phone 100 performs network data transmission, it can access the network through base station 01A or Wi-Fi router 01B and transmit the data to core network 02. Core network 02 is then connected to backbone network 03 (e.g., metropolitan area network), and the data is transmitted to server 04 through backbone network 03. Server 04 can also transmit network data to mobile phone 100 through backbone network 03, core network 02, and base station 01A or Wi-Fi router 01B, thereby realizing communication and interaction between mobile phone 100 and server 04.

[0065] Understandably, during network data transmission, various factors can cause network problems for the service units involved, leading to network failures on mobile phones and a poor user experience. For example, if base station 01A or Wi-Fi router 01B experiences weak network signal coverage or significant interference with air interface transmission, mobile phone 100 may experience network failures due to packet loss, increased latency, and decreased transmission speed. Similarly, if the core network 02 experiences temporary software or hardware failure, mobile phone 100 may experience network failures due to service interruption. Furthermore, if the backbone network 03 experiences congestion, or server 04 faces high load or connection drops, mobile phone 100 may experience significant speed drops, network lag, or connection failures due to the complex and ever-changing network environment, resulting in a poor user experience.

[0066] For example, Figure 2A The image shows a screen 101 on a mobile phone 100 where there is a refresh delay when a user is browsing the internet. When the user opens a video application (APP) and watches a video, the mobile phone 100 is unable to refresh the video page due to a significant drop in network speed. As shown by the refresh icon 1011 in the image, the mobile phone 100 is constantly refreshing the page, resulting in a poor user experience. Figure 2B The image shows a screen 102 on a mobile phone 100 that displays "Network connection failed" when a user is browsing the internet. While the user is watching a video using a video app, the mobile phone 100 loses network access due to service interruption, and the video stops on the current page. The message "Network not connected, please check settings" displayed in the prompt box 1021 indicates that the mobile phone 100's network has been disconnected.

[0067] In some embodiments, when a network failure is detected (either passively received or actively detected), the terminal device can perform network optimization operations to restore the network and improve network performance. For example, when mobile phone 100 detects network latency or connection interruption, it can perform network optimization operations such as switching the network standard from 5G to 4G, downgrading the network protocol version, downgrading network protocol fields, changing the connected base station, or restarting the phone to restore the network.

[0068] However, during the time between when a terminal device detects a network failure and when it restores the network through network optimization operations, the terminal device's network may still be faulty, affecting the user's online experience.

[0069] Understandably, network failures in electronic devices tend to follow certain patterns depending on how users access the network. For example, electronic devices may experience network failures when users are browsing the internet in certain fixed locations such as parking lots, elevators, workplaces, or on their way to and from get off work. Network failures can also occur when multiple users are browsing the internet simultaneously, such as when users are eating in a cafeteria, watching performances or sporting events in concert halls, stadiums, or theaters, or attending meetings in large conference rooms. Furthermore, network failures can also occur when users are using applications (apps) with high access volumes during specific time periods.

[0070] Therefore, this application proposes a network optimization method. In this method, a terminal device can predict the possible network failure time (i.e., the predicted failure time), the corresponding network optimization time (e.g., the time before the corresponding failure time), and the corresponding network optimization operation for each failure time, based on historical usage characteristic information of the terminal device (and / or associated devices) over multiple historical dates and historical failure times of network failures over multiple historical dates (e.g., the time when a network failure was detected, the time when a user operation indicating poor network quality was detected). During operation, if the current time matches a network optimization time, the terminal device can perform network optimization using the network optimization operation corresponding to that network optimization time.

[0071] Based on the above method, network optimization operations can be performed before a potential network failure occurs, allowing terminal devices to avoid repeating past network failures as much as possible. Furthermore, this minimizes the need for terminal devices to restore network connectivity after a failure, reducing the proportion of users experiencing network lag and subsequent recovery.

[0072] In some embodiments, the characteristic information used may include, but is not limited to, the usage time characteristics (such as device screen-on time, device network time, usage time of each APP / type of APP on the terminal device, etc.) exhibited by the terminal device when the user uses the device according to their own needs, device location characteristics (such as the location when the device screen is on, the location when the device is connected to the network, the location when different APPs are used, etc.), network requirement characteristics when each APP is used, APP usage preference characteristics, and device usage degree characteristics, etc.

[0073] In some embodiments, user actions indicating poor network quality may include user feedback actions detected by the terminal device based on the current network smoothness, such as manual user feedback actions on the app and system. Specifically, this may include actions such as launching / exiting / fast-forwarding / swiping up / down / repeatedly clicking / re-entering the app, turning system controls such as Wi-Fi network controls, cellular network controls, airplane mode controls, 5G switch controls, and primary / secondary SIM card controls on / off / reset, as well as actions such as changing data limit settings and checking data usage. It is understood that the aforementioned user feedback actions can also indicate poor network quality.

[0074] For example, suppose a user uses phone 100 multiple times at time T1 during the day and experiences network congestion. The user actively turns off Wi-Fi and turns on cellular data. Phone 100 can identify these actions as indicating poor network quality. Therefore, during prediction based on historical usage data from multiple dates, phone 100 can use time T1 as a historical fault time and predict potential network fault times within the day, including time T1. Consequently, the network optimization time corresponding to time T1 can be determined as time T2, which is earlier than time T1, allowing for optimization before network faults occur.

[0075] Understandably, using the time when a user operation indicating poor network quality is detected as the historical fault time can ensure the completeness of the identification of scenarios requiring network optimization, increase the number of times network optimization operations are performed, and reduce the number of manual operations that users can perform to improve the network, thereby enhancing the user experience.

[0076] Furthermore, in some embodiments, the terminal device can also predict the expected device state corresponding to each network optimization time based on usage characteristic information from multiple historical dates and historical failure times of network failures from multiple historical dates. For example, the expected device state may include, but is not limited to: screen on / off status when the device is in use, network status, the app being used, the specific operations performed by the app, location, and other information.

[0077] During operation, if a terminal device detects that the current time matches a network optimization time and that the terminal device's current device state matches the expected device state for that network optimization time, it will perform network optimization using the network optimization operation corresponding to that time. If the terminal device's actual device state does not match the expected device state for that time period, the terminal device may choose not to execute the network optimization operation corresponding to that time. If they match, then the network optimization operation corresponding to that time will be executed. For example, the degree of overlap between the actual and expected device states can be used to determine whether they match. If the overlap is greater than a certain threshold, the actual device state is considered to match the expected device state, and the network optimization operation corresponding to that time will be executed; otherwise, the network optimization operation corresponding to that time will not be executed.

[0078] For example, mobile phone 100 predicts that the network optimization time is 9 PM, and the expected device status is: phone screen on, using home Wi-Fi, network bandwidth requirement of 100 Mbps, using game app 1, and location at home. When mobile phone 100 is at 9 PM, it detects that the current actual device status is: phone screen on, home Wi-Fi, time is 9 PM, game app 1, at home. It determines that the expected device status matches the current actual device status and performs the network optimization operation corresponding to the network optimization time of 9 PM.

[0079] In some embodiments, network optimization operations can be divided into lossy optimization operations and lossless optimization operations. Lossy optimization operations are those that significantly impact the internet access services of terminal devices during the optimization process, such as causing internet access interruptions or prolonged periods of network quality degradation (e.g., network quality degradation or interruption lasting longer than 1 second). Lossless optimization operations are those that have a minimal impact on the internet access services of terminal devices during the optimization process, such as causing internet access interruptions or prolonged periods of network quality degradation (e.g., less than 1 second).

[0080] For example, lossless optimization operations may include, but are not limited to, synchronizing the application processor and modem chip on the IP / DNS server, accelerating network data transmission based on resource scheduling (such as four-network operation, resource scheduling acceleration operation), switching network standards according to the corresponding handover method (such as switching from 5G to 4G), and downgrading the Hypertext Transfer Protocol (HTTP) protocol version when the corresponding Internet Protocol (IP) address does not change. Specific operations will be explained in detail below and will not be elaborated here.

[0081] For example, lossy optimization operations may include, but are not limited to, switching network standards (such as switching from 5G to 4G) through redirection or reselection, downgrading network protocol versions corresponding to 3GPP access information changes, activating packet data network (PDN) operations under cellular networks, reconnecting base stations / core networks under cellular networks, resetting flight mode under cellular networks, replacing domain name system (DNS) servers under Wi-Fi networks, using dynamic host configuration protocol (DHCP) servers under Wi-Fi networks, Wi-Fi reassociation operations, and resetting Wi-Fi chips, etc. Specific operations will be explained in detail below and will not be elaborated here.

[0082] In some embodiments, the network optimization time can be the time in the most recent idle state before the fault time (where idle state means the terminal device is in a state where the screen is off or on but has not initiated a network operation), or it can be the time in the service state to which the fault time belongs, before the fault time (where service state means the terminal device is in a network state). Furthermore, when the terminal device detects that the current time matches a certain network optimization time during operation, and performs optimization using the network optimization operation corresponding to that network optimization time, the network optimization operation can continue for a relatively long time, for example, continuing until after the fault period ends.

[0083] Understandably, network optimization operations performed before the scheduled failure time prevent network failures from occurring at that time. When network optimization occurs during idle periods, it avoids impacting services used by terminal devices, ensuring a better user experience. When network optimization occurs during active periods, the effectiveness of network optimization in preventing failures may be even greater, as these active periods are closer to the scheduled failure time.

[0084] For example, refer to Figure 3AAssume the day is Monday, and the predicted fault period U1 is determined. Fault period U1 belongs to a network time period R1 and a screen-on time period Y1. The most recent screen-off time period preceding fault period U1 is screen-off time period M1. Furthermore, the most recent idle state K1 preceding fault period U1, the service state W1 to which fault period U1 belongs, and the time period X1 within service state W1 preceding fault period U1 can be determined. Assume the network optimization time can be a time within idle state K1 (as shown in network optimization time A1 and A2 in the figure) or a time within time period X1 preceding fault period U1 (as shown in network optimization time A3 and A4 in the figure). The network optimization operation corresponding to network optimization time A4 continues after fault period U1.

[0085] Understandably, when the duration of the network optimization operation covers the fault period U1 (as shown in the network optimization operation A4 in the figure), it can cover the time and space areas where users have a poor internet experience as completely as possible. Furthermore, during the execution of the network optimization operation, the specific network optimization operation can be adaptively adjusted for network faults to ensure smooth network operation without lag as much as possible.

[0086] In other embodiments, the network optimization operation corresponding to the network optimization time can use different network optimization operations depending on the service state corresponding to the network optimization time. Specifically, when the network optimization time is in the idle state before the fault time, the network optimization operation can be a lossy optimization operation or a lossless optimization operation. When the network optimization time involves the service state, the network optimization operation can preferentially select a lossless optimization operation, thereby avoiding the impact on service use due to network optimization operations when the terminal device is in use.

[0087] Furthermore, after the terminal device performs network optimization operations, hit analysis and effectiveness analysis can be performed based on the results. Hit analysis determines whether network optimization is necessary, while effectiveness analysis assesses whether the optimized operation effectively addresses the user's poor internet connection. For example, hit analysis can be conducted experimentally. After predicting the failure time and the corresponding network optimization time, the optimization operation is not performed, and the occurrence of subsequent failures is observed. For effectiveness analysis, if no failure occurs after performing the optimization operation, it is considered effective; if a failure occurs, it is considered ineffective.

[0088] Understandably, the predicted failure times, network optimization times, and network optimization operations corresponding to those failure times can be adjusted based on the results of hit analysis and validity analysis. For example, the usage characteristics of the terminal device over multiple historical dates and the historical failure times of network failures over multiple historical dates can be used as samples for the prediction model. This will train a prediction model that can predict the network optimization time and the corresponding network optimization operation for each failure time of the terminal device within a day. Then, after obtaining the results of the hit analysis and validity analysis, these results can be used as new samples to train the prediction model, resulting in a more accurate output of network optimization times and network optimization operations.

[0089] Understandably, in some embodiments, network lag may manifest in ways including but not limited to network latency, abnormal network connection, slow webpage loading, frequent network buffering, slow download speed, slow webpage updates, and complete failure to refresh the page.

[0090] It is understood that the user's internet access as described in the embodiments of this application includes, but is not limited to, reading news, making audio and video calls, browsing short videos, playing games, live streaming, downloading, uploading, speed testing, hailing a ride, and making payments. As long as the user needs to use the network, it is within the protection scope of this application, and will not be elaborated here.

[0091] Understandably, the solution of this application can be applied to any terminal device capable of networking. The terminal device in the embodiments of this application can also be referred to as a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The terminal device can be a mobile phone, smart TV, wearable device, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in a smart grid, wireless terminal in transportation safety, wireless terminal in a smart city, wireless terminal in a smart home, etc., and is not limited thereto.

[0092] Understandably, a terminal device (e.g., terminal device H) can determine in advance, based on the corresponding specific usage information, the usage characteristics information of its own terminal device on multiple historical dates when it was used by the user, as well as the fault characteristic information of network failures on multiple historical dates. The fault characteristic information includes detected network fault characteristic information and user operation information indicating poor network quality. Specifically, the network fault characteristic information may include the time of the detected network fault and the corresponding fault type information, etc. The user operation information indicating poor network quality may include the time of the user operation indicating poor network quality mentioned above and the specific information of some experience feedback operations performed by the user based on the current network smoothness, etc.

[0093] Terminal device H can also obtain usage and fault information from other devices (e.g., terminal devices K1-Kn), and determine its own network optimization time and corresponding network optimization operations based on the aggregated usage and fault information of all terminal devices. For example, when predicting fault time, terminal device H considers the situation where other devices consistently fail when passing through a certain area within a certain time period as a potential fault time for the terminal device. Even if terminal device H has not experienced a fault before, this can help minimize the chance of a fault occurring when terminal device H passes through that area again.

[0094] In some implementations, terminal device H can send usage characteristic information and fault characteristic information to cloud device, so that cloud device can determine the network optimization time and corresponding network optimization operation for each terminal device based on the aggregated usage characteristic information and fault characteristic information of all terminal devices, and send the network optimization time and corresponding network optimization operation to the corresponding terminal device.

[0095] In other implementations, where cloud devices can obtain usage and fault characteristic information sent by certain terminal devices, terminal device H can obtain usage and fault characteristic information of certain terminal devices from the cloud device, and can also obtain usage and fault characteristic information corresponding to each device from peripheral devices. Based on the aggregated usage and fault characteristic information of all terminal devices, it determines its own network optimization time and corresponding network optimization operations.

[0096] To make it easier to understand, the following will be combined with... Figure 3B This document provides a brief overview of the network optimization methods corresponding to some embodiments of this application. Figure 3B The following is an example of a terminal device (e.g., mobile phone 100) obtaining usage characteristic information and fault characteristic information from cloud device 200 and peripheral device 300.

[0097] like Figure 3B As shown, mobile phone 100 can obtain its current device information (e.g., system and environmental data), detected fault feature information, and user profile. System and environmental data includes information such as mobile phone 100's power consumption, data usage, performance, and heat, as well as specific device information such as whether the current network type of mobile phone 100 is cellular or Wi-Fi, and whether it has dual SIM cards or dual Wi-Fi capabilities. Detected fault feature information can be obtained by mobile phone 100 based on existing network fault detection technologies (e.g., quality of service (QoS) or quality of experience (QoE)). The user profile is feature information obtained by mobile phone 100 related to the user's device usage needs and operational experience. For example, the user profile can include the usage feature information from multiple historical dates mentioned above (i.e.,...). Figure 3B The content shown in the user demand profile) and user operation information indicating poor network quality (i.e., Figure 3B (Content shown in the user experience profile).

[0098] Similarly, the peripheral device 300 can obtain user profiles related to its own device and detect fault feature information. The cloud device 200 can obtain user profiles corresponding to other terminal devices and fault feature information detected by other terminal devices.

[0099] Mobile phone 100 aggregates its current device information, detected fault characteristics, and user profiles, as well as user profiles and detected fault characteristics from cloud devices 200 and peripheral devices 300. Based on this aggregated information, it predicts the potential network failure time for the current terminal device, the corresponding network optimization time for each failure time, and the corresponding network optimization operation for each optimization time. Then, during operation, when mobile phone 100 detects a match between the current time and the network optimization time, it executes the network optimization operation. Furthermore, it can perform hit analysis and effectiveness analysis based on the execution results of the network optimization operation to dynamically adjust subsequent prediction and execution processes. For example, hit analysis results can be used to correct subsequent predicted failure times, and effectiveness analysis results can be used to correct specific network optimization operations, using network optimization operations that are more effective for network failures.

[0100] In addition, mobile phone 100 can also perform network optimization operations matching the temporarily detected network fault to restore the network. Mobile phone 100 can also detect user operation information indicating poor network quality (i.e.,...) Figure 3BWhen analyzing user experience profiles, network optimization operations can be performed directly to improve network smoothness.

[0101] Figure 4A According to an embodiment of this application, a flowchart of a network optimization method is shown. This network optimization method is described using a user's terminal device (e.g., mobile phone 100) as the executing entity. Furthermore, it is specifically described using the example of mobile phone 100 determining the network optimization time and network optimization operation from information from cloud devices and peripheral devices. The specific steps are as follows:

[0102] S401, obtain historical usage characteristics and historical fault characteristics of mobile phone 100.

[0103] In some embodiments, mobile phone 100 can obtain its own historical usage characteristic information (i.e., usage characteristic information for multiple historical dates mentioned above) and historical fault characteristic information. For example, mobile phone 100 can determine its own historical usage characteristic information and historical fault characteristic information using its own collected historical data and its own computing resources. Alternatively, mobile phone 100 can send its own historical data to a server, and the server can allocate resources to determine the historical usage characteristic information and historical fault characteristic information of mobile phone 100, enabling mobile phone 100 to obtain its own historical usage characteristic information and historical fault characteristic information from the server.

[0104] As can be understood, as mentioned above, the usage characteristic information includes the usage time characteristics exhibited by the terminal device when the user uses the device according to their own needs (such as device screen-on time, device network connection time, usage time of each APP / type of APP on the terminal device, etc.), device location characteristics (such as the location when the device screen is on, the location when the device is connected to the network, the location when different APPs are used, etc.), network requirement characteristics when each APP is used, APP usage preference characteristics, and device usage intensity characteristics, etc. Fault characteristic information includes detected network fault characteristic information and user operation information indicating poor network quality. Specific fault characteristic information may include time, location, fault type, etc.

[0105] The network requirements for each app include the required data usage thresholds, bandwidth, latency, and packet loss rate to prevent buffering during app usage, as well as whether the app is connected to a cellular or Wi-Fi network. App usage preference characteristics can include information about apps users frequently use, along with related network traffic, bandwidth, latency, jitter, packet loss, cellular / Wi-Fi network usage, app usage duration and time period, and the domain names and IP versions accessed by the app. Device usage characteristics include the specific degree of device usage, such as moderate, light, or heavy. For example, if a user uses their device for 80% of their time for several consecutive days, they are considered a heavy user. Device usage characteristics can improve prediction accuracy when users' travel destinations are highly random.

[0106] Understandably, in some embodiments, the mobile phone 100 can collect specific usage information (i.e., historical data) from multiple historical dates when the user uses the device. In this case, artificial intelligence technology (e.g., neural network model) can be used to learn usage time characteristics (such as device screen-on time, device network time, usage time of each APP / type of APP on the terminal device, etc.), device location characteristics (such as the location when the device screen is on, the location when the device is connected to the network, the location when different APPs are used, etc.), network requirement characteristics when each APP is used, APP usage preference characteristics, and device usage degree characteristics, etc. The specific process will be described below and will not be elaborated here.

[0107] In some embodiments, the mobile phone 100 can detect fault characteristic information based on existing fault detection technologies. For example, it can detect fault characteristic information based on quality of service (QoS) or quality of experience (QoE) methods, or it can obtain fault characteristic information based on fault feedback information reported by the APP during use. The mobile phone 100 can also obtain fault characteristic information based on detected user operation information indicating poor network quality. For example, it can obtain fault characteristic information based on the manual experience feedback operations of the user on the APP and system as described above. Specifically, this can include operations such as launching / exiting / fast forwarding / swiping up / down / repeatedly clicking / re-entering the APP, turning on / off / resetting system controls such as Wi-Fi network controls, cellular network controls, airplane mode controls, 5G switch controls, primary and secondary SIM card controls, as well as operations such as changing data limit settings and querying data usage. It is understood that the aforementioned experience feedback operations can also indicate poor network quality.

[0108] For example, Figure 4BAccording to some embodiments of this application, a schematic diagram of usage characteristic information and fault characteristic information corresponding to historical working days is shown. It is understood that the fault characteristic information includes detected fault characteristic information and user operation information indicating poor network quality. Specifically, Figure 4B The content of the user demand profile corresponds to the usage characteristics information of historical workdays. Figure 4B The user experience profile content corresponds to user operation information indicating poor network quality.

[0109] Understandable. Figure 4BThe user demand profile (i.e., usage characteristic information), user experience profile (i.e., user operation information indicating poor network quality), and detected fault characteristics shown are all obtained by Mobile Phone 100 after learning from historical workday data. Specifically, the device screen-on time and corresponding location for the historical workdays in the user demand profile are as follows: for users waking up and having breakfast, Mobile Phone 100 is on from 6:30 to 7:00, corresponding to the location at home; for users commuting to work, Mobile Phone 100 is on around 8:00 to 8:30, corresponding to the location on the subway; for users having morning tea, Mobile Phone 100 is on around 10:00 to 10:20, corresponding to the location at the office; and so on. During the user's lunch break and lunchtime, the phone screen is on from 12:00 to 13:30, corresponding to the location of the office; during the user's afternoon tea, the phone screen is on from 16:00 to 16:30, corresponding to the location of the office; during the user's commute home, the phone screen is on from 18:00 to 18:30, corresponding to the location of the subway; and during the user's time from dinner to rest, the phone screen is on from 20:00 to 22:00, corresponding to the location of the home. The device network connection times and corresponding locations for historical workdays based on user demand profiles are as follows: For users waking up and having breakfast, phone 100 connects to the internet from 6:30-6:50 AM, at home; during commuting to work, phone 100 connects to the internet around 8:00-8:30 AM, on the subway; during morning tea, phone 100 connects to the internet around 10:00-10:20 AM, at the office; during lunch and lunch break, phone 100 connects to the internet from 12:00-1:00 PM; during afternoon tea, phone 100 connects to the internet from 4:00-4:30 PM, at the office; during commuting home, phone 100 connects to the internet from 6:00-6:30 PM, at the office; and from dinner until rest, phone 100 connects to the internet from 8:00-9:30 PM, at home.The app usage times corresponding to the user demand profile are as follows: During the user's wake-up and breakfast period, news apps and weather forecast apps are used from 6:30-6:50 AM; during the user's commute, short video apps and subway apps are used around 8:00-8:30 AM; during the user's morning tea period, chat apps and short video apps are used around 10:00-10:20 AM; during the user's lunch and lunch break, news apps are used from 12:00-1:00 PM; during the user's afternoon tea period, the phone connects to the internet from 4:00-4:30 PM; during the user's commute home, short video apps and subway apps are used from 6:00-6:30 PM; and after the user's dinner and before resting, game apps and document apps are used from 8:00-10:00 PM. The location characteristics of each app's usage are understandable and will not be elaborated upon here. In the diagram, the "dots" in the network (including background) indicate that the phone will periodically wake up to connect to the network in the background, but the time is extremely short and can be disregarded as a key factor in determining network optimization time.

[0110] In addition, the user demand profile (i.e. usage characteristic information) may also include the following information (not shown in the figure): the specific APP information used by mobile phone 100 during specific network connection time periods, such as using a news APP to browse news when mobile phone 100 is connected to the network from 6:30 to 6:50, and opening a weather forecast APP when it is not connected to the network from 6:50 to 7:00. The specific APP information used in other time periods will not be elaborated here.

[0111] The detected fault characteristics corresponding to the usage characteristics include: the phone 100 experienced lag around 8:15 when the user was commuting to work; lag occurred between 12:00 and 12:10 when the user was eating in the cafeteria due to congestion caused by many devices accessing the network; network connection abnormalities occurred when the user made a call on a chat app during afternoon tea between 16:05 and 16:10; and lag occurred when the user used a short video app between 21:00 and 21:15 after dinner and before going to bed.

[0112] User experience profile content (i.e., user operation information indicating poor network quality) includes: around 8:15, user's up-and-down swiping touch screen operations / repeated clicks / re-entry operations on the APP, indicating poor network performance; between 12:00 and 12:03, user's on / off reset operations of airplane mode, cellular network, and Wi-Fi network controls, indicating poor network performance; around 21:00, user's on / off reset operations of airplane mode, cellular network, and Wi-Fi network controls, indicating poor network performance.

[0113] Understandably, other terminal devices can also obtain their own historical usage and fault information in the same way that mobile phone 100 obtains historical usage and fault information based on historical data, and send the obtained historical usage and fault information directly to mobile phone 100, or send it to mobile phone 100 through the cloud.

[0114] S402 determines the network optimization time and corresponding network optimization operation based on historical usage characteristic information and historical fault characteristic information.

[0115] In some embodiments, a prediction model for predicting network optimization time and network optimization operation can be pre-configured. This prediction model uses historical usage characteristics and historical network failure characteristics of the acquired mobile phone 100 as training samples to learn the user's historical usage characteristics and historical network failure characteristics of the device on various dates. It then predicts the possible network failure time of the mobile phone 100 in a subsequent time period (e.g., daily or user-specified time period), and determines the network optimization time and network optimization operation corresponding to each failure time. Specifically, when determining the network optimization time and network optimization operation corresponding to each failure time, the prediction model can directly use any relatively recent time before the predicted failure time as the network optimization time. Furthermore, in predicting the failure time of the mobile phone 100, the corresponding network optimization time, and the corresponding network optimization operation, the prediction model can also predict intermediate data such as the device screen-on time and device network connection time of the mobile phone 100 during a day or a user-specified time period. Based on the device screen-on time, device network connection time, and the failure time, it can further determine the network optimization time and corresponding network optimization operation for each failure time. For example, as mentioned above, the network optimization time can be the time in the most recent idle state before the fault time, or it can be the time in the service state to which the fault time belongs, before the fault time. Furthermore, when the terminal device detects that the current time matches a certain network optimization time during operation, and performs optimization using the network optimization operation corresponding to that network optimization time, the network optimization operation can continue for a relatively long time, for example, continuing until after the fault period ends. See the above for details. Figure 3A The description of that will not be repeated here.

[0116] Understandably, historical usage data from multiple dates can reflect a user's habitual patterns when using the phone. Similarly, the historical network failure time information from multiple dates included in the failure data can reflect the patterns of failure occurrence when the user uses the phone, thus allowing for the prediction of potential network failure times for the terminal device within a day or a specified user-defined time period. Furthermore, the network optimization time corresponding to each failure time can be determined based on the predicted failure times.

[0117] In addition, in other embodiments, when determining the network optimization time corresponding to each fault time and the network optimization operation corresponding to each network optimization time, the expected device state of the mobile phone 100 corresponding to the network optimization time can also be predicted, such as the on / off state of the device, the network state, the APP used, the specific operation performed by the APP, the location, and other information.

[0118] Understandably, since the usage characteristic information can include usage time characteristics (such as device screen-on time, device network connection time, usage time of each APP / type of APP on the terminal device, etc.), device location characteristics (such as the location when the device screen is on, the location when the device is connected to the network, the location when different APPs are used, etc.), network requirement characteristics when each APP is used, APP usage preference characteristics, device usage degree characteristics, etc., when determining the network optimization time, we can also obtain the expected device status of mobile phone 100 corresponding to the network optimization time.

[0119] In some implementations, rule matching (e.g., static or dynamic rule matching) can be used to predict the possible network failure times, corresponding network optimization times, and corresponding network optimization operations for a mobile phone based on usage and failure characteristics from multiple historical dates. Static rule matching uses pre-defined, fixed rules for matching; for example, it matches the current predicted date against historical dates, failing to cover situations where the predicted date might fall on a special holiday. Dynamic rule matching, on the other hand, dynamically adjusts and generates matching rules based on real-time conditions or data. For example, when multiple matching branches exist (such as periodic rule matching or holiday date rule matching), the optimal matching branch is selected based on past experience.

[0120] Understandably, in some other implementations, users can configure the desired network optimization time period and network optimization operations for the phone 100. The phone 100 can also provide a user interface (UI) configuration switch allowing users to customize the time period for predicting network optimization, the time period for performing network optimization operations, or the specific network optimization operations to be performed during the optimization time. This allows the phone 100 to flexibly execute network optimization operations after detecting the user-defined time and corresponding network optimization methods.

[0121] Specifically, the predicted date can be matched with usage and fault characteristics of multiple historical dates according to rules. Historical dates matching the predicted date are then selected. Based on the usage and fault characteristics of the matched historical dates, the predicted fault time for the device on the predicted date, along with the corresponding network optimization time and operations, can be predicted. At this point, the expected device state corresponding to the network optimization time can also be predicted.

[0122] Understandably, the network optimization time can be a certain time before the predicted failure time. Specifically, in predicting the failure time of mobile phone 100 on the predicted date, and the corresponding network optimization time and operation for each failure time, intermediate data such as the device screen-on time and device network connection time of mobile phone 100 on the predicted date can be predicted. Based on the device screen-on time, device network connection time, and the expected failure time, the corresponding network optimization time and operation for each failure time can be further determined.

[0123] Understandably, when the network optimization time is determined, the corresponding network optimization operation can also be determined.

[0124] In some embodiments, the network optimization operation corresponding to the determined network optimization time may include multiple specific operations or a single operation, and may be of different types. In some embodiments, when multiple specific operations need to be performed, the number and order of the specific operations can be determined.

[0125] In other embodiments, specific network optimization operations targeting historical network faults and restoring the network can be directly applied based on historical fault characteristics. Furthermore, in some embodiments, the same network optimization operation is performed each time; this is not required.

[0126] For example, as mentioned earlier, network optimization operations can be either lossless or lossy. The specific type of network optimization operation used can be determined by the idle or active state of the network during the optimization period. For instance, when the mobile phone is connected to the internet, a lossless optimization operation is used; or, if the lossless optimization operation is ineffective, a lossy optimization operation is further upgraded to avoid impacting internet access. When the mobile phone is not connected to the internet, a lossy optimization operation is used. Alternatively, the impact of network optimization operations on the device's internet access can be disregarded, and either lossless or lossy optimization operations can be performed during the network optimization period. It is understood that lossy and lossless optimization operations can be performed individually or in combination during the network optimization period.

[0127] For example, refer to Figure 4BBased on historical user demand profiles (i.e., corresponding usage characteristic information), user experience profiles (i.e., user operation information indicating poor network quality), and detected fault characteristic information for weekdays, the predicted fault times G1, G2, G3, and G4 for mobile phone 100 on a weekday are approximately 8:15, 12:00, 16:05, and 21:00, respectively. The corresponding network optimization times S1, S2, S3, and S4 for each fault time G1, G2, G3, and G4 are 8:00, 11:50, 16:00, and 20:58, respectively. Furthermore, after reaching the network optimization time, mobile phone 100 can continue performing network optimization operations for a relatively long period. Understandably, when predicting each fault time, the screen-on time and network connection time of mobile phone 100 can also be predicted. The corresponding network optimization time is obtained based on the specific screen-on time, network connection time, and fault time. The screen-on time is 6:30-7:00, 8:00-8:30, 12:00-13:30, 16:00-16:30, and 20:00-22:30; the network connection time is 6:30-6:50, 8:00-8:30, 10:00-10:20, 12:00-13:00, 16:00-16:30, and 20:00-21:30. At this time, the network optimization time can be either the service state or the idle state before the phone's fault time. Network optimization time S1 belongs to the service state before fault time G1, network optimization time S2 belongs to the idle state before fault time G2, network optimization time S3 belongs to the service state before fault time G3, and network optimization time S4 ​​belongs to the service state before fault time G4. Furthermore, it can be predicted that during network optimization time S1, the expected device status of mobile phone 100 will be: screen on, connected to the internet, using a short video app, using cellular network, and located on the subway; during network optimization time S2, the expected device status of mobile phone 100 will be: screen off; during network optimization time S3, the expected device status of mobile phone 100 will be: screen on, connected to the internet, using a news app, using the company cafeteria's Wi-Fi network, and located in the cafeteria; and during network optimization time S4, the expected device status of mobile phone 100 will be: screen on, connected to the internet, using a game app, using home Wi-Fi network, and located at home. Moreover, network optimization time S1 corresponds to lossless optimization operation, network optimization time S2 corresponds to lossy optimization operation, network optimization time S3 corresponds to lossless optimization operation, and network optimization time S4 ​​corresponds to lossless optimization operation.

[0128] Understandably, the predictive model determines network optimization times and corresponding network optimization operations based on historical usage and fault characteristics, which can be executed periodically, such as at preset times every morning and evening. Alternatively, predictions can be made when the software configured with the predictive model needs to be updated, or every time a phone is detected to be powered on. Furthermore, trigger conditions can be configured. For example, the predictive model can predict the expected device state (including the expected location of the device, the expected network connection status of the phone, and the expected usage status of the app) at a fixed time point E1 each day, and then match the current device state with the predicted expected device state at that fixed time point E1. If they do not match, the predictive model changes the matching rules during rule matching to obtain a new network optimization time and corresponding network optimization operations.

[0129] S403 performs network optimization operations during network optimization time.

[0130] In some embodiments, when the mobile phone 100 is running, if it detects that the current time matches the network optimization time, it immediately executes the network optimization operation corresponding to the network optimization time. For example, if it detects that the current time is a certain network optimization time, or that the time interval between the current time and a certain network optimization time is less than a preset time threshold (e.g., 1 second), it is considered that the current time matches the network optimization time.

[0131] In some embodiments, when the mobile phone 100 is running, if it detects that the current time matches a certain network optimization time and the current device state of the mobile phone 100 matches the expected device state corresponding to that network optimization time, then network optimization is performed using the network optimization operation corresponding to that network optimization time. If it detects that the actual device state of the terminal device does not match the expected device state corresponding to that time period, the terminal device may not execute the network optimization operation corresponding to that network optimization time; if they match, then the network optimization operation corresponding to that network optimization time is executed. For example, the degree of overlap between the actual device state and the expected device state can be used to determine whether the actual device state matches the expected device state. If the degree of overlap is greater than a certain threshold, the actual device state is considered to match the expected device state, and the network optimization operation corresponding to that network optimization time is executed; otherwise, the network optimization operation corresponding to that network optimization time is not executed.

[0132] Furthermore, in some embodiments, it can be determined whether the current device state needs to be matched with the expected device state corresponding to the network optimization time based on the type of network optimization operation (i.e., lossy or lossless). If the network optimization operation type is lossless, the network optimization operation is executed directly; if the current device is on and the network optimization operation type is lossy, it is determined whether the current device state of the mobile phone 100 matches the expected device state corresponding to the network optimization time. The network optimization operation is executed only if a match is found; otherwise, the network optimization operation is not executed.

[0133] In some implementations, when performing network optimization operations, multiple specific operations can be executed sequentially in a preset order. Specifically, network optimization operations can be executed according to their network layer or optimization level. For example, the network layers involved in a network optimization operation may include: (1) the application layer; (2) the data transmission layer; and (3) the chip layer. A specific network optimization operation may involve one or more of the aforementioned three layers. Understandably, the optimization level of a network optimization operation can be set manually.

[0134] In other implementations, the network optimization operations that previously cured the network fault are used directly, avoiding the use of other ineffective network optimization operations and saving power consumption when using optimization operations.

[0135] Furthermore, during network optimization operations, some operations are time-consuming, which may impact equipment services or lead to network failures. Therefore, during the execution of network optimization operations, adjustments can be made based on their impact on equipment services or their effectiveness in mitigating network failures. For example, if network optimization operations are expected to continue beyond the predicted failure period, and a network failure still occurs during the operation, the specific operations can be dynamically adjusted in real time. Similarly, if network optimization operations significantly impact internet access services during the predicted failure period, lossy optimization operations can be switched to lossless optimization operations.

[0136] For example, continue to refer to Figure 4BWhen mobile phone 100 detects that the current time is network optimization time S1, 8:00, it begins to perform lossless optimization operations, such as four-network operation and resource scheduling acceleration operation. When mobile phone 100 detects that the current time is network optimization time S2, 11:50, it directly performs lossy optimization operations, such as reconnecting to the base station or core network. When mobile phone 100 detects that the current time is network optimization time S3, 16:00, it continues to perform lossless optimization operations, such as four-network operation and resource scheduling acceleration operation. When mobile phone 100 detects that the current time is network optimization time S4, 20:58, it performs lossless optimization operations, such as synchronizing the application processor and modem chip on the IP / DNS server (i.e., AP and chip synchronization in the diagram).

[0137] The following describes specific network optimization operations.

[0138] In some embodiments of this application, specific network optimization operations may include operations to restore the network in response to network failures (i.e., self-healing operations) and operations to accelerate network data transmission based on resource scheduling (such as four-network operation, resource scheduling acceleration operation, etc.).

[0139] For example, corresponding APP self-healing retry operations can be adopted, including but not limited to: APP re-initiating the Domain Name System (DNS), APP rebuilding the socket / HTTP link, APP initiating a service retry without rebuilding, APP directly initiating data retransmission, APP directly initiating a new request, etc. Among these, in some embodiments of this application, the corresponding APP self-healing retry operations sometimes have a small impact on the business and can be approximately regarded as lossless optimization operations.

[0140] For example, such as Figure 4C As shown, the self-healing operation based on the cellular network can include (1) synchronization of the application processor (AP) and the modem chip on the Internet Protocol (IP) / Domain Name System (DNS) server; (2) Packet data network (PDN) activation: the PDN performs deactivation and reactivation operations, and sequentially applies to the core network for the allocation of IP and DNS servers for data services; (3) Base station / core network reconnection: this operation is usually accompanied by data updates of the user equipment on the operator's network side, and also performs a series of other communication establishment and configuration operations; (4) Flight mode reset: quickly reset the data network in the mobile phone. Among them, the synchronization of the application processor and the modem chip on the IP / DNS server is a lossless optimization operation, and the rest are lossy optimization operations.

[0141] like Figure 4C As shown, self-healing operations based on Wi-Fi networks can include (1) DNS server replacement, (2) Dynamic Host Configuration Protocol (DHCP) offer, i.e., configuring multiple DHCP servers to send DHCP offer messages to DHCP clients, (3) DHCP lease renewal operation, i.e., before the lease expires, the user equipment needs to send a "DHCP renew" request to the DHCP server to request the server to reassign an IP address or extend the lease time, (4) Wi-Fi reassociation, i.e., when the user equipment has already established an association with an access point (AP), it switches to another AP and re-establishes the association, and (5) chip reset. All self-healing operations based on Wi-Fi networks are lossy optimization operations.

[0142] Furthermore, operations that accelerate network data transmission based on resource scheduling can include: four-network operation and resource scheduling acceleration operation. The four networks include the primary cellular network, the secondary cellular network, the Wi-Fi 2.4G network, and the Wi-Fi 5G network, each with its own physical channel and IP address. In this case, four-network operation refers to using some or all of the physical channels of these four networks simultaneously to achieve data transmission. For example, if the phone is currently using the Wi-Fi 2.4G network, the primary cellular network can be activated in advance to transmit data along with the Wi-Fi 2.4G network. Resource scheduling acceleration operation includes ensuring air interface resources, increasing power, and coordinating resource protection between the device and the base station or cloud when using the cellular network. Both four-network operation and resource scheduling acceleration operation are lossless optimization operations.

[0143] For the aforementioned handover method of network standard switching, the switching time is short, generally around 100ms, and the RRC is not released or the IP address changes before and after the switch, so it is a lossless optimization operation. For the redirect or reselect method of network standard switching, the time required for redirection and reselection is generally longer, and the IP address may change, requiring the TCP or UDP link to be re-established. This results in a recovery time of generally more than 1 second for services in this scenario, giving users a sense of interruption. For network protocol version downgrading due to changes in 3GPP access information, such as a change in the Rel version number, a TAU or deattach / attach operation needs to be re-initiated to reactivate the cellular data service bearer and obtain a new IP address, so it is a lossy optimization operation.

[0144] S404 performs hit analysis and validity analysis on the results of network optimization operations.

[0145] In some embodiments, after the mobile phone 100 completes the network optimization operation during the network optimization period, it can perform hit analysis and effectiveness analysis on the network optimization operation. Hit analysis involves analyzing whether a network failure was predicted to occur, while effectiveness analysis involves analyzing whether the network optimization operation implemented in advance could resolve the network failure if it was predicted to occur.

[0146] If no network optimization is performed, it can be assumed that no network failure occurred during the prediction. However, if a failure does occur later, the prediction is considered a miss. This miss can be used as negative feedback to optimize and determine the timing of network optimization. Conversely, if network optimization is performed, it indicates that a network failure was imminent. Since network optimization was implemented in advance and no failure subsequently occurred, the prediction is assumed to have succeeded.

[0147] Similarly, if a failure is predicted and network optimization is implemented, but a network failure still occurs subsequently, the configured network optimization is considered ineffective. If a failure is predicted, network optimization is implemented in advance, and no network failure subsequently occurs, then the configured network optimization is considered effective by default.

[0148] Understandably, when performing hit analysis and effectiveness analysis on the results of network optimization operations, this analysis can be conducted based on whether network failures actually occurred on mobile phone 100 after the network optimization operation. Alternatively, it can be performed experimentally. For example, after predicting an impending network failure and determining the network optimization time, the network optimization operation can be suspended, and it can be observed whether mobile phone 100 experiences a network failure at the predicted failure time.

[0149] For example, if it is predicted that mobile phone 100 will experience a network failure between 9:00 and 9:10, and the network optimization time A1 is set to 8:50, then if the network optimization operation is performed at 8:50 and no network failure is detected, then the prediction is correct. If it is predicted that mobile phone 100 will not experience a network failure between 9:00 and 9:10, and no network optimization time is set, but mobile phone 100 experiences a network failure between 9:00 and 9:10, then the prediction is incorrect.

[0150] Furthermore, in other embodiments, during the execution of specific network optimization operations, a tiered network optimization approach can be used for recovery. This involves performing multiple levels of network optimization operations during the network optimization period. If an operation proves ineffective, the next level of optimization is quickly initiated. Once the network optimization operation restores the network, it stops, and the operation continues until network usage ceases. In this case, the effective measures to overcome this type of network failure can be used as the corresponding effective network optimization operation for the next prediction of the same network failure, so that it can be used subsequently when this type of network failure is predicted.

[0151] It should be noted that step S404 is optional.

[0152] S405, the prediction model is retrained based on the results of hit analysis and validity analysis to obtain an updated prediction model.

[0153] Understandably, after obtaining the results of hit analysis and validity analysis, these results can be used as new samples to train the prediction model, resulting in a prediction model that outputs network optimization time and network optimization operations with higher accuracy.

[0154] In addition, the effective measures to overcome this type of network failure determined during the execution of step S404 can be used as samples for the prediction model, so that the prediction model can determine effective network optimization operations when it predicts that this type of network failure will occur.

[0155] It should be noted that step S405 is optional.

[0156] It is understandable that in some other embodiments, steps S401 and S402 described above can also be executed by a cloud device. After the cloud device predicts the user's internet access time and network failure time of mobile phone 100, it can send the network optimization time and corresponding network optimization operation information to mobile phone 100, so that mobile phone 100 can perform network optimization operations based on the received information. The following is in conjunction with Figure 5 To elaborate.

[0157] Figure 5 According to an embodiment of this application, a flowchart of another network optimization method is shown. In this network optimization method, after the cloud device 200 obtains the historical usage characteristic information and historical fault characteristic information of the mobile phone 100, it determines the network optimization time of the mobile phone 100 and the corresponding network optimization operation, so that the mobile phone 100 performs the network optimization operation based on the received information. The specific steps are as follows:

[0158] S501, cloud device 200 obtains historical usage characteristic information and historical fault characteristic information of mobile phone 100 from mobile phone 100.

[0159] Understandably, the relevant information regarding the historical usage characteristics and historical fault characteristics of mobile phone 100 can be found in step S401 above, and will not be repeated here.

[0160] S502, cloud device 200 determines the network optimization time and corresponding network optimization operation of mobile phone 100 based on historical usage characteristic information and historical fault characteristic information.

[0161] It is understandable that the process by which the cloud device 200 determines the network optimization time and corresponding network optimization operation of the mobile phone 100 based on historical usage characteristic information and historical fault characteristic information is essentially the same as the process by which the mobile phone 100 determines the network optimization time and corresponding network optimization operation based on historical usage characteristic information and historical fault characteristic information in step S402 above, and will not be elaborated here.

[0162] S503, cloud device 200 sends information about the network optimization time and corresponding network optimization operation of mobile phone 100 to mobile phone 100.

[0163] S504, Mobile Phone 100 performs network optimization operations during network optimization time.

[0164] Understandably, this step is essentially the same as step S403 above, and will not be repeated here.

[0165] S505, Mobile phone 100 performs hit analysis and validity analysis on the network optimization operation execution results. It should be noted that step S505 is optional.

[0166] Understandably, this step is essentially the same as step S404 above, and will not be repeated here.

[0167] S506, mobile phone 100 sends the results of hit analysis and validity analysis to cloud device 200. It should be noted that step S506 is optional.

[0168] S507, the cloud device 200 retrains the prediction model based on the results of hit analysis and validity analysis to obtain an updated prediction model. It should be noted that step S507 is optional.

[0169] It is understandable that this step is essentially the same as step S405 above, and will not be repeated here.

[0170] The following section elaborates on the process by which mobile phone 100 obtains the device usage time characteristics, device location characteristics, and network requirement characteristics of each APP used in the user demand profile in step S401.

[0171] For example, Mobile Phone 100 collects information such as the specific time and location of the user's use of Mobile Phone 100, the types of apps used, network conditions during each time period (e.g., whether connected to the internet, network metrics such as data usage, bandwidth, latency, jitter, and packet loss rate when connected, network type (cellular or Wi-Fi), domain names accessed by the apps, and IP versions used by the apps), whether Mobile Phone 100 experienced network failures, the type of network failure, and user-manually performed feedback actions. Based on this large amount of historical data, a neural network model is used for feature learning to generate a user profile, which includes a user needs profile and a user experience profile. The user needs profile includes device usage time characteristics (e.g., device screen-on time, device internet connection time, usage time of various apps / app types on the terminal device), device location characteristics (e.g., location when the device screen is on, location when the device is connected to the internet, location when different apps are used), network requirements for each app, app usage preferences, and device usage frequency.

[0172] (1) For example, regarding the above-mentioned device usage time characteristics, Figure 6A According to some embodiments of this application, a schematic diagram is shown illustrating the screen-on pattern (i.e., screen-on time characteristics) of mobile phone 100 during weekday use, derived from the user's daily usage information of mobile phone 100 over the past 5 weekdays. Thursday and Friday are not shown. Specifically, Figure 6AThe image shows the specific usage information of mobile phone 100 during user activities on Monday, Tuesday, and Wednesday (some specific information is omitted in the image), as well as the screen-on time characteristics of mobile phone 100 during user activities on weekdays. Specifically, on Monday, the user's usage time of mobile phone 100 (i.e., the screen-on time of mobile phone 100) is as follows: breakfast time 6:30-7:00, commuting time 8:00-8:25, morning tea time 10:00-10:20, lunch / nap time 12:00-13:20, afternoon tea time 16:00-16:20, before leaving get off work and commuting time 18:00-18:30, and after dinner / before going to bed time 20:00-22:00. On Tuesdays, the corresponding time slots for users to use the 100 mobile phone service are 6:20-7:00, 8:00-8:25, 10:00-10:20, 12:00-13:20, 16:00-16:20, 18:00-18:30, and 20:00-22:00. On Wednesdays, the corresponding time slots for users to use the 100 mobile phone service are 6:40-7:00, 8:00-8:30, 10:00-10:20, 12:00-13:20, 16:00-16:20, 18:00-18:30, and 20:00-22:30. Thursdays and Fridays are not described here. At this point, we can determine that the screen-on times of phone 100 are 6:30-7:00, 8:00-8:25, 10:00-10:20, 12:00-13:20, 16:00-16:20, 18:00-18:30, and 20:00-22:30. Understandably, although the time spent using the phone during breakfast and after dinner / before bedtime are different, we can still determine the screen-on time pattern of phone 100. For example, a broad coverage approach can be adopted, selecting the screen-on time characteristics of phone 100 according to the largest time range: breakfast time (6:30-7:00), commuting time (8:00-8:30), morning tea time (10:00-10:20), lunch / nap time (12:00-13:20), afternoon tea time (16:00-16:20), time before leaving get off work and commuting (18:00-18:30), and time after dinner / before bedtime (20:00-22:30). Alternatively, in other implementations, the overlapping portion can be covered, or a hybrid approach can be used, partially covering the maximum coverage and partially covering the overlapping portion, thus obtaining the final screen-on time characteristics of phone 100 for the workday.

[0173] Similarly, the above is merely an example of the screen-on time characteristics of the phone 100 obtained based on a week's worth of screen-on data. In this case, we can also consider the specific usage information of the phone 100 at different times of day. For example, the phone 100 might turn on its screen at 6:30 AM, use Wi-Fi, open a news app to browse news, and open a weather forecast app to check the weather, for a period of half an hour. During the user's commute, the phone might start using cellular data on the bus or subway at 8:00 AM, browsing short video apps, experiencing lag around 8:15 AM, and arriving at the office at 8:25 AM. During the user's morning tea break, the phone 100 might be used to reply to messages on a chat app and browse short video apps around 10:00-10:20 AM. During the user's lunch break, the phone 100 might be used to access the company cafeteria's Wi-Fi and browse news apps. Furthermore, detailed usage information, such as congestion caused by numerous network devices in the cafeteria, allows for the generation of other time-related characteristics. These include device network connection times and the usage times of various apps (e.g., the time periods, durations, and frequency of each app's use). Additionally, detailed device information from multiple workdays can be used to generate more refined patterns in workday patterns.

[0174] (2) For example, regarding the aforementioned device location characteristics, mobile phone 100 can obtain the device's location characteristics during movement based on specific information used. For instance, when a user enters the subway, mobile phone 100 will typically have its screen on and connected to the internet, and will enter the station via a subway app. In this case, mobile phone 100 can collect the device's location information when entering and exiting the subway, its location information during subway travel, screen on / off information, specific usage time / duration information, app information used, network conditions, etc., and then integrate and learn the information obtained from the user's multiple subway entries and exits to obtain the location characteristics of mobile phone 100 when entering and exiting the subway, the location characteristics of mobile phone 100 when connected to the internet, and the location characteristics of specific apps used on mobile phone 100. For example, entering the subway station can be considered as the location corresponding to the screen-on start time of mobile phone 100, and exiting the subway station can be considered as the location corresponding to the screen-off time of mobile phone 100; if some users do not usually use the device when taking the subway, the short time before and after entering and exiting the station can be considered as the location corresponding to the screen-on time, and the time during subway operation can be considered as the unused time. Understandably, once a location route is generated, device location characteristics can also be used to predict subsequent network optimization times. Furthermore, device location characteristics can reflect the specific time period during which the user uses the device, facilitating accurate prediction of network optimization times for scenarios where time characteristics are not readily apparent.

[0175] (3) For example, for the network requirements of each APP, the mobile phone 100 obtains the network requirements of each APP based on the specific historical data such as traffic, time, duration, bandwidth, latency, packet loss rate, and network type when using the specific APP. That is, the time period, duration, and frequency of the APP being used by the user, the traffic threshold, bandwidth, latency, packet loss rate and other indicators required for the APP to not lag when it is used by the user, and the requirements such as whether the APP is used by the user on a cellular network or a Wi-Fi network.

[0176] (4) For example, the predicted device screen-on time, device network connection time, and downtime will differ depending on the user group of the mobile phone (100) and their preferences for APP usage characteristics and device usage frequency characteristics. (Reference) Figure 6B Users can be categorized based on their phone usage frequency and app preferences. For example, due to different user preferences, people who frequently use their phones while commuting tend to keep their screens on and browse, suggesting that this user will likely continue to do so. Therefore, we can obtain app usage preference characteristics and device usage characteristics for each user category.

[0177] Furthermore, the user profile in step S401 can also be refined according to the time frame for measuring and analyzing things, further subdividing the user profile along the time dimension. For example, a user profile can include specific content such as device usage time characteristics, device location characteristics, network requirements when using a specific app, app usage preferences, device usage intensity, and user experience feedback. However, the specific information content corresponding to these characteristics differs across different time dimensions. For instance, the specific content of these characteristics will differ in time dimensions with clear cyclical patterns, such as weekdays, weekends, during work hours, after work hours, and Mondays. Figure 6C The user profiles shown include those for weekdays, weekends, during-work hours, after-work hours, and Mondays. Each specific time period profile can include device usage time characteristics, device location characteristics, network requirements when using specific apps, app usage preferences, device usage intensity, and fault information, etc., based on the user's specific usage information of mobile phone 100 over multiple weekends.

[0178] Understandably, in some embodiments, the above primarily relies on historical data from terminal devices to obtain usage characteristic information for multiple historical dates and historical fault characteristic information (e.g., historical fault times) of network failures on multiple historical dates. Based on this usage characteristic information and historical fault times of network failures on multiple historical dates, the network optimization time and method for a given day are determined. In other words, a time-dimensional user profile is obtained based on historical data from terminal devices, and predictions are made based on this time-dimensional user profile.

[0179] Furthermore, in other embodiments, when the terminal device learns from historical data to obtain user profiles, it can also obtain usage characteristic information corresponding to multiple different locations and historical fault characteristic information (e.g., historical fault time). That is, it obtains user profiles corresponding to different location characteristics. For example, the content of the user profile will differ when mobile phone 100 passes through different cells, is located at different latitudes and longitudes, and at different altitudes. (See reference...) Figure 6D This allows for the creation of user profiles for different commuting routes, home locations, and work environments. Each specific area's profile can include characteristics such as device usage time, device location, network requirements when using specific apps, app usage preferences, device usage frequency, and fault information. For example, based on information about multiple users using their phones at home, it's possible to obtain details like screen-on time, network connection time, app usage time, network failure times after a period of time at home, and locations prone to network failures at home. Therefore, when a user is identified as being at home, the system can predict network optimization time and actions based on the home user profile and failure times.

[0180] For example, based on historical usage characteristics and network failure times from multiple historical dates, mobile phone 100 can predict the possible network failure times, network optimization times, network optimization operations, and expected device states for a given day. During operation, if the current time matches a network optimization time and the current device state differs from the expected device state, mobile phone 100 can use the usage characteristics and historical failure information corresponding to that current location to re-predict a new network optimization time and operation. For instance, when mobile phone 100 detects a location change, it can generate a new prediction model based on the new location or directly retrieve prediction models from other devices at that new location from the cloud. This allows mobile phone 100 to optimize the terminal device's network using the network optimization operation corresponding to that new network optimization time when the current time matches a new network optimization time.

[0181] Figure 7A According to some embodiments of this application, a network optimization system architecture diagram is shown. This system architecture includes a mobile phone 100, a cloud device 200 communicating with it, and peripheral devices 300. The mobile phone 100 includes a system software architecture 610 and a chipset 620.

[0182] Specifically, the system software architecture 610 includes: application layer 611, framework layer 612, hardware abstraction layer 613, kernel layer 614, etc.

[0183] Application layer 611 includes various apps that users can use.

[0184] Framework layer 612 provides a series of interfaces and services for application development, and also provides preventative network optimization functionality. Specifically, framework layer 612 includes an interface module and a network optimization module for implementing network optimization.

[0185] The interface module, based on the interface mechanism, adds or modifies information in the network optimization module according to the content information of each APP, such as current usage information and historical usage information, so that the APP and the network optimization module work together to perform network optimization operations, thereby minimizing network lag.

[0186] The network optimization module may include: a fault detection module, a system and environment module, an information aggregation module, a user profiling module, a fault feature information and user profile transmission module, a prediction module, and a hit and effectiveness analysis module.

[0187] The fault detection module includes fault characteristic information detected by the system using QoS and QoE or reported by apps. The system and environment module includes information such as device power consumption, traffic, performance, and thermal status, as well as information on the current network type (cellular or Wi-Fi), and whether it has dual SIM cards or dual Wi-Fi. The user profile module includes user demand profiles and user experience profiles. The user demand profile provides usage characteristics of the device, including usage time, location, network requirements for various apps, app usage preferences, and device usage frequency. The user experience profile is based on user feedback indicating poor network quality. The user experience profile content can also serve as fault characteristic information.

[0188] The fault characteristic information and user profile transmission module involves data uploading, downloading, broadcasting, and receiving. Specifically, mobile phone 100 uploads locally detected fault characteristics and user profiles to cloud device 200, and also downloads fault characteristics and user profiles reported by other terminals or learned by cloud device 200 itself. It's important to note that the fault characteristic information and user profiles uploaded to cloud device 200 are generally anonymized and do not contain personal information. The purpose of cloud device 200 is to prevent mobile phone 100 from learning through trial and error on its first attempt. For example, refer to... Figure 7B When mobile phone 100 transmits and shares data with cloud device 200 and peripheral devices, mobile phone 100 can upload data to cloud device 200 or actively query cloud device 200 (i.e., polling). Cloud device 200 responds to mobile phone 100 and sends data to mobile phone 100. Peripheral device 300 can actively broadcast to mobile phone 100, and mobile phone 100 can also actively query peripheral device 300 (i.e., polling). Then peripheral device 300 responds to mobile phone 100 and sends data to mobile phone 100.

[0189] Information aggregation module: This module obtains fault characteristic information and user profiles from multiple channels, including local devices, cloud devices (200), and peripheral devices (300). It includes fault characteristic information and user profiles specific to each user's device as well as general information.

[0190] Prediction module: It is used to predict the network optimization time, location, and corresponding network optimization operation based on preset static or dynamic rules, or to predict the expected device state at the network optimization time.

[0191] Hit and effectiveness analysis module: Used to evaluate whether the network optimization time setting is correct and whether the network optimization operation is effective based on the response to the executed network optimization operation.

[0192] Execution module: Primarily responsible for performing network optimization operations. For example, network optimization operations can be executed according to different layers involved or at different levels. Furthermore, if network optimization operations are ineffective, a feedback mechanism can be used to escalate the execution measures.

[0193] The hardware abstraction layer 613 includes the radio interface layer (RIL), the network daemon (NETD), and other modules.

[0194] Kernel layer 614 includes the TCP / IP protocol stack and various drivers.

[0195] The chipset 620 includes a modem chip, a Wi-Fi chip, a Bluetooth chip, a satellite chip, etc.

[0196] Figure 8 According to an embodiment of this application, a schematic diagram of the hardware structure of a mobile phone 100 is shown.

[0197] Mobile phone 100 can execute the network optimization method provided in the embodiments of this application. Figure 8 In this context, similar components share the same reference numerals. For example... Figure 8 As shown, the mobile phone 100 may include a processor 110, a power module 140, a memory 180, a mobile communication module 130, a wireless communication module 120, a sensor module 190, an audio module 150, a camera 170, an interface module 160, buttons 101, and a display screen 102, etc.

[0198] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the mobile phone 100. In other embodiments of this application, the mobile phone 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0199] Processor 110 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. Processor 110 can execute the network optimization methods provided in the embodiments of this application. For example, executing the above... Figure 4A or Figure 5 The flowchart of the network optimization method is shown.

[0200] The display screen 102 is used to display human-computer interaction interfaces, images, videos, etc. The display screen 102 includes a display panel.

[0201] The mobile communication module 130 may include, but is not limited to, an antenna, a power amplifier, a filter, and a low-noise amplifier (LNA). The mobile communication module 130 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use on the mobile phone 100. The mobile communication module 130 can receive electromagnetic waves via the antenna, filter and amplify the received electromagnetic waves, and then transmit them to a modem processor for demodulation. The mobile communication module 130 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna. In some embodiments, at least some functional modules of the mobile communication module 130 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 130 and at least some modules of the processor 110 may be housed in the same device.

[0202] The wireless communication module 120 may include an antenna, which enables the transmission and reception of electromagnetic waves. The wireless communication module 120 can provide solutions for wireless communication applications on the mobile phone 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The mobile phone 100 can communicate with networks and other devices through wireless communication technologies.

[0203] In some embodiments, the mobile communication module 130 and the wireless communication module 120 of the mobile phone 100 may also be located in the same module.

[0204] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0205] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0206] This application also provides a computer program product that, when executed on an electronic device, enables the electronic device to implement the network optimization methods provided in the foregoing embodiments.

[0207] This application also provides a computer-readable storage medium storing one or more programs, which, when executed by an electronic device, enable the electronic device to implement the network optimization methods provided in the foregoing embodiments.

[0208] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0209] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor, a microcontroller, an application-specific integrated circuit, or a microprocessor.

[0210] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0211] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried on or stored thereon on one or more transient or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media can include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, compact disc-read-only memory (CD-ROMs), magneto-optical disks, read-only memory (ROM), random-access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagation signals. Therefore, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0212] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0213] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0214] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 limitations, 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.

[0215] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

Claims

1. A network optimization method, characterized in that, Applied to a terminal device, the method includes: The current time of the terminal device is detected to match the first network optimization time. The first network optimization time includes a time corresponding to the first predicted failure time and preceding the first predicted failure time. The first predicted failure time and the first network optimization time are obtained based on the historical usage characteristics and historical failure times of the terminal device in multiple historical time periods. Execute the first network optimization operation corresponding to the first network optimization time.

2. The method according to claim 1, characterized in that, The historical usage characteristic information includes at least the usage time characteristics of the terminal device within a historical time period; and The first network optimization time is obtained based on the usage time characteristics and the historical failure time prediction; and The first network optimization time is the time during which the terminal device is in an idle state before the first predicted failure time, or the first network optimization time is the time during which the terminal device is in a recently active state before the first predicted failure time.

3. The method according to claim 1, characterized in that, The detection that the current time of the terminal device matches the first network optimization time includes: During operation, the terminal device detects that the current time is the first network optimization time.

4. The method according to claim 1, characterized in that, Also includes: After the first predicted failure time, the first network optimization operation is stopped.

5. The method according to any one of claims 1-4, characterized in that, The first network optimization operation includes lossy optimization operation and / or lossless optimization operation.

6. The method according to claim 5, characterized in that, The execution of the first network optimization operation corresponding to the first network optimization time includes: The first network optimization operation includes lossy optimization operation and lossless optimization operation, and the lossless optimization operation is used to optimize the network of the terminal device.

7. The method according to claim 6, characterized in that, Also includes: If the network of the terminal device has a network fault after the lossless optimization operation is performed, the lossy optimization operation is performed to optimize the network of the terminal device.

8. The method according to any one of claims 1-4, wherein the first network optimization operation includes optimization operations involving multiple network layers, the network layers including at least two of the application layer, data transmission layer, and chip layer; and, performing the first network optimization operation corresponding to the first network optimization time during the first network optimization time includes: The optimization operation involving multiple network layers is performed according to the preset network layer order.

9. The method according to any one of claims 1-8, characterized in that, Before performing the first network optimization operation corresponding to the first network optimization time, the method further includes: The current device status of the terminal device and the expected device status corresponding to the first network optimization time are obtained, wherein the expected device status corresponding to the first network optimization time is obtained based on the historical usage characteristic information and historical failure time of the terminal device; Under the condition that the current device state and the expected device state satisfy a first matching condition, a first network optimization operation corresponding to the first network optimization time is executed.

10. The method according to claim 9, characterized in that, Also includes: If the current device state and the expected device state do not meet the first matching condition, the second network optimization time is re-predicted based on the current device state.

11. The method according to claim 9 or 10, characterized in that, The first matching condition includes: the degree of overlap between the current device state of the terminal device and the expected device state corresponding to the first network optimization time satisfies the first overlap threshold.

12. The method according to claim 9, characterized in that, The step of obtaining the current device status of the terminal device and the expected device status corresponding to the first network optimization time includes: If the first network optimization operation includes a lossy optimization operation, the current device state of the terminal device and the expected device state corresponding to the first network optimization time are obtained.

13. The method according to claim 9, characterized in that, The device status includes at least one of the following: the on / off state of the terminal device during use, the network status, the specific information of the application being used, the specific operations performed when using the application, and the location of the terminal device.

14. The method according to claim 5, characterized in that, The lossless optimization operation includes at least one of the following: synchronization of the application processor and modem chip on the IP or DNS server, four-network operation, resource scheduling acceleration operation, switching of network standard according to the corresponding handover method, downgrading of HTTP protocol version for the corresponding IP without change, and operation of self-healing retry for the corresponding application. The lossy optimization operations include at least one of the following: downgrading the network protocol version corresponding to the network standard or the access information change corresponding to the 3GPP protocol in the corresponding redirection or reselection method; activating the packet data network under the cellular network; reconnecting the base station or core network under the cellular network; resetting the flight mode under the cellular network; replacing the domain name system server under the Wi-Fi network; using the multi-dynamic host configuration protocol server under the Wi-Fi network; Wi-Fi reassociation; and resetting the Wi-Fi chip.

15. The method according to any one of claims 2-14, characterized in that, The usage characteristic information also includes: the device location characteristics of the terminal device within a historical time period, the network requirement characteristics when each application is used, the usage preference characteristics of the application, and the usage degree characteristics of the device. The usage time characteristics include one of the following: the device screen-on time in the terminal device during the historical time period, the device network connection time in the terminal device during the historical time period, the usage time of each application in the terminal device during the historical time period, and the usage time of each type of application in the terminal device during the historical time period. The device location features include at least one of the following: the location of the terminal device when the screen is on during a historical time period, the location of the terminal device when the device is connected to the Internet during a historical time period, and the location of the terminal device when different applications are used during a historical time period.

16. The method according to claim 1, characterized in that, The first network optimization time is obtained in the following way: The historical usage characteristics of the terminal device within the multiple historical time periods and the corresponding historical failure times of the historical usage characteristics are matched with the first time period according to a preset rule to determine at least one network optimization time in the first time period, wherein the at least one network optimization time includes the first network optimization time.

17. The method according to claim 16, characterized in that, Also includes: Perform hit analysis and / or validity analysis on the execution results of the first network optimization operation; based on the analysis results of the hit analysis and / or validity analysis, as well as the historical usage characteristic information and the historical failure time, predict the network optimization time within the second time period.

18. The method according to any one of claims 1-17, characterized in that, The historical fault time includes the first historical fault time when the terminal device detected a network fault within a historical time period, and the second historical fault time when the terminal device detected user operations indicating poor network quality within a historical time period.

19. The method according to claim 18, characterized in that, The user actions indicating poor network quality include at least one of the following: Users can launch, exit, fast forward, swipe up and down, tap repeatedly, or re-enter the application. The user can turn on, turn off, or reset at least one of the following: Wi-Fi network control, cellular network control, airplane mode control, 5G switch control, primary SIM card control, and secondary SIM card control. Users can change their data usage limits or query their data usage.

20. An electronic device, characterized in that, include: One or more processors; One or more memory units; One or more memories store one or more programs, which, when executed by one or more processors, cause the electronic device to perform the network optimization method according to any one of claims 1-19.

21. A readable storage medium, characterized in that, The readable medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the network optimization method according to any one of claims 1-19.

22. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the network optimization method according to any one of claims 1-19.

Images