Body area network networking method fusing multiple physical networks

Abstract

The invention provides a body area network networking method fusing multiple physical networks. The method comprises the following steps: 1, performing network initialization: controlling discovery, configuration and management of network equipment through an intelligent terminal SDN (Software Defined Network); 2, sending data: coordinating communication of different types of equipment by using an IP-based network protocol stack; and step 3, data receiving: de-encapsulating the received IP data packet through a network stack of the Linux kernel and transmitting the de-encapsulated IP data packet to target equipment. According to the invention, a unified IP network stack is introduced on body area network controller software. The existing network capability of Linux is utilized, and the method is compatible with the existing traditional network equipment at low cost.

Description

Technical Field

[0001] The present application relates to the field of network communication technology, and in particular to a body area network networking method integrating multiple physical networks. Background Art

[0002] The Body Area Network environment contains multiple types of nodes. Specifically, they include: controller, wearable device, and server; among them, the controller is a lightweight host carried by an individual, which has certain communication and computing capabilities. Wearable devices are physical information system terminals carried by individuals, which have specific physical world interaction capabilities (such as environmental sensing, device control), low power consumption and limited communication capabilities, and may have computing capabilities. The server is a central host independently deployed in the environment, with strong communication and computing capabilities, including information aggregation and storage capabilities.

[0003] The body area network is a heterogeneous network. Due to the different types of devices, different communication and computing capabilities, and different operational capabilities of the physical world, the interconnection between devices also has complex networking requirements. For example, practical applications include (but are not limited to) the following scenarios: 1. Under the same controller, the interconnection between various wearable devices: the intelligent temperature sensor reports the ambient temperature to the intelligent heating device to achieve automatic constant temperature. 2. Server to controller: The control center issues a temperature control strategy. 3. Controller to controller: The controllers exchange their respective ambient temperatures to provide more information to the temperature control algorithm.

[0004] In current body area networks, devices usually communicate based on different physical channels (such as Bluetooth, Zigbee, Wi-Fi, Ethernet, etc.). Each physical channel usually corresponds to a specific communication protocol stack, which has different implementations and communication modes and lacks a unified communication interface. This leads to some technical problems that need to be improved, including:

[0005] Technical issue 1: The network capabilities of devices vary, making it difficult to achieve full compatibility and a unified networking model.

[0006] Due to the physical form of the device, wearable devices often only have specific communication capabilities. For example, in order to ensure the service life, temperature sensors powered by button batteries often only use the low-power Bluetooth Low Energy protocol, encode temperature information in a specific format, and broadcast the message regularly. On the one hand, the message does not have semantics such as IP address and port number, is not compatible with various devices in the existing network, and cannot be directly transmitted on the IP network. On the other hand, the physical layer of the message is often not compatible with protocols such as Ethernet / WLAN, resulting in limited transmission distance and transmission quality.

[0007] Technical Issue 2: Hardware-bound network architecture brings additional implementation costs and supply chain risks

[0008] Current technologies such as Thread and Zigbee implement IP layer protocols such as 6LoWPAN. This allows wearable devices to implement IPv6 communication based on the low-power IEEE 802.15.4 physical layer through BorderRouter node conversion. However, the above capabilities are deeply bound to specific hardware chips, making it difficult for controllers to enable flexible software-based networking modes, increasing supply chain costs and risks.

[0009] The above problems lead to the following impacts on current technology:

[0010] Protocol incompatibility: For example, Bluetooth low energy devices usually use non-IP protocol stacks for communication, while Ethernet or Wi-Fi devices use traditional IP protocol stacks. Due to the lack of a unified protocol standard, devices with different protocols cannot be directly interconnected, resulting in communication isolation.

[0011] Difficulty in device intercommunication: Devices on different physical channels cannot work together easily. Developers need to design different communication interfaces and adaptation layers for each protocol, which increases the complexity of the system.

[0012] Poor scalability: With the emergence of new communication technologies and new devices, the original system is often unable to quickly adapt to and support these new devices, resulting in difficulties in system updates.

[0013] Therefore, how to abstract these heterogeneous physical channels into a unified IP network element and achieve transparent interconnection across protocols has become the key to solving these problems. Summary of the invention

[0014] The present application provides a body area network networking method that integrates multiple physical networks, which can be used to solve the technical problem that the system cannot quickly adapt to and support new devices.

[0015] The present application provides a body area network networking method integrating multiple physical networks, the method comprising:

[0016] Step 1: Initialize the network: discover, configure and manage network devices through intelligent terminal SDN control;

[0017] Step 2: Send data: Use IP-based network protocol stack to coordinate the communication of different types of devices;

[0018] Step 3, data reception: The received IP data packet is decapsulated and delivered to the target device through the Linux kernel's network stack.

[0019] Furthermore, step 1, network initialization, includes:

[0020] Step 11, controller startup and application loading: When the controller system is powered on, the control application is first loaded through the operating system of the intelligent terminal; the application includes a user space application for body area network management and an intelligent terminal SDN layer based on the SDN framework; the SDN layer is used to dynamically configure network hardware and realize the automatic execution of network policies;

[0021] Step 12, dynamic configuration and policy distribution: The intelligent terminal SDN initializes the network topology and protocol stack based on a configuration file containing specific hardware adaptation and network configuration rules; the content of the configuration file includes the supported hardware types, required communication protocols, network security rules and connection policies; the system generates network connection policies by reading this information;

[0022] Step 13: Hardware event monitoring and device discovery: The intelligent terminal SDN continuously monitors hardware events in the system through the Netlink protocol provided by the Linux kernel;

[0023] Step 14, configuration of supported and unsupported hardware: If the newly connected hardware device has been identified and supported in the Linux kernel, SDN will automatically configure the hardware to comply with the network networking strategy, including enabling the corresponding physical interface, configuring the necessary network security strategy, and adjusting the IP layer parameters of the network stack; if the hardware is not directly supported by the Linux kernel, SDN directly controls the hardware registers through the bus interface, sets the hardware to an available state, and creates a software interface through the TUN virtual network interface to enable it to participate in the IP network;

[0024] Step 15, hardware offline processing: When the hardware device is disconnected from the network, the intelligent terminal SDN will reversely deregister the hardware interface through the predefined networking policy and clean up the corresponding kernel resources.

[0025] Furthermore, step 2, sending data, includes:

[0026] Step 21, external events trigger data transmission: the body area network control logic in the smart terminal application detects the need to send data, and initiates a communication request with the target device according to the application requirements;

[0027] Step 22, BSD socket API and communication request: The application uses the standard BSD socket API interface to initiate a network request; the network data packet is passed down through the application layer, and a connection request is sent to the specified IP address; the data encapsulation and transmission protocol selection are managed by the network stack of the operating system kernel;

[0028] Step 23, Linux kernel protocol stack processing: Once the request reaches the network stack, the four-layer network protocol stack of the Linux kernel includes the transport layer protocol; automatically handles the transmission control of the data packet, including data retransmission, connection management and flow control; the Netfilter module ensures that the data packet complies with the predetermined security policy to prevent potential security threats;

[0029] Step 24, data distribution and routing: After being processed by the transport layer, the data packet is transmitted to the three-layer network stack. The Linux kernel determines the final destination of the data packet based on the pre-configured IP network stack and routing rules; if the target is a supported hardware device, the kernel will search for the corresponding peripheral through the hardware driver and transmit the data packet.

[0030] Step 25, processing of unsupported hardware: For hardware that is not supported by the kernel driver, the data packet is forwarded to the SDN module through the TUN interface; the SDN reads the hardware status and converts the IP data packet into a data format suitable for non-IP devices through the protocol adapter; and the hardware communication is directly controlled through the hardware registers.

[0031] Furthermore, step 3, data reception, includes:

[0032] Step 31, processing of received data packets: The received IP data packets first enter the Linux kernel through the virtual TUN interface; the kernel checks the destination address and protocol type of the data packet. If the data packet comes from an IP-supported device, the kernel directly decapsulates it and passes it to the corresponding upper-layer application; if the data packet comes from a non-IP device, the Linux kernel forwards the data to the SDN module;

[0033] Step 32, protocol adaptation and decapsulation: SDN decapsulates data packets from non-IP protocol devices into a format that complies with the IP protocol through a protocol adapter. The protocol adapter is not only responsible for decapsulation, but also performs protocol conversion according to the communication requirements of the target device to ensure that the data can be transmitted through a standard IP network.

[0034] Step 33, routing and data forwarding: After decapsulation, the data packet is routed through the three-layer network stack of the Linux kernel, and the data transmission path is determined according to the network topology; the kernel automatically selects the optimal path and forwards it to the target device according to the address.

[0035] Furthermore, all non-IP protocols use special protocol adapters to encapsulate the communication content into IP data packets and participate in the IP network for data transmission;

[0036] The protocol adapter is used for protocol encapsulation and decapsulation; for data from non-IP protocol devices, the adapter first decapsulates it, extracts the payload from the non-IP protocol, and re-encapsulates it according to the IP protocol to generate a standard IP data packet.

[0037] Furthermore, the protocol adapter is specifically used for:

[0038] Receiving non-IP protocol data: The protocol adapter first receives the original data from the device through the physical layer interface;

[0039] Data decapsulation: The protocol adapter decodes the received non-IP data packets and converts them into valid data in the protocol stack; the process involves protocol mapping, which converts the data structure of the non-IP protocol into a data structure that conforms to the IP protocol;

[0040] Protocol conversion and encapsulation: According to the type of received data, the adapter performs protocol conversion on the data;

[0041] Interact with the Linux kernel network stack: The encapsulated data packet is passed to the Linux kernel network stack through the virtual network interface; the Linux kernel sends the data packet to the correct destination device based on the target IP address.

[0042] Technical effect 1: Transmission transparency: The upper-layer intelligent terminal application is transparent and imperceptible, and the bottom layer realizes adaptive transmission.

[0043] The present invention introduces a unified IP network stack on the body area network controller software. It uses the existing network capabilities of Linux and is compatible with existing traditional network devices at low cost. For heterogeneous networking devices with unconventional network interfaces, the Netlink protocol and TUN capabilities of Linux are used to realize dynamic discovery and configuration of devices, as well as IP-free upper-layer terminal applications for heterogeneous devices.

[0044] Technical effect 2: Link modularity: The underlying physical chip can be replaced freely to avoid vendor lock-in.

[0045] The present invention introduces a programmable physical layer on the body area network controller hardware, so that the body area network controller can access the physical link provided by the hardware without perceiving the specific hardware. Generally, a heterogeneous network SoC includes a bus (such as I2C, USB), an MCU, a MAC, and an RF. The present invention introduces custom forwarding software on the MCU of the physical layer device. For example, in the scenario of sending a message, the original message of the body area network controller is transmitted to the MCU via the bus, and the forwarding software in the MCU converts the message into an access to the chip's built-in MAC, and then sends it to the physical channel through the RF layer. Therefore, the selection of heterogeneous networking hardware for the body area network controller is highly flexible: there are a large number of chip types to choose from for the same physical layer protocol, and different chips can be uniformly connected to the body area network controller by simply reprogramming the MCU, and neither the upper-layer application nor the controller software needs to be modified. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 It is an architecture diagram of the prior art;

[0047] Figure 2 A structural diagram provided for an embodiment of the present application.

[0048] Figure 3 A flow chart of the method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0050] The following first introduces the embodiments of the present application in conjunction with the accompanying drawings.

[0051] Step 1: Initialize the network: Network initialization is the starting step of the entire heterogeneous domain network method, and the discovery, configuration and management of network devices are controlled by the intelligent terminal SDN. The following are the detailed steps:

[0052] Step 11, controller startup and application loading: When the controller system is powered on, the control application is first loaded through the operating system of the smart terminal; the application includes a user space application for body area network management and an SDN (software defined network) framework-based smart terminal SDN layer; the SDN layer is used to dynamically configure network hardware and realize the automated execution of network policies.

[0053] Step 12, dynamic configuration and policy distribution: The intelligent terminal SDN initializes the network topology and protocol stack based on a configuration file containing specific hardware adaptation and network configuration rules; the content of the configuration file includes the supported hardware types, required communication protocols, network security rules and connection policies; the system generates network connection policies by reading this information;

[0054] Step 13, hardware event monitoring and device discovery: The intelligent terminal SDN continuously monitors hardware events in the system through the Netlink protocol provided by the Linux kernel; this means that whenever a new network device (such as a hardware device that supports different physical layer protocols) is connected or the current device status changes, the SDN can receive information immediately. This process ensures that the system has real-time perception of the network hardware and can automatically configure the network according to hardware changes.

[0055] Step 14, configuration of supported and unsupported hardware: If the newly connected hardware devices have been identified and supported in the Linux kernel, SDN will automatically configure these hardware to comply with the network networking strategy, including enabling the corresponding physical interface, configuring the necessary network security strategy (such as Netfilter), and adjusting the IP layer parameters of the network stack; if the hardware is not directly supported by the Linux kernel, SDN directly controls the hardware registers through the bus interface, sets the hardware to an available state, and creates a software interface through the TUN virtual network interface to enable it to participate in the IP network;

[0056] Step 15, hardware offline processing: When the hardware device is disconnected from the network, the intelligent terminal SDN will reversely deregister the hardware interface through the predefined networking policy and clean up the corresponding kernel resources (such as IP routing table and virtual network configuration) to ensure that the device offline does not affect the stability of the network.

[0057] Step 2: Send data: Use IP-based network protocol stack to coordinate the communication of different types of devices;

[0058] In the process of data transmission, the IP-based network protocol stack is innovatively used to coordinate the communication of different types of devices. The steps of data transmission are as follows:

[0059] Step 21, external event triggers data transmission: the data transmission process is usually triggered by an external event, for example, the body area network control logic in the smart terminal application detects that data needs to be sent (such as environmental sensors collect data), and initiates a communication request with the target device (such as a wearable device or a server) according to the application requirements;

[0060] Step 22, BSD socket API and communication request: The application uses the standard BSD socket API interface to initiate a network request; the network data packet is passed down through the application layer, and a connection request is sent to the specified IP address; the data encapsulation and transmission protocol selection are managed by the network stack of the operating system kernel, avoiding complex operations on the application;

[0061] Step 23, Linux kernel protocol stack processing: Once the request reaches the network stack, the four-layer network protocol stack of the Linux kernel includes transport layer protocols such as TCP and UDP; automatically handles the transmission control of data packets, including data retransmission, connection management and flow control; the Netfilter module ensures that the data packets comply with the predetermined security policy to prevent potential security threats;

[0062] Step 24, data distribution and routing: After being processed by the transport layer, the data packet is transmitted to the three-layer network stack. The Linux kernel determines the final destination of the data packet based on the pre-configured IP network stack and routing rules; if the target is a supported hardware device, the kernel will search for the corresponding peripheral through the hardware driver and transmit the data packet.

[0063] Step 25, processing of unsupported hardware: For hardware that is not supported by the kernel driver (such as devices based on the Zigbee or Thread protocol), the data packet is forwarded to the SDN module through the TUN interface; the SDN reads the status of the hardware and converts the IP data packet into a data format suitable for non-IP devices through the protocol adapter; the hardware communication is directly controlled through the hardware registers to ensure that even hardware that is not directly supported can be seamlessly connected to the IP network.

[0064] Step 3, data reception: Data reception is the opposite of sending. It is to decapsulate the received IP data packet through the Linux kernel network stack and pass it to the target device. The specific process is as follows:

[0065] Step 31, processing of received data packets: The received IP data packets first enter the Linux kernel through the virtual TUN interface. The kernel checks the destination address and protocol type of the data packet. If the data packet comes from an IP-supported device, the kernel directly decapsulates it and passes it to the corresponding upper-layer application; if the data packet comes from a non-IP device, the Linux kernel forwards the data to the SDN module;

[0066] Step 32, protocol adaptation and decapsulation: SDN decapsulates data packets from non-IP protocol devices into a format that complies with the IP protocol through a protocol adapter; the protocol adapter is not only responsible for decapsulation, but also performs protocol conversion according to the communication requirements of the target device (for example, Bluetooth Low Energy data is converted to UDP or TCP protocol) to ensure that the data can be transmitted through a standard IP network.

[0067] Step 33, routing and data forwarding: After decapsulation, the data packet is routed through the three-layer network stack of the Linux kernel, and the data transmission path is determined according to the network topology; the kernel automatically selects the optimal path and forwards it to the target device according to the address.

[0068] The present invention achieves the goal of abstracting heterogeneous, non-IP protocol devices into IP network elements through the following key steps and technical architecture, thereby breaking through the protocol compatibility problem and realizing seamless interconnection across protocols and devices:

[0069] 1. Abstract layer design of physical channels: The core of the present invention is to unify all physical layer channels and protocol stacks through an "abstract layer". In this abstract layer, instead of directly facing specific physical protocols (such as Bluetooth, Zigbee, Wi-Fi, etc.), these devices are converted into standard IP devices through adapters, so that they can communicate seamlessly in the IP network.

[0070] Specifically, all non-IP protocols (such as Bluetooth Low Energy, Zigbee, Thread, etc.) encapsulate the communication content into IP data packets through special protocol adapters, so that these devices behave like IP devices and can participate in IP networks for data transmission.

[0071] 2. Implementation of protocol adapter: The protocol adapter of the present invention is an innovative network protocol conversion mechanism, which aims to convert the data of non-IP protocol (such as Bluetooth Low Energy, Zigbee, Thread, etc.) devices into standard IP data packets. In this way, even devices using different physical layer protocols (such as low-power Bluetooth sensors or Zigbee devices) can participate in the unified IP network like traditional IP devices and achieve seamless communication with other IP devices.

[0072] The protocol adapter is used for protocol encapsulation and decapsulation; for data from non-IP protocol devices, the adapter first decapsulates, extracts the payload from the non-IP protocol (such as Bluetooth low energy data packets), and re-encapsulates it according to the IP protocol (such as UDP or TCP) to generate a standard IP data packet. The specific process is as follows:

[0073] Receiving non-IP protocol data: The protocol adapter first receives raw data from the device (such as Bluetooth, Zigbee, Thread, etc.) through the physical layer interface; these data usually do not have the identification information of the IP layer and may also use different communication protocol formats, such as low-power broadcast protocols.

[0074] Data decapsulation: The protocol adapter decodes the received non-IP data packets and converts them into valid data in the protocol stack; for example, extracting and encapsulating data in the Bluetooth low energy protocol (such as temperature sensor data) into IP data packet format. This process involves protocol mapping, which is to convert the data structure of the non-IP protocol into a data structure that conforms to the IP protocol;

[0075] Protocol conversion and encapsulation: Depending on the type of data received, the adapter performs protocol conversion on the data. For example, if the original data is Zigbee protocol, the adapter will encapsulate its data packet into a UDP data packet and attach the destination IP address and port number so that it can be forwarded through a traditional IP network.

[0076] Interact with the Linux kernel network stack: The encapsulated data packets are passed to the Linux kernel network stack through a virtual network interface (such as the TUN interface); the Linux kernel sends the data packets to the correct destination device based on the target IP address. In this way, the protocol adapter can not only achieve protocol conversion, but also ensure that data can be seamlessly transmitted through the existing network infrastructure.

[0077] The design innovation of the protocol adapter lies in its versatility and flexibility. It can support multiple physical protocols and communicate through a unified IP network. Its implementation principle relies on the encapsulation and decapsulation mechanism of the network protocol stack. By implementing the conversion rules for different physical protocols in the adapter, the interconnection between devices is ensured.

[0078] 3. Network layer virtualization and logical abstraction: In addition to the adaptation of the physical layer, the present invention also implements virtualization and abstraction at the network layer. In traditional networks, different devices communicate based on physical layer protocols. However, the present invention uses virtualization and abstraction of the physical layer to enable the body area network controller to support the access of devices with multiple physical layer protocols without being aware of the hardware. This design eliminates the hardware restrictions on the selection of network protocols, thereby greatly improving the flexibility and scalability of the system.

[0079] Virtual Network Interface (TUN Interface): In order to solve the protocol incompatibility problem between the device and the physical network, the present invention realizes virtualization through the TUN interface. The TUN interface is a virtual network device used to connect non-IP devices (such as Zigbee, Bluetooth and other devices) to the IP network. After the data of the device is encapsulated into an IP data packet by the protocol adapter, it will be transmitted through the TUN interface. The TUN interface acts as a bridge to ensure that devices with different physical protocols can communicate in a unified IP network.

[0080] Dynamic hardware configuration and protocol adaptation: During the physical layer virtualization process, the body area network controller does not need to be aware of the specific hardware implementation. For example, the controller can support multiple physical layer protocols (such as Bluetooth, Zigbee, Wi-Fi, etc.). When a new device is added, the controller will dynamically configure it through the MCU and protocol adapter. The MCU supports different physical layer protocols through programming. Whether it is the RF module, MAC layer or other hardware components, the controller can flexibly select the appropriate hardware and protocol stack.

[0081] Hardware-unaware operation: Through virtualization of the physical layer, the controller can access the device without caring about the hardware. The controller only needs to interact with the device through the virtual network interface without knowing which physical layer protocol the device uses. In this way, the body area network controller can easily support a variety of different hardware devices, avoiding the binding and restrictions of hardware vendors.

[0082] 4. Linux kernel and SDN support: In the present invention, the Linux kernel and software defined network (SDN) jointly undertake the control and configuration tasks. The Linux kernel can efficiently manage these non-IP devices encapsulated into IP data packets through its powerful network stack and kernel module support.

[0083] Netlink protocol of Linux kernel: Through the Netlink protocol of Linux, the present invention can discover non-IP devices in the network in real time and configure the devices according to the preset strategy. This enables the system to dynamically adapt to hardware changes and automatically identify and manage devices connected to the network.

[0084] Introduction of SDN controller: The SDN controller is responsible for dynamically adjusting network routing and policies to ensure the transmission efficiency and security of the IP network. The combination of SDN and the Linux kernel further enhances the configurability and flexibility of the system, allowing the network to adapt to the ever-changing hardware environment.

[0085] The above-described embodiments of the present application do not constitute a limitation on the protection scope of the present application.

Claims

1. A method for establishing a body area network integrating multiple physical networks, characterized in that: The method comprises: Step 1: Initialize the network: discover, configure and manage network devices through intelligent terminal SDN control; Step 2: Send data: Use IP-based network protocol stack to coordinate the communication of different types of devices; Step 3, data reception: The received IP data packet is decapsulated and delivered to the target device through the Linux kernel's network stack.

2. The method according to claim 1, characterized in that Step 1: Initialize the network, including: Step 11, controller startup and application loading: When the controller system is powered on, the control application is first loaded through the operating system of the intelligent terminal; the application includes a user space application for body area network management and an intelligent terminal SDN layer based on the SDN framework; the SDN layer is used to dynamically configure network hardware and realize the automatic execution of network policies; Step 12, dynamic configuration and policy distribution: The intelligent terminal SDN initializes the network topology and protocol stack based on a configuration file containing specific hardware adaptation and network configuration rules; the content of the configuration file includes the supported hardware types, required communication protocols, network security rules and connection policies; the system generates network connection policies by reading this information; Step 13: Hardware event monitoring and device discovery: The intelligent terminal SDN continuously monitors hardware events in the system through the Netlink protocol provided by the Linux kernel; Step 14, configuration of supported and unsupported hardware: If the newly connected hardware device has been identified and supported in the Linux kernel, SDN will automatically configure the hardware to comply with the network networking strategy, including enabling the corresponding physical interface, configuring the necessary network security strategy, and adjusting the IP layer parameters of the network stack; if the hardware is not directly supported by the Linux kernel, SDN directly controls the hardware registers through the bus interface, sets the hardware to an available state, and creates a software interface through the TUN virtual network interface to enable it to participate in the IP network; Step 15, hardware offline processing: When the hardware device is disconnected from the network, the intelligent terminal SDN will reversely deregister the hardware interface through the predefined networking policy and clean up the corresponding kernel resources.

3. The method according to claim 1, characterized in that Step 2, sending data, includes: Step 21, external events trigger data transmission: the body area network control logic in the smart terminal application detects the need to send data, and initiates a communication request with the target device according to the application requirements; Step 22, BSD socket API and communication request: The application uses the standard BSD socket API interface to initiate a network request; the network data packet is passed down through the application layer, and a connection request is sent to the specified IP address; the data encapsulation and transmission protocol selection are managed by the network stack of the operating system kernel; Step 23, Linux kernel protocol stack processing: Once the request reaches the network stack, the four-layer network protocol stack of the Linux kernel includes the transport layer protocol; automatically handles the transmission control of the data packet, including data retransmission, connection management and flow control; the Netfilter module ensures that the data packet complies with the predetermined security policy to prevent potential security threats; Step 24, data distribution and routing: After being processed by the transport layer, the data packet is transmitted to the three-layer network stack. The Linux kernel determines the final destination of the data packet based on the pre-configured IP network stack and routing rules; if the target is a supported hardware device, the kernel will search for the corresponding peripheral through the hardware driver and transmit the data packet. Step 25, processing of unsupported hardware: For hardware that is not supported by the kernel driver, the data packet is forwarded to the SDN module through the TUN interface; the SDN reads the hardware status and converts the IP data packet into a data format suitable for non-IP devices through the protocol adapter; and the hardware communication is directly controlled through the hardware registers.

4. The method according to claim 1, characterized in that: Step 3, data reception, includes: Step 31, processing of received data packets: The received IP data packets first enter the Linux kernel through the virtual TUN interface; the kernel checks the destination address and protocol type of the data packet. If the data packet comes from an IP-supported device, the kernel directly decapsulates it and passes it to the corresponding upper-layer application; if the data packet comes from a non-IP device, the Linux kernel forwards the data to the SDN module; Step 32, protocol adaptation and decapsulation: SDN decapsulates data packets from non-IP protocol devices into a format that complies with the IP protocol through a protocol adapter. The protocol adapter is not only responsible for decapsulation, but also performs protocol conversion according to the communication requirements of the target device to ensure that the data can be transmitted through a standard IP network. Step 33, routing and data forwarding: After decapsulation, the data packet is routed through the three-layer network stack of the Linux kernel, and the data transmission path is determined according to the network topology; the kernel automatically selects the optimal path and forwards it to the target device according to the address.

5. The method according to claim 1, characterized in that All non-IP protocols use special protocol adapters to encapsulate the communication content into IP data packets and participate in IP networks for data transmission; The protocol adapter is used for protocol encapsulation and decapsulation; For data from non-IP protocol devices, the adapter first decapsulates it, extracts the payload from the non-IP protocol, and recapsulates it according to the IP protocol to generate a standard IP data packet.

6. The method according to claim 5, characterized in that The protocol adapter is specifically used for: Receiving non-IP protocol data: The protocol adapter first receives the original data from the device through the physical layer interface; Data decapsulation: The protocol adapter decodes the received non-IP data packets and converts them into valid data in the protocol stack; the process involves protocol mapping, which converts the data structure of the non-IP protocol into a data structure that conforms to the IP protocol; Protocol conversion and encapsulation: According to the type of received data, the adapter performs protocol conversion on the data; Interact with the Linux kernel network stack: The encapsulated data packets are passed to the Linux kernel network stack through the virtual network interface; The Linux kernel sends the data packet to the correct destination device based on the destination IP address.

Images