An edge-centric approach to developing Bluetooth low energy applications

Abstract

A method for developing edge-centric low-power Bluetooth applications, including: (1) writing code on edge nodes and providing configuration files for related devices; (2) optimizing parameters for executable connections, generating binary executable files and deploying these nodes; (3) using a wireless bus architecture to implement device discovery, connection management and data transmission functions; (4) during system operation, selecting whether to redirect the device, and providing a command line interface tool for dynamic device redirection, so that the redirection of the connection can be completed without reprogramming the node. The present invention uses a wireless bus architecture to shield the underlying details of BLE, thereby greatly reducing the amount of code required for application development, and is optimized for multi-connection scenarios, automatically selecting the optimal connection parameter configuration for developers, and minimizing energy consumption while meeting the average delay to meet application requirements.

Description

Technical Field

[0001] The present invention proposes an edge-centric low-power Bluetooth application development method, named BLEdge. The invention relates to the field of Bluetooth wireless transmission, and in particular to an edge-centric low-power Bluetooth application programming paradigm and a connection parameter optimization method in a multi-connection scenario. Background Art

[0002] In recent years, the Internet of Things (IoT) has developed rapidly with its low energy consumption and low cost, and has been widely supported by various devices. Bluetooth Low Energy (BLE) is often used to develop IoT applications due to its low cost, low energy consumption and high popularity. However, from a system perspective, there are the following problems in implementing IoT applications directly based on BLE. In IoT applications, there are usually a large number of wireless sensor and actuator nodes, which are connected to a high-performance and externally powered edge node through wireless protocols. The edge node is responsible for aggregating sensor data and uploading it to the cloud or controlling the actuator according to corresponding rules. However, implementing BLE applications requires writing a lot of code to handle connections using the underlying API, and it is difficult for developers to set appropriate parameters according to different application requirements, especially in multi-connection scenarios. First, writing programs for sensor data acquisition on edge nodes is very cumbersome because developers must implement many basic connection-related functions, including device discovery, connection, and data transmission. Secondly, for the NimBLE Bluetooth protocol stack, developers must write three callback functions to handle scanning, Generic Access Profile (GAP), and Logical Link Control and Adaptation Layer Protocol (L2CAP) events, and three functions are required to implement connection, data transmission, and data reception. Furthermore, conflicts between multiple BLE connections complicate the estimation of scalable communication performance, and it is difficult for developers to set the optimal connection parameters to meet the requirements of latency and energy consumption. Summary of the invention

[0003] In order to overcome the above-mentioned shortcomings of the prior art, the present invention proposes an edge-centric low-power Bluetooth application development method. The edge-centric low-power Bluetooth application development method of the present invention comprises the following steps:

[0004] (1) Write code on the edge node and provide configuration files for related devices, including the following steps:

[0005] (1.1) Set the device information, including all basic information of the device. The ADDR field indicates the device address, which can be set to LOCAL or the MAC address of a remote node. The DEVICE_TYPE field indicates the device type, and the DRIVER_NAME field is used to find the corresponding driver.

[0006] (1.2) Set the binding information to map the physical device to the device object in the programming language.

[0007] (1.3) Setting parameter optimization information to select optimized connection parameters. The LATENCY field gives the delay requirement for each access to the remote device, which can be set to an exact delay value or to different delay levels provided by the present invention based on empirical values, which will be automatically converted into corresponding delay values ​​when the program is running.

[0008] (1.4) Set the working mode. The working mode can be set to one of the active mode, synchronous passive mode and asynchronous passive mode. In the active mode, the remote device automatically reports the sensor data to the edge node with a given period. In the synchronous passive mode, the edge node starts with a data request command or a write command. At the same time, the edge node will enter blocking to wait for the response of the remote node. In the asynchronous passive mode, the edge node also starts with a data request command or a write command, but the edge node in the asynchronous passive mode will no longer wait for a response, but use a callback function to process the response data.

[0009] (2) Optimize the parameters of the executable connection, generate binary executable files and deploy these nodes. The optimization method includes the following steps:

[0010] (2.1) Calculate the number of connection events n that remain active within one second in active mode ka :

[0011] (2.1.1) Calculate the average waiting time, because the waiting time for a data packet to wait for the next connection event to start transmitting data is uniformly distributed between 0 and t eci , so the average waiting time is 0.5t eci

[0012] (2.1.2) Calculate l app The number of application data packets after bit load segmentation n pak , since the present invention utilizes the Logical Link Control and Adaptation Protocol (L2CAP) for data transmission, the effective load length of each L2CAP data packet should be less than 247 bytes:

[0013]

[0014] (2.1.3) Calculate the number of data exchanges:

[0015]

[0016] (2.1.4) Calculate the number of connection events n that transmit all data ceand the amount of data exchanged in the last connection event n last :

[0017]

[0018] n last =mod(n pak (l app ),n maxce ) (4)

[0019] (2.1.5) Calculate the number of bits of the last data exchange:

[0020] l rem =mod(l app ,247) (5)

[0021] (2.1.6) So one-way transmission l app The time t taken for a packet of bytes uni (l app ) can be expressed as:

[0022] t uni (l app )=(n ce (l app )-1)×t eci +t int (247)×(n last -1)+t int (l rem ) (6)

[0023] (2.1.7) Therefore, the total delay of the remote node in active mode can be expressed as, where t int Indicates the time when the remote node generates data and passes the data to the BLE link layer:

[0024] t active =t int +0.5t eci +t uni (l app ) (7)

[0025] (2.1.8) In summary, the number of connection events that remain active within one second in active mode is n ka It can be obtained that (t app +t init ) / t ci The average number of connection events between two consecutive data transmissions:

[0026]

[0027] (2.2) Calculate the number of connection events n that remain active within one second in passive modeka :

[0028] (2.2.1) Calculate the delay between the start of the request data transfer and the start of the response data transfer:

[0029]

[0030] (2.2.2) Calculate the total time t required to access a passive node passive , where t uni (l rsp ) represents the time required for the remote node to transmit a response:

[0031] t passive =t init +0.5t eci +t rspdly +t uni (l rsp ) (10)

[0032] (2.2.3) In passive mode, the device supports synchronous and asynchronous calls. For synchronous calls, the application will be blocked before receiving the response data. As for asynchronous calls, once the data packet is processed to the link layer, the application timer will be restarted. For burst data, the energy consumption of the corresponding connection is mainly used to maintain the connection, so the number of connection events that remain active in one second should be Therefore, the number of connection events that remain active in one second in passive mode is n ka You can get:

[0033]

[0034] (2.3) According to (2.1) and (2.2), n is obtained ka , the connection parameter optimization problem is expressed as:

[0035]

[0036] (2.4) First, calculate the effective connection interval t eci and the number of valid data exchanges n eden .

[0037] (2.4.1) To calculate t eci and n eden We need to analyze the connection overlap in the multi-connection scenario. Connection overlap may cause significant performance degradation. After analysis, the present invention divides it into two types of connection overlap: swap-out overlap and shielded overlap.

[0038] (2.4.2) Swapping out overlap: The BLE link layer reserves a minimum duration for each connection event at each connection. This event ensures that the master and slave devices can transmit packets with the maximum payload length. Swapping out overlap occurs when the minimum durations of different connections overlap, for example Figure 1 shown.

[0039] (2.4.3) Shielded Overlap: When a connection extends its connection event to transmit a large data packet, if a new connection event is started, the connection event will be terminated early, for example Figure 2 As shown. If the current connection event has more data to transmit, the host will estimate the time for the next data exchange and measure the time to the next anchor point. If the time is not enough to complete the next data exchange, the host will terminate the current connection event to ensure that the next connection event can be scheduled in time.

[0040] (2.4.4) If there is a swap-out overlap, the link layer cannot transmit any data in the next connection event. The time interval between two valid connection events is t eci Will be larger than the original connection interval.

[0041] (2.4.5) Number of valid data exchanges n eden It is used to indicate the average number of data exchanges to transmit an L2CAP data packet with the maximum payload length in each valid connection event.

[0042] (2.4.6) Once the connection interval and anchor point positions are defined, these two values ​​can be obtained as follows. First, calculate the common connection interval t cci , which is the lowest common multiple among all connection intervals.

[0043] (2.4.7) Then, at t cci The same scheduling strategy as the BLE link layer is used to connect. During the scheduling process, two values ​​are recorded for each connection: the number of valid connection events n eff , and the maximum number of data exchanges to transmit the maximum payload L2CAP data in the i-th connection event

[0044] (2.4.8) Finally, each connection t eci and t eden It can be calculated as follows:

[0045]

[0046]

[0047] (2.5) Next, calculate the transmission delay t of the i-th connectioni and the number of keep-alive connection events per second If all devices n dev The transmission delay is less than t des , the function returns the inverse of the average energy consumption n ka .

[0048] (2.6) Since some connection parameter sets will result in n to The delay of a device exceeds its designed average delay. In order to discard these parameter sets and avoid falling into the local optimal solution, the return value is relaxed and a penalty term is added. The penalty term is a negative value. The more timeouts, the smaller the value.

[0049] (2.7) In summary, the fitness function can be obtained as follows, where represents the average delay designed for the i-th device, α is the penalty coefficient, and its empirical value is 100000:

[0050]

[0051] (2.8) To execute the genetic algorithm, first initialize the population using a random connection interval and then start iterating.

[0052] (2.9) Then, in each iteration, it sorts each set of parameters.

[0053] (2.10) Finally, after the iteration, the parameter set that may cause timeout is discarded and the parameter set with the highest value is selected.

[0054] (3) The present invention proposes a wireless bus architecture and implements the functions of device discovery, connection management and data transmission on this basis. The details are as follows: Figure 3 As shown. The wireless bus shields the communication protocol and is fully responsible for data transmission, and its modular design makes it highly scalable. Specifically, it includes the following steps:

[0055] (3.1) The remote device starts the BLEdge server and initializes the peripheral devices connected to it;

[0056] (3.2) The remote node starts broadcasting, and the BLEdge core discovers and connects to the remote node according to the configuration. The BLEdge core and BLEdge server maintain a connection state machine for each connection for connection management. The four states include standby, broadcast, discovery, and connection. The details are shown in 4;

[0057] (3.3) The BLEdge core registers local and remote peripheral devices. Applications can access devices directly through the BLEdge core or using abstract drivers. The drivers of sensors and actuators are stored as a system module, including the following three files:

[0058] (3.3.1) Driver files, which operate sensors or actuators through physical connections, are usually provided by the manufacturer or the operating system.

[0059] (3.3.2) Migration files, used to migrate a new sensor or actuator driver.

[0060] (3.3.3) Initialization code, mainly used to initialize the device and register the device interface to the BLEdge core or BLEdge server. Once the node is powered on, BLEdge will call this file to automatically initialize the device and register the interface, so that the edge node can discover and access the remote device.

[0061] (3.4) The BLEdge core and the server establish a connection. The present invention proposes an interface (wireless_interface_t), which includes eight pointers for controlling the wireless protocol stack and four callback functions for the state change of the wireless protocol stack. According to this interface, the present invention can not only adapt to the NimBLE stack, but also adapt to other protocol stacks such as IEEE 802.15.4.

[0062] (3.5) The BLEdge core and the server start to pass messages. The present invention proposes a bledgedata_t data structure to pass messages and dynamically allocate memory for it. This data structure saves the type, unit and data length of the peripheral device, and can be easily used to obtain the corresponding data.

[0063] (4) During system operation, the present invention can select whether to redirect a device and provides a command line interface tool for dynamic device redirection, which can complete the redirection of the connection without reprogramming the node.

[0064] Preferably, the remote device described in step (1.3) includes a micro control unit and a temperature sensor, wherein the delay value of the micro control unit is set to "50ms" and the delay value of the temperature sensor is set to "80ms".

[0065] Preferably, the window for selecting whether to redirect the device in step (4) refers to when a node failure occurs or the battery is exhausted.

[0066] The method of the present invention uses a wireless bus architecture to shield the underlying details of BLE, thereby greatly reducing the amount of code required for application development, and is optimized for multi-connection scenarios, automatically selecting the optimal connection parameter configuration for developers, minimizing energy consumption while satisfying the average delay to meet application requirements.

[0067] The present invention proposes a wireless bus architecture. Developers can write applications in an edge-centric way, just as sensors and actuators are physically connected to edge nodes. Then, the conflict problem in BLE multi-connection scenarios is solved. And on this basis, a genetic algorithm is proposed to minimize energy consumption while ensuring that the latency requirements are met. The advantages of the present invention can be summarized as follows:

[0068] Easy to program: The present invention proposes a wireless bus architecture for IoT devices, and developers do not need to manage wireless connections.

[0069] High scalability: The present invention provides an efficient sensor / actuator interface to support various sensors and actuators. At the same time, the wireless bus architecture can support a variety of different low-power wireless communication protocols.

[0070] BLE performance optimization in multi-connection scenarios: This paper models the transmission delay and energy consumption in multi-connection scenarios and proposes corresponding optimization problems, so as to minimize the node power consumption while ensuring that the average delay is lower than the user demand, and designs a genetic algorithm to obtain the optimal connection parameters. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] Figure 1 It is a schematic diagram of a multi-connection scenario of swap-out overlapping according to the present invention.

[0072] Figure 2 It is a schematic diagram of a shielded overlapping multi-connection scenario of the present invention.

[0073] Figure 3 is a schematic diagram of the wireless bus architecture of the present invention.

[0074] Figure 4 It is a schematic diagram of the connection state machine of the present invention. DETAILED DESCRIPTION

[0075] We use three cases to demonstrate the details of the usage of the present invention.

[0076] Case 1: Table 1 shows the sample code for accessing remote IMU and temperature sensors. Line 14 subscribes to the IMU sensor data, and the remote device will report the IMU data to the edge node every 1 second. After receiving the report data, the callback function will be called to process the sensor data, and line 5 uses the IMU abstract driver to parse the IMU data in the buffer. Line 17 reads the temperature sensor data every 1 second at the edge node. Through the abstract driver of the temperature sensor, developers can directly obtain the temperature value.

[0077]

[0078] Table 1 In order for the sample code above to work properly, the developer also needs to provide a configuration file, an example of which is shown in Table 2. It is written in YAML format and contains three parts.

[0079]

[0080] Table 2

[0081] The first part is the device information, which includes all the basic information of the device. In this example, the IMU sensor and the temperature sensor are defined. ADDR can be LOCAL or set to the MAC address of the remote node. The device type is declared in the DEVICE_TYPE field, and DRIVER_NAME is used to find the corresponding driver.

[0082] The second part is the binding information, which maps the physical device to the device object in the programming language.

[0083] The third part is parameter optimization information, which is used to help developers select optimized connection parameters. LATENCY gives the latency requirement for each access to the remote device. For advanced developers, they can specify an exact latency value, such as "50ms". The present invention can ensure that the average latency is less than the connection parameters of a given value. As for junior developers, the present invention also provides empirical values ​​to help them set different levels of latency. For example, if the latency is set to "low", BLEdge will convert the value into the corresponding "80ms". For bursty data, developers can set the latency value to "burst".

[0084] WORK_MODE has three modes: active, synchronous passive, and asynchronous passive.

[0085] In active mode, the remote device automatically reports sensor data to the edge node with a given period.

[0086] In synchronous passive mode, the edge node starts with a data request command or a write command. At the same time, the edge node will enter blocking to wait for the response of the remote node.

[0087] In the asynchronous passive mode, the edge node also starts with a data request command or a write command, but the edge node in the asynchronous passive mode will no longer wait for a response, but use a callback function to process the response data.

[0088] Example 2: Table 3 is a sample program to obtain a byte stream from a sound sensor. Developers can use the bledge_readstream() API to obtain the byte stream.

[0089]

[0090] Table 3

[0091] Case 3: The maintenance personnel can use the CLI tool to redirect the remote device. If a backup IMU is defined in the configuration file, the maintenance personnel can redirect the device to the backup device based on the device name. Table 4 is the sample code for the maintenance personnel to redirect the device named "imu" to the device named "imu_bak".

[0092]

[0093] Table 4

Claims

1. An edge-centric low-power Bluetooth application development method, comprising the following steps: (1) Write code on the edge node and provide configuration files for related devices, including the following steps: (1.1) Set the device information, including all basic information of the device; the ADDR field indicates the device address, which is set to LOCAL, or the MAC address of the remote node; the DEVICE_TYPE field indicates the device type, and the DRIVER_NAME field is used to find the corresponding driver; (1.2) Set binding information to map the physical device to the device object in the programming language; (1.3) Setting connection parameters to select optimized connection parameters; the LATENCY field gives the delay requirement for each access to the remote device, which can be set to an exact delay value or different delay levels provided by empirical values, which are automatically converted to corresponding delay values ​​when the program is running; (1.4) Set the working mode, set the working mode to one of the active mode, synchronous passive mode and asynchronous passive mode; in the active mode, the remote device will automatically report the sensor data to the edge node with a given period; in the synchronous passive mode, the edge node starts with a data request command or a write command and enters a blocking state to wait for the response of the remote node; in the asynchronous passive mode, the edge node also starts with a data request command or a write command, but the edge node in the asynchronous passive mode will no longer wait for the response, but use a callback function to process the response data; (2) Optimize the parameters of the executable connection, generate binary executable files and deploy these nodes; including the following steps: (2.1) Calculate the number of connection events n that remain active within one second in active mode ka : (2.1.1) Calculate the average waiting time, because the waiting time for a data packet to wait for the next connection event to start transmitting data is uniformly distributed between 0 and t eci , so the average waiting time is 0.5t eci (2.1.2) Calculate l app The number of application data packets after bit load segmentation n pak , since the Logical Link Control and Adaptation Protocol (L2CAP) is used for data transmission, the payload length of each L2CAP data packet should be less than 247 bytes: (2.1.3) Calculate the number of data exchanges: (2.1.4) Calculate the number of connection events n that transmit all data ce and the amount of data exchanged in the last connection event n last : n last =mod(n pak (l app ),n maxce ) (4) (2.1.5) Calculate the number of bits of the last data exchange: L rem =mod(l app ,247) (5) (2.1.6) So one-way transmission l app The time t taken for a packet of bytes uni (l app ) can be expressed as: t uni (l app )=(n ce (l app )-1)×t eci +t int (247)×(n last -1)+t int (l rem ) (6) (2.1.7) Therefore, the total delay of the remote node in active mode can be expressed as, where t int Indicates the time when the remote node generates data and passes the data to the BLE link layer: t active =t int +0.5t eci +t uni (l app ) (7) (2.1.8) In summary, the number of connection events that remain active within one second in active mode is n ka It can be obtained that (t app +t init ) / t ci The average number of connection events between two consecutive data transmissions: (2.2) Calculate the number of connection events n that remain active within one second in passive mode ka : (2.2.1) Calculate the delay between the start of the request data transfer and the start of the response data transfer: (2.2.2) Calculate the total time t required to access a passive node passive , where t uni (l rsp ) represents the time required for the remote node to transmit a response: t passive =t init +0.5t eci +t rspdly +t uni (l rsp ) (10) (2.2.3) In passive mode, the device supports synchronous and asynchronous calls. For synchronous calls, the application will be blocked before receiving the response data. For asynchronous calls, once the data packet is processed to the link layer, the application timer will be restarted. For burst data, the energy consumption of the corresponding connection is mainly used to maintain the connection, so the number of connection events that remain active in one second should be Therefore, the number of connection events that remain active in one second in passive mode is n ka You can get: (2.3) According to (2.1) and (2.2), n is obtained ka , the connection parameter optimization problem is expressed as: (2.4) First, calculate the effective connection interval t eci And the number of valid data exchanges n eden ; (2.4.1) To calculate t eci and n eden , it is necessary to analyze the connection overlap in the multi-connection scenario. Connection overlap may cause significant performance degradation. After analysis, it is divided into two types of connection overlap: swap-out overlap and shielded overlap; (2.4.2) Swapping out overlap: The BLE link layer reserves a minimum duration for each connection event at each connection; this event ensures that the master device and the slave device can transmit data packets with the maximum payload length respectively; (2.4.3) Shielded overlap: When a connection extends its connection event to transmit a large data packet, if a new connection event is started, the connection event will be terminated in advance; if the current connection event has more data to transmit, the host will estimate the time of the next data exchange and measure the time to the next anchor point; if the time is not enough to complete the next data exchange, the host will terminate the current connection event to ensure that the next connection event can be scheduled in time; (2.4.4) If there is a swap-out overlap, the link layer cannot transmit any data in the next connection event; the time interval between two valid connection events is t eci will be larger than the original connection interval; (2.4.5) Number of valid data exchanges n eden It is used to indicate the average number of data exchanges to transmit an L2CAP data packet with the maximum payload length in each valid connection event. (2.4.6) Once the connection interval and anchor point positions are defined, these two values ​​can be obtained as follows; first, calculate the common connection interval t cci , which is the lowest common multiple among all the connection intervals; (2.4.7) Then, at t cci The same scheduling strategy as the BLE link layer is used to connect; during the scheduling process, two values ​​​​of each connection are recorded: the number of valid connection events n eff , and the maximum number of data exchanges to transmit the maximum payload L2CAP data in the i-th connection event (2.4.8) Finally, each connection t eci and t eden It can be calculated as follows: (2.5) Next, calculate the transmission delay t of the i-th connection i and the number of keep-alive connection events per second If all devices n dev The transmission delay is less than t des , the function returns the inverse of the average energy consumption n ka ; (2.6) Since some connection parameter sets will result in n to The delay of a device exceeds its designed average delay. In order to discard these parameter sets and avoid falling into the local optimal solution, the return value should be relaxed and a penalty item should be added. The penalty item is a negative value. The more timeouts there are, the smaller the value. (2.7) In summary, the fitness function can be obtained as follows, where represents the average delay designed for the i-th device, α is the penalty coefficient, and its empirical value is 100000: (2.8) The genetic algorithm first initializes the population with a random connection interval and then begins iterating; in each iteration, it ranks each set of parameters and uses competitive selection to select those parameters with the highest ranking values; (2.9) Use multi-point crossover and exchange mutation to update the population; (2.10) After the iteration, discard the parameter set that may cause timeout and select the parameter set with the highest value; (3) Using a wireless bus architecture to implement device discovery, connection management, and data transmission functions; the wireless bus shields the communication protocol and is fully responsible for data transmission, and its modular design makes it highly scalable; specifically, the following steps are included: (3.1) The remote device starts the BLEdge server and initializes the peripheral devices connected to it; (3.2) The remote node starts broadcasting, and the BLEdge core discovers and connects to the remote node according to the configuration. The BLEdge core and BLEdge server maintain a connection state machine for each connection for connection management. The four states include standby, broadcast, discovery, and connection; (3.3) The BLEdge core registers local and remote peripheral devices. Applications access devices directly through the BLEdge core or using abstract drivers. The drivers of sensors and actuators are stored as a system module, including the following three files: (3.3.1) Driver files, which operate sensors or actuators through physical connections, are usually provided by the manufacturer or the operating system; (3.3.2) Migration files, used to migrate a new sensor or actuator driver; (3.3.3) Initialization code, used to initialize the device and register the device interface to the BLEdge core or BLEdge server; once the node is powered on, BLEdge will call this file to automatically initialize the device and register the interface, so that the edge node can discover and access the remote device; (3.4) The BLEdge core and the server establish a connection. The interface (wireless_interface_t) contains eight pointers to control the wireless protocol stack and four callback functions for wireless protocol stack status changes. This interface can not only adapt to the NimBLE stack, but also adapt to other protocol stacks such as IEEE 802.15.4; (3.5) The BLEdge core and the server start to pass messages, and the bledgedata_t data structure is proposed to pass messages and dynamically allocate memory for it; this data structure saves the type, unit and data length of the peripheral device, and can be easily used to obtain the corresponding data; (4) During system operation, you can choose whether to redirect the device, and provide a command line interface tool for dynamic device redirection, which can complete the redirection of the connection without reprogramming the node.

2. The edge-centric low-power Bluetooth application development method according to claim 1, characterized in that: The remote device described in step (1.3) includes a micro control unit and a temperature sensor, wherein the delay value of the micro control unit is set to "50ms" and the delay value of the temperature sensor is set to "80ms".

3. The edge-centric low-power Bluetooth application development method according to claim 1, characterized in that: The window for selecting whether to redirect the device described in step (4) refers to when a node failure occurs or the battery is exhausted.

Images