Bluetooth transmission method and system

Abstract

The application discloses a Bluetooth transmission method and system, the method comprises the following steps: sending a plurality of Bluetooth data packets while detecting Bluetooth connection; after sending the Bluetooth data packet each time, judging whether the ACK response is correctly received; if yes, increasing the initial maximum transmission window of Bluetooth in response to the correct reception of the ACK response; if not, using dichotomy to find the optimal window size of the current transmission between the initial maximum transmission window and the transmission window threshold, the transmission window threshold being smaller than the initial maximum transmission window; repeatedly calculating the optimal window size of several transmissions, and determining the best Bluetooth transmission window based on the optimal window size of several transmissions for data transmission; the application can improve the efficiency of Bluetooth transmission data.

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, and specifically to a Bluetooth transmission method and system. Background Technology

[0002] With the development of the information age, intelligence has penetrated into all aspects of people's daily lives, and people's demand for intelligent products that are convenient to use, energy-saving, and low-cost is increasing. In today's world, where battery technology has not yet achieved revolutionary breakthroughs and large-scale application, Bluetooth Low Energy (BLE) has emerged to meet the high requirements of power consumption and cost for wireless solutions.

[0003] Bluetooth technology, proposed by the Bluetooth Special Interest Group (Bluetooth SIG), is a wireless interface technology used for short-range data communication and information exchange between electronic devices. Due to its low cost, low power consumption, small module size, and high transparency, it has become a common technology for short-range connections in electronic products. To date, Bluetooth technology has gone through several versions, from V1.1 to V5.2. Starting with version V4.0, the Bluetooth protocol specification includes three Bluetooth technologies: Classic Bluetooth (Basic Rate / Enhanced Data Rate, BR / EDR), Bluetooth Low Energy (LE), and Bluetooth High Speed. Bluetooth Low Energy is widely used due to its long standby time, fast connection speed, and low peak power for transmission and reception. Compared to Bluetooth 3.0, it features low cost, low power consumption, and long transmission distance. With major mobile phone manufacturers adopting the 4.0 specification, wearable products have sprung up like mushrooms after rain. According to the "Wearable Device Research Report" released by the China Academy of Information and Communications Technology, the market size of smart wearable devices in China reached 12.58 billion yuan in 2015, with a growth rate of 471.8%. Starting in 2016, the huge potential of some vertical fields began to be released, and the wearable market officially entered the launch period. By 2017, the Chinese smart wearable device market had entered a period of rapid development. According to statistics, in 2017, the shipment of Xiaomi Band alone exceeded 15 million units, and the global wearable device market exceeded 100 billion yuan. By 2021, the global shipment of smartwatches in Q2 reached 18 million units, an increase of 47% compared with the same period last year. Such a large market has attracted numerous technology companies to participate, and technological innovation has become the focus of competition among manufacturers. The rapid development of the market has brought vitality to companies in the smart wearable industry chain based on Bluetooth Low Energy. The maturity of mobile Internet technology will bring a good user experience to wearable devices. Since the wearable device market is still in its early stages, the future market development space is huge, so wearable devices are a promising field. In this field, it is not only necessary to improve the user's use of wearable devices, but also to greatly meet the software requirements for wearable devices. Therefore, completing the software design of wearable products is a challenging task.

[0004] In related technologies, the patent document with publication number CN105827537A proposes a congestion improvement method based on the QUIC protocol, which adds latency information to the congestion algorithm and makes a judgment by comparing the previous RTT with the current RTT, but the data transmission speed is still slow in actual applications.

[0005] The patent document with publication number CN103826221A proposes a Bluetooth-based encrypted communication method, related system and method. In this method, a mutual authentication mechanism is used to ensure that the identities of both parties are legitimate before a Bluetooth connection can be established. After the identity verification is legitimate, both parties encrypt the data with the same key key2 and then transmit the encrypted data through Bluetooth with the same protocol. However, this scheme uses the traditional 3DES algorithm for encryption.

[0006] The Bluetooth receiving method proposed in the patent document with publication number CN113541864A receives the baseband signal and parses the load data and the corresponding cyclic redundancy check (CRC) information. The CRC check result is obtained based on the CRC check information. When the CRC check is incorrect and the number of retransmissions is not less than a preset retransmission threshold, the retransmission ends. However, this receiving method is more inclined towards the underlying hardware logic and does not explain the specific details of data verification.

[0007] However, for single-mode Bluetooth 4.2 smart wearable devices with extremely high requirements for low cost, low power consumption, and energy saving, the traditional Bluetooth 4.2 transmission solution still has many shortcomings, such as:

[0008] (1) Single packet ACK transmission mode: Based on the system encapsulation, the single packet ACK transmission mode has a slow transmission speed for large files.

[0009] (2) QUIC congestion control algorithm: This mechanism relies entirely on packet loss to determine network congestion. A large number of random packet losses occur on the network, and the network is constantly being re-detected, leading to a significant decrease in network utilization and further hindering the effective use of the algorithm. Simultaneously, the use of a fixed-size window for searching during packet loss probability calculation reduces the algorithm's sensitivity to network state changes, resulting in low operating efficiency. Furthermore, real-world network environments are typically unstable, and the algorithm's window growth is very simplistic, with the growth rate not adjusted according to network conditions. In poor network conditions, increased connection round-trip delays and the delayed forwarding of numerous nodes inevitably waste power. Moreover, the trade-off between the maximum accept window size update frequency and update time in QUIC flow control remains unresolved. During the initial transmission, the receiver's data reception is consistent with the theoretical value, but subsequent data transmissions fall short of the theoretical value, reaching only half of it.

[0010] (3) Slow data retrieval: Mobile applications are slow to retrieve data from the Internet. When the mobile application needs to make an HTTP / TCP response to obtain the data stream, the transmission is slow.

[0011] (4) Head-of-line blocking and retransmission ambiguity: Traditional data transmission uses TCP handshake connection. Once the data stream is lost, the subsequent data will be blocked.

[0012] (5) The device does not have an application layer encryption mechanism: The existing Bluetooth transmission system does not have an application layer encryption mechanism, which leads to the problem of sending user privacy information such as message reminders in plaintext. Therefore, an application layer data transmission encryption mechanism should be added to provide data confidentiality and protect user privacy.

[0013] (6) Business Coupling: Currently, the error codes and commands of the Bluetooth transmission system protocol are directly coupled with specific business functions, without decoupling the transport layer and the business layer, and without modularization. This inevitably leads to code coupling during coding, making it difficult to achieve decoupled coding, and may even directly induce developers to write completely coupled code.

[0014] Therefore, there is an urgent need for corresponding optimization methods to address the issues of slow transmission speed and high power consumption in low-power Bluetooth transmission systems in specific scenarios. Summary of the Invention

[0015] The technical problem to be solved by this invention is how to improve transmission efficiency.

[0016] The present invention solves the above-mentioned technical problems through the following technical means:

[0017] On one hand, the present invention proposes a Bluetooth transmission method, the method comprising:

[0018] Detect Bluetooth connection while sending multiple Bluetooth data packets;

[0019] After each Bluetooth data packet is sent, determine whether an ACK response has been correctly received;

[0020] If so, then in response to correctly receiving an ACK response, the initial maximum transmission window of Bluetooth is increased;

[0021] If not, then a binary search method is used to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold, where the transmission window threshold is less than the initial maximum transmission window.

[0022] The optimal window size for several transmissions is obtained through repeated calculations, and the best Bluetooth transmission window for data transmission is determined based on the optimal window size for several transmissions.

[0023] Further, the step of repeatedly calculating the optimal window size for several transmissions and determining the optimal Bluetooth transmission window for data transmission based on the optimal window size for several transmissions includes:

[0024] Remove the maximum and minimum values ​​from the optimal window size of several transmissions to obtain the filtered window values, and calculate the variance of the sum and mean of the filtered window values.

[0025] When the variance of the mean and the mean meets the set conditions, the smallest value among the filtered window values ​​is taken as the optimal Bluetooth transmission window.

[0026] If the variance of the mean does not meet the set conditions, the optimal window size for transmission will be recalculated several times.

[0027] Furthermore, after each transmission of the Bluetooth data packet, the method further includes:

[0028] If a correct ACK response is received within the set time, the next frame of data is sent.

[0029] If a frame data error retransmission request is received within the set time, then the frame data will be retransmitted.

[0030] If no ACK response is received within the set time, the timeout retransmission mechanism will be enabled to retransmit this frame of data.

[0031] In continuous n If the retransmission fails, the data transmission of this frame is determined to have failed.

[0032] Furthermore, the Bluetooth data packet includes a version confirmation packet, a version response packet, a data packet, and an overall response packet;

[0033] The version confirmation package is used to query the version number;

[0034] The version response packet is used to return the version number;

[0035] The data packet contains plaintext and ciphertext data;

[0036] The overall response packet is used to respond to the response message.

[0037] Furthermore, the Bluetooth transmission protocol used during Bluetooth transmission meets the following conditions:

[0038] The Bluetooth transmission protocol is a unidirectional transmission channel, with symmetrical uplink and downlink data between the two communicating devices, and each device uses a single feature.

[0039] The Bluetooth transmission protocol itself is only associated with its respective business module;

[0040] The sender in the communication controls whether an acknowledgment is required and how timeouts are handled.

[0041] Furthermore, before each transmission of the Bluetooth data packet, the method further includes:

[0042] During the authorization process, the two communicating parties generate three key encrypted numbers X, R0, and R1, where X is the original encrypted number, and R0 and R1 are the transmitted random numbers of the smart device and the client, respectively.

[0043] The original encrypted number X is XORed with the session ID of each transmission to obtain the AES encryption key key Y for this transmission;

[0044] When the smart device receives the encrypted data sent by the client for the first time, it verifies the received data based on the transmission random number R0.

[0045] When the client receives the first encrypted data sent by the smart device, it verifies the received data based on the transmission random number R1.

[0046] When data transmission is successfully decrypted, both communicating parties increment their respective transmission random numbers by 1 and use the result as the NONCE value for the next transmission.

[0047] If data transmission decryption fails, the sender increments its corresponding transmission random number by 1 and uses it as the NONCE value for the next transmission.

[0048] Furthermore, during the authorization process, the two communicating parties generate three key encryption numbers X, R0, and R1, including:

[0049] The client and the smart device interact with ECDH to generate an ECDH public key, an ECDH private key, and a binding key.

[0050] The original encrypted number X is obtained by XORing the ECDH shared cipher P used in the authorization process with the binding key.

[0051] Based on a portion of the bound key, the initial value of the received NONCE on the smart device is obtained as the transmission random number R0;

[0052] Based on another portion of the binding key, the initial value of the client's received NONCE is obtained as the transmission random number R1.

[0053] Furthermore, upon receiving a Bluetooth data packet sent by the other party, the method further includes:

[0054] Verify that the frame sequence number of the Bluetooth data packet is correct;

[0055] If the frame sequence number is correct, check if the frame CRC matches. If the frame sequence number is incorrect, send a response to the other party requesting a retransmission of the correct frame due to frame data error.

[0056] If the frame CRC matches, it is determined whether all the data in the transport layer has been received. If the frame CRC does not match, a response is sent to the other party requesting a retransmission of the correct frame due to a frame data error.

[0057] If not all transport layer data is received, an ACK frame is sent to the other party to indicate that the data has been received correctly. If all transport layer data is received, the transport layer CRC is checked to see if it matches.

[0058] If the transport layer CRC matches, an ACK frame is sent to the other party indicating that the data has been received correctly. If the transport layer CRC does not match, the received data is discarded and an ACK frame is sent to the other party indicating that the data has been received incorrectly.

[0059] Furthermore, after sending multiple Bluetooth data packets, the method further includes:

[0060] When data packets are lost on the network during data transmission, record the average round-trip time (RTT) at the time of the most recent packet loss event. avg And the congestion window size W at the time of the most recent packet loss. max ;

[0061] The average round-trip time (RTT) recorded at the time of the most recent packet loss. avg Current delay RTT when revisiting the window cur The ratio is used as the congestion level factor;

[0062] Adjust the window size based on the congestion level factor. ,in, , , Increase the rate for the congestion window. To reduce the time required to start from the last window, To increase the congestion window size in the absence of packet loss events. The time required.

[0063] On the other hand, the present invention also proposes a Bluetooth transmission system, the system comprising:

[0064] The transmitting module is used to send multiple Bluetooth data packets;

[0065] The judgment module is used to determine whether an ACK response has been correctly received after each Bluetooth data packet is sent.

[0066] The window adjustment module is used to increase the initial maximum transmission window of Bluetooth in response to the correct receipt of the ACK response when the output result of the judgment module is yes.

[0067] The window optimization module is used to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold when the output result of the judgment module is negative. The transmission window threshold is less than the initial maximum transmission window.

[0068] The window determination module is used to repeatedly calculate the optimal window size for several transmissions, and determine the best Bluetooth transmission window for data transmission based on the optimal window size for several transmissions.

[0069] The advantages of this invention are:

[0070] (1) In order to increase the amount of data transmitted, the present invention abandons the use of single packet transmission and adopts a multi-packet transmission mode without ACK response. In order to solve the problem that if the amount of data sent is too large when using the multi-packet transmission mode without ACK response, it will inevitably cause data congestion, which will seriously affect communication and even cause lag and crash. The invention automatically detects the Bluetooth connection when the data packet is sent, and then uses slow start and binary search to detect the maximum transmission window. It can dynamically and timely judge the size of the Bluetooth transmission window, prevent data congestion caused by the large amount of data in the early stage of transmission, and thus improve the data transmission efficiency.

[0071] (2) In response to the problems of deep coupling between the service layer command and profile layer and deep coupling between the packet protocol and the service layer in the current Bluetooth transmission protocol, this invention redesigns the protocol based on the Write without Response + Notify combination mode, so that the uplink and downlink data of the client and the smart device are symmetrical. This solves the problem that the communication protocol between the client App and the smart device is asymmetrical, which causes the device to be unable to directly push data to the client App in services such as eSIM and WiFi, and the processing speed is slow due to the need to process low-frequency events. This further improves the data transmission efficiency.

[0072] (3) In order to solve the problem that all current devices do not have an application layer encryption mechanism, resulting in the plaintext transmission of user privacy information such as message reminders, this invention adds an application layer data transmission encryption mechanism to provide data confidentiality and protect user privacy.

[0073] (4) In order to improve transmission efficiency, the present invention adopts a protocol based on the multi-packet transmission mode without ACK. In this way, the Bluetooth at the bottom layer of the OS system no longer needs to return ACK information. Without ACK information, once the data is lost, the transmission will fail, and even the two devices may not know that the data is lost. Therefore, the present invention designs an appropriate verification and retransmission mechanism to ensure that the data is transmitted safely and reliably. In the verification part, the frame CRC and transport layer CRC will be the focus to ensure the reliability and availability of the data.

[0074] (5) In the transmission of Internet-based smartwatches, it is necessary to form a channel for information transmission between the smart device end (i.e., the watch), the client end (i.e., the mobile phone), and the Internet. This requires the Internet end to achieve fast data transmission and lightweight communication to ensure high data rate and high reliability. This invention optimizes the Cubic algorithm by introducing a network congestion detection mechanism based on network latency, realizing a comprehensive evaluation of latency information and dynamic adjustment of the growth rate of the congestion window growth function. The simulation experiment verifies that this method can effectively reduce network throughput.

[0075] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0076] Figure 1 This is a flowchart illustrating the Bluetooth transmission method proposed in an embodiment of the present invention;

[0077] Figure 2 This is a schematic diagram of the optimized transmission window process in an embodiment of the present invention;

[0078] Figure 3 This is a flowchart illustrating the Bluetooth data retransmission mechanism in an embodiment of the present invention.

[0079] Figure 4 This is a schematic diagram of the Bluetooth general protocol in an embodiment of the present invention;

[0080] Figure 5 This is an embodiment of the present invention representing the information of the transmission packet;

[0081] Figure 6 This is an embodiment of the present invention representing the information in the version confirmation package.

[0082] Figure 7 This is the intended representation of information in the data packets in this embodiment of the invention;

[0083] Figure 8 This is an embodiment of the present invention representing the overall response packet information.

[0084] Figure 9 This is the intended representation of Error code information in this embodiment of the invention;

[0085] Figure 10 This is a schematic diagram of the ECDH interaction process between the two communicating parties in an embodiment of the present invention;

[0086] Figure 11 This is a schematic diagram of the data verification process in an embodiment of the present invention;

[0087] Figure 12This is a schematic diagram of the congestion window adjustment process in an embodiment of the present invention;

[0088] Figure 13 This is a schematic diagram of the Bluetooth transmission system proposed in an embodiment of the present invention. Detailed Implementation

[0089] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0090] like Figures 1 to 2 As shown, the first embodiment of the present invention proposes a Bluetooth transmission method, the method comprising the following steps:

[0091] S10. Detect Bluetooth connection while sending multiple Bluetooth data packets;

[0092] S20. After each Bluetooth data packet is sent, determine whether an ACK response has been received correctly. If yes, proceed to step S30; otherwise, proceed to step S40.

[0093] S30. In response to a correct reception of an ACK, increase the initial maximum transmission window of Bluetooth;

[0094] It should be noted that the initial value of the Bluetooth maximum transmission window is set to one packet size in bytes. After each transmission, if a correct ACK response is received, the initial maximum transmission window of Bluetooth is increased, for example, by doubling the initial value of the Bluetooth maximum transmission window.

[0095] S40. Use a binary search method to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold, wherein the transmission window threshold is less than the initial maximum transmission window.

[0096] It should be noted that if a correct ACK response is not received after sending data, a binary search method is used to find the optimal window size for the current transmission between the initial maximum transmission window (i.e., one packet size in bytes) and the transmission window threshold, such as size / 2.

[0097] S50. Repeat steps S10 to S40 above to obtain the optimal window size for several transmissions, and determine the best Bluetooth transmission window for data transmission based on the optimal window size for several transmissions.

[0098] This embodiment addresses the slow data transmission problem of traditional Bluetooth single-channel transmission. To increase data transmission volume, it abandons single-packet transmission and adopts a multi-packet transmission mode without ACK acknowledgment. However, since the maximum transmission window size varies across different operating systems, sending data in the multi-packet transmission mode without ACK acknowledgment can lead to data congestion if the amount of data sent is too large, severely impacting communication and potentially causing lag or crashes. Therefore, it is necessary to find the maximum transmission window that allows the smart device to process data simultaneously from the client to the client. If the client starts sending Bluetooth data packets and immediately sends a large amount of data to the smart device, Bluetooth data overload is likely to occur. Therefore, the Bluetooth connection is automatically detected when data packets are sent, and the maximum transmission window is probed using slow start and binary search. This allows for dynamic and timely determination of the Bluetooth transmission window size, preventing data congestion caused by excessive data volume in the initial stage of transmission, thereby improving data transmission efficiency.

[0099] In one embodiment, step S50 involves obtaining the optimal window size for several transmissions and determining the optimal Bluetooth transmission window for data transmission based on the optimal window size for several transmissions. This specifically includes the following steps:

[0100] S51. Remove the maximum and minimum values ​​from the optimal window size of several transmissions to obtain the filtered window values, and calculate the variance of the sum and average of the filtered window values.

[0101] S52. When the variance of the mean and the mean meets the set conditions, the smallest value among the filtered window values ​​is taken as the optimal Bluetooth transmission window.

[0102] S53. If the variance of the sum and average does not meet the set conditions, the optimal window size for transmission will be recalculated several times.

[0103] Specifically, if this process is repeated 10 times to obtain 10 optimal windows, then the two maximum and two minimum values ​​are removed. The variance of the remaining window values ​​and the average is then calculated. If the variance is no greater than 5, the sniffing result is considered to have met expectations. The smallest of the remaining 6 values ​​is then used as the optimal Bluetooth transmission window size. If the variance is greater than 5, the sniffing process is repeated until the expected result is obtained.

[0104] It should be noted that in practical applications, because Bluetooth transmission systems need to consider different mobile clients, such as Android or Apple, the maximum transmission window varies between these clients. Therefore, there is no fixed value, nor can it be consistent across all phones. This embodiment obtains the optimal window size through multiple repeated measurements. This continuous probing aims to better determine a suitable window size for more stable transmission.

[0105] It should be understood that the stability of the data can be characterized by calculating the variance of the sum and average of multiple transmission windows in this embodiment. The specific value of 5 set in this embodiment is only an empirical value obtained through experiments. The purpose of setting it is to better analyze from a statistical perspective. Those skilled in the art can also set other values ​​such as 10, 20, etc. according to the actual situation. This embodiment does not make any specific limitations.

[0106] In one embodiment, such as Figure 3 As shown, after each transmission of the Bluetooth data packet, the method further includes the following steps:

[0107] If a correct ACK response is received within the set time, the next frame of data is sent.

[0108] If a frame data error retransmission request is received within the set time, then the frame data will be retransmitted.

[0109] If no ACK response is received within the set time, the timeout retransmission mechanism will be enabled to retransmit this frame of data.

[0110] In continuous n If the retransmission fails, the data transmission of this frame is determined to have failed.

[0111] Specifically, the reason for retransmitting frame data in this embodiment is as follows:

[0112] (1) Data sending end timer timeout

[0113] The Bluetooth transport layer sends a frame segment for each transmission to facilitate communication. Simultaneously, a set of timers is set to ensure timely data transmission. If no ACK response is received from the responder after the timer expires, the frame segment needs to be retransmitted. Frame loss can occur for two reasons: first, the frame data may be corrupted during transmission; second, the frame may still be being transmitted, but at a slow speed. In the first case, the receiving end may not be aware of this, while in the second case, two identical frame data segments may result.

[0114] (2) Receive ACK request from data receiver to retransmit

[0115] When a retransmission request is received, it may be due to a failed CRC check or an incorrect frame order, thus requiring the frame data to be retransmitted.

[0116] In Bluetooth data transmission, after the protocol is assembled, it is divided into multiple frames and sent out. One frame is sent by the transmitting party, and another frame is received by the receiving end, calculated, and then sent back to the sending party. After the transmitting party sends frame data, it triggers a timer. When an appropriate ACK is received within the timer's specified time, the next frame data is transmitted. If the specified time has not been reached, the frame data is delayed for one cycle and then sent again. Conversely, if an incorrect ACK is received, the frame data is immediately retransmitted; if no response is received within the specified time, the data is retransmitted. If each retransmission fails, the number of retransmissions can be counted to determine if an error has occurred; if multiple retransmissions, such as three, fail, the data transmission is considered a failure.

[0117] In one embodiment, the Bluetooth transmission protocol used during Bluetooth transmission meets the following conditions:

[0118] (1) The Bluetooth transmission protocol is a one-way transmission channel, and the data of the two communicating devices are symmetrical in uplink and downlink, and each uses a feature;

[0119] (2) The Bluetooth transmission protocol itself is only associated with its respective business module;

[0120] (3) Whether a response is required and how to handle timeouts are controlled by the sender of the two communicating parties.

[0121] It should be noted that the current Bluetooth transmission protocol has deep coupling between the service layer command and profile layer, as well as deep coupling between the packet protocol and the service layer. This asymmetry in communication protocols between the mobile client app and the smart watch device prevents the device from directly pushing data to the mobile app in services such as eSIM and WiFi, requiring processing through low-frequency events, resulting in slow processing speeds. Therefore, the protocol designed in this embodiment needs to ensure symmetrical uplink and downlink data transmission between the mobile app and the smart watch device, using a single feature for each.

[0122] Bluetooth universal protocol design such as Figure 4 As shown, Bluetooth 4.0 feature 00000016-0000-3512-2118-0009af100700 indicates the downlink channel usage from the mobile client to the watch client, using the Write without response + Notify notification method; Bluetooth 4.0 feature 00000017-0000-3512-2118-0009af100700 indicates the uplink channel usage from the watch client to the mobile client, also using the Write without response + Notify notification method.

[0123] In one embodiment, the Bluetooth data packet includes a version confirmation packet, a version response packet, a data packet, and an overall response packet;

[0124] The version confirmation package is used to query the version number;

[0125] The version response packet is used to return the version number;

[0126] The data packet contains plaintext and ciphertext data;

[0127] The overall response packet is used to respond to the response message.

[0128] Specifically, under the Bluetooth universal protocol designed in this embodiment, such as Figure 5 Therefore, the transmission packet is divided into a Version Query confirmation packet (information table as follows) Figure 6 (as shown), Version reply response packet, Data data packet (information table as shown) Figure 7 (as shown) and the overall Reply response package (information table as shown) Figure 8 (As shown).

[0129] Among them, such as Figure 7 As shown in the information table of the Data packet:

[0130] FLAG_BEGIN: Indicates the start of transmission;

[0131] FLAG_END: ​​Indicates the end of transmission;

[0132] FLAG_REQUIRE_REPLY: Indicates that the receiver needs to reply;

[0133] FLAG_ENCRYPTION: Indicates whether encryption is selected;

[0134] App ID: Represents the App ID during the session. When the App is the sender, it represents itself; when the Device is the sender, it represents the receiving App.

[0135] Session ID: Represents the session ID, which must remain unchanged throughout a transmission session; it is recommended that the sender increment the ID by 1 for each new transmission.

[0136] Packet index: Represents the packet index;

[0137] Data total size: Optional, indicating the total size of the data, which refers to the number of bytes of plaintext or valid data;

[0138] Module: Optional, indicating the module to which the data belongs;

[0139] Data: Represents the actual data stored;

[0140] R / NONCE: Optional, indicating encrypted NONCE, which is included in the last packet of the encrypted session;

[0141] Plain text CRC32: Optional, represents plaintext CRC32. This field is used to verify whether decryption was successful; the last packet of the encrypted session will contain this information.

[0142] Padding: Optional, indicating the padding of the plaintext. Since AES encryption must be in units of 16 bytes, padding is required when the length of plaintext + R / NONCE + Plain text CRC32 is not an integer multiple of 16 bytes to ensure that the length of the ciphertext area is an integer multiple of 16. The padding content is not checked.

[0143] Furthermore, Figure 8 The Error code information table shown is available in the table below. Figure 9 The error codes for the overall Reply response packet are defined in detail, including several situations that may lead to packet errors: the Data packet's FLAG does not contain FLAG_BEGIN, but index = 0; the Data packet's FLAG contains FLAG_BEGIN, but index != 0; the Data packet's FLAG contains FLAG_BEGIN, but subsequent data does not contain the total data size; the Data packet length is insufficient; the packet sent by the Mobile App does not contain the Source App ID; the packet sent by the Device does not contain the Destination App ID.

[0144] It should be noted that, in order to address the problem that current devices lack application-layer encryption mechanisms, resulting in the plaintext transmission of user privacy information such as message notifications, an application-layer data transmission encryption mechanism is added to provide data confidentiality and protect user privacy. The encryption scheme proposed in this embodiment comprehensively considers the following points:

[0145] (1) The encryption itself must be difficult to crack to a certain level and cannot be cracked by general packet capture analysis, simulated sending of the same data, etc.

[0146] (2) To reduce the complexity of development work, it is best to use the existing App binding mechanism in the current device BLE protocol to reduce the workload;

[0147] (3) The limited availability of BLE bandwidth and other resources.

[0148] Therefore, AES is used to further encrypt data transmission. Verification showed that the performance of the AES algorithm meets the requirements on the DA14697 platform, encrypting 1MB of data in just 2.5 seconds. It supports streaming processing, encrypting while sending and decrypting while receiving, reducing transmission latency and preventing a proportional increase in the size of the transmitted data. Encryption begins upon successful authorization; both the smart device and the mobile client app must ensure that all data transmissions after authorization are encrypted.

[0149] Before a transmission can be made, the data to be encrypted should meet the following conditions simultaneously: the App queries the version number, and the firmware returns data indicating whether the master encryption switch is enabled; the mobile client App and the smart device Daunt have completed authorization.

[0150] In one embodiment, before each transmission of the Bluetooth data packet, the method further includes the following steps:

[0151] During the authorization process, the two communicating parties generate three key encrypted numbers X, R0, and R1, where X is the original encrypted number, and R0 and R1 are the transmitted random numbers of the smart device and the client, respectively.

[0152] The original encrypted number X is XORed with the session ID of each transmission to obtain the AES encryption key key Y for this transmission;

[0153] When the smart device receives the encrypted data sent by the client for the first time, it verifies the received data based on the transmission random number R0.

[0154] When the client receives the first encrypted data sent by the smart device, it verifies the received data based on the transmission random number R1.

[0155] When data transmission is successfully decrypted, both communicating parties increment their respective transmission random numbers by 1 and use the result as the NONCE value for the next transmission.

[0156] If data transmission decryption fails, the sender increments its corresponding transmission random number by 1 and uses it as the NONCE value for the next transmission.

[0157] In one embodiment, such as Figure 10 As shown, the two communicating parties generate three key encryption numbers X, R0, and R1 during the authorization process, including the following steps:

[0158] The client and the smart device interact with ECDH to generate an ECDH public key, an ECDH private key, and a binding key.

[0159] The original encrypted number X is obtained by XORing the ECDH shared cipher P used in the authorization process with the binding key.

[0160] Based on a portion of the bound key, the initial value of the received NONCE on the smart device is obtained as the transmission random number R0;

[0161] Based on another portion of the binding key, the initial value of the client's received NONCE is obtained as the transmission random number R1.

[0162] Specifically, the following is generated during ECDH interaction between the client and the smart device:

[0163] ECDH public key: The ECDH public key is a 48-byte random number that is generated when a smart device or mobile client app initiates an ECDH interaction process.

[0164] ECDH private key: The ECDH key, which is obtained by smart devices and mobile client apps from each other's ECDH public key.

[0165] After keying, a 24-byte key is calculated by combining it with the public key of each end.

[0166] Binding Key: A 16-byte key generated through ECDH key exchange. Its function is to serve as the AES key generated during the binding process.

[0167] P: The ECDH shared password during the authorization process. An ECDH process will also be performed during the authorization process, and the generated password is P.

[0168] Key / X: Authorization key + transmission key, obtained by XORing bytes 8-23 of P (i.e., the last 128 bits) with the binding key.

[0169] R0: Initial value of NONCE received by the device, which is a uint32_t integer obtained by taking bytes 0-3 of P.

[0170] R1: The App receives the initial value of NONCE, which is a uint32_t integer obtained by taking bytes 4-7 of P.

[0171] Furthermore, during authorization by the mobile client app, three key encrypted numbers X, R0, and R1 are generated according to the above process. X is the original encrypted number, a 128-bit array, generated by XORing the 8th to 23rd bytes of the bound key and the ECDH key. X is used to perform a bitwise XOR with the session ID for each transmission (all 16 bytes are XORed with Y) to obtain the AES encrypted key Y for that transmission.

[0172] R0 (uint32_t) is the transmitted random number, which is bytes 0-3 of the ECDH key. It serves as a verification code for the data received by the smart device when the mobile client app sends data for the first time after encryption. The purpose of R0 and R1 is to prevent replay attacks. Since the transmission device does not require the session ID to change, R0 and R1 are needed as a noncce.

[0173] R1 and R0 have opposite functions and are used for verification by the mobile client App. R1 is the 4th to 7th bytes of the ECDH key.

[0174] Furthermore, upon successful decryption in a transmission, both the sender and receiver should increment R1+1 or R0+1 as the next transmission's NONCE. If decryption fails, the receiver should not increment R0 by 1; the sender, regardless of whether the transmission was successful, should increment R1 by 1 for the next transmission. For the receiver, R0 must increase, and the change f can be within the range of 1-100000. This is to prevent packet loss that could cause subsequent transmissions to fail to decrypt.

[0175] In one embodiment, such as Figure 11 As shown, when receiving a Bluetooth data packet sent by the other party, the method further includes the following steps:

[0176] Verify that the frame sequence number of the Bluetooth data packet is correct;

[0177] If the frame sequence number is correct, check if the frame CRC matches. If the frame sequence number is incorrect, send a response to the other party requesting a retransmission of the correct frame due to frame data error.

[0178] If the frame CRC matches, it is determined whether all the data in the transport layer has been received. If the frame CRC does not match, a response is sent to the other party requesting a retransmission of the correct frame due to a frame data error.

[0179] If not all transport layer data is received, an ACK frame is sent to the other party to indicate that the data has been received correctly. If all transport layer data is received, the transport layer CRC is checked to see if it matches.

[0180] If the transport layer CRC matches, an ACK frame is sent to the other party indicating that the data has been received correctly. If the transport layer CRC does not match, the received data is discarded and an ACK frame is sent to the other party indicating that the data has been received incorrectly.

[0181] It should be noted that the verification mechanism is used to verify the correctness of data transmission and is an indispensable component of the transmission system. The verification mechanism proposed in this embodiment is primarily frame verification, supplemented by transport layer verification. Verification is a complete process transmitted from the sending end to the receiving end. The Bluetooth data sending end calculates the message, and then tests it at the Bluetooth data receiving end to ensure the accuracy and reliability of the data. The verification result can be represented by one or more characters. If an error occurs in the verification result, the message of that frame or segment is discarded.

[0182] This embodiment uses a 32-bit CRC checksum, which can effectively reduce the probability of erroneous data caused by collisions. Moreover, with the support of two layers of checksums, namely the transmission layer CRC and the receiving end CRC, the probability of this happening can be basically ignored.

[0183] It should be noted that, to improve transmission efficiency, this embodiment employs a transmission protocol based on Write Without Response (WFR). This eliminates the need for the underlying Bluetooth layer of the OS to return ACK information. Combined with appropriate verification and retransmission mechanisms, this improves Bluetooth transmission speed. Without ACK information, data loss can lead to transmission failure, and neither device may even be aware of the loss. Therefore, it is necessary to design a suitable verification and retransmission mechanism to prevent errors in multi-packet transmission and ensure secure and reliable delivery. Considering the inherent limitations of Bluetooth devices during data transmission, such as slower transmission speeds and susceptibility to interference from other Bluetooth signals, errors can occur during transmission. To ensure the accuracy of Bluetooth data transmission, the verification section in this embodiment focuses on frame CRC and transport layer CRC to guarantee data reliability and availability.

[0184] In one embodiment, such as Figure 12 As shown, after sending multiple Bluetooth data packets, the method further includes the following steps:

[0185] When data packets are lost on the network during data transmission, record the average round-trip time (RTT) at the time of the most recent packet loss event. avg And the congestion window size W at the time of the most recent packet loss. max ;

[0186] The average round-trip time (RTT) recorded at the time of the most recent packet loss. avg Current delay RTT when revisiting the window cur The ratio is used as the congestion level factor;

[0187] Adjust the window size based on the congestion level factor. ,in, , , The congestion window increment rate can be set to 0.4. To reduce the time required to start from the last window, To increase the congestion window size in the absence of packet loss events. The time required.

[0188] It should be noted that determining the current network state: changes in RTT can be used to determine changes in the buffer queue length on the current congested channel, thus allowing us to deduce the changes from data recorded at the time of packet loss. and when revisiting the window To determine the current network status. Increase the congestion window to... Throughout this process, the current delay is determined. And the delay of the last packet loss The size between. If Greater than This indicates that the current buffer queue length at the connection bottleneck is greater than the buffer queue length at the previous connection bottleneck, meaning that the congestion on the connection has increased compared to the last time. If Less than This indicates that the current buffer queue length at the connection bottleneck is less than the previous buffer queue length, meaning the congestion level is lower than before. Therefore, the window size is adjusted based on the current network conditions: if congestion on the channel is increasing, the congestion window size will decrease incrementally; if congestion on the channel is slowing down, the congestion window size will increase more rapidly.

[0189] Moreover, compared with the method in related technologies that uses the comparison between the previous RTT and the current RTT to make judgments, the congestion algorithm used in this embodiment achieves a data transmission speed that is about 28% faster in actual applications than before optimization.

[0190] It's important to note that in internet-based smartwatch transmission, a communication pathway needs to be established between the watch, the phone, and the internet. This requires fast data transmission on the internet side, along with lightweight communication to ensure high data rates and high reliability. Newer internet transmission protocols like QUIC effectively address these issues, and in high-speed internet environments, the QUIC protocol stack is generally chosen as the transmission layer due to its extremely fast transmission speed and efficient Cubic mechanism for controlling network congestion. This embodiment combines Bluetooth and QUIC in a single system. However, when applying QUIC to Bluetooth transmission, the Cubic mechanism relies entirely on packet loss to determine network congestion. Numerous random packet losses occur, leading to constant network re-detection and significantly reduced network utilization, further hindering the effective use of the algorithm. Furthermore, the use of a fixed-size window for calculating packet loss probability reduces the algorithm's sensitivity to network state changes, resulting in low operating efficiency. In addition, real-world network environments are often unstable. The algorithm's window growth is very simplistic, and the window growth rate is not adjusted according to network conditions. When network conditions are poor, the round-trip latency increases.

[0191] A key advantage of the Cubic algorithm is that it can utilize data from the previous probe, allowing the window size to grow slowly around Wmax. However, Cubic can only operate based on the recorded W... max While methods for determining network congestion levels can be relatively weak in controlling congestion and may lead to insufficient utilization of network resources, this embodiment combines round-trip time (RTD) with packet loss to more accurately determine whether the network is currently congested, thereby deciding whether the window size should be reduced. Simultaneously, the current RTD and the RTD of the previous packet loss can be used to determine the current network congestion level compared to the previous one, and adjust the rate at which the congestion window is increased to improve network performance and bandwidth utilization.

[0192] It should be noted that this embodiment combines Bluetooth and QUIC in a single system, enabling the convenient implementation of multiple congestion control algorithms. The congestion control algorithm process is abstracted into multiple callback interfaces, with the two core interfaces, onAck and onLost, handling the logic when the algorithm receives an ACK and detects packet loss. Internally, multiple congestion control algorithms are implemented, including the most common Cubic and New Reno. To facilitate data-driven network experience optimization, connection packet loss rate, RTT, bandwidth, and other information are sampled and analyzed using embedded data, combined with adjustments to each version of the algorithm for effect analysis. Simultaneously, the network environment distribution of real users is simulated in an experimental environment to better pre-evaluate the improvement effect of algorithm adjustments on network experience. Compared to the ordinary Bluetooth + HTTP combination, the no-ACK + QUIC mode is nearly 30% faster in transmission speed.

[0193] In addition, such as Figure 13 As shown, the second embodiment of the present invention proposes a Bluetooth transmission system, the system comprising:

[0194] Transmitting module 10 is used to transmit multiple Bluetooth data packets;

[0195] The judgment module 20 is used to determine whether an ACK response has been correctly received after each Bluetooth data packet is sent.

[0196] The window adjustment module 30 is used to increase the initial maximum transmission window of Bluetooth in response to correctly receiving the ACK response when the output result of the judgment module is yes.

[0197] The window optimization module 40 is used to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold using a binary search method when the output result of the judgment module is negative. The transmission window threshold is less than the initial maximum transmission window.

[0198] The window determination module 50 is used to repeatedly calculate the optimal window size for several transmissions, and determine the best Bluetooth transmission window for data transmission based on the optimal window size for several transmissions.

[0199] This embodiment addresses the issue of slow data transmission in traditional Bluetooth single-channel transmission. To increase data transmission volume, it abandons single-packet transmission and adopts a multi-packet transmission mode without ACK acknowledgment. To solve the problem that when sending data in the multi-packet transmission mode without ACK acknowledgment, if the amount of data sent is too large, it will inevitably cause data congestion, which will seriously affect communication and even cause lag and crashes, the Bluetooth connection is automatically detected when data packets are sent. Then, slow start and binary search are used to detect the maximum transmission window. This allows for dynamic and timely judgment of the Bluetooth transmission window size, preventing data congestion caused by excessive data volume in the early stages of transmission, thereby improving data transmission efficiency.

[0200] In one embodiment, the window determination module 50 specifically includes:

[0201] The variance calculation unit is used to remove the maximum and minimum values ​​from the optimal window size of several transmissions, obtain the filtered window values, and calculate the variance of the sum and average of the filtered window values.

[0202] The optimal window determination unit is used to determine the smallest value among the filtered window values ​​as the optimal Bluetooth transmission window when the variance of the mean and the mean satisfy a set condition.

[0203] The optimal window recalculation unit is used to recalculate the optimal window size for several transmissions when the variance of the sum and average does not meet the set conditions.

[0204] In one embodiment, the system further includes a retransmission module, specifically used for:

[0205] If a correct ACK response is received within the set time, the next frame of data is sent.

[0206] If a frame data error retransmission request is received within the set time, then the frame data will be retransmitted.

[0207] If no ACK response is received within the set time, the timeout retransmission mechanism will be enabled to retransmit this frame of data.

[0208] In continuous n If the retransmission fails, the data transmission of this frame is determined to have failed.

[0209] In one embodiment, the Bluetooth data packet includes a version confirmation packet, a version response packet, a data packet, and an overall response packet;

[0210] The version confirmation package is used to query the version number;

[0211] The version response packet is used to return the version number;

[0212] The data packet contains plaintext and ciphertext data;

[0213] The overall response packet is used to respond to the response message.

[0214] In one embodiment, the Bluetooth transmission protocol used during Bluetooth transmission meets the following conditions:

[0215] The Bluetooth transmission protocol is a unidirectional transmission channel, with symmetrical uplink and downlink data between the two communicating devices, and each device uses a single feature.

[0216] The Bluetooth transmission protocol itself is only associated with its respective business module;

[0217] The sender in the communication controls whether an acknowledgment is required and how timeouts are handled.

[0218] In one embodiment, the system further includes an encryption module, specifically used to perform the following steps:

[0219] During the authorization process, the two communicating parties generate three key encrypted numbers X, R0, and R1, where X is the original encrypted number, and R0 and R1 are the transmitted random numbers of the smart device and the client, respectively.

[0220] The original encrypted number X is XORed with the session ID of each transmission to obtain the AES encryption key key Y for this transmission;

[0221] When the smart device receives the encrypted data sent by the client for the first time, it verifies the received data based on the transmission random number R0.

[0222] When the client receives the first encrypted data sent by the smart device, it verifies the received data based on the transmission random number R1.

[0223] When data transmission is successfully decrypted, both communicating parties increment their respective transmission random numbers by 1 and use the result as the NONCE value for the next transmission.

[0224] If data transmission decryption fails, the sender increments its corresponding transmission random number by 1 and uses it as the NONCE value for the next transmission.

[0225] In one embodiment, the system further includes an authorization module for performing the following steps:

[0226] The client and the smart device interact with ECDH to generate an ECDH public key, an ECDH private key, and a binding key.

[0227] The original encrypted number X is obtained by XORing the ECDH shared cipher P used in the authorization process with the binding key.

[0228] Based on a portion of the bound key, the initial value of the received NONCE on the smart device is obtained as the transmission random number R0;

[0229] Based on another portion of the binding key, the initial value of the client's received NONCE is obtained as the transmission random number R1.

[0230] In one embodiment, the system further includes a verification module, specifically used to perform the following steps:

[0231] Verify that the frame sequence number of the Bluetooth data packet is correct;

[0232] If the frame sequence number is correct, check if the frame CRC matches. If the frame sequence number is incorrect, send a response to the other party requesting a retransmission of the correct frame due to frame data error.

[0233] If the frame CRC matches, it is determined whether all the data in the transport layer has been received. If the frame CRC does not match, a response is sent to the other party requesting a retransmission of the correct frame due to a frame data error.

[0234] If not all transport layer data is received, an ACK frame is sent to the other party to indicate that the data has been received correctly. If all transport layer data is received, the transport layer CRC is checked to see if it matches.

[0235] If the transport layer CRC matches, an ACK frame is sent to the other party indicating that the data has been received correctly. If the transport layer CRC does not match, the received data is discarded and an ACK frame is sent to the other party indicating that the data has been received incorrectly.

[0236] In one embodiment, the system further includes a congestion optimization module, specifically configured to perform the following steps:

[0237] When data packets are lost on the network during data transmission, record the average round-trip time (RTT) at the time of the most recent packet loss event. avg And the congestion window size W at the time of the most recent packet loss. max ;

[0238] The average round-trip time (RTT) recorded at the time of the most recent packet loss. avg Current delay RTT when revisiting the window cur The ratio is used as the congestion level factor;

[0239] Adjust the window size based on the congestion level factor. ,in, , , Increase the rate for the congestion window. To reduce the time required to start from the last window, To increase the congestion window size in the absence of packet loss events. The time required.

[0240] It should be noted that other embodiments or implementation methods of the Bluetooth transmission system described in this invention can refer to the above-described method embodiments, and will not be repeated here.

[0241] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0242] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0243] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A Bluetooth transmission method, characterized in that, The method includes: S10. Detect Bluetooth connection while sending multiple Bluetooth data packets; S20. After each Bluetooth data packet is sent, determine whether an ACK response has been received correctly. If yes, proceed to step S30; otherwise, proceed to step S40. S30. In response to a correct reception of an ACK, increase the initial maximum transmission window of Bluetooth; S40. Use a binary search method to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold, wherein the transmission window threshold is less than the initial maximum transmission window. S50. Repeat S10~S40 to calculate the optimal window size for several transmissions, and determine the best Bluetooth transmission window for data transmission based on the optimal window size for several transmissions. This includes removing the maximum and minimum values ​​from the optimal window sizes for several transmissions to obtain the filtered window values, and calculating the variance of the sum and average of the filtered window values. If the variance of the sum and average meets the set condition, the minimum value among the filtered window values ​​is taken as the optimal Bluetooth transmission window. If the variance of the sum and average does not meet the set condition, the optimal window size for several transmissions is recalculated. Before each transmission of the Bluetooth data packet, the method further includes: During the authorization process, the two communicating parties generate three key encrypted numbers X, R0, and R1, where X is the original encrypted number, and R0 and R1 are the transmitted random numbers of the smart device and the client, respectively. The original encrypted number X is XORed with the session ID of each transmission to obtain the AES encryption key key Y for this transmission; When the smart device receives the encrypted data sent by the client for the first time, it verifies the received data based on the transmission random number R0. When the client receives the first encrypted data sent by the smart device, it verifies the received data based on the transmission random number R1. When data transmission is successfully decrypted, both communicating parties increment their respective transmission random numbers by 1 and use the result as the NONCE value for the next transmission. If data transmission decryption fails, the sender increments its corresponding transmission random number by 1 and uses it as the NONCE value for the next transmission.

2. The Bluetooth transmission method as described in claim 1, characterized in that, After each transmission of the Bluetooth data packet, the method further includes: If a correct ACK response is received within the set time, the next frame of data is sent. If a frame data error retransmission request is received within the set time, then the frame data will be retransmitted. If no ACK response is received within the set time, the timeout retransmission mechanism will be enabled to retransmit this frame of data. In continuous n If the retransmission fails, the data transmission of this frame is determined to have failed.

3. The Bluetooth transmission method as described in claim 1, characterized in that, The Bluetooth data packet includes a version confirmation packet, a version response packet, a data packet, and an overall response packet; The version confirmation package is used to query the version number; The version response packet is used to return the version number; The data packet contains plaintext and ciphertext data; The overall response packet is used to respond to the response message.

4. The Bluetooth transmission method as described in claim 1, characterized in that, The Bluetooth transmission protocol used during Bluetooth transmission must meet the following conditions: The Bluetooth transmission protocol is a unidirectional transmission channel, with symmetrical uplink and downlink data between the two communicating devices, and each device uses a single feature. The Bluetooth transmission protocol itself is only associated with its respective business module; The sender in the communication controls whether an acknowledgment is required and how timeouts are handled.

5. The Bluetooth transmission method as described in claim 1, characterized in that, During the authorization process, the two communicating parties generate three key encryption numbers X, R0, and R1, including: The client and the smart device interact with ECDH to generate an ECDH public key, an ECDH private key, and a binding key. The original encrypted number X is obtained by XORing the ECDH shared cipher P used in the authorization process with the binding key. Based on a portion of the bound key, the initial value of the received NONCE on the smart device is obtained as the transmission random number R0; Based on another portion of the binding key, the initial value of the client's received NONCE is obtained as the transmission random number R1.

6. The Bluetooth transmission method as described in claim 3, characterized in that, Upon receiving a Bluetooth data packet sent by the other party, the method further includes: Verify that the frame sequence number of the Bluetooth data packet is correct; If the frame sequence number is correct, check if the frame CRC matches. If the frame sequence number is incorrect, send a response to the other party requesting a retransmission of the correct frame if the frame data is incorrect. If the frame CRC matches, it is determined whether all the data in the transport layer has been received. If the frame CRC does not match, a response is sent to the other party requesting a retransmission of the correct frame due to a frame data error. If not all transport layer data is received, an ACK frame is sent to the other party to indicate that the data has been received correctly. If all transport layer data is received, the transport layer CRC is checked to see if it matches. If the transport layer CRC matches, an ACK frame is sent to the other party indicating that the data has been received correctly. If the transport layer CRC does not match, the received data is discarded and an ACK frame is sent to the other party indicating that the data has been received incorrectly.

7. The Bluetooth transmission method as described in claim 1, characterized in that, After sending multiple Bluetooth data packets, the method further includes: When data packets are lost on the network during data transmission, record the average round-trip time (RTT) at the time of the most recent packet loss event. avg And the congestion window size W at the time of the most recent packet loss. max ; The average round-trip time (RTT) recorded at the time of the most recent packet loss. avg Current delay RTT when revisiting the window cur The ratio is used as the congestion level factor; Adjust the window size based on the congestion level factor. ,in, , , Increase the rate for the congestion window. To reduce the time required to start from the last window, To increase the congestion window size in the absence of packet loss events. The time required.

8. A Bluetooth transmission system, characterized in that, The system includes: The transmitting module is used to send multiple Bluetooth data packets; The judgment module is used to determine whether an ACK response has been correctly received after each Bluetooth data packet is sent. The window adjustment module is used to increase the initial maximum transmission window of Bluetooth in response to the correct receipt of the ACK response when the output result of the judgment module is yes. The window optimization module is used to find the optimal window size for the current transmission between the initial maximum transmission window and the transmission window threshold when the output result of the judgment module is negative. The transmission window threshold is less than the initial maximum transmission window. The window determination module is used to repeatedly execute the steps from the sending module to the window optimization module to calculate the optimal window size for several transmissions, and determine the best Bluetooth transmission window for data transmission based on the optimal window size for several transmissions. The window determination module specifically includes: The variance calculation unit is used to remove the maximum and minimum values ​​from the optimal window size of several transmissions, obtain the filtered window values, and calculate the variance of the sum and average of the filtered window values. The optimal window determination unit is used to determine the smallest value among the filtered window values ​​as the optimal Bluetooth transmission window when the variance of the mean and the mean satisfy a set condition. The optimal window recalculation unit is used to recalculate the optimal window size for several transmissions when the variance of the mean does not meet the set conditions. The system also includes an encryption module, specifically used to perform the following steps: During the authorization process, the two communicating parties generate three key encrypted numbers X, R0, and R1, where X is the original encrypted number, and R0 and R1 are the transmitted random numbers of the smart device and the client, respectively. The original encrypted number X is XORed with the session ID of each transmission to obtain the AES encryption key key Y for this transmission; When the smart device receives the encrypted data sent by the client for the first time, it verifies the received data based on the transmission random number R0. When the client receives the first encrypted data sent by the smart device, it verifies the received data based on the transmission random number R1. When data transmission is successfully decrypted, both communicating parties increment their respective transmission random numbers by 1 and use the result as the NONCE value for the next transmission. If data transmission decryption fails, the sender increments its corresponding transmission random number by 1 and uses it as the NONCE value for the next transmission.

Images