CN115297459A - Low-power-consumption Bluetooth application development method taking edge as center - Google Patents

Low-power-consumption Bluetooth application development method taking edge as center Download PDF

Info

Publication number
CN115297459A
CN115297459A CN202210787266.XA CN202210787266A CN115297459A CN 115297459 A CN115297459 A CN 115297459A CN 202210787266 A CN202210787266 A CN 202210787266A CN 115297459 A CN115297459 A CN 115297459A
Authority
CN
China
Prior art keywords
connection
data
node
active
blhedge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210787266.XA
Other languages
Chinese (zh)
Inventor
董玮
高艺
徐诚阳
李烨明
李博睿
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang University ZJU
Original Assignee
Zhejiang University ZJU
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhejiang University ZJU filed Critical Zhejiang University ZJU
Priority to CN202210787266.XA priority Critical patent/CN115297459A/en
Publication of CN115297459A publication Critical patent/CN115297459A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method for developing a low-power Bluetooth application with edge as a center comprises the following steps: (1) Writing codes on the edge nodes and providing configuration files of related equipment; (2) Optimizing parameters of executable connection, generating binary executable files and deploying the nodes; (3) The functions of device discovery, connection management and data transmission are realized by using a wireless bus architecture; (4) During system operation, the device is selected to be redirected or not, and a command line interface tool for dynamic device redirection is provided, so that connection redirection can be completed without reprogramming nodes. According to the invention, the wireless bus architecture is used for shielding the bottom-layer details of BLE, so that the code amount required by application development is greatly reduced, the optimization is carried out aiming at a multi-connection scene, the optimal connection parameter configuration is automatically selected for a developer, and the energy consumption is minimized on the premise of meeting the average delay and the application requirement.

Description

Low-power-consumption Bluetooth application development method taking edge as center
Technical Field
The invention provides a low-power-consumption Bluetooth application development method taking an edge as a center, which is named BLhedge. The invention relates to the field of Bluetooth wireless transmission, in particular to a connection parameter optimization method under a low-power Bluetooth application programming paradigm and a multi-connection scene with edges as centers.
Background
In recent years, the Internet of Things (Internet of Things) has been rapidly developed due to its low energy consumption and low cost, and is widely supported by various devices. Bluetooth Low Energy (BLE) is often used to develop applications for the internet of things due to its low cost, low energy consumption, and high popularity. However, from a system perspective, implementing internet of things applications directly based on BLE has the following problems. In the application of the internet of things, a large number of wireless sensor and actuator nodes are generally arranged and connected to an edge node which has stronger performance and is externally powered through a wireless protocol. The edge node is responsible for aggregating the sensor data and uploading the aggregated sensor data to the cloud or controlling an actuator according to a corresponding rule. However, implementing a BLE application requires writing a large amount of code to handle the connection using the underlying API, and it is difficult for a developer to set appropriate parameters according to different application requirements, especially in a multi-connection scenario. First, programming programs for sensor data collection on edge nodes is cumbersome because developers must implement many connection-related basic functions, including device discovery, connection, and data transfer. Second, for the NimBLE bluetooth protocol stack, developers must write three callback functions to handle scan, generic Access Profile (GAP) and logical link control and adaptation layer protocol (L2 CAP) events, and three functions are required to implement connection, data transmission and data reception. Furthermore, collisions between multiple BLE connections complicate the estimation of scalable communication performance, making it difficult for developers to set optimal connection parameters to meet latency and energy consumption requirements.
Disclosure of Invention
In order to overcome the above disadvantages of the prior art, the present invention provides a method for developing bluetooth low energy application with edge as the center. The invention relates to a low-power consumption Bluetooth application development method taking an edge as a center, which comprises the following steps of:
(1) Writing code on the edge node and providing a configuration file of the associated device, comprising the steps of:
and (1.1) setting equipment information, including all basic information of the equipment. The ADDR field represents the device address and may be 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.
And (1.2) setting binding information and mapping the physical equipment to an equipment object in the program language.
And (1.3) setting parameter optimization information for selecting optimized connection parameters. The LATENCY field gives the LATENCY requirement for each access to the remote device and can be set to the exact LATENCY value or to different LATENCY levels provided by the invention based on empirical values, which will be automatically translated to the corresponding LATENCY value when the program is running.
(1.4) setting an operation mode, wherein the operation mode can be set to be one of an active mode, a synchronous passive mode and an asynchronous passive mode. In active mode, the remote device will automatically report sensor data to the edge node with a given periodicity. In synchronous passive mode, the edge node starts with a data request command or a write command. At the same time, the edge node may enter a block to wait for a response from the remote node. In the asynchronous passive mode, the edge node also starts from a data request command or a write command, but the edge node in the asynchronous passive mode will not wait for a response any more, but uses a callback function to process the response data.
(2) Parameters of the executable connection are optimized, binary executable files are generated, and the nodes are deployed. The optimization method comprises the following steps:
(2.1) calculating the number n of connection events that remain active in the active mode for one second ka ：
(2.1.1) meterThe average latency is calculated because the latency of a packet waiting for the next connection event to begin transmitting data is evenly distributed from 0 to t eci Therefore, the average waiting time is 0.5t eci
(2.1.2) calculation of l app Number n of bit-loaded application packet partitions pak Since the present invention utilizes the logical link control and adaptation protocol (L2 CAP) for data transmission, the payload length of each L2CAP packet should be less than 247 bytes:
Figure BDA0003729193970000031
(2.1.3) calculating the number of data exchanges:
Figure BDA0003729193970000032
(2.1.4) calculating the number of connection events n for transmitting all data ce And the amount of data exchange n in the last connection event last ：
Figure BDA0003729193970000033
n last ＝mod(n pak (l app ),n maxce ) (4)
(2.1.5) calculating the number of bits of the last data exchange:
l rem ＝mod(l app ,247) (5)
(2.1.6) unidirectional transmission of app Time t taken for data 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) thus, the total delay of the remote node in active mode can be expressed as, where t int Time representing the remote node generating and delivering data to BLE link layer:
t active ＝t int +0.5t eci +t uni (l app ) (7)
(2.1.8) As mentioned above, the number of connection events n remaining active in one second in active mode ka Can be obtained, wherein (t) app +t init )/t ci For the average number of connection events between two consecutive data transmissions:
Figure BDA0003729193970000041
(2.2) counting the number n of connection events remaining active in the passive mode within one second ka ：
(2.2.1) calculating the delay between the start of the requested data transfer and the start of the responsive data transfer:
Figure BDA0003729193970000042
(2.2.2) calculating the total time t required to access a passive node once passive Wherein t is uni (l rsp ) Represents the time required for the remote node to transmit the response:
t passive ＝t init +0.5t eci +t rspdly +t uni (l rsp ) (10)
(2.2.3) in passive mode, the device supports both synchronous and asynchronous calls. For synchronous calls, the application will be blocked before receiving the response data. With asynchronous calls, the application timer restarts once the packet is processed to the link layer. For burst type data, the energy consumption of the corresponding connection is mainly used for maintaining the connection, so the number of connection events that remain active in one second should be
Figure BDA0003729193970000043
So that the number of connection events remaining active in the passive mode within one secondn ka It is possible to obtain:
Figure BDA0003729193970000044
(2.3) n obtained according to (2.1) and (2.2) ka The connection parameter optimization problem is expressed as:
Figure BDA0003729193970000045
(2.4) first, the effective connection interval t is calculated eci And a number n of valid data exchanges eden 。
(2.4.1) to calculate t eci And n eden We need to analyze the connection overlap condition in the multi-connection scenario, which may cause significant performance degradation. By analysis, the present invention distinguishes it as two types of connection overlap: swap-out overlap and shield overlap.
(2.4.2) swap-out overlap: the BLE link layer will reserve a minimum duration for each connection event at each connection. This event ensures that the master and slave each transmit a packet having the largest payload length. The swap-out overlap occurs when the shortest durations of the different connections overlap, as shown in fig. 1 for example.
(2.4.3) shielded overlap: when a connection expands its connection events to transmit large packets, the connection event will terminate prematurely if a new connection event starts, an example of which is shown in fig. 2. If the current connection event has more data to transmit, the host estimates the time of the next data interaction and measures the time to the next anchor point. If the time is not sufficient to complete the next data interaction, the host will terminate the current connection event to ensure that the next connection event can be scheduled in a timely manner.
(2.4.4) if there is a swap out overlap, the link layer cannot transmit any data in the next connection event. Time interval t between two active connection events eci Will be larger than the original connection interval.
(2.4.5) number of valid data exchanges n eden Which is used to indicate the average number of data exchanges during each active connection event that a L2CAP packet with the largest payload length is transmitted.
(2.4.6) once the connection interval and anchor point location are defined, these two values can be obtained as follows. First, a common connection interval t is calculated cci Which is the smallest common multiple of all connection intervals.
(2.4.7) then, at t cci The connection is made using the same scheduling strategy as the BLE link layer. During the scheduling process, two values for each connection are recorded: number of active connection events n eff And a maximum number of data exchanges to transmit maximum payload L2CAP data in an ith connection event
Figure BDA0003729193970000051
(2.4.8) finally, t for each connection eci And t eden Can be calculated as follows:
Figure BDA0003729193970000052
Figure BDA0003729193970000061
(2.5) Next, the transmission delay t of the ith connection is calculated i And the number of connection events remaining active within one second
Figure BDA0003729193970000062
If all devices n dev Is less than t des The function returns the inverse n of the average energy consumption ka 。
(2.6) n is due to certain sets of connection parameters to The delay of each device exceeds its design mean delay, and in order to discard these parameter sets without falling into the locally optimal solution, the return value is relaxed and a penalty is addedAn item. The penalty term is negative, the more timeout, the smaller the value.
(2.7) in summary, a fitness function can be obtained as follows, where
Figure BDA0003729193970000063
The average delay designed by the ith device is represented, alpha is a penalty coefficient, and the empirical value is 100000:
Figure BDA0003729193970000064
(2.8) the genetic algorithm is executed, first initializing the population with random connection intervals and then starting the iteration.
(2.9) it then orders each set of parameters in each iteration.
(2.10) finally, discarding parameter sets that may cause timeouts after the iteration is over, and selecting the parameter set with the highest value.
(3) The present invention proposes a wireless bus architecture, and realizes the functions of device discovery, connection management and data transmission on this basis, the details of which are shown in fig. 3. The wireless bus shields the communication protocol and is completely responsible for data transmission, and the modular design enables the wireless bus to have high expandability. The method specifically comprises the following steps:
(3.1) the remote equipment starts the BLhedge server and initializes the peripheral equipment connected with the BLhedge server;
(3.2) the remote node starts broadcasting, the BLhedge core is discovered according to configuration and connected to the remote node, the BLhedge core and the BLhedge server maintain a connection state machine for each connection for connection management, the four states comprise standby, broadcasting, discovering and connecting, and the details are shown as 4;
(3.3) the BLhedge core registers local and remote peripheral devices, and an application program can directly access the devices through the BLhedge core or by using an abstract driver, wherein the drivers of the sensor and the actuator are stored as a system module, and the system module comprises the following three files:
(3.3.1) driver files that operate sensors or actuators through physical connections, typically provided by the manufacturer or operating system.
(3.3.2) migrating the file for migrating a new sensor or actuator driver.
And (3.3.3) an initialization code, which is mainly used for initializing the equipment and registering the equipment interface to the BLhedge core or the BLhedge server. Once the node is powered on, BLEdge will call this file to automatically initialize the device and register the interface, and the edge node can discover and access the remote device.
(3.4) BLEdge core and server are connected, the invention proposes an interface (wireless _ interface _ t), it includes eight pointers for controlling wireless protocol stack and four callback functions for wireless protocol stack state change, according to this interface, the invention not only can adapt to the nimBLE stack, but also can adapt to other protocol stacks such as IEEE 802.15.4, etc.
And (3.5) starting to transmit messages between the BLEDGEdata core and the server, wherein the invention provides a data structure of bledgedata _ t for transmitting messages and dynamically allocating memory for the messages. The data structure preserves the type, unit and data length of the peripheral device, which can be easily used to obtain the corresponding data.
(4) During the operation of the system, the invention can select whether to redirect the equipment and provides a command line interface tool for dynamic equipment redirection, and the redirection of the connection can be completed without reprogramming the node.
Preferably, the remote device in step (1.3) comprises a micro control unit and a temperature sensor, wherein the delay value of the micro control unit is set to be "50ms", and the delay value of the temperature sensor is set to be "80ms".
Preferably, the selecting whether to redirect the window of the device in step (4) refers to when a node failure occurs or a battery is drained.
The method uses the wireless bus architecture to shield the bottom-layer details of BLE, thereby greatly reducing the code amount required by application development, optimizing aiming at a multi-connection scene, automatically selecting the optimal connection parameter configuration for a developer, and minimizing energy consumption on the premise of meeting the average delay and the application requirement.
The present invention proposes a wireless bus architecture. A developer may write an application in an edge-centric manner as if the sensors and actuators were physically connected to the edge nodes. Then, the collision problem in BLE multi-connection scenarios is solved. On the basis, a genetic algorithm is provided, and energy consumption is minimized while the requirement of time delay is met. The advantages of the invention can be summarized as the following three points:
easy programming: the invention provides a wireless bus architecture of Internet of things equipment, and developers do not need to manage wireless connection.
High expansibility: the present invention provides an efficient sensor/actuator interface for supporting a variety of sensors and actuators. Meanwhile, the wireless bus architecture may support a variety of different low-power wireless communication protocols in the downstream.
BLE performance optimization under a multi-connection scenario: the invention models the transmission delay and energy consumption in a multi-connection scene and provides a corresponding optimization problem, so that the node power consumption is minimized on the premise of ensuring that the average delay is lower than the user requirement, and a genetic algorithm is designed to obtain the optimal connection parameters.
Drawings
FIG. 1 is a schematic diagram of a swapped-out overlapping multi-connection scenario of the present invention.
FIG. 2 is a schematic diagram of the shielded overlapping multi-connection scenario of the present invention.
Fig. 3 is a schematic diagram of the wireless bus architecture of the present invention.
Fig. 4 is a schematic diagram of the connection state machine of the present invention.
Detailed Description
We use three cases to show the details of the use of the invention.
Case 1: table 1 is example code to access a remote IMU and temperature sensor. Line 14 subscribes to IMU sensor data, and the remote device will report IMU data to the edge node every 1 s. After receiving the report data, a callback function is called to process the sensor data, and an IMU abstract driver is used in line 5 to analyze the IMU data in the buffer area. The edge nodes in row 17 read the temperature sensor data every 1 s. Through an abstract driver of the temperature sensor, the developer can directly obtain the temperature value.
Figure BDA0003729193970000091
Table 1 in order for the above example code to work properly, the developer also needs to provide a configuration file, such as that shown in table 2. It is written in YAML format and contains three parts.
Figure BDA0003729193970000092
TABLE 2
The first part is device information, which includes all basic information of the device. The IMU sensor and the temperature sensor are defined in this example. ADDR may be LOCAL or may be set to the MAC address of the remote node. The DEVICE _ TYPE field declares the DEVICE TYPE and the DRIVER _ NAME is used to find the corresponding DRIVER.
The second part is the binding information. It maps physical devices to device objects in the program language.
The third part is parameter optimization information used to help the developer select optimized connection parameters. LATENCY gives the LATENCY requirement of each access to the remote device. For advanced developers, they may specify an exact delay value, e.g., "50ms". The invention can ensure the connection parameter with the average delay less than the given value. As for the junior developers, the present invention also provides empirical values to help them set different levels of delay. For example, setting the delay to "low", BLEdge would translate the value to the corresponding "80ms". For burst-type data, the developer may set the delay value to "burst".
The WORK _ MODE has three MODEs: active, synchronous passive and asynchronous passive.
In active mode, the remote device will automatically report sensor data to the edge node with a given periodicity.
In synchronous passive mode, the edge node starts with a data request command or a write command. At the same time, the edge node may enter a block to wait for the remote node to respond.
In the asynchronous passive mode, the edge node starts from a data request command or a write command, but the edge node in the asynchronous passive mode does not wait for a response any more, but uses a callback function to process response data.
Case 2: table 3 is an exemplary program for acquiring a byte stream from a sound sensor, which a developer can acquire using the blank _ readstream () API.
Figure BDA0003729193970000101
TABLE 3
Case 3: maintenance personnel may use the CLI tool to redirect remote devices. If a backup IMU is defined in the configuration file, the maintenance personnel may redirect the device to the backup device based on the device name. Table 4 is example code for a maintenance person to redirect a device named "imu" to a device named "imu _ bak".
Figure BDA0003729193970000111
TABLE 4

Claims (3)

1. A low-power consumption Bluetooth application development method taking an edge as a center comprises the following steps:
(1) Writing code on the edge node and providing a configuration file of the associated device, comprising the steps of:
(1.1) setting device information including all basic information of the device; the ADDR field represents the device address, set to LOCAL, or the MAC address of the remote node; the DEVICE _ TYPE field represents the DEVICE TYPE, and the DRIVER _ NAME field is used for searching a corresponding DRIVER;
(1.2) setting binding information, and mapping the physical equipment to an equipment object in the program language;
(1.3) setting connection parameters for selecting optimized connection parameters; the LATENCY field gives the LATENCY requirement for each access to the remote device, either set to an exact LATENCY value, or automatically translated to a corresponding LATENCY value at program run time based on different LATENCY levels provided by empirical values;
(1.4) setting a working mode, wherein the working mode is set to be one of an active mode, a synchronous passive mode and an asynchronous passive mode; in the active mode, the remote device will automatically report sensor data to the edge nodes with a given period; in the synchronous passive mode, the edge node starts from 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 from a data request command or a write command, but the edge node in the asynchronous passive mode does not wait for a response any more, and uses a callback function to process response data;
(2) Optimizing parameters of executable connection, generating binary executable files and deploying the nodes; the method comprises the following steps:
(2.1) calculating the number n of connection events which remain active in one second in the active mode ka ：
(2.1.1) calculate average latency because the latency of a packet waiting for the next connection event to begin transmitting data is evenly distributed from 0 to t eci Therefore, the average waiting time is 0.5t eci
(2.1.2) calculation of l app Number n of bit-loaded application packet partitions pak Since the logical link control and adaptation protocol (L2 CAP) is used for data transmission, the payload length of each L2CAP packet should be less than 247 bytes:
Figure FDA0003729193960000021
(2.1.3) calculating the number of data exchanges:
Figure FDA0003729193960000022
(2.1.4) calculating the number of connection events n for transmitting all data ce And the amount of data exchange n in the last connection event last ：
Figure FDA0003729193960000023
n last ＝mod(n pak (l app ),n maxce ) (4)
(2.1.5) calculating the number of bits of the last data exchange:
l rem ＝mod(l app ,247) (5)
(2.1.6) unidirectional transmission of app Time t taken for data 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) thus, the total delay of the remote node in active mode can be expressed as, where t int Time representing the remote node generating and delivering data to 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 n remaining active in active mode for one second ka Can be obtained wherein (t) app +t init )/t ci For the average number of connection events between two consecutive data transmissions:
Figure FDA0003729193960000024
(2.2) counting the number n of connection events which remain active in the passive mode within one second ka ：
(2.2.1) calculating the delay between the start of the requested data transfer and the start of the responsive data transfer:
Figure FDA0003729193960000031
(2.2.2) calculating the total time t required to access a passive node once passive Wherein t is uni (l rsp ) Represents the time required for the remote node to transmit the response:
t passive ＝t init +0.5t eci +t rspdly +t uni (l rsp ) (10)
(2.2.3) in the 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 packet is processed to the link layer, the application timer is restarted; for burst type data, the energy consumption of the corresponding connection is mainly used for maintaining the connection, so the number of connection events that remain active in one second should be
Figure FDA0003729193960000032
So that the number n of connection events remaining active in the passive mode within one second ka It is possible to obtain:
Figure FDA0003729193960000033
(2.3) n obtained according to (2.1) and (2.2) ka The connection parameter optimization problem is expressed as:
Figure FDA0003729193960000034
(2.4) first, the effective connection interval t is calculated eci And a number n of valid data exchanges eden ；
(2.4.1) in order toCalculating t eci And n eden The connection overlapping situation in the multi-connection scene needs to be analyzed, and the performance may be significantly reduced due to the connection overlapping; it is analyzed to distinguish two types of connection overlap: swap-out overlap and shielded overlap;
(2.4.2) swap-out overlap: the BLE link layer reserves the shortest duration for each connection event at each connection; this period of event can ensure that the master device and the slave device respectively transmit the data packet with the maximum payload length;
(2.4.3) shielded overlap: when a connection expands its connection events to transmit large packets, the connection event will terminate early if a new connection event starts; if the current connection event has more data to be transmitted, the host estimates the time of the next data interaction and measures the time of the next anchor point; if the time is not enough to complete the next data interaction, the host computer terminates 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; time interval t between two active connection events eci Will be larger than the original connection interval;
(2.4.5) number of valid data exchanges n eden For indicating the average number of data exchanges for transmitting an L2CAP packet having the largest payload length during each active connection event;
(2.4.6) once the connection interval and anchor point location are defined, these two values can be obtained as follows; first, a common connection interval t is calculated cci Which is the smallest common multiple in all connection intervals;
(2.4.7) then, at t cci The connection is carried out by using the same scheduling strategy as the BLE link layer; during the scheduling process, two values for each connection are recorded: number of active connection events n eff And a maximum number of data exchanges to transmit maximum payload L2CAP data in an ith connection event
Figure FDA0003729193960000041
(2.4.8) finally, t for each connection eci And t eden Can be calculated as follows:
Figure FDA0003729193960000042
Figure FDA0003729193960000043
(2.5) Next, the transmission delay t of the ith connection is calculated i And the number of connection events that remain active for one second
Figure FDA0003729193960000044
If all devices n dev Is less than t des The function returns the inverse n of the average energy consumption ka ；
(2.6) n may result from certain connection parameter sets to The delay of each device exceeds the designed average delay, and in order to discard the parameter sets and not fall into the local optimal solution, the return value is relaxed, and a penalty item is added; the penalty item is a negative value, and the more the timeout is, the smaller the value is;
(2.7) in summary, a fitness function can be obtained as follows, where
Figure FDA0003729193960000051
The average delay designed by the ith device is represented, alpha is a penalty coefficient, and the empirical value is 100000:
Figure FDA0003729193960000052
(2.8) the genetic algorithm first initializes the population using random connection intervals and then starts iteration; in each iteration, it orders each set of parameters and uses the contest selection to select those parameters with the highest ranking values;
(2.9) updating the population by adopting multipoint crossing and exchange variation;
(2.10) discarding parameter sets which may cause timeout after the iteration is over, and selecting the parameter set with the highest value;
(3) Using a wireless bus architecture to implement the functions of device discovery, connection management, and data transfer; the wireless bus shields a communication protocol and is completely responsible for data transmission, and the modularized design ensures that the wireless bus has high expandability; the method specifically comprises the following steps:
(3.1) the remote equipment starts the BLhedge server and initializes the peripheral equipment connected with the BLhedge server;
(3.2) the remote node starts broadcasting, the BLhedge core is discovered according to configuration and connected to the remote node, the BLhedge core and the BLhedge server maintain a connection state machine for each connection for connection management, and the four states comprise standby, broadcasting, discovering and connecting;
(3.3) the BLhedge core registers local and remote peripheral devices, and an application program directly accesses the devices through the BLhedge core or by using an abstract driver, wherein the drivers of the sensor and the actuator are stored as a system module, and the system module comprises the following three files:
(3.3.1) driver files, operating sensors or actuators through physical connections, typically provided by the manufacturer or operating system;
(3.3.2) migrating a file for migrating a new sensor or actuator driver;
(3.3.3) initializing codes, which are used for initializing the equipment and registering an equipment interface to the BLhedge core or a BLhedge server; once the node is powered on and started, the BLhedge calls the file to automatically initialize the equipment and register an interface, and the edge node can discover and access the remote equipment;
(3.4) the BLEdge core is connected with the server, an interface (wireless _ interface _ t) comprises eight pointers for controlling the wireless protocol stack and four callback functions for state change of the wireless protocol stack, and the interface can be adapted to not only the nimBLE stack but also other protocol stacks such as IEEE 802.15.4 and the like;
(3.5) starting to transmit messages between the BLEDGEdata core and the server, and providing a data structure of bleddedata _ t for transmitting the messages and dynamically allocating a memory for the messages; the data structure stores the type, unit and data length of the peripheral equipment, and the peripheral equipment can be easily used to obtain corresponding data;
(4) During system operation, whether to redirect the device is selected, and a command line interface tool for dynamic device redirection is provided, which can accomplish redirection of the connection without reprogramming the node.
2. The method of claim 1 for edge-centric bluetooth low energy application development, wherein: the remote device in step (1.3) comprises a micro control unit and a temperature sensor, wherein the delay value of the micro control unit is set to be 50ms, and the delay value of the temperature sensor is set to be 80 ms.
3. The method of claim 1 for edge-centric bluetooth low energy application development, comprising: the step (4) of selecting whether to redirect the window of the device refers to when a node failure or a battery is exhausted.
CN202210787266.XA 2022-07-04 2022-07-04 Low-power-consumption Bluetooth application development method taking edge as center Pending CN115297459A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210787266.XA CN115297459A (en) 2022-07-04 2022-07-04 Low-power-consumption Bluetooth application development method taking edge as center

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210787266.XA CN115297459A (en) 2022-07-04 2022-07-04 Low-power-consumption Bluetooth application development method taking edge as center

Publications (1)

Publication Number Publication Date
CN115297459A true CN115297459A (en) 2022-11-04

Family

ID=83822417

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210787266.XA Pending CN115297459A (en) 2022-07-04 2022-07-04 Low-power-consumption Bluetooth application development method taking edge as center

Country Status (1)

Country Link
CN (1) CN115297459A (en)

Similar Documents

Publication Publication Date Title
US5434976A (en) Communications controller utilizing an external buffer memory with plural channels between a host and network interface operating independently for transferring packets between protocol layers
US5487152A (en) Method and apparatus for frame header splitting in a media access control/host system interface unit
CN100353349C (en) Bus architecture and shared bus arbitration method for communication processor
US5634015A (en) Generic high bandwidth adapter providing data communications between diverse communication networks and computer system
US8792508B2 (en) Subscriber and communication controller of a communication system and method for implementing a gateway functionality in a subscriber of a communication system
CN101111826B (en) Method and system for guaranteeing real time message transmission of communication system
CN102521201A (en) Multi-core DSP (digital signal processor) system-on-chip and data transmission method
JP2007233522A (en) Dma data transfer device and dma data transfer method
US20090307408A1 (en) Peer-to-Peer Embedded System Communication Method and Apparatus
US7631313B2 (en) System and method for transferring data
CN100430847C (en) Method and device for determining time in a bus system and corresponding bus system
CN111538694B (en) Data caching method for network interface to support multiple links and retransmission
Edmonds et al. MASS: modular architecture for sensor systems
US7552232B2 (en) Speculative method and system for rapid data communications
CN115297459A (en) Low-power-consumption Bluetooth application development method taking edge as center
CN113067761B (en) Linear token data bus simulation platform based on OPNET
JP3293089B2 (en) PLC remote I / O system and PLC remote I / O system execution method
JP5534711B2 (en) Information processing apparatus, information processing method, and program
Winterbottom et al. Topsy: an extensible unix multicomputer
KR0154489B1 (en) Apparatus for receiving/sending ipc message in atm switching system and method thereof
CN108446131B (en) ATM firmware upgrading method, device, equipment and storage medium
WO2024037482A1 (en) Interrupt message processing method and apparatus
CN115037413B (en) Standardized configurable multi-rate switching system and method for SpaceFobore protocol
CN116405377B (en) Network state detection method, protocol conversion component, equipment and storage medium
CN116009949B (en) Numerical value acquisition method, device, equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination