WO2025168105A1 - Data transmission method and apparatus, electronic device, and storage medium - Google Patents

Abstract

The present application relates to the technical field of communications, and provides a data transmission method, an electronic device, and a storage medium, in which an important signaling message can be reliably sent, so as to improve the experience of a user using an electronic device to access the Internet by means of a Wi-Fi network. The method comprises: when a first protocol message to be sent is a signaling message of a preset protocol, an electronic device adds the first protocol message to a first priority transmission queue; when the first protocol message is not a signaling message of the preset protocol, the electronic device adds the first protocol message to a second priority transmission queue, the second priority transmission queue being different from the first priority transmission queue, and the preset protocol comprising any one or more of the following items: EAPOL, DHCP, ARP, DNS, or TCP; and, according to a preset queue message sending rule, the electronic device sends the first protocol message to a target device by means of a Wi-Fi network, the preset queue message sending rule comprising the transmission priority of the first priority transmission queue being higher than the transmission priority of the second priority transmission queue.

Description

Data transmission method and device, electronic device and storage medium

This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on February 9, 2024, with application number 2024101790006 and invention name “A data transmission method and device, electronic device and storage medium”, the entire contents of which are incorporated by reference into this application.

Technical Field

The application relates to the field of terminal technology, and in particular to a data transmission method and device, electronic equipment and storage medium.

Background Art

With the rapid development of information technology and smart terminals, Wireless Fidelity (Wi-Fi) applications have become increasingly popular in people's daily lives. Wi-Fi application scenarios mainly consist of APs (Wireless Access Points) that provide Wi-Fi services and various electronic devices that support Wi-Fi. Currently, APs can support 2.4G and 5G bands. However, since the 2.4G band is a public and free band, signal interference is likely to occur between APs operating in the 2.4G band, causing interference to the air interface (i.e., Wi-Fi air interface) signal between electronic devices and APs, reducing the user's Internet experience. For APs operating in the 5G band, since the electromagnetic waves in the 5G band have a weak ability to penetrate obstacles, once there is an obstacle between the AP and the electronic device, the air interface signal between the electronic device and the AP will also deteriorate, reducing the user's Internet experience.

In summary, currently when users use electronic devices to access the Internet via Wi-Fi, the air interface signal may be interfered with or the air interface signal is poor, resulting in a poor Internet experience for the users.

Summary of the Invention

The embodiments of the present application provide a data transmission method and apparatus, an electronic device, and a storage medium, which can improve the user experience of using an electronic device to access the Internet through a Wi-Fi network.

In order to achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

In a first aspect, an embodiment of the present application provides a data transmission method. The method includes: when a first protocol message to be sent is a signaling message of a preset protocol, the electronic device adds the first protocol message to a first priority transmission queue; when the first protocol message is not a signaling message of the preset protocol, the electronic device adds the first protocol message to a second priority transmission queue; the second priority transmission queue is different from the first priority transmission queue; the preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS, or TCP; the electronic device sends the first protocol message to a target device via a Wi-Fi network according to a preset queue message sending rule; the preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue.

Based on the technical solution provided by the above embodiment, when sending a protocol message, the electronic device can place the signaling message of the preset protocol that is closely related to the user's Internet access in a first priority transmission queue with a high transmission priority, such as a VO queue. In the Wi-Fi scenario, the message in the queue with a high transmission priority has a stronger channel seizure capability and a higher transmission success rate. In this way, even if the air interface environment is not good enough (that is, the air interface signal is interfered with or the air interface signal is poor), the signaling message of the preset protocol placed in the first priority transmission queue can be sent out more reliably (it can be understood that the probability of the recipient successfully receiving the signaling message is higher), avoiding the signaling message of the preset protocol from being successfully sent due to the air interface environment not being good enough (it can be understood that the recipient failed to successfully receive the signaling message), resulting in the user using the electronic device to access the Internet through the Wi-Fi network. Connection jams, delays or failures, ensuring the user's experience of accessing the Internet through the Wi-Fi network.

In a possible design of the first aspect, the electronic device includes a Wi-Fi driver. When a first protocol message to be sent is a signaling message of a preset protocol, the electronic device adds the first protocol message to a first priority transmission queue, including: the Wi-Fi driver parses the first protocol message, and when determining, based on a parsing result, that the first protocol message is a signaling message of the preset protocol, adds the first protocol message to the first priority transmission queue.

Based on the above design, the electronic device can use the Wi-Fi driver to identify the first protocol message to be sent, thereby determining whether the first protocol message is a signaling message. If the first protocol message is determined to be a signaling message, the first protocol message can be placed in the first priority transmission queue with the strongest channel preemption capability, thereby ensuring the reliable transmission of the signaling message and protecting the user's experience of surfing the Internet on the Wi-Fi network using the electronic device.

In a possible design manner of the first aspect, the signaling message of the preset protocol includes at least one of the following: a second handshake message in a four-way handshake process of the Extensible Authentication Protocol for Local Area Networks (EAPOL), a fourth handshake message in a four-way handshake process of the EAPOL, a Dynamic Host Configuration Protocol (DHCP) DISCOVER message, a DHCP REQUEST message, an Address Resolution Protocol (ARP) request message, a Domain Name System (DNS) request message, a first TCP handshake message in a three-way handshake process of the Transmission Control Protocol (TCP), and a third TCP handshake message that does not carry service data in the three-way handshake process of the TCP.

The ARP request message is used to request the physical address MAC of the gateway; the DNS request message is used to request the Internet Protocol address IP corresponding to the target domain name; and the first TCP handshake message is used to request the establishment of a TCP connection.

Since the above-mentioned signaling messages are all signaling messages of preset protocols that are strongly related to the user's Internet experience, after the mobile phone sends the above-mentioned signaling messages, if the recipient fails to receive them, it is impossible to determine the absence of such messages in a timely manner, thereby making it impossible for the user to use the electronic device to surf the Internet normally. Based on this, for such signaling messages, it is necessary to put them in the first priority transmission queue with the strongest channel seizure capability. In this way, even if the air interface environment is not good enough (that is, the air interface signal is interfered with or the air interface signal is poor), the signaling message can be sent out more reliably (it can be understood that the recipient can receive the signaling message with a greater probability), avoiding the signaling message from being successfully sent due to the air interface environment not being good enough (it can be understood that the recipient failed to successfully receive the signaling message), resulting in the user experiencing connection jams, delays or failures when using the electronic device to surf the Internet through the Wi-Fi network, thereby ensuring the user's experience of surfing the Internet through the Wi-Fi network.

In a possible design of the first aspect, the first priority transmission queue includes a voice-optimized VO queue; and the ability of the first priority transmission queue to seize a channel is greater than that of transmission queues other than the first priority transmission queue.

Based on the above design, since the first-priority transmission queue is the VO queue with the strongest channel preemption capability, signaling messages can be sent more reliably, thereby better ensuring that electronic devices can access the Internet through the Wi-Fi network and guaranteeing the user's Internet experience.

In a possible design manner of the first aspect, the transmission queues other than the first priority transmission queue include: a video optimization VI queue, a best effort BE queue, and a background optimization BK queue.

Based on the above design, protocol messages other than signaling messages in the preset protocol can be sent in a queue that does not have the strongest channel seizure capability, so that the signaling messages of the preset protocol can be promptly placed in the VO queue with the strongest channel seizure capability for transmission, thereby better ensuring that electronic devices can access the Internet through the Wi-Fi network and guaranteeing the user's Internet experience.

In a possible implementation manner of the first aspect, when the first protocol message is not a signaling message of a preset protocol, the first protocol message includes: a third TCP handshake message carrying service data in a TCP three-way handshake process.

Based on the above design, when the third TCP handshake message carries service data, it can contain multiple data packets. That is, after receiving the third TCP handshake message, even if it contains missing data, the TCP server can promptly determine which sequence numbers are missing based on the sequence numbers of the received messages and promptly notify the mobile phone to resend the data. Therefore, when the third TCP handshake message carries service data, it cannot be simply considered a signaling message and can be treated as a signaling message for the default protocol. Even if a transmission issue occurs, the peer device can promptly detect the issue and notify the mobile phone to resend the missing data, eliminating the need to prioritize its transmission using the default protocol's signaling message transmission priority. This allows signaling messages for the default protocol that significantly impact the Wi-Fi network experience to be promptly routed to the VO queue with the strongest channel preemption capability for transmission, thereby better ensuring Wi-Fi access for electronic devices and guaranteeing a secure user experience.

In a possible implementation of the first aspect, the electronic device includes a TCP/IP protocol stack and a Wi-Fi chip; the first protocol message is a message generated by the TCP/IP protocol stack; and the electronic device sends the first protocol message to a target device through a Wi-Fi network according to a preset queue message sending rule, including: the electronic device controls the Wi-Fi chip to send the first protocol message to the target device through the Wi-Fi network according to the preset queue message sending rule.

Based on the above design, through the cooperation of the TCP/IP protocol stack and the Wi-Fi chip, the electronic device can successfully send the first protocol message to the target device.

In a second aspect, embodiments of the present application further provide a data transmission device that can be applied to an electronic device. The functions of the device can be implemented in hardware or by executing corresponding software on the hardware. The hardware or software includes one or more modules corresponding to the above functions, such as a processing module and a sending module.

Among them, the processing module is used to add the first protocol message to the first priority transmission queue when the first protocol message to be sent is a signaling message; the processing module is also used to add the first protocol message to the second priority transmission queue when the first protocol message is not a signaling message of the preset protocol; the second priority transmission queue is different from the first priority transmission queue; the preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS or TCP; the sending module is used to send the first protocol message to the target device through the Wi-Fi network according to the preset queue message sending rule; the preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue.

In a third aspect, the present application provides an electronic device comprising a display screen, a memory, and one or more processors; the display screen, the memory, and the processor are coupled; wherein the memory stores computer program code, and the computer program code comprises computer instructions, which, when executed by the processor, enable the electronic device to execute the data transmission method provided in the first aspect and any possible design thereof.

In a fourth aspect, the present application provides an electronic device, including a TCP/IP protocol stack, a Wi-Fi driver, and a Wi-Fi chip; when the Wi-Fi driver executes computer instructions, the electronic device executes the data transmission method provided in the first aspect and any one of its design methods.

In a fifth aspect, the present application provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the data transmission method provided in the first aspect and any possible design thereof.

In a sixth aspect, the present application provides a computer program product, which, when executed on an electronic device, enables the electronic device to execute the data transmission method provided in the first aspect and any possible design thereof.

In a seventh aspect, the present application provides a chip system, which includes a processor, the processor may include an AP, and the AP includes a Wi-Fi driver and a TCP/IP protocol stack. The processor may be a SoC (system on chip). The chip system may also include a Wi-Fi chip. When the processor executes a computer instruction (e.g., when the Wi-Fi driver or Wi-Fi chip in the processor executes a computer instruction), the electronic device to which the chip system belongs executes the data transmission method provided in the first aspect and any one of its design methods.

It can be understood that the beneficial effects that can be achieved by the technical solutions provided in the second to fifth aspects mentioned above can be referred to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of an ARP interaction process provided in an embodiment of the present application;

FIG2 is a schematic diagram showing the principle of a data transmission method provided in an embodiment of the present application;

FIG3 is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

FIG4 is a schematic diagram of a software architecture of an electronic device provided in an embodiment of the present application;

FIG5 is a flowchart of a data transmission method according to an embodiment of the present application;

FIG6 is a second flow chart of a data transmission method provided in an embodiment of the present application;

FIG7 is a third flow chart of a data transmission method provided in an embodiment of the present application;

FIG8 is a fourth flow chart of a data transmission method provided in an embodiment of the present application;

FIG9 is a fifth flow chart of a data transmission method provided in an embodiment of the present application;

FIG10 is a schematic structural diagram of a chip system provided in an embodiment of the present application;

FIG11 is a schematic structural diagram of another chip system provided in an embodiment of the present application.

DETAILED DESCRIPTION

Specific content The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to be limiting of the present application. As used in the specification and appended claims of the present application, the singular expressions "a", "an", "said", "above", "the" and "this" are intended to include plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that "/" means or, for example, A/B can mean A or B; "and/or" in the text is merely a description of an association relationship of associated objects, indicating that three relationships can exist, for example, A and/or B can mean: the existence of A alone, the existence of A and B at the same time, and the existence of B alone.

References to "embodiments" in this application mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described in this application may be combined with other embodiments.

The terms "first" and "second" in the following embodiments of this application are used for descriptive purposes only and should not be understood as implying or suggesting relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the embodiments of this application, unless otherwise specified, "plurality" means two or more.

First, the nouns involved in the embodiments of this application are explained as follows:

Frequency band: In the field of communications, frequency band refers to the frequency range of electromagnetic waves.

Channel: Specifically refers to the path through which signals are transmitted in a communication system. It consists of the transmission medium through which signals travel from the transmitter to the receiver. Each commonly used Wi-Fi frequency band is divided into multiple channels.

For example, the channels and center frequencies of the 2.4 GHz frequency band used by Wi-Fi are shown in Table 1 below.

Table 1

As shown in Table 1, the 2.4 GHz frequency band can be divided into 14 channels, each with an effective bandwidth of 20 MHz. Channel 14 is generally not used. Both 802.11b/g and 802.11a/b/g/n/ac standards generally support channels 1 through 13. In other words, the channels supported by Wi-Fi mentioned above may include all 13 channels.

For example, some channels and center frequencies of the 5 GHz frequency band used by Wi-Fi are shown in Table 2 below.

Table 2

Extensible Authentication Protocol over Local Area Network (EAPOL): EAPOL is a message encapsulation format defined by the 802.1x protocol. It is primarily used to transmit EAP protocol messages between clients (such as mobile phones and other electronic devices) and devices (such as wireless routers), allowing EAP protocol messages to be transmitted on a LAN. In practical applications, EAPOL can authenticate users and establish shared data from which future encryption keys are derived. After completing identity authentication between an electronic device and a wireless router using EAPOL, the electronic device can use the encryption key to send messages to the router as an access point.

Dynamic Host Configuration Protocol (DHCP): DHCP is a standard protocol defined in RFC 1541 (superseded by RFC 2131). It allows a DHCP server to dynamically assign network configuration information, such as Internet Protocol (IP) addresses, subnet masks, and gateway addresses, to clients (e.g., mobile phones and other electronic devices). DHCP is typically used in large local area networks, primarily to centrally manage and allocate IP addresses, thereby increasing address utilization.

In a Wi-Fi scenario, when an electronic device such as a mobile phone is connected to a Wi-Fi network and obtains an IP address through DHCP interaction, the DHCP server (usually a router or a network device connected to the router) will assign an available IP address to the mobile phone and provide the IP address of the gateway at the same time. Generally speaking, in a Wi-Fi scenario, the gateway is a router connected to a Wi-Fi network. As a network boundary device, the router is responsible for forwarding messages from the internal network to the external network, and also forwarding messages from the external network to the internal network. The gateway IP address obtained by the mobile phone is the IP address pointing to the router. By sending the message to the gateway, the router can perform network address translation (NAT), routing selection and other operations, thereby realizing communication between the mobile phone and the external network.

Address Resolution Protocol (ARP): ARP is a TCP/IP protocol that obtains a physical address (media access control address, MAC) based on an IP address. Since the IP address is a logical identifier and can be modified at will by anyone, in order to ensure security, MAC addresses are used to identify specific devices in a local area network. In the process of network communication, electronic devices such as mobile phones first obtain their own IP addresses and the IP address of the gateway of the local area network to which they belong through the DHCP protocol. At this time, ARP is needed to convert the IP address of the gateway into the MAC address of the gateway. In this way, electronic devices can accurately send data to the gateway, and the gateway can then forward the data to other devices on the Internet.

In a Wi-Fi scenario, when a mobile phone or other electronic device is connected to the Wi-Fi scene and obtains its own IP address and the IP address of the gateway (usually a router or an optical modem connected to the router) through DHCP, the electronic device can send an ARP request message in the broadcast domain of the Wi-Fi local area network. The ARP request message contains the target IP address (i.e. the IP of the gateway) and the IP address of the electronic device, as well as an empty MAC address field. Other devices in the Wi-Fi local area network will receive this ARP request packet and check whether their IP address matches the target IP address in the ARP request message. If it matches, the device will reply its MAC address to the sender. In this way, the electronic device can convert the IP address into the corresponding MAC address, thereby achieving network communication.

For example, as shown in Figure 1, if there are four devices in the local area network: host A, host B, host C and host D. Among them, the IP address of host A is 192.168.1.1, the IP address of host B is 192.168.1.2, the IP address of host C is 192.168.1.3, and the IP address of host D is 192.168.1.4. If host A is an electronic device used by the user, then when host A obtains the gateway IP address of 192.168.1.3, host A will broadcast an ARP request message in the broadcast domain. The ARP request message is used to request the MAC address of the IP address (specifically the target IP address) of 192.168.1.3. Afterwards, host B, host C and host D will all receive the ARP request message and identify whether the target IP address in the ARP request message is the same as or matches their own IP address. If Host B and Host D determine that the target IP address in the ARP request message is different from or does not match their own IP address, they will discard the ARP request message. If Host C determines that the target IP address in the ARP request message is the same as or matches its own IP address, it will return its MAC address to Host A. Host A will associate the received MAC address with the gateway's ID address and store it in the ARP table entry. Host A will then use this MAC address to send messages.

Under normal circumstances, after the above process, the electronic device stores the mapping relationship between the gateway's IP address and MAC address in the ARP table entry so that it can be quickly searched when needed. For example, an example of an ARP table entry is as follows:

Among them, IP address is the IP address; HW type is the hardware type; Flags is the flag bit (used to identify the attributes of the ARP record); HW address is the hardware address, that is, the MAC address; Mask is the subnet mask; Device is the device identifier.

However, due to changes in network topology or device replacement, the mapping relationship between IP addresses and MAC addresses may change, and some mapping relationships will become invalid. This process is called ARP aging. In order to maintain the accuracy of the ARP table, electronic devices will regularly check the entries in the ARP table (i.e., mapping relationships) and delete outdated entries from the table. When an entry in the ARP table is outdated, the electronic device needs to resend the ARP request in the broadcast domain to obtain the latest MAC address. The ARP aging time is usually determined by the configuration parameters of the electronic device and can be adjusted according to the needs of the network.

Domain Name System (DNS): DNS is an internet service that acts as a distributed database that maps domain names to IP addresses, making internet access more convenient. DNS (Domain Name System) provides a service that converts easy-to-remember domain names into IP addresses. Through DNS, electronic devices can convert the host name of an application server (e.g., www.example.com) to the corresponding IP address (e.g., 192.0.2.1). Furthermore, when a user enters a domain name in a browser, the electronic device can also use DNS to convert it into the corresponding IP address to complete the corresponding communication.

Transmission Control Protocol (TCP): TCP is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. TCP serves as the primary transmission protocol in the Internet Protocol Suite (TCP/IP protocol suite), providing reliable data transmission services for many applications (such as web browsers and email clients). The main function of TCP is to provide reliable, connection-oriented communication in the network. It ensures that data is not lost, duplicated, or out of order during transmission, and provides congestion control mechanisms to avoid network congestion. When a user starts using an application on an electronic device that requires an Internet connection, the electronic device will establish a TCP connection with the application server to which the application belongs, so that it can smoothly interact with the application server according to user needs, thereby displaying the corresponding content for the user to view.

Queuing: IEEE 802.11e adds quality of service (QoS) functionality to wireless local area networks (WLANs) based on the 802.11 protocol. The standardization of this protocol took a long time. During this process, the Wi-Fi organization defined the Wi-Fi Multimedia (WMM) protocol to meet the QoS requirements of different WLAN vendors. WMM ensures that high-priority packets are sent first, thereby ensuring better quality of service for applications such as voice and video on wireless networks.

WMM defines four transmission queues with different priorities: voice optimized queue (VO), video optimized queue (VI), best effort queue (BE), and background optimized queue (BK). The VO queue is primarily used for voice data, with low latency as its primary goal; the VI queue focuses on video data, aiming to ensure smooth video streaming; the BE queue meets best-effort service requirements without strict QoS guarantees; and the BK queue targets background applications, with a certain tolerance for delay and loss.

Among the four transmission queues (VO, VI, BE, and BK), packets in queues with higher transmission priorities have a stronger ability to seize the channel. The WMM protocol defines a set of enhanced distributed channel access (EDCA) parameters that distinguish high-priority packets (i.e., packets in high-priority queues) and ensure that they receive priority in channel resources to meet diverse service requirements. Currently, EDCA parameters primarily include the arbitration interframe space (AIFS), random backoff, and transmission opportunity limit (TXOP limit).

AIFS defines the time each priority message needs to wait before starting to send on the contention medium, that is, AIFS includes a priority-related timer. Messages with higher transmission priorities can be configured with a shorter AIFS so that they can participate in the competition earlier, thereby increasing their probability of obtaining a transmission opportunity on the contention medium (i.e., channel), which also helps meet the requirements of applications with higher real-time performance. In other words, the higher the transmission priority of the transmission queue, the shorter the AIFS parameter time, so that the higher the transmission priority of the transmission queue, the higher the probability of competing for the channel. Specifically, the transmission queues with AIFS parameters from small to large are VO, VI, BE, and BK. For example, the AIFS parameter of the VO queue can be 24us, the AIFS parameter of the VI queue can be 34us, the AIFS parameter of the BE queue can be 43us, and the AIFS parameter of the BK queue can be 79us.

The random backoff parameter is a range, specifically [CWmin, CWmax]. The random backoff mechanism is to derive CW from [CWmin, CWmax]. The initial value CW = CWmin. After a contention failure, it is doubled, and then updated to CW = 2CW until CW reaches CWmax. After a contention success, CW returns to CWmin. The higher the transmission priority of a transmission queue, the smaller the corresponding [CWmin, CWmax]. The random backoff parameter ranges, from smallest to largest, are for the following transmission queues: VO, VI, BE, and BK. For example, for the BK transmission queue, CWmin(BK) = 32, CWmax(BK) = 1024; for the BE transmission queue, CWmin(BE) = 16, CWmax(BE) = 512; for the VI transmission queue, CWmin(VI) = 8, CWmax(VI) = 16; and for the VO transmission queue, CWmin(VO) = 4, CWmax(VO) = 8.

The random backoff parameter corresponds to a random backoff time of n*9us, a number randomly selected from the range [0, CW-1]. The higher the transmission priority, the smaller the range of the random backoff parameter. Therefore, the higher the transmission priority, the smaller the random backoff time.

TXOP Limit refers to the maximum duration that a given electronic device or station (STA) can transmit during a competitive or non-competitive transmission in a wireless local area network. In the IEEE 802.11 standard, TXOP Limit refers to the maximum amount of time that a STA obtains a transmission opportunity and continuously transmits data on the shared medium of the network. TXOP Limit has different configuration methods for different QoS categories. By allowing STAs to transmit for a longer time during the transmission opportunity, TXOP Limit can improve the quality of service for high transmission priority messages, such as voice and video messages. For messages with low transmission priority, the TXOP Limit is smaller to give more stations the opportunity to transmit. In other words, the TXOP Limit of the transmission queue with a higher transmission priority is larger, and the TXOP Limit of the transmission queue with a lower transmission priority is smaller.

When a channel is idle, these four transmission queues compete for the channel. They compete by counting down based on the AIFS parameter plus the random backoff parameter. If the channel is still idle after the countdown reaches 0, the queue will occupy it. If the channel is already occupied, the queue will restart the countdown after the channel becomes idle. After a transmission queue wins the channel, it can use the channel for the duration of the TXOP limit.

In addition, when the Wi-Fi driver drives the Wi-Fi communication module in the electronic device to send data, it will allocate more air interface resources to queues with higher transmission priority, so that queues with higher transmission priority have a greater probability of preempting the channel, thereby ensuring that messages in the queue are sent more reliably. For example, when sending messages in the VO queue, the transmission power of the Wi-Fi communication module will be higher than when sending messages in the BE queue, and the transmission rate of the Wi-Fi communication module when sending messages in the VO queue will be lower than when sending messages in the BE queue.

In the prior art, the AP devices that provide Wi-Fi networks operate in the 2.4G frequency band and the 5G frequency band. Among them, the 2.4G frequency band is a public frequency band and is easily interfered with by signals generated by other devices in the daily environment (such as electromagnetic waves generated by electromagnetic waves), resulting in greater interference to the air interface signal between the electronic device and the AP. The penetration ability of electromagnetic waves in the 5G frequency band is relatively weak. Once there is an obstacle between the electronic device and the AP, the air interface signal will also be deteriorated. Based on this, when users currently use electronic devices to access the Internet via Wi-Fi, the network environment will interfere with the air interface or the air interface signal is relatively poor, resulting in a poor Internet experience for users (for example, they cannot access the Internet or the Internet speed is slow).

The protocols included in the TCP/IP protocol stack may include: EAPOL, DHCP, ARP, DNS, TCP, FTP (file transfer protocol), SLP (service location protocol), BOOTP (bootstrap protocol) and dozens of other protocols.

In scenarios where the air interface signal is interfered with or the air interface signal is poor, some embodiments of the present application can improve the user's Internet experience by prioritizing the transmission of signaling messages of important protocols in the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol stack (some protocols that are strongly related to the user's Internet experience) and improving the transmission reliability of the signaling messages of these important protocols.

Among them, important protocols in the TCP/IP protocol stack are those that are strongly related to the user's Internet experience, such as EAPOL, DHCP, ARP, DNS, and TCP. When the air interface signal is interfered or poor, the sender (e.g., an electronic device) will send multiple data packets at once, for example, 100, for data packets that carry actual service data (such as listening to music, watching videos, making phone calls, etc.). Each data packet has a corresponding sequence number. After receiving multiple packets, the receiver (e.g., an application server) can identify the sequence numbers and accurately determine whether any data packets are lost or not sent. This allows the sender to promptly notify the sender, facilitating the retransmission of the missing packets. For example, if the receiver receives 99 data packets with sequence numbers ranging from 1 to 54 and 56 to 100, the receiver can accurately determine that the data packet with sequence number 55 is missing. The receiver can then promptly notify the sender of this situation, allowing the sender to resend the missing data packet with sequence number 55. In this way, even if the air interface signal is interfered with or the air interface signal is poor, it can ensure that the service data can be transmitted smoothly, allowing users to successfully complete the use of the corresponding services.

Before users use electronic devices to transmit service data packets containing real business data (such as listening to music, watching videos, making phone calls, and other business-related data), electronic devices will also generate and send signaling messages for transmitting signaling messages. This type of signaling message is responsible for completing tasks such as establishing, maintaining, and terminating network connections, as well as managing and resolving network addresses. In other words, this type of signaling message is used to ensure that users can access the Internet and then successfully use electronic devices to complete the services required by users.

For signaling messages, the sender only sends one message at a time. If the air interface signal is interfered with or poor, and the receiver fails to receive the signaling message, it cannot determine whether the sender has sent the message and cannot promptly notify the sender to resend the message. Subsequently, based on the retransmission mechanism, if the sender does not receive a response (e.g., an acknowledgment (ACK) message) from the receiver after a preset duration (retransmission interval) has passed after sending the signaling message, the sender can determine that the signaling message has failed and can resend the message. However, due to the long preset duration and the fact that the preset duration becomes longer with each successive retransmission (e.g., from 1s to 2s, 4s, etc.), users will not be able to access the Internet properly through their electronic devices if the signaling message fails to send. This can result in at least a preset duration of lag in Internet access, negatively impacting the user's Internet experience.

In the embodiment of the present application, a signaling message can be understood as a protocol message sent through only one message, and a data message can be understood as a protocol message sent through multiple messages at the same time.

To address the above issues, embodiments of the present application provide a data transmission method for use in an electronic device. In this technical solution, as shown in FIG2 , in a Wi-Fi scenario, after the electronic device receives a first protocol message generated by itself to be sent, it first parses the first protocol message to determine whether it is a signaling message of a preset protocol. The preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS, or TCP.

If the first protocol message is determined to be a signaling message of a preset protocol, the first protocol message is placed in a first transmission queue. If the first protocol message is determined not to be a signaling message, the first protocol message is placed in a second transmission queue. The first transmission queue is a VO queue, and the second transmission queue is a VI queue, a BE queue, or a BK queue.

Afterwards, the electronic device may transmit the first protocol message in the first transmission queue or the second transmission queue based on a specific queue scheduling rule, wherein the preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue.

In the technical solution provided in the present application, when sending protocol messages, the electronic device can place the signaling messages closely related to the user's Internet access in the VO queue. The VO queue is the queue with the strongest channel seizure capability for electronic devices in Wi-Fi scenarios. In this way, even if the air interface environment is not good enough (that is, the air interface signal is interfered with or the air interface signal is poor), the signaling message can be sent out more reliably (it can be understood that the receiver can receive the signaling message with a greater probability), avoiding the signaling message from being successfully sent due to the air interface environment not being good enough (it can be understood that the receiver failed to successfully receive the signaling message), resulting in the user using the electronic device to access the Internet through the Wi-Fi network. Connection jams, delays or failures, ensuring the user's experience of accessing the Internet through the Wi-Fi network.

The technical solutions provided in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

The technical solutions provided in this application can be applied to electronic devices with Wi-Fi capabilities. In some embodiments, the electronic devices can be mobile phones, tablet computers, handheld computers, personal computers (PCs), ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and/or smart city devices. The embodiments of this application do not impose any special restrictions on the specific types of the electronic devices.

For example, taking the electronic device as a mobile phone as an example, FIG3 shows a schematic structural diagram of an electronic device provided in an embodiment of the present application.

3 , the electronic device may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a display 193, a subscriber identification module (SIM) card interface 194, and a camera 195. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

The processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and/or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors. In some embodiments, the processor may include a system-on-chip (SoC).

The controller can be the nerve center and command center of the electronic device. The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (SIM) interface, and/or a universal serial bus (USB) interface.

The external memory interface 120 can be used to connect to an external non-volatile memory device to expand the storage capacity of the electronic device. The external non-volatile memory device communicates with the processor 110 via the external memory interface 120 to implement data storage. For example, files such as music and videos can be stored in the external non-volatile memory device.

Internal memory 121 may include one or more random access memories (RAMs) and one or more non-volatile memories (NVMs). RAMs can be directly read and written by processor 110 and can be used to store executable programs (e.g., machine instructions) for an operating system or other running programs, as well as user and application data. NVMs can also store executable programs and user and application data, and can be preloaded into RAMs for direct reading and writing by processor 110.

The display screen 193 is used to display images, videos, etc. The display screen 193 includes a display panel. In some embodiments, the electronic device may include 1 or N display screens 193, where N is a positive integer greater than 1.

In an embodiment of the present application, the display screen 193 can be used to display pages required by the electronic device (for example, wizard pages (including highlight recommendation pages and external module access pages), etc.), and display images captured by any one or more cameras 195 in the interface.

The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem and baseband processor.

Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in an electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

The mobile communication module 150 can provide solutions for wireless communications including 2G/3G/4G/5G, etc., applied to electronic devices. The mobile communication module 150 can receive electromagnetic waves through the antenna 1, filter, amplify, and perform other processing on the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

The wireless communication module 160 can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc. The wireless communication module 160 can be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive signals to be sent from the processor 110, frequency modulate them, amplify them, and convert them into electromagnetic waves for radiation through the antenna 2.

In some embodiments, the WiFi module in the wireless communication module 160 is used to provide the electronic device 200 with network access that complies with Wi-Fi-related standard protocols. The electronic device can access a Wi-Fi access point (AP) through the WiFi module and access the Internet. The WiFi module can also serve as a Wi-Fi wireless access point, providing Wi-Fi network access for other devices. The Bluetooth module in the wireless communication module 160 is used to enable short-range communication between the electronic device and other devices.

The WiFi module can be an integrated circuit or a WiFi chip, and the Bluetooth module can be an integrated circuit or a Bluetooth chip. The WiFi module and the Bluetooth module can each be a separate chip (FIRMWARE) or integrated circuit, or they can be integrated together. For example, in one embodiment, the WiFi module and the Bluetooth module can be integrated into the same chip. In another embodiment, the WiFi module, the Bluetooth module, and the processor can also be integrated into the same chip. The new product in which the WiFi module is located can be integrated into a system-on-a-chip (SOC) in an electronic device.

The SIM card interface 194 is used to connect a SIM card. The SIM card can be connected to and disconnected from the electronic device by inserting or removing it from the SIM card interface 194. The electronic device may support one or more SIM card interfaces. The SIM card interface 194 may support Nano SIM cards, Micro SIM cards, SIM cards, and the like. Multiple cards can be inserted into the same SIM card interface 194 at the same time. The SIM card interface 194 is also compatible with external memory cards. Electronic devices interact with the network through the SIM card to implement functions such as calls and data communications. One SIM card corresponds to one user number.

It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present invention is only a schematic illustration and does not constitute a structural limitation of the electronic device. In other embodiments of the present application, the electronic device may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

Of course, it is understood that FIG3 is merely an example of an electronic device in the form of a mobile phone. If the electronic device is a tablet computer, handheld computer, PC, PDA, wearable device (such as a smart watch, smart bracelet), or other device form factors, the structure of the electronic device may include fewer or more structures than shown in FIG3, and this is not limited here.

It is understandable that, in general, the realization of electronic device functions requires not only hardware support but also software cooperation. The software system of the electronic device can adopt a layered architecture, event-driven architecture, micro-core architecture, micro-service architecture, or cloud architecture. Taking the system as an example, the software structure of the electronic device is illustrated.

Figure 4 is a schematic diagram of the layered architecture of the software system of the electronic device provided in an embodiment of the present application. The layered architecture divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces (e.g., APIs).

In some examples, as shown in FIG4 , in an embodiment of the present application, the software system on the application processor (AP) in the system-on-chip (SOC) of an electronic device is divided into five layers: the application layer, the framework layer (or application framework layer), the system library and Android runtime (Android runtime), the HAL layer (hardware abstraction layer), and the kernel layer (or driver layer). The system library and Android runtime can also be referred to as the native framework layer or the native layer.

The application layer may include a series of applications. As shown in FIG4 , the application layer may include applications (APPs) such as camera, gallery, calendar, map, WLAN, Bluetooth, news, music, video, short message, call, navigation, and instant messaging.

In the embodiment of the present application, when an application in the application layer needs to send data, it can directly communicate with the TCP/IP protocol stack in the kernel layer through a specific communication method. Exemplarily, the communication method can be socket communication.

The framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes some predefined functions or services. For example, the application framework layer may include an activity manager, a window manager, a content provider, an audio service, a view system, a telephony manager, a resource manager, a notification manager, a package manager, etc., which are not limited in this embodiment of the application.

The window manager is used to manage window programs. The window manager can obtain the display size, determine whether there is a status bar, lock the screen, take screenshots, etc.

Content providers are used to store and retrieve data and make it accessible to applications. This data can include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

The phone manager is used to provide communication functions for electronic devices. For example, the phone manager can manage the call status of the call application (including initiation, connection, and hang up).

The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

The Notification Manager allows applications to display notifications in the status bar. These messages can be displayed briefly and then disappear automatically without user interaction. For example, the Notification Manager is used to notify users of completed downloads and message reminders. The Notification Manager can also display notifications in the top status bar of the system as icons or scrolling text, such as notifications from background applications, or as dialog windows on the screen. Examples include text messages in the status bar, beeps, vibrations on electronic devices, and flashing indicator lights.

Package Manager in The system is used to manage application packages. It allows applications to obtain detailed information about installed applications and their services, permissions, etc. The package manager is also used to manage events such as application installation, uninstallation, and upgrades.

The system library can include multiple functional modules. For example: surface manager, media libraries, open graphics library embedded systems (OpenGL ES), SGL, etc. The surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications. The media library supports playback and recording of a variety of common audio and video formats, as well as static image files. The media library can support a variety of audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc. OpenGL ES is used to implement 3D graphics drawing, image rendering, synthesis, and layer processing. SGL is a drawing engine for 2D drawing.

The Android runtime consists of the core library and the ART virtual machine. The Android runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one for the Java language's function calls and the other for the Android core library. The application layer and the application framework layer run in the ART virtual machine. The ART virtual machine executes the Java files in the application layer and application framework layer as binary files. The ART virtual machine is responsible for performing functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

The HAL layer is an interface layer located between the operating system kernel and the hardware circuit. Its purpose is to abstract the hardware. It hides the hardware interface details of a specific platform and provides a virtual hardware platform for the operating system, making it hardware-independent and portable across multiple platforms. The HAL layer provides a standard interface to display device hardware capabilities to the higher-level Java API framework (i.e., the framework layer). The HAL layer contains multiple library modules, each of which implements an interface for a specific type of hardware component, such as the audio HAL audio module, the bluetooth HAL Bluetooth module, the camera HAL camera module (also known as the camera HAL or camera hardware abstraction module), the sensors HAL sensor module (or Isensor service, sensor service), the Wi-Fi HAL (Wi-Fi module), etc.

The kernel layer is the layer between hardware and software. It contains at least various drivers and the TCP/IP protocol stack. These drivers can include display drivers, camera drivers, audio drivers, sensor drivers, battery drivers, Wi-Fi drivers, and more, though this application does not limit these.

The TCP/IP protocol stack is a collection of network communication protocols whose primary function is to ensure the correct and efficient transmission of data across a network. It provides a set of standardized protocols that enable different types of hosts, routers, and other devices to communicate and exchange data. By using the TCP/IP protocol stack, various devices can find paths between each other, exchange data, send and receive information, and ensure reliable and secure data transmission within complex networks. The TCP/IP protocol stack typically consists of multiple layers, such as the physical layer, data link layer, network layer, transport layer, and application layer. Each layer has specific functions, such as the network layer responsible for addressing and routing, and the transport layer responsible for data segmentation and transmission control.

For example, the transport layer in a TCP/IP protocol stack typically includes a TCP/UDP (user datagram protocol) protocol stack; the network layer in a TCP/IP protocol stack may include an IP protocol stack. The TCP/UDP protocol stack is responsible for data transmission at the transport layer. The transport layer is primarily responsible for breaking application layer data into smaller data blocks and passing these blocks to the network layer for reliable transmission across the network. The IP protocol stack is responsible for the network layer, which is the foundation of data transmission on the internet. The IP protocol stack uses IP addresses to identify and address devices on the network, thereby routing data between different network nodes.

When an electronic device needs to access the Internet through a Wi-Fi network, different protocol messages (including data messages and signaling messages) will be generated through the TCP/IP protocol stack to achieve the purpose of accessing the Internet.

For example, the business data that needs to be sent by various applications in the application layer will first be encapsulated by the TCP/IP protocol stack, and then sent through the Wi-Fi driver to control the Wi-Fi chip.

For another example, to enable an electronic device to access the Internet, the TCP/IP protocol stack may generate signaling messages during EAPOL interaction, signaling messages during DHCP interaction, signaling messages during ARP interaction, signaling messages during DNS interaction, and signaling messages during TCP interaction. Signaling messages in each interaction process may be generated by one or more layers of the TCP/IP protocol stack, depending on actual circumstances, and this application does not impose any specific restrictions on this.

When an electronic device uses a Wi-Fi network to access the Internet in a Wi-Fi scenario, when the TCP/IP protocol stack generates a protocol message, the TCP/IP protocol stack sends the message to the Wi-Fi driver, so that the Wi-Fi driver sends the protocol message to the corresponding recipient.

The Wi-Fi driver is used to drive the Wi-Fi module (or Wi-Fi chip) to establish a Wi-Fi connection so that the electronic device can access the Internet through the Wi-Fi network.

In an embodiment of the present application, the Wi-Fi driver may include a message parsing module, a queue allocation module and a data sending module. Among them, the message parsing module is used to parse the protocol message from the TCP/IP protocol stack, and determine whether the protocol message is a signaling message of the preset protocol based on the parsing result. The queue allocation module is used to allocate queues to the protocol messages from the TCP/IP protocol stack according to the judgment of the message parsing module on the parsing result. Specifically, when the message parsing module determines that the protocol message is a signaling message of the preset protocol, the queue allocation message allocates the protocol message to the VO queue; when the message parsing module determines that the protocol message is not a signaling message of the preset protocol, the queue allocation message allocates the protocol message to a transmission queue other than the VO queue. Afterwards, the data sending module can send the protocol message according to a specific queue message sending rule based on the allocation result of the queue allocation message to the protocol message.

It should be noted that although the embodiment of the present application is described using the Android system as an example, its basic principles are also applicable to Electronic devices running iOS, Windows, and other operating systems.

The technical solutions provided in the embodiments of this application can be implemented in electronic devices having the above-mentioned hardware architecture or software architecture.

In a Wi-Fi scenario, if an electronic device needs to access the Internet through a Wi-Fi network, it must complete the following five signaling interaction processes:

(1) First, it is necessary to establish a valid Wi-Fi connection with the AP that provides the Wi-Fi network. During this process, the electronic device needs to complete the EAPOL interaction process with the AP to complete identity authentication. If the user's network environment is very poor (i.e., the air interface signal is interfered with or the air interface signal is poor), the electronic device fails to successfully send the signaling message that needs to be sent to the AP during the EAPOL interaction process, and identity authentication cannot be completed. The electronic device will also be unable to access the Internet through the AP.

(2) After establishing a Wi-Fi connection with the AP, the electronic device needs to complete the DHCP interaction process with the AP and the DHCP server to obtain the IP address assigned to the electronic device and the IP address of the gateway. DHCP is an important protocol for obtaining the IP of a mobile phone. Normally, the signaling message sent by the DHCP server - DHCP OFFER (DHCP offer) provides the IP to the electronic device. If the user's network environment is very poor (that is, the air interface signal is interfered with or the air interface signal is poor), the DHCP server does not receive the DHCP DISCOVER (DHCP discovery) signaling message sent by the electronic device. Then, the electronic device is in a state of no IP before resending the signaling message based on the retry mechanism, and is completely unable to access the Internet. After that, before the electronic device sends the signaling message again a few seconds later, the Wi-Fi network will be unusable because there is no IP.

Furthermore, if the DHCP server does not receive the DHCP REQUEST signaling message sent by the electronic device, it cannot confirm the IP address selected by the electronic device, resulting in a failure in IP allocation or renewal, and the electronic device will be unable to use the IP address to access the Internet. Specifically, this situation will cause the user's Internet access to be stuck on the loading page. If the application does not have a retry mechanism, the Internet access will fail.

(3) After the electronic device obtains its own IP address and the IP address of the gateway, considering that the electronic device accesses the Internet through the Wi-Fi network, it must forward the corresponding message to the gateway in the Wi-Fi local area network. The data transmission in the Wi-Fi local area network is through the data link layer, so at this time the electronic device needs to obtain the MAC address of the gateway through ARP interaction to facilitate the subsequent forwarding of the data to the Internet by the gateway. If the user's network environment is very poor (that is, the air interface signal is interfered with or the air interface signal is poor), the ARP request message sent by the electronic device is not received by the gateway for a long time, which will cause the ARP table on the mobile phone to age. After that, the electronic device will not be able to send any protocol message to the gateway, resulting in the user being completely unable to access the Internet.

(4) After the electronic device obtains the MAC address of the network manager, it can start to access the Internet through the Wi-Fi network. At this time, the electronic device can start to access the Internet in response to the user's operation on a certain application or the domain name entered in the browser. When the electronic device accesses the Internet, it mainly needs to establish a TCP connection with a specific application server to exchange data and then provide data for the user to view. The establishment of a TCP connection requires knowing the IP address of the application server (i.e., the destination IP). Therefore, at this time, the electronic device needs to obtain the domain name of the application or the IP address corresponding to the domain name entered by the user through DNS interaction with the DNS service. The IP address corresponding to the domain name is the IP address of the application server. During the DNS interaction process, the electronic device will first send a DNS request message, a signaling message carrying a domain name, to the DNS server. Only when the DNS server returns the request result (i.e., the IP address corresponding to the domain name) can the corresponding website/webpage be accessed. If the user's network environment is very poor (i.e., the air interface signal is interfered with or the air interface signal is poor), the DNS request message will be lost at the air interface, and the Internet access behavior will fail, and the phenomenon is that the website/webpage cannot be opened.

(5) After the electronic device obtains the IP address of the application server, it can complete the establishment of a TCP connection (or TCP stream) through TCP interaction with the application server. After the TCP connection is established, the electronic device can normally exchange data with the application server to achieve the purpose of Internet access. During the TCP interaction process, the electronic device and the TCP server will establish a TCP connection through a three-way handshake. Among them, the Transmission Control Protocol Synchronization Sequence Number (TCP SYN) message is the first handshake message. If the user's network environment is very poor (that is, the air interface signal is interfered or the air interface signal is poor), resulting in the loss of the signaling message, the TCP server will be completely unable to perceive that there is an electronic device trying to access. After that, it can only passively initiate the retransmission of the TCP SYN message through the electronic device to recover. Under normal circumstances, the retransmission time interval of the TCP SYN message is 1->2->4s, which means that the loss of the TCP SYN message will cause at least 1s of connection lag.

In addition, if the third handshake message (or ACK message) is not successfully sent to the TCP server, and the third handshake message does not carry business data, TCP will not be able to promptly perceive that the third handshake message has not been successfully sent. Then, the TCP server will wait for a period of time (usually several retransmission timeouts). If it still does not receive an ACK message from the client during this period, the server will consider that the TCP connection establishment has failed and disconnect the TCP connection. At this point, the TCP connection establishment process will fail, communication between the electronic device and the TCP server will not be possible, and the user will not be able to access the Internet.

Based on the above description, the data transmission method provided by the present application may include five corresponding processes, which may be: EAPLO data transmission process, DHCP data transmission process, ARP data transmission process, DNS data transmission process and TCP data transmission process. Based on the software architecture shown in FIG4 above, the EAPLO data transmission process in the data transmission method provided by the embodiment of the present application is introduced below in conjunction with FIG5. FIG5 is a schematic diagram of the EAPLO data transmission process provided by the embodiment of the present application. Referring to FIG5, taking the electronic device (i.e., the client STA (station)) as a mobile phone and the AP as a router as an example, the EAPLO data transmission process may include S501-S516:

S501. The router sends the first handshake message to the mobile phone.

The first handshake message Messag1 may be an EAPOL-Key message including ANonce. The EAPOL-Key message may carry a random string -ANonce generated by the router. During the EAPOL interaction process, the mobile phone interacting with the router may also be referred to as a station STA.

It should be noted that before the EAPOL interaction process begins, the mobile phone, acting as a STA, has already established a Wi-Fi network connection with the router. This connection is typically established through the Association Request/Response (Assoc Req/Rsp) process, after probing and authenticating. An Association Request is a request sent by the STA (i.e., the mobile phone) to the AP (i.e., the router) to establish an association with a specific Basic Service Set Identifier (BSSID). The mobile phone sends an Association Request message to indicate its presence to the router and request to join the wireless network. The BSSID is the router's identifier. Before sending the Association Request, the STA obtains a pre-shared key (PSK). In some embodiments, the PSK is set by the user when configuring the router's Wi-Fi network. For example, the PSK can be the password a user enters when accessing the Wi-Fi network via their mobile phone.

An Association Response is the router's response to a phone's Association Request. Upon receiving the Association Request, the router decides whether to accept the phone's association request based on factors such as network policy and available resources. If accepted, the router sends an Association Response to the phone, which contains an indication of successful association and parameters assigned to the phone, such as the authenticator address (AA) and supported data rates.

S502: The Wi-Fi chip of the mobile phone receives the first handshake message from the router, and sends the first handshake message to the TCP/IP protocol stack through the Wi-Fi driver.

S503: The TCP/IP protocol stack of the mobile phone generates a first message based on the ANonce carried in the first handshake message and sends the first message to the Wi-Fi driver.

Specifically, after receiving the first handshake message, the TCP/IP protocol stack will calculate the key (pairwise transient key, PTK) for data encryption during subsequent communications between the mobile phone and the router based on a preset algorithm.

Exemplarily, the preset algorithm may be a pseudo-random function (PRF) algorithm. Specifically, PTK = PRF (Snonce + Anonce + PMK + AA + SA).

Among them, Snonce is a random number generated by the TCP/IP protocol stack, AA is the MAC address of the router (as the authenticator), SA (supplicant address) is the MAC address of the mobile phone (as the supplicant), and PMK (pairwise master key) is generated by the TCP/IP protocol stack based on PSK and BSSID (the generation method is not limited).

In addition, after receiving the first handshake message, the TCP/IP protocol stack uses the HMAC_MD5 hash function to calculate the message integrity code (MIC). Specifically, the MIC key is used as the key to hash the 802.1x data and output the 16-bit MIC1(sta) value, i.e., MIC1(sta) = HMAC_MD5(MIC key, 16, 802.1x data).

The MIC key is determined during the authentication process between the mobile phone and the router before the EAPOL interaction. In some embodiments, the MIC key can be the first 16 bytes of the PTK.

802.1x data refers to the data used to calculate MIC1(sta), which usually includes a handshake message - the content of the EAPOL-Key message carrying Anonce, the MAC address of the STA (i.e., the mobile phone), the BSSID of the router, and other information.

The first message finally generated by the TCP/IP protocol stack may be referred to as the second handshake message Message2, and specifically may be an EAPOL-Key message carrying Snonce and MIC1(sta).

S504: The Wi-Fi driver of the mobile phone parses the first message and determines whether the first message is a signaling message of a preset protocol based on the parsing result.

The Wi-Fi driver may parse the first message in any feasible manner. The preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS or TCP, and the same applies to the subsequent embodiments.

By parsing the first message, the Wi-Fi driver can determine the specific protocol message of the first message and the number of the protocol message interaction process, i.e., the parsing result. For example, after parsing the first message, it can be determined that the first message is an EAPOL protocol message and is an EAPOL protocol message in the second handshake of the EAPOL four-way handshake interaction process.

When the Wi-Fi driver determines that the first message is a signaling message of a preset protocol, it can be considered that the receiving method cannot promptly determine whether the first message is received. Once the first message is lost, it is necessary to wait for the sender to retransmit it based on the retransmission mechanism after a long time.

During this waiting time, the user cannot access the Internet normally. In other words, the reliable transmission of the first message has a significant impact on whether the user can access the Internet normally. Based on this, in order to ensure that the first message, which has a significant impact on the user's Internet access, is reliably transmitted and that the user can access the Internet normally through the Wi-Fi network, the first message can be placed in the VO queue, that is, S505 is executed.

If the Wi-Fi driver determines that the first message is not a signaling message, then even if the first message is lost, the receiver can still detect it and notify the sender to resend it, without causing the user's Internet access to stall. Based on this, in this case, the first message can be placed in a transmission queue other than the VO queue (e.g., the BE queue, the VI queue, or the BK queue), that is, executing S506.

S505: The Wi-Fi driver of the mobile phone puts the first message into the VO queue.

In this application, the VO queue may be referred to as a first priority transmission queue. The same applies to the subsequent embodiments.

S506: The Wi-Fi driver of the mobile phone puts the first message into a transmission queue other than the VO queue.

In this application, the transmission queue other than the VO queue can be referred to as the second priority transmission queue. The second priority transmission queue is different from the first priority transmission queue. The same applies to the subsequent embodiments.

Exemplarily, the Wi-Fi driver of the mobile phone may place the first message that is not a signaling message of the preset protocol in the BE queue.

Of course, it should be noted that, since the four-way handshake messages between the mobile phone and the router during the EAPOL four-way handshake are all signaling messages of the preset protocol, that is, each handshake message is a data message that the receiver cannot promptly determine has not been received when it is missing, and is strongly related to the user's ability to access the Internet normally. Therefore, based on the parsing result of the first message, the Wi-Fi driver can determine that the first message is a signaling message of the preset protocol. Therefore, S506 will not be executed in practice. The description of S506 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S507: The Wi-Fi driver of the mobile phone sends the first message to the router through the Wi-Fi chip according to the preset queue message sending rule.

The preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue.

S508: The router receives the first message from the mobile phone, and generates a third handshake message based on the SNonce and MIC1(sta) carried in the first message.

After receiving the first message, the router can generate a PTK and MIC1(ap) in the same way as the mobile phone generates the PTK and MIC(sta). If MIC1(sta) and MIC1(ap) are the same, the PTK calculated by the router can be determined to be correct. If MIC1(sta) and MIC1(ap) are different, it can be assumed that the PTK calculated by the mobile phone and the PTK calculated by the router are different. The router can then discard the first message and return an authentication failure message to the mobile phone, ending the entire EAPOL interaction process.

If MIC1(sta) and MIC1(ap) are identical, the router can generate a group temporal key (GTK) based on the group master key (GMK), Anonce, and AA. The generation method is not limited and this application does not impose any specific restrictions on this.

The GMK may be calculated based on secret information pre-configured by the router, authentication credentials, or other security factors. This application does not impose any specific restrictions on this.

To protect message integrity and verify the authenticity of the message for the mobile phone, the router can also use the first 16 bytes of the PTK and the first message to generate MIC2 (ap). The specific generation method can refer to the generation method of MIC1 (ap).

In addition, to prevent key leakage, the router can also encrypt the GTK using a preset encryption method and generate a third handshake message Message3 carrying MIC2(ap) and the encrypted GTK. The third handshake message can specifically be an EAPOL-Key message carrying MIC2(ap) and the encrypted GTK. Exemplarily, the preset encryption method can be to use the middle 16 bytes of the PTK to encrypt the GTK using any feasible encryption method (such as counter cipher mode with block chaining message authentication code protocol (CCMP)).

S509: The router sends a third handshake message to the mobile phone.

S510: The Wi-Fi chip of the mobile phone receives the third handshake message from the router, and sends the third handshake message to the TCP/IP protocol stack through the Wi-Fi driver.

S511. The TCP/IP protocol stack of the mobile phone decrypts the encrypted GTK carried in the third handshake message, installs the PTK and GTK, generates a second message, and sends the second message to the Wi-Fi driver.

Specifically, after receiving the third handshake message, the TCP/IP protocol stack first generates MIC2(sta) in the same way as the router generates MIC2(ap), and then determines whether MIC2(sta) is the same as MIC2(ap).

If MIC2(sta) and MIC2(ap) are the same, the third handshake message can be considered unmodified and the GTK calculated by the router is correct. The mobile phone can then use the PTK to decrypt the encrypted GTK to obtain the GTK, install the PTK and GTK, and generate the second message. If MIC2(sta) and MIC2(ap) are different, the third handshake message can be considered modified or the GTK calculated by the router is incorrect. The third handshake message can be discarded and an authentication failure message can be returned to the router, ending the entire EAPOL interaction process.

Installing the PTK and the GTK may refer to subsequently using the PTK to encrypt unicast data frames between the mobile phone and the router, and using the GTK to encrypt multicast data frames and broadcast data frames between the mobile phone and the router.

The second message can be the fourth handshake message, Message 4, specifically an EAPOL-Key Ack message carrying an ACK and MIC3(sta). The mobile phone can use the first 16 bytes of the PTK and the third handshake message to generate MIC3(sta). The specific generation method can refer to the generation method of MIC1(sta).

S512: The Wi-Fi driver of the mobile phone parses the second message, and determines whether the second message is a signaling message of a preset protocol based on the parsing result.

The Wi-Fi driver may parse the second message in any feasible manner. By parsing the second message, the Wi-Fi driver may determine the specific protocol message of the second message and the number of the protocol message interaction process, i.e., the parsing result. For example, after parsing the second message, it may be determined that the second message is an EAPOL protocol message and is the fourth EAPOL protocol message in the EAPOL protocol message interaction process.

In the case where the Wi-Fi driver determines that the second message is a signaling message of a preset protocol, it can be considered that the receiving method cannot promptly determine whether the second message is received. Once the second message is lost, it is necessary to wait for the sender to retransmit it based on the retransmission mechanism after a long time. During this waiting time, the user cannot access the Internet normally. In other words, the reliable transmission of the second message has a greater impact on whether the user can access the Internet normally. Based on this, in order to ensure that the second message that has a greater impact on the user's Internet access is reliably sent and that the user can access the Internet normally through the Wi-Fi network, the second message can be placed in the VO queue, that is, S513 is executed.

If the Wi-Fi driver determines that the second message is not a signaling message for the preset protocol, then even if the second message is lost, the receiver can promptly detect it and notify the sender to resend it, without causing the user's Internet access to stall. Based on this, in this case, the second message can be placed in a transmission queue other than the VO queue (e.g., the BE queue, the VI queue, or the BK queue), executing S514.

S513: The Wi-Fi driver of the mobile phone puts the second message into the VO queue.

S514: The Wi-Fi driver of the mobile phone puts the second message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the second message that is not a signaling message of the preset protocol in the BE queue.

Of course, it should be noted that, since the four-way handshake messages between the mobile phone and the router during the EAPOL four-way handshake are all single signaling messages, the Wi-Fi driver can determine that the second message is a signaling message of the preset protocol based on the parsing result of the second message. Therefore, S514 will not be executed in practice. The description of S514 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S515 : The Wi-Fi driver of the mobile phone sends the second message to the router through the Wi-Fi chip according to the preset queue message sending rule.

S516. When the router receives the second message from the mobile phone, it installs GTK and PTK.

Specifically, after receiving the second message, the router first generates MIC3(ap) in the same manner as the mobile phone generates MIC3(ap), and then determines whether MIC3(sta) and MIC3(ap) are the same.

If MIC3(sta) and MIC3(ap) are the same, it can be assumed that the second message has not been modified and the mobile phone has successfully installed the PTK and GTK. The router can then install the PTK and GTK and end the entire EAPOL interaction process. If MIC3(sta) and MIC3(ap) are different, it can be assumed that the second message has been modified or the mobile phone has failed to successfully install the PTK and GTK. The router can then discard the second message and return an authentication failure message to the mobile phone, ending the entire EAPOL interaction process.

It should be noted that, in practice, the electronic device and AP performing EAPOL may also be other devices. In the case of other devices, the implementation method is the same as the above process, and this application does not limit or elaborate on this.

Based on the aforementioned EAPOL data transmission process, the mobile phone can place all EAPOL signaling messages in the first-priority transmission queue with a higher transmission priority, such as the VO queue, for transmission. In Wi-Fi scenarios, the highest priority transmission queue is used, and messages in this queue have a stronger ability to seize the channel and a higher transmission success rate. This allows signaling messages placed in the first-priority transmission queue in the EAPOL data transmission process to be transmitted more reliably (i.e., with interference or poor signal quality), even in less-than-optimal air interface conditions (i.e., with a higher probability of successful reception at the receiver), allowing the mobile phone and router to successfully complete the EAPOL data transmission process. This prevents signaling messages for the pre-defined protocol from being successfully transmitted (i.e., with the receiver failing to receive the message) due to a less-than-optimal air interface condition, which could result in connection freezes, delays, or failures when the user uses the electronic device to access the internet via the Wi-Fi network. The mobile phone can then proceed to the subsequent internet access process through the router, ensuring a smooth internet access experience, ensuring a better Wi-Fi experience.

After the mobile phone completes the EAPOL data transmission process, it can start interacting with the DHCP server to obtain its own available IP address and the IP address of the gateway in the Wi-Fi LAN, so as to facilitate subsequent Internet access based on the IP address.

Based on the software architecture shown in FIG4 above, the DHCP data transmission process in the data transmission method provided by the embodiment of the present application is introduced below in conjunction with FIG6. FIG6 is a schematic diagram of the DHCP data transmission process provided by the embodiment of the present application. Referring to FIG6, taking the electronic device (acting as a DHCP client) as a mobile phone as an example, the DHCP data transmission process may include S601-S618:

S601: The TCP/IP protocol stack of the mobile phone generates a third message and sends the third message to the Wi-Fi driver.

The third message may be a DHCP DISCOVER message. The DHCP DISCOVER message may carry information such as the MAC address of the mobile phone and is used to request an IP address.

After the mobile phone connects to the Wi-Fi network and completes the EAPOL data transmission process, the TCP/IP protocol stack can generate a DHCP Discover message.

S602: The Wi-Fi driver of the mobile phone parses the third message and determines whether the third message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the third message is a signaling message of a preset protocol based on the parsing result of the third message, the third message may be put into a VO queue for sending, that is, S603 is executed.

If the Wi-Fi driver determines that the third message is not a signaling message of the preset protocol based on the parsing result of the third message, the third message may be placed in a transmission queue other than the VO queue for sending, that is, S604 is executed.

The specific implementation of S602 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S603: The Wi-Fi driver of the mobile phone puts the third message into the VO queue.

S604: The Wi-Fi driver of the mobile phone puts the third message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the third message that is not a signaling message of the preset protocol in the BE queue.

Of course, it should be noted that, since the interactive messages between the mobile phone and the DHCP server are all signaling messages of the preset protocol during the process of obtaining an IP address through the DHCP server, that is, each interactive DHCP protocol message is a data message that the recipient cannot promptly determine has not been received when it is missing, and is strongly related to the user's ability to access the Internet normally. Therefore, based on the parsing result of the third message, the Wi-Fi driver here can determine that the third message is a signaling message of the preset protocol. Therefore, S604 will not be executed in practice. The description of S604 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S605: The Wi-Fi driver of the mobile phone sends the third message to the DHCP server through the Wi-Fi chip according to the preset queue message sending rule.

In some embodiments, the Wi-Fi driver may send the third message in the broadcast domain of the Wi-Fi network through the Wi-Fi chip, so that the DHCP server can receive the third message.

In some embodiments, the DHCP server may be pre-installed in a router that provides a Wi-Fi network, or may be a device connected to the router in a Wi-Fi local area network. If the DHCP server and the router are different devices, the Wi-Fi chip may send the third message to the router, which then sends it to the DHCP server.

S606. The DHCP server receives a third message from the mobile phone, selects an unassigned first IP address from the IP address pool in response to the third message, and generates a DHCP OFFER message carrying the first IP address.

In some embodiments, the DHCP OFFER message may also carry information such as the lease term of the first IP address, the subnet mask, the IP address of the gateway, and the IP address of the DNS server. The lease term of the first IP address refers to the time during which the first IP address can be used. After the lease term of the first IP address expires, the mobile phone needs to renew the use of the first IP address or reapply for a new IP address.

S607. The DHCP server sends the DHCP OFFER message to the mobile phone.

In one possible implementation, the DHCP server can send the DHCP Offer message in the broadcast domain of the Wi-Fi network. After sending the third message, the mobile phone can obtain the DHCP Offer message by monitoring the broadcast address (i.e., monitoring messages in the broadcast domain).

In another possible implementation, the DHCP server unicasts the DHCP Offer message to the mobile phone. Specifically, the DHCP server can use the mobile phone's MAC address or other identifier carried in the third message to unicast the DHCP Offer message to the mobile phone.

In some embodiments, if the DHCP server and the router are different devices connected in the Wi-Fi network, the DHCP server can specifically send the DHCP OFFER message to the mobile phone through the router.

S608. The Wi-Fi chip of the mobile phone receives the DHCP OFFER message from the DHCP server and sends the DHCP OFFER message to the TCP/IP protocol stack through the Wi-Fi driver.

S609. The TCP/IP protocol stack of the mobile phone applies the first IP address carried in the DHCP OFFER message to the network configuration of the mobile phone and generates a fourth message.

Applying the first IP address to the mobile phone's network configuration refers to configuring the first IP address as the mobile phone's IP address. Furthermore, the TCP/IP protocol stack is used to apply information such as the lease period of the first IP address, subnet mask, gateway IP address, and DNS server IP address carried in the DHCP OFFER message to the mobile phone's network configuration in a similar manner.

Of course, in practice, after receiving the DHCP OFFER message, the TCP/IP protocol stack will also determine whether the first IP address is valid through any available method. If the first IP address is determined to be valid, the TCP/IP protocol stack will apply the first IP address to the phone's network configuration and generate the fourth message. If the first IP address is determined to be invalid, the phone can perform any available processing action, such as resending a DHCP DISCOVER message to the DHCP server.

The fourth message may specifically be a DHCP REQUEST message. The DHCP REQUEST message is used to instruct the mobile phone to accept the first IP address assigned by the DHCP server.

S610: The TCP/IP protocol stack of the mobile phone sends a fourth message to the Wi-Fi driver.

S611: The Wi-Fi driver of the mobile phone parses the fourth message, and determines whether the fourth message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the fourth message is a signaling message of a preset protocol based on the parsing result of the fourth message, the fourth message may be placed in a VO queue for sending, ie, S612 is executed.

When the Wi-Fi driver determines that the fourth message is not a signaling message of the preset protocol based on the parsing result of the fourth message, the fourth message may be placed in a transmission queue other than the VO queue for sending, that is, S613 is executed.

The specific implementation of S611 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S612: The Wi-Fi driver of the mobile phone puts the fourth message into the VO queue.

S613: The Wi-Fi driver of the mobile phone puts the fourth message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the fourth message, which is not a signaling message of the preset protocol, in the BE queue.

Of course, it should be noted that, since the interactive messages between the mobile phone and the DHCP server are all signaling messages of the preset protocol during the process of obtaining an IP address through the DHCP server, that is, each interactive DHCP protocol message is a data message that the recipient cannot promptly determine if it has not received when it is missing, and it is strongly related to whether the user can access the Internet normally. Therefore, based on the parsing result of the fourth message, the Wi-Fi driver here can determine that the fourth message is a signaling message of the preset protocol. Therefore, S613 will not be executed in practice. The description of S613 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S614: The Wi-Fi driver of the mobile phone sends the fourth message to the DHCP server through the Wi-Fi chip according to the preset queue message sending rule.

In some embodiments, the Wi-Fi driver may send the fourth message in the broadcast domain of the Wi-Fi network through the Wi-Fi chip, so that the DHCP server can receive the fourth message.

In some embodiments, the DHCP server may be pre-installed in a router that provides a Wi-Fi network, or may be a device connected to the router in a Wi-Fi local area network. If the DHCP server and the router are different devices, the Wi-Fi chip may send the fourth message to the router, which then sends it to the DHCP server.

In other embodiments, if the mobile phone has acquired the IP address of the DHCP server in advance, the Wi-Fi chip may send the fourth message to the DHCP server in a unicast manner.

S615. The DHCP server receives the fourth message from the mobile phone and generates a DHCP ACK message in response to the fourth message.

Among them, the DHCP ACK message is used to indicate that the mobile phone can start using the first IP address.

S616. The DHCP server sends a DHCP ACK message to the mobile phone.

S617. The Wi-Fi chip of the mobile phone receives the DHCP ACK message from the DHCP server and sends the DHCP ACK message to the TCP/IP protocol stack through the Wi-Fi driver.

S618. The TCP/IP protocol stack of the mobile phone responds to the DHCP ACK message and starts using the first IP address.

In some embodiments, since the first IP address obtained by the mobile phone through the DHCP server has a lease period, to ensure that the mobile phone can normally use the first IP address, the mobile phone may further send a fifth message (specifically, a DHCP REQUEST (renew) message) to the DHCP server to extend the lease period of the first IP address when the mobile phone starts using the first IP address and reaches a preset percentage of the lease period of the first IP address. The DHCP REQUEST (renew) message also belongs to the DHCP REQUEST message. Exemplarily, the preset percentage may be 50%.

If the DHCP server agrees to extend the lease of the first IP address, it may send a DHCP ACK (renew) message to the mobile phone, indicating that the lease of the first IP address can be extended by a preset time period. After receiving the DHCP ACK (renew) message, the mobile phone can extend the lease of the first IP address by the preset time period and continue to use the first IP address for Internet access.

The above-mentioned interactive process of extending the lease term of the first IP address can refer to the relevant descriptions of S609-S616 in the aforementioned embodiment, and will not be repeated here.

Based on the above DHCP data transmission process, the mobile phone can place all DHCP-related signaling messages in a first-priority transmission queue with a high transmission priority, such as a VO queue, for transmission. In Wi-Fi scenarios, the highest transmission priority transmission queue is used, as messages in this queue have a stronger ability to seize channels and a higher transmission success rate. This allows the mobile phone and the DHCP server to successfully complete the DHCP data transmission process, even if the air interface environment is poor (i.e., the air interface signal is interfered with or the air interface signal is poor). This prevents signaling messages for the preset protocol placed in the first-priority transmission queue during the DHCP data transmission process from being sent out more reliably (this can be understood as the probability of the receiver successfully receiving the signaling message being higher). This prevents signaling messages for the preset protocol from being successfully sent due to poor air interface conditions (this can be understood as the receiver failing to successfully receive the signaling message), which could cause connection freezes, delays, or failures when the user uses the electronic device to access the Internet via a Wi-Fi network. The mobile phone can then proceed to the subsequent Internet access process based on the first IP address assigned to the mobile phone and the network administrator's IP address obtained through this process, thereby smoothly accessing the Internet and ensuring a good user experience.

After the mobile phone completes the DHCP data transmission process, the mobile phone can start using the first IP address and the IP address of the gateway to obtain the MAC address of the network manager to facilitate subsequent sending of data to the Internet through the gateway.

Based on the software architecture shown in FIG4 above, the ARP data transmission process in the data transmission method provided by the embodiment of the present application is introduced below in conjunction with FIG7. FIG7 is a schematic diagram of the ARP data transmission process provided by the embodiment of the present application. Referring to FIG7, taking the electronic device as a mobile phone and the gateway as a router as an example, the ARP data transmission process may include S701-S709:

S701. The TCP/IP protocol stack of the mobile phone generates a sixth message and sends the sixth message to the Wi-Fi driver.

The sixth message may be an ARP request message, which may carry the IP address of the gateway, the MAC address of the mobile phone, and the IP address of the mobile phone; the ARP request message is used to request the MAC address of the gateway.

S702: The Wi-Fi driver of the mobile phone parses the sixth message, and determines whether the sixth message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the sixth message is a signaling message of a preset protocol based on the parsing result of the sixth message, the sixth message may be placed in a VO queue for sending, ie, S703 is executed.

When the Wi-Fi driver determines that the sixth message is not a signaling message of the preset protocol based on the parsing result of the sixth message, the sixth message may be placed in a transmission queue other than the VO queue for sending, that is, S704 is executed.

The specific implementation of S702 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S703: The Wi-Fi driver of the mobile phone puts the sixth message into the VO queue.

S704: The Wi-Fi driver of the mobile phone puts the sixth message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the sixth message, which is not a signaling message of the preset protocol, in the BE queue.

Of course, it should be noted that, since the ARP request message is a signaling message of a preset protocol when the mobile phone obtains the MAC address of the router through the router acting as a gateway, the Wi-Fi driver can determine that the sixth message is a signaling message of a preset protocol based on the parsing result of the sixth message. Therefore, S704 will not be executed in practice. The description of S704 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S705 : The Wi-Fi driver of the mobile phone sends the sixth message to the router through the Wi-Fi chip according to the preset queue message sending rule.

In some embodiments, the Wi-Fi driver may send the sixth message in the broadcast domain of the Wi-Fi network through the Wi-Fi chip, so that a router serving as a gateway can receive the sixth message.

Specifically, the implementation of the router serving as the gateway receiving the sixth message may refer to the relevant description of FIG. 1 in the aforementioned implementation, which will not be repeated here.

In some embodiments, the gateway may also be other devices connected to the router in the Wi-Fi local area network, such as an optical modem. In this case, the Wi-Fi chip may send the sixth message to the router, which then sends the message to the optical modem via the broadcast domain.

S706: The router receives the sixth message from the mobile phone, and generates an ARP response message carrying the MAC address of the router in response to the sixth message.

When the router serving as the network manager determines that the IP address of the network manager carried in the sixth message is the same as its own IP address, it may generate an ARP response message carrying the MAC address of the router.

S707: The router sends an ARP response message to the mobile phone.

In some embodiments, the router unicasts the ARP response message to the mobile phone. Specifically, the router can achieve the purpose of unicasting the ARP response message to the mobile phone by using the MAC address and IP address of the mobile phone or other identifiers used to identify the mobile phone carried in the sixth message.

S708. The Wi-Fi chip of the mobile phone receives the ARP response message from the router, and sends the ARP response message to the TCP/IP protocol stack through the Wi-Fi driver.

S709: The TCP/IP protocol stack of the mobile phone generates a mapping between the MAC address of the router carried in the ARP response message and the IP address of the gateway, and stores the mapping in the ARP table entry.

After the mapping of the gateway's MAC address and IP address exists in the ARP table, the mobile phone can accurately send messages that need to be forwarded to the Internet to the gateway in the Wi-Fi LAN, and then the gateway forwards the messages to the Internet, ensuring that the mobile phone can access the Internet smoothly.

Based on the aforementioned ARP data transmission process, the mobile phone can place all signaling messages corresponding to ARP in a first-priority transmission queue with a high transmission priority, such as the VO queue, for transmission. In Wi-Fi scenarios, messages in queues with a high transmission priority have a stronger ability to seize channels and a higher transmission success rate. This allows the signaling messages of the preset protocol placed in the first-priority transmission queue during the ARP data transmission process to be transmitted more reliably (this can be understood as a higher probability of the receiver successfully receiving the signaling message), even if the air interface environment is not optimal (i.e., the air interface signal is interfered with or the air interface signal is poor). This allows the mobile phone and the router to successfully complete the ARP data transmission process. The mobile phone can then proceed to the subsequent Internet access process based on the MAC address of the router acting as a gateway obtained through this process, thereby smoothly accessing the Internet. This prevents signaling messages of the preset protocol from being successfully transmitted due to an inadequate air interface environment (this can be understood as the receiver failing to successfully receive the signaling message), resulting in connection lag, delays, or failures when the user uses the electronic device to access the Internet via a Wi-Fi network, thereby ensuring the user's Internet experience.

After the mobile phone completes the ARP data transmission process, it can start responding to the user's operation of entering a domain name in the browser or opening an application, and obtain the IP address of the corresponding domain name, thereby facilitating the subsequent establishment of a TCP connection with the application server, so as to smoothly access the Internet.

Based on the software architecture shown in FIG4 above, the ARP data transmission process in the data transmission method provided by the embodiment of the present application is introduced below in conjunction with FIG8. FIG8 is a schematic diagram of the ARP data transmission process provided by the embodiment of the present application. Referring to FIG8, taking the electronic device as a mobile phone and the gateway as a router as an example, the ARP data transmission process may include S801-S809:

S801. The TCP/IP protocol stack of the mobile phone generates a seventh message and sends the seventh message to the Wi-Fi driver.

The seventh message may be a DNS request message. The ARP request message may carry a target domain name, such as www.example.com. The DNS request message is used to request the IP address corresponding to the domain name.

The target domain name can be a domain name entered by the user in the browser, or it can be a domain name transmitted by the application to the TCP/IP protocol stack when the user triggers an application to open. This application does not make specific restrictions on this.

S802: The Wi-Fi driver of the mobile phone parses the seventh message and determines whether the seventh message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the seventh message is a signaling message of a preset protocol based on the parsing result of the seventh message, the seventh message may be put into the VO queue for sending, ie, S803 is executed.

When the Wi-Fi driver determines that the seventh message is not a signaling message of the preset protocol based on the parsing result of the seventh message, the seventh message may be placed in a transmission queue other than the VO queue for sending, that is, S804 is executed.

The specific implementation of S802 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S803: The Wi-Fi driver of the mobile phone puts the seventh message into the VO queue.

S804. The Wi-Fi driver of the mobile phone puts the seventh message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the seventh message, which is not a signaling message of the preset protocol, in the BE queue.

Of course, it should be noted that, since the DNS request message is a signaling message of the preset protocol when the mobile phone obtains the MAC address of the router through the router acting as a gateway, the Wi-Fi driver can determine that the seventh message is a signaling message of the preset protocol based on the parsing result of the seventh message. Therefore, S804 will not be executed in practice. The description of S804 in the embodiment of this application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S805 : The Wi-Fi driver of the mobile phone sends the seventh message to the DNS server through the Wi-Fi chip according to the preset queue message sending rule.

In some embodiments, the Wi-Fi driver may send the seventh message to the DNS server using the IP address of the DNS server carried in the DHCP OFFER message previously provided by the DHCP server.

In some embodiments, the DNS server may be pre-installed in a router that provides a Wi-Fi network, or may be a device connected to the router in a Wi-Fi local area network. If the DNS server and the router are different devices, the Wi-Fi chip may send the seventh message to the router, which then sends it to the DNS server.

S806. The DNS server receives the seventh message from the mobile phone, determines the second IP address corresponding to the target domain name in the seventh message in response to the seventh message, and generates a DNS response message carrying the second IP address.

Specifically, after receiving the seventh message, the DNS server will determine the second IP address corresponding to the target domain name in any feasible manner, such as obtaining the second IP address from the local cache of the DNS server.

S807. The DNS server sends a DNS response message to the mobile phone.

In some embodiments, the DNS server unicasts the DNS response message to the mobile phone. Specifically, the source IP address in the DNS request message is the IP address of the mobile phone. After obtaining the domain name resolution result (i.e., the second IP address), the DNS server sends a DNS response message carrying the domain name resolution result to the mobile phone based on the source IP address.

S808. The Wi-Fi chip of the mobile phone receives the DNS response message from the router, and sends the DNS response message to the TCP/IP protocol stack through the Wi-Fi driver.

S809. The TCP/IP protocol stack of the mobile phone stores the second IP address carried in the DNS response message.

After obtaining the second IP address corresponding to the target domain name, the mobile phone can use the second IP address as the destination address to access the Internet.

Based on the above DNS data transmission process, the mobile phone can place all signaling messages corresponding to the DNS in the VO queue for transmission. Since the VO queue is the queue with the strongest channel preemption capability for electronic devices in Wi-Fi scenarios, even in poor air interface conditions (i.e., interference or poor air interface signals), the signaling messages in the DNS data transmission process can be sent more reliably (this can be understood as a higher probability that the receiver will successfully receive the signaling message). This allows the mobile phone and the DNS server to successfully complete the DNS data transmission process. The mobile phone can then use the destination IP address corresponding to the web page or application that the user needs to log in to, obtained through this process, to proceed with the subsequent Internet access process and successfully access the Internet. This prevents signaling messages from being unsuccessfully sent due to poor air interface conditions (this can be understood as the receiver failing to successfully receive the signaling message), resulting in connection freezes, delays, or failures when the user uses the electronic device to access the Internet via a Wi-Fi network, thereby ensuring the user's Internet experience.

After the mobile phone completes the DNS data transmission process, the mobile phone can start to use the second IP address to establish a TCP connection with the TCP server corresponding to the second IP address, and then interact with the TCP server to complete the purpose of surfing the Internet.

Based on the software architecture shown in FIG4 above, the TCP data transmission process in the data transmission method provided by the embodiment of the present application is introduced below in conjunction with FIG9. FIG9 is a schematic diagram of the ARP data transmission process provided by the embodiment of the present application. Referring to FIG9, taking the electronic device as a mobile phone as an example, the TCP data transmission process may include S901-S915:

S901. The TCP/IP protocol stack of the mobile phone generates an eighth message and sends the eighth message to the Wi-Fi driver.

Among them, the eighth message can be the Transmission Control Protocol Synchronization Sequence Number (TCP SYN (synchronize sequence number)) message (also known as the first TCP handshake message) sent by the mobile phone acting as a TCP client to the TCP server in the TCP three-way handshake process.

The TCP SYN packet includes SYN and a sequence number, seq, where SYN=1 and seq=x. SYN=1 indicates a request to establish a TCP connection with the TCP server, and seq=x indicates that the current sequence number corresponding to the mobile phone is x. In some embodiments, x can be 0.

S902: The Wi-Fi driver of the mobile phone parses the eighth message, and determines whether the eighth message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the eighth message is a signaling message of a preset protocol based on the parsing result of the eighth message, the eighth message may be put into the VO queue for sending, that is, S903 is executed.

When the Wi-Fi driver determines that the eighth message is not a signaling message of the preset protocol based on the parsing result of the eighth message, the eighth message may be placed in a transmission queue other than the VO queue for sending, that is, S904 is executed.

The specific implementation of S902 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S903: The Wi-Fi driver of the mobile phone puts the eighth message into the VO queue.

S904: The Wi-Fi driver of the mobile phone puts the eighth message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the eighth message, which is not a signaling message of the preset protocol, in the BE queue.

Of course, it should be noted that during the three-way handshake process to establish a TCP connection between the mobile phone and the TCP server, the TCP SYN message sent by the mobile phone to the TCP server during the first handshake is a signaling message of the preset protocol. Therefore, based on the parsing result of the eighth message, the Wi-Fi driver can determine that the eighth message is a signaling message. Therefore, S904 is not actually executed. The description of S904 in this embodiment of the application is only to illustrate the specific possible actions of the Wi-Fi driver in the technical solution provided by this application.

S905 : The Wi-Fi driver of the mobile phone sends the eighth message to the TCP server through the Wi-Fi chip according to the preset queue message sending rule.

The TCP server may be a server corresponding to a domain name input by the user in the browser, or the TCP server may be an application server to which an application opened by the user belongs.

In some embodiments, the Wi-Fi driver may send the eighth message to the TCP server through the Wi-Fi chip based on the second IP address returned by the DNS server.

Since the TCP server is not in the Wi-Fi local area network but in the remote Internet, the Wi-Fi chip can forward the eighth message to the TCP server through a router (or gateway).

After the mobile phone sends the eighth message to the TCP server, the mobile phone is in the SYN_SENT (synchronization sent) state, which is used to indicate that the mobile phone has sent a TCP SYN message to the TCP server to request to establish a TCP connection.

S906. The TCP server receives the eighth message from the mobile phone, and generates a TCP response message in response to the eighth message.

This TCP response message (also known as the second TCP handshake message) includes the seq, SYN, ACK, and ack fields. seq = y, SYN = 1, ACK = 1, and ack = x + 1. y is a randomly generated value by the TCP server. seq = y indicates that the TCP server's current sequence number is y; SYN = 1 and ACK = 1 indicate that the TCP server has received the TCP SYN message and agreed to establish a TCP connection; ack = x + 1 indicates the confirmation number, which is the value of seq in the eighth message sent by the client plus 1.

S907. The TCP server sends a TCP response message to the mobile phone.

In some embodiments, the TCP server may send the TCP response message to the mobile phone through a router.

Specifically, the TCP server may send a TCP response message to the source IP address in the TCP SYN message.

After the TCP server sends a TCP response packet to the mobile phone, the TCP server may enter the SYN_RCVD (Synchronize Received) state, which indicates that the server has received the TCP SYN packet sent by the client and sent a SYN+ACK packet (i.e., a TCP response packet) in response. The server enters the SYN_RCVD state to indicate that it is ready to establish a connection with the client.

S908. The Wi-Fi chip of the mobile phone receives the TCP response message from the TCP server, and sends the TCP response message to the TCP/IP protocol stack through the Wi-Fi driver.

S909. The TCP/IP protocol stack of the mobile phone generates a ninth message in response to the TCP response message.

The ninth message may be the third TCP handshake message sent by the mobile phone to the TCP server during the three interactions between the mobile phone and the TCP server.

This third TCP handshake message includes the ACK field, seq field, and ack field. ACK field = 1, seq = x+1, and ack field = y+1. ACK field = 1 indicates that the phone has received the TCP response message and agrees to establish the TCP connection; seq = x+1 indicates that the phone's current sequence number is x+1; and ack field = y+1 indicates the confirmation number, which is calculated by adding 1 to the seq value in the TCP response message sent by the TCP server.

Since both the mobile phone and the TCP server have agreed to establish a TCP connection, the third TCP handshake message can carry the specific service data that the mobile phone wants to send to the TCP server. In other words, the third TCP handshake message can include multiple protocol messages. When the third TCP handshake message includes multiple protocol messages, the TCP server can promptly know whether it has received the third TCP handshake message and perform the corresponding action. Therefore, the third TCP handshake message at this time should not be a signaling message of the preset protocol.

That is to say, if the third TCP handshake message does not carry business data, it can be considered that the third TCP handshake message is a signaling message of the preset protocol; if the third TCP handshake message carries business data, it can be considered that the third TCP handshake message is not a signaling message of the preset protocol.

S910. The TCP/IP protocol stack of the mobile phone sends a ninth message to the Wi-Fi driver.

Although the ninth message is a signaling message, the signaling message may carry a message containing business data. In this case, the signaling message may be regarded as a data message. Therefore, the ninth message is not a signaling message in the strict sense mentioned in this application and does not necessarily need to be placed in the VO queue to be sent.

S911. The Wi-Fi driver of the mobile phone parses the ninth message and determines whether the ninth message is a signaling message of a preset protocol based on the parsing result.

When the Wi-Fi driver determines that the ninth message is a signaling message of a preset protocol based on the parsing result of the ninth message, the ninth message may be placed in a VO queue for sending, ie, S912 is executed.

When the Wi-Fi driver determines that the ninth message is not a signaling message of the preset protocol based on the parsing result of the ninth message, the ninth message may be placed in a transmission queue other than the VO queue for sending, that is, S913 is executed.

The specific implementation of S911 can refer to the relevant description of S504 in the above embodiment, and will not be repeated here.

S912. The Wi-Fi driver of the mobile phone puts the ninth message into the VO queue.

S913. The Wi-Fi driver of the mobile phone puts the ninth message into a transmission queue other than the VO queue.

Exemplarily, the Wi-Fi driver of the mobile phone may place the fourth message, which is not a signaling message of the preset protocol, in the BE queue.

Of course, it should be noted that, during the three-way handshake between the mobile phone and the TCP server to establish a TCP connection, the third TCP handshake message of the last handshake can carry multiple data messages. That is to say, after the TCP server receives the third TCP handshake message, even if there is missing content in it, the TCP server can promptly determine what data is missing based on the sequence numbers of different messages, and promptly inform the mobile phone to resend it. Therefore, the ninth message may not be a signaling message of the preset protocol, so here the Wi-Fi driver can determine whether the ninth message is a signaling message of the preset protocol based on the parsing result of the ninth message. Afterwards, it is decided to execute S911 or S912 based on the judgment result.

S914. The Wi-Fi driver of the mobile phone sends the ninth message to the TCP server through the Wi-Fi chip according to the preset queue message sending rule.

Specifically, at this time, the mobile phone and the TCP server can be considered to have established a TCP connection, and the Wi-Fi chip of the mobile phone can send the ninth message to the TCP server according to the TCP protocol.

After the mobile phone sends the ninth message to the TCP server, it enters the ESTABLISHED state, which indicates that the client has received the SYN+ACK message (i.e., the TCP response message) sent by the server and sent an ACK message (i.e., the ninth message) as confirmation. At this point, the connection between the client and the server has been successfully established, and both parties can begin data transmission.

S915. The TCP server receives the ninth message from the mobile phone.

After receiving the ninth message from the mobile phone, the TCP server is also in the ESTABLISHED (connection established) state.

After S915, it can be determined that a complete TCP connection has been established between the mobile phone and the TCP server. After that, the mobile phone can normally access the TCP server based on the TCP connection to complete the purpose of surfing the Internet.

Based on the above TCP data transmission process, the mobile phone can place all signaling messages corresponding to TCP in the first-priority transmission queue with the highest transmission priority, such as the VO queue, for transmission. In Wi-Fi scenarios, messages in the queue with the highest transmission priority have a stronger ability to seize the channel, resulting in a higher transmission success rate. This allows the signaling messages in the TCP data transmission process to be sent more reliably (this can be understood as the probability of the receiver successfully receiving the signaling message) even in a less-than-optimal air interface environment (i.e., air interface signal interference or poor air interface signal). This allows the mobile phone and the TCP server to successfully complete the TCP data transmission process, and the mobile phone can subsequently access the Internet smoothly based on the TCP connection established through this process. This prevents signaling messages of the preset protocol from being successfully sent due to a less-than-optimal air interface environment (this can be understood as the receiver failing to successfully receive the signaling message), resulting in connection freezes, delays, or failures when the user uses the electronic device to access the Internet via a Wi-Fi network, thereby ensuring the user's Internet experience.

In the embodiments of the present application, the first message, the second message, the third message, the fourth message, the fifth message, the sixth message, the seventh message, the eighth message, and the ninth message generated by the mobile phone may all be referred to as first protocol messages to be sent. The router acting as an AP, the DHCP server, the router acting as a gateway, the DNS server, and the TCP server may be referred to as target devices.

It is understandable that, in order to realize the above functions, the above electronic device includes hardware structures and/or software modules corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the embodiments of the present application.

The embodiment of the present application can divide the functional modules of the above-mentioned electronic device according to the above-mentioned method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present invention is schematic and is only a logical function division. There may be other division methods in actual implementation.

In the case of dividing each functional module according to each function, the embodiment of the present application further provides a data transmission device, which can be applied to an electronic device in a Wi-Fi network. The device can include a processing module and a sending module.

Among them, the processing module is used to add the first protocol message to the first priority transmission queue when the first protocol message to be sent is a signaling message; the processing module is also used to add the first protocol message to the second priority transmission queue when the first protocol message is not a signaling message of the preset protocol; the second priority transmission queue is different from the first priority transmission queue; the preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS or TCP; the sending module is used to send the first protocol message to the target device through the Wi-Fi network according to the preset queue message sending rule; the preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue.

In addition, the cooperation between the processing module and the sending module can also enable the data transmission device to complete all the steps of the data transmission method provided in the aforementioned embodiment.

Regarding the data transmission device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the data transmission method in the above embodiment, and will not be further elaborated here. The relevant beneficial effects thereof can also be referred to the relevant beneficial effects of the above data transmission method, and will not be repeated here.

An embodiment of the present application further provides an electronic device comprising: a display screen, a memory, and one or more processors; the display screen, the memory, and the processors being coupled; wherein the memory stores computer program code, the computer program code comprising computer instructions, which, when executed by the processor, causes the electronic device to execute the frame loss fault determination method provided in the aforementioned embodiment. The specific structure of the electronic device can be referenced with reference to the electronic device structure shown in FIG3 .

The present application also provides an electronic device comprising a TCP/IP protocol stack, a Wi-Fi driver, and a Wi-Fi chip. When the Wi-Fi driver executes computer instructions, the electronic device executes the data transmission method provided in the aforementioned embodiment. Specifically, the TCP/IP protocol stack and the Wi-Fi driver may be software modules within an AP within a SOC within the electronic device.

An embodiment of the present application further provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device executes the data transmission method provided in the aforementioned embodiment.

An embodiment of the present application further provides a computer program product, which includes executable instructions. When the computer program product is run on an electronic device, the electronic device executes the data transmission method provided in the aforementioned embodiment.

The present application also provides a chip system, as shown in FIG10 . The chip system 1000 includes at least one processor 1001, a memory, and at least one interface circuit 1002. The processor 1001 and the interface circuit 1002 can be interconnected via a line. For example, the interface circuit 1002 can be used to receive signals from another device (e.g., a target device). For another example, the interface circuit 1002 can be used to send signals to another device (e.g., a target device).

For example, the interface circuit 1002 can read instructions or computer programs stored in the memory and send the instructions or computer programs to the processor 1001. When the instructions or computer programs are executed by the processor 1001, the various steps of the data transmission method provided in the above embodiment can be implemented. Of course, the chip system can also include other discrete components, which are not specifically limited in the embodiments of the present application.

In some embodiments, as shown in FIG11 , the processor in the chip system may include a SOC and a Wi-Fi chip. The SOC may include an application processor AP, and the AP may include a TCP/IP protocol stack and a Wi-Fi driver. The TCP/IP protocol stack and the Wi-Fi driver may specifically be software modules. When the Wi-Fi driver executes computer instructions, the electronic device to which the chip system belongs executes the data transmission method provided in the aforementioned embodiments.

Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed devices/equipment and methods can be implemented in other ways. For example, the device/equipment embodiments described above are merely schematic. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separate, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and other media that can store program code.

The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims (10)

A data transmission method, characterized in that the method comprises: When the first protocol message to be sent is a signaling message of a preset protocol, the electronic device adds the first protocol message to a first priority transmission queue; The electronic device adds the first protocol message to a second priority transmission queue when the first protocol message is not a signaling message of the preset protocol; the second priority transmission queue is different from the first priority transmission queue; the preset protocol includes any one or more of the following: EAPOL, DHCP, ARP, DNS or TCP; The electronic device sends the first protocol message to the target device through the Wi-Fi network according to a preset queue message sending rule; the preset queue message sending rule includes that the transmission priority of the first priority transmission queue is higher than the transmission priority of the second priority transmission queue. The method according to claim 1, wherein the electronic device includes a Wi-Fi driver; and when the first protocol message to be sent is a signaling message of the preset protocol, the electronic device adds the first protocol message to the first priority transmission queue, comprising: The Wi-Fi driver parses the first protocol message, and when determining based on the parsing result that the first protocol message is a signaling message of the preset protocol, adds the first protocol message to a first priority transmission queue. The method according to claim 1 or 2, characterized in that the signaling message of the preset protocol includes at least one of the following: the second handshake message in the four-way handshake process of Extensible Authentication Protocol for Local Area Networks (EAPOL), the fourth handshake message in the four-way handshake process of EAPOL, a Dynamic Host Configuration Protocol (DHCP) DISCOVER message, a DHCP REQUEST message, an Address Resolution Protocol (ARP) request message, a Domain Name System (DNS) request message, the first TCP handshake message in the three-way handshake process of Transmission Control Protocol (TCP), and the third TCP handshake message in the three-way handshake process of TCP that does not carry business data; The ARP request message is used to request the physical address MAC of the gateway; the DNS request message is used to request the Internet Protocol address IP corresponding to the target domain name; and the first TCP handshake message is used to request the establishment of a TCP connection. The method according to any one of claims 1 to 3, characterized in that the first priority transmission queue is a voice optimized VO queue. The method according to any one of claims 1 to 4, characterized in that the second priority transmission queue includes any one of the following: a video optimized VI queue, a best effort BE queue, or a background optimized BK queue. The method according to any one of claims 1 to 5 is characterized in that, when the first protocol message is not a signaling message of the preset protocol, the first protocol message includes: a third TCP handshake message carrying business data in a TCP three-way handshake process. The method according to any one of claims 1 to 6, wherein the electronic device comprises a TCP/IP protocol stack and a Wi-Fi chip; the first protocol message is a message generated by the TCP/IP protocol stack; The electronic device sends the first protocol message to the target device through the Wi-Fi network according to a preset queue message sending rule, including: the electronic device controls the Wi-Fi chip to send the first protocol message to the target device through the Wi-Fi network according to the preset queue message sending rule. An electronic device, characterized in that it includes: a display screen, a memory and one or more processors; the display screen and the memory are coupled to the processor; wherein the memory stores computer program code, and the computer program code includes computer instructions, and when the computer instructions are executed by the processor, the electronic device executes the data transmission method according to any one of claims 1 to 7. An electronic device, characterized in that it includes a TCP/IP protocol stack, a Wi-Fi driver and a Wi-Fi chip; when the Wi-Fi driver executes computer instructions, the electronic device executes the data transmission method according to any one of claims 1 to 7. A chip system, characterized in that the chip system includes a processor, and when the processor executes computer instructions, the electronic device where the chip system is located executes the data transmission method according to any one of claims 1 to 7.