Systems and methods for managing and coordinating a network of wireless internet of things (IoT) devices

Abstract

The present disclosure provides, in various embodiments, a system, method, and device for coordinating IoT device wireless networks. The method can include transmitting a coordination signal to a first gateway and a second gateway to coordinate a discovery process. A pause signal can be transmitted to one or more of the first gateway or the second gateway based on a pause criteria to cause a pause of the discovery process at the first gateway or the second gateway.

Description

[0001] Cross-referencing related applications This application claims the benefit of U.S. Nonprovisional Application No. 19 / 056,242, 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 for Internet of Things (IoT) devices. Specifically, these embodiments relate to edge computing platforms for managing high-density 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 each other and with external systems, typically requiring minimal human intervention. IoT devices often include sensors that monitor parameters in their 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, enabling 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 network-connected controller. 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 employ 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. Such gateways can also translate communication protocols and perform local processing to optimize network performance. Gateways can also implement edge computing technologies, where some data processing tasks are performed locally rather than sending 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 IoT devices to the gateway 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, it must wait for the current association to time out before initiating the onboarding process with the new 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] In large-scale IoT network deployments, the lack of coordination between gateways presents technical challenges that impact network performance, resource efficiency, and connection reliability. When multiple gateways operate independently within overlapping coverage areas, IoT devices may simultaneously send broadcast messages to multiple gateways, leading to message processing redundancy. Because gateways cannot determine whether neighboring gateways have already received a broadcast message, they may process the message independently, causing duplicate network communication. This duplication consumes valuable processing and bandwidth resources, exacerbates network congestion, and reduces data transmission efficiency. Furthermore, the independent processing of identical messages puts pressure on cloud servers and other backend systems, as duplicate data is transmitted, processed, and stored, potentially exceeding storage limits and degrading overall system performance.

[0016] In the absence of inter-gateway coordination, a network may be unable to efficiently manage device allocation among gateways, leading to unreliable connectivity and service interruptions for mobile IoT devices. For example, when an IoT device moves from one coverage area to another, a gateway may attempt to establish a new connection without recognizing the device's existing connections. This lack of coordination in device allocation can result in multiple connection attempts from different gateways. Devices attempting to establish concurrent connections with multiple gateways experience increased latency, interrupted data flow, and higher error rates. These issues can compromise the consistency and stability of network services.

[0017] Furthermore, without data exchange between gateways, they cannot share operational metrics or environmental conditions, leading to inefficient network resource utilization and compromised service quality. For example, gateways may independently scan and process broadcast messages from the same IoT device within overlapping time windows, increasing the likelihood of packet loss. If a gateway is unaware of the operational status of neighboring gateways, it cannot adjust its scanning time, power level, or radio channel allocation in response to local network conditions. This lack of synchronization results in wasted energy consumption on the gateways as multiple units redundantly handle the same tasks.

[0018] A lack of coordination between gateways also limits the network's ability to perform predictive maintenance, load balancing, and failover. Gateways that cannot exchange data cannot detect and respond to failed or overloaded neighboring gateways, reducing the overall resilience of the network. For example, when a gateway encounters a connectivity failure or begins operating below its optimal capacity, nearby uncoordinated gateways will not receive alerts and cannot adjust their operations to balance network load or temporarily take over the functions of the affected gateway. Without coordinated data sharing, dynamic network adjustments are difficult to implement, leading to network stagnation and increased downtime during gateway failures.

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

[0020] 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).

[0021] In one aspect, this document provides a system including a first gateway and a second gateway, and a full site controller device configured to connect to the first gateway and the second gateway. The full site controller is configured to transmit a coordination signal configured to coordinate the discovery process of the first gateway and the second gateway based on a scan schedule that provides coordinated scan parameters. One or more of the full site controller, the first gateway, and the second gateway may cause the discovery process to be paused on the first gateway or the second gateway, or simultaneously on both, based on the satisfaction of one or more pause criteria. The pause criteria may include at least one of the following: a threshold number of broadcast messages received on the first gateway or the second gateway, or the first gateway or the second gateway, or both, having cached discovery information related to the discovery process. The discovery process may include receiving multiple broadcast messages on the first gateway or the second gateway. In some embodiments, the broadcast messages may include one or more of the following: an IoT device media access control (MAC) address, an IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings. In some embodiments, the scan schedule may include at least one of the following: allocation of broadcast channels, timing schedules, or scan intervals. In some embodiments, the device discovery process is paused by pausing multiple low-priority discovery processes on a first or second gateway. These processes may include one or more of the following: authentication checks, detailed capability queries, or security key exchanges. In some embodiments, the pause criteria may include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification. In some embodiments, the first and second gateways may be determined to be in the same proximity area based on a first virtual MAC (vMAC) address assigned to the first gateway and a second vMAC address assigned to the second gateway, wherein both the first and second vMAC addresses are associated with a mapping framework that identifies a list of nearby gateways. In some embodiments, the full-site controller may be configured to receive an indication from the first or second gateway, or both, that the pause of the discovery process is covered, the coverage being determined based on at least one of the first or second gateways.

[0022] In one aspect, this document provides a method comprising transmitting a coordination signal to a first gateway and a second gateway. The coordination signal is configurable to coordinate the discovery process of the first and second gateways based on a scan schedule that provides scan parameters for coordination between the first and second gateways. The method may further include updating the scan schedule based on user instruction data received from a user terminal, full-site controller, cloud configuration server, or one or more received configuration data. The method may also include pausing the discovery process on the first or second gateway, or simultaneously on both, at least in part based on the first or second gateway or both meeting one or more pause criteria. Pause criteria may include at least one of the following: a threshold number of broadcast messages received on the first or second gateway, or a situation where the discovery process includes receiving multiple broadcast messages on the first or second gateway. In some embodiments, broadcast messages may include one or more of the following: IoT device media access control (MAC) address, IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings. In some embodiments, scan scheduling may include at least one of the following: allocation of broadcast channels, timing schedules, or scan intervals. In some embodiments, pausing the discovery process can be configured to pause multiple low-priority discovery processes on a first or second gateway. These processes may include one or more of the following: authentication checks, detailed capability queries, or security key exchanges. In some embodiments, pausing criteria may include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification. In some embodiments, the first and second gateways may be determined to be in the same proximity area based on a first virtual MAC (vMAC) address assigned to the first gateway and a second vMAC address assigned to the second gateway, and both the first and second vMAC addresses are associated with a mapping framework that identifies a list of nearby gateways. In some embodiments, the full site controller may connect to multiple gateways divided into multiple areas.

[0023] In one aspect, this document provides a first gateway device connected to a full site controller, configured to receive a coordination signal from the full site controller. This coordination signal can be configured to coordinate the discovery process of the first gateway based on a scan schedule that provides scan parameters for coordination between the first and second gateways. The first gateway device can also be configured to pause the discovery process on the first gateway device based on the first gateway device meeting one or more pause criteria. The pause criteria can include one or more of the following: a threshold number of broadcast messages received on the first gateway device, or the discovery process may involve receiving multiple broadcast messages on the first gateway device. In some embodiments, broadcast messages can include one or more of the following: IoT device media access control (MAC) address, IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings. In some embodiments, scan scheduling can include at least one of the following: allocation of broadcast channels, timing schedules, or scan intervals. In some embodiments, pausing the discovery process can be configured to pause multiple low-priority discovery processes on the first gateway device, which may include one or more of the following: authentication checks, detailed capability queries, or security key exchanges. In some embodiments, the suspension criteria may include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification. In some embodiments, based on a first virtual MAC (vMAC) address assigned to a first gateway and a second vMAC address assigned to a second gateway, it is determined that the first gateway and the second gateway are located in the same proximity area, and both the first vMAC address and the second vMAC address are associated with a mapping framework that identifies a list of nearby gateways. Attached Figure Description

[0024] 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.

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

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

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

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

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

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

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

[0032] 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.

[0033] 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.

[0034] It should be noted that this document uses approximate terminology to allow for reasonable deviations from literal values, 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.

[0035] 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.

[0036] 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 and may be applied to other embodiments throughout this disclosure. References herein to “module,” “component,” or “subcomponent” are intended to include, but are not limited to, processing blocks within a processor or other functional units in hardware, software, or a combination thereof. These terms should not be interpreted narrowly but may refer to any mechanism or structure that performs the functions described.

[0037] 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.

[0038] 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.

[0039] 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 connected gateways, enabling real-time adjustment of network parameters, load balancing, and seamless device allocation (including 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 enables dynamic aggregation, filtering, and synchronization of data, reducing packet collisions, reducing 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.

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

[0041] 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.

[0042] 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.

[0043] 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 more than one embodiment, 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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 transmit 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 protocols used on network 102 may vary depending on the type of IoT device 1010. 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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 bidirectional data exchange by routing IoT device data and gateway data. The 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.

[0056] 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.

[0057] 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.

[0058] 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 coordinate scanning windows 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 gateway from becoming overloaded.

[0059] 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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 data flows between devices, gateways, and cloud systems.

[0067] 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.

[0068] 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.

[0069] 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, enabling gateways to switch to alternative communication settings during network outages to improve connectivity.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] In another embodiment, container management component 1108 supports the deployment of Snaps or self-included packages. Snaps can bundle necessary dependencies with an application, providing consistency across different environments and minimizing compatibility issues. 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 only data or configuration areas as writable.

[0076] 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.

[0077] 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 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.

[0078] 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.

[0079] 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.

[0080] In one embodiment, the discovery process may include service discovery and / or IoT device discovery and authentication, which may be initiated by an 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 a predefined scanning window to ensure that no device broadcasts are missed.

[0081] 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.

[0082] 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 enables 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 improved 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.

[0083] 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 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 low-power roles, performing less power-intensive tasks to extend their operational lifespan within the network.

[0084] 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.

[0085] 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.

[0086] In one embodiment, periodic broadcasting enables gateway 1100 to synchronize with 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 periodic intervals for receiving IoT device data from IoT device 1010 via network 102 and transmitting gateway data to it, ensuring efficient management of large-scale device communication while minimizing latency and packet loss.

[0087] 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 data flow in an environment where thousands of devices operate 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.

[0088] 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.

[0089] 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 included in the 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.

[0090] 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).

[0091] 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 gateways, devices, or both. Virtual addressing provides 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.

[0092] In one embodiment, edge connectivity module 1112 is responsible for local monitoring and control. Edge connectivity module 1112 can monitor the status of connected IoT devices 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 device status indicators with pre-configured thresholds or rules to detect anomalies or trigger specific actions as described below.

[0093] 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.

[0094] 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 multiple conditions. For example, if a connected leak sensor detects water, edge connectivity module 1112 can 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.

[0095] Gateway 1100 can maintain event triggers and local rules for specific scenarios, stored in memory 1150. Event triggers and rules can 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 can 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 enable edge connectivity module 1112 to autonomously initiate actions based on predefined conditions. In one embodiment, configuration data can 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 can include commands such as updating ESL displays with new prices, adjusting temperature control thermostat settings, or activating lighting systems based on store occupancy. Gateway 1100 processes and relays event triggers via network 102 to relevant IoT devices 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.

[0096] 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 sensor data within a short time frame 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.

[0097] 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.

[0098] 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 process 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.

[0099] 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.

[0100] Edge connectivity module 1112 provides resource management by maintaining routing tables and scan intervals for gateways, enabling configuration server 1500 to reassign devices or communication flows to alternative gateways based on reassignment rules in configuration data. Alternatively, reassignment 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 (such as switching) to another gateway without interrupting communication by the IoT device. In one embodiment, edge configuration data can trigger device assignment to another gateway.

[0101] 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 enable users to access and interact with network management and monitoring interfaces.

[0102] 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.

[0103] 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.

[0104] 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, enabling repeated execution without additional instructions from the cloud. Alternatively, real-time instructions within the application data can be provided to meet immediate operational needs.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

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

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] 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 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.

[0125] 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.

[0126] 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.

[0127] The recipe management engine 1506 processes user instruction data received from terminals connected to the configuration server 1500, enabling 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.

[0128] 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 the configuration data, allowing adjacent gateways to take over pending tasks without interruption.

[0129] 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.

[0130] 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.

[0131] 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. Inter-gateway data can be transmitted to the configuration server 1500 in cloud-directed data, providing 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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, enabling the execution of control operations without requiring new instructions for tasks, reducing latency and reliance on cloud connectivity.

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

[0143] 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.

[0144] 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.

[0145] 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 enables third-party systems to interact with connected IoT devices by storing operational settings locally within the gateway, allowing repetitive actions to be performed without frequent cloud communication.

[0146] 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 enables the vendor to track the operational performance of connected IoT devices or detect anomalies.

[0147] 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.

[0148] 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.

[0149] 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 multiple 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.

[0150] 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.

[0151] The edge connectivity platform facilitates low-latency detection and network access for IoT devices 1010, supporting device allocation when IoT devices 1010 are moved between the coverage areas of gateway 1100 within network 108. By managing load balancing and coordinating device allocation (such as handover) 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 IoT devices 1010 to be identified and processed across multiple gateways.

[0152] 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.

[0153] In one embodiment, the edge connectivity platform 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.

[0154] 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.

[0155] Configuration server 1500 generates configuration data, including parameters and attributes associated with the connected IoT device 1010. This configuration data enables 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.

[0156] 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.

[0157] Gateway 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 Labels (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 Gateway 1100 to operate with customized settings, optimizing network behavior for different use cases in diverse environments, while also enabling unified control over large-scale distributed device deployments.

[0158] 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. The edge connectivity module generates and is responsible for exchanging data between gateways to coordinate responses to network events.

[0159] 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 for 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 the gateways adhere to the unified policies implemented throughout the site.

[0160] In addition, the edge connectivity module generates and transmits cloud-oriented data to configuration servers 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 updates are synchronized across the entire system's gateways.

[0161] 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 manages data exchange between gateways and synchronizes operational responses across connections, handling full-site coordination. 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 intervals, managing load balancing, and enforcing device allocation rules across gateways, enabling the 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.

[0162] 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 within a specific scanning window. The scanning window within a gateway refers to the configuration of the gateway's radio module to actively listen on specific broadcast channels within the spectrum. For example, the scanning window 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 scanning parameters across gateways.

[0163] Edge connectivity module 1112 within gateway 1100 manages the scanning window 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 intervals, timing schedules, and broadcast channels to gateways. The preset scan schedule is configured to allow 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. Edge connectivity module 1112 utilizes proximity data, including packet MAC or vMAC addresses of adjacent 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, enabling the edge connection module 1112 to synchronize scanning modes, share scanning schedules, and adjust timing in real time.

[0164] 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 intervals, timing schedules, 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, enabling dynamic allocation and modification.

[0165] 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.

[0166] In one embodiment, the edge connectivity module applies a preset latency criterion to optimize the discovery process (including service discovery and / or device discovery processes) and IoT device data processing for connected IoT devices. The discovery process (e.g., service discovery, device discovery, and / or other discovery processes) 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 latency 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 portions 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 portions 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. Preset delay criteria (also known as pause criteria) can also include additional attributes, such as device priority, battery level, or specific device category, to modify the discovery process. In one example, device category may include one or more characteristics associated with one or more devices, such as a list or range of MAC addresses. This list or range of MAC addresses can be predetermined or determined based on a pattern, such as a range of MAC addresses associated with devices from a particular manufacturer or a particular device type. The pattern associated with MAC addresses can be automatically determined from a variety of information. 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.

[0167] 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.

[0168] By assigning different scanning parameters or channels to gateways, the system reduces the possibility of inconsistencies such as overlapping or "shadow" networks, ensuring full coverage and improving the efficiency of capturing broadcast messages from IoT devices distributed throughout the site. Edge connectivity module 1112 can utilize inter-gateway data to optimize scanning patterns, 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.

[0169] 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 that 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 scan scheduling, distribute preset filtering criteria, and adjust service discovery parameters to implement network-wide policies. 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 operational rules, eliminating the need for inter-gateway data synchronization by performing coordination within the controller 2300 itself.

[0170] 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 enable 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) addresses, virtual MAC (vMAC) addresses, 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 distinguish 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.

[0171] 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 conditions. For example, a higher received signal strength threshold can be applied to channels or frequencies experiencing high noise levels or increased channel activity.

[0172] 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, enabling cloud configuration server 1500 to remotely and dynamically adjust the virtual addressing scheme.

[0173] 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 an 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 one or more different gateways. 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 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 transition to an alternative radio without requiring the wireless device to re-establish its connection. Device information maintained based on MAC addresses and / or device-associated identifiers enables device allocation by associating the device allocation protocol with the vMAC address and / or device-associated identifier used during initial connection.

[0174] 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.

[0175] 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 the filtering criteria and apply them to incoming broadcast messages from IoT devices. The preset filtering criteria can be updated based on configuration data or user instruction data received from a configuration server 1500, enabling responsive adjustments to the 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 repeatedly or at scheduled intervals 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 enables the edge connectivity module 1112 within the gateway to share filtering criteria, device status information, and operational metrics, maintaining filtering at the network layer 1004. This coordination ensures the uniform application of filtering criteria, thereby improving system performance and preventing redundant processing across gateways. The edge connectivity module 1112 in the gateway can process inter-gateway data to update or adjust filtering criteria as needed, thus providing a scalable implementation for handling high-density IoT devices in distributed networks.

[0176] 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.

[0177] 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 service discovery process by caching connection details of completed service 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 service discovery, the edge connectivity module retrieves the stored connection information, enabling the IoT device to bypass redundant parts of the service discovery process. The caching mechanism can reduce processing load by leveraging previous connections to accelerate the discovery of identical or compatible devices.

[0178] 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 service discovery for the same IoT device. By utilizing cached connectivity data, the edge connectivity module initiates connections, streamlining the reconnection process.

[0179] In one embodiment, a cloud configuration server can provide configuration data to dynamically adjust the service discovery protocol of the edge connectivity module. The cloud configuration server can transmit parameters, such as updated filtering thresholds or instructions for caching service 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 service discovery adjustments across multiple gateways, ensuring consistent standards and caching techniques are applied throughout the network layer.

[0180] Inter-gateway data flow enables 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.

[0181] 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.

[0182] In one embodiment, device coordination can be achieved by utilizing, for example... Figure 2 The 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 criteria across all connected gateways. This configuration enables 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 criteria in the gateways, including caching for connection priorities, vMAC allocation, and device-specific preferences, streamlining the coordination process for managing IoT device connectivity in a distributed network environment. The full-site controller 2300 communicates with gateways to provide inter-gateway coordination, rather than exchanging data between gateways. This centralized structure allows the full-site controller to act as a central node enforcing operating rules, eliminating the need for inter-gateway data synchronization by performing coordination within the controller 2300 itself.

[0183] Coordinate equipment allocation In one embodiment, an edge connectivity module within a gateway coordinates downtime events to provide coverage and connectivity for IoT devices in the network. When a gateway (such as gateway 1100) is scheduled for maintenance or experiences an unexpected downtime, inter-gateway data enables neighboring gateways (such as gateways 1200 and 1300) to synchronize their connectivity status and device handling responsibilities. The edge connectivity modules of neighboring gateways apply preset filtering criteria to evaluate which gateway is best suited to take over IoT device connections from inactive gateways. These criteria include proximity to the IoT device, the highest signal strength received from the device, and any cached history of previous connections. These criteria enable the edge connectivity modules to dynamically allocate device connections, ensuring a seamless transition and continuous service reception for the devices. Inter-gateway data includes the operational status of the gateways in network 108. When gateway 1100 enters a downtime phase, inter-gateway data transmits real-time updates on network state changes to other gateways. The edge connectivity modules in gateways 1200 and 1300 then evaluate the preset filtering criteria and, based on the strongest available signal or device proximity, determine which gateway will take over IoT devices previously connected to inactive gateways. This device allocation mechanism enables edge connection modules to prioritize the most stable and nearest connections, automatically adapting to changes in network topology.

[0184] In one embodiment, device allocation coordination can be implemented in an architecture that includes a centralized site-wide controller 2300, such as... Figure 2 As shown, the controller 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 across the entire network through monitoring. Instead of relying on inter-gateway data for direct synchronization, the full-site controller 2300 communicates with gateways to synchronize connection states and dynamically reallocates device handling responsibilities to target gateways. The controller 2300 can apply preset filtering criteria to determine the most suitable gateway to take over device connections to inactive gateways, ensuring uninterrupted service. The full-site controller 2300 provides real-time status updates on network changes to connected gateways and cloud servers.

[0185] formula In one embodiment, the edge connectivity module 1112 within gateway 1100 is configured to dynamically apply recipes to manage and respond to broadcast messages from newly detected or surrounding IoT devices. When a previously unknown device type is detected, the edge connectivity module queries a specified recipe associated with that device type. This query may include forwarding the initial broadcast message from the IoT device to a cloud configuration server that stores and maintains recipes. Alternatively, recipes may be stored on a recipe server or storage device connected to the cloud configuration server. Recipes include configuration instructions for a specific processing protocol for broadcast messages from identified devices, including processing methods and routing paths. Once a recipe is retrieved, it is applied locally within gateway 1100 to establish standardized processing actions for future broadcast messages received from that type of device.

[0186] In an alternative embodiment, the cloud configuration server can periodically or in real-time update the recipe configuration, enabling edge connectivity modules in the gateway to dynamically adjust their responses to new or surrounding devices detected in the field. The edge connectivity modules coordinate via inter-gateway data to ensure that updated recipes are synchronized across gateways in the network, resulting in improved processing behavior. By leveraging recipes, the system implements an adaptive response framework, ensuring that newly encountered devices are appropriately categorized and handled throughout the site.

[0187] In one embodiment, recipe management and application can be implemented in an architecture that includes a centralized full-site controller 2300, such as... Figure 2 As shown, the controller connects to one or more gateways, such as gateways 2100 and 2200. The full-site controller 2300 includes an edge connectivity module that centrally handles the dynamic application and synchronization of recipes to manage and respond to broadcast messages from newly detected or surrounding IoT devices. Instead of synchronizing recipes through inter-gateway data exchange, the full-site controller 2300 transmits recipe updates and instructions to connected gateways to provide recipe-based processing throughout the network. The controller can query recipes from the configuration server 2500 or an associated recipe storage device and then transmit these recipes to the gateways in real-time or at scheduled intervals.

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

[0189] 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 1 The operational behavior, components, sub-components, and descriptions of IoT device 1010 are applicable to Figure 2 IoT devices in 2010 and 2020.

[0190] 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 monitors the connectivity and resource management of gateways 2100 and 2200.

[0191] 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 is connected to gateways, enabling it to perform these functions in a coordinated manner across connected gateways.

[0192] 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.

[0193] 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 device allocation for device transfers 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.

[0194] 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 integration between the IoT devices, gateways, and the full site controller.

[0195] 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. Alternatively, such configuration data may be transmitted from the full-site controller or other sources. 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 may further modify the configuration or application data.

[0196] 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.

[0197] 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.

[0198] 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 configuration application across gateways 2100 and 2200, ensuring 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 related 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.

[0199] 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.

[0200] 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.

[0201] 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.

[0202] 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.

[0203] In one embodiment, the security protocol is implemented within the full-site edge connectivity controller 2300 to ensure data protection across the entire 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.

[0204] 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.

[0205] 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.

[0206] Edge connectivity modules provide unified connectivity for 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.

[0207] 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.

[0208] 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.

[0209] 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 service discovery process 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.

[0210] 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.

[0211] 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.

[0212] 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 suspending the service 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 service discovery process may include receiving multiple broadcast messages at either the first or second gateway.

[0213] A pause criterion is applied to optimize service discovery and IoT device data processing for connected IoT devices. Controller 2300 is configured to dynamically adjust the gateway's service 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 transmits a pause signal to the gateway to selectively postpone specific portions of the service 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.

[0214] 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.

[0215] 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.

[0216] Coordinate equipment allocation Controller 2300 is configured to generate network health data and gateway health data collected from multiple gateways. Controller 2300 may transmit a device allocation signal to a source gateway, such as to trigger a handover operation. This device allocation signal is configured to execute a device allocation routine when a device allocation trigger or criterion is met at the source gateway. Device allocation triggers may include load balancing events, failover events, roaming events, or user-initiated events. Controller 2300 is configured to determine a target gateway from multiple gateways based on multiple selection parameters within the device allocation routine. Controller 2300 receives device details from the source gateway and transmits these details to the target gateway to enable IoT devices to connect to the target gateway. Device details may include a vMAC address and / or an associated identifier of the source gateway.

[0217] The Controller 2300 uses selection parameters to evaluate which gateway is best suited to handle IoT device connections from inactive gateways. Selection parameters can include any preset filtering criteria.

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

[0219] 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.

[0220] 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 full edge application 3060. The applications include 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 operations 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.

[0221] 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), enabling functionality regardless of the specific edge application logic used. Centralized recipe management reduces redundant processing and promotes operational uniformity across the entire network.

[0222] 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.

[0223] Similarly, edge application logic recipes 3052 and 3062 enable 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 allows data collected from IoT devices to be integrated with enterprise systems. For vendors or third parties deploying dedicated equipment, the complete edge application recipes integrate both device-specific and application-specific logic.

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

[0225] 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 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.

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

[0227] 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.

[0228] The edge connectivity module utilizes recipes as modular, version-controlled configurations to enable 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.

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

[0230] 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.

[0231] 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 supports various recipe combinations tailored to specific operational needs for different instances of the edge connectivity module 4010.

[0232] 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 that edge instances receive 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.

[0233] 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, supporting Configuration Server 4020 in accessing and distributing the latest, verified versions.

[0234] 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 edge connectivity instances.

[0235] 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.

[0236] A centralized configuration and recipe management approach enables 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 instances of edge connectivity modules 4010 that depend on that recipe. This propagation ensures that connected IoT devices and applications operate on the latest configuration standards, providing uniformity for large-scale IoT networks.

[0237] 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 supporting targeted customization when necessary.

[0238] 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.

[0239] In one embodiment, the edge connection module 4010 may represent Figure 1 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.

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

[0241] "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, allowing for further processing, analysis, and storage of data within the cloud. 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 interact with cloud services from different vendors, providing flexibility for managing multi-vendor IoT networks.

[0242] 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.

[0243] 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.

[0244] 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.

[0245] 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.

[0246] 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.

[0247] 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.

[0248] "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.

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

[0250] 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.

[0251] In this embodiment, the pipeline 6010 may include one or more sequentially arranged filters to 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 may adjust event parameters or attach additional metadata, effectively preparing the event for subsequent actions. Filter 2 may be configured to alter the internal state of the edge connectivity module, influencing other connected IoT devices or system processes in real time. Afterward, the event reaches filter 3, the final stage of the pipeline. Filter 3 determines whether the event meets the criteria for a response in the connection sequence 6020. Filter 3 may terminate pipeline 6010 by terminating unnecessary events or by issuing refined events that may trigger new filters or connection sequences.

[0252] 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 actions 1, 2, and 3) represents a control response process designed to interact with the device or platform in a defined order. Note that in other embodiments, the number of actions may be more, less, or equal to the number described in this example. 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 the connection is established, the process moves to action 2, where the edge connectivity module enables notifications or updates from the device. Action 2 may include entering a state of listening to periodic data, thereby enabling real-time monitoring of the device 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.

[0253] 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, enabling the edge connectivity module 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.

[0254] The pipeline and connection sequence model supports change 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 can use filter 2 to evaluate event frequency and determine whether the notification loop should continue based on data patterns.

[0255] 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.

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

[0257] 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.

[0258] 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 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.

[0259] 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.

[0260] 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, enabling the application to perform initial verification of the ESL's identity, confirming its legitimacy before further processing.

[0261] 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.

[0262] After 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, having met the prerequisites for the authentication session, the edge connectivity module enables the application to securely initiate data transmission.

[0263] 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.

[0264] 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.

[0265] 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.

[0266] In one embodiment, the edge connectivity module can refer to Figure 1 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.

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

[0268] 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 service discovery process of the first gateway and the second gateway based on scan scheduling that provides non-overlapping scan parameters for the first gateway and the second gateway, wherein the first gateway and the second gateway are located in a neighboring area.

[0269] 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.

[0270] 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.

[0271] 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 service 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 service discovery process includes receiving multiple broadcast messages at either the first gateway or the second gateway.

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

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

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

[0275] 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.

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

[0277] 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 system comprising: First gateway and second gateway; The full site controller device is configured to connect to the first gateway and the second gateway, and the full site controller is further configured to... A coordination signal is transmitted to the first gateway and the second gateway, the coordination signal being configured to coordinate the discovery process of the first gateway and the second gateway based on a scan schedule, the scan schedule providing coordinated scan parameters for the first gateway and the second gateway, wherein the first gateway and the second gateway are located in a proximity area. The scan schedule is updated based on user instruction data received from the user terminal and configuration data received by one or more of the full site controllers or configuration servers. as well as The full site controller, the first gateway, or one or more of the second gateways, at least in part based on the first gateway or one or more of the second gateways meeting a suspension criterion, causes the discovery process to be suspended at one or more of the first gateways or the second gateways, wherein the suspension criterion includes at least one of the following: a threshold number of broadcast messages received at one of the first gateways or the second gateways, or one or more of the first gateways and the second gateways having cached discovery information related to the discovery process, wherein the discovery process includes receiving multiple broadcast messages at either the first gateway or the second gateway.

2. The device of claim 1, wherein the broadcast message includes one or more of the following: IoT device media access control (MAC) address, IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings.

3. The device of claim 1, wherein the scan scheduling includes at least one of the following: broadcast channel, timing scheduling, or scan interval allocation.

4. The device of claim 1, wherein pausing the device discovery process is configured to pause a plurality of low-priority discovery processes at one of the first gateway and the second gateway, wherein the plurality of low-priority discovery processes include one or more of the following: authentication checks, detailed capability queries, or security key exchanges.

5. The device of claim 1, wherein the pause criteria include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification.

6. The device of claim 1, wherein the first gateway and the second gateway are determined to be located in the same neighborhood based on a first virtual MAC (vMAC) address assigned to the first gateway and a second vMAC address assigned to the second gateway, and each of the first vMAC address and the second vMAC address is associated with a mapping framework that identifies a list of nearby gateways.

7. The device of claim 1, wherein the full site controller is configured to receive an instruction from one or more of the first gateway or the second gateway to override the pause in the discovery process based on at least one issue determined by the first gateway or the second gateway.

8. A method comprising: A coordination signal is transmitted to the first gateway and the second gateway, the coordination signal being configured to coordinate the discovery process of the first gateway and the second gateway based on a scan schedule, the scan schedule providing coordinated scan parameters for the first gateway and the second gateway, wherein the first gateway and the second gateway are located in a proximity area; The scan schedule is updated based on user instruction data received from the user terminal, configuration data received from the full site controller and one or more cloud configuration servers; as well as The discovery process is suspended at one or more of the first gateways or the second gateways, at least in part, based on the satisfaction of a suspension criterion, wherein the suspension criterion includes at least one of the following: a threshold number of broadcast messages received at one or more of the first gateways or the second gateways, or wherein the discovery process includes receiving multiple broadcast messages at either the first gateway or the second gateway.

9. The method of claim 8, wherein the broadcast message includes one or more of the following: IoT device media access control (MAC) address, IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings.

10. The method of claim 8, wherein the scan scheduling includes at least one of the following: broadcast channel, timing scheduling, or scan interval allocation.

11. The method of claim 8, wherein pausing the discovery process is configured to pause a plurality of low-priority discovery processes at one of the first gateway or the second gateway, wherein the plurality of low-priority discovery processes include one or more of the following: authentication checks, detailed capability queries, or security key exchanges.

12. The method of claim 8, wherein the pause criteria include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification.

13. The method of claim 8, wherein the first gateway and the second gateway are determined to be located in the same neighborhood based on a first virtual MAC (vMAC) address assigned to the first gateway and a second vMAC address assigned to the second gateway, and each of the first vMAC address and the second vMAC address is associated with a mapping framework that identifies a list of nearby gateways.

14. The method of claim 8, wherein the full site controller is connected to multiple gateways divided into multiple regions.

15. A first gateway device connected to a full site controller, the first gateway device being configured to: The system receives a coordination signal from the full-site controller, the coordination signal being configured to coordinate the discovery process of the first gateway based on a scan schedule, the scan schedule providing coordinated scan parameters for the first and second gateways, wherein the first and second gateways are located in a proximity area; and The discovery process is paused at the first gateway device based on the first gateway device meeting the pause criteria, wherein the pause criteria include one or more of the following: a threshold number of broadcast messages received at the first gateway device, or wherein the discovery process includes receiving multiple broadcast messages at the first gateway device.

16. The first gateway device of claim 15, wherein the broadcast message includes one or more of the following: IoT device media access control (MAC) address, IoT device virtual MAC (vMAC) address, signal strength, device type, firmware version, battery status, service UUID, proximity information, or sensor readings.

17. The first gateway device of claim 15, wherein the scan scheduling includes at least one of the following: allocation of a broadcast channel, timing scheduling, or scan interval.

18. The first gateway device of claim 15, wherein pausing the discovery process is configured to pause a plurality of low-priority discovery processes at the first gateway device, wherein the plurality of low-priority discovery processes include one or more of the following: authentication checks, detailed capability queries, or security key exchanges.

19. The first gateway device of claim 15, wherein the suspension criteria include one or more of the following: minimum signal strength threshold, device priority, battery level, or device classification.

20. The first gateway device of claim 15, wherein the first gateway and the second gateway are determined to be located in the same neighborhood based on a first virtual MAC (vMAC) address assigned to the first gateway and a second vMAC address assigned to the second gateway, and each of the first vMAC address and the second vMAC address is associated with a mapping framework that identifies a list of nearby gateways.

Images