Communication method and system, wearable device, electronic device and storage medium

Abstract

The invention provides a communication method and system, wearable equipment, electronic equipment and a storage medium, and relates to the technical field of communication. The wearable device communication method is applied to a master device in a wearable device communication system, and the method comprises the following steps: sending a beacon data packet which is used for performing frequency matching and time sequence synchronization with a slave device; in response to a received pairing request returned by the target slave device based on the beacon data packet, generating and sending confirmation information including a time window, so that the target slave device determines completion of pairing based on the confirmation information; wherein the time windows corresponding to the devices in the wearable device communication system are not overlapped, after pairing is completed, each device only sends data in the time window corresponding to the device, and each slave device keeps a dormant state in other time windows except the time window corresponding to the device and the time window corresponding to the master device; and after pairing is completed, data transmission with the target slave device is carried out through WiFi.

Description

Technical Field

[0001] The present application relates to the technical field of communications, and in particular to a communication method, system, wearable device, electronic device and storage medium. Background Art

[0002] With the development of technology, wearable devices such as smart AI (Artificial Intelligence) glasses have become widely used. However, in practical applications, the battery life of wearable devices is often insufficient, resulting in a poor user experience. Summary of the Invention

[0003] The present application provides a communication method, system, wearable device, electronic device and storage medium to alleviate the problem of insufficient battery life of existing wearable devices, resulting in a poor user experience.

[0004] In the first aspect, the present application provides a wearable device communication method, which is applied to a master device in a wearable device communication system, wherein the master device and the slave device in the wearable device communication system perform data transmission via WiFi, and the method comprises: sending a beacon data packet, wherein the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; in response to receiving a pairing request returned by a target slave device based on the beacon data packet, completing pairing with the target slave device based on the pairing request, generating and sending confirmation information including a time window, so that the target slave device determines that pairing is completed based on the confirmation information; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its corresponding time window, and each slave device remains in a dormant state in other time windows except its corresponding time window and the time window corresponding to the master device; after pairing is completed, data is transmitted with the target slave device via WiFi (mobile hotspot).

[0005] In the embodiment of the present application, during the pairing process between the master and slave devices, beacon data packets are also used to synchronize timing, thereby achieving timing synchronization between the slave and master devices. This prevents devices in the wearable device communication system from transmitting data simultaneously after the subsequent allocation of time windows. Furthermore, because each slave device remains dormant during all other time windows except for its own and the master device's corresponding time windows, this solution reduces device power consumption, improves device battery life, and enhances user experience, compared to existing solutions that require all devices to remain awake at all times.

[0006] In combination with the technical solution provided in the first aspect above, in some possible implementations, after the pairing is completed, the method further includes: responding to a security information packet including security information sent by the target slave device, determining whether the target slave device is a security device based on the security information; wherein, if it is determined that the target slave device is not a security device, disconnecting the pairing with the target slave device.

[0007] In an embodiment of the present application, the master device can use security information to confirm whether the slave device sending the security information packet is a security device, thereby realizing device security verification and improving the security of communication using this solution.

[0008] In combination with the technical solution provided in the first aspect above, in some possible implementations, the security information is a first hash value, and determining whether the target slave device is a security device based on the security information includes: obtaining historical communication information with the target slave device; generating a second hash value based on the historical communication information; determining whether the first hash value and the second hash value are consistent, and if they are consistent, determining that the target slave device is a security device.

[0009] In this embodiment of the present application, since the historical communication information between the master device and the target slave device is consistent, the hash values obtained by the master device and the slave device based on this same historical communication information are also the same. Therefore, the hash value obtained from the historical communication information can represent the identity of the master device, thereby enabling verification of the security device.

[0010] In combination with the technical solution provided in the first aspect above, in some possible implementations, generating a second hash value based on the historical communication information includes: inputting the historical communication information into a preset hash value generation model to obtain the second hash value; wherein the hash value generation model used by the slave device to generate the first hash value is the same as the hash value generation model used by the master device to generate the second hash value.

[0011] In an embodiment of the present application, the target slave device and the master device generate hash values through the same hash value generation model, thereby ensuring that the first hash value and the second hash value generated based on the same historical communication information are the same, thereby preventing the situation where the generated hash values are different due to different model parameters, and thus causing errors in security device verification.

[0012] In combination with the technical solution provided in the first aspect above, in some possible implementations, the confirmation information includes a parameter configuration selection table of a hash value generation model; the security information package also includes parameter selection information of the hash value generation model, and the parameter selection information is a configuration parameter type selected from the parameter configuration selection table; the method also includes: configuring the parameters of the preset hash value generation model based on the parameter selection information; accordingly, inputting the historical communication information into the preset hash value generation model to obtain the second hash value, including: inputting the historical communication information into the hash value generation model after parameter configuration to obtain the second hash value.

[0013] In an embodiment of the present application, by carrying parameter selection information of the hash value generation model in the security information packet, the slave device can configure the parameters of the model based on the parameter selection information, and at the same time return the parameter selection information to the master device, thereby ensuring that the hash value generation models used by the slave device and the master device to generate hash values are the same.

[0014] In combination with the technical solution provided in the first aspect above, in some possible implementations, the confirmation information includes security information, so that after the target slave device obtains the confirmation information, it also confirms whether the connected master device is a security device based on the security information in the confirmation information. If it is determined that the master device is not a security device, the pairing with the master device is disconnected.

[0015] In an embodiment of the present application, the target slave device can confirm whether the master device that sends the confirmation information is a secure device through security information, thereby realizing device security verification and improving the security of communication using this solution.

[0016] In a second aspect, the present application provides a wearable device communication method, which is applied to a slave device in a wearable device communication system, wherein the slave device and the master device in the wearable device communication system transmit data via WiFi, and the method includes: receiving a beacon data packet sent by the master device, and performing frequency matching and timing synchronization based on the beacon data packet; generating and sending a pairing request in response to the received beacon data packet sent by the master device; determining that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device only sends data in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device; after pairing is completed, data is transmitted with the master device via WiFi.

[0017] In the embodiment of the present application, during the pairing process between the master and slave devices, beacon data packets are also used to synchronize timing, thereby achieving timing synchronization between the slave and master devices. This prevents devices in the wearable device communication system from transmitting data simultaneously after the subsequent allocation of time windows. Furthermore, because each slave device remains dormant during all other time windows except for its own and the master device's corresponding time windows, this solution reduces device power consumption, improves device battery life, and enhances user experience, compared to existing solutions that require all devices to remain awake at all times.

[0018] In combination with the technical solution provided in the second aspect above, in some possible implementations, the confirmation information includes security information, and the method further includes: confirming whether the connected main device is a security device based on the security information in the confirmation information; and disconnecting the pairing with the main device if it is determined that the main device is not a security device.

[0019] In the embodiment of the present application, the slave device can confirm whether the master device that sends the confirmation information is a secure device through security information, thereby realizing device security verification and improving the security of communication using this solution.

[0020] In combination with the technical solution provided in the second aspect above, in some possible implementations, the security information includes a third hash value, and the confirmation of whether the connected main device is a security device based on the security information in the confirmation information includes: obtaining historical communication information with the main device; generating a fourth hash value based on the historical communication information; determining whether the third hash value and the fourth hash value are consistent, and if they are consistent, determining that the main device is a security device.

[0021] In this embodiment of the present application, since the historical communication information between the master device and the target slave device is consistent, the hash values obtained by the master device and the slave device based on this same historical communication information are also the same. Therefore, the hash value obtained from the historical communication information can represent the identity of the slave device, thereby enabling the determination of the security device.

[0022] In combination with the technical solution provided in the second aspect above, in some possible implementations, generating a fourth hash value based on the historical communication information includes: inputting the historical communication information into a preset hash value generation model to obtain the fourth hash value; wherein, the hash value generation model used by the slave device to generate the fourth hash value is the same as the hash value generation model used by the master device to generate the third hash value.

[0023] In an embodiment of the present application, the slave device and the master device generate hash values through the same hash value generation model, thereby ensuring that the third hash value and the fourth hash value generated based on the same historical communication information are the same, thereby preventing the situation where the hash values generated are different due to different model parameters, and thus causing errors in security device verification.

[0024] In combination with the technical solution provided in the second aspect above, in some possible implementations, the confirmation information includes parameter selection information of a hash value generation model, and the method further includes: configuring the parameters of a preset hash value generation model based on the parameter selection information; accordingly, inputting the historical communication information into the preset hash value generation model to obtain the fourth hash value, including: inputting the historical communication information into the hash value generation model after parameter configuration to obtain the fourth hash value.

[0025] In an embodiment of the present application, by carrying parameter selection information of the hash value generation model in the confirmation information, the slave device can configure the parameters of the model based on the parameter selection information, thereby ensuring that the hash value generation models used by the slave device and the master device to generate hash values are the same.

[0026] In combination with the technical solution provided in the second aspect above, in some possible implementations, after determining that the pairing is completed, the method further includes: sending a security information package including security information, so that the master device determines whether the slave device is a security device based on the security information; and if it is determined that the slave device is not a security device, disconnecting the pairing with the master device.

[0027] In an embodiment of the present application, the master device can use security information to confirm whether the slave device sending the security information packet is a security device, thereby realizing device security verification and improving the security of communication using this solution.

[0028] In a third aspect, the present application provides a wearable device communication device, which is deployed in a master device of a wearable device communication system, and the master device and the slave device in the wearable device communication system transmit data via WiFi. The wearable device communication device includes: a first communication module and a first processing module, the first communication module is used to send a beacon data packet, and the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; the first processing module is used to generate and send confirmation information including a time window in response to receiving a pairing request returned by the target slave device based on the beacon data packet, so that the target slave device determines that the pairing is completed based on the confirmation information; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device; the first processing module is also used to transmit data with the target slave device via WiFi after pairing is completed.

[0029] In a fourth aspect, the present application provides a wearable device communication device, which is deployed as a slave device in a wearable device communication system, and the slave device and the master device in the wearable device communication system transmit data via WiFi. The wearable device communication device includes: a second communication module and a second processing module, wherein the second communication module is used to receive a beacon data packet sent by the master device and perform frequency and timing synchronization based on the beacon data packet; the second processing module is used to generate and send a pairing request in response to the received beacon data packet sent by the master device; the second processing module is also used to determine that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; the second processing module is also used to transmit data with the master device via WiFi after pairing is completed.

[0030] In a fifth aspect, the present application provides a wearable device communication system, comprising at least two wearable devices; wherein one wearable device is a master device; and the remaining wearable devices are slave devices; the master device is configured to send a beacon data packet, the beacon data packet being used to perform frequency binding and timing synchronization with the slave device; the slave device is configured to receive the beacon data packet sent by the master device, perform frequency binding and timing synchronization based on the beacon data packet; and generate and send a pairing request in response to the received beacon data packet sent by the master device; the master device is further configured to generate and send a confirmation message including a time window in response to receiving a pairing request returned by a target slave device based on the beacon data packet; The slave device is further configured to determine that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device; after pairing is completed, the master device and the slave device transmit data via WiFi.

[0031] In a sixth aspect, the present application provides an electronic device comprising: a memory and a processor, the memory and the processor being connected; the memory being used to store programs; and the processor being used to call the programs stored in the memory to execute the method described in the first aspect and / or any possible implementation of the first aspect, or to execute the method described in the second aspect and / or any possible implementation of the second aspect.

[0032] In the seventh aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is run by a computer, it executes the method described in the first aspect and / or any possible implementation of the first aspect, or executes the method described in the second aspect and / or any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without any creative work.

[0034] Figure 1 This is a flow chart of a wearable device communication method applied to a master device according to an embodiment of the present application; Figure 2A schematic diagram of dividing a time window shown in an embodiment of the present application; Figure 3 A flow chart of a wearable device communication method applied to a slave device according to an embodiment of the present application is shown; Figure 4 A schematic diagram of communication between a master device and a slave device shown in an embodiment of the present application; Figure 5 A schematic diagram of communication between a master device and a slave device shown in an embodiment of the present application; Figure 6 This is a structural block diagram of a wearable device communication device deployed on a host device according to an embodiment of the present application; Figure 7 This is a structural block diagram of a wearable device communication apparatus deployed on a slave device according to an embodiment of the present application; Figure 8 This is a structural block diagram of a wearable device communication system shown in an embodiment of the present application; Figure 9 This is a structural block diagram of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0035] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0036] It should be noted that similar numbers and letters represent similar items in the following figures, so once an item is defined in one figure, it does not need to be further defined and explained in the subsequent figures. At the same time, in the description of this application, relational terms such as "first", "second", etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, article or equipment. In the absence of more restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method, article or equipment including the elements.

[0037] The technical solution of this application will be described in detail below with reference to the accompanying drawings.

[0038] This application provides a wearable device communication method, which is applied to a master device in a wearable communication system. The master device and slave devices in the wearable device communication system transmit data via WiFi, thereby improving the device's battery life and user experience.

[0039] Among them, the master device and the slave device are both wearable devices.

[0040] Optionally, both the master device and the slave device may be intelligent eyes.

[0041] In one embodiment, all wearable devices in the wearable communication system adopt the RTOS system, thereby increasing the service life of the glasses and turning the wearable devices into local area network chat tools to enhance the user experience.

[0042] See also Figure 1 , Figure 1 This is a flow chart of a wearable device communication method applied to a master device according to an embodiment of the present application. Figure 1 Describe the steps it involves.

[0043] S110: Send a beacon data packet.

[0044] The beacon data packet is used to synchronize the frequency and timing with the slave device.

[0045] The beacon data packet is implemented in a similar manner to the beacon packet sent when the WiFi connection is in the prior art, except that timing information for synchronization timing is added therein.

[0046] In one implementation, the beacon data packet includes frequency binding information for frequency binding and timing information for timing synchronization.

[0047] Optionally, the frequency binding information may include the MCS (Modulation and Coding Scheme) rate list, SSID (Service Set Identifier), MAC address (Media Access Control Address, also known as LAN address) supported by the master device, etc.

[0048] Optionally, the beacon data packet may also include a PIN code (a string of characters or a string of numbers), which corresponds to an encryption key, so that the target slave device can determine the encryption key used for subsequent encryption based on the PIN code.

[0049] S120: In response to receiving the pairing request returned by the target slave device based on the beacon data packet, completing pairing with the target slave device based on the pairing request, and generating and sending confirmation information including the time window, so that the target slave device determines that pairing is completed based on the confirmation information.

[0050] Among them, the time windows corresponding to each device in the wearable device communication system do not overlap. After pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device.

[0051] In one implementation, the pairing request includes data required to complete the pairing, so that after the master device receives the pairing request, it can complete the pairing based on the pairing request.

[0052] Optionally, the pairing request returned by the target slave device based on the beacon data typically includes the slave device's MAC address and all MCS rates supported by the slave device, so that the master device can complete the pairing through the slave device's MAC address and all MCS rates supported by the slave device.

[0053] The specific method and principle of pairing the master device and the slave device are well known to those skilled in the art and will not be described here for the sake of brevity.

[0054] Optionally, the pairing request may also include a timestamp. Upon receiving the pairing request, the master device uses the timestamp to determine the legitimacy of the request. Specifically, the master device determines whether the request was sent at a time less than or equal to a preset threshold. If the time is greater than the threshold, the master device determines that the request is expired.

[0055] Optionally, the pairing request may also include a public key. After receiving the pairing request, the master device encrypts all subsequent data communicated with the target slave device using the public key. Simultaneously, all subsequent data received by the master device from the target slave device is decrypted using the public key.

[0056] The target slave device retains the private key corresponding to the public key. All subsequent data sent by the target slave device to the master device is encrypted using the private key. All subsequent data sent by the master device to the target slave device is decrypted using the private key.

[0057] Since beacon packets are sent periodically, the time interval between two adjacent beacon packets is the same. The time interval between two adjacent beacon packets is divided into multiple time windows, and the time windows between any two adjacent beacon packets are divided in the same way.

[0058] Optionally, for each time window, the time window may be divided into a first sub-time window for sending data and a second sub-time window for sending response data representing received data.

[0059] In order to facilitate the understanding of the above time window, the following Figure 2 Take this as an example to illustrate.

[0060] like Figure 2 As shown, five time windows are divided between the time intervals of sending two adjacent beacon data packets, each of which includes a first sub-time window ( Figure 2 A shown) and the second sub-time window ( Figure 2 As shown in B), time window 1 is the time window corresponding to the master device.

[0061] After the master device is connected to the first slave device, a time window may be randomly selected from unassigned time windows and assigned to the first slave device.

[0062] Alternatively, the first slave device may be assigned the earliest time window among the currently unassigned time windows in chronological order, that is, time window 2 is assigned to the first slave device. Accordingly, when the master device is paired with the second slave device, time window 3 is assigned to the second slave device, and so on, until all time windows are assigned.

[0063] The examples here are only for ease of understanding. The number of time windows and the size of each time window can be set according to actual needs, and their specific number and size are not limited here.

[0064] Optionally, the specific size of the time window (ie, the duration of the time window) can be set according to actual needs, and the sizes corresponding to different time windows may be different.

[0065] Taking WiFi 4 (802.11n standard) as an example, the corresponding frequency band is 2.4 GHz or 5 GHz; the bandwidth is 20 MHz or 40 MHz; the maximum spatial stream (SS) is 4; and the MCS range is 0–31 (partially reserved). Common MCS examples (for a single spatial stream) are shown in Table 1.

[0066] Table 1

[0067] For each rate in Table 1, the time required to send a 1500-byte data packet is shown in Table 2: Table 2

[0068] Based on Table 2, it can be seen that the longest time required to send a 1500-byte data packet at different rates is 1.85 ms. Therefore, the size of a single time window can be set to be larger than 1.85 ms.

[0069] For example, the size of each time window can be set to no less than 2ms. 2ms is sufficient for a device to send a 1500-byte data packet. This example is for ease of understanding only and should not be construed as a limitation of this application.

[0070] In one embodiment, the confirmation information includes security information, so that after receiving the confirmation information, the target slave device also confirms whether the connected master device is a secure device based on the security information in the confirmation information. If the target slave device determines that the master device is a secure device, the master and target slave device transmit data via WiFi. If the target slave device determines that the master device is not a secure device, it disconnects the pairing with the master device.

[0071] Optionally, when it is determined that the master device is not a safety device, the target slave device may also issue an alarm, such as sending an alarm message.

[0072] In one embodiment, the security information is obtained by first obtaining historical communication information with the target slave device, and then generating a hash value based on the historical communication information.

[0073] In this manner, the target slave device may determine whether the master device is a secure device by generating a fourth hash value based on historical communication information with the master device. If the fourth hash value generated by the target slave device is consistent with the third hash value in the confirmation information, the master device is determined to be a secure device. If the fourth hash value generated by the target slave device is inconsistent with the third hash value in the confirmation information, the master device is determined not to be a secure device.

[0074] Optionally, a specific method of obtaining historical communication information with the target slave device may be: taking the current time point as the end point, obtaining historical communication information between the master device and the target slave device within a preset time length.

[0075] For example, the historical communication information between the master device and the target slave device within the previous hour can be obtained, or the historical communication information between the master device and the target slave device within the previous day can be obtained. The specific value of the preset time length can be set according to actual needs and is not limited here.

[0076] Optionally, a specific method for obtaining historical communication information with the target slave device may also be: obtaining N pieces of historical communication information most recent to the current time point, where N is a positive integer greater than or equal to 1.

[0077] For example, the 10 most recent historical communication information from the current time point may be obtained, or the 50 most recent historical communication information from the current time point may be obtained. The examples herein are only for ease of understanding and should not be construed as limiting the present application.

[0078] Optionally, a method of generating a hash value based on the historical communication information may be: using a pre-selected hash value algorithm to calculate the hash value of the historical communication information.

[0079] Alternatively, the historical communication information may be input into a preset hash value generation model to obtain a hash value, wherein the target slave device and the master device use the same hash value generation model to generate the hash value.

[0080] The hash value generation model may be any model that can convert text information into a hash value. For example, the hash value generation model may be a lightweight NLP (Natural Language Processing) model.

[0081] Optionally, the confirmation information may further include parameter selection information of the hash value generation model, so that after obtaining the confirmation information, the target slave device further configures parameters of its own hash value generation model based on the parameter selection information in the confirmation information.

[0082] Among them, the parameter selection information of the hash value generation model can be determined according to the actual hash value generation model. For example, the parameter selection information may include the type of word segmentation method, the weight value of each weight, the weighting algorithm type, etc., and its specific parameter type is not limited here.

[0083] In one implementation, the confirmation information may further include a rate selection order and an SN (Serial Number) number.

[0084] S130: After pairing is completed, data is transmitted with the target slave device via WiFi.

[0085] After pairing is complete, the master and slave devices can transmit data via WiFi. However, both the master and slave devices only send data during their own corresponding time windows. The slave device can remain in sleep mode during other time windows except for its own time window and the time window corresponding to the master device.

[0086] The master device can remain in sleep mode during the unassigned time window.

[0087] For ease of understanding, taking the five time windows of time window 1, time window 2, time window 3, time window 4, and time window 5 as an example, the master device corresponds to time window 1, the slave device 1 corresponds to time window 2, the slave device 2 corresponds to time window 3, and time window 4 and time window 5 are not allocated.

[0088] The master device needs to remain awake in the three time windows of time window 1, time window 2, and time window 3, and can enter the sleep state in the time window 4 and time window 5.

[0089] Slave device 1 needs to remain awake in the three time windows of time window 1 and time window 2, and can enter the sleep state in time window 3, time window 4, and time window 5.

[0090] Slave device 2 needs to remain awake during time windows 1 and 3, and can enter sleep mode during time windows 2, 4, and 5.

[0091] The examples here are only for ease of understanding and should not be construed as limiting this application.

[0092] Optionally, if the master device is in a dormant state, it may be automatically awakened a preset time before the arrival of a time window in which the master device needs to remain awake.

[0093] The preset duration can be set according to actual needs, for example, it can be 0.5ms, 1ms, etc., and its specific duration is not limited here.

[0094] Optionally, timed wake-up may be achieved through a timer.

[0095] In one embodiment, after pairing is completed, it is also possible to determine whether the target slave device is a secure device based on the security information in response to a security information packet including security information sent by the target slave device.

[0096] In which case, when the target slave device determines that the master device is a safe device, the master device and the target slave device perform data transmission via WiFi.

[0097] Optionally, the method and principle for the target slave device to generate security information are the same as the method and principle for the master device to generate security information, which will not be repeated here for the sake of simplicity.

[0098] When the security information is a hash value, the master device may determine whether the target slave device is a security device by generating a second hash value based on historical communication information with the target slave device. If the second hash value generated by the master device is consistent with the first hash value in the security information packet, the target slave device is determined to be a security device. If the hash value generated by the target slave device is inconsistent with the hash value in the confirmation information, the target slave device is determined not to be a security device.

[0099] Optionally, when the second hash value and the first hash value are generated by a hash value generation model, the confirmation information sent by the master device may further include a parameter configuration selection table, wherein the parameter configuration selection table may include configuration parameters of multiple sets of hash value generation models.

[0100] After receiving the confirmation information, the target slave device can also select a set of configuration parameters from the parameter configuration selection table and write the selected configuration parameters or the selected configuration parameter types into the security information package. After receiving the security information package, the master device can also configure the parameters of its own hash value generation model based on the parameter selection information in the security information package.

[0101] For example, if the parameter configuration selection table includes a word segmentation method list, a weight list, and a weighted algorithm selection list. After receiving the parameter configuration selection table, the target slave device determines the type of word segmentation method to be used, the weight values of each weight, and the weighted algorithm type from the word segmentation method list, the weight list, and the weighted algorithm selection list. The selected word segmentation method type, the weight values of each weight, and the weighted algorithm type are then written into the security information packet and sent. The examples here are only for ease of understanding, and the specific implementation of the parameter configuration selection table is not limited to the examples given here.

[0102] Based on the same technical concept, the present application also provides a wearable device communication method for a slave device in a wearable device communication system. Figure 3 Describe the steps it involves.

[0103] S210: Receive a beacon data packet sent by the master device, and perform frequency matching and timing synchronization based on the beacon data packet.

[0104] The specific implementation method and principle of the beacon data packet have been clearly described in the previous article. For the sake of brevity, they will not be repeated here.

[0105] The method of frequency binding based on the beacon data packet can be to obtain the PIN code and SSID in the beacon data packet, confirm the PIN code, and connect the SSID to complete the frequency binding.

[0106] The method of frequency pairing based on beacon data packets is the same as the frequency pairing operation performed during existing WiFi connection pairing. For the sake of simplicity, it will not be repeated here.

[0107] The method of synchronizing timing based on the beacon data packet may be: obtaining timing information in the beacon data packet, adjusting the timing information of the own to be consistent with the timing information in the beacon data packet, and completing timing synchronization.

[0108] S220: Generate and send a pairing request in response to the received beacon data packet sent by the master device.

[0109] The content of the pairing request has been clearly described above and will not be repeated here for the sake of brevity.

[0110] The specific implementation method of generating and sending the pairing request from the device is the same as the method of generating the pairing request during the existing WiFi connection pairing. For the sake of simplicity, it is not repeated here.

[0111] S230: In response to the confirmation information including the time window sent by the master device based on the pairing request, determine that the pairing is completed.

[0112] Among them, the time windows corresponding to each device in the wearable device communication system do not overlap. After pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device.

[0113] The specific manner in which the master device and the slave device maintain a dormant state or a wake-up state has been clearly described above and will not be repeated here for the sake of brevity.

[0114] The confirmation information sent by the master device may include security information. When the slave device receives the confirmation information including security information, it confirms whether the connected master device is a security device based on the security information in the confirmation information; when it is determined that the master device is a security device, the master device and the target slave device transmit data via WiFi.

[0115] Among them, the way in which the master device sends confirmation information and the way in which the slave device determines whether the master device is a safety device based on the safety information have been clearly described in the previous text. For the sake of simplicity, they will not be repeated here.

[0116] S240: After pairing is completed, data is transmitted with the main device via WiFi.

[0117] In one embodiment, after pairing is complete, the slave device sends a security information packet including security information, so that the master device determines whether the slave device is a secure device based on the security information; if the slave device is determined to be a secure device, the master and slave devices perform data transmission via WiFi.

[0118] Optionally, the security information is obtained by first obtaining historical communication information with the master device, and then generating a hash value based on the historical communication information.

[0119] Optionally, a specific method of obtaining historical communication information with the master device may be: taking the current time point as an end point, obtaining historical communication information between the master device and the current slave device within a preset time length.

[0120] For example, the historical communication information between the master device and the current slave device within the previous hour can be obtained, or the historical communication information between the master device and the current slave device within the previous day can be obtained. The specific value of the preset time length can be set according to actual needs and is not limited here.

[0121] Optionally, a specific method for obtaining historical communication information with the master device may also be: obtaining N pieces of historical communication information most recent to the current time point, where N is a positive integer greater than or equal to 1.

[0122] For example, the 10 most recent historical communication information from the current time point may be obtained, or the 50 most recent historical communication information from the current time point may be obtained. The examples herein are only for ease of understanding and should not be construed as limiting the present application.

[0123] Optionally, a method of generating a hash value based on the historical communication information may be: using a pre-selected hash value algorithm to calculate the hash value of the historical communication information.

[0124] Alternatively, the historical communication information may be input into a preset hash value generation model to obtain a hash value, wherein the hash value generation model used by the slave device and the master device to generate the hash value is the same.

[0125] The hash value generation model may be any model that can convert text information into a hash value. For example, the hash value generation model may be a lightweight NLP model or the like.

[0126] In one embodiment, the confirmation information includes a parameter configuration selection table for the hash value generation model. The security information package also includes parameter selection information for the hash value generation model, where the parameter selection information is a configuration parameter type selected from the parameter configuration selection table. This allows the master device to configure its own hash value generation model parameters based on the parameter selection information in the security information package after receiving the security information package.

[0127] The specific implementation method and principle of the parameter configuration selection table have been clearly described in the previous article. For the sake of brevity, they will not be repeated here.

[0128] After pairing is complete, the slave device can also automatically wake up at a preset time before the target time window. The target time window is the time window of the slave device and the time window of the master device.

[0129] In order to ensure that the slave device can work normally in the target time window, a preset time length is set before the target time window to automatically wake up the slave device to ensure that the slave device can work normally in the target time window.

[0130] The preset duration can be set according to actual needs, for example, it can be 0.5ms, 1ms, etc., and its specific duration is not limited here.

[0131] Optionally, timed wake-up may be achieved through a timer.

[0132] To understand the wearable device communication method described above, please refer to Figure 4 , the following will be combined Figure 4 An example is given to illustrate the communication method of a wearable device.

[0133] like Figure 4 As shown in Figure 1, the master device first sends a beacon packet, which includes timing information, frequency information (such as the MCS rate list supported by the master device, SSID, MAC address, etc.), and a PIN code.

[0134] After receiving the beacon packet, the slave device stores the master device's supported MCS rate list, SSID, and MAC address, then generates and sends a pairing request. The pairing request includes the slave device's MAC address, all supported MCS rates, and the public key. The pairing request is encrypted using the encryption key corresponding to the PIN code.

[0135] After receiving the pairing request, the master device generates a third hash value using the hash value generation model, and then sends the parameter selection information, the third hash value, the rate selection order, and the SN number to the slave device as confirmation information using public key encryption.

[0136] After receiving the confirmation message, the slave device decrypts the confirmation message using the private key corresponding to the public key. It then configures its own hash value generation model using the parameter selection information included in the confirmation message and generates a fourth hash value using the configured hash value generation model. If the fourth hash value generated by the slave device matches the third hash value sent by the master device, the master device is confirmed to be a secure device. If the fourth hash value generated by the slave device differs from the third hash value sent by the master device, the master device is confirmed to be not a secure device and an alarm is issued.

[0137] If the master and slave devices are connecting for the first time, they can generate a hash value using a configured hash value generation model. This can include using beacon packets sent and received during pairing and some parameters in the pairing request as input data to the hash value generation model to obtain the hash value. The input data provided to the hash value generation model by the master and slave devices must have the same parameter type and format.

[0138] The specific parameter type and format selected may be pre-set, and are not limited here.

[0139] For example, the MAC address of the master device, the MAC address of the slave device, and the SSID can be used as input data in the format of "master device MAC address - slave device MAC address - SSID" to obtain the hash value output by the hash value generation model. This example is only for ease of understanding and should not be used as a limitation of this application.

[0140] To understand the wearable device communication method described above, please refer to Figure 5 , the following will be combined Figure 4 An example is given to illustrate the communication method of a wearable device.

[0141] like Figure 5 As shown in Figure 1, the master device first sends a beacon packet, which includes timing information, frequency information (such as the MCS rate list supported by the master device, SSID, MAC address, etc.), and a PIN code.

[0142] After receiving the beacon packet, the slave device stores the master device's supported MCS rate list, SSID, and MAC address, then generates and sends a pairing request. The pairing request includes the slave device's MAC address, all supported MCS rates, and the public key. The pairing request is encrypted using the encryption key corresponding to the PIN code.

[0143] After receiving the pairing request, the master device generates a hash value using the hash value generation model. It then uses public key encryption to send the parameter configuration selection table, hash value, rate selection order, and SN number as confirmation information to the slave device.

[0144] After receiving the confirmation message, the slave device decrypts the confirmation message using the private key corresponding to the public key. The slave device selects a set of configuration parameters from the parameter configuration selection table included in the confirmation message to configure its own hash value generation model, and then generates a first hash value using the configured hash value generation model. The first hash value, the selected configuration parameters, or the selected configuration parameter types (which may also include a greeting message, the master device's MAC address, the slave device's MAC address, and the SSID) are then encrypted using the private key to generate and transmit a security information packet.

[0145] After receiving the security information packet, the master device decrypts the security information packet using the public key, configures its own hash value generation model using the selected configuration parameters or the selected configuration parameter type, and generates a second hash value using the configured hash value generation model. If the first hash value generated by the slave device is the same as the second hash value sent by the master device, the slave device is confirmed to be a secure device. If the first hash value generated by the slave device is different from the second hash value sent by the master device, the slave device is confirmed to be not a secure device and an alarm is issued.

[0146] The method of generating a hash value using the configured hash value generation model has been clearly described above and will not be repeated here for the sake of brevity.

[0147] Based on the same technical concept, the present application also provides a wearable device communication device, such as Figure 6 As shown, the wearable device communication apparatus 100 is deployed as a master device in a wearable device communication system, and the master device and slave devices in the wearable device communication system perform data transmission via WiFi. The wearable device communication apparatus 100 includes a first communication module 110 and a first processing module 120.

[0148] The first communication module 110 is configured to send a beacon data packet, where the beacon data packet is used to perform frequency matching and timing synchronization with the slave device.

[0149] The first processing module 120 is used to complete pairing with the target slave device based on the pairing request in response to receiving a pairing request returned by the target slave device based on the beacon data packet, and generate and send confirmation information including a time window, so that the target slave device determines that the pairing is completed based on the confirmation information; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except the time window corresponding to itself and the time window corresponding to the master device.

[0150] After the pairing is completed, the first processing module 120 is further used to respond to a security information packet including security information sent by the target slave device, and determine whether the target slave device is a security device based on the security information; wherein, if it is determined that the target slave device is not a security device, the pairing with the target slave device is disconnected.

[0151] The security information is a first hash value, and the first processing module 120 is specifically used to obtain historical communication information with the target slave device; generate a second hash value based on the historical communication information; determine whether the first hash value and the second hash value are consistent, and if they are consistent, determine that the target slave device is a security device.

[0152] The first processing module 120 is specifically configured to input the historical communication information into a preset hash value generation model to obtain the second hash value; wherein the hash value generation model used by the slave device to generate the first hash value is the same as the hash value generation model used by the master device to generate the second hash value.

[0153] In one embodiment, the confirmation information includes a parameter configuration selection table of the hash value generation model; the security information package also includes parameter selection information of the hash value generation model, and the parameter selection information is the configuration parameter type selected from the parameter configuration selection table; the first processing module 120 is also used to configure the parameters of the preset hash value generation model based on the parameter selection information; the historical communication information is input into the hash value generation model after parameter configuration to obtain the second hash value.

[0154] In one embodiment, the confirmation information includes security information, so that after the target slave device obtains the confirmation information, it also confirms whether the connected master device is a security device based on the security information in the confirmation information. If it is determined that the master device is not a security device, the pairing with the master device is disconnected.

[0155] The wearable device communication device 100 provided in the embodiment of the present application has the same implementation principle and technical effects as those in the aforementioned wearable device communication method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding content in the aforementioned wearable device communication method embodiment.

[0156] Based on the same technical concept, the present application also provides a wearable device communication device, such as Figure 7 As shown, the wearable device communication device 200 is deployed as a slave device in a wearable device communication system, and the master device and the slave device in the wearable device communication system perform data transmission via WiFi. The wearable device communication device 200 includes a second communication module 210 and a second processing module 220.

[0157] The second communication module 210 is configured to receive a beacon data packet sent by the master device, and perform frequency matching and timing synchronization based on the beacon data packet.

[0158] The second processing module 220 is configured to generate and send a pairing request in response to a received beacon data packet sent by the master device.

[0159] The second processing module 220 is further used to determine that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device.

[0160] The confirmation information includes security information. The second processing module 220 is further used to confirm whether the connected main device is a security device based on the security information in the confirmation information; if it is determined that the main device is not a security device, disconnect the pairing with the main device.

[0161] The security information includes a third hash value, and the second processing module 220 is specifically used to obtain historical communication information with the main device; generate a fourth hash value based on the historical communication information; determine whether the third hash value and the fourth hash value are consistent, and if they are consistent, determine that the main device is a security device.

[0162] The second processing module 220 is specifically configured to input the historical communication information into a preset hash value generation model to obtain the fourth hash value; wherein the hash value generation model used by the slave device to generate the fourth hash value is the same as the hash value generation model used by the master device to generate the third hash value.

[0163] The confirmation information includes parameter selection information of the hash value generation model. The second processing module 220 is further used to configure the parameters of the preset hash value generation model based on the parameter selection information; input the historical communication information into the hash value generation model after parameter configuration to obtain the fourth hash value.

[0164] After determining that the pairing is completed, the second processing module 220 is further used to send a security information packet including security information, so that the master device determines whether the slave device is a security device based on the security information; if it is determined that the slave device is not a security device, disconnect the pairing with the master device.

[0165] The wearable device communication device 200 provided in the embodiment of the present application has the same implementation principle and technical effects as those in the aforementioned wearable device communication method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding content in the aforementioned wearable device communication method embodiment.

[0166] Based on the same technical concept, this application also provides a wearable device communication system. Figure 8As shown, the wearable device communication system 10 includes at least two wearable devices, one of which is a master device 20 and the other wearable devices are slave devices 30.

[0167] The master device 20 is configured to send a beacon data packet, wherein the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; The slave device 30 is configured to receive a beacon data packet sent by the master device, perform frequency matching and timing synchronization based on the beacon data packet, and generate and send a pairing request in response to the received beacon data packet sent by the master device; The master device 20 is further configured to generate and send confirmation information including a time window in response to receiving a pairing request returned by the target slave device based on the beacon data packet; The slave device 30 is further configured to determine that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device.

[0168] The specific implementation methods and principles of each step of the master device and the slave device have been clearly described in the previous text and will not be repeated here for the sake of brevity.

[0169] See also Figure 9 , which is an electronic device 300 provided in an embodiment of the present application. The electronic device 300 includes: a processor 310 and a memory 320.

[0170] The memory 320 and the processor 310 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines. The memory 320 is used to store computer programs, such as Figure 3The software functional modules shown in FIG3 are wearable device communication apparatus 100 or wearable device communication apparatus 200. The wearable device communication apparatus 100 or wearable device communication apparatus 200 includes at least one software functional module that can be stored in the memory 320 in the form of software or firmware or embedded in the operating system (OS) of the electronic device 300. The processor 310 is configured to execute the executable modules stored in the memory 320, such as the software functional modules or computer programs included in the wearable device communication apparatus 100. At this time, the processor 310 is used to send a beacon data packet, which is used to perform frequency matching and timing synchronization with the slave device; in response to receiving a pairing request returned by the target slave device based on the beacon data packet, completing pairing with the target slave device based on the pairing request, generating and sending confirmation information including a time window, so that the target slave device determines that pairing is completed based on the confirmation information; wherein, the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device; after pairing is completed, data is transmitted with the target slave device via WiFi.

[0171] Alternatively, the processor 310 is configured to receive a beacon data packet sent by the master device, and perform frequency matching and timing synchronization based on the beacon data packet; generate and send a pairing request in response to the received beacon data packet sent by the master device; determine that pairing is completed in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except its own corresponding time window and the time window corresponding to the master device; after pairing is completed, data is transmitted with the master device via WiFi.

[0172] The memory 320 may be, but is not limited to, RAM (Random Access Memory), ROM (Read Only Memory), PROM (Programmable Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electric Erasable Programmable Read-Only Memory), etc.

[0173] Processor 310 may be an integrated circuit chip with signal processing capabilities. Such processors may be general-purpose processors, including CPUs (Central Processing Units) and NPs (Network Processors). They may also be DSPs (Digital Signal Processors), ASICs (Application Specific Integrated Circuits), FPGAs (Field Programmable Gate Arrays), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. These processors may implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor, or processor 310 may be any conventional processor.

[0174] Among them, the above-mentioned electronic device 300 includes but is not limited to wearable devices such as smart bracelets, smart watches, and smart glasses.

[0175] The present application also provides a computer-readable storage medium (hereinafter referred to as storage medium) that stores a computer program. When the computer program is executed by a computer, such as the electronic device 300 described above, the computer-readable storage medium executes the wearable device communication method described above. The computer-readable storage medium includes various media capable of storing program code, such as a USB flash drive, a mobile hard drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk.

[0176] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A wearable device communication method, characterized in that: A master device applied to a wearable device communication system, wherein the master device and a slave device in the wearable device communication system perform data transmission via WiFi, and the method includes: Sending a beacon data packet, wherein the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; In response to receiving a pairing request returned by a target slave device based on the beacon data packet, completing pairing with the target slave device based on the pairing request, generating and sending confirmation information including a time window, so that the target slave device determines that pairing is complete based on the confirmation information; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; After pairing is completed, data is transmitted with the target slave device via WiFi.

2. The method according to claim 1, characterized in that After the pairing is completed, the method further includes: In response to a security information packet including security information sent by the target slave device, determining whether the target slave device is a security device based on the security information; wherein, if it is determined that the target slave device is not a security device, disconnecting the pairing with the target slave device.

3. The method according to claim 2, characterized in that The security information is a first hash value, and determining whether the target slave device is a security device based on the security information includes: Acquiring historical communication information with the target slave device; generating a second hash value based on the historical communication information; Determine whether the first hash value and the second hash value are consistent. If they are consistent, determine that the target slave device is a secure device.

4. The method according to claim 3, characterized in that Generating a second hash value based on the historical communication information includes: The historical communication information is input into a preset hash value generation model to obtain the second hash value; wherein the hash value generation model used by the slave device to generate the first hash value is the same as the hash value generation model used by the master device to generate the second hash value.

5. The method according to claim 4, characterized in that The confirmation information includes a parameter configuration selection table for a hash value generation model; the security information package also includes parameter selection information for the hash value generation model, the parameter selection information being a configuration parameter type selected from the parameter configuration selection table; the method further includes: Configuring parameters of a preset hash value generation model based on the parameter selection information; Accordingly, inputting the historical communication information into a preset hash value generation model to obtain the second hash value includes: The historical communication information is input into the parameter-configured hash value generation model to obtain the second hash value.

6. The method according to claim 1, characterized in that The confirmation information includes security information, so that after obtaining the confirmation information, the target slave device also confirms whether the connected master device is a security device based on the security information in the confirmation information. If it is determined that the master device is not a security device, the pairing with the master device is disconnected.

7. A wearable device communication method, characterized in that: A slave device is applied to a wearable device communication system, wherein the slave device transmits data with a master device in the wearable device communication system via WiFi, and the method includes: Receive a beacon data packet sent by the master device, and perform frequency matching and timing synchronization based on the beacon data packet; generating and sending a pairing request in response to a received beacon data packet sent by the master device; In response to confirmation information including a time window sent by the master device based on the pairing request, determining that pairing is complete; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; After pairing is completed, data is transmitted with the main device via WiFi.

8. The method according to claim 7, characterized in that The confirmation information includes security information, and the method further includes: confirming whether the connected master device is a safety device based on the safety information in the confirmation information; If it is determined that the main device is not a secure device, pairing with the main device is terminated.

9. The method according to claim 8, characterized in that The security information includes a third hash value, and the confirming whether the connected master device is a security device based on the security information in the confirmation information includes: Acquiring historical communication information with the master device; generating a fourth hash value based on the historical communication information; Determine whether the third Hash value and the fourth Hash value are consistent. If they are consistent, determine that the master device is a secure device.

10. The method according to claim 9, characterized in that Generating a fourth hash value based on the historical communication information includes: The historical communication information is input into a preset hash value generation model to obtain the fourth hash value; wherein the hash value generation model used by the slave device to generate the fourth hash value is the same as the hash value generation model used by the master device to generate the third hash value.

11. The method according to claim 10, characterized in that The confirmation information includes parameter selection information of a hash value generation model, and the method further includes: Configuring parameters of a preset hash value generation model based on the parameter selection information; Accordingly, inputting the historical communication information into a preset hash value generation model to obtain the fourth hash value includes: The historical communication information is input into the parameter-configured hash value generation model to obtain the fourth hash value.

12. The method according to claim 7, characterized in that After determining that the pairing is completed, the method further includes: A security information packet including security information is sent, so that the master device determines whether the slave device is a security device based on the security information; if it is determined that the slave device is not a security device, the pairing with the master device is disconnected.

13. A wearable device communication device, characterized in that: The wearable device communication device is deployed in a master device of a wearable device communication system. The master device and a slave device in the wearable device communication system perform data transmission via WiFi. The wearable device communication device includes: A first communication module is configured to send a beacon data packet, wherein the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; a first processing module, configured to generate and send, in response to receiving a pairing request returned by a target slave device based on the beacon data packet, a confirmation message including a time window, so that the target slave device determines that pairing is complete based on the confirmation message; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; The first processing module is further configured to transmit data with the target slave device via WiFi after pairing is completed.

14. A wearable device communication device, characterized in that: The wearable device communication device is deployed as a slave device in a wearable device communication system. The slave device and the master device in the wearable device communication system perform data transmission via WiFi. The wearable device communication device includes: A second communication module is configured to receive a beacon data packet sent by the master device and perform frequency matching and timing synchronization based on the beacon data packet; a second processing module, configured to generate and send a pairing request in response to a received beacon data packet sent by the master device; The second processing module is further configured to determine that pairing is complete in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; The second processing module is further configured to transmit data with the main device via WiFi after pairing is completed.

15. A wearable device communication system, characterized in that: The system comprises at least two wearable devices, one of which is a master device and the other wearable devices are slave devices. The master device is configured to send a beacon data packet, wherein the beacon data packet is used to perform frequency matching and timing synchronization with the slave device; The slave device is configured to receive a beacon data packet sent by the master device, perform frequency matching and timing synchronization based on the beacon data packet, and generate and send a pairing request in response to the received beacon data packet sent by the master device; The master device is further configured to generate and send confirmation information including a time window in response to receiving a pairing request returned by the target slave device based on the beacon data packet; The slave device is further configured to determine that pairing is complete in response to confirmation information including a time window sent by the master device based on the pairing request; wherein the time windows corresponding to each device in the wearable device communication system do not overlap, and after pairing is completed, each device sends data only in its own corresponding time window, and each slave device remains in a dormant state in other time windows except for its own corresponding time window and the time window corresponding to the master device; After pairing is completed, the master device and the slave device perform data transmission via WiFi.

16. An electronic device, characterized in that: include: a memory and a processor, the memory and the processor being connected; The memory is used to store programs; The processor is configured to call a program stored in the memory to execute the method according to any one of claims 1 to 6, or to execute the method according to any one of claims 7 to 12.

17. A computer-readable storage medium, characterized in that A computer program is stored thereon, and when the computer program is run by a computer, the method according to any one of claims 1 to 6 is executed, or the method according to any one of claims 7 to 12 is executed.

Images