System and method for batch initialization and fine management of bluetooth devices based on mobile gateway

Abstract

The application belongs to the technical field of Internet of Things device management, and discloses a Bluetooth device batch initialization and fine management system and method based on a mobile gateway. The system is composed of a cloud management platform, a mobile gateway and a Bluetooth terminal. The mobile gateway and the Bluetooth terminal form a bidirectional space-time characteristic fingerprint through multiple bidirectional physical layer interactions, and the sequence value and the shared secret generated by bidirectional certificate authentication are used as key materials to derive a session key to establish an encrypted channel. Application layer data is adaptively fragmented according to the negotiation value of the current Bluetooth maximum transmission unit, the receiving end assembles and executes single and full volume checking according to the serial number. The cloud management platform determines the effective version according to the timestamp priority, permission priority and manual intervention three-level mechanism based on the parameter version account of the concurrent parameter modification record of the same Bluetooth terminal. The application takes into account the pairing anti-relay, reliable transmission of application layer data and consistency of multiple gateway concurrent parameters without relying on a special Bluetooth gateway.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) device management technology, and relates to a batch initialization and refined management system and method for Bluetooth devices based on a mobile gateway. Background Technology

[0002] Bluetooth terminals refer to embedded devices that only have Bluetooth communication capabilities and lack direct wide area network (WAN) connectivity. Existing solutions for the mass deployment and long-term maintenance of such terminals have several technological shortcomings in areas such as deployment methods, configuration granularity, pairing security, application layer data transmission, and consistency of multi-channel concurrent parameters.

[0003] Bluetooth terminals are isolated due to their lack of direct cloud connectivity. Existing batch initialization solutions mostly rely on dedicated Bluetooth gateways or specialized access hardware, with deployment costs typically ranging from hundreds to thousands of yuan per unit. Dedicated gateways are difficult to reuse across different scenarios once they are bound to specific terminal models, limiting their capacity for small to medium-scale deployments.

[0004] Once in the operation and maintenance phase, while existing solutions that replace dedicated gateways with mobile terminals have achieved automatic task synchronization and parameter distribution, their target terminal selection dimensions are mostly limited to a single dimension such as device model or device unique identifier. When there are batch-differentiated firmware parameters for the same model, or when personalized parameters are only distributed to a subset of specified terminals within the same region, single-dimensional selection cannot effectively locate the target terminal set.

[0005] The pairing process has more significant security vulnerabilities: the Bluetooth Low Energy protocol's default Just Works pairing mode does not perform authentication, making it easier for eavesdroppers to launch man-in-the-middle, relay, and replay attacks. Existing improvements typically rely on factory-pre-installed shared keys or identity-based two-way certificate authentication, but pure authentication mechanisms cannot perceive the physical location of the communicating entities; even after obtaining a forged but legally formatted certificate, an attacker can still remotely replicate an authenticated session channel, making it vulnerable to relay scenarios.

[0006] In the data transmission phase, the maximum transmission unit of the Bluetooth Low Energy protocol is only tens to hundreds of bytes. Application-layer structured data (such as initialization parameter sets with fields, batch data acquisition) typically exceeds this limit in a single packet. Existing solutions mostly rely on transparent fragmentation performed by the Bluetooth protocol stack at the link layer. This fragmentation is invisible to upper-layer applications and does not provide upper layers with fragment-level error location and retransmission entry points. Once fragments become out of order, damaged, or lost during transmission, the application layer can only detect the error in the reassembled complete data and retransmit the entire segment. For long application-layer data, retransmission is costly.

[0007] In the multi-concurrency management phase, multiple mobile gateways modify parameters of the same Bluetooth terminal under weak or no network conditions, leading to version conflicts when synchronizing back to the cloud. Existing solutions mostly use write-after-over or single-timestamp judgment; when modification records from different mobile gateways have similar or identical timestamps, but the corresponding maintenance roles have significantly different permissions, a single timestamp cannot distinguish between small-scale targeted changes by high-privilege roles and batch erroneous operations by low-privilege roles, nor does it provide a fallback solution for situations where neither of the first two layers can make a judgment.

[0008] In summary, existing solutions, while replacing dedicated Bluetooth gateways with mobile terminals, struggle to simultaneously achieve paired counter-relay, reliable big data transmission at the application layer, and consistency of parameters across multiple concurrent connections. Furthermore, these capabilities often require the addition of new trusted hardware, making them poorly adaptable to application scenarios sensitive to deployment costs. Summary of the Invention

[0009] The purpose of this invention is to address the problems of high deployment costs, coarse configuration granularity, Just Works pairing not being resistant to relaying, unreliable large data transmission at the application layer under BLE MTU limitations, and parameter version conflicts caused by concurrent offline modifications of multiple mobile gateways in existing Bluetooth terminal batch deployment and long-term operation and maintenance solutions. The invention provides a batch initialization and fine-grained management system and method for Bluetooth devices based on mobile gateways.

[0010] To achieve the above-mentioned objectives, the technical solution provided by this invention includes: A batch initialization and refined management system for Bluetooth devices based on a mobile gateway includes a cloud management platform, a mobile gateway, and Bluetooth terminals. The mobile gateway is configured to bridge the cloud management platform and the Bluetooth terminals. The mobile gateway and the Bluetooth terminals are configured to: perform multiple bidirectional physical layer interactions within a preset time window, and collect physical layer signal features during the bidirectional physical layer interactions to form a bidirectional spatiotemporal feature fingerprint. The serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret generated by bidirectional certificate authentication are used as input key material to derive a session key and establish an encrypted communication channel. Furthermore, the application layer data is adaptively fragmented according to the negotiated value of the current Bluetooth maximum transmission unit. Each fragment is appended with a fragment identifier containing the total number of fragments, a sequence number, a single-fragment checksum, and a full checksum. The receiving end assembles the fragments according to the sequence number and performs single-fragment and full-scale checks. The cloud management platform is configured to determine the effective version based on a three-level mechanism of timestamp priority, permission priority, and manual intervention for concurrent parameter modification records of the same Bluetooth terminal, according to a parameter version ledger.

[0011] Preferably, the physical layer signal features include at least two of the following: received signal strength, bidirectional transmission delay difference, carrier frequency offset, and frequency hopping synchronization error; the bidirectional spatiotemporal feature fingerprint is a feature vector composed of the physical layer signal features collected by the mobile gateway and the Bluetooth terminal through multiple bidirectional physical layer interactions within the preset time window.

[0012] Preferably, the mobile gateway and the Bluetooth terminal are further configured to: determine the consistency between the feature vector collected by the self-end and the feature vector sent by the peer end based on the cosine similarity; when the cosine similarity is not lower than a preset threshold, the pairing is considered successful; otherwise, the pairing is terminated; the preset time window and the preset threshold are configurable items.

[0013] Preferably, the input key material is formed by concatenating the serialized value of the bidirectional spatiotemporal feature fingerprint with the shared secret; the session key is obtained by processing the input key material through an HMAC-based key derivation function, and is used to perform symmetric encryption on application layer data transmitted through the encrypted communication channel.

[0014] Preferably, the adaptive fragmentation is determined by the transmitter based on the negotiated value of the current Bluetooth maximum transmission unit before each transmission; the single-fragment check code is the cyclic redundancy check value calculated by the transmitter for a single fragment payload, and the full check code is the cyclic redundancy check value calculated by the transmitter for the entire assembled fragment payload; the receiver requests the transmitter to retransmit the failed fragment or retransmit the full payload when the single-fragment check or the full check fails.

[0015] Preferably, the parameter version ledger records all parameter modifications for each Bluetooth terminal, and each parameter modification record includes a parameter version number, a timestamp, and a unique gateway identifier; the permission priority is determined based on the role permission matrix maintained by the cloud management platform, and the role permission matrix records the operation and maintenance role corresponding to each unique gateway identifier and the modification permissions of that operation and maintenance role for various parameters; when neither the timestamp priority nor the permission priority can determine the effective version, manual intervention is triggered.

[0016] Preferably, the cloud management platform is further configured to filter target Bluetooth terminals based on multiple dimensions including device unique identifier, device model, production batch and geographical group, and use the filtering results as the execution objects of the task; before executing the task, the mobile gateway matches the scanned Bluetooth terminals according to the multiple dimensions and then establishes a Bluetooth connection.

[0017] Preferably, the mobile gateway is further configured to: cache the tasks to be executed, the collected data, and the parameter modification records locally when communication with the cloud management platform is interrupted; and resume transmitting the unfinished tasks to be executed, the collected data, and the parameter modification records in the cached order when communication is restored.

[0018] This invention also discloses a method for batch initialization and fine-grained management of Bluetooth devices based on a mobile gateway, applied to a mobile gateway, comprising: performing multiple bidirectional physical layer interactions with a Bluetooth terminal within a preset time window, and collecting physical layer signal features during the bidirectional physical layer interactions to form a bidirectional spatiotemporal feature fingerprint; using the serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret generated by bidirectional certificate authentication as input key material to derive a session key and establish an encrypted communication channel; adaptively fragmenting the parameters issued by the cloud management platform through the encrypted communication channel according to the negotiated value of the current Bluetooth maximum transmission unit, and issuing each fragment with a fragment identifier containing the total number of fragments, a sequence number, a single fragment check code, and a full check code; assembling the data reported by the Bluetooth terminal according to the sequence number and performing single fragment and full check; reporting parameter modification records containing parameter version number, timestamp, and gateway unique identifier to the cloud management platform, and having the cloud management platform determine the effective version based on the parameter version ledger according to a three-level mechanism of timestamp priority, permission priority, and manual intervention.

[0019] Preferably, establishing an encrypted communication channel includes: initiating a handshake with the Bluetooth terminal; alternately sending physical layer probe signals with the Bluetooth terminal within a preset time window and collecting physical layer signal features of the peer's response; constructing a feature vector based on the physical layer signal features collected by the self-end and sending it to the Bluetooth terminal, and receiving the peer feature vector sent by the Bluetooth terminal; determining the consistency of the feature vectors of both parties according to a preset similarity metric, and entering bidirectional certificate authentication when the determination result meets a preset threshold; generating the shared secret based on the bidirectional certificate authentication; using the serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret as input key material to derive the session key through an HMAC-based key derivation function; and establishing the encrypted communication channel after negotiating encryption parameters based on the session key.

[0020] Beneficial effects Compared with the prior art, the beneficial effects of the present invention are reflected in the following three aspects: 1. To address the issue of Bluetooth pairing being vulnerable to relaying in open wireless environments, this invention provides a solution that uses physical layer near-field features as the binding element. It combines bidirectional spatiotemporal fingerprint features with the shared secret generated by bidirectional certificate authentication as input key material for the key derivation function. This fusion derivation method binds the generation of the session key to the physical observation of the near-field environment of both communicating parties, significantly increasing the difficulty for a remote attacker holding a forged legitimate certificate to recalculate the session key when relying solely on certificate-derived keys. Furthermore, it eliminates the need for maintenance personnel to intervene in the pairing process.

[0021] 2. To address the issue of large data transmission at the application layer under BLE MTU limitations, this invention adds a four-element fragmentation identifier at the application layer, containing the total number of fragments, sequence number, single-fragment checksum, and full checksum, thus decentralizing error location and retransmission operations to the single-fragment granularity. This fragmentation protocol operates at the application layer and is independent of transparent fragmentation at the link layer. In cases of out-of-order fragmentation, damaged or lost single fragments, the receiving end can request retransmission of only the failed fragments instead of the entire data segment, and it does not depend on any specific link layer implementation.

[0022] 3. To address the version conflict issue caused by multiple mobile gateways concurrently modifying the same Bluetooth terminal parameters offline, this invention introduces a three-tiered conflict resolution mechanism on the cloud management platform: timestamp, permissions, and manual intervention. A parameter version ledger records the version number, timestamp, and unique gateway identifier for each modification. This three-tiered mechanism allows concurrent modifications with similar or identical timestamps to have the effective version determined by the role-permission matrix. For cases where the first two levels cannot resolve the conflict, manual intervention is required, thereby reducing the probability of version inconsistencies in multi-role collaborative maintenance where single timestamp-based decision-making is insufficient. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of a Bluetooth device batch initialization and fine-grained management system based on a mobile gateway provided in a preferred embodiment of the present invention; Figure 2 This is a flowchart illustrating the batch initialization and fine-grained management method for Bluetooth devices based on a mobile gateway in a preferred embodiment of the present invention, in batch initialization mode. Figure 3 This is a flowchart illustrating the method for batch initialization and refined management of Bluetooth devices based on a mobile gateway in a preferred embodiment of the present invention under refined maintenance mode. Figure 4 This is a schematic diagram of a secure pairing process between a Bluetooth terminal and a mobile gateway provided in a preferred embodiment of the present invention. Figure 5 This is a schematic diagram of the application layer data adaptive fragmentation and reassembly process provided in a preferred embodiment of the present invention; Figure 6This is a schematic diagram of the three-level conflict resolution process of the cloud management platform provided in a preferred embodiment of the present invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0025] The Bluetooth terminal to which the system and method described in this invention are applicable refers to an embedded device that only has Bluetooth communication capabilities and does not have WAN direct connection capabilities, including but not limited to embedded sensors, intelligent hardware controllers and field instruments; the mobile gateway refers to a mobile device that has both Bluetooth communication and WAN communication capabilities and runs a gateway program, which can be a smartphone, tablet computer or portable industrial gateway; the cloud management platform can be deployed on an enterprise intranet server or on a public cloud of the Internet.

[0026] Example 1 like Figure 1 As shown, this embodiment provides the overall architecture of the system described in this invention. The system consists of three main layers: a cloud management platform, a mobile gateway, and a Bluetooth terminal, and is configured with a security and transmission adaptation layer that runs through all three layers.

[0027] The cloud management platform, deployed on the server side, is the core decision-making layer of the system, comprising a device management module, a task management module, a data storage and visualization module, and a security management module. The device management module maintains the unique device identifier, device model, production batch, geographic group, current parameter version number, and all parameter modification records for each registered Bluetooth terminal. These parameter modification records are organized chronologically in the form of a parameter version ledger, serving as input for the subsequent three-level conflict resolution mechanism. The task management module supports the creation of two types of tasks: batch initialization tasks for Bluetooth terminals of the same model or batch, and refined maintenance tasks located by unique device identifier, device model, production batch, or geographic group. Task records include target terminal selection criteria, parameters to be issued, execution method, and retry strategy. The data storage and visualization module stores the collected data reported by the Bluetooth terminals, task execution results, and conflict resolution records. It supports presenting the temporal changes of collected data in chart form and triggering alarms for data exceeding preset thresholds. The security management module maintains the authentication certificates of the mobile gateway and Bluetooth terminals, the gateway's unique identifier, and the role and permission matrix, and records security events during the pairing process.

[0028] The mobile gateway serves as the main bidirectional bridge between the cloud management platform and Bluetooth terminals, comprising a Bluetooth communication module, a cloud communication module, a task management module, a security authentication module, and a version synchronization module. The Bluetooth communication module scans for nearby Bluetooth terminals via Bluetooth Low Energy, filters target terminals using the Service Universal Unique Identifier (SUI), reads and writes feature values ​​at the GATT Universal Attribute Configuration File level, and sends and receives application-layer data in fragment units. This module supports simultaneous connections with multiple Bluetooth terminals, with 8 to 16 connections in a specific embodiment. The cloud communication module communicates with the cloud management platform via WiFi or cellular networks, synchronizing task execution results, collected data, and parameter modification records. When communication with the cloud management platform is interrupted, the module temporarily stores the tasks to be executed, collected data, and parameter modification records in local storage, and resumes transmission sequentially according to the cache order when communication resumes. The task management module parses the task instructions synchronized from the cloud management platform, stores the tasks in a local task queue, and executes them one by one, sorted by task creation time. The security authentication module stores the mobile gateway's own authentication certificate and the basic parameters required for session key derivation. It collaborates with the Bluetooth terminal to extract bidirectional spatiotemporal fingerprints, determine similarity, and derive session keys. The version synchronization module receives parameter version synchronization commands from the cloud management platform and updates the currently cached parameter version number of the Bluetooth terminal.

[0029] The Bluetooth terminal is the execution layer of the system and has a built-in client SDK. After the Bluetooth terminal is powered on, the client SDK automatically scans for Bluetooth broadcasts emitted by the mobile gateway; it filters the scanned broadcasts using a preset service universal unique identifier and broadcast name as matching conditions; upon a successful match, it initiates a bidirectional spatiotemporal fingerprint extraction and verification process with the mobile gateway, and receives and reports collected data after successful pairing. Internally, the client SDK is functionally divided into several sub-parts: Bluetooth connection, security authentication, parameter processing, and data acquisition and fragmentation / reassembly. These sub-parts respectively handle Bluetooth link layer connection maintenance, security verification during pairing, overlay storage of transmitted parameters, acquisition of local sensor data at preset intervals, and fragmented transmission and reassembly reception of application layer data.

[0030] The security and transmission adaptation layer spans the three main layers of the cloud management platform, mobile gateway, and Bluetooth terminal, carrying the three core mechanisms described in this invention: first, a secure pairing mechanism based on bidirectional spatiotemporal fingerprinting and a shared secret fusion-derived session key generated by bidirectional certificate authentication; second, an application-layer data fragmentation and reassembly mechanism based on the negotiated value of the current Bluetooth maximum transmission unit; and third, a three-level conflict resolution mechanism on the cloud management platform side based on a parameter version ledger. The security and transmission adaptation layer is not an independent physical entity, but rather a functional layer formed by the coordinated operation of the above three mechanisms within the three main layers.

[0031] The data exchanged between the Bluetooth terminal and the mobile gateway is divided into channels according to several characteristic values ​​under the general attribute configuration file. Each characteristic value is identified by a universally unique identifier pre-installed in the client SDK and the mobile gateway at the factory. In one specific embodiment, the several characteristic values ​​include five: the first characteristic value is used to transmit the authentication certificate required for bidirectional certificate authentication between the Bluetooth terminal and the mobile gateway; the second characteristic value is used for the Bluetooth terminal to report the device's unique identifier, device model, and production batch; the third characteristic value is used for the mobile gateway to send initialization parameters or maintenance parameters to the Bluetooth terminal; the fourth characteristic value is used for the Bluetooth terminal to send back locally collected data and task execution results to the mobile gateway; and the fifth characteristic value is used to transmit the physical layer signal characteristics collected by each terminal during the bidirectional spatiotemporal fingerprint extraction stage. The specific universally unique identifier values ​​used for each characteristic value do not constitute a limitation on the scope of protection of this invention. Those skilled in the art can use other universally unique identifier values ​​that conform to the specifications without changing the above five channel functional divisions, which are also within the scope of implementation of this invention.

[0032] The specific implementation methods of the three core mechanisms carried by the security and transport adaptation layer are given below.

[0033] For the secure pairing mechanism of bidirectional spatiotemporal fingerprint and shared secret fusion derived session key generated by bidirectional certificate authentication, such as Figure 4 As shown, the secure pairing between the Bluetooth terminal and the mobile gateway includes four interconnected stages: bidirectional physical layer probing, feature vector construction and consistency determination, bidirectional certificate authentication and session key derivation.

[0034] In the first phase, after scanning the Bluetooth broadcast from the mobile gateway and matching the service universal unique identifier with the broadcast name, the Bluetooth terminal initiates a handshake with the mobile gateway. The mobile gateway responds to the handshake and triggers bidirectional physical layer probing. Both parties alternately send physical layer probing signals within a preset time window and collect several physical layer signal characteristics from the received peer probing signals. These physical layer signal characteristics include at least two of the following: received signal strength, bidirectional transmission delay difference, carrier frequency offset, and frequency hopping synchronization error. In one specific embodiment, the preset time window is 200ms, and both parties perform three bidirectional interactions within this time window, collecting the aforementioned four physical layer signal characteristics as physical layer observation samples for this pairing. In other embodiments, the preset time window can be adjusted within the range of milliseconds to hundreds of milliseconds, and the number of bidirectional interactions can also be adjusted within a range of several times depending on the noise level.

[0035] The upper bound of the preset time window is determined by the reasonable observation assumption that the near-field environment remains basically unchanged. If the window is too long, the relative positions of the communicating parties or the near-field scatterers may change during the pairing process, causing inconsistencies in the physical layer signal characteristics collected by both ends. If the window is too short, the number of bidirectional interactions that can be completed within the window is limited, and the sampling dimension of the feature vector is insufficient to suppress noise. The lower bound of the preset time window is determined by the minimum timing constraints required for the Bluetooth physical layer to complete multiple bidirectional interactions.

[0036] In the second stage, the Bluetooth terminal and the mobile gateway each construct feature vectors based on several physical layer signal features collected by themselves, and assign weights to each component within the feature vector according to its signal-to-noise ratio (SNR). This ensures that physical layer signal features with higher SNR contribute more to the final consistency determination in the near-field environment of this pairing. Each terminal sends its constructed feature vector to the peer terminal via the fifth feature value and receives the peer terminal's feature vector.

[0037] For the received feature vectors from the other end and the feature vectors collected from the self end, the consistency between the two is determined by cosine similarity. Let the feature vector from the self end be... The feature vector of the other end is The cosine similarity between the two is calculated using the following formula: ; in, This represents the feature vector constructed by the self-end based on the physical layer signal characteristics of the peer end that it has collected; This represents the feature vector constructed by the peer based on the physical layer signal characteristics collected by the peer and sent to this end; This represents the inner product of two eigenvectors; and Let L2 norms of the two eigenvectors be represented respectively. This represents the cosine similarity between two eigenvectors.

[0038] When the calculated If the near-field physical layer environment observed by both parties is not lower than a preset threshold, it is determined that the near-field legality of this pairing is passed; otherwise, the pairing is terminated. In one specific embodiment, the preset threshold is 0.95; in other embodiments, the preset threshold can be appropriately adjusted according to the physical layer noise level of the Bluetooth terminal deployment scenario. In scenarios with high noise levels, the threshold can be appropriately lowered to avoid too many normal pairings being mistakenly judged as failures, while in scenarios with low noise levels, the threshold can be appropriately raised to improve the recognition sensitivity of relay scenarios.

[0039] The calibration logic for the preset threshold can be given according to the signal-to-noise ratio benchmark at the deployment site. In one calibration embodiment, the Bluetooth terminal is placed in a legitimate pairing environment free from relay attacks. Several sets of bidirectional physical layer signal features are collected as described in the first stage above. Feature vectors for legitimate pairing scenarios are constructed respectively, and their cosine similarity is calculated as described in this section. The mean of the obtained cosine similarity samples is then statistically analyzed. with standard deviation ,according to The form determines the initial value of the preset threshold, where This is a configurable confidence coefficient. In one specific embodiment, it is taken as... A value of 3 ensures that cosine similarity samples in a legal pairing environment fall above the threshold with a relatively high probability; in deployment scenarios with high noise levels, the value can be appropriately increased. In deployment scenarios with low noise levels, the noise level can be appropriately reduced. .

[0040] In the third stage, after near-field legitimacy is verified, two-way certificate authentication begins. The Bluetooth terminal sends its pre-stored authentication certificate to the mobile gateway via a first feature value, and the mobile gateway correspondingly sends its own authentication certificate to the Bluetooth terminal. Both parties then use the peer's public key to verify the signature and validity of the received authentication certificates. After successful two-way certificate authentication, both parties generate a shared secret based on this two-way certificate authentication process. The shared secret can be generated through key negotiation based on the private-public key pair, or it can be derived from the random number exchanged during the two-way certificate authentication process and the respective private keys.

[0041] In the fourth stage, the aforementioned near-field legitimacy is verified by serializing the corresponding bidirectional spatiotemporal feature fingerprint and combining it with the shared secret generated by bidirectional certificate authentication. Together as input key material It is formed by splicing according to the following formula: ; in, This function represents the serialization of the input feature vector according to a predetermined byte order and field order. This represents the ordered concatenation of the feature vectors from the first end and the second end; This refers to the shared secret generated during the two-way certificate authentication process; This indicates the input key material.

[0042] Will Input the HMAC-based key derivation function to obtain the session key for this pairing. Defined by the following formula: ; in, This represents a key derivation function based on HMAC; This refers to the input key material formed by concatenating bytes as described above; This represents the random salt value exchanged by the two communicating parties during the handshake phase; This field represents the identifier used to bind the context of this session, including the unique device identifier of the Bluetooth terminal, the unique gateway identifier of the mobile gateway, and the timestamp of this session. Indicates the length in bytes of the derived session key; This represents the session key derived from this pairing. The derived session key is used for symmetric encryption of application layer data during this session. In one specific embodiment, the symmetric encryption algorithm used is AES-128-GCM.

[0043] Using a bidirectional spatiotemporal fingerprint and a shared secret generated by bidirectional certificate authentication as input key materials is a key technological choice in the secure pairing mechanism described in this invention. The approach of deriving the session key solely from the shared secret generated by bidirectional certificate authentication means the session key depends only on the certificates of both parties and the negotiated random number. If an attacker possesses a forged but legally formatted certificate, they can remotely recalculate the same session key as the legitimate node, thereby relaying the encrypted channel. This mechanism adds a bidirectional spatiotemporal fingerprint to the session key derivation input. This fingerprint is generated by multiple bidirectional physical layer interactions between the communicating parties in the near field. The physical layer signal characteristics between the relay attacker and the near-end node are affected by factors such as the attacker's relative position to the near-end node, the near-field scattering environment, and differences in device hardware fingerprints. These characteristics often differ significantly from those between the attacker and the remote legitimate node. The remote attacker needs to accurately replicate this fingerprint under conditions of asymmetric physical distance from the legitimate node to recalculate the same session key, thus significantly increasing the difficulty of replication. This mechanism does not require a dedicated trusted channel between the Bluetooth terminal and the mobile gateway, nor does it require embedding a dedicated security chip in the Bluetooth terminal, thus adding virtually no new hardware cost to the Bluetooth terminal.

[0044] In some preferred embodiments, such as Figure 5 As shown, it also includes an application layer data fragmentation and reassembly mechanism. This mechanism consists of two mutually cooperating sub-processes: adaptive fragmentation at the sending end and sequential assembly at the receiving end. It is applied to the application layer structured data transmission carried on all feature values ​​in this system.

[0045] The adaptive fragmentation process at the sending end is as follows: Before each transmission, the sending end first obtains the negotiated value of the current Bluetooth maximum transmission unit (MTU) of the current Bluetooth connection. The negotiated MTU value is determined by both communicating parties during each connection establishment and is subject to the maximum values ​​supported by both parties and the limitations of the link layer implementation. This mechanism does not require the MTU to be a fixed value; it only determines the single-piece payload length based on the negotiated value before each transmission. Based on the single-piece payload length and the length of the application layer data to be transmitted, the sending end calculates the total number of fragments required. The application layer data is then divided into several fragments according to the single-piece payload length, and a fragment identifier is attached to each fragment. ; in, Indicates the total number of fragments transmitted in this transfer; This indicates the sequence number of the current fragment in the fragment sequence; This represents the cyclic redundancy check value calculated by the sender for the current fragmented payload, serving as the single-fragment check code; This represents the overall cyclic redundancy check (CRC) value calculated by the transmitting end for all fragmented payloads after assembly, serving as the full checksum. The CRC value used is a 32-bit CRC checksum, and its polynomial is selected according to the general CRC32 standard.

[0046] After attaching the fragmentation identifier, the sender presses... Each fragment is sequentially sent to the corresponding feature value's transmission queue, and then transmitted piece by piece to the receiving end by the Bluetooth link layer.

[0047] The sequential assembly process at the receiving end is as follows. The receiving end allocates a sequence number for this transmission. The size of the receive buffer and a pressurized buffer A size-defined array of bit flags is allocated; for each arriving fragment, the receiver sets the size according to... The payload is written to the corresponding position in the receive buffer, and its single-piece checksum is verified: if the single-piece checksum passes, the corresponding bit flag is set; if the single-piece checksum fails, a request is made to the sender to retransmit the failed single-piece piece, and the bit flag at that position is left unset. Once all bit flags are set, the receiver proceeds according to... The application layer data is assembled sequentially to obtain a complete data body, and a full verification is performed on the complete data body: if the full verification passes, the assembled application layer data body is handed over to the upper layer logic for decryption, parsing and application; if the full verification fails, a full retransmission is requested from the sending end, or according to the context configuration, only a few fragments with suspected inconsistent verification values ​​are requested to be retransmitted.

[0048] The application-layer four-element fragmentation identifier and the two-layer verification of single fragments and the entire data are the key differences between this mechanism and existing BLE data transmission schemes. L2CAP transparent fragmentation at the link layer is completed by the Bluetooth protocol stack at the link layer, invisible to upper-layer applications and providing no entry point for fragment-level error location and retransmission. Existing schemes often directly rely on L2CAP transparent fragmentation at the application layer. If application-layer data becomes out of order, or if a single fragment is damaged or lost during transmission, the application layer can only detect the error in the reassembled complete data and retransmit the entire segment, which is costly for long application-layer data. This mechanism defines a protocol format with a four-element fragmentation identifier at the application layer, allowing error location to be pushed down to the fragment granularity. If a single fragment verification fails, only that single fragment needs to be retransmitted. If the entire data verification fails, several fragments with suspected inconsistent verification values ​​can be retransmitted first before performing overall verification, avoiding the waste of retransmitting the entire segment every time a partial fragment failure occurs. This mechanism does not impose restrictions on the cyclic redundancy check bit width or polynomial value used; on low-computing-power Bluetooth terminals that are more sensitive to computational overhead, cyclic redundancy check or other check functions with lower computational overhead can be used; in industrial sites where the error detection rate is more critical, a hash check field can be added to the fragment identifier.

[0049] The following section provides further explanation of the three-level conflict resolution mechanism based on the parameter version ledger, such as... Figure 6 As shown, the cloud management platform's processing flow for parameter modification records from the mobile gateway includes five interconnected stages: receiving parameter modification records, querying the parameter version ledger, detecting whether there are version conflicts, and determining the effective version and the synchronously effective version according to a three-level mechanism.

[0050] The parameter version log is maintained chronologically for each Bluetooth terminal by the cloud management platform, recording all parameter modifications. Each parameter modification record contains at least three fields: parameter version number. timestamp The unique identifier of the mobile gateway that initiated this parameter modification. When the cloud management platform receives multiple parameter modification records for the same Bluetooth terminal from different mobile gateways within a short time window, the cloud management platform first compares the parameter version number carried in each record. When multiple records correspond to the same parameter version number When the increments are not consecutive, it is considered a version conflict, triggering a three-level conflict resolution mechanism.

[0051] The first level prioritizes timestamps. The cloud management platform prioritizes timestamps carried by each conflict record. Compare the timestamps. The record with the largest value is selected as the candidate for the effective version; when the timestamps of conflicting records... When the difference is greater than the preset timestamp resolution threshold, the first-level decision takes effect, and the parameter corresponding to the selected candidate record becomes the effective version.

[0052] The second level prioritizes permissions. (This refers to the timestamps of conflict records.) If the difference between the timestamps is no greater than the preset timestamp resolution threshold, or if multiple records have identical timestamps, the first level cannot determine the effective version, and the process proceeds to the second level. The cloud management platform maintains a role-based access control matrix, recording a unique identifier for each gateway. The corresponding operation and maintenance roles and their modification permissions for various parameters are specified. Operation and maintenance roles include at least three categories: senior operation and maintenance, general operation and maintenance, and field engineer. Parameter types include at least three categories: security configuration parameters, business configuration parameters, and sampling and reporting configuration parameters. The corresponding role permission matrix is ​​given in a specific embodiment as shown in Table 1 below: Table 1 Role Permission Matrix The cloud management platform uses the unique gateway identifier carried in each conflict record. The role permission matrix is ​​retrieved to obtain the operation and maintenance role corresponding to the unique identifier of each gateway. The legality of permissions is then determined by looking up the relevant parameters in the matrix according to the parameter types involved in this parameter modification. Records with valid permissions take precedence over records with invalid permissions, and roles with broader permission ranges take precedence over roles with narrower permission ranges. When the second-level adjudication can determine a unique effective version among several conflicting records with approximately the same timestamp, the parameters corresponding to the selected record are taken as the effective version.

[0053] The third level involves manual intervention. When neither the first nor the second level can determine a unique effective version, the cloud management platform will not immediately write a new effective version. Instead, it will suspend the parameter change and send a notification to the administrator account registered with the cloud management platform. Upon receiving the notification, the administrator will compare the parameter differences among the conflicting records using the comparison view provided by the platform, and manually designate one of them as the effective version, or choose to reject all conflicting records and require the relevant operations and maintenance personnel to re-initiate the parameter modification. The third-level ruling result and the reasons for the ruling will be written into the parameter version ledger.

[0054] The effective version determined by the above three-level mechanism is pushed to all relevant mobile gateways and corresponding Bluetooth terminals by the cloud management platform via version synchronization instructions. After receiving the version synchronization instructions, the mobile gateway updates the current parameter version number of the Bluetooth terminal in its local cache, and synchronizes the effective version to its local storage the next time it establishes an encrypted communication channel with the Bluetooth terminal.

[0055] Introducing a second-level permission layer is a key technological choice in this mechanism compared to existing version management solutions. Existing solutions often use a single timestamp for decision-making, taking the parameter modification corresponding to the latest timestamp as the effective version. In scenarios with multiple mobile gateways making concurrent offline modifications, the probability of the timestamp differences of multiple modification records falling within the second or sub-second range is significant. Single-timestamp decision-making cannot distinguish the relative priority of modification records from different operation and maintenance roles. For example, if a small number of targeted changes from senior operation and maintenance personnel and a batch of erroneous operations from a field engineer arrive simultaneously with approximately the same timestamp, single-timestamp decision-making may treat the latter as the effective version, leading to parameter version inconsistencies. This mechanism introduces a role permission matrix as the second-level decision-making basis, prioritizing records whose permission scope matches the type of parameter modification, thereby reducing the probability of erroneous overwriting due to insufficient timestamp resolution. The third level of manual intervention serves as a fallback for the first two levels. If the first two levels cannot make a decision, the decision-making power is handed over to the administrator for manual processing, bringing the probability of erroneous overwriting within a controllable range.

[0056] It should be understood that the specific implementation forms of the three main components—the cloud management platform 1, the mobile gateway 2, and the Bluetooth terminal 3—can be equivalently replaced without changing the above functional division: The mobile gateway 2, in addition to using a smartphone, can also be a tablet computer or a portable industrial gateway. In industrial environments with strong electromagnetic interference, the metal shielding shell of the portable industrial gateway can reduce the environmental noise level during physical layer signal feature acquisition, allowing the cosine similarity determination of bidirectional spatiotemporal fingerprints in this scenario to be appropriately increased from the aforementioned 0.95, thereby improving the recognition sensitivity in relay scenarios; the cloud management platform 1, in addition to being deployed on a public cloud, It can also be deployed on a server within an enterprise LAN to adapt to confidential scenarios, or a hybrid deployment can be adopted, with the core business module deployed on the enterprise intranet and the data visualization module deployed on the Internet. In all deployment forms, the wide area network communication between the mobile gateway and the cloud management platform is encrypted using the HTTPS protocol. In addition to Bluetooth Low Energy, the Bluetooth type used by the Bluetooth terminal 3 can also be Bluetooth Classic in scenarios where there are no strict constraints on power consumption but high requirements for single transmission rate. Bluetooth Classic natively supports larger transmission units. In this scenario, the adaptive fragmentation mechanism described in this invention only performs fragmentation when the application layer data length exceeds the current maximum transmission unit; otherwise, it transmits directly as a single packet.

[0057] Example 2 This embodiment describes the overall execution flow of the method of the present invention from the perspective of the mobile gateway. The method runs in the implementation environment of the system described in Embodiment 1, covering two application scenarios: batch initialization and fine-grained maintenance. The overall sequence of several steps remains consistent in both scenarios, differing only in the source of the pre-tasks and the selection criteria for the target terminals.

[0058] like Figure 2 As shown, in batch initialization mode, the method of the present invention includes: Step S1: The mobile gateway synchronizes batch initialization tasks and starts Bluetooth broadcasting. Maintenance personnel arrive at the deployment site of the Bluetooth terminals with a mobile terminal running the mobile gateway program. The mobile gateway logs into the cloud management platform via WiFi or cellular network and automatically synchronizes the batch initialization tasks for this batch. The synchronized tasks include general initialization parameters, the target Bluetooth terminal's device model or production batch, and security configuration parameters. After task synchronization is complete, the mobile gateway caches the above task parameters and required key materials in local storage and starts Bluetooth broadcasting according to the preset service universal unique identifier and broadcast name. Simultaneously, the mobile gateway enters the physical layer signal feature acquisition preparation state. After powering on, the Bluetooth terminal scans the mobile gateway's Bluetooth broadcast using the built-in client SDK. Upon successful pairing, it enters the pairing pre-pairing state.

[0059] Step S2: The mobile gateway and Bluetooth terminal establish an encrypted communication channel by fusing a shared secret generated from bidirectional spatiotemporal fingerprint and bidirectional certificate authentication into a session key, following the four stages of the secure pairing mechanism described in Embodiment 1. After successful pairing, an encrypted GATT channel protected by the session key is formed between the mobile gateway and the Bluetooth terminal, and all application layer data exchanged in subsequent steps is transmitted through this channel.

[0060] Step S3: The Bluetooth terminal reports its unique device identifier, device model, and production batch via the second feature value. The mobile gateway compares this reported information with the target filtering conditions in the local task queue. If the comparison result matches, the Bluetooth terminal is included in the target for parameter transmission; otherwise, the connection is disconnected, releasing only the Bluetooth terminal's connection resources and preventing further parameter transmission.

[0061] Step S4: The mobile gateway, following the application layer data fragmentation and reassembly mechanism described in Embodiment 1, adaptively fragments the initialization parameters to be sent according to the negotiated value of the current Bluetooth maximum transmission unit. Each fragment is appended with a fragment identifier containing the total number of fragments, a sequence number, a single-fragment checksum, and a full checksum. This identifier is then sequentially sent to the Bluetooth terminal via a third feature value. The Bluetooth terminal temporarily stores each fragment in the receiving buffer according to its sequence number, performs single-fragment verification on each fragment immediately, and assembles all fragments after they are collected, performing a full checksum on the assembled whole.

[0062] Step S5: After the Bluetooth terminal passes the full parameter verification after assembly, it decrypts the parameters using the session key established during this pairing, and stores the obtained initialization parameters in the local non-volatile storage and makes them effective immediately. At the same time, it records the parameter version number, timestamp, and unique identifier of the mobile gateway that initiated the change. The Bluetooth terminal returns an initialization success response to the mobile gateway via the fourth feature value, and the response carries a digest of the parameter version number that has taken effect.

[0063] Step S6: The mobile gateway synchronizes the task execution result to the cloud management platform; if communication with the cloud management platform is interrupted, the task execution result is temporarily stored locally and will be resumed in cache order after communication is restored. After receiving the task execution result, the cloud management platform updates the initialization status of the Bluetooth terminal and expands its parameter version ledger.

[0064] Step S7: The mobile gateway repeats steps S1 to S6 until all target Bluetooth terminals covered by this batch of tasks have completed initialization or reached the preset retry limit. For Bluetooth terminals that have not completed initialization within this task window, the mobile gateway adds them to the failure queue, awaiting manual intervention from maintenance personnel.

[0065] like Figure 3 As shown, in the refined maintenance mode, the overall sequence of the method described in this invention is the same as that in the batch initialization mode, with the difference being: First, the task source has changed from batch initialization tasks to refined maintenance tasks. Target selection criteria can be provided by any dimension or combination of multiple dimensions, including unique device identifier, device model, production batch, or geographical group. In one specific embodiment, maintenance personnel choose to accurately distribute personalized calibration parameters based on the unique device identifier; in another specific embodiment, maintenance personnel choose to distribute a unified sampling period and reporting frequency to all Bluetooth terminals in a workshop based on geographical group; in yet another specific embodiment, maintenance personnel choose to distribute model-batch specific firmware update parameters based on a two-dimensional combination of device model and production batch. In all the above specific embodiments, the mobile gateway compares one or more of the reported unique device identifier, device model, production batch, and geographical group with the selection criteria of the local task queue. If the comparison matches, a connection is established; otherwise, the connection is abandoned.

[0066] Second, the application layer data sent out has been changed from general initialization parameters to maintenance parameters differentiated according to filtering dimensions. After the data is sent out, the Bluetooth terminal uploads the recently collected sensor readings, operation logs, and fault information via the fourth feature value. This uplink data is usually large in volume, and is uploaded piece by piece by the Bluetooth terminal after adaptive fragmentation according to the application layer data fragmentation and reassembly mechanism described in Example 1. The mobile gateway performs assembly and single-piece and full-data two-layer verification.

[0067] Third, the mobile gateway synchronizes the parameter modification records of this maintenance task to the cloud management platform. In the case where multiple mobile gateways simultaneously initiate maintenance tasks for the same Bluetooth terminal, the cloud management platform determines the effective version according to the three-level conflict resolution mechanism based on the parameter version ledger described in Example 1, and synchronizes the effective version to all relevant mobile gateways and Bluetooth terminals, expanding the parameter version ledger of the Bluetooth terminal.

[0068] Fourth, for the target Bluetooth terminal that fails to complete the task in the current attempt, the mobile gateway scans for surrounding Bluetooth terminals at a preset retry interval and initiates connection and task execution again. If the task is still not completed after the preset maximum number of retries, the mobile gateway reports the task execution failure to the cloud management platform and provides the reason for the failure in the record. In one specific embodiment, the preset retry interval is once every 5 minutes, and the preset maximum number of retries is 10. The reasons for failure include Bluetooth terminal offline, two-way certificate authentication failure, feature vector consistency determination failure, and transmission timeout.

[0069] In some preferred embodiments, the method of the present invention further includes: when communication with the cloud management platform is interrupted, caching the tasks to be executed, collected data, and parameter modification records in local non-volatile storage; and resuming the transmission of incomplete tasks to be executed, collected data, and parameter modification records in the cached order when communication is restored. This resuming transmission is performed at the fragment granularity; fragments that have already been transmitted during the previous interruption are not uploaded again, and incomplete fragments are transmitted sequentially according to their position in the fragment sequence, avoiding additional energy consumption and traffic overhead caused by frequent full retransmissions in long-term weak network environments.

[0070] It should be understood that the method described in this embodiment can be extended in specific implementations as follows: the symmetric encryption algorithm corresponding to the session key is replaced by other authentication encryption algorithms known in the art, including but not limited to AES-256-GCM and ChaCha20-Poly1305; the hash algorithm corresponding to the HMAC-based key derivation function is replaced by SHA-256 and other collision-resistant hash algorithms known in the art; the derived session key still relies on the concatenated input key material of the bidirectional spatiotemporal feature fingerprint and the shared secret generated by bidirectional certificate authentication. The similarity metric in the feature vector consistency determination is replaced by other similarity metrics known in the art. In one specific embodiment, it is replaced by the Pearson correlation coefficient, calculated as follows: the inner product of the centered vectors obtained by subtracting the mean of each component from the feature vector at the self end and the feature vector at the other end, divided by the product of the L2 norms of the two centered vectors. When the obtained correlation coefficient is not lower than a preset threshold, consistency is considered passed. In another specific embodiment, it is replaced by a determination based on Mahalanobis distance. The covariance matrix between the feature vector components is estimated in advance under a legal pairing environment. The Mahalanobis distance between the feature vectors at the self end and the other end is calculated according to the covariance matrix. When the obtained Mahalanobis distance is not higher than a preset distance threshold, consistency is considered passed. In yet another specific embodiment, it is replaced by a distance metric based on dynamic time warping. The cumulative distance is calculated after optimally aligning the physical layer signal feature sequences at the self end and the other end on the time axis. The task filtering dimensions can be further expanded to include filtering by device operating status, in addition to device unique identifier, device model, production batch, and geographical grouping. The physical layer signal features in the bidirectional spatiotemporal fingerprint can also be expanded to include features derived from other observable physical layer quantities, in addition to received signal strength, bidirectional transmission delay difference, carrier frequency offset, and frequency hopping synchronization error. Regardless of the specific implementation of the above extensions, as long as the functional division of the three core mechanisms described in this invention is maintained, the system and method described in this invention are applicable.

[0071] The above embodiments are merely illustrative of the technical solutions of the present invention and are not intended to limit them; any modifications, equivalent substitutions and improvements made by those skilled in the art to the specific technical details of the above embodiments without departing from the scope of protection defined by the claims of the present invention should be included within the scope of protection of the present invention.

[0072] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A batch initialization and refined management system for Bluetooth devices based on a mobile gateway, characterized in that, The system includes a cloud management platform, a mobile gateway, and a Bluetooth terminal. The mobile gateway is configured to bridge the cloud management platform and the Bluetooth terminal. The mobile gateway and the Bluetooth terminal are configured to perform multiple bidirectional physical layer interactions within a preset time window, and collect physical layer signal features during the bidirectional physical layer interactions to form a bidirectional spatiotemporal feature fingerprint. The serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret generated by bidirectional certificate authentication are used together as input key material to derive a session key and establish an encrypted communication channel. Furthermore, the application layer data is adaptively fragmented according to the negotiated value of the current Bluetooth maximum transmission unit. Each fragment is attached with a fragment identifier containing the total number of fragments, a sequence number, a single fragment check code, and a full check code. The receiving end assembles the fragments according to the sequence number and performs single fragment check and full check. The cloud management platform is configured to determine the effective version based on a three-level mechanism of timestamp priority, permission priority, and manual intervention for concurrent parameter modification records of the same Bluetooth terminal, based on the parameter version ledger.

2. The Bluetooth device batch initialization and refined management system based on a mobile gateway according to claim 1, characterized in that, The physical layer signal features include at least two of the following: received signal strength, bidirectional transmission delay difference, carrier frequency offset, and frequency hopping synchronization error; the bidirectional spatiotemporal feature fingerprint is a feature vector composed of the physical layer signal features collected by the mobile gateway and the Bluetooth terminal through multiple bidirectional physical layer interactions within the preset time window.

3. The Bluetooth device batch initialization and refined management system based on a mobile gateway according to claim 2, characterized in that, The mobile gateway and the Bluetooth terminal are further configured to: determine the consistency of the feature vector collected by the self-end and the feature vector sent by the peer end based on the cosine similarity; when the cosine similarity is not lower than a preset threshold, the pairing is considered successful, otherwise the pairing is terminated; the preset time window and the preset threshold are configurable items.

4. The Bluetooth device batch initialization and refined management system based on a mobile gateway according to claim 1, characterized in that, The input key material is formed by concatenating the serialized value of the bidirectional spatiotemporal feature fingerprint with the shared secret; the session key is obtained by processing the input key material through an HMAC-based key derivation function, and is used to perform symmetric encryption on application layer data transmitted through the encrypted communication channel.

5. The Bluetooth device batch initialization and refined management system based on a mobile gateway according to claim 1, characterized in that, The adaptive fragmentation is determined by the transmitter based on the negotiated value of the current Bluetooth maximum transmission unit before each transmission, thus determining the effective payload length of a single fragment. The single-piece check code is the cyclic redundancy check value calculated by the transmitter for a single fragment of the payload, and the full check code is the cyclic redundancy check value calculated by the transmitter for the entire assembled payload of all fragments; when the single-piece check or the full check fails, the receiver requests the transmitter to retransmit the failed fragment or retransmit the full payload.

6. The Bluetooth device batch initialization and fine-grained management system based on a mobile gateway according to claim 1, characterized in that, The parameter version ledger records all parameter modifications for each Bluetooth terminal. Each parameter modification record includes a parameter version number, a timestamp, and a unique gateway identifier. The permissions are determined primarily based on the role permission matrix maintained by the cloud management platform. The role permission matrix records the maintenance role corresponding to each unique gateway identifier and the maintenance role's modification permissions for various parameters. The manual intervention is triggered when neither the timestamp priority nor the permission priority can determine the effective version.

7. The Bluetooth device batch initialization and refined management system based on a mobile gateway according to claim 1, characterized in that, The cloud management platform is also configured to filter target Bluetooth terminals based on multiple dimensions, including device unique identifier, device model, production batch, and geographical group, and use the filtering results as the execution objects of the task to be issued; before executing the task, the mobile gateway matches the scanned Bluetooth terminals according to the multiple dimensions and then establishes a Bluetooth connection.

8. The Bluetooth device batch initialization and fine-grained management system based on a mobile gateway according to claim 1, characterized in that, The mobile gateway is further configured to: cache the tasks to be executed, the collected data, and the parameter modification records locally when communication with the cloud management platform is interrupted; and resume transmitting the unfinished tasks to be executed, the collected data, and the parameter modification records in the cached order when communication is restored.

9. A method for batch initialization and fine-grained management of Bluetooth devices based on a mobile gateway, applied to a mobile gateway, characterized in that: include: The system performs multiple bidirectional physical layer interactions with the Bluetooth terminal within a preset time window, and collects physical layer signal features during the bidirectional physical layer interactions to form a bidirectional spatiotemporal feature fingerprint. The serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret generated by bidirectional certificate authentication are used together as input key material to derive a session key and establish an encrypted communication channel. The parameters sent by the cloud management platform through the encrypted communication channel are adaptively fragmented according to the negotiated value of the current Bluetooth maximum transmission unit. Each fragment is sent after being attached with a fragment identifier containing the total number of fragments, the sequence number, the single fragment check code and the full check code. The data reported by the Bluetooth terminal is assembled according to the sequence number and single fragment and full check are performed. The cloud management platform reports parameter modification records containing parameter version number, timestamp, and gateway unique identifier. The cloud management platform then determines the effective version based on the parameter version ledger, following a three-level mechanism: timestamp priority, permission priority, and manual intervention.

10. The method for batch initialization and fine-grained management of Bluetooth devices based on a mobile gateway according to claim 9, characterized in that, The establishment of the encrypted communication channel includes: initiating a handshake with the Bluetooth terminal; alternately sending physical layer probe signals with the Bluetooth terminal within the preset time window and collecting physical layer signal features of the peer's response; constructing a feature vector based on the physical layer signal features collected by the self-end and sending it to the Bluetooth terminal, and receiving the peer feature vector sent by the Bluetooth terminal; determining the consistency of the feature vectors of both parties according to a preset similarity metric, and entering bidirectional certificate authentication when the determination result meets a preset threshold; generating the shared secret based on the bidirectional certificate authentication; using the serialized value of the bidirectional spatiotemporal feature fingerprint and the shared secret as input key material to derive the session key through an HMAC-based key derivation function; and establishing the encrypted communication channel after negotiating encryption parameters based on the session key.

Images