Communication link management method, electronic equipment, readable storage medium and chip

Abstract

The invention provides a communication link management method, electronic equipment, a readable storage medium and a chip, and relates to the technical field of communication. The method is applied to the electronic equipment comprising an application processor (AP) and a communication processor (CP), and the electronic equipment does not establish a communication link. The method comprises the following steps: in response to a first event, an AP sends a network preheating command to a CP before sending an internet protocol (IP) message to the CP; wherein the IP message is a first message which is predicted to be sent by the AP; and the CP establishes a communication link with the wireless access network equipment according to the network preheating command. According to the method provided by the embodiment of the invention, after the IP message reaches the CP, the CP can quickly send the IP message through the communication link, so that the time of waiting for transmission of the IP message on the CP side is shortened or avoided, the sending speed of the IP message can be improved, and the sending time delay of the IP message can be reduced.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method for managing a communication link, an electronic device, a readable storage medium, and a chip. Background Technology

[0002] Electronic devices typically have various applications installed. During operation, these applications usually need to interact with network-side devices, including sending application data to the network-side devices.

[0003] Currently, when electronic devices send application data to network-side devices, they typically first encapsulate the application data into several Internet Protocol (IP) packets at the application processor (AP) side, and then sequentially send the encapsulated IP packets to the communication processor (CP) for transmission. It should be noted that in this process, if the CP has not established a communication link with the radio access network (RAN) device when the IP packets reach the CP, it must wait for the communication link to be established before it can begin sending IP packets. This results in a relatively slow IP packet transmission speed.

[0004] Understandably, in scenarios with stringent latency requirements, slower IP packet transmission speeds can lead to a poor user experience. For example, in scenarios such as ticket grabbing, red envelope grabbing, stock trading, or accessing the application's homepage, users may fail to grab tickets / red envelopes / stock trades, or the application's homepage may load slowly. Summary of the Invention

[0005] This application provides a communication link management method, electronic device, readable storage medium, and chip method and apparatus to solve the problem of slow IP packet transmission speed in the prior art.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] In a first aspect, embodiments of this application provide a method for managing a communication link. The method is applied to an electronic device, which includes an application processor (AP) and a communication processor (CP). The electronic device has not yet established a communication link. The method includes: in response to a first event, the AP sends a network warm-up command to the CP before sending an IP packet to the CP; wherein the IP packet is the first packet that the AP predicts needs to send; and the CP establishes a communication link with the wireless access network device according to the network warm-up command.

[0008] The method provided in this application embodiment allows the CP to establish a communication link in advance before the first IP packet arrives at the CP from the AP. This enables the CP to quickly send the IP packet through the communication link after the first IP packet arrives at the CP, shortening or avoiding the waiting time for the IP packet to be transmitted on the CP side, thereby improving the sending speed of the first IP packet and reducing its transmission latency.

[0009] It is understandable that in scenarios such as flash sales, ticket grabbing, red envelope grabbing, stock trading, and opening application homepages, electronic devices based on this method can quickly communicate with network-side devices, increasing the likelihood of successful flash sales / ticket grabbing / red envelope grabbing and successful stock trading, improving the speed of application homepage opening, and providing a better user experience.

[0010] In some embodiments, the method further includes: after the AP sends a network warm-up command to the CP, it sends an IP packet to the CP; the CP sends the IP packet through the communication link.

[0011] As can be seen, in this embodiment, the generation of IP packets and the packet migration process from the AP to the CP are performed in parallel with the network warm-up process. Compared to the serial processing of packet generation and migration with network warm-up, the parallel processing method reduces the waiting time after the IP packets arrive at the CP, and can quickly send out the arriving IP packets.

[0012] In some embodiments, the network warm-up command includes at least one of first-time information, uplink data volume, and link type. It is understood that, based on the first-time information, uplink data volume, and link type, the CP can perform network warm-up more accurately.

[0013] In some embodiments, the first time information is the predicted start time of an upcoming network task; or, the first time information is the estimated time when an IP packet arrives at the CP; or, the first time information is the time when the CP begins network warm-up.

[0014] In this embodiment, based on the first-time information, the CP can more accurately control the start time of network warm-up, so that the CP completes network warm-up exactly when the first IP packet arrives. This not only reduces the waiting time for IP packets to be sent after arriving at the CP, but also reduces the idle time of the communication link after the CP has pre-established it, thus fully realizing the rational utilization of resources.

[0015] In some embodiments, the uplink data volume is the size of an IP packet or the amount of data to be sent within a preset time. When the uplink data volume is the amount of data to be sent within a preset time, the uplink data volume includes the amount of data to be packetized within the preset time, and the amount of data that has been packetized but not yet sent to the CP. For example, for a cellular warm-up scenario, the preset time is one buffer status report (BSR) cycle. For a Wi-Fi warm-up scenario, the preset time is the length of the channel occupancy period indicated in the clear to send (CTS) frame broadcast by the network-side device.

[0016] In some embodiments, the first event includes at least one of the following: the application calls the network interface; the AP receives a network task notification from the application; an artificial intelligence (AI) model predicts that network warm-up is needed; a user action, application event, or network event is used to trigger network warm-up; target text information is identified in the display interface / schedule information / electronic alarm clock; a notification message about a scheduled network task is received from a server or surrounding electronic device; and the operating system performs pre-establishment of the link.

[0017] In some embodiments, in response to a first event, before sending an Internet Protocol (IP) packet to a CP, the AP sends a network warm-up command to the CP, including: in response to the first event, the AP predicts that a first application is about to execute a network task; the AP determines the warm-up object, namely the CP, based on the service type of the network task and the current communication status of the electronic device under various link types; and sends a network warm-up command to the CP.

[0018] In some embodiments, the CP sends IP packets through a communication link, including: if the communication link is not established when the IP packet arrives at the CP, the CP waits for the communication link to be established before immediately sending the IP packet through the communication link; and / or, if the communication link is established when the IP packet arrives at the CP, the CP immediately sends the IP packet through the communication link.

[0019] In some embodiments, the IP packet is the packet corresponding to a network task, and the task channel for that network task is opened periodically. For example, a ticket-grabbing task starting at 12:00 pm.

[0020] In some embodiments, where the first time information is the start time of network warm-up and the communication link is a cellular communication link, the method further includes: if the first network task needs to be initiated based on user operation, the AP or CP determines the first time information based on the start time of the network task, an estimated value of the duration of the user operation, an estimated value of the duration required to establish the communication link, and an estimated value of the duration required to keep the link resources alive. If the first network task is automatically initiated by an electronic device, the AP or CP determines the first time information based on the start time of the network task, an estimated value of the duration required for the AP to generate and send IP packets to the CP, an estimated value of the duration required to establish the communication link, and the duration of an inactive timer (such as UeInactiveTimer).

[0021] In some embodiments, where the first time information is the start time of network warm-up and the communication link is a Wi-Fi communication link, the method further includes: when the network task needs to be initiated based on user operation, the AP or CP determines the first time information based on the start time of the network task, an estimated value of the user operation duration, an estimated value of the duration required to request uplink resources, and an estimated value of the duration required to keep the link resources alive. In scenarios where the network task is automatically initiated by an electronic device, the AP or CP determines the first time information based on the start time of the network task, an estimated value of the duration required for the AP to generate and send IP packets to the CP, and an estimated value of the duration required to request uplink resources.

[0022] In some embodiments, when the communication link is a cellular communication link, the CP establishes a communication link with the radio access network device according to the network warm-up command, including: the CP establishing a radio resource control (RRC) connection and a radio bearer (RB) with the radio access network device according to the network warm-up command; the CP requesting uplink authorization from the radio access network device through a scheduling resource request (SR); and the CP requesting uplink resources from the radio access network device through a buffer status report (BSR), wherein the BSR includes the uplink data volume.

[0023] In some embodiments, the method further includes: the AP updating the uplink data volume; the AP sending the updated uplink data volume to the CP; and the CP re-requesting uplink resources from the radio access network device based on the updated uplink data volume.

[0024] Understandably, this method can calibrate the uplink data volume after successful network warm-up, so that wireless access network devices can allocate uplink resources to electronic devices more rationally, avoiding resource waste and network congestion.

[0025] In some embodiments, when the CP receives a network warm-up command, the CP starts an inactive timer T302. The CP establishes a communication link with the wireless access network device according to the network warm-up command, including: if the start time of network warm-up has been reached before T302 times out, then establishes a communication link with the wireless access network device.

[0026] In this embodiment, the electronic device can perform network warm-up without waiting for the T302 timer to expire, which can improve the speed of network warm-up and thus improve the data transmission rate.

[0027] In some embodiments, before the CP sends an IP packet through the communication link, the method further includes: if the IP packet has not reached the CP when the communication link has been established and is about to exceed a first duration, sending an unguaranteed delivery message to the radio access network device through the communication link, the unguaranteed delivery message including the target data.

[0028] The phrase "not guaranteeing the delivery of target data" can be understood as not guaranteeing that the delivered messages are valuable; that is, messages with other practical uses besides keep-alive. For example, messages with uncertain delivery could be DNS messages, IP keep-alive messages, or probe messages from an uncertain delivery queue, user-delegated messages, redundant or critical messages from a regular delivery queue, etc. This method can reduce the transmission of valueless data, reduce bandwidth waste, and minimize power consumption.

[0029] In some embodiments, it is not guaranteed that the sent message includes at least one of the following: DNS-related messages; IP keep-alive messages; IP messages related to probe tasks; IP messages related to delayed network tasks; messages related to the application's business network tasks; critical messages; and retransmission / redundancy messages.

[0030] In some embodiments, when the communication link is a cellular communication link, the first duration is equal to the current buffer state report (BSR) period, or the first duration is equal to the duration of the inactive timer issued by the radio access network device; in addition, when the communication link is a Wi-Fi communication link, the first duration is equal to the length of the channel occupancy period indicated in the CTS frame allowed to be transmitted issued by the radio access network device.

[0031] The method provided in this application embodiment allows an electronic device to send uplink data while the network side permits it to do so. However, during periods when the electronic device is temporarily unable to send data, the transmission of packets does not guarantee link keep-alive. This method can prevent the wireless access network device from being affected by the electronic device's subsequent data transmission due to the inability to receive uplink data.

[0032] In some embodiments, before sending keep-alive data packets to a wireless access network device via a communication link, the method further includes: in response to a target event, the AP establishing a non-guaranteed network task pool, the non-guaranteed network task pool including multiple network tasks, the AP not guaranteeing whether to process the network tasks, and not guaranteeing the processing result when processing the network tasks. The AP can generate non-guaranteed transmission messages based on the network tasks in the non-guaranteed network task pool.

[0033] In some embodiments, the target event includes: the AP determining that network warm-up is required; or, the AP predicting through an artificial intelligence model that link resource keep-alive is required.

[0034] In some embodiments, the acquisition method for unguaranteed delivery messages includes: the CP (Content Provider) acquiring a preset unguaranteed delivery message from the unguaranteed delivery queue on the CP side based on keep-alive parameters; or, the CP acquiring important messages or retransmission / redundant messages from the regular delivery queue on the CP side based on keep-alive parameters. The important messages or retransmission / redundant messages are the unguaranteed delivery messages. This method can quickly acquire unguaranteed delivery messages and is suitable for scenarios requiring rapid acquisition of such messages.

[0035] Alternatively, the CP sends a message retrieval request to the AP, which includes keep-alive parameters. The AP retrieves the target network task from the non-guaranteed network task pool based on the keep-alive parameters and generates a non-guaranteed delivery message based on the target network task. The AP then sends this non-guaranteed delivery message to the CP. This method involves generating non-guaranteed delivery messages in real time and is suitable for scenarios where rapid retrieval of non-guaranteed delivery messages is not required, such as RRC keep-alive scenarios.

[0036] In some embodiments, keepalive parameters include at least one of the following: the size of the data to be filled, the lifetime of the keepalive packet, the data type and priority of the keepalive packet, whether the keepalive packet needs to be retransmitted, and whether the downlink data corresponding to the keepalive packet is allowed to be discarded by the CP. It can be understood that, based on the keepalive parameters, the CP can obtain appropriate non-guaranteed delivery messages.

[0037] In some embodiments, the method further includes: in response to a second event, the AP sends a warm-up stop command to the CP; in response to the warm-up stop command, the CP disconnects the communication link. Exemplarily, the second event includes: the AP failing to generate an IP packet within a preset time; or, a user-triggered user action, application event, or device control event to stop network warm-up. In other words, if network warm-up fails, the AP of the electronic device notifies the CP to stop network warm-up.

[0038] In some embodiments, the method further includes: after establishing a communication link, if the CP does not receive an IP packet within a preset time, the CP disconnects the communication link. That is, if network warm-up fails, the CP actively stops network warm-up.

[0039] In a second aspect, embodiments of this application provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method shown in the first aspect above.

[0040] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method performed by the AP or CP as described in the first aspect above.

[0041] Fourthly, embodiments of this application provide a chip including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the method executed by AP or CP as described in the first aspect above.

[0042] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when run by an electronic device, causes the electronic device to implement the method executed by the AP or CP as described in the first aspect above.

[0043] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application;

[0045] Figure 2 This is a schematic diagram of the communication system provided in an embodiment of this application;

[0046] Figure 3A This is a schematic diagram of an electronic device transmitting uplink data via a cellular communication link, as provided in an embodiment of this application.

[0047] Figure 3B This is a schematic diagram of an electronic device transmitting uplink data via a Wi-Fi link, as provided in an embodiment of this application.

[0048] Figure 4 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application;

[0049] Figure 5 This is an overall schematic diagram of the communication link management method provided in the embodiments of this application;

[0050] Figure 6 This is a schematic diagram of the AI ​​model provided in this application performing network warm-up prediction;

[0051] Figure 7 This is a schematic diagram illustrating the user's usage time for different applications, provided in an embodiment of this application.

[0052] Figures 8-9 These are schematic diagrams of display interfaces including target text provided in different embodiments of this application;

[0053] Figure 10A This is a schematic flowchart of a communication link management method provided in an embodiment of this application;

[0054] Figure 10B This is a schematic diagram illustrating the time benefits of the network preheating method provided in the embodiments of this application;

[0055] Figure 11 This is a flowchart illustrating the establishment of a cellular link between an electronic device and a RAN device, as provided in an embodiment of this application.

[0056] Figure 12 This is a flowchart of a cellular network preheating method provided in another embodiment of this application;

[0057] Figure 13 This is a flowchart of determining the start time of network preheating provided in one embodiment of this application;

[0058] Figures 14-15 This is a schematic diagram illustrating the determination of the start time of network preheating in different embodiments of this application.

[0059] Figure 16 This is a schematic diagram illustrating the amount of uplink data updated by an electronic device according to an embodiment of this application;

[0060] Figures 17-18 These are flowcharts illustrating network warm-up processes under abnormal cellular network conditions provided in different embodiments of this application.

[0061] Figure 19 This is a flowchart illustrating how an electronic device establishes a Wi-Fi connection and transmits data, as provided in an embodiment of this application.

[0062] Figure 20 This is a flowchart of a Wi-Fi network preheating method provided in one embodiment of this application;

[0063] Figures 21-22 This is a schematic diagram illustrating the determination of the start time of network preheating in different embodiments of this application.

[0064] Figure 23This is a schematic diagram of the process for establishing a network task pool without guarantee, provided in an embodiment of this application;

[0065] Figure 24 This is a schematic diagram of the structure of the non-guaranteed network task pool provided in the embodiments of this application;

[0066] Figure 25 This is a schematic flowchart of a link resource keep-alive method provided in one embodiment of this application;

[0067] Figure 26 This is a schematic diagram illustrating different methods by which a CP obtains IP packets, as provided in one embodiment of this application;

[0068] Figure 27 This is a schematic diagram illustrating how an AP generates IP packets in real time based on a DNS request, according to an embodiment of this application.

[0069] Figure 28 This is a schematic diagram illustrating how an AP pre-generates IP packets based on a DNS request, according to an embodiment of this application.

[0070] Figure 29 This is a schematic diagram of the data format of a DNS request message provided in an embodiment of this application;

[0071] Figure 30A This is a schematic diagram of the data packet encapsulation process after the transmission message partially replaces the PADDING data, provided in an embodiment of this application.

[0072] Figure 30B This is a schematic diagram of the data packet encapsulation process provided in the embodiments of this application, which does not guarantee that the sent message will completely replace the PADDING data;

[0073] Figure 31 This is a schematic diagram of the retransmission strategy for IP packets provided in an embodiment of this application;

[0074] Figure 32 This is a schematic flowchart of a link resource keep-alive method provided in another embodiment of this application;

[0075] Figure 33 This is a schematic diagram of the chip structure provided in the embodiments of this application. Detailed Implementation

[0076] The technical solutions provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0077] It should be understood that in the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0078] In this embodiment, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0079] Figure 1 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. For example... Figure 1 As shown, the electronic device includes an access point (AP) and a network protocol stack (CP). The AP is configured with various applications and network protocol stacks. The CP can be a modem, a Wi-Fi chip, a Bluetooth chip, or a satellite chip, etc.

[0080] During operation, applications typically need to send relevant application data to the target device according to user needs. For example, shopping applications need to send shopping-related instructions to the server, and chat applications need to send chat information to the other device. Generally, electronic devices send application data through the following processes (1) to (3).

[0081] (1) The AP generates IP packets based on the application data.

[0082] Specifically, the application first sends the application data to be sent to the network protocol stack, which then generates an IP packet based on the application data and sends the IP packet to the CP.

[0083] (2) CP prepares the communication link.

[0084] In this embodiment, the process of the CP preparing the communication link can also be referred to as air interface warm-up, network warm-up, or network preheating. When the CP receives the first IP packet sent by the AP, its communication link with the RAN device is usually not ready. For example, it may be in the radio resource controller (RRC) IDLE state, have insufficient air interface authorized resources, be out of uplink synchronization, or have its inactive timer expire and the RRC released. Therefore, it cannot send IP packets temporarily. In this situation, the CP needs to establish an RRC connection with the RAN device, re-request authorized resources, or improve uplink synchronization capabilities so that the communication link can send IP packets normally. It should be noted that if the air interface can send IP packets normally when the CP receives the IP packet, then air interface warm-up is not required.

[0085] (3) CP sends IP packets through the communication link.

[0086] In the above process, receiving the IP packet is a necessary condition for the CP to perform air interface warm-up. That is, the CP can only perform air interface warm-up after receiving the IP packet. The contents (1) to (3) are executed serially, which means that after the first IP packet arrives at the CP, it needs to wait for a period of time before it can be sent out. As a result, in scenarios with strict latency requirements, this will lead to a poor user experience. For example, in scenarios such as ticket grabbing / red envelope grabbing / stock trading, it may cause users to fail to grab tickets / red envelopes / stock trading. For another example, in the process of opening the application homepage, it may cause the homepage to open slowly.

[0087] Therefore, this application provides a communication link management method. This method starts preparing the communication link between the electronic device and the RAN device before the first IP packet arrives at the CP, that is, to perform network warm-up in advance, so that the IP packet can be sent out quickly after it arrives at the CP, thereby improving the IP packet sending speed, reducing the sending latency, and improving the user experience.

[0088] First, the communication system to which the communication link management method provided in the embodiments of this application is applicable is introduced.

[0089] Figure 2 This is a schematic diagram of the communication system provided in an embodiment of this application. For example... Figure 2 As shown, the communication system includes electronic devices and RAN devices, and the electronic devices are wirelessly connected to the RAN devices.

[0090] Electronic devices support wireless data transmission. For example, electronic devices can be handheld devices, in-vehicle devices, wearable devices, or computing devices with wireless communication capabilities, such as mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), smart bracelets, smartwatches, smart glasses, and in-vehicle systems. Electronic devices can also be virtual reality (VR) electronic devices, augmented reality (AR) electronic devices, wireless electronic devices in industrial control, wireless electronic devices in autonomous driving, wireless electronic devices in telemedicine, wireless electronic devices in smart grids, wireless electronic devices in smart cities, and wireless electronic devices in smart homes.

[0091] RAN equipment is a device or node used to connect electronic devices to a wireless network. This wireless network can be a cellular network, a wireless local area network (WLAN) (e.g., a Wi-Fi network), a satellite network, or a Bluetooth network, etc. This application embodiment does not limit the type of wireless network.

[0092] For example, for cellular networks, the RAN device can be a base station in 5G or future communications, where a 5G base station can also be called a transmission reception point (TRP) or a next-generation node B (gNB). Alternatively, the RAN device can be an evolved node B (eNB), a radio network controller (RNC), a node B (NB), a base station controller (BSC), a base transceiver station (BTS), a home base station (e.g., a home evolved Node B, or a home Node B (HNB), a base band unit (BBU), etc. For WLAN, the RAN device can be a router, a wireless access point, a wireless repeater, a wireless extender, and a Wi-Fi access point device, etc. For satellite networks, the RAN device can be satellite equipment. For Bluetooth networks, the RAN device can be a Bluetooth gateway, a Bluetooth router, etc. The embodiments of this application do not limit the specific technology or specific device form used in the RAN device.

[0093] Based on the communication system provided in this embodiment, when an electronic device needs to send uplink data, it must first establish a communication link with the RAN device before it can send uplink data to the RAN device through that communication link. For example... Figure 3A As shown, the electronic device establishes a cellular communication link with the base station and sends uplink data to the base station through the cellular communication link. Or, for example... Figure 3B As shown, the electronic device establishes a Wi-Fi link with the Wi-Fi access point device and sends uplink data to the Wi-Fi access point device through the Wi-Fi link.

[0094] Next, the specific structure of the electronic device to which the communication link management method provided in the embodiments of this application is applicable will be described.

[0095] Figure 4 This is a schematic diagram of the structure of an electronic device provided in another embodiment of this application. For example... Figure 4 As shown, the electronic device includes an AP and a CP, as detailed below.

[0096] Application Processor (AP)

[0097] In this embodiment, the AP includes an application layer and a network subsystem, as detailed below.

[0098] Application layer This includes a range of applications, such as games, chat, messaging, calendar, camera, navigation, gallery, shopping, audio / video, browser, banking, ticketing, and payment applications.

[0099] Network Subsystem It includes the network interface layer, the transmission control protocol / internet protocol (TCP / IP) stack, the network preheating module, and the unguaranteed task module. Details are shown below.

[0100] (1) Network interface layer

[0101] The network interface layer includes one or more network interfaces, such as the Domain Name System (DNS) interface, the Socket interface, the Hypertext Transfer Protocol (HTTP) interface, and the WebSocket interface. Electronic devices can perform specific functions by calling these interfaces; for example, an electronic device can translate a domain name into an IP address by calling the DNS interface.

[0102] In this embodiment, the network interface layer can process network interface calls and network prediction in parallel. In other words, while calling network interfaces (such as DNS interfaces) according to the application's needs, the network interface layer can send interface call notifications to the network warm-up module. These interface call notifications include the type of the network interface being called and the time of the call.

[0103] (2) TCP / IP protocol stack

[0104] The TCP / IP protocol stack is typically a four- or five-layered structure. Each layer can use different protocols to implement specific functions and interact with adjacent layers through standard interfaces. The TCP / IP protocol provides standard data transmission paths and communication rules for electronic devices, ensuring correct data transmission and normal network operation. In this embodiment, the TCP / IP protocol stack can encapsulate the data to be sent by the application into several IP packets.

[0105] (3) Network warm-up module

[0106] The network warm-up module includes an information identification unit, an event and context monitoring unit, a network interface monitoring unit, a prediction unit, and a warm-up management unit. The specific functions of each unit are shown below.

[0107] Information recognition unit This is used to identify target text and target controls in the application interface. The target text indicates that a channel for a certain network task is about to open. The target control is used to control the execution of operations related to this event, such as a purchase control or a redemption control.

[0108] In some embodiments, the information recognition unit can acquire a screenshot data stream of the entire screen or a portion of the screen, and use optical character recognition (OCR) technology to recognize the screenshot data stream to obtain the text information in the display interface. Alternatively, the electronic device can directly read the text in each control of the display interface. Subsequently, the target text in the application interface is recognized through template matching, regular expression matching, keyword filtering, and other methods.

[0109] In other embodiments, the information recognition unit can obtain the schedule information (such as flash sale information) when the user manually adds it, or obtain the schedule information recorded by the user through the calendar's query interface, and recognize the target text in the schedule information. Additionally, with user authorization, the calendar can also automatically add flash sale information to the schedule.

[0110] In other embodiments, users can also add schedule information such as flash sales and transactions to the electronic alarm clock, and the information recognition unit can obtain the schedule information through the query interface of the electronic alarm clock.

[0111] Event and Context Monitoring Unit This system is used to monitor user events, network events, and network context information. For example, user events include the type and timing of the event. User event types include touch events, swipe events, and in-application control operations (such as single click, double click, long press, pressure press down events, and release up events), application cold start, warm start, application update, opening the camera, and launching the QR code scanner. Network events include network card recognition and activation (i.e., network card up), data service activation, successful Wi-Fi hotspot connection, and changes to default routing information. Network context monitoring includes network self-healing, network switching, airplane mode on / off, and other network change information.

[0112] Network Interface Monitoring Unit This system monitors the network interface layer and the application's ecosystem warm-up interface calls. These calls can include the type of interface called and the time of the call. The application's ecosystem warm-up interface can be understood as the application's information notification interface. After an event triggers network warm-up in the application (such as detecting user input or the system obtaining the accurate time of ticket opening from the server), the application notifies the network interface detection unit of this event before or during network operations, enabling the electronic device to quickly perform network warm-up.

[0113] Prediction Unit It is used to predict the start time of network preheating and the amount of uplink data based on collected application behavior, user behavior, and network behavior, and then send the predictions to the preheating management unit. It should be noted that if the network preheating module has already detected a user action that triggers network preheating, the prediction unit can temporarily refrain from making network preheating-related predictions to reduce device power consumption.

[0114] Preheating Management Unit This is used to manage matters related to network preheating, such as starting, canceling, pausing, and ending network preheating. For example, the network preheating unit can send a network preheating command to the CP, which includes first-time information and uplink data volume related to network preheating. The first-time information could be the estimated time when the first IP packet arrives at the CP; or the estimated time when the CP will begin network preheating.

[0115] Network notification and surrounding area forecast detection unitThis is used to detect network notifications and surrounding area announcements. Specifically, network-side devices typically deploy scheduled network tasks. Scheduled network tasks refer to network tasks that process channels that open at regular intervals, such as ticket purchase services opening at 9:00 AM and points redemption services opening at 12:00 PM. To allow users to be aware of these scheduled network tasks in advance, network-side devices support sending advance notices of scheduled network tasks to electronic devices / users via network notifications. Electronic devices / users can subscribe to network notifications, and the network-side devices push network notifications through the PUSH channel. Alternatively, the network-side devices can push scheduled network tasks that users are interested in based on their usual content usage habits and levels of interest. Alternatively, electronic devices can proactively initiate socket connections to access the network-side devices and actively query and obtain various scheduled network tasks.

[0116] In this embodiment, the network notification includes at least the time information of the timed network task, such as start time / remaining time / time interval range, etc. Optionally, the network notification may also include at least one of the following: task name, task description, category, application name / application package name, or identifier (ID).

[0117] Surrounding notification refers to the notification information about a scheduled network task sent by surrounding electronic devices. This notification information can be generated by surrounding electronic devices or forwarded by them; this application does not restrict the source of the notification information.

[0118] (4) Task modules are not guaranteed.

[0119] In this embodiment, the task module does not guarantee the inclusion of an ecosystem preheating interface, a network task pool, and a link resource management unit. Details are as follows.

[0120] Ecological preheating interface The ecosystem preheating interface can be understood as an information notification interface for applications. For a certain network task, when the application determines that it will inevitably or is highly likely to send data at a certain future time, it notifies the network subsystem of the task's start time, task type, etc., through this ecosystem preheating interface. The network preheating module can obtain this information through the network interface monitoring unit so as to trigger network preheating before the network task starts.

[0121] In some embodiments, the ecosystem warm-up interface is an interface for configuring prefetch information, such as a network warm-up interface, an interface for prefetching DNS information, a pre-built link interface, and a prefetch resource interface. The prefetched DNS information can be interpreted as DNS information acquired and stored in advance during pre-data transmission or processing for later use.

[0122] Network task pool is not guaranteedThis includes various network tasks for which execution is not guaranteed, nor is the outcome guaranteed. It is not guaranteed that the network task pool will select a target network task based on the instructions of the link resource management unit, or generate IP packets in advance or in real-time based on the target network task. Furthermore, it is not guaranteed that the network task pool will configure a lifetime for each network task. Therefore, it is not guaranteed that the network task pool will manage tasks based on their lifetimes, deleting expired tasks.

[0123] Link Resource Management Unit It is responsible for interfacing with the link resource keep-alive module on the CP side, receiving keep-alive task requests from the link resource keep-alive module, triggering the non-guaranteed network task pool to select a task to generate IP packets and send them to the chip's non-guaranteed sending queue, etc.

[0124] [Communication Processor CP]

[0125] A CP (Content Processor) includes at least one of the following devices: a baseband processor (BP) (e.g., a modem), a Wi-Fi chip, a Bluetooth chip, or a strobe chip. The CP is used to establish a communication link with the RAN (Radio Access Controller) equipment and to send and receive IP packets through this link. Taking the CP as the baseband processor and the RAN equipment as the base station as an example, the baseband processor establishes an RRC (Radio Relay Connection) connection with the base station, establishes a radio bearer (RB) with the base station, requests scheduling resources from the base station, and finally sends IP packets to the base station.

[0126] In this embodiment, the CP includes a pre-radio execution module, a link resource keep-alive module, a non-guaranteed transmission queue, and a regular transmission queue. Details are shown below.

[0127] (1) Preheating Execution Module

[0128] The preheating execution module is used to perform network preheating and establish a communication link based on the first-time information and uplink data volume carried in the network preheating command after receiving it. See below for details; further elaboration is not provided here.

[0129] (2) Sending queue is not guaranteed

[0130] In this embodiment, it is not guaranteed that the sending queue includes IP packets such as DNS packets, IP keep-alive packets, probe packets, user delegation packets, critical packets, and retransmission / redundancy packets. The CP does not guarantee that it will send any IP packets in the queue, nor does it guarantee that downlink data will be obtained after sending such an IP packet. These IP packets can be generated in real-time when link resource keep-alive is required, or they can be generated in advance; this embodiment does not impose any restrictions on this. Furthermore, these IP packets typically carry a lifetime; if an IP packet exceeds its lifetime and has not been sent, it is automatically deleted. The lifetime time unit can be accurate to milliseconds (ms) or seconds (s), etc.

[0131] (3) Regular Sending Queue

[0132] In this embodiment, the regular sending queue refers to the queue of messages that typically need to be sent. The regular sending queue may include multiple queues with different priorities, such as a high-priority queue and a normal-priority queue. The high-priority queue includes critical messages, while the normal-priority queue includes critical messages and retransmission / redundant messages.

[0133] (4) Link resource keep-alive module

[0134] In this embodiment, the link resource keep-alive module is used to perform link resource keep-alive. For cellular communication links, link resource keep-alive mainly includes RRC keep-alive and grant keep-alive. RRC keep-alive includes establishing an RRC connection and establishing a radio bearer (RB). Grant keep-alive includes requesting uplink grants through a scheduling request (SR) and requesting uplink resources through a buffer status report (BSR). For Wi-Fi communication links, link resource keep-alive mainly involves keeping uplink resources that have been contested and retained.

[0135] When performing an authorized keep-alive task, the communication module needs to acquire unguaranteed delivery messages as keep-alive data packets and send them to the access network device for authorized keep-alive. For example, the link resource keep-alive module can communicate with the unguaranteed task module to request the unguaranteed task module to generate and return unguaranteed delivery IP packets in real time; or, it can obtain pre-generated IP packets from the unguaranteed delivery queue; or, it can obtain critical packets and retransmission / redundancy packets from the regular delivery queue; or, it can generate IP packets itself through the IP protocol stack.

[0136] Based on the communication system and electronic equipment provided in the above embodiments, the communication link management method provided in the embodiments of this application will be specifically described below.

[0137] Figure 5 This is an overall schematic diagram of the communication link management method provided in this application embodiment. The method is applied to electronic devices including an Access Point (AP) and a Communication Partner (CP), where the CP of the electronic device has not yet established a communication link. Figure 5 As shown, the electronic device first predicts network warm-up through the AP, that is, it determines whether the CP needs to establish a communication link in advance. If the AP predicts that network warm-up is needed, the AP and CP execute their respective processes in parallel. The AP's process includes: generating IP packets after the network task begins, and transferring the IP packets from the AP to the CP. The CP's process includes: performing network warm-up according to the AP's network warm-up command, and keeping the link resources alive if warm-up is complete but the IP packets have not arrived. Finally, the CP sends the IP packets when the IP packets arrive and network warm-up is complete. If the IP packets arrive after network warm-up is complete, there is no need to keep the link resources alive; the IP packets can be sent directly.

[0138] It should be noted that if the network task predicted by the AP fails to materialize, the AP does not actually need to send data. In this case, the CP also needs to stop network warm-up to avoid wasting resources.

[0139] Based on the above description, the communication link management method provided in this application mainly involves the following four parts: the first part is network warm-up prediction, the second part is network warm-up, the third part is link resource keep-alive, and the fourth part is network warm-up termination. Each part will be described in detail below.

[0140] Part 1: Predicting Online Preheating

[0141] In this embodiment, network warm-up refers to the CP establishing a communication link in advance before IP packets arrive at the CP from the AP, so that the CP can quickly send IP packets using the pre-established communication link after the IP packets arrive at the CP. Network warm-up prediction refers to determining whether the CP needs to start establishing a communication link in advance. This prediction task is usually performed by the AP.

[0142] Optionally, before performing network warm-up prediction, the electronic device can first determine whether its communication link is ready for data transmission. If the electronic device's communication link is ready for data transmission, no further prediction is needed; after the IP packet reaches the CP, the CP can directly use the communication link to send the IP packet. If the electronic device's communication link is not ready for data transmission, then network warm-up prediction is performed. Situations where the electronic device's communication link is not ready for data transmission include: the electronic device being in RRC IDLE state, insufficient uplink authorization resources, uplink synchronization failure, the UE releasing RRC after the inactivity timer expires, or data services not being activated.

[0143] In this embodiment, the electronic device can determine that network warm-up is required after detecting a first event. For example, the first event includes at least one of the following (1-1) to (1-7).

[0144] (1-1) Application calls network interface

[0145] When an application calls a network interface, it means that the application needs to send or receive data, and there is usually a subsequent need to use a wireless network to transmit IP packets. Therefore, this embodiment can determine whether the application needs to send data by monitoring the network interface.

[0146] The network interface in this embodiment can directly or indirectly trigger the generation and transmission of IP packets. For example, the network interface may include at least one of the following interfaces:

[0147] Domain Name System (DNS) request interfaces, such as Bionic's standard C interfaces getaddrinfo / gethostbyname, and Android's Java interface InetAddress.getAllByName. Bionic is a POSIX-compliant C library provided by the Android platform for C / C++ developers to develop native applications.

[0148] Hypertext Transfer Protocol (HTTP) interfaces, such as createHttp / request and other application programming interfaces (APIs).

[0149] The WebSocket interface can be an API, such as createWebSocket / connect / send, etc.

[0150] Socket interfaces, such as socket creation interface, socket connection interface (socket connect), and socket data sending interface (socket send / sendto / write), etc.

[0151] It should be noted that among the network interfaces mentioned above, the socket creation interface, createHttp interface, and createWebSocket interface are all network interfaces that indirectly trigger network warm-up.

[0152] (1-2) The AP receives a network task notification from the application's ecological warm-up interface.

[0153] To facilitate information exchange between applications and the operating system, ecological interfaces can be set up for applications, such as network warm-up interfaces, interfaces for pre-fetching DNS information, pre-built connection interfaces, and pre-fetched resource interfaces.

[0154] Taking the network preheating interface as an example, after detecting an upcoming network task, or a network task that is highly likely to begin in the future, the application sends a notification of the network task (i.e., a network task notification) to the AP's network preheating module through the network preheating interface. This network task notification includes the start time of the network task, the type of the network task, or other relevant descriptive information. For example, the type of network task could be a data transmission task, an application service task, or a network monitoring task. The network preheating module performs network preheating based on the network task notification.

[0155] (1-3) The AI ​​model predicted that network warm-up was needed.

[0156] In this embodiment, see Figure 6 As shown, electronic devices can use artificial intelligence (AI) models, either locally or in the cloud (i.e., on a cloud server), to learn the relationships between user behavior, application behavior, and network behavior. Based on current user and application behavior, they can predict network behavior and determine whether network warm-up is necessary. If network warm-up is required, the AI ​​model can send a pre-set notification to the AP's network warm-up module at a pre-set time (e.g., 5 seconds) to instruct it to perform network warm-up.

[0157] For example, the AI ​​model can be a neural network model, a time series AI model, such as a long short-term memory network (LSTM), a TimesNet model, a TSMixer model, etc.

[0158] The following section provides a detailed explanation of user behavior, application behavior, and network behavior involved in AI model learning and inference.

[0159] User behavior mainly involves a sequence of user actions. This sequence includes a series of information related to the user's actions, such as the name of the application the user is using, the time of use (e.g., start time, end time, and duration), the location of use, the network environment (e.g., Wi-Fi and data services), and the type of user command (e.g., swipe, tap, and long press).

[0160] It's important to note that location and network environment can influence the choice of server and network warm-up strategy. Specifically, network environments can vary across locations; for example, Wi-Fi signal strength is generally stronger at home than cellular, 5G cellular signal strength is stronger in some areas than 4G, and vice versa. AI models can learn the relationships between different locations and network environments in advance and select appropriate warm-up targets based on the location of electronic devices. For instance, when an electronic device is at home, considerations regarding data charges and battery life can be less important, allowing for a greater focus on warming up the Wi-Fi network and potentially earlier warm-up times.

[0161] Application behavior refers to the business functions performed by an application in response to user control operations. Examples include opening the application's homepage, loading homepage content, sending pictures in a chat interface, making audio or video calls, making payments through a payment application, displaying weather forecasts through a weather application, playing short videos, displaying text and image news, playing live streams, and running the scan function.

[0162] Network behavior refers to the interaction between an application and network-side devices when implementing business functions. For example, this network behavior includes warm-up factors such as initiating DNS requests, establishing TCP connections, and initiating request commands (e.g., HTTP / HTTPS / WEBSOCKET / QUIC). Relevant information about network behavior includes the set / time of DNS requests, the number and target ports of TCP connections established, whether the local port is specified, and encryption methods.

[0163] In some embodiments, taking a user's workday as an example, for instance... Figure 7 As shown, user behavior and application behavior are as follows:

[0164] Between 6:30 and 7:30, while using the home Wi-Fi network, I controlled my phone screen to turn on, and then opened a news app to read the news and a weather app to check the weather forecast.

[0165] Between 8:00 and 8:30, while commuting to work (such as on a bus or subway), use cellular data to play short videos.

[0166] Between 8:40 and 9:00, I checked my Moments on the chat app while using the company's Wi-Fi network.

[0167] From 9:50 to 10:30, use office applications on the company's Wi-Fi network.

[0168] Around 11:00, I used a chat application to send and receive chat messages on the company's Wi-Fi network.

[0169] Around 11:50, I used a payment app to pay for my meal using the company cafeteria's cellular network.

[0170] From 12:00 to 1:30, use a short video app to play short videos on the company's Wi-Fi network.

[0171] Around 15:50, I used a payment app to pay for my meal using the company cafeteria's cellular network.

[0172] From 16:00 to 16:20, use a short video app to play short videos on the company's Wi-Fi network.

[0173] Around 5:10 PM, I used a chat application to send and receive chat messages on the company's Wi-Fi network.

[0174] Between 18:00 and 18:30, while commuting to work (such as on a bus or subway), use cellular data to play short videos.

[0175] Around 19:10, I used a chat application to send and receive chat messages on my home Wi-Fi network.

[0176] From 8:00 PM to 10:00 PM, use a short video app to play short videos on your home Wi-Fi network.

[0177] From 22:00 to 22:20, I opened a news app to read the news while using my home Wi-Fi network.

[0178] At 23:00, control the phone to turn off the screen / power off.

[0179] Electronic devices can generate user profiles based on user behavior and application behavior, and combine these user profiles to predict network preheating. For example, they can generate profiles based on time dimensions, such as profiles for weekdays, weekends, during-work hours, after-work hours, and Monday workdays.

[0180] (1-4) User actions, application events, or network events used to trigger network warm-up

[0181] In this embodiment, the user operation can trigger the electronic device to send data using the network. For example, the first user operation could be an operation on a message sending control, an operation on an application download control, an operation on an application update control, a user clicking to scan and opening the camera, or a user opening the gallery interface from a chat application and selecting to send an image / video / file, etc. This embodiment does not impose specific limitations on these operations. The user's operation on the message sending control includes clicking, swiping, etc.

[0182] In some embodiments, for a control on the interface, such as a ticket-grabbing control, the electronic device typically determines that the user has clicked the control after detecting that the user has pressed and released the control (i.e., detecting an up event), and then initiates a network task such as ticket grabbing. To further improve the speed of initiating network tasks, the electronic device confirms that the user has clicked the control as soon as it detects that the user has pressed the control (i.e., detecting a down event), without needing to detect that the user's hand has released the control (i.e., without detecting an up event).

[0183] In other embodiments, the electronic device can also trigger network warm-up when it detects that a user has pressed a relevant control (i.e., a down event is detected). Subsequently, when it detects that the user's hand has left the control (i.e., an up event is detected), it triggers a network task command (e.g., a ticket-grabbing command). In this way, the electronic device can prioritize network warm-up in order to quickly send the IP packets corresponding to the network task later.

[0184] In this embodiment, application events can include application download, application update, application installation, application cold start, application warm start, application launching the scan function, or completion of the scan task. It should be noted that after application download, update, or installation, the user typically opens and uses the application. Since applications usually require network access during use, network preheating can be performed in advance after the electronic device detects the application download / update / installation task, during the application download / update / installation process, or after the application download / update / installation is completed, but before the user opens the application, establishing a communication link for sending uplink data. Furthermore, an application cold start refers to the application starting from its initial state, loading all necessary resources, configurations, and data. An application warm start refers to the process of restarting or refreshing an application that is already running. During a warm start, the application may attempt to restore part of its previous state rather than completely reloading. Therefore, cold starts typically require longer startup times than warm starts. Both application cold starts and warm starts may require network access; therefore, this application uses application cold starts and warm starts as trigger conditions to perform network preheating in advance.

[0185] In some operating systems, applications must request network access permissions before they can access the network. For example, in HarmonyOS, applications need to request ohos.permission.INTERNET permission before accessing the network. Therefore, the access point (AP) can read the application's permission configuration file or confirm its network access permissions in advance based on information such as the application name / package name. If an application does not have network access permissions, there is no need to perform network preheating for that application.

[0186] In this embodiment, network events include network switching, network self-healing, and network context recovery. Details are as follows.

[0187] Network switching can be a process such as switching from Wi-Fi to cellular, switching from the primary SIM card to the secondary SIM card in an electronic device, switching from Wi-Fi 2.4G to Wi-Fi 5G, Wi-Fi roaming, or switching from one Wi-Fi hotspot to another. Network switching can immediately trigger network warm-up.

[0188] In some embodiments, electronic devices can predict network warm-up based on the triggering reason for the current network switch, which can further improve the accuracy of the prediction. For example, if a user is watching a video and the system initiates a network switch from a cellular network to a Wi-Fi network due to reasons such as buffering, transport layer anomalies, or air interface anomalies, the network warm-up can be initiated simultaneously with the CP sending a notification to the application after the network switch is completed.

[0189] Network self-healing refers to the restoration of normal network functionality after an anomaly occurs. It primarily involves system-initiated signaling or media plane (e.g., network transport layer, chip air interface layer) self-healing retries. For example, when network congestion is severe, it may trigger network and cell selection again, and data service activation and IP acquisition may be re-initiated. It's important to note that network self-healing will cause all previous connections to be disconnected. Therefore, if network activities prior to self-healing are not completed after self-healing, network warm-up will be triggered.

[0190] Network context recovery refers to the process by which electronic devices restore network connectivity after changes in the network channel, IP address, or IP address interruption, using the link information from before the network change as input. It should be noted that during network context recovery, changes in the physical channel may necessitate re-updating the remote server IP address via DNS requests.

[0191] (1-5) The target text information is identified in the display interface / calendar information / electronic alarm clock.

[0192] In this embodiment, the target text information is used to indicate that a certain node is about to begin, for example... Figure 8 The text in (a) indicates "September 26th, 10:08 AM start time for the flash sale". Figure 8 The following are examples of redemption options, as shown in (b): "Redemption starts at 0 days, 0 minutes, and 33 seconds," "Friday," "Purchase starts at XX:XX," "Bonuses are replenished on the Xth, XXth, and XXth of each month at XX:00," "XX minutes and XX seconds until the next sales start time," "Coming Soon: XX Month XX Day XX:XX," and "Purchase starts at XX:00 daily." Additionally, [the following are examples of redemption options]... Figure 9For example, in the schedule information shown, “Purchase concert tickets at 12:00 noon on December 26, 2024”, “Purchase at 12:00 noon on December 26, 2024” is the target text.

[0193] (1-6) Receive notification information from the server or surrounding electronic devices regarding scheduled network tasks.

[0194] Servers typically deploy various scheduled network tasks, such as flash sales and live streaming tasks. If an electronic device subscribes to these scheduled network tasks, the server will push notifications of these tasks to the device via a PUSH channel. Alternatively, the server can match user preferences for different types of content and their browsing habits to push network notifications for network tasks that the user is interested in. Furthermore, electronic devices can proactively initiate connections via sockets, websockets, or HTTP to access the server and actively query and retrieve network notifications for various scheduled network tasks.

[0195] In this embodiment, the electronic device can perform network warm-up based on notification information about scheduled network tasks from the server or surrounding electronic devices. For example, the network notification typically includes the task name, task description, task category, task-related time information (e.g., task start time / remaining time / time range), application name / application package name, etc.

[0196] (1-7) Operating system performs pre-establishment of links

[0197] For example, the operating system can pre-establish communication links (referred to as pre-established links) through different methods such as PreDNS / PreConnect / PreTLS / PreDTLS / Prefetch. PreDNS is DNS prefetching; PreConnect is pre-connection, such as pre-establishing a TCP connection; PreTLS / PreDTLS is pre-encryption negotiation; and Prefetch is resource prefetching. When the operating system performs pre-established link behavior, electronic devices can also simultaneously initiate network warm-up to pre-establish communication links. That is, electronic devices can perform pre-established links simultaneously in two paths to improve the speed of pre-established links.

[0198] In summary, the network warm-up prediction method provided in this embodiment has more accurate prediction results, can improve the prediction hit rate, and prevent subsequent invalid network warm-up.

[0199] Part Two: Online Warm-up

[0200] Figure 10A This is a schematic flowchart illustrating the communication link management method provided in an embodiment of this application. See also... Figure 10AAs shown, this method is applied to electronic devices including an access point (AP) and a communication partner (CP), where the electronic devices have not yet established a communication link. Specifically, it includes the following:

[0201] S1001, in response to the first event, the AP sends a network warm-up command to the CP before sending an IP packet to the CP, wherein the IP packet is the first packet that the AP predicts needs to send.

[0202] In this embodiment, the network warm-up command is used to instruct the CP to perform network warm-up. After detecting the first event, the AP believes that the application has a need to send network data. Therefore, the AP can instruct the electronic device to establish a communication link based on factors such as the application's services and the current network environment, or it can instruct it to establish multiple communication links in parallel for later use.

[0203] Optionally, the network warm-up command includes at least one of the following: first time information, uplink data volume, and link type. The first time information is the estimated time when the first IP packet arrives at the CP, or the estimated time when the CP begins network warm-up. The uplink data volume can be the estimated data volume of the first IP packet to be sent, or the estimated data volume to be sent within one BSR cycle. The link type can be Wi-Fi 2.4G, Wi-Fi 5G, primary cellular SIM, secondary cellular SIM, 4G cellular, or 5G cellular, etc.

[0204] S1002, the CP establishes a communication link with the RAN equipment according to the network warm-up command.

[0205] Taking a modem as an example, and the network preheating command indicating the link type to be established as a 5G link, the modem establishes a 5G communication link with the base station after receiving the network preheating command. Taking a Wi-Fi chip as an example, and the network preheating command indicating the link type to be established as a Wi-Fi 2.4G link, the modem establishes a Wi-Fi 2.4G communication link with the router after receiving the network preheating command.

[0206] It should be noted that after the AP establishes a communication link in advance, the network transmission events predicted by the AP will usually occur, but there is also a possibility that they will not. For example, although the electronic device currently displays a ticket-grabbing interface, the user may not actually grab a ticket, and therefore no data transmission is required. Therefore, in the subsequent process, the AP may execute S1003-S1004, sending IP packets to the RAN device via the CP. Of course, the AP may also not execute S1003-S1004. Additionally, the AP usually cancels network warm-up and disconnects the established communication link.

[0207] S1003: After sending the network warm-up command to the CP, the AP sends the first IP packet to the CP.

[0208] S1004, the CP sends the first IP packet to the RAN device through this communication link.

[0209] In some embodiments, if the uplink data volume in the network warm-up command is the same as the data volume of the first IP packet, then the CP sends the first IP packet immediately after receiving the first IP packet.

[0210] In another embodiment, if the uplink data volume in the network warm-up command is the expected data volume to be sent within a BSR cycle, then the CP can select one or more IP packets of the corresponding data size to send, starting from the head of the buffer queue, based on the uplink grant volume within the current BSR cycle. It should be noted that this one or more IP packets necessarily includes the first IP packet.

[0211] In this embodiment, the AP can instruct the CP to perform network warm-up at multiple time points before the first IP packet arrives at the CP, thereby improving the IP packet transmission rate. Compared to starting network warm-up after the IP packet arrives at the CP, warm-up commands at different times can bring different time benefits T. This time benefit T can be understood as preparing the communication link T time in advance.

[0212] For example Figure 10B As shown, when the model predicts a network task, the AP can send a network warm-up command to the CP, thereby obtaining T. A The time benefit. Since models typically predict network warm-up a considerable time in advance (e.g., 10 seconds), the entire network warm-up process usually completes before the first IP packet arrives. Therefore, T A This refers to the duration of the entire network warm-up process. Alternatively, the AP can send a network warm-up command to the CP when it detects an application calling the network interface, thereby obtaining T. B +T C The time gain. Alternatively, the AP can send a network warm-up command to the CP when the protocol stack just begins generating IP packets, thereby gaining T C The time benefit. Among them, T B T is the time from when the application starts calling the network interface to when the application data packet reaches the protocol stack. C The time required to generate IP packets for the protocol stack.

[0213] In this embodiment, the generation of IP packets and the packet migration process from AP to CP are performed in parallel with the network warm-up process. Specifically, before the first IP packet reaches the CP from the AP, the CP pre-establishes a communication link so that after the first IP packet arrives at the CP, the CP can quickly send the IP packet through the communication link, shortening or avoiding the waiting time of the IP packet transmission on the CP side, thereby improving the transmission speed of the first IP packet and reducing its transmission latency. It can be understood that in scenarios such as flash sales, ticket grabbing, red envelope grabbing, stock trading, and opening application homepages, electronic devices based on this method can quickly communicate with application servers, increasing the probability of successful flash sales / ticket grabbing / red envelope grabbing and successful stock trading, improving the speed of application homepage opening, and providing a better user experience.

[0214] In this embodiment, the network preheating process described above is applicable to cellular communication, as well as Wi-Fi networks, Bluetooth, satellite networks, or other wireless communication networks. The network preheating method provided in this application embodiment will be specifically described below with reference to cellular networks and Wi-Fi networks.

[0215] Scenario 1: Cellular preheating scenario

[0216] First, combined Figure 11 The diagram illustrates the process by which electronic devices establish cellular links with RAN devices such as eNodeB / gNodeB via a CP. This process specifically includes the following steps: S1101–S1104.

[0217] S1101, Electronic equipment establishes RRC connection with RAN equipment.

[0218] For example, if the electronic device's RRC connection has been released, the electronic device sends an RRC connection request message (RRCConnectionRequest) to the RAN device through a random access procedure. This message includes basic user information and required radio resources. Subsequently, the RAN device sends an RRC connection configuration message (RRCConnectionSetup) to the electronic device, which includes information on how the RAN device allocates radio resources to the electronic device based on network conditions and user needs. Finally, the electronic device sends an RRC connection configuration complete message (RRCConnectionSetupComplete) to the RAN device.

[0219] S1102, Electronic equipment establishes a radio bearer (RB) with RAN equipment.

[0220] The establishment of the Radio Bearer (RB) prepares for data transmission. For example, if the RB of an electronic device has been released, the electronic device sends a Service Request to the RAN device via an RRC Connection Request message in S1101. This Service Request requests the establishment of the RB. The RAN device then forwards the Service Request to the Mobility Management Entity (MME) or Gateway (GW) of the core network (CN). Subsequently, the electronic device performs authentication and security management with the CN. Finally, Radio Bearer Establishment is completed.

[0221] S1103, the electronic device requests uplink authorization from the RAN device via the SR.

[0222] For example, the electronic device sends a Scheduling Request (SR) to the RAN device on the Physical Uplink Control Channel (PUCCH) or the Physical RAN Device Dominant Access Channel (PRACH) to request an uplink grant (UL Grant). It should be noted that the main purpose of the SR is to inform the network side (such as the eNodeB or gNodeB) that the UE needs uplink resources. Upon receiving the SR, the RAN device responds to the SR and sends the UL Grant to the electronic device via downlink control information (DCI). After receiving the UL Grant, the electronic device can then send data to the RAN device at the specified time and on the specified resources according to the UL Grant.

[0223] S1104 After obtaining uplink authorization, the electronic device requests uplink resources from the RAN device through the BSR.

[0224] In this embodiment, after the electronic device obtains uplink authorization, the CP sends a buffer state report (BSR) to the RAN device on the resources allocated by the RAN device to inform the RAN device of the amount of data waiting to be transmitted in the electronic device's buffer. This amount of data is the sum of the amount of data to be transmitted within one BSR cycle carried in one or more network warm-up commands.

[0225] After receiving the BSR, the RAN device assesses how many resources need to be allocated to the electronic devices based on the amount of data in the BSR, and sends the ULGrant to the electronic devices through the DCI of the physical downlink control channel (PDCCH).

[0226] After understanding the basic process of establishing a cellular link with electronic devices, the network warm-up process in a cellular scenario is described below.

[0227] Figure 12 This is a flowchart of a cellular network preheating method provided in another embodiment of this application. See also... Figure 12 As shown, this method is applied to electronic devices including an AP and a CP, where the CP has not yet established a communication connection. The method specifically includes the following steps S1201 to S1207.

[0228] S1201, AP detected the first event.

[0229] In this embodiment, the specific details of the first event are described in Part 1: Prediction of Network Warm-up, and will not be repeated here.

[0230] S1202, the AP determines whether the communication link is not ready for data transmission.

[0231] In this embodiment, the electronic device is not ready for data transmission, including situations such as the electronic device being in RRC IDLE state, insufficient authorized resources, uplink synchronization failure, UE inactivity timer expiration releasing RRC, or data service not being activated. If the electronic device is not ready for data transmission, the next step S1203 is executed. If the communication link of the electronic device is ready for data transmission, no further network warm-up is required; after the IP packet reaches the CP, the communication link can be used directly to send the IP packet.

[0232] S1203, if the CP's communication link is not ready for data transmission, the AP generates a network warm-up command.

[0233] In this embodiment, the network warm-up command includes first-time information, uplink data volume, and link type. These information will be described below.

[0234] (3-1) First-time information

[0235] Based on the first-hand information, the CP can complete network warm-up precisely when the first IP packet arrives, thereby increasing the IP packet transmission rate and avoiding link keep-alive processes, thus reducing resource waste caused by link keep-alive. Taking the complete warm-up of electronic devices as an example, completing network warm-up includes establishing RRC connections, establishing radio bearers, and requesting uplink resources from the RAN equipment in advance via SR / BSR.

[0236] In some embodiments, see Figure 13 As shown, the first piece of information is the start time of network warm-up. For example, after detecting the first event, the AP first sends a query to the CP to inquire about the CP's warm-up duration. This warm-up duration can be determined by the CP based on factors such as the current network status of the electronic device, chip performance, and historical warm-up durations. Subsequently, the start time of network warm-up is determined based on the start time of the scheduled network task and the warm-up duration.

[0237] In some other embodiments, the first time information is the time when the first IP packet arrives at the CP (denoted as T4), which is usually an estimate that can be determined by the AP.

[0238] For example, for a network task triggered by user operation, suppose T3 is the start time of the timed network task, such as the time when the ticket-grabbing channel opens, or the time when a user can initiate a ticket-grabbing activity; Δt1 is the sum of the user operation duration, the time required for the AP to generate IP packets, and the time required for the IP packets to travel from the AP to the CP after the timed network task starts (i.e., after T3); then, T4 = T 3+ Δt1.

[0239] For example, for a network task automatically triggered by an AP at regular intervals, assuming T3 is the start time of the scheduled network task; Δt2 is the sum of the time required for the AP to generate IP packets and the time required for the IP packets to travel from the AP to the CP after the scheduled network task starts (i.e., after T3); then, T4 = T 3+ Δt2.

[0240] In other embodiments, the first time information is the start time of the application's scheduled network task, which the AP can obtain by recognizing interface information or by obtaining notification information from the application, server, or surrounding electronic devices.

[0241] (3-2) Uplink data volume

[0242] In this embodiment, the amount of uplink data is an estimated value, which can be determined comprehensively based on factors such as application type and the type of business processed by the application (such as text, image or video sending business).

[0243] In some embodiments, the uplink data volume is the predicted data volume of the first IP packet that needs to be sent.

[0244] In other embodiments, the uplink data volume is the first data volume of data to be sent within a BSR cycle. For example, the uplink data volume includes the amount of data being assembled and the amount of data within a BSR cycle that may have finished assembling but has not yet started assembling.

[0245] Based on the uplink data volume, the CP can pre-apply for uplink authorization resources that are more suitable for the current data volume through BSR, so as to avoid the situation of insufficient or wasted uplink authorization resources by BSR.

[0246] (3-3) Link Type

[0247] In this embodiment, the AP can comprehensively determine one or more link types based on various factors such as the service scenario, network environment, electronic device capabilities, application instructions, remaining data allowance on the SIM card, and communication power consumption. For example, the link type can be wired communication, or it can be a wireless link type such as primary SIM cellular, secondary SIM cellular, 5G cellular, 4G cellular, Wi-Fi 2.4G, or Wi-Fi 5G. Determining the link type can be understood as determining the warm-up target or the communication method.

[0248] In some embodiments, for services with high latency requirements, such as flash sales, electronic devices can determine the link type primarily based on factors such as latency, packet loss rate, TCP connection establishment success rate, TLS / DTLS handshake success rate, retransmission rate, and bandwidth. For example, considering the round trip time (RTT) of the electronic device, if the RTT of cellular 5G is lower than that of cellular 4G and Wi-Fi, cellular 5G can be identified as the warm-up target, and the link type can be determined as a cellular 5G link. Alternatively, if the electronic device is connected to Wi-Fi, the link type can be determined as a Wi-Fi link.

[0249] In other embodiments, for high-throughput services such as downloads and video playback, the electronic device can determine the link type as a Wi-Fi link. Alternatively, if the remaining data allowance on the SIM card exceeds a threshold and the electronic device supports 5G cellular communication, the electronic device can determine the link type as a 5G cellular link.

[0250] In other embodiments, the electronic device can also determine the link type based on historical data of establishing various communication links. For example, the link type can be determined based on the success rate of establishing various types of communication links, the time required, etc.

[0251] Furthermore, this embodiment can determine the link type not only in scenarios involving adding new communication links but also in scenarios involving switching communication links. It should be noted that electronic link switching can be a network-wide switch (i.e., switching the entire device network), a switch of the communication link of a specific application within the device, or a switch of the communication link of a specific socket stream within an application. For example, an application might switch link type A to the default link type B in some scenarios. For instance, some video applications, when downloading videos, default to switching the link type from cellular to Wi-Fi. Or, when congestion or poor signal occurs in a Wi-Fi or 5G cellular network, the default link type is determined to be a 4G cellular link, etc. Based on this, the link that the electronic device defaults to switching to is the link type that needs to be determined in this case.

[0252] It should be noted that when there are multiple link types, electronic devices can establish multiple communication links simultaneously based on these multiple link types, or they can establish different communication links sequentially based on different link types.

[0253] S1204, AP sends a network warm-up command to CP.

[0254] In this embodiment, the network warm-up command includes at least one of the following: first time information, the amount of data to be sent within one BSR cycle, and link type. The first time information can be the time when the first IP packet of this communication arrives at the CP, or the time when the CP begins network warm-up; this embodiment does not impose any limitations on this.

[0255] S1205, the CP establishes a cellular communication link with the RAN equipment according to the network warm-up command.

[0256] In this embodiment, the CP starts network preheating based on the first time information in the network preheating command. However, as described in S1203, the first time information in the network preheating command can have multiple possible forms. When the first time information is the start time of network preheating, the CP starts network preheating based on this first time information. However, when the first time information is the time when the first IP packet arrives at the CP, or when the first time information is the start time of a scheduled network task of the application, the CP needs to convert it into the start time of network preheating before it can start network preheating.

[0257] The following example uses the first-time information as the start time of a scheduled network task in an application. For network tasks triggered in different ways, the application compiler (CP) can calculate the start time of network warm-up in different ways. Details are shown below.

[0258] For ease of description, the embodiments of this application divide the network warm-up of the cellular network into two stages. The first stage involves establishing RRC connections and establishing RBs, and the second stage involves requesting scheduling resources through SR and BSR.

[0259] First, combined Figures 14-16 As shown, the time information involved in this embodiment is introduced.

[0260] T0: The time when the AP detects the first event.

[0261] T1: The start time of the first stage of network warm-up, that is, the start time of network warm-up.

[0262] T2: The start time of the second phase of network warm-up.

[0263] T3: The opening time of the task channel for the timed network task in the application. T3 is the time that the AP can accurately detect. Taking the application opening the ticket-grabbing channel at 12:00 as an example, T3 is 12:00.

[0264] T4: The time when the IP packets corresponding to the scheduled network task reach the CP.

[0265] Δt1: In the scenario where a user triggers a timed network task, the sum of the user operation time, the time required for the AP to generate an IP packet, and the time required for the IP packet to travel from the AP to the CP after the timed network task starts (i.e., after T3) is an estimated value.

[0266] Δt2: In scenarios where timed network tasks are automatically triggered, the sum of the time required for the AP to generate IP packets and the time required for the IP packets to travel from the AP to the CP after the timed network task starts (i.e., after T3). This value can be determined based on historical data, and Δt2 is a relatively accurate value. It can be seen that, compared to Δt1 in manual scenarios, Δt2 in automatic scenarios does not include user operation time.

[0267] Δt RRC : The time required to establish an RRC connection.

[0268] Δt RB : The time required to establish RB.

[0269] Δt SR The time required to request scheduling resources from the RAN equipment via SR.

[0270] Δt BSR The time required for the BSR to request scheduling resources from the RAN equipment.

[0271] T timer : Duration of the UE inactive timer UeInactiveTimer.

[0272] Δt D1 The duration of the first phase of the network warm-up is an estimated value.

[0273] Δt D2 The duration of the second phase of network warm-up, including link resource keep-alive time, is an estimate. Δt D1 =Δt RRC +Δt RB + Stay alive duration.

[0274] In this embodiment, the timed network task can be triggered by user operation or automatically by the electronic device at the start of the task channel; this application embodiment does not impose any limitations on this. The following exemplifies the process of determining the start time of network warm-up, using different triggering methods for network tasks.

[0275] Example A: Scheduled network tasks are triggered by user actions.

[0276] For timed network tasks triggered by user actions, such as ticket-grabbing tasks triggered by users clicking on a ticket-grabbing control, the AP defaults to link keep-alive after network warm-up due to the uncertainty of user operation time, so that IP packets can be sent at any time after arrival. Therefore, the AP roughly determines the start time T1 of network warm-up based on the default keep-alive time.

[0277] This application's embodiments are combined with Figure 14 As shown, T1 is determined using reverse reasoning, as detailed below.

[0278] First, T4 is determined based on the known T3 and the roughly estimated Δt1.

[0279] On the AP side, after the application's timed network task begins (i.e., after T3), if the application receives a specific user operation (such as confirming ticket purchase), the application sends application data to the communication subsystem so that the communication subsystem can generate the corresponding IP packet based on the application data. Since user response time may vary, the duration of the user operation is uncertain. Therefore, the time when the AP starts generating the IP packet is uncertain, and the time when the IP packet arrives at the CP is also uncertain. Therefore, in this embodiment, the AP can only roughly determine the user operation duration based on the user's response time. Then, based on the sum of the user operation duration, the time required to generate the IP packet, and the time required for the IP packet to travel from the AP to the CP, Δt1, the AP determines the duration. Figure 14 It can be seen that after the application's timed network task starts (i.e., after T3), T4 will occur after Δt1. Therefore, T4 = T3 + Δt1.

[0280] Secondly, based on T4 and the duration Δt of the second stage D2 Determine T2.

[0281] In this embodiment, the duration of the second stage is Δt. D2 This is an estimate, specifically the sum of the time required for the CP to request scheduling resources based on the SR and BSR, and the time required for link resource keep-alive. The AP can preset a second-stage duration, for example, 200ms. In this embodiment, see... Figure 14 As shown, T2≤T4-Δt D2 .

[0282] Finally, based on T2 and the duration Δt of the first stage... D1 Determine T1.

[0283] The duration of the first phase is Δt. D1 This is an estimate, specifically the time Δt required for electronic equipment to establish an RRC connection and an RB connection with RAN equipment. RRC +Δt RB The timeframe is typically around 1 second, but can be determined through inference and learning based on the current network environment and historical data (such as historical RTT latency information and network environment assessment information). In this embodiment, it is based on T2 and the first stage duration Δt. D1 We can deduce T1 from this. That is, T1 = T2 - Δt D1 .

[0284] In summary, based on the above calculations, T4 = T3 + Δt1, T2 ≤ T4 - Δt D2 And T1 = T2 - Δt D1 We can obtain: T1≤T3+Δt1-Δt D2 -Δt D1 .

[0285] Example B: Scheduled network tasks are automatically triggered by the AP at regular intervals.

[0286] In this embodiment, for network tasks automatically triggered by the AP when the task channel is opened, such as the ticket-grabbing task automatically triggered by the AP when the ticket-grabbing channel starts, since the start time of the timed network task is fixed, the relevant IP packets can basically reach the CP on time according to the preset time. Therefore, the AP can calculate the start time T1 of network warm-up relatively accurately, taking into account the case where link keep-alive is not performed.

[0287] This application's embodiments are combined with Figure 15 As shown, T1 is determined using reverse reasoning. The details are as follows.

[0288] First, T4 is determined based on the known T3 and the estimated Δt2.

[0289] For scheduled network tasks configured with automatic execution time, after the task channel of the scheduled network task is opened, the AP can automatically generate IP packets based on application data and send the IP packets to the CP without user operation of the electronic device. Therefore, Δt2 is a relatively accurate value. After the application's scheduled network task starts (i.e., after T3), T4 is reached after Δt2. Therefore, T4 = T3 + Δt2.

[0290] Then, T2 is determined based on T4.

[0291] In this embodiment, since the time T4 when the IP packet arrives at the CP is a relatively accurate time, in order to save power consumption of the electronic device and ensure that the IP packet is sent out immediately after arriving at the CP, it can be controlled so that when the IP packet arrives at the CP, the CP has just secured uplink resources, that is, the CP is just able to send the IP packet. Since the time required for the CP to secure uplink resources precisely includes at least the time (Δt) for requesting uplink scheduling resources through the SR, this is crucial. SR ), and the time (Δt) required for the CP to receive the uplink resources allocated by the RAN device exactly after sending the BSR. BSR Based on this, in this embodiment, T2 = T4 - Δt SR -Δt BSR .

[0292] Finally, T1 is determined based on T2.

[0293] Normally, after RRC and RB are successfully established, the RAN device will start a UE inactivity timer UeInactiveTimer, the duration of which is denoted as T. timer If the electronic device does not use the RRC link to send data before the timer expires, the RAN device will release the RRC connection. Therefore, during network warm-up, the time during which the electronic device does not send data after establishing RRC and RB cannot exceed T. timer Therefore, T1 > T2 - Δt RRC -Δt RB -T timer Additionally, since the CP must establish RRC connections and RBs before the second phase of network warm-up begins, T1 ≤ T2 - Δt RRC -Δt RB Therefore, T1∈(T2-Δt) RRC -Δt RB -T timer ,T2-Δt RRC -Δt RB ].

[0294] In summary, according to T4 = T3 + Δt2, T2 = T4 - Δt SR -ΔtBSR and T1∈(T2-Δt) RRC -Δt RB -T timer ,T2-Δt RRC -Δt RB From this, we can obtain T1∈(T3+Δt2-Δt). SR -Δt BSR -Δt RRC -Δt RB -T timer T3+Δt2-Δt SR -Δt BSR -Δt RRC -Δt RB AP can select any time within this range as the actual value of T1.

[0295] After determining the start time T1 for network warm-up, the CP can begin network warm-up once T1 is reached. It should be noted that electronic devices can perform either full or partial network warm-up. Details are as follows.

[0296] A fully warmed-up communication link can be used directly for data transmission. For example, full warm-up includes establishing an RRC connection, requesting an RB, requesting uplink authorization via SR, and requesting uplink resources via BSR. In this way, when an IP packet reaches the CP within the current BSR cycle, the CP can directly send the IP packet to the RAN device at the specified time and resources according to the UL Gtant, ensuring transmission efficiency.

[0297] Partially warmed-up communication links cannot be used directly for data transmission and require further warming up before data can be sent. For example, partial warming may only establish an RRC connection and request an RB. Only after the IP packet arrives at the CP (Content Provider) does the CP request uplink authorization via SR (Streaming Service) and uplink resources via BSR (Background Service Service), thus completing the full warming up of the communication link. It should be noted that compared to existing technologies where the CP only begins network warming after the IP packet arrives, partial warming can complete some network warming operations before the IP packet arrives, which can also improve data transmission rates and enhance user experience to some extent.

[0298] S1206: After sending a network warm-up command to the CP, the AP generates and sends an IP packet to the CP.

[0299] For example, after the AP sends a network preheating command to the CP, the application receives the user's instruction to grab tickets. The application then sends the ticket-grabbing-related application data to the protocol stack. The protocol stack encapsulates the application data layer by layer to form IP packets. After generating the IP packets, the AP sends them to the CP through the interface between the AP and the CP.

[0300] S1207, the CP sends IP packets to the access network device through a pre-established communication link.

[0301] It should be noted that, due to factors such as network environment and equipment performance, the communication link between the CP and AP may or may not be established after the CP receives the IP packet sent by the AP. Therefore, the CP may send IP packets in the following situations.

[0302] Scenario 1: The IP packet arrives at the CP before the communication link is established. In this case, the CP temporarily stores the received IP packet in its buffer and waits for the communication link to be established before sending the IP packet.

[0303] Scenario 2: The IP packet arrives at the CP within the first BSR cycle after the communication link is established. In this case, the CP directly uses the communication link to send IP packets on the Physical Uplink Shared Channel (PUSCH) resource indicated by the RAN device.

[0304] Scenario 3: The IP packet does not reach the CP within the first BSR cycle after the communication link is established. In this case, the CP needs to perform link keep-alive according to the BSR cycle. Specifically, if no IP packet arrives at the CP within the i-th BSR cycle, the CP needs to send a keep-alive data packet to the RAN device before the end of the i-th BSR cycle, and continue to request uplink resources from the RAN device according to the BSR to enter the (i+1)-th BSR cycle, until the IP packet arrives at the CP, at which point the CP sends the IP packet through the communication link. Here, i is a positive integer.

[0305] It should be noted that, in the above process, the electronic device can also execute S1202 before S1201, that is, before detecting the first event to determine whether network warm-up should be performed, it can first detect the readiness of the communication link. If the communication link is not ready for data transmission, then S1201 is executed to detect the first event in order to predict network warm-up. If the communication link is ready, then network warm-up is not required, that is, S1201 and subsequent steps do not need to be executed.

[0306] Alternatively, after receiving the network warm-up command, the CP can also check the readiness of the communication link itself. If the communication link is not ready for data transmission, S1205 is executed to establish the communication link in advance. If the communication link is ready for data transmission, S1205 is not executed, that is, the communication link is not established.

[0307] In other embodiments, the electronic device can simultaneously send network warm-up commands to multiple different CPs, for example, sending network warm-up commands to a first CP (such as a modem) and a second CP (such as a Wi-Fi chip). The first CP establishes a first communication link with the RAN device based on the network warm-up command; the second CP establishes a second communication link with the RAN device based on the network warm-up command. The electronic device can simultaneously use the first and second communication links to send received IP packets; alternatively, after receiving IP packets, it can select any established communication link to send IP packets, thereby further improving the IP packet transmission rate.

[0308] In summary, the network preheating method provided in this application allows electronic devices to control the CP to begin establishing a communication link before the first IP packet arrives at the CP (e.g., before the IP packet is generated), thus enabling concurrent IP packet generation and network preheating processes. Based on this, after the IP packet arrives at the CP, the CP can quickly send the first IP packet using the pre-established communication link, resulting in lower network transmission latency and improved IP packet transmission rate. It can be understood that in scenarios such as ticket grabbing, red envelope grabbing, stock trading, and opening application homepages, this method can improve the success rate of electronic devices in ticket grabbing, red envelope grabbing, and stock trading, increase the speed of application homepage opening, and improve user experience.

[0309] As described above, during network warm-up, the AP estimates the initial data volume of IP packets to be sent by the CP and sends it to the CP so that the CP can request appropriate uplink resources based on this estimated data volume. Since the initial data volume is an estimate, the AP can update this estimated data volume based on current network tasks or the amount of data already assembled. One BSR period T... BSR This can be understood as the time interval for BSR transmission, i.e., every interval T. BSR The CP sends a BSR to the RAN device.

[0310] For example Figure 16As shown, the AP first sends the estimated uplink data volume (denoted as the first data volume S1) to the CP via a network warm-up command. During the network warm-up process, the CP uses S1 to request uplink resources from the RAN device within the first BSR cycle and sends a keep-alive data packet. However, within the first BSR cycle, the AP initiates other network tasks, resulting in an increase in the uplink data volume. Therefore, the AP can update the uplink data volume and send the updated uplink data volume (denoted as the second data volume S2) to the CP, so that the CP can re-request uplink resources via BSR based on S2.

[0311] It is understood that the network preheating method provided in this embodiment can calibrate the uplink data volume of IP packets to be sent after successful network preheating, so that the RAN device can allocate uplink resources to electronic devices more reasonably and avoid resource waste and network congestion.

[0312] In addition, during the process of the CP formally sending IP packets through the communication link, the AP can also notify the CP of the new estimated data volume in advance according to a certain period (e.g., according to the BSR period), so that the CP can apply for uplink resources from the RAN equipment in advance based on the estimated data volume.

[0313] It's important to note that in some technologies, the CP (Content Provider) typically requests uplink resources based only on the amount of data in the uplink buffer (UL Buffer) (e.g., S2), without considering data that the AP (Access Point) is currently assembling or that hasn't yet been assembled but will reach the uplink buffer before transmission. This leads to inaccurate resource allocation requests from the CP to the RAN (Radio Access Network). In other words, between the time the CP starts requesting uplink resources and the time it begins using those resources to transmit data, new IP packets may be received in the buffer, increasing the data volume to S3. Therefore, when the CP uses the uplink resources requested based on S2 to transmit data from the buffer, the link resources only support transmitting S2's worth of data, not S3's, resulting in insufficient uplink resources. In this case, the CP needs to send a BSR (Background Request) to the RAN again after transmitting S2's worth of data to re-request uplink resources for the remaining data, causing the CP to be unable to transmit some of the buffered data in a timely manner, increasing data transmission latency.

[0314] In this embodiment, the AP combines data already cached on the CP side, data that has been packetized on the AP side but not yet sent to the CP, data that is currently being packetized on the AP side, and data that is about to begin packetization, to comprehensively estimate the amount of data to be sent in the next BSR cycle, and sends the estimated amount of data to the CP in advance to request uplink resources. Therefore, this embodiment not only obtains a more accurate amount of cached data, but also reduces data transmission latency, improves data transmission speed, continuously avoids resource waste and network congestion, and improves user experience.

[0315] When electronic devices are warming up in a cellular network, various cellular network anomalies may occur. The following describes the network warm-up process under different network anomaly scenarios.

[0316] Example 1: Before the electronic device starts network warm-up, it receives an RRCConnectionReject message from the RAN device.

[0317] Normally, when an electronic device establishes an RRC connection with the RAN device, or after establishing an RRC connection, if the RAN device detects insufficient radio resources, protocol errors, or other issues, it will send an RRCConnectionReject message to the electronic device. The RRCConnectionReject message carries the electronic device's waittime.

[0318] For example Figure 17 As shown, after receiving an RRCConnectionReject message, the electronic device typically starts timer T302 based on the waiting time specified in the message. If the electronic device enters the RRC_CONNECTED state and reselects a cell before timer T302 expires, timer T302 will stop. After timer T302 expires, the electronic device re-initiates the RRC connection. In this situation, if the electronic device waits for timer T302 to expire before performing network warm-up, it will slow down the network warm-up process and affect the data transmission rate.

[0319] To improve network warm-up speed, for example Figure 17 As shown, when the cellular network is malfunctioning and the CP is waiting for the T302 timer to expire, the CP can determine whether the network warm-up start time T1 has been reached. If T1 has not been reached, it continues to wait for the T302 timer to expire. If the network warm-up start time T1 has been reached, it no longer waits for the T302 timer to expire and directly begins network warm-up.

[0320] Example 2: During the network warm-up process, an electronic device enters the RRC idle state due to a network anomaly.

[0321] For example Figure 18 As shown, the electronic device begins network warm-up, establishing an RRC connection and RB in advance, and enters the RRC connection state. Subsequently, the electronic device continuously monitors its RRC connection state. If the electronic device is in the RRC connection state, it performs link keep-alive and sends IP packets after receiving them. If the electronic device is not in the RRC connection state, it indicates a network connection anomaly. In this case, the electronic device immediately restarts network warm-up and establishes the RRC connection again.

[0322] Scenario 2: Wi-Fi Warm-up Scenario

[0323] The network preheating method provided in this application embodiment will be described in detail below with reference to a Wi-Fi network.

[0324] First, combined Figure 19 As shown, the process of an electronic device establishing a Wi-Fi connection and transmitting data is described. This process is executed by the Wi-Fi chip of the electronic device and specifically includes the following steps S1901 to S1903.

[0325] S1901, Electronic devices connect to Wi-Fi networks.

[0326] For example, the specific process of an electronic device accessing a Wi-Fi network includes the following (1) to (4):

[0327] (1) Detection phase. This refers to the process by which electronic devices discover Wi-Fi networks through active or passive scanning.

[0328] (2) Authentication Phase. This is the process of identity authentication between the electronic device and the Wi-Fi access point device. During the authentication process, the electronic device and the Wi-Fi access point device can negotiate and exchange keys to ensure the security of subsequent data transmission.

[0329] (3) Association Phase. After successful authentication, the electronic device and the Wi-Fi access point (AP) establish a connection. During the association process, the electronic device first sends an association request frame to the Wi-Fi access point. This frame includes information such as the electronic device's Media Access Control (MAC) address, supported speeds, and encryption methods. Upon receiving the association request frame, the Wi-Fi access point checks if the information in the frame matches its own configuration. If they match, the Wi-Fi access point returns an association response frame, which contains information such as the Service Set Identifier (SSID), performance settings, and encryption settings. At this point, the connection between the client and the AP is established.

[0330] (4) Obtaining an IP Address. After successful association, the electronic device can send a request to the Wi-Fi access point device via Dynamic Host Configuration Protocol (DHCP) to request an IP address. The Wi-Fi access point device selects an available IP address from its IP address pool and assigns it to the electronic device via a DHCP response message. After receiving the IP address, the electronic device configures it on its network interface, thus giving it a unique identity in the Wi-Fi network.

[0331] S1902, When an electronic device needs to transmit data, it acquires uplink resources.

[0332] In Wi-Fi networks, electronic devices primarily transmit data using the Distributed Coordination Function (DCF) mode. DCF mode is based on a carrier sense multiple access with collision avoidance (CSMA / CA) contention mechanism. DCF mode supports distributed access, allowing multiple distributed wireless nodes (such as mobile phones) to compete for the same resources.

[0333] It should be noted that when electronic devices need to send data, they use carrier sensing and collision avoidance to occupy uplink resources through channel contention.

[0334] Carrier sensing refers to monitoring the status of the wireless channel before transmitting data. If the channel is occupied, meaning another device is transmitting data, the current device will pause transmission to avoid collisions. This step is crucial for ensuring orderly data transmission.

[0335] Collision avoidance refers to a process where a sending device, before preparing to transmit data, sends a request-to-send (RTS) frame to the receiving device. The sending device indicates its intention to transmit data and requests to occupy the channel. The RTS frame includes a Duration field, indicating the time period for which the sending device requests exclusive channel access. After confirming the channel is idle, the receiving device broadcasts a clear-to-send (CTS) frame to all devices in the network. This CTS frame includes a Duration field and the sending device's address information. The Duration field in the CTS frame stores the value of the network allocation vector (NAV). This value indicates the time period during which the designated device exclusively uses the channel, ensuring that other devices will not attempt to transmit data during data transmission, thus avoiding signal collisions and packet corruption. After receiving the CTS frame, the sending device transmits data within the time specified in the CTS frame. Other electronic devices, upon receiving a CTS frame, will pause data transmission until the specified time expires.

[0336] S1903, Electronic devices use uplink resources to send data.

[0337] Specifically, the electronic device occupies the channel to transmit data within the time specified in the CTS frame. In this embodiment, the data can be an IP packet or a keep-alive data packet. After receiving the data, the Wi-Fi access point device returns a response message (i.e., an ACK message) to the electronic device.

[0338] It should be noted that electronic devices do not occupy the channel indefinitely; they will release the channel after the time period specified by their requested CTS. Therefore, after releasing the channel, if they need to send data, they can retransmit an RTS frame to preempt uplink resources. Furthermore, when an electronic device needs to send data, if it receives a CTS request from another electronic device, it determines the time period during which the channel was occupied by that other electronic device based on the CTS, and then preempts the link resources again after that time period ends.

[0339] Through the above steps S1901 to S1903, the electronic device can establish a Wi-Fi communication link with the Wi-Fi access point device and send data to the Wi-Fi access point device.

[0340] After understanding the process of electronic devices sending data through Wi-Fi networks, the following section introduces the network warm-up process in Wi-Fi scenarios.

[0341] Figure 20 This is a flowchart of a Wi-Fi network warm-up method provided in one embodiment of this application. See also... Figure 20As shown, this method is applied to electronic devices including AP and CP, where the CP has not established a communication link. The method includes the following steps S2001 to S2007.

[0342] S2001, AP detected the first event.

[0343] In this embodiment, the specific details of the first event are described in Part 1: Prediction of Network Warm-up, and will not be repeated here.

[0344] S2002, in response to the first event, the AP determines whether the communication link is not ready for data transmission.

[0345] For details, please refer to S1202, which will not be elaborated here.

[0346] S2003: If the communication link is not ready for data transmission, the AP generates a network warm-up command.

[0347] In this embodiment, the network warm-up command includes first-time information and link type, which will be described below.

[0348] (1) First-time information

[0349] The first piece of information could be the start time of network warm-up, the time when the first IP packet arrives at the CP, or the start time of a scheduled network task in the application. See section S1203 for details; further explanation is omitted here.

[0350] (2) Determine the link type

[0351] An access point (AP) can determine one or more link types based on various factors such as the business scenario, network environment, capabilities of electronic devices, and application instructions. For example, the link type could be Wi-Fi 2.4G or Wi-Fi 5G.

[0352] Optionally, the network warm-up command can also include the amount of uplink data. Based on the amount of uplink data, the AP can determine the length of the time period indicated in the RTS to be occupied, in order to avoid wasting uplink resources or insufficient uplink resources.

[0353] S2004, the AP of the electronic device sends a network warm-up command to the CP.

[0354] S2005, according to the network warm-up command, the electronic device establishes a Wi-Fi communication link with the Wi-Fi access point device through the CP.

[0355] In this embodiment, the CP starts network warm-up based on the first time information in the network warm-up command. However, as described in S2003, the first time information in the network warm-up command can have multiple possible forms. When the first time information is the start time of network warm-up, the CP starts network warm-up based on this first time information. However, when the first time information is the time when the first IP packet arrives at the CP, or when the first time information is the start time of a scheduled network task of the application, the CP needs to convert it into the start time of network warm-up before it can start network warm-up.

[0356] The following example uses the first-time information as the start time of a scheduled network task in an application. For network tasks triggered in different ways, the application compiler (CP) can calculate the start time of network warm-up in different ways. Details are shown below.

[0357] For ease of description, this embodiment divides the Wi-Fi network warm-up process into two stages: the first stage is accessing the Wi-Fi network, and the second stage is initiating contention to acquire uplink resources. After an electronic device first connects to a Wi-Fi network, it will automatically access the network again when it is within its coverage area. In other words, the electronic device has typically completed the first stage of Wi-Fi network warm-up. Therefore, the start time of the second stage is the focus of this application.

[0358] First, combined Figure 21 As shown, the time information involved in this embodiment is introduced.

[0359] T0: The time when the AP detects the first event.

[0360] T2: The start time of the second phase of network warm-up, that is, the start time of network warm-up.

[0361] T3: The start time of the timed network task in the application. T3 is the time that the AP can accurately detect. Taking the application opening the ticket-grabbing channel at 12:00 as an example, T3 is 12:00.

[0362] T4: The time when the IP packets corresponding to the scheduled network task reach the CP.

[0363] Δt1: In the scenario where a user triggers a timed network task, the sum of the user operation time, the time required to generate an IP packet, and the time required for the IP packet to travel from the AP to the CP after the timed network task starts (i.e., after T3) is an estimated value.

[0364] Δt2: In scenarios where timed network tasks are automatically triggered, the sum of the time required for the AP to generate IP packets and the time required for the IP packets to travel from the AP to the CP after the timed network task starts (i.e., after T3) can be determined based on historical data. Δt2 is a relatively accurate value.

[0365] Δt D2 The duration of the second phase during the warm-up process of the Wi-Fi network.

[0366] The following example illustrates the process of determining the start time T2 of network warm-up, taking into account different triggering methods for network tasks.

[0367] Example 1: Scheduled network tasks are triggered by user actions.

[0368] In this embodiment, for timed network tasks triggered by user operations, such as a ticket-grabbing task triggered by a user clicking a ticket-grabbing control, the AP defaults to link keep-alive after network warm-up due to the uncertainty of the user operation time, so that IP packets can be sent as soon as they arrive. Therefore, for network tasks triggered by user operations, the AP roughly determines the start time T2 of network warm-up based on the default keep-alive time. The details are shown below.

[0369] This application's embodiments are combined with Figure 21 As shown, T2 is determined using reverse reasoning, as detailed below.

[0370] First, T4 is determined based on the known T3 and the roughly estimated Δt1.

[0371] In this embodiment, due to the uncertainty of user operations, the AP can only roughly estimate the sum of the user operation duration, the time required to generate the IP packet, and the time required for the IP packet to travel from the AP to the CP, Δt1. After the application's timed network task begins (i.e., after T3), Δt1 elapses until T4. Therefore, T4 = T3 + Δt1.

[0372] Secondly, based on T4 and Δt D2 Determine T2.

[0373] In this embodiment, the second stage includes requesting uplink resources and keeping the communication link alive. The duration for requesting uplink resources is a preset value, which can be determined based on the duration required for requesting uplink resources in historical processes, for example, 50ms. The keep-alive duration for the communication link is also a preset value, for example, 200ms. Therefore, the duration Δt of the second stage... D2 This is an estimate, for example, 250 ms. Therefore, T2 = T4 - Δt D2 .

[0374] In summary, according to T4 = T3 + Δt1, T2 = T4 - ΔtD2 We can obtain: T2 = T3 + Δt1 - Δt D2 .

[0375] Example 2: Scheduled network tasks are automatically triggered by the AP.

[0376] In this embodiment, for network tasks automatically triggered by the AP at a preset time, such as a ticket-grabbing task automatically triggered by the AP after the ticket-grabbing channel opens, the relevant IP packets can reach the CP on time according to the preset time. Therefore, for network tasks automatically triggered by the AP, the CP calculates the second time information T2 relatively accurately, taking into account the case where link keep-alive is not performed.

[0377] This application's embodiments are combined with Figure 22 As shown, T2 is determined using reverse reasoning, as detailed below.

[0378] First, determine T4 based on the known T3 and Δt2.

[0379] For timed network tasks configured with automatic execution, the AP can automatically generate IP packets based on application data and send them to the CP (Content Processing Unit) after the set time, without requiring user intervention. Therefore, Δt2 is a relatively accurate value. After the application's timed network task begins (i.e., after T3), T4 occurs after Δt2. Therefore, T4 = T3 + Δt2.

[0380] Then, T2 is determined based on T4.

[0381] In this embodiment, since the time T4 when the IP packet arrives at the CP is a relatively accurate time, in order to save power consumption of the electronic device and ensure that the IP packet is sent out immediately after arriving at the CP, it can be controlled so that when the IP packet arrives at the CP, the CP just happens to have requested uplink resources, that is, the CP just happens to be able to send the IP packet. The time required for the CP to request uplink resources includes the carrier sensing process and the collision avoidance process. The carrier sensing duration is a preset value and can be determined based on historical sensing processes. For the collision avoidance process, the CP can adopt different avoidance strategies, such as no avoidance, with a fixed collision avoidance time of 0ms; or random short-term avoidance (e.g., 5us, 10us, etc.); or normal random collision avoidance. Therefore, T2 = T4 - Δt 侦听 -Δt 冲突避让 .

[0382] In summary, based on T4 = T3 + Δt2 and T2 = T4 - Δt 侦听 -Δt 冲突避让 We can obtain: T2 = T3 + Δt2 - Δt 侦听 -Δt 冲突避让 .

[0383] After determining the start time T2 for Wi-Fi network warm-up, the CP can begin network warm-up once T2 is reached. Specifically, with electronic devices already connected to the Wi-Fi network, the CP uses a CSMA / CA contention mechanism to seize uplink resources, thereby establishing a Wi-Fi communication link. See the relevant description in S1902 for details, which will not be repeated here.

[0384] In addition, after an electronic device acquires uplink resources, if the IP packets may not have reached the CP yet, the CP needs to use the uplink resources to send keep-alive packets to occupy the uplink resources and keep the link alive, so as to prevent the uplink resources from being preempted by other electronic devices.

[0385] S2006: After sending a network warm-up command to the CP, the AP generates and sends an IP packet to the CP.

[0386] For example, after the AP sends a network warm-up command to the CP, the application receives a user instruction to perform a stock trading operation. The application then sends the relevant application data to the protocol stack, which encapsulates the application data layer by layer to form IP packets. After generating the IP packets, the AP sends them to the CP through the interface between the AP and the CP.

[0387] S2007, the CP sends IP packets to the Wi-Fi access point device through a pre-established Wi-Fi communication link.

[0388] Due to factors such as network environment and equipment performance, the Wi-Fi communication link may or may not be established after the CP receives the IP packet sent by the AP. Therefore, the CP may send IP packets in the following situations.

[0389] Scenario 1: The IP packet arrives at the CP before the communication link is established. In this case, the CP temporarily stores the received IP packet in its buffer and waits for the Wi-Fi communication link to be established before sending the IP packet.

[0390] Scenario 2: IP packets arrive at the CP during the channel occupancy period indicated by the CTS. In this case, the CP directly uses the Wi-Fi communication link to send IP packets.

[0391] Scenario 3: The CP does not arrive within the channel occupancy period indicated by the CTS. In this case, the CP needs to send a keep-alive packet to keep the link alive, in order to prevent the Wi-Fi access point device from detecting that the electronic device is wasting channel resources and affecting subsequent communication.

[0392] Regarding scenario 3, it should be noted that after the channel occupancy period indicated by the current CTS expires, the CP can re-occupy the channel through RTS and CTS and wait for IP packets.

[0393] The link management method provided in this application, for scenarios where electronic devices use Wi-Fi network communication, allows the CP to initiate contention in advance and acquire uplink resources before the first IP packet arrives, so that the IP packet can be sent quickly after it arrives, thereby improving data transmission speed, especially the transmission speed of the first IP packet, and improving user experience.

[0394] Part Three: Link Resource Keep-Alive

[0395] As described above, after the electronic device completes network warm-up, IP packets may not reach the CP in a timely manner. To prevent the communication links pre-established by the CP from being released by the access network devices, the electronic device needs to keep the link resources alive.

[0396] It should be noted that link resource keep-alive can be initiated after network warm-up is complete, or it can be initiated independently, without relying on network warm-up. For example, it can be initiated after network warm-up begins, at which point the link resource keep-alive scenario is determined. Alternatively, it can be initiated in non-network warm-up scenarios, such as when network signal is poor or in pre-scheduling scenarios.

[0397] In this embodiment, link resource keep-alive includes link keep-alive and authorized keep-alive. Link resource keep-alive includes RRC keep-alive, RB keep-alive, etc. Authorized keep-alive mainly refers to uplink resource keep-alive, such as scenarios where the amount of data requested by the BSR exceeds the current actual amount, requiring the sending of PADDING packets, and scenarios where there is no data left under pre-scheduling, requiring the sending of PADDING packets. These are all examples of uplink resource keep-alive.

[0398] In some embodiments, the keep-alive data packet can be a PADDING packet or a PING message (also known as a PING packet).

[0399] A PADDING packet is a data packet used to pad or adjust the size of data during communication; it does not contain actual transmitted data. If an electronic device sends too many PADDING packets, the base station may impose penalties, affecting the uplink authorization of subsequent electronic devices. Additionally, after a BSR (Base Station Registry) obtains uplink authorization, if the terminal's data is less than the authorized amount, an empty PADDING packet must be sent after the terminal has sent all its data. There are also pre-scheduled scenarios where an empty PADDING packet must be sent even when the terminal has no data.

[0400] A PING message is a data packet based on the Internet Control Message Protocol (ICMP) used to test the network connectivity between a source host and a target host. It's important to note that PING messages are typically assembled on the AP's protocol stack. While they can be used for RRC keep-alive, this consumes user bandwidth. Furthermore, generating PING messages on the AP side incurs performance overhead and prevents the AP from sleeping, wasting power.

[0401] In addition, in RLC unacknowledged mode (UM), there is no confirmation from the base station when sending messages, so it cannot be guaranteed that the message has been sent successfully. For critical messages sent in the case of User Datagram Protocol (UDP), there is a requirement for stable transmission of critical messages, such as the need to increase the number of transmission opportunities.

[0402] Therefore, this embodiment provides a link resource keep-alive method, which uses valuable, non-guaranteed-send messages as keep-alive data packets to keep link resources alive. Valuable messages refer to messages that have other practical uses besides keep-alive. For example, non-guaranteed-send messages can be DNS messages, IP keep-alive messages, or probe messages from non-guaranteed-send queues, user-delegated messages, redundant or critical messages from regular send queues, etc. This embodiment does not limit the specific type of valuable messages. This method can reduce the transmission of worthless data, reduce traffic waste, and minimize power consumption.

[0403] First, the non-guaranteed network task pool and non-guaranteed sending queue involved in the embodiments of this application will be specifically described.

[0404] The unsecured network task pool includes various network tasks whose processing is uncertain, and whose processing results are uncertain. These network tasks only need to achieve the purpose of keeping the network alive. In other words, electronic devices merely increase the processing opportunities for these network tasks. Electronic devices can process these network tasks when needed, or they can choose not to process them or fail to process them. The unsecured network task pool can distinguish data packets of normal network tasks, aiming to keep the link alive, minimizing additional costs, and reducing or eliminating retransmissions. These network tasks have the lowest priority.

[0405] After entering a link resource keep-alive scenario, electronic devices begin to establish a pool of network tasks with uncertain access. For example... Figure 23As shown, the AP of an electronic device can store independent, non-guaranteed transmission tasks in the non-guaranteed network task pool, and can also add some regular network tasks to the non-guaranteed network task pool to increase the transmission opportunities of these regular network tasks. Here, an independent, non-guaranteed transmission task refers to a task used solely for non-guaranteed transmission; this task is not a regular transmission task.

[0406] For non-guaranteed transmission tasks, if transmission fails after being sent in a link resource keep-alive scenario, the network task can be discarded or retransmitted a limited number of times. If transmission is successful, it is determined whether it is a regular transmission task. If it is a regular transmission task, or both a regular transmission task and downlink data has been received from the RAN device, the regular transmission task is removed from the regular network task queue. Regular transmission tasks, after transmission failure, can be retransmitted using retransmission strategies such as radio link control acknowledged mode (RLC AM) or hybrid automatic repeat request (HARQ) in the MAC layer.

[0407] Figure 24 This is a schematic diagram of the structure of the unsecured network task pool provided in an embodiment of this application. The unsecured network task pool includes one or more network tasks, and each network task is assigned a lifetime. Network tasks that reach their lifetime will be automatically removed from the unsecured network task pool by the AP.

[0408] like Figure 24 As shown, it is not guaranteed that the network tasks in the network task pool include the following (3-1) to (3-7).

[0409] (3-1) DNS Request

[0410] In some embodiments, the DNS request task is used to request domains in the cache whose time to live (lifetime) is about to expire or has already expired.

[0411] In other embodiments, DNS prediction tasks refer to tasks that predict and analyze DNS-related data, which may involve multiple aspects such as DNS query performance, DNS failures, DNS cache hit rate, user online activity, and website security.

[0412] An access point (AP) can add network tasks to a non-guaranteed network task pool based on certain selection strategies. For example, an AP can add one or more recently generated DNS request tasks to the non-guaranteed network task pool based on the most recently updated (MRU) policy.

[0413] In this embodiment, the DNS request may carry additional information, including but not limited to the application's query type (such as IPv4, IPv6, or IPv4v6) and physical channel type (such as cellular network or Wi-Fi). Based on this information, the AP can select a more suitable link for the application to keep it alive.

[0414] (3-2)IP keep-alive

[0415] IP keepalive is a mechanism in TCP connections used to detect whether the other end of the connection is still alive, ensuring connection reliability. This mechanism is called the "keepalive" mechanism in the TCP / IP protocol stack.

[0416] Typically, the AP uses TCP Keep-alive messages for keep-alive and probe operations. TCP Keep-alive messages usually include the [TCP keep Alive] field, and TCP Keep-alive acknowledgment messages usually include the [TCP keepAlive Ack] field.

[0417] For example, the TCP Keep-alive message is: 13:29:25.810654000 58.220.18.9192.168.137.140TCP 54[TCP keep Alive]7824>39582[Ack]Seq=6478Ack=4449Win=43008Len=0.

[0418] For example, the TCP Keep-alive response message is: 13:29:25.838357000 192.168.137.14058.220.18.9TCP 54[TCP keep Alive Ack]39582>7824Seq=4449Ack=6479Win=94720Len=0.

[0419] Application network tasks typically invoke sockets. The application processing unit (AP) can determine whether the socket caller has set fields related to IP keep-alive, such as SO_KEEPALIVE, TCP_KEEPIDLE, TCP_KEEPINTVL, or TCP_KEEPCNT. Here, the socket caller refers to the application using socket functionality. If these fields are set in the socket, it indicates that the network task is an IP keep-alive task. In scenarios where electronic devices require keep-alive capabilities, the AP can add this network task to a pool of non-secure network tasks.

[0420] For example, for network tasks as shown in Table 1, because their sockets have the SO_KEEPALIVE field set, the AP can determine that they are IP keep-alive tasks. In scenarios with link keep-alive requirements, the AP can add them to the pool of network tasks that are not guaranteed.

[0421] Table 1

[0422]

[0423] (3-3) Exploration Mission

[0424] The probe tasks include latency detection, connectivity detection, and node detection. These tasks can be implemented using commands such as PING, Tracert, and HTTP probe commands. Probe tasks can be initiated by the operating system of the electronic device or by an application. The AP can generate relevant probe packets based on the probe tasks and send these packets via protocols such as HTTP, ICMP, or ARP.

[0425] In some embodiments, after the operating system / application initiates a probe task, the AP, in addition to processing the probe task normally, can also add it to a non-guaranteed network task pool so that it can send the IP packets corresponding to the probe task when link keep-alive is required. It is understood that for the same probe task, the method provided in this embodiment can obtain two probe results sequentially, thereby improving the accuracy of the probe results.

[0426] In other embodiments, when the operating system or application of the electronic device does not actively initiate a probe task, the AP of the electronic device can pre-generate probe tasks and store them in an indeterminate transmission task pool so that the IP packets corresponding to the probe tasks can be sent when link keep-alive is needed. The AP can cache the probe results obtained through the indeterminate transmission tasks so that the previous probe results can be reused when the operating system or application formally initiates a probe task, achieving a rapid response to network probes.

[0427] (3-4) Delayed network tasks

[0428] Delayed network tasks refer to tasks that are allowed to run for a certain period of time (T). delay The transmission task completed within ) can be a non-urgent or background network service configured by the user through interfaces such as HTTP, WebSocket, socket, or encapsulated network transmission interfaces. In T delay At any time within the specified period, the AP can add relevant packets of delayed network tasks to the unsecured network task pool for later use.

[0429] It should be noted that once a delayed network task is added to the non-guaranteed network task pool and successfully sent via the non-guaranteed sending queue during the link keep-alive phase, the electronic device will no longer send the delayed network task via the regular sending queue. Additionally, in T... delay Before termination, if a delayed network task fails to be sent through the uncertain sending queue, or if it has been sent but no response has been received from the network device, the device can continue sending the delayed network task through the regular sending queue, increasing the chances of the delayed network task being sent. Furthermore, after a delayed network task is sent in a link keep-alive scenario, it does not need to be sent through the regular sending queue again, thus achieving the goal of saving power.

[0430] (3-5) Business Network Tasks

[0431] Business network tasks include PUSH status updates and application status synchronization. In addition to being sent via the regular send queue, these network tasks can also be added to a pool of non-guaranteed network tasks.

[0432] (3-6) Ecosystem additions do not guarantee task delivery

[0433] To facilitate communication between applications and the operating system, an ecosystem interface can be set up for the application. Through the ecosystem interface, the application can directly add network tasks to the pool of non-guaranteed network tasks.

[0434] (3-7) Critical messages, retransmitted / redundant messages

[0435] Critical messages and retransmission / redundant messages can be added to the unguaranteed network task pool or the unguaranteed transmission queue, thus increasing the transmission opportunities compared to general transmission. It's important to note that the lifetime of these messages must be accurately recorded, and after receiving the corresponding downlink message following general transmission, the unguaranteed transmission queue must be notified. If previously sent data has not yet been transmitted, it needs to be canceled and deleted. Without notification, deletion based on lifetime timeout is the only option. Increasing the transmission opportunities for critical data messages, retransmissions, and redundant messages, replacing PADDING transmission, can increase the reliability of air interface transmission.

[0436] After introducing the unguaranteed network task pool, the unguaranteed send queue will be introduced below.

[0437] The transmission queue is not guaranteed to send packets, including DNS packets, IP keep-alive packets, probe packets, user-delegated packets, redundant packets from the regular transmission queue, and critical packets. It is not guaranteed that these packets will be IP packets. Each of these packets carries its own lifetime; when a packet's lifetime expires, the electronic device automatically deletes it. Critical packets and retransmission / redundant packets can originate from the AP side or from the regular transmission queue.

[0438] After introducing the non-guaranteed network task pool and the non-guaranteed transmission queue, the following section provides a detailed explanation of the specific process for keeping electronic devices alive with link resources.

[0439] Figure 25 This is a schematic flowchart illustrating a link resource keep-alive method provided in one embodiment of this application. The method specifically includes the following steps S2501 to S2504.

[0440] S2501, CP determines that link resource keep-alive is required.

[0441] In some embodiments, when an electronic device detects a keep-alive trigger condition, it determines that link resource keep-alive is required. For example, the keep-alive trigger condition may include detecting that the current BSR period is about to end and no IP packets have been received from the AP; or detecting that the channel occupancy period indicated by the current CTS is about to end and no IP packets have been received from the AP; or detecting that the electronic device's inactivity timer is about to expire and no IP packets have been received from the AP.

[0442] S2502, CP acquisition does not guarantee message delivery.

[0443] See Figure 26 As shown, the CP (Content Controller) of an electronic device can obtain unguaranteed transmission packets using methods one through three, based on keep-alive parameters such as the required data volume and lifetime. These keep-alive parameters include: the size of the data volume to be transmitted, the lifetime of the unguaranteed transmission task, whether to retry, and whether downlink filtering is required. Downlink filtering refers to the CP discarding received downlink data after sending an unguaranteed network task. The keep-alive parameters can be determined based on uplink resource information obtained from the network side.

[0444] Method 1: CP requests the IP packets generated by AP in real time.

[0445] For example Figure 27As shown, the electronic device obtains the corresponding DNS request task from the non-secure network task pool based on the data length to be sent, lifetime, and keep-alive parameters such as whether downlink filtering is required, and encapsulates it through the TCP / IP protocol stack to generate an IP packet.

[0446] For example, in an RRC keep-alive scenario, the task with the smallest data volume that is not guaranteed to send can be selected to save device resources and power consumption. Alternatively, in an authorized keep-alive scenario, a task with a data volume less than or equal to the current amount of PADDING data to be filled should be selected. Or, in a scenario that increases the chance of sending, the network task with the highest priority, high urgency, short lifetime, and used to increase the chance of sending should be selected.

[0447] Alternatively, non-guaranteed delivery tasks can be selected based on priority. Prioritize the types of non-guaranteed delivery tasks, such as DNS requests, IP keepalive, probe tasks, delayed network tasks, business network behavior, ecosystem-added non-guaranteed tasks, critical message tasks, and retransmission / redundancy tasks. Critical message tasks and retransmission / redundancy tasks have the highest priority, so these types of tasks should be prioritized.

[0448] In certain scenarios, network devices may prioritize certain types of packets, allowing for the prioritization of these types of non-guaranteed delivery tasks, such as PING packets in probe tasks. Furthermore, retransmission policies for non-guaranteed delivery packets can be defined, including whether to completely eliminate retransmissions, retransmit only a few packets, and whether the corresponding downlink packets should be discarded.

[0449] It should be noted that since the generation of IP packets takes a certain amount of time, the real-time generation of IP packets has a certain time delay and its timeliness is relatively weak.

[0450] Method 2: CP does not guarantee that it will receive pre-generated IP packets from the sending queue.

[0451] In some embodiments, the AP generates IP packets based on unguaranteed network tasks according to the unguaranteed task module. For example, after determining that network warm-up is needed, the network warm-up module on the AP side can send a notification message to the unguaranteed sending task module to inform its CP that network warm-up is about to begin. Based on this warm-up notification, the unguaranteed sending task module obtains M target network tasks from the unguaranteed network task pool and generates M IP packets based on these target network tasks. Subsequently, the M IP packets are sent to the unguaranteed sending queue for later use. M is a positive integer.

[0452] Taking the pre-generated DNS message with no guarantee of delivery as an example, such as Figure 28As shown, the DNS cache on the AP side includes DNS request tasks with first and second priorities. The first-priority DNS request tasks include Pre-DNS requests (i.e., pre-resolved DNS requests), while the second-priority DNS requests include DNS requests in the DNS cache whose lifetime is about to expire or has already expired. The AP can generate IP packets according to the IPv4 or IPv6 protocol based on the first-priority or second-priority packets and add them to the DNS packet queue in the non-guaranteed delivery queue on the CP side.

[0453] Taking a DNS request to perform an IPv4 DNS lookup on the domain mobile.12306.cn as an example, such as... Figure 29 As shown, the data format of this DNS request message includes a 20-byte IP header, an 8-byte UDP header, and 32 bytes of UDP data, totaling 61 bytes. The UDP data specifically represents DNS query A (indicating a request for an IPv4 DNS query), including 18 bytes of basic DNS information (such as fixed fields like DNS header, query type, and query class) and 15 bytes of the domain name mobile.12306.cn.

[0454] It should be noted that if the RAN device returns downlink data after a DNS message in the unreliable transmission queue has been sent, the DNS message needs to be removed from the unreliable transmission queue, and a new DNS request message should be generated as needed to eliminate redundant messages.

[0455] In other embodiments, the CP can send critical messages, retransmission / redundant messages from the normal transmission queue to the non-guaranteed transmission queue.

[0456] In some other embodiments, the CP can periodically generate some unreliable transmission packets when in a link resource keep-alive scenario, and it can also periodically generate some unreliable transmission packets when not in a link resource keep-alive scenario. Alternatively, after the IP address of the electronic device changes, the IP packets in the current unreliable transmission queue can be cleared, and then some IP packets can be regenerated based on the new IP and stored in the unreliable transmission queue. Or, after the IP is lost, the unreliable transmission queue can be cleared. In the cellular preheating scenario, the electronic device's data service being turned off or deactivated will result in the loss of the electronic device's IP.

[0457] Based on this, the link resource keep-alive module on the CP side sends a packet retrieval request to the unsecured transmission queue before sending an IP packet. In response to this packet retrieval request, the unsecured transmission queue sends an IP packet to the link resource keep-alive module.

[0458] It should be noted that since the IP packets are pre-generated, the CP can directly use the IP packets without waiting when performing link resource keep-alive, and the real-time performance of the data transmission process is relatively strong.

[0459] Method 3: The CP obtains IP packets from the regular sending queue.

[0460] Before sending an IP packet, the link resource keep-alive module on the CP side sends a packet retrieval request to the regular sending queue. In response to this request, the regular sending queue sends an IP packet to the link resource keep-alive module.

[0461] S2503, CP generates keep-alive data packets based on messages that are not guaranteed to be sent.

[0462] Typically, after an IP packet arrives at the CP (Content Provider), it needs to be encapsulated by various protocol layers of the data link layer (L2) of the radio interface protocol stack before it can be sent. Taking mobile communication as an example, the data link layer (L2) of the radio interface protocol stack, from top to bottom, consists of the Service Data Adaptation Protocol (SDAP), the Packet Data Convergence Protocol (PDCP), the Radio Link Control Protocol (RLC), and the Medium Access Control Protocol (MAC).

[0463] In existing technologies, keep-alive data packets are typically PADDING data. However, in this embodiment, the CP's link resource keep-alive module can use partially or completely replace the PADDING data with a non-guaranteed transmission message to form keep-alive data packets.

[0464] For example Figure 30A As shown, when it is not guaranteed that the transmitted message will partially replace the PADDING data, part of the PADDING data and the message whose transmission is not guaranteed are treated as keep-alive data packets. These packets are then sequentially encoded at the SDAP, PDCP, RLC, and MAC layers to generate corresponding protocol data units, and a header (H) is added. Optionally, in... Figure 30A The data packet shown may also include regular IP packets.

[0465] For example Figure 30BAs shown, without guaranteeing that the entire transmitted message will replace the PADDING data, and without guaranteeing that the transmitted message will independently function as a keep-alive data packet, it will participate in layered encoding at the SDAP, PDCP, RLC, and MAC layers to generate corresponding protocol data units, and a header will be added. Since all data in the IP packet is not guaranteed to be transmitted, and therefore, if the transmission of this unguaranteed message fails, retransmission can be cancelled. Optionally, in... Figure 30B The data packet shown may also include regular IP packets.

[0466] The keep-alive data packet is encoded at the SDAP layer to generate an SDAP SDU and add a header. Then, it is encoded at the PDCP layer to generate a PDCP SDU and add a header. Next, it is encoded at the RLC layer to generate an RLC SDU and add a header. Finally, it is encoded at the MAC layer to generate a MAC SDU and add a header. The keep-alive data packet encoded at the MAC layer is then ready for transmission.

[0467] S2504, CP uses a pre-established communication link to send keep-alive data packets according to the keep-alive rules.

[0468] For example, in cellular communication, after the CP requests uplink resources according to the BSR, the CP sends keep-alive data through a pre-established cellular communication link within the current BSR period. Alternatively, in Wi-Fi communication, the CP sends keep-alive data through a pre-established Wi-Fi communication link within the channel occupancy period indicated by the current CTS.

[0469] Taking link resource keep-alive after cellular network preheating as an example, after the RRC link is established in advance, when the RAN device detects that the electronic device is not sending data, it will actively release the RRC after the UeInactiveTimer times out. Therefore, it is necessary to keep the RRC link alive. For example... Figure 21 In the rough warm-up scenario shown, the CP sends keep-alive packets based on the keep-alive packet sending duration. For example... Figure 22 In the precise warm-up scenario shown, the CP sends a message that is not guaranteed to be sent before the UeInactiveTimer times out.

[0470] It's important to note that when the terminal fails to obtain a keep-alive timeout, it needs to autonomously learn the keep-alive transmission period. For example, an initial value, such as 10 seconds, can be preset, and then progressively increased during subsequent keep-alive attempts—for instance, adding 2 seconds, 4 seconds, or 8 seconds to the initial 10 seconds to determine the minimum keep-alive time and thus learn the approximate keep-alive transmission period. Additionally, electronic devices can obtain the keep-alive periods of other electronic devices or the current network from the cloud or peripheral devices. Autonomously learning the keep-alive transmission period can improve keep-alive efficiency, saving power and bandwidth.

[0471] Since the keep-alive data in this embodiment includes messages that are not guaranteed to be sent, the CP does not need to guarantee that they will be sent successfully. Therefore, the air interface protocol stack on the CP side needs to use a separate retransmission policy to control the transmission of this data.

[0472] For example Figure 31 As shown, after a data transmission failure, the air interface protocol stack first determines whether the data is non-guaranteed transmission data. If it is not non-guaranteed transmission data, it retryes normally according to the air interface protocol stack's usual retry strategy. If it is non-guaranteed transmission data, it further determines whether it is a single transmission. A single transmission means that it is sent only as keep-alive data and not through the regular message queue. If the data is a single transmission, it means that the data is only used for link keep-alive and does not need to be guaranteed to be transmitted successfully, therefore no retransmission is performed. If the data is not a single transmission, meaning that the non-guaranteed transmission message within it is still sent through the regular message queue, then it means that the non-guaranteed transmission message is a relatively important message, and the air interface protocol stack can use a preset retransmission strategy to retransmit the data.

[0473] It should be noted that the embodiments of this application do not limit the number of retransmissions, nor do they limit the type of unguaranteed transmission packets to be retransmitted. These packets can be IP packets that the CP requests the AP to generate in real time, and the CP can obtain pre-generated IP packets from the unguaranteed packet queue. Alternatively, the CP can obtain IP packets from the regular packet queue.

[0474] In addition, since the keep-alive data packet in this embodiment includes a message that is not guaranteed to be sent, the CP does not need to guarantee that it will be sent successfully. Therefore, the air interface protocol stack on the CP side needs to use a separate retransmission policy control to control the transmission of this data.

[0475] It should be noted that after sending the unguaranteed delivery message, the CP (Content Controller) of the electronic device may receive downlink data returned by the RAN (Radio Access Controller). The CP can either discard this downlink data or deliver it to the AP (Access Point). For example, the CP can determine whether to discard the downlink data or deliver it to the AP based on the return indication field carried in the unguaranteed delivery message or the return indication field in the corresponding unguaranteed delivery task. The return indication field indicates whether the CP needs to send the downlink data to the AP.

[0476] In other embodiments, the electronic device may also generate unguaranteed delivery messages solely based on unguaranteed delivery tasks. Based on this, the process of link resource keep-alive by the electronic device is as follows.

[0477] Figure 32 This is a schematic flowchart illustrating a link resource keep-alive method provided in another embodiment of this application. The method is applied to electronic devices requiring link resource keep-alive and specifically includes the following steps S3201 to S3207.

[0478] S3201, the electronic device has been determined to enter the link resource keep-alive scenario.

[0479] In this embodiment, link resource keep-alive can be initiated after network warm-up is complete, or it can be initiated independently, without relying on network warm-up. For example, the link resource keep-alive scenario can be determined after network warm-up begins. Alternatively, the link resource keep-alive scenario can be determined in non-network warm-up scenarios, such as when the network signal is poor or in pre-scheduling scenarios.

[0480] S3202, the electronic device determines whether there is a task that cannot be guaranteed to be sent.

[0481] As described above, the unreliable task module on the AP side of the electronic device contains an unreliable network task pool. This pool stores unreliable transmission tasks for the electronic device, such as DNS requests, IP keep-alive, probe tasks, delayed network tasks, push status updates, service network tasks, ecosystem-added unreliable transmission tasks, critical packets, retransmission / redundant packets, etc. Therefore, the electronic device can determine whether the unreliable network task pool includes unreliable transmission tasks. If unreliable transmission tasks exist, proceed to step S3203. If not, proceed to step S3207.

[0482] S3203, the electronic device determines whether to generate an unguaranteed delivery message in advance based on the unguaranteed delivery task.

[0483] In this embodiment, generating unguaranteed delivery messages in advance based on the unguaranteed delivery task means generating unguaranteed delivery messages in advance based on the unguaranteed delivery task before the keep-alive data packet needs to be sent, for later use. Generating unguaranteed delivery messages in real time based on the unguaranteed delivery task means that generating unguaranteed delivery messages only begins when the keep-alive data packet needs to be sent.

[0484] Since IP packet generation takes time, real-time generation generally has relatively poor timeliness. Therefore, electronic devices can determine whether to pre-generate unguaranteed delivery packets based on the unguaranteed delivery task, depending on the keep-alive scenario. For example, in scenarios like RRC keep-alive where the timeliness requirement for IP packet acquisition is not high, IP packets can be generated in real-time. However, in scenarios like BSR and pre-scheduling where the timeliness requirement for IP packet acquisition is high, unguaranteed delivery packets should be pre-generated based on the unguaranteed delivery task.

[0485] It should be noted that the process of generating IP packets in real time can be executed on the AP side. In addition, in scenarios where the IP protocol stack / DNS protocol stack is deployed synchronously on the CP side, it is also executed on the CP side to avoid waking up the AP and reduce the power consumption of electronic devices.

[0486] If it is necessary to generate unguaranteed delivery messages in advance, proceed to the next step S3204. If it is not necessary to generate unguaranteed delivery messages in advance based on the unguaranteed delivery task, proceed to S3205.

[0487] S3204, the electronic device generates an unguaranteed delivery message in advance based on the unguaranteed delivery task. See Method 2 in S2502 for details.

[0488] S3205: When an electronic device needs to send a keep-alive data packet, it generates an unguaranteed delivery message in real time based on the unguaranteed delivery task. See Method 1 in S2502 for details.

[0489] S3206: Electronic devices, following the keep-alive rule, send messages without guarantee of delivery.

[0490] S3207: Electronic devices send PING or PADDING packets according to the keep-alive rule.

[0491] In summary, in this embodiment, when performing keep-alive, if there is an uncertain delivery task, valuable uncertain delivery messages generated in advance or in real-time by the uncertain delivery task are used as keep-alive data packets according to a certain strategy, so that the keep-alive data packets are no longer invalid or singular. If there is no uncertain delivery message, PING packets are used for link keep-alive or PADDING packets are used for authorized keep-alive.

[0492] Part Four: Stopping and Switching Network Warm-up

[0493] Since the network warm-up in this application is predicted and determined in advance by the electronic equipment, there may be instances where the prediction fails, meaning the electronic equipment does not actually need to send data. Therefore, if the prediction fails, the electronic equipment needs to stop network warm-up to avoid wasting the resources of the electronic equipment and RAN equipment.

[0494] In this embodiment, in response to the second event, the CP of the electronic device stops network warm-up. For example, in a cellular warm-up scenario, stopping network warm-up may involve disconnecting the RRC connection or stopping cellular link keep-alive. In a Wi-Fi warm-up scenario, it may involve disconnecting the Wi-Fi connection or stopping Wi-Fi link keep-alive.

[0495] In some embodiments, the second event is the detection of a specific user operation or device control event. For example, the second event may be the electronic device screen turning off, the predicted exit of the target application for data transmission, receiving a user-controlled operation to power off / restart the electronic device, airplane mode being turned on, the SIM card not being detected in a cellular preheating scenario, data service being turned off, or the user being in arrears with payment, etc., or the Wi-Fi network being turned off, the Wi-Fi network card not being detected, or the Wi-Fi communication system being uninstalled or restarted, etc. The embodiments of this application do not limit the specific type of the second event.

[0496] In other embodiments, the second event is that the AP fails to generate an IP packet within a preset time period. For example, after network warm-up begins, or after successful network warm-up, or after T4 (the time estimated by the AP for the IP packet to reach the CP), the AP fails to generate an IP packet, or the CP fails to receive an IP packet within the preset time period. This preset time period can be a preset value (e.g., 5 seconds, 10 seconds, etc.), or it can be N times the time required to execute the network task. Here, N is a number greater than 1, such as N = 1.5, N = 2, N = 5, etc.

[0497] Optionally, the second event mentioned above is typically detected by the AP. After detecting the second event, the AP sends a warm-up stop command to the CP. Upon receiving the warm-up stop command, the CP stops the network warm-up task.

[0498] In some embodiments, the second event is that the CP does not receive an IP packet from the AP within a preset time. For example, after T1 (network warm-up start time), or after successful network warm-up, or after T4 (the time when the AP estimates that the IP packet will reach the CP), the CP does not receive an IP packet from the AP within the preset duration. This preset duration can be determined by the CP itself, or it can be notified to the CP by the AP through a network warm-up command or other commands. Furthermore, the preset duration can be a preset value (e.g., 5 seconds, 10 seconds, etc.), or it can be N times the time required to execute the network task. Here, N is a number greater than 1, such as N = 1.5, N = 2, N = 5, etc. After detecting this second event, the CP automatically terminates the network warm-up task.

[0499] In some other embodiments, during network warm-up, the network being warmed up by the electronic device becomes abnormal, such as due to unpaid cellular network fees or Wi-Fi outage. In this case, the electronic device can switch to another network for network warm-up. For example, it can switch from a cellular network to a Wi-Fi network for network warm-up, or vice versa.

[0500] After an electronic device initiates network warm-up, due to network lag, device lag, or other reasons, the user may control the device to reconnect to the network or restart the application. For example, the user might control the device to turn airplane mode on and then immediately turn it off, turn data service off and then immediately turn it on, or close a ticket-grabbing application and then immediately open it and display the ticket-grabbing page. In these situations, the electronic device may need to re-initiate network warm-up.

[0501] Based on the above, after detecting the third event, the electronic device can retain the network warm-up-related data in the AP's protocol stack for a preset time (e.g., 3 seconds or 5 seconds) for use when initiating network warm-up again. If the electronic device does not resume network warm-up within this preset time, i.e., the CP does not receive the network warm-up command again or receives the network stop command issued by the AP, then the network warm-up-related data in the protocol stack is deleted.

[0502] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0503] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the communication link management method shown in the above embodiments. The communication link management method includes a network warm-up method and a link resource keep-alive method.

[0504] This application also provides a chip, see [link to relevant documentation] Figure 33 As shown, the chip includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the communication link management method in the above embodiments. The communication link management method includes a network warm-up method and a link resource keep-alive method.

[0505] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the communication link management method provided in the above embodiments. The communication link management method includes a network warm-up method and a link resource keep-alive method.

[0506] This application also provides a computer program product, which includes a computer program. When the computer program is run by an electronic device, the electronic device implements the communication link management method provided in the above embodiments. The communication link management method includes a network warm-up method and a link resource keep-alive method.

[0507] It should be understood that the processor mentioned in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0508] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAN device DOM, RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0509] In the embodiments provided in this application, the division of each framework or module is only a logical functional division. In actual implementation, there may be other division methods. For example, multiple frameworks or modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0510] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0511] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0512] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0513] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for managing a communication link, characterized in that, Applied to an electronic device, the electronic device including an application processor (AP) and a communication processor (CP), wherein the electronic device has not established a communication link, the method includes: In response to the first event, the AP sends a network warm-up command to the CP before sending an Internet Protocol (IP) packet to the CP; wherein the IP packet is the first packet that the AP predicts it needs to send; The CP establishes a communication link with the wireless access network device according to the network preheating command.

2. The method according to claim 1, characterized in that, The method further includes: After sending a network warm-up command to the CP, the AP sends the IP packet to the CP; The CP sends the IP packet through the communication link.

3. The method according to claim 1 or 2, characterized in that, The network warm-up command includes at least one of the following: first-time information, uplink data volume, and link type.

4. The method according to claim 3, characterized in that, The first time information is the predicted start time of the upcoming network task; or, The first time information is the estimated time when the IP packet arrives at the CP; or, The first time information is the time when the CP begins network warm-up.

5. The method according to claim 3 or 4, characterized in that, The uplink data volume is the size of the IP packet, or the amount of data to be sent within a preset time.

6. The method according to claim 5, characterized in that, When the uplink data volume is the amount of data to be sent within a preset time, the uplink data volume includes the amount of data that will be packetized within the preset time, as well as the amount of data that has been packetized but not sent to the CP.

7. The method according to any one of claims 1 to 6, characterized in that, The first event includes at least one of the following: The application calls the network interface; The AP receives a network task notification from the application. The artificial intelligence (AI) model predicted that network warm-up was necessary. User actions, application events, or network events used to trigger network warm-up; The target text information was identified in the display interface / calendar information / electronic alarm clock; Receive notification information from the server or surrounding electronic devices regarding scheduled network tasks; The operating system pre-builds the chain.

8. The method according to any one of claims 1 to 7, characterized in that, In response to the first event, before sending an Internet Protocol (IP) packet to the CP, the AP sends a network warm-up command to the CP, including: In response to the first event, the AP predicts that the first application is about to perform a network task; The AP determines the warm-up object based on the service type of the network task and the current communication status of the electronic device under each link type. The warm-up object is the CP. Send the network warm-up command to the CP.

9. The method according to any one of claims 1 to 8, characterized in that, The CP sends the IP packet through the communication link, including: If the communication link is not established when the IP packet arrives at the CP, the CP waits for the communication link to be established before immediately sending the IP packet through the communication link; and / or, When the IP packet arrives at the CP, if the communication link has been established, the CP immediately sends the IP packet through the communication link.

10. The method according to claim 8, characterized in that, The IP packet is the packet corresponding to the network task, and the task channel of the network task is opened periodically.

11. The method according to claim 10, characterized in that, If the first time information is the start time of network warm-up, and the communication link is a cellular communication link, the method further includes: When the first network task needs to be initiated based on user operation, the AP or the CP determines the first time information based on the start time of the network task, the estimated duration of the user operation, the estimated duration required to establish the communication link, and the estimated duration required to keep the link resources alive. When the first network task is automatically initiated by the electronic device, the AP or the CP determines the first time information based on the start time of the network task, an estimated time required for the AP to generate and send the IP packet to the CP, an estimated time required to establish the communication link, and the duration of the inactive timer.

12. The method according to claim 10, characterized in that, If the first time information is the start time of network warm-up, and the communication link is a Wi-Fi communication link, the method further includes: When the network task needs to be initiated based on user operation, the AP or the CP determines the first time information based on the start time of the network task, the estimated duration of the user operation, the estimated duration required to request uplink resources, and the estimated duration required to keep the link resources alive. In the scenario where the network task is automatically initiated by the electronic device, the AP or the CP determines the first time information based on the start time of the network task, an estimated time required for the AP to generate and send the IP packet to the CP, and an estimated time required to request uplink resources.

13. The method according to claim 3, characterized in that, When the communication link is a cellular communication link, the CP establishes a communication link with the wireless access network device according to the network warm-up command, including: The CP establishes a Radio Resource Control (RRC) connection and a Radio Bearer (RB) with the wireless access network device according to the network warm-up command; The CP requests uplink authorization from the radio access network device via a scheduling resource request (SR). The CP requests uplink resources from the radio access network device through a buffer status report (BSR), and the BSR includes the uplink data volume.

14. The method according to claim 13, characterized in that, The method further includes: The AP updates the uplink data volume; The AP sends the updated uplink data volume to the CP; The CP re-requests the uplink resources from the radio access network device based on the updated uplink data volume.

15. The method according to any one of claims 1 to 14, characterized in that, When the CP receives the network warm-up command, the CP starts an inactive timer T302. The CP establishes a communication link with the wireless access network device according to the network warm-up command, including: If the network warm-up start time has been reached before T302 times out, a communication link is established with the wireless access network equipment.

16. The method according to any one of claims 1 to 15, characterized in that, Before the CP sends the IP packet through the communication link, the method further includes: If the IP packet fails to reach the CP after the communication link has been established and is about to exceed the first time period, an unguaranteed delivery message is sent to the wireless access network device through the communication link. The unguaranteed delivery message includes the target data.

17. The method according to claim 16, characterized in that, The statement that message delivery is not guaranteed includes at least one of the following: DNS-related messages in the domain name lookup system; IP keep-alive message; IP packets related to the reconnaissance mission; IP packets related to delayed network tasks: Messages related to the application's business network tasks; Critical messages, retransmitted / redundant messages.

18. The method according to claim 16 or 17, characterized in that, When the communication link is a cellular communication link, the first duration is equal to the current buffer state report (BSR) period, or the first duration is equal to the duration of the inactive timer issued by the radio access network device. When the communication link is a Wi-Fi communication link, the first duration is equal to the length of the channel occupancy period indicated in the CTS frame issued by the wireless access network device.

19. The method according to any one of claims 16 to 18, characterized in that, Before sending the keep-alive data packet to the wireless access network device via the communication link, the method further includes: In response to a target event, the AP establishes a non-guaranteed network task pool, which includes multiple network tasks. The AP does not guarantee whether to process the network task, nor does it guarantee the processing result when processing the network task.

20. The method according to claim 19, characterized in that, The target event includes: The AP determines that network preheating is required; or... The AP predicted the need for link resource keep-alive through an artificial intelligence model.

21. The method according to any one of claims 16 to 20, characterized in that, The methods for obtaining messages that do not guarantee delivery include: The CP obtains a preset unguaranteed transmission message from the unguaranteed transmission queue on the CP side according to the keep-alive parameter; or, The CP obtains important messages or retransmission / redundant messages from the regular sending queue on the CP side according to the keep-alive parameters. The important messages or the retransmission / redundant messages are the messages whose transmission is not guaranteed. or, The CP sends a message acquisition request to the AP, and the message acquisition request includes keep-alive parameters; The AP obtains the target network task from the non-guaranteed network task pool according to the keep-alive parameter, and generates the non-guaranteed transmission message according to the target network task; The AP sends the unguaranteed delivery message to the CP.

22. The method according to claim 21, characterized in that, The keep-alive parameters include at least one of the following: the size of the data to be filled, the lifetime of the keep-alive data packet, the data type and priority of the keep-alive data packet, whether the keep-alive data packet needs to be retransmitted, and whether the downlink data corresponding to the keep-alive data packet is allowed to be discarded by the CP.

23. The method according to any one of claims 1 to 22, characterized in that, The method further includes: In response to the second event, the AP sends a preheating stop command to the CP; In response to the preheating stop command, the CP disconnects the communication link.

24. The method according to claim 23, characterized in that, The second event includes: The AP does not generate the IP packet within a preset time; or... User actions, application events, or device control events that trigger the cessation of network warm-up.

25. The method according to any one of claims 1 to 22, characterized in that, The method further includes: After the communication link is established, if the CP does not receive the IP packet within a preset time, the CP disconnects the communication link.

26. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in any one of claims 1 to 25.

27. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method performed by the AP or the CP as described in any one of claims 1 to 25.

28. A chip, characterized in that, The chip includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the method performed by the AP or the CP as described in any one of claims 1 to 25.

Images