Starburst SLE-based IP bridging method and system

CN122601416APending Publication Date: 2026-08-18LIERDA SCI & TECH GRP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610909004.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-23
Publication Date
2026-08-18

AI Technical Summary

Technical Problem

但目前业界尚未形成针对星闪SLE特性优化的IP化桥接方案,尤其缺少多设备并发连接下的统一接口管理机制、以及SLE与WiFi网络的二层透明桥接能力,无法充分发挥星闪SLE的技术优势,限制了其在IP化物联网场景中的应用落地

Benefits of technology

[0039] 1. This invention leverages the physical layer technology advantages of StarSpark SLE to significantly improve transmission performance and reduce communication latency compared to traditional low-power wireless IP solutions. It meets the IP communication requirements of high-real-time IoT services, breaking through the performance bottlenecks of traditional low-power wireless IP solutions. Furthermore, by creating a unique SLE virtual network interface within the IP protocol stack and maintaining the mapping relationship between terminal MAC addresses and connection identifiers using a connection management list, it enables bidirectional data transmission from a single interface to multiple SLE connections. This eliminates the need to create independent virtual network interfaces for each SLE connection, greatly simplifying the interface management logic of the protocol stack, reducing system resource overhead and scheduling complexity in scenarios with concurrent access from multiple devices, and improving the processing efficiency of uplink data aggregation and downlink data distribution.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122601416A_ABST
    Figure CN122601416A_ABST
Patent Text Reader

Abstract

The application discloses an IP bridging method and system based on star flash SLE, belongs to the technical field of short-distance wireless communication and Internet of Things, and aims at the problems of complex multi-connection management, high deployment cost of heterogeneous network intercommunication of the existing low-power wireless IP scheme.The center device is configured as an access point role, the mapping relationship between terminal MAC addresses and connection identifiers is maintained through a connection management list, a unique SLE virtual network interface is created in an IP protocol stack, bidirectional data forwarding of a single interface to multiple SLE connections is realized, a data link layer bridging channel of SLE and WiFi can be further established, and two-layer transparent forwarding is realized.The application can simplify multi-device access management logic, reduce networking complexity, and improve the efficiency and compatibility of low-power terminal IP access.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of short-range wireless communication technology, and in particular to an IP-based bridging method and system based on Star Flash SLE. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) industry, a massive number of low-power wireless terminal devices require access to IP networks and end-to-end data interaction. Currently, the industry has developed various IP-based adaptation solutions for traditional low-power wireless protocols to enable IP network access for low-power devices, such as:

[0003] 6LoWPAN technology defines an IPv6 adaptation layer on top of the IEEE 802.15.4 physical layer protocol. Through packet header compression and fragmentation reassembly mechanisms, it enables low-rate, short-frame-length wireless links to carry IPv6 data packets. It is currently widely used in IoT protocols such as Zigbee and Thread. However, the 802.15.4 physical layer, on which this technology relies, has a relatively low rate limit, making it difficult to meet the requirements of high-throughput and low-latency scenarios.

[0004] IPv6 over BLE technology, based on the RFC 7668 standard, builds a 6LoWPAN adaptation layer on top of the L2CAP layer of the BLE protocol, enabling BLE devices to participate in network communication as independent IP nodes. A typical implementation is the 6LoWPAN module in the Linux kernel, which can create an independent virtual network interface for each BLE connection. However, this solution's architecture of one virtual interface per connection leads to complex interface management and high system scheduling overhead in scenarios with multiple devices accessing concurrently. At the same time, BLE itself has limited air interface speed and latency performance, making it unsuitable for more demanding real-time communication scenarios.

[0005] Heterogeneous network interconnection solutions, such as those for existing low-power wireless networks and WiFi networks, typically employ Layer 3 routing or application-layer gateways for protocol conversion. These solutions require address mapping and route calculation at the network layer, or data parsing and forwarding at the application layer. Such solutions suffer from high forwarding latency, high deployment complexity, and cannot achieve Layer 2 transparent communication between the two networks, preventing direct data interaction between terminal devices on the same Ethernet segment.

[0006] Meanwhile, NearLink SLE, as a next-generation short-range wireless communication technology, boasts an air interface rate of up to 12Mbps, communication latency of less than 3ms, and stronger anti-interference capabilities, giving it a significant performance advantage over traditional BLE. However, the industry currently lacks an IP-based bridging solution optimized for the characteristics of NearLink SLE, particularly lacking a unified interface management mechanism for concurrent multi-device connections and Layer 2 transparent bridging capabilities between SLE and WiFi networks. This hinders the full realization of NearLink SLE's technological advantages and limits its application in IP-based IoT scenarios.

[0007] Therefore, there is an urgent need for an IP-based bridging solution that adapts to the SLE characteristics of StarFlash, enabling efficient concurrent access for multiple devices and low-complexity Layer 2 interoperability with WiFi networks, thus meeting the IP-based access needs of low-power devices in scenarios such as smart homes and industrial IoT. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides an IP-based bridging method and system based on StarSpark SLE, aiming to solve the aforementioned problems.

[0009] On the one hand, this application provides an IP-based bridging method based on StarSpark SLE, applied to a central device equipped with a StarSpark SLE wireless interface, including the following steps:

[0010] Configure the central device as an access point, initialize and maintain the connection management list, which is used to store the MAC address, connection identifier and link status of the terminal device corresponding to multiple SLE wireless connections;

[0011] The central device establishes SLE wireless connections with multiple terminal devices to form a one-to-many star network topology, and stores the corresponding parameters of each connection in the connection management list.

[0012] A unique SLE virtual network interface is created in the IP network protocol stack of the central device and registered as a standard network device. By querying the correspondence between the connection identifier and the MAC address of the terminal device in the connection management list, the correspondence is used to realize bidirectional data forwarding between multiple SLE connections and a single interface.

[0013] When an uplink data frame is received from any SLE wireless connection, the data source is identified according to the corresponding connection identifier, the data frame payload is extracted and converted into a network data packet that can be recognized by the IP network protocol stack, and submitted to the SLE virtual network interface for network layer processing.

[0014] When the IP network protocol stack sends downlink data packets through the SLE virtual network interface, it queries the connection management list based on the target MAC address of the data packet, matches the corresponding connection identifier, and sends the payload to the target terminal device through the corresponding SLE wireless connection.

[0015] By maintaining the mapping relationship between terminal MAC addresses and connection identifiers through a connection management list, a unique SLE virtual network interface is created in the IP protocol stack, enabling bidirectional data forwarding from a single interface to multiple SLE connections. Furthermore, a data link layer bridging channel between SLE and WiFi can be established, achieving Layer 2 transparent forwarding. This invention simplifies the management logic for multi-device access, reduces networking complexity, and improves the efficiency and compatibility of IP-based access for low-power terminals.

[0016] Furthermore, the specific steps for establishing SLE wireless connections between the central device and multiple terminal devices are as follows:

[0017] The central device initiates an SLE scanning process, detects SLE broadcast packets carrying a preset network identifier, and initiates connection requests to terminal devices that match the preset network identifier to establish an SLE wireless connection; wherein, the preset network identifier is a specific service identifier or a custom network identifier field embedded in the SLE broadcast packet.

[0018] Furthermore, the central device also has a WiFi wireless interface;

[0019] The method further includes:

[0020] A data link layer bridging channel is established between the SLE virtual network interface and the WiFi wireless interface; the bridging channel is used to realize transparent forwarding of data packets between the SLE network and the WiFi network, and the forwarding process does not go through the network layer processing of the IP network protocol stack.

[0021] Furthermore, the link state control logic of the SLE virtual network interface is as follows:

[0022] When any SLE wireless connection is successfully established, the link status of the SLE virtual network interface is set to active.

[0023] The link state of the SLE virtual network interface is set to inactive only when all SLE wireless connections are disconnected.

[0024] Furthermore, the connection management list stores information on a preset number of concurrent SLE wireless connections; the information for each connection also includes the PHY rate parameters and modulation and coding scheme configuration parameters corresponding to the link; during the process of establishing an SLE wireless connection with the terminal device, the PHY parameters of the link are configured according to a preset application scenario.

[0025] Furthermore, the bidirectional forwarding process of the data link layer bridging channel specifically includes:

[0026] SLE forwarding to WiFi: When the SLE virtual network interface receives an uplink data frame from the corresponding SLE wireless connection, it determines the target MAC address of the data frame. If the target MAC address does not belong to the central device itself, the data frame is directly forwarded to the WiFi wireless interface through the bridging channel. If the target MAC address belongs to the central device itself, the data frame is submitted to the IP network protocol stack for processing.

[0027] WiFi forwarding to SLE: When the WiFi wireless interface receives a data packet from an external network, it determines the destination MAC address of the data packet. If the destination MAC address belongs to a terminal device within the SLE network range, the data packet is directly forwarded to the SLE virtual network interface through the bridging channel. After matching the connection identifier, it is sent to the target terminal device through the corresponding SLE wireless connection. If the destination MAC address belongs to the central device itself, the data packet is submitted to the IP network protocol stack for processing.

[0028] Furthermore, in the uplink data processing step, after extracting the payload of the uplink data frame, a packet buffer structure is requested in the memory pool of the IP network protocol stack, the payload is copied to the packet buffer structure, and submitted to the IP network protocol stack through the input processing function of the SLE virtual network interface.

[0029] Furthermore, in the downlink data processing step, the payload is extracted from the downlink data packet received from the SLE virtual network interface, and the transmission interface of the SLE wireless driver is called according to the matched connection identifier to send the payload to the target terminal device through the corresponding SLE wireless connection.

[0030] On the other hand, this application provides an IP-based bridging system based on StarSpark SLE, including a central device with a StarSpark SLE wireless interface, the central device comprising:

[0031] The connection management module is used to configure the central device as an access point, initialize and maintain the connection management list, which stores the MAC address, connection identifier and link status of the terminal device corresponding to multiple SLE wireless connections.

[0032] The SLE communication control module is used to establish SLE wireless connections with multiple terminal devices to form a one-to-many star network topology, and to store the corresponding parameters of each connection in the connection management list.

[0033] The virtual network interface adapter module is used to create a unique SLE virtual network interface in the IP network protocol stack and register it as a standard network device. It maintains the mapping relationship between connection identifiers and terminal device MAC addresses by querying the connection management list, and realizes bidirectional data forwarding between multiple SLE connections and a single interface based on the mapping relationship.

[0034] The uplink data processing module is used to extract the payload from the uplink data frame received from any SLE wireless connection, identify the data source according to the connection identifier, convert the payload into a network data packet that can be recognized by the IP network protocol stack, and then submit it to the SLE virtual network interface.

[0035] The downlink data processing module is used to query the connection management list based on the target MAC address of the downlink data packet sent by the SLE virtual network interface, match the corresponding connection identifier, and send the payload of the downlink data packet to the target terminal device through the corresponding SLE wireless connection.

[0036] Furthermore, the central device also has a WiFi wireless interface, and the central device also includes a Layer 2 bridging module.

[0037] The Layer 2 bridging module is used to establish a data link layer bridging channel between the SLE virtual network interface and the WiFi wireless interface. It determines the forwarding direction based on the target MAC address of the data packet and completes transparent forwarding of data packets between the SLE network and the WiFi network at the data link layer. The forwarding process does not go through the network layer processing of the IP network protocol stack.

[0038] The substantial effects of this invention:

[0039] 1. This invention leverages the physical layer technology advantages of StarSpark SLE to significantly improve transmission performance and reduce communication latency compared to traditional low-power wireless IP solutions. It meets the IP communication requirements of high-real-time IoT services, breaking through the performance bottlenecks of traditional low-power wireless IP solutions. Furthermore, by creating a unique SLE virtual network interface within the IP protocol stack and maintaining the mapping relationship between terminal MAC addresses and connection identifiers using a connection management list, it enables bidirectional data transmission from a single interface to multiple SLE connections. This eliminates the need to create independent virtual network interfaces for each SLE connection, greatly simplifying the interface management logic of the protocol stack, reducing system resource overhead and scheduling complexity in scenarios with concurrent access from multiple devices, and improving the processing efficiency of uplink data aggregation and downlink data distribution.

[0040] 2. In this invention, a data link layer bridging channel is constructed between the SLE virtual interface and the WiFi interface. The forwarding direction is determined based on the target MAC address of the data packet. Cross-protocol forwarding is completed entirely at the data link layer without the need for network layer processing of the IP network protocol stack, effectively reducing forwarding latency and system processing overhead. Under this mechanism, SLE terminal devices and WiFi network devices can directly communicate at Layer 2, as if they were in the same Ethernet segment. There is no need to deploy additional Layer 3 gateway devices or configure complex routing rules, which greatly reduces the networking complexity and deployment and maintenance costs of heterogeneous networks.

[0041] 3. In this invention, by adopting the link state control logic that activates the virtual interface when any SLE connection is successfully established and closes the virtual interface only when all SLE connections are disconnected, in scenarios with concurrent access by multiple devices, the disconnection of a single terminal will not cause the entire SLE virtual network interface to fail, ensuring that the IP communication of other online terminals is not affected, and significantly improving the stability and continuity of network services in multi-connection scenarios. Attached Figure Description

[0042] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a flowchart of Example 1.

[0044] Figure 2 This is a system principle block diagram of Example 2. Detailed Implementation

[0045] To more clearly illustrate the technical solutions in the embodiments of the invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Example 1:

[0047] Reference Figure 1 As shown, an IP-based bridging method based on StarSpark SLE is applied to an IoT central gateway device that integrates both StarSpark SLE wireless RF units and WiFi wireless RF units. The device runs a lightweight TCP / IP protocol stack and achieves bridging and interoperability between the SLE wireless link and the IP network through a software adaptation layer. The specific implementation process of the method is as follows:

[0048] Device initialization and role configuration: After the device is powered on and started, it first reads the preset role configuration parameters from the configuration partition of non-volatile storage and configures itself as an SLE access point (AP) role; at the same time, it initializes the connection management list in memory. This list is a structure array of preset length. Each entry reserves storage space for fields such as terminal device MAC address, connection identifier, link status, physical layer configuration parameters, etc., for subsequent recording of the corresponding information of each SLE wireless connection.

[0049] Once a multi-terminal SLE wireless connection is established, the central device initiates an SLE scanning process, continuously monitoring SLE broadcast frames in the air interface. For each received broadcast frame, the custom identifier field it carries is parsed. If the field matches the preset network identifier, it is determined to be a compatible terminal device to be accessed.

[0050] The central device initiates connection requests to the matched terminal devices sequentially according to the scanning order. After completing link negotiation, an SLE wireless connection is established, and the terminal's MAC address, assigned connection identifier, negotiated physical layer parameters, and link status are written to the corresponding entry in the connection management list. The central device can repeat the above scan-connection process until the preset maximum number of concurrent connections is reached, ultimately forming a one-to-many star network topology.

[0051] Virtual network interface creation and mapping: The device creates a unique SLE virtual network interface in the TCP / IP protocol stack, configures an independent MAC address for the interface, and registers it as a standard network device access protocol stack.

[0052] The virtual network interface adaptation layer establishes a query mapping mechanism for the connection management list, maintains a one-to-one correspondence between terminal MAC addresses and connection identifiers, and enables a single virtual network interface to simultaneously carry bidirectional data forwarding for multiple SLE connections without needing to create a separate network interface instance for each connection.

[0053] Uplink data reception and forwarding processing: When any SLE wireless connection receives an uplink data frame sent by a terminal device, the SLE wireless driver reports the data payload and corresponding connection identifier to the adaptation layer through a preset callback function; the adaptation layer requests a data packet buffer structure in the protocol stack memory pool, copies the uplink data payload to the buffer structure, and completes the data frame format conversion.

[0054] The forwarding path is then determined: if the destination MAC address of the data frame is the central device's own MAC address, the data packet is submitted to the TCP / IP protocol stack through the input processing function of the virtual network interface. The protocol stack performs network layer and transport layer parsing and then delivers it to the upper layer application. If the central device has enabled the Layer 2 bridging function between SLE and WiFi, and the destination MAC address of the data frame does not belong to the central device itself, the data packet is directly forwarded to the WiFi wireless interface through the bridging channel. The WiFi interface then sends the data frame as a standard Ethernet frame to the external network. The forwarding process does not go through the network layer processing of the IP protocol stack.

[0055] Downlink data distribution and transmission processing: When the upper-layer application generates downlink data to be sent, or the WiFi interface receives a data packet destined for the SLE terminal, the TCP / IP protocol stack sends the data packet to the SLE virtual network interface according to the routing rules; the adaptation layer extracts the payload from the data packet buffer structure, parses the target MAC address of the data packet, and uses the address as an index to query the connection management list to obtain the corresponding connection identifier.

[0056] The adaptation layer calls the transmission interface of the SLE wireless driver to send the data payload to the target terminal device through the SLE wireless link corresponding to the matched connection identifier, thus completing the accurate distribution of downlink data.

[0057] During the above process, the link status of the virtual network interface is dynamically updated according to the connection status: when the first SLE connection is successfully established, the protocol stack interface is called to set the link status of the virtual network interface to the active state; when a new connection is added subsequently, the active state of the interface remains unchanged; when a connection is disconnected, it first checks whether there are other active connections in the connection management list, and only when all SLE connections are disconnected is the link status of the virtual network interface set to the inactive state, ensuring the continuity of network services in multi-connection scenarios.

[0058] Example 2:

[0059] Reference Figure 2 As shown, this embodiment provides an IP-based bridging system based on StarSpark SLE, which is the corresponding software system implementation of the method described in Embodiment 1. It is deployed in a central device that simultaneously possesses both StarSpark SLE wireless interfaces and WiFi wireless interfaces. The system adopts a layered modular design, with each module completing data interaction through a preset callback interface. The specific implementation and collaboration logic of each module in the system are as follows:

[0060] The connection management module is deployed between the SLE protocol stack and the adaptation layer. It is responsible for configuring the access point role parameters during the device initialization phase, initializing and maintaining the connection management list in memory, monitoring the connection and disconnection events of SLE links in real time, and synchronously updating the terminal MAC address, connection identifier and link status of each connection in the list. It also provides a unified connection information query interface for all other modules.

[0061] The SLE communication control module directly interfaces with the SLE wireless radio frequency hardware driver and is responsible for performing operations such as SLE scanning, broadcast listening, connection initiation, and link parameter negotiation. When a terminal device matching the preset network identifier is detected, it actively initiates a connection request and synchronizes the link-related parameters to the connection management module for storage after the connection is successfully established.

[0062] The virtual network interface adapter module, as the core of the adaptation between the SLE link and the TCP / IP protocol stack, is responsible for creating and registering a unique SLE virtual network interface in the IP protocol stack, maintaining the mapping relationship between the terminal MAC address and the connection identifier; in the uplink direction, it aggregates data from multiple SLE connections and submits it to the protocol stack, and in the downlink direction, it distributes the data issued by the protocol stack to the corresponding SLE connection, realizing bidirectional carrying of multiple links by a single interface.

[0063] The uplink data processing module connects to the SLE wireless driver's receive callback, and is responsible for receiving uplink data frames from different SLE connections, extracting the data payload, applying for the data packet buffer structure, and copying the data. At the same time, it works with the Layer 2 bridging module to determine the forwarding path and forward the data to the protocol stack or WiFi interface according to the target MAC address.

[0064] The downlink data processing module, which interfaces with the virtual network interface's send callback, is responsible for receiving downlink data packets from the protocol stack, extracting the payload, calling the query interface of the connection management module, matching the corresponding connection identifier based on the target MAC address, and finally calling the SLE wireless driver's send interface to complete the data transmission.

[0065] The Layer 2 bridging module is an optional feature module that connects the SLE virtual network interface and the WiFi wireless interface. It is responsible for building a bridging channel at the data link layer. In the uplink direction, it identifies data packets with non-local MAC addresses and forwards them to the WiFi interface. In the downlink direction, it identifies WiFi data packets destined for the SLE terminal and forwards them to the SLE virtual interface. The entire forwarding process is completed at the data link layer without the need for the IP protocol stack to participate in the processing.

[0066] The SLE communication control module completes the connection access of multiple terminals, and the connection management module maintains the connection status synchronously. When data is uploaded, the uplink data processing module completes the data reception and format conversion, and submits it to the protocol stack through the virtual network interface adapter module, or directly forwards it to the WiFi network through the Layer 2 bridging module. When data is downloaded, the downlink data processing module completes the target matching and link distribution, and finally realizes the IP-based communication of multiple SLE terminals and Layer 2 interoperability of heterogeneous networks.

[0067] Example 3:

[0068] This embodiment is basically the same as Embodiment 2, except that it provides a multi-connection IP-based bridging system based on StarSpeed ​​SLE. The system includes: a central device (AP) and up to four terminal devices (STAs). The central device simultaneously establishes connections with multiple terminal devices via an SLE wireless link, forming a star topology. The central device also has a WiFi interface, which can connect to a local area network or the Internet. Through the dual-mode bridging mechanism of this invention, SLE terminal devices can directly perform Layer 2 communication with devices in a WiFi network.

[0069] The central equipment contains the following core functional modules:

[0070] Application layer: Runs user business logic and uses standard Socket API for network communication.

[0071] TCP / IP protocol stack (lwIP): handles network protocols such as TCP, UDP, and IP.

[0072] Virtual Network Interface Adapter (sle_netif_mng module): The core module of this invention. It is responsible for creating a virtual network interface named "sle", managing the mapping of multiple connections to a single interface, and handling the encapsulation and distribution of uplink and downlink data.

[0073] SLE-WiFi bridging module (sle_bridge module): Enables L2 transparent forwarding between SLE and WiFi, and determines the forwarding direction of data packets by MAC address.

[0074] Connection Management Module (sle_link_mng module): Maintains the g_sle_user_link_list connection list, recording the device address, connection ID, PHY parameters, and status information of up to 4 concurrent connections.

[0075] SLE Wireless Driver: Drives SLE RF hardware, supporting 1 / 2 / 4 MHz bandwidth and various MCS configurations.

[0076] The specific steps for link establishment and interface activation are as follows:

[0077] Step 1: After the device is powered on, it reads the role configuration from the NET_ID_MODE_CFG partition stored in flash memory. role_idx=0 indicates AP, and role_idx>0 indicates STA.

[0078] Step 2: Call enable_sle() to start the SLE protocol stack, and call net_adapter_netdev_init() to create an LWIP virtual network interface instance g_sle_netdev, named "sle".

[0079] Step 3: Call sle_set_netdev_addr() to set the MAC address for the virtual interface, and call sle_netdev_create() to create a role instance.

[0080] Step 4: Register SLE connection management callbacks (sle_user_register_cbks) and network interface callbacks (sle_netdev_register_callbacks), including link state change and data input callbacks.

[0081] Step 5: The STA starts broadcasting (including the "SLE_NET" identifier), and the AP starts scanning. After discovering the STA, the AP calls sle_user_create_connection() to establish a connection.

[0082] Step Six: After the connection is successfully established, write the connection information to g_sle_user_link_list and call netif_set_link_up() to activate the virtual interface. The AP can repeat this process, establishing a maximum of 4 concurrent connections.

[0083] The uplink data stream (SLE to IP / WiFi) processing flow is as follows:

[0084] When the SLE wireless driver receives a data frame from a connection, it reports it via the sle_netdev_input_cb callback, carrying the connection ID and payload.

[0085] The adapter requests a pbuf buffer in the lwIP memory pool and calls pbuf_take() to copy the payload into the pbuf.

[0086] Bridging determination: Check the destination MAC address of the data packet. If the destination MAC address is the local device, it is submitted to the TCP / IP protocol stack for processing via driverif_input(); if the destination MAC address is not the local device and SLE-WiFi bridging is enabled, the data packet is forwarded directly to the WiFi interface for transmission via the bridging callback (Layer 2 forwarding, bypassing the IP layer).

[0087] The TCP / IP protocol stack parses the submitted data packets at the network and transport layers before delivering them to the application layer.

[0088] The downlink data stream (IP / WiFi to SLE) processing flow is as follows:

[0089] The application layer sends data via the Socket API, or the WiFi interface receives a data packet destined for an SLE device, triggering bridge forwarding.

[0090] The TCP / IP protocol stack determines, based on the routing table, to send via the "sle" virtual interface and calls the registered drv_send function (sle_send_pkt).

[0091] The adapter extracts the payload from pbuf, queries g_sle_user_link_list based on the target MAC address, and determines the connection ID corresponding to the target STA.

[0092] Call sle_netdev_driver_send() to send data to the target STA by specifying the connection ID.

[0093] Specific implementation of SLE-WiFi dual-mode bridging:

[0094] When the compiler macro _PRE_WLAN_FEATURE_SLE_BRIDGE is enabled, the sle_bridge module is activated. Its working principle is as follows:

[0095] (1) During initialization, the SLE virtual interface is associated with the WiFi interface through the callback function registration mechanism.

[0096] (2) After receiving a data packet, the SLE interface performs a MAC address check before submitting it to the protocol stack. If the target MAC address does not belong to this device, it is determined that the data packet needs to be bridged and forwarded.

[0097] (3) The bridging module calls the WiFi interface's send function to send the data packet directly from the WiFi interface as an Ethernet frame.

[0098] (4) Similarly, when the WiFi interface receives a data packet whose target MAC belongs to the SLE network, it forwards it to the SLE adaptation layer for processing through a bridging callback.

[0099] (5) The entire process is completed at the L2 layer and is completely transparent to the upper layer protocols. SLE terminal devices and WiFi devices can ping each other and establish TCP connections as if they were on the same Ethernet segment.

[0100] The substantive technical effects of this embodiment:

[0101] High-performance IP bridging: Fully leverages the high speed (up to 12 Mbps, 6 times that of BLE5.0) and low latency (<3ms, 1 / 2.5 of BLE) of SLE to provide high-performance IP communication capabilities for low-power devices.

[0102] Multi-connection concurrent management: The AP device can manage the connection of up to 4 STA devices at the same time. Through a unified virtual network interface and connection ID mapping mechanism, it can achieve efficient aggregation and distribution of data streams from multiple devices without having to create an independent network interface for each connection.

[0103] SLE-WiFi Layer 2 Transparent Bridging: Innovatively realizes L2 transparent forwarding between SLE and WiFi networks. SLE devices can communicate directly with WiFi devices at Layer 2 without the need for application layer gateways or network layer routing, greatly simplifying the interconnection of heterogeneous networks.

[0104] Dynamic PHY parameter configuration: Supports 1 / 2 / 4 MHz bandwidth for SLE and multiple MCS configurations, allowing for flexible balance between power consumption and performance based on application scenarios.

[0105] The architecture is simple and efficient: the entire bridging solution is completed at the data link layer, which is completely transparent to the upper TCP / IP protocol stack. Standard Socket applications can run on SLE devices without any modification.

[0106] It should be noted that while the preferred embodiments of the present invention are provided in the specification and accompanying drawings, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. These embodiments are not intended to impose additional limitations on the content of the present invention; their purpose is to provide a more thorough and comprehensive understanding of the disclosure of the present invention. Furthermore, the above-described technical features can be combined with each other to form various embodiments not listed above, all of which are considered to be within the scope of the present invention specification. Moreover, those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. An IP-based bridging method based on StarFlash SLE, characterized in that, For use in central devices equipped with a StarSpark SLE wireless interface, the following steps are included: Configure the central device as an access point, initialize and maintain the connection management list, which is used to store the MAC address, connection identifier and link status of the terminal device corresponding to multiple SLE wireless connections; The central device establishes SLE wireless connections with multiple terminal devices to form a one-to-many star network topology, and stores the corresponding parameters of each connection in the connection management list. A unique SLE virtual network interface is created in the IP network protocol stack of the central device and registered as a standard network device. By querying the correspondence between the connection identifier and the MAC address of the terminal device in the connection management list, the correspondence is used to realize bidirectional data forwarding between multiple SLE connections and a single interface. When an uplink data frame is received from any SLE wireless connection, the data source is identified according to the corresponding connection identifier, the data frame payload is extracted and converted into a network data packet that can be recognized by the IP network protocol stack, and submitted to the SLE virtual network interface for network layer processing. When the IP network protocol stack sends downlink data packets through the SLE virtual network interface, it queries the connection management list based on the target MAC address of the data packet, matches the corresponding connection identifier, and sends the payload to the target terminal device through the corresponding SLE wireless connection.

2. The IP-based bridging method based on StarFlash SLE according to claim 1, characterized in that, The specific steps for establishing SLE wireless connections between the central device and multiple terminal devices are as follows: The central device initiates an SLE scanning process, detects SLE broadcast packets carrying a preset network identifier, and initiates connection requests to terminal devices that match the preset network identifier to establish an SLE wireless connection; wherein, the preset network identifier is a specific service identifier or a custom network identifier field embedded in the SLE broadcast packet.

3. The IP-based bridging method based on StarFlash SLE according to claim 2, characterized in that, The central device also has a WiFi wireless interface; The method further includes: A data link layer bridging channel is established between the SLE virtual network interface and the WiFi wireless interface; the bridging channel is used to realize transparent forwarding of data packets between the SLE network and the WiFi network, and the forwarding process does not go through the network layer processing of the IP network protocol stack.

4. The IP-based bridging method based on StarFlash SLE according to claim 3, characterized in that, The link state control logic of the SLE virtual network interface is as follows: When any SLE wireless connection is successfully established, the link status of the SLE virtual network interface is set to active. The link state of the SLE virtual network interface is set to inactive only when all SLE wireless connections are disconnected.

5. The IP-based bridging method based on StarFlash SLE according to claim 1, characterized in that, The connection management list stores information on a preset number of concurrent SLE wireless connections; the information for each connection also includes the PHY rate parameters and modulation and coding scheme configuration parameters corresponding to the link; during the process of establishing an SLE wireless connection with the terminal device, the PHY parameters of the link are configured according to the preset application scenario.

6. The IP-based bridging method based on StarFlash SLE according to claim 3, characterized in that, The bidirectional forwarding process of the data link layer bridging channel specifically includes: SLE forwarding to WiFi: When the SLE virtual network interface receives an uplink data frame from the corresponding SLE wireless connection, it determines the target MAC address of the data frame. If the target MAC address does not belong to the central device itself, the data frame is directly forwarded to the WiFi wireless interface through the bridging channel. If the target MAC address belongs to the central device itself, the data frame is submitted to the IP network protocol stack for processing. WiFi forwarding to SLE: When the WiFi wireless interface receives a data packet from an external network, it determines the destination MAC address of the data packet. If the destination MAC address belongs to a terminal device within the SLE network range, the data packet is directly forwarded to the SLE virtual network interface through the bridging channel. After matching the connection identifier, it is sent to the target terminal device through the corresponding SLE wireless connection. If the destination MAC address belongs to the central device itself, the data packet is submitted to the IP network protocol stack for processing.

7. The IP-based bridging method based on StarFlash SLE according to claim 1, characterized in that, In the uplink data processing step, after extracting the payload of the uplink data frame, a packet buffer structure is requested in the memory pool of the IP network protocol stack, the payload is copied to the packet buffer structure, and submitted to the IP network protocol stack through the input processing function of the SLE virtual network interface.

8. The IP-based bridging method based on StarFlash SLE according to claim 1, characterized in that, In the downlink data processing step, the payload is extracted from the downlink data packet received from the SLE virtual network interface, and the transmission interface of the SLE wireless driver is called according to the matched connection identifier to send the payload to the target terminal device through the corresponding SLE wireless connection.

9. An IP-based bridging system based on StarFlash SLE, used to implement the bridging method according to any one of claims 1-8, characterized in that, This includes a central device equipped with a StarSpark SLE wireless interface, the central device comprising: The connection management module is used to configure the central device as an access point, initialize and maintain the connection management list, which stores the MAC address, connection identifier and link status of the terminal device corresponding to multiple SLE wireless connections. The SLE communication control module is used to establish SLE wireless connections with multiple terminal devices to form a one-to-many star network topology, and to store the corresponding parameters of each connection in the connection management list. The virtual network interface adapter module is used to create a unique SLE virtual network interface in the IP network protocol stack and register it as a standard network device. It maintains the mapping relationship between connection identifiers and terminal device MAC addresses by querying the connection management list, and realizes bidirectional data forwarding between multiple SLE connections and a single interface based on the mapping relationship. The uplink data processing module is used to extract the payload from the uplink data frame received from any SLE wireless connection, identify the data source according to the connection identifier, convert the payload into a network data packet that can be recognized by the IP network protocol stack, and then submit it to the SLE virtual network interface. The downlink data processing module is used to query the connection management list based on the target MAC address of the downlink data packet sent by the SLE virtual network interface, match the corresponding connection identifier, and send the payload of the downlink data packet to the target terminal device through the corresponding SLE wireless connection.

10. The IP-based bridging system based on StarSpark SLE according to claim 9, characterized in that, The central device also has a WiFi wireless interface, and the central device also includes a Layer 2 bridging module. The Layer 2 bridging module is used to establish a data link layer bridging channel between the SLE virtual network interface and the WiFi wireless interface. It determines the forwarding direction based on the target MAC address of the data packet and completes transparent forwarding of data packets between the SLE network and the WiFi network at the data link layer. The forwarding process does not go through the network layer processing of the IP network protocol stack.