METHOD FOR MANAGING SMART INTERNET OF THINGS HUB AND NODE INTERACTIONS

Abstract

A method for managing communication between Internet of Things (IoT) nodes in an IoT environment with an IoT hub involves using a high-power initiator node to request services and identify a candidate intelligent device among the nodes. Depending on a parameter of the initiator node, the intelligent device can flexibly operate as a low-power, high-power, or hybrid device. The method can include selectively assigning the intelligent device as a trusted designated node within the IoT environment. Furthermore, the method includes determining, based on the parameter, an optimal periodicity for communicating status messages from the trusted designated node to the IoT hub.The procedure then involves transmitting the status messages to the hub with the optimal periodicity via the trusted designated node, so that the trusted designated node acts as a proxy for the initiator node when it reports the status messages to the hub.

Description

[0001] The present invention relates to a method for managing communication between Internet of Things (IoT) nodes in a networked IoT environment with the IoT nodes and an IoT hub. INTRODUCTION

[0002] Advances in global automation technology have led to the adoption of Internet of Things (IoT)-based solutions and the associated management of the countless types of connected devices used to implement an IoT environment. Devices and their communication nodes within a connected IoT environment serve to collect and exchange messages, thereby automating and optimizing device-based processes. For example, the charging of a battery-powered electric vehicle or a plug-in hybrid electric vehicle at home can be scheduled and managed via the IoT network of a "smart garage." Such a network can utilize smartphone-based monitoring and opening / closing of garage doors or other access points, control of climate settings such as temperature, humidity, and air quality, and the monitoring / control of other connected systems.IoT networks can also be used in other operational environments, such as the user's home or office, but not only there. Modern industrial and manufacturing environments can also utilize a networked IoT ecosystem to facilitate order placement, track assembly progress, or otherwise enable communication between various connected devices.

[0003] Communication between nodes in a networked IoT environment relies on near-field distance measurement and the reliable exchange of other information via a coordinated exchange of electronic signals or messages. The networked devices / nodes can rely on one or more connectivity technologies, such as Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), cellular, Zigbee, or others, to transmit this measurement data and information. The coordinated operation of potentially disparate technologies in a networked IoT environment is currently facilitated by the open-source standard Matter, which is why networked IoT ecosystems are often referred to as Matter networks.Regardless of the design or subnetworks used in a networked IoT ecosystem, the individual nodes of the ecosystem must regularly communicate with an IoT hub to maintain the status within the ecosystem and control over it.

[0004] For further background information, reference is made to publications US 2017 / 0 280 395 A1 and US 2017 / 0 188 308 A1. SUMMARY

[0005] The present invention relates to a method for managing and controlling a networked Internet of Things (IoT) ecosystem with one or more IoT hubs and a multitude of networked smart devices. Each smart device contains / functions as one or more communication nodes within the IoT ecosystem. As used here, the IoT hub is a central hardware and software device that connects and manages the ongoing exchange of data / messages between connected IoT devices. The IoT hub, which in various implementations can be either local or global / cloud-based, thus acts as a central communication node for the exchange of messages between the connected devices.Some examples of such messages are activation or deactivation commands, telemetry data, performance metrics, software / firmware updates, error states, status, security evidence, timestamps, status reports, and other relevant information or data.

[0006] According to one aspect of the invention, a trusted designated node is dynamically or statically assigned by a service-requesting device (“initiator node”) or an IoT hub in various embodiments. The assignment is based on a parameter of the initiator node, e.g., its current power level or state of charge. The designated node is then used as a “trusted node” within the IoT ecosystem, specifically for the purpose of transmitting status messages to the IoT hub on behalf of the initiator node. As disclosed herein, the term “hybrid device” refers to a smart, high-power device such as an electric vehicle (EV) or a controller with multiple processors / other computing nodes.It can happen that the battery of a high-power device is depleted or its energy budget is reduced, causing it to behave more like a low-power device. Using a parameter in the form of a reduced capacity level or state of charge of an electric vehicle (EV) traction battery, if the initiator node / smart device is the EV, the designated node negotiates an optimal power-on period with the IoT hub.

[0007] In the case of the exemplary EV and its onboard traction battery, periodic message transmission between the EV and the IoT hub during the EV's shutdown mode could rapidly discharge and further deplete the traction battery or any other onboard energy storage system used for this purpose. To address this issue, the method described here involves selectively introducing the trusted designated node into the IoT environment as a trusted node and message proxy. The selection of the trusted designated node is performed in various embodiments, depending on requirements, either by the service-requesting initiator node / device or by the IoT hub. The introduced trusted designated node then acts as a proxy for status messages and other message exchanges with the IoT hub and negotiates the optimal frequency of these reports.

[0008] A method for managing communication between IoT nodes in a networked IoT environment with an IoT hub, according to one embodiment, includes determining a parameter (e.g., the aforementioned capacity level, state of charge, energy budget, etc.) of a service-requesting initiator node with high power consumption in the IoT network, such as an electric vehicle. The method includes identifying, based on this parameter, whether the initiator node is operating in a hybrid power mode. If the initiator node is operating in hybrid mode, which, as used here, occupies a range between high- and low-power modes, the method includes identifying a candidate smart device / node among a multitude of neighboring nodes in the IoT network. The method includes selectively assigning the candidate smart device as the trusted designated node within the IoT network.The procedure also includes determining an optimal periodicity for communicating status messages from the trusted designated node to the IoT hub, based on the initiator node's parameter. Subsequently, the procedure involves transmitting the status messages to the IoT hub at the optimal periodicity via the trusted designated node, so that the trusted designated node acts as a proxy for the initiator node when reporting the status messages to the IoT hub.

[0009] The initiator node can contain a battery, in which case the parameter includes the battery's capacity or state of charge. In one or more embodiments, the initiator node is part of a vehicle equipped with a battery. In such embodiments, determining the optimal periodicity for transmitting status messages is based on the battery's capacity or state of charge.

[0010] The selective introduction of a candidate smart device into the IoT environment can involve selectively introducing an electric vehicle charger into the IoT environment as a trusted designated node, where the electric vehicle charger contains the candidate smart device. The selective introduction of the candidate smart device into the IoT environment can occur during the commissioning of the candidate smart device.

[0011] The optimal periodicity of communication of status messages from the trusted designated node to the IoT hub may include access to a lookup table that is indexed or referenced by the optimal periodicity and the parameter.

[0012] The selective introduction of a candidate smart device into the IoT environment can optionally include the dynamic assignment of the candidate smart device as a trusted designated node during the operation of the IoT environment. For example, the IoT environment might be part of a manufacturing plant, so the dynamic assignment of the candidate smart device as a trusted designated node could include the dynamic assignment of an automation robot or a controller of the manufacturing plant as a trusted designated node during the operation of the manufacturing plant. The dynamic assignment of the candidate smart device as a trusted designated node can also be performed by the initiator node according to a device-based model, e.g.,by selecting the trusted designated node from neighboring / within-range IoT nodes via the initiator node using the device-driven model. Alternatively, the dynamic assignment of the intelligent candidate device as the trusted designated node can be performed by the IoT hub according to a hub-driven model.

[0013] Embodiments of the method may include the following steps: consolidating a status message from the initiator node with a status message from the trusted designated node to create a consolidated report, and regularly transmitting the consolidated report to the IoT hub via the trusted node to reduce the power consumption of the IoT environment. According to one aspect of the invention, a connected IoT environment comprises a

[0014] The IoT hub comprises a variety of IoT devices. Among these devices is a device that requests a service (the "initiator node"). The IoT hub and / or the initiator node is operational to identify, in response to a parameter of the initiator node, a smart candidate device from among the multitude of IoT devices and selectively introduce the smart candidate device into the IoT environment. This last step can include assigning the smart candidate device as a trusted designated node within the IoT environment via the initiator node and / or the IoT hub. In this particular embodiment, the trusted designated node is able to determine an optimal periodicity for communicating status messages from the trusted designated node to the IoT hub, based on the parameters of the initiator node.The trusted designated node is also functional for transmitting status messages to the IoT hub with optimal periodicity, so that the trusted designated node acts as a proxy for the initiator node when reporting the status messages to the IoT hub.

[0015] Another aspect of the invention is that an IoT environment comprises an IoT hub, a vehicle, and a vehicle infrastructure device. The vehicle consists of a body, one or more wheels connected to the body, and a battery connected to the body. The battery, in turn, has a capacity level or state of charge. In this embodiment, the vehicle acts as a service-requesting device (“initiator node”) within the IoT environment. The vehicle is able to identify a potential smart device from a multitude of IoT devices in the IoT environment in response to the capacity level or state of charge. The vehicle is also operable to selectively introduce the candidate smart device into the IoT environment by assigning the candidate smart device as a trusted designated node within the IoT environment.In this implementation, the vehicle infrastructure device is able to determine an optimal periodicity for transmitting status messages from the vehicle infrastructure device to the IoT hub, based on the capacity level or state of charge. The vehicle infrastructure device can also be operated in such a way that it sends the status messages to the IoT hub with the optimal periodicity, thus acting as a proxy for the vehicle when reporting the status messages to the IoT hub.

[0016] The features summarized above, as well as other features and advantages of this invention, will be readily apparent from the following detailed description of illustrative examples and methods for carrying out the present invention in conjunction with the accompanying drawings and claims. Furthermore, this invention expressly includes combinations and subcombinations of the elements and features presented above and below. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a schematic representation of a representative networked Internet of Things (IoT) ecosystem in which, according to one embodiment, a statically assigned designated node is used. Fig. Figure 2 is a power rating diagram used for managing or controlling the IoT ecosystem of Fig. 1 can be used, where the reaction periodicity is shown on the vertical axis and the battery level of an initiator device or node is shown on the horizontal axis. Fig. Figure 3 shows a representative production line that represents a dynamically assigned designated node according to one aspect of the invention. Fig. Figure 4 is a top-level block diagram illustrating the negotiation and management of a designated node in the networked IoT ecosystems of Fig. 1 and Fig. 3 represents. Fig. Figure 5 is a model for selecting a designated node via an initiator device or an initiator node according to one aspect of the invention. Fig. 6 is an alternative model for selecting the intended node using an IoT hub. Fig. 7 is a multi-ecosystem / network model for consolidating messages in scenarios where an initiator node of an IoT network sends messages or reports via various IoT hubs. Fig. 8 is a flowchart that shows an implementation of the in Fig. The 7 depicted mesh model shows this.

[0017] The present invention can be modified or implemented in alternative forms, with representative embodiments shown in the drawings and described in detail below. DETAILED DESCRIPTION

[0018] Referring to the drawings, in which the same reference numbers refer to the same features in the different views, it is stated in Fig. Figure 1 depicts a networked Internet of Things (IoT) ecosystem 10 with one or more IoT hubs 11. The term "ecosystem" used here refers to a group of networked communication nodes that share a common root certificate, i.e., a trusted digital certificate that establishes a chain of trust for device authentication, as is known in engineering. The IoT ecosystem 10 is shown in Fig. Figure 1 represents an unlimited, statically assigned node implementation for a smart location 12, e.g., a smart house or building with a smart garage 14. The smart location 12 can include a variety of IoT devices 15-1, 15-2, and 15-3. For simplicity, the IoT devices 15-1, 15-2, and 15-3 are collectively referred to here as nodes 15 of the IoT ecosystem 10. However, the terms "device" and "node" are distinct and are therefore used interchangeably in the following discussion.

[0019] As used here, devices such as the IoT devices 15-1, 15-2, and 15-3 are pieces of equipment that contain or function as one or more communication nodes. Nodes, in turn, are individually addressable, unique resources or logical units within the IoT ecosystem 10 with functions and capabilities that a user of the IoT ecosystem 10 would clearly recognize as a functional whole. A network such as that described in Fig. As described in Figure 7, the IoT ecosystem 10 is a set of nodes 15 that interact with each other by accessing data model elements in a specific domain. The IoT ecosystem 10 within the scope of the invention may comprise more or fewer devices or nodes in other implementations; for the sake of simplicity and clarity, the following example uses the approach referred to as static. Fig. 1 is used. The IoT devices 15-1, 15-2 and 15-3 in Fig. 1 could be, for example, a smartphone, a wireless / Wi-Fi enabled thermostat, a garage door or other doors / access points, a security camera, a device, or one or more other smart devices.

[0020] As part of the overall management of the IoT ecosystem 10, periodic communication of status messages takes place between the nodes 15. This can be done via a low-power mesh network protocol called Thread and / or the open-source application layer protocol Matter. In a common implementation, Thread can, for example, be used as a wireless communication method to control various Matter devices. The IoT ecosystem 10 of Fig. 1 can therefore be viewed as a Matter network, as is known to experts.

[0021] In the representative embodiment of Fig. The IoT ecosystem comprises 10 additional nodes 15 in the form of an electric vehicle (EV) 16 and an EV charger 17, e.g., a home charging station for an electric vehicle supply equipment (EVSE). Other vehicle types can be used here, including those with an internal combustion engine (ICE) or hybrid electric vehicles. In these or other implementations, the vehicle could communicate with a vehicle ecosystem device, which is also a Matter device. The trusted designated node 15D is thus a device that can act as a "trusted node" from the security perspective of the initiator node 15I.

[0022] The EV charger 17 can therefore function as a trusted designated node 15D in embodiments where the initiator node 15I is the EV 16. In conjunction with the EV charger 17, the hybrid device type of the exemplary EV 16 flexibly occupies an energy budget range that lies somewhere between and including that of a true high-power device type during its normal operation and a true low-power device type when the EV 16's battery is depleted or discharged. Thus, the EV charger 17 (or another designated device in various embodiments) can be used statically or dynamically as a trusted designated node 15D within the networked IoT ecosystem 10 as one aspect of the solutions presented here.

[0023] Once designated as a trusted designated node 15D, for example by the EV 16 itself, the IoT hub 11, or another smart device in the IoT ecosystem 10, the EV charger 17 then acts as a notification service proxy for performing operations to report the device status and for negotiating an optimal intervention frequency with the IoT hub 11 for transmitting status messages within the IoT ecosystem 10. In this embodiment, the EV 16 would still be able to send pre-authorized messages of high priority or urgency directly to the IoT hub 11, with the described proxy function of the trusted designated node 15D otherwise handling the more routine message communication to the IoT hub 11.The EV 16 would also be able to send messages less frequently, depending on its performance, if the EV 16 does not assign the trusted designated node 15D.

[0024] The EV 16 from Fig. 1 in a representative electrified vehicle configuration, in which the IoT environment 10 is a vehicle IoT environment, comprises a vehicle body 18 and one or more wheels 20. The electric vehicle 16 is also equipped with a high-voltage traction battery (B HV ) 22 and one or more electric drive motors 24. In alternative embodiments of electric vehicles with internal combustion engines or hybrid electric vehicles, other battery types 22 can also be used for other purposes, e.g. as standby batteries for engine start / stop operations, lead-acid or lithium starter batteries, smaller traction batteries for limited distances, etc. While other components in Fig. For the sake of simplicity, the EV 16 may also include power electronics devices, such as an inverter module that converts a direct current (DC) waveform from the traction battery 22 when it excites phase windings of alternating current (AC) versions of the electric drive motor(s) 24, a DC-DC converter for controlling the DC waveform to or from the traction battery 22, thermal management systems for maintaining a temperature of the traction battery 22 and the electric drive motor(s) 24, etc.

[0025] When a driver of the electric vehicle 16 returns to the smart garage 14 in a representative usage scenario, an onboard charging controller or other smart device 25 of the EV 16 can communicate with the charger 17 via the transmission of message data 30 (dashed line) over a first connection (D1). Similar message data 30 can be exchanged between the EV charger 17 and the IoT hub 11. In the exemplary implementation of Fig. 1 represents the display of message data 30 as a dashed line, therefore a periodic communication of information / messages with lower priority / standards to the IoT hub 11 on behalf of the EV 16.

[0026] Also in Fig. Figure 1 shows internal data 32 (solid line) representing the communication of internal data from the trusted designated node 15D, where the static (unchanging) trusted designated node 15D in this exemplary use case is the EV charger 17 and its associated processor / control circuit (not shown, but known in the prior art). The EV charger 17 then communicates, as needed, with one or more of the IoT devices 15-1, 15-2, and / or 15-3 within the smart home 12, with a representative connection (D2) between the IoT devices 15-1 and 15-2 also shown in Figure 1. Fig. Figure 1 is shown. Similar to the described connection (D1) between EV 16 and EV charger 17, connection D2 indicates that one of the IoT devices 15-1 or 15-2 can act as the initiator node of a hybrid device, similar to EV 16, with the other device 15-1 being used as the designated node (or vice versa). In this embodiment, EV 16 retains the ability to communicate directly with the IoT hub via internal data 32, for example, if the information concerns a fault or other high-priority or urgent message. As mentioned above, the device types and the use / configuration of the IoT ecosystem 10 can vary depending on the intended application, and therefore the configuration shown in Figure 10 is not always applicable. Fig. One example shown illustrates the present teaching.

[0027] Other hardware (not shown in the drawings) connected to the various nodes 15 may take the form of one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), electronic circuits, central processing units such as microprocessors or processors, and associated computer-readable storage media / memory. Non-transitory components of such memory, such as the computer-readable storage medium, are capable of storing machine-readable instructions in the form of one or more software or firmware programs or routines, combinational logic circuits, input / output circuits and devices, signal conditioning and buffer circuits, and other components that one or more processors can access to provide a described functionality.With this hardware and the associated antennas, receivers and transmitters located at the various nodes, information can be exchanged wirelessly between the nodes.

[0028] Selection based on the hybrid device type: Referring to diagram 35 in Fig. 2 in conjunction with the networked IoT ecosystem 10 in Fig. 1 As part of the present strategy, a hybrid device type such as the electric vehicle 16 selects a trusted designated node 15D. The power state or charge state is determined for an initiating or service-requesting node (initiator node 15I). Fig. 5 and Fig. 6) within the networked IoT ecosystem 10, e.g., the EV 16, is evaluated. The initiator node is a hybrid device type within the scope of the present invention and can therefore function as either a high-power or low-power device type as needed, the actual mode being based on one or more parameters of the initiator node 15I and thus on current conditions or situations. In the present IoT context, the relative terms "high power consumption" and "low power consumption" differ from each other by their relative energy consumption as well as by their computing capacities and communication characteristics. The structure of the devices from which the nodes 15 in Fig. The number of participants may vary depending on the application.

[0029] Examples of low-power devices include small battery-operated actuators or sensors, RFID (Radio Frequency Identification) tracking devices, wearable monitoring devices, and other smart devices. Such devices typically have relatively low data transmission rates and can also use suitable communication protocols such as Bluetooth Low Energy (BLE) or Zigbee. In contrast, high-power devices in the IoT context considered here can consume significantly more energy and involve complex data processing / transmission. The IoT Hub 11 in Fig. For example, device 1 can operate as a high-power device, as can the EV charger 17, an onboard controller of the EV 16, etc. High-performance IoT devices can also use various communication protocols, typically, but not exclusively, Wi-Fi or Ethernet. The term "hybrid," as used here, therefore refers to the capability of the trusted designated node 15D of Fig. 1. To occupy an energy budget zone somewhere between the characteristics of high-power and low-power device types. The hybrid device type is therefore able to operate as either a high-power or a low-power device, depending on the situation.

[0030] In the representative usage scenario of Fig. In Figure 1, the EV 16 (a high-power device) is parked in the smart garage 14 in close proximity to the charger 17, with the ignition off. In this mode, the traction battery 22 or other connected batteries / energy storage systems may tend to draw more power than permitted, as described above. Against the backdrop of this representative scenario, Diagram 35 illustrates Fig. 2. The periodicity of the message response is shown on the vertical axis. The battery level, in this case the state of charge or the remaining capacity of the traction battery 22, is displayed on the horizontal axis.

[0031] According to the invention, a smart device is selected and introduced into the IoT ecosystem 10 to subsequently act as a trusted designated node 15D, which is selected, for example, by the EV 16 or the IoT hub 11. The smart device can be a hybrid device or a low-power device and can be or include the EV charger 17. The smart device, now acting as the trusted designated node 15D, then negotiates an optimal power-on frequency with the IoT hub 11 when status messages 30 are sent on behalf of the EV 16. The trusted designated node 15D thus acts as a representative or proxy for the EV 16 to report the device status and for carrying out other interactions with the various nodes 15 of the IoT hub 11.

[0032] In Fig. Figure 2 shows three different energy budget zones or power modes. The three example modes are low power consumption (Mode I), hybrid power (Mode II), and high power consumption (Mode III). Line LL represents the inverse relationship between the periodicity of the response on the one hand and the state of charge of the battery on the other. The battery level, which serves as a reference parameter in this example, can represent the remaining capacity of a battery, e.g., the traction battery 22. Fig. 1, represent the device that supplies power to the initiator node / device, e.g. the EV 16.

[0033] When the EV 16's battery level is high, the EV 16 can continue to report its own message traffic to the IoT hub 11 at a predetermined or self-negotiated frequency / periodicity. This is the EV 16's default / normal operating mode, which would be the only default operating mode without the benefits of the present solutions. Within the scope of the invention, as the battery level decreases, the EV 16 transitions from high power consumption (Mode III) to low power consumption (Mode I). As the EV 16 (or another initiator node) moves towards Mode I, it first switches to Mode II, i.e., hybrid mode. In this case, the EV 16 (or the IoT hub 11) selectively assigns a smart device / smart node as the trusted designated node 15D, thereby transferring the reporting task from the initiator node to the trusted designated node 15D.Low power consumption (Mode I) can be used by the designated node 15D to transmit messages within the IoT network 10 when the battery level of the initiator node 15I is relatively low or nearly depleted. In one or more embodiments, therefore, determining the optimal periodicity of status message communication by the trusted designated node 15D on behalf of the EV 16 (or another initiator node 15I) to the IoT hub 11 may involve accessing a lookup table that is indexed or referenced by the optimal periodicity and a parameter of the initiator node 15I, which in this case includes the battery level / state of charge of the traction battery 22.

[0034] Message periodicity: In general, each node in a typical Matter ecosystem must communicate regularly with an IoT hub to maintain its status within the Matter network. Messages within the exemplary networked IoT environment 10 of Fig. Messages transmitted can be of different types and convey specific information. Examples of message types include Address Resolution Protocol (ARP), Neighbor Discovery Protocol (NDP), Dynamic Host Configuration Protocol (DHCP), Internet Control Message Protocol (ICMP), Message Queuing Telemetry Transport (MQTT), etc. The frequency of message transmission depends on the device type, i.e., its power consumption.

[0035] Furthermore, the periodicity is typically set to a maximum time limit for the Layer 2, Layer 3, and Layer 4 IoT stacks. Layer 2 (i.e., the L2 / data link layer) is generally responsible for data transmission from node to node within the network, which in a Matter network is typically IEEE 802.15.4 (Thread / ZigBee) or Wi-Fi. L2 messages can include error handling, physical addressing of the various devices, MAC (Media Access Control) addressing, and so on. Layer 3 (i.e., the L3 / network layer) is responsible for routing and logical addressing across network segments, forwarding message packets, and implementing Thread, Wi-Fi, and other network link protocols. Layer 4 (i.e., the L4 / transport layer) is responsible, among other things, for establishing connections and managing end-to-end communication between connected devices.Layers L2, L3 and L4 together enable a standardized IoT communication framework that facilitates the effective use of devices from the same or different manufacturers.

[0036] A potential problem in managing device-type-dependent message periodicity using existing standards can arise when attempting to manage communication with / from high-power device types, such as the representative EV 16 in Fig. 1, or with other devices / nodes that are in a depleted energy state. Existing Matter-based and other approaches to managing node interaction between node 15 and the IoT hub 11 of Fig. 1. cannot efficiently handle the increased reporting rate for such devices. Therefore, the present solutions selectively reconnect to the IoT hub 11 by using a trusted designated node 15D, based on power constraints or other parameters of the service-requesting node / device, as described in Fig. 2 shown, possibly using the dynamic selection of the trusted designated node 15D ( Fig. 3) if it acts as a proxy for message communication.

[0037] Dynamic allocation: Regarding the networked IoT infrastructure 10A in Fig. 3. A device / node can be dynamically assigned instead of being statically assigned as in the example in Fig. 1. Dynamic assignment can be used in an exemplary manufacturing plant where automation robots 38 are arranged relative to a production line 40. Various IoT devices 15-4, 15-5, 15-6, 15-7, 15-8, and 15-9 are in Fig. Figure 3 illustrates this. In this example, production or manufacturing is sequential, meaning that one of the robots 38 is located in a first time window T1 before or after another robot 38 in a second / later time window T2.

[0038] The IoT device 15-4 in the exemplary implementation of Fig. Device 4 can be designed as an intelligent light-thread device, while IoT devices 15-5, 15-6, and 15-7 can be manufacturing control units / controllers. While one device 15-7 is shown, the networked IoT infrastructure 10A can contain a large number of additional such devices 15-7, i.e., an integer n. Thus, "manufacturing unit n" represents one or more additional controllers along the manufacturing line 40. Device 15-8 can contain an RFID tag reader for tracking objects. Device 15-9 is depicted as a smartphone. Various other devices can be used in a manufacturing plant, which is why the examples in Fig. 3. To illustrate the present teaching. Since the trusted designated node 15D is dynamically assigned, its identity can change during operation.

[0039] As in the static example of Fig. In time window 1, where the identity of the trusted designated node 15D is established, the various devices / nodes can exchange message data 30 (dashed line). For example, an automation robot 38 can communicate with the manufacturing controller (first device type D1) in the first time window T1, while a downstream automation robot 38 communicates with the manufacturing controller (device type D2) in the second time window T2. The dashed line of message data 30 represents the regular transmission of information / messages to the IoT hub 11 on behalf of, for example, the automation robots 38. Internal data 32 (solid line), as mentioned above, represents the transmission of internal data from a designated node, for example, one of the automation robots 38, which in this case changes dynamically as described below.

[0040] Referring to flowchart 42 in Fig. 4 and continuing the discussion on the dynamic designation of a hybrid device type, designated nodes can be dynamically assigned in accordance with one of two different models: (i) a device-based model 50, as in Fig. 5 shown, or (ii) a hub-supported model 50A, as shown in Fig. 6 shown. Fig. Figure 4 shows two different types of IoT Hubs 11: IoT Hub 11A and IoT Hub 11B. For example, IoT Hubs 11A and 11B can each be configured as a smart switch and as a voice assistant platform, e.g., Amazon Alexa, Siri, or Google Assistant. In another embodiment, IoT Hub 11B can also include the EV 16. Fig. 1. A Matter controller 150, one of the IoT nodes 15, is in Fig. 4 also shown schematically, e.g. a smartphone, infotainment system, etc. If the IoT environment 10A is part of a manufacturing plant, as in Fig. As shown in Figure 3, the dynamic assignment of the hybrid candidate device type as trusted designated node 15D can include the dynamic assignment of an automation robot 38 or a manufacturing controller, e.g., 15-5, 15-6, or 15-7, as trusted designated node 15D. This can occur during the ongoing operation of a production line in the manufacturing plant, with the identity of the trusted designated node 15D potentially changing during operation.

[0041] Fig. Figure 4 generally represents a sequence of events that can be performed according to the invention. The sequence begins with the selection of a trusted designated node 15D within the networked IoT infrastructure 10 or 10A described above, or variations thereof. The INIT arrows denote initiation signals. The ACK arrows denote acknowledgment signals from the IoT hub 11A and the trusted designated node 15D. The trusted designated node 15D is dynamically located and initially selected from among the nodes 15 by exchanging the INIT and ACK signals.

[0042] As part of this process, the Matter Controller 150 performs a series of functions F1-F6. These include identifying candidates for designated nodes among the discovered neighboring nodes (F2), authorizing the use of the designated nodes (F3), evaluating the communication and performance capabilities of the designated nodes (F4) with regard to their suitability for the given situation, e.g., in terms of energy requirements, and selecting a designated node (F5) for use as a proxy. Access control functions (F6) can be performed with the trusted designated node 15D via corresponding functions (F6A) of the trusted designated node 15D. These functions F6 can include transferring control to the trusted node 15D.Other functions are performed by the designated node 15D, including the provision of services (F7) and the management of the running service (F8).

[0043] Referring to the device-supported designated node model 50 of Fig. 5 can be found in the representative case of Fig. 1, in which the EV 16 is connected to the EV charger 17 and two IoT hubs, e.g. 11A and 11B from Fig. 5, used, the permissions are dynamically reclassified by one of the IoT hubs 11 when these dynamically monitor the nodes for compliance and other configuration information. Once activated, permissions can be managed by the nodes 15 upon receipt of new requirements or requests. As long as it is not overridden by the Matter Controller 150 of Fig. If a trusted designated node 15D is reclassified, it cannot nominate other nodes 15 to act as another trusted designated node 15D. Therefore, aspects of the invention may involve a selective reclassification of the trusted designated node 15D to enable it to do so.

[0044] Statically designated node: In an exemplary smart home implementation such as the use case of Fig. 1. If the location of a particular IoT device is easily available, e.g., the EV charger 17 of Fig. Since device 1, located at a fixed position in the smart garage 14, can subsequently be used as a trusted designated node 15D. The EV charger 17 / the other trusted designated node 15D, once assigned by the EV 16 or the IoT hub 11 in this implementation, acts as a messaging proxy for the EV 16 for direct messaging activities with the IoT hub 11. The status message can be consolidated with the status message of the trusted designated node 15D, i.e., its own status message to the IoT hub 11. In some cases, as mentioned above, the EV 16 can also flag critical messages and send them directly to the IoT hub 11.

[0045] The designation of the trusted designated node 15D in the static designation case can occur in one or more embodiments during an IoT device commissioning process. As is well known in the industry, an IoT device commissioning process ensures network security by preventing spoofing and preventing unauthorized or malicious devices from joining the IoT network. During device commissioning, devices are configured for use in the IoT network, provided with operating parameters to ensure device and communication consistency, and network resources are managed. Commissioning a new device may involve the device broadcasting its presence while searching for available networks, for example, using Bluetooth, BLE, Wi-Fi, Zigbee, or another suitable protocol.The device can then exchange security keys with other nodes in the network, receiving a unique device identifier, and verify its connectivity with the other nodes. After commissioning, the new device is free to act as one of the various nodes within the IoT ecosystem 10, 10A 15.

[0046] Dynamically designated node: In the exemplary industrial embodiment of Fig. 3. The dynamic designation can occur as a response to a manufacturing controller unit 1, i.e., device 15-5 (device type D1), requesting support from an automation robot 38. The robot 38, which itself can be a hybrid device type as described above, can be assigned multiple tasks in the plant, e.g., asset management functions, quality control, fault analysis, repair, maintenance, etc. In the first time window T1 of Fig. 3. The automation robot 38 can assign device 15-5 as a trusted designated node 15D. Afterwards, the robot 38 can dynamically update the IoT hub 11 as soon as the second time window T2 begins.

[0047] In the model 50 of Fig. 5 can be, for example, the service-requesting initiator node (15I), like the EV 16 of Fig. 1, communicate with a designated node 15D, e.g., the EV charger 17 in this representative embodiment. Model 50 describes a “device-based” approach in that the initiator node 15I, which functions as a hybrid device type, determines / selects the designated node 15D from the neighboring / within-range nodes 15. In Fig. Figure 5 shows various communication options between the initiator node 15I, the trusted designated node 15D, and the IoT hubs 11A and 11B. These include (in Fig. (5 from top to bottom) node discovery 51, followed by querying information about the designated node 52. The initiator node 15I also initiates service authorization 53 with the IoT hub 11A. The trusted designated node 15D can transmit its device type to the IoT hub 11B, i.e., as message 54. The IoT hub 11A can send a message 55 to the initiator node 15I, containing similar device type information to message 54.

[0048] The Model 50 from Fig. Figure 5 also shows an authorization control logic 57 for management control, i.e., enabling the trusted designated node 15D to function as a proxy, as requested. The connection and provisioning status 58 can be transmitted to the IoT hub 11A. Additional messages may include a message 59 regarding the rejection of the trusted designated node 15D for its designated proxy function and deauthorization. The decision feedback 60 is then transmitted from the trusted designated node 15D to the initiator node 15I. A service activation message 61 can be transmitted from the trusted designated node 15D to the IoT hub 11A, i.e., upon activation of the trusted designated node 15D.

[0049] The alternative hub-supported model 50A from Fig. 6 can be used in cases where a requesting device or an initiator node 15I is unable to determine the trusted designated node 15D. For example, the exemplary EV 16 from Fig. EV 16 acts as a receiver of a service and communicates with IoT Hub 11. EV 16 can send a service request 63 to IoT Hub 11. IoT Hub 11 can then send a resource availability request 64A to two possible candidate nodes, namely the designated nodes 15D-1 and 15D-2. The candidates then respond with a message 67Y (yes) or 67N (no), indicating whether they can provide the requested service. IoT Hub 11 then processes these responses using its permission control logic 69 (analogous to logic 57 in [reference missing]). Fig. 5).

[0050] Once IoT Hub 11 has decided which candidate node to accept, in this case the trusted designated node 15D-1, after transmitting message 67Y, IoT Hub 11 sends message 70 to EV 16 to initiate the acceptance of the service from the trusted designated node 15D-1. EV 16, i.e., its onboard controller, responds with an acceptance message 71 to the ready trusted designated node 15D-1. The trusted designated node 15D-1 then sends message 72 to EV 16 indicating that the trusted designated node 15D-1 is provisioned and connected. EV 16 and the trusted designated node 15D-1 then exchange message 73 indicating that the service is active and running.

[0051] In some cases, according to Fig. 7 a device in the networked IoT ecosystem 10 or 10A containing several IoT hubs 11, e.g., hubs H1, H2, and H3. In the representative embodiment of Fig. 1. Hubs H1, H2, and H3 can be implemented as several different control modules of the EV 16. A device with such connectivity options may require intelligent and consolidated optimization functions for assigning a trusted designated node 15D and for determining an energy-appropriate reporting cadence or periodicity. Different nodes 15 can serve as initiator nodes 15I. A device acting as node N1 can communicate with hubs H1 and H3, while a device acting as node N2 can communicate with hub H2. Similarly, a device acting as node N3 can communicate with hub H3. Thus, in this example, node N1 has two possible communication options: hub H1 or hub H3.

[0052] In a situation where a device uses multiple hubs, sending regular reports consumes significant computing power, requires coordination of sleep / wake cycles, and similar tasks. To reduce power consumption, one aspect of the present strategy consolidates reports and determines an optimal time for sending the reports / messages to one of the IoT hubs. Representative conditions are presented in a condition table, such as energy budget, (energy) costs, communication coverage, latency, node proximity, and node priority (e.g., transit, designated, critical, etc.). Based on these conditions, a population of candidate nodes is identified, from which a parent node is selected.In some embodiments, the various conditions can be normalized and weighted so that the condition table 75 as a whole outputs a binary decision (0 or 1) as to whether the trusted designated node 15D should be assigned or whether the initiator node 15I should continue to be used to transmit its status messages to the IoT hub 11.

[0053] In Block 76, for example, the nodes 15 are evaluated against the conditions in Table 75 to identify trusted designated nodes 15D, which are represented as 15D-1 and 15D-2 for simplicity. The nodes 15N are not considered because they do not have the required capabilities given the conditions. The node 15 *A possible designated node could be , but due to the conditions and relative capabilities, designated nodes 15D-1 and 15D-2 are considered the better choice. Of the two remaining designated nodes, 15D-1 and 15D-2, node 15D-2 may currently be occupied, i.e., performing functions that preclude its use as a trusted designated node 15D. This would leave node 15D-1 available and capable of serving as the trusted designated node 15D. In this example, node 15D-1 is then assigned as the trusted designated node 15D, followed by a message (Block 78). This occurs at the previously defined, energy-budget-based cadence, as described above. Fig. 2 was explained.

[0054] To illustrate one aspect of the present teaching, in Fig. 8 describes an embodiment of a method 100. In general, the method 100 is designed to manage intranodal interactions in a networked IoT environment, where such a networked environment is here referred to as the IoT environments 10 and 10A of the respective Fig. 1 and Fig. Method 100 is implemented in IoT environment 10, 10A. Method 100 may involve using a service-requesting initiator node 15I, potentially with high power consumption, from IoT environment 10, 10A, or IoT hub 11 to identify a suitable smart device among a multitude of neighboring nodes 15. Depending on the requirements of the initiator node 15I, the candidate smart device may have high power consumption, low power consumption, or be a hybrid device (flexibly operating as either a high- or low-power device). Method 100 includes the selective assignment of the candidate device as a trusted designated node 15D within IoT environment 10, 10A based on the battery level or other parameters of the initiator node 15I.Method 100 also includes determining, based on a parameter of the initiator node 15I, an optimal periodicity for the communication of status messages from the initiator node 15I to an IoT hub 11 of the IoT environment 10, 10A. Method 100 involves using the trusted designated node 15D to transmit the status messages to the IoT hub 11 with the optimal periodicity. This action is performed via the designated node 15D, so that the trusted designated node 15D negotiates the periodicity and acts as a proxy for the initiator node 15I when reporting the status messages to the IoT hub 11.

[0055] A representative embodiment of the in Fig. Procedure 100, as shown in Figure 8, begins with logic block B102. Here, procedure 100 involves the initialization or request of a service via an initiator node 15I, e.g., EV 16 from Fig. 1. For example, the EV 16 can park in the smart garage 14 and switch to the "ignition off" state near the charger 17. In the manufacturing example of Fig. 3. An automation robot 38 or another device can take over the role of the initiator node 15I. The procedure 100 then proceeds to block B104.

[0056] In block B104, the neighboring nodes 15 are scanned for candidates, i.e., for one or more nodes 15 that could potentially serve as the trusted designated node 15D described above. Using EV 16 as an example, EV 16 can search for neighboring devices / nodes in its vicinity that could potentially serve as the trusted designated node 15D. Procedure 100 then proceeds to block B106.

[0057] In block B106, procedure 100 includes determining whether the initiator node 15I is a multi-node device. According to the present vehicle example, the EV 16 would be such a device, since the EV 16 typically contains several different control modules, as mentioned above. These characteristics are typical of a hybrid device type. Procedure 100 continues with block B108 if the initiator node 15I is a multi-node device, and alternatively with block B110 if the initiator node 15I is a single-node device.

[0058] Block B108 is reached from block B106 after it has been determined that the initiator node 15I is a multi-node device, such as the EV 16. Block B108 involves locating neighbors within the node (intranodal neighbors). As is well known in the field, a neighbor within a node in the networked IoT infrastructure 10 is a neighboring device / node that is connected to or belongs to the same local network segment as the scanning device. For example, neighbors within a node might share a router or network connection. The procedure 100 proceeds to block B112 after neighbors within a node have been located.

[0059] In block B110, procedure 100 follows. Fig. 8 a one-node river, such as the one described above with reference to Fig. 1 was described. The procedure 100 is then completed, with the single trusted designated node 15D subsequently acting as a proxy for message transmission by the initiator node 15D.

[0060] Block B112 checks whether there are any neighbors within a node in block B108. Procedure 100 continues to block B114 if a neighbor within a node is found. Alternatively, procedure 100 continues to block B110 if no neighbor within a node is found.

[0061] Block B114 comprises the consolidation of a message packet, as above with reference to Fig. 7 described. Procedure 100 then proceeds to block B116.

[0062] In block B116, the consolidated message is sent to IoT hub 11, e.g., IoT hub H1 or H3. Fig. 7, sent. This completes procedure 100.

[0063] As outlined above, the solutions presented here relate to methods and node systems for introducing a smart device as a designated node 15D into a networked IoT ecosystem such as the IoT ecosystem 10 and 10A of Fig. 1 or 3. The designated node 15D would then be selected based on a parameter, such as the energy budget of an initiator device (e.g., the EV 16 in Fig. 1) selectively negotiate an optimal activation period for message exchange with an IoT hub 11. The message from the trusted designated node 15D can be based on the parameters or the current situation of the requesting device, e.g., the battery level of the traction battery 22 or another battery of the vehicle 16.

[0064] The trusted designated node 15D can be classified as such and, in some cases, selected by the EV 16 or another initiator node / device. In other approaches, the IoT Hub 11 can assist in selecting the trusted designated node 15D. Reporting then occurs at a cadence or periodicity appropriate to the energy budget. This ensures that a high-power device, such as the EV 16, is not automatically included in the data. Fig. 1, as part of the IoT ecosystem 10, e.g., a Matter ecosystem, can be used even when it is in a state with low energy reserves. This is ensured by using the trusted designated node 15D (e.g., the EV charger 17) as a proxy for reporting the device status to the IoT hub 11. This, in turn, would help to reduce the power consumption of the battery 22. Fig.1 to minimize in such an embodiment. These and other related advantages are readily apparent to those skilled in the art in view of the foregoing.

Claims

[1] Method for managing communication between Internet of Things (IoT) nodes in a networked IoT environment with the IoT nodes and an IoT hub, wherein the method comprises: Identifying an intelligent candidate device among the IoT nodes in response to a parameter from a service-requesting initiator node; Selective introduction of the intelligent candidate device into the IoT environment, including assigning the intelligent candidate device as a trusted designated node within the IoT environment using the initiator node or the IoT hub; Determine, based on the parameter of the initiator node, an optimal periodicity for the communication of status messages from the trusted designated node to the IoT hub; and Transmitting status messages to the IoT hub with optimal periodicity via the trusted designated node, so that the trusted designated node acts as a proxy for the initiator node when it reports the status messages to the IoT hub. [2] Method according to claim 1, wherein the initiator node contains a battery, and wherein the parameter comprises a capacity level or state of charge of the battery. [3] Method according to claim 2, wherein the initiator node is part of a vehicle with the battery, and wherein the determination of the optimal periodicity of the communication of the status messages is based on the capacity level or the state of charge of the battery. [4] Method according to claim 3, wherein the selective introduction of the intelligent candidate device into the IoT environment comprises the selective introduction of an electric vehicle charger into the IoT environment as the trusted designated node, and wherein the electric vehicle charger contains the intelligent candidate device. [5] Method according to claim 1, wherein determining the optimal periodicity of the communication of status messages from the trusted designated node to the IoT hub comprises accessing a lookup table that is indexed or referenced by the optimal periodicity and the parameter. [6] Method according to claim 1, wherein the selective introduction of the intelligent candidate device into the IoT environment comprises the dynamic assignment of the intelligent candidate device type as a trusted designated node during the operation of the IoT environment. [7] Method according to claim 6, wherein the IoT environment is part of a manufacturing plant, and wherein the dynamic assignment of the intelligent candidate device as the trusted designated node comprises the dynamic assignment of an automation robot or a controller of the manufacturing plant as the trusted designated node during the operation of the manufacturing plant. [8] Method according to claim 6, wherein the dynamic assignment of the intelligent candidate device as the trusted designated node is performed by the initiator node according to a device-based model, further comprising: Selecting the trusted designated node via the initiator node from neighboring / within-range IoT nodes using the device-based model. [9] Method according to claim 6, wherein the dynamic assignment of the intelligent candidate device as a trusted designated node is performed by the IoT hub according to a hub-supported model. [10] Method according to claim 1, further comprising: Consolidate a status message from the initiator node with a status message from the trusted designated node to create a consolidated report; and Regular transmission of the consolidated report to the IoT hub via the trusted node to reduce the power consumption of the IoT environment.

Images