Method for managing interaction between intelligent internet of things center and node

Abstract

A method for managing communications between Internet of Things (IoT) nodes in an IoT environment having an IoT center includes using a service request high power initiator node to identify candidate smart devices in the nodes. Based on the parameters of the initiator node, the smart device can flexibly operate as a low-power or high-power device, a hybrid device. The method may include selectively assigning the smart device as a trusted designated node within the IoT environment. The method also includes determining an optimal period of status messaging from the trusted designated node to the IoT hub based on the parameter. Thereafter, the method includes transmitting, via the trusted designated node, the status message to the center at the optimal cycle, such that the trusted designated node acts as a proxy for the initiator node when reporting the status message to the center.

Description

[0001] introduce

[0002] Advances in global automation technologies have led to the adoption of Internet of Things (IoT)-based solutions and the associated management of a vast array of connected device types used to enable IoT environments. Devices and their communication nodes within a networked IoT environment collect and exchange messages to automate and optimize processes performed by the devices. For example, a “smart garage” IoT network can be used to schedule and manage residential charging operations for battery electric vehicles or plug-in hybrid electric vehicles. Such a network can leverage smartphone-based monitoring and the opening / closing of garage doors or other access points, control of climate settings (such as temperature, humidity, and air quality), and monitoring / control of other networked systems. IoT networks can be used in other operating environments, including but not limited to users’ homes or offices. Modern industrial and manufacturing environments can also utilize a networked IoT ecosystem to facilitate order scheduling, track assembly progress, or otherwise facilitate communication between different connected devices.

[0003] Communication between nodes in a networked IoT environment relies on proximity ranging and the reliable exchange of other information via coordinated exchanges of electronic signals or messages. Networked devices / nodes may rely on one or more connectivity technologies (such as Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), cellular, Zigbee, or others) to transmit such ranging data and information. The coordinated operation of potentially different technologies across a networked IoT environment is currently facilitated by the open-source Matter standard, and therefore, networked IoT ecosystems are often referred to as Matter networks. Regardless of the constructs or subnetworks used in a networked IoT ecosystem, the constituent nodes of the ecosystem are required to periodically communicate with an IoT hub to maintain the state within the ecosystem and to control the ecosystem. Summary of the Invention

[0004] This disclosure relates to methods and systems for managing and controlling a networked Internet of Things (IoT) ecosystem having one or more IoT hubs and multiple networked smart devices. Each smart device includes / acts as one or more communication nodes within the IoT ecosystem. As used herein, an IoT hub is a centralized hardware and software device that connects and manages ongoing data / message exchanges between connected IoT devices. In various implementations, the IoT hub may be local or global / cloud-based, thus acting as a centralized communication node during message exchange between connected devices. Several examples of such messages include activation or deactivation commands, telemetry data, performance metrics, software / firmware updates, error conditions, status, security credentials, timestamps, health reports, and other relevant information or data.

[0005] According to aspects of this disclosure, in various embodiments, a trusted designated node is dynamically or statically assigned by a service requesting device (“initiator node”) or an IoT hub. The assignment occurs based on parameters of the initiator node, such as its current power level or state of charge. This designated node is then used as a “trusted node” as part of the IoT ecosystem, particularly for the purpose of providing status messages to the IoT hub on behalf of the initiator node. As disclosed herein, the term “hybrid device” refers to a high-power smart device, such as an electric vehicle (EV) or a controller with multiple processors / other computing nodes. Sometimes, high-power devices may experience depleted batteries or reduced energy budgets and thus begin to behave more like low-power devices. Therefore, when the initiator node / smart device is an EV, the designated node negotiates an optimal engagement period with the IoT hub using parameters such as, for example, the reduced capacity level or state of charge of the propulsion battery of an electric vehicle (EV).

[0006] In the non-limiting scenario of the example EV and its inherent propulsion battery, periodic messaging between the EV and the IoT hub during the EV's ignition-off mode could rapidly discharge and further deplete the propulsion battery or another onboard energy storage system used for this purpose. To address this issue, the method described herein involves selectively introducing a trusted designated node into the IoT environment as a trusted node and messaging broker. In various embodiments, the task of selecting the trusted designated node is performed as needed by the service request initiator node / device or by the IoT hub. Subsequently, the introduced trusted designated node acts as a broker for status reporting and other message exchanges with the IoT hub, negotiating the optimal period for such reporting.

[0007] A method for managing communication between IoT nodes in a networked IoT environment with an IoT hub, according to an embodiment, includes determining parameters (e.g., capacity level, state of charge, energy budget, etc.) of a high-power initiator node (e.g., an EV) of a service request from the IoT network. The method includes identifying, based on these parameters, whether the initiator node is operating in a mixed-power mode. When the initiator node operates in a mixed-power mode, as used herein, the mixed-power mode occupies a space between high-power and low-power modes. The method includes identifying candidate smart devices / nodes among multiple neighboring nodes in the IoT network. The method includes selectively assigning candidate smart devices as trusted designated nodes within the IoT network. The method also includes determining an optimal period for status message delivery from the trusted designated node to the IoT hub based on the parameters of the initiator node. Thereafter, the method includes transmitting status messages to the IoT hub via the trusted designated node at the optimal period, such that the trusted designated node acts as an agent of the initiator node when reporting status messages to the IoT hub.

[0008] The initiator node may include a battery, in which case parameters include the battery's capacity level or state of charge. In one or more embodiments, the initiator node is a part of a vehicle having a battery. In such embodiments, determining the optimal period for status message passing is based on the battery's capacity level or state of charge.

[0009] Selectively introducing candidate smart devices into an IoT environment can include selectively introducing electric vehicle chargers as trusted designated nodes, wherein the electric vehicle chargers include candidate smart devices. The selective introduction of candidate smart devices into the IoT environment can occur during the deployment of the candidate smart devices.

[0010] The optimal cycle for state message passing from a trusted designated node to the IoT hub may include accessing a lookup table indexed or referenced by the optimal cycle and the parameters.

[0011] Selectively introducing candidate smart devices into an IoT environment may optionally include dynamically assigning candidate smart device types as trusted designated nodes during the operation of the IoT environment. For example, the IoT environment may be part of a manufacturing plant, such that dynamically assigning candidate smart devices as trusted designated nodes includes dynamically assigning automated robots or controllers of the manufacturing plant as trusted designated nodes during the operation of the manufacturing plant. Dynamically assigning candidate smart devices as trusted designated nodes can also be performed by the initiating node according to a device acquisition model, such as selecting trusted designated nodes from nearby / distance nodes of the IoT node via the initiating node using a device acquisition model. Alternatively, dynamically assigning candidate smart devices as trusted designated nodes can be performed by the IoT hub according to a hub-assisted model.

[0012] Implementations of this method may include merging the status messages of the initiator node with the status messages of the trusted designated node to form a merge report, and periodically sending the merge report to the IoT center via the trusted designated node, thereby reducing power consumption in the IoT environment.

[0013] According to aspects of this disclosure, a networked IoT environment includes an IoT hub and a plurality of IoT devices. The devices include service requesting devices (“initiator nodes”). The IoT hub and / or the initiator nodes are operable to identify candidate smart devices from the plurality of IoT devices in response to parameters of the initiator nodes, and selectively introduce candidate smart devices into the IoT environment. This subsequent step may include assigning candidate smart devices as trusted designated nodes within the IoT environment via the initiator nodes and / or the IoT hub. In this particular embodiment, the trusted designated node is operable to determine an optimal period for status message delivery from the trusted designated node to the IoT hub based on parameters of the initiator nodes. The trusted designated node is also operable to transmit status messages to the IoT hub at the optimal period, such that the trusted designated node acts as an agent of the initiator node when reporting status messages to the IoT hub.

[0014] In another aspect of this disclosure, the IoT environment includes an IoT hub, a vehicle, and vehicle infrastructure equipment. The vehicle includes a body, one or more wheels connected to the body, and a battery connected to the body. The battery itself includes 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 operable to identify candidate smart devices from a plurality of IoT devices in the IoT environment in response to a capacity level or state of charge. The vehicle is also operable to selectively introduce candidate smart devices into the IoT environment by assigning them as trusted designated nodes within the IoT environment. In this embodiment, the vehicle infrastructure equipment is operable to determine an optimal period for status message transmission from the vehicle infrastructure equipment to the IoT hub based on a capacity level or state of charge. The vehicle infrastructure equipment is also operable to transmit status messages to the IoT hub at this optimal period, such that the vehicle infrastructure equipment acts as an agent of the vehicle when reporting status messages to the IoT hub.

[0015] This disclosure provides the following examples:

[0016] Example 1. A method for managing communication between IoT nodes in a networked IoT environment having Internet of Things (IoT) nodes and an IoT hub, the method comprising:

[0017] In response to parameters from the service request initiator node, candidate smart devices are identified from the IoT nodes;

[0018] Selectively introducing the candidate smart devices into the IoT environment includes using the initiator node or the IoT hub to assign the candidate smart devices as trusted designated nodes within the IoT environment;

[0019] Based on the parameters of the initiator node, determine the optimal period for transmitting status messages from the trusted designated node to the IoT center; and

[0020] The status message is transmitted to the IoT center via the trusted designated node at the optimal period, so that the trusted designated node acts as a proxy for the initiator node when reporting the status message to the IoT center.

[0021] Example 2. According to the method of Example 1, wherein the initiator node includes a battery, and wherein the parameters include the battery's capacity level or state of charge.

[0022] Example 3. The method according to Example 2, wherein the initiator node is a part of the vehicle having the battery, and wherein the optimal period for determining the delivery of the status message is based on the battery's capacity level or state of charge.

[0023] Example 4. The method according to Example 3, wherein selectively introducing the candidate smart device into the IoT environment includes selectively introducing an electric vehicle charger into the IoT environment as the trusted designated node, and wherein the electric vehicle charger includes the candidate smart device.

[0024] Example 5. The method according to Example 1, wherein selectively introducing the candidate smart device into the IoT environment occurs during the deployment of the candidate smart device.

[0025] Example 6. According to the method of Example 1, wherein determining the optimal period for the delivery of status messages from the trusted designated node to the IoT hub includes accessing a lookup table indexed or referenced by the optimal period and the parameters.

[0026] Example 7. The method according to Example 1, wherein selectively introducing the candidate smart device into the IoT environment includes dynamically assigning the candidate smart device type as the trusted designated node during operation of the IoT environment.

[0027] Example 8. The method according to Example 7, wherein the IoT environment is part of a manufacturing plant, and wherein dynamically assigning the candidate smart devices as the trusted designated nodes includes dynamically assigning automated robots or controllers of the manufacturing plant as the trusted designated nodes during operation of the manufacturing plant.

[0028] Example 9. The method according to Example 7, wherein dynamically assigning the candidate smart device as the trusted designated node is performed by the initiator node based on the device acquisition model, further comprising:

[0029] The device is used to obtain a model that selects the trusted designated node from the neighboring / distance nodes of the IoT node via the initiator node.

[0030] Example 10. The method according to Example 7, wherein dynamically assigning the candidate smart devices as the trusted designated nodes is performed by the IoT center according to the center-assisted model.

[0031] Example 11. The method described in Example 1 further includes:

[0032] The status message of the initiator node is merged with the status message of the trusted designated node to form a merge report; and

[0033] The merged report is periodically sent to the IoT center via the trusted designated node, thereby reducing the power consumption of the IoT environment.

[0034] Example 12. A networked Internet of Things (IoT) environment, comprising:

[0035] IoT Center; and

[0036] A plurality of IoT devices, including a service requesting device (“initiator node”), wherein the IoT hub and / or the initiator node is operable to:

[0037] In response to parameters from the initiator node, candidate smart devices are identified from the plurality of IoT devices; and

[0038] Selectively introducing the candidate smart devices into the IoT environment includes assigning the candidate smart devices as trusted designated nodes within the IoT environment via the initiator node and / or the IoT hub, wherein the trusted designated nodes are operable to:

[0039] Based on the parameters of the initiator node, determine the optimal period for transmitting status messages from the trusted designated node to the IoT center; and

[0040] The status message is transmitted to the IoT center at the optimal period, so that the trusted designated node acts as a proxy for the initiator node when reporting the status message to the IoT center.

[0041] Example 13. In the IoT environment described in Example 12, the initiator node includes a battery, and the parameters include the battery's capacity level or state of charge.

[0042] Example 14. In the IoT environment described in Example 13, the initiator node is part of a high-power device having the battery, and the designated node is operable to determine the optimal cycle for delivering the status message based on the battery's capacity level or state of charge.

[0043] Example 15. An IoT environment according to Example 14, wherein the high-power device is a battery charger for the battery, and wherein the IoT hub and / or the initiator node is operable to selectively introduce the candidate smart device into the IoT environment by selectively introducing the battery charger as the trusted designated node into the IoT environment.

[0044] Example 16. In the IoT environment described in Example 12, the trusted designated node is operable to determine the optimal period for the delivery of status messages from the trusted designated node to the IoT hub by accessing a lookup table indexed or referenced by the optimal period and the parameters.

[0045] Example 17. An IoT environment according to Example 12, wherein the IoT hub and / or the initiator node is operable to selectively introduce the candidate smart device into the IoT environment by dynamically assigning the candidate smart device as the trusted designated node during operation of the IoT environment.

[0046] Example 18. An IoT environment according to Example 17, wherein the initiator node is operable to dynamically assign the candidate smart devices as the trusted designated nodes within the IoT environment based on a device acquisition model.

[0047] Example 19. An IoT environment according to Example 17, wherein the IoT hub is operable to dynamically assign the candidate smart devices as the trusted designated nodes within the IoT environment based on a hub-assisted model.

[0048] Example 20. An Internet of Things (IoT) environment, comprising:

[0049] IoT Center;

[0050] A vehicle having a body, one or more wheels connected to the body; and a battery connected to the body, the battery having a capacity level or state of charge, wherein the vehicle acts as a service requesting device (“initiator node”) within the IoT environment; and

[0051] Vehicle infrastructure equipment, wherein the vehicle is operable for:

[0052] In response to the capacity level or charging state, candidate smart devices are identified from a plurality of IoT devices in the IoT environment;

[0053] By assigning the candidate smart devices as trusted designated nodes within the IoT environment, the candidate smart devices are selectively introduced into the IoT environment, wherein...

[0054] The aforementioned vehicle infrastructure equipment is operable for:

[0055] Based on the capacity level or charging status, determine the optimal cycle for transmitting status messages from the vehicle infrastructure equipment to the IoT center; and

[0056] The status message is transmitted to the IoT center at the optimal period, so that the vehicle infrastructure device acts as an agent of the vehicle when reporting the status message to the IoT center.

[0057] The foregoing generalized features and other features and advantages of this disclosure will become apparent when understood in conjunction with the accompanying drawings and appended claims, based on the following detailed description of illustrative examples and models for carrying out this disclosure. Furthermore, this disclosure expressly includes combinations and sub-combinations of the elements and features presented above and below. Attached Figure Description

[0058] Figure 1 This is a schematic diagram of a representative Internet of Things (IoT) ecosystem according to an embodiment, in which statically assigned designated nodes are used.

[0059] Figure 2 It can be used Figure 1 A power evaluation line graph for the management or control of the IoT ecosystem, where the response cycle is shown on the vertical axis and the battery level of the initiator device or node is shown on the horizontal axis.

[0060] Figure 3 The illustration depicts a representative manufacturing line with dynamically assigned specified nodes according to aspects of this disclosure.

[0061] Figure 4 It is shown in the figure. Figure 1 and Figure 3 A top-level diagram of negotiation and management of designated nodes in a connected IoT ecosystem.

[0062] Figure 5 It is a model for selecting a designated node via an initiator device or node, according to aspects of this disclosure.

[0063] Figure 6 It is an alternative model used to select a specific node with the help of an IoT hub.

[0064] Figure 7 It is a multi-ecosystem / structure model used to merge messages in scenarios where initiator nodes in an IoT network send messages or reports via different IoT hubs.

[0065] Figure 8 It is shown in the figure. Figure 7 The flowchart illustrates the implementation of the structural model shown in the figure.

[0066] This disclosure may be modified or embodied in alternative forms, wherein representative embodiments are shown in the accompanying drawings and described in detail below. The inventive step of this disclosure is not limited to the disclosed embodiments. Rather, this disclosure is intended to cover alternatives falling within the scope of the disclosure defined by the appended claims. Detailed Implementation

[0067] Now referring to the accompanying drawings, which are present in several views, similar reference numerals denote similar features. Figure 1 The diagram illustrates a networked Internet of Things (IoT) ecosystem 10 with one or more IoT hubs 11. As used herein, the term "ecosystem" refers to a group of networked communication nodes that have a common root credential (i.e., a trusted digital credential that establishes a chain of trust for device authentication), as is known in the art. Figure 1 The IoT ecosystem 10 shown is a designated node implementation of a non-limiting, statically allocated smart location 12 (e.g., a smart home or building equipped with a smart garage 14). The smart location 12 may include multiple IoT devices 15-1, 15-2, and 15-3. For simplicity, IoT devices 15-1, 15-2, and 15-3 are collectively referred to herein as nodes 15 of the IoT ecosystem 10. However, the terms "device" and "node" are distinct and are therefore used in the different contexts below.

[0068] As used herein, devices such as IoT devices 15-1, 15-2, and 15-3 are several pieces of equipment that include or function as one or more communication nodes. A node is, in turn, a uniquely addressable resource or logical entity within the IoT ecosystem 10, possessing the functionality and capabilities that will be clearly identified as a functional whole by users of the IoT ecosystem 10. See below for reference. Figure 7 The described structure is a set of nodes 15 that interact with each other by accessing data model elements in a given domain. In other embodiments, the IoT ecosystem 10 within the scope of this disclosure may include more or fewer devices or nodes, wherein, for simplicity and clarity, they will be referred to hereinafter as... Figure 1 The example statically specifies the method. Figure 1The IoT devices 15-1, 15-2, and 15-3 may include, for example, smartphones, wireless / Wi-Fi enabled thermostats, garage doors or other doors / access points, security cameras, home appliances, or one or more other smart devices.

[0069] As part of the overall management of the IoT ecosystem 10, the periodic delivery of status messages occurs between nodes 15. This can occur via a low-power mesh networking protocol called Thread and / or the open-source Matter application layer protocol. For example, in common implementations, Thread can be used as a wireless communication method for controlling various Matter devices. As those skilled in the art will understand, Figure 1 The IoT ecosystem 10 can therefore be considered a Matter network.

[0070] exist Figure 1 In a representative embodiment, the IoT ecosystem 10 includes additional nodes 15 in the form of electric vehicles (EVs) 16 and EV chargers 17 (e.g., EVSE residential charging stations). Other vehicle embodiments may be used herein, including those with internal combustion engines (ICEs) or hybrid electric vehicles. In these or other embodiments, the vehicle can communicate with vehicle ecosystem devices that are also Matter devices. Therefore, from the security perspective of the initiator node 15I, the trusted designated node 15D is a device that can act as a "trusted node".

[0071] In embodiments where the initiator node 15I is EV 16, the EV charger 17 can therefore act as a trusted designated node 15D. In communication with the EV charger 17, the exemplary EV 16 flexibility of mixed device types occupies an energy budget region somewhere between a true high-power device type during normal operation of the EV 16 and a true low-power device type when the EV 16's battery level is depleted, encompassing both the aforementioned true high-power and true low-power device types. Similarly, as one aspect of the solution described herein, the EV charger 17 (or another designated device in different embodiments) can be statically or dynamically assigned to operate as a trusted designated node 15D within the networked IoT ecosystem 10.

[0072] Once assigned as a trusted designated node 15D, for example by EV 16 itself, by IoT hub 11, or by another smart device in the IoT ecosystem 10, EV charger 17 then acts as a messaging service broker to perform device status reporting operations and to negotiate with IoT hub 11 the optimal engagement period for transmitting status messages within the IoT ecosystem 10. In this embodiment, EV 16 will retain the ability to send pre-authorized high-priority or urgent messages directly to IoT hub 11, while the brokerage functions described for trusted designated node 15D will handle more regular messaging communication to IoT hub 11. Even if EV 16 is not assigned a trusted designated node 15D, EV 16 will also be able to send messages at a lower frequency as needed based on its power level.

[0073] In the IoT environment 10, which is a representative embodiment of an electrified motor vehicle in a vehicle IoT environment, Figure 1 The EV 16 comprises a body 18 and one or more wheels 20. The EV 16 is also equipped with a high-voltage propulsion battery (B). HV )22 and one or more electric traction motors 24. ICE-based or hybrid electric vehicle alternative embodiments may use other types of batteries 22 for other purposes, such as backup batteries for engine start / stop events, lead-acid or lithium starting batteries, smaller / limited-range propulsion batteries, etc. Although for the sake of simplicity, from Figure 1 Other components are omitted, but the EV 16 may also include: power electronics, such as a power inverter module operable to invert the DC voltage waveform from the propulsion battery 22 when the phase windings of the AC embodiment of the electric traction motor(s) 24 are energized; a DC-to-DC converter for regulating the DC voltage waveform to or from the propulsion battery 22; a thermal management system for maintaining the temperature of the propulsion battery 22 and the electric traction motor(s) 24, etc.

[0074] In a representative use case, when the operator of the EV 16 returns to the smart garage 14, the EV 16's onboard charging controller or other smart devices 25 can communicate with the EV charger 17 via message data 30 (dashed line) on the first link (D1). Similar message data 30 can be exchanged between the EV charger 17 and the IoT hub 11. Therefore, in Figure 1 In the example implementation, the dashed line depicting message data 30 represents the periodic transmission of lower priority / default information / messages from EV 16 to IoT hub 11.

[0075] Figure 1The diagram also illustrates internal data 32 (solid line) representing internal data transfer from a trusted designated node 15D. In this exemplary use case, the static (unchanging) trusted designated node 15D is the EV charger 17 and its associated processor / control circuitry (not shown, but understandable in the art). Subsequently, the EV charger 17 communicates as needed with one or more IoT devices 15-1, 15-2, and / or 15-3 within the smart home 12. A representative link (D2) between IoT devices 15-1 and 15-2 is also... Figure 1 As shown in the diagram. Similar to the described link (D1) from EV 16 to EV charger 17, link D2 indicates that one of IoT devices 15-1 or 15-2 can act as an initiator node of a mixed device type (similar to EV 16), in which case the other device 15-1 can act as a designated node (and vice versa). In this embodiment, EV 16 retains the ability to communicate directly with the IoT hub via internal data 32, for example, when the information is a fault or other high-priority or urgent message. As mentioned above, the device types and usage / configuration of the IoT ecosystem 10 can vary with the intended applications, and therefore... Figure 1 The examples shown are illustrative of this teaching and do not limit it.

[0076] Other hardware (omitted in the figures) associated with the various nodes 15 may take the form of one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), one or more electronic circuits, one or more central processing units (e.g., one or more microprocessors or processors), and associated computer-readable storage media / memory. Non-transitory components of such memory include computer storage media capable of storing machine-readable instructions in the form of one or more software or firmware programs or routines, one or more combinational logic circuits, one or more input / output circuits and devices, signal conditioning and buffering circuits, and other components accessible by one or more processors to provide the described functions. Therefore, using such hardware and associated antennas, receivers, and transmitters residing at the various nodes, information can be wirelessly exchanged between nodes.

[0077] Selection based on hybrid device type: combination Figure 1 10 References for the Internet of Things Ecosystem Figure 2As part of this strategy, in line diagram 35, a trusted designated node 15D is selected for hybrid device types (such as EV 16). The power level or charging state of the initiating or service requesting node (initiator node 15I in Figures 54 and 6) (e.g., EV 16) within the networked IoT ecosystem 10 is evaluated. The initiator node is a hybrid device type within the scope of this disclosure and can therefore be classified as a high-power or low-power device type as needed, based on one or more parameters of the initiator node 15I, and thus on current conditions or circumstances. In the current IoT context, the relative terms "high-power" and "low-power" are distinguishable from each other according to their relative energy consumption levels and their computing power and communication characteristics. Figure 1 The configuration of the device at node 15 can vary depending on the application.

[0078] Exemplary low-power device types include small battery-powered actuators or sensors, radio frequency identification (RFID) tracking devices, wearable monitors, or other smart devices. Such devices tend to have relatively low data transmission rates and may also follow appropriate communication protocols such as Bluetooth Low Energy (BLE) or Zigbee. In contrast, high-power device types in the IoT scenarios considered herein may consume significantly more energy and may involve complex data processing / transmission. For example, Figure 1 The IoT hub 11 can operate as a high-power device type, as can the EV charger 17, the vehicle controller of the EV 16, and so on. High-power IoT devices can also follow different communication protocols, typically but not limited to Wi-Fi or Ethernet. Therefore, the term "hybrid" as used herein refers to... Figure 1 The trusted designated node 15D has the ability to occupy any energy budget region between the characteristics of high-power device type and low-power device type. Therefore, the hybrid device type can operate as either a high-power or low-power device depending on the situation.

[0079] exist Figure 1 In a representative use case, when in ignition-off mode, EV 16 (a high-power device) is parked in smart garage 14, extremely close to EV charger 17. In this mode, propulsion battery 22 or other connected battery / energy storage systems may tend to consume power at a rate higher than the acceptable rate mentioned above. Considering this representative scenario, Figure 2 Line graph 35 illustrates the message response cycle on the vertical axis. The horizontal axis shows the battery level, in this case, the state of charge or remaining capacity of the propulsion battery 22.

[0080] According to this disclosure, a smart device is selected and introduced into the IoT ecosystem 10 to subsequently serve as a trusted designated node 15D, for example, selected by EV 16 or IoT hub 11. The smart device may be a hybrid or low-power device type and may be or may include an EV charger 17. Subsequently, when sending a status message 30 on behalf of EV 16, the smart device, now acting as trusted designated node 15D, negotiates an optimal engagement period with IoT hub 11. Thus, trusted designated node 15D acts as an agent for reporting device status from EV 16 and performing other interactions with various nodes 15 of IoT hub 11.

[0081] exist Figure 2 In Figure 35, line graph 35 depicts three different energy budget regions or power modes. The three example modes include low power (Mode I), mixed power (Mode II), and high power (Mode III). Line LL represents the inverse relationship between the response cycle on one side and the battery level / state of charge on the other. In this example, the battery level, as a reference parameter, can represent the battery (e.g., ...). Figure 1 The remaining capacity of the propulsion battery 22 (which powers the initiator node / device (e.g., EV 16)).

[0082] When EV 16 has a high battery level, EV 16 can continue to report its own message traffic to IoT Hub 11 at a predetermined or self-negotiated frequency / cycle. This is the default / normal operating mode of EV 16, and this would be the sole default mode without the benefits of this solution. Within the scope of this disclosure, as the battery level decreases, EV 16 moves from high power (Mode III) to low power (Mode I) capability. As EV 16 (or another initiator node) evolves towards Mode I, EV 16 will first enter Mode II (i.e., hybrid mode). Here, EV 16 (or IoT Hub 11) selectively assigns smart devices / nodes as trusted designated nodes 15D, thereby offloading the reporting task from the initiator node to the trusted designated node 15D. When the battery level of the initiator node 15I is relatively low or nearly depleted, the designated node 15D can use low power (Mode I) to transmit messages within the IoT network 10. Therefore, in one or more embodiments, the action of determining the optimal period for the state message transmission from a trusted designated node 15D representing EV 16 (or other initiator node 15I) to IoT hub 11 may include accessing a lookup table indexed or referenced by the optimal period and parameters of initiator node 15I, in which case the parameters of initiator node 15I include the battery level / charging state of propulsion battery 22.

[0083] Message Cycle: Generally, each node in a typical Matter ecosystem is required to periodically communicate with an IoT hub to maintain its state within the Matter network. Figure 1 In an example of a networked IoT environment, messages transferred within 10 can be of different types and convey specific information. For example, message types may 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 message delivery cycle depends on the device type, i.e., high power or low power.

[0084] Furthermore, the time frame is typically fixed at a maximum time limit spanning the Layer 2, Layer 3, and Layer 4 IoT stacks. As is known in the art, Layer 2 (i.e., L2 / Data Link Layer) is typically responsible for node-to-node data transfer within the network; in Matter networks, this is typically IEEE 802.15.4 (Thread / ZigBee) or Wi-Fi. L2 messages may include error detection, physical addressing of various devices, Media Access Control (MAC) addressing, etc. Layer 3 (i.e., L3 / Network Layer) is responsible for routing and logical addressing across network segments, packet forwarding, and implementing Thread, Wi-Fi, and other network connectivity protocols. Layer 4 (i.e., L4 / Transport Layer) is responsible for establishing connections and managing end-to-end communication between connected devices, among other tasks. Layers L2, L3, and L4 together implement a standardized IoT communication framework, facilitating the efficient use of devices manufactured by the same or different manufacturers.

[0085] When trying to manage the destination / origin of high-power device types (such as...) Figure 1 When communicating with representative EV 16 devices or other devices / nodes in a depleted energy state, potential issues may arise when using existing standards to manage message cycles related to the device type. This is for management purposes. Figure 1 Existing Matter-based and other methods for node interaction between node 15 and IoT hub 11 cannot efficiently handle the increased reporting rate of such devices. Therefore, this solution uses a trusted designated node 15D to selectively reconnect with IoT hub 11, doing so based on... Figure 2 The energy constraints or other parameters of the service request node / device illustrated in the example may be used when acting as a message passing broker, and a trusted designated node 15D may be employed. Figure 3 Dynamic selection of ).

[0086] Dynamic allocation: Brief reference Figure 3 In the 10A networked IoT infrastructure, devices / nodes can be dynamically allocated, rather than as... Figure 1As in the example, it is statically allocated. Dynamic allocation can be used in an exemplary manufacturing plant, where automated robots 38 are arranged relative to manufacturing line 40. Figure 3 The diagram illustrates various IoT devices 15-4, 15-5, 15-6, 15-7, 15-8, and 15-9. In this example, production or manufacturing is sequential, such that one of the robots 38 is located in the initial time window T1, upstream or downstream of another robot 38 in the second / later time window T2.

[0087] Figure 4 In a non-limiting example implementation, IoT device 15-4 can be configured as a smart lighting thread device, while IoT devices 15-5, 15-6, and 15-7 can be manufacturing control units / controllers. Although one device 15-7 is shown, the networked IoT infrastructure 10A can include multiple additional such devices 15-7, i.e., an integer n. Therefore, "manufacturing unit n" refers to one or more additional controllers along manufacturing line 40. Device 15-8 can include an RFID tag reader for asset tracking. Device 15-9 is illustrated as a smartphone. Various other devices can be used in a manufacturing plant, and therefore... Figure 3 The example provided is an illustrative example of this teaching and a non-limiting example of the teachings described above. Because it is dynamically assigned, the identity of the trusted designated node 15D may change during operation.

[0088] as Figure 1 This is a static example where the identity of the trusted designated node 15D is fixed, and various devices / nodes can exchange message data 30 (dashed lines). For example, an automated robot 38 may communicate with a manufacturing controller (first device type D1) in an initial time window T1, while a downstream automated robot 38 may communicate with a manufacturing controller (device type D2) in a second time window T2. The dashed lines of message data 30 represent, for example, the periodic transmission of information / messages from the automated robot 38 to the IoT hub 11. The internal data 32 (solid lines) mentioned above represents the transmission of internal data from a designated node (e.g., one of the automated robots 38), in which case the designated node changes dynamically as described below.

[0089] refer to Figure 4 Flowchart 42 continues the discussion on the dynamic assignment of hybrid device types, which can be dynamically assigned nodes according to one of the following two different models: (i) such as Figure 5 The device shown in the figure acquires model 50, or (ii) as Figure 6 The central auxiliary model 50A is illustrated in the figure. Figure 4In this embodiment, two different types of IoT hubs 11 are shown as IoT hub 11A and IoT hub 11B. For example, IoT hubs 11A and 11B can be embodied as a smart switch and a voice assistant platform, such as Amazon Alexa, Siri, or Google Assistant, respectively. In another embodiment, IoT hub 11B can also be... Figure 1 The EV 16. Figure 4 The diagram also schematically illustrates Matter controller 150, one of the IoT nodes 15, such as a smartphone, infotainment system, etc. When the IoT environment 10A is as follows... Figure 3 When the manufacturing plant shown is partially completed, dynamically assigning candidate hybrid device types as trusted designated nodes 15D may include dynamically assigning automated robots 38 or manufacturing controllers (e.g., 15-5, 15-6, or 15-7) as trusted designated nodes 15D. This may occur during ongoing operation of the manufacturing line in the manufacturing plant, where the identity of the trusted designated node 15D may change during operation.

[0090] Figure 4 A sequence of events that can be executed according to this disclosure is generally illustrated. The sequence begins with the selection of a trusted designated node 15D within the networked IoT infrastructure 10 or 10A described above, or a variant of the networked IoT infrastructure described above. Arrow INIT indicates an initiation signal. Arrow ACK indicates an acknowledgment signal from both the IoT hub 11A and the trusted designated node 15D. The exchange of signals INIT and ACK dynamically locates and initially selects the trusted designated node 15D from node 15.

[0091] As part of this process, Matter controller 150 performs a series of functions F1-F6. These functions include discovering candidate designated nodes from discovered neighboring nodes (F2), authorizing the use of designated nodes (F3), evaluating the communication and power capabilities of designated nodes for ideal capabilities corresponding to a given situation (e.g., in terms of energy requirements) (F4), and selecting a designated node (F5) to be used as a proxy. Access control functions (F6) can be performed by trusted designated node 15D via corresponding functions (F6A). Such function F6 may include transferring control to trusted designated node 15D. Designated node 15D performs additional functions, including service provisioning (F7) and management of ongoing services (F8).

[0092] refer to Figure 5 The device obtains the specified node model 50, in Figure 1 In a representative case, EV 16 is paired with EV charger 17 and two IoT centers (e.g., Figure 5Used in conjunction with 11A and 11B, when IoT hub 11 dynamically monitors node compliance and other configuration information, one of the IoT hubs 11 can dynamically reclassify licenses. Once a license is activated, it can be managed by node 15 upon receiving a new request. Unless otherwise specified... Figure 4 The Matter controller 150 needs to reclassify the trusted designated node 15D, otherwise the trusted designated node 15D cannot nominate other nodes 15 to act as another trusted designated node 15D. Therefore, aspects of this disclosure may require selective reclassification of the trusted designated node 15D to enable it to do so.

[0093] Static specified nodes: In an exemplary smart home implementation, such as Figure 1 Use cases where the location of a given IoT device is readily available, for example... Figure 1 The EV charger 17 is located in a fixed position within the smart garage 14, and this device can subsequently be used as a trusted designated node 15D. In this embodiment, once assigned by the EV 16 or IoT hub 11, the EV charger 17 / other trusted designated node 15D then acts as a messaging agent for the EV 16, for engaging with direct messaging with the IoT hub 11. Status reports can be merged with the status messages of the trusted designated node 15D (i.e., its own status messages destined for the IoT hub 11). In some cases as mentioned above, the EV 16 can also tag critical messages and transmit them directly to the IoT hub 11.

[0094] In one or more embodiments, the designation of a trusted designated node 15D in a static designation scenario can occur during the IoT device deployment process. As understood in the art, the IoT device deployment process ensures network security by preventing electronic spoofing and preventing unauthorized or malicious devices from joining the IoT network. During device deployment, the device is configured for use in the IoT network, assigned operating parameters to ensure device / communication consistency, and manages network resources. Deploying a new device may include enabling the device to broadcast its presence while scanning 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, receive a unique device identifier, and verify its connectivity to other nodes. Once deployed, the new device is free to function as one of the various nodes 15 within the IoT ecosystem 10, 10A.

[0095] Dynamically specified nodes: For Figure 3In an exemplary industrial embodiment, dynamic specification can occur in response to manufacturing controller unit 1 (i.e., devices 15-5 (device type D1)) requesting assistance from automated robot 38. Robot 38 itself may be a hybrid device type as described above, capable of performing multiple tasks in the factory, having functions such as asset management, or quality control, defect analysis, repair, maintenance, etc. Figure 3 During the initial time window T1, the automated robot 38 can assign device 15-5 as a trusted designated node 15D. Thereafter, once the second time window T2 begins, the robot 38 can dynamically update the IoT center 11.

[0096] exist Figure 5 In model 50, for example, such as Figure 1 A service request initiator node (15I), such as EV 16, can communicate with a designated node 15D (e.g., EV charger 17 in this representative embodiment). Model 50 describes a "device acquisition" method in the sense that the initiator node 15I, as a hybrid device type, determines / selects the designated node 15D from neighboring / distance nodes 15. Figure 5 The diagram illustrates various communications between the initiator node 15I, the trusted designated node 15D, and the IoT centers 11A and 11B. Figure 5 From top to bottom, these include node discovery 51, followed by a request for specified node information 52. The initiating node 15I also initiates a service authorization 53 to the IoT center 11A. The trusted specified node 15D can provide its device type to the IoT center 11B, i.e., as message 54. The IoT center 11A can send a message 55 containing device type information similar to message 54 to the initiating node 15I.

[0097] Figure 5 Model 50 also illustrates admission control logic 57 for management control, namely, enabling the trusted designated node 15D to act as an agent as requested. Connection and provisioning status 58 can be transmitted to the IoT hub 11A. When appropriate, additional messages 59 may include messages regarding: denying the designated agent function of the trusted designated node 15D and deauthorizing it. The trusted designated node 15D then transmits decision feedback 60 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., when the trusted designated node 15D is activated.

[0098] Figure 6 The alternative center auxiliary model 50A can be used when the requesting device or initiator node 15I cannot specify a trusted designated node 15D. For example, Figure 1The exemplary EV 16 can act as a service recipient and communicate with the IoT hub 11. EV 16 can transmit a service request 63 to the IoT hub 11. The IoT hub 11 can then send a resource availability request 64A to two possible candidate nodes, designated nodes 15D-1 and 15D-2. Each candidate then responds with a message 67Y (yes) or 67N (no), indicating whether it can provide the requested service. The IoT hub 11 then uses its admission control logic 69 (similar to...) Figure 5 The logic 57) is used to process these responses.

[0099] Once IoT Center 11 decides which candidate node to accept, in this case Trusted Designated Node 15D-1, after it provides message 67Y, IoT Center 11 sends message 70 to EV 16 to initiate acceptance of the service from Trusted Designated Node 15D-1. EV 16 (i.e., its onboard controller) replies with acceptance message 71 to the capable Trusted Designated Node 15D-1. Trusted Designated Node 15D-1 then sends message 72 to EV 16, indicating that Trusted Designated Node 15D-1 has been provisioned and connected. Afterwards, EV 16 and Trusted Designated Node 15D-1 exchange message 73, indicating that the service is active and in progress.

[0100] Now for reference Figure 7 In some cases, devices within a connected IoT ecosystem 10 or 10A may include multiple IoT hubs 11, such as hubs H1, H2, and H3. Figure 1 In a representative embodiment, centers H1, H2, and H3 may be embodied as multiple different control modules of EV 16. Devices with such connectivity options may require intelligent and merging optimization capabilities for allocating trusted designated nodes 15D and for determining an appropriate reporting rhythm or period for energy. Various nodes 15 can serve as initiator nodes 15I. A device as node N1 can communicate with centers H1 and H3, while a device as node N2 can communicate with center H2. Similarly, a device as node N3 can communicate with center H3. Therefore, in this example, node N1 has two possible communication options: center H1 or center H3.

[0101] In a scenario where a device uses multiple centers, sending periodic reports consumes significant processing power and requires coordination of sleep / wake cycles, among other things. To reduce power consumption, this strategy involves merging the various reports and determining the optimal time to send the report / message to one of the IoT centers 11. Representative conditions are illustrated in condition table 75 as, for example, energy budget, (energy) cost, communication coverage, latency, node proximity, and node priority (e.g., relay, designated, critical, etc.). Based on these conditions, a set of candidate nodes 15 is identified, from which a dominant node is selected. In some embodiments, the various conditions can be normalized and weighted such that condition table 75 collectively outputs a binary decision (0 or 1) regarding whether to assign a trusted designated node 15D or continue using the initiator node 15I to deliver its status messages to the IoT center 11.

[0102] For example, in box 76, node 15 is evaluated against the conditions in Table 75 to determine the trusted designated nodes 15D, shown as 15D-1 and 15D-2 for simplicity. Given these conditions, node 15N is ignored due to lack of the required capabilities. Node 15 * Nodes 15D-1 and 15D-2 are considered the preferred choices based on conditions and relative capabilities. Of the remaining two designated nodes, 15D-1 and 15D-2, node 15D-2 is currently likely occupied, i.e., busy performing functions that exclude it from use as a trusted designated node 15D. This would make node 15D-1 available for service and capable of being used as a trusted designated node 15D. In this example, node 15D-1 is then assigned as a trusted designated node 15D, and is reported accordingly (Box 78). This is referenced above. Figure 2 The discussion takes place at a pace based on a predetermined energy budget.

[0103] refer to Figure 8 The embodiments of method 100 are described to illustrate aspects of this teaching. Generally, method 100 is intended to manage intra-node interactions in a networked IoT environment, wherein such a networked environment is embodied herein as a corresponding… Figure 1 and Figure 3The IoT environments 10 and 10A are described. Method 100 may include identifying candidate smart devices among multiple neighboring nodes 15 using a service request initiator node (possibly a high-power initiator node 15I) of the IoT environments 10, 10A, or IoT hub 11. Based on the requirements of the initiator node 15I, the candidate smart device may be high-power, low-power, or a hybrid (flexibly operable as either a low-power or high-power device type). Method 100 includes selectively assigning candidate devices as trusted designated nodes 15D within the IoT environments 10 and 10A based on the battery level or other parameters of the initiator node 15I. Method 100 also includes determining the optimal period for status message delivery from the initiator node 15I to the IoT hub 11 of the IoT environments 10 and 10A based on parameters of the initiator node 15I. Method 100 includes transmitting status messages to the IoT hub 11 using the trusted designated node 15D at the optimal period. This action occurs via designated node 15D, enabling trusted designated node 15D to negotiate the cycle and act as a proxy for initiator node 15I when reporting status messages to IoT center 11.

[0104] Figure 8 A representative embodiment of method 100 shown begins at logic block B102. Here, method 100 includes methods via initiator node 15I (e.g., Figure 1 The EV 16 can be initialized or service requested. For example, the EV 16 can be parked in the smart garage 14 and enter an ignition-off state near the EV charger 17. Figure 3 In the manufacturing example, automated robot 38 or another device can act as the initiator node 15I. Then, method 100 continues to box B104.

[0105] Box B104 requires scanning neighboring nodes 15 to find candidate nodes, i.e., one or more nodes 15 that could potentially be used as the aforementioned trusted designated node 15D. Using the example of EV 16, for example, EV 16 can scan neighboring devices / nodes that could potentially be used as the trusted designated node 15D within its proximity. Method 100 then proceeds to box B106.

[0106] In block B106, method 100 includes determining whether the initiator node 15I is a multi-node device. Consistent with this vehicle example, EV 16 will be such a device, as EV 16 will typically include multiple different control modules mentioned above. This characteristic is typical of hybrid device types. When the initiator node 15I is a multi-node device, method 100 proceeds to block B108, and alternatively, when the initiator node 15I is a single-node device, method 100 proceeds to block B110.

[0107] After determining that the initiator node 15I is a multi-node device (such as EV 16), the process proceeds from box B106 to box B108. Box B108 includes locating intra-node neighbors. As understood in the art, intra-node neighbors in the networked IoT infrastructure 10 are neighboring devices / nodes connected to or belonging to the same local network segment as the scanning device. For example, intra-node neighbors may share a public router or network connector. After locating intra-node neighbors, method 100 continues to box B112.

[0108] At box B110, Figure 8 Method 100 continues to follow the single-node process, as shown in the reference above. Figure 1 As described. Then, method 100 is completed, and the single trusted designated node 15D thereafter acts as a proxy for message transmission performed by the initiator node 15D.

[0109] Box B112 includes determining whether an intra-node neighbor is located at box B108. If an intra-node neighbor is located, method 100 proceeds to box B114. If no intra-node neighbor is located, method 100 instead proceeds to box B110.

[0110] Box B114 includes the above reference. Figure 7 The described merge message packets. Method 100 then proceeds to box B116.

[0111] In box B116, the merged message is sent to IoT center 11, for example. Figure 7 The IoT center H1 or H3. Then, method 100 is completed.

[0112] As described above, this solution relates to the introduction of smart devices as designated nodes 15D into a networked IoT ecosystem (such as...). Figure 1 and Figure 3 The methods and node systems in the IoT ecosystem (10 and 10A). Then, based on initiator devices (such as... Figure 1 Based on parameters such as the energy budget of the EV 16, the designated node 15D will selectively negotiate with the IoT center 11 for the optimal engagement period for message exchange. Reports from the trusted designated node 15D can be based on parameters of the requesting device or current conditions, such as the battery level of the propulsion battery 22 or other batteries in the EV 16.

[0113] Trusted Designated Nodes 15D can be categorized in this way and, in some cases, selected by EV 16 or other initiator nodes / devices. In other methods, the IoT Hub 11 can assist in selecting the Trusted Designated Nodes 15D. Reporting is then performed at an appropriate pace or cycle according to the energy budget. This action ensures that... Figure 1High-power device types like the EV 16 can be used as part of the IoT ecosystem 10 (e.g., the Matter ecosystem), even when in a power-depleted state. This is ensured by using a trusted designated node 15D (e.g., the EV charger 17) as a proxy to report device status to the IoT hub 11. In such an embodiment, this, in turn, helps to minimize Figure 1 The power consumption of battery 22. In view of the foregoing disclosure, those skilled in the art will readily understand these and other accompanying benefits.

[0114] This disclosure allows for numerous different forms of embodiments. Representative examples of this disclosure are shown in the accompanying drawings and are described in detail herein as non-limiting examples of the disclosed principles. Therefore, elements and limitations described in the abstract, introduction, summary, and detailed description sections but not expressly set forth in the claims should not be incorporated into the claims, individually or collectively, by implication, inference, or otherwise.

[0115] For the purposes of this specification, unless specifically waived, the use of the singular includes the plural and vice versa; the terms “and” and “or” should be used both as conjunctions and disjunctive words; “any” and “all” should mean “any and all”; and the words “including,” “containing,” “comprising,” “having,” and similar words should mean “including, but not limited to.” Furthermore, approximate words such as “approximately,” “almost,” “substantially,” “generally,” “approximately,” etc., may be used herein in the sense of “being, near, or almost being” or “within 0-5%” or “within acceptable manufacturing tolerances” or logical combinations thereof.

[0116] The detailed description and accompanying drawings are intended to support and describe this teaching, but the scope of this teaching is defined only by the claims. While some preferred modes and other embodiments for carrying out this teaching have been described in detail, various alternative designs and embodiments exist for practicing the teaching as defined in the appended claims. Furthermore, this disclosure explicitly includes combinations and sub-combinations of the elements and features presented above and below.

Claims

1. A method for managing communication between IoT nodes in a networked IoT environment having Internet of Things (IoT) nodes and an IoT hub, the method comprising: In response to parameters from the service request initiator node, candidate smart devices are identified from the IoT nodes; Selectively introducing the candidate smart devices into the IoT environment includes using the initiator node or the IoT hub to assign the candidate smart devices as trusted designated nodes within the IoT environment; Based on the parameters of the initiator node, determine the optimal period for transmitting status messages from the trusted designated node to the IoT center; as well as The status message is transmitted to the IoT center via the trusted designated node at the optimal period, so that the trusted designated node acts as a proxy for the initiator node when reporting the status message to the IoT center.

2. The method of claim 1, wherein the initiator node comprises a battery, and wherein the parameter comprises the battery's capacity level or state of charge.

3. The method of claim 2, wherein the initiator node is a part of a vehicle having the battery, and wherein determining the optimal period for the delivery of the status message is based on the battery's capacity level or state of charge.

4. The method of claim 3, wherein selectively introducing the candidate smart device into the IoT environment includes selectively introducing an electric vehicle charger into the IoT environment as the trusted designated node, and wherein the electric vehicle charger includes the candidate smart device.

5. The method of claim 1, wherein selectively introducing the candidate smart device into the IoT environment occurs during the deployment of the candidate smart device.

6. The method of claim 1, wherein determining the optimal period for the delivery of status messages from the trusted designated node to the IoT center includes accessing a lookup table indexed or referenced by the optimal period and the parameters.

7. The method of claim 1, wherein selectively introducing the candidate smart device into the IoT environment includes dynamically assigning the candidate smart device type as the trusted designated node during operation of the IoT environment.

8. The method of claim 7, wherein the IoT environment is part of a manufacturing plant, and wherein dynamically assigning the candidate smart devices as the trusted designated nodes includes dynamically assigning automated robots or controllers of the manufacturing plant as the trusted designated nodes during operation of the manufacturing plant.

9. The method of claim 7, wherein dynamically assigning the candidate smart devices as the trusted designated nodes is performed by the initiator node based on the device acquisition model, further comprising: The device is used to obtain a model that selects the trusted designated node from the neighboring / distance nodes of the IoT node via the initiator node.

10. The method of claim 7, wherein dynamically assigning the candidate smart devices as the trusted designated nodes is performed by the IoT center according to the center-assisted model.

Images