A device communication method, an electronic device, and a computer-readable storage medium

Abstract

The application provides a device communication method, an electronic device and a computer readable storage medium, relates to the technical field of industrial Internet of Things, and is applied to a communication system containing a plurality of electronic devices supporting the same soft bus communication architecture. The electronic devices can include a plurality of miner terminal devices and network infrastructure devices, and the electronic devices are distributed in a plurality of local area networks (such as a local area network A and a local area network B). In the method, a root node device of the local area network A can send parameter information of a trusted device in the local area network B to a miner terminal device in the local area network A; the miner terminal device in the local area network A can discover the miner terminal device in the local area network B based on the parameter information, and send data to the miner terminal device in the local area network B through the root node device of the local area network A and the root node device of the local area network B, so that the limitation of the original broadcast domain of the soft bus communication architecture is broken, cross-local-area-network interconnection is realized, and the number of devices that can be supported by the soft bus communication architecture is significantly improved.

Description

Technical Field

[0001] This application relates to the field of industrial Internet of Things (IoT) technology, and in particular to a device communication method, electronic device, and computer-readable storage medium. Background Technology

[0002] A soft bus is a communication architecture implemented at the software level. It is based on standardized software protocols, distributed programming interfaces and system-level capabilities. Through a unified device discovery, identity authentication, link optimization and resource scheduling mechanism, it makes cross-device, cross-protocol and cross-system data interaction present a user experience to the application layer as if it were a local call.

[0003] Based on the aforementioned advantages, the soft bus communication architecture can be applied to coal mine scenarios. Through a unified device discovery, authentication, link optimization, and resource scheduling mechanism, it seamlessly interconnects mining, transportation, ventilation, and detection equipment from different manufacturers, breaking down data silos and helping coal mining enterprises achieve comprehensive intelligentization. The electronic devices and their operating systems that run on this soft bus communication architecture, conform to the Kuanghong standard communication protocol, and are certified by Kuanghong constitute Kuanghong terminal devices and the Kuanghong operating system.

[0004] Currently, the aforementioned soft bus communication architecture has two limitations when applied to the coal mine scenario: First, the soft bus communication architecture can only support a limited number of devices that can simultaneously establish connections and carry out transmission services, which cannot meet the needs of hundreds of devices connecting concurrently and high-throughput transmission services in underground coal mines; Second, the current soft bus communication architecture requires electronic devices to be located in the same local area network, while the network topology in coal mine scenarios is complex, causing some mine terminal devices in these scenarios to be unable to complete device discovery, session establishment, and subsequent data transmission. Summary of the Invention

[0005] This application provides a device communication method, an electronic device, and a computer-readable storage medium. The device communication method can be applied to a communication system comprising multiple electronic devices supporting the same soft bus communication architecture. The electronic devices in the communication system can include multiple mining terminal devices and network infrastructure devices, and these electronic devices can be distributed across multiple local area networks (LANs) (such as LAN A and LAN B). In the device communication method, the root node device of LAN A can send parameter information of trusted devices in LAN B to the mining terminal devices in LAN A. The mining terminal devices in LAN A can discover the mining terminal devices in LAN B based on the aforementioned parameter information and send data to the mining terminal devices in LAN B through the root node devices of LAN A and LAN B, thereby breaking through the original broadcast domain limitation of the soft bus communication architecture, realizing cross-LAN interconnection, and significantly increasing the number of devices supported by the soft bus communication architecture.

[0006] In a first aspect, this application provides a device communication method applied to a first communication system, the first communication system including a first electronic device, a second electronic device, a third electronic device, and a fourth electronic device, the first electronic device and the second electronic device belonging to a first local area network (LAN), and the third electronic device and the fourth electronic device belonging to a second LAN, the method comprising: within the first LAN, the first electronic device sending first trusted device information to the second electronic device, the first trusted device information including parameter information of one or more trusted devices in the second LAN, the one or more trusted devices in the second LAN including the third electronic device and the fourth electronic device, the parameter information including identification information; the second electronic device sending a first data packet to the first electronic device through the first LAN, the first data packet carrying first service data and the identification information of the fourth electronic device; after receiving the first data packet, the first electronic device sending a second data packet to the third electronic device, the second data packet carrying the first service data and the identification information of the fourth electronic device; and after receiving the second data packet, the third electronic device sending a third data packet to the fourth electronic device through the second LAN, the third data packet carrying the first service data.

[0007] By implementing the method provided in the first aspect, the first electronic device (such as the root node of LAN A) can send parameter information of one or more trusted devices in the second LAN (such as LAN B) to the second electronic device (such as the mining terminal device in LAN A). Subsequently, the second electronic device (such as the mining terminal device in LAN A) can discover the fourth electronic device (such as the mining terminal device in LAN B) based on the parameter information, and send data to the fourth electronic device (such as the mining terminal device in LAN B) in the second LAN through the first electronic device (such as the root node device of LAN A) and the third electronic device (such as the root node device of LAN B), thereby breaking through the original broadcast domain limitation of the soft bus communication architecture, realizing cross-LAN interconnection, and significantly increasing the number of devices that the soft bus communication architecture can support.

[0008] In conjunction with the first aspect, in some embodiments, the first electronic device and the third electronic device belong to a third local area network. Before the first electronic device sends the first trusted device information to the second electronic device within the first local area network, the method further includes: within the third local area network, the third electronic device sends the second trusted device information to the first electronic device, wherein the second trusted device information includes parameter information of one or more trusted devices in the second local area network.

[0009] By implementing the method provided in the above embodiments, the first electronic device can obtain parameter information of one or more electronic devices in the second local area network from the third electronic device in the second local area network.

[0010] In conjunction with the first aspect, in some embodiments, the first electronic device and the third electronic device are trusted devices within the third local area network.

[0011] By implementing the method provided in the above embodiments, since the first electronic device and the third electronic device are trusted devices within the third local area network, it is ensured that the parameter information transmitted by the first electronic device to one or more electronic devices in the second local area network of the second electronic device is reliable. Subsequently, the second electronic device can transmit data to the fourth electronic device in the one or more electronic devices in the second local area network based on this reliable parameter information.

[0012] In conjunction with the first aspect, in some embodiments, in the first local area network, the parameter information of the trusted device sent by the first electronic device to the second electronic device further includes one or more of the following: device type, geographical location of the device, production subsystem to which the device belongs, security level of the device, and performance parameters.

[0013] In conjunction with the first aspect, in some embodiments, the aforementioned identification information includes: a device universally unique identifier (UUID), and / or, a device name, and / or, a private Internet Protocol (IP) address and a private port, and / or, a public IP address and a public port.

[0014] In conjunction with the first aspect, in some embodiments, the aforementioned third data packet also carries the private Internet Protocol (IP) address of the aforementioned fourth electronic device.

[0015] By implementing the method provided in the above embodiments, the third electronic device (such as the root node device of LAN B) can accurately transmit service data (such as the first service data mentioned above) to the fourth electronic device in the second LAN (such as LAN B) based on the private Internet Protocol IP address of the fourth electronic device, thereby avoiding errors such as packet loss.

[0016] In conjunction with the first aspect, in some embodiments, after receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: after receiving the first data packet, if the first electronic device's list of trusted devices includes the fourth electronic device, the first electronic device sends the second data packet to the third electronic device.

[0017] Implementing the method provided in the above embodiments, the first electronic device can only send a second data packet to the third electronic device if the fourth electronic device is in the first electronic device's list of trusted devices. It is understood that if the fourth electronic device is not in the first electronic device's list of trusted devices, the first electronic device will not send a second data packet to the third electronic device; that is, after receiving the first data packet, the first electronic device will drop the packet locally instead of generating a second data packet. This method effectively avoids the situation where routing forwarding reaches the last hop only to discover the address is invalid, reducing bandwidth waste and processing latency caused by invalid data packets wandering multiple times in the network and futile end-to-end transmission, thus improving device communication efficiency.

[0018] In conjunction with the first aspect, in some embodiments, after receiving the second data packet, the third electronic device sends the third data packet to the fourth electronic device through the second local area network. Specifically, after receiving the second data packet, if the third electronic device's list of trusted devices includes the fourth electronic device, the third electronic device sends the third data packet to the fourth electronic device through the second local area network.

[0019] By implementing the method provided in the above embodiments, the third electronic device can only send a third data packet to the fourth electronic device if the fourth electronic device is in the list of trusted devices of the third electronic device; otherwise, after receiving the second data packet, the third electronic device can locally drop the packet instead of sending the third data packet to the fourth electronic device. Through this method, even if an attacker tamperes with the data packet during transmission and attempts to redirect it to a forged device, it will be intercepted because the forged device is not in the list of trusted devices of the third electronic device. This ensures that business data can only reach the initially trusted fourth electronic device, completely blocking unauthorized delivery and improving the security of data transmission.

[0020] In conjunction with the first aspect, in some embodiments, the first electronic device is the root node device of the first local area network. The root node device of the first local area network is determined based on the performance parameters of one or more devices in the first local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

[0021] By implementing the method provided in the above embodiments, the first communication system can automatically determine the most powerful electronic device in the local area network to serve as the root node device of the local area network according to performance parameters. This concentrates high-throughput tasks on the more powerful electronic device while avoiding the overload of low-performance electronic devices. At the same time, it improves the overall network communication efficiency and significantly extends the service life of low-performance electronic devices.

[0022] In conjunction with the first aspect, in some embodiments, the third electronic device is the root node device of the second local area network. The root node device of the second local area network is determined based on the performance parameters of one or more devices in the second local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

[0023] By implementing the method provided in the above embodiments, the first communication system can automatically determine the most powerful electronic device in the local area network to serve as the root node device of the local area network according to performance parameters. This concentrates high-throughput tasks on the more powerful electronic device while avoiding the overload of low-performance electronic devices. At the same time, it improves the overall network communication efficiency and significantly extends the service life of low-performance electronic devices.

[0024] In conjunction with the first aspect, in some embodiments, the second electronic device sends a first data packet to the first electronic device via the first local area network, specifically including: the second electronic device sending the first data packet to a first agent process running on the first electronic device via the first local area network; before the first electronic device sends the second data packet to the third electronic device, the method further includes: the first electronic device parsing the identification information of the fourth electronic device from the first data packet through the first agent process; and the first electronic device generating the second data packet based on the identification information of the fourth electronic device and the first service data through the first agent process.

[0025] By implementing the method provided in the above embodiments, a first agent process can run on the first electronic device. The first agent process can receive the first data packet, parse it to obtain the identifier of the fourth electronic device, and then generate a second data packet. Through the above method, the first electronic device can perform other calculations based on the parsed content, thereby flexibly adding new services based on demand.

[0026] In conjunction with the first aspect, in some embodiments, after receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: after receiving the first data packet, the first electronic device sends the second data packet to a second agent process running on the third electronic device; before the third electronic device sends the third data packet to the fourth electronic device through the second local area network, the method further includes: the third electronic device parses the second data packet through the second agent process to obtain the identification information of the fourth electronic device; the third electronic device generates the third data packet based on the identification information of the fourth electronic device and the first service data through the second agent process.

[0027] By implementing the method provided in the above embodiments, a second agent process can run on the third electronic device. This second agent process can receive the second data packet, parse it to obtain the identifier of the fourth electronic device, and then generate a third data packet. Through this method, the second electronic device can perform other calculations based on the parsed content, thereby allowing for the flexible addition of new services based on demand.

[0028] In conjunction with the first aspect, in some embodiments, when the identification information includes the public IP address and public port, before sending the third data packet to the fourth electronic device via the second local area network, the method further includes: the third electronic device storing a first mapping relationship, the first mapping relationship including the mapping between the private IP address and private port of the fourth electronic device and the public IP address and public port of the fourth electronic device; after receiving the second data packet, the third electronic device sends the third data packet to the fourth electronic device via the second local area network, specifically including: after receiving the second data packet, the third electronic device modifies the public IP address and public port of the fourth electronic device in the second data packet to the private IP address and private port of the fourth electronic device based on the first mapping relationship, thereby obtaining the third data packet.

[0029] By implementing the method provided in the above embodiments, the third electronic device can forward data packets through NAT mapping, thereby avoiding the risk of attacks caused by parsing vulnerabilities and reducing the opportunity for malicious processes to directly spy on or modify business data, thus effectively improving the security of device communication.

[0030] In conjunction with the first aspect, in some embodiments, when the identification information includes the public IP address and public port, before sending the second data packet to the third electronic device, the method further includes: the first electronic device storing a second mapping relationship, the second mapping relationship including the mapping between the private IP address and private port of the second electronic device and the public IP address and public port of the second electronic device; after receiving the first data packet, the first electronic device sends the second data packet to the third electronic device, specifically including: after receiving the first data packet, the first electronic device modifies the private IP address and private port of the second electronic device in the first data packet to the public IP address and public port of the second electronic device based on the second mapping relationship, thereby obtaining the second data packet.

[0031] By implementing the method provided in the above embodiments, the first electronic device can forward data packets through NAT mapping, thereby avoiding the risk of attacks caused by parsing vulnerabilities and reducing the opportunity for malicious processes to directly spy on or modify business data, thus effectively improving the security of device communication.

[0032] In conjunction with the first aspect, in some embodiments, the above method further includes: after a first period of time following the transmission of the first trusted device information, the first electronic device sends third trusted device information to the second electronic device, the third trusted device information including parameter information of one or more trusted devices in the second local area network; the second electronic device updates the locally stored first trusted device information to the third trusted device information.

[0033] By implementing the method provided in the above embodiments, the first electronic device, as the root node device of the first local area network (such as local area network A), can update the parameter information of trusted devices to non-root nodes (such as the second electronic device) in the first local area network at a certain frequency, thereby ensuring that the parameter information of trusted devices on non-root node devices in the local area network is updated in a timely manner.

[0034] In conjunction with the first aspect, in some embodiments, the method further includes: the first electronic device sending fourth trusted device information to the third electronic device, the fourth trusted device information including parameter information of one or more trusted devices in the first local area network, one or more trusted devices in the first local area network including the second electronic device; after the second electronic device becomes a trusted device of the first electronic device for a second period of time, the first electronic device sending fifth trusted device information to the third electronic device, the fifth trusted device information including parameter information of one or more trusted devices in the first local area network; and the third electronic device updating the locally stored fourth trusted device information to the fifth trusted device information.

[0035] By implementing the method provided in the above embodiments, the first electronic device, as the root node device of the first local area network (such as local area network A), can update the parameter information of the trusted device to the root node device (such as the third electronic device) of another local area network (such as the second local area network or local area network B) at a certain frequency, thereby ensuring that the parameter information of the trusted device is updated and synchronized in a timely manner between different local area networks.

[0036] In conjunction with the first aspect, in some embodiments, the method further includes: after a third period of time following the receipt of the first trusted device information, if the locally stored first trusted device information has not been updated, the second electronic device sends a first synchronization request to the first electronic device; in response to the first synchronization request, the first electronic device sends sixth trusted device information to the second electronic device, the sixth trusted device information including parameter information of one or more trusted devices in the second local area network; and the second electronic device updates the locally stored first trusted device information to the sixth trusted device information.

[0037] If the parameter information of a trusted device on a non-root node device (such as a second electronic device) in a local area network has not been updated for a long time, the non-root node device can request the parameter information of the trusted device from the root node device (such as a first electronic device) of the local area network to update the parameter information of the trusted device stored locally on the non-root node. This reduces the synchronization delay of the parameter information of the trusted device on the non-root node device caused by occasional failures such as packet loss and network outage, and further reduces the errors in business data transmission caused by the asynchronous parameter information of the trusted device.

[0038] In conjunction with the first aspect, in some embodiments, the method further includes: after a fourth period of time following the receipt of the second trusted device information, if the locally stored second trusted device information has not been updated, the first electronic device sends a second synchronization request to the third electronic device; in response to the second synchronization request, the third electronic device sends seventh trusted device information to the first electronic device, the seventh trusted device information including parameter information of one or more trusted devices in the second local area network; and the first electronic device updates the locally stored second trusted device information to the seventh trusted device information.

[0039] If the parameter information of a trusted device on a root node device (such as a first electronic device) in a local area network has not been updated for a long time, the root node device can request the parameter information of the trusted device from the root node device of another local area network (such as a third electronic device in a second local area network) to update the parameter information of the trusted device stored locally on the root node (first electronic device). This reduces the synchronization lag of the parameter information of the trusted device on the root node device caused by occasional failures such as packet loss and network outage, and further reduces the errors in business data transmission caused by the asynchronous parameter information of the trusted devices.

[0040] In conjunction with the first aspect, in some embodiments, the method further includes: the fourth electronic device sending a fourth data packet to the third electronic device via the second local area network, the fourth data packet carrying second service data and identification information of the second electronic device; the third electronic device, after receiving the fourth data packet, sending a fifth data packet to the first electronic device, the fifth data packet carrying the second service data and identification information of the second electronic device; and the first electronic device, after receiving the fifth data packet, sending a sixth data packet to the second electronic device via the first local area network, the sixth data packet carrying the second service data.

[0041] Implementing the method provided in the above embodiments, in the first communication system, the second electronic device can send data to the fourth electronic device in sequence through the first electronic device and the third electronic device, and the fourth electronic device can also send data to the second electronic device in sequence through the third electronic device and the first electronic device, that is, the second electronic device also receives data packets sent across the local area network.

[0042] Secondly, this application provides a device communication method applied to a first electronic device, wherein the first electronic device belongs to a first communication system, the first communication system further includes a second electronic device, a third electronic device, and a fourth electronic device, the first electronic device and the second electronic device belong to a first local area network (LAN), and the third electronic device and the fourth electronic device belong to a second LAN. The method includes: within the first LAN, the first electronic device sends first trusted device information to the second electronic device, the first trusted device information including parameter information of one or more trusted devices in the second LAN, the one or more trusted devices in the second LAN including the third electronic device and the fourth electronic device, the parameter information including identification information; the first electronic device receives a first data packet sent by the second electronic device through the first LAN, the first data packet carrying first service data and the identification information of the fourth electronic device; after receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, the second data packet carrying the first service data and the identification information of the fourth electronic device, the third electronic device being used to send a third data packet to the fourth electronic device through the second LAN after receiving the second data packet, the third data packet carrying the first service data.

[0043] By implementing the method provided in the second aspect, the first electronic device (such as the root node of LAN A) can send parameter information of one or more trusted devices in the second LAN (such as LAN B) to the second electronic device (such as the mining terminal device in LAN A). Subsequently, the first electronic device can act as a proxy to forward data packets containing service data to the third electronic device when the second electronic device performs cross-LAN data transmission. This can overcome the limitations of the original broadcast domain in the soft bus communication architecture, realize cross-LAN interconnection, and significantly increase the number of devices that the soft bus communication architecture can support.

[0044] In conjunction with the second aspect, in some embodiments, the first electronic device and the third electronic device belong to a third local area network. Before the first electronic device sends the first trusted device information to the second electronic device within the first local area network, the method further includes: within the third local area network, the first electronic device receives the second trusted device information sent by the third electronic device, the second trusted device information including parameter information of one or more trusted devices in the second local area network.

[0045] In conjunction with the second aspect, in some embodiments, the first electronic device and the third electronic device are trusted devices within the third local area network.

[0046] In conjunction with the second aspect, in some embodiments, in the first local area network, the parameter information of the trusted device sent by the first electronic device to the second electronic device further includes one or more of the following: device type, geographical location of the device, production subsystem to which the device belongs, security level of the device, and performance parameters.

[0047] In conjunction with the second aspect, in some embodiments, the aforementioned identification information includes: a device universally unique identifier (UUID), and / or, a device name, and / or, a private Internet Protocol (IP) address and a private port, and / or, a public IP address and a public port.

[0048] In conjunction with the second aspect, in some embodiments, the aforementioned third data packet also carries the private Internet Protocol (IP) address of the aforementioned fourth electronic device.

[0049] In conjunction with the second aspect, in some embodiments, after receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: after receiving the first data packet, if the first electronic device's list of trusted devices includes the fourth electronic device, the first electronic device sends the second data packet to the third electronic device.

[0050] In conjunction with the second aspect, in some embodiments, the first electronic device is the root node device of the first local area network. The root node device of the first local area network is determined based on the performance parameters of one or more devices in the first local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

[0051] In conjunction with the second aspect, in some embodiments, the third electronic device is the root node device of the second local area network. The root node device of the second local area network is determined based on the performance parameters of one or more devices in the second local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

[0052] In conjunction with the second aspect, in some embodiments, the first electronic device receiving the first data packet sent by the second electronic device through the first local area network specifically includes: the first electronic device receiving the first data packet sent by the second electronic device through the first local area network through a first agent process running on the first electronic device; before the first electronic device sends the second data packet to the third electronic device, the method further includes: the first electronic device parsing the identification information of the fourth electronic device from the first data packet through the first agent process; and the first electronic device generating the second data packet based on the identification information of the fourth electronic device and the first service data through the first agent process.

[0053] In conjunction with the second aspect, in some embodiments, after receiving the first data packet, the first electronic device sends a second data packet to the third electronic device. Specifically, after receiving the first data packet, the first electronic device sends the second data packet to a second proxy process running on the third electronic device. The second proxy process is used to parse the second data packet to obtain the identification information of the fourth electronic device. The second proxy process is also used to generate the third data packet based on the identification information of the fourth electronic device and the first service data.

[0054] In conjunction with the second aspect, in some embodiments, when the identification information includes the public IP address and public port, before sending the second data packet to the third electronic device, the method further includes: the first electronic device storing a second mapping relationship, the second mapping relationship including the mapping between the private IP address and private port of the second electronic device and the public IP address and public port of the second electronic device; after receiving the first data packet, the first electronic device sends the second data packet to the third electronic device, specifically including: after receiving the first data packet, the first electronic device modifies the private IP address and private port of the second electronic device in the first data packet to the public IP address and public port of the second electronic device based on the second mapping relationship, thereby obtaining the second data packet.

[0055] In conjunction with the second aspect, in some embodiments, the above method further includes: after a first duration of sending the first trusted device information, the first electronic device sends third trusted device information to the second electronic device, the third trusted device information including parameter information of one or more trusted devices in the second local area network, the third trusted device information being used to update the first trusted device information locally stored in the second electronic device.

[0056] In conjunction with the second aspect, in some embodiments, the method further includes: the first electronic device sending fourth trusted device information to the third electronic device, the fourth trusted device information including parameter information of one or more trusted devices in the first local area network, one or more trusted devices in the first local area network including the second electronic device; after the second electronic device becomes a trusted device of the first electronic device for a second period of time, the first electronic device sending fifth trusted device information to the third electronic device, the fifth trusted device information including parameter information of one or more trusted devices in the first local area network, the fifth trusted device information being used to update the fourth trusted device information locally stored in the third electronic device.

[0057] In conjunction with the second aspect, in some embodiments, the above method further includes: in response to a first synchronization request, the first electronic device sends sixth trusted device information to the second electronic device, the sixth trusted device information including parameter information of one or more trusted devices in the second local area network, the sixth trusted device information being used to update the first trusted device information locally stored by the second electronic device, and the first synchronization request being sent by the second electronic device to the first electronic device after a third period of time following receipt of the first trusted device information, provided that the first trusted device information stored locally has not been updated.

[0058] In conjunction with the second aspect, in some embodiments, the above method further includes: after a fourth period of time following the receipt of the second trusted device information, if the locally stored second trusted device information has not been updated, the first electronic device sends a second synchronization request to the third electronic device, the second synchronization request being used to trigger the third electronic device to send seventh trusted device information to the first electronic device, the seventh trusted device information including parameter information of one or more trusted devices in the second local area network; the first electronic device updates the locally stored second trusted device information to the seventh trusted device information.

[0059] Understandably, the device communication method provided in the second aspect is the method step executed by the first electronic device in the device communication method provided in the first aspect. Therefore, the beneficial effects it can achieve can be referred to the beneficial effects in the corresponding method, and will not be repeated here.

[0060] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory; the processor executes the computer program to implement the method described in the second aspect and any possible implementation thereof.

[0061] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the second aspect and any possible implementation thereof.

[0062] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in the second aspect and any possible implementation thereof.

[0063] Understandably, the electronic device provided in the third aspect, the computer storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect are all used to execute the method provided in this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0064] Figure 1A-Figure 1B An exemplary diagram illustrates an automatic networking scenario using a soft bus communication architecture in an office setting.

[0065] Figure 2 This is a schematic diagram of the distribution of electronic equipment in a coal mine setting, provided in an embodiment of this application.

[0066] Figure 3 A partial schematic diagram of the distribution of electronic devices in a coal mine setting is shown;

[0067] Figure 4 This is a flowchart illustrating the device authentication and networking stage in a device communication method provided in this application embodiment;

[0068] Figure 5 This is a schematic diagram of a cross-local area network architecture for electronic devices provided in an embodiment of this application;

[0069] Figure 6 This is a schematic diagram of a method for identifying the root node device of a local area network through a large model A, provided in an embodiment of this application;

[0070] Figure 7 This is a schematic diagram illustrating a data transmission stage provided in an embodiment of this application;

[0071] Figure 8 This is a schematic diagram of a cross-LAN collaborative control process between electronic devices based on a soft bus, provided in an embodiment of this application.

[0072] Figure 9 This is a schematic diagram of another data transmission stage provided in an embodiment of this application;

[0073] Figure 10 This is a schematic diagram illustrating device information synchronization between electronic devices according to an embodiment of this application;

[0074] Figure 11 This is a schematic diagram of an electronic device aging mechanism provided in an embodiment of this application;

[0075] Figure 12 An exemplary schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0076] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0077] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. The terms “first” and “second” are used for descriptive purposes only and should not be construed as implying relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as “first” or “second” may explicitly or implicitly include one or more of that feature. “First” and “second,” etc., are used to distinguish different objects, not to describe a particular order of objects. For example, a first object and a second object are used to distinguish different objects, not to describe a particular order of objects.

[0078] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

[0079] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or related scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0080] The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A existing alone, A and B existing simultaneously, and B existing alone.

[0081] With the continuous expansion of the categories and quantity of electronic devices, the rapid popularization of collaborative office scenarios, and the intelligentization of life scenarios, the demand for efficient interconnection between electronic devices is becoming increasingly urgent.

[0082] Traditional solutions typically rely on local area networks (LANs) to establish communication connections between different electronic devices. However, LANs only provide low-level link interoperability and are insufficient to support upper-layer business data access. In other words, in actual deployment and use, if the above-mentioned traditional solutions are adopted, users still need to perform complex operations such as manual network configuration, port mapping, and protocol adaptation, which increases the usage threshold, introduces the risk of human configuration errors, and lacks effective fault tolerance and self-healing mechanisms in the event of link jitter or node failure. In addition, different electronic devices may use different communication technologies, causing these electronic devices using different communication technologies to be unable to communicate directly, and even conflicting under certain circumstances. For example, electronic device A only supports Bluetooth (BT) communication, while electronic device B only supports Wireless Fidelity (Wi-Fi) communication. Because the two electronic devices use different communication technologies, electronic device A and electronic device B cannot establish a communication connection under traditional solutions.

[0083] To overcome the aforementioned shortcomings, the industry has proposed a communication architecture implemented at the software level—the soft bus. As can be understood, a bus provides a transmission channel for information to flow between different parts of a system. Traditional hardware buses connect various hardware modules within electronic devices through such a unified transmission channel, enabling orderly data flow within the electronic devices. The aforementioned soft bus borrows the design concept of traditional hardware buses, using software to build a virtual bus between various distributed electronic devices, achieving orderly communication between them. Specifically, the soft bus is based on standardized software protocols, distributed programming interfaces, and system-level capabilities. Through unified device discovery, authentication, link optimization, and resource scheduling mechanisms, it presents cross-device, cross-protocol, and cross-system data interaction to the application layer as a user experience akin to local calls. For example, the soft bus architecture can be embedded in the operating system in the form of an application programming interface (API). As long as different electronic devices use the same soft bus architecture, for example, electronic device A and electronic device B use the same soft bus architecture, electronic device A can call the system-level API to automatically network with electronic device B, and then directly access the hardware resources of electronic device B through the soft bus to complete business tasks.

[0084] Compared to relying solely on a local area network (LAN), the aforementioned soft bus communication architecture can overcome complex technical challenges and the presence of numerous heterogeneous hardware devices to build a relatively stable, reliable, and extremely low-latency network. This enables various types of devices to communicate with each other within the same LAN, providing a foundation for distributed applications to run on multiple devices and achieving hardware cooperation and resource sharing among multiple electronic devices.

[0085] Currently, the communication architecture of the aforementioned soft bus is typically used in home and / or office scenarios. Figure 1A-Figure 1B An exemplary diagram illustrates an automatic networking scenario using a soft bus communication architecture in an office setting.

[0086] like Figure 1A As shown, there are five electronic devices in the above office scenario, namely electronic devices a through e. Electronic device a can be a mobile phone, electronic device b can be a tablet, electronic device c can be a laptop, electronic device d can be a conference screen, and electronic device e can be a router. Specifically, electronic devices a through e can be near-field devices (e.g., all located in the same office), and electronic devices a through d can access the same local area network (e.g., LAN A) through electronic device e. Electronic devices running the same soft bus communication architecture (e.g., electronic devices a through d) can automatically discover and network once connected to the LAN (e.g., ...). Figure 1B (As shown), a communication connection based on a soft bus can then be established. Figure 1B Taking electronic device c as an example, after connecting to the aforementioned local area network A, it can automatically network with electronic devices a, b, and d, which also have the same soft bus architecture. Subsequently, the user can project the first content from electronic device c onto electronic device d, and the image will be pushed in real-time via the soft bus and magnified on the conference screen. The user can also set electronic device b as an extended screen for electronic device c, allowing electronic device c to instantly send operation commands to electronic device b via the soft bus, achieving dual-screen collaboration. In addition, the user can use electronic device a as a second camera; electronic device c can request camera data from electronic device a via the soft bus, and electronic device a can transmit the image back in real-time, completing dual-camera shooting together with the camera built into electronic device c.

[0087] In addition, in office settings, electronic devices such as laptops, tablets, printers, conference screens, and security terminals can utilize the aforementioned soft bus to achieve functions such as keyboard and mouse sharing, wireless printing, and unified identity authentication. In home settings, electronic devices such as smart TVs, speakers, mobile terminals, IoT sensors, and wearable devices can use the soft bus to perform operations such as audio and video projection, distributed camera linkage, cross-device file drag-and-drop, and remote control.

[0088] Based on the aforementioned advantages, the application scenarios of the soft bus communication architecture can also be extended to coal mining scenarios. Through unified device discovery, identity authentication, link optimization, and resource scheduling mechanisms, it can seamlessly interconnect mining, transportation, ventilation, and monitoring equipment from different manufacturers, breaking down data silos and helping coal mining enterprises achieve comprehensive intelligentization. The electronic devices and their operating systems running on this soft bus communication architecture, conforming to the Mining-Hong standard communication protocol, and certified by Mining-Hong constitute the Mining-Hong terminal devices and the Mining-Hong operating system. It is understood that the aforementioned Mining-Hong standard communication protocol is a mandatory unified communication standard for the coal mining industry. This protocol is designed for the explosive environment of underground coal mines and specifies complete technical requirements for the physical layer, data link layer, application layer, and security extensions; the soft bus is the technical framework that carries this standard.

[0089] However, the aforementioned soft bus communication architecture has two limitations when applied to the coal mine scenario:

[0090] 1. Equipment capacity limitations

[0091] Currently, the aforementioned soft bus communication architecture only supports a maximum of 20 devices simultaneously establishing connections and conducting transmission services. However, a single local area network (LAN) in a coal mining area often contains multiple types of equipment, such as coal mining machines, hydraulic supports, pump stations, sensors, and cameras, with the number of nodes reaching over a hundred. Understandably, when the number of mining terminal devices in a single LAN exceeds this minimum, issues such as session conflicts, bandwidth contention, and routing table overflows will arise, leading to a sharp increase in communication latency or even service interruption. This makes it impossible to meet the demands of hundreds of devices connecting concurrently and transmitting high-throughput data in underground coal mines.

[0092] 2. Network topology limitations

[0093] The aforementioned soft bus communication architecture requires all electronic devices to establish connections and perform subsequent transmissions within the same broadcast domain. However, underground coal mines commonly employ multi-level converged ring or tree network topologies, dividing the mine's operating area into multiple broadcast domains, with each broadcast domain corresponding to a local area network (LAN). Figure 2 This is a schematic diagram illustrating the distribution of electronic equipment in a coal mine setting, as provided in an embodiment of this application. Figure 2 As shown, in a coal mine scenario, the coal mine enterprise's intranet / cloud management platform can aggregate multiple mining area ring networks. Figure 2Taking the aforementioned mining area ring network 1 and mining area ring network 2 as examples, routers A through D can be deployed in mining area ring network 1. Router D can be used to connect mining area ring network 1 to the coal mine enterprise's intranet / cloud management platform, while routers A through C can each be deployed as independent gateways within mining area ring network 1. Given that a coal mine operating area can contain multiple working faces (such as fully mechanized mining faces, tunneling faces, etc.), the mine terminal equipment in each working face can belong to the same broadcast domain and therefore can access the same local area network. Specifically, as... Figure 2 As shown, in the fully mechanized mining face 1, the explosion-proof mobile phone 1, gas concentration detector, coal mining machine 1, camera, and other mining terminal equipment can be connected to the same local area network A via router A; in the tunneling face, the belt conveyor 1, tunneling machine, hydraulic support, and other mining terminal equipment can be connected to another local area network B via the aforementioned router B; in the fully mechanized mining face 2, the explosion-proof mobile phone 2, coal mining machine 2, smart mine lamp 1, and other mining terminal equipment can be connected to another local area network C via the aforementioned router C. Similarly, router E and router F can be deployed in the aforementioned mining ring network 2. Router E can be used to connect the aforementioned mining ring network 2 to the aforementioned coal mine enterprise intranet / cloud management platform, while router F can be deployed as an independent gateway within the aforementioned mining ring network 2. In the fully mechanized mining face 3, the explosion-proof mobile phone 3, belt conveyor 2, coal mining machine 3, smart mine lamp 2, and other mining terminal equipment can be connected to local area network F via the aforementioned router F. As a result, multiple mine terminal devices in a coal mine scenario can be distributed in different VLANs or network segments, causing broadcast domain isolation in the soft bus architecture during use, thus making it impossible to complete device discovery, session establishment and subsequent data transmission across domains.

[0094] In view of this, embodiments of this application provide a device communication method, an electronic device, and a computer-readable storage medium. The device communication method described above can be applied to a communication system. The communication system described above may include a communication system in an industrial setting (such as the coal mine setting described above). The communication system described above is also referred to as a first communication system. The aforementioned first communication system may include a first electronic device, a second electronic device, a third electronic device, and a fourth electronic device. The first electronic device and the second electronic device belong to a first local area network (LAN), and the third electronic device and the fourth electronic device belong to a second local area network (LAN). The method includes: within the first LAN, the first electronic device can send first trusted device information to the second electronic device. The first trusted device information may include parameter information of one or more trusted devices in the second LAN. The one or more trusted devices in the second LAN may include the third electronic device and the fourth electronic device. The parameter information includes identification information. The second electronic device can send a first data packet to the first electronic device through the first LAN. The first data packet may carry first service data and the identification information of the fourth electronic device. After receiving the first data packet, the first electronic device can send a second data packet to the third electronic device. The second data packet may carry the first service data and the identification information of the fourth electronic device. After receiving the second data packet, the third electronic device can send a third data packet to the fourth electronic device through the second LAN. The third data packet carries the first service data.

[0095] It is understood that the electronic devices in the aforementioned communication system (such as the first electronic device, the second electronic device, the third electronic device, and the fourth electronic device) support the same soft bus communication architecture. For example, the aforementioned communication system may include multiple of the aforementioned mining terminal devices, and may also include network infrastructure devices such as routers, switches, and wireless access points. It is understood that although the aforementioned network infrastructure devices are not part of the aforementioned mining terminal devices, they should also support the same soft bus communication architecture as the aforementioned mining terminal devices.

[0096] By implementing the above device communication method, the above soft bus communication architecture can break through the original broadcast domain limitation, realize cross-LAN interconnection, and significantly increase the number of devices that the above soft bus communication architecture can support.

[0097] The following text is incomplete and cannot be translated. Figure 3 The partial schematic diagram of the distribution of electronic devices in the coal mine scenario shown is used as an example to fully explain the communication methods of the above-mentioned devices.

[0098] For example, in such Figure 3The coal mine scenario shown may include multiple local area networks (LANs), such as LAN A and LAN B. LAN A is also referred to as the first LAN, and LAN B as the second LAN. LAN A can be deployed in the coal mining face area, serving as the core control network for coal mining operations. It not only undertakes the main tasks of coal mining but also monitors the working environment in real time through a gas concentration detector, ensuring that coal mining operations are conducted in a safe and controllable environment. The broadcast domain of LAN A includes coal mining machine 1 (i.e., electronic device 11), a gas concentration detector (i.e., electronic device 12), and router A (i.e., electronic device 10). Among them, coal mining machine 1 can serve as the core equipment for underground coal mining, responsible for coal cutting, loading, and automated operation control; the gas concentration detector can monitor the gas concentration in the working environment in real time, providing key environmental parameters for safe production; and router A can serve as the network communication hub of LAN A, responsible for routing and forwarding interconnection of devices within the LAN and cross-network segment communication. The aforementioned local area network (LAN) B can be deployed in the tunnel excavation area as the core control network for tunnel excavation. It not only performs tunnel development tasks but also transports coal or gangue generated during excavation in a timely manner via belt conveyors, forming a collaborative working environment for excavation and transportation. The broadcast domain of LAN B can include belt conveyor 1 (i.e., electronic device 21), tunneling machine (i.e., electronic device 22), and router B (i.e., electronic device 20). The tunneling machine is responsible for the development and excavation of coal mine tunnels, collecting real-time data on geological conditions, excavation progress, and equipment status at the excavation face. Belt conveyor 1 is responsible for transporting coal mined by the tunneling machine or gangue generated during tunnel excavation, serving as a key device connecting excavation operations with subsequent processing stages. Router B acts as the network communication hub of LAN B, responsible for routing and forwarding communication between devices within the LAN and across network segments.

[0099] Understandable. Figure 3 This example only demonstrates some electronic devices within the broadcast domains of LAN A and LAN B, but it fully presents the core elements of cross-LAN communication: the coal mining machine 1 (electronic device 11) in the coal mining face and the tunneling machine (electronic device 22) in the roadway excavation area can each serve as core production equipment in two independent LANs. The aforementioned device communication method is implemented through a soft bus communication architecture, thereby achieving collaborative operation of devices across LANs. Specifically, the aforementioned device communication method can be divided into a device authentication and networking stage and a data transmission stage.

[0100] Device certification and networking phase

[0101] The aforementioned device authentication and networking phase refers to the preparatory stage where electronic devices complete identity verification, authorization confirmation, and establish a trusted topology and secure channel before transmitting business data based on a soft bus communication architecture. Through this device authentication phase, participating electronic devices can effectively determine whether the other end (i.e., another electronic device, such as another mining terminal device) has legitimate communication qualifications, that is, whether the other end is a trustworthy electronic device (i.e., a trusted device / trusted device), and possess end-to-end secure data transmission capabilities, thus preparing for subsequent business data exchange.

[0102] Figure 4 This is a flowchart illustrating the device authentication and networking stage in a device communication method provided in this application embodiment.

[0103] S101. Electronic devices can each connect to their own local area network.

[0104] Specifically, the aforementioned electronic devices can connect to the corresponding local area network (LAN) according to the broadcast domain in which the electronic device resides. For example, such as... Figure 3 As shown, the aforementioned coal mining machine 1 (i.e., electronic device 11) and the aforementioned gas concentration detector (i.e., electronic device 12), etc., are mining terminal equipment that can connect to local area network A through the aforementioned router A. The aforementioned belt conveyor 1 (electronic device 21) and the aforementioned tunneling machine (electronic device 22), etc., are mining terminal equipment that can connect to local area network B through the aforementioned router B. This application embodiment does not impose any special restrictions on whether the aforementioned mining equipment uses Ethernet connection, Wi-Fi connection, or other connection methods when accessing the local area network through a router. Optionally, the aforementioned local area network (including...) Figure 3 Local area networks (LANs) A and B in the example can use User Datagram Protocol / Internet Protocol (UDP / IP) as their communication protocol. However, they are not limited to UDP / IP; other communication protocols, such as Transmission Control Protocol / Internet Protocol (TCP / IP), can also be used. This application does not impose any specific restrictions on the communication protocol used by the LANs. It is understood that different LANs can use different or the same communication protocols.

[0105] Figure 5 This is a schematic diagram of a cross-local area network architecture for electronic devices provided in an embodiment of this application.

[0106] When electronic devices connect to a local area network (LAN), the router or a dedicated Dynamic Host Configuration Protocol (DHCP) server within the LAN can automatically assign network configuration parameters to the connected devices. These network configuration parameters include, but are not limited to, IP address, subnet mask, and gateway. For example... Figure 5 As shown, when the coal mining machine 1 (i.e., electronic device 11) is connected to local area network A, it can be automatically assigned the IP address 192.168.1.2; similarly, when the gas concentration detector (i.e., electronic device 12) is connected to local area network A, it can be assigned the IP address 192.168.1.3. In addition, the router A (corresponding to electronic device 10) in local area network A has the IP address 192.168.1.1.

[0107] Similarly, after the belt conveyor 1 (i.e., electronic device 21) connects to LAN B, it can be automatically assigned the IP address 192.168.2.2; similarly, after the tunneling machine (i.e., electronic device 22) connects to LAN B, it can be assigned the IP address 192.168.2.3. In addition, the router B (corresponding to electronic device 20) in LAN B has the IP address 192.168.2.1.

[0108] S102. Electronic devices can discover other electronic devices within the local area network and complete pairwise authentication and networking based on a soft bus architecture.

[0109] Specifically, the constrained application protocol (CoAP) can be used between electronic devices to achieve device discovery and authentication within the aforementioned local area network. In this case, the electronic devices need to have CoAP communication capabilities. Step S102 is described below using the example of device discovery and authentication between electronic devices 11 and 12 based on the CoAP protocol. Figure 3 and Figure 5 The following process can be used as a reference for device discovery and pairwise device authentication between electronic devices in other local area networks, and will not be repeated below.

[0110] The CoAP protocol described above supports device discovery via broadcast communication. For example, after accessing LAN A, the electronic device 11 can send a device discovery broadcast message. This message may carry one or more of the following parameters of the electronic device 11: device identifier (ID), device name, device type, IP address, etc. The device ID can be presented using a universally unique identifier (UUID). The device ID, device name, IP address, and other parameters can all be used to identify the electronic device; therefore, these parameters are also called device identification information. In the coal mine scenario described above, the device types may include coal mining machines, hydraulic supports, scraper conveyors, tunneling machines, belt conveyors, gas detectors, cameras, smart mine lamps, explosion-proof mobile phones, etc. It is understood that the device types can be pre-defined by the developers. In some implementations, after accessing LAN A, the electronic device 11 can periodically send the device discovery broadcast message. In some implementations, the electronic device 11 may send the device discovery broadcast message only after detecting the first user operation. For example, if a first application is present on the electronic device 11, the electronic device 11 will send the device discovery broadcast message only after detecting a user operation in the first application that enables the device discovery and authentication function. This application embodiment does not specifically limit how device discovery is initiated after the electronic device accesses the local area network.

[0111] After accessing local area network A, the aforementioned electronic device 12 can receive the device discovery broadcast message. Upon receiving the device discovery broadcast message, the electronic device 12 can determine whether to respond to the device discovery broadcast. For example, since the network environment in the mine may be unstable, the aforementioned electronic device 12 can assess the network environment by detecting the status of the network interface, measuring network signal strength and bandwidth, etc. For example, when the network bandwidth is detected to be lower than a first value or the signal strength is lower than a second value, the electronic device 12 can determine that the current network environment is poor, and therefore will not respond to the aforementioned device discovery broadcast to avoid further increasing the network burden; conversely, if the electronic device 12 determines that the current network environment is good (i.e., there is no situation where the network bandwidth is lower than the first value or the signal strength is lower than the second value), then the electronic device 12 can respond to the aforementioned device discovery broadcast. Not limited to the above methods, the electronic device can also determine whether to respond to the aforementioned device discovery broadcast based on its own working status (e.g., whether it is in maintenance mode or fault state), etc. The embodiments of this application do not specifically limit how the electronic device that receives the device discovery broadcast determines whether to respond to the device discovery broadcast. If a response is deemed acceptable, in response to the aforementioned device discovery broadcast, electronic device 12 can unicast a discovery response message to electronic device 11 based on the IP address of electronic device 11 in the device discovery broadcast. Similarly, the discovery response message may also carry one or more of the following parameters of electronic device 12: device ID, device name, device type, IP address, etc. In addition, the discovery response message may also carry data such as device status information; wherein, the device status information may include device operating status (e.g., normal operation, fault shutdown, maintenance mode, standby state, etc.), real-time detected data (e.g., the current gas concentration value of the gas detector, etc.), device communication connection status (e.g., the connection stability, signal strength, packet loss rate, etc. between the device and the network), etc. This application embodiment does not specifically limit what data is included in the discovery response message.

[0112] Upon receiving the aforementioned discovery response message, electronic device 11 can discover electronic device 12 and send an authentication request to electronic device 12 based on the IP address of electronic device 12 in the discovery response message. The authentication request may carry parameter information such as the device ID, device name, device type, IP address, and digital certificate of electronic device 11. The parameter information of electronic device 11 carried in the authentication request can also serve as the authentication information of electronic device 11. It is understood that if the electronic device is the aforementioned mining terminal device (for example, electronic device 11 here is coal mining machine 1, belonging to the aforementioned mining terminal device), then the digital certificate of the electronic device can be issued by a mining certificate authority. Optionally, since electronic device 11 is the aforementioned mining terminal device, the authentication request message may also carry the geographical location identifier of electronic device 11. For example, the geographical location identifier may include one or more of the following: the mine area identifier (such as the mine area number) to which electronic device 11 belongs, the coal mine roadway (such as the roadway number) where electronic device 11 is located, and the working face area where electronic device 11 is located. Optionally, the authentication request message may also carry the information about the coal mine subsystem to which the electronic device 11 belongs. The coal mine subsystem refers to the functional modules obtained after subdividing the overall coal mine production, safety, and management system. Each coal mine subsystem can focus on specific functional implementations and cooperate with each other to ensure the normal production and management activities of the coal mine. The coal mine subsystem includes, but is not limited to, coal mining subsystems, tunneling subsystems, transportation subsystems, gas detection subsystems, carbon monoxide detection subsystems, power supply subsystems, drainage subsystems, and ventilation subsystems. It is understood that the geographical location identifiers (such as mine area number, roadway number, working face area, etc.) and coal mine subsystem-related data (such as classification information for coal mining system, transportation system, safety monitoring system, etc.) are all exemplary data generated based on the coal mine scenario. However, it should be noted that the data related to the scenario that may be included in the actual authentication request message is not limited to these two types—its specific content can be flexibly expanded according to the actual business needs, production environment characteristics, management model, and technology application direction in the coal mine scenario. This application embodiment does not impose any special limitations on this.

[0113] Upon receiving the authentication request, electronic device 12 can verify the legitimacy of electronic device 11's identity by checking the signature, validity period, and issuing authority of electronic device 11's digital certificate. If electronic device 12 confirms the legitimacy of electronic device 11, it can return an authentication result message to electronic device 11. This authentication result message may carry an authentication result identifier (e.g., authentication successful) and the authentication information of electronic device 12. This authentication information includes, but is not limited to, the device ID, device name, device type, IP address, digital certificate, and other parameter information of electronic device 12. It is understood that the fields of the authentication information of electronic device 12 included in the authentication result message correspond one-to-one with the fields of the authentication information of electronic device 11 included in the authentication request message. For example, if the authentication request message contains the geographical location identifier of electronic device 11, then the authentication result message may also contain the geographical location identifier of electronic device 12.

[0114] Upon receiving the authentication result message, electronic device 11 can similarly verify the identity of electronic device 12 by checking the signature, validity period, and issuing authority of its digital certificate. If electronic device 11 confirms the identity of electronic device 12 is legitimate, it can return a confirmation message to electronic device 12, thereby completing the two-way device authentication between them. Understandably, the confirmation message may carry an authentication result identifier (e.g., authentication successful).

[0115] After authentication, electronic devices 11 and 12 can be trusted devices within LAN A (i.e., the first LAN). Therefore, electronic devices 11 and 12 can each add the other authenticated electronic device to their trusted device list. It can be understood that after completing the device discovery and authentication process, electronic devices can establish a data connection, complete the networking process, and then exchange subsequent business data.

[0116] The device discovery process is not limited to broadcasting; multicast and other methods can also be used between electronic devices to achieve the same result. This application embodiment does not impose any special limitations on this. Furthermore, electronic devices can use other protocols to execute step S102 (i.e., the device discovery and authentication process within a local area network), and this application embodiment does not impose any special limitations on this. It is understood that regardless of the protocol actually chosen by the electronic device to implement the device discovery and authentication functions, the underlying implementation completes the corresponding operation steps by calling standardized API interfaces provided by the operating system or communication architecture.

[0117] S103. Electronic devices can detect whether cross-domain networking function is enabled.

[0118] The aforementioned cross-domain networking function refers to the ability of electronic devices to overcome the limitations of a single network domain and achieve interconnection and communication across local area networks through technical means.

[0119] In one implementation, the aforementioned cross-domain networking function can be manually enabled based on user operation. For example, when a user needs to temporarily establish cross-LAN communication, such as in the aforementioned coal mine scenario where the user temporarily needs to remotely debug mining terminal equipment within another LAN, the user can actively select the "Cross-domain Networking Switch" control in the settings application or the device management interface of the aforementioned first application to enable the cross-domain networking function. Therefore, if the electronic device detects a user operation (such as the selection operation) applied to the aforementioned "Cross-domain Networking Switch" control, the electronic device can confirm that the cross-domain networking function is enabled.

[0120] In another implementation, the aforementioned cross-domain networking function can be automatically configured based on preset rules or changes in the network environment. For example, when multiple local area networks (LANs) exist in the coal mine scenario (e.g., LAN A and LAN B), the electronic device can automatically enable the cross-domain networking function. Optionally, the electronic device can detect the existence of multiple LANs in the coal mine scenario through a topology-aware mechanism, and then automatically enable the cross-domain networking function. Alternatively, as... Figure 3 The cloud management platform shown can act as a unified operation and maintenance center in the aforementioned coal mine scenario. This cloud management platform can record and maintain the number and status information of connected local area networks (LANs) in real time. When multiple LANs are detected (e.g., LAN A and LAN B are both registered to the cloud management platform), the cloud management platform can proactively send notifications to electronic devices within each LAN (e.g., via API push, configuration updates, or heartbeat packets carrying status information). Upon receiving the notification, the electronic devices can automatically enable cross-domain networking functionality.

[0121] This application does not specifically limit how the electronic device detects the activation of the above-mentioned cross-domain networking function.

[0122] If the electronic device detects that the cross-domain networking function is enabled, it can continue to execute step S104 below. If the electronic device detects that the cross-domain networking function is not enabled, it can terminate the execution of subsequent steps S104 to S108, that is, stop executing the remaining process of the above device communication method.

[0123] S104. Electronic devices can determine the root node device of the local area network.

[0124] The aforementioned root node devices can be used for proxying and routing cross-LAN communication. Therefore, these root node devices should possess at least the following capabilities: data forwarding capability and the ability to simultaneously connect to multiple LANs. Specifically, electronic devices can achieve simultaneous access to multiple LANs by configuring multiple network interface cards (NICs) (or multiple network interfaces). Each NIC can independently connect to different LAN domains, thereby constructing a multi-link concurrent communication architecture and providing underlying network support for cross-LAN data interaction and collaborative control.

[0125] The aforementioned electronic devices can be configured with settings to indicate whether they belong to the root node or a non-root node within the local area network. For example, setting the configuration to 1 indicates that the electronic device belongs to the root node, while setting it to 0 indicates that it belongs to a non-root node.

[0126] In one implementation, the above configuration items can be set in advance by the developers.

[0127] In another implementation, electronic devices can elect the root node device of the local area network (LAN) based on the performance parameters of the devices connected to the LAN. Understandably, after completing pairwise authentication, electronic devices can exchange their performance parameters. These performance parameters include, but are not limited to, throughput, network latency, signal strength, bandwidth capacity, protocol support types, computing resources (such as CPU / memory / storage performance), storage capacity, power consumption, and historical communication stability metrics. It is understood that the stronger the performance of an electronic device, the more likely it is to be elected as the root node device of the LAN. For example, in... Figure 5 In this context, the aforementioned electronic device 10 (i.e., the first electronic device) can be the root node device of local area network A (i.e., the first local area network), and the root node device of local area network A is determined based on the performance parameters of one or more devices in local area network A; the aforementioned electronic device 20 (i.e., the third electronic device) can be the root node device of local area network B (i.e., the second local area network), and the root node device of local area network B is determined based on the performance parameters of one or more devices in local area network B.

[0128] Optionally, electronic devices can use built-in large neural network models (such as deep learning models, large language models, or other artificial intelligence models) to achieve intelligent election of root node devices. Figure 6 This is a schematic diagram illustrating a method for identifying the root node device of a local area network (LAN) using a large model A, as provided in an embodiment of this application. Specifically, the electronic device may have a built-in large model A, which can comprehensively evaluate and determine the most suitable device to serve as the root node within the LAN based on the performance parameters of each electronic device in the LAN. Figure 6 As shown, with Figure 5Taking local area network A as an example, an electronic device (e.g., electronic device 11) can locally collect the performance parameters of all devices (e.g., electronic devices 10–12) within the local area network after authentication, and input them into the aforementioned large model A. The large model A can comprehensively compare parameters such as throughput, network latency, signal strength, and bandwidth capacity of each electronic device, and directly output that electronic device 10 is the most suitable root node device. Since each electronic device in the same local area network has obtained a dataset of consistent performance parameters and calls the same large model A for inference, the election results of the root node device obtained by each electronic device will necessarily be the same. Therefore, the unified, fast, and intelligent determination of the root node device can be achieved without manual weighting.

[0129] Optionally, electronic devices can also determine the root node device using preset election rules. For example, researchers can pre-assign weights to parameters such as throughput, network latency, and signal strength. Electronic devices can substitute the performance parameters of each electronic device in the locally maintained global area network into a weighted sum to obtain the score of that electronic device. After sorting the scores in descending order, the device with the highest score is directly selected as the root node device. Similarly, as long as all electronic devices use the same weight settings and sorting logic, the election result of the root node device will necessarily be consistent. This application does not impose any special limitations on the specific form of the election rules, the specific parameters included in the performance parameters, or the weight settings of each performance parameter.

[0130] Understandably, if the root node device in the local area network (LAN) is determined through an election, electronic devices can update the configuration items of each electronic device in the LAN after the election. For example, if the configuration items of each electronic device are default settings before the election (e.g., all set to "0" for non-root node devices or all set to "null"), then after the election, the electronic devices can modify the locally stored configuration item information based on the election results, such as setting the root node device to "1" and the non-root node devices to "0". In some implementations, after the election, the electronic devices may not store the configuration items of each electronic device locally, but instead directly store the identification information of the root node device corresponding to their local LAN.

[0131] Understandably, electronic devices can re-elect the root node device at set intervals, and the configuration items are refreshed immediately after the role of the electronic device changes: the newly elected electronic device is set as the root node device, and the original root node device is simultaneously demoted to a non-root node device. Alternatively, electronic devices can establish the root node device of the local area network only once during the initial network setup, and then permanently lock it without further updates. This application does not impose special restrictions on the election refresh strategy and frequency.

[0132] S105. The root node device in the electronic equipment can obtain and configure the network segment parameters of the mining ring network.

[0133] Understandably, for ease of distinction, this solution defines the "local area network where the mining area terminal equipment is located and which has already obtained an IP address in the previous step S101" as the internal network, the corresponding address as the internal IP, also known as the private IP address, and the corresponding port as the private port; while if the root node device is to perform the proxy function for cross-local area network communication, it must also obtain a set of address parameters "facing other mining areas"—that is, the external IP and network segment configuration relative to the internal network, for example Figure 3 The network segment parameters of the mining ring network shown above, where the external IP is also called a public IP address, and the corresponding port is a public port. Therefore, the identification information of the above devices can actually include: device ID (such as UUID), and / or, device name, and / or, private IP address and private port, and / or, public IP address and public port. In some embodiments, the identification information of the above devices may also exclude the port and only include the IP address (such as private IP address and / or public IP address).

[0134] Similarly, the aforementioned network segment parameters include, but are not limited to, IP address, subnet mask, and gateway. Optionally, these network segment parameters can be directly input by the operator's staff, meaning the root node device can configure the network segment parameters of the mining ring network based on the staff's input. Optionally, after the electronic device confirms itself as a root node device, it can proactively request the aforementioned network segment parameters from the platform or address reserved by the operator and automatically configure them as the network segment parameters of the mining ring network.

[0135] For example, such as Figure 5 As shown, electronic device 10, as a device in local area network A, can have its internal IP address (i.e., private IP address) of LAN A as 192.168.1.1. However, after step S104 determines that it is the root node device (i.e., root node device 1) of LAN A, its IP address (i.e., public IP address) in the mining ring network can be configured as 10.100.1.1. Similarly, electronic device 20, as a device in local area network B, can have its internal IP address (i.e., private IP address) of LAN B as 192.168.2.1. However, after step S104 determines that it is the root node device (i.e., root node device 2) of LAN B, its IP address (i.e., public IP address) in the mining ring network can be configured as 10.100.1.2.

[0136] S106. Each local area network root node device can discover and establish connections with each other within the above-mentioned mining area ring network.

[0137] The completion of the network segment parameter configuration in step S105 above means that the root node device has a legal IP address within the scope of the mining area ring network, thus enabling the root node device to communicate with any electronic device (such as the root node device of another local area network) that is also connected to the mining area ring network. The mining area ring network is also called a third local area network.

[0138] Subsequently, the root node devices of each local area network (LAN) can perform device discovery and authentication steps within the scope of this new LAN, the mining ring network. For example, such as... Figure 5 As shown, electronic device 10, acting as the root node device (i.e., root node device 1) in local area network A, can discover and authenticate other root node devices (such as electronic device 20, i.e., root node device 2) based on the IP address (e.g., 10.100.1.1) allocated in the mining ring network. Understandably, after the above discovery and authentication process, electronic device 10 (i.e., the first electronic device) and electronic device 20 (i.e., the second electronic device) become mutually trusted devices within the mining ring network (i.e., the third local area network). The specific implementation process can be found in the relevant description in step S102 above, and will not be repeated here.

[0139] Understandably, the fact that each local area network root node device can discover and authenticate each other within the mining area ring network means that a secure and reliable communication connection can be established between the previously relatively independent local area networks within the mining area, providing a prerequisite for the efficient collaborative operation of the overall mining area network in the future.

[0140] S107. Root node devices can exchange parameter information of trusted electronic devices within their respective local area networks.

[0141] After completing the mutual discovery and authentication between the root node devices, they can exchange parameter information of trusted electronic devices within their respective local area networks, which becomes trusted device information. The exchanged trusted device parameter information may include one or more of the following: the device ID, device name, device type, and IP address of the electronic device. The device ID, device name, and IP address are also referred to as device identification information. In addition, the device information of the electronic device may also include one or more of the following: the geographical location of the device, the production subsystem to which the device belongs, the device's security level, and performance parameters. For example, for... Figure 5 Regarding the electronic devices shown, electronic devices 10 and 20 belong to the mining area ring network (i.e., the third local area network). Within the mining area ring network, electronic device 20 can send the aforementioned trusted device information to electronic device 10. The trusted device information sent by electronic device 20 is also called the second trusted device, which includes parameter information of one or more trusted devices in local area network B (i.e., the second local area network).

[0142] Optionally, the fields in the LAN parameter information exchanged by the root node device can be consistent with the fields in the parameter information exchanged between electronic devices during the previous device discovery and authentication process within the LAN. In this way, a set of parameter information containing electronic devices across the mining area's LAN can be integrated, while ensuring that the fields contained in the parameter information of each electronic device are the same. This facilitates unified management, analysis, and processing, providing comprehensive and accurate data support for the intelligent management and decision-making of the mining area.

[0143] Understandably, the core purpose of step S107 described above is to clearly identify which electronic devices are trustworthy through information exchange between root node devices, thereby laying the foundation for subsequent network management, device collaboration, or security control operations. Therefore, optionally, the local area network parameter information fields exchanged between root node devices should at least include device identification information (e.g., device ID and IP address) to ensure that trustworthy electronic devices can be uniquely identified and located. This application embodiment does not impose any special restrictions on the specific content of the parameter information of trustworthy electronic devices within their respective local area networks exchanged between root node devices.

[0144] S108. The root node device can synchronize the parameter information of trusted electronic devices in other local area networks to non-root node devices in its own subnet.

[0145] After step S107, the root node device can identify which electronic devices in other local area networks are trusted. Subsequently, the root node device can synchronize this trusted electronic device information to non-root node devices within the local area network.

[0146] For example, root node device 1 can confirm that electronic devices 20-22 in LAN B are trusted electronic devices through step S107. Then, root node device 1 can send trusted device information (especially parameter information of trusted devices in other LANs) to non-root node devices (e.g., electronic devices 11 and 12) in LAN A, so that electronic devices 11 and 12 can also confirm that electronic devices 20-22 in LAN B are trusted electronic devices. The trusted device information sent by root node device 1 (i.e., electronic device 10 / first electronic device) to non-root node devices (e.g., electronic device 11, i.e., second electronic device) is also called first trusted device information, which may include parameter information of one or more trusted devices in LAN B. These one or more trusted devices in LAN B include electronic device 20 (i.e., third electronic device) and electronic device 22 (i.e., fourth electronic device), and the parameter information includes the aforementioned identification information. The aforementioned first trusted device information can be equal to the aforementioned second trusted device information, or it can include more trusted device parameter information than the aforementioned second trusted device information (for example, the first trusted device information may also include parameter information of trusted devices in other local area networks). It can be understood that when the root node device synchronizes the trusted device information of other local area networks to the non-root node devices within its local area network, it essentially achieves the process of distributing the locally maintained trusted device list to these non-root node devices.

[0147] Through the trusted device information synchronization mechanism between the aforementioned electronic devices (i.e., steps S107 and S108), although the electronic devices in LAN A and LAN B do not directly execute the point-to-point authentication process, they have essentially established a cross-LAN trust relationship indirectly through data exchange between root node devices and between root node devices and non-root node devices. Devices in LAN A (such as electronic device 11) can obtain and confirm the trusted identity of devices in LAN B (such as electronic devices 20-22) through root node device 1 (i.e., electronic device 10), thereby logically "discovering" these cross-LAN devices and regarding them as trusted devices, which is equivalent to completing an indirect authentication. Subsequently, the electronic devices can achieve cross-LAN networking.

[0148] In the above method, step S103 is optional, meaning that the electronic device can directly jump to the subsequent step S104 after executing step S102. This is because the electronic device can be set to have cross-domain networking enabled by default.

[0149] In the above method, if the root node device is configured manually by the user, steps S104 and S105 can be executed immediately after the electronic device is powered on. For example, after each electronic device is powered on, the user can directly input relevant configuration items through the first application on the device; subsequently, the electronic device can read the configuration information pre-input by the user after completing step S101. This means that the configuration process does not need to wait for all devices in the local area network to complete pairwise authentication, but can complete the settings in advance based on user input. This application embodiment does not impose special restrictions on the specific timing of determining whether each electronic device in the local area network is a root node device or a non-root node device based on user manual configuration after the electronic device is powered on.

[0150] It is worth noting that the solution presented in the above-mentioned device authentication networking phase is fundamentally different from the traditional routing and forwarding strategy: conventional routing and forwarding only realizes the cross-network segment transmission of data packets, and devices in LAN A cannot perceive or discover the specific electronic devices existing in LAN B; while in this solution, through the synchronization and downward distribution of the trusted device list (i.e., the parameter information of the aforementioned trusted devices) between root node devices and between root node devices and non-root node devices, not only is the routing reachability of cross-LAN communication supported, but also enables non-root node devices in each LAN to actively "discover" and clearly identify the authenticated trusted devices and their identity information in other LANs, thereby building a cross-domain trust system with both reachability and knowability at the network layer.

[0151] Understandably, in real-world industrial scenarios (such as coal mine environments), the core requirements for cross-LAN collaboration differ fundamentally from those in non-industrial scenarios (such as the aforementioned office or home scenarios). Only when non-root node devices (such as underground sensors and coal mining machines) possess the ability to proactively discover other non-root node devices on the local area network can direct invocation and real-time collaboration between cross-domain devices be truly supported. This is drastically different from the user-terminal-centric collaboration model in traditional office networks, which relies on fixed routing strategies or centralized authentication. In the aforementioned office scenarios, cross-network segment devices typically meet basic communication needs through preset routing rules or centralized server relays, eliminating the need for frequent autonomous discovery between devices. However, industrial environments require electronic devices (especially non-root node production terminals, such as the aforementioned mining terminal devices) to proactively perceive the status of surrounding cross-domain devices in order to flexibly respond to collaborative scenarios with high real-time requirements, such as sudden task scheduling and equipment linkage control. This solution utilizes a trusted device information synchronization mechanism between root node devices and between root node devices and non-root node devices. This allows non-root node devices to indirectly obtain a cross-domain trusted device list without direct authentication, ensuring network security in industrial environments such as mining areas while precisely adapting to the strong reliance on autonomous device collaboration in production sites.

[0152] At this point, the device authentication and networking phase is complete. Electronic devices distributed across multiple local area networks (LANs) in the same application scenario have successfully completed the cross-domain authentication and networking process, enabling cross-LAN electronic devices to establish communication connections and transmit business data. The data transmission phase of the above device communication method will be described below.

[0153] Data transmission phase

[0154] The aforementioned data transmission phase refers to the stage where electronic devices, after completing device authentication and networking, interact and transmit actual business data based on the established trust relationship and the aforementioned soft bus communication architecture. Through this data transmission phase, mutually trusted electronic devices can utilize the secure channel provided by the soft bus communication architecture to achieve efficient and reliable data flow across local area networks, ensuring that business data (such as sensor-collected information, control commands, and status feedback) can be accurately transmitted and collaboratively processed between trusted devices. Specifically, this phase, building upon the identity verification and authorization confirmation established during the device authentication and networking phase, further enables the orderly exchange and collaborative application of business data between the communicating parties. It supports real-time data synchronization, task collaboration, and business logic linkage among multiple devices, and is a crucial link in building substantial business collaboration between devices within a complete mining ecosystem.

[0155] Figure 7 This is a schematic diagram illustrating a data transmission stage provided in an embodiment of this application. Figure 7 In this context, electronic devices connected directly or indirectly by dashed lines are considered trustworthy electronic devices, while solid lines with arrows can be used to identify the transmission path of data packets during cross-domain data transmission.

[0156] like Figure 7 As shown, taking cross-LAN communication between electronic devices 11 and 22 as an example, through the cross-LAN data transmission mechanism under the soft bus communication architecture, electronic device 11 can achieve reliable cross-domain data transmission and interaction without directly establishing a point-to-point connection with electronic device 22. Instead, it relies on the trusted channel built by the root node devices (such as root node device 1 and root node device 2) of LAN A and LAN B. In the coal mine scenario, this mechanism not only ensures the security isolation requirements of network communication but also provides key communication support for mining collaboration in intelligent coal mine production.

[0157] The following is combined Figure 3 and Figure 7 Taking the data transmission from electronic device 11 (coal mining machine 1) to electronic device 22 (tunneling machine) across the local area network as an example, the specific implementation of this solution is explained in detail.

[0158] Understandably, in actual coal mine production scenarios, when the coal mining machine 1 (i.e., the aforementioned electronic device 11) analyzes the coal seam status and overall production progress of the current working face based on the intelligent decision-making system, it may need to actively adjust the tunneling parameters and operating status of the tunneling machine (i.e., the aforementioned electronic device 22) to achieve precise coordination and production optimization in mining operations. In this case, the coal mining machine 1 can send cross-local area network control commands to the tunneling machine through a soft bus communication architecture, including adjusting the tunneling speed (e.g., matching the optimal advance rate according to the coal mining machine's cutting capacity), optimizing the tunneling direction (e.g., fine-tuning the tunneling angle according to the coal seam direction), controlling the tunneling machine to pause or resume operations (e.g., temporarily stopping tunneling operations when the coal mining machine is about to reach the tunneling face), and adjusting the cutting depth (e.g., coordinating the cutting depth according to changes in geological conditions). These control commands can help the tunneling machine accurately coordinate with the working rhythm and position requirements of the coal mining machine, avoiding work interruptions caused by the coal mining machine 1 not excavating in time when it reaches the tunneling face, or safety hazards caused by untimely roof support due to tunneling ahead. By actively controlling the tunneling machine from the coal mining machine, seamless connection of the mining face can be achieved, the overall production process can be optimized, the efficiency and safety of coal mining can be improved, equipment idling and energy waste can be reduced, and the risk of equipment wear and production accidents caused by uncoordinated mining can be reduced, thus realizing the overall optimization and intelligent scheduling of the mine production system.

[0159] Figure 8 This is a schematic diagram illustrating a cross-LAN collaborative control process between electronic devices based on a soft bus, as provided in an embodiment of this application. The electronic device sending data is also called the source device, and the electronic device ultimately receiving data is also called the target device.

[0160] S201. The source device can determine the local area network affiliation of the target device.

[0161] Understandably, the source device (such as the coal mining machine 1 / electronic device 11) can collect its own operating status data (including but not limited to cutting depth, drum speed, and cutting tooth wear) and spatial location information (such as current coordinates and advance direction) in real time through built-in sensors, and perform intelligent analysis and decision-making in combination with preset production target parameters (such as target coal mining volume and cutting path planning). In some embodiments, the aforementioned target device and the business data such as the control commands to be transmitted can be determined by a neural network intelligent decision-making model. Specifically, the source device can input its currently collected operating status data (such as cutting depth and drum speed) and the real-time status data (such as tunneling speed and tunneling face coordinates) of other cooperating electronic devices (such as tunneling machines) into a pre-trained neural network large model (such as large model B), and output the optimal target device identifier (such as the tunneling machine device ID that needs to cooperate), control parameters (such as target tunneling speed and direction adjustment angle), and the local area network affiliation information of the target device, thereby accurately determining the data content and communication objects that need to be interacted through the soft bus communication architecture. This intelligent decision-making process can effectively improve the accuracy and coordination efficiency of equipment communication, and is particularly suitable for equipment linkage control scenarios under complex working conditions. In some embodiments, the target device described above can also be determined directly based on user input (such as user selection input). This application does not specifically limit how the source device determines the target device.

[0162] Once the target device is identified, the source device can determine the target device's local area network (LAN) affiliation. This LAN affiliation information can be presented as a LAN number (e.g., LAN B corresponds to number 02) or network segment information (e.g., 192.168.2.0 / 24). Understandably, the purpose of the source device determining the target device's LAN affiliation is to determine whether the target device is within the same LAN as the source device.

[0163] Optionally, the source device can directly determine the local area network (LAN) affiliation of the target device based on the output of the aforementioned large model B. For example, the aforementioned electronic device 11 (i.e., the source device) can call the large model B and directly output electronic device 22 as the target device, and output that electronic device 22 is located in LAN B; the source device can compare this output result (i.e., LAN B) with its own LAN (i.e., LAN A) to determine that the target device and the source device are not in the same LAN.

[0164] Optionally, after identifying the target device, the source device can also obtain the target device's IP address and the subnet mask of the target LAN through network configuration queries, and then calculate the network segment information of the target device's network. Simultaneously, the source device can also obtain its own current IP address and the subnet mask of its LAN, and calculate the network segment information of its LAN by comparing the IP address and subnet mask. If the target device's network segment information matches the source device's LAN network segment information, then the target device and the source device are determined to belong to the same LAN; if they do not match, then the target device and the source device are determined to belong to different LANs.

[0165] This application embodiment does not specifically limit how the source device determines the local area network (LAN) affiliation of the target device. Based on the above judgment logic, if the target device and the source device belong to the same LAN, the source device executes step S202; if the target device and the source device belong to different LANs, the source device executes steps S203 to S205.

[0166] S202. When the target device and the source device are on the same local area network, the source device can directly send service data to the target device.

[0167] Understandably, when the target device and the source device are on the same local area network (i.e., the target device's IP address is within the IP range of this local area network), there is no obstacle to cross-local area network communication as mentioned above. The source device can directly establish a data transmission channel through the local area network communication protocol and send business data (such as control commands and sensor data) directly to the target device without going through the root node device, ensuring low latency and high efficiency in communication between devices within the same local area network.

[0168] For example, when the source device is electronic device 11 (i.e., coal mining machine 1) and the target device is electronic device 12 (i.e. gas concentration detector), electronic device 11 can directly establish a data connection with electronic device 12, and then electronic device 11 can directly request gas concentration data in the current environment from electronic device 12.

[0169] For example, when the source device can be a coal mining machine 1 (electronic device 11) in LAN A and the target device can be a tunneling machine (electronic device 22) in LAN B, a typical scenario for cross-LAN communication between the source and target devices can be: the coal mining machine 1 sends control commands (such as adjusting the tunneling speed or direction compensation) to the tunneling machine to achieve coordinated mining and tunneling operations. Since the coal mining machine 1 is located in LAN A (IP segment: 192.168.1.0 / 24) and the tunneling machine is located in LAN B (IP segment: 192.168.1.0 / 24), they belong to different LANs. At this time, the coal mining machine 1, as the source device, will trigger a cross-domain communication process—encapsulating the control commands into a cross-domain transmission request packet, sending it first to the root node device 1 of LAN A (i.e., the root node of this LAN) through the internal communication network of LAN A, and then the root node device 1 further completes the cross-domain routing and forwarding, finally accurately delivering the control commands to the tunneling machine (target device). The above process is specifically embodied in the following steps S203 to S205.

[0170] S203. When the target device and the source device are not on the same local area network, the source device can first send the service data to the root node device of the local area network.

[0171] When the target device and the source device belong to different local area networks (i.e., the target device's IP address is not within the IP range of this local area network), the source device can trigger a cross-domain communication process by encapsulating the business data into a data packet and sending it to the root node device of this local area network via the internal communication network of this local area network.

[0172] by Figure 7 Taking the typical scenario shown as an example, when the source device is a coal mining machine 1 (electronic device 11) in local area network A and the target device is a tunneling machine (electronic device 22) in local area network B, one application scenario for cross-domain communication between the two is that the coal mining machine 1 sends control commands to the tunneling machine (such as adjusting the tunneling speed or direction compensation) to achieve coordinated control of mining operations. Figure 7 The solid curves with arrows visually illustrate the actual flow of data during cross-domain communication between electronic device 11 and electronic device 22. The direction of the arrows indicates the direction of data transmission, clearly depicting the complete communication path from the source device through the root node to the target device.

[0173] Specifically, the control commands (business data) generated by the coal mining machine 1 need to be encapsulated through layers of protocols before they can be sent to the root node device of this local area network (i.e., root node device 1 / electronic device 10 / router A).

[0174] First, the coal mining machine 1 can generate the business data to be sent. For example, in the above example, the generated business data can be the control command. Exemplarily, the control command can include parameters such as target speed (e.g., 4.5 m / min) and direction compensation (e.g., 5°). This embodiment does not specifically limit which parameters are included in the control command. The control command can be presented in JSON format. For example, the control command can be presented as: {"command":"adjust_speed_and_direction","target_speed": 4.5,"direction_offset": 5}. Subsequently, the coal mining machine 1 can use the CoAP protocol to encapsulate the business data at the application layer, that is, add a CoAP header to the business data, including message type, request code, and Uniform Resource Identifier (URI) and other control information, forming an application layer data unit. The message type can be used to determine whether the transmission requires confirmation, the request code can be used to indicate the operation semantics, and the URI can be used to indicate the target resource (i.e., the operation object) to be operated on. Optionally, the coal mining machine 1 can use the target device's equipment information, including but not limited to the target device's identification information (such as the target device's UUID), as a parameter of the aforementioned URI. Optionally, the coal mining machine 1 can also use other fields in the application layer to carry the aforementioned target device's equipment information. This application embodiment does not impose any special restrictions on which specific fields the coal mining machine 1 (i.e., the source device) uses to carry the target device's equipment information.

[0175] Next, the coal mining machine 1 can encapsulate the aforementioned application layer data units into transport layer protocol messages, that is, add a transport layer protocol header to the application layer data units. The transport layer can be implemented based on the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP). The transport layer header can include transmission control information such as the source port number (e.g., port number 5000 for the coal mining machine 1 control program) and the destination port number (e.g., port number 6000 for the tunneling machine receiving services), thus constructing a complete transport layer data packet through the encapsulation process. Subsequently, the coal mining machine 1 can further encapsulate the transport layer data packet into a network layer IP data packet. The header of the IP data packet can include the source IP address, destination IP address, and routing information such as the protocol type (identifying the upper layer as TCP / UDP), forming an IP data packet that can be routed across local area networks within the network. Figure 7Taking the routing example, the IP data packet constructed by the coal mining machine 1 can use its own IP address within LAN A (i.e., 192.168.1.2) as the source IP address, and the IP address of the root node device within LAN A (i.e., 192.168.1.1) as the destination IP address. Ultimately, this layered encapsulated data packet can be sent from the coal mining machine 1 (i.e., electronic device 11) to the root node device (i.e., electronic device 10) of LAN A via LAN A. The data packet sent by the coal mining machine 1 (i.e., electronic device 11 / second electronic device) to the root node device (i.e., electronic device 10 / first electronic device) of LAN A is also called the first data packet, and the service data (such as the control commands mentioned above) within it is also called the first service data.

[0176] S204. The root node device of the local area network where the source device is located can forward service data to the root node device of the local area network where the target device is located.

[0177] The root node device of the local area network where the source device is located (e.g.) Figure 7 The root node device 1) can parse the data packet received through step S203 above, extract the CoAP application layer data unit, and further re-encapsulate it according to the device information of the target device (tunneling machine), thereby forwarding the above service data to the root node device (e.g., the target device's local area network) where the target device is located. Figure 7 The root node device 2 in the middle.

[0178] Specifically, continuing with the example above, after receiving the IP data packet, root node device 1 can decapsulate the received IP data packet layer by layer, finally extracting the application layer CoAP message. Subsequently, root node device 1 can parse the target device's identification information, such as the target device's device ID, from the CoAP message header. Not limited to parsing the target device's device information from the CoAP message header, root node device 1 can also obtain the target device's identification information by parsing the target device field in the service data (such as the "target_device_id" parameter in JSON format). It is understood that if the source device writes the target device's identification information into the CoAP's payload field or other fields in step S203, then root node device 1 can extract the target device's device information at the same location in step S204.

[0179] If the target device (here, the fourth electronic device / electronic device 22) is included in the list of trusted devices of root node device 1 (i.e., the first electronic device), then root node device 1 can send a re-encapsulated data packet to the root node device (here, the third electronic device / electronic device 20 / root node device 2) in the local area network where the target device is located. This re-encapsulated data packet sent by root node device 1 to root node device 2 is also called the second data packet. Specifically, root node device 1 can traverse its locally cached list of trusted devices. This list contains parameter information of electronic devices identified as trusted, obtained through exchange and synchronization with other root node devices in step S107, including the identification information (such as device ID) of these trusted electronic devices. Root node device 1 can perform an exact match between the target device's device ID and entries in its local list of trusted devices (e.g., using a hash table for fast lookup or a string comparison algorithm). After a successful match, root node device 1 can initiate the subsequent data forwarding process. Figure 7 Taking the route shown as an example, the IP data packet constructed by the root node device 1 (i.e., the second data packet) can use its own IP address in the mining ring network (i.e., 10.100.1.1) as the source IP address, and the IP address of the root node device 2 in the mining ring network (i.e., 10.100.1.2) as the destination IP address. Finally, the re-encapsulated IP data packet can be sent from the root node device 1 (i.e., electronic device 10 / router A) to the root node device (i.e., root node device 2 / electronic device 20 / router B) of the local area network B through the mining ring network.

[0180] If the target device (here, the fourth electronic device / electronic device 22) is not included in the list of trusted devices of root node device 1 (i.e., the first electronic device), that is, root node device 1 did not find a match in the above matching process, then root node device 1 cannot determine the IP address of the next hop. Therefore, root node device 1 can refuse to perform the above data forwarding, that is, root node device 1 will not generate the above second data packet, thereby ensuring that only authenticated trusted devices can participate in cross-LAN collaborative operations.

[0181] S205. The root node device of the local area network where the target device is located can forward the above-mentioned service data to the target device.

[0182] Root node device 2 can receive IP data packets (i.e., the second data packet) from root node device 1 through the mining ring network. Similarly, root node device 2 can parse the received IP data packets to extract the target device's identification information. After receiving the second data packet, if the target device (here, the fourth electronic device / electronic device 22) is included in root node device 2's list of trusted devices, root node device 2 (i.e., the third electronic device) can send a re-encapsulated data packet to the target device (here, the fourth electronic device / electronic device 22) through LAN B. This re-encapsulated data packet sent by root node device 2 to the target device is also called the third data packet. Figure 7 Taking the route shown as an example, the IP data packet constructed by the root node device 2 can use its own IP address in LAN B (i.e., 192.168.2.1) as the source IP address, and the IP address of the target device (i.e., electronic device 22) in LAN B (i.e., 192.168.2.3) as the destination IP address. That is, the third data packet can carry the private IP address of the destination device (such as the fourth electronic device / electronic device 22). Finally, the re-encapsulated IP data packet can be sent from the root node device 2 to the target device's electronic device 22 (such as a tunneling machine) in LAN B via LAN B, thus ultimately achieving accurate delivery and reliable transmission from the source device to the target device.

[0183] After receiving the second data packet, if the target device (here, the fourth electronic device / electronic device 22) is not included in the list of trusted devices of the root node device 2 (i.e., the third electronic device), then the root node device 2 may not generate the third data packet.

[0184] For specific details, please refer to the relevant steps of root node device 1 in step S204, which will not be repeated here.

[0185] Understandable. Figure 7 The aforementioned cross-domain data transmission relies on a proxy process on the root node device to perform packet unpacking, verification of trusted devices, and forwarding. For example, in Figure 7In this embodiment, electronic device 11 (i.e., the second electronic device) can send the first data packet to the first proxy process running on electronic device 10 (i.e., the first electronic device) via local area network A. Electronic device 10 can parse the identification information of electronic device 22 (i.e., the fourth electronic device) from the first data packet through the first proxy process. Subsequently, electronic device 10 can generate the second data packet based on the identification information of electronic device 22 and the first service data through the first proxy process and send it to electronic device 20. Alternatively, after receiving the first data packet, electronic device 10 can send the second data packet to the second proxy process running on electronic device 20. Electronic device 20 can parse the second data packet to obtain the identification information of electronic device 22 through the second proxy process. Subsequently, electronic device 20 can generate a third data packet based on the identification information of electronic device 22 and the first service data through the second proxy process and send it to electronic device 22. Once this process is abnormally terminated or manually killed, although the IP layer routing still exists, the application layer proxy logic is missing. The IP data packet will be directly discarded because it cannot pass trust verification and re-encapsulation, and cross-mine transmission will be interrupted. The proxy process can be a system process or a third-party process; this embodiment does not impose any special restrictions on this.

[0186] Figure 9 This is a schematic diagram of another data transmission stage provided in an embodiment of this application. Figure 9 The cross-domain data transmission shown can be completed directly at the transport layer without relying on the agent process on the root node device, thus avoiding the situation where cross-domain data cannot be transmitted after the agent process is killed.

[0187] The following is combined Figure 3 and Figure 9 Taking the example of electronic device 11 (coal mining machine 1) transmitting data across the local area network to electronic device 22 (tunneling machine), the specific implementation of this solution will be explained in detail.

[0188] like Figure 9As shown, during the device authentication and networking phase, after the root node device confirms its identity, or after the root node device and non-root node devices complete pairwise device authentication, the root node device can obtain the IP address and port of the non-root node device within its local area network (LAN). Then, within its own mining ring network address space, it allocates a unique set of IP addresses and ports (i.e., public IP addresses and public ports) for the aforementioned non-root node devices within the mining ring network, and writes this mapping table of IP addresses and ports within its local area network to IP addresses and ports within the mining ring network into its local NAT / port mapping module. For example, root node device 2 can store a first mapping relationship, which may include the mapping between the private IP address and private port of electronic device 22 and the public IP address and public port of electronic device 22; root node device 1 can store a second mapping relationship, which may include the mapping between the private IP address and private port of electronic device 11 and the public IP address and public port of electronic device 11. It is understood that in step S107 above, the root node devices can exchange the mapped IP addresses and ports of the non-root node devices in the local area network.

[0189] For example, if the IP address and port of electronic device 11 in LAN A are 192.168.1.2:46123, then root node device 1 (i.e., electronic device 10) can map the IP address and port of electronic device 11 in LAN A to 10.100.1.1:10164. After completing the above device authentication and networking phase, the IP address and port of electronic device 11 stored in root node device 2 and electronic device 22 in LAN B will be 10.100.1.1:10164. Alternatively, the IP address and port of root node device 1 (i.e., electronic device 10) in LAN A stored in root node device 2 and electronic device 22 in LAN B will be 10.100.1.1:33333. However, the IP address and port of electronic device 22 stored in root node device 2 in LAN B can also be 192.168.2.2:41413. Similarly, the IP address and port of electronic device 22 stored in root node device 1 and electronic device 11 in LAN A are mapped to 10.100.1.2:10231, and the IP address and port of root node device 2 (i.e. electronic device 20) in LAN B are 10.100.1.2:44444; however, the IP address and port of electronic device 11 stored in root node device 1 in LAN A can also be 192.168.1.2:46123.

[0190] Therefore, during the data transmission phase, the IP data packets sent from electronic device 11 (such as coal mining machine 1) to root node device 1 (i.e., electronic device 10) have the following source addresses: the original IP address and port of electronic device 11 within local area network A (e.g., 192.168.1.2:46123), and the destination address: the IP address and port of the target device (i.e., electronic device 22) obtained by electronic device 11 through the above step S108 (e.g., the unified mapped cross-domain address 10.100.1.2:10231). The IP address and port of electronic device 22 refer to the mapped IP address and port, which can be obtained by electronic device 11 by querying the parameter information of trusted devices stored locally. When electronic device 11 discovers that the target device does not belong to this local area network, electronic device 11 can send the above IP data packets to the default gateway, i.e., the internal network address of root node device 1 (192.168.1.1:33334), thereby triggering the subsequent cross-domain communication processing flow. For details on how to determine if a target device is not on the same local area network as your electronic device 11, please refer to the relevant description above.

[0191] After receiving the aforementioned IP data packet, root node device 1 can continue to perform subsequent NAT / port mapping. Specifically, root node device 1 can replace the source address of the IP data packet with the registered address of electronic device 11 in the mining ring network, 10.100.1.1:10164, while keeping the destination address 10.100.1.2:10231 unchanged. That is, after receiving the first data packet, root node device 1 can modify the private IP address and private port of electronic device 11 in the first data packet to the public IP address and public port of electronic device 11 based on the aforementioned second mapping relationship, thus obtaining the second data packet. After completing the address translation, root node device 1 forwards the packet to the next hop according to the ring network route, ultimately delivering it to root node device 2 of local area network B. After receiving the data packet, root node device 2 can restore the destination address 10.100.1.2:10231 to the IP address and port 192.168.2.2:41413 of the target device (i.e., electronic device 22) in LAN B. In other words, after receiving the second data packet, root node device 2 can modify the public IP address and public port of electronic device 22 in the second data packet to the private IP address and private port of electronic device 22 based on the first mapping relationship, thus obtaining the third data packet. Subsequently, the IP data packet (i.e., the third data packet) is sent by root node device 2 to electronic device 22 through LAN B.

[0192] Understandable, through Figure 9The method shown allows electronic devices to avoid multiple layers of encapsulation and decapsulation of IP packets, thereby improving forwarding efficiency, reducing data transmission latency, and making it more suitable for scenarios with high real-time collaboration requirements. Furthermore, IP layer forwarding only replaces the header address, while the payload content remains encrypted and passes through the root node device. The root node device does not need to parse any business data, eliminating the risk of plaintext leakage and preventing the possibility of man-in-the-middle attacks. This provides a higher level of security isolation for downhole control messages without increasing additional encryption overhead.

[0193] Understandably, the aforementioned cross-LAN data transmission process can also be reversed. That is, electronic device 22 can send a fourth data packet to electronic device 20 via LAN B. This fourth data packet carries the second service data and the identification information of electronic device 11. After receiving the fourth data packet, electronic device 20 sends a fifth data packet to electronic device 10. This fifth data packet may carry the aforementioned second service data and the identification information of electronic device 11. After receiving the fifth data packet, electronic device 10 can send a sixth data packet to electronic device 11 via LAN A. This sixth data packet carries the aforementioned second service data. The specific data transmission process can be referred to the relevant description above, and will not be repeated here.

[0194] Figure 10 This is a schematic diagram illustrating device information synchronization between electronic devices according to an embodiment of this application.

[0195] like Figure 10 As shown, Figure 10 The system presents three cycles: the first cycle, the second cycle, and the third cycle. The first cycle can be an external synchronization cycle, used to indicate the time interval for the root node device to broadcast or unicast local trusted device information to external LANs, ensuring the consistency of trusted device information stored in root node devices across LANs. The second cycle can be an internal synchronization cycle, used to indicate the time interval for the root node device to synchronize trusted device information to non-root node devices within its own LAN, ensuring the consistency of trusted device information within the LAN. The third cycle can be an aging cycle for trusted device information, used to limit the maximum silent time for locally stored trusted device information not to be refreshed by any event. If the electronic device does not receive trusted device information from other devices within this period, it can be determined that the locally stored trusted device information may be outdated. In this case, the electronic device can proactively send a "synchronization request" to re-acquire the latest trusted device information, thereby preventing information distortion due to prolonged lack of updates. Understandably, root node devices can have timers corresponding to the above three cycles, while non-root nodes can only have a timer corresponding to the third cycle.

[0196] After system startup, the root node device first initializes cross-domain information, initializing the first, second, and third cycles and starting the corresponding timers. For example, root node device 1 can initialize its first cycle Ta_1 and second cycle Ta_2. Subsequently, when device events such as device addition or device offline are detected within the local area network (LAN A), for example, when a change in the device status of electronic device 11 is received (such as electronic device 11 and root node device 1 completing device authentication), root node device A can update the locally stored trusted device information 100 and reset the third cycle (aging cycle) Ta_3 timer of root node device 1 based on this event, ensuring that the local trusted device information is always in a trusted state. Here, trusted device information 100 refers to trusted device information on root node device 1, trusted device information 200 (described later) refers to trusted device information on root node device 2, and trusted device information 101 (described later) refers to trusted device information on electronic device 11. This cross-domain information is used for subsequent cross-domain device discovery, routing queries, etc.

[0197] When the first cycle (i.e., the external synchronization cycle, such as Ta_1) arrives, the root node device (such as root node device 1) can encapsulate the latest trusted device information 100 into a cross-domain synchronization message and send it to other root node devices (such as root node device 2) in the mining ring network through the mining ring network. After receiving it, these root node devices can update their local trusted device information (such as trusted device information 200) based on the received trusted device information and send an acknowledgment. This completes one peer-to-peer refresh of the cross-domain trusted device information.

[0198] In some embodiments, after the devices are networked, root node device 1 can send fourth trusted device information to root node device 2. This fourth trusted device information includes parameter information of one or more trusted devices in local area network A, including electronic device 11. During the network formation, electronic device 11 becomes a trusted device of root node device 1. Then, after a second period of time since electronic device 11 became a trusted device of root node device 1, root node device 1 can send fifth trusted device information to root node device 2. This fifth trusted device information may include parameter information of one or more trusted devices in local area network A. Root node device 2 can update the locally stored fourth trusted device information to the fifth trusted device information. The second period of time can correspond to the first cycle of root node device 1 (i.e., the external synchronization cycle, Ta_1).

[0199] Understandably, when the first cycle (i.e., the external synchronization cycle) arrives, the root node device can traverse all other root node devices in the mining ring network to perform the above steps. After updating the local trusted device information, other root node devices can also reset the timer corresponding to the local third cycle (such as the third cycle Tb_3 timer of root node device 2).

[0200] When the second cycle (internal synchronization cycle, such as Ta_2) arrives, the root node device (e.g., root node device 1) can encapsulate the latest trusted device information 100 into a synchronization message and send it to the non-root node devices (e.g., electronic device 11) within the local area network (e.g., LAN A). Upon receiving the synchronization message, the non-root node device can update its local trusted device information (e.g., trusted device information 101) and reset its local third cycle. After replacing its local trusted device information, the non-root node device can also reset the timer corresponding to its local third cycle.

[0201] In some embodiments, after a first duration of sending the first trusted device information, the root node device 1 sends the third trusted device information (i.e., the updated trusted device information 100) to the electronic device 11. The third trusted device information includes parameter information of one or more trusted devices in the local area network B. The electronic device 11 can update the locally stored first trusted device information to the third trusted device information, that is, update the received trusted device information 100 to trusted device information 101. Subsequently, the electronic device 11 can reset its third cycle Ta1_1 timer 7. The first duration can correspond to the second cycle of the root node device 1 (i.e., the internal synchronization cycle, Ta_2).

[0202] Understandably, when the second cycle (i.e., the internal synchronization cycle) arrives, the root node device can traverse all non-root node devices in the local area network to perform the above steps.

[0203] like Figure 10 As shown, changes in device information in LAN B can also lead to updates to trusted device information 200. When the first cycle Tb_1 of root node device 2 arrives, root node device 2 can also synchronize trusted device information 200 on root node device 1. Root node device 1 can update the trusted device information 200 to trusted device information 100 and reset the timing of the third cycle Ta_3 of root node device 1.

[0204] Through the aforementioned three-cycle coordination mechanism, the system can automatically update, synchronize, and clean up trusted device information in three scenarios: device change, cycle arrival, and aging timeout, providing a real-time, unified, and secure addressing foundation for subsequent cross-domain control and data forwarding.

[0205] Figure 11 This is a schematic diagram of an electronic device aging mechanism provided in an embodiment of this application.

[0206] like Figure 11 As shown, the aging mechanism described above can be divided into two levels: non-root node devices and root node devices. After startup, non-root node devices and root node devices can initialize their local caches and start timers respectively. For example, electronic device 11 can initialize its third-cycle timer Ta1_3, and root node device 1 can initialize its third-cycle timer Ta_3.

[0207] When the third cycle (i.e., aging cycle) of a non-root node device arrives, such as when Ta1_3 arrives, the non-root node device (e.g., electronic device 11) can send a synchronization request (i.e., the first synchronization request) to the root node device of the local area network (e.g., root node device 1). In response to this synchronization request, the root node device can return the latest trusted device information 100. Subsequently, the non-root node device can update the aforementioned trusted device information 100 to trusted device information 101 and reset the aforementioned third cycle Ta1_3 timer.

[0208] In some embodiments, after a third period of time following the receipt of the first trusted device information, if the locally stored first trusted device information has not been updated, the non-root node device (such as electronic device 11) sends a first synchronization request to the root node device 1 (i.e., the first electronic device); in response to the first synchronization request, the root node device 1 (i.e., the first electronic device) sends a sixth trusted device information to the non-root node device (such as electronic device 11), the sixth trusted device information including parameter information of one or more trusted devices in the second local area network; the non-root node device (such as electronic device 11) updates the locally stored first trusted device information to the sixth trusted device information. The aforementioned third period corresponds to the third cycle Ta1_3 of electronic device 11.

[0209] When the third cycle (i.e., aging cycle) of a root node device arrives, the root node device (e.g., root node device 1) can send a synchronization request (i.e., a second synchronization request) to other root node devices in the local area network (e.g., root node device 2). Optionally, the root node device can traverse the aforementioned mining ring network to request all other root node devices one by one, or it can request only one of them. For example, root node device 1 can randomly select root node device 2 to request the latest trusted device information. In response to the above synchronization request, other root node devices can return the latest trusted device information, such as root node device 2 returning trusted device information 200. After receiving the latest trusted device information 200, root node device 1 updates trusted device information 200 to trusted device information 100 and resets the aforementioned third cycle Ta_3 timer.

[0210] In some embodiments, after a fourth period of time following the receipt of the second trusted device information, if the locally stored second trusted device information has not been updated, root node device 1 may send a second synchronization request to root node device 2; in response to the second synchronization request, root node device 2 may send seventh trusted device information to root node device 1, the seventh trusted device information including parameter information of one or more trusted devices in the second local area network; subsequently, root node device 1 may update the locally stored second trusted device information to the seventh trusted device information.

[0211] Through the above methods, the system can still periodically refresh the trusted device information even when there are no events for a long time or the network is isolated, ensuring that cross-domain communication is performed according to the latest list.

[0212] The above-described device communication method is not limited to the coal mine scenario. It can also be applied to any scenario that requires the deployment of multiple electronic devices, where these devices need to work collaboratively, and where they are distributed across different local area networks (LANs), such as drone swarm control scenarios. It is understood that the reasons for the distribution of these multiple electronic devices across different LANs include, but are not limited to, the following: the physical locations of these multiple electronic devices are too far apart to be included in the same LAN; or the access permissions or security levels required by these multiple electronic devices are different, thus placing them in different LANs. This application does not specifically limit the specific scenarios (such as coal mine scenarios, oil and gas field production scenarios, or drone swarm control scenarios) to which the above-described device communication method is applicable.

[0213] Figure 12 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is illustrated. The electronic device can be various types of smart terminal devices, and this application does not limit the specific type of electronic device. For example, the electronic device can be a mobile phone, as well as a tablet computer, desktop computer, laptop computer, handheld computer, and so on.

[0214] like Figure 12 As shown, the electronic device may include a processor 210, an external memory interface 220, an internal memory 221, a USB interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 1, an antenna 2, a mobile communication module 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, a display screen 294, and a SIM card interface 295, etc. The sensor module 280 may include at least one of a pressure sensor 280A, a gyroscope sensor 280B, a barometric pressure sensor 280C, a magnetic sensor 280D, an accelerometer sensor 280E, a proximity sensor 280F, a proximity light sensor 280G, a fingerprint sensor 280H, a temperature sensor 280J, a touch sensor 280K, an ambient light sensor 280L, and a bone conduction sensor 280M, etc.

[0215] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device 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.

[0216] Processor 210 may include one or more processing units, such as application processors, modem processors, graphics processors, image signal processors, controllers, memory, video codecs, digital signal processors, baseband processors, and / or neural network processors. These different processing units may be independent devices or integrated into one or more processors. In some embodiments, the electronic device may also include one or more processors 210.

[0217] The controller can serve as the nerve center and command center of an electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0218] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 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 210, and thus improves the efficiency of the electronic device.

[0219] The USB 230 port is a USB standard compliant interface that can be used to connect chargers to charge electronic devices, as well as for data transfer between electronic devices and peripherals. It can also be used to connect headphones for audio playback.

[0220] 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 limitation on the structure of the electronic device. In other embodiments, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0221] The charging management module 240 receives charging input from the charger. While charging the battery 242, the charging management module 240 can also supply power to the electronic device through the power management module 241.

[0222] The power management module 241 is used to connect the battery 242, the charging management module 240, and the processor 210. The power management module 241 receives input from the battery 242 and / or the charging management module 240 to power the processor 210, internal memory 221, external memory, display 294, camera 293, and wireless communication module 260, etc.

[0223] The wireless communication function of an electronic device can be implemented through antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Mobile communication module 250 can provide wireless communication solutions for electronic devices, including 2G / 3G / 4G / 5G. The modem processor can include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. Wireless communication module 260 can provide wireless communication solutions for electronic devices, including WLAN (such as Wi-Fi networks), Bluetooth, Global Navigation Satellite System, FM, NFC, infrared technology, and ultra-wideband (UWB).

[0224] Electronic devices can achieve display functions through GPUs, displays 294, and application processors. A GPU is a microprocessor for image processing, connecting the display 294 and the application processor. The GPU performs mathematical and geometric calculations and is used for graphics rendering. Processor 210 may include one or more GPUs, which execute instructions to generate or modify display information.

[0225] A touch sensor can be installed in the display screen 294. The touch sensor is used to detect touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Then, the electronic device can provide visual output related to the touch operation through the display screen 294. The electronic device can implement display functions through the GPU, display screen 294, touch sensor, and application processor. In this embodiment, the electronic device can use the display functions provided by the GPU, display screen 294, touch sensor, and application processor to achieve cross-local area network device invocation, or to activate the cross-domain networking function of the electronic device, etc.

[0226] Display screen 294 is used to display images, videos, etc. Display screen 294 includes a display panel.

[0227] Electronic devices can achieve shooting functions through ISPs, cameras 293, video codecs, GPUs, displays 294, and application processors. Camera 293 is used to capture still images or videos. Digital signal processors are used to process digital signals. Video codecs are used to compress or decompress digital video. NPUs (Neural-Network Processing Units) are neural network (NN) computing processors that, by borrowing from the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, can quickly process input information and continuously learn on their own.

[0228] The external memory interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 210 through the external memory interface 220 to perform data storage functions. The internal memory 221 can be used to store one or more computer programs, which include instructions. The processor 210 can execute the instructions stored in the internal memory 221, thereby causing the electronic device to perform the device communication methods, various functional applications, and data processing provided in some embodiments of this application.

[0229] Electronic devices can implement audio functions through audio modules 270, speakers 270A, receivers 270B, microphones 270C, headphone jacks 270D, and application processors. Examples include music playback and recording.

[0230] The audio module 270 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 270 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 270 may be located in the processor 210, or some functional modules of the audio module 270 may be located in the processor 210.

[0231] The speaker 270A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. Electronic devices can listen to music or make hands-free calls through the speaker 270A.

[0232] The receiver 270B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When an electronic device answers a phone call or voice message, the receiver 270B can be brought close to the ear to hear the voice.

[0233] Microphone 270C, 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 270C, inputting the sound signal into microphone 270C. An electronic device can have at least one microphone 270C. In some embodiments, the electronic device can have two microphones 270C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, the electronic device can also have three, four, or more microphones 270C, enabling sound signal collection, noise reduction, sound source identification, and directional recording, among other functions.

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

[0235] Pressure sensor 280A is used to sense pressure signals and convert them into electrical signals. Gyroscope sensor 280B can be used to determine the motion posture of electronic devices. Barometric pressure sensor 280C is used to measure air pressure. Magnetic sensor 280D includes a Hall sensor. Accelerometer sensor 280E can detect the magnitude of acceleration of electronic devices in various directions (generally three axes). Distance sensor 280F is used to measure distance. Proximity light sensor 280G may include, for example, a light-emitting diode (LED) and a photodetector, such as a photodiode. Electronic devices can use the aforementioned proximity light sensor 280G to determine that there are no objects nearby. Ambient light sensor 280L is used to sense ambient light intensity. Fingerprint sensor 280H is used to collect fingerprints. Temperature sensor 280J is used to detect temperature. Touch sensor 280K, also known as a touch panel or touch-sensitive surface. Touch sensor 280K can be set on display screen 294, and the touch sensor 280K and display screen 294 form a touch screen, also known as a "touchscreen". Touch sensor 280K is used to detect touch operations applied to or near it. The touch sensor can then transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided via display screen 294. Bone conduction sensor 280M can acquire vibration signals.

[0236] Buttons 290 include a power button, volume buttons, etc. Buttons 290 can be mechanical buttons or touch-sensitive buttons. The electronic device can receive button input and generate key signal inputs related to user settings and function control of the electronic device.

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

[0238] Indicator 292 can be an indicator light, which can be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0239] The SIM card interface 295 is used to connect a SIM card. Electronic devices interact with the network through the SIM card to perform functions such as calls and data communication. In some embodiments, the electronic device uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device and cannot be separated from it.

[0240] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer. Embodiments of this application also provide a computer program product, including a computer program that, when run on a processor, implements the steps in the various method embodiments described above.

[0241] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A device communication method, characterized in that, Applied to a first communication system, the first communication system including a first electronic device, a second electronic device, a third electronic device, and a fourth electronic device, wherein the first electronic device and the second electronic device belong to a first local area network, and the third electronic device and the fourth electronic device belong to a second local area network, the method includes: Within the first local area network, the first electronic device sends first trusted device information to the second electronic device. The first trusted device information includes parameter information of one or more trusted devices in the second local area network. The one or more trusted devices in the second local area network include the third electronic device and the fourth electronic device. The parameter information includes identification information. The second electronic device sends a first data packet to the first electronic device through the first local area network. The first data packet carries first service data and the identification information of the fourth electronic device. After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device. The second data packet carries the first service data and the identification information of the fourth electronic device. After receiving the second data packet, the third electronic device sends a third data packet to the fourth electronic device through the second local area network. The third data packet carries the first service data.

2. The method according to claim 1, characterized in that, The first electronic device and the third electronic device belong to a third local area network. Before the first electronic device sends the first trusted device information to the second electronic device within the first local area network, the method further includes: Within the third local area network, the third electronic device sends second trusted device information to the first electronic device. The second trusted device information includes parameter information of one or more trusted devices in the second local area network.

3. The method according to claim 2, characterized in that, The first electronic device and the third electronic device are trusted devices within the third local area network.

4. The method according to claim 1, characterized in that, In the first local area network, the parameter information of the trusted device sent by the first electronic device to the second electronic device also includes one or more of the following: device type, geographical location of the device, production subsystem to which the device belongs, security level of the device, and performance parameters.

5. The method according to claim 1, characterized in that, The identification information includes: a device universally unique identifier (UUID), and / or, a device name, and / or, a private Internet Protocol (IP) address and a private port, and / or, a public IP address and a public port.

6. The method according to claim 1, characterized in that, The third data packet also carries the private Internet Protocol (IP) address of the fourth electronic device.

7. The method according to claim 1, characterized in that, After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, if the first electronic device includes the fourth electronic device in its list of trusted devices, the first electronic device sends the second data packet to the third electronic device.

8. The method according to claim 1, characterized in that, After receiving the second data packet, the third electronic device sends the third data packet to the fourth electronic device through the second local area network, specifically including: After receiving the second data packet, if the third electronic device includes the fourth electronic device in its list of trusted devices, the third electronic device sends the third data packet to the fourth electronic device through the second local area network.

9. The method according to claim 1, characterized in that, The first electronic device is the root node device of the first local area network. The root node device of the first local area network is determined based on the performance parameters of one or more devices in the first local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

10. The method according to claim 1, characterized in that, The third electronic device is the root node device of the second local area network. The root node device of the second local area network is determined based on the performance parameters of one or more devices in the second local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

11. The method according to any one of claims 1-10, characterized in that, The second electronic device sends a first data packet to the first electronic device through the first local area network, specifically including: The second electronic device sends the first data packet to the first agent process running on the first electronic device via the first local area network; Before the first electronic device sends the second data packet to the third electronic device, the method further includes: The first electronic device parses the identification information of the fourth electronic device from the first data packet through the first proxy process; The first electronic device generates the second data packet based on the identification information of the fourth electronic device and the first service data through the first proxy process.

12. The method according to any one of claims 1-10, characterized in that, After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, the first electronic device sends the second data packet to the second agent process running on the third electronic device; Before the third electronic device sends the third data packet to the fourth electronic device via the second local area network, the method further includes: The third electronic device obtains the identification information of the fourth electronic device by parsing the second data packet through the second proxy process; The third electronic device generates the third data packet based on the identification information of the fourth electronic device and the first service data through the second proxy process.

13. The method according to claim 5, characterized in that, If the identification information includes the public IP address and the public port, the method further includes the following steps before sending the third data packet to the fourth electronic device via the second local area network: The third electronic device stores a first mapping relationship, which includes the mapping between the private IP address and private port of the fourth electronic device and the public IP address and public port of the fourth electronic device. After receiving the second data packet, the third electronic device sends the third data packet to the fourth electronic device through the second local area network, specifically including: After receiving the second data packet, the third electronic device modifies the public IP address and public port of the fourth electronic device in the second data packet to the private IP address and private port of the fourth electronic device based on the first mapping relationship, thereby obtaining the third data packet.

14. The method according to claim 5, characterized in that, If the identification information includes the public IP address and the public port, the method further includes the following steps before sending the second data packet to the third electronic device: The first electronic device stores a second mapping relationship, which includes the mapping between the private IP address and private port of the second electronic device and the public IP address and public port of the second electronic device. After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, the first electronic device modifies the private IP address and private port of the second electronic device in the first data packet to the public IP address and public port of the second electronic device based on the second mapping relationship, and obtains the second data packet.

15. The method according to claim 1, characterized in that, The method further includes: After a first period of time following the transmission of the first trusted device information, the first electronic device sends the third trusted device information to the second electronic device, wherein the third trusted device information includes parameter information of one or more trusted devices in the second local area network. The second electronic device updates the locally stored first trusted device information to the third trusted device information.

16. The method according to claim 1, characterized in that, The method further includes: The first electronic device sends fourth trusted device information to the third electronic device. The fourth trusted device information includes parameter information of one or more trusted devices in the first local area network, and one or more trusted devices in the first local area network include the second electronic device. After the second electronic device becomes a trusted device of the first electronic device for a second period of time, the first electronic device sends the fifth trusted device information to the third electronic device. The fifth trusted device information includes parameter information of one or more trusted devices in the first local area network. The third electronic device updates the locally stored information of the fourth trusted device to the information of the fifth trusted device.

17. The method according to claim 1, characterized in that, The method further includes: After a third period of time following receipt of the first trusted device information, if the first trusted device information stored locally has not been updated, the second electronic device sends a first synchronization request to the first electronic device. In response to the first synchronization request, the first electronic device sends a sixth trusted device information to the second electronic device, the sixth trusted device information including parameter information of one or more trusted devices in the second local area network; The second electronic device updates the locally stored first trusted device information to the sixth trusted device information.

18. The method according to claim 2, characterized in that, The method further includes: After a fourth period of time following receipt of the second trusted device information, if the locally stored second trusted device information has not been updated, the first electronic device sends a second synchronization request to the third electronic device. In response to the second synchronization request, the third electronic device sends seventh trusted device information to the first electronic device, the seventh trusted device information including parameter information of one or more trusted devices in the second local area network; The first electronic device updates the locally stored second trusted device information to the seventh trusted device information.

19. The method according to claim 1, characterized in that, The method further includes: The fourth electronic device sends a fourth data packet to the third electronic device through the second local area network. The fourth data packet carries second service data and identification information of the second electronic device. After receiving the fourth data packet, the third electronic device sends a fifth data packet to the first electronic device, the fifth data packet carrying the second service data and the identification information of the second electronic device; After receiving the fifth data packet, the first electronic device sends a sixth data packet to the second electronic device through the first local area network. The sixth data packet carries the second service data.

20. A device communication method, characterized in that, The method is applied to a first electronic device, which belongs to a first communication system. The first communication system further includes a second electronic device, a third electronic device, and a fourth electronic device. The first electronic device and the second electronic device belong to a first local area network (LAN), and the third electronic device and the fourth electronic device belong to a second LAN. The method includes: Within the first local area network, the first electronic device sends first trusted device information to the second electronic device. The first trusted device information includes parameter information of one or more trusted devices in the second local area network. The one or more trusted devices in the second local area network include the third electronic device and the fourth electronic device. The parameter information includes identification information. The first electronic device receives a first data packet sent by the second electronic device through the first local area network. The first data packet carries first service data and the identification information of the fourth electronic device. After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device. The second data packet carries the first service data and the identification information of the fourth electronic device. The third electronic device is used to send a third data packet to the fourth electronic device through the second local area network after receiving the second data packet. The third data packet carries the first service data.

21. The method according to claim 20, characterized in that, The first electronic device and the third electronic device belong to a third local area network. Before the first electronic device sends the first trusted device information to the second electronic device within the first local area network, the method further includes: Within the third local area network, the first electronic device receives second trusted device information sent by the third electronic device. The second trusted device information includes parameter information of one or more trusted devices in the second local area network.

22. The method according to claim 21, characterized in that, The first electronic device and the third electronic device are trusted devices within the third local area network.

23. The method according to claim 20, characterized in that, In the first local area network, the parameter information of the trusted device sent by the first electronic device to the second electronic device also includes one or more of the following: device type, geographical location of the device, production subsystem to which the device belongs, security level of the device, and performance parameters.

24. The method according to claim 20, characterized in that, The identification information includes: a device universally unique identifier (UUID), and / or, a device name, and / or, a private Internet Protocol (IP) address and a private port, and / or, a public IP address and a public port.

25. The method according to claim 20, characterized in that, The third data packet also carries the private Internet Protocol (IP) address of the fourth electronic device.

26. The method according to claim 20, characterized in that, After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, if the first electronic device includes the fourth electronic device in its list of trusted devices, the first electronic device sends the second data packet to the third electronic device.

27. The method according to claim 20, characterized in that, The first electronic device is the root node device of the first local area network. The root node device of the first local area network is determined based on the performance parameters of one or more devices in the first local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

28. The method according to claim 20, characterized in that, The third electronic device is the root node device of the second local area network. The root node device of the second local area network is determined based on the performance parameters of one or more devices in the second local area network. The performance parameters include one or more of the following: throughput, network latency, signal strength, bandwidth capacity, protocol support type, computing resources, storage capacity, power endurance, and historical communication stability indicators.

29. The method according to any one of claims 20-28, characterized in that, The first electronic device receives a first data packet sent by the second electronic device through the first local area network, specifically including: The first electronic device receives a first data packet sent by the second electronic device through the first local area network via a first agent process running on the first electronic device. Before the first electronic device sends the second data packet to the third electronic device, the method further includes: The first electronic device parses the identification information of the fourth electronic device from the first data packet through the first proxy process; The first electronic device generates the second data packet based on the identification information of the fourth electronic device and the first service data through the first proxy process.

30. The method according to any one of claims 20-28, characterized in that, After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, the first electronic device sends the second data packet to the second agent process running on the third electronic device. The second agent process is used to parse the second data packet to obtain the identification information of the fourth electronic device. The second agent process is also used to generate the third data packet based on the identification information of the fourth electronic device and the first service data.

31. The method according to claim 24, characterized in that, If the identification information includes the public IP address and the public port, the method further includes the following steps before sending the second data packet to the third electronic device: The first electronic device stores a second mapping relationship, which includes the mapping between the private IP address and private port of the second electronic device and the public IP address and public port of the second electronic device. After receiving the first data packet, the first electronic device sends a second data packet to the third electronic device, specifically including: After receiving the first data packet, the first electronic device modifies the private IP address and private port of the second electronic device in the first data packet to the public IP address and public port of the second electronic device based on the second mapping relationship, and obtains the second data packet.

32. The method according to claim 20, characterized in that, The method further includes: After a first period of time following the transmission of the first trusted device information, the first electronic device sends the third trusted device information to the second electronic device. The third trusted device information includes parameter information of one or more trusted devices in the second local area network. The third trusted device information is used to update the first trusted device information stored locally by the second electronic device.

33. The method according to claim 20, characterized in that, The method further includes: The first electronic device sends fourth trusted device information to the third electronic device. The fourth trusted device information includes parameter information of one or more trusted devices in the first local area network, and one or more trusted devices in the first local area network include the second electronic device. After the second electronic device becomes a trusted device of the first electronic device for a second period of time, the first electronic device sends the fifth trusted device information to the third electronic device. The fifth trusted device information includes parameter information of one or more trusted devices in the first local area network. The fifth trusted device information is used to update the fourth trusted device information stored locally by the third electronic device.

34. The method according to claim 20, characterized in that, The method further includes: In response to the first synchronization request, the first electronic device sends a sixth trusted device information to the second electronic device. The sixth trusted device information includes parameter information of one or more trusted devices in the second local area network. The sixth trusted device information is used to update the first trusted device information stored locally by the second electronic device. The first synchronization request is sent by the second electronic device to the first electronic device after a third time period following receipt of the first trusted device information, provided that the first trusted device information stored locally has not been updated.

35. The method according to claim 21, characterized in that, The method further includes: After a fourth period of time following receipt of the second trusted device information, if the locally stored second trusted device information has not been updated, the first electronic device sends a second synchronization request to the third electronic device. The second synchronization request is used to trigger the third electronic device to send the seventh trusted device information to the first electronic device. The seventh trusted device information includes parameter information of one or more trusted devices in the second local area network. The first electronic device updates the locally stored second trusted device information to the seventh trusted device information.

36. An electronic device, characterized in that, The method includes one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, the computer program code including computer instructions that, when the one or more processors execute the computer instructions, cause the method as described in any one of claims 20-35 to be performed.

37. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run on an electronic device, it causes the method described in any one of claims 20-35 to be performed.

Images