Communication method, device and equipment of Internet of Things equipment

Abstract

The embodiment of the invention discloses a communication method, device and equipment for Internet of Things equipment, relates to the technical field of communication, and is used for solving the communication problem that the equipment can realize reliable data transmission when the Internet of Things equipment is in a weak network or disconnected network environment. The method comprises the following steps: when the network connection quality of first Internet of Things equipment is lower than a preset threshold value, triggering the first Internet of Things equipment, and establishing a near field communication link with second Internet of Things equipment through near field communication; through a near field communication link, protocol forwarding is carried out on the flow of the first Internet of Things device through a dual-stack gateway, so that a network protocol stack between the first Internet of Things device and a second Internet of Things device is cascaded, and the first Internet of Things device accesses a target network through the second Internet of Things device. The network protocol stack comprises a system protocol stack and a private protocol stack which are parallel in the same dual-stack gateway.

Description

Technical Field

[0001] This specification relates to the field of communication technology, and in particular to a communication method, apparatus, and device for an Internet of Things (IoT) device. Background Technology

[0002] With the popularization of IoT technology, various IoT devices, such as point-of-sale (POS) machines, handheld terminals, and industrial sensors, have been widely used in various application scenarios, including retail, logistics, and industrial services. These IoT devices typically rely on cellular networks or wireless Fidelity (Wi-Fi) to maintain connections with cloud-based business platforms to complete payment transactions, data reporting, and command reception. In traditional solutions, IoT devices mainly rely on a single communication module to directly connect to the internet. When the network environment is weak or unavailable, the IoT devices cannot restore the connection on their own and can only wait for the environment to improve, making it difficult for them to conduct network communication and exchange business data.

[0003] In practical applications, IoT devices with weak or no network connections often have other smart devices with normal network connectivity nearby. To leverage the network capabilities of these smart devices to enable IoT services, existing technologies run proprietary protocols directly on top of physical layers such as Universal Serial Bus (USB) for data transmission. However, IoT devices run standard system protocol stacks, while near-field links like USB only support specific link-layer protocols. Modifying upper-layer applications to adapt to near-field link-layer protocols breaks the transparent forwarding of service data. Furthermore, physical layer links are susceptible to electromagnetic interference and signal attenuation, leading to risks of packet loss, errors, and disordered data transmission.

[0004] Therefore, a method is needed to ensure reliable communication of IoT devices in weak or offline environments. Summary of the Invention

[0005] This specification provides one or more embodiments of a communication method, apparatus, and device for Internet of Things (IoT) devices, which addresses the following technical problem: the need for a method to ensure reliable communication of IoT devices in weak network or offline environments.

[0006] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows: This specification provides a communication method for an Internet of Things (IoT) device according to one or more embodiments, the method comprising: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device via near-field communication. Through the near-field communication link, the traffic of the first IoT device is forwarded via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes a system protocol stack and a private protocol stack running in parallel within the same dual-stack gateway.

[0007] This specification provides a communication device for an Internet of Things (IoT) device according to one or more embodiments, comprising: The near-field communication establishment module is used to trigger the first IoT device to establish a near-field communication link with the second IoT device when the network connection quality of the first IoT device is lower than a preset threshold. The cascaded communication module is used to forward the traffic of the first IoT device through the near-field communication link via the dual-stack gateway, so as to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes: a system protocol stack and a private protocol stack running in parallel in the same dual-stack gateway.

[0008] This specification provides a communication device for an Internet of Things (IoT) device according to one or more embodiments, comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device via near-field communication. Through the near-field communication link, the traffic of the first IoT device is forwarded via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes a system protocol stack and a private protocol stack running in parallel within the same dual-stack gateway.

[0009] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: By triggering the establishment of a near-field communication link between the first IoT device and the second IoT device when the network connection quality of the first IoT device falls below a preset threshold, the device can quickly switch to utilizing the network resources of surrounding devices when its own network is unavailable, avoiding long service wait times or failures caused by network interruptions. By forwarding the traffic of the first IoT device through a dual-stack gateway and connecting the network protocol stacks between the first and second IoT devices in a cascaded manner, standard network protocol data streams that cannot run directly on non-Internet Protocol physical links can be stably transmitted through these links without any modification to upper-layer business applications, achieving network convergence transparent to applications. Running the private protocol stack and the system protocol stack in parallel within the same dual-stack gateway bypasses the fixed behavior of the operating system kernel's Transmission Control Protocol / Internet Protocol (TCP / IP), achieving stable and efficient transmission in the interference-prone near-field environment. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 This is a schematic flowchart of a communication method for an Internet of Things (IoT) device provided in an embodiment of this specification. Figure 2 A schematic diagram of a basic direct-connect architecture provided for embodiments of this specification; Figure 3 A schematic diagram of a basic proxy architecture provided for an embodiment of this specification; Figure 4 A schematic diagram of a cascaded expansion architecture provided for an embodiment of this specification; Figure 5 This is a schematic diagram of a distributed tunnel architecture provided in the embodiments of this specification; Figure 6 A schematic diagram of a custom architecture for a private protocol stack provided in the embodiments of this specification; Figure 7 This diagram illustrates a network collaboration scenario provided in the embodiments of this specification. Figure 8 This is a schematic diagram of the structure of a communication device for an Internet of Things (IoT) device provided in an embodiment of this specification. Figure 9This is a schematic diagram of the structure of a communication device for an Internet of Things (IoT) device provided in an embodiment of this specification. Detailed Implementation

[0011] This specification provides a communication method, apparatus, and device for Internet of Things (IoT) devices.

[0012] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0013] In the scenarios mentioned in the background technology, with the popularization of IoT technology, various IoT devices, such as cash registers, handheld terminals, and industrial sensors, have been widely used in various application scenarios such as commercial retail, logistics and distribution, and industrial services. These IoT devices typically rely on cellular networks or Wi-Fi to maintain connections with cloud business platforms to complete tasks such as payment transactions, data reporting, and instruction reception.

[0014] In traditional solutions, IoT devices primarily rely on their own cellular networks or Wi-Fi modules, which are directly connected to the cloud. When encountering weak or out-of-network conditions due to base station failures or complex environments, IoT devices cannot restore connectivity on their own and must wait for the environment to improve. This makes it difficult for IoT devices to conduct network communication and exchange business data.

[0015] To address the communication issues of IoT devices in weak or offline network environments, several optimization methods for IoT device communication are proposed. The following sections provide a more intuitive and illustrative overview of the optimization methods attempted.

[0016] In one approach, IoT devices use a single direct-connect mode where the system network stack directly connects to the cloud to access it. While this architecture is simple, it lacks intermediate traffic control and encryption, making it unable to effectively bypass complex network boundary restrictions and lacking buffering and scheduling capabilities when facing network fluctuations.

[0017] In one approach, a basic proxy component is added to achieve centralized traffic management. Instead of directly connecting to the cloud, services access the cloud through local ports. While this provides a unified interface for access and makes service access controllable, it still relies on the system's standard protocol stack. Therefore, it is constrained by the rigidity of TCP / IP implementation and is difficult to perform in-depth protocol customization and optimization.

[0018] In one approach, a two-level proxy cascade is used to separate encapsulation and forwarding responsibilities. While this method separates encapsulation and forwarding, improving flexibility, it often relies on generic tunneling technologies in cross-device scenarios. These tunnels typically still run on top of the kernel protocol stack, unable to perceive application-layer business characteristics, and difficult to optimize for user space.

[0019] In one approach, to achieve near-field communication between devices, proprietary protocols are typically run directly on top of physical layers such as USB and Bluetooth. While this architecture is simple to implement, it is limited in development, and due to inherent problems with physical links, such as electromagnetic interference, signal attenuation, and unstable contact, data transmission is prone to packet loss, errors, and disorder. Relying on pure physical layer transmission lacks the guarantee of underlying reliability mechanisms, forcing upper-layer services to handle complex error correction logic themselves, severely limiting transaction success rates and system stability, and making it difficult to meet the high-reliability requirements of scenarios such as financial-grade payments.

[0020] Therefore, to address the aforementioned issues and ensure reliable data transmission for IoT devices in weak or offline environments, this application proposes a communication method for IoT devices. This method involves constructing a parallel system and private dual-protocol stack within the IoT device. In weak network conditions, standard traffic is automatically redirected to the user-space private protocol stack for adaptation and encapsulation, then transmitted via a near-field communication link to a nearby second IoT device for restoration and forwarding, thus achieving network interoperability between different devices. This method not only bypasses the TCP limitations of the operating system but also allows tunnel transmission to run entirely on a user-space customized protocol, ensuring both security and efficiency. Based on this overall approach, the solution of this application will be described in detail below.

[0021] Figure 1 This diagram illustrates a communication method for an IoT device, provided in one or more embodiments of this specification. The method can be applied to various IoT terminal devices with network access requirements, such as mobile POS machines, industrial handheld terminals, smart inspection devices, logistics scanners, and smart wearable devices, which need to maintain business continuity in complex network environments. It can also be applied to other scenarios, such as mobile payment systems with increasingly stringent network reliability requirements, industrial IoT systems requiring real-time data transmission, and remote medical devices with stringent connection stability requirements. This process can be executed via the IoT device's control server, and certain input parameters or intermediate results can be manually adjusted to improve accuracy.

[0022] The following detailed description of each step of the method, with reference to specific embodiments, illustrates the method, which includes the following steps: S102: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device through near-field communication.

[0023] The second IoT device is a relay device that establishes a near-field communication link with the first IoT device and provides network forwarding services. This second IoT device has normal network connectivity. For example, in a scenario where a mobile POS machine is the first IoT device, located in an underground parking lot and needing to process a payment, its 4G signal is completely interrupted, preventing direct connection to the payment server (target network). However, within its vicinity (e.g., within Bluetooth or USB effective communication range), there is a mobile phone or another mobile POS machine with a normal network connection. These devices have good 4G / 5G signals and support near-field communication. In this case, the mobile phone or the other mobile POS machine serves as a candidate IoT device. When the first IoT device detects that the network connection quality is below a preset threshold, it needs to utilize the network capabilities of other IoT devices. Through its built-in near-field communication module, it initiates a request to the candidate IoT devices within the effective communication range to request device status information. Based on the returned information, it selects the device with the better uplink network type and the highest signal strength as the second IoT device.

[0024] When the first IoT device initiates a near-field communication request, such as a Bluetooth connection request, to the second IoT device, parameter negotiation can be conducted between the two devices through the connection request. Upon successful negotiation, a usable near-field communication link is established between the two devices. This near-field communication link is a point-to-point direct communication channel established based on near-field communication technology and does not rely on public network infrastructure.

[0025] The preset threshold is a pre-set threshold value used to determine whether the network connection quality meets the business requirements. It can be a fixed value statically pre-configured by the operator based on the different scenarios of the devices, or it can be a threshold that is adaptively adjusted according to the business type, historical data or environmental information.

[0026] In this feasible embodiment, the first IoT device monitors the network connection quality between itself and a target network, such as a cloud server or a service platform corresponding to the first IoT device, in real time. In one approach, the network connection quality can be determined based on one or more network connection metrics, such as signal strength, packet loss rate, and round-trip time.

[0027] When the network connection quality of the first IoT device is detected to be below a preset threshold, meaning the first IoT device is in a weak or disconnected network environment, it indicates that the current network cannot meet the service requirements of the first IoT device. In this case, the first IoT device needs to automatically trigger its near-field communication (NFC) module to scan for surrounding devices, thereby establishing a NFC link with the selected second IoT device. The establishment of this NFC link lays the physical foundation for subsequently encapsulating and forwarding the first IoT device's service traffic through a dual-stack gateway to the second IoT device, enabling it to access the target network.

[0028] Based on the above Figure 2-5 The evolution process of the original direct connection architecture, basic proxy architecture, cascaded expansion architecture, and distributed tunnel architecture can be understood. Figure 2 The original direct connection architecture, and Figure 3 The basic proxy architecture relies on the device's own WAN module and the standard TCP / IP protocol stack of the operating system kernel. Once the physical signal is interrupted or its quality falls below a threshold, it can only passively wait for the network to recover or perform inefficient retries, unable to utilize the idle network resources of surrounding devices, resulting in prolonged service interruptions. Figure 4 Cascading expansion architecture, and Figure 5 Although the distributed tunnel architecture introduces proxy forwarding and tunneling technologies to achieve traffic redirection and cross-device transmission, its transmission channel is usually still built on top of the operating system's standard network protocol stack.

[0029] However, this process establishes a near-field communication link between the first and second IoT devices. This link does not rely on any public network infrastructure, is entirely based on direct communication between the first and second IoT devices, and is independent of the first IoT device's original WAN connection. It can function normally even when the original network is completely interrupted, providing a physical channel for the subsequent protocol forwarding of the dual-stack gateway. This allows the first IoT device to encapsulate its service traffic through a private protocol stack and send it to the second IoT device via this link, where it is then restored and forwarded to the target network. This helps to automatically switch to the network resources of nearby devices when the main network is completely interrupted, avoiding passive waiting by actively borrowing the network. Furthermore, it breaks through the rigid constraints of the standard TCP / IP stack on the physical link, enabling standard service traffic to be stably transmitted over non-Internet Protocol (IP) links such as Bluetooth / USB after being encapsulated by a private protocol.

[0030] In one feasible embodiment, in order to obtain the network connection quality of the first IoT device and thus promptly borrow the network from the first IoT device located in a weak network or out-of-network environment to ensure normal service interaction, it is necessary to evaluate the network connection quality of the first IoT device. Since the first IoT device may run various types of services, and the target networks corresponding to different services—that is, the cloud servers or service platforms that need to be accessed—may be different, the method further includes the following process to achieve targeted quality assessment of the target network: Based on the current service of the first IoT device, the target network corresponding to the current service is determined. It should be noted that, in one approach, the first IoT device maintains a mapping table between services and target networks. This mapping table records the correspondence between target network addresses corresponding to different service types, so the target network corresponding to the current service can be determined based on this correspondence. For example, if the first IoT device's service is a user-initiated payment transaction, then the first IoT device needs to access a payment server, and the network corresponding to the payment server is the target network. In one approach, the first IoT device's current service can be identified by obtaining the network request from the first IoT device's operating system or communication module when the first IoT device's application initiates a network request, thereby obtaining the service identifier based on the network request and identifying the current service. In another approach, for services directly triggered by the user, the current service of the first IoT device can be determined based on the user interface interaction information. In yet another approach, for scheduled tasks, the first IoT device maintains a scheduled task table, and the current service is identified based on the current time.

[0031] After identifying the current service, network connectivity metrics of the first IoT device relative to the target network are obtained to determine the network connectivity quality of the first IoT device. Specifically, each network connectivity metric can be assigned a threshold; if any metric falls below its corresponding threshold, the network connectivity quality is considered below a preset threshold. Alternatively, weights can be determined for each network connectivity metric based on historical data, and the normalized network connectivity metrics are weighted and summed to obtain a comprehensive score. metric with a comprehensive score below a threshold is considered to have insufficient network connectivity quality. Another approach is to determine key network connectivity metrics based on the type of the current service; if a key network connectivity metric falls below its corresponding preset threshold, the network connectivity quality is considered insufficient.

[0032] In a feasible embodiment, to address the issue that the standard TCP / IP protocol stack cannot run directly on non-IP physical links such as Bluetooth and USB, allowing upper-layer business applications to operate without any code modification and without needing to be aware of the underlying network, thus eliminating service interruptions or retry delays caused by network switching, the aforementioned triggering of the first IoT device to establish a near-field communication link with the second IoT device via near-field communication can be achieved based on the following process: A low-level communication link is established between the first IoT device and the second IoT device through the built-in near-field communication module. In one feasible approach, the first IoT device's built-in near-field communication module scans and identifies the second IoT device within a preset range, i.e., the effective communication distance of the near-field communication module, and initiates a connection request to the second IoT device. Based on the connection request, a physical layer connection is established between the first and second IoT devices to perform authentication and negotiate communication transmission parameters, thereby obtaining the low-level communication link between the two devices. At this point, the two devices have basic byte stream transmission capabilities, but the low-level communication link is only a physical channel and cannot directly carry standard IP network data packets.

[0033] To transform the physical channel into a usable network channel, the first IoT device and the second IoT device negotiate and interact based on a pre-defined tunneling protocol. This allows the first IoT device to instantiate a virtual network interface and redirect network traffic destined for the target network to the virtual network interface. The pre-defined tunneling protocol is a private transport rule used in the dual-stack gateway to run IP packets over Bluetooth / USB. Specifically, in one feasible approach, this process involves negotiating and interacting with the first and second IoT devices based on the pre-defined tunneling protocol through the underlying communication link to obtain tunnel configuration information. That is, after the underlying communication link is successfully established, the first IoT device sends a tunnel establishment request to the second IoT device through the underlying communication link. The second IoT device responds to this request, returning confirmation information and tunnel configuration information assigned to the first IoT device. This tunnel configuration information includes the second IoT device's local tunnel service listening address and tunnel parameters. Based on the obtained tunnel configuration information, the first private protocol stack of the dual-stack gateway in the first IoT device is invoked to create a virtual network interface, making it logically behave as a standard network device. Then, the virtual network interface is logically bound to the tunnel service running on the second IoT device through the first IoT device, thereby establishing a connection such as... Figure 6 or Figure 7The diagram illustrates an end-to-end tunnel (kd4) connection. The first IoT device modifies its local routing policy to redirect network traffic originally destined for the target network to this virtual network interface. This allows the data to be captured by the first proprietary protocol stack and transmitted via the tunnel, thus completing the construction of the path from the physical connection to the logical network.

[0034] After obtaining the virtual network interface and underlying communication link through the above process, the virtual network interface and the underlying communication link are associated and bound, thereby establishing a near-field communication link between the first IoT device and the second IoT device that can carry standard IP data streams. It can be understood that the first IoT device internally establishes a mapping relationship, directly associating the data transceiver ports of the instantiated virtual network interface with the data transmission channel of the underlying communication link. All standard network protocol data streams entering this virtual network interface are automatically captured and encapsulated, and then physically transmitted to the second IoT device through the underlying communication link. This process enables the first IoT device to access the target network via the second IoT device as if using a local network card.

[0035] To avoid data transmission instability caused by electromagnetic interference or signal attenuation in near-field communication links, in a practical application, a first IoT device, such as a POS machine, is sending payment transaction data to a second IoT device via a Bluetooth link. A proprietary protocol stack splits this data into 10 data frames and sends them sequentially. When the 5th frame is sent, due to strong electromagnetic interference, this frame is lost during Bluetooth transmission, resulting in the second IoT device not receiving it. In a feasible embodiment, the method further includes: The underlying communication link's transmission status is monitored to obtain frame loss instructions. This monitoring of transmission status can be achieved through acknowledgment mechanisms or timeout timers. If the first IoT device does not receive an acknowledgment for a specific data frame within a specified time or receives a negative acknowledgment, it is determined that the data frame was lost or corrupted during transmission, thereby generating a frame loss instruction.

[0036] In response to the received frame loss command, the first IoT device and the second IoT device are triggered to retransmit local data frames based on a pre-configured tunneling protocol. It should be noted that this local data frame retransmission is performed within a private protocol stack. That is, the private protocol stack directly retrieves the original data of the lost frame from its maintained send buffer, repackages it, and retransmits it through the underlying communication link, without the involvement of upper-layer business applications or the complex processing of the kernel protocol stack.

[0037] S104: Through the near-field communication link, the traffic of the first IoT device is forwarded via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes: a system protocol stack and a private protocol stack running in parallel within the same dual-stack gateway.

[0038] like Figure 6 As shown, the dual-stack gateway is a software architecture component deployed in the first IoT device (local on machine A) and the second IoT device (remote on machine B), respectively, to maintain a parallel system protocol stack and a private protocol stack. The system protocol stack resides in kernel mode, responsible for standard network communication and serving as the default network exit for upper-layer business applications, handling routine interactions with the target network. The private protocol stack resides in user mode, responsible for near-field communication link adaptation. It does not rely on the operating system's standard TCP / IP implementation but executes custom protocol adaptation and conversion logic. The dual-stack gateway configuration allows the first IoT device to send standard protocol stack data streams to the target network via the system protocol stack when the network is normal. When a weak or disconnected network is detected, a routing strategy intercepts and redirects the standard protocol stack data streams from the system protocol stack to the private protocol stack. Since the private stack runs in user mode, it can bypass the rigid limitations of the kernel protocol stack, ensuring communication security and efficiency in specific scenarios such as high interference and low bandwidth. Figure 6 Tinyproxy, as shown, is a lightweight and efficient HTTP / HTTPS proxy server daemon that serves as a container for the system protocol stack (system Socket) and the private protocol stack (self-developed lwIP private stack).

[0039] The traffic generated by the first IoT device consists of upper-layer business applications running on it, such as payment software, data acquisition programs, and Message Queuing Telemetry Transport (MQTT) clients in different scenarios. Since these applications are developed based on system protocol stack interfaces, the traffic generated after processing by the operating system kernel's system protocol stack is a standard network protocol data stream.

[0040] In this embodiment, the dual-stack gateway, acting as a proxy gateway, utilizes a private protocol stack to take over the transmission control logic from the first IoT device to the second IoT device. It then directly encapsulates and forwards the data after taking over the protocol stack through the physical layer of the near-field communication link, thereby achieving cascading interoperability between different network protocol stacks. That is, Figure 7As shown, when a device encounters a weak network or network outage, to avoid becoming an information silo, it borrows network bandwidth from neighboring devices. This evolves the original single-device communication into a distributed network relay architecture supporting full service coverage, including Remote Procedure Call (RPC), event tracking, MQTT, and network requests. When the first IoT device generates service traffic destined for the target network, this traffic is first received based on the first IoT device's system protocol stack. At this point, the dual-stack gateway can intercept the standard network protocol data stream from the output path of the system protocol stack according to a preset routing strategy and transfer it to the first IoT device's private protocol stack. After entering the first IoT device's private protocol stack, the private protocol stack generates a private transmission format data stream adapted to this link, transforming standard TCP / IP packets, which could not be efficiently transmitted directly over non-IP physical links such as Bluetooth and USB, into private frames that can be stably transmitted over near-field links. The proprietary transmission format data stream is sent to the second IoT device via the established near-field communication link. It then passes through the second IoT device's proprietary protocol stack, is processed by the system protocol stack, and is forwarded to the target network using the second IoT device's normal WAN connection. This achieves a cascading of the first IoT device's system protocol stack to its proprietary protocol stack, and then to the second IoT device's proprietary protocol stack and system protocol stack. The network protocol stacks of the first and second IoT devices are logically cascaded into a single unit, allowing the first IoT device to transparently utilize the second IoT device's network channel to access the target network without requiring upper-layer services to be aware of the underlying link switching.

[0041] In one feasible embodiment, the process of forwarding the traffic of the first IoT device through a near-field communication link via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, thereby enabling the first IoT device to access the target network through the second IoT device, can be as follows: The first IoT device internally maintains a parallel system protocol stack and a private protocol stack. When a service generates a standard network protocol data stream, the application directly binds the socket to the virtual network interface corresponding to the private protocol stack via the socket option when creating the network socket. After binding, all data transmission and reception of this socket is directly handled by the private protocol stack, without the need for routing lookup and interception by the system protocol stack. After receiving the application layer data, the private protocol stack encapsulates it into a private transmission format data stream based on the characteristics of the near-field link. This private transmission format data stream is then sent to the second IoT device via the near-field communication link. The second IoT device's private protocol stack performs reverse restoration and, based on the output of the second IoT device's system protocol stack, forwards it to the target network using the second IoT device's normal WAN connection. For example, a proxy process runs on the first IoT device, listening on a local proxy port. The application on the first IoT device is configured to send traffic to this proxy port instead of directly to the target network. After receiving the traffic from the application, the proxy process delivers the traffic to the first IoT device's private protocol stack. The proprietary protocol stack encapsulates traffic into a proprietary transmission format data stream based on the characteristics of the near-field link, and sends it to the second IoT device via the near-field communication link. The second IoT device runs a corresponding proxy service process. This process receives the proprietary transmission format data stream, reverse-engineers it using the second IoT device's proprietary protocol stack to obtain the original standard network protocol data stream, and then forwards this data stream to the target network through the second IoT device's system protocol stack.

[0042] In another feasible embodiment, the traffic of the first IoT device is forwarded via a near-field communication link through a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, specifically including: On the first IoT device side, when upper-layer services generate data destined for the target network, this data stream is processed by the first system protocol stack in the operating system kernel to form a standard network protocol data stream. At this point, through the first system protocol stack of the dual-stack gateway in the first IoT device, the standard network protocol data stream destined for the target network is redirected to the first private protocol stack of the dual-stack gateway in the first IoT device. In other words, the standard network protocol data stream is intercepted from the output path of the first system protocol stack and redirected to the first private protocol stack running in user space, achieving a seamless transfer from the standard network environment to the private processing environment, and remaining transparent to upper-layer applications.

[0043] After receiving the standard network protocol data stream, the first private protocol stack performs protocol adaptation and conversion on the standard network protocol data stream to obtain a private transmission format data stream that matches the near-field communication link. This solves the problem that standard TCP / IP packets cannot be efficiently transmitted over non-IP physical links. Then, based on the near-field communication link, the private transmission format data stream is sent to the second IoT device. The second IoT device then restores the private transmission format data stream, that is, it performs a reverse operation based on the second private protocol stack within the second IoT device to obtain the standard network protocol data stream and forwards it to the target network. This allows the first device to transparently use the network channel of the second device to access the target network, achieving cross-device network interoperability and service disaster recovery.

[0044] Furthermore, in one feasible embodiment, the aforementioned redirection of the standard network protocol data stream destined for the target network to the first private protocol stack of the dual-stack gateway in the first IoT device via the first system protocol stack of the dual-stack gateway specifically includes: The first system protocol stack uses a pre-defined routing strategy to intercept standard network protocol data streams destined for the target network. This modifies the output path of standard network protocol data streams that meet the network access requirements—that is, standard network protocol data streams processed by the first IoT device in weak or offline network environments—preventing them from being sent to the wide area network. Instead, they are redirected to a virtual network interface instantiated by the first private protocol stack. It should be noted that this virtual interface logically behaves as a standard network interface card (NIC) device with an independent IP address and routing attributes, but it is not connected to a real physical network line. When standard network protocol data streams are routed to this virtual network interface, the operating system kernel automatically suspends these packets and writes them to a file descriptor or data queue bound to the interface. The first private protocol stack, running in user space, reads and captures these standard network protocol data streams, then transfers them to the user space corresponding to the first private protocol stack, allowing the first private protocol stack to take over the standard network protocol data streams. During this process, the data flow successfully moved from the kernel-mode system protocol stack to the user-mode private protocol stack, completing a seamless transfer of control. This allowed the private protocol stack to fully take over subsequent data processing and protocol conversion, and the entire process was completely transparent to the upper-layer business applications without requiring any code modifications.

[0045] Furthermore, in one feasible embodiment, the above-mentioned protocol adaptation and conversion of the standard network protocol data stream based on the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link specifically includes: After receiving a standard network protocol data stream from the system protocol stack, the first private protocol stack running in user space parses the protocol structure of the standard network protocol data stream to obtain the data content to be transmitted, which is the application layer payload. Based on this process, redundant header overhead that is not suitable for near-field communication links is removed from the standard network protocol data stream. According to the preset private protocol encapsulation format of the first private protocol stack, a private protocol header is added to the data content to be transmitted, generating a private transmission format data stream. The private protocol header contains control information that matches the near-field communication link. By converting standard TCP / IP packets into a private transmission format data stream adapted to the characteristics of the near-field link, not only is the transmission load reduced in the low-bandwidth environment of the near field, but the addition of the private header also compensates for the defects of physical links that are prone to packet loss and errors, laying a solid foundation for the stable transmission of subsequent data.

[0046] Furthermore, in one feasible embodiment, the above-mentioned restoration of the standard network protocol data stream obtained through the second IoT device and forwarding it to the target network specifically includes: The second IoT device, running a second private protocol stack in user space, receives a private transmission format data stream from the near-field communication link and performs reverse parsing on it. This reverse parsing process compares the data stream to the private protocol encapsulation format of the first IoT device, accurately removing the private protocol header to obtain the data content to be transmitted. The data content is then restored to reconstruct a standard protocol header, resulting in a standard network protocol data stream. This restored standard network protocol data stream is then sent to the second IoT device's second system protocol stack, which treats it as a legitimate network request from a local application. After entering the second system protocol stack, the standard network protocol data stream is managed by the second IoT device's operating system. Based on the second IoT device's WAN connection, the optimal path is automatically found according to the target network's network address, forwarding the standard network protocol data to the target network. This transparently extends the first IoT device's service traffic to the second device's network egress, achieving cross-device network interoperability.

[0047] In one feasible embodiment, since the first IoT device needs to borrow a second IoT device for forwarding when the network is weak or offline, it is difficult to guarantee data security if plaintext transmission is performed or if the data is decrypted by the second IoT device before forwarding. Therefore, the method further includes: The first system protocol stack performs end-to-end encryption on the standard network protocol data stream, ensuring that the standard network protocol data stream sent to the target network is encrypted using a confidential key held solely by the target network, such as a cloud server, generating inner ciphertext data. Since the encryption key for end-to-end encryption is held by the target network, it ensures that the data cannot be decrypted even if intercepted in subsequent stages. Then, the first private protocol stack performs protocol adaptation and conversion on the inner ciphertext data to obtain a private transmission format data stream compatible with the near-field communication link. It is understood that the inner ciphertext is not decrypted during this process; instead, a private format adapted to the near-field communication link is added, generating a private transmission format data stream compatible with the near-field communication link. Based on this near-field communication link, the private transmission format data stream is sent to a second IoT device, which then restores the private transmission format data stream to obtain the inner ciphertext data. At this point, the second IoT device does not possess the key to decrypt the ciphertext, therefore it cannot and does not need to view the data content, ensuring data security. The second IoT device then repackages the extracted inner-layer encrypted data into a standard network protocol format and forwards it to the target network using its own WAN connection. Once the data arrives at the target network, the target network server holding the key performs a decryption operation to restore the original standard network protocol data stream.

[0048] For example, in a specific application scenario, a car owner uses a smart POS machine to pay for parking, but the POS machine is offline. At the same time, a stranger nearby is watching a video on their smartphone with a full signal. The POS machine uses the stranger's mobile network via Bluetooth to upload the payment data. Before sending the data, the POS machine's system protocol stack directly encrypts the transaction data using the public key of the bank server (the target network), generating an inner ciphertext. Then, the POS machine's private protocol stack packages this inner ciphertext, adds the private protocol header required for Bluetooth transmission, and sends it to the stranger's phone. The stranger's phone receives the data, strips the private protocol header to obtain the inner ciphertext, but because the phone doesn't have the private key, it cannot access the inner ciphertext and must forward it to the bank server. The bank server then decrypts the ciphertext using its private key, completing the payment transaction.

[0049] In a feasible embodiment, in order to enable the first IoT device to solve the problem of latency and resource waste caused by high-frequency connection establishment when borrowing networks from other devices, the method may further include the following process: When the second IoT device's second private protocol stack receives a private transmission format data stream from the near-field link, it checks whether the private format data stream contains a new session initiation frame. If it does, it indicates a completely new service request, requiring parsing of the new session initiation frame to obtain basic information about the target network, such as the target server's IP address, port number, and required transmission protocol. It should be noted that the new session initiation frame can be determined based on standard protocol flag detection or first packet detection methods.

[0050] The basic information of the target network extracted by the second private protocol stack is transmitted to the second system protocol stack running in kernel mode, so as to perform a connection status query based on the basic information of the target network and determine whether there is a matching transport layer connection that has been established with the target network and is in an active state.

[0051] If the connection does not exist, it indicates that the current standard network protocol data stream is the initial request from the target network, or that the old connection has failed. In this case, a three-way handshake or binding operation is performed between the second IoT device and the target network based on the basic information, thereby establishing a transport layer connection between the second IoT device and the target network. The standard network protocol data stream is added to the sending queue corresponding to this transport layer connection, waiting for the link to be ready before being sent. If the connection exists, it means that the second IoT device has already established a valid connection with the target network. There is no need to re-establish the connection; instead, the transport layer connection is directly reused, and the standard network protocol data stream is injected into the sending queue of this connection and transmitted to the target network. This process solves the problems of low efficiency and missing state in the simple transparent transmission mode. Through connection reuse, in complex environments where devices share networks, the first IoT device can have a low-latency experience close to local direct connection and a better configuration of system resources.

[0052] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figure 8 , Figure 9 As shown.

[0053] Figure 8 This specification provides a schematic diagram of the structure of a communication device for an Internet of Things (IoT) device according to one or more embodiments. The device includes: The near-field communication establishment module 202 is used to trigger the first IoT device to establish a near-field communication link with the second IoT device when the network connection quality of the first IoT device is lower than a preset threshold. The cascaded communication module 204 is used to forward the traffic of the first IoT device through the dual-stack gateway via the near-field communication link, so as to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes: a system protocol stack and a private protocol stack running in parallel in the same dual-stack gateway.

[0054] Optionally, the cascaded communication module specifically includes: The pointing module 2042 is used to point the standard network protocol data stream destined for the target network to the first private protocol stack of the dual-stack gateway in the first IoT device through the first system protocol stack of the dual-stack gateway in the first IoT device. The conversion module 2044 is used to perform protocol adaptation conversion on the standard network protocol data stream based on the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link; The sending module 2046 is used to send the private transmission format data stream to the second Internet of Things device based on the near-field communication link; The restoration module 2048 is used to restore the private transmission format data stream through the second IoT device to obtain the standard network protocol data stream, and forward it to the target network to realize network interconnection between the first IoT device and the second IoT device.

[0055] Optionally, the pointing module 2042 specifically includes: The system intercepts standard network protocol data streams destined for the target network using the preset routing strategy of the first system protocol stack, and redirects the output path of the standard network protocol data streams to the virtual network interface instantiated by the first private protocol stack. The standard network protocol data stream is transferred to the user space corresponding to the first private protocol stack through the virtual network interface, so that the first private protocol stack can take over the standard network protocol data stream.

[0056] Optionally, the conversion module 2044 specifically includes: The protocol structure of the standard network protocol data stream is parsed using the first private protocol stack to obtain the data content to be transmitted; Based on the preset private protocol encapsulation format of the first private protocol stack, a private protocol header is added to the data content to be transmitted to generate the private transmission format data stream; wherein, the private protocol header includes control information that matches the near-field communication link.

[0057] Optionally, the restoration module 2048 specifically includes: Based on the second private protocol stack of the second IoT device, the private transmission format data stream is reverse-parsed to remove the private protocol header to obtain the data content to be transmitted, and the data content to be transmitted is restored to obtain the standard network protocol data stream; The restored standard network protocol data stream is sent to the second system protocol stack of the second IoT device, so as to forward the standard network protocol data stream to the target network based on the second system protocol stack.

[0058] Optionally, the device further includes: an encryption module 206; The encryption module is used to perform end-to-end encryption on the standard network protocol data stream based on the first system protocol stack to generate inner ciphertext data; wherein the encryption key for the end-to-end encryption is held by the target network; The inner ciphertext data is adapted and converted using the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link. Based on the near-field communication link, the private transmission format data stream is sent to the second IoT device, so that the private transmission format data stream can be restored based on the second IoT device to obtain the inner ciphertext data and forward it to the target network.

[0059] Optionally, the near-field communication establishment module 202 specifically includes: The underlying communication link establishment module 2022 is used to establish an underlying communication link with the second IoT device through the built-in near-field communication module of the first IoT device; The redirection module 2024 is used to negotiate and interact between the first IoT device and the second IoT device based on a preset tunneling protocol, so as to instantiate a virtual network interface in the first IoT device and redirect network traffic sent by the first IoT device to the target network to the virtual network interface. The near-field communication link establishment module 2026 is used to establish a near-field communication link between the first IoT device and the second IoT device based on the virtual network interface and the underlying communication link.

[0060] Optionally, the underlying communication link establishment module 2022 specifically includes: The first IoT device uses its built-in near-field communication module to scan and identify the second IoT device within a preset range, and initiates a connection request to the second IoT device. Based on the connection request, a physical layer connection is established between the first IoT device and the second IoT device to negotiate communication transmission parameters based on the physical layer connection and obtain the underlying communication link between the first IoT device and the second IoT device.

[0061] Optionally, the redirection module 2024 specifically includes: Through the underlying communication link, the first IoT device and the second IoT device perform negotiation and interaction based on the preset tunnel protocol to obtain tunnel configuration information; Based on the tunnel configuration information, the first private protocol stack of the dual-stack gateway in the first IoT device is invoked to instantiate the virtual network interface; The first IoT device establishes a tunnel connection between the virtual network interface and the tunnel service of the second IoT device, and redirects network traffic sent by the first IoT device to the target network to the virtual network interface.

[0062] Optionally, the device further includes: a retransmission module 208; The retransmission module 208 is used to monitor the transmission status of the underlying communication link and obtain frame loss instructions. In response to the frame loss instruction, the first IoT device and the second IoT device are triggered to retransmit local data frames based on the preset tunneling protocol. The local data frame retransmission is performed within the private protocol stack.

[0063] Optionally, the device further includes: a network connection quality determination module 210; The network connection quality determination module is used to determine the target network corresponding to the current service based on the current service of the first IoT device; Obtain the network connectivity metrics of the first IoT device relative to the target network, and determine the network connectivity quality of the first IoT device based on the network connectivity metrics.

[0064] Optionally, the device further includes: a transport layer module 212; The transport layer module 212 is used to parse the new session initial data frame to obtain basic information about the target network if the second private protocol stack receives the private transport format data stream containing a new session initial data frame. The basic information of the target network is transmitted to the second system protocol stack to determine whether a matching transport layer connection exists based on the basic information of the target network. If it does not exist, a transport layer connection between the second IoT device and the target network is established based on the basic information, and the standard network protocol data stream is added to the sending queue corresponding to the transport layer connection. If present, the standard network protocol data stream is transmitted to the target network based on the transport layer connection.

[0065] Figure 9 This specification provides a schematic diagram of the structure of a communication device for an Internet of Things (IoT) device, according to one or more embodiments. The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device via near-field communication. Through the near-field communication link, the traffic of the first IoT device is forwarded via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes a system protocol stack and a private protocol stack running in parallel within the same dual-stack gateway.

[0066] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog are commonly used. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0067] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0068] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0069] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0070] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0072] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0073] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0074] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0075] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0076] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0077] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0078] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0079] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, and therefore described more simply; relevant parts can be referred to the descriptions of the method embodiments.

[0080] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0081] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A communication method for an Internet of Things (IoT) device, the method comprising: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device via near-field communication. Through the near-field communication link, the traffic of the first IoT device is forwarded through a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, thereby enabling the first IoT device to access the target network through the second IoT device. The network protocol stack includes: a system protocol stack and a private protocol stack that run in parallel within the same dual-stack gateway.

2. The method as described in claim 1, wherein the traffic of the first IoT device is forwarded via a dual-stack gateway through the near-field communication link to cascade the network protocol stacks between the first IoT device and the second IoT device, specifically including: The standard network protocol data stream destined for the target network is directed to the first private protocol stack of the dual-stack gateway in the first IoT device via the first system protocol stack of the dual-stack gateway in the first IoT device. Based on the first private protocol stack, the standard network protocol data stream is adapted and converted to obtain a private transmission format data stream that matches the near-field communication link; Based on the near-field communication link, the private transmission format data stream is sent to the second IoT device; The private transmission format data stream is restored by the second IoT device to obtain the standard network protocol data stream, which is then forwarded to the target network, thereby enabling network interoperability between the first IoT device and the second IoT device.

3. The method as described in claim 2, wherein the standard network protocol data stream destined for the target network is redirected to the first private protocol stack of the dual-stack gateway in the first IoT device via the first system protocol stack of the dual-stack gateway, specifically includes: The system intercepts standard network protocol data streams destined for the target network using the preset routing strategy of the first system protocol stack, and redirects the output path of the standard network protocol data streams to the virtual network interface instantiated by the first private protocol stack. The standard network protocol data stream is transferred to the user space corresponding to the first private protocol stack through the virtual network interface, so that the first private protocol stack can take over the standard network protocol data stream.

4. The method as described in claim 2, based on the first private protocol stack, performs protocol adaptation conversion on the standard network protocol data stream to obtain a private transmission format data stream that matches the near-field communication link, specifically including: The protocol structure of the standard network protocol data stream is parsed using the first private protocol stack to obtain the data content to be transmitted; Based on the preset private protocol encapsulation format of the first private protocol stack, a private protocol header is added to the data content to be transmitted to generate the private transmission format data stream; wherein, the private protocol header includes control information that matches the near-field communication link.

5. The method as described in claim 4, wherein the standard network protocol data stream is obtained by restoring it through the second IoT device and forwarded to the target network, specifically includes: Based on the second private protocol stack of the second IoT device, the private transmission format data stream is reverse-parsed to remove the private protocol header to obtain the data content to be transmitted, and the data content to be transmitted is restored to obtain the standard network protocol data stream; The restored standard network protocol data stream is sent to the second system protocol stack of the second IoT device, so as to forward the standard network protocol data stream to the target network based on the second system protocol stack.

6. The method of claim 2, further comprising: The standard network protocol data stream is end-to-end encrypted based on the first system protocol stack to generate inner ciphertext data; wherein the encryption key for the end-to-end encryption is held by the target network. The inner ciphertext data is adapted and converted using the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link. Based on the near-field communication link, the private transmission format data stream is sent to the second IoT device, so that the private transmission format data stream can be restored based on the second IoT device to obtain the inner ciphertext data and forward it to the target network.

7. The method as described in claim 1, wherein triggering the first IoT device to establish a near-field communication link with the second IoT device via near-field communication specifically includes: The first IoT device establishes a low-level communication link with the second IoT device through its built-in near-field communication module; Based on a pre-built tunneling protocol, negotiation and interaction are performed between the first IoT device and the second IoT device to instantiate a virtual network interface in the first IoT device and redirect network traffic sent by the first IoT device to the target network to the virtual network interface. Based on the virtual network interface and the underlying communication link, a near-field communication link is established between the first IoT device and the second IoT device.

8. The method as described in claim 7, wherein establishing a low-level communication link with the second IoT device through the built-in near-field communication module of the first IoT device, specifically includes: The first IoT device uses its built-in near-field communication module to scan and identify the second IoT device within a preset range, and initiates a connection request to the second IoT device. Based on the connection request, a physical layer connection is established between the first IoT device and the second IoT device to negotiate communication transmission parameters based on the physical layer connection and obtain the underlying communication link between the first IoT device and the second IoT device.

9. The method as described in claim 7, wherein, based on a pre-configured tunneling protocol, negotiation and interaction are performed between the first IoT device and the second IoT device to instantiate a virtual network interface in the first IoT device and redirect network traffic from the first IoT device to the target network to the virtual network interface, specifically including: Through the underlying communication link, the first IoT device and the second IoT device perform negotiation and interaction based on the preset tunnel protocol to obtain tunnel configuration information; Based on the tunnel configuration information, the first private protocol stack of the dual-stack gateway in the first IoT device is invoked to instantiate the virtual network interface; The first IoT device establishes a tunnel connection between the virtual network interface and the tunnel service of the second IoT device, and redirects network traffic sent by the first IoT device to the target network to the virtual network interface.

10. The method of claim 9, further comprising: Monitor the transmission status of the underlying communication link and obtain frame loss instructions; In response to the frame loss instruction, the first IoT device and the second IoT device are triggered to retransmit local data frames based on the preset tunneling protocol. The local data frame retransmission is performed within the private protocol stack.

11. The method of claim 1, further comprising: Based on the current service of the first IoT device, determine the target network corresponding to the current service; Obtain the network connectivity metrics of the first IoT device relative to the target network, and determine the network connectivity quality of the first IoT device based on the network connectivity metrics.

12. The method of claim 5, further comprising: If the second private protocol stack receives the private transmission format data stream, which contains a new session initial data frame, then the new session initial data frame is parsed to obtain basic information about the target network. The basic information of the target network is transmitted to the second system protocol stack to determine whether a matching transport layer connection exists based on the basic information of the target network. If it does not exist, a transport layer connection between the second IoT device and the target network is established based on the basic information, and the standard network protocol data stream is added to the sending queue corresponding to the transport layer connection. If present, the standard network protocol data stream is transmitted to the target network based on the transport layer connection.

13. A communication device for an Internet of Things (IoT) device, comprising: The near-field communication establishment module is used to trigger the first IoT device to establish a near-field communication link with the second IoT device when the network connection quality of the first IoT device is lower than a preset threshold. The cascaded communication module is used to forward the traffic of the first IoT device through the dual-stack gateway via the near-field communication link, so as to cascade the network protocol stack between the first IoT device and the second IoT device, and enable the first IoT device to access the target network through the second IoT device. The network protocol stack includes: a system protocol stack and a private protocol stack that run in parallel within the same dual-stack gateway.

14. The apparatus of claim 13, wherein the cascaded communication module specifically comprises: The pointing module is used to point the standard network protocol data stream destined for the target network to the first private protocol stack of the dual-stack gateway in the first IoT device through the first system protocol stack of the dual-stack gateway in the first IoT device. The conversion module is used to perform protocol adaptation conversion on the standard network protocol data stream based on the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link; The sending module is used to send the private transmission format data stream to the second IoT device based on the near-field communication link; The restoration module is used to restore the private transmission format data stream through the second IoT device to obtain the standard network protocol data stream, and forward it to the target network to realize network interconnection between the first IoT device and the second IoT device.

15. The apparatus of claim 14, wherein the pointing module specifically comprises: The system intercepts standard network protocol data streams destined for the target network using the preset routing strategy of the first system protocol stack, and redirects the output path of the standard network protocol data streams to the virtual network interface instantiated by the first private protocol stack. The standard network protocol data stream is transferred to the user space corresponding to the first private protocol stack through the virtual network interface, so that the first private protocol stack can take over the standard network protocol data stream.

16. The apparatus of claim 14, wherein the conversion module specifically comprises: The protocol structure of the standard network protocol data stream is parsed using the first private protocol stack to obtain the data content to be transmitted; Based on the preset private protocol encapsulation format of the first private protocol stack, a private protocol header is added to the data content to be transmitted to generate the private transmission format data stream; wherein, the private protocol header includes control information that matches the near-field communication link.

17. The apparatus of claim 16, wherein the restoration module specifically comprises: Based on the second private protocol stack of the second IoT device, the private transmission format data stream is reverse-parsed to remove the private protocol header to obtain the data content to be transmitted, and the data content to be transmitted is restored to obtain the standard network protocol data stream; The restored standard network protocol data stream is sent to the second system protocol stack of the second IoT device, so as to forward the standard network protocol data stream to the target network based on the second system protocol stack.

18. The apparatus of claim 14, further comprising: Encryption module; The encryption module is used to perform end-to-end encryption on the standard network protocol data stream based on the first system protocol stack to generate inner ciphertext data; wherein the encryption key for the end-to-end encryption is held by the target network; The inner ciphertext data is adapted and converted using the first private protocol stack to obtain a private transmission format data stream that matches the near-field communication link. Based on the near-field communication link, the private transmission format data stream is sent to the second IoT device, so that the private transmission format data stream can be restored based on the second IoT device to obtain the inner ciphertext data and forward it to the target network.

19. The apparatus of claim 13, wherein the near-field communication establishment module specifically comprises: The underlying communication link establishment module is used to establish an underlying communication link with the second IoT device through the built-in near-field communication module of the first IoT device; The redirection module is used to negotiate and interact between the first IoT device and the second IoT device based on a preset tunneling protocol, so as to instantiate a virtual network interface in the first IoT device and redirect network traffic sent by the first IoT device to the target network to the virtual network interface. The near-field communication link establishment module is used to establish a near-field communication link between the first IoT device and the second IoT device based on the virtual network interface and the underlying communication link.

20. The apparatus of claim 19, wherein the underlying communication link establishment module specifically comprises: The first IoT device uses its built-in near-field communication module to scan and identify the second IoT device within a preset range, and initiates a connection request to the second IoT device. Based on the connection request, a physical layer connection is established between the first IoT device and the second IoT device to negotiate communication transmission parameters based on the physical layer connection and obtain the underlying communication link between the first IoT device and the second IoT device.

21. The apparatus of claim 19, wherein the redirection module specifically comprises: Through the underlying communication link, the first IoT device and the second IoT device perform negotiation and interaction based on the preset tunnel protocol to obtain tunnel configuration information; Based on the tunnel configuration information, the first private protocol stack of the dual-stack gateway in the first IoT device is invoked to instantiate the virtual network interface; The first IoT device establishes a tunnel connection between the virtual network interface and the tunnel service of the second IoT device, and redirects network traffic sent by the first IoT device to the target network to the virtual network interface.

22. The apparatus of claim 21, further comprising: Retransmission module; The retransmission module is used to monitor the transmission status of the underlying communication link and obtain frame loss instructions. In response to the frame loss instruction, the first IoT device and the second IoT device are triggered to retransmit local data frames based on the preset tunneling protocol. The local data frame retransmission is performed within the private protocol stack.

23. The apparatus of claim 13, further comprising: Network connection quality determination module; The network connection quality determination module is used to determine the target network corresponding to the current service based on the current service of the first IoT device; Obtain the network connectivity metrics of the first IoT device relative to the target network, and determine the network connectivity quality of the first IoT device based on the network connectivity metrics.

24. The apparatus of claim 17, further comprising: Transport layer module; The transport layer module is used to parse the new session initial data frame to obtain basic information about the target network if the second private protocol stack receives the private transport format data stream containing a new session initial data frame. The basic information of the target network is transmitted to the second system protocol stack to determine whether a matching transport layer connection exists based on the basic information of the target network. If it does not exist, a transport layer connection between the second IoT device and the target network is established based on the basic information, and the standard network protocol data stream is added to the sending queue corresponding to the transport layer connection. If present, the standard network protocol data stream is transmitted to the target network based on the transport layer connection.

25. A communication device for an Internet of Things (IoT) device, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: When the network connection quality of the first IoT device is lower than a preset threshold, the first IoT device is triggered to establish a near-field communication link with the second IoT device via near-field communication. Through the near-field communication link, the traffic of the first IoT device is forwarded via a dual-stack gateway to cascade the network protocol stacks between the first IoT device and the second IoT device, enabling the first IoT device to access the target network through the second IoT device; the network protocol stack includes a system protocol stack and a private protocol stack running in parallel within the same dual-stack gateway.

Images