A method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy

Abstract

This invention discloses a method for accelerating cross-system Bluetooth file transfer based on a protocol stack penetration proxy. After the host machine starts up, it collects Bluetooth hardware capabilities and MAC addresses, runs a collaboration manager, allocates shared memory, builds a connection state library and IPC channel, and starts a resource dynamic manager. The container loads the penetration proxy and binds an interception unit, disabling native negotiation. The container application requests a Bluetooth connection, the interception unit encapsulates the request frame and sends it to the collaboration manager to generate optimal connection parameters, and the host protocol stack establishes a connection. The application transfers files, the interception unit encapsulates the transmission frame and passes the buffer descriptor. The penetration proxy queries the link quality to negotiate the optimal transmission parameters, synchronizes the two-layer protocol stack, requests resources, and completes the cross-system address mapping of shared memory. The application writes the file to shared memory according to the optimal fragment size, the penetration proxy generates fragment metadata, the host protocol stack reads the fragment encapsulation, processes it, and sends it to the Bluetooth hardware, finally sending it to the peer device.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy. Background Technology

[0002] In scenarios where heterogeneous mobile application runtime environments are run in a container compatibility layer within a host operating system to achieve cross-system application compatibility, when applications within the container call physical Bluetooth hardware to transfer files, the transmission throughput rate is significantly lower than in native hardware direct connection environments due to multiple factors, including container isolation sandbox mechanism, independent operation of dual-system Bluetooth protocol stacks, redundancy in data forwarding link layers, mismatch between connection negotiation and transmission parameters, and the lack of unified exception handling logic. This results in a clear performance bottleneck. Existing technical solutions suffer from the following technical problems:

[0003] First, the protocol stack connection negotiation process is fragmented. The container independently completes Bluetooth connection parameter negotiation without co-calibrating with the host's underlying Bluetooth protocol stack. The connection parameters, such as connection interval and slave latency, produced by the negotiation conflict with the optimal configuration for high-speed transmission, limiting the upper limit of transmission performance from the link establishment stage. Second, the data forwarding link has multiple layers and high copy overhead. The complete data flow requires multiple layers of forwarding, namely the application service layer, container application Bluetooth socket layer, container L2CAP protocol layer, container HCI interface layer, container kernel network forwarding module, host kernel network forwarding module, host HCI interface layer, host L2CAP protocol layer, and physical Bluetooth hardware. Each layer involves data packet encapsulation, decapsulation, and memory copy operations, resulting in a large cumulative overhead. The system suffers from several problems: First, it experiences transmission delays and performance losses. Second, it lacks dedicated guarantees for transmission resources and cannot dynamically adapt to business needs. The system uses a global, general scheduling strategy for CPU, memory, and hardware interrupts, causing the Bluetooth transmission process to compete with background services and foreground applications for hardware resources. At the same time, the resource allocation scale cannot be dynamically adjusted according to file size and real-time link quality, resulting in insufficient computing power and cache capacity for Bluetooth protocol stack data processing. Third, it lacks fragmentation, encryption, and link adaptation capabilities. The container's built-in protocol stack uses a fixed data packet fragment size, which cannot match the optimal transmission unit of the Bluetooth chip hardware. Data encryption relies entirely on container-side CPU software computation and cannot reuse the host machine's hardware encryption acceleration module. There is no dynamic parameter adjustment logic when the link signal quality fluctuates, and the probability of data packet retransmission increases significantly.

[0004] In summary, current mainstream optimization methods are limited to static parameter tuning and partial link reduction. They do not cover the complete transmission lifecycle reconstruction of cross-system collaborative architecture, including connection establishment, parameter coordination and negotiation, dedicated resource allocation, data transmission reading and writing, encrypted operation and processing, data packet fragmentation and transmission, and link status feedback. Therefore, they cannot completely eliminate the multi-layer forwarding loss caused by container isolation, and the transmission speed can never approach the level of native direct connection of hardware. Summary of the Invention

[0005] In view of this, the present invention provides a method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy. By reconstructing the dual-layer Bluetooth protocol stack collaborative architecture of the host machine and container, simplifying the cross-system data forwarding link, and building a dedicated dynamic resource scheduling system for transmission, the method maximizes the Bluetooth file transfer speed of heterogeneous applications within the container without modifying the underlying Bluetooth hardware driver.

[0006] This invention provides a method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy, which specifically includes the following steps:

[0007] The host collects the Bluetooth chip's hardware capabilities and MAC address, starts the Bluetooth collaboration manager; allocates shared memory, builds the Bluetooth connection state library, initializes the cross-system IPC channel, and starts the resource dynamic manager; the container starts the Bluetooth penetration proxy and binds to the request interception unit, reports the container's Bluetooth access permissions, and disables the container's native Bluetooth negotiation;

[0008] The container application initiates a Bluetooth connection request. The request interception unit encapsulates it into a cross-system Bluetooth connection request frame and sends it to the Bluetooth Coordination Manager through the IPC channel. The Bluetooth Coordination Manager reads the Bluetooth hardware capabilities and generates the optimal connection parameter set according to the application's expected parameters. The host protocol stack initiates a Bluetooth connection based on the optimal connection parameter set and synchronizes the connection negotiation feedback to the Bluetooth passthrough agent. The Bluetooth passthrough agent returns a successful connection establishment to the container protocol stack and writes the optimal connection parameter set into the connection status register.

[0009] The container application initiates a file transfer request, which is encapsulated into a cross-system Bluetooth file transfer request frame by the request interception unit and then sent to the Bluetooth Coordinator. The application buffer memory descriptor is sent to the Bluetooth passthrough proxy. The Bluetooth passthrough proxy reads the real-time link quality from the Bluetooth connection state library, initiates a transmission capability negotiation request to the Bluetooth Coordinator, and the Bluetooth Coordinator returns the optimal transmission parameter set and synchronizes it to the host Bluetooth protocol stack. The Bluetooth passthrough proxy updates the container protocol stack, sends a resource activation request to the resource dynamic manager, and the resource dynamic manager returns a resource allocation result frame and sends it to the Bluetooth Coordinator. The Bluetooth passthrough proxy maps shared memory to the container address space, and the Bluetooth Coordinator synchronizes the address to the host Bluetooth protocol stack.

[0010] Container applications use DMA to write the file to be transferred into shared memory in fragments according to the optimal set of transmission parameters. The Bluetooth pass-through agent generates fragment metadata for the file. The host protocol stack reads the fragment metadata, encapsulates the data, and sends it to Bluetooth. Bluetooth then sends the data to the target device.

[0011] Furthermore, the container application uses DMA to write the file to be transferred into fragments according to the optimal transmission parameter set. The Bluetooth pass-through proxy generates fragment metadata for the fragments. The host protocol stack reads the fragment metadata, encapsulates the data, and sends it to Bluetooth. Specifically, the method is as follows:

[0012] After the container application completes the writing of a single fragment of data according to the fragment size in the optimal transmission parameters, the Bluetooth penetration agent generates fragment metadata, updates the fragment status to "ready to send," sends a data ready notification to the host's shared memory data monitoring unit, and returns a data write success response to the container application, allowing it to send the next batch of data. At the same time, it monitors the processing status of the sent fragments through the status flag area. The fragment sending unit located in the L2CAP layer of the host protocol stack obtains the shared memory fragment status through the semaphore monitoring status flag area. When the fragment status is "ready to send," it reads the corresponding metadata from the metadata area according to the fragment number, reads the fragment data from the shared memory data buffer based on the data offset, and sends it to Bluetooth.

[0013] Furthermore, the fragmented data is read from the shared memory data buffer based on the data offset. If the fragment length is greater than the maximum effective payload of the single control packet, the maximum effective payload of the single control packet is used as the new fragment size for secondary fragmentation. The secondary fragment number consists of the primary fragment number and the secondary fragment number. The secondary fragmented data is encapsulated into an L2CAP data frame and sent to the HCI layer. The HCI layer converts the L2CAP data frame into an HCI ACL data frame according to the PHY mode and transmit power in the optimal transmission parameter set, and then sends it to Bluetooth.

[0014] Furthermore, the Bluetooth then sends the data to the target device in the following manner: Bluetooth sends the data to the target device through the radio frequency module and returns a successful transmission response to the HCI layer. The HCI layer sends the response to the fragmentation transmission unit, which updates the fragmentation status and records the transmission timestamp and link feedback parameters.

[0015] The Bluetooth Collaboration Manager periodically generates transmission status feedback frames, including transmission progress, link quality, resource status, anomaly markers, and checksums, which are synchronized to the Bluetooth Penetration Proxy via the IPC channel. The Bluetooth Penetration Proxy performs flow control based on dual thresholds of memory usage and link error rate. When the cache or link quality is below the threshold, application writing is paused. The file transmission progress is synchronized to the application in real time. When the fragment failure rate exceeds the threshold, a transmission anomaly is returned to the application, and failed fragments are retransmitted according to the user's selection. After all files have been transmitted, CPU and memory resources are released.

[0016] Furthermore, the optimal connection parameter set is generated as follows: After receiving the transmission request frame, the Bluetooth penetration agent reads the real-time link quality indicators in the Bluetooth connection status database, and initiates a capability negotiation request to the Bluetooth Co-Manager based on the size of the file to be transmitted and the type of transmission service, carrying the unique link identifier, file metadata, and real-time link status information; after receiving the negotiation request, the Bluetooth Co-Manager collects Bluetooth performance parameters, classifies the link quality level based on signal strength, bit error rate, and retransmission frequency, and generates the optimal transmission parameter set based on the hardware limit and link operating conditions.

[0017] Furthermore, the host Bluetooth protocol stack deploys a cross-system Bluetooth encryption service, supporting hardware-accelerated computation of specified encryption algorithms, managing key contexts, and synchronizing across environments. Upon receiving a data-ready notification, the host's shared memory data monitoring unit reads the encryption switch identifier from the fragment metadata. If encryption is enabled, it sends a fragment encryption task to the encryption service. Upon receiving the task, the encryption service first reads the key information obtained from the current link negotiation from the Bluetooth connection state library, constructs an encryption context containing the key, random vector, and counting parameters, and stores it in a dedicated shared memory partition. It then reads the original fragment data from shared memory and sends it, along with the encryption context, to the hardware acceleration module for computation. After encryption, the ciphertext is written to the shared memory encryption buffer, and a data checksum is generated and filled back into the corresponding fragment metadata. The fragment status is switched from pending encryption to pending transmission, and a semaphore is used to notify the shared memory data monitoring unit that the encryption task has been completed. If the encryption switch is off, the monitoring unit changes the fragment status back to pending transmission.

[0018] Furthermore, after each set number of fragments is sent, the fragment sending unit reads the real-time link quality. If the link quality level changes, it sends a link quality update request to the Bluetooth Co-Manager. Upon receiving the update request, the Bluetooth Co-Manager regenerates the transmission parameters based on the current link conditions and simultaneously sends them to the Bluetooth Penetration Proxy and the fragment sending unit. The fragment sending unit sets the fragment sending rules based on the updated transmission parameters. If Bluetooth reports a data packet transmission failure, the fragment sending unit checks whether the cumulative retransmission count for that fragment has not reached the maximum retry threshold. If it has not, the fragment status is marked as retransmission and a retransmission is immediately initiated. If it has reached the threshold, the fragment is marked as a transmission failure, and a link anomaly alarm is simultaneously reported to the Bluetooth Co-Manager.

[0019] Furthermore, after receiving the status feedback frame, the Bluetooth penetration agent calculates the remaining writable fragments based on the total shared memory capacity, the occupied capacity, and the current fragment size. When the remaining writable fragment count is lower than a smaller threshold or the link error rate exceeds a risk threshold, a pause transmission notification is pushed to the application. When the remaining writable fragment count is greater than a larger threshold and the link error rate is within a healthy range, application data writing is resumed. When all fragments have been sent and no fragment transmission has failed, a transmission completion notification is pushed, triggering the application to end the current file transfer service.

[0020] Furthermore, the fragment metadata includes: fragment number, which is a unique identifier for the fragment; data offset, which is the starting offset address of the fragment in the shared memory data buffer; fragment length, which is the actual length of data written to the fragment; target device information, which is the target device MAC address and Bluetooth device type identifier; transmission configuration, including transmission service type encoding, encryption enable flag, and fragment type identifier; verification information, which is the CRC32 check value calculated based on the complete fragment data; and timestamp, which is the timestamp of the moment when the fragment data was written.

[0021] Furthermore, the Bluetooth file transfer request frame includes a frame header, a file metadata field, a transfer configuration field, a data buffer handle field, and a frame trailer.

[0022] Beneficial effects:

[0023] This invention completes Bluetooth hardware capability identification and basic initialization after the host starts, deploys core capabilities such as global collaborative management, resource scheduling, encryption services, fragmented transmission, and status monitoring, and builds an isolated shared memory state library and cross-system communication channel. After the container starts, it loads the Bluetooth protocol stack, creates a penetration proxy and binds connection and transmission interception units, establishes a cross-system communication link, and disables the container's native autonomous negotiation capability, which is then taken over by the host. After the container application starts, it initiates a Bluetooth connection request. The container interception unit encapsulates the request message and uploads it to the global collaborative manager to generate optimal connection parameters, complete remote device connection negotiation, and synchronize the status and parameters to the container, while simultaneously writing the global connection state. After an application initiates a file transfer, the container interception unit intercepts and encapsulates the transfer request. The container's penetration agent reads the real-time link status and initiates a transfer capability negotiation with the host to generate the optimal transfer parameter set. The application writes the file data directly to shared memory via DMA. The penetration agent cuts the data according to the negotiated fragment size, generates standardized fragment metadata, marks the fragment status, and reports a data readiness notification to the monitoring unit. The fragment sending unit monitors the fragments to be sent, reads the metadata and cached data, and completes secondary fragmentation as needed. After encapsulating the protocol frame, the data is sent, and the fragment sending status and link statistics are updated synchronously. After all files are transferred, the system releases dedicated hardware and memory resources in a unified manner. Attached Figure Description

[0024] Figure 1 This is a flowchart illustrating a method for accelerating cross-system Bluetooth file transfer based on a protocol stack penetration proxy, as provided by the present invention. Detailed Implementation

[0025] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0026] This invention provides a method for accelerating cross-system Bluetooth file transfer based on a protocol stack penetration proxy. The core idea is as follows: After the host starts, it completes Bluetooth hardware capability identification and basic initialization, deploys core capabilities such as global collaborative management, resource scheduling, encryption services, fragmented transmission, and state monitoring, and builds an isolated shared memory state library and a cross-system communication channel. After the container starts, it loads the Bluetooth protocol stack, creates a penetration proxy, and binds connection and transmission interception units to establish a cross-system communication link, disabling the container's native autonomous negotiation capabilities, which are then taken over by the host. After the container application starts, it initiates a Bluetooth connection request. The container interception unit encapsulates the request message and uploads it to the global collaborative manager to generate optimal connection parameters, complete remote device connection negotiation, and synchronize the state. The parameters are written to the container and simultaneously to the global connection state library. After the application initiates a file transfer, the container interception unit intercepts and encapsulates the transfer request. The container penetrates the proxy to read the real-time link status and initiates a transfer capability negotiation with the host to generate the optimal set of transfer parameters. The application writes the file data directly to shared memory via DMA. The penetration proxy cuts the data according to the negotiated fragment size, generates standardized fragment metadata, marks the fragment status, and reports a data readiness notification to the monitoring unit. The fragment sending unit monitors the fragments to be sent, reads the metadata and cached data, and completes secondary fragmentation as needed. After encapsulating the protocol frame, the data is sent, and the fragment sending status and link statistics are updated synchronously. After all files are transferred, the system releases dedicated hardware and memory resources in a unified manner.

[0027] This invention provides a method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0028] Step 1: After the host starts, it identifies the Bluetooth hardware, collects the hardware capabilities and MAC address of the Bluetooth chip, including supported PHY modes, maximum MTU, and connection parameter range; instantiates the cross-system Bluetooth global coordination manager, and starts message verification, permission authentication, link parameter optimization, and link status monitoring capabilities; allocates isolated shared memory space, builds a cross-system Bluetooth connection state library, and only grants read and write permissions to the cross-system Bluetooth global coordination manager and container-side agent for unified storage of connection parameters, link quality, and encryption context; initializes a cross-system IPC communication channel with encryption and permission verification capabilities as a bidirectional data interaction channel between the host and the container; starts a dedicated Bluetooth transmission resource dynamic manager, pre-allocates CPU, memory, and hardware interrupt basic resource pool, and divides the space into data cache, encryption cache, metadata storage, and exception log partitions; and loads the Bluetooth protocol stack supporting capability modules, including cross-system Bluetooth encryption service, deterministic fragmentation transmission unit, and shared memory data monitoring unit.

[0029] Step 2: After the container starts, load the Bluetooth protocol stack, create a Bluetooth protocol stack penetration proxy, bind the request interception unit and the transmission request penetration interception unit to the Bluetooth protocol stack penetration proxy to handle Bluetooth connection and file transfer request capture; the Bluetooth protocol stack penetration proxy completes the binding with the host IPC channel, establishes a bidirectional communication link, reports the container's Bluetooth hardware access permissions to the cross-system Bluetooth global collaboration manager for filing, pre-registers the user-space zero-copy write interface, reserves the shared memory mapping entry, and completes the memory access permission isolation configuration; disable the container's native Bluetooth self-negotiation logic, and the container protocol stack only synchronizes the unified link parameters issued by the host machine.

[0030] Step 3: The application inside the container initiates a Bluetooth connection request, which carries the target device's MAC address, service identifier, connection type, and expected connection interval. The request interception unit captures the connection request, stops the container's native negotiation process, extracts the key information of the request, encapsulates it into a cross-system Bluetooth connection request frame, which includes a frame header, target device information field, connection configuration field, and verification field, and sends the request frame to the host's cross-system Bluetooth global collaboration manager through the cross-system IPC channel.

[0031] The cross-system Bluetooth global coordination manager verifies message integrity and container Bluetooth access permissions, reads physical Bluetooth hardware capabilities, and generates the optimal connection parameter set based on the application's expected parameters. It then initiates a connection to the Bluetooth device via the host protocol stack using the optimal connection parameter set and captures the connection negotiation feedback from the host protocol stack in real time, including the connection parameters supported by the target device, the MTU negotiation result, and the encryption negotiation status. This feedback is synchronized to the Bluetooth protocol stack penetration agent via the IPC channel. Upon receiving the connection negotiation feedback, the Bluetooth protocol stack penetration agent returns a successful connection establishment message to the container protocol stack and synchronizes the optimal connection parameter set to the container protocol stack's connection status register.

[0032] The cross-system Bluetooth global collaboration manager writes the connection status, negotiation parameters, and initial link quality into the shared memory cross-system Bluetooth connection status library, which serves as the data source for subsequent transmissions.

[0033] The method for generating the optimal connection parameter set based on the application's expected parameters is as follows: After the container-side Bluetooth protocol stack penetration agent receives the standardized transmission request frame, it reads the real-time link quality indicators in the shared memory-based cross-system Bluetooth connection state library, and, in conjunction with the file size and transmission service type, initiates a capability negotiation request to the host machine's cross-system Bluetooth global coordination manager, carrying the link's unique identifier, file metadata, and real-time link status information; After receiving the negotiation request, the cross-system Bluetooth global coordination manager synchronously executes the entire set of coordination logic, including full hardware capability detection, link quality grading assessment, and optimal matching of transmission parameters: collecting Bluetooth hardware integrity performance indicators, and based on signal strength, error rate, etc. The link quality is divided into four levels based on bit rate and retransmission frequency. A set of optimal transmission parameters is generated based on hardware limits and link conditions. At the same time, the parameters are checked for hardware compatibility, and parameters that cannot be adapted are automatically downgraded. The collaboration manager assembles a fixed-length standardized optimal transmission parameter configuration message and sends it to the Bluetooth protocol stack penetration agent through a cross-system encrypted communication channel. The hardware transmission parameters are initialized synchronously to the underlying Bluetooth protocol stack. After receiving the parameter message, the Bluetooth protocol stack penetration agent synchronously updates the Bluetooth protocol stack transmission configuration in the container, disables the container's local autonomous rate, transmission unit, and encryption policy negotiation capabilities, and eliminates the problem of inconsistent parameters between the two-layer protocol stack.

[0034] Step 4: The application initiates a file transfer request, carrying the size of the file to be transferred, the starting offset of the data block, the length of the data block, the file type, and the encryption enable flag;

[0035] The transmission request penetration interception unit captures the transmission request, stops the container's native forwarding process, verifies the data block length, offset continuity, and encryption configuration validity, and generates a standardized cross-system Bluetooth file transfer request frame containing a frame header, file metadata field, transmission configuration field, data buffer handle field, and frame tail. The transmission request frame is sent to the cross-system Bluetooth global collaboration manager through the IPC channel, and the memory descriptor of the application buffer is passed to the Bluetooth protocol stack penetration proxy.

[0036] The Bluetooth protocol stack penetrates the proxy to read real-time link quality data from the shared memory connection state library and initiates a transmission capability negotiation request to the cross-system Bluetooth global coordination manager. The cross-system Bluetooth global coordination manager detects the complete capabilities of the Bluetooth hardware, classifies the link quality level based on RSSI, bit error rate, and retransmission count, and generates the optimal transmission parameter set, including supported PHY modes, maximum transmission unit of L2CAP layer, fragment size, encryption algorithm, and transmit power, to complete hardware compatibility downgrade verification.

[0037] The cross-system Bluetooth global collaboration manager sends parameter configuration frames to the Bluetooth protocol stack penetration agent, and synchronizes the optimal transmission parameter set to the host Bluetooth protocol stack; the Bluetooth protocol stack penetration agent synchronously updates the container protocol stack transmission parameters.

[0038] Step 5: The Bluetooth protocol stack penetration agent sends a resource activation request to the resource dynamic manager, carrying the optimal transmission parameter set, the size of the file to be transmitted, and the transmission service type; the resource dynamic manager binds a dedicated CPU core, increases the process scheduling priority, and exclusively uses Bluetooth hardware interrupts; it dynamically adjusts each partition of the shared memory pool based on the size of the file to be transmitted, including the data buffer, encryption buffer, metadata area, and status flag area; it generates a resource allocation result frame and sends it to the Bluetooth protocol stack penetration agent and the cross-system Bluetooth global collaboration manager; the Bluetooth protocol stack penetration agent maps the shared memory to the container address space and isolates read and write permissions; the cross-system Bluetooth global collaboration manager synchronizes the shared memory address to the host Bluetooth protocol stack.

[0039] Step 6: The Bluetooth protocol stack penetration proxy verifies the validity of the application data buffer through the memory descriptor passed by the application. After successful verification, a direct mapping is established between the application buffer and the shared memory data buffer. The application uses DMA to write the file to be transferred into the shared memory data buffer through the zero-copy interface provided by the Bluetooth protocol stack penetration proxy.

[0040] After writing a single data fragment according to the fragment size in the optimal transmission parameters, the Bluetooth protocol stack generates fragment metadata through the proxy, updates the fragment status to pending encryption or pending transmission, and sends a data ready notification to the host's shared memory data monitoring unit through the shared memory data ready notification mechanism, including the range of fragment numbers to be processed and the starting address of the metadata area; it returns a data write success response to the application, allowing the application to continue sending the next batch of data, and monitors the processing status of the sent fragments through the status flag area.

[0041] The fragment metadata is defined as follows: the fragment number is an unsigned integer starting from 0 and incrementing sequentially, serving as a unique identifier for each fragment; the data offset is the starting offset address of the fragment in the shared memory data buffer; the fragment length is the actual length of data written to the fragment, with the standard fragment size equal to the negotiated fragment size, and the last fragment being the remaining data length; the target device information is the MAC address of the target device and the Bluetooth device type identifier stored in compressed format; the transmission configuration includes the transmission service type encoding, encryption enable flag, and fragment type identifier; the verification information is the CRC32 checksum calculated based on the complete fragment data; and the timestamp is the millisecond-level timestamp at the moment the fragment data is written.

[0042] Furthermore, the host Bluetooth protocol stack deploys a cross-system Bluetooth encryption service, supporting hardware-accelerated computation of specified encryption algorithms, uniformly managing key contexts, and completing cross-environment synchronization. Upon receiving a data-ready notification, the shared memory data monitoring unit reads the encryption switch identifier from the fragment metadata. If encryption is enabled, it immediately sends a fragment encryption task to the encryption service, carrying the fragment number, data cache offset address, and metadata storage address. Upon receiving the task, the encryption service first reads the key information obtained from the current link negotiation from the global connection state library, assembles a complete encryption context containing the key, random vector, and counting parameters, and stores the context in the shared memory. A dedicated memory partition is provided, granting read-only permissions to the container-side proxy component to ensure consistent key parameters across both ends. The original fragment data is then read from the shared memory and sent to the hardware acceleration module along with the encryption context for computation. After encryption, the ciphertext is written to the shared memory encryption buffer, and a data verification code is generated and populated back into the corresponding fragment metadata. The encryption service modifies the status flag entry, switching the fragment status from pending encryption to pending transmission, and notifies the monitoring unit via a semaphore that the encryption task is complete. If the encryption switch is off, the monitoring unit directly modifies the fragment status, skipping the entire encryption process and setting it directly to the pending transmission state.

[0043] Step 7: Add a deterministic fragmentation transmission unit within the L2CAP layer of the host protocol stack. Obtain the shared memory fragmentation status through the semaphore monitoring status marker area. When the fragmentation status is "to be transmitted," read the corresponding metadata from the metadata area according to the fragmentation number, and read the fragmentation data from the shared memory data buffer or encryption buffer based on the data offset. If the fragmentation length is greater than the maximum effective payload of the control single packet, use the maximum effective payload of the control single packet as the new fragmentation size for secondary fragmentation. The secondary fragmentation number consists of the primary fragmentation number and the secondary fragmentation number. Encapsulate the secondary fragmentation data into an L2CAP data frame and send it to the HCI layer. The HCI layer converts the L2CAP data frame into an HCI ACL data frame according to the optimal transmission parameter set PHY mode and transmit power, and sends it to the Bluetooth hardware.

[0044] The Bluetooth hardware sends data to the target device through the radio frequency module and returns a successful transmission response to the HCI layer. The HCI layer sends the response to the deterministic fragmentation transmission unit, which updates the fragmentation status and records the transmission timestamp and link feedback parameters.

[0045] Furthermore, after each set number of main fragments is sent, the deterministic fragmentation unit within the host protocol stack's L2CAP layer reads real-time link quality metrics, including signal strength, bit error rate, and retransmission count. If the link quality level changes, it initiates a link quality update request to the global coordination manager. Upon receiving the update request, the global coordination manager regenerates a complete set of adapted transmission parameters based on the current link conditions, including adjusting fragment size, switching transmission rate modes, and increasing RF transmit power. This is then synchronously distributed to the container-side penetration agent and the local fragmentation unit via the cross-system communication channel. The fragmentation unit adjusts subsequent fragmentation sending rules according to the updated transmission parameters to match the current wireless link transmission capability. If the Bluetooth hardware reports a data packet transmission failure, the fragmentation unit checks whether the cumulative retransmission count for that fragment has not reached the maximum retry threshold. If it has not exceeded the threshold, the fragment status is marked as retransmission and a retransmission is immediately initiated. Once the retransmission count reaches the threshold, the fragment is marked as a transmission failure, and a link anomaly alarm is simultaneously reported to the global coordination manager.

[0046] Step 8: The cross-system Bluetooth global collaboration manager periodically generates transmission status feedback frames, including transmission progress, link quality, resource status, anomaly markers, and checksums, and synchronizes them to the Bluetooth protocol stack penetration proxy via the IPC channel. The Bluetooth protocol stack penetration proxy performs flow control based on dual thresholds of memory usage and link error rate. When the cache is insufficient or the link quality is below the threshold, application writing is paused, and transmission is resumed when resources are sufficient and the link is stable. The file transmission progress is synchronized to the application in real time. When the fragment failure rate is greater than the threshold, a transmission anomaly is returned to the application, and failed fragments are retransmitted according to the user's selection. After all files have been transmitted, CPU and memory resources are released, and this process ends.

[0047] Furthermore, this invention provides a cross-system real-time status feedback and precise flow control method, specifically as follows:

[0048] The cross-system Bluetooth global collaboration manager monitors the shared memory status marker area, the transmission statistics of the fragmented transmission unit, and the underlying link quality data in real time. It assembles and generates standardized real-time transmission status feedback frames at fixed intervals. The messages include a fixed frame header, transmission progress field, link quality field, resource status field, abnormal status field, and integrity check code, summarizing the running status of the current file transmission process. The cross-system Bluetooth global collaboration manager synchronously sends the real-time status feedback frames to the container-side Bluetooth protocol stack penetration proxy through a cross-system encrypted communication channel, ensuring that the container side can perceive the underlying transmission dynamics at the millisecond level.

[0049] After the Bluetooth protocol stack receives the status feedback frame through the proxy, it initiates precise flow control logic. Combining the total shared memory capacity, the occupied capacity, and the current standard fragment size, it calculates the number of remaining writable fragments in real time. Flow scheduling is performed based on a dual-dimensional threshold of remaining cache resources and link error rate: when the number of remaining writable fragments is below the low threshold or the link error rate exceeds the risk threshold, a pause transmission notification is pushed to the upper-layer application, restricting the application from continuing to write and transmit data; when the number of remaining writable fragments is above the high threshold and the link error rate is within a healthy range, the transmission restriction is lifted, and normal data writing by the application resumes; when all fragments have been sent and no fragment transmission failures, a transmission completion notification is pushed, triggering the application to end the current file transfer service.

[0050] The Bluetooth protocol stack penetrates the proxy to parse the transmitted byte data in the feedback frame in real time, and calculates the standardized transmission progress percentage based on the total file size. It continuously synchronizes the real-time transmission progress with the upper-layer application to support the application's progress display business. At the same time, it statistically analyzes the proportion of failed fragments across the entire domain. When the number of failed fragments exceeds the global threshold, it pushes a transmission error prompt to the application and provides a retry option. After the user confirms the retry, it only performs the retransmission operation for the failed fragments, without requiring the application to re-initiate the entire file transmission process, thus achieving accurate fault-tolerant retransmission.

[0051] Furthermore, this invention provides full lifecycle anomaly protection to ensure data security and resource integrity, specifically as follows:

[0052] The Bluetooth transmission dedicated resource dynamic manager has a built-in anomaly monitoring and response unit that monitors the entire lifecycle of file transmission in real time and continuously identifies various abnormal conditions, including Bluetooth link disconnection, rapid deterioration of wireless link quality, shared memory cache overflow, data encryption processing failure, fragment transmission timeout, and transmission-dedicated computing and memory resources being preempted by other services. It also implements graded and differentiated protection and recovery strategies for different anomaly types.

[0053] When the monitoring unit detects a Bluetooth link disconnection anomaly, it immediately suspends all fragment transmission, updates uncompleted fragments to a paused state, freezes the dedicated transmission resource pool to avoid wasting system resources, pushes a link disconnection notification to the upper-layer application via the container-side proxy component, and waits for a reconnection command. After receiving the application's reconnection command, it automatically triggers the Bluetooth link reconstruction process, and resumes the transmission of the remaining fragments after the link is restored to normal.

[0054] When the monitoring unit identifies a shared memory cache overflow anomaly, it automatically initiates a dynamic memory expansion mechanism to expand the data cache space to accommodate subsequent data to be written. If the cache expansion cannot be completed, the flow control mechanism is activated to suspend application data writing and wait for existing fragments to be sent and cache resources to be released before resuming the normal data writing and fragment transmission process to avoid data anomalies caused by memory overflow.

[0055] When the monitoring unit identifies an anomaly in the data encryption process, it automatically downgrades the encryption operation mode, switching from hardware-accelerated encryption to a general software encryption method to ensure that the data encryption process is not interrupted. At the same time, it pushes an encryption mode switching prompt to the upper-layer application and records the anomaly event for subsequent system iteration and performance optimization analysis.

[0056] When the monitoring unit identifies a fragment transmission timeout anomaly, it automatically triggers the fragment retransmission mechanism and performs a retransmission operation according to the preset maximum number of retries. If the transmission still fails after multiple retries, the corresponding fragment is marked as a transmission failure. When the number of failed fragments exceeds the system's preset threshold, the transmission interruption protection process is proactively triggered to avoid resource waste caused by large-scale abnormal transmission.

[0057] When the monitoring unit identifies an anomaly in the preemption of dedicated CPU and memory resources for transmission, the resource management unit proactively clears the background processes that are preempting the resources and restores the exclusive resource status of the Bluetooth transmission service. In response to frequent resource preemption scenarios, the system scheduling priority of the Bluetooth transmission service is proactively increased to ensure stable exclusive access to transmission resources and that the transmission process is not interfered with by background system tasks.

[0058] After all abnormal events are handled, the abnormal monitoring and response unit collects the event type, handling plan, execution result and processing time of this abnormality and records them completely in the shared memory abnormal log area. The log data is only open to the system debugging module and is used to transmit abnormal source tracing, problem location and performance optimization iteration.

[0059] Example:

[0060] This embodiment employs a cross-system Bluetooth file transfer acceleration method based on protocol stack penetration proxy provided by the present invention. Using OpenHarmony as the host system and Android as the container system, it improves the file transfer rate of Android applications accessing physical Bluetooth devices through penetration protocol stack adaptation, user-space zero-copy shared memory direct transfer, dedicated resource reservation throughout the transmission process, deterministic link optimization, and full lifecycle anomaly protection. The specific process includes:

[0061] S1, Bluetooth connectivity for cross-system collaboration.

[0062] Modify the connection management module of the Bluetooth protocol stack Bluedroid on the Android container side. Add a connection request interception and proxy unit to the connection creation and initiation interfaces such as createRfcommSocketToServiceRecord(), createInsecureRfcommSocketToServiceRecord() and connectGatt() in the BluetoothDevice class. This unit is deeply bound to the container-side Bluetooth protocol stack piercing proxy (PBSP) to intercept all Bluetooth connection initiation requests.

[0063] When an Android application initiates a Bluetooth connection request by calling the above connection interface, the key information carried in the connection request includes: the target device's MAC address, the service UUID, the connection type (secure or non-secure), and the expected connection parameters (initial connection interval, slave latency, and timeout duration).

[0064] After the connection request is intercepted by the proxy unit, it is prevented from entering the traditional connection negotiation process of the Android container protocol stack. Instead, the connection request is immediately standardized into a cross-system Bluetooth connection request frame, with the frame structure defined as follows:

[0065] Frame header, 10 bytes: Frame identifier BT_CONN_REQ is 6 bytes, frame version is 1 byte with a default value of 0x01, total frame length is 2 bytes, and reserved bits are 1 byte;

[0066] The target device information field is 14 bytes: the MAC address is 6 bytes and stored in binary format AA:BB:CC:DD:EE:FF; the device type identifier is 2 bytes to distinguish between classic Bluetooth, BLE, and dual-mode devices; and the service UUID is 16, 32, or 128 bits and stored according to the actual length, occupying 2 to 16 bytes.

[0067] The connection configuration field is 8 bytes: the connection type is marked as 1 byte, 0x01 indicates a secure connection, and 0x00 indicates a non-secure connection. The application expects a connection interval of 2 bytes with a size of 1.25ms. The application expects a slave delay of 1 byte in a time slot. The application expects a timeout of 2 bytes in a 10ms unit. The reserved bits are 2 bytes.

[0068] Verification field, 4 bytes: CRC32 checksum based on the frame header, target device information field, and connection configuration field.

[0069] The connection request interception and proxy unit, through the cross-system IPC channel and based on the OpenHarmony HM-IPC framework, has the ability to verify permissions and encrypt data, and sends standardized connection request frames to the Cross-system Bluetooth Global Coordinator (CBGC) on the OpenHarmony host side.

[0070] After receiving the connection request frame, CBGC first verifies the frame integrity through the validation fields, and then verifies the Bluetooth access permissions of the Android container based on the OpenHarmony permission management framework to verify the legality of the permissions. After successful verification, the connection establishment process is initiated.

[0071] CBGC calls the HCI layer interfaces hci_read_local_supported_features() and hci_read_bd_addr() of the OpenHarmony Bluetooth protocol stack (BlueZ) to obtain the hardware capabilities of the physical Bluetooth device, including the supported PHY modes, maximum MTU and connection parameter range, and its own MAC address;

[0072] CBGC generates the optimal set of connection parameters based on the physical Bluetooth device's capabilities and the application's expected parameters in the connection request frame. The connection interval is set to the minimum interval supported by the physical Bluetooth device, which can be 1.25ms. The slave latency is set to 0 timeslots, and the timeout duration is set to 4000ms to ensure connection stability and real-time performance.

[0073] CBGC calls the L2CAP layer interface l2cap_create_channel() of the OpenHarmony Bluetooth protocol stack to initiate a Bluetooth connection with the target device based on the optimal connection parameter set, replacing the Android container protocol stack in performing the connection negotiation process.

[0074] During the connection establishment process, CBGC captures connection negotiation feedback from the OpenHarmony protocol stack in real time, such as the connection parameters supported by the target device, the MTU negotiation result, and the encryption negotiation status, and synchronizes them to PBSP through the cross-system IPC channel.

[0075] After receiving the connection negotiation feedback, PBSP returns a connection establishment success response to the connection management module of the Android container protocol stack. At the same time, it writes the negotiated optimal connection parameters, such as connection interval, initial MTU value, and encryption status, into the connection status register of the container protocol stack to ensure that the connection status perceived by the container-side protocol stack is consistent with that of the host machine.

[0076] Once the connection is established, CBGC stores the connection status (connected or not), negotiation parameters, and initial link quality values ​​of the target device in the cross-system Bluetooth connection state library. This state library is a shared memory structure and is only accessible to CBGC and PBSP. It is used for parameter querying and state synchronization in subsequent transmission processes.

[0077] S2. The application initiates a Bluetooth file transfer request, which is then intercepted and parsed using a penetrating proxy.

[0078] After the Bluetooth connection is established, the Android application initiates a file transfer request by calling the custom BluetoothSocket.getOutputStream().write(byte[] buffer) or BluetoothGattCharacteristic.setValue(byte[] value). The core information carried in the transfer request includes the total size of the file to be transferred, the starting offset of the current data block, the length of the data block, the file type such as binary file, document and media file, and the encryption enable flag based on the application layer settings.

[0079] Modify the Socket and GATT layers of the Android container protocol stack, and embed a transmission request penetration interception unit in the write() method of BluetoothOutputStream and the setValue() method of BluetoothGattCharacteristic. This unit communicates with PBSP in real time to intercept all transmission requests and associated data buffers.

[0080] The transmission request penetration interception unit prevents requests from entering the L2CAP and HCI layers of the container protocol stack, and initiates the structured parsing process:

[0081] File metadata extraction: From the parameters passed by the application, the total number of bytes of the file to be transmitted is a 4-byte unsigned integer, the starting offset of the current data block is a 4-byte unsigned integer, the length of the current data block is a 2-byte unsigned integer with a maximum value of 64KB, and the file type encoding is 1 byte, where 0x01 represents a binary file, 0x02 represents a text document, 0x03 represents an image, 0x04 represents audio, and 0x05 represents video.

[0082] Verify the transmission configuration information, verify whether the data block length exceeds the maximum transmission unit size of the L2CAP layer (64KB), whether the encryption enable flag is a valid value (0x00 indicates disabled, 0x01 indicates enabled), and whether the starting offset is continuous with the amount of data already transmitted to avoid duplicate data transmission.

[0083] For exception verification, if the data block length exceeds the limit or the starting offset is not continuous, return an exception indicating that the parameter is invalid to the application; if encryption is enabled but the connection status is unencrypted, return a prompt indicating that encryption is not enabled to the application and ask whether to continue the transmission.

[0084] After successful parsing and verification, the transmission request penetration interception unit generates a cross-system Bluetooth file transfer request frame, with the frame structure defined as follows:

[0085] The frame header is 12 bytes: the frame identifier BT_FILE_TRANS_REQ is 8 bytes, the frame length is 2 bytes, the frame type is 1 byte, where 0x01 indicates data block transmission, 0x02 indicates transmission termination, 0x03 indicates transmission pause, and the checksum is 1 byte based on the XOR checksum of the frame header.

[0086] The file metadata field is 14 bytes: total file size is 4 bytes, current data block starting offset is 4 bytes, current data block length is 2 bytes, file type encoding is 1 byte, and reserved bits are 3 bytes;

[0087] The transmission configuration field is 6 bytes: the encryption enable flag is 1 byte, the transmission service type encoding is 2 bytes, where 0x0001 represents OPP, 0x0002 represents FTP, and 0x0003 represents A2DP, and the target device MAC address is 3 bytes and is stored in compressed format.

[0088] The data buffer handle field is 8 bytes: the user-mode memory descriptor of the Android application's data buffer, which avoids directly exposing the physical address to ensure security. The buffer permission flag is 2 bytes, where 0x01 indicates readable and 0x02 indicates writable.

[0089] The frame tail, consisting of 4 bytes, contains a CRC32 checksum based on the frame header, file metadata field, and transmission configuration field.

[0090] The transmission request penetration interception unit sends the transmission request frame to PBSP through the HM-IPC channel, and at the same time passes the memory descriptor of the application data buffer to PBSP to ensure that PBSP can access the buffer through memory mapping and avoid data copying.

[0091] S3, cross-system Bluetooth capability deep negotiation to determine the optimal set of transmission parameters.

[0092] After receiving a transmission request frame, PBSP reads the link quality data of the current connection from the cross-system Bluetooth connection state library, including real-time RSSI, bit error rate, and number of retransmissions. Combining this with the total file size and transmission service type in the transmission request frame, PBSP sends a cross-system Bluetooth capability negotiation request to CBGC, requesting that it carry the connection identifier, the unique connection ID assigned to CBGC, file metadata, and the current link quality data.

[0093] After receiving the negotiation request, CBGC initiates a collaborative process of hardware capability detection, link state assessment, and transmission parameter optimization:

[0094] For refined hardware capability probing, CBGC calls the HCI layer interfaces of the OpenHarmony Bluetooth protocol stack to obtain a complete list of capabilities for the physical Bluetooth device, including: calling HCI_LE_Read_Local_Supported_PHYS() to obtain supported PHY modes, including BLE 1M, 2M, LE Coded PHY, and classic Bluetooth EDR 2Mbps or 3Mbps; calling HCI_LE_Read_Maximum_Data_Length() to obtain the maximum transmission unit of the L2CAP layer, which defaults to 64KB and is supported by Bluetooth 5.0 and above; calling HCI_Read_Local_Supported_Commands() to obtain supported encryption algorithms, such as AES-CCM or AES-ECB; and calling HCI_LE_Read_Transmit_Power() to obtain the current transmit power level, typically from level 0 to 15.

[0095] Link status dynamic evaluation: CBGC evaluates link quality levels based on real-time RSSI, bit error rate, and retransmission count in the connection state database according to the following rules: Excellent links meet RSSI ≥ -60dB, bit error rate < 3%, and retransmission count < 1 / 100 frames; Good links meet -70dB ≤ RSSI < -60dB, 3% ≤ bit error rate < 5%, and 1 to 2 retransmissions per 100 frames; Average links meet -80dB ≤ RSSI < -70dB, 5% ≤ bit error rate < 10%, and 3 to 5 retransmissions per 100 frames; Poor links meet RSSI < -80dB, bit error rate ≥ 10%, and more than 5 retransmissions per 100 frames.

[0096] Transmission parameter optimization decision: CBGC generates an optimal set of transmission parameters based on the hardware capability list and link quality level. The specific decision rules are as follows:

[0097] For PHY mode selection, select the highest speed PHY (BLE 2M PHY or Classic Bluetooth EDR 3Mbps) for a good or excellent link; select BLE 1M PHY or Classic Bluetooth EDR 2Mbps for a normal link; and select LE Coded PHY (long-range mode) for a poor link.

[0098] MTU configuration: Set the ATT layer MTU to 251 bytes, which is the maximum protocol value; set the L2CAP layer MTU to 64KB, which is the maximum hardware supported value.

[0099] Fragment size: high-quality or good links are fragmented according to L2CAP layer MTU of 64KB, general links are fragmented according to 32KB, and poor links are fragmented according to 16KB.

[0100] When encryption is enabled, the default Bluetooth 5.0 AES-CCM is preferred. If the hardware does not support it, AES-ECB is selected.

[0101] Transmit power: for high-quality or good links, set to medium power (level 8); for average or poor links, set to maximum power (level 15).

[0102] For parameter set verification, CBGC calls the HCI layer interfaces hci_set_phy() and hci_set_mtu() of the OpenHarmony protocol stack to verify whether the optimal parameter set can be supported by the physical Bluetooth device. If some parameters are not supported, the adaptation is downgraded. For example, if BLE 2M PHY is not supported, it is downgraded to 1M PHY.

[0103] CBGC generates a transmission optimal parameter configuration frame. The frame structure includes an 8-byte frame header, an identifier BT_PARAM_OPT, a 2-byte PHY mode configuration, a 4-byte MTU configuration, an ATT layer and an L2CAP layer, a 2-byte fragment size, a 2-byte encryption algorithm configuration, a 1-byte transmit power level, a 1-byte link quality level, a 4-byte checksum, and a fixed total length of 32 bytes.

[0104] CBGC sends the optimal parameter configuration frame to PBSP through the HM-IPC channel, and at the same time sends parameter configuration commands to the HCI layer and L2CAP layer of the OpenHarmony protocol stack to complete the parameter initialization of the physical Bluetooth device.

[0105] After receiving the parameter configuration frame, PBSP calls the L2CAP layer interface l2cap_update_mtu() and the encryption module interface bt_encrypt_set_algorithm() of the Android container protocol stack to synchronize the parameters of the container-side protocol stack to the optimal configuration. At the same time, it disables the container-side PHY mode switching, MTU negotiation, and encryption negotiation functions to avoid parameter conflicts between the two protocol stacks.

[0106] S4. Dynamically activate resources and build a dedicated resource pool for transmission.

[0107] A new Bluetooth Transmission Dedicated Resource Dynamic Manager (BTDRDM) has been added to the OpenHarmony host system framework layer. This manager has three core functions: resource pre-allocation at system startup, dynamic resource adjustment during transmission, and elastic resource release after transmission termination.

[0108] During the system startup phase, BTDRDM completes the pre-allocation of the basic resource pool, including:

[0109] The CPU resource pool is pre-allocated based on the number of CPU cores in the device, with 1 to 2 cores pre-allocated as dedicated cores for Bluetooth transmission. For example, 1 core is allocated to a 4-core CPU and 2 cores are allocated to an 8-core CPU. Dedicated CPU groups are created through cgroups, with the initial scheduling weight set to 1024, which is the highest priority.

[0110] The memory resource pool is pre-allocated with 2GB of memory as a dedicated shared memory pool for Bluetooth transmission. It is locked by mlock() to prevent swapping. The memory pool is divided into a data buffer (80%), an encryption buffer (15%), a metadata area (3%), a status flag area (1%), and an exception log area (1%). Each partition adopts a circular queue structure.

[0111] The interrupt resource pool uses the OpenHarmony interrupt management framework to identify the IRQ number corresponding to the physical Bluetooth device, such as IRQ17, and pre-binds it to a dedicated CPU core, setting the interrupt priority to IRQF_HIGHPRI.

[0112] After receiving the optimal parameter configuration frame, PBSP sends a dedicated resource dynamic activation request to BTDRDM. The request carries the optimal set of transmission parameters, the total file size, and the transmission service type, which is used by BTDRDM to adjust the granularity of resource allocation.

[0113] After receiving the activation request, BTDRDM initiates dynamic resource allocation, including:

[0114] CPU resources are dynamically bound. The sched_setaffinity() system call binds the Android container's PID, PBSP process, OpenHarmony side CBGC process, OpenHarmony protocol stack L2CAP layer processing process, and HCI layer sending process to a dedicated CPU core. At the same time, the nice() system call adjusts the priority of these processes to -20, which is the highest user-mode priority, to prevent other processes from occupying the dedicated CPU core.

[0115] Dynamic allocation of memory resources, based on the total file size and fragment size, adjusts the size of each partition in the shared memory pool, including:

[0116] The data buffer adjusts the length of the circular queue to 1.5 times the total file size, and the size of each queue element is equal to the fragment size, such as 64KB, to ensure that 1.5 times the file data can be cached and to avoid buffer overflow when transferring large files.

[0117] The encryption buffer is adjusted to 20% of the data buffer size to ensure unblocked data storage of encrypted data.

[0118] The metadata area is adjusted according to the product of the number of fragments and 32 bytes. Each fragment corresponds to 32 bytes of metadata. A metadata index table is established to support fast query by fragment number.

[0119] The status marker area sets status bits according to the number of fragments. Each fragment occupies 1 byte and indicates whether it is idle, pending encryption, pending transmission, sent, retransmitted, or failed. At the same time, it sets the status update timestamp, accurate to microseconds.

[0120] Interrupt resource exclusivity: irq_set_affinity() is called to confirm the binding relationship between the Bluetooth IRQ and the dedicated CPU core, preventing other interrupt requests from preempting the interrupt response resources of this core, and controlling the interrupt response delay to within 1ms; Resource allocation result generation: BTDRDM generates a dedicated resource allocation result frame, which includes the dedicated CPU core number, the physical address and virtual address mapping relationship of each partition of the shared memory pool, the IRQ binding status, and the resource allocation validity period, which is equal to the expected transmission duration by default, and is sent to PBSP and CBGC through the HM-IPC channel.

[0121] After receiving the resource allocation result frame, PBSP uses the mmap() system call to map the virtual address of the shared memory pool to the process address space of the Android container. During mapping, permissions are set so that the application can only write to the data buffer and cannot access other partitions, ensuring memory access isolation.

[0122] After receiving the resource allocation result frame, CBGC synchronizes the shared memory address information to the L2CAP and HCI layers of the OpenHarmony protocol stack, enabling the protocol stack to directly read the data in the shared memory without needing to go through the kernel network module for forwarding.

[0123] S5 enables zero-copy data writing in user space, allowing for direct data transfer across systems.

[0124] Based on shared memory mapping, PBSP provides a user-space zero-copy write interface for Android applications. This interface is implemented by hooking the BluetoothSocket.getOutputStream() method of the Android container protocol stack, and applications can call it without modifying their code.

[0125] When an Android application calls the `write()` method, data is directly written to the shared memory pool's data buffer via a zero-copy write interface, including:

[0126] PBSP verifies the legitimacy of the application data buffer through the memory descriptor passed by the application, including address range and permissions. After successful verification, a direct mapping is established between the application buffer and the shared memory data buffer. Application data is directly written to the shared memory data buffer through the Direct Memory Access (DMA) mechanism, bypassing the L2CAP layer, HCI layer, network module, and file system module of the Android container protocol stack, achieving zero-copy transfer of Android applications to shared memory in user space, without any intermediate data copying. During the data writing process, PBSP monitors the writing progress in real time. When a single fragment is written and reaches the fragment size in the optimal parameter set, the metadata entry for that fragment is immediately generated in the metadata area.

[0127] The metadata entry consists of 32 bytes, formatted as follows: Fragment number (4 bytes): an unsigned integer starting from 0 and incrementing, uniquely identifying each fragment; Data offset (4 bytes): the starting address offset of the fragment in the data buffer; Fragment length (2 bytes): the actual length of data written, equal to the fragment size or the remaining length of the last fragment; Target device information (6 bytes): including the compressed MAC address and device type identifier; Transmission configuration (4 bytes): including a 2-byte Transmission Service Type Encoding, a 1-byte Encryption Enable Flag, and a 1-byte Fragment Type, where 0x01 indicates a data fragment and 0x02 indicates the end of a fragment; Verification information (4 bytes): a CRC32 checksum based on the fragmented data; Timestamp (4 bytes): the timestamp indicating the completion of fragment writing, accurate to milliseconds.

[0128] After PBSP completes the writing of the metadata entry, it updates the corresponding fragment status in the status flag area: from idle 0x00 to pending encryption 0x01 or pending transmission 0x02.

[0129] PBSP sends a notification to the shared memory data monitoring unit on the OpenHarmony side through a semaphore-based shared memory data readiness notification mechanism. This unit is a new module added to the L2CAP layer of the OpenHarmony protocol stack in this application. The notification includes the range of fragment numbers to be processed and the starting address of the metadata area.

[0130] After the data ready notification is sent, PBSP returns a data write success response to the Android application, allowing the application to continue sending the next batch of data. At the same time, it monitors the processing status of the sent fragments through the status flag area to prevent the application from repeatedly writing to the same memory area.

[0131] S6, cross-system encrypted context synchronization and hardware-accelerated encryption.

[0132] A new Cross-system Bluetooth Encryption Service (CBES) has been added to the Bluetooth protocol stack on the OpenHarmony host side. This service integrates the hardware encryption engine interface of the OpenHarmony system, such as the TEE hardware encryption module based on ARM TrustZone, supports hardware acceleration of AES-CCM or AES-ECB algorithms, and also has encryption context management and cross-system synchronization functions.

[0133] After receiving the data ready notification, the shared memory data monitoring unit reads the encryption enable flag of the metadata entry. If the flag is enabled (0x01), it sends an encryption processing request to CBES, which includes the number of the fragment to be encrypted, the data buffer offset, and the address of the metadata entry.

[0134] After receiving an encryption processing request, CBES initiates cross-system encryption context synchronization, including:

[0135] Encryption context acquisition: CBES reads the encryption negotiation results of the current connection from the cross-system Bluetooth connection state library, such as the link key LK, session key SK, and encryption algorithm parameters. Based on this information, it generates an encryption context containing a key, counter, and initialization vector IV.

[0136] Encryption context sharing: CBES stores the encryption context in a dedicated area of ​​the encryption buffer in shared memory, and grants read-only access to PBSP through memory mapping, ensuring that the Android container-side protocol stack can obtain the encryption context and avoiding incompatibility caused by repeated key generation;

[0137] Hardware-accelerated encryption: CBES calls the input interface of the hardware encryption engine, passes the fragmented data to be encrypted in the shared memory data buffer to the hardware encryption engine, and passes the encryption context parameters at the same time.

[0138] After the encryption result is written, the hardware encryption engine completes the encryption operation according to the specified algorithm, writes the encrypted data into the encryption buffer of shared memory, and generates an encryption verification code based on the SHA256 algorithm, which is then written into the verification information field of the metadata entry.

[0139] After encryption is completed, CBES updates the corresponding fragment status in the status marker area: from 0x01 to be encrypted to 0x02 to be sent, and at the same time notifies the shared memory data monitoring unit that encryption is complete via a semaphore;

[0140] If the encryption enable flag is set to disabled (0x00), the shared memory data monitoring unit directly updates the fragment status of the status flag area from idle (0x00) to pending transmission (0x02) to skip the encryption process.

[0141] S7, Deterministic Fragmentation and Dynamic Link Adaptation.

[0142] The OpenHarmony protocol stack's L2CAP layer adds a new Deterministic Fragmentation Transmission Unit (DFTU). This unit executes a fixed-rule fragmentation transmission strategy based on the optimal transmission parameter set, while also possessing dynamic link adaptation capabilities.

[0143] The DFTU monitors the status flag area via semaphore. When it detects a fragment status of "to be transmitted 0x02", it initiates the transmission process, including:

[0144] For fragmented reading, DFTU reads the corresponding metadata entry from the metadata area according to the fragment number, reads fragmented data based on the data offset, reads from the shared memory data buffer when encryption is disabled, and reads from the encryption buffer when encryption is enabled.

[0145] Secondary fragmentation processing: If the fragment length is greater than the maximum MTU of the ATT layer (251 bytes), then deterministic secondary fragmentation is performed according to the ATT layer MTU. The length of each secondary fragment is fixed at 251 bytes, including a 2-byte L2CAP header. The length of the last secondary fragment is adjusted as needed, with a minimum of 20 bytes. The secondary fragment number format is fragment number and secondary fragment number, such as 0-0, 0-1.

[0146] L2CAP frame encapsulation: DFTU encapsulates the secondary fragmented data into L2CAP data frames. The frame structure is defined according to the Bluetooth core specification. The L2CAP header is 4 bytes including the length and channel ID, and the secondary fragmented data and checksum are 2 bytes in total. Redundant fields such as optional extended headers are disabled during the encapsulation process to reduce frame overhead.

[0147] In HCI frame conversion, DFTU sends L2CAP data frames to the HCI layer of the OpenHarmony protocol stack. The HCI layer converts the L2CAP frames into HCI ACL data frames according to the PHY mode and transmit power in the optimal parameter set, and sends them directly to the physical Bluetooth device through the HCI interface, bypassing the network forwarding module of the host kernel.

[0148] After receiving the HCI ACL data frame, the physical Bluetooth device sends the data to the target device through the radio frequency module. After the transmission is completed, it returns a transmission success response to the HCI layer. The HCI layer feeds back the response to the DFTU. The DFTU updates the corresponding fragment status in the status flag area, changing it from pending transmission 0x02 to transmitted 0x03. At the same time, it records the transmission timestamp and link feedback parameters, such as RSSI and bit error rate.

[0149] Link dynamic adaptation: Every 10 fragments sent, DFTU obtains real-time link quality data such as RSSI, bit error rate and retransmission count from HCI layer. If the link quality level changes, such as from excellent to good, it sends a link quality update request to CBGC.

[0150] After receiving the request, CBGC regenerates transmission parameters adapted to the new link quality, such as reducing fragment size, switching PHY mode, and increasing transmit power. These parameters are then synchronized to PBSP and DFTU via the HM-IPC channel. DFTU adjusts the fragmentation transmission strategy according to the new parameters to ensure that the transmission rate matches the link quality.

[0151] Retransmission handling: If the physical Bluetooth device returns a transmission failure response, DFTU checks whether the number of retransmissions has exceeded the threshold (default 3 times). If it has not exceeded the threshold, the fragment status is updated to retransmission 0x04, and the fragment is retransmitted immediately. If it has exceeded the threshold, the status is updated to failure 0x05, and a link alarm is sent to CBGC.

[0152] S8, cross-system real-time status feedback and precise flow control.

[0153] CBGC monitors the shared memory status marker area, DFTU transmission statistics, and HCI layer link quality data in real time, generating real-time transmission status feedback frames with a 5ms period. The frame structure is defined as follows:

[0154] The frame header is 8 bytes long and contains the frame identifier BT_STATUS_FEEDBACK.

[0155] The transmission progress field contains 4 bytes for the number of fragments sent, 4 bytes for the number of successful fragments, 4 bytes for the total number of fragments, and 4 bytes for the number of bytes transmitted.

[0156] The link quality field is 6 bytes: the current RSSI is 2 bytes stored in two's complement, the bit error rate is 2 bytes, and the number of retransmissions is 2 bytes;

[0157] The resource status field is 4 bytes: shared memory occupancy is 2 bytes, and the remaining writable fragments are 2 bytes.

[0158] The exception status field is 2 bytes: the exception flag is 1 byte, such as 0x00, which indicates no exception; the exception fragment number is 1 byte, which is 0x00 when there is no exception.

[0159] The checksum is 4 bytes: a CRC32 checksum based on the frame header and all fields.

[0160] CBGC sends feedback frames to PBSP in real time via the HM-IPC channel, ensuring that the container receives the latest status within 5ms. After receiving the feedback frame, PBSP initiates precise flow control, including:

[0161] Remaining resource calculation: Based on the total shared memory capacity, the occupied capacity, and the current fragment size, calculate the remaining number of writable fragments. Flow control decision: If the remaining number of writable fragments is no greater than 10 or the link error rate is no less than 10%, then return a pause sending notification to the Android application through the flow control interface of the Android container protocol stack to prevent the application from continuing to write data; if the remaining number of writable fragments is no less than 20 and the link error rate is less than 5%, then return a resume sending notification to allow the application to continue transmission; if the number of fragments sent is equal to the total number of fragments and there are no failed fragments, then return a transmission completion notification to trigger the application to close the output stream.

[0162] Application progress synchronization: PBSP converts the transmission progress, such as the number of bytes transferred and the total file size, into a percentage and feeds it back to the application through the Android container protocol stack callback interface, so that the application can display the real-time progress.

[0163] If the number of fragments with failure 0x05 is detected to exceed 3% of the total number of fragments, PBSP returns a transmission error message to the application, asking whether to retry the transmission. If the user chooses to retry, PBSP notifies DFTU to resend the failed fragments, without the application needing to re-initiate the entire transmission request.

[0164] S9 provides full lifecycle anomaly protection to ensure data security and resource integrity.

[0165] BTDRDM is a newly added anomaly monitoring and response unit that monitors abnormal events throughout the entire transmission process in real time, including: Bluetooth connection loss, sudden drop in link quality, shared memory overflow, encryption failure, fragmentation transmission timeout, CPU or memory resource preemption, etc.

[0166] The anomaly monitoring and response unit implements differentiated protection strategies for different anomaly types:

[0167] Type 1, Bluetooth connection lost, i.e., a connection loss event is detected at the HCI layer, then the DFTU is notified to suspend all fragment transmission and update the status of all untransmitted fragments to pause 0x06; the BTDRDM is notified to freeze the dedicated resource pool to avoid resource waste; a connection loss exception is returned to the application via PBSP, asking whether to re-establish the connection; if the user chooses to reconnect, the connection coordination establishment process is triggered, and the transmission of untransmitted fragments is resumed after a successful reconnection;

[0168] Type 2, shared memory overflow: If the data buffer occupancy rate is not less than 95%, the BTDRDM's dynamic memory expansion process is triggered, requesting an additional 1GB of memory from the system to expand the data buffer; if the expansion fails, the flow control's pause transmission logic is immediately triggered until the partial fragment transmission is completed and the memory is released.

[0169] Type 3, encryption failure: If the hardware encryption engine returns an error code, it will automatically downgrade to software encryption. For example, if CBES calls the software encryption library of the OpenHarmony system, it will return a message to the application indicating that encryption acceleration has failed and software encryption has been switched. The encryption failure log will be recorded in the exception log area for subsequent optimization.

[0170] Type 4: If the fragment transmission times out, a retransmission process is triggered, with a maximum of 3 retransmissions. If the retransmission still fails, the fragment is marked as failed (0x05). If the number of failed fragments exceeds the threshold, a transmission interruption process is initiated.

[0171] Type 5, CPU or memory resource preemption: When a dedicated CPU core is detected to be occupied by another process, BTDRDM forcibly evicts the preempting process through cgroups, restoring the exclusive access of the dedicated CPU core. If preemption is frequent, a resource priority upgrade request is sent to the OpenHarmony system framework to further improve the scheduling priority of Bluetooth transmission resources. After all exception handling is completed, the exception monitoring and response unit records the exception type, processing result, and processing time in the exception log area of ​​shared memory. The log is only accessible to the system debugging module for problem localization.

[0172] S10, Transmission Termination and Resource Elastic Release.

[0173] The triggering conditions for transmission termination include: the application calling BluetoothSocket.close() to close the connection, the number of sent fragments equaling the total number of fragments and no failed fragments, the user actively canceling the transmission, and an unrecoverable exception causing transmission interruption. When transmission termination is triggered, PBSP sends a transmission termination request to CBGC, carrying the transmission termination type (e.g., normal termination or abnormal termination) and transmission statistics such as total transmission time, average rate, and number of successfully transmitted bytes. After receiving the request, CBGC executes the termination preprocessing procedure, including:

[0174] Wait for all fragments in the 0x02 and 0x04 states to complete processing, and set the timeout to 5 seconds; calculate the final transmission results: transmission success rate = number of bytes successfully transmitted / total file size * 100%, average transmission rate = number of bytes successfully transmitted / total transmission time; generate a transmission termination report, including transmission statistics, anomaly log summary, and link quality change curve data; CBGC sends the transmission termination report to PBSP through the HM-IPC channel, and simultaneously sends a resource release request to BTDRDM;

[0175] After receiving a resource release request, BTDRDM executes the elastic release process: CPU resource release, unbinding Android containers, PBSP, CBGC, and other processes from dedicated CPU cores, restoring the processes to the general CPU group, and restoring the scheduling weights to default values; memory resource release, clearing data in the shared memory pool, including data buffers, encryption buffers, metadata areas, and status flag areas, to avoid data residue; if it is a normal termination and there are no other Bluetooth transmission requests in the short term, shrinking the shared memory pool from its expanded size back to the pre-allocated 2GB; calling munlock() to unlock the memory and returning unused memory to the system; interrupt resource release, unbinding the Bluetooth IRQ from the dedicated CPU core, and restoring the default priority of the interrupt.

[0176] After receiving a transmission termination report, PBSP converts it into a result that the Android application can recognize and returns it to the application through the BluetoothSocket close callback interface. At the same time, it destroys the cross-system IPC channel and shared memory mapping relationship. If it is an abnormal termination, PBSP synchronizes the abnormal log summary to the application to facilitate error handling, such as retrying the transmission and saving the transmission progress.

[0177] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for accelerating cross-system Bluetooth file transfer based on protocol stack penetration proxy, characterized in that, Specifically, the following steps are included: The host collects the Bluetooth chip's hardware capabilities and MAC address, starts the Bluetooth collaboration manager; allocates shared memory, builds the Bluetooth connection state library, initializes the cross-system IPC channel, and starts the resource dynamic manager; the container starts the Bluetooth penetration proxy and binds to the request interception unit, reports the container's Bluetooth access permissions, and disables the container's native Bluetooth negotiation; The container application initiates a Bluetooth connection request. The request interception unit encapsulates it into a cross-system Bluetooth connection request frame and sends it to the Bluetooth Coordination Manager through the IPC channel. The Bluetooth Coordination Manager reads the Bluetooth hardware capabilities and generates the optimal connection parameter set according to the application's expected parameters. The host protocol stack initiates a Bluetooth connection based on the optimal connection parameter set and synchronizes the connection negotiation feedback to the Bluetooth passthrough agent. The Bluetooth passthrough agent returns a successful connection establishment to the container protocol stack and writes the optimal connection parameter set into the connection status register. The container application initiates a file transfer request, which is encapsulated into a cross-system Bluetooth file transfer request frame by the request interception unit and then sent to the Bluetooth Coordinator. The application buffer memory descriptor is sent to the Bluetooth passthrough proxy. The Bluetooth passthrough proxy reads the real-time link quality from the Bluetooth connection state library, initiates a transmission capability negotiation request to the Bluetooth Coordinator, and the Bluetooth Coordinator returns the optimal transmission parameter set and synchronizes it to the host Bluetooth protocol stack. The Bluetooth passthrough proxy updates the container protocol stack, sends a resource activation request to the resource dynamic manager, and the resource dynamic manager returns a resource allocation result frame and sends it to the Bluetooth Coordinator. The Bluetooth passthrough proxy maps shared memory to the container address space, and the Bluetooth Coordinator synchronizes the address to the host Bluetooth protocol stack. Container applications use DMA to write the file to be transferred into shared memory in fragments according to the optimal set of transmission parameters. The Bluetooth pass-through agent generates fragment metadata for the file. The host protocol stack reads the fragment metadata, encapsulates the data, and sends it to Bluetooth. Bluetooth then sends the data to the target device.

2. The cross-system Bluetooth file transfer acceleration method according to claim 1, characterized in that, The container application uses DMA to write the file to be transferred into shared memory in fragments according to the optimal transmission parameter set. The Bluetooth pass-through proxy generates fragment metadata for the fragments. The host protocol stack reads the fragment metadata, encapsulates the data, and sends it to Bluetooth. The specific method is as follows: After the container application completes the writing of a single fragment of data according to the fragment size in the optimal transmission parameters, the Bluetooth penetration agent generates fragment metadata, updates the fragment status to "ready to send," sends a data ready notification to the host's shared memory data monitoring unit, and returns a data write success response to the container application, allowing it to send the next batch of data. At the same time, it monitors the processing status of the sent fragments through the status flag area. The fragment sending unit located in the L2CAP layer of the host protocol stack obtains the shared memory fragment status through the semaphore monitoring status flag area. When the fragment status is "ready to send," it reads the corresponding metadata from the metadata area according to the fragment number, reads the fragment data from the shared memory data buffer based on the data offset, and sends it to Bluetooth.

3. The cross-system Bluetooth file transfer acceleration method according to claim 2, characterized in that, The process involves reading fragmented data from the shared memory data buffer based on the data offset. If the fragment length is greater than the maximum effective payload of a single control packet, the maximum effective payload of the single control packet is used as the new fragment size for secondary fragmentation. The secondary fragment number consists of the primary fragment number and the secondary fragment number. The secondary fragmented data is encapsulated into an L2CAP data frame and sent to the HCI layer. The HCI layer converts the L2CAP data frame into an HCI ACL data frame according to the optimal transmission parameter set PHY mode and transmit power, and then sends it to Bluetooth.

4. The cross-system Bluetooth file transfer acceleration method according to claim 1, characterized in that, The Bluetooth then sends the data to the target device in the following way: Bluetooth sends the data to the target device through the radio frequency module and returns a successful transmission response to the HCI layer. The HCI layer sends the response to the fragmentation transmission unit, which updates the fragmentation status and records the transmission timestamp and link feedback parameters. The Bluetooth Co-Manager periodically generates transmission status feedback frames, including transmission progress, link quality, resource status, anomaly markers, and checksums, which are synchronized to the Bluetooth Penetration Proxy via the IPC channel. The Bluetooth passthrough proxy performs flow control based on two thresholds: memory usage and link error rate. When the cache is less than the threshold or the link quality is less than the threshold, the application write is paused. The file transfer progress is synchronized with the application in real time. When the fragment failure rate is greater than the threshold, a transfer exception is returned to the application, and the failed fragments are retransmitted according to the user's selection. After all files have been transferred, CPU and memory resources will be released.

5. The cross-system Bluetooth file transfer acceleration method according to claim 1, characterized in that, The optimal connection parameter set is generated as follows: After receiving the transmission request frame, the Bluetooth penetration agent reads the real-time link quality index in the Bluetooth connection status library, and initiates a capability negotiation request to the Bluetooth Co-Manager based on the size of the file to be transmitted and the type of transmission service, carrying the unique link identifier, file metadata and real-time link status information. After receiving the negotiation request, the Bluetooth Co-Manager collects Bluetooth performance parameters, classifies the link quality level based on signal strength, bit error rate, and retransmission frequency, and generates the optimal transmission parameter set based on hardware limits and link conditions.

6. The method for accelerating cross-system Bluetooth file transfer according to claim 2, characterized in that, The host Bluetooth protocol stack deploys a cross-system Bluetooth encryption service, supports hardware-accelerated computation of specified encryption algorithms, manages key contexts, and synchronizes across environments. After receiving a data ready notification, the host's shared memory data monitoring unit reads the encryption switch identifier in the fragment metadata. If encryption is enabled, it sends a fragment encryption task to the encryption service. Upon receiving the task, the encryption service first reads the key information obtained from the current link negotiation from the Bluetooth connection state library, constructs an encryption context containing the key, random vector, and counting parameters, and stores it in a dedicated partition of shared memory. It then reads the original fragment data from the shared memory and sends it along with the encryption context to the hardware acceleration module for computation. After encryption, the ciphertext is written to the shared memory encryption buffer, and a data checksum is generated and filled back into the corresponding fragment metadata. The fragmentation state is switched from pending encryption to pending transmission, and the shared memory data monitoring unit is notified of the completion of the encryption task via a semaphore; if the encryption switch is in the off state, the monitoring unit changes the fragmentation state back to pending transmission.

7. The method for accelerating cross-system Bluetooth file transfer according to claim 2, characterized in that, After each set number of fragments is sent, the fragment sending unit reads the real-time link quality. If the link quality level changes, it sends a link quality update request to the Bluetooth Co-Manager. Upon receiving the update request, the Bluetooth Co-Manager regenerates the transmission parameters based on the current link conditions and simultaneously sends them to the Bluetooth Penetration Proxy and the fragment sending unit. The fragment sending unit sets the fragment sending rules based on the updated transmission parameters. If Bluetooth reports a data packet transmission failure, the fragment sending unit checks whether the cumulative retransmission count for that fragment has not reached the maximum retry threshold. If it has not, the fragment status is marked as retransmission and a retransmission is immediately initiated. If it has reached the threshold, the fragment is marked as a transmission failure, and a link anomaly alarm is simultaneously reported to the Bluetooth Co-Manager.

8. The cross-system Bluetooth file transfer acceleration method according to claim 4, characterized in that, After receiving the status feedback frame, the Bluetooth passthrough proxy calculates the number of remaining writable fragments based on the total shared memory capacity, the occupied capacity, and the current fragment size. When the number of remaining writable fragments is lower than a smaller threshold or the link error rate exceeds a risk threshold, a pause transmission notification is pushed to the application. When the number of remaining writable fragments is greater than a larger threshold and the link error rate is within a healthy range, application data writing is resumed. When all fragments have been sent and no fragment transmission has failed, a transmission completion notification is pushed, triggering the application to end the current file transfer service.

9. The cross-system Bluetooth file transfer acceleration method according to claim 1, characterized in that, The fragment metadata includes: fragment number, which is a unique identifier for the fragment; and data offset, which is the starting offset address of the fragment in the shared memory data buffer. The fragment length is the actual length of data written to the fragment. The target device information includes the target device's MAC address and Bluetooth device type identifier; the transmission configuration includes the transmission service type encoding, encryption enable flag, and fragmentation type identifier; and the verification information is the CRC32 checksum calculated based on the complete fragmented data. A timestamp is the timestamp at which the data fragment was written to the end.

10. The cross-system Bluetooth file transfer acceleration method according to claim 1, characterized in that, The Bluetooth file transfer request frame includes a frame header, a file metadata field, a transfer configuration field, a data buffer handle field, and a frame trailer.

Images