Internet of Things module gateway collaborative IPv4 (Internet Protocol Version 4) service transparent transmission system and method

Abstract

The invention discloses an internet of things module gateway collaborative IPv4 service transparent transmission system and method, and aims to solve the core contradiction that an IPv6 single-stack internet of things module with strictly limited resources cannot efficiently access an IPv4 server. According to the invention, bidirectional protocol conversion is realized through cooperation of the module side and the gateway side. A lightweight CLAT module is integrated on the module side, an IPv4 message generated by a standard IPv4 Socket API called by an application program is intercepted, the IPv4 message is packaged into an IPv6 message according to the RFC 2473 IP-in-IP standard, and the IPv6 message is sent to a gateway through an LTE network in cooperation with a deeply-cut LwIP protocol stack. The gateway side receives the IPv6 message through the PLAT module, decapsulates and extracts an original IPv4 message, then completes dynamic mapping of a module IPv6 address and a gateway public network IPv4 address through an NAT44 engine, and forwards the IPv6 message to a target IPv4 server; and the flow is reversely executed in the downlink direction. And meanwhile, the NAT table activity and gateway fault automatic switching are maintained through a heartbeat engine. The IPv4 service transparent transmission system and the IPv4 service transparent transmission method meet the scene requirements of low power consumption and high real-time property of the Internet of Things.

Description

Technical Field

[0001] This invention relates to the field of wireless communication, and specifically to an IPv4 service pass-through system and method for IoT module gateway collaboration. Background Technology

[0002] Currently, operator networks have generally completed IPv6 upgrades, building an IoT communication infrastructure centered on IPv6. However, many IoT industry customers still rely on traditional IPv4 servers to deploy services such as industrial data acquisition and remote equipment monitoring using IPv4 protocol stack application servers. This leads to a "network protocol incompatibility" contradiction between IPv6 single-stack IoT terminals and IPv4 servers. In other words, IPv6 single-stack IoT modules cannot directly establish a communication link with IPv4 servers and need to use protocol conversion technology to achieve transparent transmission of business data.

[0003] In existing technologies, there are three main solutions to the problem of "IPv6 terminals accessing IPv4 servers," but all of them have significant drawbacks in resource-constrained IoT scenarios, such as low-power narrowband IoT devices (NB-IoT) and embedded modules with severely limited memory / computing power, as detailed below:

[0004] (1) IPv4 / IPv6 Dual-Stack Solution. A complete IPv4 and IPv6 dual-protocol stack is integrated within the IoT module, enabling the module to process packets of both protocols simultaneously. Its main drawback is:

[0005] (a) High resource overhead: Dual-stack protocol stacks need to load a full set of functional modules such as IPv4 and IPv6 routing, encapsulation, and verification at the same time, resulting in generally high memory consumption. However, most low-power IoT modules, such as NB-IoT modules, only have tens of KB of available memory, which is difficult to support dual-stack operation.

[0006] (b) Protocol stack conflict risk: The network interface and processing thread of the dual stack shared by the module are prone to problems such as IPv4 and IPv6 packets competing for resources and routing table conflicts, which leads to an increased probability of service interruption and poor stability.

[0007] (2) Cloud-based NAT64 solution. For example... Figure 1 As shown, a dedicated NAT64 gateway is deployed in the operator's core network or customer cloud to convert packets sent by IPv6 terminals into IPv4 format before forwarding them to the target server, while simultaneously converting the response packets from the IPv4 server into IPv6 format for return transmission. Its main drawback is:

[0008] (a) High deployment and adaptation costs: It requires additional modifications to the customer's existing DNS system to support DNS64 resolution, mapping IPv4 domain names to IPv6 addresses, and relies on the resources invested by the operator or customer to deploy and maintain the NAT64 gateway, which is not suitable for small and medium-sized enterprises or lightweight IoT scenarios.

[0009] (b) Incomplete protocol support: It does not support the ICMP protocol, so it cannot test the network connectivity between the terminal and the server via Ping. It also lacks IP fragmentation and reassembly capabilities; when the service data exceeds the MTU (Maximum Transmission Unit), the packet will be discarded directly.

[0010] (c) Compatibility limitations: It does not support raw socket communication and cannot meet the customized protocol requirements of some industrial IoT devices based on raw socket.

[0011] (3) Application Layer Proxy Solution. An HTTP / HTTPS / Socket proxy module needs to be added to the application layer of the IoT module to relay business data between IPv6 and IPv4 through a proxy server. Its main drawback is:

[0012] (a) Significant increase in business latency: Data needs to go through multiple hops of "module-proxy server-target server", and the proxy module needs to unpack, forward and reassemble application layer data, resulting in a significant increase in average business latency.

[0013] (b) High protocol coupling: The proxy module needs to be strongly bound to specific application layer protocols, such as HTTP and MQTT. If the customer changes the business protocol, such as switching from HTTP to a private TCP protocol, the proxy module needs to be redeveloped and adapted, which is inflexible.

[0014] In summary, existing technologies cannot simultaneously meet the core requirements of IoT scenarios: low resource consumption, high compatibility, and low latency. Therefore, a lightweight, efficient, and compatible IPv4 service pass-through technology is needed that is adapted to resource-constrained IPv6 single-stack IoT modules. Summary of the Invention

[0015] To address the aforementioned shortcomings of existing technologies, this invention achieves IPv4 service pass-through through a lightweight conversion architecture that coordinates modules and gateways. This invention proposes an IPv4 service pass-through system and method for IoT module-gateway collaboration, comprising a module side and a gateway side. The module side encapsulates IPv4 packets into IPv6 packets and receives IPv6 packets returned from the gateway side, decapsulating them back into IPv4 packets. The gateway side receives IPv6 packets sent by the module side, performs decapsulation and NAT address translation, forwards them to an IPv4 server, and receives response packets from the IPv4 server, encapsulates them into IPv6 packets, and returns them to the module side.

[0016] The module side includes an application program, a client-side converter module, an LwIP protocol stack, and an LTE network interface; the gateway side includes a dual-interface network interface, a packet distributor, a provider-side converter engine, a NAT44 engine, and a NAT table management module; the dual-interface network interface includes a downlink core network interface for LTE operators and an uplink Internet interface.

[0017] Preferably, the application calls the standard IPv4 Socket API to initiate an IPv4 service request, sends an IPv4 packet to the client-side converter module, and obtains a decapsulated IPv4 response packet from the client-side converter module.

[0018] Preferably, the client-side converter module is integrated between the application and the LwIP protocol stack, serving as a lightweight hook to intercept packets; during uplink, it encapsulates IPv4 packets into IPv6 packets; during downlink, it strips the IPv6 header to extract the original IPv4 packets and delivers them to the application.

[0019] Preferably, the packet distributor checks whether the destination address of the IPv6 packet matches the preset client-side converter module dedicated prefix; if it matches, it is determined to be a service packet encapsulated by the client-side converter module and sent to the provider-side converter engine for processing; if it does not match, it is handed over to the gateway's regular IPv6 routing stack or discarded.

[0020] Preferably, the provider-side converter engine supports IP fragmentation and reassembly and ICMP protocols; during uplink, it parses the IPv6 header, strips the IPv6 header to extract the original IPv4 packet, and passes it to the NAT44 engine; during downlink, it receives the IPv4 packet restored by the NAT44 engine, encapsulates it into an IPv6 packet, and delivers it to the core network interface.

[0021] Preferably, the NAT table management module uses a hash table to store the NAT mapping entries corresponding to the five-tuple "module IPv6 + module source port + protocol number + target IPv4 + target port"; the NAT44 engine realizes dynamic mapping between the module virtual IPv4 and the gateway public IPv4.

[0022] Preferably, the system implementation based on any one of claims 1-6 includes an uplink module-side process, an uplink gateway-side process, a downlink gateway-side process, and a downlink module-side process.

[0023] The uplink module-side process includes the following steps:

[0024] S11: Intercept the packet and determine the address family;

[0025] S12: Construct the IPv6 header for encapsulating the original IPv4 packet;

[0026] S13: Perform zero-copy on the IPv4 packet, reuse the checksum, and encapsulate it into an IPv6 packet;

[0027] S14: The encapsulated IPv6 packet is delivered to the LwIP protocol stack, converted into a wireless signal through the LTE network interface, and transmitted to the gateway side via the base station;

[0028] The uplink gateway-side process includes the following steps:

[0029] S21: The gateway-side network interface receives IPv6 packets. The packet distributor checks whether the destination address matches the client-side converter module's dedicated prefix. If it matches, the packet is sent to the provider-side converter engine.

[0030] S22: Provide the provider-side converter engine to parse the IPv6 header. If the "next header" is 4, then strip the IPv6 header to extract the original IPv4 packet and pass it to the NAT44 engine.

[0031] S23: The NAT table management module searches for NAT mapping entries based on the five-tuple of "module IPv6 + module source port + protocol number + target IPv4 + target port". If it exists, it updates the "last active timestamp"; otherwise, the NAT44 engine allocates a public network free port to create a mapping entry.

[0032] S24: The NAT44 engine modifies the source IP of the IPv4 packet to the gateway's public IPv4 and the source port to the assigned public port. After recalculating the IPv4 header checksum, it forwards the packet to the target IPv4 server through the Internet interface.

[0033] The downlink gateway-side process includes the following steps:

[0034] S31: The gateway receives the response message from the IPv4 server through the Internet interface and hands it over to the NAT44 engine.

[0035] S32: The NAT table management module uses "gateway public IP + public port + protocol number + server IP + server port" as the key to perform a reverse query on the NAT mapping entries to obtain the module's IPv6 and original port;

[0036] S33: The NAT44 engine modifies the destination IP / port of the response packet to the module's virtual IPv4 and the original port, restoring it to an IPv4 packet that the module can recognize, and then passes it to the provider-side converter engine.

[0037] S34: The provider-side converter engine encapsulates the restored IPv4 packet into an IPv6 packet ("Next header" is set to 4), and transmits it to the module side via the base station through the operator's core network interface.

[0038] The downlink module-side process includes:

[0039] S41: The module-side LTE network interface receives IPv6 packets, delivers them to the LwIP protocol stack, and then the LwIP protocol stack forwards them to the client-side converter module.

[0040] S42: The client-side converter module checks the "Next Header" field of the IPv6 header. If it is 4, it is determined to be the target service response message. If it is not 4, it is handed over to the application's IPv6 Socket.

[0041] S43: The client-side converter module strips the IPv6 header and extracts the original IPv4 response message;

[0042] S44: Through the virtual network card injection mechanism, the extracted IPv4 response message is delivered to the application's IPv4Socket.

[0043] Preferably, it also includes a heartbeat maintenance and fault switching procedure, which includes the following steps:

[0044] S51: Every 30 seconds, the module side constructs a heartbeat packet containing IMEI, NAT session ID, and CRC checksum, which is then encapsulated into an IPv6 message by the client-side converter module and sent to the gateway side.

[0045] S52: The gateway-side heartbeat engine receives heartbeat packets. If the CRC verification passes, it updates the timestamp of the corresponding NAT table entry and returns an acknowledgment response. If the verification fails, it discards the packet.

[0046] S53: If the module does not receive a confirmation response within 5 seconds, a retry will be triggered. If multiple retry attempts fail, the system will automatically switch to the backup gateway and re-initiate the client-side converter module registration and heartbeat process.

[0047] Preferably, step S12 includes: copying the TOS field value of the original IPv4 packet to the "Traffic Category" field of the IPv6 header; setting the "Flow Label" field to 0 when QoS flow management is not enabled; setting the "Payload Length" field to the total length of the original IPv4 packet; setting the "Hop Limit" field to 64; setting the "Source Address" to the module's global unicast IPv6 address; and constructing the "Destination Address" according to "[Gateway Client-Side Converter Module Prefix]::ffff:[Destination IPv4 Address]".

[0048] Preferably, the zero-copy method directly associates the memory address of the original IPv4 packet with the newly constructed IPv6 header via a memory pointer; the multiplexing of the checksum includes:

[0049] (1) IPv4 checksum: The checksum of the original IPv4 packet is used directly. This checksum has been calculated by the application or the LwIP upper layer.

[0050] (2) IPv6 checksum: Only the newly constructed IPv6 header checksum is calculated, which is generated based on the IPv6 header field using the standard CRC32 algorithm;

[0051] (3) TCP / UDP checksum: Taking advantage of the feature of "IPv6 destination address embedded in original IPv4 address", the result of TCP / UDP checksum calculation based on original IPv4 pseudo header is still valid and the original value is directly used.

[0052] The present invention has the following beneficial effects:

[0053] (1) Reduced resource consumption and adaptation to low-power IoT modules. Significantly reduced memory usage: The lightweight CLAT module integrated on the module side and the deeply customized LwIP protocol stack result in a total memory consumption that is far lower than existing dual-stack and NAT64 solutions. The encapsulation process adopts a zero-copy mechanism, avoiding complete copying of IPv4 packets through memory pointer operations, which significantly reduces memory consumption and shortens the CPU processing time for a single packet. At the same time, the TCP / UDP transport layer checksum is reused, eliminating the need for recalculation due to protocol conversion, further reducing computing resource consumption and adapting to IoT terminals with limited computing power.

[0054] (2) Improve service transmission efficiency and meet real-time requirements. Data transmission only goes through a simplified link of "module-gateway-target server" and there is no multi-hop forwarding and packet reassembly time consumption of application layer proxy, reducing service latency. By simplifying the protocol conversion process and the NAT table fast lookup mechanism, the connection establishment time is reduced, improving device access efficiency and service response speed.

[0055] (3) Improved protocol support capabilities and compatibility covering all scenarios. Fully supports ICMP protocol, IP fragmentation and reassembly, and raw Socket communication. The module-side application only calls the standard IPv4 Socket API, without needing to be aware of the underlying protocol conversion logic, and without being strongly bound to specific application layer protocols, which provides good flexibility and reduces adaptation costs.

[0056] This invention proposes an IPv4 service pass-through system and method for IoT module gateway collaboration, which features low resource consumption and high transmission efficiency. Attached Figure Description

[0057] Figure 1 A diagram of the existing NAT64 scheme;

[0058] Figure 2 This is a system structure diagram of an embodiment of the present invention;

[0059] Figure 3 This is the module-side CLAT processing flow according to an embodiment of the present invention;

[0060] Figure 4 This is the PLAT processing flow on the gateway side of an embodiment of the present invention; Detailed Implementation

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

[0062] Terminology Explanation:

[0063] CLAT: Customer side Translator, located on the user equipment side, converts IPv4 packets into IPv6 format for transmission in IPv6 networks.

[0064] PLAT: Provider side Translator, located on the network operator's side, converts IPv6 packets back to IPv4 for communication with IPv4 services.

[0065] LwIP: Light Weight IP, is a TCP / IP protocol stack designed specifically for resource-constrained embedded systems.

[0066] Example 1

[0067] This embodiment describes an IPv4 service pass-through system that coordinates IoT module gateways. For example... Figure 2 As shown, it includes the module side and the gateway side.

[0068] The core objective of the module side is to encapsulate IPv4 packets into IPv6 packets with low resource overhead and without modifying the application, adapting to the operator's IPv6 network. This includes the following parts:

[0069] (1) Application Program. This is the source and final receiver of business data, responsible for initiating IPv4 service requests, such as uploading data from industrial equipment and sending remote monitoring commands. The application program only calls the standard IPv4 Socket API, without needing to be aware of the underlying IPv4 and IPv6 conversion logic, achieving "zero-modification adaptation." When customers change their business protocol, such as switching from HTTP to a private TCP protocol, no modification to the application code is required. Data Flow: When sending data, IPv4 packets are output to the CLAT module; when receiving data, the decapsulated IPv4 response packets are obtained from the CLAT module.

[0070] (2) CLAT module (client-side converter). It is the core conversion component on the module side, integrated between the application and the LwIP protocol stack, and acts as a lightweight "hook" to intercept and process packets. It has a low memory footprint and is adapted to the resource limitations of low-power modules.

[0071] Uplink processing: Intercept IPv4 packets from applications and encapsulate them into IPv6 packets according to the RFC 2473 IP-in-IP standard, including IPv6 header structures such as "Version Number = 6" and "Next Header = 4" to identify the IPv4 payload. Zero-copy mechanism and checksum reuse are employed to reduce resource consumption.

[0072] Downlink processing: Receive IPv6 packets from the LwIP protocol stack, check the "next header" field, and if the value is 4, determine that it is a CLAT response packet. After stripping the IPv6 header, extract the original IPv4 packet and deliver it to the application through the "virtual NIC injection mechanism".

[0073] (3) A deeply trimmed LwIP protocol stack, a lightweight network protocol stack adapted to LTE networks, retaining only core functions such as IPv6 routing and LTE data adaptation, and eliminating redundant modules. It supports default route configuration pointing to the operator's core network gateway, ensuring efficient forwarding of IPv6 packets to the gateway. Data flow: Receives IPv6 packets from the CLAT module and sends them through the LTE network interface; simultaneously receives downlink IPv6 packets from the LTE interface and delivers them to the CLAT module.

[0074] (4) LTE Network Interface. The communication adaptation layer between the module and the operator's base station, supporting low-power IoT communication standards such as NB-IoT and LTE-M. Uplink: Converts IPv6 packets output from the LwIP protocol stack into wireless signals and transmits them to the gateway via the base station. Downlink: Receives gateway IPv6 response packets forwarded by the base station, converts them into data frames, and delivers them to the LwIP protocol stack.

[0075] The core objective of the gateway side is to receive IPv6 packets from the receiving module, perform decapsulation, NAT translation, and IPv4 forwarding, while maintaining connection stability through a heartbeat mechanism. This includes the following parts:

[0076] (1) Network Interface. This is the connection point between the gateway and the external network, employing a dual-interface design to enable interconnection with different networks. Carrier Core Network Interface: Interconnects to the LTE network, receives IPv6 packets sent by the module, and sends downlink IPv6 response packets. Internet Interface: Interconnects to the public IPv4 network, receives response packets from the IPv4 server, and sends converted IPv4 request packets. The network interface performs preliminary legality checks on the received IPv6 packets, such as discarding illegal format packets, to improve network security.

[0077] (3) Packet Distributor. Enables rapid classification and routing of IPv6 packets, avoiding invalid processing and improving gateway processing efficiency. It checks whether the destination address of the IPv6 packet matches the preset CLAT prefix, such as 2001:db8:ffff:: / 64. If a match is found, it is determined to be a service packet encapsulated by the module's CLAT and sent to the PLAT engine's fast processing link. If a mismatch is found, it is transferred to the gateway's regular IPv6 routing stack or discarded directly to prevent illegal packet attacks.

[0078] (3) PLAT Conversion Engine (Provider-Side Converter). This is the core conversion component on the gateway side, responsible for bidirectional decapsulation and encapsulation of IPv6 and IPv4, connecting the data link between the module and the IPv4 server. It supports IP fragmentation and reassembly, solving the problem of large-size business data transmission, and is compatible with the ICMP protocol, such as detecting the connectivity between the terminal and the server through Ping.

[0079] Uplink processing: Parse the IPv6 header, verify "Next header = 4", strip the IPv6 header to extract the original IPv4 packet, and pass it to the NAT44 engine. Downlink processing: Receive the IPv4 packet restored by the NAT44 engine, encapsulate it into an IPv6 packet (IPv6 source address is gateway IPv6, destination address is module IPv6, "Next header = 4"), and deliver it to the core network interface.

[0080] (4) NAT44 Engine. Enables dynamic mapping between module IPv6 addresses and gateway public IPv4 addresses, solving the problem of IPv4 address scarcity. Supports NAT entry aging mechanism (default 180 seconds) to automatically clean up invalid mappings and avoid resource waste.

[0081] Uplink: Receives IPv4 packets from the PLAT engine, modifies the source IP from the module's virtual IPv4 (e.g., 10.0.0.5) to the gateway's public IPv4 (203.0.113.5), replaces the source port with a public free port assigned by the gateway (e.g., 56789), recalculates the IPv4 header checksum, and then delivers it to the IPv4 routing stack.

[0082] Downlink: Receives response packets from the IPv4 server, modifies the destination IP / port to the module's virtual IPv4 and the original port based on the reverse lookup results from the NAT table management module, and restores the IPv4 packets that the module can recognize.

[0083] (5) NAT Table Management Module. Maintains the dynamic mapping relationship between "module - public network - target server" to provide address translation basis for the NAT44 engine. Hash tables can be used to store mapping items, resulting in short query time and ensuring address translation efficiency.

[0084] Mapping Creation: Based on the 5-tuple "Module IPv6 + Module Source Port + Protocol Number + Target IPv4 + Target Port", a NAT mapping entry is created, such as {2001:db8:100:200::5:12345 → 203.0.113.5:56789 →192.0.2.100:8080}. Mapping Update: Upon receiving a trigger signal from the heartbeat engine, the mapping entry's "Last Activity Timestamp" is updated to prevent NAT table aging. Reverse Lookup: During downlink operations, the corresponding module IPv6 and source port are queried using "Gateway Public IP + Public Port + Protocol Number + Server IP + Server Port" as the key.

[0085] (6) Heartbeat Engine. Maintains the connection stability between the module and the gateway, enables automatic switching in case of gateway failure, and meets the reliability requirements of industrial-grade IoT. Supports CRC data integrity verification to avoid misjudgment caused by heartbeat packet tampering or loss.

[0086] Module Interaction: Receives heartbeat packets (containing module IMEI, NAT session ID, and CRC checksum) sent by the module every 30 seconds. After successful verification, updates the NAT table entry timestamp and returns a "heartbeat confirmation response". Fault Handling: If the module fails to receive a confirmation response for 3 consecutive times (each with a timeout of 5 seconds), it determines that the primary gateway is unreachable, triggering the module to switch to the backup gateway. The switchover is short, ensuring uninterrupted service.

[0087] In this embodiment of the invention, the components on the module side and the gateway side of the system cooperate with each other to complete the IPv4 service pass-through with low resource consumption and high processing efficiency.

[0088] Example 2

[0089] This embodiment addresses the challenge of resource-constrained IPv6 single-stack IoT modules, such as low-power narrowband IoT devices (NB-IoT), which have limited available memory (only tens of KB) and computing power, making it difficult to efficiently access IPv4 servers. Through a collaborative architecture of "lightweight CLAT conversion on the module side + stateless PLAT conversion on the gateway side," seamless transmission of IPv4 services is achieved without modifying the application or increasing resource overhead.

[0090] This embodiment describes a method for transparent transmission of IPv4 services in collaboration between an IoT module and a gateway. The core logic is as follows: the module encapsulates IPv4 packets into IPv6 packets to adapt to the operator's IPv6 network, and the gateway decapsulates the packets and performs NAT mapping before forwarding them to the IPv4 server. The process is executed in reverse in the downlink direction, while maintaining connection stability through a heartbeat mechanism. The entire process takes into account low resource consumption, low latency, and high compatibility.

[0091] To ensure the module and gateway work together, the following parameters need to be preset. These parameters can be dynamically assigned through configuration files or by the operator:

[0092] (1) Module-side parameters. Global unicast IPv6 address: 2001:db8:100:200::5, allocated by the operator's core network.

[0093] (2) Gateway side parameters. Gateway type: Carrier edge gateway. CLAT special prefix: 2001:db8:ffff:: / 96, used to identify IPv6 packets encapsulated by the module. Public IPv4 address: 203.0.113.5, used for NAT44 address mapping. NAT table aging time: 180 seconds by default.

[0094] (3) Target IPv4 server parameters. Address: 192.0.2.100, providing HTTP data receiving service. Port: 8080, TCP protocol.

[0095] (4) Heartbeat mechanism parameters. Heartbeat cycle: 30 seconds / beat. Timeout: 5 seconds / beat. Number of retries: 3. Fault handover time: ≤20 seconds.

[0096] The uplink process refers to the entire chain of "the IoT module application initiates an IPv4 service request → the module CLAT encapsulates it into IPv6 → the gateway PLAT decapsulates and performs NAT translation → forwarding it to the target IPv4 server". The following is a detailed explanation of the module side and the gateway side.

[0097] The main processing step of the uplink module's CLAT module is to encapsulate IPv4 packets into IPv6. For example... Figure 3 As shown, the CLAT module, as a lightweight hook, is integrated between the application and the LwIP protocol stack. Its core function is to "intercept IPv4 packets and encapsulate them into IPv6 according to the RFC 2473 IP-in-IP standard," without affecting the original logic of the application; the application still calls the standard IPv4 Socket API. The specific steps are as follows:

[0098] S11: Message interception and address family determination.

[0099] (1) Interception trigger: When an application, such as an industrial data acquisition program, sends data through an IPv4 socket, for example, when uploading a device status log to 192.0.2.100:8080, the CLAT module will intercept the IPv4 packet first.

[0100] (2) Address determination: Parse the sin_family (address family identifier) ​​field of the packet:

[0101] (a) If sin_family == AF_INET (the target is an IPv4 address, such as 192.0.2.100), proceed to the subsequent encapsulation process;

[0102] (b) If sin_family == AF_INET6 (the target is an IPv6 address), the IPv6 processing link is directly passed through to the LwIP protocol stack without any additional operations.

[0103] S12: IPv6 packet header construction and IP-in-IP encapsulation.

[0104] The CLAT module encapsulates the raw IPv4 packet (including IPv4 header + HTTP payload) into an IPv6 packet. This primarily involves constructing an IPv6 header conforming to RFC 2473. The configuration rules for each field strictly match preset parameters, as detailed below:

[0105] (1) Version number, set to 6, is a fixed identifier for the IPv6 protocol, which is different from the "4" in IPv4.

[0106] (2) Traffic Class: Copy the TOS (Type of Service) field value of the original IPv4 packet. For example, "0x08" indicates high priority to ensure QoS consistency.

[0107] (3) Flow Label: Set to 0 when QoS flow management is not enabled. If real-time control is required, set to a non-zero value such as "0x12345".

[0108] (4) Payload Length: The total length of the original IPv4 packet, including the IPv4 header and HTTP payload. For example, if the IPv4 header is 20 bytes and the payload is 100 bytes, it is set to 120 here.

[0109] (5) Next Header, set to 4, a fixed value, to identify the IPv6 payload as an IPv4 packet, i.e. IP-in-IP encapsulation.

[0110] (6) Hop Limit, which can be set to 64 to prevent packets from being forwarded indefinitely in the network. Packets exceeding the hop limit will be dropped.

[0111] (7) Source Address: The module’s global unicast IPv6 address: 2001:db8:100:200::5, which is dynamically allocated by the operator to ensure uniqueness.

[0112] (8) Destination Address, constructed according to “[gateway CLAT prefix]::ffff:[target IPv4 address]”, in this embodiment it is 2001:db8:ffff::ffff:192.0.2.100, hexadecimal abbreviation: 2001:db8:ffff::ffff:c000:264.

[0113] After encapsulation, the final IPv6 packet structure is: [IPv6 header (40 bytes)] + [original IPv4 packet (IPv4 header 20 bytes + HTTP payload 100 bytes)].

[0114] S13: Zero-copy and checksum reuse.

[0115] To reduce module memory and computing resource overhead, the CLAT module employs the following optimization methods:

[0116] (1) Zero-copy mechanism. Instead of generating the IPv6 payload by "copying the original IPv4 packet", the memory address of the original IPv4 packet is directly associated with the newly constructed IPv6 header through memory pointer operations. This operation reduces memory overhead by about 40% and shortens the CPU processing time for a single packet to less than 1ms.

[0117] (2) Checksum reuse. IPv4 checksum: The checksum of the original IPv4 packet is not modified. This checksum has been calculated by the application or the LwIP upper layer. IPv6 checksum: Only the newly constructed IPv6 header checksum is calculated. It is generated based on the IPv6 header field using the standard CRC32 algorithm. TCP / UDP checksum: Taking advantage of the feature of "IPv6 destination address embedded in the original IPv4 address", the result of TCP / UDP checksum calculation based on the original IPv4 pseudo-header is still valid. No recalculation is required. The original value is directly used, reducing computational overhead.

[0118] S14: Message sent to gateway

[0119] The encapsulated IPv6 packets are delivered to a deeply trimmed LwIP protocol stack. The protocol stack retains only basic functions such as IPv6 routing and LTE adaptation, with a memory of ≤8KB. The protocol stack converts the packets into wireless signals via the LTE modem through the default route pointing to the operator's core network gateway, and then transmits them to the PLAT module of the target gateway via the base station.

[0120] The gateway-side PLAT module mainly handles "IPv6 decapsulation + NAT translation + IPv4 forwarding". For example... Figure 4 As shown, the PLAT module is a core component on the gateway side. It is responsible for receiving IPv6 packets from other modules, performing decapsulation and NAT44 address mapping, and then forwarding the IPv4 packets to the target server. The specific steps are as follows:

[0121] S21: Message reception and rapid distribution.

[0122] (1) Message reception: The gateway receives IPv6 messages sent by the module through the "operator core network interface" (interfacing with the LTE network);

[0123] (2) Fast filtering: The gateway's packet distributor checks the destination address of the IPv6 packet. If the destination address matches the preset CLAT special prefix (such as 2001:db8:ffff:: / 96), it is determined to be a service packet encapsulated by the module's CLAT and sent to the PLAT module's fast processing link. If it does not match, such as an illegal IPv6 packet, it is handed over to the gateway's regular IPv6 routing stack for processing or directly discarded to avoid network attacks.

[0124] S22: Protocol parsing and IPv4 packet extraction.

[0125] The PLAT module performs protocol parsing on the filtered IPv6 packets to ensure data legitimacy.

[0126] (1) Header verification: Check if the "Next Header" field in the IPv6 header is 4:

[0127] (a) is: confirm that the payload is an IPv4 packet encapsulated in IP-in-IP, strip the IPv6 header (40 bytes), and extract all subsequent data as the original IPv4 packet (including IPv4 header + HTTP payload).

[0128] (b) No: If the message is deemed illegal, it is discarded and logged, for example, “Next Header field is abnormal, expected 4, actual XX”.

[0129] S23: NAT44 session lookup and creation, maintaining connection status through aging time.

[0130] The gateway's NAT table management module uses the "five-tuple" (a unique identifier for the communication link between the module and the server) to find or create NAT mapping rules, thus solving the problem of IPv4 address scarcity.

[0131] The 5-tuple consists of: {Module IPv6 address (2001:db8:100:200::5), Module source port (e.g., 12345), Protocol number (TCP=6), Destination IPv4 address (192.0.2.100), Destination port (8080)}.

[0132] Search and create logic:

[0133] (1) If the mapping entry for the 5-tuple already exists in the NAT table (e.g., {203.0.113.5:56789 →192.0.2.100:8080}, indicating that the gateway uses public port 56789 to map port 12345 of the module): update the "last active timestamp" of the mapping entry and reset it to the current time to avoid the NAT table aging due to timeout (e.g., 180 seconds).

[0134] (2) If it does not exist: the NAT44 engine allocates an idle public port for the gateway, such as 56789, creates a new mapping item, records the correspondence between "module IPv6-gateway public port-target IPv4 service", and sets the aging time.

[0135] S24: IPv4 packet modification and forwarding.

[0136] The NAT44 engine modifies the header information of the original IPv4 packet to ensure that it can be recognized by the public IPv4 network:

[0137] (1) Header Modification. Source IP Address: Modified from the module's virtual IPv4 (e.g., 10.0.0.5, temporarily assigned by the CLAT module) to the gateway's public IPv4 address (203.0.113.5). Source Port: Modified from the module's source port (12345) to the public port (56789) assigned by the gateway. Checksum Update: Due to the change in source IP / port, the IPv4 header checksum is recalculated using the standard CRC algorithm.

[0138] (2) Message forwarding: The modified IPv4 message is sent to the IPv4 routing stack of the gateway and sent from the "Internet interface" connected to the public IPv4 network according to the routing table, and finally reaches the target IPv4 server (such as 192.0.2.100:8080).

[0139] The downlink process refers to the reverse link of "IPv4 server returns response message → gateway PLAT encapsulates into IPv6 → module CLAT decapsulates into IPv4 message → delivered to application", which is also implemented on both the gateway side and the module side.

[0140] The PLAT module on the downlink gateway side primarily encapsulates IPv4 responses into IPv6. After the IPv4 server processes the request, such as returning an HTTP 200 OK response, the response packet first reaches the gateway, where the PLAT module performs the reverse conversion. The specific steps are as follows:

[0141] S31: IPv4 Response Message Reception. The gateway receives the response message from the IPv4 server through the "Internet Interface". The key information includes: destination IP, the gateway's public IPv4 address (203.0.113.5); destination port, the public port assigned by the gateway (56789); source IP / port, 192.0.2.100:8080.

[0142] S32: NAT reverse lookup.

[0143] The NAT table management module uses the "downlink 5-tuple" as the key ({destination public IP=203.0.113.5, destination port=56789, protocol number=6, source IP=192.0.2.100, source port=8080}) to perform a reverse lookup of the NAT table and obtain the corresponding module information: module IPv6 address, 2001:db8:100:200::5; module original source port: 12345.

[0144] S33: IPv4 packet restoration and IPv6 encapsulation.

[0145] (1) Message restoration: The NAT44 engine modifies the "destination IP / port" of the response message to the module's virtual IPv4 (10.0.0.5) and the original port (12345), restoring it to an IPv4 response message that the module can recognize;

[0146] (2) IPv6 Encapsulation: The PLAT module encapsulates the restored IPv4 packet into an IPv6 packet. The header configuration is as follows: IPv6 source address, the gateway's IPv6 address (2001:db8:ffff::1); IPv6 destination address: the module's IPv6 address (2001:db8:100:200::5); Next Header: 4 (identifies the payload as an IPv4 packet). Other fields, including traffic category and hop limit, are configured according to the default rules. The traffic category can be copied from the server's response TOS value, and the hop limit can be set to 64.

[0147] S34: Message sent to module.

[0148] The encapsulated IPv6 response message is routed through the operator's core network and transmitted to the module's LTE network interface via the base station.

[0149] The downlink module's CLAT module primarily handles the decapsulation of IPv6 into IPv4. After receiving the IPv6 response, the CLAT module decapsulates the IPv6 packet and delivers it to the application program. The specific steps are as follows:

[0150] S41: IPv6 response message reception and identification.

[0151] (1) Message reception: The module’s LwIP protocol stack receives IPv6 response messages and delivers them to the CLAT module.

[0152] (2) Validity check: The CLAT module checks the "Next Header" field of the IPv6 header. If it is 4: it is determined to be a CLAT response message returned by the gateway and enters the decapsulation process. If it is any other value: it is handed over to the application's IPv6 Socket.

[0153] S42: Decapsulation and IPv4 packet extraction.

[0154] The CLAT module strips the IPv6 header (40 bytes) and extracts the original IPv4 response message (including the modified IPv4 header and HTTP 200 OK payload).

[0155] S43: The message is delivered to the application. The CLAT module, through a virtual network interface card injection mechanism, simulates the IPv4 reception process of the LwIP protocol stack, and directly delivers the extracted IPv4 response message to the application's IPv4 socket. The application can receive and parse the response without any modification.

[0156] To avoid connection interruptions due to NAT table aging and to ensure service continuity in the event of gateway failure, the module and gateway coordinate through a heartbeat engine to maintain connection and handle failover. The specific steps are as follows:

[0157] S51: Module-side heartbeat transmission.

[0158] (1) Timed trigger: The module has a built-in timer that triggers a heartbeat task every 30 seconds;

[0159] (2) Heartbeat packet structure: The heartbeat packet contains three types of core information:

[0160] (a) Module unique identifier: IMEI number, such as 861234567890123, to ensure that the gateway recognizes the module.

[0161] (b) Current active NAT session ID: such as "12345", which corresponds to the mapping item ID created in S23.

[0162] (c) CRC checksum: Calculated based on IMEI and session ID to ensure the integrity of heartbeat packet data.

[0163] (3) Sending logic: The heartbeat packet is encapsulated into an IPv6 message by the CLAT module, with the destination address being the gateway IPv6:2001:db8:ffff::1, and sent to the gateway.

[0164] S52: Gateway-side heartbeat processing.

[0165] (1) CRC check: After receiving the heartbeat packet, the network heartbeat engine first checks the CRC. If the check fails: the packet is discarded and no reply is given. If the check succeeds: the corresponding NAT session is found according to the module IMEI, the "last active timestamp" of all associated NAT entries is updated and reset to the current time to avoid aging.

[0166] (2) Confirmation response: The gateway returns a “heartbeat confirmation response” containing gateway status information, such as “main gateway is normal”, which is encapsulated as an IPv6 message and sent to the module.

[0167] S53: Module-side heartbeat retry and fault switching.

[0168] (1) Retry mechanism: If the module does not receive a heartbeat confirmation response within 5 seconds, a retry is triggered. For example, it can retry a maximum of 2 times, with a total time of 15 seconds.

[0169] (2) Fault switching: If three consecutive retries fail, the main gateway is determined to be unreachable, and the module automatically switches to the preset backup gateway IPv6 address, such as 2001:db8:ffff::2, and re-initiates the CLAT registration and heartbeat process. The switching time is ≤20 seconds to ensure uninterrupted service.

[0170] The test results of this embodiment show that the method is significantly better than the existing solution in terms of memory usage and latency performance, and fully supports key functions such as ICMP and IP fragmentation, fully meeting the IPv4 service pass-through requirements of resource-constrained IoT modules.

[0171] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An IPv4 service pass-through system for IoT module gateway collaboration, characterized in that, It includes a module side and a gateway side; the module side is used to encapsulate IPv4 packets into IPv6 packets, and to receive IPv6 packets returned by the gateway side and decapsulate them into IPv4 packets. The gateway side is used to receive IPv6 packets sent by the module side, perform decapsulation and NAT address translation, and then forward them to the IPv4 server. It also receives the response packets from the IPv4 server, encapsulates them into IPv6 packets, and sends them back to the module side. The module side includes an application program, a client-side converter module, an LwIP protocol stack, and an LTE network interface; the gateway side includes a dual-interface network interface, a packet distributor, a provider-side converter engine, a NAT44 engine, and a NAT table management module; the dual-interface network interface includes a downlink core network interface for LTE operators and an uplink Internet interface.

2. The system according to claim 1, characterized in that, The application calls the standard IPv4 Socket API to initiate an IPv4 service request, sends an IPv4 packet to the client-side converter module, and obtains a decapsulated IPv4 response packet from the client-side converter module.

3. The system according to claim 1, characterized in that, The client-side converter module is integrated between the application and the LwIP protocol stack, acting as a lightweight hook to intercept packets. During uplink, it encapsulates IPv4 packets into IPv6 packets; during downlink, it strips the IPv6 header to extract the original IPv4 packets and delivers them to the application.

4. The system according to claim 1, characterized in that, The message distributor checks whether the destination address of the IPv6 message matches the preset client-side converter module dedicated prefix; if it matches, it is determined to be a service message encapsulated by the client-side converter module and sent to the provider-side converter engine for processing; if it does not match, it is handed over to the gateway's regular IPv6 routing stack or discarded.

5. The system according to claim 1, characterized in that, The provider-side converter engine supports IP fragmentation and reassembly as well as ICMP protocols. Uplink, it parses the IPv6 header, strips the IPv6 header to extract the original IPv4 packet, and passes it to the NAT44 engine. Downlink, it receives the IPv4 packet restored by the NAT44 engine, encapsulates it into an IPv6 packet, and delivers it to the core network interface.

6. The system according to claim 1, characterized in that, The NAT table management module uses a hash table to store the NAT mapping entries corresponding to the five-tuple "module IPv6 + module source port + protocol number + target IPv4 + target port"; the NAT44 engine realizes dynamic mapping between the module virtual IPv4 and the gateway public IPv4.

7. A method for transparent transmission of IPv4 services in collaboration between IoT module gateways, characterized in that, The system implementation based on any one of claims 1-6 includes an uplink module-side process, an uplink gateway-side process, a downlink gateway-side process, and a downlink module-side process; The uplink module-side process includes the following steps: S11: Intercept the packet and determine the address family; S12: Construct the IPv6 header for encapsulating the original IPv4 packet; S13: Perform zero-copy on the IPv4 packet, reuse the checksum, and encapsulate it into an IPv6 packet; S14: The encapsulated IPv6 packet is delivered to the LwIP protocol stack, converted into a wireless signal through the LTE network interface, and transmitted to the gateway side via the base station; The uplink gateway-side process includes the following steps: S21: The gateway-side network interface receives IPv6 packets. The packet distributor checks whether the destination address matches the client-side converter module's dedicated prefix. If it matches, the packet is sent to the provider-side converter engine. S22: Provide the provider-side converter engine to parse the IPv6 header. If "next header" is 4, then strip the IPv6 header to extract the original IPv4 packet and pass it to the NAT44 engine. S23: The NAT table management module searches for NAT mapping entries based on the five-tuple "module IPv6 + module source port + protocol number + target IPv4 + target port". If it exists, it updates the "last active timestamp"; otherwise, the NAT44 engine allocates a public network free port to create a mapping entry. S24: The NAT44 engine modifies the source IP of the IPv4 packet to the gateway's public IPv4 and the source port to the assigned public port. After recalculating the IPv4 header checksum, it forwards the packet to the target IPv4 server through the Internet interface. The downlink gateway-side process includes the following steps: S31: The gateway receives the response message from the IPv4 server through the Internet interface and hands it over to the NAT44 engine. S32: The NAT table management module uses "gateway public IP + public port + protocol number + server IP + server port" as the key to perform a reverse lookup of the NAT mapping entries and obtain the module's IPv6 and original port. S33: The NAT44 engine modifies the destination IP / port of the response packet to the module's virtual IPv4 and the original port, restoring it to an IPv4 packet that the module can recognize, and then passes it to the provider-side converter engine. S34: The provider-side converter engine encapsulates the restored IPv4 packet into an IPv6 packet ("Next header" is set to 4), and transmits it to the module side via the base station through the operator's core network interface. The downlink module-side process includes: S41: The module-side LTE network interface receives IPv6 packets, delivers them to the LwIP protocol stack, and then the LwIP protocol stack forwards them to the client-side converter module. S42: The client-side converter module checks the "Next Header" field of the IPv6 header. If it is 4, it is determined to be the target service response message. If it is not 4, it is handed over to the application's IPv6 Socket. S43: The client-side converter module strips the IPv6 header and extracts the original IPv4 response message; S44: Through the virtual network interface card injection mechanism, the extracted IPv4 response message is delivered to the application's IPv4 Socket.

8. The method according to claim 7, characterized in that, It also includes a heart rate maintenance and failover process, which includes the following steps: S51: Every 30 seconds, the module side constructs a heartbeat packet containing IMEI, NAT session ID, and CRC checksum, which is then encapsulated into an IPv6 message by the client-side converter module and sent to the gateway side. S52: The gateway-side heartbeat engine receives heartbeat packets. If the CRC verification passes, it updates the timestamp of the corresponding NAT table entry and returns an acknowledgment response. If the verification fails, it discards the packet. S53: If the module does not receive a confirmation response within 5 seconds, a retry will be triggered. If multiple retry attempts fail, the system will automatically switch to the backup gateway and re-initiate the client-side converter module registration and heartbeat process.

9. The method according to claim 7, characterized in that, Step S12 includes: copying the TOS field value of the original IPv4 packet to the "Traffic Category" field of the IPv6 header; setting the "Flow Label" field to 0 when QoS flow management is not enabled; setting the "Payload Length" field to the total length of the original IPv4 packet; setting the "Hop Limit" field to 64; setting the "Source Address" to the module's global unicast IPv6 address; and constructing the "Destination Address" according to "[Gateway Client-Side Converter Module Prefix]::ffff:[Destination IPv4 Address]".

10. The method according to claim 7, characterized in that, The zero-copy method involves directly associating the memory address of the original IPv4 packet with the newly constructed IPv6 header using a memory pointer. The multiplexing of the checksum includes: (1) IPv4 checksum: The checksum of the original IPv4 packet is used directly. This checksum has been calculated by the application or the LwIP upper layer. (2) IPv6 checksum: Only the newly constructed IPv6 header checksum is calculated, which is generated based on the IPv6 header field using the standard CRC32 algorithm; (3) TCP / UDP checksum: Taking advantage of the feature of "IPv6 destination address embedded in original IPv4 address", the result of TCP / UDP checksum calculation based on original IPv4 pseudo-header is still valid and the original value is directly used.

Images