Method and apparatus for network keep-alive

Abstract

Embodiments of the present application provide a networking keep-alive method and device. The method comprises: a first device receiving a heartbeat keep-alive broadcast message from a second device, the heartbeat keep-alive broadcast message being used to indicate that the second device is in a networking online state, the heartbeat keep-alive broadcast message comprising a first identifier, the first identifier being used to indicate a group to which the second device belongs; the first device matching the first identifier and a second identifier to obtain a matching result, the second identifier being used to indicate a group to which the first device belongs; and processing the heartbeat keep-alive broadcast message according to the matching result. In the embodiments of the present application, the devices keep alive based on the groups to which the devices belong. In this way, one heartbeat keep-alive broadcast message can maintain multiple devices in a "networking online" state in a short time, which is efficient and thus helps to improve user experience.

Description

Technical Field

[0001] This application relates to the field of terminals, and more specifically, to a method and apparatus for network keep-alive. Background Technology

[0002] After a connection is established between devices, periodic heartbeat keep-alive broadcast messages are typically initiated between networked devices. The target device identifier is filled into the advertising data (AD data) field of the heartbeat keep-alive broadcast message. In this way, the receiving end can determine whether to keep the device in a "networked online" state by using the target device identifier in the heartbeat keep-alive broadcast message, and thus determine whether to exchange information.

[0003] Currently, the target device identifier is quite long, resulting in a small payload of the target device identifier carried in a single heartbeat keep-alive broadcast message. However, in real-world network environments, a device often networks with multiple other devices. If the target device identifier payload in a heartbeat keep-alive broadcast message is too small, the sender may send multiple heartbeat keep-alive broadcast messages, making the process of maintaining the device in a "network online" state time-consuming and inefficient, ultimately leading to a poor user experience. Summary of the Invention

[0004] This application provides a method and apparatus for network keep-alive. The method can keep multiple devices in a "network online" state in a short time with a single heartbeat keep-alive broadcast message, which is highly efficient and helps to improve the user experience.

[0005] In a first aspect, a system is provided, the system comprising a first device and a second device, wherein the second device is configured to broadcast a first heartbeat keep-alive broadcast message, the first heartbeat keep-alive broadcast message indicating that the second device is in a network online state, the first heartbeat keep-alive broadcast message including a first identifier, the first identifier indicating the group to which the second device belongs; the first device is configured to, in response to receiving the first heartbeat keep-alive broadcast message, match the first identifier with a second identifier to obtain a first matching result, wherein the second identifier indicates the group to which the first device belongs; the first device is further configured to process the first heartbeat keep-alive broadcast message according to the first matching result.

[0006] In this embodiment, the second device carries its group affiliation in the first heartbeat keep-alive broadcast message. This allows the first device to match the received first identifier indicating the second device's group affiliation with a second identifier indicating the group affiliation of the first device, and process the received first heartbeat keep-alive broadcast message based on the first matching result. In other words, devices maintain keep-alive based on their respective groups. Thus, a single first heartbeat keep-alive broadcast message can keep multiple devices in a "networked online" state within a short time, resulting in high efficiency and improved user experience.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the first identifier is generated based on an authentication method between the second device and the third device, wherein the third device is a device within the group to which the second device belongs; and / or, the second identifier is generated based on an authentication method between the first device and the fourth device, wherein the fourth device is a device within the group to which the first device belongs.

[0008] In this embodiment of the application, since there is a one-to-one correspondence between the authentication method and the identifier (such as the first identifier or the second identifier) ​​used to indicate the group to which the device belongs, the identifier used to indicate the group to which the device belongs can be compatible with various types of authentication methods between devices. In this way, when expanding the authentication method in the future, there is no need to modify the structure of TGID, and thus the scalability of the first heartbeat keep-alive broadcast message is high.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, the first identifier further includes a first identifier bit and / or a second identifier bit; wherein the first identifier bit is used to indicate whether a response to the first heartbeat keep-alive broadcast message is required; and the second identifier bit is used to indicate the authentication type between the second device and the third device.

[0010] By setting a flag in the first identifier to indicate whether a response to the first heartbeat keep-alive broadcast message is required, the first device can determine whether to respond to the first heartbeat keep-alive broadcast message based on the first heartbeat keep-alive broadcast message. Thus, it can respond to the first heartbeat keep-alive broadcast message on demand from the demand side (second device), which can significantly reduce the bandwidth and power consumption load of the first device.

[0011] By setting an identifier bit in the first identifier to identify the authentication type corresponding to the trusted group identifier, the first device can determine the degree of protection of the user's privacy data on the first device from the perspective of the sending end (second device) based on the first heartbeat keep-alive broadcast message.

[0012] In conjunction with the first aspect, in some implementations of the first aspect, the authentication type includes same-account authentication type and different-account authentication type.

[0013] If the authentication type corresponding to the identifier used to identify the authentication type included in the first identifier is the same as the authentication method for the same account, then the receiving end (first device) can consider the sending end (second device) and the receiving end (first device) to be personal devices based on the first identifier, that is, the sending end (second device) and the receiving end (first device) belong to the same person. In this way, the receiving end (first device) can determine that, from the perspective of the sending end (second device), the protection level of the user's privacy data on the receiving end (first device) is relatively low. Therefore, the receiving end (first device) can share the user's privacy data on the receiving end (first device) with the sending end (second device).

[0014] If the authentication type corresponding to the identifier included in the first identifier is a non-same-account authentication method, then the receiving end (first device) can, based on the first identifier, consider that the sending end (second device) and the receiving end (first device) may not belong to the same personal device, that is, the sending end (second device) and the receiving end (first device) may not belong to the same person. Thus, the receiving end (first device) can determine that, from the perspective of the sending end (second device), the user's privacy data on the receiving end (first device) is highly protected. Therefore, the receiving end (first device) may not share the user's privacy data on the receiving end (first device) with the sending end (second device).

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the first device is further specifically used to: determine that the first matching result is a match, and maintain the networking status with the second device according to the first heartbeat keep-alive broadcast message.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the communication system further includes a fifth device, the fifth device being configured to broadcast a second heartbeat keep-alive broadcast message, the second heartbeat keep-alive broadcast message being used to indicate that the fifth device is in a network online state, the second heartbeat keep-alive broadcast message including a fifth identifier, the fifth identifier being used to indicate the group to which the fifth device belongs; the first device is further configured to, in response to receiving the second heartbeat keep-alive broadcast message, match the fifth identifier with a second identifier to obtain a second matching result; the first device is further configured to, if the second matching result is a mismatch, discard the second heartbeat keep-alive broadcast message.

[0017] Secondly, a method for network keep-alive is provided, the method comprising: a first device receiving a first heartbeat keep-alive broadcast message from a second device, the first heartbeat keep-alive broadcast message indicating that the second device is in a network online state, the first heartbeat keep-alive broadcast message including a first identifier, the first identifier indicating the group to which the second device belongs; the first device matching the first identifier with a second identifier to obtain a first matching result, wherein the second identifier indicates the group to which the first device belongs; and the first device processing the first heartbeat keep-alive broadcast message according to the first matching result.

[0018] In this embodiment, the first device matches a first identifier indicating the group to which the second device belongs with a second identifier of the group to which the first device belongs, and processes the received first heartbeat keep-alive broadcast message from the second device based on the first matching result. In other words, devices maintain keep-alive based on their respective groups. Thus, a single first heartbeat keep-alive broadcast message can keep multiple devices in a "networked online" state within a short time, resulting in high efficiency and improved user experience.

[0019] In conjunction with the second aspect, in some implementations of the second aspect, the first identifier is generated based on the authentication method between the second device and the third device, wherein the third device is a device within the group to which the second device belongs.

[0020] In conjunction with the second aspect, in some implementations of the second aspect, the first identifier further includes a first identifier bit and / or a second identifier bit; wherein the first identifier bit is used to indicate whether a response to the first heartbeat keep-alive broadcast message is required; and the second identifier bit is used to indicate the authentication type between the second device and the third device.

[0021] In conjunction with the second aspect, in some implementations of the second aspect, the authentication type includes same-account authentication type and different-account authentication type.

[0022] In conjunction with the second aspect, in some implementations of the second aspect, the length of the first identifier is related to the scenario in which the first device is applied.

[0023] Given the varying number of devices in different scenarios, the different requirements for the maximum number of TGIDs, and the different sensitivities to power consumption and / or bandwidth, different lengths of the first identifier are set for different scenarios to flexibly adapt to the needs of different scenarios.

[0024] For example, in industrial scenarios, the equipment is primarily powered, so its sensitivity to power consumption and / or bandwidth is relatively low. This means that the performance requirements for the first heartbeat keep-alive broadcast message are lower in industrial settings. However, industrial scenarios involve a relatively large number of devices, often ranging from thousands to tens of thousands in a single factory. Therefore, assuming no TGID conflicts, industrial scenarios have a higher requirement for the maximum number of TGIDs. In such cases, the length of the TGID can be set relatively large, increasing the maximum number of TGIDs.

[0025] In home scenarios, there are many non-powered devices, making them more sensitive to power consumption and / or bandwidth. This means higher performance requirements are placed on the first heartbeat keep-alive broadcast message 2. However, the number of devices in a home scenario is relatively small. Therefore, assuming no TGID conflicts, the requirement for the maximum number of TGIDs is not as stringent. In this case, the TGID length can be set relatively small, increasing the number of TGIDs carried in a single broadcast of the first heartbeat keep-alive broadcast message 2, thus reducing device power consumption and / or bandwidth.

[0026] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: the first device generating the fourth identifier according to the authentication method between the first device and the fourth device, wherein the fourth device is a device within the group to which the first device belongs; performing a hash calculation on the fourth identifier, and extracting the remaining M bits as the second identifier.

[0027] It should be noted that the first device may generate the second identifier before receiving the first heartbeat keep-alive broadcast message; or, the first device may generate the second identifier after receiving the first heartbeat keep-alive broadcast message and before matching the first identifier with the second identifier; or, the first device may generate the second identifier during the process of receiving the first heartbeat keep-alive broadcast message; the embodiments of this application do not limit this.

[0028] In conjunction with the second aspect, in some implementations of the second aspect, the length of the first identifier is N bits, the length of the second identifier is M bits, and the first device matches the first identifier with the second identifier to obtain a first matching result, including: when N > M, the first device matches the value of the last M bits of the first identifier with the value of the second identifier to obtain the first matching result; or, when N < M, the first device matches the value of the first identifier with the value of the last N bits of the second identifier to obtain the first matching result.

[0029] It should be noted that when N > M, the value of the M bits following the first identifier can be understood as the content obtained by truncating the M bits of the first identifier from the end to the beginning. The value of the second identifier can be understood as the content of the M bits of the second identifier.

[0030] When N < M, the value of the first identifier can be understood as the content of the N bits of the first identifier; the value of the N bits after the second identifier can be understood as the content obtained by truncating the N bits of the second identifier from the end to the beginning.

[0031] In conjunction with the second aspect, in some implementations of the second aspect, 8 ≤ N ≤ 20, and / or 8 ≤ M ≤ 20.

[0032] Typically, setting the identifier length used to indicate the group to which a device belongs to is between 8 and 20 bits, which is sufficient for most scenarios. Thus, a first heartbeat keep-alive broadcast message can carry a maximum of 7.5 bytes (60 bits) for the target device identifier, resulting in 3 to 5 TGIDs per message. This means that the number of target device identifiers carried in a single first heartbeat keep-alive broadcast message is greater than the existing maximum of two. Therefore, a single first heartbeat keep-alive broadcast message carries a larger target device identifier load, requiring fewer first heartbeat keep-alive broadcast messages to be sent. This allows multiple devices to remain "networked online" in a shorter time, resulting in higher efficiency and improved user experience.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the step of processing the first heartbeat keep-alive broadcast message according to the first matching result includes: if the first matching result is a mismatch, the first device discards the first heartbeat keep-alive broadcast message; or, if the first matching result is a match, the first device maintains the network state with the second device according to the first heartbeat keep-alive broadcast message.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the step of processing the first heartbeat keep-alive broadcast message according to the first matching result includes: determining that the first matching result is a match, and the first device maintaining the network state with the second device according to the first heartbeat keep-alive broadcast message.

[0035] In conjunction with the second aspect, in some implementations of the second aspect, the first device receives a second heartbeat keep-alive broadcast message from the fifth device. The second heartbeat keep-alive broadcast message is used to indicate that the fifth device is in a network online state. The second heartbeat keep-alive broadcast message includes a fifth identifier, which is used to indicate the group to which the fifth device belongs. The first device matches the fifth identifier with the second identifier to obtain a second matching result. If the second matching result is determined to be a mismatch, the first device discards the second heartbeat keep-alive broadcast message.

[0036] At this point, the fifth device can be understood as another second device, which may be the second device described in some embodiments of the second aspect above.

[0037] Thirdly, a method for network keep-alive is provided, the method comprising: a second device generating a first heartbeat keep-alive broadcast message, the first heartbeat keep-alive broadcast message being used to indicate that the second device is in a network online state, the first heartbeat keep-alive broadcast message including a first identifier, the first identifier being used to indicate the group to which the second device belongs; and the second device broadcasting the first heartbeat keep-alive broadcast message.

[0038] In conjunction with the third aspect, in some implementations of the third aspect, the first identifier further includes a first identifier bit and / or a second identifier bit; wherein the first identifier bit is used to indicate whether a response to the first heartbeat keep-alive broadcast message is required; and the second identifier bit is used to indicate the authentication type between the second device and the third device.

[0039] In conjunction with the third aspect, in some implementations of the third aspect, the authentication type includes same-account authentication type and different-account authentication type.

[0040] In conjunction with the third aspect, in some implementations of the third aspect, the length of the first identifier is related to the scenario in which the first device is applied.

[0041] In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: generating a third identifier based on the authentication method between the second device and the third device, wherein the third device is a device within the group to which the second device belongs; performing a hash calculation on the third identifier, and extracting the last N bits as the first identifier, wherein N is a positive integer.

[0042] In conjunction with the third aspect, in some implementations of the third aspect, 8 ≤ N ≤ 20.

[0043] In conjunction with the third aspect, in some implementations of the third aspect, before the second device broadcasts the first heartbeat keep-alive broadcast message, the method further includes: the second device determining that the performance of the second device meets the conditions for actively participating in keep-alive, or the second device determining that the application on the second device is in a running state.

[0044] Fourthly, a network keep-alive device is provided, the device comprising: a transceiver unit, configured to receive a first heartbeat keep-alive broadcast message from a second device, the first heartbeat keep-alive broadcast message indicating that the second device is in a network online state, the first heartbeat keep-alive broadcast message including a first identifier, the first identifier indicating the group to which the second device belongs; a processing unit, configured to match the first identifier with a second identifier to obtain a first matching result, wherein the second identifier indicates the group to which the device belongs; the processing unit is further configured to process the first heartbeat keep-alive broadcast message according to the first matching result.

[0045] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first identifier is generated based on the authentication method between the second device and the third device, wherein the third device is a device within the group to which the second device belongs.

[0046] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the first identifier further includes a first identifier bit and / or a second identifier bit; wherein the first identifier bit is used to indicate whether a response to the first heartbeat keep-alive broadcast message is required; and the second identifier bit is used to indicate the authentication type between the second device and the third device.

[0047] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the authentication type includes same-account authentication type and different-account authentication type.

[0048] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the length of the first identifier is related to the scenario in which the device is applied.

[0049] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is further configured to: generate the fourth identifier according to the authentication method between the device and the fourth device, wherein the fourth device is a device within the group to which the device belongs; perform a hash calculation on the fourth identifier, and extract the remaining M bits as the second identifier.

[0050] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the length of the first identifier is N bits and the length of the second identifier is M bits. The processing unit is further configured to: when N > M, match the content indicated by the last M bits of the first identifier with the second identifier to obtain the first matching result; or, when N < M, match the first identifier with the content indicated by the last N bits of the second identifier to obtain the first matching result.

[0051] In conjunction with the fourth aspect, in some implementations of the fourth aspect, 8 ≤ N ≤ 20, and / or 8 ≤ M ≤ 20.

[0052] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is further specifically used to: if the first matching result is a mismatch, discard the first heartbeat keep-alive broadcast message; or, if the first matching result is a match, maintain the network status with the second device according to the first heartbeat keep-alive broadcast message.

[0053] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the processing unit is further specifically used to: determine that the first matching result is a match, and maintain the networking status with the second device according to the first heartbeat keep-alive broadcast message.

[0054] In conjunction with the fourth aspect, in some implementations of the fourth aspect, the transceiver unit is further configured to receive a second heartbeat keep-alive broadcast message from the fifth device, the second heartbeat keep-alive broadcast message indicating that the fifth device is in a network online state, the second heartbeat keep-alive broadcast message including a fifth identifier, the fifth identifier indicating the group to which the fifth device belongs; the processing unit is further configured to: match the fifth identifier with the second identifier to obtain a second matching result; the processing unit is further configured to: determine that the second matching result is a mismatch, and the first device discards the second heartbeat keep-alive broadcast message.

[0055] Fifthly, a network keep-alive device is provided, comprising: a processing unit for generating a first heartbeat keep-alive broadcast message, the first heartbeat keep-alive broadcast message indicating that the device is in a network online state, the first heartbeat keep-alive broadcast message including a first identifier, the first identifier indicating the group to which the device belongs; and a transceiver unit for broadcasting the first heartbeat keep-alive broadcast message.

[0056] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the first identifier further includes a first identifier bit and / or a second identifier bit; wherein the first identifier bit is used to indicate whether a response to the first heartbeat keep-alive broadcast message is required; and the second identifier bit is used to indicate the authentication type between the device and the third device.

[0057] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the authentication type includes same-account authentication type and different-account authentication type.

[0058] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the length of the first identifier is related to the scenario in which the first device is applied.

[0059] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to: generate a third identifier based on the authentication method between the device and the third device, wherein the third device is a device within the group to which the device belongs; perform a hash calculation on the third identifier, and extract the last N bits as the first identifier, wherein N is a positive integer.

[0060] In conjunction with the fifth aspect, in some implementations of the fifth aspect, 8 ≤ N ≤ 20.

[0061] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the processing unit is further configured to: determine that the performance of the device meets the conditions for actively participating in keep-alive, or determine that the application on the device is in a running state.

[0062] A sixth aspect provides a network keep-alive device, comprising: one or more processors; a memory; and one or more computer programs. The one or more computer programs are stored in the memory, and the one or more computer programs include instructions. When the instructions are executed by the network keep-alive device, the network keep-alive device performs the method of the second aspect or any possible implementation thereof.

[0063] A seventh aspect provides a network keep-alive device, comprising: one or more processors; a memory; and one or more computer programs. The one or more computer programs are stored in the memory, and the one or more computer programs include instructions. When the instructions are executed by the network keep-alive device, the network keep-alive device performs the method described in the third aspect or any possible implementation thereof.

[0064] Eighthly, a computer program product comprising instructions is provided, which, when executed on a first device, causes the first device to perform the method described in the second aspect or the method described in the second aspect.

[0065] Ninth aspect, a computer program product including instructions is provided, which, when run on a second device, causes the second device to perform the method described in the third aspect or the method described in the third aspect.

[0066] A tenth aspect provides a computer-readable storage medium that may be non-volatile. The storage medium includes instructions that, when executed on a first device, cause the first device to perform the methods described in the second aspect or the method described in the second aspect.

[0067] Eleventhly, a computer-readable storage medium is provided, which may be non-volatile. The storage medium includes instructions that, when executed on a second device, cause the second device to perform the methods described in the third aspect or the method described in the third aspect.

[0068] In a twelfth aspect, a chip is provided, comprising at least one processor and an interface circuit, the interface circuit being configured to provide program instructions or data to the at least one processor, the at least one processor being configured to execute the program instructions to implement the second aspect or the method described in the second aspect, or to implement the third aspect or the method described in the third aspect. Attached Figure Description

[0069] Figure 1 This is a schematic diagram of the architecture of an example industrial communication system applicable to embodiments of this application.

[0070] Figure 2 This is a schematic diagram of the architecture of an example non-industrial communication system applicable to embodiments of this application.

[0071] Figure 3 This is a schematic diagram of the hardware structure of a terminal device provided in an embodiment of this application.

[0072] Figure 4 This is a software structure block diagram of a terminal device provided in an embodiment of this application.

[0073] Figure 5 An example provided for an embodiment of this application Figure 2 The diagram shows the four heartbeat keep-alive broadcast messages sent by mobile phone 201.

[0074] Figure 6 An example provided for an embodiment of this application Figure 2 The image shows an example of a heartbeat keep-alive broadcast message sent by mobile phone 201.

[0075] Figure 7 This is a schematic flowchart illustrating a network keep-alive method provided in an embodiment of this application.

[0076] Figure 8 This is a schematic diagram of an example communication system provided in an embodiment of this application.

[0077] Figure 9 This is a schematic structural diagram of an example device provided in an embodiment of this application.

[0078] Figure 10 This is a schematic structural diagram of another device provided in the embodiments of this application. Detailed Implementation

[0079] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0080] 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, "plural" or "multiple" refers to two or more than two.

[0081] Hereinafter, the terms "first" and "second" 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" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0082] To facilitate understanding of the embodiments of this application, the terminology involved in the embodiments of this application will be briefly explained first.

[0083] 1. Same account authentication: This is a device digital certificate derived from the same user account. The characteristic of this type of digital certificate is that if the device accounts are the same, the digital certificates of the devices share a common public key. Conversely, if the devices belong to different accounts, the digital certificates of the devices cannot authenticate each other.

[0084] 2. No account authentication: This is a device authentication method based on a temporary personal identification number (PIN) or a random value known to both parties, using a symmetric key. Devices without this random value cannot be authenticated.

[0085] 3. Cross-account authentication: This method involves two devices using different accounts. Each device generates its own device certificate after encryption using an asymmetric encryption algorithm. The accessed device, after user-specific authorization (such as entering a password, facial recognition, or fingerprint authentication), exchanges its device certificate with the accessing device. The digital certificates of these two devices share a common public key. Conversely, if the devices belong to different accounts, their digital certificates cannot authenticate each other. Authentication can succeed if devices share a public key, but not if they do not.

[0086] 4. User Identifier (UID): This indicates the UID corresponding to the same account. In other words, the UID corresponding to the same account is the same.

[0087] 5. Device Identifier (ID): Used to indicate the device.

[0088] To facilitate understanding of the embodiments of this application, the communication system applicable to the methods provided in the embodiments of this application will first be introduced.

[0089] Figure 1 This is a schematic diagram of the architecture of an industrial communication system 100 applicable to embodiments of this application.

[0090] For example, such as Figure 1 As shown, the industrial communication system 100 may include an industrial intranet, which is mainly used for networking industrial equipment in an industrial production environment. At least one core network device may be deployed in this industrial intranet, such as... Figure 1 The core network device 110 shown is shown.

[0091] like Figure 1 As shown, the industrial communication system 100 may also include at least one access network device 130.

[0092] This application embodiment does not limit the communication method between the access network device 130 and the core network device 110. For example, the access network device 130 can establish a wireless link with the core network device 110 through the gateway 120, or the access network device 130 can directly establish a wireless link with the core network device 110 to realize communication between the access network device 130 and the core network device 110.

[0093] The industrial communication system 100 may also include at least one industrial device, such as Figure 1 Industrial equipment 108, industrial equipment 107 and industrial equipment 117 are shown.

[0094] The embodiments of this application do not limit the type of industrial equipment. For example, the industrial equipment may include machine tools, mechanical equipment, instruments and meters, etc.

[0095] This application embodiment does not limit the communication method between industrial equipment and access network equipment 130.

[0096] In some embodiments, the industrial equipment can establish a wireless link with the access network device 130 through at least one intermediate device to realize communication between the industrial equipment 108 and the access network device 130.

[0097] In one example, such as Figure 1 As shown, industrial equipment 108 establishes wireless links with access network equipment 130 through router 106, core router 105 and firewall 104 respectively.

[0098] This application embodiment does not limit the communication method between router 106 and industrial device 108. For example, industrial device 108 can communicate with router 106 through a wireless fidelity (Wi-Fi) network.

[0099] In another example, such as Figure 1 As shown, industrial equipment 107 establishes wireless links with access network equipment 130 through core router 105 and firewall 104 respectively.

[0100] This application embodiment does not limit the communication method between the core router 105 and the industrial device 107. For example, the industrial device 107 can communicate with the core router 105 through a local area network (LAN).

[0101] In yet another example, such as Figure 1 As shown, industrial equipment 112 establishes wireless links with access network equipment 130 through core router 105 and firewall 104 respectively.

[0102] This application embodiment does not limit the communication method between the core router 105 and the industrial device 112. For example, the industrial device 112 can communicate with the core router 105 through a controller area network (CAN) bus, a 485 bus, a programmable logic controller (PLC), or Zigbee technology.

[0103] In other embodiments, the industrial equipment can directly establish a wireless link with the access network device 130 to realize communication between the industrial equipment and the access network device 130.

[0104] Optionally, in some embodiments, the industrial communication system 100 may further include at least one data center 111, such as Figure 1 The data center 111 shown is an example. For instance, the functions of the data center 111 are not limited to sending, receiving, storing, and processing data.

[0105] This application embodiment does not limit the communication method between the data center 111 and the access network device 103.

[0106] For example, data center 111 establishes wireless links with access network device 130 through core router 105 and firewall 104 respectively.

[0107] This application embodiment does not limit the communication method between the core router 105 and the data center 111. For example, the data center 111 can communicate with the core router 105 via Ethernet.

[0108] Optionally, in some embodiments, the industrial communication system 100 may further include at least one non-industrial device (e.g., a personal user device), such as... Figure 1 The computer 110, tablet 109, mobile phone 113, and smartwatch 114 shown are shown.

[0109] This application does not limit the networking method for non-industrial equipment.

[0110] In some embodiments, the non-industrial device may be connected to an industrial intranet.

[0111] This application does not limit the method by which non-industrial equipment is connected to the industrial intranet.

[0112] In one example, both computer 110 and tablet computer 109 can establish wireless links with access network device 130 through router 106, core router 105 and firewall 104 to enable computer 110 and tablet computer 109 to connect to the industrial intranet.

[0113] This application embodiment does not limit the communication method between the computer 110 or tablet computer 109 and the router 106. For example, the computer 110 or tablet computer 109 can communicate with the router 106 via a Wi-Fi network.

[0114] In another example, mobile phone 113 can directly establish a wireless link with access network device 103 to achieve communication.

[0115] In other embodiments, the non-industrial device may be connected to an industrial external network. For example, mobile phone 113 may be connected to an industrial external network. This application does not limit the manner in which the non-industrial device is connected to the industrial external network.

[0116] Optionally, in some embodiments, if the industrial communication system 100 includes at least two non-industrial devices, these at least two non-industrial devices can also communicate. This application embodiment does not limit the communication method between these at least two non-industrial devices; for example, the at least two non-industrial devices can communicate via Bluetooth (BT) or Wi-Fi networks.

[0117] In such Figure 1 In the industrial communication system 100 shown, access network device 103 and mobile phone 113 can constitute a communication system; access network device 103 and tablet computer 109 can also constitute a communication system; access network device 103 and computer 110 can also constitute a communication system. Mobile phone 113 and smartwatch 114 can also constitute a communication system.

[0118] It should be noted that, Figure 1 The classification of industrial and non-industrial equipment is based on whether it is used in industrial production. If certain equipment is used to handle tasks in industrial production, it can also be called industrial equipment. For example, if computer 110 is used to handle data processing in industrial production, then computer 110 can also be called industrial equipment.

[0119] For example, Figure 1 The access network equipment shown can be any device with wireless transceiver capabilities. This equipment includes, but is not limited to: evolved NodeB (eNB or eNodeB), radio network controller (RNC), Node B (NB), base station controller (BSC), base transceiver station (BTS), home base station (e.g., home evolved NodeB, or home Node B, HNB), base band unit (BBU), access point (AP), wireless relay node, wireless backhaul node, transmission point (TP), or transmission and reception point (TRP) in a Wi-Fi system. It can also be a gNB in ​​a 5G system, such as NR, or a transmission point (TRP or TP), one or a group of antenna panels (including multiple antenna panels) of a base station in a 5G system, or a network node constituting a gNB or transmission point, such as a base band unit (BBU) or a distributed unit (DU).

[0120] In some deployments, a gNB may include a centralized unit (CU) and a DU. The gNB may also include a radio unit (RU). The CU implements some of the gNB's functions, and the DU implements others. For example, the CU implements radio resource control (RRC) and packet data convergence protocol (PDCP) layer functions, while the DU implements radio link control (RLC), media access control (MAC), and physical (PHY) layer functions. Since RRC layer information ultimately becomes PHY layer information, or is derived from PHY layer information, in this architecture, higher-layer signaling, such as RRC layer signaling, can be considered to be sent by the DU, or by the DU+CU. It is understood that access network equipment can be a CU node, a DU node, or a device including both CU and DU nodes. Furthermore, the CU can be classified as an access network device in the radio access network (RAN) or as an access network device in the core network (CN), and this application does not limit it in this way.

[0121] It should also be understood that Figure 1The industrial and / or non-industrial equipment may also be referred to as: terminal equipment or user equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device. In the embodiments of this application, the terminal equipment may be a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. The embodiments of this application do not limit the application scenarios.

[0122] In this embodiment, the terminal device or access network device includes a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software. Furthermore, this embodiment does not specifically limit the specific structure of the execution entity of the method provided in this embodiment, as long as it can communicate according to the method provided in this embodiment by running a program that records the code of the method provided in this embodiment. For example, the execution entity of the method provided in this embodiment can be a terminal device or access network device, or a functional module in the terminal device or access network device that can call and execute a program.

[0123] It should be noted that, Figure 1 The devices shown can also communicate with each other. This application embodiment describes... Figure 1 The communication methods between the devices shown are not limited. In one example... Figure 1The non-industrial and / or industrial equipment shown can communicate via access network devices. In another example, Figure 1 The non-industrial and / or industrial equipment shown can communicate directly. This application's embodiments... Figure 1 The communication method used for direct communication between the devices shown is not limited. In yet another example, Figure 1 The non-industrial equipment and / or industrial equipment can communicate directly with the access network equipment.

[0124] It should be noted that, Figure 1 The industrial communication system 100 shown is merely an example and should not be construed as limiting this application. For example, the industrial communication system 100 may also include more or fewer devices.

[0125] Figure 2 This is a schematic diagram of the architecture of a non-industrial communication system 200 applicable to embodiments of this application.

[0126] The non-industrial communication system 200 may include at least one terminal device, such as Figure 2 The device shown includes a mobile phone 201, a smart TV 202, a tablet computer 203, a computer 204, a smart speaker 205, a mobile phone 206, and a smartwatch 207. Among these, mobile phone 201, smart TV 202, and tablet computer 203 can constitute a communication system. Mobile phone 201, computer 204, and smart speaker 205 can constitute a communication system. Mobile phone 201, mobile phone 206, and smartwatch 207 can constitute a communication system.

[0127] It should be noted that this application does not limit the type of terminal equipment included in the non-industrial communication system 200. The type of terminal equipment can be as described above, and no specific examples will be given here.

[0128] Figure 2 The devices shown can also communicate with each other. This application embodiment describes... Figure 2 The communication methods between the various devices shown are not limited.

[0129] It should be noted that the embodiments of this application can also be applied to another communication system, which includes... Figure 1 The industrial communication system 100 shown and Figure 2 The non-industrial communication system 200 is shown. The industrial communication system 100 and the non-industrial communication system 200 are described above and will not be repeated here.

[0130] Below, in conjunction with Figure 3 and Figure 4 The structure of the terminal device involved in the embodiments of this application will be described.

[0131] For example, Figure 3A schematic diagram of the terminal device 900 is shown. The terminal device 900 may include a processor 910, an external memory interface 920, an internal memory 921, a universal serial bus (USB) interface 930, a charging management module 940, a power management module 941, a battery 942, antenna 1, antenna 2, a mobile communication module 950, a wireless communication module 960, an audio module 970, a speaker 970A, a receiver 970B, a microphone 970C, a headphone jack 970D, a sensor module 980, buttons 990, a motor 991, an indicator 992, a camera 993, a display screen 994, and a subscriber identification module (SIM) card interface 995, etc.

[0132] This application embodiment does not limit the types of sensors included in the sensor module 980. For example, the sensor module 980 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0133] It is understood that the structure illustrated in the embodiments of this application does not constitute a specific limitation on the terminal device 900. In other embodiments of this application, the terminal device 900 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.

[0134] The processor 910 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0135] The controller can serve as the central nervous system and command center of the terminal device 900. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0136] The processor 910 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 910 is a cache memory. This memory can store instructions or data that the processor 910 has just used or that are used repeatedly. If the processor 910 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 910, and thus improves the efficiency of the system.

[0137] In some embodiments, the processor 910 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0138] 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 terminal device 900. In other embodiments of this application, the terminal device 900 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0139] The charging management module 940 receives charging input from a charger, which can be either a wireless or wired charger. The power management module 941 connects the battery 942, the charging management module 940, and the processor 910. The power management module 941 receives input from the battery 942 and / or the charging management module 940, supplying power to the processor 910, internal memory 921, external memory, display 994, camera 993, and wireless communication module 960, etc. The power management module 941 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance).

[0140] The wireless communication function of the terminal device 900 can be implemented through antenna 1, antenna 2, mobile communication module 950, wireless communication module 960, modem processor and baseband processor.

[0141] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in terminal device 900 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0142] The mobile communication module 950 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the terminal device 900. The mobile communication module 950 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 950 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 950 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 950 may be housed in the processor 910. In some embodiments, at least some functional modules of the mobile communication module 950 and at least some modules of the processor 910 may be housed in the same device.

[0143] The wireless communication module 960 can provide solutions for wireless communication applications on the terminal device 900, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 960 can be one or more devices integrating at least one communication processing module. The wireless communication module 960 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 910. The wireless communication module 960 can also receive signals to be transmitted from processor 910, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0144] In some embodiments, antenna 1 of terminal device 900 is coupled to mobile communication module 950, and antenna 2 is coupled to wireless communication module 960, enabling terminal device 900 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0145] The terminal device 900 implements display functions through a GPU, a display screen 994, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 994 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 910 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0146] Display screen 994 is used to display images, videos, etc. Display screen 994 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, terminal device 900 may include one or N displays 994, where N is a positive integer greater than 1.

[0147] The terminal device 900 can perform shooting functions through an ISP, camera 993, video codec, GPU, display 994, and application processor.

[0148] The ISP is used to process data fed back from the camera 993. The ISP can also perform algorithmic optimizations on image noise, brightness, and skin tone. The ISP can also optimize parameters such as exposure and color temperature of the shooting scene. In some embodiments, the ISP can be integrated into the camera 993.

[0149] Camera 993 is used to capture still images or videos. An object is projected onto a photosensitive element by generating an optical image through the lens. The photosensitive element can be a charge-coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, which is then passed to an ISP for conversion into a digital image signal. The ISP outputs the digital image signal to a DSP for processing. The DSP converts the digital image signal into image signals in standard RGB, YUV, or other formats. In some embodiments, the terminal device 900 may include one or N cameras 993, where N is a positive integer greater than 1.

[0150] A digital signal processor (DSP) is used to process digital signals. Besides digital image signals, it can also process other digital signals. For example, when the terminal device 900 is selecting a frequency, the DSP is used to perform Fourier transforms on the frequency energy.

[0151] Video codecs are used to compress or decompress digital video. Terminal device 900 may support one or more video codecs. Thus, terminal device 900 can play or record video in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0152] NPU stands for Neural Network (NN) Computing Processor. By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in terminal devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0153] The external memory interface 920 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the terminal device 900. The external memory card communicates with the processor 910 through the external memory interface 920 to perform data storage functions.

[0154] Internal memory 921 can be used to store computer executable program code, which includes instructions. Processor 910 executes various functional applications and data processing of terminal device 900 by running the instructions stored in internal memory 921. Internal memory 921 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of terminal device 900 (such as audio data, phonebook, etc.). Furthermore, internal memory 921 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0155] Terminal device 900 can implement audio functions such as music playback and recording through audio module 970, speaker 970A, receiver 970B, microphone 970C, headphone jack 970D, and application processor.

[0156] The audio module 970 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 970 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 970 may be located in the processor 910, or some functional modules of the audio module 970 may be located in the processor 910.

[0157] The speaker 970A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The terminal device 900 can listen to music or make hands-free calls through the speaker 970A.

[0158] The receiver 970B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the terminal device 900 answers a phone call or voice message, the receiver 970B can be brought close to the listener's ear to hear the voice.

[0159] Microphone 970C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 970C, inputting the sound signal into microphone 970C. Terminal device 900 may have at least one microphone 970C. In some embodiments, terminal device 900 may have two microphones 970C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, terminal device 900 may have three, four, or more microphones 970C, which can collect sound signals, reduce noise, identify the sound source, and perform directional recording, etc.

[0160] The 970D headphone jack is used to connect wired headphones. The 970D headphone jack can be a USB 930 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0161] Buttons 990 include a power button, volume buttons, etc. Buttons 990 can be mechanical buttons or touch-sensitive buttons. Terminal device 900 can receive button input and generate key signal inputs related to user settings and function control of terminal device 900.

[0162] Motor 991 can generate vibration alerts. Motor 991 can be used for incoming call vibration alerts or for touch vibration feedback.

[0163] Indicator 992 can be an indicator light, used to indicate charging status, power changes, or to indicate messages, missed calls, notifications, etc.

[0164] The SIM card interface 995 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 995 to establish contact with and disconnect from the terminal device 900. The terminal device 900 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The SIM card interface 995 can support Nano SIM cards, Micro SIM cards, and other SIM cards. Multiple cards can be inserted into the same SIM card interface 995 simultaneously. The multiple cards can be of the same or different types. The SIM card interface 995 is also compatible with different types of SIM cards. The SIM card interface 995 is also compatible with external memory cards. The terminal device 900 interacts with the network through the SIM card to achieve functions such as voice calls and data communication. In some embodiments, the terminal device 900 uses an embedded SIM (eSIM) card. The eSIM card can be embedded in the terminal device 900 and cannot be separated from it.

[0165] It should be understood that the phone cards in the embodiments of this application include, but are not limited to, SIM cards, eSIM cards, universal subscriber identity modules (USIM), universal integrated circuit cards (UICC), etc.

[0166] The software system of the terminal device 900 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture. Taking the system as an example, the software structure of the terminal device 900 is illustrated.

[0167] Figure 4 This is a software structure block diagram of a terminal device 900 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 following is omitted as the text is incomplete and requires further context]. The system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer. The application layer can include a series of application packages.

[0168] like Figure 4 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, and SMS.

[0169] 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.

[0170] like Figure 4 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, etc.

[0171] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0172] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0173] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0174] The phone manager is used to provide communication functions for terminal devices 900. For example, it manages call status (including connection and disconnection).

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

[0176] 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 the device, and flashing indicator lights.

[0177] The Android Runtime consists of core libraries and a virtual machine. The Android runtime is responsible for the scheduling and management of the Android system.

[0178] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0179] 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.

[0180] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0181] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0182] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

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

[0184] A 2D graphics engine is a graphics engine for 2D drawing.

[0185] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0186] It should be understood that the technical solutions in the embodiments of this application can be used for In systems such as...

[0187] Whether Figure 1 The communication system 100 shown is still... Figure 2 The communication system 200 shown in the diagram requires each device in the communication system to establish a connection with each other before they can communicate.

[0188] Optionally, in some embodiments, after the devices establish a connection, they may also need to authenticate each other. This application does not limit the authentication method between devices.

[0189] Here, with Figure 2 The communication system shown is used as an example to illustrate the authentication methods between devices. It should be understood that this example description should not be construed as limiting this application.

[0190] In one example, different devices can be authenticated using the same account.

[0191] For example, such as Figure 2 As shown, in the communication system consisting of mobile phone 201, smart TV 202, and tablet computer 203, if account 1 is logged in on all three devices, they can authenticate each other by logging into the same account 1. Once authentication is successful, mobile phone 201, smart TV 202, and tablet computer 203 form a group.

[0192] In another example, authentication between devices can be performed without an account.

[0193] For example, such as Figure 2 As shown, in the communication system consisting of mobile phone 201 and computer 204, if mobile phone 201 is logged into account 1, but computer 204 is not logged into an account, then mobile phone 201 and computer 204 can authenticate each other using the first PIN code. In this case, it can be considered that mobile phone 201 and computer 204 are authenticating without an account. If the authentication between mobile phone 201 and computer 204 is successful, mobile phone 201 and computer 204 form a group. For example, as... Figure 2 As shown, in the communication system consisting of mobile phone 201 and smart speaker 205, if mobile phone 201 is logged into account 1, but smart speaker 205 is not logged into an account, then mobile phone 201 and smart speaker 205 can authenticate each other using a second PIN code. In this case, it can be considered that mobile phone 201 and smart speaker 205 are authenticating without an account. If the authentication between mobile phone 201 and smart speaker 205 is successful, mobile phone 201 and smart speaker 205 form a group.

[0194] In yet another instance, authentication can be performed between devices across accounts.

[0195] For example, such as Figure 2 As shown, in the communication system consisting of mobile phone 201, mobile phone 206, and smartwatch 207, if mobile phone 201 is logged into account 1, mobile phone 206 is logged into account 2, and smartwatch 207 is logged into account 2, and account 1 and account 2 are two mutually bound accounts, then mobile phone 201 and mobile phone 206 can authenticate each other through these two bound accounts, and mobile phone 201 and smartwatch 207 can also authenticate each other through these two bound accounts. If mobile phone 201 successfully authenticates with both mobile phone 206 and smartwatch 207, then mobile phone 201 and mobile phone 206 form one group, and mobile phone 201 and smartwatch 207 form another group.

[0196] After each device completes authentication, it can be considered that devices that have completed mutual authentication are trusted devices, or that devices that have completed mutual authentication have a trusted relationship.

[0197] In some embodiments, after each device completes authentication, the devices may also exchange information with each other (e.g., device name, address, type, etc.).

[0198] For ease of description, the process of establishing connections between devices, the authentication process, and the exchange of information between them are collectively referred to as the networking process.

[0199] After the various devices are networked, it is necessary to maintain an end-to-end device status awareness capability, that is, a device needs to be able to perceive the online or offline status of the devices in its network. Currently, based on different types of device authentication, devices can perceive the device status among the fully authenticated networked devices through heartbeat keep-alive broadcast messages. The specific process is as follows:

[0200] First, the sending end carries the target device identifier in the heartbeat keep-alive broadcast message and periodically sends this heartbeat keep-alive broadcast message to maintain the device in a "network online" state. For example, this heartbeat keep-alive broadcast message can sense the device status within the communication system through screen wake-up or sensing device online / offline status, thereby supporting distributed services to be aware of the status of devices within the network at all times.

[0201] Then, after receiving the heartbeat keep-alive broadcast message from the sender, the receiving end matches the target device identifier carried in the heartbeat keep-alive broadcast message with its own identifier. If the target device identifier matches the receiving end's identifier, the receiving end can further process the heartbeat keep-alive broadcast message. For example, if the receiving end determines that it is not networked with the sender, it can first establish a network with the sender and then maintain the device's online status; if the receiving end is already networked with the sender, it directly maintains the device's online status. If the target device identifier does not match the receiving end's identifier, it is assumed that there is no relationship between the sender and the receiving end. In this case, the heartbeat keep-alive broadcast message can be discarded to avoid interference or abnormal wake-up between unrelated devices.

[0202] The heartbeat keep-alive broadcast message can have a maximum of 7.5 bytes of AD data field area used to fill the target device (i.e., the device receiving the broadcast message) identification field. One approach is to fill the AD data field area with a user identifier field for the same account; this UID field occupies 2 bytes. Another approach is to fill the AD data field area with a device ID field; this device ID field occupies 5.5 bytes. Since the heartbeat keep-alive broadcast message can have a maximum of 7.5 bytes of AD data field area used to fill the target device identification field, the AD data field area of ​​a heartbeat keep-alive broadcast message can simultaneously contain a maximum of one UID field and one device ID field. The UID in the UID field and the device ID in the device ID field can be referred to as characteristic values.

[0203] In a real network environment, a device may be in multiple groups. If the target device identifier carried in a heartbeat keep-alive broadcast message is too small, the sender may send multiple heartbeat keep-alive broadcast messages, making the process of keeping the device in the "network online" state time-consuming and inefficient, thus resulting in a poor user experience.

[0204] For example, as mentioned above Figure 2 As described, mobile phone 201, smart TV 202, and tablet computer 203 form one group (referred to as group 1); mobile phone 201 and computer 204 form another group (referred to as group 2); mobile phone 201 and smart speaker 205 form another group (referred to as group 3); mobile phone 201 and mobile phone 206 form another group (referred to as group 4); and mobile phone 201 and smartwatch 207 form another group (referred to as group 5). Therefore, mobile phone 201 is in five groups, including one group with the same account authentication (group 1) and four groups with different account authentication (groups 2, 3, 4, and 5).

[0205] At this point, if mobile phone 201 needs to send a heartbeat keep-alive broadcast message, mobile phone 201 needs to send at least 4 heartbeat keep-alive broadcast messages.

[0206] Figure 5 for Figure 2 The diagram shows the four heartbeat keep-alive broadcast messages sent by mobile phone 201.

[0207] As described above, a heartbeat keep-alive broadcast message can carry at most one UID and one device ID. Therefore, a heartbeat keep-alive broadcast message sent by mobile phone 201 can carry at most one UID and one device ID.

[0208] For example, such as Figure 5As shown, in the first round, mobile phone 201 sends a heartbeat keep-alive broadcast message 301. The target device identifier field filled in the AD data field area of ​​this heartbeat keep-alive broadcast message 301 is UID-1 and ID-1. Among them, UID-1 is the UID corresponding to account 1 mentioned above, and ID-1 is the ID corresponding to computer 204 mentioned above. In this way, through the heartbeat keep-alive broadcast message 301, mobile phone 201 can not only keep the devices (smart TV 202 and tablet computer 203) in group 1 to which mobile phone 201 belongs in a "network online" state, but also keep the devices (computer 204) in group 2 to which mobile phone 201 belongs in a "network online" state.

[0209] Since phone 210 is only in one group (Group 1) with the same account authentication, phone 201 will not carry the UID in subsequent heartbeat keep-alive broadcast messages, only the device ID. Furthermore, as described above, a heartbeat keep-alive broadcast message can carry a maximum of one ID.

[0210] In the second round, mobile phone 201 sends a heartbeat keep-alive broadcast message 302. The target device identifier field filled in the AD data field area of ​​this heartbeat keep-alive broadcast message 302 is ID-2. Here, ID-2 is the ID corresponding to the smart speaker 205 mentioned above. In this way, mobile phone 201 can maintain the device (smart speaker 205) in a "network online" state within group 3 to which mobile phone 201 belongs through the heartbeat keep-alive broadcast message 302.

[0211] In the third round, mobile phone 201 sends a heartbeat keep-alive broadcast message 303. The target device identifier field filled in the AD data field area of ​​this heartbeat keep-alive broadcast message 303 is ID-3. Here, ID-3 is the ID corresponding to mobile phone 206 mentioned above. In this way, mobile phone 201 can maintain the device (mobile phone 206) in a "network online" state within group 4 to which mobile phone 201 belongs through the heartbeat keep-alive broadcast message 303.

[0212] In the fourth round, mobile phone 201 sends a heartbeat keep-alive broadcast message 304. The target device identifier field filled in the AD data field area of ​​this heartbeat keep-alive broadcast message 304 is ID-4. Here, ID-4 is the ID corresponding to the smartwatch 207 mentioned above. In this way, mobile phone 201 can maintain the device (smartwatch 207) in a "network online" state within group 5 to which mobile phone 201 belongs through the heartbeat keep-alive broadcast message 304.

[0213] It should be noted that the above text Figure 5 The order of the four heartbeat keep-alive broadcast messages sent by the mobile phone 201 in the above description is merely an example and should not constitute a limitation on this application.

[0214] To further shorten the time required to keep multiple devices in a "networked online" state and improve the efficiency of keeping multiple devices in a "networked online" state, this application provides a new structure for a heartbeat keep-alive broadcast message. The identifier carried in this new heartbeat keep-alive broadcast message indicates the group to which the device belongs. In this way, multiple devices can maintain a "networked online" state based on their respective groups, thereby helping to improve the user experience.

[0215] For ease of description, the heartbeat keep-alive broadcast message mentioned above will be referred to as heartbeat keep-alive broadcast message 1, and the new heartbeat keep-alive broadcast message will be referred to as heartbeat keep-alive broadcast message 2.

[0216] The structure of the heartbeat keep-alive broadcast message 2 provided in the embodiments of this application will be described in detail below.

[0217] The heartbeat keep-alive broadcast message 2 includes a first identifier, which indicates the group to which the device belongs.

[0218] The embodiments of this application do not limit the name of the first identifier; any identifier used to indicate the group to which a device belongs can be considered the first identifier. It should be understood that the following description uses the Trust Group ID (TGID) as an example of the first identifier, which should not constitute a limitation on the embodiments of this application.

[0219] The TGID is generated based on the authentication method between devices. This application does not limit the authentication method between devices; specific examples have been described above and will not be repeated here.

[0220] Specifically, in one example, a group ID can be generated first based on the authentication method between devices. Then, the group ID is hashed, and the last M bits are truncated as the final TGID.

[0221] This application does not limit the specific value of M in its embodiments. It can be set according to actual needs. For details on how to set M according to actual needs, please refer to the description below, which will not be repeated here.

[0222] It should be noted that there is a one-to-one correspondence between authentication methods and TGIDs; that is, the same authentication method corresponds to one TGID. It should be understood that "same authentication method" refers not only to the same type of authentication method, but also to the same authentication process.

[0223] For example, such as Figure 2As shown, mobile phone 201, smart TV 202, and tablet computer 203 are authenticated using the same account. Therefore, mobile phone 201, smart TV 202, and tablet computer 203 belong to the same group. After hashing this group ID, the resulting 8 bits (if M=8) are 00000001. Therefore, 00000001 is the TGID corresponding to the group to which mobile phone 201, smart TV 202, and tablet computer 203 belong.

[0224] For example, such as Figure 2 As shown, mobile phone 201 and computer 204 are authenticated using the first PIN code, therefore, mobile phone 201 and computer 204 belong to the same group. After hashing this group ID, the resulting 8 bits (if M=8) are 00000010, then 00000010 is the TGID corresponding to the group to which mobile phone 201 and computer 204 belong.

[0225] For example, such as Figure 2 As shown, mobile phone 201 and smart speaker 205 are authenticated via the second PIN code, therefore, mobile phone 201 and smart speaker 205 belong to the same group. After hashing this group ID, the resulting 8 bits (if M=8) are 00000011, which is the TGID corresponding to the group to which mobile phone 201 and smart speaker 205 belong.

[0226] For example, such as Figure 2 As shown, mobile phones 201, 206, and smartwatch 207 are authenticated through cross-account (account 1 and account 2). Therefore, mobile phones 201, 206, and smartwatch 207 belong to the same group. After hashing this group ID, the resulting 8 bits (if M=8) are 00000100. Therefore, 00000100 is the TGID corresponding to the group to which mobile phones 201, 206, and smartwatch 207 belong.

[0227] It should be noted that the 00000001, 00000010, 00000011, and 00000100 mentioned above are examples of TGID in binary form and should not constitute a limitation on the embodiments of this application. For example, the TGID can be represented not only in pure number form but also in string form.

[0228] Therefore, in the embodiment of network keep-alive based on heartbeat keep-alive broadcast message 1, mobile phone 201 needs one UID and four device IDs to maintain the devices in the group to which mobile phone 201 belongs in a "network online" state. However, in the embodiment of network keep-alive based on heartbeat keep-alive broadcast message 2, mobile phone 201 only needs four TGIDs to maintain the devices in the group to which mobile phone 201 belongs in a "network online" state.

[0229] Furthermore, in the network keep-alive implementation based on heartbeat keep-alive broadcast message 1, the strong coupling between the same account UID or device ID and the current authentication type does not adequately satisfy the diversity of trusted types between devices and lacks scalability. This necessitates modifying the feature value structure of the keep-alive broadcast when expanding authentication types in the future. For example, in addition to supporting same account authentication and point-to-point accountless authentication, two devices may also support cross-account authentication and, in the future, cross-account-based shared authentication. Since keep-alive needs to cover devices with different trusted authentication types, the current format cannot meet the needs of future communication system service evolution. In contrast, in the network keep-alive implementation based on heartbeat keep-alive broadcast message 2, because the authentication method and TGID have a one-to-one correspondence, the TGID identifier can be compatible with various types of authentication methods between devices. Thus, when expanding authentication methods in the future, there is no need to modify the TGID structure, resulting in higher scalability of the heartbeat keep-alive broadcast message.

[0230] Optionally, in one example, the TGID may also include a flag bit for identifying whether a response to the heartbeat keep-alive broadcast message is required.

[0231] In this application embodiment, the length of the flag bit used to indicate whether a response to the heartbeat keep-alive broadcast message is required is not limited. For example, the flag bit used to indicate whether a response to the heartbeat keep-alive broadcast message is required can be 1 bit.

[0232] This application embodiment does not limit how the flag bit used to indicate whether or not to respond to the heartbeat keep-alive broadcast message indicates whether or not to respond to the heartbeat keep-alive broadcast message. For example, the flag bit used to indicate whether or not to respond to the heartbeat keep-alive broadcast message can be "1" to indicate that the heartbeat keep-alive broadcast message needs to be responded to, and "0" to indicate that the heartbeat keep-alive broadcast message does not need to be responded to.

[0233] Optionally, in one example, the TGID may also include a flag bit for identifying the authentication type.

[0234] This application does not limit the length of the identifier used to identify the authentication type. For example, the identifier used to identify the authentication type can be 1 bit.

[0235] This application does not limit the categories included in the TGID used to identify authentication types.

[0236] In one example, the TGID includes a classification of authentication methods corresponding to the identifiers used to identify authentication types, which can be one-to-one with the authentication methods described above.

[0237] For example, the identifier bit used to identify the authentication type can be "0" to indicate authentication type through the same account, "1" to indicate authentication type through cross-account, "2" to indicate authentication type through PIN code, "3" to indicate authentication type through cross-account, and so on.

[0238] In another example, the TGID includes an authentication method corresponding to the authentication type, which can be divided into two categories based on whether it is an authentication method for the same account: one is the authentication type for the same account, and the other is the authentication type for different accounts.

[0239] For example, the flag bit used to identify the authentication type uses "1" to indicate authentication type for the same account and "0" to indicate authentication type for different accounts.

[0240] It should be noted that the "0", "1" and "2" mentioned above are examples of identifier bits used to identify the authentication type, and should not constitute a limitation on the embodiments of this application. The embodiments of this application do not limit how the authentication type is identified.

[0241] It should be understood that any method that does not involve authentication through the same account is considered a non-same-account authentication type. For example, cross-account authentication, PIN codes, or authentication using random values ​​known to both parties can all be considered non-same-account authentication types.

[0242] Since devices that have completed mutual authentication have a trusted relationship, the degree of trust between the sender and receiver can be determined by the identifier used to identify the authentication type.

[0243] This application does not limit the classification of the degree of trust relationship between the sending end and the receiving end in the embodiments.

[0244] In one example, the degree of trust between the sender and receiver and the authentication method can be one-to-one.

[0245] For example, the level of trust between the sender and receiver can be pre-defined for different authentication methods. For instance, it can be pre-defined that the level of trust decreases sequentially for same-account authentication, cross-account authentication, PIN code, or authentication using a random value known to both parties.

[0246] In another example, the degree of trust between the sender and receiver and the authentication method can be many-to-one.

[0247] For example, it can be preset that the degree of trust between the sender and receiver corresponding to the authentication method of the same account is high, and the degree of trust between the sender and receiver corresponding to the authentication method of different accounts is medium to low.

[0248] By assessing the degree of trust between the sender and receiver, the receiver can determine the level of protection afforded to the user's privacy data on the receiver, from the sender's perspective. Specifically, the degree of trust between the sender and receiver is inversely proportional to the level of protection afforded to the user's privacy data on the receiver. In other words, the higher the degree of trust between the sender and receiver, the lower the level of protection afforded to the user's privacy data on the receiver, meaning the receiver can share the user's privacy data with the sender.

[0249] For example, if the identifier included in the TGID identifies the authentication method for the same account, then the sender and receiver can be considered personal devices, meaning they belong to the same person. The receiver can then determine that, from the sender's perspective, the user's privacy data on the receiver is poorly protected. Therefore, the receiver can share the user's privacy data on the receiver with the sender.

[0250] For example, if the identifier included in the TGID that identifies the authentication type is a different account authentication method, then it can be assumed that the sender and receiver may not belong to the same personal device; that is, the sender and receiver may not belong to the same person. Therefore, the receiver can determine that, from the sender's perspective, the user's privacy data on the receiver is highly protected. Consequently, the receiver may not share the user's privacy data on the receiver with the sender.

[0251] Alternatively, in one example, a user can find the various groups to which the device belongs and the group members within each group.

[0252] This application does not limit the method by which a user searches for the various groups to which the device belongs and the group members within each group. For example, a user can bring up a control center interface, which can display the various groups to which the device belongs and the group members within each group.

[0253] This application does not limit the form in which group members within a device's group are presented on the device. For example, group members within a device's group can be presented on the device in the form of the device name.

[0254] Optionally, in one example, a user can also find the authentication method or type between the device and group members within the various groups to which the device belongs.

[0255] This application does not limit the method by which a user searches for the various groups to which the device belongs and the authentication methods or types among group members within each group. For example, a user can bring up a control center interface, which can display the various groups to which the device belongs and the authentication methods or types among group members within each group.

[0256] This application embodiment does not limit the form in which the authentication method or authentication type between group members within the group to which the device belongs is presented on the device.

[0257] In this embodiment of the application, the order of the group ID, the flag indicating whether a response to the heartbeat keep-alive broadcast message is required, and the flag indicating the authentication type in the TGID is not limited. For example, in the TGID, the group ID, the flag indicating whether a response to the heartbeat keep-alive broadcast message is required, and the flag indicating the authentication type can be arranged in the following order: the flag indicating whether a response to the heartbeat keep-alive broadcast message is required, the flag indicating the authentication type, and the group ID.

[0258] As can be seen from the above description of the structure of the heartbeat keep-alive broadcast message 2, since the number of bits M extracted after hashing the group ID in the heartbeat keep-alive broadcast message 2 is indefinite, the length of the TGID is also indefinite.

[0259] To further avoid TGID conflicts, specifically to prevent different groups of devices from corresponding to the same TGID, M can be set according to different scenarios.

[0260] In one example, the length of a TGID can be set according to the sensitivity of different scenarios to TGID conflicts. For instance, in applications with a small number of devices, where TGID conflicts do not occur, the requirement for the maximum number of TGIDs is considered low, and M can be set smaller. Conversely, in applications with a large number of devices, where TGID conflicts do not occur, the requirement for the maximum number of TGIDs is considered high, and M can be set larger. In other words, the values ​​of M and the maximum number of TGIDs can be set to have a positive correlation.

[0261] For example, the relationship between the number of TGIDs K and M can be found in the formula (1) for calculating the conflict rate, as follows:

[0262]

[0263] The collision rate formula can be understood as the relationship between K and M when the probability of a hash collision occurring between a maximum of K TGIDs is 0. Therefore, based on the collision rate calculation formula and the scenario, the length of the corresponding TGID can be set.

[0264] It should be noted that M in the above formula for calculating the collision rate represents the number of bits. If the TGID length is represented in bits, the number of bits M and the bit value N satisfy formula (2): M = 2 N .

[0265] Optionally, in some embodiments, different TGID strategies (parameters corresponding to TGIDs) can be set for different scenarios. The values ​​for TGID level, TGID length, and maximum number of TGIDs differ for each TGID strategy, thus resulting in a different number of TGIDs included in each heartbeat keep-alive broadcast message.

[0266] The maximum number of TGIDs can be understood as the probability of a TGID collision being 0 when the total number of TGIDs is less than the maximum number of TGIDs.

[0267] The number of TGID policies is not limited in the embodiments of this application.

[0268] Tables 1 and 2 illustrate the TGID strategies for two application scenarios. It should be understood that Tables 1 and 2 are merely examples and should not be construed as limiting the embodiments of this application.

[0269] The values ​​of TGID length (in bits) and maximum TGID data shown in Tables 1 and 2 are obtained according to formulas (1) and (2) described above. It should be noted that in this embodiment, the values ​​of M and the maximum number of TGIDs only need to satisfy a positive correlation, and do not necessarily need to be set to satisfy formula (1) described above.

[0270] The number of TGIDs included in each heartbeat keep-alive broadcast message shown in Tables 1 and 2 can be obtained by rounding down the ratio of the size of the TGID field that can be filled in heartbeat keep-alive broadcast message 2 to the length of a single TGID. It should be noted that Tables 1 and 2 use a 7.5-byte (60-bit) size for the TGID field in heartbeat keep-alive broadcast message 2 as an example, and this should not constitute a limitation on this application.

[0271] It should be noted that the number of TGIDs included in each heartbeat keep-alive broadcast message shown in Tables 1 and 2 is described according to the maximum number of TGIDs included in a heartbeat keep-alive broadcast message.

[0272] Table 1 shows the TGID strategies for two application scenarios, assuming the TGID does not include the flags used to indicate whether a response to the heartbeat keep-alive broadcast message is required and the flags used to identify the authentication type. Table 2 shows the TGID strategies for three application scenarios, assuming the TGID also includes the flags used to indicate whether a response to the heartbeat keep-alive broadcast message is required and the flags used to identify the authentication type. The precision mentioned in Tables 1 and 2 refers to the maximum number of TGIDs required by the application scenario when there are no TGID conflicts; the higher the precision, the higher the maximum number of TGIDs required by the application scenario when there are no TGID conflicts. Performance refers to the number of TGIDs carried in the heartbeat keep-alive broadcast message 2 at one time; the higher the performance, the more TGIDs carried in the heartbeat keep-alive broadcast message 2 at one time.

[0273] Table 1

[0274]

[0275]

[0276] Table 2

[0277]

[0278] As shown in Tables 1 and 2, different TGID strategies are set for different application scenarios, including the maximum number of TGIDs required and the number of TGIDs (performance) carried in a single heartbeat keep-alive broadcast message 2, without TGID conflicts. This allows for flexible adaptation to the needs of different scenarios.

[0279] For example, in industrial scenarios, the equipment is primarily powered, so its sensitivity to power consumption and / or bandwidth is relatively low. This means that the performance requirements for heartbeat keep-alive broadcast messages (2) are lower in industrial settings. However, industrial scenarios involve a relatively large number of devices, often ranging from thousands to tens of thousands in a single factory. Therefore, assuming no TGID conflicts, industrial scenarios have a higher requirement for the maximum number of TGIDs, meaning higher accuracy is required for TGIDs. In this case, the TGID strategy corresponding to HALP can be used to increase the length of the TGIDs, thereby increasing the maximum number of TGIDs.

[0280] In home scenarios, there are many non-powered devices, making them more sensitive to power consumption and / or bandwidth. This means higher performance requirements are placed on the heartbeat keep-alive broadcast message 2. However, the number of devices in a home scenario is relatively small. Therefore, assuming no TGID conflicts, the requirement for the maximum number of TGIDs is not as high, meaning the accuracy requirement for TGIDs can be slightly lower. In this case, the default TGID strategy corresponding to MAMP or LAHP can be adopted, reducing the length of TGIDs and thus increasing the maximum number of TGIDs. This, in turn, increases the number of TGIDs carried in a single broadcast of the heartbeat keep-alive broadcast message 2, reducing device power consumption and / or bandwidth.

[0281] It should be noted that the terms "high precision" and "low precision" in Table 1 are relative concepts. For example, precision greater than the first threshold can be referred to as high precision, and precision less than or equal to the first threshold can be referred to as low precision. The first threshold can be set according to actual circumstances, and this application embodiment does not limit it.

[0282] Similarly, the terms "high performance" and "low performance" in Table 1 are relative concepts. For example, performance exceeding the second threshold can be termed "high performance," while performance less than or equal to the second threshold can be termed "low performance." The second threshold can be set according to actual circumstances, and this application does not limit this setting.

[0283] Similarly, the terms high precision, medium precision, and low precision mentioned in Table 2 are relative concepts. For example, precision greater than the third threshold can be called high precision; precision greater than the fourth threshold and less than or equal to the third threshold can be called medium precision; and precision less than or equal to the fourth threshold can be called low precision. The third threshold and / or the fourth threshold can be set according to actual conditions, and this application embodiment does not limit this.

[0284] Similarly, the terms "high performance," "medium performance," and "low performance" in Table 2 are relative concepts. For example, performance exceeding the fifth threshold can be termed "high performance"; performance exceeding the sixth threshold but less than or equal to the fifth threshold can be termed "medium performance"; and performance less than or equal to the sixth threshold can be termed "low performance." The fifth and / or sixth thresholds can be set according to actual circumstances, and this application embodiment does not limit this.

[0285] Optionally, in one example, the user can set the TGID policy corresponding to the device according to their needs.

[0286] For example, setting the TGID policy corresponding to a device may include: modifying the TGID policy configured for the device or configuring the TGID policy corresponding to the device.

[0287] This application does not limit the method by which users set the TGID policy corresponding to the device. For example, users can set the TGID policy corresponding to the device through voice or interaction with the display screen.

[0288] It should be noted that the embodiments of this application do not limit the TGID strategy adopted by the device.

[0289] In one example, different TGID strategies can be used in the same scenario. This may result in the TGID carried in the heartbeat keep-alive broadcast message 2 sent by the sender having a different length than the TGID of the receiver. The handling method for this situation is described in detail in S530 below, and will not be described here.

[0290] In another example, different TGID strategies can be used for different scenarios. This avoids the problem that the TGID carried in the heartbeat keep-alive broadcast message 2 sent by the sender is inconsistent in length with the TGID of the receiver itself.

[0291] For example, in Bluetooth 4.0, the TGID length is typically set between 8 and 20 bits to meet the needs of various scenarios. Thus, a heartbeat keep-alive broadcast message can carry a maximum of 7.5 bytes (60 bits) to display the target device identifier, meaning a single heartbeat keep-alive broadcast message can carry 3 to 5 TGIDs. This means that the number of target device identifiers carried in a single heartbeat keep-alive broadcast message is greater than the existing maximum of two. Therefore, a single heartbeat keep-alive broadcast message carries a larger payload of target device identifiers, requiring fewer heartbeat keep-alive broadcast messages to be sent. This allows multiple devices to remain "networked online" in a shorter time, resulting in higher efficiency and improved user experience.

[0292] It should be noted that in Bluetooth 5.0 or User Datagram Protocol (UDP), the length of TGID can be slightly larger than that set in Bluetooth 4.0, and its specific value can be determined according to the upper limit of the data field size in Bluetooth 5.0 or UDP protocol. This application embodiment does not limit this.

[0293] Figure 6 An example provided for an embodiment of this application Figure 2The diagram shows an example of a heartbeat keep-alive broadcast message sent by mobile phone 201. TGID1 corresponds to the group to which mobile phone 201, smart TV 202, and tablet 203 belong; TGID2 corresponds to the group to which mobile phone 201, computer 204, and smart speaker 205 belong; TGID3 corresponds to the group to which mobile phone 201 and smart speaker 205 belong; and TGID4 corresponds to the group to which mobile phone 201, mobile phone 206, and smartwatch 207 belong. Each TGID is 8 bits long.

[0294] Based on the structure of the heartbeat keep-alive broadcast message 2, multiple devices are kept in a "networked online" state. In this way, devices maintain their online status based on their respective groups. Thus, a single heartbeat keep-alive broadcast message can keep multiple devices in a "networked online" state in a relatively short time, which is highly efficient and helps to improve the user experience.

[0295] The network keep-alive method provided in the embodiments of this application will be described in detail below.

[0296] This network keep-alive method is applied to a communication system including a first device and a second device. The embodiments of this application do not limit the number of the second device and / or the first device.

[0297] This application does not limit the type of the second device and / or the first device. For example, the second device and / or the first device may be as described above. Figure 1 Any of the aforementioned industrial or non-industrial equipment. For example, the second equipment and / or the first equipment can be any of the aforementioned... Figure 2 Any of the terminal devices described herein.

[0298] Figure 7 This is a schematic flowchart of a network keep-alive method 500 provided in an embodiment of this application.

[0299] For example, such as Figure 7 As shown, the methods for keeping this network alive include:

[0300] S510, the second device generates a heartbeat keep-alive broadcast message.

[0301] The heartbeat keep-alive broadcast message is used to indicate that the second device is in a network online state. This heartbeat keep-alive broadcast message includes a first identifier. That is, the structure of this heartbeat keep-alive broadcast message is the same as the structure of heartbeat keep-alive broadcast message 2 described above.

[0302] It should be noted that the second device being in a network online state can be understood as the second device being in a trusted group, and the second device and at least one device in the trusted group having already formed a network with each other.

[0303] For information on the heartbeat keep-alive broadcast message in S510, please refer to the description of heartbeat keep-alive broadcast message 2 above. For example, how heartbeat keep-alive broadcast message 2 is generated, the first identifier carried by heartbeat keep-alive broadcast message 2, in addition to indicating that the second device is in the online networking state and the first identifier, the first identifier may also include which identifier bits (e.g., the identifier bit used to identify whether a heartbeat keep-alive broadcast message needs to be responded to and / or the identifier bit used to identify the authentication type corresponding to the trusted group identifier), the relevant description of each identifier bit, and the setting of the length of the first identifier (the selection of the first identifier strategy), etc., which will not be repeated here.

[0304] The first identifier is generated based on the authentication method between the second device and the third device, where the third device is a device within the group to which the second device belongs.

[0305] In one example, the first identifier is generated by the second device. Specifically, the second device first generates a third identifier based on the authentication method between the second device and the third device; then, it performs a hash calculation on the third identifier and extracts the last N bits as the first identifier.

[0306] In this example, after the second device and the third device authenticate each other, the second device generates a first identifier. At this time, the step of the second device generating the first identifier can be performed before S510 or during the execution of S510; this embodiment of the application does not limit this.

[0307] In another example, the first identifier is generated by a third device. Specifically, firstly, the third device generates a third identifier based on the authentication method between the third device and the second device; secondly, it performs a hash calculation on the third identifier and extracts the last N bits as the first identifier. Finally, the third device sends the first identifier to the second device.

[0308] In this example, after the third device and the second device authenticate each other, the third device generates a first identifier and sends the first identifier to the second device. At this time, the step of the third device generating the first identifier and sending the first identifier to the second device can be performed before S510 or during the execution of S510. This embodiment of the application does not limit this.

[0309] It should be noted that the third device may or may not include the second device, and this application embodiment does not limit this.

[0310] S520, the second device broadcasts a heartbeat keep-alive broadcast message. Correspondingly, the first device receives the heartbeat keep-alive broadcast information sent by the second device.

[0311] This application does not limit the method by which the second device sends the heartbeat keep-alive broadcast message. For example, the second device may send the heartbeat keep-alive broadcast message in the form of a broadcast.

[0312] Optionally, in some embodiments, the device can also flexibly adjust the device keep-alive method according to its performance, i.e., whether the device actively participates in keep-alive or not. In this way, truly starting from the demand side and keeping-alive on demand, the bandwidth and load impact caused by a large number of invalid device-level keep-alive heartbeats can be eliminated, thus significantly reducing bandwidth and power consumption load.

[0313] For example, when the device's performance meets the conditions for actively participating in keep-alive, the device will actively participate in keep-alive by default, that is, the device will actively send heartbeat keep-alive broadcast messages by default. When the device's performance does not meet the conditions for actively participating in keep-alive, the device will not actively participate in keep-alive by default, that is, the device will not actively send heartbeat keep-alive broadcast messages by default.

[0314] Thus, in this embodiment, before S520, the second device also needs to determine that the performance of the second device meets the conditions for actively participating in the keep-alive operation.

[0315] This application does not limit the conditions for actively participating in keep-alive. For example, the conditions for actively participating in keep-alive include at least one of the following: the device's battery level is greater than or equal to a first preset value, the device is a device that is always powered, and the device's bandwidth network speed is greater than or equal to a second preset value.

[0316] The embodiments of this application do not limit the specific values ​​of the first preset value and / or the second preset value, which can be set according to the actual situation.

[0317] It should be noted that "constantly powered equipment" can be understood as equipment that is always powered on.

[0318] Optionally, in some embodiments, the device can also flexibly adjust the device keep-alive period based on the service duration, meaning the period during which the device actively participates in keep-alive is equal to the service duration. This truly starts from the demand side, ensuring keep-alive on demand, which can eliminate the bandwidth and load impact caused by a large number of invalid device-level keep-alive heartbeats, thus significantly reducing bandwidth and power consumption load.

[0319] It should be noted that, in the embodiments of this application, regardless of whether the device is currently in a scenario of not participating in active keep-alive or in a scenario of participating in active keep-alive, the device can flexibly adjust the device keep-alive period according to the service time.

[0320] It should be understood that the business described above can be understood as an application on a device, and the time served by the business can be understood as the running time of the application.

[0321] For example, if a service monitoring device goes online or offline, the device management service initiates a heartbeat keep-alive broadcast message. When a service unregisters to monitor the device going online or offline, the device management service stops sending heartbeat keep-alive broadcast messages. In other words, when the application is running, the device management service initiates heartbeat keep-alive broadcast messages, and when the application is closed, the device management service stops sending heartbeat keep-alive broadcast messages.

[0322] Thus, in this embodiment, before S520, the second device also needs to determine that the application on the second device is running.

[0323] Optionally, in some embodiments, the second device may also periodically send heartbeat keep-alive broadcast messages. This application embodiment does not limit the period at which the second device sends heartbeat keep-alive broadcast messages; it can be set according to actual circumstances.

[0324] S530, the first device matches the first identifier with the second identifier to obtain a matching result. The second identifier is used to indicate the group to which the first device belongs.

[0325] The second identifier is generated based on the authentication method between the first device and the fourth device, where the fourth device is a device within the group to which the first device belongs.

[0326] In one example, the second identifier is generated by the first device. Specifically, the first device first generates the fourth identifier based on the authentication method between the first device and the fourth device; then, it performs a hash calculation on the fourth identifier and extracts the last N bits as the second identifier.

[0327] In this example, after the first device and the fourth device authenticate each other, the first device generates a second identifier. At this time, the step of the first device generating the second identifier can be performed before S520, after S520, or simultaneously with S520. The implementation of this application embodiment does not limit this.

[0328] In another example, the second identifier is generated by a fourth device. Specifically, firstly, the fourth device generates a fourth identifier based on the authentication method between the fourth device and the first device; secondly, it performs a hash calculation on the fourth identifier and extracts the last N bits as the second identifier. Finally, the fourth device sends the second identifier to the first device.

[0329] In this example, after the fourth device and the first device authenticate each other, the fourth device generates a second identifier and sends the second identifier to the first device. At this time, the step of the fourth device generating the second identifier and sending the second identifier to the first device can be performed before S520, after S520, or simultaneously with S520. This embodiment of the application does not limit this.

[0330] It should be noted that the fourth device may or may not include the second device, and this application embodiment does not limit this.

[0331] The embodiments of this application do not limit the algorithm for matching the first identifier with the second identifier.

[0332] In one example, if the lengths of the first identifier and the second identifier are the same, the first device can use an existing matching algorithm to match the first identifier with the second identifier, which will not be elaborated here.

[0333] In another example, if the lengths of the first identifier and the second identifier are inconsistent, the first device can use a backward matching algorithm to match the first identifier with the second identifier based on the minimum length. Here, the minimum length can be understood as the shorter of the lengths of the first identifier and the second identifier.

[0334] Specifically, if the length of the first identifier is N bits and the length of the second identifier is M bits, when N > M, the first device matches the value of the last M bits of the first identifier with the value of the second identifier to obtain a matching result. When N < M, the first device matches the value of the first identifier with the value of the last N bits of the second identifier to obtain a matching result.

[0335] It should be noted that when N > M, the value of the M bits following the first identifier can be understood as the content obtained by truncating the M bits of the first identifier from the end to the beginning. The value of the second identifier can be understood as the content of the M bits of the second identifier.

[0336] When N < M, the value of the first identifier can be understood as the content of the N bits of the first identifier; the value of the N bits after the second identifier can be understood as the content obtained by truncating the N bits of the second identifier from the end to the beginning.

[0337] For example, if the length of the first identifier is 15 bits and the length of the second identifier is 10 bits, the first device can match the second identifier with the content obtained by the last 10 bits of the first identifier.

[0338] The matching results include matches and non-matches. A match can be understood as the first identifier and the second identifier being the same, while a non-match can be understood as the first identifier and the second identifier being different.

[0339] It should be noted that if one device switches from the first authentication method to the second authentication method with another device, both devices will store two first identifiers. One first identifier is generated based on the first authentication method, and the other is generated based on the second authentication method. In this case, a match is considered complete as long as one of the first identifiers at the receiving end matches the first identifier sent by the receiving end.

[0340] S540, the first device processes the heartbeat keep-alive broadcast message based on the matching result.

[0341] If the first identifier and the second identifier do not match, i.e., the matching result is a mismatch, the heartbeat keep-alive broadcast message is discarded.

[0342] If the first identifier and the second identifier match, i.e., the matching result is a match, the first device maintains the networking state between the first device and the second device.

[0343] In one example, if the first device determines that it and the second device have formed a network, then the first device and the second device can exchange information with each other. For example, the first device can send information related to itself to the second device and / or the first device can receive information related to itself from the second device. This maintains the network status between the first device and the second device.

[0344] In another example, if the first device determines that the first device and the second device are not networked, then the first device and the second device need to network together to maintain the network status between the first device and the second device.

[0345] In this example, after the first device and the second device form a network, the first device and the second device can also exchange information with each other.

[0346] It should be noted that the method 500 described above is based on the example of one second device. If there are multiple second devices, all of the multiple second devices will perform the steps described in the method 500 above.

[0347] The above text combined Figures 5 to 7 The method for network keep-alive provided in this application is described in detail below. Figure 8 The present application provides a detailed description of an example communication system.

[0348] Figure 8 This is a schematic diagram of an example communication system provided in an embodiment of this application.

[0349] For example, such as Figure 8 As shown, the communication system includes device 610 and device 620.

[0350] This application does not limit the type of device 610 and / or device 620. For example, device 610 and / or device 620 may be as described above. Figure 1 Any of the aforementioned industrial or non-industrial equipment. For example, equipment 610 and / or equipment 620 can be any of the aforementioned... Figure 2Any of the terminal devices described above. For example, device 610 could be any of the terminal devices mentioned above. Figure 7 The second device mentioned above, device 620, can be the device described above regarding... Figure 7 The first device described herein.

[0351] It should be noted that the number of devices 610 and / or devices 620 is not limited in the embodiments of this application. Figure 8 This illustration uses a communication system comprising two devices as an example and should not be construed as limiting the scope of this application. It should be understood that the communication system may also include more devices, and the embodiments of this application do not limit this.

[0352] like Figure 8 As shown, both devices 610 and 620 include a device management interface, a networking module, a device authentication module (e.g., hichain), a soft bus, a sensor hub module, and a properties unit. The device management interface includes a device status unit; the networking module includes a device keep-alive policy unit; the soft bus includes a networking unit and a transmission unit; the device authentication module includes a group management unit; and the sensor hub module includes a sensor hub unit.

[0353] It should be noted that, Figure 8 The modules included in devices 610 and 620 shown are merely examples, and may also include other modules; this application does not limit this. Furthermore, Figure 8 The units included in the various modules of the devices 610 and 620 shown are merely examples, and may also include other units, which are not limited in this application embodiment.

[0354] Below, in conjunction with Figure 8 The communication system shown provides a detailed description of the network keep-alive method provided in this application embodiment. The active network keep-alive method using device 610 is used as an example.

[0355] based on Figure 8 The communication system shown includes the following network keep-alive methods:

[0356] The first step is for the networking unit of device 610 to start the keep-alive heartbeat and send the TGID along with the heartbeat keep-alive broadcast message to device 620.

[0357] For a description of TGID, please refer to the description above; it will not be repeated here.

[0358] Optionally, in one example, before the first step, device 610 needs to determine whether to enable network keep-alive. Specifically, the device keep-alive policy unit of device 610 reads the local keep-alive configuration from the performance unit of device 610 and decides whether to enable network keep-alive based on the configuration.

[0359] The local keep-alive configuration can be understood as the local network keep-alive strategy of device 610. For example, the network keep-alive strategy may include: the structure of the heartbeat keep-alive broadcast message mentioned above, the device keep-alive method mentioned above (actively participating in keep-alive or not actively participating in keep-alive), and / or the device keep-alive duration mentioned above.

[0360] For example, the step of determining whether to start network keep-alive can be performed after the device 610 is powered on.

[0361] Alternatively, in one example, prior to the first step, device 610 may also calculate the TGID described in the first step.

[0362] Specifically, first, the device keep-alive policy unit of device 610 queries the trusted groups of device 610 from the group management unit of device 610. Second, the device keep-alive policy unit of device 610 transmits the trusted groups read in the second step to the networking unit of device 610. Finally, the networking unit of device 610 calculates the TGID based on the trusted groups.

[0363] This application embodiment does not limit the method by which device 610 sends the heartbeat keep-alive broadcast message to device 620. In one example, the networking unit of device 610 may first send the heartbeat keep-alive broadcast message to the sensor hub unit of device 610. Then, the sensor hub unit of device 610 sends the heartbeat keep-alive broadcast message to the sensor hub unit of device 620.

[0364] The second step is for device 620 to match the TGID in the heartbeat keep-alive broadcast message with the TGID of device 620 to obtain the matching result.

[0365] In one example, the sensor hub unit of device 620 can read the TGID of device 620 from the TGID policy module of device 620, and match the TGID in the heartbeat keep-alive broadcast message with the TGID of device 620 to obtain the matching result.

[0366] The third step is to process the heartbeat keep-alive broadcast message based on the matching results.

[0367] In one example, if the matching result is a match, the sensor hub unit of device 620 can report a heartbeat keep-alive broadcast message to the networking unit of device 620. After receiving the heartbeat keep-alive broadcast message, the networking unit of device 620 sends information to the device management interface of device 620 to trigger keep-alive networking, thereby triggering the keep-alive networking of device 620 through the device management interface of device 620.

[0368] In another example, if the matching result is a mismatch, the sensor hub unit of device 620 can discard the heartbeat keep-alive broadcast message.

[0369] For example, the device 620 may also include a network keep-alive module, through which the device 620 performs network keep-alive.

[0370] Optionally, in one example, only devices with a trusted relationship (authenticated devices) and devices with the same account (unauthenticated devices) are considered. After authentication, the network is triggered to go online.

[0371] Optionally, in one example, after receiving the heartbeat keep-alive broadcast message, the networking unit of device 620 can also perform the following: the networking unit of device 620 can report the device to the device management interface as online. The device management interface can also report the device to the outside world as online callback.

[0372] Optionally, the device 610 may also include a device information management module, which listens for online events and performs data synchronization between devices.

[0373] Optionally, the device status unit of device 610 listens for the synchronous completion event of the device information management module and sends a ready status notification to the device management interface.

[0374] Below, in conjunction with Figure 9 and Figure 10 The present application provides a detailed description of the apparatus provided in the embodiments thereof.

[0375] Figure 9 This is a schematic structural diagram of a network keep-alive device 700 provided in an embodiment of this application.

[0376] For example, such as Figure 9 As shown, the network keep-alive device 700 includes a transceiver unit 710 and a processing unit 720.

[0377] In one possible implementation, the network keep-alive device 700 can be the first device described in method 500 above or the aforementioned... Figure 8 The device 610 described herein.

[0378] Specifically, the transceiver unit 710 is used to receive a heartbeat keep-alive broadcast message from the second device. The heartbeat keep-alive broadcast message is used to indicate that the second device is in a network online state. The heartbeat keep-alive broadcast message includes a first identifier, which is used to indicate the group to which the second device belongs. The processing unit 720 is used to match the first identifier with a second identifier to obtain a matching result, wherein the second identifier is used to indicate the group to which the device 700 belongs. The processing unit 720 is also used to process the heartbeat keep-alive broadcast message according to the matching result.

[0379] In another possible implementation, the network keep-alive device 700 can be the second device described in method 500 above or the above-described device. Figure 8 The device 620 described herein.

[0380] Specifically, the processing unit 720 is used to generate a heartbeat keep-alive broadcast message, which is used to indicate that the device 700 is in a network online state. The heartbeat keep-alive broadcast message includes a first identifier, which is used to indicate the group to which the device 700 belongs. The transceiver unit 710 is used to broadcast the heartbeat keep-alive broadcast message.

[0381] Figure 10 A schematic structural diagram of a network keep-alive device 800 provided in an embodiment of this application is shown.

[0382] like Figure 10 As shown, the network keep-alive device 800 includes: one or more processors 810, one or more memories 820, the one or more memories 820 storing one or more computer programs, the one or more computer programs including instructions. When the instructions are executed by the one or more processors 810, the network keep-alive device 800 performs the technical solution described in the above embodiments.

[0383] This application provides a communication system, including a first device and a second device, which is used to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to those of the related embodiments described above, and will not be repeated here.

[0384] This application provides a computer program product that, when run on a first device, causes the first device to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to those of the related embodiments described above, and will not be repeated here.

[0385] This application provides a computer program product that, when run on a second device, causes the second device to execute the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar to those of the related embodiments described above, and will not be repeated here.

[0386] This application provides a readable storage medium containing instructions that, when executed by a first device, cause the first device to perform the technical solution described in the above embodiments. The implementation principle and technical effects are similar and will not be repeated here.

[0387] This application provides a readable storage medium containing instructions that, when executed by a second device, cause the second device to perform the technical solution described in the above embodiments. The implementation principle and technical effects are similar and will not be repeated here.

[0388] This application provides a chip for executing instructions. When the chip is running, it executes the technical solutions described in the above embodiments. Its implementation principle and technical effects are similar and will not be repeated here.

[0389] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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 implementations should not be considered beyond the scope of the embodiments of this application.

[0390] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0391] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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 system, 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; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0392] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0393] In addition, 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.

[0394] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or parts of the technical solutions, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in 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.

[0395] 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 network keep-alive system, characterized in that, The system includes a first device and a second device, wherein... The second device is used to broadcast a first heartbeat keep-alive broadcast message, which indicates that the second device is in a network online state. The first heartbeat keep-alive broadcast message includes a first identifier, which indicates the group to which the second device belongs. The first device is configured to, in response to receiving the first heartbeat keep-alive broadcast message, match the first identifier with the second identifier to obtain a first matching result, wherein the second identifier is used to indicate the group to which the first device belongs; The first device is further configured to process the first heartbeat keep-alive broadcast message based on the first matching result; The first identifier includes a second identifier bit; wherein the second identifier bit is used to indicate the authentication type between the second device and the third device, the third device being a device within the group to which the second device belongs.

2. The system according to claim 1, characterized in that, The first identifier is generated based on the authentication method between the second and third devices; and / or, The second identifier is generated based on the authentication method between the first device and the fourth device, wherein the fourth device is a device within the group to which the first device belongs.

3. The system according to claim 1, characterized in that, The first device is also specifically used for: Once the first matching result is confirmed as a match, the network status with the second device is maintained according to the first heartbeat keep-alive broadcast message.

4. The system according to claim 1, characterized in that, The first identifier further includes a first identifier bit; wherein the first identifier bit is used to indicate whether it is necessary to respond to the first heartbeat keep-alive broadcast message.

5. The system according to claim 1, characterized in that, The authentication types include same account authentication type and different account authentication type.

6. The system according to claim 1, characterized in that, The length of the first identifier is related to the scenario in which the second device is used.

7. The system according to any one of claims 1 to 6, characterized in that, The system also includes a fifth device. The fifth device is used to broadcast a second heartbeat keep-alive broadcast message, which indicates that the fifth device is in a network online state. The second heartbeat keep-alive broadcast message includes a fifth identifier, which indicates the group to which the fifth device belongs. The first device is further configured to, in response to receiving the second heartbeat keep-alive broadcast message, match the fifth identifier with the second identifier to obtain a second matching result; The first device is further configured to determine that the second matching result is a mismatch and discard the second heartbeat keep-alive broadcast message.

8. A method for network keep-alive, characterized in that, The method includes: The first device receives a first heartbeat keep-alive broadcast message from the second device. The first heartbeat keep-alive broadcast message is used to indicate that the second device is in a network online state. The first heartbeat keep-alive broadcast message includes a first identifier, which is used to indicate the group to which the second device belongs. The first device matches the first identifier with the second identifier to obtain a first matching result, wherein the second identifier is used to indicate the group to which the first device belongs; The first device processes the first heartbeat keep-alive broadcast message based on the first matching result; The first identifier includes a second identifier bit; wherein the second identifier bit is used to indicate the authentication type between the second device and the third device, the third device being a device within the group to which the second device belongs.

9. The method according to claim 8, characterized in that, The first identifier further includes a first identifier bit; wherein the first identifier bit is used to indicate whether it is necessary to respond to the first heartbeat keep-alive broadcast message.

10. The method according to claim 8, characterized in that, The authentication types include same account authentication type and different account authentication type.

11. The method according to claim 8, characterized in that, The length of the first identifier is related to the scenario in which the second device is used.

12. The method according to claim 8, characterized in that, The first identifier has a length of N bits, the second identifier has a length of M bits, and the first device matches the first identifier with the second identifier to obtain a first matching result, including: When N > M, the first device matches the value of the last M bits of the first identifier with the value of the second identifier to obtain the first matching result.

13. The method according to claim 12, characterized in that, 8≤N≤20, and / or, 8≤M≤20.

14. The method according to any one of claims 8 to 13, characterized in that, The step of processing the first heartbeat keep-alive broadcast message based on the first matching result includes: Once the first matching result is determined to be a match, the first device maintains the network status with the second device according to the first heartbeat keep-alive broadcast message.

15. The method according to any one of claims 8 to 13, characterized in that, The first device receives a second heartbeat keep-alive broadcast message from the fifth device. The second heartbeat keep-alive broadcast message is used to indicate that the fifth device is in a network online state. The second heartbeat keep-alive broadcast message includes a fifth identifier, which is used to indicate the group to which the fifth device belongs. The first device matches the fifth identifier with the second identifier to obtain a second matching result; If the second matching result is determined to be a mismatch, the first device discards the second heartbeat keep-alive broadcast message.

16. A method for network keep-alive, characterized in that, The method includes: The second device generates a heartbeat keep-alive broadcast message, which is used to indicate that the second device is in a network online state. The heartbeat keep-alive broadcast message includes a first identifier, which is used to indicate the group to which the second device belongs. The second device broadcasts the heartbeat keep-alive broadcast message; The first identifier includes a second identifier bit; wherein the second identifier bit is used to indicate the authentication type between the second device and the third device, the third device being a device within the group to which the second device belongs.

17. The method according to claim 16, characterized in that, The first identifier further includes a first identifier bit; wherein the first identifier bit is used to indicate whether a response to the heartbeat keep-alive broadcast message is required.

18. The method according to claim 16, characterized in that, The authentication types include same account authentication type and different account authentication type.

19. The method according to claim 16, characterized in that, The length of the first identifier is related to the scenario in which the second device is used.

20. The method according to any one of claims 16 to 19, characterized in that, Before the second device broadcasts the heartbeat keep-alive broadcast message, the method further includes: The second device determines that its performance meets the conditions for actively participating in keep-alive, or the second device determines that the application on the second device is running.

21. A network-based keep-alive device, characterized in that, include: One or more processors; One or more memory units; And one or more computer programs, wherein the one or more computer programs are stored in the one or more memories, the one or more computer programs including instructions that, when executed by the one or more processors, cause the apparatus to perform the method as claimed in any one of claims 8 to 15, or to perform the method as claimed in any one of claims 16 to 20.

22. A computer storage medium, characterized in that, Includes computer instructions that, when executed on a terminal device, cause the terminal device to perform the method as described in any one of claims 8 to 15, or to perform the method as described in any one of claims 16 to 20.

Images