A hybrid communication method and system based on bluetooth dual protocol stack

Abstract

The application relates to the field of Bluetooth and communication technology and discloses a hybrid communication method and system based on a Bluetooth dual-protocol stack. The method comprises the following steps: initializing a device supporting a dual-protocol stack as a distributed ledger node and allocating a unique identity; constructing a lightweight consensus mechanism based on proof of stake and behavior credibility weighting; recording device network access and message forwarding behavior logs and chaining; broadcasting block abstracts through low-power Bluetooth and synchronizing complete blocks through classic Bluetooth to realize efficient verification and consistency maintenance; and realizing decentralized identity authentication and abnormal behavior auditing based on a local ledger. The system is composed of Internet of Things nodes with dual-protocol stack capability and cooperatively executes the above process. Through the above technical scheme, the application can realize a decentralized security architecture, full-process behavior traceability, dynamic trust evaluation and low-power efficient communication, and the security, credibility and resource adaptability of a large-scale Bluetooth Mesh network are improved.

Description

Technical Field

[0001] This invention belongs to the field of Bluetooth and communication technology, specifically relating to a hybrid communication method and system based on Bluetooth dual protocol stack. Background Technology

[0002] With the widespread application of IoT technology, Bluetooth Mesh networks have become the mainstream communication architecture in scenarios such as smart lighting, building automation, and industrial sensing due to their self-organizing network, multi-hop relay, and large-scale device interconnection capabilities. In the network, a massive number of terminal devices achieve efficient collaboration through broadcast and relay mechanisms, supporting the low-power, high-coverage communication requirements in complex environments.

[0003] Bluetooth dual-stack technology allows devices to simultaneously support Bluetooth Classic (BR / EDR) and Bluetooth Low Energy (BLE), providing a hardware foundation for heterogeneous communication and multi-functional integration. However, in large-scale deployment environments, the openness and decentralized nature of Mesh networks also bring serious security challenges: anonymous device access lacks effective authentication, and message relay processes are easily hijacked, tampered with, or forged by malicious nodes, leading to compromised data integrity and leakage of user privacy.

[0004] Existing security mechanisms largely rely on centralized trust models, such as pre-defined keys or certificates distributed by a central controller. This not only introduces single points of failure but also struggles to adapt to dynamic topologies and resource-constrained IoT devices. Furthermore, traditional encryption and authentication schemes are computationally expensive and cannot operate efficiently on lightweight nodes. The lack of behavior auditing and accountability mechanisms further weakens network trustworthiness and manageability. Therefore, how to build a decentralized, verifiable, and attack-resistant trust management mechanism while ensuring low power consumption and high scalability has become a pressing technical challenge in the current Bluetooth Mesh network security field. Summary of the Invention

[0005] The purpose of this invention is to provide a hybrid communication method and system based on Bluetooth dual protocol stack, which can effectively solve the problems in the background art mentioned above.

[0006] To achieve the above objectives, the present invention provides a hybrid communication method based on Bluetooth dual-protocol stack, comprising the following steps:

[0007] Initialize the distributed ledger nodes in the Bluetooth Mesh network, using IoT devices that support both Bluetooth Classic and Bluetooth Low Energy dual protocol stacks as network nodes. Assign a unique device identity to each device when it joins the network, and store the initial blockchain ledger structure locally. The initial blockchain ledger structure includes the genesis block and device public key information.

[0008] A lightweight consensus mechanism is constructed, which adopts a hybrid consensus algorithm based on proof of stake and behavioral credibility weighting. The consensus weight is dynamically calculated based on the device's historical behavior records, message forwarding success rate and online duration. Only nodes with a weight greater than a preset threshold are allowed to participate in block generation and verification.

[0009] Record device network entry and message forwarding behavior. When a new device requests to join the network, the neighboring nodes broadcast its identity credentials to the local subnet. After consensus verification, a network entry transaction is generated and written into a new block. During the message relay process, each forwarding node encapsulates the message digest, timestamp, source address and destination address into a behavior log, and submits it to the transaction pool to be packaged after digital signature.

[0010] The block generation and synchronization process involves the selected master node in the current round collecting transactions to be confirmed, sorting them in chronological order to generate candidate blocks, and broadcasting them to neighboring nodes via Bluetooth Low Energy for rapid verification. Once verified, the blocks are synchronized via Bluetooth Classic to ensure consistency across the entire network ledger.

[0011] It enables decentralized identity authentication and behavior auditing. Any node can query the historical network access records and message forwarding trajectory of any device based on the local ledger. By verifying the transaction signature chain, the source of behavior can be traced, and devices with abnormal behavior can be automatically isolated or have their permissions downgraded.

[0012] Preferably, the device identity is generated by hashing the device's unique hardware serial number and the first network access timestamp, the device public key is generated using the SM2 national cryptographic algorithm in elliptic curve cryptography, and the private key is securely stored in the device's secure element.

[0013] Preferably, the weighting factors for the behavior credibility weighting include message integrity verification pass rate, relay delay standard deviation, and collaborative score of neighboring nodes for its behavior; wherein, the collaborative score is calculated through a local reputation propagation mechanism, and the score increases by a specific value for each successful relay, and if tampering or discarding of messages is detected, another specific value is deducted at once, the initial weight is set to a predetermined value, and the weight update is set to periodic update.

[0014] Preferably, the network access transaction includes device identity identifier, public key, network access request time, verification node list and digital signature of each verification node, behavior log uses SHA-3-256 algorithm to generate message digest, timestamp accuracy is predetermined, and the current block height of the sending node is appended to prevent replay attacks.

[0015] Preferably, the maximum capacity of the candidate block is limited to a predetermined capacity, containing no more than a predetermined number of transaction records. The block header includes the hash of the previous block, Merkle root, timestamp, consensus round number, and master node public key. The low-power Bluetooth channel is used to transmit the block header and transaction digest, and the classic Bluetooth channel is used to transmit the complete block body.

[0016] Block verification includes three checks: verifying the link between the block header hash and the previous block, verifying the consistency between the Merkle root and the transaction set, and verifying the validity of the master node signature and whether the consensus weight meets the requirements. If any check fails, the block is discarded and a new round of consensus election is triggered.

[0017] Preferably, the behavior audit is achieved by traversing all transactions related to the target device in the local ledger. The audit results include the legality of the device's network access, the number of historical message forwardings, the frequency of abnormal behavior, and the most recent active time. If multiple consecutive relay behaviors are marked as abnormal, the consensus rights are automatically reset to zero and the device is prohibited from participating in the subsequent consensus process.

[0018] Preferably, the system optimizes storage overhead under limited device resources by using a rolling window mechanism to retain only a predetermined number of complete data blocks, and compresses earlier blocks into state snapshots. The snapshots contain the latest public keys, permission levels, and cumulative trust scores of all devices, with a compression ratio of not less than a predetermined ratio.

[0019] Preferably, the collaborative scheduling strategy of the dual protocol stack is as follows: Bluetooth Low Energy is used for regular Mesh broadcasting, heartbeat packets and lightweight transaction digest transmission, and Bluetooth Classic is activated on demand when a large block synchronization requirement or an emergency security event is detected, with the activation delay controlled within a predetermined time range.

[0020] Preferably, at the beginning of each consensus cycle, the hybrid consensus algorithm requires all network nodes to independently calculate the candidate set of master nodes for this round based on their local ledgers. The candidate set includes nodes whose weight ranking is within a preset proportion range. Finally, the master node is selected from the candidate set through a verifiable random function.

[0021] The present invention also provides a hybrid communication system based on Bluetooth dual-protocol stack for implementing the above-described method, comprising:

[0022] The distributed ledger initialization module is used to assign a unique device identity and store the initial blockchain ledger structure on IoT devices that support both classic Bluetooth and Bluetooth Low Energy dual protocol stacks.

[0023] A lightweight consensus building module is used to dynamically calculate consensus weights based on the device's historical behavior records, message forwarding success rate, and online duration, and to limit only high-weight nodes to participate in block generation and verification.

[0024] The behavior recording module is used to generate network access transactions when a device joins the network, and to generate digitally signed behavior logs and submit them to the transaction pool to be packaged during message relay.

[0025] The block generation and synchronization module is used to generate candidate blocks from the master node, perform fast verification through the low-power Bluetooth channel, and perform high-bandwidth block synchronization through the classic Bluetooth channel.

[0026] The decentralized auditing module is used to query device historical behavior based on the local ledger and implement automatic isolation or permission downgrading.

[0027] Compared with the prior art, the present invention has the following beneficial effects:

[0028] 1. By building each Bluetooth device into a blockchain ledger node, the traditional centralized certificate authority or key distribution center is eliminated. Even if some nodes fail or are compromised, the overall network trust system can still be maintained, significantly improving system availability. Device identity authentication and behavior verification are entirely based on distributed ledger records, without relying on external servers, fundamentally solving the single point of failure problem.

[0029] 2. The designed hybrid consensus algorithm combines dynamic weighting of behavioral credibility, avoiding the high energy consumption problem of proof-of-work algorithms, and reducing communication overhead through dual-protocol stack division of labor. Experimental results show that on a typical BLE chip, the computation time for a single consensus verification is less than a predetermined threshold, and the memory usage is less than a predetermined capacity, meeting the long-term operating requirements of battery-powered devices.

[0030] 3. Key operations such as device network access and message forwarding are all recorded on the blockchain in an immutable manner, allowing any node to independently audit historical behavior. Malicious nodes cannot forge identities or deny their forwarding behavior, and the accuracy of accountability is close to the theoretical limit, significantly improving the management transparency and security resilience of large-scale self-organizing networks.

[0031] 4. Leveraging the high bandwidth of classic Bluetooth to accelerate block synchronization, while relying on Bluetooth Low Energy to maintain daily Mesh communication, a balance is achieved between security mechanisms and energy efficiency. In test networks with a large number of nodes, the block synchronization completion time is significantly reduced compared to the pure BLE solution, while the average power consumption increases only slightly, balancing performance and battery life.

[0032] 5. A credibility scoring mechanism based on real-time behavioral data enables the network to self-purify. Abnormal nodes are automatically marginalized after multiple violations, requiring no manual intervention. Tests show that, facing Sybil attacks with a high proportion of malicious nodes, this system can suppress malicious traffic to an extremely low percentage of the original level within a predetermined time period, with a defense response speed significantly superior to traditional static key schemes. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall technical solution architecture of the present invention;

[0034] Figure 2 This is a schematic diagram of the core principle framework of the hybrid consensus algorithm based on proof of rights and behavioral credibility weighting in this invention;

[0035] Figure 3 This is a logical flow diagram of the device network access and message forwarding behavior recording in this invention;

[0036] Figure 4 This is a logical flow diagram of block generation and dual protocol stack collaborative synchronization in this invention;

[0037] Figure 5 This is a schematic diagram of the multi-level interaction relationship and data flow of the decentralized identity authentication and behavior auditing mechanism in this invention;

[0038] Figure 6 This is a logical flowchart of the dual-protocol stack collaborative scheduling and resource optimization strategy in this invention. Detailed Implementation

[0039] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following description is provided in conjunction with the appendix. Figure 1 To be continued Figure 6 The specific embodiments, structures, features, and effects of the present invention are described in detail below.

[0040] In intelligent building automation systems, a large number of IoT terminal devices based on Bluetooth dual-protocol stacks are deployed, including lighting controllers, temperature and humidity sensors, access control actuators, and environmental monitoring nodes. These devices need to complete self-organizing networking, secure communication, and trusted behavior management without the intervention of a central server. Traditional solutions rely on pre-set keys or central authentication servers, which pose a single point of failure risk and are difficult to dynamically adapt to the addition or removal of devices. This embodiment adopts the hybrid communication method and system based on Bluetooth dual-protocol stacks proposed in this invention to achieve decentralized identity authentication, lightweight consensus, and full-process behavior traceability.

[0041] Step 1: Initialize the distributed ledger nodes in the Bluetooth Mesh network: All participating IoT devices have built-in wireless communication chips supporting both Classic Bluetooth (BR / EDR) and Bluetooth Low Energy (BLE) dual protocol stacks, such as Nordic RF52840 or TICC2652RB. Upon initial power-up, the device reads its unique hardware serial number (16 bytes long, stored in the OTP memory by the chip manufacturer) and obtains the current system timestamp (millisecond precision, provided by the internal RTC module). These two serial numbers are concatenated and input into the SM3 hash function to generate a 256-bit device ID, which is globally unique and unpredictable.

[0042] Subsequently, the device invokes the SM2 key generation module in the Secure Element to generate a pair of elliptic curve public keys (the curve parameters are the 256-bit domain curve recommended by SM2). The public key is stored in local non-volatile memory in ASN.1DER encoding format, while the private key is permanently locked inside the Secure Element and cannot be read through any software interface.

[0043] Simultaneously, the device initializes the blockchain ledger structure in its local Flash memory, including the genesis block. The genesis block has fixed content, including a block height of 0, a timestamp of the device's manufacturing date, an empty Merkle root, a hash of all zeros for the previous block, and embeds the device's public key as the initial trust anchor. At this point, the device completes its initialization as a distributed ledger node, possessing the basic capability to participate in subsequent consensus and transaction verification.

[0044] Step Two: Constructing a Lightweight Consensus Mechanism: During network operation, each node continuously maintains a local weight table, recording its own consensus weight and that of other known nodes. The initial weight value is uniformly set to 1000. The weight update cycle is 300 seconds, triggered by a system timer. Within each update cycle, nodes dynamically adjust their weights based on a credibility weighting factor for three types of behavior:

[0045] First, the message integrity verification pass rate is calculated by counting the proportion of messages forwarded by nodes that pass both CRC32 and HMAC-SM3 verifications within the current period. If the proportion is less than 0.95, the weight is multiplied by 0.9.

[0046] Second, relay delay standard deviation, calculate the standard deviation of the end-to-end delay (time interval from reception to broadcast) of the node forwarding the message. If the standard deviation is greater than 500 milliseconds, the weight is multiplied by 0.95.

[0047] Third, neighboring nodes collaborate on scoring, which is calculated through a local reputation propagation mechanism.

[0048] Specifically, whenever node A successfully relays a legitimate message from node B, A sends an acknowledgment score packet to B (containing B's DeviceID, this relay ID, and A's signature). Upon receiving the packet, B verifies the validity of the signature and adds 5 points to the accumulated score. If A detects that the message forwarded by B has been tampered with (e.g., digest mismatch) or maliciously discarded (e.g., not forwarded within timeout), it sends a penalty score packet, and B's score is reduced by 20.

[0049] If C gives A a high rating, then C will believe A's rating of B, thus achieving a reputation dissemination mechanism.

[0050] The collaborative score is ultimately normalized to a factor between 0 and 1. This factor is then weighted and averaged with the two factors mentioned above (with weights of 0.4, 0.3, and 0.3 respectively), and multiplied by the base weight to obtain the new weight. Only nodes with a weight greater than 800 are allowed to participate in block generation and verification. This mechanism ensures that highly reliable nodes dominate the consensus process and reduces the influence of malicious nodes.

[0051] Step 3 records device network entry and message forwarding behavior: When a new device X requests to join the network, it first sends a network entry request packet via the BLE broadcast channel, containing its DeviceID, public key, and timestamp. Upon receiving this packet, the neighboring node Y (already in the network and with a weight > 800) verifies the validity of X's public key format and checks whether the DeviceID has already been registered using its local ledger (to prevent replay). If the verification passes, Y encapsulates X's identity credentials into a network entry transaction proposal and broadcasts it to the local subnet via the BLEMesh flooding mechanism (hop count limited to 3).

[0052] Other high-weight nodes within the subnet independently verify the proposal and generate digital signatures locally. Once at least three valid signatures are collected, Y officially writes the network entry transaction into the pending transaction pool. The network entry transaction data structure includes: device identity (32 bytes), public key (65 bytes, uncompressed SM2 format), network entry request time (8-byte Unix timestamp), list of verification nodes (up to five DeviceIDs, totaling 160 bytes), and SM2 signatures of each verification node (64 bytes each).

[0053] During routine message relay, whenever node Z forwards an application-layer message (such as a "turn on the lights" command), it first calculates the message's SHA-3-256 digest (32 bytes) and records the current system timestamp (8 bytes), source address (i.e., the original sender's DeviceID, 32 bytes), and destination address (target device or group address, 32 bytes). These fields are concatenated and then SM2-signed using Z's private key to form a behavior log transaction. The behavior log transaction is appended with the latest block height (4 bytes) of Z's current local ledger to prevent replay attacks. All behavior log transactions are submitted to the local pool of pending transactions, awaiting block generation.

[0054] Step four involves block generation and synchronization: Each consensus cycle lasts 60 seconds, during which all network nodes independently calculate the candidate set of master nodes for that round based on their local ledgers. The candidate set includes the top 10% of nodes by weight. The final master node is selected from the candidate set using a Verifiable Random Function (VRF): each candidate node uses its own private key to perform a VRF operation on "consensus round number + current time window," generating a pseudo-random output and proof; the node with the smallest output value wins.

[0055] The elected master node P collects all transactions in the pending transaction pool (incoming transactions and behavior log transactions), sorts them in ascending order by timestamp, truncates them to a maximum of 100 transactions (or a total size not exceeding 8KB), and generates candidate blocks. The candidate block header contains: the hash of the previous block (32 bytes), the Merkle root (32 bytes, the root of a binary hash tree constructed from the transaction list), the timestamp (8 bytes), the consensus round number (4 bytes), the master node's public key (65 bytes), and the master node's SM2 signature of the block header (64 bytes).

[0056] The master node P first sends the block header and the SHA-3-256 digest of each transaction (32 bytes / transaction) to all one-hop neighbor nodes via the BLE broadcast channel in Mesh multicast mode. This stage only transmits about 2KB of data, with extremely low energy consumption.

[0057] Upon receiving the block, neighboring nodes immediately perform a triple check: First, they calculate the received block header hash and compare it with the hash of the previous block stored locally to verify the chain link; second, they reconstruct the Merkle tree based on the received transaction digest to verify the root value consistency; finally, they use the master node's public key to verify the signature validity and query the local weight table to confirm that P's weight is greater than 800 at the time of generation. If any check fails, the node discards the block and broadcasts a negative response, triggering a new round of elections.

[0058] If the verification passes, the node sends a positive response to P. Once P receives positive responses from at least 5 high-weight neighbors, it determines the block is valid and immediately activates the classic Bluetooth (BR / EDR) channel, establishes an ACL connection, and synchronizes the complete block (containing all 100 original transactions) to all nodes in the network at high bandwidth (theoretically up to 2.1Mbps). This dual-channel strategy significantly reduces daily communication energy consumption while ensuring high-capacity data synchronization efficiency.

[0059] Step 5 implements decentralized identity authentication and behavior auditing: Any node Q can perform behavior auditing on any device R based on the local ledger. Q traverses all blocks in its local storage, filtering out records of transactions involving R's DeviceID, including inbound transactions and all behavior logs generated or relayed by R.

[0060] The audit results are summarized into a structured report, which includes: the legitimacy of R's entry into the network (verifying whether the transaction signature chain is complete), the number of historical message forwards (counting the number of behavior logs), the frequency of abnormal behavior (statistically calculating the percentage of logs marked as tampered or discarded), and the most recent active time (the latest behavior log timestamp). If R's abnormal behavior percentage is greater than 20% within three consecutive consensus periods, Q will automatically reset its consensus weight to zero and mark it in the local blacklist.

[0061] Subsequently, Q refuses to forward any messages from R and no longer accepts its participation in consensus. This mechanism achieves network self-purification without central intervention. Furthermore, the system employs a rolling window mechanism to optimize storage: only the complete data of the most recent 100 blocks is retained locally, while earlier blocks are compressed into state snapshots. These snapshots contain the latest public keys of all devices, current permission levels (such as ordinary nodes / relay nodes / master node candidates), and cumulative trust scores (i.e., final weight values), compressed using the LZ4 algorithm with a compression ratio of no less than 70%, significantly reducing Flash usage.

[0062] The coordinated scheduling of the dual protocol stacks is uniformly managed by the underlying driver. BLE is always in a listening state, handling Mesh broadcasts, heartbeats (every 10 seconds), and lightweight transaction summaries. Classic Bluetooth is disabled by default and is only activated as needed when the following conditions are met: 1) the size of the block to be synchronized is detected to be greater than 4KB; 2) an emergency security event notification is received (such as a large-scale abnormal behavior alarm). The activation process is controlled by the RF module via HCI commands, with latency controlled within 200 milliseconds to ensure timely security response.

[0063] In industrial sensing and monitoring scenarios, factories deploy thousands of vibration sensors, temperature probes, and pressure transmitters based on Bluetooth dual-protocol stacks to monitor the real-time operating status of large rotating machinery. Such environments place extremely high demands on communication reliability and secure response speed, and the equipment's computing resources are even more limited (a typical MCU is a Cortex-M0+ with a 48MHz clock speed and only 32KB of RAM). This embodiment addresses this scenario by deeply optimizing the consensus algorithm and data structure to adapt to extreme resource constraints.

[0064] In step one, the device identity generation method remains unchanged, but the public key storage adopts a compressed format. The uncompressed format of the SM2 public key is 65 bytes, but this embodiment forces the use of a compressed format (33 bytes), which is achieved by setting the parity flag of the public key's Y-coordinate. During decompression, the complete coordinates are recovered using the elliptic curve equation. This reduces the storage overhead by 32 bytes, which is crucial for nodes with limited memory. The genesis block structure is also simplified, retaining only necessary fields, with the total size controlled within 128 bytes.

[0065] In step two, the calculation of the behavioral credibility weighting factor is significantly simplified. Due to the limited computing power of the MCU, the calculation of the relay delay standard deviation (involving floating-point operations and variance statistics) is eliminated, retaining only the message integrity verification pass rate and the collaborative scoring. The collaborative scoring mechanism is also adjusted: the scoring packet is no longer sent separately, but is embedded in the regular heartbeat packet, with a score update carried every 10 heartbeat packets, reducing the communication frequency. The weight update cycle is extended to 600 seconds to reduce the computational burden. The consensus weight threshold is increased to 900 to ensure that only the most stable node participates in consensus.

[0066] In step three, the behavior log transaction structure is simplified. The source and destination address fields are removed, as industrial sensor messages are mostly one-way upwards (sensor → gateway), and address information can be inferred from the context. The message digest is replaced with the lighter SM3 hash (instead of SHA-3-256), maintaining the same 32-byte output length but improving computation speed by 40%. Timestamp precision is reduced to the second level, saving 4 bytes. The digital signature adopts the SM2 fast signature mode, pre-calculating some parameters, reducing signature generation time from 15ms to 8ms.

[0067] In step four, the block generation strategy is adjusted. The maximum size of candidate blocks is limited to 4KB, and the maximum number of transactions is 50. The master node public key field is removed from the block header and replaced with the master node DeviceID index. The receiver can retrieve the corresponding public key from its local ledger, saving 65 bytes. The Bluetooth Low Energy channel only transmits the block header (excluding transaction digests). Verification relies on the complete transaction synchronized with Classic Bluetooth for Merkle root reconstruction. This strategy sacrifices some pre-verification reliability but significantly reduces BLE load. The Classic Bluetooth activation threshold is reduced to 2KB because industrial scenarios have lower tolerance for synchronization latency.

[0068] In step five, the behavior auditing function is limited. Nodes only cache the most recent 50 blocks, and the state snapshot compression ratio is increased to 80%. The abnormal behavior judgment logic is simplified: as soon as message tampering is detected even once, the device rights are immediately reset to zero, and the cumulative evaluation mechanism is canceled to accelerate the isolation of malicious nodes. Audit queries only support behavior tracing within the most recent 24 hours; data outside this range must be requested from nearby high-performance nodes to achieve tiered resource utilization.

[0069] Through the above structural adjustments, this embodiment, while maintaining the core security mechanism unchanged, controls the peak memory usage for a single consensus verification to within 28KB and the CPU utilization rate to less than 45%, and has been successfully deployed on industrial sensor nodes with extremely limited resources. This verifies the high configurability and engineering adaptability of the invention in different application scenarios.

[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0071] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A hybrid communication method based on Bluetooth dual-protocol stack, characterized in that, Includes the following steps: Initialize the distributed ledger nodes in the Bluetooth Mesh network, using IoT devices that support both Bluetooth Classic and Bluetooth Low Energy dual protocol stacks as network nodes. Assign a unique device identity to each device when it joins the network, and store the initial blockchain ledger structure locally. The initial blockchain ledger structure includes the genesis block and device public key information. A lightweight consensus mechanism is constructed, which adopts a hybrid consensus algorithm based on proof of stake and behavioral credibility weighting. The consensus weight is dynamically calculated based on the device's historical behavior records, message forwarding success rate and online duration. Only nodes with a weight greater than a preset threshold are allowed to participate in block generation and verification. Record device network entry and message forwarding behavior. When a new device requests to join the network, the neighboring nodes broadcast its identity credentials to the local subnet. After consensus verification, a network entry transaction is generated and written into a new block. During the message relay process, each forwarding node encapsulates the message digest, timestamp, source address and destination address into a behavior log, and submits it to the transaction pool to be packaged after digital signature. The block generation and synchronization process involves the selected master node in the current round collecting transactions to be confirmed, sorting them in chronological order to generate candidate blocks, and broadcasting them to neighboring nodes via Bluetooth Low Energy for rapid verification. Once verified, the blocks are synchronized via Bluetooth Classic to ensure consistency across the entire network ledger. It enables decentralized identity authentication and behavior auditing. Any node can query the historical network access records and message forwarding trajectory of any device based on the local ledger. By verifying the transaction signature chain, the source of behavior can be traced, and devices with abnormal behavior can be automatically isolated or have their permissions downgraded.

2. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 1, characterized in that, The device identity is generated by hashing the device's unique hardware serial number and the first network access timestamp. The device's public key is generated using the SM2 national cryptographic algorithm in elliptic curve cryptography, and the private key is securely stored in the device's secure element.

3. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 2, characterized in that, The weighting factors for the credibility of the behavior include message integrity verification pass rate, relay delay standard deviation, and collaborative score of the behavior by neighboring nodes. The collaborative score is calculated through a local reputation propagation mechanism. For each successful relay, the score increases by a specific value. If tampering or discarding of messages is detected, another specific value is deducted at once. The initial weight is set to a predetermined value, and the weight update is set to periodic update.

4. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 3, characterized in that, The network access transaction includes device identity, public key, network access request time, list of verification nodes and digital signatures of each verification node. The behavior log uses the SHA-3-256 algorithm to generate message digests, the timestamp precision is predetermined, and the current block height of the sending node is appended to prevent replay attacks.

5. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 4, characterized in that, The maximum capacity of the candidate block is limited to a predetermined capacity, containing no more than a predetermined number of transaction records. The block header includes the hash of the previous block, Merkle root, timestamp, consensus round number, and master node public key. The Bluetooth Low Energy channel is used to transmit the block header and transaction digest, and the Bluetooth Classic channel is used to transmit the complete block body. Block verification includes three checks: verifying the link between the block header hash and the previous block, verifying the consistency between the Merkle root and the transaction set, and verifying the validity of the master node signature and whether the consensus weight meets the requirements. If any check fails, the block is discarded and a new round of consensus election is triggered.

6. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 5, characterized in that, The behavior audit is achieved by traversing all transactions related to the target device in the local ledger. The audit results include the legality of the device's network access, the number of historical message forwardings, the frequency of abnormal behavior, and the most recent active time. If multiple consecutive relay behaviors are marked as abnormal, the consensus rights are automatically reset to zero and the device is prohibited from participating in the subsequent consensus process.

7. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 6, characterized in that, The system optimizes storage overhead under limited device resources by using a rolling window mechanism to retain only a predetermined number of complete data blocks. Earlier blocks are compressed into state snapshots, which contain the latest public keys, permission levels, and cumulative trust scores of all devices, with a compression ratio of no less than a predetermined ratio.

8. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 7, characterized in that, The collaborative scheduling strategy of the dual protocol stack is as follows: Bluetooth Low Energy is used for regular Mesh broadcasting, heartbeat packets and lightweight transaction digest transmission, while Bluetooth Classic is activated on demand when a large block synchronization requirement or an emergency security event is detected, with the activation delay controlled within a predetermined time range.

9. The hybrid communication method based on Bluetooth dual-protocol stack according to claim 8, characterized in that, At the beginning of each consensus cycle, the hybrid consensus algorithm requires all network nodes to independently calculate the candidate set of master nodes for this round based on their local ledgers. The candidate set includes nodes whose weight ranking is within a preset ratio range. Finally, the master node is selected from the candidate set through a verifiable random function.

10. A hybrid communication system based on Bluetooth dual-protocol stack, used to implement the method of any one of claims 1 to 9, characterized in that, include: The distributed ledger initialization module is used to assign a unique device identity and store the initial blockchain ledger structure on IoT devices that support both classic Bluetooth and Bluetooth Low Energy dual protocol stacks. A lightweight consensus building module is used to dynamically calculate consensus weights based on the device's historical behavior records, message forwarding success rate, and online duration, and to limit only high-weight nodes to participate in block generation and verification. The behavior recording module is used to generate network access transactions when a device joins the network, and to generate digitally signed behavior logs and submit them to the transaction pool to be packaged during message relay. The block generation and synchronization module is used to generate candidate blocks from the master node, perform fast verification through the low-power Bluetooth channel, and perform high-bandwidth block synchronization through the classic Bluetooth channel. The decentralized auditing module is used to query device historical behavior based on the local ledger and implement automatic isolation or permission downgrading.

Images