KR20230113652A - Efficient communication for devices of a home network - Google Patents

Abstract

Systems and methods are provided for efficiently communicating over a fabric network of devices in a home environment or similar environment. For example, electronic devices can efficiently control communications to balance power concerns and reliability concerns, and analyze Internet Protocol version 6 (IPv6) packet headers using EULAs (Extended Unique Local Addresses) to determine specific preferences. Can efficiently communicate messages to networks, can efficiently communicate software updates and status reports across a fabric network, and/or can participate in a fabric network easily and efficiently.

Description

Efficient communication for devices in a home network {EFFICIENT COMMUNICATION FOR DEVICES OF A HOME NETWORK}

[0001] The present disclosure relates to efficient communication enabling a variety of devices, including low-power or sleepy devices, to communicate in a home network or similar environment.

[0002] This section is intended to introduce the reader to various aspects of the technology that may be related to the various aspects of the technology described and/or claimed below. This discussion is believed to help provide the reader with background information to aid in a better understanding of various aspects of the present disclosure. Accordingly, it should be understood that these statements are made in this light and not as admissions of prior art.

[0003] Network-connected devices are popping up all over homes. Some of these devices can communicate with each other over a single network type (eg, WiFi connection), often using transport protocols. For some battery-powered devices, it may be desirable to use less power-intensive connection protocols or receive a reduced fee. However, in some scenarios, devices connected to a lower power protocol may not be able to communicate with devices connected to a higher power protocol (eg, WiFi).

[0004] Moreover, numerous electronic devices can now be connected to wireless networks. For example, smart meter technology uses a wireless network to communicate electrical energy consumption data associated with dwelling characteristics back to the utility for monitoring, billing, and the like. As such, a number of wireless networking standards are currently available that allow electronic devices to communicate with each other. Some smart meter implementations, for example, employ 6LoWPAN (employ Internet Protocol version 6 (IPv6) over Low power Wireless Personal Area Networks) to enable electronic devices to communicate with the smart meter. However, currently available wireless networking standards such as 6LoWPAN generally may not be well equipped to support electronic devices deployed throughout a residence or home in one or more practical scenarios. That is, currently available wireless networking standards may not efficiently connect all electronic devices in networks in a secure yet simple consumer-friendly manner in view of one or more known practical constraints. Also, for one or more practical scenarios, currently available wireless networking standards may not provide an efficient way to add new electronic devices to an existing wireless network in an ad hoc manner.

[0005] Additionally, when providing a wireless network standard for electronic devices for use in and around the home, it would be advantageous to use a wireless network standard that provides an open protocol for different devices to learn how to gain access to the network. will be. In addition, given the number of electronic devices that can be associated with a home, a wireless network standard such as IPv6 (Internet Protocol It will be advantageous in that it can support version 6) communication. Also, a wireless network standard that allows electronic devices to communicate within a wireless network using a minimal amount of power would be beneficial. With these features in mind, each known and currently available wireless networking standard in the context of providing a low-power, IPv6-based wireless mesh network standard that has an open protocol and can be used for electronic devices in and around the home. It is contemplated that one or more disadvantages are presented by For example, wireless network standards such as Bluetooth®, Dust Networks®, Z-wave®, WiFi, and ZigBee® fail to provide one or more of the desired features described above.

[0006] For example, Bluetooth® generally provides a wireless network standard for communicating over short distances via short-wavelength radio transmissions. As such, the wireless network standard of Bluetooth® may not support a communication network of multiple electronic devices deployed throughout a home. Moreover, the wireless networking standard of Bluetooth® may not support wireless mesh communication or IPv6 addresses.

[0007] As mentioned above, the wireless network standard provided by Dust Networks® may also introduce one or more disadvantages to one or more features that allow electronic devices deployed in a home to communicate efficiently with each other. In particular, the Dust Networks® wireless network standard may not provide an open protocol that can be used by others to interface with devices operating in the Dust Networks® network. Instead, Dust Networks® can be designed to facilitate communication between devices located in industrial environments such as assembly lines, chemical plants, and the like. As such, the Dust Networks® wireless network standard is about providing a reliable communications network with predefined time windows in which each device can communicate to and listen for commands from other devices. can In this way, the Dust Networks® wireless network standard may require sophisticated and relatively expensive wireless transmitters that may not be economical to implement into consumer electronics devices for use in the home.

[0008] Like Dust Networks® wireless network standards, the wireless network standards associated with Z-wave® may not be open protocols. Instead, the Z-wave® wireless network standard may be available only to authorized clients that embed a particular transceiver chip into their device. Moreover, the Z-wave® wireless network standard may not support IPv6-based communications. That is, the Z-wave® wireless network standard may require a bridge device to convert data generated on a Z-wave® device into IP-based data that can be transmitted over the Internet.

[0009] Now, referring to Z-wave® wireless network standards, Z-wave® has two standards commonly known as ZigBee® Pro and ZigBee® IP. Additionally, ZigBee® Pro may have one or more drawbacks in the context of support for wireless mesh networking. Instead, ZigBee® Pro may rely, at least in part, on a central device that facilitates communication between each device in the ZigBee® Pro network. In addition to the increasing power requirements for this central device, devices that are left on to process or reject certain wireless traffic can generate additional heat inside the housings of the devices, which is Some sensor readings, such as temperature readings, can be changed. Since these sensor readings can be useful in determining how each device in the home can operate, it can be advantageous to prevent unnecessary heat generation inside the device that can change sensor readings. Additionally, ZigBee® Pro may not support IPv6 communication.

[0010] Referring now to ZigBee® IP, ZigBee® IP can introduce one or more disadvantages in the context of direct device-to-device communication. ZigBee® IP is about facilitating communication by relaying device data to a central router or device. As such, a central router or device may require a constant power supply and thus not provide a low power means for communicating between devices. Moreover, ZigBee® IP may have a practical limit on the number of nodes that can be used in one network (ie ~20 nodes per network). Additionally, ZigBee® IP uses the "Ripple" routing protocol (RPL), which can exhibit high bandwidth, processing, and memory requirements that can imply additional power for each ZigBee® IP connected device.

[0011] Like the ZigBee® wireless network standards mentioned above, a wireless network of WiFi can present one or more disadvantages in enabling communications among devices with low power requirements. For example, the wireless network standard of WiFi may also require that each network device be always powered on, and may further require the existence of a central node or hub. As known in the art, WiFi is a relatively common wireless network standard that can be ideal for relatively high bandwidth data transmissions (eg, streaming video, syncing devices). As such, WiFi devices are typically coupled to a continuous power source or rechargeable batteries that support a constant stream of data transmissions between devices. Also, a wireless network of WiFi may not support wireless mesh networking. Nonetheless, WiFi can sometimes provide better connectivity than some lower-power protocols.

[0012] A summary of specific embodiments disclosed herein is presented below. It should be understood that these aspects merely provide the reader with a brief summary of these specific embodiments and that these aspects are not intended to limit the scope of this disclosure. Indeed, the disclosure may include various aspects that may not be presented below.

[0013] Systems and methods are provided for efficiently communicating over a fabric network of devices in a home environment or similar environment. For example, electronic devices can efficiently control communications to balance power concerns and reliability concerns, and analyze Internet Protocol version 6 (IPv6) packet headers using EULAs (Extended Unique Local Addresses) to determine specific preferences. Can efficiently communicate messages to networks, can efficiently communicate software updates and status reports across a fabric network, and/or can participate in a fabric network easily and efficiently.

[0014] For example, an electronic device has a memory or storage device that stores instructions for operating the network stack, a processor for executing the instructions, and a network-connected device that participates in a fabric of devices and uses the network stack to send messages to target devices in the fabric of devices. It may include a network interface for communication. The network stack consists of an application layer to provide application payloads with data to be transmitted in messages, a platform layer to encapsulate application payloads in a message's universal message format, and User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). and a transport layer for selectively transmitting messages using Internet Protocol Version 6 (IPv6), and a network layer for communicating messages using Internet Protocol Version 6 (IPv6) over one or more networks. These networks may include, for example, an 802.11 wireless network, an 802.15.4 wireless network, a powerline network, a cellular network, and/or an Ethernet network. Moreover, the application layer, platform layer, transport layer, and/or network layer can determine the type of message, the network over which the message will be transmitted, the distance the message can travel through the fabric, the power consumption behavior of the electronic device, and the power consumption of the target device. and/or power consumption behavior of an intermediate device in a fabric of devices that will communicate a message between the electronic device and the target device. Moreover, changing the nature of the communication scheme can cause the electronic device, target device and/or intermediate device to consume different amounts of power and allow messages to reach the target node more or less reliably.

[0015] In another example, a tangible, non-transitory computer-readable medium may contain instructions to be executed by a first electronic device communicatively coupled to other electronic devices of a fabric of devices in a home environment. The instructions may include instructions for the first electronic device to receive an Internet Protocol version 6 (IPv6) message from the second electronic device over the first network of the fabric of devices. The message may be directed to a target electronic device. The instructions may further include instructions for identifying an Extended Unique Local Address (EULA) encoded in the IPv6 header of the message. Here, an Extended Unique Local Address (EULA) may indicate that the second network is preferred in order to reach the target electronic device. The instructions may also include instructions for communicating a message through the fabric of devices towards the target electronic device using the second network based at least in part on an Extended Unique Local Address (EULA).

[0016] A method for sending a software update over a fabric network can include sending an image query message from a first device in the fabric network to a second device or local or remote server in the fabric network. The image query message may include information about the transmission capabilities of the first device and software stored on the first device. The image query response may be received by the first device from a second device or a local or remote server. The image query response indicates whether a software update is available and includes download information with a uniform resource identifier (URI) for causing the first device to download the software update. The image query message contains transmitter information about the transmission capabilities of the transmitter device and the software stored on the transmitter device, and the update priority. Using the URI, a software update can be downloaded at the first device from the sender device. The software may be downloaded at a time based at least in part on network traffic and update priorities of the fabric network, and the software may be downloaded in a manner based at least in part on common delivery capabilities indicated in the image query message and image query response. .

[0017] In a further example, a tangible, non-transitory computer-readable medium may store the status report format. The status report format includes a profile field for indicating a status update type of a plurality of status update types, a status code for indicating the status being reported, the status code being configured to be interpreted in a manner based at least in part on the status update type. and a next status field to indicate whether an additional status is included in the status report formed using the status report format.

[0018] Another example of an electronic device is a memory storing instructions for causing a first electronic device to pair with a fabric network comprising a second electronic device, a processor for executing instructions, and accessing 802.11 and 802.15.4 logical networks. It includes a network interface for The instructions may include instructions for establishing communication with the second electronic device over the first 802.15.4 logical network. The second electronic device can be paired with the fabric network and can communicate with the service through other logical networks in the fabric network. The instructions may also receive network configuration information from the service, via the second electronic device, for causing the first electronic device to participate in the first 802.11 logical network, establish communications over the first 802.11 logical network, and establish communications over the first 802.11 logical network. It connects to the service through and may include commands for registering to be paired with the fabric network through communication with the service.

[0019] Various refinements of the features noted above may be used in conjunction with various aspects of the present disclosure. Additional features may also be included in these various aspects as well. These improvements and additional features may be used individually or in any combination. For example, the various features discussed below in connection with one or more of the illustrated embodiments may be included alone or in any combination of any of the above-described aspects of the disclosure. The brief summary presented above is intended to familiarize the reader with the specific aspects and contexts of embodiments of the present disclosure, but is not intended to limit the scope of the claims.

[0020] Various aspects of the present disclosure may be better understood upon reading the following detailed description and referring to the drawings.
1 illustrates a block diagram of a generic device capable of communicating with other devices deployed in a home environment using an efficient network layer protocol according to one embodiment.
[0022] FIG. 2 illustrates a block diagram of a home environment in which the generic device of FIG. 1 can communicate with other devices via an efficient network layer protocol, according to one embodiment.
[0023] FIG. 3 illustrates an example wireless mesh network associated with the devices shown in the home environment of FIG. 2, according to one embodiment.
[0024] FIG. 4 illustrates a block diagram of an Open Systems Interconnection (OSI) model featuring a communication system for the home environment of FIG. 2, according to one embodiment.
[0025] FIG. 5 illustrates a detailed diagram of an efficient network layer of the OSI model of FIG. 4, according to one embodiment.
[0026] FIG. 6 illustrates a flow diagram of a method of implementing a Routing Information Protocol - Next Generation (RIPng) network as a routing mechanism of the efficient network layer of FIG. 5, according to one embodiment.
[0027] FIGS. 7A-7D illustrate examples of how the RIPng network of the method of FIG. 6 may be implemented according to one embodiment.
[0028] FIG. 8 illustrates a block diagram of a manufacturing process involving embedding a security credential into the generic device of FIG. 1, according to one embodiment.
[0029] FIG. 9 illustrates an exemplary handshake protocol between devices in the home environment of FIG. 2 using the Datagram Transport Layer Security (DTLS) protocol at the efficient network layer of FIG. 5, according to one embodiment.
10 illustrates a fabric network with a single logical network topology, according to one embodiment.
11 illustrates a fabric network with a star network topology, according to one embodiment.
12 illustrates a fabric network with an overlapping network topology, according to one embodiment.
13 illustrates a service communicating with one or more fabric networks, according to one embodiment.
14 illustrates two devices of a fabric network in a communication connection, according to one embodiment.
15 illustrates a unique local address format (ULA) that may be used to address devices of a fabric network, according to one embodiment.
16 illustrates a process for proxying peripheral devices on a hub network, according to one embodiment.
17 illustrates a tag-length-value (TLV) packet that may be used to transmit data over a fabric network, according to one embodiment.
[0038] FIG. 18 illustrates a general message protocol (GMP) that may be used to transmit data over a fabric network that may include the TLV packets of FIG. 17, according to one embodiment.
[0039] FIG. 19 illustrates message header fields of the GMP of FIG. 18, according to one embodiment.
[0040] FIG. 20 illustrates the Key Identifier field of the GMP of FIG. 18, according to one embodiment.
[0041] Figure 21 illustrates the application payload field of the GMP of Figure 18, according to one embodiment.
22 illustrates a status reporting schema that may be used to update status information of a fabric network, according to one embodiment.
[0043] FIG. 23 illustrates the profile fields of the status reporting schema of FIG. 22, according to one embodiment.
24 illustrates a protocol sequence that may be used to perform a software update between a client and a server, according to one embodiment.
[0045] FIG. 25 illustrates an image query frame that may be used in the protocol sequence of FIG. 24, according to one embodiment.
[0046] FIG. 26 illustrates a frame control field of the image query frame of FIG. 25, according to one embodiment.
[0047] FIG. 27 illustrates a product specification field of the image query frame of FIG. 25, according to one embodiment.
[0048] FIG. 28 illustrates a version specification field of the image query frame of FIG. 25, according to one embodiment.
[0049] FIG. 29 illustrates a locale specification field of the image query frame of FIG. 25, according to one embodiment.
[0050] FIG. 30 illustrates an integrity type support field of the image query frame of FIG. 25, according to one embodiment.
[0051] FIG. 31 illustrates an update scheme support field of the image query frame of FIG. 25, according to one embodiment.
[0052] FIG. 32 illustrates an image query response frame that may be used in the protocol sequence of FIG. 24, according to one embodiment.
[0053] FIG. 33 illustrates a uniform resource identifier (URI) field of the image query response frame of FIG. 32 according to an embodiment.
[0054] FIG. 34 illustrates an integrity specification field of the image query response frame of FIG. 32, according to one embodiment.
[0055] FIG. 35 illustrates an update scheme field of the image query response frame of FIG. 32, according to one embodiment.
[0056] Figure 36 illustrates a sequence used to utilize a data management protocol to manage data between devices in a fabric network, according to one embodiment.
[0057] FIG. 37 illustrates a snapshot request frame that may be used in the sequence of FIG. 36, according to one embodiment.
[0058] FIG. 38 illustrates an example profile schema that may be accessed using the snapshot request frame of FIG. 37, according to one embodiment.
[0059] Figure 39 is a binary format of a path that can represent a path in a profile schema, according to one embodiment.
[0060] FIG. 40 illustrates a watch request frame that may be used in the sequence of FIG. 36, according to one embodiment.
[0061] Figure 41 illustrates a periodic update request frame that may be used in the sequence of Figure 36, according to one embodiment.
[0062] FIG. 42 illustrates a refresh request frame that may be used in the sequence of FIG. 36, according to one embodiment.
[0063] FIG. 43 illustrates a cancel view request that may be used in the sequence of FIG. 36, according to one embodiment.
[0064] Figure 44 illustrates a view response frame that may be used in the sequence of Figure 36, according to one embodiment.
[0065] FIG. 45 illustrates an explicit update request frame that may be used in the sequence of FIG. 36, according to one embodiment.
[0066] Figure 46 illustrates a view update request frame that may be used in the sequence of Figure 36, according to one embodiment.
[0067] Figure 47 illustrates an update item frame that may be updated using the sequence of Figure 36, according to one embodiment.
[0068] FIG. 48 illustrates an update response frame that may be transmitted as an update response message in the sequence of FIG. 36, according to one embodiment.
[0069] Figure 49 illustrates a communication connection between a transmitter and a receiver in a bulk data transmission, according to one embodiment.
[0070] FIG. 50 illustrates a SendInit message that may be used to initiate a communication connection by the transmitter of FIG. 49, according to one embodiment.
[0071] Figure 51 illustrates the transmission control field of the SendInit message of Figure 50, according to one embodiment.
[0072] Figure 52 illustrates the range control field of the SendInit message of Figure 51, according to one embodiment.
[0073] FIG. 53 illustrates a SendAccept message that may be used to accept a communication connection presented by the SendInit message of FIG. 50 sent by the transmitter of FIG. 50, according to one embodiment.
[0074] FIG. 54 illustrates a SendReject message that may be used to reject a communication connection presented by the SendInit message of FIG. 50 sent by the transmitter of FIG. 50, according to one embodiment.
[0075] FIG. 55 illustrates a ReceiveAccept message that may be used to accept a communication connection presented by the receiver of FIG. 50, according to one embodiment.
[0076] Figure 56 is a block diagram of an example of an IPv6 packet header using an Extended Unique Local Address (EULA), according to one embodiment.
[0077] Figure 57 is a block diagram for an example of communicating an IPv6 packet with the IPv6 packet of Figure 56 over a fabric topology with two networks, according to one embodiment.
[0078] Figure 58 is a flow diagram of a method for efficiently communicating IPv6 packets over the fabric of Figure 57 using the IPv6 packet header of Figure 56, according to one embodiment.
[0079] Figure 59 is a flow diagram of a method for selecting an efficient transport protocol to transmit a message based at least in part on one or more reliability factors, according to one embodiment.
[0080] Figure 60 is a diagram illustrating a use case of a fabric of devices, in which one device calls a method on another device, according to one embodiment.
[0081] FIG. 61 is a diagram illustrating a use case of a fabric of devices in which an alarm message is propagated through multiple low-power sleepy devices, according to one embodiment.
[0082] Figures 62-64 are flow diagrams of a method for introducing a new device to a fabric of devices, according to one embodiment. and
[0083] Figures 65-67 are flow diagrams of another method for introducing a new device to a fabric of devices, according to one embodiment.

[0084] One or more specific embodiments of the present disclosure will be described below. These described embodiments are merely examples of the presently disclosed technologies. Additionally, in order to provide a concise description of these embodiments, not all features of an actual implementation may not be described herein. In the development of any such actual implementation, as in any engineering or design project, a number of implementation-specific decisions are made to achieve the developer's particular objectives while adhering to system-related and business-related constraints that may vary between implementations. You have to recognize that it has to be done for the sake of it. Moreover, it should be appreciated that such a development effort, while complex and time consuming, may nonetheless be a routine undertaking of design, fabrication, and fabrication for those skilled in the art having the benefit of this disclosure.

[0085] When introducing elements of various embodiments of the present disclosure, the singular expression is intended to mean that one or more of the elements are present. The terms “comprising,” “comprising,” and “having” are intended to be inclusive and mean that additional elements may be present other than those listed. Additionally, it should be understood that references to “one embodiment” or “an embodiment” in the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also include the recited features.

[0086] As used herein, the term "HVAC" refers to systems that provide both heating and cooling, heating only, cooling only, as well as other occupant comfort and/or conditioning functions, such as humidification, dehumidification, and ventilation. including systems that

[0087] As used herein, the terms "harvesting," "sharing," and "stealing" when referring to home devices refer directly to a transformer or equipment load without using a common wire source. It refers to drawing power from a power transformer through a load.

[0088] As used herein, the term “thermostat” means a device or system for regulating parameters, such as temperature and/or humidity, within at least one part of an enclosure. The term “thermostat” may include a control unit for a heating and/or cooling system or component part of a heater or air conditioner. As used herein, the term "thermostat" may also refer generically to a VSCU unit (versatile sensing and control unit), which is visually attractive, unobtrusive, elegant to look at, pleasantly easy to use, and at the same time , configured and adapted to provide sophisticated, customizable, energy-saving HVAC control.

[0089] As used herein, the term “hazard detector” is capable of detecting evidence of fire (eg, smoke, heat, carbon monoxide) and/or other hazardous conditions (eg, too high temperatures, accumulation of hazardous gases). Refers to any home device that exists.

[0090] The present disclosure relates to efficient communication that can be used by devices communicating with each other in a home environment. Efficient communication of the present disclosure may enable devices and/or fabric of services to communicate in a home environment. Indeed, consumers residing in homes may find it useful to coordinate the operation of the various devices in their home, so that all of their devices operate efficiently. For example, a thermostat device can be used to detect the temperature of a home and adjust the operation of other devices (eg, lights) based on the detected temperature. The thermostat device can detect the temperature, which can indicate that the temperature outside the home corresponds to the time of day. The thermostat device may then communicate to a light device that there may be daylight available in the home and thus the lights should be turned off. In another example, a smart risk detector may detect environmental conditions indicative of occupancy. The thermostat device can query the hazard detector for these environmental conditions and change its behavior accordingly. In addition to efficiency, consumers may prefer user-friendly devices that generally involve a minimal amount of setup or initialization. That is, consumers may generally prefer devices that work perfectly after performing a few initialization steps, especially devices that can be performed by almost any individual, regardless of age or skill level.

[0091] To efficiently and effectively communicate data with each other within a home environment, devices may use a fabric network that includes one or more logical networks to manage communication between devices. That is, an efficient fabric network can enable various devices within a home to communicate with each other using one or more logical networks. A fabric network may be supported by an efficient communication scheme involving, for example, an efficient network layer, an efficient platform layer, and/or an efficient application layer to manage communications. The fabric network may support Internet Protocol version 6 (IPv6) communication so that each connected device can have a unique local address (ULA). In some examples, IPv6 communications may use an Extended Unique Local Address (EULA). Additionally, to enable each device to integrate with the home, it may be useful for each device to communicate within the network using a small amount of power. That is, by enabling devices to communicate using less power, the devices can be placed anywhere in the home without being coupled to a continuous power source (eg, powered by a battery).

[0092] On a relatively lower layer (eg, network layer) of a communication protocol, an efficient fabric network layer can establish a communication network in which multiple devices in a home can communicate with each other via a wireless mesh network. Since the communications network may support Internet Protocol Version 6 (IPv6) communications, each connected device may have a unique Internet Protocol (IP) address. Additionally, to enable each device to integrate with the home, it may be useful for each device to communicate within the network using a small amount of power. That is, by enabling devices to communicate using less power, devices can be placed anywhere in the home without being coupled to a continuous power source.

[0093] An efficient network layer can thus establish procedures by which data can be passed between two or more devices, so that the establishment of a communication network involves little user input, and communication between devices involves little energy. It does not, and the communication network itself is secure. In one embodiment, an efficient network layer may be an IPv6-based communication network that employs Routing Information Protocol-Next Generation (RIPng) as its routing mechanism and Datagram Transport Layer Security (DTLS) protocol as its security mechanism. As such, an efficient network layer can provide a simple means for adding or removing devices to a home while protecting information communicated between connected devices.

[0094] On relatively higher layers of a communication protocol (eg, platform and/or application layers), a fabric of devices may be created and maintained. These layers may enable fabric-wide status reports and parametric software updates. These layers can also provide communication that can be aware of certain network power constraints, such as power constraints of "sleepy" or battery powered devices, and can communicate messages with these factors in mind. .

[0095] As such, embodiments of the present disclosure are fabric network systems and methods that include one or more logical networks that enable devices connected to a fabric to communicate with each other using a list of protocols and/or profiles known to the devices. It is about. Communications between devices may follow a typical message format that enables devices to understand communications between devices, regardless of which logical networks the communication devices are connected to the fabric. Within the message format, a payload of data may be included in a receiving device for storage and/or processing. The contents and format of the payload may vary depending on a profile (including one or more protocols) and/or a header within the payload indicating the type of message being transmitted according to the profile.

[0096] According to some embodiments, two or more devices in a fabric may communicate using status reporting protocols or profiles. For example, in certain embodiments, a status reporting protocol or schema may be included in a core profile available to devices connected to the fabric. Using a status reporting protocol, devices can send or request status information to or from other devices in the fabric.

[0097] Similarly, in certain embodiments, two or more devices in a fabric may communicate using update software protocols or profiles. In some embodiments, an update software protocol or schema may be included in a core profile available to devices connected to the fabric. Using the update software protocol, devices can request, send or notify the existence of updates within the fabric.

[0098] In certain embodiments, two or more devices in a fabric may communicate using data management protocols or profiles. In some embodiments, a data management protocol or schema may be included in a core profile available to devices connected to the fabric. Using the update data management protocol, devices can request, view or track node-resident information stored on other devices.

[0099] Additionally, in certain embodiments, two or more devices in a fabric may transmit data using bulk data transfer protocols or profiles. In some embodiments, a bulk data transfer protocol or schema may be included in a core profile available to devices connected to the fabric. Using a bulk data transfer protocol, devices can initiate, transmit, or receive bulk data using any logical network in the fabric. In certain embodiments, a sending or receiving device using a bulk data transfer protocol may be able to “drive” a synchronous transfer between devices. In other embodiments, bulk transfer may be performed as an asynchronous transfer.

fabric introduction

[00100] As an introduction, FIG. 1 shows an example of a generic device 10 capable of communicating with other similar devices within a home environment. In one embodiment, device 10 includes one or more sensors 12, a user-interface component 14, a power source 16 (including, for example, a power connection and/or battery), a network interface 18, The processor 20 and the like may be included. Certain sensors 12 , user-interface components 14 , and power supply configurations may be the same as or similar to respective devices 10 . However, note that in some embodiments, each device 10 may include specific sensors 12, user-interface components 14, power supply configurations, etc. based on the device type or model. Should be.

[00101] In a particular embodiment, sensors 12 may include acceleration, temperature, humidity, water, supplied power, proximity, external motion, device motion, sound signals, ultrasonic signals, light signals, fire, smoke, carbon monoxide, GPS It can detect various characteristics such as global-positioning-satellite (global-positioning-satellite) signals, radio-frequency (RF), other electromagnetic signals or fields, and the like. As such, sensors 12 may include temperature sensor(s), humidity sensor(s), hazard-related sensor(s) or other environmental sensor(s), accelerometer(s), microphone(s), camera(s), (eg, charge-coupled devices or video cameras), active or passive radiation sensors, GPS receiver(s) or radio frequency identification detector(s). 1 shows an embodiment using one sensor, many embodiments may include multiple sensors. In some instances, device 10 may include one or more primary sensors and one or more secondary sensors. Here, the primary sensor(s) can sense data central to the core operation of the device (e.g., sensing temperature from a thermostat or sensing smoke from a smoke detector), while secondary sensors The (s) may sense other types of data (eg, motion, light or sound) that may be used for energy-efficient purposes or smart-operating purposes.

[00102] One or more user-interface components 14 within device 10 may receive input from a user and/or provide information to a user. Received input can be used to determine settings. In certain embodiments, user-interface components may include mechanical or virtual components that respond to user movement. For example, a user can mechanically move a sliding component (eg, along a vertical or horizontal track) or mechanically rotate a rotatable ring (eg, along a circular track), or move a user along a touchpad. can be detected. These movements may be based on a setting adjustment that may be determined based on the absolute position of the user-interface component 104 or based on displacement of the user-interface components 104 (e.g., 1 for every 10° rotation of the rotatable ring component). adjusting the set point temperature by °F). User-interface components that are physically and virtually movable can allow a user to configure settings along one part of an explicit continuum. In this way, the user may not be limited to choosing between two distinct options (as if the up and down buttons were used, for example), but may quickly and intuitively define a setting along a range of possible setting values. there is. For example, the magnitude of movement of a user-interface component can be related to the magnitude of adjustment of a setting, so that a user can dramatically change a setting with a large movement or fine-tune a setting with a small movement.

[00103] User-interface components 14 may also include one or more buttons (eg, up and down buttons), a keypad, a number pad, a switch, a microphone, and/or a camera (eg, to detect gestures). In one embodiment, user-interface component 14 rotates the ring (eg, to adjust a setting) and/or clicks the ring inward (eg, to select an adjusted setting or select an option). You can include a click-and-spin circular ring component that allows the user to interact with the component by doing so. In another embodiment, user-interface component 14 may include a camera capable of detecting gestures (eg, to indicate that a device's power or alarm state has changed). In some examples, device 10 may have one primary input component that may be used to set multiple types of settings. User-interface components 14 may also be configured to present information to a user, for example, via a visual display (eg, a thin-film-transistor display or organic light-emitting diode display) and/or an audio speaker.

[00104] The power component 16 may include a power connection and/or a local battery. For example, a power connection may connect device 10 to a power source, such as a wired voltage source. In some examples, an AC power source may be used to repeatedly charge a local (eg, rechargeable) battery, such that the battery may be used later to power device 10 when AC power is not available.

[00105] Network interface 18 may include components that enable device 10 to communicate between devices. In one embodiment, network interface 18 may communicate using an efficient network layer as part of its Open Systems Interconnection (OSI) model. In one embodiment, an efficient network layer, described in more detail below with reference to FIG. 5, may allow device 10 to wirelessly communicate IPv6-type data or traffic using a RIPng routing mechanism and a DTLS security scheme. there is. As such, network interface 18 may include a wireless card or some other transceiver connection.

[00106] Processor 20 may support one or more of a variety of different device functions. As such, processor 20 may include one or more processors configured and programmed to execute and/or cause execution of one or more of the functions described herein. In one embodiment, processor 20 executes computer code stored in local memory (eg, flash memory, hard drive, random access memory), special purpose processors or application specific integrated circuits, combinations thereof, and/or or general purpose processors using other types of hardware/firmware/software processing platforms. Additionally, the processor 20 may execute central servers or cloud-based systems, such as a Java virtual machine (JVM) that executes instructions provided from a cloud server using Asynchronous JavaScript and XML (AJAX) or similar protocols. It can be implemented as localized versions of algorithms that are remotely executed or governed by, or as algorithms that correspond to them. By way of example, processor 20 may determine when a location (eg, house or room) is occupied, including whether it is occupied by a specific number of people or by a specific person (eg, in relation to one or more thresholds). can be detected. In one embodiment, this detection is performed by, for example, analyzing microphone signals, detecting user movements (eg, in front of the device), detecting opening and closing of doors or garage doors, detecting wireless signals. , detecting the IP address of a received signal, detecting the operation of one or more devices within a time window, and the like. Additionally, processor 20 may include image recognition technology to identify specific occupants or objects.

[00107] In certain embodiments, processor 20 may also include a high power processor and a low power processor. A high power processor may execute computationally intensive operations, such as operating user interface components 14 and the like. On the other hand, a low-power processor may manage less complex processes, such as detecting a hazard or temperature from sensor 12. In one embodiment, a low power processor may wake or initialize a high power processor for computationally intensive processes.

[00108] In some examples, processor 20 may anticipate and/or implement desirable settings. For example, based on presence detection, processor 20 may, for example, save power when no one is at home or in a particular room, or set user preferences (eg, general home preferences or user-specific preferences). You can adjust the device settings to suit your needs. As another example, based on detection of a particular person, animal or object (eg, a child, pet or lost item), the processor 20 may initiate an audible or visual indicator of where the person, animal or object is located, or Or it may initiate an alarm or security feature if an unauthorized person is detected under certain conditions (eg at night or when the lights are off).

[00109] In some examples, the devices can interact with each other so that an event detected by the first device affects the operations of the second device. For example, the first device may detect that the user has entered the garage (by detecting movement in the garage, detecting a change in lighting in the garage, or detecting an open garage door). The first device can transmit this information through an efficient network layer to the second device, whereby the second device can, for example, adjust home temperature settings, light settings, music settings, and/or security-alarm settings. As another example, the first device can detect a user approaching the front door (eg, by detection of motion or sudden light pattern changes). The first device may, for example, cause a general audible or visual signal to be provided (eg, the sound of a doorbell) or a location-specific audible or visual signal (eg, announcing the presence of a visitor to a room occupied by the user). A signal can be provided.

[00110] As an example, device 10 may include a thermostat such as a Nest® Learning Thermostat. Here, the thermostat can include sensors 12, such as temperature sensors, humidity sensors, etc., so that the thermostat can determine current climate conditions within the building in which it is placed. Since the power component 16 for the thermostat can be a local battery, the thermostat can be placed anywhere in the building without considering being located very close to a continuous power source. Because the thermostat is powered using a local battery, the thermostat can minimize its energy use, so the battery is rarely replaced.

[00111] In one embodiment, the thermostat may include a circular track that may have a rotatable ring disposed thereon as user-interface component 14 . In this way, the user can interact with or program the thermostat using the rotatable ring, so that the thermostat can control heating, ventilation, and air-conditioning (HVAC) units, etc. By controlling the temperature of the building. In some examples, a thermostat can determine when a building can be emptied based on its programming. For example, if a thermostat can be programmed to keep an HVAC unit powered off for an extended period of time, the thermostat can determine that the building will be empty during this period of time. Here, the thermostat can be programmed to turn off light switches or other electronic devices upon determining that the building is unoccupied. As such, the thermostat can use the network interface 18 to communicate with the light switch device, so the thermostat can send a signal to the light switch device if it determines that the building is vacant. In this way, the thermostat can efficiently manage a building's energy use.

[00112] With the foregoing in mind, FIG. 2 shows a block diagram of a home environment 30 in which device 10 of FIG. 1 can communicate with other devices via an efficient network layer. The illustrated home environment 30 may include a structure 32 such as a house, office building, garage, or mobile home. It will be appreciated that the devices may also be integrated into a home environment that does not include the entire structure 32, such as an apartment, condo, office space, or the like. Additionally, home environment 30 may control and/or couple to devices external to actual structure 32 . In fact, some of the devices in home environment 30 need not be physically inside structure 32 at all. For example, a device controlling pool heater 34 or irrigation system 36 may be located outside structure 32 .

[00113] The structure 32 shown includes a number of rooms 38 that are at least partially separated from each other by walls 40 . Walls 40 may include interior walls or exterior walls. Each room 38 may further include a floor 42 and a ceiling 44 . Devices may be mounted, integrated and/or supported on wall 40 , floor 42 , or ceiling 44 .

[00114] Home environment 30 includes a plurality of devices, including intelligent, multi-sensing, networked devices, that can seamlessly integrate with each other and/or with cloud-based server systems to provide any of a variety of useful home purposes. can include One, two or more or each of the devices shown in home environment 30 may include one or more sensors 12, user interface 14, power source 16, network interface 18, processor 20, etc. can

[00115] Exemplary devices 10 may include a network connected thermostat 46 such as the Nest® Learning Thermostat-Gen 1 T100577 or the Nest® Learning Thermostat-Gen 2 T200577 by Nest Labs, Inc. Thermostat 46 may detect ambient climate characteristics (eg, temperature and/or humidity) and control heating, ventilation, and air-conditioning (HVAC) system 48 . Another exemplary device 10 may include a hazard detection unit 50, such as a hazard detection unit by Nest®. Hazard detection unit 50 may detect the presence of hazardous objects and/or hazardous conditions (eg, smoke, fire, or carbon monoxide) within home environment 30 . Additionally, entrance interface devices 52, which may be referred to as "smart doorbells," detect a person approaching or leaving a location, control an audible function, and make an audible or visual The means may signal the approach or departure of a person, or control settings on the security system (eg, activating or deactivating the security system).

[00116] In certain embodiments, device 10 includes a light switch 54 that can detect ambient lighting conditions, detect room-occupancy conditions, and control the power and/or dim condition of one or more lights. can include In some examples, light switches 54 may control the power state or speed of a fan, such as a ceiling fan.

[00117] Additionally, wall plug interface 56 may detect occupancy of a room or enclosure (eg, so that plugs are not powered when no one is in the home) and may control power supply to one or more wall plugs. Device 10 in home environment 30 may include appliances 58, such as refrigerators, stoves and/or ovens, televisions, washing machines, dryers, (within structure 32 and/or external) lights, stereos, intercom systems, garage door openers, floor fans, ceiling fans, whole home fans, wall air conditioners, pool heaters (34), irrigation systems (36), security systems and the like. Although the descriptions of FIG. 2 may identify specific sensors and functionalities associated with specific devices, it should be noted that any of a variety of sensors and functionalities (as described throughout the specification) may be incorporated into device 10. will recognize

[00118] In addition to including processing and sensing capabilities, each of the example devices described above enables data communications and information sharing with any other device and with any other device networked to any cloud server or anywhere in the world. can do. In one embodiment, devices 10 may transmit and receive communications over an efficient network layer as will be described below with reference to FIG. 5 . In one embodiment, an efficient network layer may allow devices 10 to communicate with each other over a wireless mesh network. As such, certain devices can act as wireless repeaters and/or function as bridges between devices in a home environment that may not be directly connected to each other (ie, with one hop).

[00119] In one embodiment, wireless router 60 may further communicate with devices 10 in home environment 30 via a wireless mesh network. The wireless router 60 can then communicate with the Internet 62 so that each device 10 can communicate with a central server or cloud-computing system 64 via the Internet 62 . A central server or cloud-computing system 64 may be associated with a manufacturer, support entity, or service provider associated with a particular device 10 . Thus, in one embodiment, a user may use the device itself to access customer support rather than using some other means of communication, such as a phone or Internet-connected computer. Additionally, software updates may be automatically sent to devices from a central server or cloud-computing system 64 (eg, when available, purchased, or at regular intervals).

[00120] With a network connection, one or more of the devices 10 may further enable a user to interact with the device even when the user is not in close proximity to the device. For example, a user may use a computer (eg, desktop computer, laptop computer, or tablet) or other portable electronic device (eg, smart phone) 66 to communicate with the device. The webpage or application may receive communication from the user and control the device 10 based on the received communications. In addition, the web page or application may provide information about the operation of the device to the user. For example, a user may view the current set point temperature for the device and adjust this temperature using a computer that may be connected to the internet 62 . In this example, thermostat 46 may receive a current set point temperature view request over a wireless mesh network created using an efficient network layer.

[00121] In a particular embodiment, the home environment 30 may also be controlled (on/off), albeit coarse, by the wall plug interfaces 56, such as older conventional washers/dryers, refrigerators, etc. It may include communicative legacy appliances 68 . The home environment 30 is infrared (infrared), which may be controlled by IR signals provided by various partially communicative legacy appliances 70, such as hazard detection units 50 or light switches 54. IR) controlled wall air conditioners or other IR-controlled devices.

[00122] As noted above, each of the exemplary devices 10 described above may establish a wireless mesh network so that data may be communicated to each device 10 . With the example device of FIG. 2 in mind, FIG. 3 depicts an example wireless mesh network 80 that may be used to facilitate communication between some of the example devices described above. As shown in FIG. 3 , the thermostat 46 may have a direct wireless connection to the hazard detection unit 50 and to a plug interface 56 that may be wirelessly connected to the light switch 54 . In the same manner, light switch 54 can be wirelessly coupled to appliance 58 and portable electronic device 66 . Appliance 58 may only be coupled to pool heater 34 and portable electronic device 66 may only be coupled to irrigation system 36 . Irrigation system 36 may have a wireless connection to gateway interface device 52 . Each device in the wireless mesh network 80 of FIG. 3 may correspond to a node within the wireless mesh network 80 . In one embodiment, an efficient network layer can specify that each node sends data using the RIPng protocol and the DTLS protocol, so that data can be safely transmitted to the destination node over a minimum number of hops between nodes.

[00123] In general, an efficient network layer may be part of an Open Systems Interconnection (OSI) model 90 as shown in FIG. 4 . The OSI model 90 depicts the functions of a communication system to abstraction layers. That is, the OSI model may specify a networking framework or how communications may be implemented between devices. In one implementation, the OSI model includes six layers: physical layer 92, data link layer 94, network layer 96, transport layer 98, platform layer 100 and application layer 102. can do. In general, each layer of the OSI model 90 may be served by a layer above that respective layer, and may be served by a layer below the respective layer. In at least some embodiments, a higher layer may be agnostic to the technologies used in the lower layer. For example, in certain embodiments, platform layer 100 may be agnostic to the type of network used in network layer 96.

[00124] With this in mind, the physical layer 92 can provide hardware specifications to devices that can communicate with each other. As such, the physical layer 92 can establish how devices can connect to each other, support management of how communication resources can be shared between devices, and so forth.

[00125] The data link layer 94 can specify the amount of data that can be transferred between devices. In general, the data link layer 94 may provide a way for data packets being transmitted to be encoded and decoded into bits as part of a transmission protocol.

[00126] The network layer 96 may specify how data sent to the destination node is to be routed. Network layer 96 may also provide security protocols by which the integrity of transmitted data may be maintained.

[00127] The transport layer 98 may specify transparent transport of data from a source node to a destination node. The transport layer 98 may also control how the transparent transfer of data remains reliable. As such, the transport layer 98 can be used to ensure that data packets intended for transmission to the destination node do indeed arrive at the destination node. Example protocols that may be used for transport layer 98 may include Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

[00128] The platform layer 100 may establish connections between devices according to a protocol specified inside the transport layer 98. Platform layer 100 may also convert data packets into a form usable by application layer 102 . Application layer 102 may support software applications that may directly interface with a user. As such, the application layer 102 may implement protocols defined by the software application. For example, a software application may provide services such as file transfer, e-mail, and the like.

efficient network layer

[00129] Referring now to FIG. 5 , in one embodiment, the network layer 96 and transport layer 98 may be configured in a specific way to form an efficient low power wireless personal network (ELoWPAN) 110 . In one embodiment, ELoWPAN 110 may be based on an IEEE 802.15.4 network, which may correspond to low-rate wireless personal area networks (LR-WPANs). ELoWPAN 110 may specify that network layer 96 may route data between devices 10 in home environment 30 using a communication protocol based on Internet Protocol Version 6 (IPv6). As such, each device 10 has a 128-bit IPv6 protocol that provides each device 10 with a unique address to use to identify itself over the Internet, local network, etc. around the home environment 30. It may contain an address.

[00130] In one embodiment, network layer 96 may specify that data may be routed between devices using Routing Information Protocol-Next Generation (RIPng). RIPng is a routing protocol that routes data through a wireless mesh network based on a number of hops between a source node and a destination node. That is, RIPng can determine a route from a source node to a destination node that uses the least number of hops when determining how data will be routed. In addition to supporting transport of data over a wireless mesh network, RIPng can support IPv6 networking traffic. As such, each device 10 may use a unique IPv6 address for identifying itself and a unique IPv6 address for identifying a destination node when routing data. Additional details regarding how RIPng can transfer data between nodes will be described below with reference to FIG. 6 .

[00131] As mentioned above, the network layer 96 may also provide security protocols that may manage the integrity of data being transmitted. Here, an efficient network layer can protect data transmitted between devices using a Datagram Transport Layer Security (DTLS) protocol. In general, the Transport Layer Security (TLS) protocol is commonly used to secure data transmissions over the Internet. However, in order for the TLS protocol to be efficient, the TLS protocol can use a reliable transport channel such as Transmission Control Protocol (TCP) to transmit data. DTLS supports unreliable transport channels such as User Datagram Protocol (UDP) while providing a similar level of security for transmitted data. Additional details regarding the DTLS protocol will be described below with reference to FIGS. 8 and 9 .

[00132] The network layer 96 shown in FIG. 5 features the efficient network layer referred to herein above. That is, the efficient network layer routes IPv6 data using RIPng and protects the routed data using the DTLS protocol. Since the efficient network layer uses the DTLS protocol to secure data transmission between devices, the transport layer 98 can support TCP and UDP transport schemes for data.

[00133] Referring now to FIG. 6 , FIG. 6 illustrates a flow diagram of a method 120 that may be used to determine a routing table for each device 10 of the wireless mesh network 80 of FIG. 3 using RIPng. do. Method 120 may be performed by each device 10 in home environment 30 so that each device 10 represents how each node in wireless mesh network 80 may be connected to each other. You can create a routing table. As such, each device 10 can independently determine how to route data to a destination node. In one embodiment, processor 20 of device 10 may perform method 120 using network interface 18 . As such, device 10 may transmit data associated with sensor 12 or determined by processor 18 to other devices 10 in home environment 30 via network interface 18 . .

[00134] The following discussion of method 120 will be described with reference to FIGS. 7A-7D to clearly illustrate the various blocks of method 120 . With this in mind and referring to both FIGS. 6 and 7A , at block 122 , device 10 may send a request 132 to any other device 10 , which requests device 10 to may be direct (i.e. zero hop). Request 132 may include a request for all routing information from an individual device 10 . For example, referring to FIG. 7A , device 10 of node 1 sends a request 132 to device 10 of node 2 to retrieve all routes contained in node 2's memory (i.e., routes of N2). can transmit

[00135] At block 124, the requesting device 10 may receive a message from each device 10, which may include all of the routes contained in each memory of each device 10. Routes may be organized in a routing table that may specify how each node of the wireless mesh network 80 may be connected to each other. That is, the routing table may designate intermediate nodes through which data may be transmitted from a source node through which data is transmitted to a destination node. Referring back to the above example and to FIG. 7B , in response to node 1's request for routes in N2, at block 124, node 2 returns all routes contained in node 2's memory or storage (routes in N2). (144)) to node 1. In one embodiment, each node of wireless mesh network 80 may send a request 132 to its neighboring node as shown in FIG. 7A. In response, each node may then forward its routes to its neighbor node as shown in FIG. 7B. For example, FIG. 7B shows that each node has routes 142 of N1, routes 144 of N2, routes 146 of N3, routes 148 of N4, and routes 150 of N5. , routes 152 in N6, routes 154 in N7, routes 156 in N8, and routes 158 in N9 forwarding its route data to each neighboring node. shows

[00136] Initially, each node knows which nodes it can directly connect to (i.e., zero hops). For example, initially, node 2 can only know how to connect directly to node 1, node 3 and node 4. However, after receiving routes 142 of N1, routes 146 of N3, and routes 148 of N4, processor 20 of node 2 determines routes 142 of N1, routes 142 of N3 146, and all of the information included with routes 148 in N4. Thus, the next time node 2 receives a request for its routes or routing table (i.e., routes 144 of N2), node 2 receives routes 142 of N1, routes 142 of N2, routes 144 of N2, and N2. A routing table including routes 146 of N4 and routes 148 of N4 may be transmitted.

[00137] With this in mind and referring back to FIG. 6 , at block 126 the requesting device 10 may update its local routing table to include the routing information received from the neighboring device 10 . In particular embodiments, each device 10 may perform method 120 periodically, such that each device 10 features a method in which each node in wireless mesh network 80 may be connected to each other. Contains an updated routing table with . As noted above, each time method 120 is performed, each device 10 determines whether or not its neighbor device 10 has updated its routing table with information received from its neighbor devices 10. ) to receive additional information. As a result, each device 10 can understand how each node in the wireless mesh network 80 can be connected to each other.

[00138] 7C shows a routing table 172 that may have been determined by device 10 at node 1 using, for example, method 120 . In this example, routing table 172 may designate each node in wireless mesh network 80 as a destination node, intermediate nodes between node 1 and each destination node, and the number of hops between node 1 and destination node. there is. The number of hops corresponds to the number of times data sent to a destination node can be forwarded to an intermediate node before reaching the destination node. When sending data to a particular destination node, the RIPng routing scheme can choose a route involving the least number of hops. For example, if node 1 intends to send data to node 9, the RIPng routing scheme would be as opposed to routing the data via nodes 2, 4, 6, 7 and 8 involving 5 hops. will route the data through nodes 2, 4, 5, and 8 involving four hops.

[00139] By using the RIPng routing scheme, each device 10 can independently determine how data will be routed to the destination node. On the other hand, conventional routing schemes such as the "Ripple" Routing Protocol (RPL) used in 6LoWPAN devices can route data through a central node, which may be the only node that knows the structure of the wireless mesh network. More specifically, the RPL protocol can create a wireless mesh network according to a directed acyclic graph (DAG) that can be structured hierarchically. Located at the top, this layer may include a border router that can periodically multicast requests to lower level nodes to determine the rank for each of the node's connections. Essentially, when data is transferred from a source node to a destination node, the data can be transferred up the hierarchy of nodes and then down again to the destination node. In this way, nodes located in higher tiers may route data more frequently than nodes located in lower tiers. Moreover, border routers in RPL systems can also operate more frequently because they control how data is routed through the layers. In a conventional RPL system, in contrast to the RIPng system taught herein, some nodes route data more frequently simply based on their position in the hierarchy rather than due to their position relative to the source and destination nodes. can do. Those nodes that route data more frequently under the RPL system may consume more energy and thus may not be suitable for implementation with devices 10 in a home environment 30 that operate using low power. Moreover, as noted above, if a border router or any other high-level node in the RPL system corresponds to thermostat 46, the increased data routing activity increases the heat generated inside thermostat 46. can make it As a result, the temperature reading of thermostat 46 may inaccurately represent the temperature of home environment 30 . Because other devices 10 may perform certain actions based on temperature readings of thermostat 46, and thermostat 46 commands various devices 10 based on its temperature readings. It may be advantageous to ensure that the temperature reading of thermostat 46 is accurate.

[00140] In addition to ensuring that none of the devices 10 route data in a disproportionate amount of time, by using the RIPng routing scheme, new devices 10 can connect to the wireless mesh with minimal effort by the user. can be added to the network. For example, FIG. 7D shows the addition of a new node 10 to the wireless mesh network 80. In certain embodiments, once node 10 establishes a connection to wireless mesh network 80 (e.g., via node 4), device 10 corresponding to node 10, respectively, in wireless mesh network 80 Method 120 described above may be performed to determine how data may be routed to the nodes of . If each node of the wireless mesh network 80 has already performed method 120 multiple times, the device 10 at node 10 receives the entire routing structure of the wireless mesh network 80 from the device 10 at node 4. can do. In the same way, devices 10 can be removed from wireless mesh network 80 and each node can update its routing table with relative ease by performing method 120 again.

[00141] After establishing a routing scheme using the RIPng routing scheme, the ELoWPAN 110 may use the DTLS protocol to protect data communications between each device 10 in the home environment 30 . As noted above, by using the DTLS protocol instead of the TLS protocol, ELoWPAN 110 may enable transport layer 98 to transmit data over TCP and UDP. Although UDP may be generally less reliable than TCP, UDP data transmissions use a simple communication scheme without dedicated transmission channels or data paths being set up prior to use. This allows new devices 10 added to the wireless mesh network 80 to use UDP data transmissions to efficiently communicate to other devices 10 in the wireless mesh network more quickly. Moreover, UDP data transmissions generally use less energy by the device 10 that is sending or forwarding the data because there is no guarantee of delivery. As such, devices 10 can transmit non-critical data (eg, presence of a person in a room) using UDP data transmission, thereby conserving energy within device 10 . However, critical data (eg, smoke alarms) may be sent over TCP data transport to ensure that the appropriate party receives the data. To reiterate, using the DTLS security scheme over ELoWPAN 110 can help UDP and TCP data transmissions seamlessly.

[00142] With the foregoing in mind, ELoWPAN 110 may use the DTLS protocol to ensure that data is communicated between devices 10 . In one embodiment, the DTLS protocol can guarantee data transfers using a handshake protocol. In general, the handshake protocol may authenticate each communication device using a security credential that may be provided by each device 10 . 8 depicts an example manufacturing process 190 illustrating how security credentials may be embedded within device 10 .

[00143] Referring to FIG. 8 , a trusted manufacturer 192 of device 10 may be provided with a number of security credentials that may be used for each manufactured device. As such, during manufacture of a device 10 that may be used in a home environment 30 and coupled to a wireless mesh network 80, a trusted manufacturer 192 may provide certificates 194 to the device during the manufacturing process 190. (10) can be embedded. That is, certificate 194 may be embedded into the hardware of device 10 during manufacture of device 10 . Credentials 194 may include public keys, private keys, or other cryptographic data that may be used to authenticate different communication devices within wireless mesh network 80 . As a result, once the user receives the device 10, the user can integrate the device 10 into the wireless mesh network 80 without initializing the device 10 or registering it with a central secure node or the like.

[00144] In conventional data communication security protocols such as PANA (Protocol for Carrying Authentication for Network Access) used in 6LoWPAN devices, each device 10 can authenticate itself using a specific node (ie, authentication agent). can As such, before data is transferred between any two devices 10, each device 10 can authenticate itself using an authentication agent node. The authentication agent node may then forward the result of the authentication to an enforcement point node (which may be co-located with the authentication agent node). The reinforcement point node may then establish a data communication link between the two devices 10 if the authentications are valid. Furthermore, in PANA, each device 10 can communicate with each other via an enforcement point node that can verify that authentication for each device 10 is valid.

[00145] Thus, by using the DTLS protocol rather than PANA to ensure data transfers between nodes, an efficient network layer can avoid over-utilizing an authentication agent node, an reinforcement point node, or both. That is, no node using an efficient network layer can process authentication data for each data transfer between nodes in a wireless mesh network. As a result, nodes using an efficient network layer can save more energy than authentication agent nodes or reinforcement point nodes in the PANA protocol system.

[00146] With this in mind, FIG. 9 depicts an exemplary handshake protocol 200 that may be used between devices 10 when transferring data between the devices. As shown in FIG. 9 , device 10 at node 1 can send message 202 to device 10 at node 2 . Message 202 may be a hello message that may include cipher suites, hash and compression algorithms, and a random number. Device 10 at node 2 may then respond with message 204 confirming that device 10 at node 2 received message 202 from device 10 at node 1 .

[00147] After establishing a connection between node 1 and node 2, the device at node 1 may again send message 202 to device 10 at node 2. Device 10 of node 2 then sends message 208, which may include a hello message from node 2, a certificate 194 from node 2, a key exchange from node 2, and a certificate request for node 1. can respond The hello message of message 208 may include cryptographic suites, hash and compression algorithms, and a random number. Certificate 194 may be a security certificate embedded inside device 10 by trusted manufacturer 192 as described above with reference to FIG. 8 . A key exchange may include a public key, private key, or other cryptographic information that may be used to determine a secret key to establish a communication channel between two nodes. In one embodiment, the key exchange may be stored in the certificate 194 of the corresponding device 10 located at separate nodes.

[00148] In response to message 208, device 10 at node 1 will include certificate 194 from node 1, key exchange from node 1, verification of node 2's certificate, and change cipher specification from node 1. A message 210 may be transmitted. In one embodiment, node 1's device 10 can use node 2's certificate 194 and a key exchange from node 1 to verify node 2's certificate 194. That is, the device 10 of node 1 can verify that the certificate 194 received from node 2 is valid based on the key exchange from node 1 with the certificate 194 of node 2. If the certificate 194 from node 2 is valid, node 1's device 10 can send a change cipher specification message to node 2's device 10 to indicate that the communication channel between the two nodes is secure.

[00149] Similarly, upon receipt of message 210, device 10 at node 2 can verify node 1's certificate 194 using node 1's certificate 194 and a key exchange from node 2. That is, device 10 of node 2 can verify that the certificate 194 received from node 1 is valid based on the key exchange from node 2 with node 1's certificate 194 . If the certificate 194 from node 1 is valid, the device 10 at node 2 may also send a change cipher specification message to the device 10 at node 1 to indicate that the communication channel between the two nodes is secure. .

[00150] After establishing that the communication channel is secure, the device 10 at node 1 may transmit the group-specific network key 214 to the device 10 at node 2. A group-level network key 214 may be associated with ELoWPAN 110 . In this way, as new devices join ELoWPAN 110 , devices that have been previously authenticated to communicate inside ELoWPAN 110 can provide new device accesses to ELoWPAN 110 . That is, devices that have been pre-authorized to communicate within ELoWPAN 110 can provide a group-wide network key 214 to new devices, which allows the new devices to communicate with other devices within ELoWPAN 110. can make it possible For example, the per-group network key 214 can be used for communication with other devices that have been properly authenticated and have been previously provided with the per-group network key 214 . In one embodiment, once the Change Encryption Specification message has been exchanged between the device 10 of Node 1 and the device 10 of Node 2, identification information such as model number, device capabilities, etc. may be communicated between the devices. . However, after the device 10 of node 2 receives the group unit network key 214, additional information such as data from sensors disposed on the device 10, data analysis performed by the device 10, and the like can be communicated between devices.

[00151] By embedding a security credential inside device 10 during the manufacturing process, device 10 may not be associated with users by establishing security or authentication processes for device 10 . Furthermore, security of data transmissions in the wireless mesh network 80 is ensured, since the device 10 can ensure that data is securely transmitted between nodes based on the handshake protocol as opposed to a central authentication agent node. may not depend on one node for security. Instead, an efficient network layer can ensure that data can be safely transferred between nodes even when some nodes are unavailable. As such, an efficient network layer may be much less vulnerable to security problems since it does not rely on a single node to secure data messages.

Efficient Platform and/or Application Layers

[00152] Using the ELowPAN 110 described above and/or any other suitable IPv6 logical networks, efficient platform and/or application layers can be used to create a fabric of devices in a home environment or similar environments. A fabric of devices typically allows many local devices to communicate, share data and information, call methods on each other, provide software updates parametrically over a network, and are generally efficient and power-aware. You can communicate messages in a power-conscious way.

Fabric-to-device interconnection

[00153] As discussed above, a fabric may be implemented using one or more suitable communication protocols, such as IPv6 protocols. In practice, a fabric may be partially or completely agnostic to the underlying technologies (eg, network types or communication protocols) used to implement the fabric. Within one or more communication protocols, a fabric may be implemented using one or more types used to communicatively couple electrical devices using wireless or wired connections. For example, certain embodiments of the fabric may include Ethernet, WiFi, 802.15.4, ZigBee®, ISA100.11a, WirelessHART, MiWi ^™ , power-line networks, and/or other suitable network types. Within the fabric devices (eg nodes) can exchange packets of information either directly or through intermediary nodes with other devices (eg nodes) in the fabric, such as intelligent thermostats acting as IP routers. These nodes may include manufacturer devices (eg, thermostats and smoke detectors) and/or customer devices (eg, phones, tablets, computers, etc.). Additionally, some devices may be “always on” and continuously powered using electrical connections. Other devices may have partially reduced power usage (eg, medium duty cycle) using a reduced/intermittent power connection, such as a thermostat or doorbell power connection. Finally, some devices may have short duty cycles and operate exclusively on battery power. In other words, in certain embodiments, a fabric may include heterogeneous devices that may be connected to one or more sub-networks depending on the type of connection and/or desired power usage. 10-12 illustrate three embodiments that a fabric may be used to connect electrical devices through one or more sub-networks.

A. single network topology

[00154] 10 illustrates an embodiment of a fabric 1000 with a single network topology. As illustrated, fabric 1000 includes a single logical network 1002 . Network 1002 may include Ethernet, WiFi, 802.15.4, power-line networks, and/or other suitable network types of IPv6 protocols. Indeed, in some embodiments where network 1002 comprises a WiFi or Ethernet network, network 1002 may span multiple WiFi and/or Ethernet segments bridged at the link layer.

[00155] Network 1002 includes one or more nodes 1004, 1006, 1008, 1010, 1012, 1014, and 1016, collectively referred to as 1004-1016. Although illustrated network 1002 includes seven nodes, certain embodiments of network 1002 may include one or more nodes interconnected using network 1002 . Additionally, if network 1002 is a WiFi network, each of nodes 1004-1016 may be interconnected using node 1016 (eg, a WiFi router) and/or WiFi Direct (ie, WiFi P2P). ) can be used to pair with other nodes.

B. Radial Network Topology

[00156] FIG. 11 illustrates an alternative embodiment of fabric 1000 as fabric 1018 with a radial network topology. Fabric 1018 includes a hub network 1020 that joins two peripheral networks 1022 and 1024 together. Hub network 1020 may include a home network such as a WiFi/Ethernet network or a power line network. Peripheral networks 1022 and 1024 may be different additional network connection types of different types than hub network 1020 . For example, in some embodiments, hub network 1020 can be a WiFi/Ethernet network, perimeter network 1022 can include an 802.15.4 network, and perimeter network 1024 can be a power line network, ZigBee®. network, ISA100.11a network, WirelessHART network, or MiWi ^TM network. Moreover, although the illustrated embodiment of fabric 1018 includes three networks, particular embodiments of fabric 1018 may include any number of networks, such as 2, 3, 4, 5, or more networks. can Indeed, some embodiments of fabric 1018 include multiple perimeter networks of the same type.

[00157] Although the illustrated fabric 1018 includes 14 nodes, each individually referred to by reference numbers 1024-1052, it should be understood that the fabric 1018 may include any number of nodes. do. Communication within each network 1020, 1022, or 1024 may occur directly between devices and/or via an access point such as node 1042 of a WiFi/Ethernet network. Communications between peripheral networks 1022 and 1024 pass through hub network 1020 using inter-network routing nodes. For example, in the illustrated embodiment, nodes 1034 and 1036 use a first type of network connection (eg, 802.15.4) to the peripheral network 1022 and use a second type of network connection (eg, WiFi). Node 1044 connects to hub network 1020 using a second network connection type and to peripheral network 1024 using a third network connection type (e.g., power line). do. For example, a message sent from node 1026 to node 1052 may pass through nodes 1028, 1030, 1032, 1036, 1042, 1044, 1048, and 1050 to node 1052 in transit.

C. Overlapping Network Topology

[00158] 12 illustrates an alternative embodiment of fabric 1000 as fabric 1054 with an overlapping network topology. Fabric 1054 includes networks 1056 and 1058 . As illustrated, each of nodes 1062, 1064, 1066, 1068, 1070, and 1072 may be coupled to a respective one of a network. In other embodiments, node 1072 may include an access point to an Ethernet/WiFi network rather than an endpoint, and neither may be on network 1056 or network 1058 that is not an Ethernet/WiFi network. there is. Thus, communication from node 1062 to node 1068 may pass through network 1056, network 1058, or some combination thereof. In the illustrated embodiment, each node can communicate with any other node over any network using any desired network. Thus, unlike the radial network topology of FIG. 11, the overlapping network topology can communicate directly between nodes over any network without using inter-network routing.

D. Fabric network connectivity to services

[00159] In addition to communications between devices within a home, a fabric (eg, fabric 1000) may include services that may be located physically close to or physically remote from other devices in the fabric. A fabric connects to these services through one or more service end points. 13 illustrates an embodiment of a service 1074 communicating with fabrics 1076, 1078 and 1080. It should be appreciated that service 1074 may include a variety of services that may be used by devices within fabrics 1076 , 1078 and/or 1080 . For example, in some embodiments, service 1074 may be a time service to supply time to devices, a weather service to provide various weather data (eg, outside temperature, sunset, wind information, weather forecast, etc.), respectively. It may be an echo service that “pings” the device, data management services, device management services, and/or other suitable services. As illustrated, a service 1074 is a server 1082 (which stores/accesses relevant data and communicates information to one or more endpoints 1086 via a service endpoint 1084 into a fabric, such as fabric 1076). For example, a web server). Although the illustrated embodiment includes only three fabrics with a single server 1082, a service 1074 can be connected to any number of fabrics and connections to server 1082 and/or additional services. In addition, it should be appreciated that it may include servers.

[00160] In certain embodiments, service 1074 may also couple to consumer device 1088, such as a phone, tablet, and/or computer. Consumer device 1088 can be used to connect to service 1074 via a fabric such as fabric 1076, an Internet connection, and/or some other suitable connection method. Consumer device 1088 can be used to access data from one or more end points (eg, electronic devices) to the fabric directly through fabric or service 1074 . In other words, using service 1074, consumer device 1088 can be used to access/manage devices in a fabric remote from the fabric.

E. Communication between devices in the fabric

[00161] As discussed above, each electronic device or node may communicate directly or indirectly with any other node in the fabric depending on the fabric topology and network connection types. Additionally, some devices (eg, remote devices) may communicate via a service to communicate with other devices in the fabric. 14 illustrates an embodiment of communication 1090 between two devices 1092 and 1094 . Communication 1090 may span one or more networks, either directly or indirectly through additional devices and/or services, as described above. Additionally, communication 1090 may occur over a suitable communication protocol, such as IPv6, using one or more transport protocols. For example, in some embodiments communication 1090 may include using transmission control protocol (TCP) and/or user datagram protocol (UDP). In some embodiments, device 1092 can transmit first signal 1096 to device 1094 using a connectionless protocol (eg, UDP). In certain embodiments, device 1092 can communicate with device 1094 using a connection-oriented protocol (eg, TCP). Although illustrated communication 1090 is depicted as a two-way connection, in some embodiments communication 1090 may be a single-way broadcast.

i. Unique Local Address (ULA)

[00162] As discussed above, data transmitted within the fabric received by a node may be redirected or forwarded through the node to another node depending on the target desired for communication. In some embodiments, transmission of data may be intended to be broadcast to all devices. In such embodiments, data may be retransmitted without further processing to determine if the data should be forwarded to another node. However, some data may be directed to specific endpoints. Nodes may be assigned identification information to allow addressed messages to be sent to desired endpoints.

[00163] Each node may be assigned a set of link-local addresses (LLAs), one assigned to each network interface. These LLAs can be used to communicate with other nodes on the same network. Additionally, LLAs can be used for various communication procedures such as the IPv6 Neighbor Discovery Protocol. In addition to LLAs, each node may be assigned a unique local address (ULA). In some embodiments, this may be referred to as an Extended Unique Local Address (EULA), as it contains information about the device's fabric as well as the preferred network to reach the device over the fabric.

[00164] 15 illustrates an embodiment of a unique local address (ULA) 1098 that can be used to address each node in a fabric. In certain embodiments, the ULA 1098 may be formatted as an IPv6 address format that includes 128 bits divided into a global ID 1100, a subnet ID 1102, and an interface ID 1104. Global ID 1100 contains 40 bits and subnet ID 1102 contains 16 bits. The global ID 1100 and subnet ID 1102 together form the fabric ID 1103 for the fabric.

[00165] Fabric ID 1103 is a unique 64-bit identifier used to identify a fabric. Fabric ID 1103 may be generated upon creation of the associated fabric using a pseudo-random algorithm. For example, a pseudo-random algorithm can 1) get the current time in 64-bit NTP format, 2) get the interface ID 1104 for the device, 3) get the interface ID 1104 and can associate the time of day, 4) compute the SHA-1 digest for the key resulting in 160 bits, 5) use the least significant 40 bits as the global ID 1100, and 6) fabric ID 1103 You can associate a ULA and set the least significant bit to 1 to generate . In certain embodiments, once fabric ID 1103 is created with a fabric, fabric ID 1103 remains until the fabric is detached.

[00166] Global ID 1100 identifies the fabric to which the node belongs. Subnet ID 1102 identifies logical networks within the fabric. Subnet ID F3 can be monotonously assigned starting with 1 with each new logical network addition to the fabric. For example, a WiFi network can be identified by a hexadecimal value of 0x01, and a later connected 802.15.4 network can be identified by a hexadecimal value of 0x02, which continues to increment with each new network connection to the fabric.

[00167] Finally, ULA 1098 includes Interface ID 1104, which contains 64 bits. Interface (ID) 1104 may be assigned using a globally-unique 64-bit identifier according to the IEEE EUI-64 standard. For example, devices with IEEE 802 network interfaces may use the burned-in MAC address for the devices "primary interface" to derive the interface ID 1104. In some embodiments, the design in which the interface is the primary interface may be arbitrarily determined. In other embodiments, an interface type (eg, WiFi) may be considered a primary interface when present. The MAC address for the device's primary interface is 48 bits rather than 64 bits, and the 48-bit MAC address can be converted to an EUI-64 value via encapsulation (eg, encapsulating a systematically unique identifier). In consumer devices (eg, phones or computers), the interface ID 1104 may be assigned by the local operating systems of the consumer device.

ii. Routing transmissions between logical networks

[00168] As discussed above with respect to radial network topology, inter-network routing allows communication to occur between two devices across logical networks. In some embodiments, inter-network routing is based on subnet ID 1102. Each inter-networking node (e.g., node 1034 of FIG. 11) connects to other routing nodes (e.g., node 1034 of FIG. For example, it may maintain a list of Node B 14 of FIG. 11 . When a packet arrives addressed to a node other than the routing node itself, the destination address (e.g., the address for node 1052 in FIG. 11) is compared to a list of network prefixes and sent to the routing node (e.g., node 1044). ) is selected to be attached to the desired network (e.g., neighbor network 1024). The packet is then forwarded to the selected routing node. If multiple nodes (e.g., 1034 and 1036) are attached to the same perimeter network, routing nodes are selected in an alternative manner.

[00169] Additionally, inter-network routing nodes may regularly send Neighbor Discovery Protocol (NDP) Router Advertisement messages on the hub network to alert consumer devices to the presence of the hub network and allow them to obtain a subnet prefix. Router Advertisements may contain one or more route information options to help route information in the fabric. For example, these route information options can inform consumer devices of the existence of surrounding networks and how to route packets to the surrounding networks.

[00170] In addition to or instead of route information options, routing nodes can act as proxies to provide connectivity between consumer devices and devices in peripheral networks, such as process 1105 as illustrated in FIG. 16 . As illustrated, process 1105 includes assigning each peripheral network device a virtual address on the hub network by associating the subnet ID 1102 with the interface ID 1104 for the device on the peripheral network (block 1106). To proxy using virtual addresses, routing nodes maintain a list of all neighboring nodes in the fabric that are directly reachable through one of their interfaces (block 1108). Routing nodes listen on the hub network for neighbor solicitation messages requesting link addresses of neighboring nodes using their virtual addresses (block 1110). Upon receiving such a message, the routing node attempts to assign a virtual address to its hub interface after a period of time (block 1112). As part of the assignment, routing nodes perform double address detection to block proxying of virtual addresses by more than one routing node. After the assignment, the routing node responds to the neighbor claim message and receives the packet (block 1114). Upon receiving the packet, the routing node rewrites the destination address to be the real address of the neighboring node (block 1116) and forwards the message to the appropriate interface (block 1118).

iii. Consumer devices connecting to the fabric

[00171] To join the fabric, a consumer device can discover the address of a node already in the fabric that the consumer device wants to join. Additionally, if a consumer device is disconnected from the fabric for an extended period of time, the consumer device may need to rediscover nodes on the network if the fabric topology/layout has changed. To aid discovery/rediscovery, fabric devices on the hub network can publish Domain Name System-Service Discovery (DNS-SD) records via mDNS that announce the existence of the fabric and provide addresses to consumer devices.

data sent from the fabric

[00172] After address creation for the nodes and creation of the fabric, data can be transmitted over the fabric. Data passed through the fabric may be arranged in a format common to a particular type of conversation in the fabric and/or common to all messages. In some embodiments, the message format can enable a one-to-one mapping to JavaScript Object Notation (JSON) using the TLV serialization format discussed below. Additionally, while the data frames below are described as including specific sizes, it should be noted that the lengths of the data fields of the data frames may be varied to other suitable bit lengths.

A. Security

[00173] Along with the data it intends to transmit, the fabric may transmit the data with additional security measures, such as encryption, message integrity checks and digital signatures. In some embodiments, the level of security supported for a device may vary depending on the physical security of the device and/or capabilities of the device. In certain embodiments, messages transmitted between nodes in the fabric may be encrypted using Advanced Encryption Standard (AES) block cipher operating in counter mode (AES-CTR) with a 128-bit key. As discussed below, each message contains a 32-bit message id. The message id may be combined with the sending node id to form a nonce for the AES-CTR algorithm. The 32-bit counter allows 4 billion messages to be encrypted and transmitted by each node before a new key is negotiated.

[00174] In some embodiments, the fabric can guarantee message integrity using a message authentication code, such as HMAC-SHA-1, that can be included in each encrypted message. In some embodiments, the message authentication code may be generated using a 160-bit message integrity key that is paired one-to-one with an encryption key. Additionally, each node may check the message id of incoming messages against a list of recently received ids maintained per node to block replay of messages.

B. Tag Length Value (TLV) Formatting

[00175] To save power consumption, by skipping to the next location of understood data within the serialization of data, allowing data containers to represent data flexibly to accommodate skipping data they do not recognize or understand, allowing compact transmission across the fabric. It is desirable to transmit at least part of the data. In certain embodiments, tag-length-value (TVL) formatting may be used to encode/decode data compactly and flexibly. By storing at least part of the transmitted data in the TLV, as described below with reference to Table 7, data can be stored/transmitted compactly and flexibly with low encoding/decoding and memory overhead. In certain embodiments, TVL may be used for some data as flexible and extensible data, while other portions of non-extensible data may be stored and transmitted in an understood standard protocol data unit (PDU).

[00176] Data formatted in the TLV format can be encoded as various types of TVL elements, such as base types and container types. Basic types contain data values in specific formats, such as integers or strings. For example, the TLV format includes 1, 2, 3, 4 or 8 byte signed/unsigned integers, UTF-8 strings, byte strings, single/double precision floating numbers (e.g. eg IEEE 754-1985 format), boolean, null, and other suitable data format types. Container types may include a set of elements that are then subclassed as containers or primitive types. Container types may be classified into various categories, such as dictionaries, arrays, paths, or other suitable types, to group TLV elements known as members. A dictionary is a set of members, each with distinct definitions and unique tags within the dictionary. An array is an ordered collection of members with implied definitions or no explicit definitions. A path is an ordered set of members that describes how to traverse a tree of TLV elements.

[00177] As shown in FIG. 11 , an embodiment of a TLV packet 1120 includes three data fields: a tag field 1122 , a length field 1124 and a value field 1126 . Although illustrated fields 1122, 1124 and 1126 are shown as approximately equal in size, the size of each field may be variable and may vary in size relative to one another. In other embodiments, TLV packet 1120 may further include a control byte before tag field 1122 .

[00178] In embodiments with a control byte, the control byte can be subdivided into an element type field and a tag control field. In some embodiments, the element type field contains the lower 5 bits of the control byte and the tag control field uses the upper 3 bits. The element type field indicates how the length field 1124 and value field 1126 are encoded in addition to the type of the TLV element. In certain embodiments, the Element Type field also encodes Boolean values and/or Null values for the TLV. For example, an example of a list of element type fields is provided in Table 1 below.

Table 1. Example element type field values

The tag control field indicates the type of tag in the tag field 1122 assigned to the TLV element (including zero-length tags). Examples of tag control field values are provided in Table 2 below.

Table 2. Example values for tag control fields

In other words, in embodiments with a control byte, the control byte may indicate the length of the tag.

[00179] In certain embodiments, tag field 1122 may include 0 to 8 bytes, such as 8, 16, 32 or 64 bits. In some embodiments, tags in a tags field can be classified as profile-specific tags or context-specific tags. Profile-specific tags identify elements that globally use a vendor Id, profile Id, and/or tag number, as discussed below. Context-specific tags identify TLV elements within the context of a containing dictionary element, and may contain a single-byte tag number. Because context-specific tags are defined in the context of their containers, a single context-specific tag can have different interpretations when included in different containers. In some embodiments, context can also be derived from nested containers.

[00180] In embodiments with a control byte, the tag length is encoded in the tag control field, and tag field 1122 includes three possible fields: a vendor Id field, a profile Id field, and a tag number field. In fully-qualified form, the encoded tag field 1122 includes all three fields, with the tag number field containing 16 or 32 bits as determined by the tag control field. In implicit form, the tag contains only the tag number, and the vendor Id and profile number are inferred from the protocol context of the TLV element. The core profile form contains profile-specific tags, as discussed above. Context-specific tags are encoded as a single byte carrying the tag number. Anonymous elements have a zero-length tag field 1122.

[00181] In some embodiments without a control byte, 2 bits may indicate the length of the tag field 1122, and 2 bits may indicate the length of the length field 1124. , and the 4 bits may indicate the type of information stored in the value field 1126. An example of possible encoding for the upper 8 bits of the tag field is illustrated in Table 3 below.

Table 3. Tag field of TLV packet

As illustrated in Table 3, the upper 8 bits of tag field 1122 can be used to encode information about tag field 1122, length field 1124, and value field 1126, so that tag field 112 can be used to determine the lengths for the tag field 122 and the length field 1124. The remaining bits of the tag field 1122 may be made available for user-assigned and/or user-assigned tag values.

[00182] Length field 1124 may include 8, 16, 32 or 64 bits as indicated by element field as illustrated in Table 2 or tag field 1122 as illustrated in Table 3. Furthermore, the length field 1124 can include an unsigned integer representing the length encoded in the value field 1126 . In some embodiments, the length may be selected by the device sending the TLV element. Value field 1126 may contain payload data to be decoded, but interpretation of value field 1126 may depend on the tag length field and/or control type. For example, a TLV packet in which the control byte does not contain an 8-bit tag is illustrated in Table 4 below for illustrative purposes.

Table 4. Example of a TLV Packet with an 8-Bit Tag

As illustrated in Table 4, the first line indicates that each of the tag field 1122 and length field 1124 has a length of 8 bits. Additionally, the tag field 1122 indicates that the tag type for the first line is container (eg, TLV packet). The tag field 1124 for lines 2 to 6 indicates that each entry of the TLV packet has a tag field 1122 and a length field 1124 each consisting of 8 bits. Additionally, tag field 1124 indicates that each entry in the TLV packet has a value field 1126 containing a 32-bit floating point number. Each entry in the value field 1126 corresponds to a floating number that can be decoded using the corresponding tag field 1122 and length field 1124 information. As illustrated in this example, each entry in value field 1126 corresponds to a temperature in degrees Fahrenheit. As can be appreciated, by storing data in TLV packets, as described above, data can be transmitted compactly, while remaining flexible for variable lengths and information as it can be used by different devices in the fabric. . Moreover, in some embodiments, multi-byte integer fields may be sent in little-endian order or big-endian order.

[00183] By transmitting TLV packets using an array protocol (e.g., little-endian) that can be used by sending/receiving device formats (e.g., JSON), data transmitted between nodes is transmitted by at least one of the nodes. It may be transmitted in the array protocol used (e.g., little endian). For example, if one or more nodes include ARM or ix86 processors, transmissions between nodes may be sent using little-endian byte array to reduce the use of byte rearrangement. By reducing the inclusion of byte rearrangements, the TLV format allows devices to communicate using less power than transmissions that use byte rearrangements at both ends of the transmission. Moreover, TLV formatting can be specified to provide one-to-one interpretation between different data storage technologies such as JSON+Extensible Markup Language (XML). As an example, the TLV format may be used to represent the following XML attribute list:

As an example, the attribute list can be expressed as tags (without control bytes) in the TLV format described above according to Table 5 below.

Table 5. Example representation of an XML attribute list in TLV format

Similarly, Table 6 shows an example of literal tag, length and value representations for an exemplary XML attribute list.

Table 6. Examples of literal values for tag, length, and value fields for an XML attribute list

The TLV format enables the reference of attributes that may also be enumerated in XML, but with a smaller storage size. For example, Table 7 shows a comparison of data sizes of an XML attribute list, a corresponding binary attribute list, and a TLV format.

Table 7. Comparison of sizes of attribute list data sizes.

[00184] By reducing the amount of data used to transmit data, the TLV format allows the Fabric 1000 transfer data to and/or from devices with short duty cycles due to limited power (eg, battery supplied devices). enable That is, the TLV format allows flexibility of transmission while increasing the compressibility of the data to be transmitted.

C. general message protocol

[00185] In addition to transmitting specific entries of varying sizes, data may be transmitted within the fabric using a generic message protocol that may include TLV formatting. An embodiment of a general message protocol (GMP) 1128 is illustrated in FIG. 18 . In certain embodiments, general message protocol (GMP) 1128 may be used to transmit data within the fabric. GMP 1128 may be used to transmit data over connectionless protocols (eg UDP) and/or connection-oriented protocols (eg TCP). Accordingly, the GMP 1128 can flexibly accommodate information used in one protocol while ignoring information used in another protocol. Moreover, GMP 1226 may enable omission of fields not used for a particular transmission. Data that may be omitted from one or more GMP 1226 transmissions is generally indicated using gray borders around the data units. In some embodiments, multi-byte integer fields may be transmitted in little-endian order or big-endian order.

i. packet length

[00186] In some embodiments, GMP 1128 may include packet length field 1130 . In some embodiments, packet length field 1130 includes 2 bytes. The value of the packet length field 1130 corresponds to an unsigned integer representing the total length of the message in bytes, excluding the packet length field 1130 itself. The packet length field 1130 may be present when GMP 1128 is sent over a TCP connection, but when GMP 1128 is sent over a UDP connection, the message length is the basic UDP packet excluding the packet length field 1130. may be equal to the payload length of

ii. message header

[00187] GMP 1128 may also include message header 1132 regardless of whether GMP 1128 is sent using a TCP or UDP connection. In some embodiments, message header 1132 includes two bytes of data aligned in the format illustrated in FIG. 19 . As illustrated in FIG. 19 , message header 1132 includes version field 1156 . Version field 1156 corresponds to the version of GMP 1128 used to encode the message. Thus, when GMP 1128 is updated, new versions of GMP 1128 may be created, but each device in the fabric will be able to receive data packets with any version of GMP 1128 known to the device. may be In addition to version field 1156 , message header 1132 may include S flag field 1158 and D flag 1160 . The S flag 1158 is a single bit that indicates whether or not the transmitted packet includes a Source Node Id field (discussed below). Similarly, D flag 1160 is a single bit that indicates whether or not the packet being transmitted includes a destination node Id field (discussed below).

[00188] Message header 1132 also includes an encryption type field 1162 . The encryption type field 1162 contains 4 bits that specify what type of encryption/integrity check, if present, was applied to the message. For example, 0x0 may indicate that no encryption or message integrity check is included, while the decimal number 0x1 may indicate that AES-128-CTR encryption with HMAC-SHA-1 message integrity check is included.

[00189] Finally, the message header 1132 further includes a signature type field 1164. The signature type field 1164 contains 4 bits that specify which type of digital signature, if present, has been applied to the message. For example, 0x0 may indicate that no digital signature is included in the message, while 0x1 may indicate that the Elliptical Curve Digital Signature Algorithm (ECDSA) with Prime256v1 elliptic curve parameters is included in the message.

iii. message ID

[00190] Returning to FIG. 18, the GMP 1128 also includes a message Id field 1134 that may be included in the sent message, regardless of whether the message is sent using TCP or UDP. do. Message Id field 1134 contains 4 bytes corresponding to an unsigned integer value that uniquely identifies a message from the perspective of the sending node. In some embodiments, nodes may assign incrementing Message Id 1134 values to each message they send and return to zero after reaching 2 ³² messages.

iv. Source Node Id

[00191] In certain embodiments, GMP 1128 may also include a Source Node Id field 1136 comprising 8 bytes. As discussed above, the source node Id field 1136 may be present in a message if the single-bit S flag 1158 of the message header 1132 is set to one. In some embodiments, the source node Id field 1136 may include the interface ID 1104 of the ULA 1098 or the entire ULA 1098 . In some embodiments, the bytes in the source node Id field 1136 are transmitted in ascending index-value order (e.g., EUI[0], then EUI[1], then EUI[2], then EUI [3], etc.).

v. Destination node ID

[00192] GMP 1128 may include a Destination Node Id field 1138 that contains 8 bytes. The destination node Id field 1138 is similar to the source node Id field 1136, but the destination node Id field 1138 corresponds to the destination node of the message. The destination node Id field 1138 may be present in the message if the single-bit D flag 1160 of the message header 1132 is set to one. Also similar to source node Id field 1136, in some embodiments, bytes in destination node Id field 1138 may be transmitted in ascending index-value order (e.g., EUI[0], then EUI[ 1], then EUI[2], then EUI[3], etc.).

vi. Key Id

[00193] In some embodiments, GMP 1128 may include a key ID field 1140 . In certain embodiments, the key ID field 1140 includes 2 bytes. The key ID field 1140 contains an unsigned integer value that identifies the encryption/message integrity keys used to encrypt the message. The existence of the key ID field 1140 may be determined by the value of the encryption type field 1162 of the message header 1132. For example, in some embodiments, if the value for the encryption type field 1162 of the message header 1132 is 0x0, the key ID field 1140 may be omitted from the message.

[00194] An example of a key ID field 1140 is shown in FIG. 20 . In the illustrated embodiment, key ID field 1140 includes key type field 1166 and key number field 1168 . In some embodiments, key type field 1166 includes 4 bits. The key type field 1166 corresponds to an unsigned integer value that identifies the type of encryption/message integrity used to encrypt the message. For example, in some embodiments, if the key type field 1166 is 0x0, the fabric key is shared by all or most of the nodes in the fabric. However, if the key type field 1166 is 0x1, the fabric key is shared by a pair of nodes in the fabric.

[00195] The Key Id field 1140 also includes 12 bits corresponding to an unsigned integer value that identifies a particular key used to encrypt a message from a set of available keys, either shared or fabric keys. Key number field 1168.

vii. payload length

[00196] In some embodiments, GMP 1128 may include payload length field 1142 . The payload length field 1142 may contain 2 bytes if present. The payload length field 1142 corresponds to an unsigned integer value indicating the size in bytes of the application payload field. The payload length field 1142 may be present if the message is encrypted using an algorithm that uses message padding, as described below with respect to the padding field.

viii. initialization vector

[00197] In some embodiments, GMP 1128 may also include an initialization vector (IV) field 1144 . The IV field 1144, when present, contains a variable number of bytes of data. The IV field 1144 contains encryption IV values used to encrypt the message. The IV field 1144 may be used when a message is encrypted with an algorithm using an IV. The length of the IV field 1144 can be driven by the type of encryption used to encrypt the message.

ix. application payload

[00198] GMP 1128 includes application payload field 1146 . The application payload field 1146 contains a variable number of bytes. Application payload field 1146 contains application data carried in the message. The length of the application payload field 1146 , if present, can be determined from the payload length field 1142 . If the payload length field 1142 is not present, the length of the application payload field 1146 is the total length of the message and/or any other field from the data values (e.g., TLV) contained within the application payload 1146. can be determined by subtracting the lengths of

[00199] An embodiment of the application payload field 1146 is illustrated in FIG. 21 . The application payload field 1146 includes an APVersion field 1170 . In some embodiments, APVersion field 1170 includes 8 bits indicating which version of fabric software is supported by the sending device. The application payload field 1146 also includes a message type field 1172 . The message type field 1172 may include 8 bits corresponding to a message action code indicating the type of message being transmitted within the profile. For example, in a software update profile, 0x00 may indicate that the message being sent is an image announcement. The application payload field 1146 further includes an Exchange Id field 1174 containing 16 bits corresponding to an exchange identifier unique to the sending node for the transaction.

[00200] The application payload field 1146 also includes a profile Id field 1176 . Profile Id 1176 indicates a "subject of discussion" used to indicate what type of communication is taking place in a message. Profile Id 1176 may correspond to one or more profiles with which the device may communicate. For example, profile Id 1176 may indicate that the message relates to a core profile, software update profile, status update profile, data management profile, climate and comfort profile, security profile, safety profile, and/or other suitable profile types. can Each device on the fabric can include a list of profiles associated with the device, where the device can "join the discussion." For example, many devices in the fabric may include a core profile, software update profile, status update profile, and data management profile, but only some devices will include a climate and comfort profile. The APVersion field 1170, message type field 1172, exchange Id field, profile Id field 1176, and profile-specific header field 1176 (if present) may be combined to be referred to as an "application header."

[00201] In some embodiments, the indication of the profile Id via profile Id field 1176 may provide sufficient information to provide a schema for the data transmitted for the profile. However, in some embodiments, additional information may be used to determine additional guidance for decoding application payload field 1146 . In such embodiments, the application payload field 1146 may include a profile-specific header field 1178. Some profiles may not use the profile-specific header field 1178, allowing the application payload field 1146 to omit the profile-specific header field 1178. Upon determination of the schema from profile Id field 1176 and/or profile-specific header field 1178 , data may be encoded/decoded in application payload sub-field 1180 . Application payload sub-field 1180 contains core application data transmitted between devices and/or services to be stored, rebroadcast, and/or actuated by a receiving device/service.

x. Message Integrity Check

[00202] Returning to FIG. 18 , in some embodiments, GMP 1128 may also include a message integrity check (MIC) field 1148 . The MIC field 1148, if present, contains variable length bytes of data containing the MIC for the message. The length and byte order of the fields depend on the integrity checking algorithm used. If the message is checked for message integrity using, for example, HMAC-SHA-1, then the MIC field 1148 contains 20 bytes in big-endian order. Additionally, the presence of the MIC field 1148 can be determined by whether the encryption type field 1162 of the message header 1132 includes any value other than 0x0.

xi. padding

[00203] GMP 1128 may also include a padding field 1150 . The padding field 1150, if present, contains a sequence of bytes representing the encryption padding added to the message to make the encrypted portion of the message evenly divisible by the encryption block size. The presence of the padding field 1150 depends on whether the type of encryption algorithm indicated by the encryption type field 1162 of the message header 1132 (e.g., block ciphers in the cipher-block chaining mode) uses encryption padding. can be determined by

xii. encryption

[00204] Application payload field 1146 , MIC field 1148 and padding field 1150 together form encryption block 1152 . The encryption block 1152 includes portions of a message that are encrypted when the encryption type field 1162 of the message header 1132 is any value other than 0x0.

xiii. message signature

[00205] GMP 1128 may also include a message signature field 1154. The message signature field 1154, if present, contains a sequence of bytes of variable length that contains the encryption signature of the message. The length and contents of the message signature field may be determined according to the type of signature algorithm used, and may be indicated by the signature type field 1164 of the message header 1132. For example, if ECDSA using Prime256v1 elliptic curve parameters is the algorithm in use, the message signature field 1154 may contain two 32-bit integers encoded in little-endian order.

Profiles and Protocols

[00206] As discussed above, one or more schemas of information may be selected for a desired generic discussion type for a message. A profile can consist of one or more schemas. For example, a set of schemas of information may be used to encode/decode data in the application payload sub-field 1180 if one profile is indicated in the profile Id field 1176 of the application payload 1146. can However, if a different profile is indicated in the profile Id field 1176 of the application payload 1146, a different set of schemas may be used to encode/decode data in the application payload sub-field 1180.

[00207] Additionally, in certain embodiments, each device may include a set of methods used to process profiles. For example, the core protocol may include the following profiles: GetProfiles, GetSchema, GetSchemas, GetProperty, GetProperties, SetProperty, SetProperties, RemoveProperty, RemoveProperties, RequestEcho, NotifyPropertyChanged, and/or NotifyPropertiesChanged. The Get Profiles method can return an array of profiles supported by the queried node. The GetSchema and GetSchemas methods can each return one or all schemas for a particular profile. GetProperty and GetProperties can each return a value or all value pairs for the profile schema. SetProperty and SetProperties can respectively set single or multiple values for the profile schema. RemoveProperty and RemoveProperties may each attempt to remove single or multiple values from the profile schema. RequestEcho can send an arbitrary data payload to the specified node, and that node returns unmodified. NotifyPropertyChange and NotifyPropertiesChanged can each issue a notification if single/multiple value pairs have changed for the profile schema.

[00208] To help understand profiles and schemas, a non-exclusive list of profiles and schemas is provided below for illustrative purposes.

A. Status report

[00209] The status report schema is presented as status report frame 1182 in FIG. 22 . The status reporting schema can be a separate profile or can be included in one or more profiles (eg, core profile). In certain embodiments, the status report frame 1182 includes a profile field 1184, a status code field 1186, a next status field 1188, and may include an additional status information field 1190.

i. profile field

[00210] In some embodiments, the profile field 1184 contains 4 bytes of data that define the profile by which the information in the current status report is interpreted. An embodiment of a profile field 1184 having two sub-fields is illustrated in FIG. 23 . In the illustrated embodiment, the profile field 1184 includes a profile Id sub-field 1192 that contains 16 bits corresponding to the vendor-specific identifier of the profile for which the value of the status code field 1186 is being defined. The profile field 1184 may also include a vendor Id sub-field 1194 containing 16 bits identifying the vendor providing the profile identified in the Profile Id sub-field 1192 .

ii. status code

[00211] In certain embodiments, status code field 1186 includes 16 bits encoding the reported status. Values in the status code field 1186 are interpreted relative to the values encoded in the vendor Id sub-field 1192 and the profile Id sub-field 1194 provided in the profile field 1184 . Additionally, in some embodiments, the status code space may be partitioned into four groups, as indicated in Table 8 below.

Table 8. Status code range table

Although Table 8 identifies general status code ranges that may be assigned and used separately for each particular profile Id, in some embodiments, some status codes may be common for each of the profiles. For example, these profiles may be identified using a common profile (eg, core profile) identifier such as 0x00000000.

iii. next situation

[00212] In some embodiments, the next status code field 1188 includes 8 bits. The next state code field 1188 indicates whether next state information exists after the current reported state. If the next state information is included, the next state code field 1188 indicates what type of state information is included. In some embodiments, the next status code field 1188 may always be included, thereby potentially increasing the size of the message. However, by providing an opportunity to chain state information together, the potential for an overall reduction in transmitted data may be reduced. If the next status field 1186 is 0x00, then no next status information field 1190 is included. However, non-zero values may indicate that data may be included, and may indicate the form in which data is included (eg, in a TLV packet).

iv. Additional status information

[00213] When the next status code field 1188 is non-zero, an additional status information field 1190 is included in the message. If present, the state item field may contain the state in a form that can be determined by the value of the previous state type field (eg, TLV format).

B. Software Update

[00214] A software update profile or protocol is a set of client/server protocols and schemas that enable clients to recognize or seek information about the existence of software that clients can download and install. Using a software update protocol, a software image may be provided to a profile client in a format known to the client. Subsequent processing of the software image may be general, device-specific, or vendor-specific and determined by the software update protocol and devices.

i. application Common application headers for payload

[00215] In order to be properly recognized and processed, software update profile frames may be identified within the application payload field 1146 of GMP 1128. In some embodiments, all software update profile frames may use a common profile Id 1176, such as 0x0000000C., Additionally, software update profile frames include a message type field 1172 indicating additional information. It can be selected according to Table 9 below and the type of message transmitted.

Table 9. Software Update Profile Message Types

Additionally, as described below, a software update sequence may be initiated by a server sending an update as an image announcement or a client receiving an update as an image query. In either embodiment, the Exchange Id 1174 from the initiation event is used for all messages used in connection with software updates.

ii. protocol sequence

[00216] 24 illustrates an embodiment of a protocol sequence 1196 for software updates between software update client 1198 and software update server 1200 . In certain embodiments, any device in the fabric may be a software update client 1198 or a software update server 1200 . Certain embodiments of protocol sequence 1196 may include additional steps, such as those illustrated with dotted lines, that may be omitted in some software update transmissions.

1. Service discovery

[00217] In some embodiments, protocol sequence 1196 begins with the software update profile server announcing the existence of an update. However, in other embodiments, such as the illustrated embodiment, protocol sequence 1196 begins with service discovery 1202 discussed above.

2. Image announcement

[00218] In some embodiments, image notification message 1204 may be multicast or unicast by software update server 1200 . The image notification message 1204 notifies devices in the fabric that the server 1200 has a software update to offer. Upon receipt of the image notification message 1204 , the software update client 1198 responds with an image query message 1206 if the update is applicable to the client 1198 . In certain embodiments, image announcement message 1204 may not be included in protocol sequence 1196 . Instead, in such embodiments, software update client 1198 can use a polling schedule to determine when to send image query message 1206.

3. Image query

[00219] In certain embodiments, the image query message 1206 may be unicast from the software update client 1198 in response to the image announcement message 1204 or according to a polling schedule, as discussed above. Image query message 1206 includes information from client 1198 about itself. An embodiment of a frame of an image query message 1206 is illustrated in FIG. 25 . As illustrated in FIG. 25 , particular embodiments of an image query message 1206 include frame control field 1218, product specification field 1220, vendor specific data field 1222, version specification field 1224, locale specification field 1226 , supported integrity types field 1228 , and supported update schemes field 1230 .

a. frame control

[00220] The frame control field 1218 contains 1 byte and indicates various information about the image query message 1204. An example of the frame control field 128 is illustrated in FIG. 26 . As illustrated, the frame control field 1218 may include three sub-fields: a vendor specific flag 1232, a locale specification flag 1234 and a reserved field S3. The vendor specific flag 1232 indicates whether the vendor specific data field 1222 is included in the message image query message. For example, when vendor specific flag 1232 is 0, no vendor specific data field 1222 may be present in the image query message, but when vendor specific flag 1232 is 1, vendor specific data field 1222 ) may be present in the image query message. Similarly, a value of 1 in the locale-specification flag 1234 indicates that the locale-specification field 1226 is present in the image query message, and a value of 0 indicates that the locale-specification field 1226 is not present in the image query message.

b. product specifications

[00221] The product specification field 1220 is a 6 byte field. An embodiment of the product specification field 1220 is illustrated in FIG. 27 . As illustrated, product specification field 1220 may include three sub-fields: vendor Id field 1236 , product Id field 1238 and product modification field 1240 . Vendor Id field 1236 contains 16 bits indicating the vendor for software update client 1198. The product Id field 1238 contains 16 bits that indicate the product of the device sending the image query message 1206 to the software update client 1198. The product revision field 1240 contains 16 bits indicating the revision attribute of the software update client 1198 .

c. Vendor specific data

[00222] The vendor specific data field 1222, when present in the image query message 1206, is a variable number of bytes in length. The presence of the vendor specific data field 1222 can be determined from the vendor specific flag 1232 in the frame control field 1218 . When present, vendor specific data field 1222 encodes vendor specific information about software update client 1198 in TLV format, as described above.

d. version specification

[00223] An embodiment of the version specification field 1224 is illustrated in FIG. 28 . The version specification field 1224 contains a variable number of bytes that are subdivided into two sub-fields: a version length field 1242 and a version string field 1244. The version length field 1242 contains 8 bits indicating the length of the version string field 1244. The version string field 1244 is of variable length and is determined by the version length field 1242 . In some embodiments, the version string field 1244 may be capped at 255 UTF-8 characters in length. The encoded value in the version string field 1244 indicates the software version attribute for the software update client 1198.

e. locale specification

[00224] In certain embodiments, the locale specification field 1226 may be included in the image query message 1206 when the locale specification flag 1234 of the frame control 1218 is equal to one. An embodiment of the locale specification field 1226 is illustrated in FIG. 29 . The illustrated embodiment of locale specification field 1226 includes a variable number of bytes that are divided into two sub-fields: locale string length field 1246 and locale string field 1248 . The locale string length field 1246 contains 8 bits indicating the length of the locale string field 1248. The locale string field 1248 of the locale specification field 1226 is variable in length and can contain a string of UTF-8 characters that encodes a local description based on Portable Operating System Interface (POSIX) locale codes. The standard format for POSIX locale codes is [language[_territory][.codeset][@modifier]]. For example, the POSIX representation for Australian English is en_AU.UTF8.

f. Supported Integrity Types

[00225] An embodiment of the integrity type field 1228 is illustrated in FIG. 30 . The Supported Integrity Types field 1228 contains 2 to 4 bytes of data that is divided into two sub-fields: a Type List Length field 1250 and an Integrity Type List field 1252. The type list length field 1250 contains 8 bits representing the length in bytes of the integrity type list field 1252. The integrity type list field 1252 indicates the value of the software update integrity type attribute of the software update client 1198 . In some embodiments, the integrity type can be derived from Table 10 below:

Table 10. Example Integrity Types

The integrity type list field 1252 may include at least one element from Table 10 or other additional values not included.

g. Supported update schemes

[00226] An embodiment of the supported scheme field 1230 is illustrated in FIG. 31 . The supported schemes field 1230 contains a variable number of bytes that is divided into two sub-fields: a scheme list length field 1254 and an update skip list field 1256 . The scheme list length field 1254 contains 8 bits indicating the length of the update scheme list field in bytes. The update scheme list field 1256 of the supported update schemes field 1222 is variable in length determined by the scheme list length field 1254 . The update scheme list field 1256 indicates update scheme attributes of the software update profile of the software update client 1198 . Examples of exemplary values are shown in Table 11 below.

Table 11. Example update schemes

Upon receipt of the image query message 1206, the software update server 1200 determines whether the software update server 1200 has an update for the software update client 1198 and how best to send the update to the software update client 1198. Use the transmitted information to determine how to deliver.

4. Image Q&A

[00227] Returning to FIG. 24 , after the software update server 1200 receives the image query message 1206 from the software update client 1198, the software update server 1200 responds with an image query response 1208. Image query response 1208 may provide information about why an update image is not available to software update client 1198 or about available image updates to enable software update client 1198 to download and install updates. Contains descriptive information.

[00228] An embodiment of a frame of an image query response 1208 is illustrated in FIG. 32 . As illustrated, image query response 1208 has five possible sub-fields: query status field 1258, uniform resource identifier (URI) field 1260, integrity specification field 1262, update scheme field 1264 ) and an update options field 1266.

a. query status

[00229] The query status field 1258 contains a variable number of bytes and contains a status reporting the formatted data as discussed above with reference to status reporting. For example, query status field 1258 can include image query response status codes such as those illustrated in Table 12 below.

Table 12. Example Image Query Response Status Codes

b.URI

[00230] The URI field 1260 contains a variable number of bytes. The presence of URI field 1260 can be determined by query status field 1258 . If query status field 1258 indicates that an update is available, URI field 1260 may be included. An embodiment of the URI field 1260 is illustrated in FIG. 33 . URI field 1260 includes two sub-fields: URI length field 1268 and URI string field 1270 . The URI length field 1268 contains 16 bits indicating the length of the URI string field 1270 in UTF-8 characters. The URI string field 1270 indicates the URI attribute of the software image update being presented so that the software update client 1198, when present, can locate, download, and install the software image update.

c. integrity specification

[00231] The integrity specification field 1262 can be variable in length and is present when the query status field 1258 indicates that an update from the software update server 1198 to the software update client 1198 is available. An embodiment of the integrity specification field 1262 is illustrated in FIG. 34 . As illustrated, integrity specification field 1262 includes two sub-fields: integrity type field 1272 and integrity value field 1274 . Integrity type field 1272 contains 8 bits representing the integrity type attribute for software image updates and can be populated using a list similar to that illustrated in Table 10 above. Integrity value field 1274 is an image update message. It contains an integrity value used to verify that has maintained integrity during transmission.

d. update scheme

[00232] The update scheme field 1264 contains 8 bits and is present when query status field 1258 indicates that an update from software update server 1198 to software update client 1198 is available. If present, update scheme field 1264 indicates scheme attributes for the software update image presented to software update server 1198 .

e. update options

[00233] The update options field 1266 contains 8 bits and is present when query status field 1258 indicates that an update from the software update server 1198 to the software update client 1198 is available. The update options field 1266 can be subdivided as illustrated in FIG. 35 . As illustrated, the update options field 1266 includes four sub-fields: an update priority field 1276, an update condition field 1278, a reporting status flag 1280, and a reserved field 1282. . In some embodiments, update priority field 1276 includes 2 bits. The update priority field 1276 indicates the priority attribute of the update and may be determined using values such as those exemplified in Table 13 below.

Table 13. Example update priority values

The update condition field 1278 contains 3 bits that can be used to determine conditional factors to determine whether to update or when to update. For example, the values of update condition field 1278 can be decoded using Table 14 below.

Table 14. Example update conditions

Report status flag 1280 is a single bit indicating whether software update client 1198 should respond with download notification message 1210 . If the report status flag 1280 is set to 1, the software update server 1198 requests the download notification message 1210 to be sent after the software update has been downloaded by the software update client 1200.

[00234] If image query response 1208 indicates that an update is available, software update client 1198 uses the information contained in image query response 1208 to download the update at the time indicated in image query response 1208. Load (1210).

5. Download Notice

[00235] After the update download 1210 completes successfully or fails, and the report status flag 1280 has a value of one, the software update client 1198 can respond with a download notification message 1212 . The download notification message 1210 may be formatted according to the status report format discussed above. Examples of status codes used in the download notification message 1212 are illustrated in Table 15 below.

Table 15. Example download verification status codes

In addition to the status reports described above, the download notification message 1208 may include an obstacle to the download and/or additional status information that may be related to the download.

6. Notification response

[00236] The software update server 1200 may respond with a notification response message 1214 in response to the downloaded notification message 1212 or update notification message 1216 . The notification response message 1214 may include a status report format, as described above. For example, notification response message 1214 can include status codes as listed in Table 16 below.

Table 16. Example Notification Response Status Codes

In addition to the status report described above, the notification response message 1214 may include additional status information that may relate to download, update, and/or failure to download/update a software update.

7. update notice

[00237] After the update completes successfully or fails and the report status flag 1280 has a value of one, the software update client 1198 can respond with an update notification message 1216 . The update notification message 1216 may use the status report format described above. For example, the update notification message 1216 can include status codes as listed in Table 17 below.

Table 17. Example update notification status codes

In addition to the status reports described above, the update notification message 1216 may include additional status information that may be related to the update and/or update failure.

C. Data Management Protocol

[00238] Data management can be included in a common profile (eg, core profile) used by various electronic devices within the fabric or can be specified as a separate profile. In either situation, device management protocol (DMP) may be used for nodes to browse, share, and/or update node-resident information. A sequence 1284 used in DMP is shown in FIG. 36 . Sequence 1284 shows viewing node 1286 requesting to view and/or change the resident data of node 1288 being viewed. Additionally, the viewing node 1286 may request to view the resident data using one of several viewing options, such as a snapshot request, a watching request where the viewing persists over a period of time, or another suitable viewing type. there is. Each message follows the format for application payload 1146 described with reference to FIG. 21 . For example, each message includes a profile Id 1176 corresponding to a data management profile and/or an associated core profile, such as 0x235A0000. Each message also includes a message type 1172. The message type 1172 can be used to determine various factors related to a conversation, such as a viewing type for a view. For example, in some embodiments, message type field 1172 may be encoded/decoded according to Table 18 below.

Table 18. Example Software Update Profile Message Types

i.View request

[00239] Even if the view request message 1290 requests to view node-resident data, the request type may be determined by the message type field 1172 as described above. Accordingly, each request type may include a different view request frame.

1. Snapshot request

[0241] A snapshot request can be sent by viewing node 1286 if viewing node 1286 wants to immediately view node-resident data on viewed node 1288 without requesting feature updates. An embodiment of a snapshot request frame 1292 is shown in FIG. 37 .

[00242] As shown in FIG. 37 , snapshot request frame 1292 can be of variable length and contains three fields: view handle field 1294, path length list field 1296, and path list field 1298. include The view handle field 1294 may contain 2 bits providing a "handle" to identify the requested view. In some embodiments, view handle field 1294 is populated using a random 16-bit number or 16-bit sequence number along with a unique check performed on viewing node 1286 when a request is made. The path list length field 1296 contains 2 bytes indicating the length of the path list field 1298. The path list field 1298 has a variable length and is indicated by the value of the path list length field 1296. A value of the path list field 1298 represents a schema path for nodes.

[00242] A schema path is a compact description of a container or data item that is part of the schema residency on nodes. For example, FIG. 38 provides an example of a profile schema 1300 . In the illustrated profile schema 1300, the path to the data item 1302 may be written as "Foo:bike:mountain" in binary format. The binary format of the path may be represented as profile binary format 1304, as shown in FIG. The profile binary format 1304 includes two sub-fields: a profile identifier field 1306 and a TLV data field 1308. Profile identifier field 1306 identifies which profile (eg, Foo profile) is being referenced. TLV data field (1308) route information. As mentioned above, TLV data includes a tag field containing information about enclosed data. The tag field values used to refer to the Foo profile of FIG. 38 may be similar to those listed in Table 19.

Table 19. Example tag values for profile Foo

Using Table 19 and the Foo profile of FIG. 38, a binary string in TLV format representing the path “Foo:bike:mountain” can be represented as shown in Table 20 below.

Table 20. Example binary tag list for schema path

If viewing node 1286 wants to receive the full set of data defined in the profile schema (e.g., the Foo profile schema in FIG. empty length) can be requested.

2. Surveillance request

[00243] If viewing node 1286 wants more than a snapshot, viewing node 1286 can request a monitoring request. When changes are made to the data of interest at the viewing node 1288, the watch request asks the viewing node 1288 to send updates, so that the viewing node 1286 can maintain a synchronized list of data. The monitoring request frame may have a different format from the snapshot request of FIG. 37 . An embodiment of a monitor request frame 1310 is shown in FIG. 40 . The monitor request frame 1310 includes four fields: a view handle field 1312 , a route list length field 1314 , a route list field 1316 , and a change count field 1318 . The view handle field 1312, the path list length field 1314, and the path list field are the view handle field 1294, the path list length field 1296, and the path list field 1298 of the snapshot request of FIG. 37, respectively. It can be formatted similarly to An additional field, change count field 1318 indicates the threshold of the number of changes to requested data for which an update is sent to viewing node 1286 . In some embodiments, if the value of change count field 1318 is zero, the viewed node 1288 can itself determine when to send an update. If the value of the change count field 1318 is non-zero and the number of subsequent changes equals that value, then an update is sent to the viewing node 1286.

3. Periodic Update Request

[00244] A third type of view may also be requested by viewing node 1286 . This third type of view is referred to as periodic update. Periodic updates include snapshot views as well as periodic updates. As can be appreciated, periodic update requests can be similar to snapshot requests with additional information determining the update period. For example, an embodiment of a periodic update request frame 1320 is shown in FIG. 41 . Periodic update request frame 1320 includes four fields: view handle field 1322 , route list length field 1324 , route list field 1326 , and update period field 1328 . View handle field 1322 , path list length field 1324 , and path list field 1326 may be formatted similarly to their respective fields in snapshot request frame 1292 . The update period field 1328 is 4 bytes in length and contains a value corresponding to the period of time that elapses between updates of the relevant unit of time (eg, seconds).

4. Refresh request

[00245] If the viewing node 1286 wishes to receive the updated snapshot, the viewing node 1286 may transmit a view request message 1290 in the form of a refresh request frame 1330 as shown in FIG. 42 . Refresh request frame 1330 essentially includes a snapshot view handle field (e.g., Retransmit the view handle field 1294.

5. Cancel view request

[00246] If the viewing node 1286 wishes to cancel an ongoing view (eg, periodic update or watch view), the viewing node 1286 sends a view request message in the form of a view request cancellation frame 1332 as shown in FIG. 43 . (1290) can be transmitted. The view request cancel frame 1332 is essentially a previous periodic update or watch view (e.g. , view handle fields 1310 or 1322) to cancel the current periodic update or watch view.

ii. view response

[00247] Returning to FIG. 36 , after the viewed node 1288 receives the view request message 1290 , the viewed node 1288 responds with a view response message 1334 . An example of a view response message frame 1336 is shown in FIG. 44 . View response message frame 1336 includes three fields: view handle field 1338 , view request status field 1240 , and data item list 1242 . The view handle field 1338 may be formatted similarly to any of the view handle fields 1338 noted above. Additionally, view handle field 1338 includes a value that matches the respective view handle field from view request message 1290 to which view response message 1334 is responding. The view request status field 1340 is a variable length field indicating the status of the view request and can be formatted according to the status updating format mentioned above. The data item list field 1342 is a variable length field that is present when the view request status field 1340 indicates that the view request was successful. If present, the data item list field 1342 contains an ordered list of requested data corresponding to the path list of the view request message 1290 . Moreover, the data in data item list field 1342 can be encoded in TLV format as described above.

iii. update request

[00248] As discussed above, in some embodiments, viewing node 1288 may send updates to viewing node 1286 . These updates may be sent as update request message 1344 . The update request message 1344 may include a specified format depending on the type of update request. For example, the update request can be an explicit update request or a view update request field that can be identified by message Id 1172 .

1. Explicit update request

[00249] Explicit update requests may be sent at any time as a result of a desire for information from other nodes in fabric 1000 . Explicit update requests can be formatted in update request frame 1346 shown in FIG. 45 . The illustrated update request frame 1346 includes four fields: update handle field 1348 , route list length field 1350 , route list field 1352 , and data item list field 1354 .

[00250] The update handle field 1348 contains two bytes that can be populated with random or sequential numbers with uniqueness checks to identify the update request or responses to the request. The path list length field 1350 contains two bytes indicating the length of the path list field 1352. Route list field 1352 is a variable length field indicating a sequence of routes, as described above. Data item list field 1354 may be formatted similarly to data item list field 1242 .

2. Request to update the view

[00251] A view update request message can be sent by a node that previously requested a view into the schemas of another node, or a node that set a view into its own data on behalf of the other node. One embodiment of a view update request frame 1356 is illustrated in FIG. 46 . The view update request frame 1356 includes four fields: update handle field 1358, view handle field 1360, update item list length field 1362, and update item list field 1364. The update handle field 1358 can be constructed using the format described above with reference to the update handle field 1348 . The view handle field 1360 contains two bytes that identify the view created by the related view request message 1290 that has the same view handle. The update item list length field 1362 includes 2 bytes and indicates the number of update items included in the update item list field 1364 .

[00252] The update item list field 1364 lists data items that contain a variable number of bytes and consist of updated values. Each updated item list may include multiple update items. Accordingly, individual update items are formatted into an update item frame 1366 illustrated in FIG. 47 . Each update item frame 1366 includes three sub-fields: item index field 1368, item timestamp field 1370, and data item field 1372. Item index field 1368 contains two bytes indicating the view for which an update is being requested, and the index in that view's path list to data item field 1372 .

[00253] The item timestamp field 1370 contains 4 bytes and indicates the elapsed time from change (eg, in seconds) until the communicated update was made. If more than one change has been made to a data item, the item timestamp field 1370 can indicate the most recent or earliest change. Data item field 1372 is a variable length field encoded in a TLV format to be received as updated information.

iv. update response

[00254] After an update is received, a node (e.g., viewing node 1286) can send an update response message 1374. The update response message 1374 can use the update response frame 1376 illustrated in FIG. The update response frame 1376 includes two fields: an update handle field 1378 and an update request status field 1380. The update handle field 1378 includes an update response message 1374 Corresponds to the value of the update handle field of the update request message 1344 to which DMP responds. The update request status field 1380 reports the status of the update according to the status report format described above. Additionally, using DMP A profile (eg, Core Profile or Data Management Profile) may contain profile-specific codes, such as those listed in Table 21 below.

D. Bulk transfer

[00255] In some embodiments, it may be desirable to transfer bulk data files (eg, sensor data, logs, or update messages) between nodes/services within fabric 1000. A separate profile or protocol may be incorporated into one or more profiles to enable transmission of bulk data and may be made available to nodes/services within nodes. A bulk data transfer protocol can model data files as collections of data with metadata attachments. In certain embodiments, data may be opaque, but metadata may be used to determine whether to process a requested file transfer.

[00256] Devices participating in bulk transport can generally be divided according to bulk transport communication and event generation. As illustrated in FIG. 49 , each communication 1400 in a bulk transfer is a transmitter, which is a node/service that transmits bulk data 1404 to a receiver 1406, which is a node/service that receives the bulk data 1404. (1402). In some embodiments, the receiver can send status information 1408 to the transmitter 1402 indicating the status of the bulk transmission. Additionally, a bulk transfer event can be initiated by either transmitter 1402 (eg, upload) or receiver 1406 (eg, download) as an initiator. A node/service that responds to an initiator may be referred to as a responder in bulk data transmission.

[00257] Bulk data transfer can occur using either synchronous or asynchronous modes. The mode in which data is transmitted may be determined using various factors, such as the underlying protocol (eg UDP or TCP) in which bulk data is transmitted. In connectionless protocols (eg UDP), bulk data may be transmitted using a synchronization mode that allows one of the nodes/services ("driver") to control the rate at which the transmission proceeds. In certain embodiments, an acknowledgment may be sent after each message in a bulk data transfer in synchronization mode, before sending the next message in the bulk data transfer. The driver can be either the transmitter 1402 or the receiver 1406. In some embodiments, a driver may toggle between an online and offline state while sending messages to drive transmission when online. In bulk data transfers using connection-oriented protocols (eg, TCP), the bulk data is sent using an asynchronous mode that does not use an acknowledgment before sending successive messages or a single driver. It can be.

[00258] Regardless of whether the bulk data transfer is performed using synchronous or asynchronous mode, the type of message can be determined using the message type 1172 in the application payload 1146 according to the profile Id 1176 in the application payload. there is. Table 22 includes an example of message types that may be used in conjunction with the Bulk Data Transfer Profile value in Profile Id 1176.

i. SendInit

[00259] One embodiment of a SendInit message 1420 is illustrated in FIG. 50 . The SendInit message 1420 contains seven fields: a transmission control field 1422, a range control field 1424, a file specifier length field 1426, a suggested maximum block size field 1428, and a start offset field 1430. , a length field 1432, and a file designator field 1434.

[00260] The transmission control field 1422 contains the bytes of data illustrated in FIG. 51 . The transmission control field includes at least four fields: an Asynch flag 1450, an RDrive flag 1452, an SDrive flag 1454, and a version field 1456. Asynch flag 1450 indicates whether the proposed transfer can be performed using synchronous or asynchronous mode. RDrive flag 1452 and SDrive flag 1454 each indicate whether receiver 1406 can transmit data using either receiver 1402 or transmitter 1408 driving synchronous mode transmission.

[00261] The range control field 1424 contains bytes of data, such as the range control field 1424 illustrated in FIG. 52 . In the illustrated embodiment, extent control field 1424 includes at least three fields: BigExtent flag 1470 , start offset flag 1472 , and finite length flag 1474 . Finite length flag 1474 indicates whether the transmission has a finite length. A finite length flag 1474 indicates whether a length field 1432 is present in the SendInit message 1420, and a BigExtent flag 1470 indicates the size for the length field 1432. For example, in some embodiments, a value of 1 in BigExtent flag 1470 indicates that length field 1432 is 8 bytes. Otherwise, the length field 1432, if present, is 4 bytes. If the transfer is of finite length, start offset flag 1472 indicates whether a start offset exists. If a start offset is present, the BigExtent flag 1470 indicates the length for the start offset field 1430 . For example, in some embodiments, a value of 1 in BigExtent flag 1470 indicates that start offset field 1430 is 8 bytes. Otherwise, the start offset field 1430, if present, is 4 bytes.

[00262] Referring to FIG. 50 , a file specifier length field 1426 includes two bytes indicating the length of a file specifier field 1434. File specifier field 1434, which is a variable length field, depends on file specifier length field 1426. The maximum block size field 1428 suggests the maximum size of a block that can be transmitted in a single transmission.

[00263] If present, the start offset field 1430 has the length indicated by the BigExtent flag 1470 . The value of the start offset field 1430 indicates the position within the file to be transferred that the sender 1402 can begin sending, which in essence causes large file transfers to be segmented into multiple bulk transfer sessions.

[00264] When present, length field 1432 indicates the length of the file to be transferred if finite length field 1474 indicates that the file has a finite length. In some embodiments, if receiver 1402 receives the last block before the length is achieved, the receiver may consider the transmission to have failed and report an error as described below.

[00265] File designator field 1434 is a variable length identifier selected by transmitter 1402 to identify the file to be transmitted. In some embodiments, transmitter 1402 and receiver 1406 may negotiate an identifier for a file prior to transmission. In other embodiments, receiver 1406 can use the metadata along with file specifier field 1434 to determine whether to accept the transfer and how to handle the data. The length of the file specifier field 1434 can be determined from the file specifier length field 1426 . In some embodiments, the SendInit message 1420 may also include a variable length metadata field 1480 encoded in TLV format. Metadata field 1480 allows the initiator to transmit additional information, such as application-specific information about the file being transferred. In some embodiments, metadata field 1480 can be used to avoid negotiating file designator field 1434 prior to bulk data transmission.

ii. SendAccept

[00266] A transmission acceptance message is sent from the responder to indicate the transmission mode selected for transmission. One embodiment of a SendAccept message 1500 is presented in FIG. 53 . The SendAccept message 1500 includes a transmission control field 1502 similar to the transmission control field 1422 of the SendInit message 1420. However, in some embodiments, only the RDrive flag 1452 or SDrive 1454 has a non-zero value in the transmission control field 1502 to identify the transmitter 1402 or receiver 1406 as a driver for synchronous mode transmission. can have The SendAccept message 1500 also includes a maximum block size field 1504 indicating the maximum block size for transmission. The block size field 1504 may be equal to the value of the max blocks field 1428 of the SendInit message 1420, but the value of the max block size field 1504 may be less than the value suggested in the max blocks field 1428. can Finally, the SendAccept message 1500 can include a metadata field 1506 indicating information that the receiver 1506 can send to the sender 1402 about the transmission.

iii. SendReject

[00267] When receiver 1206 rejects the transmission after the SendInit message, receiver 1206 can send a SendReject message indicating that there are one or more problems with the bulk data transfer between sender 1202 and receiver 1206. . The send rejection message may be formatted according to the status report format described above and illustrated in FIG. 54 . The reject transmission frame 1520 may include a status code field 1522 containing two bytes indicating the reason for rejecting the transmission. The status code field 1522 can be decoded using values similar to those listed as indicated in Table 23 below.

Table 23 Example Status Codes for Reject Send Message

In some embodiments, the reject to send message 1520 may include a next status field 1524. The next status field 1524, if present, may be formatted and encoded as discussed above with respect to the next status field 1188 of the status report frame. In certain embodiments, the reject to send message 1520 may include an additional information field 1526. The additional information field 1526, if present, can store information about additional state and can be encoded using the TLV format discussed above.

iv . ReceiveInit

[00268] A ReceiveInit message may be sent by receiver 1206 as an initiator. The ReceiveInit message may be formatted and encoded similarly to the SendInit message 1480 illustrated in FIG. 50 , but the BigExtent field 1470 may be referred to as a maximum length field that specifies the maximum file size that the receiver 1206 can handle. can

v. ReceiveAccept

[00269] When transmitter 1202 receives the ReceiveInit message, transmitter 1202 can respond with a ReceiveAccept message. The ReceiveAccept message can be formatted and encoded as the ReceiveAccept message 1540 illustrated in FIG. 55 . The ReceiveAccept message 1540 may include four fields: a transmission control field 1542 , a range control field 1544 , a maximum block size field 1546 , and sometimes a length field 1548 . The ReceiveAccept message 1540 may be formatted similarly to the SendAccept message 1502 of FIG. 53 , with the second byte indicating the range control field 1544 . Further, the range control field 1544 may be formatted and encoded using the same methods discussed above with respect to the range control field 1424 of FIG. 52 .

ⅵ. ReceiveReject

[00270] If sender 1202 encounters problems sending the file to receiver 1206, sender 1202 can send a ReceiveReject message, similar to SendReject message 48 both discussed above. are formatted and encoded using the status report format. However, the status code field 1522 can be encoded/decoded using values similar to those listed as shown in Table 24 below.

Table 24 Example Status Codes for Receive Rejection Messages

vii. BlockQuery

[00271] A BlockQuery message may be sent by the driving receiver 1202 to request the next block of data in a synchronous mode bulk data transmission. If no explicit acknowledgment is sent, BlockQuery implicitly acknowledges receipt of the previous block of data. In embodiments using asynchronous transfers, the BlockQuery message may be omitted from the sending process.

iii. block

[00272] Blocks of data transmitted in a bulk data transmission may contain any length greater than zero and less than the maximum block size agreed upon by the transmitter 1202 and receiver 1206.

ix. BlockEOF

[00273] The last block of a data transfer may be presented as a block end of file (BlockEOF). BlockEOF can have a length between 0 and the maximum block size. If receiver 1206 finds a discrepancy between the pre-negotiated file size (e.g., length field 1432) and the amount of data actually transmitted, receiver 1206 indicates a failure, as discussed below. Error messages can be sent.

x . Ack

[00274] If transmitter 1202 is driving a synchronous mode transmission, transmitter 1202 may wait after transmitting a block until receiving an acknowledgment (Ack) before transmitting the next block. If the receiver is driving a synchronous mode transmission, receiver 1206 can send an explicit Ack or BlockQuery to acknowledge receipt of the previous block. Also, in asynchronous mode bulk transfers, the Ack message can be omitted entirely from the transmission process.

xi. AckEOF

[00275] An acknowledgment of an end of file (AckEOF) may be sent in bulk transfers sent in synchronous mode or asynchronous mode. Using AckEOF, receiver 1206 indicates that all of the data in the transmission has been received, and signals the end of the bulk data transmission session.

xii. Error

[00276] In the event of certain problems in communication, the transmitter 1202 or receiver 1206 may send an error message to terminate the bulk data transfer session prematurely. Error messages may be formatted and encoded according to the status report format discussed above. For example, the error message may be formatted similar to the SendReject frame 1520 of FIG. 54 . However, status codes may include the values listed in Table 25 below and/or be encoded/decoded to values similar to these values.

Table 25. Example Status Codes for Error Messages in Bulk Data Transfer Profile

[00277] It should be understood that the specific embodiments described above have been presented as examples, and that these embodiments may tolerate various modifications and alternative forms. Additionally, it should be understood that the claims are not intended to be limited to the particular forms disclosed, but are intended to cover all modifications, equivalents, and alternatives included within the spirit and scope of the disclosure.

Efficient communication use cases and power awareness

[00278] An efficient IPv6 802.15.4 network protocol and/or an efficient platform protocol discussed above may enable power-efficient operation in a home environment. As will be discussed below, in one example, such communication may include communicating IPv6 packets to traverse a particular preferred network. Additionally or alternatively, characteristics of the communication scheme, eg the type of transport protocol used to transmit the message - TCP or UDP - may also be selectable. For example, TCP may be selected to provide less power savings but greater reliability, whereas UDP may be selected to provide less reliability but greater power savings.

Smart communication using IPv6 packet header fields

[00279] As indicated above, the fields available in IPv6 packet headers can be used to convey information about a target node of fabric 1000 targeted for receiving messages in a system of the present disclosure. For example, as shown in FIG. 56 , a packet header 1600 of an IPv6 packet targeted to a specific node may include a MAC field 1602, a subnet field 1604, and a fabric ID field 1606. The MAC field 1602 may fill a 64-bit area, commonly understood to represent Extended Unique Identifier (EUI)-64. The MAC field 1602 can include an indication of the MAC address of the target node. The subnet field 1604 and fabric ID field 1606 may collectively represent an Extended Unique Local Address (EULA). In the EULA of these fields, the Fabric ID field 1606 can indicate a particular fabric 1000 over which an IPv6 packet must be transmitted, while the Subnet field 1604 can indicate the fabric ( 1000), and preferably through this preferred network, the target node can receive messages. In the example of FIG. 56 , the subnet field 1604 indicates that the target node can preferably receive messages over a particular WiFi network. It is recognized that the EULA formed by the Fabric ID field 1606 and Subnet field 1604 may be used when IPv6 packets are being transmitted entirely within one or more connected fabrics and/or services serving those fabrics. It should be. When IPv6 packets are to be sent from a node in fabric 1000 to an external IPv6 Internet address, a different (eg, more common) IPv6 packet header structure may be used.

[00280] EULA information in subnet field 1604 and fabric ID field 1606 can be used to efficiently communicate IPv6 packets through fabric 1000 toward a target node. In the example shown in FIG. 57 , messages are transmitted over the network topology discussed above with reference to FIG. 11 . Here, node 1026 is a transmitting node and node 1036 is a target node. While node 1026 is operating on 802.15.4 network 1022 , target node 1036 operates on both 802.15.4 network 1022 and WiFi network 1020 . The preferred network of the target node 1036 is represented as being the WiFi network 1020 in the example of FIG. 57 . As such, IPv6 packets used to transmit messages from sending node 1026 to target node 1036 may generally have the characteristics shown in IPv6 packet 1600 of FIG. 56 .

[00281] Various nodes 1026, 1028, 1030, 1034, and 1042 are shown in FIG. When there is only one network to send a message to, the message can be communicated across that network. This is the case for nodes 1026, 1028, and 1030 in the example of FIG. 57 . However, when a message arrives at a node operating on more than one network, e.g., node 1034, that node determines which network to use to communicate the message further towards the target node 1036 subnet. Field 1604 can be used.

[00282] Flow diagram 1650 of FIG. 58 illustrates an example of a method for using the subnet field 1604 of a packet header 1600 to communicate an IPv6 packet towards a target node. In the method, a node operating on two networks (eg, node 1034 operating on both WiFi network 1020 and 802.15.4 network 1022) may receive an IPv6 packet (block 1652). The node can analyze the subnet field 1604 of the IPv6 packet header 1600 to determine which network is the most appropriate network to use for forwarding IPv6 packets towards the target node. The subnet field 1604 can, for example, indicate that the message should be received by the target node (eg, node 1036) over the WiFi network 1020. The receiving node (eg, node 1034) then communicates the IPv6 packet towards the target node (eg, node 1036) over the network indicated by the subnet field 1604 (eg, the WiFi network 1020). may (block 1654).

[00283] In some examples, the network through which the IPv6 packet was received may be different from the network indicated by subnet field 1604 . In FIG. 57 , node 1034 receives a message over 802.15.4 network 1022, for example. However, when the subnet field 1604 indicates that WiFi network 1020 is the preferred network to be used for forwarding IPv6 packets, node 1034 may communicate IPv6 packets over WiFi network 1020 instead. In this way, the subnet field 1604 can enable a target node to have a preferred network to receive messages from. In the example of FIG. 57 , target node 1036 can be an always-on electronic device that can communicate more quickly or more reliably over WiFi network 1020 than over 802.15.4 network 1022 . In other examples, target node 1036 may be a battery powered sleepy device that would be better served for receiving messages over 802.15.4 network 1022 . Under this example, even though target node 1036 can receive messages over WiFi network 1020, by receiving messages over 802.15.4 network 1022, which may be indicated by subnet field 1604, Target node 1036 may save power. Thus, the EULA (eg, fabric ID field 1606 and subnet field 1604) of the IPv6 packet header 1600 can be used to facilitate efficient message transmission across the fabric.

Selection of a transport protocol or preferred target network based on the desired reliability of the message

[00284] Careful selection of the preferred target node network and/or transport protocol (eg, TCP or UDP) used to transmit IPv6 packets may also lead to efficient network usage. Indeed, while TCP is more reliable than UDP, TCP's reliability comes from its handshaking when sending messages and the use of acknowledgments, many of which UDP lacks. However, the added reliability of TCP can increase the cost of sending messages in terms of power consumed. Indeed, there is an additional cost in power due to TCP's handshaking and acknowledgments. Additionally, using TCP will cause dropped packets to be retransmitted until they are confirmed to have been received, which consumes additional power on all devices experiencing the dropped packets.

[00285] As such, unless there are reasons why reliability is preferred over power efficiency, it may be desirable to transmit messages by means of UDP. For example, as shown in flow diagram 1670 of FIG. 59 , one of the devices on fabric 1000 may generate a message (block 1672). The device may consider one or more reliability factors related to the desired reliability of the message (block 1674). This consideration of one or more reliability factors may occur at the application layer 102 or platform layer 100 of the OSI stack 90 running on the device. In any case, the reliability factor(s) that the device may consider are (1) the type of message generated in block 1672, (2) the type of network over which the message will be transmitted, and (3) the distance the message will travel through the fabric. , (4) the power sensitivity of the target node and/or the transmitting nodes that will be used to communicate messages to the target node, and/or (5) the target end node type (eg, whether it is a device or a service). In some embodiments, only one factor may be considered. Moreover, the list of reliability factors discussed herein is not intended to be exhaustive, but rather to provide examples for determining whether reliability or power savings may be more desirable in transmitting a message.

[00286] A first factor that can affect the desired reliability of a transport protocol is the type of message to be transmitted. If the message is an alert message, such as a message indicating that danger has been detected, very high reliability may be required. However, if the message represents sensor data or specific device state data, high reliability may be less important than power savings.

[00287] A second factor that can affect the desired reliability of the transport protocol is the type of network over which the message will be transported. If the message primarily traverses an 802.15.4 network, for example, this may mean that power savings may be more beneficial than reliability. However, if the message primarily or entirely goes through a WiFi network, this may mean that power savings may be less important and reliability may be more important.

[00288] A third factor that can affect the desired reliability of the transport protocol is the distance a message can travel through the fabric 1000 to reach its target node. The distance may indicate, for example, the number of “hops” to reach the target node, the number of different types of networks that may be traversed to reach the target node, and/or the actual distance through the network.

[00289] A fourth factor that can affect the desired reliability of the transport protocol is the power sensitivity of the devices that can be used to communicate the message to the target node. If all or substantially all of these devices are always-on or powered by an external power source, higher reliability may be desirable for power savings. If one or many of the devices are low power, sleepy, and/or battery powered devices, power savings may be desirable if the message is not particularly urgent.

[00290] A fifth factor that can affect the desired reliability of the transport protocol is the type of target end node of the message. In one example, higher reliability may be required if the target end node - whether local or remote - is a service. Thus, in this case, TCP may be preferred over UDP. In another example, higher reliability may be preferred if the target end node is a remote service, but lower reliability and greater power savings may be desired if the target end node is a local service. In other examples, a type of service may be considered. That is, reliability may be preferred over power savings for some services, while power savings may be preferred over reliability for other services. To give just one example, relatively lower reliability compared to power savings may be required to communicate with a service used to provide weather information. On the other hand, for communicating with a service used to provide software updates, higher reliability may be preferred over power savings.

[00291] A device may consider one or more of these factors in any suitable way. In one example, weights may be assigned to the factors, and the reliability determination may be based on the total weight of the factors. In other examples, certain factors may have a higher priority than other factors. In this example, an urgent message can always be considered as having more demanding reliability than power savings, whereas the desirability of reliability for non-urgent messages can depend on other factors. Thus, if power savings rather than reliability are desired (decision block 1676), the device may send a message over UDP to save power despite the lower reliability (block 1678). If more reliability than power savings is desired (decision block 1676), the device may transmit the message over TCP with increased reliability despite the higher power consumption (block 1680).

[00292] Although the above method was discussed with reference to the choice of sending messages using TCP or UDP, it should be noted that the present communication system can effectively adjust any number of characteristics of the communication method to balance power consumption with required reliability. It should be recognized. For example, in some embodiments, a higher power network (eg, WiFi) may be preferred when higher reliability is required, whereas a lower power network (eg, WiFi) when lower reliability and higher power savings are required. For example, 802.15.4) may be preferred. The sending node may select a different preferred network to note, eg, in the subnet field 1604 of the IPv6 packet header 1600, thereby causing the message to be communicated over that selected network, if possible.

Additional Use Cases

[00293] The fabric of connected devices 1000 discussed above can be used in a variety of ways. An example may include using one device to call a method on another device. Another example may include propagating a message such as a risk alert through various devices in the fabric. It should be understood that these use cases are intended to provide examples and are not intended to be exhaustive.

Calling a method from one device on another device

[00294] In one case, a device in one area of fabric 1000 may invoke a particular method on another compatible device. One example is shown in diagram 1700 of FIG. 60 . Diagram 1700 illustrates interactions between a first device 1702 and a second device 1704 , as mediated by a directory device (DDS) 1706 . A directory device (DDS) 1706 can issue a DDS service broadcast 1708 to various devices on the fabric, including the first device 1702 and the second device 1704 . In response, directory device (DDS) 1706 may receive a list of all methods and/or profiles supported by the various devices in fabric 1000 .

[00295] When one of the devices of the fabric, such as the first device 1702, wants to perform a method (shown in FIG. 60 as method n), the first device 1702 sends a corresponding query message 1710 (eg , GetProperty (support-n)) can query the directory device (DDS) 1706. A directory device (DDS) 1706 can respond with devices that support this feature, where it responds with a message 1712 indicating that the second device 1704 supports the desired method. Now in possession of this information, the first device 1702 can invoke the method in a message 1714 to the second device 1704 . Second device 1704 can then issue response 1716 with an appropriate response.

[00296] The method invoked by the first device 1702 on the second device 1704 may be any of a number of methods that may be useful for a home network. In one example, first device 1702 can request environmental sensor data from second device 1704 . Environmental sensor data may indicate motion, temperature, humidity, and the like. The environmental sensor data can be used by the first device 1702 to determine utilization rates, eg for security, or to determine various temperatures currently located around the house. In another example, the first device 1702 can request user interface input information from the second device 1704 . For example, the first device 1702 can request an indication of recent thermostat temperature setpoints to ascertain information regarding occupants' recent desired accommodation settings.

Propagates messages to various devices in the fabric

[00297] In some circumstances it may be desirable to propagate a message to multiple devices in a fabric. For example, as shown in diagram 1720 of FIG. 61, several devices 1722, 1724, 1726, and 1728 may be used to propagate a danger alert message. Additionally, the danger alert message can be propagated even though one or more of the various devices 1722, 1724, 1726, and 1728 may be low power “sleepy” devices. In the example of FIG. 61 , device 1722 is a garage hazard detector (eg, smoke detector), device 1724 is a dining room hazard detector (eg, smoke detector), and device 1726 is a front door smart door. Bell, and device 1728 is the thermostat in the hallway.

[00298] Operation of diagram 1720 begins when event 1730 (eg, fire) is detected by garage device 1722 . Garage device 1722 can propagate network wake message 1732 to dining room device 1724 , and dining room device 1724 can issue response 1734 accordingly. The dining room device 1724 may temporarily wake up from its sleep state to an awake always-on state. Dining room device 1724 can also propagate network wake message 1736 to hallway device 1726, which likewise propagate another network wake message 1740 to hallway device 1728 while You can respond 1738.

[00299] When devices in the fabric wake up, garage device 1722 can output an alert 1744 associated with event 1730 and can issue an alert notification message 1746 to dining room device 1724 . Alert notification message 1746 may indicate, among other things, the type of event and the originating device (eg, the event occurred in a garage). Dining room device 1724 can output a corresponding alert 1748 and forward an alert notification message to foyer device 1726, which itself can begin outputting alert 1752. . Hallway device 1726 can also forward an alert notification message to hallway device 1728 .

[00300] The hallway device 1728 can display an interface message 1756 to enable the user to respond to the alert. In the meantime, messages can continue to propagate through the fabric. These may include additional network wake and response messages 1758, 1760, 1762, 1764, and 1766, and additional alert notification messages 1768, 1770, and 1772. If the user provides user feedback 1774 on hallway device 1728 requesting that the alarm be silenced (e.g., in the understanding that the alarm is false or due to non-hazardous conditions), hallway device 1728 may respond by sending an alert silence message 1776, which may be propagated to all of the devices through the fabric 1000. The alarm silence message 1776 can reach the foyer device 1726, which silences its own alarm 1778 and sends an additional alarm silence message 1780 to the dining room device 1724. can be issued. In response, dining room device 1724 can silence its alarm 1782 and issue an additional alarm silence message to garage device 1722, which in turn silences its alarm 1786. can silence

[00301] After causing devices 1726, 1724, and 1722 to silence their alerts, hallway device 1728 can cause devices 1726, 1724, and 1722 to re-enter the sleepy low power state. Specifically, hallway device 1728 can issue network sleep message 1790 to hallway device 1726, hallway device 1726 can issue network sleep message 1792 to dining room device 1724, and then You can enter sleepy state. Dining room device 1724 can correspondingly enter a sleep state after issuing network sleep message 1794 to garage device 1722 . Upon receiving network sleep message 1794, garage device 1722 may enter a low power sleep state.

Join a fabric or create a fabric

[00302] The protocols discussed above can be used to create a fabric 1000 or join a fabric 1000 of devices in a home network or similar environment. For example, FIGS. 62-64 relate to a first method in which a new device joins an existing fabric 1000 through another device in the fabric 1000 connected to a service (eg, via the Internet). 65-67 show how a new device joins an existing fabric 1000 or creates a new fabric 1000 through peer-to-peer connections with other devices, regardless of which devices are connected to other services. It relates to the second method. The following examples relate to joining fabric 1000 with a new device that may not have a user interface with a native display, and as such may include assistance from a third party client device (eg, mobile phone or tablet computer). can In other embodiments, such as those where the new device includes a user interface with a native display, activities described below as running on a third-party client device may instead occur on the new device.

Join or create a fabric using an internet connection to the service

[00303] Referring first to the flow chart 1800 shown in FIGS. 62-64 , the user activates the application on a third-party client device (e.g., mobile phone or tablet computer) by opening the box in which the device was sold (block 1802). By obtaining instructions to install (block 1804), a new device can join the fabric 1000. The application may be installed on the client device (block 1806) and the user may log in to a service account associated with the fabric 1000, where the user may select a particular fabric 1000 for the new device to join (block 1806). block 1808). For example, a user can install a Nest® application and log in to a Nest® service account associated with a Nest® Weave™ fabric. An application on a client device may obtain information associated with the service configuration of fabric 1000 (block 1810). Information associated with service configuration of fabric 1000 may include, for example:

● service node identification (eg EUI-64 or EULA);

● a set of certificates that can act as trust anchors for a service (eg, a fabric authentication token);

● Globally unique account identification associated with the user's account;

● a Domain Name Service (DNS) host name that identifies the entry point for the service; and/or

● An opaque account pairing token that can be used by new devices to pair with the user's account.

[00304] The user may also elect to add a new device to the fabric 1000 via an application on the client device (block 1812). Based on whether an existing fabric 1000 associated with the user currently exists or based on any other suitable criteria (decision block 1814), the application is selected to create a new fabric 1000 (block 1816). )), may be selected to add a new device to the existing fabric 1000 (block 1818).

[00305] When the application chooses to add a new device to the existing fabric 1000 (block 1818), the application can determine whether the devices in the network are awake rather than in a sleepy state (decision block 1820) , causes the devices to wake if not awake (block 1822). A user may select a particular existing device in the network for use in the join process, for example, by pressing a button (block 1824). The existing device may provide the fabric-participation information to the application on the client device (block 1826). For example, an application on a client device can use a Fabric 1000 authentication token to establish a secure session with an existing device. An application can obtain network configuration information and/or fabric 1000 configuration information from an existing device using requests (eg, GetNetworkConfiguration and/or GetFabricConfiguration). The application may store this information for later use.

[00306] The application may further instruct the user to wake the new device (block 1828), eg, by pressing a button on the new device (block 1830). The method may then proceed to block (A) 1832 , which continues with FIG. 63 . Here, an application on the client device can instruct the old device to connect to the new device (block 1834). For example, an application can use the fabric authentication token to establish a new secure session to an existing device, and over this new session, it can send a request (eg, ConnectOtherDevice) to the existing device. On the other hand, the new device may have set up an 802.15.4 “participating network” specific to the purpose of joining with the existing device. Accordingly, the request of block 1834 may specify that the application wishes the existing device to connect to the new device via an 802.15.4 network connection (eg, an 802.15.4 participating network created by the new device). . The existing device can then perform a scan of nearby 802.15.4 networks looking for networks created by the new device. Once discovered, the old device leaves the old fabric, joins the new 802.15.4 participating network, and attempts to connect to the rendezvous address (which can be pre-specified by software or firmware on the old device or by an application on the client device). 802.15.4 to probe participating networks. Once the connection to the new device is established, the existing device can respond to a request to connect to the new device (eg, ConnectOtherDevice) from an application on the client device in response to success. From this point on, messages provided to the new device from the application can be forwarded by the proxy through the existing device via the 802.15.4 participating network. That is, new devices can connect to existing devices via 802.15.4 participating networks, existing devices can connect to service nodes via WiFi (and/or Internet connections), and applications on client devices can connect to services. In this way, an application can connect to a new device over the existing fabric, and the existing device can connect to just a single WiFi connection and a single 802.15.4 connection (thereby avoiding the use of multiple receivers and transmitters in an existing device per network type). , which can reduce device cost and power consumption).

[00307] Alternatively, when a new fabric 1000 is to be created, an application on a client device can connect directly to the new device using a WiFi connection. Accordingly, the application on the client device may instruct the user to switch to the WiFi connection (block 1836). The user may switch to WiFi networks on their client device to establish a peer-to-peer WiFi connection with the new device (block 1838). For example, a new device can associate with it a unique WiFi SSID name behind the new device. An application on a client device may probe for a new device by repeatedly attempting to connect to a predetermined rendezvous address (eg, as provided to the application by configuration information from a service or encoded in the application). .

[00308] Upon either of these connections being established, the application on the client device can detect the new device and display the serial number provided by the new device (block 1840). At this time, the application can also validate that the new device installs certain security features on it that identify the device as being positively validated and have the appropriate permissions to participate in the fabric. These security features may be the same as or in addition to the DTLS security certificates discussed above.

[00309] Using either connection, the user scans a QR code or other code associated with the new device (e.g., printed on the new device or on a card provided by the new device) for the application on the client device to prompt the user. may enable the authentication procedure when commanded to do so (block 1842). The user may enter the code into the application by scanning or typing the code (block 1844). This code information can be provided to the new device, and the new device can use the code to confirm that the application is being used by a user in possession of the new device. A new device can validate the code using, for example, a built-in check digit. A new device can indicate when a code has been entered incorrectly by a corresponding response. The application may establish a secure session with the new device using any suitable protocol, including the Weave PASE protocol, using the supplied pairing code as a password (block 1848). Upon establishing a secure connection to the new device, the application on the client device may issue a request (eg, ArmConfigurationFailsafe) to arm for failsafe therapy on the new device (block 1850). By arming the failsafe regime, the new device can revert to specifying the original configurations if the joining process is not completed by some timeout value. The application can also determine whether the new device belongs to another existing fabric 1000 by issuing an appropriate request (eg, GetFabricState) (decision block 1852). If so, the application can instruct the new device to leave the other existing fabric 1000 by issuing another request (eg, LeaveFabric) (block 1854).

[00310] If the new device will form the new fabric 1000 to the old device (decision block 1856), the application sends the new device (e.g., via an EnumerateVisibleNetworks request) a list of WiFi networks visible to the new device. can be commanded to enumerate (block 1858). Upon command from the application (block 1860), the user can then select between these networks or enter the WiFi network that the new device will join (block 1862). The user may also enter the appropriate password to join the WiFi network (block 1864). The method may further proceed to block (B) 1866 , which continues with FIG. 64 . The application may send WiFi network configuration information to the new device (eg, via an AddNetwork request) (block 1868), and the application may attempt to reach a service on the Internet (eg, via a TestNetwork request). The new device may be commanded to test the connection (Block 1870). The application may indicate to the user that the network connection is being verified (block 1872), and the new device may subsequently confirm its connection to the application (block 1874).

[00311] For a new device currently connected to the Internet via a WiFi connection, when a new fabric 1000 is created (block 1876), the application returns the fabric 1000 (e.g., user's home) WiFi connection to the user. (Block 1878). The user may change the WiFi network used by the client device to the WiFi connection used by the fabric 1000 (block 1880).

[00312] Whether creating a new fabric 1000 or joining an existing one, the application can instruct the new device to do so at this point (block 1882). That is, the application can instruct a new device to create a new fabric 1000 (eg, via a CreateFabric request) or a new device to join an existing fabric 1000 (eg, via a JoinExistingFabric request). can be ordered to do. When joining an existing fabric, an application can notify an existing device to a new device (eg, to a new device via a RegisterNewFabricMember request). In either case, the application causes the new device to communicate with the service (eg, Nest® service) by sending a request (eg, RegisterService request) that includes service configuration information (eg, Weave™ service configuration information). can be configured.

[00313] Using the service configuration information, the new device may register for the service (block 1884). For example, a new device can connect to the service using the service node ID and DNS name from the service configuration information. The new device can register for the service using the certificate installed on the new device and private key. The new device may transmit a message (eg, PairDeviceToAccount message) including an account pairing token obtained from the service account identification and service configuration information associated with the fabric 1000 to the service. Using this information, the service can validate the account pairing token and associate the new device with the user's service account associated with the fabric. At this point, the new device may be understood by the service to form part of the fabric 1000, and may appear as an associated device when the user logs into the service. The service can respond to messages from the new device (eg PairDeviceToAccount message), destroy its copy of the account pairing token, and respond to messages previously sent to the application (eg RegisterService request). can do.

[00314] In response, to terminate the new device's participation in the existing fabric 1000 or new fabric, the application can cancel the participating failsafe mechanism by sending a corresponding message (eg, a DisarmConfigurationFailsafe request) to the new device. may (Block 1886). The new device may then receive this request to disarm the configuration failsafe (block 1888). Pairing of the new device to the existing device in the new fabric 1000 or the existing fabric 1000 can now be considered complete. Accordingly, an application on the client device can provide user instructions for additional setup settings (block 1890) that the user can select (block 1892). These may include, for example, continuing pairing of additional devices or an existing setup.

Join or create a fabric without a WiFi connection to the internet

[00315] New devices can join or create fabric 1000 without necessarily having access to services or a WiFi connection to the Internet. For example, as shown in FIGS. 65-67, such a connection may be formed using another network connection without being enabled by a service (eg, only over an 802.15.4 network connection). This section describes actions and events that can occur during the process of joining a new device in a device-to-device fabric. As used herein, a “device-to-device fabric” is a network of two or more Fabric 1000 devices connected through a single network interface (eg, only through 802.15.4 interfaces). Devices in the device-to-device fabric 1000 are not necessarily connected to a WiFi network and, therefore, by applications (e.g., web or mobile) running on client devices (as in FIGS. 62-64) or You may not be talking to a service on the Internet (e.g. Nest® service).

[00316] In some cases, device-to-device fabrics may be easier to form than WiFi fabrics, involving user participation only in that the user can press buttons on two devices within a short period of time. The device-to-device join process illustrated by FIGS. 65-67 is the creation of a new device-to-device fabric 1000 using two independent devices, as well as the creation of a new independent device into an existing device-to-device fabric. Both participations can be supported. Device-to-device participation can also be used to remove a device from an existing device-to-device fabric 1000 and join it to another device-to-device fabric. This latter scenario can be particularly useful when a user captures a device in use that has not been properly disconnected from its previous device-to-device fabric.

[00317] It is noted that the device-to-device join process may not be used to join a new device into an existing WiFi fabric 1000 in some embodiments. In this regard, the user may follow the WiFi join process discussed above with reference to FIGS. 62-64. Also, the device-to-device join process may not be used to join a device that is already a member of the WiFi fabric 1000 to the device-to-device fabric. Thus, if a user catches a used device that was not properly disconnected from its original WiFi fabric, the user can perform a factory reset on the device before proceeding to the device-to-device fabric 1000 subscription process.

[00318] The device-to-device joining process may begin when a first of the two devices to be joined (e.g., device 1) is activated, as shown by flow diagram 1900 of FIG. 65 (block 1902 )). For example, based on commands in the sale box of the first device, the user may press a button on the first device. Here, when a user adds a device to an existing fabric, the user may be instructed to press a button on the device to be added. When a user creates a new fabric 1000 among two independent devices, the user may select one device as a first device. Also, if the first device is a member of the WiFi fabric, the first device may not take any further action and subscription procedure interruptions. When the first device is a member of the WiFi fabric, the first device can be disassociated from the WiFi fabric 1000 before joining the device-to-device network (eg, via a factory reset).

[00319] If not a member of an existing WiFi fabric, a first device (eg, device 1 ), when activated as in block 1902 , may initiate certain initialization procedures. For example, device 1 may start a counter that increments over time (eg, several times per second). This counter will then be used, if appropriate, to determine which of the two devices has priority in establishing the fabric. Device 1 may also create an 802.15.4 wireless network, which may be referred to as an 802.15.4 participating network (block 1904). These 802.15.4 participating networks may generally be proprietary insecure networks. For example, an 802.15.4 participating network typically contains the following information: (a) a string identifying the network as a participating network, (b) the node id of the first device, and (c) whether the device is part of a fabric. A unique ELoWPAN (110) network name including a flag indicating whether or not to use can be used. If the participating network is established, Device 1 may also assign two IPv6 addresses to itself in the participating network (block 1906). These include, for example, (a) an IPv6 ULA or EULA with a separate prefix, which may be referred to as the rendezvous prefix, and an interface identifier derived from the device's MAC address, and (b) a rendezvous prefix, which may be referred to as the rendezvous address, and a 1 It may include an IPv6 ULA or EULA with an interface identifier of

[00320] Device 1 can then continue scanning for 802.15.4 networks created by other devices (block 1908). Indeed, either parallel to or subsequent to the operations of blocks 1902-1908, the second device (device 2) may itself perform the operations (block 1910). Either device 1 or device 2 may detect the other device's participating network (block 1912). Depending on the particular characteristics of the device - device 1 or device 2 - that first detected the other network, the devices may either process the initiating device (e.g., as shown in FIG. 66) or (e.g., as shown in FIG. 67). You can perform a response device process. That is, when one of the devices discovers another device's participating network, the device may compare the information included in the participating network name with its own information, and take the following actions, namely (a) that If the device is an independent device and the other device is a member of a fabric, the device may perform the operations shown in the initiating device process of FIG. 66; or (b) if the device is a member of fabric 1000 and the other device is an independent device, the device may perform the operations shown by the responding device process of FIG. 67 . If neither device is a member of the fabric or both devices are members of the fabric, then a device that detects the other device's participating network may (a) compare its node id to the other device's node id, and (b) If the node id of the device is less than the node id of the other device, the device may perform the operations shown in the initiating device process of FIG. 66 . If neither device is a member of the fabric, or if both devices are members of the fabric, then a device that detects the other device's participating network may (a) compare its node id to the other device's node id, and (b) If the node id of the device is greater than the node id of the other device, the operations shown by the responding device process of FIG. 67 may be performed.

[00321] The device performing the initiating device process of FIG. 66 may be either Device 1 or Device 2, as noted above. Therefore, the device performing the initiating device process of FIG. 66 will now be referred to as the “initiating device”. Similarly, the device performing the responding device process of FIG. 67 may be a device not acting as an initiating device, and may be either device 1 or device 2, as noted above. Therefore, a device performing the responding device process of FIG. 67 will now be referred to as a “responding device”.

[00322] As observed in flow diagram 1920, the initiating device process of FIG. 66 may begin when the initiating device terminates its own participating network and connects to a participating network created by a responding device (block 1922). The initiating device may assign an IPv6 ULA or EULA with a rendezvous prefix and an interface identifier derived from its MAC address (block 1924). The initiating device may send a participation request message to the responding device at its rendezvous address. The join solicitation message from the initiating device contains the following information: (a) a numeric discriminator value set to the value of the counter started when the device woke up, and (b) whether the device is already a member of the fabric. flags may be included. The initiating device may then wait for a response message from the responding device, and receives either an existing fabric join request or a request to join request (block 1928).

[00323] When the initiating device receives the existing fabric join request, the initiating device may, if appropriate, remain in its current fabric, reinitialize itself as an independent device, and use the information in the existing fabric join request to It may make itself part of the existing fabric 1000 for the responding device (Block 1930). The initiating device may send an existing fabric join response to the responding device indicating that it is now a member of existing fabric 1000 (block 1932).

[00324] When an initiating device receives a request to join an existing fabric, it may respond in different ways depending on whether it is an independent device or a member of an existing fabric, but in either case, the request to join an existing fabric Fabric 1000 information may be transmitted (block 1934). For example, if the initiating device is an independent device, the initiating device can create a new fabric 1000 by generating a new fabric id and corresponding fabric security information, make itself part of the new fabric, and A join request may be sent to the responding device. A request to join an existing fabric may include information about a new fabric. Otherwise, that is, if the device is a member of a fabric, the device may send to the responding device an existing fabric join request containing information about the existing fabric 1000 of which the initiating device is a member. The initiating device can then wait and receive an existing fabric join response from the responding device when the responding device joins the initiating device's fabric 1000.

[00325] The responding device process of FIG. 67 describes the manner in which a responding device may behave with respect to an initiating device. The responding device process of FIG. 67 is illustrated by flow diagram 1950 . Flow diagram 1950 begins when a responding device receives a join solicitation message from an initiating device (block 1952).

[00326] If the responding device is an independent device and is not in the existing fabric 1000 (decision block 1954), the responding device may create a new fabric 1000 by generating a new fabric id and corresponding fabric security information ( Block (1956)). The responding device may make itself part of the new fabric 1000 (block 1958). The responding device may then send a request to join an existing fabric to the initiating device that includes information about the responding device's new fabric 1000 (block 1960). The responding device may wait for an existing fabric join response from the initiating device.

[00327] Otherwise, that is, if the responding device is in the existing fabric 1000 upon receipt of the join solicitation message (block 1952) (decision block 1954), the responding device may adopt a different behavior. Specifically, if the responding device is in the fabric, the responding device examines the join solicitation message (block 1962). The responding device checks the discriminator value in the participation claim (the initiating device's counter value) and the flag "member of the fabric".

[00328] Otherwise, that is, if the join claim message indicates that the initiating device is not a member of fabric 1000, or if the discriminator value is greater than or equal to the counter started by the responding device when it woke up. (Decision block 1964), the responding device may send an existing fabric join request to the initiating device that includes information about the responding device's fabric 1000 (block 1974). The responding device may wait for an existing fabric join response from the initiating device.

[00329] If the join claim message indicates that the initiating device is a member of fabric 1000, or if the discriminator value is less than the counter started by the responding device when the responding device woke up (decision block 1964), the responding device reports its It may remain in the current fabric 1000 and reinitialize itself as an independent device (block 1966). The responding device may further send a join request message to the initiating device (block 1968) and may wait for an existing fabric join request from the initiating device. Upon receiving the request to join the existing fabric from the initiating device (block 1970), the responding device may use the information in the request to join the existing fabric to make itself part of the new fabric 1000 (block 1972). )). The responding device may also send an existing fabric join response indicating that it is now a member of the initiating device's existing fabric 1000 .

[00330] It should be understood that the specific embodiments described above have been shown by way of example, and that these embodiments are capable of various modifications and alternative forms. Additionally, it should be understood that the claims are not intended to be limited to the particular forms disclosed, but are intended to cover modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure.

Claims (20)

As a first electronic device,
a memory configured to store instructions enabling the first electronic device to pair with a fabric network comprising a second electronic device;
a processor configured to execute the instructions; and
a network interface configured to access an 802.11 logical network and an 802.15.4 logical network;
These commands are
establish communication with the second electronic device over a first 802.15.4 logical network, the second electronic device being paired with the fabric network and configured to communicate with a service over another logical network in the fabric network;
receive, via the second electronic device, from the service network configuration information enabling the first electronic device to participate in a first 802.11 logical network;
establish communication over the first 802.11 logical network;
connect to the service through the first 802.11 logical network; and
Including pairing instructions for registering to pair with the fabric network through communication with the service,
A first electronic device. According to claim 1,
Pairing instructions to establish communication with the second electronic device over the first 802.15.4 logical network create the first 802.15.4 logical network and from the second electronic device via a rendezvous address. configured to receive communications;
A first electronic device. According to claim 1,
the pairing instructions are configured to receive a code from the service via the second electronic device;
The code originates from a client device that has logged into the service, and the code determines that, if the code matches an expected value stored in the memory of the first electronic device, the user of the client device owns the first electronic device. configured to confirm that you are doing
A first electronic device. According to claim 3,
wherein the pairing instructions are configured to establish communication over the first 802.11 logical network only when the code matches the expected value.
A first electronic device. According to claim 1,
The pairing commands,
disconnect from the first 802.15.4 logical network; and
configured to establish communication over a second 802.15.4 logical network associated with the fabric network if the first electronic device has registered to pair with the fabric network through communication with the service;
A first electronic device. According to claim 1,
A user interface configured to generate a signal in response to activation of the user interface.
A first electronic device. According to claim 6,
Wherein the user interface is configured to send the signal to the processor to initiate pairing of the first electronic device with the fabric network.
A first electronic device. A tangible, non-transitory computer-readable medium containing instructions enabling a first electronic device to pair with a fabric network comprising a second electronic device, comprising:
These commands are
establish communication with the second electronic device over a first 802.15.4 logical network, the second electronic device being paired with the fabric network and configured to communicate with a service over another logical network in the fabric network;
receive, via the second electronic device, from the service network configuration information enabling the first electronic device to participate in a first 802.11 logical network;
establish communication over the first 802.11 logical network;
connect to the service through the first 802.11 logical network; and
Including pairing instructions for registering to pair with the fabric network through communication with the service,
A tangible, non-transitory computer readable medium. According to claim 8,
Pairing instructions to establish communication with the second electronic device over the first 802.15.4 logical network create the first 802.15.4 logical network and from the second electronic device via a rendezvous address. configured to receive communications;
A tangible, non-transitory computer readable medium. According to claim 8,
the pairing instructions are configured to receive a code from the service via the second electronic device;
The code originates from a client device that has logged into the service, and the code determines that, if the code matches an expected value stored in the memory of the first electronic device, the user of the client device owns the first electronic device. configured to confirm that you are doing
A tangible, non-transitory computer readable medium. According to claim 10,
wherein the pairing instructions are configured to establish communication over the first 802.11 logical network only when the code matches the expected value.
A tangible, non-transitory computer readable medium. According to claim 8,
The pairing commands,
disconnect from the first 802.15.4 logical network; and
configured to establish communication over a second 802.15.4 logical network associated with the fabric network if the first electronic device has registered to pair with the fabric network through communication with the service;
A tangible, non-transitory computer readable medium. According to claim 8,
wherein the pairing instructions are configured to generate a signal in response to activation of a user interface;
A tangible, non-transitory computer readable medium. According to claim 13,
Wherein the pairing instructions are configured to initiate pairing of the first electronic device with the fabric network based on the signal.
A tangible, non-transitory computer readable medium. A method comprising executing instructions through a processor of a first electronic device enabling a first electronic device to pair with a fabric network comprising a second electronic device, comprising:
These commands are
establish communication with the second electronic device over a first 802.15.4 logical network, the second electronic device being paired with the fabric network and configured to communicate with a service over another logical network in the fabric network;
receive, via the second electronic device, from the service network configuration information enabling the first electronic device to participate in a first 802.11 logical network;
establish communication over the first 802.11 logical network;
connect to the service through the first 802.11 logical network; and
Including pairing instructions for registering to pair with the fabric network through communication with the service,
method. According to claim 15,
Pairing instructions to establish communication with the second electronic device over the first 802.15.4 logical network create the first 802.15.4 logical network and from the second electronic device via a rendezvous address. configured to receive communications;
method. According to claim 15,
receiving a code from the service via the second electronic device;
The code originates from a client device that has logged into the service, and the code determines that, if the code matches an expected value stored in the memory of the first electronic device, the user of the client device owns the first electronic device. configured to confirm that you are doing
method. According to claim 17,
establishing communication over a first 802.11 logical network only when the code matches the expected value.
method. According to claim 15,
disconnecting from the first 802.15.4 logical network; and
establishing communication over a second 802.15.4 logical network associated with the fabric network if the first electronic device has registered to pair with the fabric network through communication with the service;
method. According to claim 15,
generating a signal in response to activation of the user interface; and
Sending the signal to the processor to initiate pairing of the first electronic device with the fabric network.
method.

Images