A Bluetooth data transmission system and method

Abstract

This invention relates to a Bluetooth data transmission system and method. The system includes a paired first Bluetooth device and a second Bluetooth device, configured to establish a transmission mode comprising a first phase and a second phase. The first Bluetooth device is configured to continuously send data packets containing consecutive sequence numbers to the second Bluetooth device during the first phase. The second Bluetooth device is configured to send an acknowledgment packet containing sequence numbers of data packets requiring retransmission to the first Bluetooth device during the second phase. This method increases the utilization efficiency of Bluetooth technology in the same amount of time by continuously switching between the first and second phases of the transmission mode between the first and second Bluetooth devices, thereby improving the transmission rate of Bluetooth Low Energy technology.

Description

Technical Field

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

[0002] Bluetooth is a short-range wireless communication technology that enables data exchange between fixed and mobile devices. According to the current Bluetooth protocol specification, it primarily proposes three modes: "Bluetooth Low Energy," "Traditional Bluetooth," and "Bluetooth High Speed." High Speed ​​Bluetooth focuses on data exchange and transmission; Traditional Bluetooth emphasizes information communication and device connectivity; Bluetooth Low Energy prioritizes connections between devices that don't require excessive bandwidth. Its predecessor was Nokia's Wibree technology, originally developed as an extremely low-power mobile wireless communication technology specifically for mobile devices. After being adopted and standardized by the Bluetooth SIG, it was renamed Bluetooth Low Energy (BLE). Bluetooth Low Energy (BLE) is a short-range, low-cost, interoperable wireless technology that utilizes many intelligent methods to minimize power consumption. BLE's operating mode is well-suited for transmitting data from miniature wireless sensors (exchanging data every half second) or other peripherals using fully asynchronous communication, such as remote controls. These devices send very small amounts of data (typically a few bytes) and transmit very infrequently (e.g., a few times per second to once per minute, or even less).

[0003] The classic Bluetooth Low Energy (BLE) transmission scenario typically involves a pair of BLE devices: a Bluetooth master (Central) and a Bluetooth slave (Peripheral). The slave typically acts as the server (ATT Server), generating the data. The master acts as the client (ATT Client), sending control commands to the server and receiving data from it. Before data transmission begins, the BLE devices need to establish synchronization and enter a connected state. Based on agreed-upon connection intervals and other parameters, they periodically transmit and receive data at specific intervals. The master sends a data packet (or empty packet) at the beginning of each connection interval. After a fixed connection interval (T_IFS, e.g., 150µs), the slave replies with a data packet (or empty packet). This interaction is repeated to complete the data transmission process. When one application layer generates data, the new data, after adding ATT and L2CAP headers, is sent to the other device at the aforementioned specific intervals. Data retransmission and flow control are achieved through the Serial Number (SN) and Expected Serial Number (NESN) flags in the header (LLHeader). However, while achieving the goal of low power consumption, Bluetooth Low Energy technology still has considerable room for improvement in transmission efficiency.

[0004] Existing technologies, such as the data transmission method, BLE device, and BLE chip proposed in patent document CN111801955A, can improve data transmission rates. The method includes: a first device interacting with a second device via a first link, and the first device interacting with a third device via a second link; the first device determining the first link as an active link and the second link as an idle link; after completing one data interaction via the idle link within a connection time interval (CI) corresponding to the idle link, the first device stops data interaction on the idle link for N CIs, where N is a positive integer; during the period when data interaction on the idle link is stopped, the first device performs data interaction via the active link within each CI corresponding to the active link. This technical solution reduces the number of data interactions via the idle link and increases the number of data transmissions via the active link. However, with the increased number of data transmissions via the active link, the energy consumption of this solution also increases accordingly.

[0005] Existing technologies, such as the patent document with publication number CN115022852A, disclose a method and electronic device for controlling Bluetooth transmission rate, which relates to the field of communication technology. For scenarios where a PC initiates screen mirroring to a smart screen, this application independently develops a BLE driver on the PC side and provides a BLE driver interface API for the communication module. The PC-side communication module can call the BLE driver interface to set BLE driver parameters, such as the BLE connection event interval, and initiate a connection. After establishing a BLE connection, the PC-side communication module sends device binding, authentication, and Wi-Fi P2P parameter negotiation data to the smart screen according to the set BLE connection event interval. The BLE connection event interval can be set to a smaller value (7.5ms) defined in the BLE specification through the BLE driver interface. This technical solution achieves a rate increase by using a smaller connection interval than specified in the specification. However, reducing the connection interval means sending data packets more frequently. The low power consumption of Bluetooth Low Energy technology is mainly achieved by entering a sleep state during the waiting time of the connection interval. Reducing the connection interval means reducing the sleep time, which increases the power consumption requirement, contradicting the low power consumption requirement.

[0006] Furthermore, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the inventors studied a large number of documents and patents when making this invention, but due to space limitations, not all details and contents were listed in detail. However, this does not mean that the present invention does not possess the features of these prior art. On the contrary, the present invention already possesses all the features of the prior art, and the applicant reserves the right to add relevant prior art to the background art. Summary of the Invention

[0007] To address the drawback of increased power consumption in existing technical solutions, this application proposes a Bluetooth data transmission system and method aimed at improving the low-power Bluetooth transmission rate.

[0008] After calculating and analyzing the transmission efficiency of Bluetooth Low Energy (BLE) technology in typical scenarios, the inventors of this application found that after transmitting 100 bytes of data (occupying a duration of 472µs), approximately 350µs of time cannot be effectively utilized. If this 350µs of time can be fully utilized to send data, then there is room for further improvement in the transmission rate of BLE in typical scenarios.

[0009] Therefore, this application proposes a Bluetooth data transmission system, including a first Bluetooth device and a second Bluetooth device that are paired and connected, characterized in that the first Bluetooth device and the second Bluetooth device are configured to establish a transmission mode (Flush Mode) including a first stage (Stage 1) and a second stage (Stage 2); the first Bluetooth device is configured to continuously send data packets containing consecutive data packet sequence numbers to the second Bluetooth device in the first stage; and the second Bluetooth device is configured to send an acknowledgment packet containing the sequence number of the data packet that needs to be retransmitted to the first Bluetooth device in the second stage.

[0010] Preferably, the first Bluetooth device is further configured to continuously send incrementally increasing data packets containing consecutive sequence numbers to the second Bluetooth device during the second phase. The data packets sent by the first Bluetooth device also include application layer data. "Incrementally increasing data packets containing consecutive sequence numbers" refers to a portion of data packets arranged according to the original data transmission queue, following the data packets already sent to the second Bluetooth device in the first phase, with their sequence numbers incremented based on the sequence numbers of the data packets sent in the first phase. When a data packet needs to be retransmitted, the data packet requiring retransmission is inserted into the transmission sequence, and then the data packets with incremented sequence numbers are placed after the retransmitted data packets.

[0011] Preferably, after the first Bluetooth device and the second Bluetooth device are paired and connected, the first Bluetooth device sends a request to enter the transmission mode to the second Bluetooth device, and negotiates with the second Bluetooth device the duration of the first phase and the start time of the transmission mode.

[0012] Preferably, the first Bluetooth device and the second Bluetooth device enter the transmission mode synchronously after the start time of the transmission mode; after the duration of the first phase ends, the first Bluetooth device and the second Bluetooth device synchronously switch to the second phase.

[0013] Preferably, the confirmation packet sent by the second Bluetooth device in the second phase also includes the duration of the second phase.

[0014] Preferably, the second Bluetooth device is also capable of sending data packets or empty packets for data transmission to the first Bluetooth device during the second phase.

[0015] Preferably, after the duration of the second phase ends, the first Bluetooth device and the second Bluetooth device synchronize again to enter the first phase; either the first Bluetooth device or the second Bluetooth device can send a request to exit the transmission mode to exit the transmission mode.

[0016] Preferably, the second Bluetooth device determines whether data is lost based on the continuity of data packet sequence numbers in the first stage, and the determination criterion is as follows:

[0017] If the sequence numbers of the data packets received by the second Bluetooth device are consecutive, it is determined that the data packets have not been lost and the first Bluetooth device does not need to retransmit the data packets.

[0018] If the sequence number of the data packet received by the second Bluetooth device is not consecutive, it is determined that the data packet is lost, and the first Bluetooth device needs to retransmit the lost data packet.

[0019] Preferably, when the second Bluetooth device predicts that the local cache space is insufficient, the second Bluetooth device can adjust the data transmission rate of the transmission mode by adjusting the duration of the second phase.

[0020] This application also proposes a data transmission method for a Bluetooth data transmission system, providing a first Bluetooth device and a second Bluetooth device that are paired and connected.

[0021] Establish a transmission mode between the first Bluetooth device and the second Bluetooth device, including a first phase and a second phase;

[0022] In the first phase, the first Bluetooth device continuously sends data packets containing consecutive data packet sequence numbers to the second Bluetooth device;

[0023] In the second phase, the second Bluetooth device sends an acknowledgment packet containing the sequence number of the data packet that needs to be retransmitted to the first Bluetooth device. Attached Figure Description

[0024] Figure 1 This is a simplified flowchart illustrating the Bluetooth data transmission method of the present invention.

[0025] Figure 2 This is a simplified structural diagram of the Bluetooth data transmission system of the present invention. Detailed Implementation

[0026] The present invention will now be described in detail with reference to the accompanying drawings.

[0027] Example 1

[0028] Figure 1 A simplified flowchart illustrating a transmission method for implementing a Bluetooth data transmission system according to this application is shown. The system includes a paired first Bluetooth device and a second Bluetooth device. The first and second Bluetooth devices are configured to establish a transmission mode including a first phase and a second phase. The first Bluetooth device is configured to continuously send data packets containing consecutive sequence numbers to the second Bluetooth device during the first phase. The second Bluetooth device is configured to send an acknowledgment packet containing the sequence number of the data packet requiring retransmission to the first Bluetooth device during the second phase. After calculating and analyzing the transmission efficiency of Bluetooth Low Energy (BLE) technology in typical scenarios, the inventors of this application found that approximately 350µs of time is unusable after every 100 bytes of data transmitted (occupying a duration of 472µs). If this 350µs of time can be fully utilized for data transmission, there is potential for further improving the transmission rate of BLE in typical scenarios.

[0029] The classic Bluetooth Low Energy (BLE) transmission scenario typically involves a pair of BLE devices: a Bluetooth master (Central) and a Bluetooth slave (Peripheral). The slave typically acts as the server (ATT Server), generating the data. The master acts as the client (ATT Client), sending control commands to the server and receiving data from it. Before data transmission begins, the BLE devices need to establish synchronization and enter a connected state. Based on agreed-upon connection intervals and other parameters, they periodically transmit and receive data at specific intervals. The master sends a data packet (or empty packet) at the beginning of each connection interval. After a fixed connection interval (T_IFS, e.g., 150µs), the slave replies with a data packet (or empty packet). This interaction is repeated to complete the data transmission process. When one application layer generates data, the new data, after adding ATT and L2CAP headers, is sent to the other device at the aforementioned specific intervals. Data retransmission and flow control are achieved through the sequence number (SN) and expected sequence number (NESN) flags in the header (LLHeader).

[0030] Specifically, assuming the application layer has 100 bytes of data and a 2M PHY transmission rate, the length of the air interface packet would be 100 bytes + 3 bytes (ATT) + 4 bytes (L2CAP) + fixed overhead of approximately 118 bytes, taking 472µs. After the Bluetooth host sends this data packet, it needs to open the receive mode after T_IFS (150µs). After receiving the data packet from the other party, it then spends another T_IFS (150µs) to switch back to transmit mode to send the next data packet. In some typical scenarios, such as when the Bluetooth slave transmits images or video streams, the scenario is singular, the service is fixed, and all transmissions are unidirectional, meaning only the Bluetooth slave is sending the payload, while the Bluetooth host returns empty packets. Continuing with the 100-byte data packet example above, in this scenario, without considering other overhead caused by the specific implementation, the data transmission rate is approximately 121.6KByte / s. However, approximately 350µs of time will be unusable after every 100-byte packet (taking 472µs).

[0031] Preferably, the sending window and the confirmation window are determined by a transmission mode under the Bluetooth Low Energy protocol that has a first stage and a second stage, which is different from the traditional connection mode. The first Bluetooth device and the second Bluetooth device can switch between the first stage and the second stage of the transmission mode to transmit data in order to build a low-power data transmission channel between the two parties.

[0032] Preferably, based on the transmission mode, the first Bluetooth device and the second Bluetooth device adjust the traditional fixed switching mode of the send and receive windows to a mode of sending window and acknowledgment window, wherein the sending window is used to continuously send application layer data packets, and the acknowledgment window is used to reply with an acknowledgment packet containing the number of the data packet that needs to be retransmitted.

[0033] Specifically, this system adjusts the existing fixed switching mode of send and receive windows to a sending window and an acknowledgment window. The first Bluetooth device can continuously send data packets during the first and second phases of the transmission mode based on the sending window; the second Bluetooth device can send acknowledgment packets, small-payload data packets, or empty packets during the second phase of the transmission mode based on the acknowledgment window, with the second Bluetooth device prioritizing the sending of acknowledgment packets. The sending window is used to continuously send application layer data, and the sent data packets contain consecutive sequence numbers of data packets and the data to be transmitted; the acknowledgment window is used to reply with acknowledgment packets containing the sequence numbers of data packets that need to be retransmitted.

[0034] Preferably, the durations of the first and second phases are determined by a first threshold (Threshold_1) and a second threshold (Threshold_2) negotiated by the first and second Bluetooth devices, respectively. The units of the first and second thresholds are single connection intervals. The first phase lasts for the duration of the first threshold before transitioning to the second phase, and the second phase lasts for the duration of the second threshold before transitioning back to the first phase. In other words, the first and second Bluetooth devices determine the durations of the sending and acknowledgment windows based on the first and second thresholds. The sending window switches to the acknowledgment window after lasting for the duration of the first threshold, and the acknowledgment window switches back to the sending window after lasting for the duration of the second threshold.

[0035] Specifically, in Flush Mode, both devices use Threshold_1 and Threshold_2 to determine the duration of the sending and acknowledgment windows. When the time reaches the Threshold_1 threshold, the second phase, the acknowledgment window, begins. The second Bluetooth device includes the sequence number of the data packet to be retransmitted in the acknowledgment packet. The first Bluetooth device receives the acknowledgment packet and adds the data to be retransmitted to the next transmission packet sequence. When Threshold_2 is triggered, the system switches back to the sending window. Therefore, the interaction in Flush Mode can be divided into two phases.

[0036] Preferably, the first Bluetooth device and the second Bluetooth device are able to switch between data transmission during at least the first and second phases of the transmission mode, thereby establishing a low-power data transmission channel between the two devices.

[0037] Preferably, during the first phase of the transmission mode, the first Bluetooth device continuously transmits data packets based on a transmission window within a first threshold.

[0038] During the second phase of the transmission mode, the second Bluetooth device continuously sends acknowledgment packets and / or data packets and / or empty packets that need to be transmitted within the second threshold, while the first Bluetooth device continues to send data packets within the second threshold.

[0039] Specifically, in the first phase (sending window): the first Bluetooth device continuously sends data packets within the Threshold_1 time period, and there is no receiving window during the first phase; in the second phase (acknowledgment window): the second Bluetooth device sends an acknowledgment packet / a small number of data packets to be transmitted / an empty packet within the Threshold_2 time period, and the first Bluetooth device continues to continuously send data packets within the Threshold_2 time period. According to the Bluetooth Low Energy protocol, the two parties alternately send and receive interactive data.

[0040] Preferably, the transmission mode is entered and exited based on specific entry and exit commands, and one of the first Bluetooth device and the second Bluetooth device is able to issue an exit command.

[0041] When the application layer determines that one-way data transmission is required in a specific scenario, the application layer issues a first command that includes at least parameters for entering or exiting the transmission mode, the start time parameter of the transmission mode, and the maximum first threshold parameter that the first Bluetooth device can accept. The first Bluetooth device and the second Bluetooth device will enter the transmission mode after the connection interval of the start time parameter.

[0042] When it is necessary to exit the transmission mode, one of the first Bluetooth devices or the second Bluetooth device sends a first command and sets the entry or exit parameter to exit, and the other party replies with a second command containing the maximum first threshold parameter that the second Bluetooth device can accept, and then both parties exit the transmission mode.

[0043] Specifically, assume that the device that needs to send a large amount of data is the first Bluetooth device and the device that needs to send a large amount of data is the second Bluetooth device.

[0044] When the application layer deems that the scenario requires a large amount of unidirectional data transmission, it can use the following newly added command, LLControl, to control entering or exiting the transmission mode. First command: LL_FLUSH_MODE_REQ; Second command: LL_FLUSH_MODE_RSP.

[0045] The first command LL_FLUSH_MODE_REQ should contain at least the following:

[0046] LL_FLUSH_MODE_REQ:

[0047] Comumand

[0048] Instant

[0049] Threshold_1_Max

[0050] Command, which occupies 1 byte, can be assigned a value of 0 or 1. A value of 0 indicates entering Flush Mode, and a value of 1 indicates exiting Flush Mode;

[0051] Instant, which occupies two bytes, is used to indicate how many connection events the Command of both parties takes effect after. This part will use the existing Bluetooth Low Energy Instant update process protocol.

[0052] Threshold_1_Max, which occupies two bytes and is the number of connection events, represents the maximum duration of the first phase that the first Bluetooth device can accept.

[0053] The second command LL_FLUSH_MODE_RSP should contain at least the following:

[0054] LL_FLUSH_MODE_RSP:

[0055] Threshold_1

[0056] Threshold_1, which occupies two bytes and is the number of connection events, represents the maximum duration of the first phase that the second Bluetooth device can accept.

[0057] The application layer initiates the first command. Receiving the second command indicates that both parties will enter transmission mode after an instant. The final Threshold_1 is the minimum value between the two. If the second command is not received after the timeout, it means the command failed, and the timeout process will use the existing Bluetooth Low Energy procedure to respond to the timeout handling protocol.

[0058] If either party needs to exit the transmission mode, it can send the first command in the second phase and set Command to 1. The other party will reply with the second command, in which the Threshold-related values ​​will no longer be effective.

[0059] Preferably, the system redefines the air interface data packet of the transmission mode based on the traditional data packet format of the Bluetooth Low Energy protocol; the first Bluetooth device sends data according to a specific data packet format in the transmission mode. The data packet sent by the first Bluetooth device based on the sending window stores at least application layer data and data packet sequence number; the acknowledgment packet sent by the second Bluetooth device based on the acknowledgment window stores at least second threshold information and the sequence number of the data packet that needs to be retransmitted.

[0060] Specifically, the air interface data packet format defined in the transmission mode is as follows:

[0061]

[0062]

[0063] The Flush Mode Header is a new addition to this application; the rest uses the traditional Bluetooth Low Energy protocol. The Flush Mode Header includes at least:

[0064] Type, which occupies 1 byte, is assigned a value of 0 to indicate a data packet (DATA) and a value of 1 to indicate an acknowledgment packet (ACK);

[0065] The Packet Counter occupies 15 bytes and represents the sequence number of the data packets, starting from 0 and incrementing to a maximum of 0x7FFF;

[0066] The payload, or valid data, has a size that depends on the Data PDU length and ATT MTU.

[0067] When Type is 0, Payload is the data to be transmitted, in the following format:

[0068] Date Byte 0,

[0069] Date Byte 1,

[0070] Date Byte 2,

[0071] ......,

[0072] Data Byte MAX

[0073] The Data Byte MAX is derived from the MTU; when Type is 1, the Payload contains Threshold_2 and the number that needs to be retransmitted, in the following format:

[0074] Threshold_2,

[0075] Packet Counter

[0076] Packet Counter

[0077] ......,

[0078] Packet Counter MAX

[0079] Each item is 16 bytes long, and Packet Counter MAX is derived from the MTU. Threshold_2 indicates that both parties should enter the first phase after Threshold_2, starting from the second phase. It's important to note that in the first phase, the SN and NESN flow control flags in the LL Header are no longer effective. When Type is Data, the Payload is application layer data. When Type is ACK, the Payload is a combination of Threshold_2 and the Packet Counters that need to be retransmitted. Each Packet Counter occupies 16 bits, arranged sequentially. When the MTU is exceeded, it should be processed according to the Bluetooth Low Energy protocol, i.e., setting MD in the LL Header to 1 and splitting it into multiple data packets.

[0080] Specifically, the first Bluetooth device will transmit data in the following format:

[0081] Preamble

[0082] Access Address

[0083] LL Header: MD=1, Length=13

[0084] L2CAP Header

[0085] ATT Header

[0086] Flush Mode Header:Type=0,Packet Counter++

[0087] Payload=data

[0088] In this setup, the Packet Counter increments from 1, while the Payload represents the data to be sent. In the first phase, data packets are continuously sent, and the second Bluetooth device continuously receives them. Once Threshold_1 is triggered, both devices synchronize and enter the second phase after Threshold_1 connection events from the start of the first phase. If the second Bluetooth device has a small amount of data to send, it can do so during the second phase.

[0089] Preferably, in the first stage, the second Bluetooth device determines whether data is lost based on the continuity of the sequence numbers of the received data packets, and the determination criterion is as follows:

[0090] If the sequence numbers of the data packets received by the second Bluetooth device are consecutive, it is determined that the data packets have not been lost and the first Bluetooth device does not need to retransmit the data packets.

[0091] If the sequence numbers of the data packets received by the second Bluetooth device are not consecutive, it is determined that the data packets are lost, and the first Bluetooth device needs to retransmit the lost data packets.

[0092] In the first phase of the transmission mode, the second Bluetooth device determines whether data is lost based on the continuity of the received data number. If the second Bluetooth device determines that the data packet is lost, in the second phase, the second Bluetooth device combines an acknowledgment packet according to a specific format and sends the acknowledgment packet to the first Bluetooth device. After receiving the acknowledgment packet, the first Bluetooth device resends the data packet with the corresponding number based on the acknowledgment packet.

[0093] Specifically, assume the device sending the large amount of data is the first Bluetooth device and the device sending the second Bluetooth device. If, during a certain first phase, the second Bluetooth device's local data packet numbering is missing (0xA, 0xB), causing a discontinuous numbering sequence, then the data packet with number (0xA, 0xB) can be considered lost. Assuming that the current channel quality is good according to the channel map information, and threshold_2 is set to 1, meaning the second phase begins after one connection event. Upon entering the second phase, the second Bluetooth device should assemble the acknowledgment packet according to the following format:

[0094] Preamble

[0095] Access Address

[0096] LL Header: MD=1, Length=13

[0097] L2CAP Header

[0098] ATT Header

[0099] Flush Mode Header: Type=1, Packet Counter

[0100] Payload, Threshold2 = 1

[0101] Packet Counter = 0xA

[0102] Packet Counter = 0xB

[0103] After receiving the acknowledgment packet, the first Bluetooth device re-places the data packet numbered (0xA, 0xB) in the pending data and continues sending data. At the start of the next connection event, both parties synchronously enter the first phase. If the channel encounters sudden interference, causing the acknowledgment packet in the second phase to fail to be sent, the second Bluetooth device should record the information and resend the previous acknowledgment packet in the next second phase.

[0104] Specifically, the first and second phases of the transmission mode are switched as follows: In the first phase, the first Bluetooth device continuously sends data packets, and the second Bluetooth device continuously receives them. When Threshold_1 is triggered, both parties begin to synchronize and enter the second phase after Threshold_1 connection events from the start of the first phase. In the second phase, the second Bluetooth device first determines Threshold_2 based on the channel quality, combines the sequence numbers of the data packets that need to be retransmitted, transmits an acknowledgment packet, and both parties activate the SN and NESN flags, while the first Bluetooth device continues to increment the Packet Counter and transmit data packets. When the acknowledgment packet of the second Bluetooth device is successfully transmitted, it should continue to transmit empty packets according to the Bluetooth Low Energy protocol. The first Bluetooth device then checks the acknowledgment packet and adds the data packet corresponding to the retransmission number to the transmission sequence. Data packet reception and transmission alternate until Threshold_2 is triggered, at which point both parties will begin to synchronize and switch back to the first phase state after Threshold_2 connection events from the start of the second phase.

[0105] Preferably, when the second Bluetooth device predicts that the local cache space is insufficient, the second Bluetooth device can adjust the data transmission rate by adjusting the size of the second threshold within the second phase; the second Bluetooth device can also implement flow control within the second phase using the serial number and the expected serial number.

[0106] Specifically, assuming the device sending a large amount of data is the first Bluetooth device and the other is the second Bluetooth device, the flow control method in this system during transmission mode is as follows: When the second Bluetooth device deems its local buffer insufficient and needs to slow down the data reception rate, it can increase the Threshold_2 value in the second stage. This keeps both devices in the second stage, receiving data in the traditional Bluetooth Low Energy mode, with a lower data rate compared to the first stage. The second Bluetooth device can determine if its buffer is sufficient by detecting whether it has reached a certain threshold. For example, if the second Bluetooth device detects that its buffer has reached 90% of the total buffer space, it considers its local buffer space insufficient and needs to slow down the data reception rate, thus performing the above operation. The method for determining if the buffer is insufficient is not limited to this; other methods that can determine buffer insufficiency can also be applied.

[0107] Preferably, if the second Bluetooth device has further flow control requirements, flow control can be implemented in the second phase using the SN and NESN flags in accordance with the Bluetooth Low Energy protocol.

[0108] Example 2

[0109] This application also proposes a data transmission method for a Bluetooth data transmission system, which provides a first Bluetooth device and a second Bluetooth device that are paired and connected.

[0110] The first Bluetooth device and the second Bluetooth device jointly negotiate and determine the first threshold for the duration of the first phase of the transmission mode and the start time of the transmission mode. The first Bluetooth device and the second Bluetooth device enter the first phase of the transmission mode after the start time.

[0111] The first Bluetooth device continuously sends data packets containing consecutive data packet sequence numbers based on the sending window until the first threshold is triggered, and the first Bluetooth device and the second Bluetooth device synchronously switch to the second stage.

[0112] In the second phase, the first Bluetooth device continues to send data packets containing consecutive data packet sequence numbers based on the sending window; the second Bluetooth device is at least able to send acknowledgment packets, small-payload data packets, or empty packets in the second phase of the transmission mode based on the acknowledgment window, wherein the second Bluetooth device prioritizes sending acknowledgment packets;

[0113] Once the first Bluetooth device and the second Bluetooth device trigger the second threshold, both parties return to the first stage and repeat the operations from the first stage to the second stage to complete the data transmission.

[0114] Specifically, the method can be described as follows:

[0115] Step 1: The party that needs to send a large amount of data sends a request to enter Flush Mode after the connection is established, and negotiates Threshold_1 and the start time of Flush Mode.

[0116] Step 2: After the Flush Mode starts, both parties enter the first phase, during which the SN and NESN flags are no longer effective. The first Bluetooth device sends data (containing consecutive packet sequence numbers) until the Threshold_1 threshold is triggered, and both parties synchronously switch to the second phase.

[0117] Step 3: In the second phase, the SN and NESN flags take effect, and both parties exchange data according to the Bluetooth Low Energy protocol. The second Bluetooth device needs to send an acknowledgment packet first, which is the sequence number of the data packet that failed to transmit in the first phase. Furthermore, Threshold_2 information needs to be added to each acknowledgment packet (determined based on the current channel quality and flow control requirements). After a successful acknowledgment packet transmission, data or an empty packet can be sent according to application requirements. The first Bluetooth device continues to send data according to the traditional Bluetooth Low Energy protocol until both parties trigger Threshold_2.

[0118] Step 4: After Threshold_2 is triggered, both parties return to the first phase and repeat Step 2.

[0119] This application can also demonstrate the Bluetooth data transmission system and method based on this application, as follows:

[0120] Assume that the device that needs to send a large amount of data is the first Bluetooth device, and the other device is the second Bluetooth device;

[0121] Once the connection is successfully established, assuming the data rate is 2M PHY, the connection interval is 10ms, and both parties agree on an LLData Length of 109 bytes, when the peripheral device has a large amount of data to send and decides to enter Flush Mode, it sends the LL_FLUSH_MODE_REQ command to the central device.

[0122] LL_FLUSH_MODE_REQ:

[0123] Instant=1000

[0124] Threshold_1Max = 10

[0125] After receiving the data, Central sends LL_FLUSH_MODE_RSP.

[0126] LL_FLUSH_MODE_RSP:

[0127] Threshold_1 = 5

[0128] When Peripheral receives LL_FLUSH_MODE_RSP, the final Threshold_1 is set to 5;

[0129] Both parties enter Flush Mode simultaneously when the event counter equals Instant;

[0130] Without using CTE, after adding a packet header and fixed overhead, each packet is 120 bytes. At a 2M PHY rate, the time slot width of each packet is 480µs, so 20 packets can be sent within 10ms.

[0131] The first data packet sent by Peripheral is:

[0132] Packet 1:

[0133] Preamble

[0134] Access Address

[0135] LL Header: MD=1, Length=109

[0136] L2CAP Header

[0137] ATT Header

[0138] Flush Mode Header: Type=0, Packet Counter=1

[0139] Payload = 100 Bytes

[0140] When Central receives data, it verifies the CRC. If successful, it caches the data locally and keeps the receive window open.

[0141] Peripheral continues to send a second data packet:

[0142] Packet 2:

[0143] Preamble

[0144] Access Address

[0145] LL Header: MD=1, Length=109

[0146] L2CAP Header

[0147] ATT Header

[0148] Flush Mode Header: Type=0, Packet Counter=2

[0149] Payload = 100 Bytes

[0150] After receiving the data, Central performs the same operations as the previous packet;

[0151] After the Peripheral sends the 20th packet, it enters the next connection interval and continues to send data until it reaches Threshold_1(5). At this point, a total of 20*5=100 data packets have been sent.

[0152] Central and Peripheral triggered the Threshold_1(5) threshold. Peripheral opened reception in the 6th connection interval, while Central started sending acknowledgment packets in the 6th connection interval.

[0153] Assuming the channel is good at this time, Central believes that all acknowledgment packets can be received within one connection interval (10ms). If Central does not receive packets with Packet Counters of 0xA and 0xB, then the acknowledgment packet sent by Central will be...

[0154] Packet:

[0155]

[0156]

[0157] At this point in the second phase, one of the following situations may occur.

[0158] In the first scenario: Central sends an acknowledgment packet, Peripheral receives the acknowledgment packet and begins transmitting the 101st data packet after T_IFS. Central also receives the 101st data packet after T_IFS. By checking the SN and NESN flags, it can be confirmed that Peripheral has correctly received the acknowledgment packet. Therefore, Central will send an empty packet after T_IFS, and the two parties will exchange data in the second phase in the traditional Bluetooth Low Energy manner.

[0159] The second scenario: Central sends an acknowledgment packet, but due to channel interference, the acknowledgment packet is lost. Peripheral starts transmitting the 101st data packet after T_IFS, and Central receives the 101st data packet after T_IFS. By checking the SN and NESN flags, it is found that the acknowledgment packet is lost, so Central will retransmit the acknowledgment packet after T_IFS.

[0160] The third scenario: Central sends an acknowledgment packet, Peripheral receives the acknowledgment packet, and starts transmitting the 101st data packet after T_IFS. If Central does not receive the 101st data packet after T_IFS, i.e. data loss, Central will repeatedly send the acknowledgment packet according to the Bluetooth Low Energy protocol.

[0161] The fourth scenario: The Central terminal sends an acknowledgment packet, but the Peripheral terminal does not receive it. Since the two parties have not completed data exchange within the connection interval (10ms), the Central terminal should increment Threshold_2 and continue sending acknowledgment packets in the next connection interval until both parties consider the acknowledgment packet to have been successfully sent. Both parties will use the Threshold_2 in the new acknowledgment packet as the effective value. Because Threshold_2 is dynamically updated based on channel quality, the fourth scenario is less likely to occur.

[0162] When the Threshold_2 threshold is triggered, both parties will synchronously switch to the first phase;

[0163] Assuming good channel quality, i.e., in the first case, taking a combination of Stage 1 and Stage 2 with a duration of 6 connection intervals (60ms) as an example, the comparison of transmission efficiency between Flush Mode and the traditional method is as follows:

[0164] Traditional mode: LL Data Length is 109 bytes, of which 102 bytes are application layer data, each sent packet is 480µs, T_IFS is 150µs, the received packet is 44µs (empty packet), the next T_IFS is 150µs, and then the next sent packet. Thus, 72 data packets are sent in 60ms, and the total application layer data is 7344 bytes.

[0165] Flush Mode: LL Data Length is 109 bytes, of which 100 bytes are application layer data. Each transmitted packet is 480µs. In the first phase, 104 data packets are transmitted, totaling 10400 bytes of application layer data. In the second phase, 12 data packets are transmitted, totaling 1200 bytes of application layer data, for a total application layer data of 11600 bytes.

[0166] Therefore, under this configuration and scenario, the data transmission efficiency of this system is improved by 57% compared with the traditional method.

[0167] Example 3

[0168] This embodiment is a supplement or improvement to Embodiments 1 and 2, and repeated content will not be described again.

[0169] The first and second Bluetooth devices in this system are primarily electronic devices, according to... Figure 2 As shown, the Bluetooth data transmission system of this application can be incorporated into any suitable electronic device. Specifically, the Bluetooth data transmission system of this application includes a main MCU, a radio frequency (RF) circuit, and an antenna in terms of hardware. The main MCU and the RF circuit are integrated into a single SOC as a Bluetooth chip. The MCU integrates a Bluetooth protocol stack, in which all Bluetooth actions and logic are integrated as part of the firmware. The MCU controls the RF circuit to transmit and receive data, sending data to or receiving data from the RF circuit. The RF circuit modulates signals and sends them to the antenna, which then transmits them to the outside world. Conversely, the antenna can also receive external signals and send them to the RF circuit, which demodulates the signals and sends the data back to the MCU. Specifically, a processor and a memory are also integrated within the Bluetooth chip or the main MCU.

[0170] The processor may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0171] The aforementioned memory can be volatile memory or non-volatile memory, or may include both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM).

[0172] It should be noted that the specific embodiments described above are exemplary, and those skilled in the art can devise various solutions inspired by the disclosure of this invention. These solutions all fall within the scope of this invention and its protection. Those skilled in the art should understand that this specification and its accompanying drawings are illustrative and not intended to limit the scope of the claims. The scope of protection of this invention is defined by the claims and their equivalents.

Claims

1. A Bluetooth data transmission system comprising a first Bluetooth device and a second Bluetooth device in a paired connection, characterized in that, the first Bluetooth device and the second Bluetooth device are configured to be able to establish a transmission mode comprising a first phase and a second phase; the first Bluetooth device is configured to continuously send data packets containing consecutive packet numbers to the second Bluetooth device in the first phase; the second Bluetooth device is configured to send acknowledgement packets containing packet numbers requiring retransmission to the first Bluetooth device in the second phase; the first Bluetooth device is further configured to continuously send data packets containing consecutive packet numbers that are incremented to the second Bluetooth device in the second phase, the data packets sent by the first Bluetooth device further containing application layer data, the data packets containing consecutive packet numbers that are incremented being part of the data packets arranged in the original data transmission queue after the data packets sent to the second Bluetooth device in the first phase, the packet numbers of the data packets containing consecutive packet numbers that are incremented being incremented on the basis of the packet numbers of the data packets sent in the first phase, the data packets requiring retransmission being inserted into the transmission sequence after the data packets containing consecutive packet numbers that are incremented, and the data packets containing consecutive packet numbers that are incremented being arranged after the data packets requiring retransmission; after the first Bluetooth device and the second Bluetooth device are in the paired connection, the first Bluetooth device sends a request to enter the transmission mode to the second Bluetooth device, and negotiates the duration of the first phase and the start time of the transmission mode with the second Bluetooth device.

2. The Bluetooth data transmission system of claim 1, wherein, the first Bluetooth device and the second Bluetooth device enter the transmission mode synchronously after the start time of the transmission mode; the first Bluetooth device and the second Bluetooth device enter the second phase synchronously after the duration of the first phase ends.

3. The Bluetooth data transmission system of claim 2, wherein, the second Bluetooth device further includes the duration of the second phase in the acknowledgement packets sent in the second phase.

4. The Bluetooth data transmission system of claim 1, wherein, the second Bluetooth device is further capable of sending data packets or empty packets for data transmission to the first Bluetooth device in the second phase.

5. The Bluetooth data transmission system of claim 3, wherein, the first Bluetooth device and the second Bluetooth device enter the first phase again synchronously after the duration of the second phase ends; one of the first Bluetooth device and the second Bluetooth device is capable of sending a request to exit the transmission mode to exit the transmission mode.

6. The Bluetooth data transmission system of claim 1, wherein, the second Bluetooth device judges whether data is lost based on the continuity of the packet numbers in the first phase, the judging standard being that: if the packet numbers of the data packets received by the second Bluetooth device are consecutive, it is judged that the data packets are not lost, and the first Bluetooth device does not need to retransmit the data packets; if the packet numbers of the data packets received by the second Bluetooth device are not consecutive, it is judged that the data packets are lost, and the first Bluetooth device needs to retransmit the lost data packets.

7. The Bluetooth data transmission system of claim 3, wherein, when the second Bluetooth device predicts that the local cache space is insufficient, the second Bluetooth device is capable of adjusting the data transmission rate of the transmission mode by adjusting the duration of the second phase.

8. A data transmission method using the Bluetooth data transmission system of any one of claims 1 to 7, providing a first Bluetooth device and a second Bluetooth device in a paired connection, characterized in that, a transmission mode is established between the first Bluetooth device and the second Bluetooth device, comprising a first phase and a second phase; the first Bluetooth device continuously sends data packets containing consecutive data packet numbers to the second Bluetooth device in the first phase; the second Bluetooth device sends an acknowledgement packet containing a data packet number requiring retransmission to the first Bluetooth device in the second phase.

Images