Dynamic reconfiguration system and method for internet of things (iot) device networks

Abstract

The present disclosure provides, in various embodiments, a system, method, and apparatus for Internet of Things (IoT) device network dynamic reconfiguration. The method can include collecting network health data and gateway health data from a source gateway and transmitting a handoff signal to the source gateway. The handoff signal can initiate a device assignment routine when at least one trigger criteria is met, such as a load balancing event, a failover event, a roaming event, or a user initiated event. A target gateway can be determined based on selection parameters, and relevant device details can be received from the source gateway to enable the IoT devices to connect with the target gateway.

Description

[0001] Cross-referencing related applications This application claims the benefit of U.S. Nonprovisional Application No. 19 / 056,330, filed February 18, 2025, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The embodiments described herein generally relate to systems, apparatuses, and methods for managing and coordinating wireless networks of Internet of Things (IoT) devices. Specifically, these embodiments relate to the dynamic reconfiguration of IoT device networks. Background Technology

[0003] The following statements do not constitute an admission that any subject matter herein is prior art or known to those skilled in the art.

[0004] The Internet of Things (IoT) refers to a network of interconnected devices that communicate with other devices and external systems, typically requiring minimal human intervention. IoT devices generally include sensors that monitor various parameters of the surrounding environment. These sensors collect data and transmit it to other devices or a central management system via wired or wireless communication protocols. Common sensors include thermometers, accelerometers, microphones, cameras, motion detectors, humidity sensors, and electricity meters. The sensed data can be used to automate processes, monitor environmental conditions, or trigger specific actions based on predefined criteria. For example, a humidity detector in a warehouse can trigger an alarm when a leak is detected, or a motion sensor can turn on lights when movement is detected in a room.

[0005] In addition to sensors, IoT devices can also include actuators, allowing IoT systems to respond to data signals and perform physical tasks. An actuator is a mechanism that performs actions, typically in response to commands from a controller connected to a network. For example, a smart thermostat may include both sensors (for monitoring temperature) and actuators (for controlling the HVAC system). The thermostat collects temperature data and sends it to the network; in response to commands from a remote controller, the actuator adjusts the heating or cooling system accordingly. The interaction between sensors and actuators enables IoT systems to support a wide range of applications—from remote monitoring and automation in smart homes to inventory management and environmental monitoring in industrial environments.

[0006] The retail industry is leveraging IoT technology to improve operations, optimize customer experience, and streamline inventory management. IoT devices can be deployed throughout the supply chain, from warehouses to retail floors, enabling real-time monitoring and control. For example, asset tags, security sensors, and environmental monitoring devices track the location, status, and safety of products stored in warehouses. These sensors ensure items are preserved under appropriate conditions by monitoring variables such as temperature, humidity, and motion. During product transportation, fleet management sensors collect vehicle status, temperature, and location data to ensure uninterrupted delivery of goods to retail locations or end customers. IoT-enabled tracking helps retailers maintain inventory accuracy, prevent product loss, and adhere to quality standards throughout the distribution process.

[0007] Within stores, electronic shelf labels (ESLs) dynamically display price, promotion, and inventory information on e-paper or e-ink displays, synchronized with the retailer's central system. ESL systems minimize the need for manual price updates, ensuring consistency and accuracy across product information. Retailers can also integrate occupancy sensors, geolocation trackers, and customer interaction technologies to optimize store layout and personalize marketing strategies. For example, geolocation technology tracks customer movement within the store, identifies high-traffic areas, and adjusts product placement accordingly. These IoT solutions enable retailers to deliver customized promotions, real-time discounts, and personalized pricing based on customer behavior.

[0008] IoT networks typically operate on wireless communication technologies, enabling devices to transmit data over both long and short distances. Some IoT systems rely on cellular technologies such as LTE and 5G to connect remote sensors to cloud platforms, while others use Wi-Fi, Bluetooth, Zigbee, LoRa, or proprietary low-power communication protocols for local communication between devices and gateways. These communication protocols are designed to support various network topologies, such as star, mesh, or peer-to-peer configurations. For example, Bluetooth Low Energy (BLE) is well-suited for local communication due to its low power consumption, making it ideal for devices such as wearables and electronic shelf labels (ESL). On the other hand, Wi-Fi networks offer higher bandwidth, making them suitable for transmitting large amounts of data, such as video streams from security cameras.

[0009] Many existing IoT networks use gateways as intermediaries between IoT devices and cloud platforms. Gateways aggregate data from multiple devices and manage network connectivity. They operate as local hubs, reducing the communication burden on individual sensors. Gateways can also translate communication protocols and perform local processing to optimize network performance. They can also implement edge computing, where some data processing tasks are performed locally, rather than sending all data to a remote cloud. However, managing a large number of devices and gateways presents challenges, especially in scenarios where devices frequently move between different coverage areas or where network conditions fluctuate.

[0010] Implementing IoT networks also presents several technical challenges. These include network scalability, device coordination, interference reduction, data security, and power management. High-density environments, such as retail stores or industrial facilities, introduce additional complexity, including packet collisions, connection overlap, and the need for seamless device allocation between gateways. Furthermore, IoT devices typically operate under constrained conditions, such as limited battery life and processing power, requiring protocols and systems to be highly efficient and reliable. As IoT systems scale to support thousands of devices, addressing issues related to network latency, reliable data transmission, and secure communication becomes crucial.

[0011] Enterprises (including retailers, wholesalers, and logistics companies) may rely on IoT deployments from multiple vendors to meet diverse operational needs. However, one vendor may require the use of its own set of gateways and cloud-based management systems, resulting in the creation of "shadow networks." These overlapping networks not only increase installation and maintenance complexity but also lead to operational inefficiencies by creating data silos and duplicated infrastructure. This fragmented approach also increases the risk of network interference and security vulnerabilities, as different systems may lack coordinated or integrated security protocols.

[0012] Furthermore, IoT deployments in retail environments may involve higher densities of devices and gateways. Retail locations, such as grocery stores or warehouses, may require coordinating tens of thousands of electronic shelf labels (ESLs) and hundreds of gateways. This high-density network presents unique technical challenges, such as an increased probability of collisions between broadcast packets transmitted by different devices, which can lead to longer discovery delays and hinder network performance.

[0013] Broadcast packets from IoT devices may be received by multiple gateways unaware of each other's activities, potentially leading to duplicate connections with the same device, resulting in inefficiency and wasted resources. These challenges are further exacerbated by the lack of a site-wide coordination mechanism between gateways.

[0014] Implementing PAwR (Periodic Broadcast with Response) in high-density environments such as retail locations introduces synchronization challenges that can significantly impact network efficiency and device performance. Synchronizing gateways with IoT devices transmitting periodic broadcast packets is inherently time-consuming, as the process involves multiple steps and message exchanges, increasing discovery latency. The process of locating, resolving, and synchronizing multiple packet types contributes to latency, reducing responsiveness and hindering real-time applications. Another significant challenge with PAwR arises when attempting to switch device connections from one gateway to another. When an IoT device has an active PAwR association with a gateway, the device must wait for the current association to time out before initiating the onboarding process with the new gateway (e.g., Gateway). This latency results in considerable downtime, impacting the service continuity of IoT devices and the stability of other devices within the gateway's coverage area.

[0015] Maintaining continuous device connectivity is challenging in high-density IoT environments, such as retail, healthcare, and industrial deployments, especially when IoT devices move between different areas or coverage zones. Using traditional BLE protocols (which inherently do not support device assignment between gateways), IoT devices may face connectivity interruptions when moving out of the range of a single gateway. Furthermore, in scenarios requiring device roaming capabilities (such as warehouses or logistics centers), moving IoT devices between different coverage areas can result in prolonged connectivity disruptions. Without a coordination mechanism for device roaming between gateways, devices may need to re-establish a connection each time they enter a new gateway's coverage area.

[0016] Furthermore, the lack of a coordinated failover mechanism in traditional systems can create vulnerabilities. When a gateway fails (whether due to maintenance requirements, technical issues, or network load), connected devices may lose connectivity without alternative options. This can lead to data gaps, lost updates, or the need for manual intervention to restore connectivity. These failures become particularly problematic in high-density deployments, where a single gateway or access point may handle hundreds of devices simultaneously. Therefore, gateway failures can have a significant impact, causing widespread outages.

[0017] Another issue arises in environments requiring load balancing. Because IoT devices may be densely clustered in certain areas, some gateways become overloaded while others are underutilized. Without a method to dynamically distribute connections among available gateways, overloading a single gateway can lead to performance degradation, high latency, and increased error rates. This not only reduces device response time but can also cause devices to disconnect, requiring repeated reconnection attempts and further increasing network congestion.

[0018] Therefore, alternative systems and methods are needed to remedy the inefficiency of traditional systems. Summary of the Invention

[0019] The purpose of this summary is to familiarize the reader with the following detailed description without limiting or defining any claimed or unclaimed invention. This summary is not a comprehensive analysis, nor is it intended to highlight key features. Rather, it provides a general overview of certain inventive concepts as an introduction to the subsequent detailed description. One or more inventions may exist in any combination or sub-combination of the elements or process steps disclosed in any part of this document (including its claims and drawings).

[0020] In one aspect, the full site controller can be configured to collect network health data and gateway health data from the source gateway. The full site controller can also be configured to transmit a device allocation signal to the source gateway, which can be configured to initiate a device allocation routine when one or more device allocation triggering criteria are met at the source gateway. Device allocation triggers may include at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. The full site controller can also be configured to determine a target gateway based on multiple selection parameters within the device allocation routine. The full site controller can also be configured to receive IoT device details from the source gateway and transmit the IoT device details to the target gateway to enable the IoT device to connect to the target gateway. The IoT device details include at least one identifier associated with at least one of one or more IoT devices, which has been used by the source gateway to connect to the IoT device. In some embodiments, gateway health data may include one or more of the following: CPU load, memory usage, network throughput, radio utilization (including transmission, reception, and idle timing), reported and assigned device type combinations, received signal strength, transmission power, response time, timeout events, latency indicators, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error reports, data consumption, noise levels between communication channels, channel mapping, spectrum capacity, or packet loss. In some embodiments, a load balancing event may occur when the gateway health data of the source gateway exceeds a load threshold based on one or more of CPU usage, memory consumption, or congestion metrics. In some embodiments, a failover event may occur in response to a source gateway experiencing a failure or maintenance outage. In some embodiments, a roaming event may occur in response to one or more of the following: the full site controller determines a signal strength difference based at least in part on gateway data received from the target gateway indicating that the target gateway is receiving a signal with a first signal strength greater than a second signal strength received by the source gateway; or, the full site controller determines the movement of the IoT device based at least in part on a predictive roaming model that includes historical model data associated with the signal strength data. In some embodiments, the identifier associated with at least one of one or more IoT devices may include at least one of a MAC address or a vMAC address. In some embodiments, multiple selection parameters for the target gateway may include at least one of the following: load capacity, radio availability, proximity of the target gateway to the IoT device, signal strength, communication history between the target gateway and the IoT device, or spectrum resources. In some embodiments, IoT device details may include one or more of the following: timing data, device-specific identifier, encryption key, communication status, device status indicator, or protocol version.

[0021] In one aspect, a method may include collecting network health data and gateway health data from a source gateway. The method may also include transmitting a device allocation signal to the source gateway, the device allocation signal being configurable to initiate a device allocation routine when a device allocation trigger is met at the source gateway. The device allocation trigger may include at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. The method may also include determining a target gateway based on a plurality of selection parameters within the device allocation routine. The method may further include receiving IoT device details from the source gateway and transmitting the IoT device details to the target gateway to enable the IoT device to connect to the target gateway. The IoT device details include at least one identifier associated with at least one of one or more IoT devices, the identifier being used by the source gateway to connect to the IoT device. In some embodiments, gateway health data may include one or more of the following: CPU load, memory usage, network throughput, radio utilization (including transmission, reception, and idle timing), reported and allocated device type combinations, received signal strength, transmission power, response time, timeout events, latency indicators, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error reports, data consumption, noise levels between communication channels, channel mapping, spectrum capacity, or packet loss. In some embodiments, initiating a device allocation routine for a load balancing event may include initiating the device allocation routine in response to a source gateway's gateway health data exceeding a load threshold based on one or more of CPU usage, memory consumption, or congestion metrics. In some embodiments, initiating a device allocation routine for a failover event may include initiating the device allocation routine in response to a source gateway experiencing a failure or maintenance downtime. In some embodiments, initiating a device allocation routine for a roaming event may include initiating the device allocation routine in response to one or more of the following: determining a signal strength difference based at least in part on gateway data received from a target gateway indicating that the target gateway is receiving a signal with a first signal strength greater than a second signal strength received by the source gateway; or determining the movement of the IoT device based at least in part on a predictive roaming model including historical model data associated with the signal strength data. In some embodiments, an identifier associated with at least one of one or more IoT devices may include at least one of a MAC address or a vMAC address. In some embodiments, multiple selection parameters for the target gateway may include at least one of the following: load capacity, radio availability, proximity of the target gateway to the IoT device, signal strength, communication history between the target gateway and the IoT device, or spectrum resources. In some embodiments, IoT device details may include one or more of the following: timing data, device-specific identifier, encryption key, communication status, device status indicator, or protocol version.

[0022] In one aspect, a computer-readable storage medium stores instructions thereon that, when executed by a processor, configure the processor to collect network health data and gateway health data from a source gateway. The computer-readable storage medium also stores instructions that, when executed by a processor, further configure the processor to transmit a device allocation signal to the source gateway, the device allocation signal being configurable to initiate a device allocation routine when a device allocation trigger is met at the source gateway, wherein the switching trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. The computer-readable storage medium further stores instructions that, when executed by a processor, further configure the processor to determine a target gateway based on a plurality of selection parameters within the device allocation routine. Finally, the computer-readable storage medium stores instructions that, when executed by a processor, further configure the processor to receive IoT device details from the source gateway and transmit the IoT device details to a target gateway to enable the target gateway to connect to the IoT device. The IoT device details include at least one identifier associated with at least one of one or more IoT devices, the identifier being used by the source gateway to connect to the IoT device. In some embodiments, gateway health data may include one or more of the following: CPU load, memory usage, network throughput, radio utilization (including transmission, reception, and idle timing), reported and assigned device type combinations, received signal strength, transmission power, response time, timeout events, latency indicators, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error reports, data consumption, noise levels between communication channels, channel mapping, spectrum capacity, or packet loss. In some embodiments, a load balancing event may occur in response to the source gateway's gateway health data exceeding a load threshold based on one or more of CPU usage, memory consumption, or congestion metrics. In some embodiments, a failover event may occur in response to the source gateway experiencing a failure or maintenance downtime. Attached Figure Description

[0023] The present invention will be described by way of exemplary and non-limiting embodiments, with reference to the accompanying drawings, wherein: Figure 1 This is a schematic block diagram of an IoT wireless network management system 100 according to one embodiment.

[0024] Figure 2 This is a schematic block diagram of an IoT wireless network management system 200 according to one embodiment.

[0025] Figure 3 This is a schematic block diagram of an edge connection module 300 according to one embodiment.

[0026] Figure 4 This is a schematic block diagram of an IoT wireless network management system 400 according to one embodiment.

[0027] Figure 5 This is a schematic block diagram of an IoT edge connectivity framework 500 according to one embodiment.

[0028] Figure 6 This is a schematic flowchart of an event detection and triggering mechanism 600 according to one embodiment.

[0029] Figure 7 This is a schematic flowchart of an event detection and triggering mechanism 700 according to one embodiment.

[0030] Figure 8 This is a schematic flowchart of a full-site configuration method 800 according to one embodiment.

[0031] Figure 9 This is a schematic flowchart of a broadcast message filtering method 900 according to one embodiment.

[0032] Figure 10 This is a schematic flowchart of a device allocation method 1000 according to one embodiment. Detailed Implementation

[0033] The embodiments disclosed herein are illustrations of various implementations of the inventive concepts and techniques described herein. The statements in the specification are not necessarily limiting of any claimed embodiment. Rather, they are provided to illustrate different possible implementations, and variations in form or configuration may still fall within the scope of the invention. Certain features described herein may be applicable to some embodiments but not to others. Furthermore, unless expressly stated otherwise, the use of singular elements should include plural forms and vice versa, without losing generality or changing the scope of the invention.

[0034] The accompanying drawings are provided to aid in understanding these embodiments and do not limit the scope of the invention. For clarity and consistency, the same reference numerals are used in the figures to refer to the same or similar components. It will also be apparent to those skilled in the art that the invention described herein can be practiced without specific details in certain examples. In some cases, well-known methods, procedures, or elements may not be described in detail to avoid unnecessarily obscuring core aspects of the invention.

[0035] It should be noted that this document uses approximate terminology to allow for reasonable deviations from the literal meaning, provided that such deviations do not materially alter the intended function or purpose. Furthermore, terms such as “including” should mean “including, but not limited to”, unless explicitly stated otherwise. Similarly, the list of items is for illustrative purposes only and should not be construed as mutually exclusive or exhaustive unless explicitly stated otherwise.

[0036] The systems and methods described herein may be implemented in hardware, software, or a combination of both. For example, these embodiments may be implemented as computer programs that execute on one or more programmable computing devices, including servers, network appliances, embedded devices, laptops, smartphones, or other computing devices capable of performing the described functions. These computer programs or computer-executable instructions may be written in a variety of programming languages, including but not limited to high-level procedural languages, object-oriented languages, or scripting languages, or compiled or interpreted languages. They may be stored on non-transitory computer-readable media, such as disks, optical disks, or solid-state storage devices, and when executed by a computing system, perform the methods described herein.

[0037] Certain portions of this disclosure may be provided in a title or header. Such title or header is included for reference and clarity purposes only. The disclosure within the title section is not limited to the specific embodiments shown, but may be applied to other embodiments throughout this disclosure.

[0038] The Internet of Things (IoT) refers to a distributed network of interconnected devices that autonomously collect and exchange data. Large-scale deployment of IoT networks can introduce several challenges related to network congestion, duplicate communications, device discovery, broadcast packet collisions, and connection management. For example, without a coordinated broadcast transmission mechanism, ESLs may transmit their broadcast messages simultaneously or within overlapping intervals. This uncoordinated transmission leads to collisions, and gateways or access points may be unable to detect or decode these broadcast messages, causing initial communication attempts to fail. On the gateway side, the lack of coordinated scanning among multiple gateways results in additional inefficiencies.

[0039] Connectivity issues are particularly pronounced on devices using the Bluetooth 5.4 standard, which includes protocols such as Periodic Broadcast with Response (PAwR). While designed for efficient communication, PAwR is limited in high-density environments because it relies on precise synchronization. The already complex synchronization process becomes even more time-consuming when broadcast messages repeatedly collide or are missed by uncoordinated gateways. This latency hinders ESL from synchronizing quickly and participating in subsequent tasks, impacting real-time responsiveness and operational efficiency.

[0040] To address these issues, this disclosure provides systems, devices, and methods for managing and coordinating high-density IoT networks. The system 100 is responsible for site-wide coordination of the network. In one embodiment, site-wide coordination may be provided by edge connectivity module instances located in one or more gateways, where the gateways are connected to a cloud configuration server for centralized coordination. The edge connectivity modules are also responsible for synchronizing data exchange between gateways for coordinated operations. In another embodiment, one or more gateways are connected to a full-site controller. The full-site controller includes edge connectivity module instances that provide unified configuration management, data aggregation, and synchronized network operations. The full-site controller enables centralized monitoring and control of all connected gateways, allowing for real-time adjustment of network parameters, load balancing, and seamless device allocation (such as switching). The full-site controller may connect to a server layer. Furthermore, the full-site controller can aggregate network health and device monitoring data across the entire deployment, supporting predictive maintenance, adaptive resource allocation, and coordinated responses to network events. This coordination allows for dynamic aggregation, filtering, and synchronization of data, reducing packet collisions, minimizing redundant connections, and improving network efficiency. The disclosed system can perform real-time processing tasks using edge computing capabilities within the gateway, minimizing latency by managing operations on local processing devices and reducing reliance on cloud resources for time-sensitive activities.

[0041] Now for reference Figure 1 The diagram shows a schematic block diagram of an IoT network system 100 according to one embodiment.

[0042] The embodiments disclosed herein include a system 100 for the management and coordination of IoT devices in a multi-layer network. The system 100 includes IoT devices 1010, 1020, 1030, 1040, and 1050, and gateways 1100, 1200, and 1300. Gateways 1100, 1200, and 1300 operate as intermediate nodes between a perception layer 1004 and a cloud analytics layer 1006. IoT devices 1010, 1020, 1030, 1040, and 1050 (including hardware and firmware components) communicate via wireless protocols such as Bluetooth Low Energy (BLE) or Zigbee, transmitting environmental data to gateways 1100, 1200, and 1300. Gateways 1100, 1200, and 1300 can perform local processing, coordination, and aggregation of sensor data at the network edge. Gateways 1100, 1200, and 1300 further communicate with cloud servers 1500, 1600, and 1700 deployed on the cloud computing platform.

[0043] In one embodiment, processing, coordination, and data aggregation can be performed at gateways 1100, 1200, and 1300. Alternatively, processing, coordination, and data aggregation can be performed at configuration server 1500, with real-time instructions transmitted to gateways 1100, 1200, and 1300 for synchronized operation and responsive network management.

[0044] System 100 includes a sensing layer 1002. Sensing layer 1002 includes multiple endpoint devices 1010, 1020, 1030, 1040, and 1050 (also referred to as sensors or IoT devices). In one embodiment, endpoint devices 1010, 1020, 1030, 1040, and 1050 are provided to collect environmental data or monitor specific conditions. The IoT devices are exemplary, and a reference to one IoT device (such as IoT device 1010) may also refer to other devices, such as IoT devices 1020, 1030, 1040, or 1050. The number of IoT devices is not limited to the specific number shown in the figures. In various embodiments, more or fewer IoT devices may be installed depending on the requirements of system 100. IoT devices may include various components such as temperature sensors, electronic shelf labels (ESLs), thermometers, accelerometers, optical scanners, and humidity detectors, as well as other specialized hardware such as actuators.

[0045] Furthermore, a reference to a subcomponent of an IoT device may refer to a corresponding subcomponent of one or more other IoT devices. For example, a reference to an operation performed by the device firmware 1012 of IoT device 1010 may refer to a similar process performed by the device firmware 1022 of IoT device 1020, the device firmware 1032 of IoT device 1030, the device firmware 1042 of IoT device 1040, or the device firmware 1050 of IoT device 1050. Similarly, a reference to the sensor hardware 1014 of IoT device 1010 may include the sensor hardware 1024 of IoT device 1020, the sensor hardware 1034 of IoT device 1030, the sensor hardware 1044 of IoT device 1040, or the sensor hardware 1054 of IoT device 1050. Furthermore, references to the IoT radio module 1016 in IoT device 1010 may refer to similar operations performed by the IoT radio module 1026 of IoT device 1020, the IoT radio module 1036 of IoT device 1030, the IoT radio module 1046 of IoT device 1040, or the IoT radio module 1056 of IoT device 1050. Although sub-components are part of different IoT devices, they can perform equivalent operations throughout the network system 100 to achieve coordinated functionality.

[0046] The perception layer 1002 operates through the perception layer network 102, enabling the IoT device 1010 to transmit IoT device data to the network layer 1004. Depending on the specific implementation and deployment requirements, various protocols can be used within the perception layer 1002.

[0047] In one embodiment, the perception layer network 102 provides a lightweight, low-power wireless protocol for energy-efficient communication. Bluetooth Low Energy (BLE) can be used for short-range connections, enabling sensors to transmit IoT device data with minimal power consumption. In larger-scale deployments, Zigbee can be used to create a mesh network. For deployments requiring long-range communication and low data rates, LoRa (long-range) can be used. The protocol can be selected based on factors such as IoT device density, coverage area, and network topology to ensure optimal communication.

[0048] In one embodiment, IoT devices within the perception layer 1002 connect to one or more gateways 1100, 1200, 1300 via the perception layer network 102. The perception layer network 102 may also support adaptive mechanisms, such as dynamic frequency selection or channel hopping, to minimize interference. In one embodiment, the perception layer 102 provides a local data buffer within the IoT device 1010 to reduce data loss during brief network outages.

[0049] In one embodiment, the perception layer network 102 provides local wireless communication between IoT devices 1010, 1020, 1030, 1040, and 1050 and gateways 1100, 1200, and 1300. The perception layer network 102 enables bidirectional data exchange, allowing IoT devices 1010 to send IoT device data and receive gateway data from gateways 1100, 1200, and 1300. In one embodiment, IoT devices 1010 (such as electronic shelf labels (ESLs)) may receive gateway data including display content data. For IoT devices 1010 that include actuators, the gateway data may include control data that causes IoT devices 1040 to perform specific operations (such as closing a valve or adjusting environmental settings). The protocol used on network 102 may vary depending on the type of IoT device 1010. All IoT devices 1010 within the same system 100 may not operate on the same protocol. Different protocols may be selected based on the range, power consumption, and network topology requirements of a specific deployment environment or IoT device type.

[0050] IoT device data transmitted via network 102 may include sensor data. For example, a temperature sensor may transmit sensor data including temperature readings (e.g., 23°C). A leak sensor may transmit sensor data including a "leak detected" status signal. For the electricity meter IoT device 1010, IoT device data may include energy consumption data at regular intervals. IoT device data may include metadata. Metadata may include a unique sensor ID, timestamp, and battery status, providing contextual information for further processing at gateway 1100. The packet format of IoT device data depends on the protocol used. For example, BLE packets may follow the structure defined in BLE broadcast or connection protocols.

[0051] In one embodiment, a security mechanism is implemented for transmissions on the perception layer network 102. The security mechanism may include an authentication token or session identifier in the IoT device data packet to verify the authenticity of the transmitting IoT device 1010. For security and efficiency, a lightweight security protocol configured for the IoT device 1010 with limited processing power may be installed. The lightweight security protocol may include Elliptic Curve Cryptography (ECC) to provide strong encryption with a small key. The lightweight security protocol may also include DTLS (Datagram Transport Layer Security) to protect datagrams with minimal latency. In one embodiment, symmetric encryption (including AES-128 and a pre-shared key) may be used with the IoT device data packet to provide efficient and secure communication without incurring the processing requirements typically required by more complex security frameworks.

[0052] In one embodiment, IoT device 1010 may include additional components beyond sensors to perform specific operations. These components may include actuators, drivers, display modules, data simulators, relays, and controllers. For example, the ESL within IoT device 1010 may utilize an LED display, LCD panel, or electronic paper display to present display content data (including in gateway data) received from gateway 1100 via perception layer network 102. Actuators included in IoT device 1010 may receive control data (including in gateway data) to perform actions such as adjusting lighting, opening valves, or triggering alarms based on these instructions. IoT device 1010 may also include additional firmware drivers, signal converters, and power modules to manage device operation and connectivity.

[0053] In one embodiment, IoT device 1010 includes device firmware 1012 configured to manage internal operations of IoT device 1010, including managing tasks such as data collection, communication, and control logic. IoT device 1010 includes sensor hardware 1014 that may vary depending on the use case and may include temperature sensors, optical cameras, humidity detectors, motion sensors, or other dedicated hardware to detect environmental or operating conditions. IoT device 1010 includes an IoT radio module 1016 configured to enable wireless communication via a perception layer network 102 using protocols such as BLE, Zigbee, or LoRa. In one embodiment, a power module may be included in IoT device 1010 to manage power consumption.

[0054] In one embodiment, specific modules may be implemented within the IoT device 1010 to perform different functions and generate data included in the IoT device data. For example, a sensor module (not shown) may collect sensor data. A firmware module (not shown) may perform operations based on firmware control data configured to manage software functions. A radio module (not shown) may receive or transmit radio communication data via protocols such as BLE or Zigbee. An actuator module (not shown) may perform physical actions, such as opening a valve or adjusting lighting, in response to control data sent from the gateway 1100. Alternatively, a single processor within the IoT device 1010 may be configured to perform the tasks of one or more modules, depending on the device architecture and design.

[0055] IoT device 1010 may include a simulator component configured to generate simulated data, replicating specific environmental conditions or sensor outputs to support testing or calibration. The simulated data may be included in the IoT device data. This simulated data can simulate temperature values ​​or leak detection conditions to verify device performance without actual environmental input. Furthermore, IoT device 1010 may include a reader configured to interpret external data from sources such as barcodes, RFID tags, or optical scanners.

[0056] The IoT network system 100 includes a network layer 1004 (also known as the intermediate network layer 1004). The intermediate network layer 1004 operates as a communication bridge between the perception layer 1002 (including the PAWR-enabled IoT device 1010) and the cloud analytics layer 1006. The intermediate network layer 1004 provides seamless bidirectional data exchange by routing IoT device data and gateway data. The intermediate network layer 1004 can communicate via local wireless protocols (such as BLE, Zigbee, or LoRa) to receive IoT device data from the IoT device 1010. The IoT device data is then aggregated at the gateway level and transmitted via a local area network (LAN) or secure internet connection to the cloud system in the cloud analytics layer 1006 for further analysis and management.

[0057] Gateways 1100, 1200, and 1300 can provide data aggregation by routing and collecting IoT device data from IoT device 1100. Aggregated inter-gateway data can be transmitted from gateway 1100 to another gateway 1200 or 1300. Cloud-directed data can be transmitted from gateway 1100 to the cloud analytics layer 1006. By aggregating multiple data streams from the perception layer 1002, the intermediate network layer 1004 reduces the number of independent transmissions to the cloud analytics layer 1006.

[0058] The intermediate network layer 1004 provides bidirectional communication between IoT device 1010 and gateway 1100. Additionally, the intermediate network layer 1004 provides bidirectional communication between gateway 1100 and servers 1500, 1600, and 1700. Gateways 1100, 1200, and 1300 can transmit control data (including in gateway data) to IoT devices, such as electronic shelf labels (ESLs) or actuators.

[0059] Gateways 1100, 1200, and 1300 are configured to communicate with heterogeneous devices within the same network. Gateways 1100, 1200, and 1300 can also perform protocol conversion to provide interoperability between IoT devices using different communication protocols, such as BLE, Zigbee, and LoRa. Gateways 1100, 1200, and 1300 can also harmonize protocols by converting IoT device data formats to standard cloud-compatible formats. Gateways 1100, 1200, and 1300 can implement local communication management processes to minimize interference and harmonize scan parameters among multiple gateways. This disclosure provides network optimization techniques to reduce packet collisions, manage data congestion, and improve overall latency. The gateways can evenly distribute the communication load among IoT devices 1010, preventing any single gateway from becoming overloaded.

[0060] In one embodiment, the intermediate network layer 1004 implements security mechanisms to protect data and provide trusted communication between system components. Gateways 1100, 1200, and 1300 may apply encryption protocols such as TLS or AES to protect the transmission of cloud-oriented data through network 104.

[0061] The intermediate network layer 1004 includes gateways 1100, 1200, and 1300. The gateways are not limited to... Figure 1 The specific number shown is not included. Depending on deployment requirements, the system may have fewer or more gateways. Gateways are exemplary and refer to one gateway (such as gateway 1100). The description may also refer to other gateways, such as gateway 1200 or 1300.

[0062] Furthermore, a reference to a subcomponent of a gateway (such as gateway 1100) may refer to a corresponding subcomponent in another gateway within network layer 1004. The processor 1102 and memory 1150 in gateway 1100, which perform processing and storage operations, may refer to similar functions performed by the processor 1202 and memory 1250 in gateway 1200 or the processor 1302 and memory 1350 in gateway 1300. For example, a reference to network and settings 1104 in gateway 1100 may refer to similar operations performed by network and settings 1204 in gateway 1200 or the network and settings 1304 in gateway 1300. Similarly, a reference to operating system 1106 in gateway 1100 may refer to operating system 1206 in gateway 1200 or the operating system 1306 in gateway 1300. A reference to IoT radio 1110 in gateway 1100 may refer to corresponding operations performed by IoT radio 1210 in gateway 1200 or the IoT radio 1310 in gateway 1300. Furthermore, container management 1108 in gateway 1100 may represent a similar process performed by container management 1208 in gateway 1200 or container management 1308 in gateway 1300. Similarly, edge connectivity module 1112 in gateway 1100 may correspond to edge connectivity module 1212 in gateway 1200 or edge connectivity module 1312 in gateway 1300. Although the sub-components are integrated into different gateways, they can perform equivalent functions throughout the network system 100 to achieve coordinated operation.

[0063] Furthermore, any process, operation, or function attributed to a specific component of gateway 1100 can be executed by executing data generated by that component. Additionally, processes, operations, and configurations associated with components of gateway 1100 can be executed as steps in methods for implementing said functions.

[0064] Gateway 1100 acts as an intermediate network processing node between IoT devices in the perception layer 1002 and higher-level systems (such as cloud platforms, enterprise applications, or vendor-specific services) in the cloud analytics layer 1006. Gateway 1100 is configured to receive IoT device data from IoT device 1010. Furthermore, Gateway 1100 provides protocol conversion, transforming the protocols used by IoT device 1010 for local communication (such as BLE, Zigbee, or LoRa) into internet-based upstream protocols (such as MQTT or HTTPS) compatible with the cloud systems in the cloud analytics layer 1006. After aggregation, Gateway 1100 generates and transmits cloud-directed data to the cloud analytics layer 1006 using protocols such as MQTT or HTTPS. During the conversion process, IoT device data collected using local protocols is reformatted into cloud-directed data compatible with the upstream systems. Gateway 1100 can perform local data processing to generate control data and display content data, which are included in the gateway data sent to the IoT devices.

[0065] The Gateway 1100 enables edge computing capabilities to perform local filtering, aggregation, and a degree of data analysis. By processing data at or near the data source, the gateway saves bandwidth and reduces network latency by minimizing the amount of data transmitted to the cloud.

[0066] In one embodiment, gateway processor 1102 includes a network and settings component 1104. Network and settings component 1104 may generate network configuration data to perform operations attributed to component 1104. The network configuration data is included in gateway data generated at the gateway level. Alternatively, the network configuration data may be referred to as gateway data for operations performed for network and settings component 1104. Gateway 1100 may include a dedicated network and settings module to perform the functions of network and settings component 1104. Alternatively, processor 1102 may be configured to perform network and settings functions.

[0067] In one embodiment, the network and configuration component 1104 is configured to manage network parameters, communication protocols, and device settings. The network and configuration component 1104 provides IP (Internet Protocol) address allocation, communication window configuration, routing table configuration, and scan interval management. Network configuration data may include routing tables for seamless data flow between devices, gateways, and cloud systems.

[0068] In one embodiment, the network and setup component 1104 may implement encryption protocols to protect IoT device data, gateway data, and cloud-directed data. The network and setup component 1104 manages security keys, certificates, or authentication tokens used for device communication and protocol handshakes. For wireless networks, the network and setup component 1104 adjusts channel selection and frequency hopping modes to minimize interference. The network and setup component 1104 enforces network policies by generating firewall data and access control data (such as ACLs) to restrict unauthorized access.

[0069] The network and configuration component 1104 also supports dynamic network data management, such as IP address management using DHCP or static addressing. For larger networks, the network and configuration component 1104 enables VLAN segmentation to separate service flows and optimize communication flows. The network and configuration component 1104 is configured to synchronize with a time server to provide accurate timestamps, supporting timestamped communication data for logging and monitoring.

[0070] In one embodiment, the network and setup component 1104 interacts with a network discovery protocol (such as mDNS or UPnP) to identify new IoT devices and process their network access. The network and setup component 1104 may also implement Quality of Service (QoS) policy data received from the configuration server 1500 to prioritize specific types of traffic, such as real-time sensor alerts, over non-critical data flows. The configuration settings maintained by the network and setup component 1104 can be locally coordinated on network 108 with other gateways 1200, 1300. Alternatively, the configuration settings can be synchronized with a cloud system in the cloud analytics layer 1006 to maintain consistency across gateways 1100. The network configuration may also include backup configuration files, allowing gateways to switch to alternative communication settings during network outages to ensure continuous connectivity.

[0071] In one embodiment, gateway processor 1102 includes operating system component 1106. Operating system component 1106 may generate resource management data to perform operations attributed to component 1106. Resource management data is included in gateway data generated at the gateway level. Alternatively, resource management data may be referred to as gateway data for operations performed for operating system component 1106. Gateway 1100 may include a dedicated operating system module to perform the functions of operating system component 1106. Alternatively, processor 1102 may be configured to perform operating system functions.

[0072] Operating system component 1106 is responsible for the synchronization of network drivers, security protocols, and software modules. Gateway data generated by operating system component 1106 enables task prioritization and thread scheduling based on real-time conditions. Operating system component 1106 is responsible for efficient allocation of CPU cycles, ensuring that critical operations (including packet forwarding and protocol conversion) are executed without delay. Lower-priority tasks (such as background monitoring) are scheduled according to process management data. Operating system component 1106 can also implement interrupt handling routines, instructing processor 1102 to respond immediately to time-sensitive events, such as incoming IoT device data packets from IoT device 1010.

[0073] Operating system component 1106 provides management of memory 1150. Operating system component 1106 can dynamically allocate and release memory blocks to ensure that processes operating on gateway 1100 have the necessary resources while avoiding memory conflicts. In one embodiment, operating system component 1106 manages a virtual memory system, exchanging data between physical memory and storage devices to optimize performance under different workloads. Memory 1150 may further include the generation and maintenance of logs to support monitoring and diagnostics of gateway activity.

[0074] In one embodiment, gateway processor 1102 includes container management component 1108. Gateway 1100 may include a dedicated container management module to perform the functions of container management component 1108. Alternatively, processor 1102 may be configured to perform container management functions.

[0075] The container management component 1108 is configured to provide deployment, execution, and management of containerized applications within gateway 1100. Container management component 1108 is also responsible for resource isolation, enabling containers to operate independently to avoid conflicts. Container deployment data allocates CPU cycles, memory, and storage resources to each container. Container management component 1108 can also define namespaces and control groups (cgroups) to monitor resource consumption in real time. If a container performs poorly or encounters an error, container management component 1108 can enable gateway 1100 to restart or replace the container without affecting the entire system 1100.

[0076] In another embodiment, container management component 1108 supports the deployment of Snaps or self-included packages. Snaps can bundle all necessary dependencies with the application, providing consistency and minimizing compatibility issues across different environments. Component 1108 provides Snapcraft tools to manage the installation, updates, and rollback of Snaps. Snaps can be deployed in read-only mode to maintain system integrity, while specifying writable data or configuration areas.

[0077] Container management component 1108 performs orchestration functions, managing the lifecycle of multiple containers by scheduling the start, stop, and restart processes based on predefined triggers or performance conditions. Component 1108 ensures that containers operate autonomously while remaining synchronized with the operation of system 100. For example, if a firmware update is deployed as a container, orchestration component 1108 can initiate the update at low-volume intervals to avoid service interruptions. In some implementations, component 1108 communicates with an external container registry to pull updated container images, ensuring that gateway 1100 always runs the latest, secure versions of software modules.

[0078] In one embodiment, gateway processor 1102 includes IoT radio 1110. Gateway 1100 may include a dedicated IoT radio module to perform the functions of the IoT radio. Alternatively, processor 1102 may be configured to perform IoT radio functions. IoT radio 1110 is responsible for wireless connectivity with IoT device 1010 via protocols such as BLE, Zigbee, LoRa, or Wi-Fi. IoT radio 1110 scans for incoming broadcast packets from IoT device 1010 and transmits data between IoT device 1010 and gateway 1100 via network 102. IoT radio 1110 can operate in broadcast and / or connection-oriented modes, supporting simultaneous communication with multiple devices. IoT radio 1110 can also manage frequency hopping and signal strength thresholds to avoid interference and ensure reliable connectivity. IoT radio 1110 is configured to dynamically adjust transmission power levels based on proximity to devices to save energy. In one embodiment, IoT radio 1110 is responsible for synchronizing the connection intervals of devices communicating with it, ensuring efficient packet transmission and minimizing collisions.

[0079] The IoT radio 1110 provides adaptive channel selection to reduce interference from co-located networks. The IoT radio 1110 supports dynamic power adjustment based on device proximity, saving energy. In dense environments where multiple wireless devices operate simultaneously, the IoT radio 1110 can dynamically switch transmission frequencies to avoid channel congestion. The IoT radio 1110 can perform real-time monitoring of spectrum activity and adjust its operating frequency based on interference levels. The IoT radio 1110 can implement spread spectrum techniques, such as frequency hopping spread spectrum (FHSS), to improve signal stability by transmitting small blocks of data across multiple channels at short intervals. In one embodiment, the IoT radio 1110 is responsible for real-time spectrum monitoring and implementing spread spectrum techniques (such as FHSS) to improve signal stability and ensure uninterrupted communication.

[0080] The IoT radio 1110 further supports multi-protocol communication by managing protocol stacks corresponding to multiple IoT standards (such as BLE, Zigbee, or LoRa), enabling the gateway 1100 to connect to heterogeneous IoT devices 1010. The IoT radio 1110 can operate in a synchronous multi-channel mode, allowing it to communicate with devices simultaneously across different protocols. In one embodiment, the IoT radio 1110 provides a timing synchronization mechanism to ensure that the communication window is aligned with the IoT device 1010, reducing latency and minimizing retransmissions due to packet loss. In one embodiment, the IoT radio 1110 is responsible for optimizing packet delivery using an SNR threshold and for encrypted radio-level communication to protect wireless transmissions from unauthorized access.

[0081] In one embodiment, IoT device discovery and authentication is initiated by IoT radio 1110 within gateway 1100 by scanning broadcast messages from IoT device 1010. The broadcast messages may be included in IoT device data generated by IoT device 1010. In one embodiment, IoT device 1010 is a BLE-enabled device. The broadcast packets may be transmitted on multiple BLE channels, and radio 1110 switches between these channels during predefined scanning parameters to ensure that no device broadcasts are missed.

[0082] In one embodiment, when a new BLE IoT device initiates communication, it transmits a broadcast packet as part of its data over a BLE channel specified in network 102. Upon detecting the broadcast packet, IoT radio 1110 extracts information such as the BLE IoT device's unique identifier and service data. IoT radio 1110 then initiates a connection request to the BLE IoT device, signaling its intention to establish a connection. The BLE IoT device responds, and the gateway completes a handshake by allocating connection parameters (including connection interval and monitoring timeout) to manage continuous communication. After the connection is established, gateway 1100 synchronizes with the BLE IoT device to maintain communication and ensure stable data exchange.

[0083] The BLE standard supports three different communication topologies to accommodate varying network requirements and power efficiency needs between IoT devices 1010 or between IoT devices 1010 and gateways 1100. First, BLE allows one-to-one communication between devices in a connection-oriented mode. In this mode, a stable connection is established between devices to facilitate continuous data exchange. Second, BLE supports one-to-one communication in a connectionless mode, where data packets can be transmitted without establishing a persistent connection, enabling faster interaction and saving power. Finally, BLE supports one-to-many communication topologies in a connectionless broadcast mode, where a single device can simultaneously transmit data to an unlimited number of receiving devices. This broadcast mode further supports mesh networking capabilities, enabling the interconnection of tens of thousands of devices in a scalable and distributed communication framework.

[0084] In BLE networks, asymmetric roles can be assigned to devices based on power availability and functional responsibilities to optimize overall network power consumption. Devices with larger, more reliable power sources (such as those powered by high-capacity batteries, like smartphone batteries, or connected by wired power) handle tasks requiring higher power consumption. These tasks might include managing large volumes of data exchange, maintaining continuous broadcast transmissions, or acting as a primary communication node in the network. Conversely, IoT devices operating with smaller power sources (such as coin cells) are assigned priority to low-power roles, performing less power-intensive tasks to extend their operational lifespan within the network.

[0085] BLE standard version 5.4 supports Periodic Broadcast with Response (PAwR), a feature that enables bidirectional communication between gateway 1100 and a large number of IoT devices 1010 in a centralized star topology. PAwR allows a single gateway (such as gateway 1100) to receive cloud-directed data from hundreds or even tens of thousands of IoT devices 1010 and transmit gateway data to them. By incorporating PAwR into the communication protocol, gateway 1100 can manage synchronous communication in large-scale IoT deployments without establishing separate connections with other devices, thus providing efficient data exchange throughout the perception layer 1002.

[0086] The PAwR function utilizes two core elements of the BLE standard: Extended Broadcast and Periodic Broadcast. In Extended Broadcast, the broadcast IoT device 1010 transmits IoT device data as broadcast packets through one or more of the three broadcast channels defined by the BLE standard. Extended Broadcast packets may not contain broadcast data. Instead, the broadcast packet includes a secondary packet pointer, which directs the gateway 1100 to the secondary broadcast channel transmitting the secondary broadcast packets. The secondary packet pointer also provides timing information, enabling the gateway 1100 to locate these secondary broadcast packets. These secondary packets can include more data than traditional broadcast packets, supporting the transmission of multiple data segments via "chained" packets.

[0087] In one embodiment, periodic broadcasting enables gateway 1100 to synchronize with a continuous sequence or “sequence” of broadcast packets transmitted by IoT device 1010. Gateway 1100 first identifies and processes auxiliary broadcast packets during the extended broadcast phase. Timing information included in the auxiliary broadcast packets allows gateway 1100 to align with the timing of the periodic broadcast sequence, enabling it to predict the arrival of subsequent packets. This synchronization provides gateway 1100 with consistent intervals for receiving IoT device data from IoT device 1010 and transmitting gateway data to it via network 102, ensuring efficient management of large-scale device communication while minimizing latency and packet loss.

[0088] In one embodiment, the PAwR function supports scalability by enabling multiple IoT devices 1010 to communicate with gateway 1100 using synchronized time slots. IoT devices 1010 can be assigned specific time slots to transmit or receive data, reducing collisions and ensuring ordered communication. Therefore, gateway 1100 can manage communication with numerous devices in a structured manner, ensuring seamless data flow in environments with thousands of devices operating simultaneously. This function ensures that gateway 1100 maintains an organized communication protocol with connected IoT devices, aligning data transmission times with periodic broadcast scheduling to ensure reliable data exchange within system 100.

[0089] In one embodiment, gateway processor 1102 includes edge connectivity module 1112 (also referred to as gateway coordination and edge management component 1112 or edge module 1112). Edge connectivity module 1112 may generate edge configuration data to perform operations attributed to edge module 1112. Alternatively, the edge configuration data may be referred to as gateway data for operations performed for edge connectivity module 1112. Gateway 1100 may include a dedicated edge module to perform the functions of edge module 1112. Alternatively, processor 1102 may be configured to perform the functions of edge connectivity module 1112.

[0090] In one embodiment, edge connectivity module 1112 is configured to manage device connectivity, device allocation, and resource allocation across multiple gateways. Upon receiving a broadcast message, edge connectivity module 1112 can extract IoT device data, including security tokens, payload data, unique device identifiers, and service UUIDs embedded in IoT device data packets. Edge connectivity module 1112 is configured to handle load balancing, distributing communication traffic evenly across gateways to avoid congestion. Furthermore, edge management functions include filtering, aggregating, and deduplicating data received from multiple IoT devices 1010. Edge connectivity module 1112 can also execute local rules or event triggers to perform actions at the edge, reducing the need for cloud-based decision-making. In one embodiment, edge connectivity module 1112 is configured to manage device configurations and report status updates via network 104, and is responsible for synchronization with the cloud platform on cloud analytics layer 1006.

[0091] In one embodiment, edge connectivity module 1112 is configured to provide dynamic device onboarding and authentication by managing the exchange of keys and credentials during the initial connection phase. This functionality ensures that authorized IoT device 1010 can establish a connection with gateway 1100. Edge connectivity module 1112 can receive health and availability information for connected devices and gateways. In the event of gateway failure or device timeout, edge connectivity module 1112 can initiate a failover procedure to reconnect the device to an alternative gateway (such as 1200 or 1300).

[0092] Edge connectivity module 1112 can implement predictive algorithms to predict potential congestion in communication traffic based on current usage patterns and historical data. In one embodiment, edge connectivity module 1112 manages a virtual addressing scheme by assigning virtual MAC addresses (vMACs) to devices and gateways. Virtual addressing supports seamless roaming across multiple gateways 1100, 1200, and 1300 without requiring IoT devices to re-establish secure sessions or reconfigure communication settings. Furthermore, edge connectivity module 1112 can perform local data retention in memory 1150 to temporarily store device-generated events in the event of cloud connectivity loss and forward data once connectivity to the cloud via network 104 is restored.

[0093] In one embodiment, edge connectivity module 1112 is responsible for local monitoring and control. Edge connectivity module 1112 continuously monitors the status of the connected IoT device 1010 in real time by collecting data packets from IoT device data transmitted via IoT radio 1110. In one embodiment, data packets are processed locally by analyzing device status indicators included in the IoT device data. Device status indicators include sensor readings, battery level, and connectivity status. Edge connectivity module 1112 can compare the device status indicators with pre-configured thresholds or rules to detect anomalies or trigger specific actions as described below.

[0094] In one embodiment, when edge module 112 identifies a triggering condition from IoT device data that requires immediate action, edge module 112 transmits control commands from edge configuration data to the relevant IoT device 1010 via local network 102. For example, if data received from a sensor indicates an abnormal temperature, edge module 112 may trigger an actuator connected to gateway 1100 to open a valve or adjust a thermostat. The execution of the control task can bypass clouds to minimize latency and ensure a fast response time. The edge configuration data executes commands to the IoT device via local network 102, thereby performing the control task.

[0095] In one embodiment, edge connectivity module 1112 triggers event-driven actions based on real-time IoT device data received from connected IoT devices 1010, such as sensors or actuators. Pre-configured rules stored locally in memory 1150 define specific actions for various conditions. For example, if a connected leak sensor detects water, edge connectivity module 1112 can immediately trigger a valve actuator to cut off the water flow, preventing further damage. These rules can be executed locally by edge connectivity module 1112 for low-latency responses without cloud intervention.

[0096] Gateway 1100 maintains event triggers and local rules for specific scenarios, stored in memory 1150. Event triggers and local rules may be included in configuration data generated by configuration server 1500 based on user instructions. Configuration server 1500 transmits configuration data to gateway 1100. Configuration data may include adding new triggers, modifying thresholds, or adjusting actions related to specific events. Operating system component 1106 ensures that updated rules are synchronized without interrupting ongoing operations, applying changes in real-time or during low-traffic intervals. Event triggers allow edge connectivity module 1112 to autonomously initiate actions based on predefined conditions. In one embodiment, configuration data may be received from the user in real-time via configuration server 1500 connected to gateway 1100. In another embodiment, edge configuration data generated by edge connectivity module 1112 autonomously initiates actions based on predefined conditions and event triggers stored in memory 1150. Event triggers may include commands such as updating an ESL display with a new price, adjusting a temperature control thermostat setting, or activating a lighting system based on store occupancy. Gateway 1100 processes and relays the event triggers via network 102 to the relevant IoT device 1010 for immediate execution. Event triggers can also include complex workflows, such as triggering multiple actuators or generating alerts for specific stakeholders when certain thresholds are exceeded.

[0097] The IoT radio 1110 captures raw data packets from IoT device data via network 102, including sensor readings and device status updates. The edge connectivity module 1112 can apply filtering algorithms to suppress unnecessary or redundant information. For example, the edge connectivity module 1112 can discard packets containing recurring sensor data within short timeframes or data exceeding a predefined range. An aggregation process combines multiple readings (such as hourly average temperature) from the IoT device data into a consolidated dataset to minimize transmission size and reduce bandwidth consumption.

[0098] Edge connectivity module 1112 can also perform deduplication by identifying and removing duplicate messages received from multiple gateways and IoT devices to provide a clean dataset before transmission over network 104 to cloud analytics layer 1006. Edge connectivity module 1112 can compare packet identifiers, timestamps, and device IDs to detect redundant entries in IoT device data and gateway data.

[0099] During protocol conversion, edge connectivity module 1112 can convert IoT device data (BLE, Zigbee, or LoRa-specific formats) received from IoT device 1010 into internet-based protocols (such as MQTT or HTTPS) for use by cloud analytics layer 1006. Furthermore, edge connectivity module 1112 can convert incoming configuration data from cloud analytics layer 1006 into syntax and timeslots conforming to BLE or Zigbee protocol requirements, and then transmit the configuration data to IoT device 1010. Edge connectivity module 1112 can also apply security measures, such as reformatting the payload with an encrypted header, to ensure that the converted data complies with security policies during transmission.

[0100] In one embodiment, edge connectivity module 1112 is responsible for load balancing and resource management across multiple gateways (such as gateways 1100, 1200, and 1300). Edge connectivity module 1112 can dynamically monitor traffic load, device connectivity, and resource availability across gateways to ensure even distribution of communication.

[0101] Edge connectivity module 1112 provides resource management by maintaining routing tables and scan intervals for gateways, allowing configuration server 1500 to reassign devices or communication flows to alternative gateways based on redistribution rules in configuration data. Alternatively, redistribution rules may be stored locally in gateway 1100. When a device (such as IoT device 1010) establishes a connection, edge connectivity module 1112 can assess real-time network conditions to determine the optimal gateway. If a gateway becomes congested, edge connectivity module 1112 can initiate device assignment to another gateway without interrupting communication with the IoT device. In one embodiment, edge configuration data can trigger device assignment to another gateway.

[0102] In one embodiment, gateway 1100 communicates with configuration server 1500 and application servers 1600 and 1700 via network 104. Cloud-oriented data is generated by gateway 1100 and transmitted to configuration server 1500 and application servers 1600 and 1700. Configuration data is generated by configuration server 1500 and transmitted to gateway 1100. Application data is generated by application servers 1600 and 1700 and transmitted to gateway 1100. User terminals (not shown) can connect to configuration server 1500 and application servers 1600 and 1700 to receive data for bidirectional data exchange between the user and the cloud server. User terminals may include personal computers, PDAs, smartphones, tablets, or other mobile and desktop computing devices that allow users to access and interact with network management and monitoring interfaces.

[0103] In one embodiment, edge connectivity module 1112 implements predictive routines to predict future congestion based on historical traffic patterns generated from IoT device data. The predictive routines provide resource reallocation by offloading specific IoT devices to less burdened gateways during peak periods. The predictive routines and resource quotas are included in configuration data received from configuration server 1500. The configuration data may be received in real-time from configuration server 1500 or stored locally at gateway 1100. Resource quotas regulate container management within the gateway, giving critical processes higher priority than non-essential processes to maintain operational efficiency.

[0104] In one embodiment, edge connectivity module 1112 manages firmware and configuration updates for connected IoT device 1010. Configuration data received from configuration server 1500 may include firmware and configuration updates. Updates may be cached locally on gateway 1100 for deployment during an optimal window based on network traffic, device status, and resource availability. In one embodiment, edge module 1112 may implement a rollback mechanism to ensure that if an update fails, gateway 1100 restores the device to a previous stable firmware version. Status reports for updates may be sent back to configuration server 1500 by gateway 1100 in cloud-directed data.

[0105] In one embodiment, edge connectivity module 1112 establishes third-party cloud integration with external platforms, such as third-party application servers 1600 and 1700. Gateway 1100 receives application data from application servers on cloud analytics layer 1006. The application data includes application commands, alarms, and triggers that initiate actions at edge connectivity module 1112 or IoT device 1010. For example, application data may include instructions to adjust thermostat settings or update ESL displays. Application data may be stored locally at gateway 1100, allowing for repeated execution without additional instructions from the cloud. Alternatively, real-time instructions within the application data can be provided to meet immediate operational needs.

[0106] In one embodiment, the cloud-oriented data transmitted by gateway 1100 to application servers 1600 and 1700 may include processed IoT device data. The processed IoT device data includes sensor data such as temperature readings, leak detection status, and energy consumption values. The processed IoT device data may also include metadata, unique sensor IDs, timestamps, and battery levels.

[0107] In one embodiment, gateway 1100 receives application data from third-party application servers 1600 and 1700. The application data may include firmware patches, new operating parameters, or control commands from the target IoT device 1010. Edge connectivity module 1112 can handle specific data processing tasks or edge protocol conversions by operating a custom vendor-provided agent, and perform interactions with third-party platforms.

[0108] In one embodiment, network 108 operates within network layer 1004, providing communication between gateways 1100, 1200, and 1300. Inter-gateway data is transmitted between the gateways. This inter-gateway data ensures that connected IoT devices 1010, 1020, 1030, 1040, and 1050 remain operational even when moved between different gateway coverage areas. Inter-gateway data supports information exchange between gateways 1100 to manage device allocation and load distribution. Communication on network 108 may utilize Ethernet or a Wi-Fi-based LAN protocol, depending on the site's infrastructure. Edge connectivity module 1112 generates, processes, and transmits inter-gateway data.

[0109] In one embodiment, networks 104 and 106 establish a communication link between network layer 1004 and cloud analytics layer 1006. Network 104 provides bidirectional data transmission between gateways 1100, 1200, and 1300 and configuration server 1500. Network 106 provides bidirectional data transmission between gateways 1100, 1200, and 1300 and application servers 1600 and 1700. Networks 104 and 106 can provide local LAN connectivity within a site, or uplink connectivity to the cloud via a public or private internet, or both. The network architecture supports secure communication protocols and efficient data formats, ensuring reliable data transmission and minimal latency.

[0110] In one embodiment, communications on networks 104 and 106 are protected using Transport Layer Security (TLS) to safeguard data from unauthorized access during transmission. Gateway 1100 may use AES encryption to initiate encrypted sessions to provide end-to-end data confidentiality and integrity. In one embodiment, an authentication token or session key is attached to data packets to ensure that authorized devices and cloud services can exchange information.

[0111] In one embodiment, communication provided by networks 104 and 106 from network layer 1004 to cloud analytics layer 1006 operates based on Internet Protocol (IP) protocols, including HTTPS, MQTT, or WebSocket, depending on the application. In one embodiment, data transmitted over networks 104 and 106 undergoes protocol conversion and reformatting at the gateway level to ensure compatibility with cloud services. Data may be sent by gateway 1100 in one or more formats, such as JSON, XML, protobuf, CBOR, or others. In one embodiment, compressed data batches are transmitted to reduce bandwidth usage by grouping multiple sensor readings or events into a single payload.

[0112] Edge connectivity module 1112 is responsible for aggregating and filtering IoT device data sent from gateway 1100 to the cloud server for processing. In one embodiment, event-driven messages (such as temperature anomalies or security alarms) are sent to cloud analytics layer 1006 to reduce traffic. Regular telemetry data (such as environmental metrics) can be batched and transmitted at scheduled intervals to optimize network efficiency.

[0113] In one embodiment, a custom API or vendor-specific platform (such as Azure IoT Hub or AWS IoT) is integrated through networks 104 and 106, enabling seamless cloud interaction. In one embodiment, network 104 provides cloud-to-gateway communication by transmitting configuration data from configuration server 1500 to gateway 1100. When data from the cloud is formatted for cloud-level transmission, such as in JSON, XML, protobuf, CBOR, or other formats, the data can be reformatted at the gateway level to correspond to the protocols or configurations used by the connected IoT device 1010. For example, configuration data sent from configuration server 1500 in JSON format can be parsed and reassembled into BLE-compatible broadcast packets or Zigbee commands for delivery to IoT device 1010. In one embodiment, gateway 1100 applies a data compression algorithm during data reformatting to reduce overhead within network layer 1004.

[0114] System 100 includes a cloud analytics layer 1006 (also known as service layer 1006 or cloud layer 1006). The cloud analytics layer 1006 interacts with the network layer 1004 and gateways 1100, 1200, and 1300, receiving aggregated data, transmitting configuration updates, and coordinating the operation of the entire network 100. The cloud analytics layer 1006 includes a configuration server 1500 and application servers 1600 and 1700. The servers can also perform data aggregation and analysis routines on processed IoT device data and cloud-oriented data received from gateway 1100.

[0115] In one embodiment, the cloud analytics layer 1006 receives cloud-oriented data from the gateway 1100 via networks 104 and 106 to enable centralized control and management of network 100. The cloud-oriented data may include processed IoT device data, real-time device metrics, status updates, and event-driven messages. The cloud analytics layer 1006 processes the cloud-oriented data to generate insights, alerts, or operational recommendations. Configuration data transmitted from the cloud analytics layer 1006 to the gateway 1100 includes configuration changes, firmware updates, and operational rules. The configuration data ensures that the IoT device 1010 operates according to predefined policies.

[0116] Furthermore, any process, operation, or function attributed to a specific component of the configuration server 1500 can be executed by executing configuration data generated by the configuration server 1500. Additionally, processes, operations, and configurations associated with components of the configuration server 1500 can be executed as steps in a method for implementing said function.

[0117] In one embodiment, configuration server 1500 operates as the primary control node within cloud analytics layer 1006. Configuration server 1500 transmits configuration data to gateways 1100, 1200, and 1300 via network 104 to manage and synchronize the gateways. Configuration data received from configuration server 1500 includes configuration updates, management instructions, operating rules, status configurations, recipes, and infrastructure updates. Configuration data may also include parameters such as scan intervals, device onboarding policies, and device allocation coordination settings. Configuration data may also include software patches or parameter adjustments. Configuration data may also include device allocation information, load distribution metrics, and event triggers. Gateway 1100 locally applies the configuration data to one or more connected IoT devices 1010. Furthermore, targeted configuration updates can be directed to specific IoT devices 1010 for personalized operational adjustments. The configuration data provides operating rules, device allocation configurations, and load balancing policies for gateways 1100, 1200, and 1300, and can be uniformly applied across the entire site through inter-gateway data. Configuration data may include real-time instructions, operating policies, device-specific rules, and device allocation instructions. The configuration data ensures that gateways 1100, 1200, and 1300 perform device migration, load balancing, threshold checking, and network management tasks.

[0118] In one embodiment, configuration server 1500 includes a memory 1522 for storing configuration data. The configuration data stored in memory 1522 can be dynamically updated based on network performance and operational requirements. Configuration server 1500 transmits configuration data to gateway 1100, which can locally cache the configuration data. The cached configuration data ensures that gateway 1100 remains functional during intermittent interruptions to cloud connectivity.

[0119] Configuration server 1500 can provide secure communication with gateway 1100 through TLS encrypted channels and authentication mechanisms.

[0120] In one embodiment, configuration server 1500 receives user instruction data from connected user terminals (not shown). The user instruction data may include device allocation policies, threshold parameters for event triggers (e.g., temperature limits or signal strength thresholds), load balancing configurations, firmware update scheduling, and adjustments to network parameters such as IP address allocation and scan intervals. Configuration server 1500 processes the user instruction data and converts it into executable commands. Based on the user instruction data, configuration server 1500 transmits configuration data to connected gateways 1100, 1200, and 1300 to implement network-wide changes.

[0121] User instruction data may also include modifications to recipes and operating rules, stored and managed by the recipe management component 1506. User instruction data may include updating device configuration files, defining new event triggers, or modifying Quality of Service (QoS) policies for prioritized data transmission. In response, the configuration server 1500 generates device status data, including real-time status reports, gateway performance metrics, device health indicators, and logs of executed operations. Device status data may be generated based on cloud-directed data received from the gateway 1100. Device status data may be transmitted to user terminals for monitoring.

[0122] In one embodiment, configuration server processor 1502 includes a state configuration engine 1504. State configuration engine 1504 can generate configuration data to perform operations attributed to engine 1504. Configuration server 1500 may include a dedicated state configuration engine 1504. Alternatively, processor 1502 may be configured to perform the functions of state configuration engine 1504.

[0123] The State Configuration Engine 1504 manages the generation, processing, and distribution of configuration data across gateways 1100, 1200, and 1300. Engine 1504 analyzes real-time cloud-oriented data received from the gateways, including monitoring data such as device status metrics, performance logs, and alerts. Based on this analysis, the State Configuration Engine 1504 generates configuration data that includes operating rules, infrastructure updates, and device-specific commands. This configuration data allows for adjustments to gateway parameters, such as device allocation policies, device access protocols, or load balancing rules, to align with current network conditions.

[0124] The status configuration engine 1504 processes user instruction data received from user terminals connected to the configuration server 1500. This user instruction data can modify device rules, update gateway configurations, or create new event triggers. Engine 1504 incorporates the user instruction data into new or existing configuration data and synchronizes the configuration data between gateways via network 104. The configuration data ensures that operational changes are applied locally by the edge connectivity module 1112 at the gateway, ensuring compliance with updated policies and real-time network requirements.

[0125] The state configuration engine 1504 coordinates the exchange of data between gateways on network 108, and is responsible for the distributed execution of configuration data. The inter-gateway data exchanged between gateways includes device allocation information, load balancing metrics, and synchronization signals. Engine 1504 ensures that gateway 1100 implements consistent state transitions across multiple sites by uniformly applying configuration data. For example, if configuration server 1500 detects an overloaded gateway through incoming monitoring data, state configuration engine 1504 generates configuration data that triggers device allocation operations, distributing connected devices to adjacent gateways without interrupting operations.

[0126] In one embodiment, configuration server processor 1502 includes recipe management engine 1506. Recipe management engine 1506 can generate configuration data to perform operations attributed to engine 1506. Configuration server 1500 may include a dedicated recipe management engine 1506. Alternatively, processor 1502 may be configured to perform the functions of recipe management engine 1506.

[0127] The recipe management engine 1506 generates and distributes configuration data, including predefined operational workflows (recipes), to gateways 1100, 1200, and 1300. A recipe defines a sequence of tasks or actions that gateway 1100 and connected IoT devices 1010 must perform under specific conditions. Recipes can include gateway rules, device control commands, and event triggers to ensure coordinated operation of multiple components within the IoT devices and gateways. The configuration data generated by the recipe management engine 1506 provides the gateways with instructions to execute recipes locally, such as automating device onboarding routines or multi-actuator control workflows.

[0128] The recipe management engine 1506 processes user instruction data received from terminals connected to the configuration server 1500, allowing users to modify, update, or create new recipes. Updated recipes are packaged into configuration data and transmitted to the gateway via network 104. The configuration data ensures that the gateway 1100 autonomously applies recipes in response to predefined conditions detected by the edge module 1112. For example, the edge module 1112 can trigger recipes that adjust HVAC settings, activate lighting, and send alarms when a occupancy sensor reports increased store traffic.

[0129] The recipe management engine 1506 coordinates recipe synchronization across gateways via inter-gateway data transmitted over network 108. This inter-gateway data includes active recipe status, synchronization timestamps, and device allocation changes, ensuring consistent execution across the entire site. If a gateway fails, the recipe management engine 1506 ensures recipe continuity by incorporating failover instructions into its configuration data, allowing adjacent gateways to take over pending tasks without interruption.

[0130] In one embodiment, configuration server processor 1502 includes an edge infrastructure management engine 1508. The edge infrastructure management engine 1508 can generate configuration data to perform operations attributed to the engine 1508. Configuration server 1500 may include a dedicated edge infrastructure management engine 1508. Alternatively, processor 1502 may be configured to perform the functions of the edge infrastructure management engine 1508.

[0131] In one embodiment, the edge infrastructure management engine 1508 generates configuration data to manage physical and virtual resources deployed at the gateway level. The configuration data includes infrastructure updates such as scan intervals, network routing parameters, and device inbound policies. This configuration data can be applied locally by gateways 1100, 1200, and 1300 to optimize operations. The edge infrastructure management engine 1508 monitors resource allocation across gateways to ensure that device allocation rules and load balancing policies remain synchronized within the network layer 1004.

[0132] Inter-gateway data transmitted via network 108 enables the edge infrastructure management engine 1508 to coordinate infrastructure management tasks among gateways 1100. This inter-gateway data includes status updates, resource availability metrics, and active device connections. This data is transmitted to the configuration server 1500 in cloud-directed data to provide visibility into network conditions. Based on this cloud-directed data, the edge infrastructure management engine 1508 generates and distributes configuration data, including updated rules for bandwidth allocation, routing adjustments, and device assignments, to maintain system-wide efficiency.

[0133] The edge infrastructure management engine 1508 processes monitoring data generated by the edge module 1112, including device health metrics, communication logs, and error reports. This monitoring data (included in cloud-directed data) enables the engine 1508 to detect infrastructure network congestion or IoT device failures. In response, the edge infrastructure management engine 1508 generates configuration data that includes corrective actions, such as reallocating communication channels, triggering predictive maintenance routines, or activating backup gateways to reduce downtime.

[0134] In one embodiment, configuration server processor 1502 includes an IoT device configuration engine 1510. The IoT device configuration engine 1510 can generate configuration data to perform operations attributed to the engine 1510. Configuration server 1500 may include a dedicated IoT device configuration engine 1510. Alternatively, processor 1502 may be configured to perform the functions of the IoT device configuration engine 1510.

[0135] In one embodiment, the IoT device configuration engine 1510 generates configuration data for a single IoT device 1010. The configuration data includes IoT device-specific parameters such as firmware version, operating thresholds, and control logic settings. These parameters are transmitted to the gateway 1100 to direct the IoT device 1010. The IoT device configuration engine 1510 ensures that the IoT device 1010 operates within defined specifications by synchronizing configuration updates with the gateway 1100. The gateway relays the updated parameters to the corresponding IoT device via network 102.

[0136] The IoT device configuration engine 1510 processes user command data received from connected user terminals to customize device configurations based on real-time operational needs. Configuration data may also include adaptive parameters, such as dynamic performance thresholds or event-specific triggers, which the gateway applies to connected devices.

[0137] In one embodiment, the cloud application interface 1512 in the configuration server 1500 manages the application data exchange between the cloud server 1500 and external application servers 1600 and 1700 via network 110. The cloud application interface 1512 can also convert cloud-oriented data (such as processed IoT device data) from the gateway 1100 into a format compatible with the application servers 1600 and 1700, ensuring seamless integration with third-party platforms. In one embodiment, application data is exchanged between the application servers 1600 and 1700 and the gateway 1100 via network 106.

[0138] In one embodiment, the memory 1522 in the configuration server 1500 may store synchronization schedules, user instruction data, configuration data, operating rules, and gateway settings for network coordination. The memory 1522 includes a data repository 1524 that maintains a comprehensive record, such as monitoring data for diagnostic purposes, historical IoT device data, gateway data logs, and inter-gateway data. The data repository 1524 also stores device profiles, status configurations, recipes, and firmware versions to support real-time updates and event-triggered operations. This structured storage enables the configuration server 1500 to efficiently retrieve and transmit configuration updates or management instructions throughout the network 100.

[0139] Cloud Layer 1006 includes application servers 1600 and 1700, which are responsible for coordinating cloud-oriented data exchange and supporting interaction with third-party platforms. Figure 1 Application servers 1600 and 1700 shown are exemplary, and a reference to one application server (such as application server 1600) may also cover other servers (such as application server 1700). The number or configuration of application servers is not limited to those shown. In various embodiments, additional or fewer application servers may be deployed depending on system architecture or operational requirements.

[0140] Furthermore, a reference to one application server subcomponent can also refer to a corresponding subcomponent of another application server. For example, a reference to a vendor cloud service in application server 1600 can also refer to vendor cloud service 1702 in application server 1700. Similarly, a reference to enterprise cloud application 1604 in application server 1600 can refer to enterprise cloud application 1704 in application server 1700. Additionally, a reference to Azure service 1606 in application server 1600 can include Azure service 1706 in application server 1700.

[0141] Furthermore, any process, operation, or function attributed to a specific component of application server 1600 can be executed by executing application data generated by application server 1600. Application data generated by any component of application server 1600 provides the instructions or inputs required to perform the operation. Additionally, processes, operations, and configurations associated with components of application server 1600 can be executed as steps in a method to implement the function.

[0142] Application server 1600 receives cloud-directed data from the gateway, including processed IoT device data and monitoring data, to perform real-time analytics, generate operational insights, and issue alerts based on predefined conditions. Application server 1600 generates and transmits application data back to the gateway. Application data includes control commands, event triggers, and updates. Application data generated within application server 1600 can also be stored locally at gateway 1100, allowing for the repeated execution of control operations without requiring new instructions for the task, reducing latency and reliance on cloud connectivity.

[0143] Application server 1600 can interact with cloud configuration server 1500 to synchronize operation policies and configuration updates across the entire network 110.

[0144] In one embodiment, application server 1600 connects to a user terminal (not shown) to provide an interface for external customers and third-party vendors utilizing IoT devices within system 100. Application server 1600 processes user instruction data, transmitting real-time instructions to gateway 1100 or initiating specific actions at edge module 1112. User instruction data may include service requests, operation commands, or configuration preferences provided by customer or vendor systems. User instruction data may also include tasks such as initiating device-specific operations, adjusting ESL display content, scheduling device activities, or requesting analytics reports generated from IoT device data. The user instruction data processed by application server 1600 can trigger operations communicated via a gateway at edge connectivity module 1112 or on IoT device 1010.

[0145] In one embodiment, application server 1600 includes vendor cloud service 1602, enabling third-party vendors to interact with the deployed IoT device infrastructure. User instruction data may include commands to adjust the operation of IoT devices, such as modifying ESL display content or scheduling executor activities. Upon receiving user instruction data, vendor cloud service 1602 generates corresponding application data. The application data is transmitted to gateway 1100 via network 104, where it is either executed locally by edge connectivity module 1112 or relayed to the appropriate IoT device 1010 for operational control.

[0146] Vendor cloud service 1602 can generate application data corresponding to specific vendor-defined protocols or device standards. For example, the application data generated by vendor cloud service 1602 can instruct gateway 1100 to adjust sensor configurations, update displays, or initiate environmental changes in real time. Vendor cloud service 1602 also allows third-party systems to maintain consistent interaction with connected IoT devices by storing operational settings locally within the gateway, enabling repetitive actions without frequent cloud communication.

[0147] Vendor cloud service 1602 additionally provides a feedback mechanism by receiving and transmitting user command data based on monitoring data received from IoT devices and gateways. This feedback loop allows vendors to track the operational performance of connected IoT devices or detect anomalies.

[0148] In one embodiment, application server 1600 includes enterprise cloud application 1604 configured to provide integration between IoT infrastructure and enterprise-level systems such as resource planning tools, inventory management platforms, or customer relationship management (CRM) systems. The cloud application generates application data based on user instruction data received from the enterprise systems, which may include commands to adjust operational workflows, trigger alarms, or synchronize device activity with enterprise processes. For example, enterprise cloud application 1604 may generate application data instructing gateway 1100 to adjust warehouse lighting scheduling based on occupancy data or update ESL displays according to inventory levels. The application data is transmitted via network 104 to gateway 1100 for local execution or relayed to appropriate IoT devices 1010. Furthermore, the application data may include operational adjustments such as task scheduling, sensor configuration, or actuator commands. Enterprise cloud application 1604 can process monitoring data from IoT devices 1010 and gateway 1100 to track performance metrics, inventory status, or system anomalies. Monitoring data enables enterprises to monitor key performance indicators and adjust workflows in response to changing operational needs.

[0149] In one embodiment, application server 1600 includes Azure service 1606, providing a cloud-based interface for integrating IoT infrastructure with the Microsoft Azure cloud solution suite. Azure service 1606 is responsible for the exchange of cloud-oriented data between gateway 1100 and the Azure platform for advanced data processing, machine learning, or analytics. Azure service 1606 can receive IoT device data collected by gateway 1100 and transmit it to the Azure cloud environment for analysis, generating actionable insights for predictive maintenance, anomaly detection, or performance optimization. Azure service 1606 can also manage cloud-based automated workflows by processing user instruction data received from user terminals connected to application server 1600. User instruction data may include commands to schedule device actions, configure sensors, or deploy firmware updates. Application data generated by Azure service 1606 may include task schedulers, alarm triggers, or optimization routines transmitted to gateway 1100 to initiate operations at the edge.

[0150] In one embodiment, the edge management platform (also referred to as the edge connectivity platform or the platform itself) provides a coordinated, unified, and secure data pipeline for aggregating IoT device data from various types of sensors and transmitting control data to IoT device 1010. In one embodiment, the edge connectivity platform is implemented by a gateway-level edge connectivity module 1112 for the management and control of IoT device 1010. The edge connectivity platform is also implemented at the cloud level within the edge infrastructure management engine 1508, enabling centralized monitoring and control of the entire network.

[0151] The edge connectivity platform supports the integration of sensor data across heterogeneous networks, including IoT devices 1010, such as Electronic Shelf Tags (ESLs). The edge connectivity platform communicates via the BLE protocol and coordinates bidirectional communication between IoT devices 1010 and gateways 1100, 1200, and 1300. The edge connectivity platform processes incoming IoT device data from sensors such as leak detectors, occupancy sensors, energy monitors, and temperature sensors, and transmits cloud-oriented data to configuration servers 1500 and application servers 1600 and 1700, thereby providing centralized management and control of a large-scale IoT device 1010 network.

[0152] The edge connectivity platform facilitates low-latency detection and network access for IoT devices 1010, supporting seamless device distribution when IoT devices 1010 move between the coverage areas of gateway 1100 within network 108. By managing load balancing and coordinating device distribution among gateways 1100, 1200, and 1300, the edge connectivity platform distributes IoT device 1010 connections across the network, preventing congestion and optimizing data traffic. The edge connectivity platform also supports security measures such as spoofing detection by identifying unauthorized devices attempting to connect to the network. The platform allocates virtual addresses and implements virtual radios to manage and streamline communication across system 100, enabling consistent identification and processing of IoT devices 1010 across multiple gateways.

[0153] The edge connectivity platform also manages deduplication of broadcast messages received from the same IoT device 1010 by multiple gateways. By filtering duplicate messages, the edge connectivity platform transmits unique IoT device data within cloud-guided data to the cloud analytics layer 1006, reducing data redundancy and improving bandwidth efficiency. Furthermore, the edge connectivity platform synchronizes connections between multiple gateways and the IoT device 1010, ensuring that the IoT device 1010 remains actively connected when moving between gateway coverage areas. This synchronization is advantageous in high-density environments where numerous IoT devices must be managed simultaneously.

[0154] In one embodiment, the edge connectivity platform continuously monitors data consumption across connected IoT devices 1010 and gateway 1100 to provide insights into network usage patterns. The edge connectivity platform relays the integrated monitoring data to application servers 1600 and 1700 for further analysis, enabling application-level device operation control.

[0155] The edge connectivity module 1112 provides functions including establishing and maintaining communication with connected sensors, integrating sensor data from multiple sources, and generating control commands directed to the sensors. The edge connectivity functionality enables the edge connectivity module 1112 to operate as a central node, managing data exchange with the IoT device 1010 in real time and providing coordinated actions such as device onboarding, data filtering, and connectivity management. The edge connectivity module 1112 also supports bidirectional communication with the IoT device 1010 by delivering gateway data using BLE or a similar protocol, ensuring timely control and configuration of connected devices.

[0156] Configuration server 1500 generates configuration data, including parameters and attributes associated with the connected IoT device 1010. This configuration data allows configuration server 1500 to coordinate with edge connectivity module 1112 to synchronize IoT device settings, update operating parameters, and maintain a consistent network configuration across multiple gateways.

[0157] In one embodiment, cloud configuration server 1500 is responsible for stateful configuration to monitor the updates and operational status of connected IoT devices 1010. Cloud configuration server 1500 generates configuration data, including update scheduling, rollout tracking details, and device replacement protocols. Stateful configuration enables cloud server 1500 to dynamically support large-scale deployments, monitoring and updating device status as needed. In the event of errors or hardware replacement, stateful configuration engine 1504 ensures smooth recovery by reapplying stored configuration state to maintain operational continuity.

[0158] Gateways 1100 can be organized into "points" based on specific deployment locations and configuration requirements, enabling System 100 to effectively scale across multiple regions or retail environments. A single site can include multiple gateways, supporting thousands of IoT devices (such as Electronic Shelf Tags (ESLs)) to facilitate comprehensive network management. Site-specific configurations are achieved through configuration data generated by the State Configuration Engine 1504, which defines unique settings and operating parameters for gateways within a site. Configuration variables in the configuration data allow individual gateways 1100 to operate with customized settings, optimizing network behavior for different use cases in various environments, while enabling unified control over large-scale distributed device deployments.

[0159] Site-wide coordination In one embodiment, edge connectivity module 1112 is responsible for site-wide coordination of the network within system 100. Gateways (such as gateways 1100, 1200, and 1300) are interconnected via network 108. This network supports data exchange between gateways, enabling gateways to understand the operation and resource status of other gateways. Edge connectivity modules within gateways generate and are responsible for exchanging data between gateways to coordinate responses to network events.

[0160] Gateways 1100, 1200, and 1300 also connect to cloud servers, specifically configuration server 1500 and application servers 1600 and 1700. The cloud servers can provide operational instructions to the gateways in the form of configuration data and application data. Configuration data includes management instructions, operational rules, and updates defining specific actions and policies across the entire site, such as scan intervals, device allocation rules, and load balancing parameters. Application data may include additional instructions or event triggers for device control, such as actuator commands or display updates. When gateways 1100, 1200, and 1300 receive configuration data or application data, they apply it synchronously, ensuring that all gateways adhere to a consistent policy implemented throughout the site.

[0161] In addition, the edge connectivity module generates and transmits cloud-oriented data to configuration server 1500 and application servers 1600 and 1700. This cloud-oriented data includes network health data and device monitoring data (collectively referred to as monitoring data). Monitoring data may include performance metrics, device health reports, and detailed connection stability information, providing cloud servers with real-time insights into network health and device status. The edge connectivity module within the gateway manages bidirectional communication and aligns data with gateways to ensure consistent synchronization of updates across all gateways in the system.

[0162] In one embodiment, site-wide coordination can be implemented by the site-wide controller 2300, such as... Figure 2 As shown, the full site controller 2300 connects to one or more gateways 2100 and 2200. The full site controller 2300 includes an edge connectivity module that is responsible for full site coordination by managing data exchange between gateways and synchronizing operational responses across connected gateways. Alternatively, the full site controller 2300 may communicate with gateways to handle inter-gateway coordination, rather than inter-gateway data exchange. The edge connectivity module within the full site controller 2300 centralizes tasks such as distributing scan parameters, managing load balancing, and enforcing device allocation rules across all gateways, enabling consistent application of site-wide policies. Furthermore, cloud-directed data (including network health and device monitoring data) can be aggregated by the controller 2300 and sent to the configuration server 2500 for centralized analysis. This centralized architecture allows the full site controller to act as a central node for enforcing operational rules, eliminating the need for inter-gateway data synchronization by performing coordination within the controller 2300 itself.

[0163] Coordinated scan parameters System 100 coordinates scanning parameters across multiple gateways to optimize the capture of broadcasts from various IoT devices. In one embodiment, edge connectivity module 1112 is configured to signal to a radio within the gateway to scan for broadcast messages at specific intervals with one or more parameters, such as specific channels and timing. Scanning parameters within the gateway may refer to the configuration of the gateway's radio module, such as configuring the radio module to actively "listen" on specific broadcast channels within the spectrum. For example, scanning parameters or a set of parameters may specify the interval at which the gateway listens on a set of broadcast channels (such as channels 37, 38, and 39) within the Bluetooth frequency range. IoT device transmissions occur rapidly and continuously on multiple channels, enabling devices to repeatedly broadcast their presence for detection. However, a single gateway can only scan one channel at a time, which may result in missed broadcasts on alternating channels. To address this issue, system 100 implements a coordination mechanism for coordinating scanning parameters across gateways.

[0164] Edge connectivity module 1112 within gateway 1100 manages scanning parameters together with other gateways 1200 and 1300 through inter-gateway data exchange. In one embodiment, edge connectivity module 1112 within gateway 1100 is configured to operate on a preset scan schedule. The preset scan schedule includes allocating scan parameters and timing to gateways. The preset scan schedule is configured to enable neighboring gateways 1100 to operate on different intervals, timing schedules, and broadcast channels, optimizing the coverage and efficiency of broadcast capture from IoT device 1010. By distributing scanning responsibilities among gateways 1100, the system reduces overlap and minimizes missed broadcasts due to channel conflicts. Proximity between gateways can be determined based on the pre-stored MAC addresses or virtual MAC (vMAC) addresses of adjacent gateways. Furthermore, proximity between gateways can be discovered using in-band and / or out-of-band ranging techniques. Edge connectivity module 1112 utilizes proximity data including packet MAC or vMAC addresses of neighboring gateways and coordinates the scanning activities of the gateways accordingly. The preset scan schedule uses inter-gateway data exchanged through network 108 for synchronization. The data between gateways provides a communication path, allowing the edge connection module 1112 to synchronize scanning modes, share scanning schedules, and adjust timing in real time.

[0165] The preset scan schedule can be received or updated by the cloud configuration server 1500 or through user command data from the user terminal. The cloud configuration server 1500 can transmit the preset scan schedule as part of the configuration data to the gateway 1100. The edge connection module 1112 can execute the preset scan schedule locally within the gateway, implementing the allocated scan parameters, scheduling, and broadcast channels. Alternatively, the cloud configuration server 1500 can provide real-time adjustments to the preset scan schedule based on current network conditions or operational requirements, allowing for dynamic allocation and modification.

[0166] For example, if three gateways 1100, 1200, and 1300 are located adjacent to each other within the same operating area, the gateways can be assigned the following preset scan schedule: gateway 1100 is configured to scan on broadcast channel 37 at 20 millisecond intervals, gateway 1200 scans on channel 38 at 25 millisecond intervals, and gateway 1300 scans on channel 39 at 30 millisecond intervals. The timing schedule of the gateways is further interleaved by starting from an offset point. For example, gateway 1100 starts its scan cycle at 0 milliseconds, gateway 1200 starts at 5 milliseconds, and gateway 1300 starts at 10 milliseconds within its cycle.

[0167] In one embodiment, the edge connectivity module applies a preset delay criterion to optimize the discovery process (e.g., service discovery, device discovery, and / or other discovery processes) and IoT device data processing for connected IoT devices. The discovery process may include identifying and establishing communication parameters with IoT device 1010 to determine its capabilities, configuration, and available services. The edge connectivity module is configured to dynamically adjust the discovery process and IoT device data processing based on real-time network conditions and device attributes received via IoT device data. For example, when the edge connectivity module detects a large number of broadcast messages from IoT devices (compared to a threshold level set within the preset delay criterion), the edge connectivity module selectively postpones specific portions of the discovery process or the processing of incoming IoT device data that requires longer processing times. The postponed target portion or incoming IoT data may include device authentication checks, detailed capability queries, or security key exchanges, which may be more time-consuming steps in establishing a connection. By postponing the processing of the target portion or incoming IoT data, the edge connectivity module prioritizes necessary connection or data processing steps, reducing latency in processing large numbers of incoming messages, thereby minimizing overall discovery latency and maintaining efficient device management. The preset delay criterion (also known as a pause criterion) may also include additional attributes, such as device priority, battery level, or specific device classification, to modify the discovery process. For example, devices with low battery indicators or non-critical roles may experience a shortened discovery process, while high-priority devices may be processed completely.

[0168] In one embodiment, a pre-defined scan schedule organizes gateways 1100 into a grid-like scanning pattern within the network. The pre-defined scan schedule specifies that gateways operate alternately within different scan intervals to minimize overlap. For example, gateways located in the "primary" area of ​​the grid are assigned an initial scan time window, while gateways in adjacent "secondary" areas begin scanning in subsequent non-overlapping time windows. This time-based partitioning across the grid reduces redundant scanning work and saves network resources by efficiently distributing the scan load. In dense environments where a large number of broadcast messages from IoT devices may occur simultaneously, grid-based coordination maximizes resource allocation by staggering scan intervals, ensuring that each area captures a unique data packet.

[0169] By assigning different parameters or channels to gateways, the system reduces the possibility of overlapping or "shadow" networks, ensuring full coverage and improving the efficiency of capturing broadcast messages from IoT devices distributed throughout the site. The edge connectivity module 1112 can continuously optimize scanning patterns using inter-gateway data, adapting to changes such as new gateway deployments or variations in IoT device activity. This synchronized configuration minimizes missed broadcasts and prevents connection duplication by distributing scanning responsibilities across sites and dynamically adjusting on demand based on traffic patterns or device density changes.

[0170] In one embodiment, the coordination of scan parameters can be implemented by the full-site controller 2300, such as... Figure 2 As shown. The full-site controller 2300 connects to one or more gateways 2100, 2200, including an edge connectivity module, which coordinates scanning activities and device discovery processes across connected gateways. In this architecture, the full-site controller 2300 replaces the need for edge connectivity modules within gateways, centralizing coordination functions within the controller 2300 to provide synchronization for the network. The full-site controller communicates with gateways to manage scanning parameters, schedule and distribute preset filtering criteria, and adjust discovery process parameters to achieve consistent implementation of policies across the entire network. Alternatively, the full-site controller 2300 may communicate with gateways to handle inter-gateway coordination, rather than inter-gateway data exchange. This centralized architecture allows the full-site controller to act as a central node for enforcing operating rules, eliminating the need for inter-gateway data synchronization by performing coordination within the controller 2300 itself.

[0171] Coordinated device connection In one embodiment, edge connectivity modules 1112, 1212, and 1312 within gateways 1100, 1200, and 1300 are configured to apply preset filtering criteria to broadcast message data received from IoT device 1010. The edge connectivity modules are configured to allow connections to IoT devices that meet the preset filtering criteria. The broadcast message data transmitted by IoT device 1010 includes, but is not limited to, media access control (MAC) address, virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, sensor readings, operational status indications, and other device-specific characteristics. This IoT device data enables the edge connectivity modules to effectively distinguish between various devices and prioritize communications based on operational needs and site-wide coordination. In one embodiment, the edge connectivity modules are configured to respond to broadcast messages by establishing connections only with devices that meet the preset filtering criteria.

[0172] Preset filtering criteria include applying a minimum signal strength threshold. For example, upon receiving broadcast message data, the edge connectivity module verifies whether the IoT device exhibits a signal strength threshold. The filtering criteria specify establishing connections with devices that have stronger signals and higher signal-to-noise ratios (SNR). Broadcast messages above the threshold are more likely to maintain reliable detection, even in environments prone to signal interference. Devices farther from the radio and falling below the signal strength threshold may connect to a closer radio with a higher received signal strength or SNR. The minimum signal strength threshold criteria can be received as configuration data from the cloud configuration server 1500 and stored locally at the edge connectivity module 1112 for execution within the gateway. Alternatively, the cloud configuration server 1500 can dynamically update the signal strength threshold criteria in real time based on current network conditions, device density, or environmental factors. For example, a higher received signal strength threshold can be applied to channels or frequencies experiencing high noise levels or increased channel activity.

[0173] In one embodiment, the filtering criteria include a vMAC address. The vMAC address includes a virtual identifier assigned to IoT device 1010. The allocation of vMAC addresses may occur locally at the gateway level, where edge connectivity module 1112 coordinates the issuance of a unique vMAC to IoT device 1010 according to predefined rules. These predefined rules can be adjusted based on user instruction data received from configuration server 1500, allowing users to update vMAC allocations by specifying priorities, address ranges, or specific device processing requirements. In an alternative embodiment, cloud configuration server 1500 manages the allocation of vMAC addresses within configuration data sent to edge connectivity module 1112. The configuration data may include updates or changes to the vMAC allocation protocol, allowing cloud configuration server 1500 to remotely and dynamically adjust the virtual addressing scheme.

[0174] Edge connectivity module 1112 can assign virtual MAC (vMAC) addresses to radios within a gateway or IoT device infrastructure. In one embodiment, these vMAC addresses are assigned to “virtual radios,” which can be implemented using a single radio or a combination of radios within the IoT device or gateway. A single physical radio can support multiple virtual radios by assigning multiple vMAC addresses. A single vMAC address can correspond to a single radio or a group of radios within the gateway. vMAC assignment enables dynamic management of IoT device connectivity by allowing ESL or other wireless devices to connect to multiple physical radios (identified by a common vMAC address) associated with a shared virtual radio. vMAC assignment supports features such as merging or eliminating copies of broadcast messages received across different physical radios. Furthermore, vMAC addresses enable IoT devices to roam seamlessly between radios under the same virtual radio, maintaining uninterrupted connectivity even when the device moves between coverage areas. vMAC assignment also supports failover transitions. For example, if a physical radio fails, IoT devices connected under the same vMAC address can seamlessly transition to an alternative radio without requiring the wireless device to re-establish its connection. Device details maintained based on MAC addresses enable seamless device assignment by associating the device assignment protocol with the vMAC address used during initial connection.

[0175] Preset filtering criteria enable edge connectivity module 1112 to determine whether a device's broadcast messages meet the attributes stored within the preset filtering criteria. For example, filtering based on MAC address or vMAC address allows edge connectivity module 1112 to distinguish between authorized and unauthorized devices. MAC address provides a hardware-based identifier. vMAC provides the flexibility of virtual address allocation and reallocation. Additional filtering criteria based on device-specific characteristics can provide an additional layer of precision. For example, a combination of broadcast message data, such as a low battery indication combined with a high-priority device tag, can trigger a preset processing protocol for a specific broadcast message based on preset filtering criteria.

[0176] In one embodiment, preset filtering criteria are implemented locally by an edge connectivity module 1112 within the gateway. The edge connectivity module 1112 can store filtering criteria and apply them to incoming broadcast messages from IoT devices. Preset filtering criteria can be updated based on configuration data or user instruction data received from a configuration server 1500, allowing for responsive adjustments to filtering rules based on changing network conditions, user instructions, or operational policies. Alternatively, the filtering process operates through a unified communication interface involving both the edge connectivity module 1112 and the cloud configuration server 1500. The cloud configuration server 1500 can transmit configuration data in real time, including updated filtering criteria, thresholds, or parameters. The configuration data can continuously or periodically optimize the filtering process based on network conditions, device density, or operational requirements. By processing configuration data from the cloud configuration server 1500, the edge connectivity module 1112 dynamically applies the latest filtering rules without interrupting ongoing communication with connected devices. Inter-gateway data is responsible for the synchronous application of preset filtering criteria across multiple gateways. The filtering process can also be coordinated between gateways (such as gateways 1200 and 1300) via inter-gateway data exchanged on network 108. Inter-gateway data allows edge connectivity modules 1112 within a gateway to share filtering criteria, device status information, and operational metrics, maintaining consistent filtering at network layer 1004. This coordination ensures the uniform application of filtering criteria, thereby improving system performance and preventing redundant processing across gateways. Edge connectivity modules 1112 within a gateway can process inter-gateway data to update or adjust filtering criteria as needed, providing a scalable implementation for handling high-density IoT devices in distributed networks.

[0177] In one embodiment, edge connectivity modules 1112, 1212, and 1312 within gateways 1100, 1200, and 1300 coordinate to apply preset filtering criteria in the network. The edge connectivity modules evaluate incoming broadcast messages based on the preset filtering criteria to determine the most suitable gateway for establishing a connection. The preset filtering criteria also include attributes that differentiate the gateway most suitable for establishing a connection with the IoT device when multiple gateways receive the same broadcast message. Preset filtering criteria may include vMAC address specification, highest signal strength, proximity data, cached connection history, device-specific operating status, or predefined device priority tags assigned to a specific gateway. For example, in an instance where multiple gateways detect the same IoT device, the edge connectivity modules implement the filtering criteria, prioritizing connection through the gateway receiving the highest signal strength. Proximity data may include the packet MAC or vMAC addresses of nearby gateways, and the mapped physical location of the gateway or IoT device area. Furthermore, gateway proximity can be determined by pre-stored MAC or vMAC addresses of adjacent gateways.

[0178] In one embodiment, a cloud configuration server can provide configuration data to dynamically adjust the discovery process protocol of the edge connectivity module. The cloud configuration server can transmit parameters, such as updated filtering thresholds or instructions for caching discovery information, enabling the edge connectivity module to respond to changing network traffic and environmental factors. Furthermore, the edge connectivity module can leverage inter-gateway data to coordinate discovery process adjustments across multiple gateways, ensuring consistent standards and caching techniques are applied throughout the network layer.

[0179] Inter-gateway data flow enables continuous synchronization between gateways 1100, 1200, and 1300, allowing edge connectivity modules to monitor the connection status and operational metrics of neighboring gateways in real time. When an IoT device begins broadcasting a message, the edge connectivity module within the gateway applies preset filtering criteria, evaluates the broadcast message attributes, and compares signal strength across gateways. Gateways that meet the criteria (e.g., the closest gateway with the strongest signal) are designated as the primary connection point. Other gateways, upon receiving this selection information via inter-gateway data, will cease their connection attempts, preventing redundant device connections. Inter-gateway data facilitates additional coordination by enabling edge connectivity modules 1112, 1212, and 1312 to dynamically adjust preset filtering criteria based on network-wide conditions. For example, in high-density IoT environments, criteria can automatically adjust signal strength thresholds or prioritize gateways with lower network loads, distributing device connections more evenly across the network.

[0180] By coordinating these vMAC allocations among gateways 1100, 1200 and 1300, edge connectivity module 1112 ensures that neighboring gateways do not initiate redundant connections with the same IoT device 1010.

[0181] In one embodiment, device coordination can be achieved by utilizing, for example... Figure 2The architecture shown is implemented within a centralized full-site controller 2300, which connects to multiple gateways (such as gateways 2100 and 2200). The full-site controller 2300 includes an edge connectivity module that provides centralized full-site coordination by managing and applying preset filtering standards across all connected gateways. This configuration allows the full-site controller to coordinate device connectivity activities by communicating with gateways rather than exchanging data between gateways. The controller 2300 synchronizes connection management based on controller instructions. In this architecture, the full-site controller 2300 applies and updates preset filtering standards in the gateways. Preset filtering standards can be dynamically set and updated by the full-site controller 2300 based on real-time network conditions or operational policies received from a configuration server 2500 or a third-party application server 2400. Alternatively, preset filtering standards can be transmitted from the full-site controller and stored locally within the gateways, allowing gateways to apply standards independently while the controller remains synchronized overall. The full-site controller 2300 communicates with gateways to provide inter-gateway coordination, rather than exchanging data between gateways. This centralized architecture allows the full site controller to act as a central node for enforcing operational rules, eliminating the need for data synchronization between gateways by performing coordination within the controller 2300 itself.

[0182] Pre-approved connection In one embodiment, preset filtering criteria may include a cached history of preferred or previous connections between the IoT device and the gateway. For example, if a broadcast message from the same device is received by multiple gateways, the connection will be preferentially established with the gateway to which the device was previously connected. Furthermore, the preferred connection between the device and the gateway may be pre-stored within the gateway or a cloud configuration server. The edge connectivity module can also improve the discovery process by caching connection details of completed discovery sessions. In one embodiment, the edge connectivity module stores connection data for a specific device type or model and associates it with identifiers within the preset filtering criteria. The cached history of preferred or previous connections can be synchronized at the gateway level by transmitting the cached history within the data between gateways. Additionally, the cached history of preferred or previous connections may be stored at a cloud configuration server 1500. When a new IoT device with similar characteristics initiates the discovery process, the edge connectivity module retrieves the stored connection information, enabling the IoT device to bypass redundant parts of the discovery process. The caching mechanism can reduce processing load by leveraging previous connections to accelerate the discovery of identical or compatible devices.

[0183] In one embodiment, edge connectivity module 1112 applies a pre-approved connectivity and caching mechanism to improve device connectivity. A list of approved devices serves as a preset filtering criterion for processing inbound broadcast messages and initiating connections between preferred or previously connected gateways and IoT devices. For example, if a broadcast message from the same IoT device is detected by multiple gateways, edge connectivity module 1112 can consult its cached history and connect the device to a gateway it previously connected to. Therefore, the edge connectivity module facilitates direct connections between IoT devices and their preferred or previously connected gateways, bypassing the need for repeated discovery processes for the same IoT device. By utilizing cached connectivity data, the edge connectivity module initiates connections, streamlining the reconnection process.

[0184] In one embodiment, a cloud configuration server can provide configuration data to dynamically adjust the discovery protocol of the edge connectivity module. The cloud configuration server can transmit parameters, such as updated filtering thresholds or instructions for caching discovery information, enabling the edge connectivity module to respond to changing network traffic and environmental factors. Furthermore, the edge connectivity module can utilize inter-gateway data to coordinate discovery process adjustments across multiple gateways, ensuring consistent standards and caching techniques across the entire network layer.

[0185] By coordinating vMAC allocation among gateways 1100, 1200 and 1300, edge connectivity module 1112 ensures that neighboring gateways do not initiate redundant connections with the same IoT device 1010.

[0186] Network health and device monitoring data In one embodiment, edge connectivity module 1112 is configured to generate network health data, including metrics such as packet loss, signal strength, response time, latency indication, connection stability, connection failure, response failure, packet retry, and diagnostic error reports. Network health data may also include metrics such as data consumption, noise levels across communication channels, spectrum capacity, and frequency reallocation between gateways. Network noise level refers to interference measurements across communication channels, including external radio frequency interference or overlapping signals from other nearby devices. Spectrum capacity includes the ability of a gateway or access point to manage concurrent data transmission within its designated frequency band. Noise level represents interference across communication channels, including in-band noise from nearby or co-located networks (such as Wi-Fi or other radio traffic). Environmental monitoring data allows edge connectivity module 1112 to assess the impact of noise on the access point and adjust radio parameters accordingly.

[0187] Network health data can be generated at the single gateway level, such as the network health data for gateway 1100. Network health data can also reflect an overall assessment of network conditions across all gateways. To generate network health data, edge connectivity module 1112 can aggregate inter-gateway data exchanged between gateways 1100, 1200, and 1300. Inter-gateway data may include metrics such as packet transmission rate, latency reports, and signal quality indicators. Furthermore, edge connectivity module 1112 integrates IoT device data received from connected IoT device 1010, capturing real-time signal strength, response time, and connection stability.

[0188] In one embodiment, edge connectivity module 1112 generates device monitoring data to assess the health and functionality of IoT devices 1010 connected to the system. Device monitoring data includes attributes such as operational metrics related to device health and availability, battery level, signal strength, communication logs, status reports, performance metrics, connection status, error logs, and uptime. Device monitoring data can be generated by processing IoT device data received at gateway 1100. Device monitoring data can be updated periodically to maintain up-to-date insights into device-specific conditions. Device monitoring data can also be generated based on broadcast messages from IoT devices attempting to connect to capture device health and activity status before full integration into the network. Device monitoring data may also include message count, message frequency, and message reception signal strength.

[0189] Inter-gateway data exchange enables the edge connectivity module 1112 within the gateway to collect comprehensive network health and device monitoring data by aggregating metrics across multiple gateways. The gateway's edge connectivity module 1112 continuously transmits and receives inter-gateway data, which includes individual gateway metrics such as signal strength indications, packet loss rates, and latency measurements from connected IoT devices. Inter-gateway data exchange allows the edge connectivity module to analyze the real-time performance of the entire network, integrating individual metrics into a holistic dataset of network health. For example, as gateways 1100, 1200, and 1300 share inter-gateway data, the edge connectivity modules within these gateways can detect network load fluctuations, spectrum capacity changes, or increases in noise levels at specific locations and adjust their respective configurations accordingly.

[0190] Furthermore, inter-gateway data is responsible for generating device monitoring data by sharing metrics related to the performance and connectivity status of individual IoT devices across gateways. Inter-gateway data includes real-time updates to device status, such as changes in signal strength or connection stability. This information is relayed to other connected gateways, enabling the edge connectivity module to create integrated, up-to-date monitoring profiles for IoT devices.

[0191] Edge connectivity module 1112 can transmit network health data and device monitoring data (collectively referred to as monitoring data) as part of cloud-directed data to configuration server 1500 and application servers 1600 and 1700. The cloud servers can further transmit network health data and device monitoring data to users via user terminals. Configuration server 1500 can process monitoring data to track the operational performance and status of gateways and IoT devices. Users connected to configuration server 1500 access monitoring data to update configuration parameters, modify operating rules, or set additional monitoring criteria. For example, users can monitor data usage and associated transmission costs from the BLE network to external systems. Furthermore, device monitoring data enables real-time insights into device functionality, such as identifying devices with low battery power, detecting communication anomalies, or tracking devices that may require maintenance due to frequent errors or reduced connectivity. For example, network health data showing a high retry rate or frequent disconnections may indicate the use of unauthorized devices or reveal poorly performing infrastructure, such as faulty access points or unresponsive electronic shelf labels (ESLs). In addition, network health data and device monitoring data can communicate with other gateways as gateway-to-gateway data, supporting the coordination of failover operations and enabling predictive maintenance across the network.

[0192] In one embodiment, the coordination and generation of network health data and device monitoring data can be achieved by, for example... Figure 2 The illustrated full-site controller 2300 implementation connects to one or more gateways (such as gateways 2100 and 2200). Unlike gateways that independently aggregate data between gateways, controller 2300 centrally collects and analyzes network metrics such as packet loss, latency, signal strength, and device connectivity stability, which are received from each gateway.

[0193] Equipment allocation routine In one embodiment, the edge connectivity module 1112 within gateway 1100 is responsible for implementing the device allocation process (such as a handover process). The device allocation process may include transferring IoT device connections from a source gateway to a target gateway using inter-gateway data communication. Device allocation enables the edge connectivity module to modify or reconfigure the network in response to specific events (referred to as device allocation triggers). The device allocation routine includes initiating the reallocation of IoT device connections to optimize network continuity and maintain seamless connectivity. During device allocation, devices can coordinate operations between gateways using inter-gateway data exchange and virtual MAC (vMAC) address management to maintain uninterrupted communication.

[0194] Device assignment routines can be executed by edge connectivity modules that synchronize across gateways via inter-gateway data exchange. The target gateway can be pre-specified within the device assignment routine or dynamically selected based on target gateway selection parameters such as current load capacity, proximity to IoT devices, received signal strength, device communication history, and available spectrum resources. Within the device assignment routine, the edge connectivity module initiates the transmission of device information (such as binding information or device details) from the source gateway or other data sources to the target gateway. Device information may include the protocol version required for seamless device connectivity continuation, MAC address, vMAC address, timing data, one or more IoT device identifiers, encryption keys, communication status, and device status indicators.

[0195] Device information can be transmitted from the source gateway to the target gateway via inter-gateway data, enabling the target gateway to adopt the device's previous connection state. For example, upon receiving device information, the target gateway may broadcast or adopt the source gateway's vMAC address, allowing IoT devices to seamlessly identify the connection. The edge connectivity module is configured to update new gateways to adopt the vMAC address previously used by the source gateway. The vMAC address is associated with one or more physical or virtual radios in the gateway and serves as a persistent device identifier, providing continuity by allowing devices to remain unaware of changes in gateway connectivity. Device assignment routines eliminate the need for device reconnection or reconfiguration, maintaining continuous data exchange without requiring devices to restart the connection protocol.

[0196] For device allocation triggers such as user-initiated device allocation, cloud-initiated device allocation, load-balanced device allocation, or roaming device allocation, the device allocation routine includes a set of device allocation instructions. These instructions instruct the source gateway to cease connection attempts or communication with the specified IoT device, while simultaneously instructing the target gateway to assume responsibility for connecting to the specified IoT device. Inter-gateway data provides real-time coordination of the device allocation instructions, enabling the source gateway to release device information when the target gateway adopts the source gateway's communication state. Device allocation (including connection or PAWR handover) can be hard or soft. Peripheral devices or devices can maintain connections with both to achieve soft handover, or the connection can be terminated before the target gateway requests a connection.

[0197] In scenarios involving electronic shelf labels (ESLs) operating on a sequence of periodic broadcasts with responses (PAwR), the device assignment routine instructs the target gateway to assume responsibility for communicating with the ESL during the specified time slots of the ESL. The device assignment routine may include sending a transfer command to IoT device 1010, instructing the device to initiate or continue broadcasting its broadcast messages. The device assignment routine executed by the edge connectivity module allows the target gateway to maintain the synchronization timing and communication parameters previously established between the source gateway and the ESL, ensuring that the connection remains intact through device assignment.

[0198] In one embodiment, device monitoring data includes a cached history of preferred or previous connections between the IoT device and the gateway. Furthermore, the preferred connection between the device and the gateway may be pre-stored within the gateway or a cloud configuration server. In one embodiment, the edge connectivity module stores connection data for a specific device type or model, associating it with identifiers within preset filtering criteria. The cached history of preferred or previous connections can be synchronized at the gateway level by transferring the cached history within the data between gateways. Additionally, the cached history of preferred or previous connections may be stored at the cloud configuration server 1500. When a device assignment routine is initiated for an IoT device with a cached history of preferred or previous connections between the IoT device and the gateway, the IoT device can connect to the target gateway based on this cached history.

[0199] When a device assignment event occurs due to a failover scenario (such as a gateway failure), the edge connectivity module will notify other connected gateways via inter-gateway data to take over the device connection held by the inactive gateway. Device details (including the vMAC address and / or identifier associated with the IoT device) are dynamically distributed to the target gateway. The communication instructs the target gateway to begin listening for the specific IoT device identifier associated with the failed gateway, allowing immediate adoption of the device connection without interruption.

[0200] In one embodiment, the device allocation routine within the edge connectivity module applies preset filtering criteria and other selection parameters to identify the most suitable target gateway for device allocation based on factors such as signal strength, proximity, cached connection history, or available resources. The selected target gateway then processes the received device information, enabling the target gateway to establish and maintain seamless connectivity with the IoT device. The device allocation process can be coordinated and processed locally within the gateway or centrally processed via a cloud configuration server or other servers, depending on the site-wide configuration. In any configuration, data exchange between gateways and coordination within the edge connectivity module ensure the efficient completion of the device allocation process.

[0201] In one embodiment, the device allocation routine is executed by the edge connectivity module to manage device connection transfers during the initial phase of connection establishment, such as when broadcast messages are being actively processed. During this phase, the device allocation routine continuously evaluates connectivity parameters across multiple gateways. If a gateway other than the current connection point exhibits metrics that better meet preset filtering criteria (such as improved signal strength, lower network load, or greater proximity to IoT devices), the device allocation routine initiates a dynamic reallocation to that target gateway. Reallocation occurs by transmitting device information, including timing synchronization and device-specific identifiers, enabling the new gateway to seamlessly take over the connection.

[0202] In an embodiment supporting Periodic Broadcast with Response (PAwR) sequences, the device allocation routine is further configured to coordinate the transfer of connectivity responsibilities between gateways during ongoing PAwR communication. The PAwR protocol operates over defined broadcast intervals and channel sequences to ensure consistent operation of IoT devices. IoT devices, such as Electronic Shelf Tags (ESLs), rely on synchronized transmissions. To implement device allocation within a PAwR sequence, the edge connectivity module includes timing details in the device information. Timing details may include time slot allocations associated with the PAwR process, one or more broadcast intervals, and channel sequences. The device information enables a target gateway to assume the transmission role of a source gateway without interrupting scheduled PAwR intervals or requiring IoT devices to resynchronize.

[0203] The device allocation routine uses inter-gateway data to transmit PAwR communication-related parameters from the source gateway to the target gateway. Parameters such as timing offsets and channel hopping sequences are synchronized to enable the target gateway to seamlessly resume PAwR transmission. Edge connectivity modules within the gateway process inter-gateway data exchange in real time, coordinating across gateways to maintain continuous PAwR communication even during device allocation.

[0204] In one embodiment, device allocation is triggered based on load balancing criteria derived from network health data and device monitoring data. Load balancing criteria include metrics that exceed predefined load thresholds based on network health data and device monitoring data, such as congestion thresholds, CPU usage percentages, and resource allocation limits set by the network administrator. For example, load balancing criteria may include congestion metrics, such as queued packet volume or active connections, indicating that one or more radios within the gateway are experiencing high traffic density. Load balancing criteria may include gateway-level measurements of memory consumption, CPU usage, or Received Signal Strength Indicator (RSSI). Load balancing criteria may include a redistribution history that indicates scenarios involving frequent mobile device movement, such as electronic shelf labels (ESLs). When IoT devices exhibit periodic movement or movement in response to certain events, a redistribution history can indicate that device allocation may improve network performance.

[0205] In another embodiment, device allocation is triggered based on a predictive device allocation criterion designed to proactively prevent potential network congestion or performance degradation. The predictive device allocation criterion uses network health data to predict impending load imbalances or network stress that may affect connection stability. For example, if the resource usage patterns or signal quality metrics of the source gateway indicate a potential decline in service quality, the edge connectivity module can preemptively initiate device allocation to avoid end-network conditions such as packet loss, latency spikes, or signal interruptions.

[0206] In a further embodiment, device allocation is triggered during the connection establishment phase, particularly when broadcast messages from IoT devices are initially processed. Device allocation is initiated during the process if the broadcast message (such as RSSI values ​​or initial signal quality) indicates that a different gateway can provide improved connectivity. In the case of PAwR (Periodic Broadcast with Response) communication, device allocation can be applied to optimize resource allocation by redirecting connections to gateways better able to handle PAwR sequence timing and channel distribution.

[0207] In one embodiment, after the device allocation trigger is activated, a target gateway is selected based on selection parameters within the device allocation routine. These selection parameters may include current load capacity as measured by CPU and memory utilization, proximity to IoT devices, current received signal strength, historical connection stability, and available spectrum resources of neighboring gateways. The edge connectivity module can dynamically evaluate these parameters.

[0208] In one embodiment, during load balancing, the selection of a subset of IoT devices assigned from one gateway to another may be based on a set of predefined parameters evaluated by a synchronous edge connectivity module. These predefined parameters may include a criticality or priority level assigned to a particular device, based on stored values ​​indicating its operational importance within the network. Predefined parameters may include device classification to prioritize the switching of devices belonging to high-requirement categories, such as Electronic Shelf Labels (ESLs) or sensors in critical monitoring areas. Predefined parameters may include re-evaluated signal strength measurements, such as RSSI, to prioritize the reassignment of selected IoT devices exhibiting better signal strength at the target gateway. Predefined parameters may include Quality of Service (QoS) metrics such as latency sensitivity and packet transmission rate, the device's historical mobility patterns, and battery level.

[0209] Failover device allocation trigger In one embodiment, the device assignment trigger is initiated by a gateway failover event, where an entire group of connected IoT devices is reassigned to another gateway. The failover trigger is activated when a gateway experiences an unexpected failure rendering it inactive, or during scheduled maintenance requiring the gateway to be temporarily offline. Device assignment criteria for such events include a gateway inactivity detected by metrics from network health data or device monitoring data, or an upcoming scheduled maintenance period.

[0210] Roaming device allocation trigger In one embodiment, device assignment triggering includes a roaming event that initiates when an IoT device physically moves within the network, shifting device proximity from one gateway to another. Movement can be detected via inter-gateway data, where changes in device assignment criteria, such as increased signal strength, signal consistency, or closer proximity to a new gateway, prompt a device assignment trigger. For example, a handover process is initiated if the device signal strength at the target gateway exceeds that of the source gateway, or if signal stability indicates a more favorable connection to the new gateway. Roaming handover criteria may also include reactivation of the preferred gateway, device popularity levels, or nearby gateways reporting stronger and more reliable connections.

[0211] In one embodiment, device allocation triggers and criteria are based on instructions received from a cloud server or other source via configuration data or user instruction data. The cloud configuration server can dynamically update device allocation criteria, such as load balancing thresholds, signal strength preferences, or failover responses, which are then transmitted to all gateways for immediate implementation. Alternatively, device allocation triggers and criteria can be stored locally within the gateway's edge connectivity module, enabling the gateway to autonomously respond to real-time conditions. The local implementation allows for synchronous, site-wide device allocation management, with gateways updating through inter-gateway data sharing.

[0212] In one embodiment, device allocation coordination may include, for example, Figure 2 The architecture shown is implemented in a centralized full-site controller 2300, which connects to one or more gateways (such as gateways 2100 and 2200). The full-site controller 2300 includes an edge connectivity module that centrally manages device allocation coordination by monitoring network events, device connectivity status, and network resource status. Without relying on inter-gateway data synchronization, the controller 2300 communicates with gateways to coordinate connectivity status and dynamically reallocate device processing responsibilities to target gateways. Upon recognizing a device allocation trigger (such as gateway inactivity or load balancing requirements), the controller 2300 executes device allocation routines by exchanging device information with the selected target gateway. Furthermore, the full-site controller 2300 applies preset filtering criteria to identify the most suitable target gateway based on factors such as signal strength, proximity, and current load, ensuring uninterrupted service continuity.

[0213] Now for reference Figure 2 The diagram shows a schematic block diagram of an IoT wireless network management system 200 according to one embodiment.

[0214] IoT devices 2010 and 2020 are endpoint devices within a network, configured to transmit environmental data or receive control commands via protocols such as BLE or Zigbee. IoT devices 2010 and 2020 may include sensors, actuators, display modules, and other dedicated components, depending on the application. Figure 1The operational behavior, components, sub-components, and descriptions of IoT device 1010 are applicable to Figure 2 IoT devices in 2010 and 2020.

[0215] Gateways 2100 and 2200 operate as intermediate network nodes or access points between IoT devices 2010 and 2020 and cloud-based servers. Gateways 2100 and 2200 can partially provide data aggregation, protocol conversion, and initial data processing at the edge. Figure 1 Similar to gateway 1100, gateways 2100 and 2200 facilitate bidirectional data flow between the perception layer and the cloud server. This is attributed to... Figure 1 The functions, hardware, and processes (including data aggregation, local processing, and protocol coordination) of gateway 1100 can also be applied to gateways 2100 and 2200. However, in this embodiment, Figure 1 The edge connectivity functionality of the edge connectivity module 1112 in the middle gateway 1100 is centralized within the full-site edge connectivity controller 2300 (also known as the full-site controller 2300 or controller 2300). The full-site controller 2300 communicates with multiple gateways. The full-site controller 2300 can connect to gateways in various network deployments, such as a star topology. The full-site controller 2300 oversees the connectivity and resource management of all gateways 2100 and 2200.

[0216] In one embodiment, the full-site controller 2300 includes an edge connectivity module (not shown). The edge connectivity module within the full-site controller 2300 is configured to perform the processing operations and functions performed by the edge connectivity module 1112 within a single gateway. The functions of the edge connectivity module can be performed by a processor within the controller 2300 or by the controller 2300 itself. By integrating edge connectivity functionality within a single controller, the system 200 provides unified edge management for gateways 2100 and 2200. The controller 2300 is responsible for unified and efficient processing of IoT device onboarding, data filtering, deduplication, load balancing, and device allocation management from a single control point. Unlike gateways that manage these functions independently, the controller 2300 connects to gateways, allowing the controller 2300 to perform these functions in a coordinated manner across all connected gateways.

[0217] Controller 2300 is connected to one or more gateways 2100 and 2200. The edge connectivity module within controller 2300 adapts to centralized operation by dynamically interacting with the gateways. The full-site edge connectivity controller 2300 operates as a central node implementing edge connectivity functions across systems 200.

[0218] The controller 2300 manages the onboarding process of new devices, applies load balancing by redistributing IoT device connections between gateways 2100 and 2200, and coordinates seamless device allocation for device migration between coverage areas. The edge connectivity module operates as a single edge management point, reducing redundancy associated with distributed edge functions across multiple gateways 2100 and 2200.

[0219] The full site controller 2300 is configured to manage operation across multiple gateways (such as gateways 2100 and 2200) by transmitting coordination signals to the gateways, providing synchronized device management and network functionality. The full site controller 2300 receives gateway data from gateways 2100 and 2200, which may include metrics such as device connectivity status, signal strength reports, and operational performance data. Based on the gateway data, the full site controller 2300 can transmit coordination signals to the gateways. These coordination signals provide instructions to the gateways to modify their scan parameters, adjust device connectivity parameters, or execute specific operational protocols. For example, the coordination signals may specify a non-overlapping scan schedule for a gateway based on a preset scan schedule. IoT device data received by the gateways from IoT devices is processed into gateway data, then aggregated and transmitted to the full site controller. This bidirectional data exchange ensures seamless integration between IoT devices, gateways, and the full site controller.

[0220] The full-site controller 2300 also communicates with external cloud servers, such as cloud configuration server 2500 and application servers 2400 and 2600. Controller 2300 generates cloud-oriented data, including aggregated network health data and operational metrics from the gateway. This cloud-oriented data is transmitted to the cloud configuration server to provide real-time insights into network performance. Configuration data transmitted from cloud configuration server 2500 to controller 2300 may include operational rules, updated scan intervals, or device allocation instructions. Similarly, application data received by controller 2300 from third-party application server 2400 may include event triggers or device-specific commands. User instruction data transmitted from user terminals to the cloud configuration server or application server can further modify configuration or application data.

[0221] Any function attributed to the full site controller can be implemented by transmitting coordination signals to the gateway. Similarly, any action caused by one component to another is performed by transmitting data between components. For example, a gateway can update the network status to the full site controller by transmitting gateway data. IoT devices can provide operating parameters or device-specific metrics to the gateway by sending IoT device data. A cloud configuration server can instruct the full site controller by transmitting configuration data. User instruction data from user terminals can be transmitted to the cloud server to define specific operating rules or preferences. This data exchange forms the basis for interaction between components, providing the necessary instructions, updates, or metrics to dynamically execute the functions in a coordinated manner.

[0222] Controller 2300 can dynamically reallocate IoT devices 2010 and 2020 between gateways 2100 and 2200 based on real-time conditions, providing optimal resource utilization and reducing network congestion. For example, if gateway 2100 reaches its capacity limit, controller 2300 can redirect new devices to gateway 2200, balancing the load across the entire network and maintaining efficient data transmission.

[0223] Configuration server 2500 generates and transmits configuration data to full-site edge connectivity controller 2300. This configuration data includes operating rules, device allocation coordination parameters, firmware updates, and load balancing policies. By sending configuration data to controller 2300, configuration server 2500 ensures consistent configuration application across gateways 2100 and 2200, ensuring all connected devices operate under synchronized policies and configurations. Centralized data flow improves scalability and simplifies network management for large-scale deployments. Configuration server 2500 can perform operations similar to... Figure 1 The configuration server shown has similar functionality and includes similar components, and is adapted to interact with controller 2300. The configuration data generated by configuration server 2500 can be used with... Figure 1 The configuration data is consistent. The configuration data is specifically directed to controller 2300. Subsequently, controller 2300 implements the configuration data across gateways 2100 and 2200 to ensure coordinated and synchronized management of the entire network.

[0224] The full-site controller 2300 can receive user instruction data from the configuration server 2500 or other connected cloud platforms (such as a third-party application server 2400). User instruction data may include network configuration, device allocation policies, and device-specific operation commands. By managing the device allocation process across gateways, the controller 2300 reduces downtime during device migration. User instruction data can be used with... Figure 1 The user instruction data is similar. The user instruction data can be transmitted from the cloud server to the controller 2300. The controller 2300 then implements the user instruction data on the gateway.

[0225] In one embodiment, the configuration server 2500 can connect to a user terminal (also known as a user edge direct terminal) to provide system administrators or authorized users with a direct interface for real-time access to and management of the network. The user terminal can connect to... Figure 1The user terminal is similar. Users can monitor network health, configure operating parameters, and deploy updates or patches directly from the user edge terminal. This interface can also be used to input user command data, such as device-specific configurations, network policies, or event triggers. User command data can be converted into executable configuration data by the configuration server 2500. By enabling a real-time link between the user terminal and the configuration server 2500, the system 200 can achieve responsive network adjustments, troubleshooting, and remote diagnostics, providing comprehensive control over all site operations managed by the edge connectivity modules within the full site edge connectivity controller 2300.

[0226] The controller 2300 aggregates monitoring data including device health metrics, performance data, and diagnostic logs received from connected gateways 2100 and 2200. The controller 2300 transmits this monitoring data to the configuration server 2500 for centralized analysis. This integrated view of network operations allows the configuration server 2500 to dynamically adjust configurations based on real-time network insights, enabling predictive maintenance, load balancing, and rapid troubleshooting. The full-site controller reduces redundancy in data processing and optimizes network efficiency. Local processing of IoT device data and monitoring data can also be performed at the controller 2300 based on predefined rules. The controller can be adjusted and optimized in real-time independently of the configuration server 2500.

[0227] The third-party application server 2400 and the hardware vendor server 2600 serve as external integration points within the IoT network, providing connectivity with third-party applications and vendor-specific services. Servers 2400 and 2600 can perform operations related to… Figure 1 Servers 1600 and 1700 perform similar functions, such as receiving and processing IoT device data from the gateway via controller 2300 and generating application-specific commands. Third-party application server 2400 provides external application interaction. Hardware vendor server 2600 provides hardware-related configuration, such as firmware updates and diagnostics.

[0228] In one embodiment, the security protocol is implemented within the full-site edge connectivity controller 2300 to ensure consistent data protection across the network. The controller 2300 manages the authentication and encryption processes, ensuring secure data exchange between gateways, cloud servers, and third-party services such as application server 2400 and hardware vendor server 2600. Furthermore, the centralized architecture improves interoperability with external platforms, enabling the controller 2300 to implement standardized protocols and security measures throughout the network.

[0229] In one embodiment, the edge connectivity module within the full-site edge connectivity controller 2300 performs data filtering and formatting operations. When IoT device data is received from IoT devices 2010 and 2020 to the controller 2300 via gateways 2100 and 2200, the edge connectivity module applies filtering algorithms to remove redundant, incomplete, or unnecessary data, ensuring that relevant information is further processed. The streamlined data is then formatted into a standardized structure compatible with cloud-oriented data protocols. In one embodiment, gateways 2100 and 2200 operate as initial access points, providing data aggregation and routing capabilities, as well as API support for external applications. Furthermore, the gateways can relay data via TLS / TCP protocols to maintain a secure data flow to the controller 2300.

[0230] In one embodiment, an edge connectivity module within controller 2300 provides cloud-configurable data processing, secure cloud integration, and distributed radio management. Cloud-configurable data processing includes applying specific processing rules based on operational requirements or predefined rules, such as aggregating sensor data for analysis or preprocessing data to detect anomalies. For secure cloud integration, the edge connectivity module implements end-to-end encryption, enabling secure data exchange with cloud-based servers, such as configuration server 2500. Distributed radio management coordinates radio resources across gateways 2100 and 2200 to reduce interference and maintain stable connectivity with IoT devices. Radio management includes controlling scan intervals, frequency adjustments, and power settings at the gateway level to ensure optimized, interference-free communication across the entire network. Gateways 2100 and 2200 thus operate as localized radio nodes, while controller 2300 maintains centralized oversight for seamless distributed radio operation across the entire site.

[0231] Edge connectivity modules provide unified connectivity for seamless communication across distributed radio hardware such as wireless access points (APs), dedicated IoT gateways, or wireless bridges. This unified connectivity can be implemented in on-premises or cloud-based architectures. Edge connectivity modules coordinate communication with wireless devices across multiple use cases and protocols. For example, distributed radios in a gateway can communicate with electronic shelf labels (ESLs) using Bluetooth Low Energy (BLE) 5.4 in the 2.4 GHz Industrial, Scientific, and Medical (ISM) band.

[0232] In some implementations, the unified connectivity function is connected to an instance of the edge direct routine of the edge connectivity module. The edge direct routine manages the operating parameters and configuration settings of devices within the network. This integration enables the unified connectivity function to dynamically adjust configurations and apply policies across distributed radio hardware, enhancing network adaptability and control.

[0233] Figure 2The number of components shown, including the full-site edge connectivity controller 2300, IoT devices 2010, 2020, gateways 2100, 2200, and external servers (such as configuration server 2500, third-party application server 2400, and hardware vendor server 2600), is exemplary and not intended to be limiting. In a real deployment, additional component instances may exist, with multiple controllers, IoT devices, gateways, and servers deployed based on the specific requirements of the environment. For example, a large-scale retail deployment might include numerous groups of gateways connected to their respective controllers. A controller may connect to other controllers, such as in a mesh topology. Furthermore, or alternatively, controllers may be synchronized via a cloud configuration server connected to the controller. Similarly, additional servers may be integrated to manage larger volumes of data, provide redundancy, or support dedicated functions within the network.

[0234] Coordinated scan parameters The full-site controller 2300 is configured to transmit coordination signals to a first gateway and a second gateway. The first and second gateways may be part of a plurality of gateways connected to the controller 2300. The coordination signals are configured to coordinate the discovery processes (such as service discovery, device discovery, and / or other discovery processes) of the first and second gateways based on scan scheduling that provides coordinated scan parameters for the first and second gateways. The coordinated scan parameters may include one of basic non-overlapping scan parameters, interleaved scan parameters, or basic overlapping scan parameters. In one example, the scan parameters may include a scan window and / or other parameters. The first and second gateways may be located in a neighboring area.

[0235] In one embodiment, the coordination signal is configured to enable the target gateway to operate on scan scheduling. Scan scheduling includes allocating scan intervals, timing schedules, and broadcast channels to gateways. A preset scan scheduling configuration is set to enable neighboring gateways to operate on different scan intervals, timing schedules, and broadcast channels, optimizing the coverage and efficiency of broadcast capture from IoT devices. By distributing scan responsibilities among gateways, the system reduces overlap and minimizes missed broadcasts due to channel conflicts. Proximity between gateways can be determined based on the pre-stored MAC addresses or virtual MAC (vMAC) addresses of adjacent gateways.

[0236] The preset scan schedule can be received or updated by the cloud configuration server 2500 or through user command data from the user terminal. The cloud configuration server 2500 can transmit the preset scan schedule as part of the configuration data to the controller 2300.

[0237] The full-site controller 2300 is configured to transmit a pause signal to one of the first and second gateways that meets the pause criteria, thereby pausing the discovery process at either the first or second gateway. The pause criteria include a threshold number of broadcast messages received by either the first or second gateway. The discovery process may include receiving multiple broadcast messages at either the first or second gateway.

[0238] A pause criterion is applied to optimize the discovery process and data processing of connected IoT devices. Controller 2300 is configured to dynamically adjust the gateway's discovery process, including IoT device data processing, based on device attributes received via IoT device data and real-time network conditions. For example, when controller 2300 detects a large number of broadcast messages from IoT devices (compared to a threshold level set within the pause criterion), controller 2300 directs a pause signal to the gateway to selectively postpone specific portions of the discovery process that require longer processing times. The postponed incoming IoT device data or target portions may include device authentication checks, detailed capability queries, or security key exchanges, which can be more time-consuming steps in establishing a connection.

[0239] Coordinated device connection The full-site controller 2300 is configured to determine whether a broadcast message received from an IoT device at a first gateway meets preset filtering criteria. The preset filtering criteria include a minimum signal strength. Furthermore, the full-site controller 2300 is configured to transmit a coordination signal to the first gateway. The coordination signal is configured to establish a connection between the first gateway and the IoT device if the broadcast message meets the preset filtering criteria. Additionally, when a connection is established between the first gateway and the IoT device, the full-site controller 2300 is configured to transmit a preset processing protocol to the first gateway. The preset processing protocol includes multiple operational actions directed to the IoT device. The preset filtering criteria are configured to enable the gateway to establish a connection with IoT devices that meet the preset filtering criteria. The preset filtering criteria or pause criteria can be received from the controller 2300 and stored locally at the gateway for local execution. Alternatively, the controller 2300 can dynamically update the preset filtering criteria or pause criteria in real time based on current network conditions, device density, or environmental factors. For example, a higher received signal strength threshold can be applied to channels or frequencies experiencing high noise levels or increased channel activity.

[0240] In one embodiment, controller 2300 coordinates the application of preset filtering criteria within the network. Controller 2300, communicating in real-time with multiple gateways, evaluates incoming broadcast messages based on the preset filtering criteria to determine the most suitable gateway for establishing a connection. In one embodiment, the preset filtering criteria may include a cached history of preferred or previous connections between IoT devices and gateways. In another embodiment, controller 2300 applies pre-approved connection and caching mechanisms to improve device connectivity.

[0241] Network health and device monitoring data In one embodiment, controller 2300 is configured to generate network health data, including metrics such as packet loss, signal strength, response time, latency indication, connection stability, connection failure, response failure, packet retry, and diagnostic error reports. Network health data may be generated for a single gateway, and this network health data may be referred to as gateway health data. Network health data may also reflect an overall assessment of network conditions across all gateways. To generate network health data, controller 2300 may aggregate gateway data received from gateways. Gateway data may include metrics used to generate network health data. Furthermore, controller 2300 integrates IoT device data received from connected IoT devices, capturing real-time signal strength, response time, and connection stability.

[0242] In one embodiment, controller 2300 generates device monitoring data to assess the health and functionality of IoT devices connected to the gateway. Device monitoring data can be generated by processing IoT device data received at the gateway and further transmitted to controller 2300.

[0243] The controller 2300 can transmit network health data and device monitoring data (collectively referred to as monitoring data) as part of cloud-directed data to the configuration server 2500 and application servers 2400 and 2600. The cloud server can further transmit the network health data and device monitoring data to the user via the user terminal.

[0244] Equipment allocation routine In one embodiment, controller 2300 implements the device allocation process by transmitting a device allocation signal to the source gateway. The device allocation signal is configured to initiate a device allocation routine when a device allocation trigger is met at the source gateway. The device allocation trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. The device allocation signal may be included in a coordination signal transmitted by controller 2300 to the gateway.

[0245] The device allocation process (such as a switching process) may include using inter-gateway data or other communication to transmit IoT device connections from a source gateway to a target gateway, or to allocate IoT device connections to a specific gateway.

[0246] The device allocation routine is executed by the controller 2300 connected to the gateway for synchronous data exchange. The target gateway can be pre-specified within the device allocation routine or dynamically selected based on target gateway selection parameters (or selection parameters), such as current load capacity, proximity to IoT devices, received signal strength, device communication history, and available spectrum resources. Within the device allocation routine, the controller 2300 receives detailed device information from the source gateway. The controller 2300 then transmits the device information to the target gateway to enable the IoT device to connect to the target gateway.

[0247] In one embodiment, device monitoring data includes a cached history of preferred or previous connections between the IoT device and the gateway. Furthermore, the preferred connection between the device and the gateway may be pre-stored within the controller 2300 or the cloud configuration server 2500. In one embodiment, the controller 2300 stores connection data for a specific device type or model, associating it with identifiers within preset filtering criteria. The cached history of preferred or previous connections can be synchronized by the controller 2300.

[0248] When a device assignment event occurs due to a failover scenario (such as a gateway failure), the controller 2300 will notify other connected gateways via a coordination signal to take over the device connection held by the inactive gateway. Device details (including the IoT device's vMAC address and / or identifier) ​​are dynamically distributed to the target gateway. Device information may be included in the coordination signal.

[0249] In one embodiment, the device assignment routine within the controller 2300 applies preset filtering criteria and other selection parameters to identify the target gateway for device assignment.

[0250] In one embodiment, the device allocation routine is executed by the controller 2300 to manage device connection transfer during the initial phase of connection establishment, such as when broadcast messages are being actively processed.

[0251] The device allocation routine uses coordination signals to transmit parameters related to PAwR communication from the source gateway to the target gateway.

[0252] In one embodiment, device allocation is triggered based on load balancing criteria derived from network health data and device monitoring data. A load balancing event occurs in response to the source gateway's gateway health data exceeding a load threshold. The load threshold (or load balancing criteria) includes metrics based on network health data and device monitoring data exceeding predefined load thresholds.

[0253] In one embodiment, the selection of a subset of IoT devices allocated from one gateway to another during load balancing can be based on a set of predefined parameters determined by the synchronization controller 2300.

[0254] In one embodiment, device allocation is triggered by a gateway failover event, where an entire group of connected IoT devices is reassigned to another gateway. The failover trigger is activated when a gateway experiences an unexpected failure rendering it inactive, or during scheduled maintenance requiring the gateway to be temporarily offline. Device allocation triggers for such events may include gateway inactivity detected by metrics from network health data or device monitoring data, or an upcoming scheduled maintenance period.

[0255] In one embodiment, device assignment triggering includes a roaming event, which is initiated when an IoT device physically moves within the network, transferring device proximity from one gateway to another. The roaming event occurs when the full-site controller determines, based on gateway data received from the target gateway, that the target gateway is receiving a stronger signal from the IoT device than the source gateway.

[0256] In one embodiment, the device allocation trigger and device allocation criteria are based on instructions received from the cloud server via configuration data or user instruction data. Alternatively, the device allocation trigger and criteria may be stored at the controller 2300 to implement autonomous device allocation routines in response to real-time conditions.

[0257] Now for reference Figure 3 The diagram shows a schematic block diagram of an edge connection module 300 according to one embodiment.

[0258] In one embodiment, the edge connectivity module implements a flexible multi-vendor edge framework that supports a range of IoT devices 3010, 3020 managed through vendor-specific edge applications and generic device recipes. The edge connectivity module can be... Figure 1 Edge connection module 1112, or Figure 2 The edge connectivity module is located within the full-site controller. The technical architecture includes an edge management system, in which the edge connectivity module operates as a central node, coordinating communication, processing, and operational control across various devices and applications from different vendors.

[0259] In one embodiment, the edge connectivity module serves as a centralized layer for hosting vendor-specific edge applications, such as vendor A edge application 3050 and vendor B complete edge application 3060. The applications include unique edge application logic components, such as edge application logic 3052 within vendor A's application and edge application logic 3062 within vendor B's application. Components 3050, 3052, 3060, and 3062 handle vendor-specific operational and processing requirements. By placing the edge application logic within the edge connectivity module, the architecture ensures that device-specific operations, such as data processing, event processing, and device state management, can be customized for the vendor without requiring separate physical infrastructure.

[0260] The generic device recipe 3070 is managed by the edge connectivity module. Recipe 3070 represents a pre-configured operational workflow whose definition can be universally applied to actions or sequences across different device types 3010, 3020, and vendor applications 3050, 3060, such as network access routines, control commands, and data preprocessing steps. The edge connectivity module executes these recipes as templates to standardize operations across IoT devices (such as vendor A's device 3010 and vendor B's device 3020), ensuring consistent functionality regardless of the specific edge application logic used. Centralized recipe management reduces redundant processing and promotes operational uniformity across the entire network.

[0261] A recipe represents a self-contained logical block tailored to manage device-specific characteristics, including proprietary protocols and unique identifiers. Recipes align device-specific characteristics with standardized formats used by the platform. Through recipes, edge connectivity modules support both vendor-specific and universally applicable configurations, enabling robust, adaptive, and scalable device management. Recipes can function independently or in combination with other recipes to enable flexible and layered device interactions. For example, a device recipe is used to convert IoT device-specific data, such as unique sensor addresses or proprietary data structures, into a platform-compatible format. This process ensures that device-specific information is uniformly represented in the platform's data schema, regardless of device-specific protocol requirements. For instance, an edge connectivity module can use a device recipe to interpret proprietary data streams from sensors and convert them into standardized event streams. This event stream can then be processed or transmitted according to a common protocol, making device data accessible and available within the platform ecosystem. The platform can be an edge connectivity platform.

[0262] Similarly, edge application logic recipes 3052 and 3062 allow edge connectivity modules to interpret and transform standardized data streams into executable events that can be delivered to enterprise applications hosted in the cloud, including those managed by vendors or end users. The recipes provide transformation and control logic that enables seamless integration of data collected from IoT devices with enterprise systems. For vendors or third parties deploying dedicated devices, complete edge application recipes integrate both device-specific and application-specific logic.

[0263] The formulation implemented within the edge connectivity module can be provided by the device manufacturer, platform operator, or end user.

[0264] The edge connectivity module also includes a device communication component 3064 within vendor B's application, which manages protocol conversion and secure data forwarding. Device communication component 3064 enables seamless interoperability by handling the specific data formats, encryption protocols, and communication standards required by vendor devices. For example, device communication 3064 in vendor B's application ensures that IoT devices 3020 can transmit data to and receive commands from the edge system using protocols optimized for those devices, while adhering to the security and formatting requirements set by the edge connectivity module.

[0265] The technical architecture allows for the integration of additional vendor-specific applications into the edge connectivity module. As new edge applications are added, the Generic Device Recipe 3070 can be dynamically updated or expanded to include additional operational workflows. For example, if a new vendor's equipment requires customized onboarding procedures or specific data preprocessing, the edge connectivity module can update its recipe accordingly.

[0266] Furthermore, the edge connectivity module is configured to support real-time data management and secure cloud integration. For scenarios requiring immediate processing, the edge connectivity module can handle priority functions locally within the edge application logic, such as data filtering or device coordination. When cloud-based processing is needed, selected data streams can be forwarded to cloud-based configuration or application servers (such as configuration server 1500 or third-party application servers 1600 and 1700) without interrupting local device operations. This allows the system to balance edge and cloud processing based on operational needs, enabling low-latency decision-making at the edge while providing comprehensive analytics in the cloud.

[0267] The edge connectivity module utilizes recipes as modular, version-controlled configurations to enable seamless interaction between connected IoT devices and the network. Within this framework, the edge connectivity module operates as an instance within the edge architecture, serving as a middleware layer to manage and standardize communication between different IoT devices (such as devices 3010 and 3020) and the network.

[0268] Now for reference Figure 4 The diagram shows a schematic block diagram of an IoT wireless network management system 400 according to one embodiment.

[0269] In one embodiment, the edge connectivity module 4010, configuration server 4020, and recipe server 4030 coordinate to manage recipe configuration in a centralized and version-controlled manner.

[0270] The edge connectivity module 4010 acts as the operational core, executing configurations that define recipes for specific tasks and processes within the IoT network. A configuration is a curated collection of recipes, such as recipes A, B, and C, designed together to perform a comprehensive set of operations on devices (not shown) connected to the edge connectivity module 4010. This configuration allows for various recipe combinations to be customized for different instances of the edge connectivity module 4010 according to specific operational needs.

[0271] Configuration server 4020 operates as an intermediate control node, responsible for the deployment and synchronization of recipe configurations within the network. Configuration server 4020 manages the interaction between edge connectivity module 4010 and recipe server 4030, ensuring all edge instances always have the latest recipes. Configuration server 4020 retrieves configurations and their associated recipes from recipe server 4030, maintaining version accuracy and aligning with the latest recipe updates. Configuration server 4020 can connect to a user terminal (not shown). Through the user terminal, users can initiate configuration updates, view recipe versions, adjust operating parameters, and deploy new recipes among edge connectivity module instances, enabling responsive adjustments and precise control of the IoT network.

[0272] Recipe Server 4030 (also known as Edge Direct Functionality) operates as a centralized repository for recipes and maintains version-controlled instances of recipes. Centralized storage ensures that the configuration executed by Edge Connectivity Module 4010 is based on the latest recipe logic and standards, providing stability and consistency across multiple instances of Edge Connectivity Module. When recipes are updated or modified, Recipe Server 4030 manages version control, allowing Configuration Server 4020 to access and distribute the latest, verified versions.

[0273] In operation, configuration server 4020 communicates with recipe server 4030 to request and retrieve specific recipes included in the configuration. For example, when edge connectivity module 4010 needs to update its configuration, configuration server 4020 queries recipe server 4030 for the latest versions of recipes A, B, and C. Recipe server 4030 processes the query by identifying and providing the current versions (e.g., version 1.12 for recipe A and version 2.04 for recipe B) to configuration server 4020. This architecture enables system 400 to dynamically adapt to changing operational requirements without requiring manual updates to individual edge connectivity instances.

[0274] Upon receiving the updated configuration, the edge connectivity module 4010 loads and initializes the recipes, as instructed by the configuration server 4020. The edge connectivity module 4010 utilizes the recipes to perform edge-level operations, including data processing, protocol conversion, and device coordination specified in the recipes. By loading recipes in real time, the edge connectivity module provides responsiveness and adaptability to manage a range of tasks while minimizing latency.

[0275] A centralized configuration and recipe management approach allows for scalable deployment of edge capabilities across numerous sites and devices. For example, a single change to a recipe within recipe server 4030 can be propagated through configuration server 4020 to all instances of edge connectivity modules 4010 that depend on that recipe. This propagation ensures that all connected IoT devices and applications are always operating on the latest configuration standards, providing uniformity for large-scale IoT networks.

[0276] In scenarios requiring custom or vendor-specific operations, the edge connectivity module 4010 can handle specific configurations by selectively loading relevant recipes stored in the recipe server 4030. For example, a specific configuration for vendor A's equipment might include custom recipes that address proprietary communication protocols or device-specific preprocessing steps. Similarly, standardized configurations can be used to maintain common device functionality across different deployments for interoperability, while allowing targeted customization where necessary.

[0277] Furthermore, by separating recipe storage and execution into discrete server functions, this architecture reduces operational redundancy and optimizes resource utilization across the entire network. Recipe server 4030 provides a single point of control for recipe version control and distribution. Edge connectivity module 4010 performs edge processing and device management functions.

[0278] In one embodiment, the edge connection module 4010 may represent Figure 1 The edge connection module 1112, or Figure 2 The edge connectivity module in the full site controller depends on the deployment requirements. In one embodiment, the configuration server 4020 is... Figure 1 Cloud configuration server 1500, or Figure 2 Configure server 2500. Figure 4 The architecture can be integrated into Figure 1 or Figure 2 In the larger system architecture shown, the edge connectivity module 4010 operates alongside gateways, IoT devices, and cloud-based servers. Although Figure 4 Specific devices and gateways are not shown, but they exist in a wider system and are connected via the edge connectivity module 4010.

[0279] Now for reference Figure 5 The diagram shows a schematic block diagram of an IoT edge connectivity framework 500 according to one embodiment.

[0280] "Upstream protocols" (such as HTTPS, MQTT, WebSocket, Azure IoT, AWS IoT, GCP IoT, IBM IoT) represent the connections from edge connectivity modules (such as...) Figure 1 or Figure 2The connection paths from the edge to cloud-based platforms and services in the cloud analytics layer. These protocols enable secure, structured data transmission to the cloud, where data can be further processed, analyzed, and stored. For example, MQTT and HTTPS are used to transmit cloud-oriented data from the edge. Cloud-oriented data includes device metrics, status updates, and event-triggered messages. Integration with vendor-specific platforms such as Amazon Web Services IoT (AWS IoT), Google Cloud Platform IoT (GCP IoT), and IBM IoT (IBM IoT) enables edge connectivity modules to seamlessly interact with cloud services from different vendors, providing flexibility for managing multi-vendor IoT networks.

[0281] The "recipe" layer provides pre-configured workflows or templates that define operational logic and enable the conversion of device-specific data formats and protocols into a platform-compatible standardized format. In this context, a recipe is similar to... Figure 3 The recipe is executed by the edge connectivity module to coordinate device operation. Figure 5 This explains several categories of recipes: Common Device Types: This recipe manages "protocol and identity conversion," enabling edge connectivity modules to normalize data from heterogeneous IoT devices such as sensors and actuators. For example, data from a BLE temperature sensor can be converted to a uniform format before being sent upstream, making it compatible with centralized analysis.

[0282] Enterprise Applications: Recipes within the Enterprise Applications category support complex operations such as message transformation, offline queuing, and device debugging. Enterprise Application Recipes enable interoperability with enterprise applications and even support queuing during intermittent connectivity outages by transforming raw IoT data into actionable insights.

[0283] Single-purpose IoT: This recipe represents a combinatorial logic that combines device type and enterprise application, simplifying the configuration of dedicated IoT devices that perform specific functions. These recipes streamline the data flow from edge to cloud by integrating protocol processing and enterprise logic within a single recipe structure.

[0284] The "Event Processing Service" layer represents the real-time processing of events generated by IoT devices. Managed by the edge connectivity module, the event processing service handles events from IoT devices (such as anomaly alarms or status updates) and applies predefined rules or triggers. For example, if a temperature sensor transmits a reading exceeding a threshold, the edge connectivity module can initiate appropriate actions, such as sending commands to actuators to adjust environmental controls.

[0285] Downstream protocols (such as BLE, HTTP, Wirepas Mesh, Zigbee, 900MHz, LoRa, and UWB) facilitate communication from edge connectivity modules to IoT devices at the network edge. For example, downstream protocols can be applied to… Figure 1 Between the perception layer 1002 and the network layer 1004. Downstream protocols enable the edge connectivity module to communicate with a variety of IoT devices, providing compatibility with various wireless standards used in different deployment environments. For example, BLE and Zigbee are typically used for short-range, low-power sensor networks, while LoRa and 900MHz support long-range, low-bandwidth communication with remote devices.

[0286] The "control panel" refers to comprehensive control and monitoring capabilities. Device service functions include device discovery, access control lists (ACLs), identity management, assignment to the nearest gateway, signal strength tracking, per-device configuration, and device twin functionality. Device services enable the edge connectivity module to manage the device lifecycle, ensuring that IoT devices are authenticated, assigned to the optimal gateway, and configured as needed. For example, when a new device joins the network, the edge connectivity module handles its discovery, verifies its identity, and assigns it to the nearest gateway based on signal strength and network load.

[0287] "Health and Billing" can refer to Figure 1 Monitoring data is generated by the edge connectivity module. This data includes tracked metrics such as heartbeat, battery level, retries, dropped packets, transmission rate, bytes used, and spectrum usage. The monitoring data, generated by the edge connectivity module, provides real-time visibility into device health and network performance to support maintenance and diagnostic processes. For example, the edge connectivity module can flag devices with low battery or high retries, enabling preventative maintenance or network configuration adjustments.

[0288] Now for reference Figure 6 The diagram shows a schematic flowchart of an event detection and triggering mechanism 600 according to one embodiment.

[0289] In one embodiment, the edge connectivity module is responsible for event detection, filtering, and action triggering based on structured pipelines and connection sequences. The edge connectivity module supports a streamlined process for detecting and responding to asynchronous events flowing through the network.

[0290] In this embodiment, the pipeline 6010 includes sequentially arranged filters that perform specific operations on incoming events. For example, at filter 1, events (such as Bluetooth Low Energy (BLE) broadcasts, messages from the cloud analytics layer 1006, or inter-pipeline messages) enter the pipeline for initial screening. Filter 1 acts as a gateway, evaluating the relevance of the events and verifying whether the relevant data warrants further processing. Upon successful passage, the event enters filter 2 for intermediate processing. Here, filter 2 can adjust event parameters or attach additional metadata, effectively preparing the event for subsequent actions. Filter 2 can be configured to alter the internal state of the edge connectivity module, influencing other connected IoT devices or system processes in real time. Events then reach filter 3, the final stage of the pipeline. Filter 3 determines whether the event meets all the necessary criteria for a response in the connection sequence 6020. Filter 3 can terminate pipeline 6010 by terminating unnecessary events or by issuing refined events that may trigger new filters or connection sequences.

[0291] Connection sequence 6020 follows a filtering process as a series of actions triggered after the successful completion of event pipeline 6010. Connection sequence 6020 (shown as Action 1, Action 2, and Action 3) represents a control response process designed to interact with devices or platforms in a defined order. Action 1 is initiated by establishing a connection with an IoT device, such as a BLE device that has emitted a presence signal. Action 1 may include configuring specific read / write characteristics on the target device, effectively setting communication parameters. Once connected, the process moves to Action 2, where the edge connectivity module enables notifications or continuous updates from the device. Action 2 may include entering a state of listening to periodic data, enabling real-time monitoring of the device's status. Finally, Action 3 completes the communication process, allowing the edge connectivity module to adjust operating settings or send configuration updates as needed. Furthermore, Action 3 may emit further events, looping back to other pipelines or connection sequences to create an adaptive feedback loop that improves system responsiveness and adaptability.

[0292] Pipeline 6010 and connection sequence 6020 can operate asynchronously. Events (such as BLE broadcasts, cloud messages, and inter-pipeline communication) flow independently through the system, allowing edge connectivity modules to operate based on a set of predefined rules. These predefined rules are system configuration instructions within the edge connectivity module that specify how to process and filter incoming events (such as device status updates, BLE broadcasts, or cloud messages) and sequences of actions to be executed. Predefined rules include actions such as activating control sequences based on context and operational requirements, triggering specific workflows, or adjusting device settings. For example, a BLE broadcast received from a device in the perception layer 1002 provides an update on the device's status or location; the pipeline processes these updates to initiate the relevant connection sequence. Similarly, Figure 1The configuration data may carry instructions to initiate real-time configuration or change the behavior of connected IoT devices within the system. Filters within the pipeline can modify events to meet specific operational requirements, while connection sequences trigger complex, context-sensitive actions on the target device.

[0293] The pipeline and connection sequence model allows for variation and adaptation to improve the flexibility of event detection and action triggering processes. The pipeline and connection sequence structure can dynamically adapt to real-time changes in network conditions or device states, allowing the addition of new filters or actions without interrupting ongoing operations. Furthermore, pipelines can include conditional loops, where filters or actions remain in a monitoring or waiting state until specified conditions are met. For example, an edge connectivity module could use filter 2 to evaluate event frequency and determine whether the notification loop should continue based on data patterns.

[0294] The interconnected filter pipelines and sequential connection model enable the system to implement mechanisms for processing, filtering, and triggering responses to IoT events, as disclosed in other embodiments. This architecture enables efficient real-time interaction between IoT devices within the cloud analytics layer 1006, the intermediate network layer 1004, and the perception layer 1002, such as... Figure 1 As shown. For example, the perception layer 1002 includes a large number of IoT devices, such as BLE-enabled sensors, actuators, and electronic shelf labels (ESL), continuously transmitting IoT device data, including status updates, sensor readings, and control signals that initiate a series of activities at the edge level. The edge connectivity module is configured to operate as a central processor for IoT device data, filtering and coordinating events through structured pipelines 6010. After being filtered through pipelines 6010, events are shaped and transformed according to predefined rules of the system, enabling the edge connectivity module to prioritize, modify, or enrich event content before advancing events to connection sequences 6020. Pipelines 6010 and connection sequences 6020 enable actions such as protocol conversion, device authentication, and real-time configuration changes to be executed directly in response to event triggers. The configuration server 1500 further refines the process by transmitting configuration data, which dynamically updates pipeline parameters and connection sequences at the gateway level. Furthermore, user command data received from user terminals can influence the behavior of these pipelines and sequences by changing threshold parameters in real time, adjusting device-specific rules, or triggering custom event responses.

[0295] Now for reference Figure 7 The diagram shows a schematic flowchart of an event detection and triggering mechanism 700 according to one embodiment.

[0296] Mechanism 700 relates to an electronic shelf label (ESL) and an application on a gateway according to one embodiment. Mechanism 700 illustrates a multi-step authentication and communication process that, coordinated by an edge connectivity module, enables secure interaction and data exchange between the ESL and the application on the gateway.

[0297] Mechanism 700 includes BLE broadcast messages sent by the application scanning ESL broadcasts, enabling the system to identify nearby IoT devices and establish initial communication with them. The scanning action, as the first step in the connection sequence, involves the edge connectivity module continuously monitoring the broadcasts, effectively facilitating the identification of nearby IoT devices. The application can reside on the edge connectivity module, operating as part of an intermediate network layer that facilitates ESL interaction with the perception layer.

[0298] Upon detecting the ESL's BLE broadcast, the edge connectivity module initiates BLE connection setup between the ESL and the application, establishing a secure, low-latency communication channel. The connection setup process provides a direct path for subsequent data exchange and authentication procedures. As part of the BLE connection setup, the system may perform a handshake to confirm that both the ESL and the application are ready to proceed.

[0299] The application then sends a random request to ESL, transmitting a first randomly generated number to initiate the challenge-response protocol. This exchange may form the first layer of the authentication mechanism within the connection sequence. ESL responds with a response message including a second random number and the first authorization information, which is then processed by the application. The authorization information is managed by the edge connectivity module, allowing the application to perform preliminary verification of the ESL's identity, confirming its legitimacy before further processing.

[0300] During device authentication, the application uses random numbers and authorization information provided by ESL to perform device authentication checks. The authentication verifies the ESL's identity by comparing it with the device profile stored in the gateway, ensuring authorized devices can continue interacting. Upon successful device authentication, the application transmits an authorization response including additional authentication credentials, signaling to ESL to verify the application's authenticity. ESL performs gateway authentication steps to confirm the gateway's identity and permissions, establishing mutual trust between the gateway and the IoT device. This mutual authentication ensures secure data transactions and enables the trusted gateway and application to control or interact with IoT devices within the system.

[0301] Upon successful verification, the connection sequence reaches a successful state, completing the authentication process and establishing a trusted communication channel between ESL and the application. At this point, with all prerequisites for the authentication session met, the edge connectivity module allows the application to securely initiate data transmission.

[0302] In this embodiment, the final step of the connection sequence includes a command to download an image, whereby the application transmits image data (such as product images or promotional graphics) to the ESL. This image data transmission initiates real-time updates to the ESL display, improving the device's usability in environments such as retail stores. The downloaded content (typically visual information relevant to the ESL) is stored and rendered by the ESL in response to the application's commands, enabling dynamic and immediate updates that reflect changes in inventory or promotions.

[0303] This workflow illustrates the edge connectivity module's ability to manage complex, multi-step interactions between IoT devices and gateway applications, combining secure authentication, data exchange, and real-time updates. Furthermore, variations in this connection sequence can include additional authentication layers, dynamic re-authentication based on session duration, or conditional access restrictions based on user instruction data from the user terminal. When provided, user instruction data can influence authentication protocols or instruct specific actions after authentication, enabling customized workflows that adapt to changing operational requirements or user preferences.

[0304] Mechanism 700 is available Figure 1 and Figure 2 Implemented within the larger IoT architecture described above. The edge connectivity module coordinates sequences, oversees data flow, event detection, and authorization verification between ESL and applications. IoT device data generated by ESL (such as BLE broadcasts and status updates) is authenticated and authorized through the edge connectivity module's pipeline before any action is taken. Gateway data includes authorization and authentication exchanges that maintain secure communication. Cloud servers (such as configuration servers) can provide updated protocols or instructions to the edge connectivity module to influence the authentication or data transmission process.

[0305] In one embodiment, the edge connectivity module can refer to Figure 1 The edge connection module 1112, or Figure 2 The edge connectivity module in the full site controller depends on the specific deployment requirements. Although Figure 7 Specific devices and gateways are not shown, but they exist in a wider system and are connected via edge connectivity modules.

[0306] Now for reference Figure 8 The diagram illustrates a schematic flowchart of a full-site configuration method 800 according to one embodiment.

[0307] In 802, the method includes transmitting a coordination signal to a first gateway and a second gateway, the coordination signal being configured to coordinate the discovery process (e.g., service discovery, device discovery, and / or other discovery process) of the first and second gateways based on a scan schedule that provides coordinated scan parameters for the first and second gateways. The coordinated scan parameters may include one of basic non-overlapping scan parameters, interleaved scan parameters, or basic overlapping scan parameters. In one example, the scan parameters may include a scan window and / or other parameters. The first and second gateways are located in a neighboring area.

[0308] Broadcast message data from IoT devices includes device-specific details such as Media Access Control (MAC) address, Virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, sensor readings, and operational status indications.

[0309] At 804, the method includes updating the scan schedule based on configuration data received from a cloud configuration server or user instruction data received from a user terminal.

[0310] At 806, the method includes transmitting a pause signal to one of a first gateway and a second gateway that meets a pause criterion to pause the discovery process at either the first gateway or the second gateway, wherein the pause criterion includes a threshold number of broadcast messages received at either the first gateway or the second gateway, and wherein the discovery process includes receiving multiple broadcast messages at either the first gateway or the second gateway.

[0311] Scan scheduling includes timing scheduling, broadcast channels, and scan interval allocation.

[0312] The pause signal configuration suspends multiple low-priority discovery processes at one of the first and second gateways. These low-priority discovery processes include authentication checks, detailed capability queries, or security key exchanges.

[0313] The suspension criteria include minimum signal strength threshold, device priority, battery level, and device classification.

[0314] The first and second gateways are determined to be in the same neighborhood based on the virtual MAC (vMAC) addresses assigned to the gateways and associated with a list of gateways that identify similar gateways.

[0315] The multiple gateways connected to the full site controller are divided into multiple zones.

[0316] The method also includes organizing preset scan schedules into a grid-like scan pattern in the network, specifying that alternating gateways operate at distinctly different scan intervals to minimize overlap and optimize resource allocation.

[0317] The preset filtering criteria used in the method may include a minimum signal strength threshold to prioritize connections with devices that have stronger signals and higher signal-to-noise ratios (SNR). The filtering criteria also include vMAC addresses, which serve as virtual identifiers assigned to IoT devices. In another embodiment, the preset filtering criteria include a cached history of preferred or previous connections between the IoT device and the gateway. If a broadcast message from the same device is received by multiple gateways, the connection will be prioritized with the gateway to which the device was previously connected. The history of preferred connections between the device and the gateway may also be stored within the gateway or on a cloud configuration server to facilitate the preferred device connection process.

[0318] For reference Figure 9 The diagram shown is an illustrative flowchart of a broadcast message filtering method 900 according to one embodiment.

[0319] In 902, the method includes determining whether a broadcast message received from an IoT device at a first gateway meets a preset filtering criterion.

[0320] Broadcast message data from IoT devices includes device-specific details such as Media Access Control (MAC) address, Virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, sensor readings, and operational status indications.

[0321] In 904, the method includes transmitting a coordination signal to a first gateway. If the broadcast message meets preset filtering criteria, the coordination signal is configured to establish a connection between the first gateway and the IoT device.

[0322] In 906, the method includes establishing a connection between the gateway and the IoT device if the broadcast message meets preset filtering criteria. The connection establishment process includes verifying device attributes according to the preset filtering criteria and ensuring compliance with security and network protocols.

[0323] In 908, the method includes transmitting a preset processing protocol to a first gateway. The preset processing protocol can be executed on the first gateway when a connection is established between the first gateway and the IoT device. The preset processing protocol includes multiple operational actions directed to the IoT device.

[0324] Operational actions may include displaying instructions, such as updating electronic shelf label (ESL) information, receiving and processing sensor data, transmitting actuator control signals, performing equipment diagnostics, updating firmware or software configurations, generating alarms or notifications, executing equipment status update commands, or synchronizing data logs with connected gateways or cloud systems. These actions may also include adjusting communication parameters, such as data transmission intervals, power-saving measures, or prioritizing high-critical equipment tasks, to optimize network performance and ensure seamless equipment functionality.

[0325] The method also includes updating preset filtering criteria based on user command data received from user terminals. The filtering criteria and processing protocols can also be dynamically modified via configuration data or user command data transmitted from the configuration server, enabling adjustments based on changing network conditions or policies.

[0326] The method also includes establishing connections with IoT devices based on an approved device list, which includes qualified devices determined by permission identifiers such as vMAC addresses, device types, or service identifiers. For example, a device is allowed to connect to the network when a broadcast message includes a vMAC address or device identifier that matches a list entry. The approved device list can be updated using configuration data from a configuration server, adjusting parameters or adding new device entries to adapt to changes in network or security requirements.

[0327] In another embodiment, the method further includes prioritizing connections based on a cached history of preferred or previous connections between the IoT device and the gateway. When a broadcast message from the same device is received by multiple gateways, the method prioritizes connecting the device to the gateway it has previously connected to (if any). The cached connection data may also be stored within the gateway or configuration server to enhance the discovery process by reusing details of previous connections.

[0328] The method involves applying preset filtering criteria to detect unauthorized or spoofed devices attempting to connect. Filtering criteria include spoofing data indicators such as irregular time intervals between broadcast messages, inconsistent signal strength, lack of any cached previous connections, unidentified device types, and identifiers previously flagged as spoofed.

[0329] The method also includes deduplicating IoT device data by parsing and deduplicating broadcast messages received from the same IoT device across multiple gateways. The deduplication process includes extracting identifiers (such as MAC or vMAC addresses) to detect whether messages originate from the same IoT device. In cases where duplicate packets are identified by matching vMAC addresses, the method includes merging these packets or eliminating unnecessary copies for efficient processing.

[0330] For reference Figure 10 The diagram shown is a schematic flowchart of an example device allocation method (such as switching method 1000) according to one embodiment.

[0331] In 1002, the method includes collecting network health data and gateway health data from the source gateway. Network health data includes metrics such as packet loss, signal strength, response time, latency indication, connection stability, connection failure, response failure, packet retry, diagnostic error reports, data consumption, noise levels across communication channels, and spectrum capacity. Additionally, network health data may include network noise measurements indicating inter-channel interference caused by factors such as external radio frequency interference or overlapping signals from nearby devices, as well as spectrum capacity.

[0332] The method also includes generating device monitoring data to assess the health and functionality of IoT devices connected to the system. Device monitoring data includes metrics such as battery level, signal strength, communication logs, status reports, performance indicators, connectivity status, error logs, uptime, and other operational metrics related to device availability and health.

[0333] In 1004, the method includes transmitting a device allocation signal to a source gateway, the device allocation signal being configured to initiate a device allocation routine when the source gateway meets a device allocation trigger, wherein the device allocation trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. For a load balancing event, the trigger occurs when the network load exceeds a load threshold defined in network health or device monitoring data (such as high CPU usage, memory consumption, or congestion metrics). In a failover event, an unexpected failure of the gateway or planned maintenance activates the device allocation trigger, prompting the reconfiguration of connected IoT devices. A roaming event is triggered when an IoT device physically moves within the network, detecting a change in proximity from one gateway to another via a stronger signal at the target gateway. User-initiated events allow manual initiation of device allocation to a target gateway based on user input.

[0334] In 1006, the method includes determining the target gateway based on multiple selection parameters within a device allocation routine.

[0335] In 1008, the method includes receiving device details from a source gateway. The device details include data representing the IoT device's connection status and / or identifier, representing parameters required to establish, maintain, or identify the device's connection to the gateway. The device details may include data elements such as protocol version required to maintain an uninterrupted device connection, vMAC address, timing data, device-specific identifiers, identifiers associated with multiple devices, encryption keys, communication status, and device status indications. The device details are transmitted from the source gateway to the target gateway via inter-gateway data, or provided separately, enabling the target gateway to adopt the device's connection status. Alternatively, the device details can be exchanged via a full-site controller connecting both the source and target gateways.

[0336] In 1010, the method includes transmitting device details to a target gateway to enable an IoT device to connect to the target gateway, wherein the device details include the vMAC address of the source gateway.

[0337] The method also includes, in the event of device allocation triggering (such as user-initiated, cloud-initiated, load balancing, or roaming events), using a device allocation routine to instruct the source gateway to stop connection attempts or communication with the specified IoT device, while concurrently allocating the target gateway to assume connection responsibilities. In failover scenarios, the method includes notifying the connected gateway to take over device connections from inactive gateways and transmitting device details (such as vMAC address and / or device identifier) ​​to the specified gateway.

[0338] In embodiments specific to Periodic Broadcast with Response (PAwR) communication, the method includes coordinating the transmission of connection responsibilities during an ongoing PAwR sequence. The method also includes synchronizing parameters such as timing offsets and channel hopping sequences between the source and target gateways to maintain seamless PAwR transmission and ensure uninterrupted connection.

[0339] The various embodiments described herein are not mutually exclusive and can be combined or implemented in any suitable manner to achieve the desired functionality. Various changes, modifications, and equivalent substitutions can be made to the disclosed embodiments without departing from the scope of this disclosure. For example, components, data exchanges, and processes described in one embodiment may be adapted or used in another embodiment to provide enhanced functionality. Furthermore, steps or operations attributable to one component may be performed by another component or distributed across multiple components in some embodiments. Such combinations, modifications, and alternative implementations are intended to fall within the scope of this disclosure.

Claims

1. A site-wide controller device, configured as follows: Collect network health data and gateway health data from the source gateway; A device allocation signal is transmitted to the source gateway. The device allocation signal is configured to start a device allocation routine when at least one device allocation trigger criterion is met at the source gateway. The device allocation trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. Within the device allocation routine, the target gateway is determined based on multiple selection parameters; Receive detailed IoT device information from the source gateway; as well as The IoT device details are transmitted to the target gateway to enable the IoT device to connect to the target gateway, wherein the IoT device details include at least one identifier associated with at least one of the IoT devices or multiple IoT devices, the identifier being used by the source gateway to connect to the IoT device.

2. The full-site controller device of claim 1, wherein the gateway health data includes at least one of the following: CPU load, memory usage, network throughput, radio utilization including transmission, reception and idle timing, reported and assigned device type combination, received signal strength, transmission power, response time, timeout event, delay indication, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error report, data consumption, noise level across communication channels, channel mapping, spectrum capacity or packet loss.

3. The full site controller device of claim 1, wherein the load balancing event occurs in response to the source gateway's gateway health data exceeding a load threshold based on at least one of CPU usage, memory consumption, or congestion metrics.

4. The site-wide controller device of claim 1, wherein the failover event occurs in response to a fault or maintenance downtime experienced by the source gateway.

5. The site-wide controller device of claim 1, wherein the roaming event occurs in response to at least one of the following: The full-site controller determines a signal strength difference based at least in part on gateway data received from the target gateway, which indicates that the target gateway is receiving a signal with a first signal strength from an IoT device, the first signal strength being greater than a second signal strength received by the source gateway, or The full-site controller determines the movement of the IoT devices based at least in part on a predictive roaming model that includes historical model data related to signal strength data.

6. The full-site controller device of claim 1, wherein the identifier associated with at least one of one or more IoT devices includes at least one of a MAC address or a vMAC address.

7. The full-site controller device of claim 1, wherein the plurality of selection parameters of the target gateway includes at least one of the following: load capacity, radio availability, proximity of the target gateway to the IoT device, signal strength, communication history of the target gateway to the IoT device, or spectrum resources.

8. The full-site controller device of claim 1, wherein the IoT device details include at least one of the following: timing data, device-specific identifier, encryption key, communication status, device status indication, or protocol version.

9. A network reconfiguration method, the method comprising: Collect network health data and gateway health data from the source gateway; A device allocation signal is transmitted to the source gateway. The device allocation signal is configured to start a device allocation routine when a device allocation trigger is met at the source gateway. The device allocation trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. Within the device allocation routine, the target gateway is determined based on multiple selection parameters; Receive detailed IoT device information from the source gateway; as well as The IoT device details are transmitted to the target gateway to enable the IoT device to connect to the target gateway, wherein the IoT device details include at least one identifier associated with at least one of one or more IoT devices, the identifier being used by the source gateway to connect to the IoT device.

10. The method of claim 9, wherein the gateway health data includes at least one of the following: CPU load, memory usage, network throughput, radio utilization including transmission, reception and idle timing, reported and assigned device type combinations, received signal strength, transmission power, response time, timeout events, delay indication, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error reports, data consumption, noise level across communication channels, channel mapping, spectrum capacity, or packet loss.

11. The method of claim 9, wherein starting the device allocation routine in response to the load balancing event comprises starting the device allocation routine in response to the source gateway's gateway health data exceeding a load threshold based on at least one of CPU usage, memory consumption, or congestion metrics.

12. The method of claim 9, wherein starting the device allocation routine in response to the failover event includes starting the device allocation routine in response to the source gateway experiencing a fault or maintenance downtime.

13. The method of claim 9, wherein in response to the roaming event, activating the device allocation routine includes activating the device allocation routine in response to at least one of the following: The signal strength difference is determined, at least in part based on gateway data received from the target gateway, which indicates that the target gateway is receiving a signal with a first signal strength from the IoT device, the first signal strength being greater than a second signal strength received by the source gateway, or The movement of the IoT device is determined, at least in part, based on a predictive roaming model that includes historical model data related to signal strength data.

14. The method of claim 9, wherein the identifier associated with at least one of an IoT device or multiple IoT devices includes at least one of a MAC address or a vMAC address.

15. The method of claim 9, wherein the plurality of selection parameters of the target gateway includes at least one of the following: load capacity, radio availability, proximity of the target gateway to the IoT device, signal strength, communication history of the target gateway to the IoT device, or spectrum resources.

16. The method of claim 9, wherein the IoT device details include at least one of the following: timing data, device-specific identifier, encryption key, communication status, device status indication, or protocol version.

17. A computer-readable storage medium having instructions stored thereon, the instructions configuring the processor when executed by a processor: Collect network health data and gateway health data from the source gateway; A device allocation signal is transmitted to the source gateway. The device allocation signal is configured to start a device allocation routine when a device allocation trigger is met at the source gateway. The switching trigger includes at least one of a load balancing event, a failover event, a roaming event, or a user-initiated event. Within the device allocation routine, the target gateway is determined based on multiple selection parameters; Receive detailed IoT device information from the source gateway; as well as The IoT device details are transmitted to the target gateway to enable the target gateway to connect to the IoT device, wherein the IoT device details include at least one identifier associated with at least one of one or more IoT devices, the identifier being used by the source gateway to connect to the IoT device.

18. The storage medium of claim 17, wherein the gateway health data includes at least one of the following: CPU load, memory usage, network throughput, radio utilization including transmission, reception and idle timing, reported and assigned device type combinations, received signal strength, transmission power, response time, timeout events, delay indication, clock accuracy, connection stability, connection failure, response failure, packet retry, diagnostic error report, data consumption, noise level across communication channels, channel mapping, spectrum capacity, or packet loss.

19. The storage medium of claim 17, wherein the load balancing event occurs in response to the source gateway's gateway health data exceeding a load threshold based on at least one of CPU usage, memory consumption, or congestion metrics.

20. The storage medium of claim 17, wherein the failover event occurs in response to a failure or maintenance downtime experienced by the source gateway.

Images