Bluetooth BLE low power consumption communication method and system

CN122602119APending Publication Date: 2026-08-18GUANGZHOU ANYKA MICROELECTRONICS CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610597443.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-04-30
Publication Date
2026-08-18

AI Technical Summary

Technical Problem

[0005]本申请提供了一种蓝牙BLE低功耗通信方法,解决现有技术中BLE从设备延迟参数固定化导致的通信效率与功耗难以平衡的技术问题

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122602119A_ABST
    Figure CN122602119A_ABST
Patent Text Reader

Abstract

The application discloses a Bluetooth BLE low-power consumption communication method and system, the method is applied to a slave device, and comprises the following steps: establishing a BLE connection with a master device and negotiating connection parameters, wherein the connection parameters comprise a connection interval and a maximum delay parameter; determining a delay parameter configuration value according to current communication demand, and sending the delay parameter configuration value to a controller, wherein the delay parameter configuration value does not exceed the maximum delay parameter; and the controller adjusts a delay parameter value currently used by the slave device in real time according to the received delay parameter configuration value. According to the application, the delay parameter is dynamically adjusted locally by the slave device, and it is unnecessary to re-negotiate the connection parameters with the master device, so that the communication efficiency is ensured, and the system power consumption is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, and more particularly to the field of Bluetooth Low Energy (BLE) communication technology. Background Technology

[0002] With the rapid development of IoT technology, Bluetooth Low Energy (BLE) devices have been widely used in smart homes, wearable devices, healthcare, and industrial control. Compared to classic Bluetooth, BLE devices offer the key advantage of lower power consumption, meeting the stringent battery life requirements of small embedded mobile devices. In the BLE communication protocol, the connection between master and slave devices involves data exchange through connection events, which are defined as connection intervals. To further reduce the power consumption of slave devices, the Bluetooth core protocol defines a slave latency mechanism, allowing slave devices to skip a certain number of connection events, thereby reducing the frequency of communication between master and slave devices and achieving power savings.

[0003] Traditional delay parameter mechanisms typically have fixed activation methods and parameter values, making dynamic adjustment impossible based on actual communication needs. When delay parameters are used, if communication between the master and slave devices fails, the slave device must promptly exit the delay parameter mechanism and can only resume use after at least one successful communication interaction. Exiting or adjusting the delay parameter mechanism generally requires both the master and slave devices to renegotiate the connection parameters, i.e., through a Connection Parameter Update process. This operation necessitates link-layer signaling interaction between the master and slave devices, resulting in negotiation delays and signaling overhead. Frequent negotiation also increases system power consumption.

[0004] Therefore, there is an urgent need for a technical solution that can dynamically adjust the delay parameters according to the actual communication situation, so as to achieve lower system power consumption while ensuring the timeliness and efficiency of Bluetooth communication, and without the need for frequent negotiation of connection parameters. Summary of the Invention

[0005] This application provides a Bluetooth BLE low-power communication method, which solves the technical problem in the prior art where the fixed latency parameters of BLE slave devices make it difficult to balance communication efficiency and power consumption.

[0006] In a first aspect, embodiments of this application provide a Bluetooth BLE Low Power Communication method, applied to a slave device, comprising: Establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum latency parameters; The application layer determines the delay parameter configuration value based on the current communication requirements and sends the delay parameter configuration value to the controller. The delay parameter configuration value does not exceed the maximum delay parameter. The controller adjusts the current delay parameter value used by the slave device in real time based on the received delay parameter configuration value.

[0007] Furthermore, the method also includes: the application layer determining the delay parameter configuration value according to the current communication requirements, including: obtaining the data transmission and reception status and communication timeliness requirements; when there is no data transmission and reception, determining the delay parameter configuration value to be the maximum delay parameter; when there is data transmission and reception and the communication timeliness requirements are high, determining the delay parameter configuration value to be 0; when there is data transmission and reception and the communication timeliness requirements are not high, determining the delay parameter configuration value to be a value between 0 and the maximum delay parameter.

[0008] Furthermore, the method also includes, when data is being sent and received, after the data communication ends, the application layer restores the latency parameter configuration value to the maximum latency parameter.

[0009] Furthermore, the method also includes: When there is data transmission and reception and the timeliness requirement for communication is not high, the configuration value of the delay parameter is determined according to the following formula: L = (1-α) × (1-β) × L_max; Where L is the configuration value of the delay parameter, L_max is the maximum delay parameter, α is the data communication volume factor, 0≤α≤1, and β is the communication real-time factor, 0≤β≤1.

[0010] Furthermore, the method also includes: When in data receiving state, the controller dynamically adjusts the delay parameter configuration value according to the type of data being received.

[0011] Furthermore, the method also includes: The data types include empty packets, link control packets, and ACL data packets.

[0012] Furthermore, the method also includes: The controller dynamically updates the delay parameter configuration value according to the data type received, specifically including: When receiving the empty packet, the delay parameter configuration value is set to the maximum delay parameter; When receiving the link control packet, if no response is required, the delay parameter configuration value is set to the maximum delay parameter; if a response is required, the delay parameter configuration value is set to 0, and after the response is completed, it is restored to the application layer configuration value. When receiving the ACL data packet, the delay parameter configuration value is initially set to 0. If the next connection event continues to receive ACL data packets, it remains at 0; otherwise, the application layer determines a value no greater than the maximum delay parameter based on the data volume and real-time requirements.

[0013] Secondly, embodiments of this application provide a Bluetooth BLE Low Energy communication system, comprising: The connection management module is used to establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum delay parameter; the application layer module is used to determine the delay parameter configuration value according to the current communication requirements and send the delay parameter configuration value to the controller module, wherein the delay parameter configuration value does not exceed the maximum delay parameter; the controller module is used to receive the delay parameter configuration value and apply it in real time.

[0014] Furthermore, the application layer module includes: A communication monitoring unit is used to acquire data transmission and reception status and communication timeliness requirements; a delay parameter decision unit, connected to the communication monitoring unit, is used to determine the delay parameter configuration value according to the data transmission and reception status and communication timeliness requirements; when there is no data transmission and reception, the delay parameter configuration value is determined to be the maximum delay parameter; when there is data transmission and reception and the communication timeliness requirement is high, the delay parameter configuration value is determined to be 0; when there is data transmission and reception and the communication timeliness requirement is not high, the delay parameter configuration value is determined to be a value between 0 and the maximum delay parameter.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of a Bluetooth BLE Low Power Communication method as described in any of the above embodiments.

[0016] In summary, compared with the prior art, the beneficial effects of the technical solution provided in this application include at least the following: This invention employs a strategy of dynamically adjusting latency parameters locally on the device, enabling Bluetooth Low Energy (BLE) devices to achieve an effective balance between system power consumption and data communication efficiency based on actual communication data volume and real-time requirements, without the need for frequent negotiation and updates of connection parameters. For application scenarios where communication data volume varies over time, this invention can significantly reduce system power consumption while ensuring necessary communication efficiency, demonstrating significant practical engineering implications. Since latency parameter adjustment is performed locally on the device, frequent renegotiation of connection parameters between the master and slave devices is eliminated, avoiding cumbersome operations and the resulting data communication delays. Through the coordinated action of application-layer policies and controller execution, based on application-layer policies and considering the impact of data packet types, more refined latency parameter management is achieved. Attached Figure Description

[0017] Figure 1 This is an overall flowchart of the Bluetooth BLE Low Energy Communication method.

[0018] Figure 2 A flowchart for determining the configuration values ​​of latency parameters for the application layer.

[0019] Figure 3 This is a flowchart illustrating how the controller adjusts the configuration value of the delay parameter based on the type of data received.

[0020] Figure 4 This is a block diagram of a Bluetooth BLE low-power communication system. Detailed Implementation

[0021] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0022] Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Please see Figure 1 This application provides a Bluetooth BLE Low Energy communication method, applied to a slave device, corresponding to claim 1. For example... Figure 1 As shown, the method includes: S101: Establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum delay parameters.

[0024] Taking a Bluetooth smart lock as the slave device and a smartphone as the master device as an example, the negotiation process of connection parameters is explained in detail. After the Bluetooth smart lock is powered on, the general access specification layer of the protocol stack configures the broadcast parameters, setting the broadcast interval to 100 milliseconds, and sends broadcast messages on three broadcast channels: 37, 38, and 39. The smartphone, acting as the master device, starts scanning mode with a scanning window of 30 milliseconds and a scanning interval of 100 milliseconds. After scanning for broadcast messages, the smartphone sends a connection request, proposing a connection interval of 30 milliseconds, a slave device delay of 0, and a supervisory timeout of 500 milliseconds. After evaluation, the Bluetooth smart lock considers the power consumption of these parameters to be too high and sends a connection parameter update request to the smartphone, proposing a minimum connection interval of 50 milliseconds, a maximum connection interval of 100 milliseconds, a slave device delay of 10, and a supervisory timeout of 6000 milliseconds. The smartphone accepts the proposal, and both parties negotiate and agree on a connection interval of 50 milliseconds, a maximum delay parameter of 10, and a supervisory timeout of 6000 milliseconds, establishing a communication link.

[0025] Those skilled in the art will understand that the above negotiation process follows the Bluetooth core protocol specification. The maximum delay parameter of 10 determined through negotiation will serve as the upper limit for subsequent local dynamic adjustments, meaning the delay parameter configuration value L satisfies 0 ≤ L ≤ 10. When L = 0, the actual communication interval is 50 milliseconds; when L = 5, the actual communication interval is 300 milliseconds; and when L = 10, the actual communication interval is 550 milliseconds.

[0026] S102: The application layer determines the delay parameter configuration value according to the current communication requirements and sends the delay parameter configuration value to the controller. The delay parameter configuration value does not exceed the maximum delay parameter.

[0027] The application layer can quantify the current demand level through buffer lookups. The application layer periodically queries the protocol stack data buffer status to obtain the amount of data to be sent (Tx) and received (Rx), and calculates the data transmission / reception status D = Tx + Rx, in bytes. Communication timeliness requirements are determined by a scenario tagging table maintained by the application layer. This table is loaded during device initialization and contains real-time level tags for each application scenario.

[0028] The application layer determines the latency parameter configuration value based on quantified communication requirements using either a lookup table method or a calculation method. The lookup table method involves the application layer maintaining a latency parameter decision table and directly obtaining the L value based on the data transmission / reception status interval and the communication timeliness requirement level. The calculation method involves the application layer calculating the L value in real time according to a preset algorithm. The determined L value is sent to the controller through the host control interface, satisfying the constraint that L ≤ L_max = 10.

[0029] S103: The controller adjusts the current delay parameter value used by the slave device in real time according to the received delay parameter configuration value.

[0030] The controller is the link layer of the BLE protocol stack. The controller receives latency parameter configuration values ​​sent by the application layer through the host control interface and maintains internal variables. (Previously used delay parameter value). Before each connection event, the controller checks the connection event counter `skip_counter`: if `skip_counter` is 0, it participates in this connection event, sends and receives data, and resets `skip_counter`. If skip_counter is not 0, skip the current connection event, enter low-power sleep mode, and decrement skip_counter.

[0031] Those skilled in the art will understand that the aforementioned "real-time adjustment" means that after receiving a new delay parameter configuration value, the controller applies it immediately in the next connection event, without waiting for the negotiation of the connection parameter update process to be completed. For example, if the application layer determines L=0, the controller will participate immediately in the next connection event 50 milliseconds later; if it determines L=5, it will participate after 300 milliseconds; and if it determines L=10, it will participate after 550 milliseconds.

[0032] Please see Figure 2 In some embodiments, the method further includes: S201: Obtain data transmission and reception status and communication timeliness requirements.

[0033] The methods for obtaining data transmission and reception status include: querying the difference between the write pointer and read pointer in the send buffer to obtain the amount of data to be sent; and querying the difference between the write pointer and read pointer in the receive buffer to obtain the amount of data to be received. The methods for obtaining communication timeliness requirements include: reading the current scenario entry in the application layer scenario tag table; receiving priority parameters passed from the business logic module; and querying the real-time preference settings in the user configuration file.

[0034] S202: When there is no data transmission or reception, determine that the delay parameter configuration value is the maximum delay parameter.

[0035] The criteria for determining no data transmission or reception include: the amount of data to be sent is 0; the data buffer to be received is empty; and no new data packets are received within a preset time threshold. All three conditions must be met simultaneously, or configured to be partially met according to product requirements. The preset time threshold can be configured to 100 milliseconds, 500 milliseconds, 1000 milliseconds, etc.; this embodiment uses 500 milliseconds.

[0036] After the judgment condition is met, the application layer determines the delay parameter configuration value L=L_max=10 and sends it to the controller through the host control interface. The controller will... Updated to 10, skipping every connection event, the device is in a minimum power consumption state, theoretically reducing power consumption to less than one-tenth of normal communication state.

[0037] S203: When there is data transmission and reception and the timeliness requirement for communication is high, the delay parameter is configured to be 0.

[0038] Among them, the conditions for determining data transmission and reception are: the amount of data to be sent is greater than 0, or the data buffer to be received is not empty, or a new data packet notification is received. Scenarios with high requirements for communication timeliness include: user operation response scenarios, such as physical button triggering, touch screen clicks, and near-field sensor triggering; emergency event response scenarios, such as anti-tamper alarms, low battery alarms, and abnormal status reporting; and real-time data transmission scenarios, such as audio and video streams and real-time control commands.

[0039] After meeting the determination condition, the application layer determines that the delay parameter configuration value L = 0 and sends it to the controller through the host control interface. The controller will be updated to 0 and participate in each connection event to ensure that the response delay is equal to the connection interval of 50 milliseconds, meeting the high real-time requirement.

[0040] S204: When there is data transmission and reception and the requirement for communication timeliness is not high, determine that the delay parameter configuration value is a value between 0 and the maximum delay parameter.

[0041] Among them, the scenarios with low requirement for communication timeliness include: periodic heartbeat packet reporting, such as status synchronization every 30 seconds; background data synchronization scenarios, such as batch uploading of historical records and transfer of log files; non-urgent status query responses, such as battery power query and device information reading.

[0042] After meeting the determination condition, the application layer determines that the delay parameter configuration value L satisfies 0 < L < L_max, that is, an integer between 1 and 9. The determination method can adopt the empirical look-up table method or the dynamic calculation method. The empirical look-up table method means that the application layer maintains a preset delay parameter configuration table and directly looks up the L value according to the specific scenario. The dynamic calculation method means that the application layer calculates the L value in real time according to factors such as the data volume size and the strength of the real-time requirement.

[0043] Please refer to Figure 3 , in some embodiments, the method further includes: S301: Determine whether the data communication is over.

[0044] Among them, the judgment conditions for the end of data communication include: the amount of data to be sent is 0, indicating that there is no data to be sent; the data reception buffer is empty, indicating that all received data has been processed; the application layer confirms that there is no task with high real-time requirement currently, indicating that there is no urgent communication requirement. The above three conditions need to be met simultaneously.

[0045] Those skilled in the art can implement this judgment in various ways, including: periodic polling check, that is, the application layer queries the above conditions every 100 milliseconds; event-triggered check, that is, the application layer checks when the data sending completion event and the received data processing completion event are triggered; timeout-triggered check, that is, the application layer starts a timer after the last data communication and checks after the timeout.

[0046] S302: After the data communication ends, restore the delay parameter configuration value to the maximum delay parameter.

[0047] After meeting the determination condition, the application layer immediately determines that the delay parameter configuration value L = L_max = 10 and sends it to the controller through the host control interface. The controller will be updated to 10, apply the new delay parameter configuration value in the next connection event, and the device returns to the lowest power consumption state.

[0048] Those skilled in the art will understand that the aforementioned "recovery" refers to returning from a temporary state (such as L=0 or L=5) to the default state (L=10). The recovery operation ensures that the device promptly enters a low-power mode after data communication ends, avoiding continuous high-power operation.

[0049] In some embodiments, the method further includes: The value between 0 and the maximum delay parameter is determined according to the influence factor, satisfying L=(1-α)×(1-β)×L_max, where L is the configuration value of the delay parameter, L_max is the maximum delay parameter, α is the data communication volume factor, β is the communication real-time factor, 0≤α≤1, 0≤β≤1.

[0050] The determination of the influence factor includes multiple implementation schemes. For example, data communication volume can be linearly mapped to α, and real-time requirement level can be linearly mapped to β. For example, if the data communication volume ranges from 0 to 1024 bytes, α = data communication volume / 1024; real-time requirements are divided into three levels: high, medium, and low, corresponding to β = 0.9, 0.5, and 0.1 respectively. Assuming the current data communication volume is 512 bytes and the real-time requirement is medium, then α = 512 / 1024 = 0.5, β = 0.5, L = (1-0.5)(1-0.5) × 10 = 2.5, and the rounded-down delay parameter is configured as 2 or 3.

[0051] Data communication volume can also be divided into multiple intervals, each corresponding to a fixed α value. For example, 0 to 128 bytes corresponds to α=0.1, 128 to 512 bytes corresponds to α=0.3, 512 bytes to 1KB corresponds to α=0.5, and greater than 1KB corresponds to α=0.9. Real-time requirements are also divided into multiple levels, each corresponding to a fixed β value. Suppose the current data communication volume is 256 bytes, belonging to the 128 to 512 byte interval, α=0.3; the real-time requirement is low level, β=0.1. Then L=(1-0.3)(1-0.1)×10=6.3, and the rounded-down delay parameter configuration value is 6.

[0052] Those skilled in the art will understand that the multiplication operations in the above formulas can be implemented using floating-point or fixed-point arithmetic, and the rounding operations can be performed using rounding, rounding up, or rounding down, depending on the product's precision requirements and processor performance.

[0053] In some embodiments, the method further includes: S501: Determine whether the current state is data receiving.

[0054] The controller monitors the link layer state machine. When the state machine is in the receive sub-state of the connection state, it determines that it is in the data receiving state. Triggering conditions include: a connection event occurs and the slave device needs to listen; the radio frequency module receives a valid message; and the host control interface notifies that downlink data is available.

[0055] S502: Parse the received data type.

[0056] The controller parses the Logical Link Identifier (LLID) and Length field of the link-layer packet header to identify the received data type. This data type includes three categories: Empty packets: LLID is 01, length is 0, no payload, used for maintaining connection or acknowledging reception; Link Control packets: LLID is 11, used for link-layer management, including connection update requests, connection update responses, channel mapping requests, connection termination requests, etc.; ACL packets: LLID is 10 or 01 and length is greater than 0, containing L2CAP layer and above data, carrying actual application data.

[0057] S503: Adjust the delay parameter configuration value according to the data type.

[0058] Upon receiving the empty packet, the latency parameter configuration value is set to the maximum latency parameter. In this embodiment, the controller detects an LLID of 01 with a length of 0, and determines it to be an empty packet. Empty packets do not contain valid application data and do not require application layer processing; the controller immediately... Update L_max to 10 to ensure minimum power consumption. Those skilled in the art will understand that this adjustment may temporarily override the current application layer configuration, or may only apply to the current connection event, with the application layer configuration reverting to the next event. The specific implementation should be chosen based on product requirements.

[0059] Upon receiving the link control packet, if no response is required, the delay parameter configuration value is set to the maximum delay parameter; if a response is required, the delay parameter configuration value is set to 0, and restored to the application layer configuration value after the response is completed. In this embodiment, the controller parses the opcode of the link control packet to identify the specific type: Types that do not require a response include: connection update indication, where the master device notifies the slave device that connection parameters have been updated; and channel mapping indication, where the master device notifies the slave device that channel mapping has changed. For these types, the controller will... Update to 10, do not trigger application layer callback, process directly.

[0060] The types of responses required include: connection parameter update requests (the master device requests to update connection parameters, and the slave device must respond with acceptance or rejection); and link layer ping requests (used to verify connection activity, and the slave device must respond with a ping). For these types, the controller will... Update to 0 to ensure a timely response. Once the response is complete, Restore to the current configuration value of the application layer.

[0061] When receiving the ACL data packet, the latency parameter configuration value is initially set to 0. If the next connection event continues to receive ACL data packets, the value remains 0; otherwise, the application layer determines a value not greater than the maximum latency parameter based on the data volume and real-time requirements. In this embodiment, the controller detects an LLID of 10 or 01 with a length greater than 0, and determines it to be an ACL data packet. The ACL data packet contains valid application data, and the controller initially... Update to 0 to ensure that data is received and submitted to the application layer for processing in a timely manner.

[0062] Before the next connection event, the controller checks whether to continue receiving ACL packets: if it continues, it indicates a large data volume or continuous transmission, and then maintains... If the delay parameter is set to 0, it indicates that the data transmission has ended or is intermittent. Control is then returned to the application layer, which determines a new delay parameter configuration value based on the current data volume and real-time requirements, ensuring that the value is no greater than 10.

[0063] Those skilled in the art can use various methods to determine whether to continue receiving the next connection event, including setting a flag to mark the receipt of an ACL packet in the current connection event and checking the flag in the next event; querying the receive buffer status and checking whether there is new data in the buffer before the next event; or starting a timer and checking whether a new packet has been received before the timer expires.

[0064] Please see Figure 4 Another embodiment of this application provides a Bluetooth BLE Low Energy communication system, the device comprising: The connection management module is used to establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum delay parameter; the application layer module is used to determine the delay parameter configuration value according to the current communication requirements and send the delay parameter configuration value to the controller module, wherein the delay parameter configuration value does not exceed the maximum delay parameter; the controller module is used to receive the delay parameter configuration value and apply it in real time.

[0065] In some embodiments, the application layer module includes: A communication monitoring unit is used to acquire data transmission and reception status and communication timeliness requirements; a delay parameter decision unit is used to determine the delay parameter configuration value based on the data transmission and reception status and communication timeliness requirements; when there is no data transmission and reception, the delay parameter configuration value is determined to be the maximum delay parameter; when there is data transmission and reception and the communication timeliness requirement is high, the delay parameter configuration value is determined to be 0; when there is data transmission and reception and the communication timeliness requirement is not high, the delay parameter configuration value is determined to be a value between 0 and the maximum delay parameter.

[0066] This application provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of a Bluetooth BLE Low Energy communication method as described in any of the above embodiments. The computer-readable storage medium refers to a data storage carrier, which may include, but is not limited to, floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The working process, details, and technical effects of the computer-readable storage medium provided in this embodiment can be found in the above embodiment regarding a combat control method for a virtual character, and will not be repeated here.

[0067] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0068] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0069] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A Bluetooth BLE Low Energy Communication method, characterized in that, Applied to slave devices, including: Establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum latency parameters; The application layer determines the delay parameter configuration value based on the current communication requirements and sends the delay parameter configuration value to the controller. The delay parameter configuration value does not exceed the maximum delay parameter. The controller adjusts the current delay parameter value used by the slave device in real time based on the received delay parameter configuration value.

2. The method according to claim 1, characterized in that, The application layer determines the delay parameter configuration value based on current communication requirements, including: Obtain data transmission and reception status and communication timeliness requirements; When there is no data transmission or reception, the delay parameter configuration value is determined to be the maximum delay parameter; When there is data transmission and reception and the timeliness requirement for communication is high, the delay parameter is configured to be 0. When there is data transmission and reception and the timeliness requirement for communication is not high, the value of the delay parameter is determined to be a value between 0 and the maximum delay parameter.

3. The method according to claim 2, characterized in that, When data is being sent and received, after the data communication ends, the application layer restores the latency parameter configuration value to the maximum latency parameter.

4. The method according to claim 2, characterized in that, When there is data transmission and reception and the timeliness requirement for communication is not high, the configuration value of the delay parameter is determined according to the following formula: L = (1-α) × (1-β) × L_max; Where L is the configuration value of the delay parameter, L_max is the maximum delay parameter, α is the data communication volume factor, 0≤α≤1, and β is the communication real-time factor, 0≤β≤1.

5. The method according to claim 1, characterized in that, The method further includes: When in data receiving state, the controller dynamically adjusts the delay parameter configuration value according to the data type received.

6. The method according to claim 5, characterized in that, The data types include empty packets, link control packets, and ACL data packets.

7. The method according to claim 6, characterized in that, The controller dynamically updates the delay parameter configuration value according to the data type received, specifically including: When receiving the empty packet, the delay parameter configuration value is set to the maximum delay parameter; When receiving the link control packet, if no response is required, the delay parameter configuration value is set to the maximum delay parameter; if a response is required, the delay parameter configuration value is set to 0, and after the response is completed, it is restored to the application layer configuration value. When receiving the ACL data packet, the delay parameter configuration value is initially set to 0. If the next connection event continues to receive ACL data packets, it remains at 0; otherwise, the application layer determines a value no greater than the maximum delay parameter based on the data volume and real-time requirements.

8. A Bluetooth BLE Low Energy Communication System, characterized in that, include: The connection management module is used to establish a BLE connection with the master device and negotiate connection parameters, including connection interval and maximum latency parameters. The application layer module is used to determine the delay parameter configuration value according to the current communication requirements and send the delay parameter configuration value to the controller module. The delay parameter configuration value does not exceed the maximum delay parameter. The controller module is used to receive the delay parameter configuration value and apply it in real time.

9. The system according to claim 8, characterized in that, The application layer module includes: The communication monitoring unit is used to acquire data transmission and reception status and communication timeliness requirements; A delay parameter decision unit, connected to the communication monitoring unit, is used to determine the delay parameter configuration value based on the data transmission and reception status and communication timeliness requirements. When there is no data transmission or reception, the delay parameter configuration value is determined to be the maximum delay parameter; When there is data transmission and reception and the timeliness requirement for communication is high, the delay parameter is configured to be 0. When there is data transmission and reception and the timeliness requirement for communication is not high, the value of the delay parameter is determined to be a value between 0 and the maximum delay parameter.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the Bluetooth BLE Low Power Communication method as described in any one of claims 1 to 7.