Data transmission method, device, chip and computer readable storage medium

Abstract

The application provides a data transmission method, device, chip and computer readable storage medium, which can solve the fault problem caused by the new MTU negotiation strategy. The method is applied to a first device, a first application is installed on the first device, and the first device comprises a first Bluetooth module. The first application is used for communicating with a second application in a second device through the first Bluetooth module. The second device comprises a second Bluetooth module. The method comprises the following steps: the first application receives a first MTU sent by the second application. The first MTU is an MTU determined by the second application for data transmission. The first application obtains a second MTU from the first Bluetooth module. The second MTU is an MTU after the first Bluetooth module and the second Bluetooth module perform MTU negotiation. The first application determines a target MTU based on the first MTU and the second MTU. The target MTU is less than or equal to the first MTU, and the target MTU is less than or equal to the second MTU. The first application sends data to the second application based on the target MTU.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of wireless communication, and particularly relates to a data transmission method, device, chip and computer readable storage medium. BACKGROUND

[0002] With the continuous expansion of application requirements and use scenarios, Bluetooth communication technology is applied in more and more fields. Two devices can be connected through Bluetooth to perform data transmission. After the Bluetooth connection is completed, a first application in a first device can perform data transmission with a second application in a second device. In order to ensure the smooth progress of data transmission, the first device and the second device can perform maximum transmission unit (MTU) negotiation, and transmit data based on the negotiated MTU, so as to ensure that the data packet sent by the upper layer application does not exceed the carrying capacity of the underlying Bluetooth, thereby avoiding data loss or communication interruption.

[0003] At present, some systems introduce a new MTU negotiation strategy. After the new MTU negotiation strategy is used, a fault scenario in which part of the functions of some applications appear abnormal when interacting with other devices occurs. SUMMARY

[0004] The present application provides a data transmission method, device, chip and computer readable storage medium, which can solve the fault problem caused by the new MTU negotiation strategy.

[0005] In a first aspect, a data transmission method is provided. The method is applied to a first device, a first application is installed on the first device, and the first device includes a first Bluetooth module. The first application is configured to communicate with a second application in a second device through the first Bluetooth module. The second device includes a second Bluetooth module. The method includes: the first application receives a first maximum transmission unit (MTU) sent by the second application. The first MTU is an MTU determined by the second application for data transmission. The first application obtains a second MTU from the first Bluetooth module. The second MTU is an MTU after the first Bluetooth module and the second Bluetooth module perform MTU negotiation. The first application determines a target MTU based on the first MTU and the second MTU. The target MTU is less than or equal to the first MTU, and the target MTU is less than or equal to the second MTU. The first application sends data to the second application based on the target MTU.

[0006] After using the new MTU negotiation strategy, the first MTU sent by the second application to the first application may exceed the second MTU that the Bluetooth protocol stack can carry. This will cause the first application to fail to connect with the second application and fail to transmit data.

[0007] The technical solution provided in this application does not involve the first application directly using the first MTU reported by the second application for data transmission. Instead, it obtains the second MTU negotiated between the two Bluetooth modules from the first Bluetooth module and determines a target MTU that is no larger than or equal to both the first and second MTUs. After determining the target MTU, the first application can transmit data based on it. Since the target MTU is less than or equal to the second MTU, the data packets generated based on the target MTU will not exceed the MTU that the Bluetooth protocol stack can support, thus avoiding connection failures and the problem of data transmission failure.

[0008] In some possible implementations, the first application determines a target MTU based on the first MTU and the second MTU, including: the first application determining the smaller of the first MTU and the second MTU; and the first application using the smaller value as the target MTU.

[0009] The first application can use the smaller of the first MTU and the second MTU as the target MTU. The first application only needs to compare the first MTU with the second MTU to determine the target MTU, thus reducing its computational overhead. Furthermore, the target MTU determined by the first application is the maximum MTU within the carrying capacity range of both the first and second Bluetooth modules, thereby improving data transmission efficiency.

[0010] In some possible implementations, the first application obtains the second MTU from the first Bluetooth module by: the first application obtaining the second MTU from the first Bluetooth module by calling an MTU callback function.

[0011] The first application can actively obtain the second MTU by calling the callback function, so that the first application can independently determine which MTUs need to be obtained from the first Bluetooth module, thus avoiding unnecessary transmission overhead.

[0012] In some possible implementations, the callback function is BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt, int mtu, int status).

[0013] By reusing the onMtuChanged function to obtain the second MTU, the complexity of obtaining the second MTU can be reduced.

[0014] In some possible implementations, before the first application obtains the second MTU from the first Bluetooth module, the method further includes: the first Bluetooth module receiving a third MTU sent by the second Bluetooth module, the third MTU being the MTU that the second Bluetooth module can carry; the first Bluetooth module determining the second MTU based on the third MTU and a fourth MTU, wherein the fourth MTU is the MTU that the first Bluetooth module can carry, and the second MTU is the smaller value between the third MTU and the fourth MTU.

[0015] Before the first application obtains the second MTU, the first Bluetooth module and the second Bluetooth module can negotiate the second MTU. The negotiated second MTU does not exceed the carrying capacity of the first Bluetooth module and the second Bluetooth module, which helps to ensure the smooth transmission of data.

[0016] In some possible implementations, the third MTU is carried in the MTU request, and the method further includes: in response to the MTU request, the first Bluetooth module sends an MTU response to the second Bluetooth module, the MTU response including the fourth MTU.

[0017] Exchanging the MTU through an MTU request and MTU response process can reduce the complexity of MTU exchange.

[0018] In some possible implementations, the first application sends data to the second application based on the target MTU, including: the first application segments the data to be sent using the target MTU; and the first application sends the segmented data to the second application through the first Bluetooth module and the second Bluetooth module.

[0019] The first application can segment the data according to the target MTU, ensuring that the data sent from the first application to the second application does not exceed the carrying capacity of either the first or second Bluetooth module. This allows the first Bluetooth module to send the data completely to the second device, thus guaranteeing smooth data transmission.

[0020] In some possible implementations, the first application sends segmented data to the second application through the first Bluetooth module, including: the first application sending the segmented data to the first Bluetooth module; the first Bluetooth module verifying the segmented data using the second MTU; and if the segmented data passes verification, the first Bluetooth module sending the segmented data to the second application through the second Bluetooth module.

[0021] The first Bluetooth module can verify the data sent by the first application, which helps ensure the smooth transmission of data.

[0022] In some possible implementations, the first Bluetooth module uses the second MTU to verify the segmented data, including: the first Bluetooth module determining whether the length of the segmented data exceeds the value of the second MTU; if the length of the segmented data does not exceed the value of the second MTU, the first Bluetooth module determines that the segmented data has passed verification.

[0023] The first Bluetooth module uses the second MTU to verify the data sent by the first application, which can prevent the length of the data sent by the first application from exceeding the second MTU that the first Bluetooth module can handle, thus avoiding communication failure.

[0024] In some possible implementations, the method further includes: the first Bluetooth module receiving a response message sent by the second Bluetooth module, the response message being a response to the segmented data, the response message being used to indicate whether the segmented data has been successfully verified.

[0025] The first Bluetooth module and the first application can determine whether the Bluetooth connection between the first device and the second device is successful based on the response message, which helps the first device to adjust its subsequent transmission strategy in a timely manner.

[0026] In a second aspect, an apparatus is provided, which is a first apparatus comprising a unit consisting of software and / or hardware, the unit being used to perform any one of the methods in the technical solution of the first aspect.

[0027] Thirdly, a chip is provided, including a processor; the processor is used to read and execute a computer program stored in a memory to perform any of the methods described in the first aspect.

[0028] Optionally, the chip further includes a memory, which is connected to the processor via a circuit or wire.

[0029] Alternatively, the chip may further include a communication interface.

[0030] Fourthly, a device is provided, which is a first device, comprising: a processor, a memory, and an interface; the processor, memory, and interface cooperate with each other to enable the first device to execute any one of the technical solutions described in the first aspect; or to include any one of the chips described in the third aspect.

[0031] Fifthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, the processor performs any one of the methods described in the first aspect.

[0032] In a sixth aspect, a computer program product is provided, the computer program product comprising: computer program code, which, when executed on an electronic device, causes the electronic device to perform any one of the methods described in the first aspect. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the structure of a device 100 provided in an embodiment of this application;

[0034] Figure 2 This is a software structure block diagram of a device 100 provided in an embodiment of this application;

[0035] Figure 3a This is a schematic diagram illustrating Bluetooth communication between a mobile phone and a smart bracelet according to an embodiment of this application;

[0036] Figure 3b This is a schematic diagram illustrating Bluetooth communication between a mobile phone and a vehicle, as provided in an embodiment of this application.

[0037] Figure 3c This is a schematic diagram illustrating Bluetooth communication between a mobile phone and multiple devices according to an embodiment of this application;

[0038] Figure 4 This is a schematic flowchart illustrating MTU interaction using a Bluetooth module;

[0039] Figure 5 This is a schematic flowchart illustrating data transmission between a first application and a second application.

[0040] Figure 6 This is a schematic flowchart illustrating data transmission between a fitness and health app on a mobile phone and a fitness tracker app on a smart band.

[0041] Figure 7 This is a schematic flowchart illustrating Bluetooth communication between a mobile phone and a smart band based on a new MTU interaction strategy.

[0042] Figure 8 The bracelet log shows a packet verification failure.

[0043] Figure 9 This shows the basic information of the 0103 data packet in the bracelet log;

[0044] Figure 10 The data packet length information in the bracelet log is displayed;

[0045] Figure 11 The problem description from the phone's logs is shown;

[0046] Figure 12 This displays information about the MTU value negotiated by the mobile terminal.

[0047] Figure 13 The system displays information about issues encountered when a mobile phone interacts with a vehicle via Bluetooth.

[0048] Figure 14 This is a schematic flowchart illustrating a data transmission method provided in an embodiment of this application;

[0049] Figure 15 This is a schematic flowchart illustrating another data transmission method provided in an embodiment of this application;

[0050] Figure 16 This is a schematic block diagram of a device provided in an embodiment of this application;

[0051] Figure 17 This is a schematic diagram of the structure of a device provided in an embodiment of this application. Detailed Implementation

[0052] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0053] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0054] The embodiments of this application can be applied to scenarios where communication is conducted using Bluetooth. For ease of understanding, the first and second devices involved in the embodiments of this application will be described in detail first.

[0055] The first device and the second device can be any device with Bluetooth communication capabilities. The first device and the second device can establish a Bluetooth connection and transmit data via Bluetooth. Both the first device and the second device include a Bluetooth module. This Bluetooth module can be a Bluetooth chip.

[0056] The first device can be a fixed terminal or a mobile terminal. For example, the first device can be an in-vehicle device, electrical appliance, desktop computer, laptop computer, tablet computer, personal computer (PC), mobile phone, wearable device, augmented reality (AR) / virtual reality (VR) device, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), smart speaker, smart home appliance, etc. Wearable devices can include, for example, watches, bracelets, and headphones. In some implementations, the first device can also be a remote control, Bluetooth keyboard, Bluetooth mouse, Bluetooth headset, Bluetooth blood pressure monitor, Bluetooth printer, Bluetooth work card, Bluetooth adapter, Bluetooth Moving Picture Experts Group Audio Layer III (MP3), Bluetooth compact flash (CF) card, etc. The type of the second device can be similar to the first device; that is, the second device can also be any of the above-mentioned devices. This application does not impose any restrictions on the specific types of the first and second devices.

[0057] In some embodiments, the type of the first device and the type of the second device can be the same. For example, both the first device and the second device can be mobile phones. In some embodiments, the type of the first device and the type of the second device can be different. As an example, the second device can be an accessory or peripheral device of the first device. For example, the first device is a mobile phone, and the second device is a smart bracelet or a car, etc.

[0058] For example, Figure 1This is a schematic diagram of the structure of a device 100 provided in an embodiment of this application. Device 100 can be either the first device mentioned above or the second device. Device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, etc.

[0059] The mobile communication module 150 may include one or more of second-generation (2G), 3G, 4G, and 5G communication modules. The mobile communication module 150 may include one or more of a filter, a switch, a power amplifier, and a low-noise amplifier (LNA).

[0060] The wireless communication module 160 may include one or more of the following: Bluetooth (BT) module, Wireless Local Area Network (WLAN) module, Global Navigation Satellite System (GNSS) module, Near Field Communication (NFC) module, Infrared (IR) module, and Frequency Modulation (FM) module. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering on the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification on them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0061] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on device 100. In other embodiments of this application, device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0062] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the device 100. In other embodiments of this application, the device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0063] The following is combined Figure 2 This application describes the software system architecture of the device (first device, such as a mobile phone) in the embodiments of this application. The software system of the device in the embodiments of this application can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment takes the layered architecture Android system as an example to illustrate the software structure of the device.

[0064] Figure 2 This is a software architecture block diagram of the device according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system can be divided into four layers, from top to bottom: the application (APP) layer, the application framework layer, the native service layer, and the driver layer. The native layer can also be called the system layer.

[0065] like Figure 2 As shown, the application layer can include a series of application packages, which may include applications such as SMS, calendar, camera, video, navigation, gallery, calling, fitness and health, Bluetooth, and wireless fidelity (WiFi).

[0066] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0067] like Figure 2 As shown, the application framework layer may include a window manager, resource manager, notification manager, Bluetooth manager, WiFi manager, camera manager, etc.

[0068] The window manager is used to manage window applications, including managing the window hierarchy and display order. The window manager can obtain the screen size, determine if a status bar is present, lock the screen, and capture the screen, among other things.

[0069] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, etc.

[0070] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0071] The Bluetooth Manager is used to manage and control various Bluetooth functions, coordinating communication between applications and Bluetooth. For example, the Bluetooth Manager can monitor changes in the Bluetooth hardware's state, such as the device's on / off status, visibility, and pairing status, and respond accordingly, such as turning the Bluetooth adapter on or off, sending visibility broadcasts, and handling Bluetooth pairing requests. Secondly, the Bluetooth Manager also manages connections between Bluetooth devices. It can maintain a list of paired devices and handle connection requests. When a device requests a connection, the Bluetooth Manager establishes a connection with that device and notifies the relevant application. The Bluetooth Manager can also support parallel connections between multiple devices and provides corresponding APIs for application use. In addition, the Bluetooth Manager has other functions, such as server and client implementations for Bluetooth data transmission, and Bluetooth device discovery and search.

[0072] WiFi Manager is used to manage wireless network connections on your device. With WiFi Manager, you can obtain information about currently connected networks, search for available networks, connect to specified networks, and disable networks.

[0073] The camera manager is used to manage the cameras on the device, including getting a list of cameras and turning specific cameras on or off.

[0074] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0075] The system layer can include multiple functional modules. For example: sensor service module, physical state recognition module, 3D graphics processing library, Bluetooth stack, WiFi module, camera module, etc.

[0076] The sensor service module is used to monitor sensor data uploaded by various sensors at the hardware layer to determine the physical status of the device.

[0077] The physical state recognition module is used to analyze and recognize user gestures, faces, etc.

[0078] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0079] The Bluetooth stack, also known as the Bluetooth protocol stack, enables communication and data transmission between Bluetooth devices through a series of protocol layers.

[0080] The kernel layer is the layer between hardware and software. The kernel layer includes at least the display driver, camera driver, sensor driver, Bluetooth driver, and WiFi driver.

[0081] The Bluetooth connection between the first device and the second device can be either a classic Bluetooth connection or a Bluetooth Low Energy (BLE) connection. The BLE connection can be established on top of the Generic Attribute Profile (GATT). The first device and the second device can establish a communication connection via GATT. The first device includes a first Bluetooth module, and the second device includes a second Bluetooth module. The first Bluetooth module can be either a classic Bluetooth module or a BLE module. The second Bluetooth module can also be either a classic Bluetooth module or a BLE module. The Bluetooth module in this embodiment can also be referred to as a Bluetooth communication module. A Bluetooth connection between the first device and the second device can be achieved through the connection between the first Bluetooth module and the second Bluetooth module. The first device and the second device can communicate through this Bluetooth connection.

[0082] In some embodiments, the Bluetooth module can listen to signals emitted by other devices, such as probe requests and scan signals. The Bluetooth module can also send response signals and scan responses. The Bluetooth module can establish Bluetooth connections with other devices and communicate with them via these connections.

[0083] In other embodiments, the Bluetooth module may also transmit signals, such as broadcasting a BLE signal, enabling other devices to discover the Bluetooth device. The Bluetooth module can establish Bluetooth connections with other devices and communicate with them via these connections.

[0084] Applications can be installed on both the first and second devices. These applications can be software applications or mini-programs. The applications on the first and second devices can transmit data via Bluetooth. This application does not specifically limit the applications on the devices. For example, the application can be a sports and health app, a fitness tracker app, a vehicle app, a smart home appliance app, a remote control app, etc. A remote control app, for example, can remotely control devices such as vehicles, computers, and home appliances.

[0085] The following is combined Figures 3a-3c Taking a mobile phone as the first device as an example, this paper introduces the Bluetooth connection scenarios between mobile phones and other devices.

[0086] See Figure 3a , Figure 3a The Bluetooth connection between the phone and the fitness tracker is shown. The phone has a fitness app installed, and the fitness tracker has a fitness tracker app installed. The fitness tracker app can monitor the user's health information. Through the Bluetooth connection between the phone and the fitness tracker, the phone's display shows the user's health information, such as steps taken, exercise intensity, calories burned, sleep patterns, and heart health.

[0087] See Figure 3b , Figure 3b The Bluetooth connection between the phone and the vehicle is shown. A remote control app is installed on the phone, allowing for remote vehicle control. Through the Bluetooth connection, the phone's display shows the vehicle's current status information, such as remaining range, fuel level, lock status, engine status, door status, trunk status, window status, and air conditioning status. Furthermore, the phone can also control the vehicle's status via Bluetooth. For example, it can control the vehicle to unlock or lock, start or stop the engine, lock or open the doors, open or close the trunk, open or close the windows, and turn the air conditioning on or off.

[0088] In this application embodiment, the first device can connect to one device via Bluetooth or to multiple devices simultaneously; this application embodiment does not specifically limit this. See also Figure 3c The phone can simultaneously connect to headphones, a smartwatch, and a vehicle via Bluetooth. It should be noted that... Figure 3c This is just one example, and the embodiments of this application are not limited thereto. For example, a mobile phone can simultaneously connect to a mouse, keyboard, and headphones via Bluetooth.

[0089] Based on the Bluetooth connection between the first and second Bluetooth modules, applications in the first device can transmit data with applications in the second device. Taking the application installed on the first device as the first application and the application installed on the second device as the second application as an example, before the first application and the second application can transmit data, the first and second devices must first establish a low-level Bluetooth connection; that is, the first Bluetooth module in the first device and the second Bluetooth module in the second device need to establish a Bluetooth link connection. The first and second Bluetooth modules need to exchange some information (such as Bluetooth parameters) to establish the link connection. After the connection between the Bluetooth modules is established, the first application and the second application can achieve application-level connection through the exchange of some information. Figure 3a In the scenario shown, the phone's Bluetooth and the bracelet's Bluetooth first establish a Bluetooth connection, and then the fitness app and the bracelet's app connect through the transmission of some data.

[0090] In some implementations, the first and second Bluetooth modules can establish a Bluetooth connection through an MTU negotiation process. MTU represents the maximum amount of data a device can transmit in a single data packet (such as a Protocol Data Unit (PDU)). In other words, MTU represents the maximum number of bytes a device can transmit to the other device at once. During Bluetooth communication, different devices may have different MTUs due to differences in their communication capabilities.

[0091] The MTU value is typically determined by the hardware and software implementation of a device. The MTU size directly impacts the efficiency and performance of data transmission between two devices. A larger MTU improves data transmission efficiency because each data packet can carry more data. Conversely, a smaller MTU reduces latency because data can be segmented into smaller packets for transmission more quickly.

[0092] Through MTU negotiation, the first and second devices can transmit data based on the negotiated MTU to ensure smooth data transmission. This negotiation process ensures that data packets sent by the upper-layer application do not exceed the carrying capacity of the underlying Bluetooth layer, thereby avoiding data loss or communication interruption.

[0093] The following is combined Figure 4 The MTU negotiation process of the first Bluetooth module and the second Bluetooth module is introduced.

[0094] See Figure 4In step S410, the second Bluetooth module sends an MTU request to the first Bluetooth module. This MTU request may include the MTU that the second Bluetooth module can carry (or supports), denoted as MTU1. MTU1 can also be understood as the MTU that the second device can carry. Taking a wristband as an example, MTU1 can be 247 bytes.

[0095] In step S420, in response to the MTU request, the first Bluetooth module sends an MTU response to the second Bluetooth module. After the first Bluetooth module sends the MTU response to the second Bluetooth module, the connection between the first Bluetooth module and the second Bluetooth module is established. Upon receiving the MTU request, the first Bluetooth module can determine the size of the MTU that the second Bluetooth module can support.

[0096] The first Bluetooth module can determine the MTU required for communication between the two parties based on MTU1 and the MTU it can support.

[0097] Typically, the MTU response includes MTU1. That is, the MTU in the MTU response includes the MTU carried in the MTU request. Including MTU1 in the MTU response also indicates that the first Bluetooth module supports MTU1, meaning the first Bluetooth module can transmit data packets of MTU1 size.

[0098] After receiving the MTU response, the second Bluetooth module can determine that the negotiated MTU value is MTU1. In other words, after the above process, the MTU negotiated by the first and second Bluetooth modules is MTU1.

[0099] It should be noted that the above description is only based on the example of the second Bluetooth module sending an MTU request and the first Bluetooth module sending an MTU response. Of course, the MTU negotiation process can also be that the first Bluetooth module sends an MTU request to the second Bluetooth module and the second Bluetooth module sends an MTU response to the first Bluetooth module. This application embodiment does not specifically limit this.

[0100] After the underlying Bluetooth connection is established, upper-layer applications can establish connections. The following section will combine... Figure 5 This section introduces the process of establishing connections between upper-layer applications.

[0101] See Figure 5 In step S430, the second application obtains the MTU stored in the second Bluetooth module through the MTU callback function. This MTU callback function is the onMtuchanged callback function.

[0102] In step S440, the second application determines the MTU required for data transmission with the first application, denoted as MTU2. MTU2 can be determined based on MTU1 and the default (or outlier) MTU value in the second application. MTU2 can be the smaller of MTU1 and the default MTU value. For example, if MTU1 is 247 bytes and the default MTU value is 260 bytes, then MTU2 is 247 bytes.

[0103] In step S450, the second application sends MTU2 to the first application. The second application may send MTU2 to the second Bluetooth module, which then sends MTU2 to the first Bluetooth module, which in turn sends MTU2 to the first application.

[0104] In step S460, the first application can segment the data to be transmitted based on MTU2 and send the segmented data packets to the first Bluetooth module.

[0105] Taking an MTU of 247 bytes as an example, the first application can segment the data into units of 247 bytes. That is, one data packet occupies 247 bytes. It should be noted that in the data packet sent by the first application, one byte is the type opcode and two bytes are the type op handle. Therefore, the actual data carried in the 247-byte data packet is 244 bytes. In other words, the actual transmitted data is the MTU value minus 3 bytes. Therefore, the first application can segment the data to be sent into a size of (MTU2-3) bytes, encapsulate the segmented data into data packets, and the final size of the encapsulated data packets is MTU2.

[0106] The first Bluetooth module can detect the data packets sent by the first application and determine whether the size of the data packet exceeds the MTU stored in the Bluetooth protocol stack. The MTU stored in the Bluetooth protocol stack is the MTU negotiated between the first Bluetooth module and the second Bluetooth module. In this embodiment, the MTU stored in the Bluetooth protocol stack is 247 bytes, and the size of the data packet received by the first Bluetooth module is also 247 bytes. Therefore, the first Bluetooth module can directly send the received data packet to the second Bluetooth module.

[0107] In step S470, the first Bluetooth module sends the segmented data packets to the second Bluetooth module.

[0108] In step S480, the second Bluetooth module verifies the received data.

[0109] In step S490, if the verification is successful, the second Bluetooth module sends a response message to the first Bluetooth module, indicating that the verification was successful. The verification performed by the second Bluetooth module may include, for example, integrity verification or CRC verification.

[0110] If the second Bluetooth module verification is successful, it means that the connection between the first application and the second application has been established, and the first application and the second application can transmit data through the Bluetooth connection.

[0111] The following example illustrates the Bluetooth connection process between a mobile phone and a fitness tracker. The mobile phone has a fitness tracker app installed, and the fitness tracker has a fitness tracker app installed.

[0112] See Figure 6 In step S610, the wristband Bluetooth sends MTU1 to the mobile phone Bluetooth, MTU1 = 247 bytes.

[0113] In step S620, the mobile phone Bluetooth sends an MTU1 response to the wristband Bluetooth.

[0114] In step S630, the bracelet APP obtains the MTU1 in the bracelet's Bluetooth through the onMtuchanged function.

[0115] In step S640, the wristband app determines the smaller value, MTU2, between MTU1 and 260. MTU2 = min(247, 260) = 247 bytes. Here, 260 is the default MTU value in the wristband app.

[0116] In step S650, the wristband APP sends MTU2 to the sports and health APP.

[0117] In step S660, the sports and health app segments the data using MTU2 and sends the segmented data to the phone via Bluetooth. The length of the segmented data packet is MTU2.

[0118] In step S670, the mobile phone's Bluetooth sends data to the wristband's Bluetooth.

[0119] In step S680, the wristband's Bluetooth verifies the data.

[0120] In step S690, if the verification is successful, the wristband Bluetooth sends a verification success response message to the mobile phone Bluetooth.

[0121] However, some versions, such as Android 14, use a new BLE negotiation MTU strategy. During MTU interaction, the local device defaults to sending the maximum MTU. This new MTU interaction strategy causes some apps to experience malfunctions when interacting with the peer Bluetooth device. Analysis by the inventors revealed that the main reason is that the MTU obtained by the upper-layer application is inconsistent with the MTU that the underlying Bluetooth can support. When the data packet length sent by the upper-layer application exceeds the MTU that the underlying Bluetooth can support, the Bluetooth protocol stack determines that the data packet is too long and prunes it before sending. The resulting data packet received by the peer device is not a complete data packet, fails the integrity check, and therefore cannot respond to the data packet, leading to functional abnormalities.

[0122] The following is combined Figure 7 The causes of the above problems will be described in detail. Figure 7 The MTU negotiation process shown can be understood as a new negotiation process. Figure 5 and Figure 6 The MTU negotiation process shown can be understood as the old negotiation process. Figure 7 Using mobile phones and smartwatches as examples, the above issues will be explained.

[0123] See Figure 7 In step S710, the wristband's Bluetooth sends an MTU request to the phone's Bluetooth. This MTU request carries the maximum MTU that the wristband's Bluetooth can support, denoted as MTU1.

[0124] In step S720, in response to the MTU request, the mobile phone Bluetooth sends an MTU response to the wristband Bluetooth. This MTU response carries the maximum MTU that the mobile phone Bluetooth can support, denoted as MTU3.

[0125] Through MTU requests and responses, the Bluetooth devices on the phone and wristband can determine the negotiated MTU value. The negotiated MTU value is the smaller of MTU1 and MTU3. For example, if MTU1 is 247 bytes and MTU3 is 517 bytes, then the negotiated MTU value is 247 bytes, and the Bluetooth protocol stack can only support an MTU of 247 bytes.

[0126] It should be noted that in the old MTU negotiation process, the MTU carried in the MTU response was the MTU carried in the MTU request, i.e., MTU1. However, in the new MTU negotiation process, the MTU carried in the MTU response is the maximum MTU that the mobile phone's Bluetooth can support, i.e., MTU3. This will result in MTU1 and MTU3 being unequal.

[0127] In step S730, the bracelet app obtains the MTU3 from the bracelet's Bluetooth.

[0128] In step S740, the band app determines MTU2. MTU2 is the MTU required for data transmission between the band app and the fitness app. MTU2 can be determined based on MTU3 and the default MTU value in the band app. MTU2 can be the smaller value between MTU3 and the default MTU value. For example, if MTU3 is 517 bytes and the default MTU value is 260 bytes, then MTU2 is 260 bytes.

[0129] In step S750, the band app sends MTU2 to the fitness app. The band app can send MTU2 to the band's Bluetooth, the band's Bluetooth sends MTU2 to the phone's Bluetooth, and the phone's Bluetooth then sends MTU2 to the fitness app.

[0130] In step S760, the sports and health APP can segment the data to be sent based on MTU2 and send the segmented data packets to the mobile phone via Bluetooth.

[0131] Taking an MTU of 247 bytes for MTU1, 517 bytes for MTU3, and a default MTU of 260 bytes as an example, the MTU2 determined by the fitness tracker app is 260 bytes. Therefore, the data packet length sent by the fitness tracker app to the phone via Bluetooth is 260 bytes.

[0132] In step S770, after receiving the data packet, the mobile phone's Bluetooth system detects the data packet. The mobile phone's Bluetooth system can detect the data packet based on MTU1. The MTU that the mobile phone's Bluetooth protocol stack can carry is 247 bytes, and the length of the data packet exceeds the MTU that the protocol stack can carry. Therefore, the mobile phone's Bluetooth system will prune the data packet, discarding the portion of the data packet that exceeds 247 bytes, so that the length of the pruned data packet is 247 bytes.

[0133] In step S780, the mobile phone's Bluetooth sends the trimmed data packet to the wristband's Bluetooth.

[0134] In step S790, the wristband's Bluetooth verifies the received data packet. Because the data packet was trimmed by the phone's Bluetooth, the trimmed data packet is not a complete data packet. Therefore, the trimmed data packet cannot pass the integrity check, and the wristband's Bluetooth determines that the verification has failed.

[0135] In step S795, the bracelet's Bluetooth sends a response message to the phone's Bluetooth, indicating that the verification failed. Therefore, the fitness app and the bracelet app cannot connect, and data transmission is impossible.

[0136] Currently, the MTU1 negotiated by the Bluetooth protocol stack on the mobile phone side is not actively reported to the application side (such as a fitness app). The application side obtains the MTU of the Bluetooth protocol stack from the other end, the wristband. After the mobile phone and wristband establish an asynchronous connectionless (ACL) link and exchange GATT MTU commands, the wristband uploads the MTU to the mobile phone's application side layer by layer from the Bluetooth chip and Bluetooth protocol stack. The problem with this is that the MTU2 reported by the wristband to the mobile phone application side may be abnormal and mismatched with the MTU1 in the Bluetooth protocol stack, leading to communication failures.

[0137] from Figure 7 As shown in the flowchart, the MTU1 obtained by the mobile phone via Bluetooth is 247 bytes, while the MTU2 reported by the wristband to the mobile app is 260 bytes. When the data packet sent by the mobile app is longer than 247 bytes but shorter than 260 bytes, the data packet is truncated when sent to the Bluetooth protocol stack, and the data packet sent by the Bluetooth protocol stack to the wristband is the truncated data packet. Therefore, when the MTU negotiation strategy changes, i.e., when the MTU response carries the maximum MTU it can carry, the MTU received by the application side will be inconsistent with the MTU that the Bluetooth side can carry. In particular, when the MTU received by the application side is larger than the MTU that the Bluetooth side can carry, it will cause the verification to fail, and the applications at both ends will be unable to transmit data.

[0138] Under the current MTU interaction mechanism, the Bluetooth module (or Bluetooth protocol stack) will not actively report the negotiated MTU value, which can lead to the problems described above in certain scenarios.

[0139] The following example uses a mobile phone as the first device and a smart band as the second device to illustrate the above issues through log analysis.

[0140] Bracelet log such as Figure 8 As shown, by analyzing the bracelet logs, we can see that there are verification failures printed.

[0141] A comparison with the Bluetooth host control interface (HCI) logs on the mobile phone side confirmed that the 0103 data packet sent by the mobile phone failed verification. Figure 9 As shown. If the verification fails, the data will be discarded by the wristband.

[0142] By parsing the contents of the 0103 data packet, the cause of the problem was investigated. The parsed data packet was found to be 249 bytes long, while the HCI only contains 244 bytes. Figure 10 As shown, this confirms that the length of the data packet is abnormal.

[0143] Continue checking the phone's application logs (aplog) and see things like... Figure 11 The problem description is shown.

[0144] Code analysis reveals that this log indicates Bluetooth truncated the data being written by the application because the data length exceeded the MTU size limit. In the BLE connection process, the MTU is negotiated in the first step, and normally the application should not send data packets exceeding the MTU size.

[0145] By studying the data interaction specifications of smart wearable devices, it was observed that the MTU is negotiated in the first business instruction 0101. The data format is tag-length-value (TLV). The negotiated MTU value is 0104 = 260 bytes, which is greater than the Bluetooth negotiated MTU of 247 bytes. Figure 12 As shown.

[0146] The above example illustrates the problem of connection failure between applications using a mobile phone and a smart band as an example, but the embodiments of this application are not limited to this scenario. The embodiments of this application can be applied to any scenario where two devices communicate via Bluetooth. For example, the embodiments of this application can be applied to a scenario where a mobile phone communicates with a vehicle via Bluetooth, and some in-vehicle apps also exhibit the aforementioned problem after using the new MTU interaction strategy. For example, ... Figure 13 As shown, when a car app uses a Bluetooth car key, the app expects to receive an MTU of 180 bytes. However, under the new MTU negotiation strategy, the app receives an MTU of 251 bytes, causing the app's internal parameter interaction to fail and preventing the execution of the subsequent unlocking process.

[0147] To address the aforementioned issues, this application provides a data transmission method and device. After receiving the MTU negotiation value sent by the peer, the application side obtains the MTU stored in the Bluetooth module from its own Bluetooth module and determines a suitable MTU based on these two MTUs to segment the data. This ensures that the segmented data does not exceed the MTU that the Bluetooth protocol stack can carry, thereby guaranteeing that when the data packets sent by the upper-layer application reach the lower-layer Bluetooth module, the Bluetooth module can completely send the data packets to the peer device. This avoids the problem of application-side connection failure leading to the inability to transmit data.

[0148] The following is combined Figure 14 The data transmission method provided in the embodiments of this application will be described in detail. Figure 14The data transmission method illustrated is described from the perspective of interaction between the first device and the second device. The first device and the second device can be any of the Bluetooth-enabled devices mentioned above. In some implementations, the first device can be a mobile phone and the second device can be a smart bracelet. In other implementations, the first device can be a mobile phone and the second device can be a vehicle.

[0149] The first device has a first application installed, which can be a fitness and health app or a remote control app, etc. The second device has a second application installed, which can be a fitness tracker app or a car app, etc.

[0150] The first device includes a first Bluetooth module, and the second device includes a second Bluetooth module. A first application can communicate with a second application in the second device via the first Bluetooth module. In some implementations, the first and second Bluetooth modules can first establish a Bluetooth connection, and then the first and second applications can transmit data via Bluetooth. Both the first and second Bluetooth modules can be Bluetooth chips.

[0151] See Figure 14 In step S1410, the second application sends a first MTU to the first application. The first MTU is the MTU determined by the second application for data transmission, or in other words, the first MTU can be the MTU determined by the second application for data transmission between applications. For example, the first MTU can be MTU2 as mentioned above.

[0152] In step S1420, the first application obtains the second MTU from the first Bluetooth module. The second MTU is the MTU obtained after the first Bluetooth module and the second Bluetooth module negotiate the MTU. The first Bluetooth module can store the negotiated MTU in the first Bluetooth module. In some implementations, the first Bluetooth module can update the stored MTU value to the second MTU. The second MTU can be, for example, MTU1 mentioned above.

[0153] This application does not specifically limit the method by which the first application obtains the second MTU. As an example, the first application can actively obtain the second MTU, which can avoid causing significant overhead to the first Bluetooth module. In scenarios where the first device has many applications installed, the first Bluetooth module may not know which application to send the second MTU to; if the first Bluetooth module sends the second MTU to all applications, it will cause unnecessary waste and incur significant overhead to the first Bluetooth module.

[0154] In some implementations, the first application can obtain the second MTU from the first Bluetooth module through a public interface. This public interface serves as the interface between the first application and the first Bluetooth module. This interface can be an application programming interface (API).

[0155] In some implementations, the first application can obtain the second MTU from the first Bluetooth module via a callback function. This callback function can be the `onMtuChanged` function. For example, the callback function could be `BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt, int mtu, int status)`. By actively obtaining the second MTU by calling the callback function, the first application can determine which MTUs to obtain from the first Bluetooth module, thus avoiding unnecessary transmission overhead. Furthermore, reusing the `onMtuChanged` function to obtain the second MTU reduces the complexity of obtaining it.

[0156] In some implementations, the first application can determine whether it needs to obtain the second MTU from the first Bluetooth module based on information from the second device. After the first and second Bluetooth modules are connected, the first application can obtain information about the second device. If the second device is closely associated with the first application, the first application obtains the second MTU from the first Bluetooth module.

[0157] As another example, the first application can passively acquire the second MTU, meaning the first Bluetooth module can send the second MTU to the first application. After determining the second MTU, the first Bluetooth module can actively send the second MTU to the first application. To reduce the communication overhead of the first Bluetooth module, it can determine which applications need to acquire the second MTU based on first information; or, in other words, it can determine which applications need to have the second MTU sent to based on the first information. The first information may include one or more of the following: information about the first application, the association between the application and the second device, and information about the second device. Using this first information, the first Bluetooth module can determine whether the first application needs information from the first device, thereby determining whether to send the second MTU to the first application.

[0158] For example, if the second device is a wristband and the first device is a mobile phone, and the first device has a fitness and health app and an app for remotely controlling a vehicle installed, the first Bluetooth module does not need to send the second MTU to the remote control app because the wristband is unrelated to the vehicle remote control app, or in other words, the wristband does not contain vehicle-related information. However, since the wristband is related to the fitness and health app, or in other words, the wristband stores fitness and health-related information, the first Bluetooth module can send the second MTU to the fitness and health app.

[0159] This application does not specifically limit the timing of the first application acquiring the second MTU. As an example, the first application can acquire the second MTU from the first Bluetooth module after receiving the first MTU sent by the second application. In other words, in response to receiving the first MTU, the first application acquires the second MTU from the first Bluetooth module. This reduces the overhead of the first device and helps save power. As another example, the first application can periodically acquire the second MTU from the first Bluetooth module. This ensures that the first application can be aware of MTU updates in a timely manner, thereby quickly determining the target MTU and reducing the data transmission delay between the first and second applications.

[0160] In step S1430, the first application determines the target MTU based on the first MTU and the second MTU.

[0161] The target MTU is less than or equal to the first MTU, and the target MTU is less than or equal to the second MTU; in other words, the target MTU is less than or equal to the smaller of the first MTU and the second MTU. This ensures that the target MTU does not exceed the MTU that the Bluetooth protocol stack can support, thereby preventing data transmission failures or connection failures.

[0162] In some implementations, the target MTU can be equal to the smaller of the first MTU and the second MTU. The first application can determine the smaller of the first MTU and the second MTU and then use that smaller value as the target MTU. For example, if the first MTU is less than the second MTU, the target MTU is the first MTU; if the first MTU is greater than the second MTU, the target MTU is the second MTU. In this way, the first application only needs to compare the first MTU and the second MTU to determine the target MTU, thereby reducing the computational overhead of the first application. In addition, the target MTU determined by the first application is the maximum MTU within the underlying Bluetooth bearer capability range of both the first and second devices, thereby improving data transmission efficiency. In other implementations, the target MTU can be less than the smaller of the first MTU and the second MTU.

[0163] For example, if the first MTU is 260 bytes and the second MTU is 247 bytes, then the target MTU is 247 bytes. If the first MTU is 251 bytes and the second MTU is 180 bytes, then the target MTU is 180 bytes.

[0164] The above process can also be understood as a calibration process of the first MTU by the first application. In related technologies, the first application directly uses the first MTU for data transmission. However, in this embodiment, the first application can calibrate the first MTU based on the second MTU, and the calibrated first MTU is the target MTU. The first application can then perform data transmission based on the target MTU.

[0165] In step S1440, the first application sends data to the second application based on the target MTU.

[0166] In some implementations, the first application can utilize the target MTU to segment the data to be transmitted and send the segmented data to the second application via a first Bluetooth module and a second Bluetooth module. For example, the first application can segment the data according to the length of the target MTU, ensuring that the length of the segmented data packet does not exceed the target MTU. If the target MTU is 247 bytes, the first application can segment the data to a length of 247 bytes, ensuring that the segmented data packet does not exceed 247 bytes. By segmenting the data according to the target MTU, the first application ensures that the data sent to the second application does not exceed the carrying capacity of either the underlying Bluetooth of the first or second device. This allows the first Bluetooth module to send the data completely to the second device, facilitating smooth data transmission.

[0167] In some implementations, considering that one byte in the data packet is the type opcode and two bytes are the type operation handle, the first application can segment the data according to a length of (target MTU - 3 bytes) and encapsulate the segmented data into a data packet. This ensures that the length of the final generated data packet will not exceed the target MTU. For example, if the target MTU is 247 bytes, the first application can segment the data into 244-byte segments.

[0168] For example, if the length of the data to be sent in the first application is 1000 bytes and the target MTU is 247 bytes, then the first application can transmit a maximum of 244 bytes of data at a time. Therefore, the 1000 bytes of data need to be divided into 5 data packets for transmission. In the first 4 data packets, each data packet carries 244 bytes of data, and the last data packet carries 24 bytes of data.

[0169] The technical solution provided in this application does not directly use the first MTU as the target MTU, but instead takes the smaller value of the first MTU and the second MTU, and segments the data based on the smaller value. This ensures that the generated data packets will not exceed the maximum MTU that the Bluetooth protocol stack can carry, which is beneficial to ensuring normal data transmission.

[0170] In some implementations, before the first application obtains the second MTU from the first Bluetooth module, the first and second Bluetooth modules can negotiate the MTU to determine the second MTU. The MTU negotiation process between the first and second Bluetooth modules is described below.

[0171] See Figure 15 In step S1402, the second Bluetooth module sends a third MTU to the first Bluetooth module. The third MTU is the MTU that the second Bluetooth module can carry.

[0172] In step S1406, the first Bluetooth module determines the second MTU based on the third MTU and the fourth MTU. The fourth MTU is the MTU that the first Bluetooth module can support. In other words, the first Bluetooth module can determine the second MTU based on its own maximum support MTU and the maximum support MTU of the second Bluetooth module, ensuring that the second MTU does not exceed the maximum support MTU of either the first or the second Bluetooth module, thus facilitating smooth data transmission.

[0173] The second MTU can be the smaller of the third MTU and the fourth MTU. For example, if the third MTU is less than the fourth MTU, then the second MTU is the third MTU; if the third MTU is greater than the fourth MTU, then the second MTU is the fourth MTU. Of course, in some embodiments, the second MTU can be less than the smaller of the third MTU and the fourth MTU, as long as the second MTU does not exceed the maximum MTU that the first Bluetooth module and the second Bluetooth module can support.

[0174] In some implementations, Figure 15 The method shown may further include steps S1404 and S1408. In step S1404, the first Bluetooth module sends a fourth MTU to the second Bluetooth module. In step S1408, the second Bluetooth module can determine a second MTU based on the third and fourth MTUs. Through MTU interaction, the first Bluetooth module and the second Bluetooth module can determine the same second MTU.

[0175] In some implementations, MTU exchange can be achieved through MTU requests and responses. Exchanging the MTU via these requests and responses reduces the complexity of MTU switching. The MTU request can be initiated by either the first or second Bluetooth module; this embodiment does not specifically limit this. For example, the second Bluetooth module can send an MTU request to the first Bluetooth module, which includes a third MTU. In response to this MTU request, the first Bluetooth module sends an MTU response to the second Bluetooth module, which includes a fourth MTU. As another example, the first Bluetooth module can send an MTU request to the second Bluetooth module, which includes a fourth MTU. In response to this MTU request, the second Bluetooth module can send an MTU response to the first Bluetooth module, which includes a third MTU.

[0176] The solution proposed in this application can be applied to both new and old MTU negotiation strategies. In other words, the solution proposed in this application can be used regardless of whether the MTU response carries the maximum MTU supported by the Bluetooth module.

[0177] In some implementations, the second application can obtain the second MTU from the second Bluetooth module, or the second Bluetooth module can send the second MTU to the second application. The second application can determine the first MTU based on the second MTU and the default MTU value in the second application. Taking a wristband app as an example, the default MTU value is 260. The second application can use the smaller of the second MTU and the default MTU value as the first MTU. If the second MTU is less than the default MTU value, then the first MTU is the second MTU; if the second MTU is greater than the default MTU value, then the first MTU is the default MTU value. After obtaining the first MTU, the second application can send the first MTU to the first application.

[0178] As mentioned earlier, after determining the target MTU, the first application can segment the data to be transmitted using the target MTU. Furthermore, after obtaining the segmented data, the first application can also send the segmented data to the second application via the first Bluetooth module and the second Bluetooth module.

[0179] In some possible implementations, the first application can send segmented data to the first Bluetooth module. Upon receiving the segmented data, the first Bluetooth module can verify it to ensure successful data transmission. If the verification passes, the first Bluetooth module can then send the segmented data to the second application via the second Bluetooth module.

[0180] The first Bluetooth module can verify the segmented data based on the second MTU. The first Bluetooth module can determine whether the length of the segmented data exceeds the value of the second MTU. If the length of the segmented data does not exceed the value of the second MTU, the first Bluetooth module determines that the segmented data has passed verification. By using the second MTU to verify the data sent by the first application, the first Bluetooth module can prevent the length of the data sent by the first application from exceeding the second MTU that the first Bluetooth module can handle, thus avoiding communication failures.

[0181] In some implementations, sending segmented data from the first Bluetooth module to the second application via the second Bluetooth module can mean that the first Bluetooth module sends segmented data to the second Bluetooth module, and the second Bluetooth module forwards the segmented data to the second application. After receiving the segmented data, the second Bluetooth module can verify the segmented data, such as performing integrity checks and / or CRC checks. It should be noted that verifying the segmented data can refer to verifying the segmented data packets.

[0182] The second Bluetooth module can send a response message to the first Bluetooth module based on the verification result. This response message is for the segmented data and can be used to indicate whether the segmented data was successfully verified. If the verification is successful, the second Bluetooth module can send a verification success response message to the first Bluetooth module; if the verification fails, the second Bluetooth module can send a verification failure response message to the first Bluetooth module.

[0183] If the response message indicates successful verification, the connection between the first application and the second application is established, and the two applications can then communicate further. If the response message indicates failed verification, the connection between the first application and the second application fails.

[0184] The solutions in this application are applicable to scenarios where two devices communicate via Bluetooth, as well as scenarios where multiple devices communicate via Bluetooth simultaneously. For example, a first device can communicate with multiple devices via Bluetooth simultaneously. Taking a mobile phone as an example, a mobile phone can communicate with a Bluetooth headset, a Bluetooth mouse, and a Bluetooth keyboard simultaneously. As another example, a mobile phone can communicate with headphones, a smart bracelet, a car, etc., simultaneously.

[0185] The first device communicating with multiple devices simultaneously via Bluetooth means that the first device can maintain Bluetooth connections with multiple devices. In this scenario, the first device can only send data to and / or receive data from one device at a time, or the first device can send data to and / or receive data from multiple devices at the same time. The first device sending data to multiple devices simultaneously can mean that the first device sends the same data to multiple devices at the same time.

[0186] If the first device communicates with multiple devices via Bluetooth simultaneously, the first Bluetooth module can negotiate MTU values ​​with these devices. The MTU values ​​negotiated by the first Bluetooth module with different devices can be the same or different.

[0187] The first Bluetooth module can store the correspondence between connected devices and their MTU negotiation values, and this correspondence can be stored in a list format. For example, the first Bluetooth module can store the correspondence shown in Table 1.

[0188] Table 1

[0189] Connected device MTU negotiation value Device 1 MTUa Device 2 MTUb Device 3 MTUc

[0190] Based on the correspondence shown in Table 1, when the first device sends data to a certain device, it can use the MTU corresponding to that device to segment the data to be sent. For example, when the first device communicates with device 1, it can use MTUa to segment the data; when the first device communicates with device 2, it can use MTUb to segment the data; and when the first device communicates with device 3, it can use MTUc to segment the data.

[0191] After the first Bluetooth module connects to multiple devices, the application in the first device can obtain the MTU negotiation value corresponding to the connected devices. As mentioned above, the application in the first device can actively obtain the MTU negotiation value corresponding to the connected devices, or it can passively obtain the MTU negotiation value corresponding to the connected devices.

[0192] In some implementations, the application in the first device can determine whether it needs to obtain the MTU negotiation value corresponding to the connected devices based on the information of the connected devices. Taking application 1 in the first device as an example, if application 1 determines that device 1 and device 2 are closely related to application 1 based on the information of the connected devices, then application 1 can obtain MTUa and MTUb.

[0193] In some implementations, the first Bluetooth module can determine which applications to send which devices' MTU negotiation values ​​to, based on the first information described above. The MTU negotiation values ​​sent by the first Bluetooth module to different applications can be the same or different. For example, if the first Bluetooth module determines, based on the first information, that application 2 is closely related to devices 1 and 3, then the first Bluetooth module can send MTUa and MTUc to application 2. As another example, if the first Bluetooth module determines, based on the first information, that application 3 is closely related to device 2, then the first Bluetooth module can send MTUb to application 3.

[0194] The foregoing has detailed examples of the methods provided in this application. It is understood that the corresponding apparatus, in order to achieve the above functions, includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0195] This application can divide the data transmission device into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0196] The following is combined Figures 16-17 The following describes the device embodiments of this application. It should be noted that the device embodiments correspond to the method embodiments, and any content not described in detail can be found in the method embodiments.

[0197] Figure 16 This is a schematic block diagram of a device provided in an embodiment of this application. Figure 16 The device 1600 shown is a first device. A first application is installed on the first device, and the first device includes a first Bluetooth module. The first application is used to communicate with a second application in a second device through the first Bluetooth module. The second device includes a second Bluetooth module.

[0198] Figure 16 The device 1600 shown may include a receiving module 1610, an acquiring module 1620, a determining module 1630, and a sending module 1640.

[0199] The receiving module 1610 is used to receive a first maximum transmission unit (MTU) sent by the second application using the first application. The first MTU is the MTU that the second application determines is needed for data transmission.

[0200] The acquisition module 1620 is used to acquire a second MTU from the first Bluetooth module using the first application. The second MTU is the MTU obtained after the first Bluetooth module and the second Bluetooth module negotiate the MTU.

[0201] The determining module 1630 is used to determine a target MTU based on the first MTU and the second MTU using the first application, wherein the target MTU is less than or equal to the first MTU and the target MTU is less than or equal to the second MTU.

[0202] The sending module 1640 is used to send data to the second application based on the target MTU using the first application.

[0203] In some possible implementations, the determining module 1630 is configured to: determine the smaller of the first MTU and the second MTU using the first application, and use the smaller value as the target MTU using the first application.

[0204] In some possible implementations, the acquisition module 1620 is used to: obtain the second MTU from the first Bluetooth module by calling the MTU callback function using the first application.

[0205] In some possible implementations, the callback function is BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt, int mtu, int status).

[0206] In some possible implementations, before the acquisition module 1620 acquires the second MTU from the first Bluetooth module using the first application, the receiving module 1610 is further configured to: receive a third MTU sent by the second Bluetooth module using the first Bluetooth module, wherein the third MTU is the MTU that the second Bluetooth module can carry; the determining module 1630 is further configured to: determine the second MTU using the first Bluetooth module based on the third MTU and the fourth MTU, wherein the fourth MTU is the MTU that the first Bluetooth module can carry, and the second MTU is the smaller value between the third MTU and the fourth MTU.

[0207] In some possible implementations, the third MTU is carried in the MTU request, and the sending module 1640 is further configured to: in response to the MTU request, send an MTU response to the second Bluetooth module using the first Bluetooth module, wherein the MTU response includes the fourth MTU.

[0208] In some possible implementations, the device 1600 further includes a segmentation module for segmenting the data to be transmitted using the target MTU via the first application; the transmission module 1640 is used to transmit the segmented data to the second application via the first Bluetooth module and the second Bluetooth module using the first application.

[0209] In some possible implementations, the sending module 1640 is configured to: send the segmented data to the first Bluetooth module using the first application; the device 1600 further includes a verification module, configured to verify the segmented data using the second MTU via the first Bluetooth module; the sending module 1640 is configured to: if the segmented data is verified, send the segmented data to the second application via the second Bluetooth module using the first Bluetooth module.

[0210] In some possible implementations, the verification module is used to: use the first Bluetooth module to determine whether the length of the segmented data exceeds the value of the second MTU; if the length of the segmented data does not exceed the value of the second MTU, then use the first Bluetooth module to determine that the segmented data has passed verification.

[0211] In some possible implementations, the receiving module 1610 is used to receive a response message sent by the second Bluetooth module using the first Bluetooth module. The response message is a response to the segmented data and is used to indicate whether the segmented data has been successfully verified.

[0212] This application also provides a device including the processor described above. This device can be the first device described above, used to execute the data transmission method described above. When using integrated units, the first device may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the actions of the first device; for example, it can be used to support the first device in executing the steps performed by the receiving unit, the acquiring unit, the determining unit, and the sending unit. The storage module can be used to support the first device in executing stored program code and data. The communication module can be used to support communication between the first device and other devices.

[0213] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a digital signal processor (DSP), and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a WiFi chip, or other devices that interact with other devices.

[0214] In one embodiment, when the processing module is a processor and the storage module is a memory, the device involved in this embodiment can be a device having... Figure 1 The device with the structure shown.

[0215] Figure 17 This is a schematic structural diagram of the device according to an embodiment of this application. Figure 17 The dashed lines indicate that the unit or module is optional. The device 1700 can be used to implement the methods described in the above method embodiments. The device 1700 can be a chip, a first device, or a second device.

[0216] Apparatus 1700 may include one or more processors 1710. The processor 1710 may support apparatus 1700 in implementing the methods described in the preceding method embodiments. The processor 1710 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0217] The apparatus 1700 may further include one or more memories 1720. The memories 1720 store a program that can be executed by the processor 1710, causing the processor 1710 to perform the methods described in the preceding method embodiments. The memories 1720 may be independent of the processor 1710 or integrated within the processor 1710.

[0218] The device 1700 may also include a transceiver 1730. The processor 1710 can communicate with other devices or chips via the transceiver 1730. For example, the processor 1710 can send and receive data with other devices or chips via the transceiver 1730.

[0219] This application also provides a chip including a processor, which is used to read and execute a computer program stored in a memory to perform the data transmission method described in any of the above embodiments.

[0220] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the data transmission method described in any of the above embodiments.

[0221] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the data transmission method described in the above embodiments.

[0222] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0223] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units. The replaced units may or may not be physically separate. The component shown as a unit may be one physical unit or multiple physical units, that is, it may be located in one place or distributed in multiple different places. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0224] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0225] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0226] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0227] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method, characterized in that, The method is applied to a first device, which has a first application installed on it and includes a first Bluetooth module. The first application is used to communicate with a second application in a second device via the first Bluetooth module. The second device includes a second Bluetooth module. The method includes: The first Bluetooth module receives a maximum transmission unit (MTU) request sent by the second Bluetooth module. The MTU request includes a third MTU, which is the MTU that the second Bluetooth module can support. In response to the MTU request, the first Bluetooth module sends an MTU response to the second Bluetooth module, the MTU response including a fourth MTU, the fourth MTU being the MTU that the first Bluetooth module can carry; The first Bluetooth module determines the second MTU based on the third MTU and the fourth MTU, wherein the second MTU is the smaller value between the third MTU and the fourth MTU; The first application receives a first MTU sent by the second application. The first MTU is the MTU determined by the second application for data transmission. The first MTU is the smaller value between the default MTU in the second application and the fourth MTU. The fourth MTU is obtained by the second application from the second Bluetooth module through an MTU callback function. The first application obtains information about the second device; The first application determines whether it needs to obtain the second MTU from the first Bluetooth module based on the information from the second device; If it is necessary to obtain the second MTU from the first Bluetooth module, the first application obtains the second MTU from the first Bluetooth module by calling the MTU callback function. The second MTU is the MTU after the first Bluetooth module and the second Bluetooth module negotiate the MTU. The callback function is BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt,int mtu,int status). The first application determines a target MTU based on the first MTU and the second MTU, wherein the target MTU is less than or equal to the first MTU and the target MTU is less than or equal to the second MTU; The first application sends data to the second application based on the target MTU.

2. The method according to claim 1, characterized in that, The first application determines the target MTU based on the first MTU and the second MTU, including: The first application determines the smaller of the first MTU and the second MTU; The first application uses the smaller value as the target MTU.

3. The method according to claim 1 or 2, characterized in that, The first application sends data to the second application based on the target MTU, including: The first application uses the target MTU to segment the data to be transmitted; The first application sends segmented data to the second application through the first Bluetooth module and the second Bluetooth module.

4. The method according to claim 3, characterized in that, The first application sends segmented data to the second application via the first Bluetooth module and the second Bluetooth module, including: The first application sends the segmented data to the first Bluetooth module; The first Bluetooth module uses the second MTU to verify the segmented data; If the segmented data passes verification, the first Bluetooth module sends the segmented data to the second application via the second Bluetooth module.

5. The method according to claim 4, characterized in that, The first Bluetooth module uses the second MTU to verify the segmented data, including: The first Bluetooth module determines whether the length of the segmented data exceeds the value of the second MTU; If the length of the segmented data does not exceed the value of the second MTU, the first Bluetooth module determines that the segmented data has passed verification.

6. The method according to claim 3, characterized in that, The method further includes: The first Bluetooth module receives a response message sent by the second Bluetooth module. The response message is a response to the segmented data and is used to indicate whether the segmented data has been successfully verified.

7. A device, characterized in that, The device is a first device, the device includes a memory and a processor, the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method as described in any one of claims 1 to 6.

8. A chip, characterized in that, Includes a processor for reading and executing a computer program stored in a memory to perform the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method as described in any one of claims 1 to 6.

Images