Threads over Internet Protocol

Abstract

Describe a technique and device for a node in a thread network to determine a preferred physical layer for communication. The node transmits a first IPv6, 6LoWPAN frame (502) on a low-power wireless personal area network to a neighbor node using a first physical layer, and transmits a first 6LoWPAN frame (504) to the neighbor node using a second physical layer. The node determines a first preference value (506) of the neighbor node using the first physical layer, and determines a second preference value (508) of the neighbor node using the second physical layer. The node compares the first preference value and the second preference value to determine a preferred physical layer for communication (510), and transmits a second 6LoWPAN frame (512) to the neighbor node using the preferred physical layer.

Description

BACKGROUND OF THE INVENTION

[0001] Wirelessly connecting devices to each other and to cloud-based services is increasingly being used for sensing environmental conditions, controlling devices, and providing information and alerts to users. Many devices on a wireless network are designed to operate for extended periods on battery power, which limits the computing, user interface, and radio resources available in these devices.

[0002] The Thread 1.1 network is designated to operate over an IEEE 802.15.4 radio network. Thread networks are designed to operate without a single point of failure and will automatically organize into separate Thread partitions when there is no connectivity between two or more groups of devices. Thread partitions allow devices to maintain communication with other devices in the same Thread partition. Because Thread is still an emerging technology, the coverage of Thread networks may be limited in many cases. As a result, Thread partitions are likely to occur when Thread deployments are sparse and, therefore, there is an opportunity to enhance device connectivity in Thread networks. SUMMARY OF THE INVENTION

[0003] This Summary of the Invention is provided to introduce a concept of Thread over Internet Protocol and generally relates to providing connectivity using multiple networking technologies in a fabric network for IPv6 communication. These concepts are further described in the Detailed Description below. This Summary of the Invention is not intended to identify essential features of the claimed subject matter nor is it intended to be used to determine the scope of the claimed subject matter.

[0004] In various aspects, methods, devices, systems, and apparatuses for Thread over Internet Protocol are described for determining a preferred physical layer for communication by a node in a network, particularly a Thread network. The node transmits a first IPv6, 6LoWPAN frame over a low-power wireless personal area network to a neighbor node using a first physical layer and transmits the first 6LoWPAN frame to the neighbor node using a second physical layer. The node determines a first preference value for the neighbor node using the first physical layer and determines a second preference value for the neighbor node using the second physical layer. The node compares the first preference value and the second preference value to determine a preferred physical layer for communication and transmits a second 6LoWPAN frame to the neighbor node using the preferred physical layer.

[0005] Details of one or more implementations are set forth in the accompanying drawings and the following description. Other features and advantages will be apparent from the description and drawings, and from the claims. This Summary of the Invention is provided to introduce the subject matter further described in the Detailed Description and Drawings. Accordingly, this Summary of the Invention should not be considered to describe essential features nor be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Aspects of Thread over Internet Protocol are described with reference to the following figures. The same numbers are used throughout the figures to refer to the same features and components:

[0007] Figure 1 An example network environment is shown in which aspects of Thread over Internet Protocol may be implemented.

[0008] Figure 2 An example environment is shown in which aspects of Thread over Internet Protocol may be implemented.

[0009] Figure 3 An example network protocol stack is shown that may be used to implement aspects of Thread over Internet Protocol.

[0010] Figure 4 An example message format is shown that may be used to implement aspects of Thread over Internet Protocol.

[0011] Figure 5 An example method of a network node is shown in accordance with one or more aspects of the techniques described herein.

[0012] Figure 6 An example environment is shown in which aspects of the techniques described herein may be implemented.

[0013] Figure 7 An example wireless network device that may be implemented in a home local area network is shown in accordance with one or more aspects of the techniques described herein.

[0014] Figure 8 An example system is shown having an example device that may implement aspects of Thread over Internet Protocol. Detailed Description

[0015] This document details how a Thread device incorporates Internet Protocol (IP)-based link technologies (e.g., Wi-Fi and / or Ethernet) into a Thread network topology. Doing so allows a Thread network to leverage the advantages of Wi-Fi and Ethernet, including higher throughput, larger channel capacity, and / or coverage, while still supporting low-power devices that must operate on limited batteries for many years. At the same time, devices implementing Thread over Internet Protocol remain fully backward compatible with earlier versions of the Thread specification.

[0016] Wi-Fi is complementary to Thread in many ways. The popularity of Wi-Fi has motivated many consumers to ensure Wi-Fi coverage throughout their homes. The emergence of Wi-Fi mesh solutions has also helped to improve Wi-Fi coverage. At the same time, Wi-Fi provides higher throughput, higher channel capacity, and additional communication frequencies at the cost of higher power consumption.

[0017] From the very beginning, Thread was designed to provide network connectivity with no single point of failure in the network. As a self-healing mesh network, this principle of robustness maintains device-to-device communication as long as there is a communication path between a group of communicating devices. This is in contrast to Wi-Fi networks, which typically rely on a single wireless access point to provide connectivity.

[0018] While a Thread network is defined by a group of devices sharing the same Thread network credentials, a Thread partition is a group of Thread devices that are connected to each other within a given Thread network. In other words, within a Thread partition, there is a communication path between every pair of devices in the partition. Thread automatically forms partitions based on the observed connectivity between devices. Since connectivity is time-varying (especially for wireless communication), a given partition may split into multiple partitions when connectivity is lost. Conversely, if connectivity is restored between multiple partitions, the multiple partitions can merge into a single partition.

[0019] Each Thread partition has a dynamically elected leader device. The leader device periodically increments a sequence number and propagates the updated value via Mesh Link Establishment (MLE) advertisements. Thread devices determine whether they are connected to the partition by observing the sequence number value of the leader when receiving MLE advertisements. If a Thread device does not see the sequence number of the leader change for a period of time, the Thread device determines that it has become disconnected from the leader device.

[0020] After losing connectivity, a device attempts to attach to another partition. If no such partition exists, it forms its own partition and declares itself the leader. Adjacent devices that have also lost connectivity perform the same process. If a large group of devices is partitioned simultaneously, many of these devices may form their own partitions even though they may still have connectivity. Eventually, the group of connected devices will merge into a single partition using Thread's partition merging mechanism.

[0021] Since Thread devices must be in the same Thread partition to communicate via the Thread mesh network, the Thread network protocol continuously seeks to merge partitions as much as possible. Each partition is identified by a partition identifier (ID) randomly selected by the leader device when the partition is formed. Thread devices include the partition ID in the MLE advertisement. If a device receives an MLE advertisement with a higher partition ID than its own, the device will attempt to attach to the new partition and leave its current partition.

[0022] A partitioned thread network can pose significant challenges. For example, devices in different thread partitions cannot communicate using the thread mesh network, but can communicate via a thread border router using other IP-based networks. However, supporting this approach significantly increases the complexity of dynamically managing multiple IPv6 subnets and the routing between them. In another example, partitioning and merging thread network partitions is costly because the affected devices must reattach to the network as end devices, devices with router capabilities need to obtain new router IDs, the routing topology needs to be formed and / or updated, the border router needs to inject new network data, and so on. This increases a significant amount of control message passing overhead. During this time, application data messages may be significantly delayed or lost. In another example, managing multiple partitions can be confusing for end users. When debugging a new device on a thread network, the user must somehow determine the thread border router attached to the thread partition that can provide connectivity to the joining device. When updating thread network parameters, the user must manually configure each partition separately.

[0023] Wi-Fi and thread network technologies complement each other as IP-based link technologies. While Thread is well-suited for low-power devices, Wi-Fi offers higher throughput and capacity. At the same time, with the emergence of Wi-Fi mesh solutions, the Wi-Fi coverage in consumer homes has also increased significantly. While Thread is an emerging technology, Wi-Fi may have a wider coverage in consumer homes before Thread is more widely deployed. Combining Wi-Fi and IEEE 802.15.4 links in a single thread topology can combine their advantages and address the problems posed by partitioned thread networks.

[0024] Although a thread network can consist of multiple thread partitions, a thread domain can consist of multiple thread networks. A thread domain combines multiple thread networks into a single IPv6 subnet, enabling devices to maintain a stable IPv6 address even when roaming between different thread networks within the same domain. Although a thread domain uses Wi-Fi and / or Ethernet as backbone links to stitch multiple thread networks into a single IPv6 subnet, previous versions of Thread (e.g., Thread 1.2) did not provide any mechanism for a given thread partition to utilize Wi-Fi or Ethernet in its routing topology.

[0025] Example Environment

[0026] Figure 1 An example network environment 100 is shown in which aspects of Thread over Internet Protocol can be implemented. The network environment 100 (e.g., a fabric network, a thread network, an IP Connected Home (CHIP) network, a woven network) includes one or more network segments that form a home area network (HAN), such as HAN 200, which is described below with reference toFigure 2 is described. The HAN includes a wireless network device 102, which is disposed around a structure 104 such as a house and is connected by one or more wireless and / or wired network technologies, as described below. The HAN includes a border router 106, which connects the HAN to an external network 108 (access network 108), such as the Internet, via a home router or access point 110.

[0027] To provide a user with access to functions implemented using the wireless network device 102 in the HAN, a cloud service 112 is connected to the HAN via the border router 106, via a secure tunnel 114 through the external network 108 (access network 108) and the access point 110. The cloud service 112 uses a network-based application programming interface (API) 118 to facilitate communication between the HAN and an Internet client 116, such as an application on a mobile device. The cloud service 112 also manages a home map that describes the connections and relationships between the elements of the wireless network device 102, the structure 104, and the users. The cloud service 112 hosts a controller that coordinates and arbitrates the home automation experience, as described in more detail below.

[0028] The HAN may include one or more wireless network devices 102 that act as a hub 120. The hub 120 can be a general-purpose home automation hub or a dedicated hub, such as a security hub, an energy management hub, an HVAC hub, etc. The functionality of the hub 120 can also be integrated into any wireless network device 102, such as a smart thermostat device or the border router 106. In addition to hosting the controller on the cloud service 112, the controller can be hosted on any hub 120 in the structure 104, such as the border router 106. The controller hosted on the cloud service 112 can be dynamically moved to a hub 120 in the structure 104, such as moving an HVAC zone controller to a newly installed smart thermostat. Hosting functionality on a hub 120 in the structure 104 can improve reliability when the user's Internet connection is unreliable, can reduce the latency of operations that typically have to connect to the cloud service 112, and can meet system and regulatory constraints regarding local access between wireless network devices 102.

[0029] The wireless network devices 102 in the HAN can be from a single manufacturer that also provides the cloud service 112, or the HAN can include wireless network devices 102 from partners. These partners can also provide a partner cloud service 122, which provides services related to their wireless network devices 102 via a partner Web API 124. The partner cloud service 122 can optionally or additionally provide services to the Internet client 116 via the network-based API 118, the cloud service 112, and the secure tunnel 114.

[0030] The network environment 100 can be implemented on various hosts, such as battery-powered microcontroller-based devices, line-powered devices, and servers hosting cloud services. Protocols operating in the wireless network device 102 and the cloud service 112 provide a variety of services that support the operation of a home automation experience in the distributed computing environment 100. These services include, but are not limited to, real-time distributed data management and subscriptions, command and response control, real-time event notifications, historical data logging and storage, password-controlled security groups, time synchronization, network and service pairing, and software updates.

[0031] Figure 2An example environment (e.g., a fabric network, a woven network, a CHIP network) is shown in which various aspects of Thread over Internet Protocol can be implemented. A home area network (HAN, Thread network) 200 may include a wireless mesh network segment 202 (e.g., a Thread network segment), a Wi-Fi network segment 204, and / or an Ethernet segment 212. The mesh network segment 202 is a wireless personal area network (WPAN) that implements the Thread specification, particularly Thread specification 1.0, 1.1, 1.2, or any subsequent version. For example, the mesh network segment 202 may be compatible with version 1.1 and / or version 1.2 of the Thread specification. The Wi-Fi segment 204 is a wireless local area network (WLAN) that implements the IEEE 802.11 standard, particularly the 1997 IEEE 802.11 standard and / or any subsequent versions such as 802.11b, 802.11g, 802.11n, 802.11ac, 802.11ax, and 802.11ad. For example, the Wi-Fi segment 204 may be compatible with one or more (e.g., all) of these versions. The wireless mesh network segment 202 includes a router 206 and end devices 208. The router 206 and the end devices 208 each include a mesh network interface for communicating over the mesh network segment 202. The router 206 receives and transmits packet data through the mesh network interface. The router 206 also routes traffic over the mesh network segment 202. The end devices 208 are devices that can communicate using the mesh network segment 202 but lack the ability to route traffic in the mesh network segment 202 other than simply forwarding to their parent router 206. One or more of the end devices 208 may be battery-powered. For example, a battery-powered sensor is one type of end device 208. The Wi-Fi network segment 204 includes Wi-Fi devices 210. Each Wi-Fi device 210 includes a Wi-Fi network interface for communicating over the Wi-Fi network segment 204. Optionally or additionally, the HAN 200 may include an Ethernet network segment 212, which includes one or more Ethernet devices 214 connected to a border router 106 or an access point 110. The Ethernet network segment 212 may be compatible with any version of the IEEE 802.3 standard, such as 802.3cu or any previous version.

[0032] The border router 106 is included in the wireless mesh network segment 202 and is included in the Wi-Fi network segment 204. The border router 106 includes a mesh network interface for communicating through the mesh network segment 202 and a Wi-Fi network interface for communicating through the Wi-Fi network segment 204. The border router 106 routes packets between devices in the wireless mesh network segment 202 and the Wi-Fi network segment 204. The border router 106 also routes packets between devices in the HAN 200 and external network nodes (e.g., cloud service 112) via a home router or access point 110 through an access network 108 (such as the Internet).

[0033] Devices in the mesh network segment 202, the Wi-Fi network segment 204, and the Ethernet network segment 212 communicate with each other using standard IP routing configurations and a transport protocol such as the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP). When devices in the mesh network segment 202, the Wi-Fi network segment 204, and / or the Ethernet network segment 212 are provided as part of a braided network, a fabric network, or a CHIP network, these devices can convey messages through these same UDP and / or TCP transports.

[0034] Thread Radio Encapsulated Link (TREL) devices (nodes) support multiple physical layer communications, such as IEEE 802.15.4, Wi-Fi, and / or Ethernet. For example, the TREL device 220 supports IEEE 802.15.4 for communicating through the wireless mesh network segment 202 and the Wi-Fi network segment 204. In another example, the TREL device 222 supports IEEE 802.15.4 for communicating through the wireless mesh network segment 202 and the Ethernet network segment 212. TREL nodes communicate using the TREL network stack, which will be described below with reference to Figure 3 be described.

[0035] Thread Radio Encapsulated Link (TREL) network stack

[0036] Figure 3 An example of a Thread Radio Encapsulated Link (TREL) network protocol stack 300 that can be used to implement aspects of Thread over Internet Protocol is shown. In one aspect, a thread device can use the multi-physical layer (multi-phy, multi-PHY) link layer of the TREL network stack 300 to utilize multiple IP-based link technologies. The TREL network stack 300 provides backward compatibility for the IEEE 802.15.4 wireless network used in previous versions of Thread (e.g., Thread 1.1 and 1.2).

[0037] The TREL network stack 300 includes support for an application 302 having a Mesh Link Establishment (MLE) protocol layer 304, a Thread Management Framework (TMF) protocol layer 306, and a Constrained Application Protocol (CoAP) protocol layer 308. In the TREL network stack 300, thread messages are transported by a Transmission Control Protocol (TCP) layer 310 or a User Datagram Protocol (UDP) layer 310, an Internet Protocol Version 6 (IPv6) layer 312, and an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) protocol layer 314.

[0038] To minimize changes to existing versions of the Thread network protocol, the multi-phy link layer 316 presents a single link interface to the upper layers of the TREL network stack 300 for one or more physical layers (PHYs). From a network layering perspective, the multi-phy link layer 316 is located below the 6LoWPAN protocol layer 314. 6LoWPAN frames are addressed using short addresses or extended addresses defined in the 1.1 version Thread specification. The multi-phy link layer 316 has a short address and an extended address. The multi-phy link layer 316 is responsible for determining which PHY to use when transmitting to an adjacent device. In some cases, a neighbor may be reachable via multiple PHYs simultaneously.

[0039] The Thread Radio Encapsulation Link (TREL) protocol layer 318 enables the transmission of 6LoWPAN frames over IP link technologies including Wi-Fi or Ethernet. The TREL protocol layer 318 uses transport layer protocols (such as TCP and / or UDP) and network layer protocols (such as IPv4 and / or IPv6) to encapsulate IEEE 802.15.4 MAC frames. In one alternative, when using a Thread-based protocol (e.g., MLE) to discover adjacent TREL devices, the TREL protocol layer 318 assumes a single broadcast domain, so all TREL packets use link-local IPv6 addressing. In another alternative, TREL neighbors can be manually configured (e.g., by an administrator) or automatically configured (e.g., using Domain Name Service - Service Discovery (DNS-SD)). In the case of this global address scope, TREL neighbors do not need to be attached to the same physical link and can be any reachable IPv4 or IPv6 destination.

[0040] When the multi-phy link layer 316 determines that a 6LoWPAN frame will be transmitted using the IEEE 802.15.4 network, the multi-phy link layer 316 passes the 6LoWPAN frame to the IEEE 802.15.4 Media Access Control (MAC) protocol layer 320 and the IEEE 802.15.4 Physical (PHY) protocol layer 322 for transmission on the Thread network. In one option, the TREL device can omit the IEEE 802.15.4 communication hardware (radio) and use only IP-based communication (Wi-Fi and / or Ethernet) for communication in the Thread network. When the multi-phy link layer 316 determines that a 6LoWPAN frame will be transmitted using an IP link technology, the multi-phy link layer 316 passes the 6LoWPAN frame to the TREL protocol layer 318, which transmits the 6LoWPAN frame in a TREL packet using an IP link interface such as the Wi-Fi MAC protocol layer 324 and the Wi-Fi PHY protocol layer 326, the Ethernet MAC protocol layer 328 and the Ethernet PHY protocol layer 330, or any other suitable IP link technology. For example, the 6LoWPAN frame complies with RFC 4944, RFC 6282, and / or RFC 6775.

[0041] The multi-phy link protocol and the Thread Border Router protocol are independent of each other. A device implementing the multi-phy link protocol may or may not implement the Thread Border Router. The multi-phy link protocol is a link layer mechanism, while the Thread Border Router feature is a network layer mechanism.

[0042] Multi-PHY Link Layer

[0043] The multi-phy link layer 316 maintains an information base that includes a PHY preference set, a set of received 6LoWPAN frames, and a set of TREL outstanding acknowledgments. The multi-phy link layer 316 records the preference values in the PHY preference set for determining which PHY layer to use when transmitting to an adjacent device. The multi-phy link layer 316 maintains a PHY preference set for each PHY it supports. The PHY preference set includes neighbor preference tuples, and a neighbor preference tuple includes an extended address and a preference. The extended address is the IEEE 802.15.4 extended address used to communicate with an adjacent device, and the preference is the preference value associated with the PHY associated with using it when communicating with an adjacent device.

[0044] Each PHY preference set contains one neighbor preference tuple for each MLE neighbor entry. When the MLE creates a new neighbor entry, a new neighbor preference tuple is created with an initial preference value of zero. When the MLE removes a neighbor entry, the associated neighbor preference tuple is also removed.

[0045] The multi-phy link layer 316 records the most recent 6LoWPAN frames received from a given neighbor in the received 6LoWPAN frame set. When updating the 6LoWPAN frame set, the multi-phy link layer 316 does not include 6LoWPAN frames that are not from a direct neighbor that includes a mesh addressing header. The multi-phy link layer 316 maintains a single received 6LoWPAN frame set. The received 6LoWPAN frame set includes neighbor frame tuples, which include an extended address, a datagram tag, and a datagram offset. The extended address is the IEEE 802.15.4 extended address used to communicate with an adjacent device. The datagram tag is the most recent 6LoWPAN fragment header datagram_tag received from the adjacent device. The datagram offset is the most recent 6LoWPAN fragment header datagram_offset received from the adjacent device.

[0046] The multi-phy link layer 316 records the number of unacknowledged TREL packets when transmitting to an adjacent device in the TREL pending acknowledgment set. The TREL pending acknowledgment set includes neighbor pending acknowledgment tuples, which include an extended address, a current pending Ack (acknowledgment), a previous pending Ack, and a packet number. The extended address is the IEEE 802.15.4 extended address used to communicate with an adjacent device. The current pending Ack is the number of TREL Ack (acknowledgment) packets that the TREL protocol layer 318 is waiting to receive during the current time window for a transmitted packet. The previous pending Ack is the number of TREL Ack packets that the TREL protocol layer 318 was waiting to receive during the previous time window for a transmitted packet. The packet number is the packet number used when sending the next TREL packet to the neighbor identified by the extended address.

[0047] The Thread network protocol uses broadcast transmissions to discover adjacent devices. For example, MLE announcements, MLE discovery requests, and MLE advertisement messages are sent with IPv6 link-local multicast destination addresses that map to link layer broadcast transmissions.

[0048] In one aspect, to continue to support the same discovery mechanism as previous versions of Thread, the multi-phy link layer 316 transmits all 6LoWPAN frames destined for the broadcast address on all supported PHYs. For example, a device that supports both IEEE 802.15.4 and Wi-Fi transmits each MLE advertisement on both IEEE 802.15.4 and Wi-Fi.

[0049] In an alternative aspect, the feature of separating discovery messages from normal data communication is the IEEE 802.15.4 MAC frame security configuration. All messages for discovery disable MAC frame security, or utilize MAC key ID mode 2. All data communication uses MAC key ID mode 1. The multi-phy link layer 316 identifies 6LoWPAN discovery frames with the destination address set to the broadcast address (0xffff), and MAC frame security is disabled or enabled with MAC key ID mode 2. To continue to support the same discovery mechanism as the previous version of Thread, the multi-phy link layer 316 transmits all 6LoWPAN discovery frames on all supported PHYs. For example, a device that supports both IEEE 802.15.4 and Wi-Fi transmits each 6LoWPAN discovery frame on both IEEE 802.15.4 and Wi-Fi. When transmitting a 6LoWPAN frame to the broadcast address but not a 6LoWPAN discovery frame, the multi-phy link layer 316 transmits on each PHY where the PHY has the highest priority value for at least one neighboring device with an active link. The destination address of a 6LoWPAN frame with an extended address or short address not set to the broadcast address (0xffff) is sent via unicast message transmission.

[0050] For IEEE 802.15.4 direct transmissions (MAC frame transmissions initiated by the device itself rather than sent in response to receiving an IEEE 802.15.4 data request frame), the multi-phy link layer 316 selects the PHY with the highest priority value for a given destination. If there is no priority value for a given neighbor and the message is an MLE discovery response, the multi-phy link layer 316 transmits the 6LoWPAN frame on the same PHY used to receive the associated MLE discovery request. Otherwise, the multi-phy link layer 316 transmits the 6LoWPAN frame on all supported PHYs. Transmitting on all supported PHYs allows the device to synchronize parent-child links after a reset without the need to store and update PHY priorities in non-volatile storage. If more than one PHY shares the same maximum priority value, the multi-phy link layer 316 selects from the subset of PHYs sharing the same maximum priority value as follows: (i) when transmitting an IEEE 802.15.4 data request frame, the multi-phy link layer 316 selects the PHY with the lowest power profile to complete the indirect transmission, or (ii) when transmitting any other frame, the multi-phy link layer 316 selects the PHY with the highest channel capacity.

[0051] For IEEE 802.15.4 indirect transmission, (data frame transmission in response to receiving an IEEE 802.15.4 data request frame), the thread router that forwards the data frame via indirect transmission uses the same PHY as the received associated IEEE 802.15.4 data request frame to transmit the data frame. When transmitting a data frame via indirect transmission, the PHY priority value is not used.

[0052] Given a 6LoWPAN frame that can be transmitted over multiple PHYs, a receiver may receive the same 6LoWPAN frame multiple times via different PHYs. To suppress duplicate frames, a frame identifier is included in the 6LoWPAN frame itself. When transmitting a 6LoWPAN frame with IEEE802.15.4 MAC security enabled, the 6LoWPAN frame includes a 6LoWPAN fragmentation header, even if the encapsulated IPv6 datagram is small and does not require 6LoWPAN fragmentation. The multi-phy link layer 316 uses the datagram_tag of the fragmentation header to suppress duplicate frames.

[0053] Reachability on a given PHY is time-varying, either due to time-varying wireless communication characteristics or because of link infrastructure state changes (e.g., a Wi-Fi interface goes up or down). Although a given PHY is typically more desirable (e.g., Wi-Fi over 802.15.4 due to throughput and capacity reasons), communication may occur on a less desirable PHY when a neighbor is unreachable on the more desirable PHY. The more desirable PHY is defined as the PHY that would be selected if the associated priority values were the same.

[0054] When performing direct transmission, the multi-phy link layer 316 supports link probing to help discover reachability via the more desirable PHY shortly after connectivity is restored. The following procedure is used to send reachability probes:

[0055] 1. After selecting a PHY for a given direct transmission as described above, the multi-phy link layer 316 identifies all other PHYs supported by the destination.

[0056] 2. If there is no more desirable PHY, the procedure exits here.

[0057] 3. The device performs a random trial that returns a value of 1 with a probability set to the REACHABILITY_PROBE_PROBABILITY value and a value of 0 in all other cases. If the value returned by the random trial is zero, the procedure exits here.

[0058] 4. Except for the previously selected PHY as described above for direct transmission, the device performs a reachability probe by sending the same 6LoWPAN frame on the more desirable PHY.

[0059] Reachability detection effectively transmits duplicate 6LoWPAN frames over different PHYs. One advantage of transmitting duplicate 6LoWPAN frames is the ability to achieve redundancy in data transmission, giving neighbors an additional opportunity to receive the 6LoWPAN frame. Another advantage of transmitting duplicate 6LoWPAN frames is to use existing logic to handle acknowledgments and minimize the dedicated logic for reachability detection.

[0060] When the multi-phy link layer 316 processes a message, the multi-phy link layer 316 uses the following procedure to suppress duplicate messages:

[0061] 1. If the 6LoWPAN frame does not have MAC security enabled, the procedure exits here.

[0062] 2. If the 6LoWPAN frame does not have a 6LoWPAN fragmentation header, the procedure exits here.

[0063] 3. If the datagram_tag of the fragmentation header is greater than the datagram tag of the associated neighbor, the procedure exits here.

[0064] 4. If any of the following is true, the frame is marked as duplicate:

[0065] (i) The datagram_tag of the fragmentation header is less than the datagram tag of the associated neighbor, or

[0066] (ii) The datagram_offset of the fragmentation header is less than or equal to the datagram offset of the associated neighbor.

[0067] When comparing two datagram_tag values, the multi-phy link layer 316 uses the sequence number algorithm defined in IETF RFC1982. If the 6LoWPAN frame is marked as duplicate, the multi-phy link layer 316 does not pass the frame up to the next higher layer of the TREL network stack 300 for processing.

[0068] Each time an IEEE 802.15.4 MAC frame with MAC security and MAC key ID mode 1 enabled is received from a given PHY, the multi-phy link layer 316 updates the PHY preference set associated with the PHY that received the message. When increasing the preference value of an associated neighbor, when receiving a message via the TREL protocol layer 318, the multi-phy link layer 316 increases the preference value by using the PHY_PREF_TREL_RX_SUCCESS_INCREASE function, or when receiving a message via the IEEE 802.15.4 radio (PHY), increases the preference value by using the PHY_PREF_802154_RX_SUCCESS_INCREASE function.

[0069] When transmitting a message using IEEE 802.15.4, the multi-phy link layer 316 performs the following update process on the PHY preference set each time a data transmission request with a request for confirmation (ACK) (e.g., IEEE 802.15.4 MCPS-DATA.confirm) is completed:

[0070] 1. When the data transmission request is completed (MCPS-DATA.confirm), retrieve the associated neighbor preference tuple from the PHY preference set of the 802.15.4 PHY. If there are no entries, the process exits here.

[0071] 2. If the data transmission request is successful (ACK successfully received), the preference value of the associated neighbor is increased by PHY_PREF_802154_TX_SUCCESS_INCREASE (e.g., the preference value is increased by 1).

[0072] 3. If the data transmission request is unsuccessful due to channel access failure or failure to receive an ACK, the preference of the associated neighbor is decreased by the value PHY_PREF_802154_TX_FAILURE_DECREASE (e.g., the preference value is decreased by 1).

[0073] Thread Radio Encapsulation Link Layer

[0074] The Thread Radio Encapsulation Link (TREL) layer 318 enables Thread devices to communicate directly via an IPv6-based link technology rather than IEEE 802.15.4, including Wi-Fi and Ethernet. Thread devices communicating using the TREL network protocol stack 300 are connected to the same IPv6 link. The TREL network protocol stack 300 can use wide-area communication to reach neighboring nodes, or use link-local IPv6 communication to reach neighboring devices.

[0075] The TREL interface is configured with the same link-local IPv6 address as the address assigned to the thread interface. That is, the TREL interface has been configured with a link-local IPv6 address that is derived from the same MAC extension address used on the IEEE 802.15.4 radio. Using the same link-local IPv6 address avoids the need to discover and maintain an address mapping between the TREL and the thread interface.

[0076] Figure 4 Illustrates example message formats that can be used to implement aspects of Thread over Internet Protocol. The Thread Radio Encapsulation Link (TREL) layer 318 uses UDP messages to transport IEEE 802.15.4 MAC frames.

[0077] The TREL message 400 includes a version field 402, which is a 3-bit unsigned integer that indicates the version of the TREL protocol. For example, the initial version of TREL sets the version field 402 to a zero value. The TREL message 400 includes a 2-bit Reserved (Rsv) field 404 that is reserved for future use. The Rsv field 404 is set to a zero value for transmission and is ignored after reception.

[0078] The TREL message 400 includes a 1-bit A field 406. The A field 406 is set to the value 1 to indicate that the sending device is requesting a TREL Ack packet for the TREL message 400, or is set to the value 0 to indicate that no TREL Ack is being requested for the TREL message 400.

[0079] The TREL message 400 includes a Type (Typ) field 408, which is a 2-bit unsigned integer. The Typ field 408 indicates the TREL packet type. The Typ field 408 is set to the value 0 to indicate that the TREL packet is a TREL broadcast packet, is set to the value 1 to indicate that the TREL packet is a TREL unicast packet, or is set to the value 2 to indicate that the TREL packet will indicate a TREL Ack.

[0080] The TREL message 400 includes a channel field 410, which is an 8-bit unsigned integer. The channel field 410 indicates the IEEE 802.15.4 channel that will be used to transmit the message using the IEEE 802.15.4 PHY. The TREL message 400 includes an 802.15.4 destination PAN ID field 412, which is a 16-bit unsigned integer (big-endian format). The 802.15.4 destination PAN ID field 412 is the IEEE 802.15.4 destination PAN ID encapsulated in the 6LoWPAN frame. If the frame does not have an 802.15.4 destination PAN ID, the broadcast PAN ID (0xffff) is used.

[0081] The TREL message 400 includes a packet number field 414, which is a 32-bit unsigned integer (big-endian format). The content of the packet number field 414 is the packet number associated with a specific TREL packet.

[0082] The TREL message 400 includes an 802.15.4 extended source address field 416, which is a 64-bit field (big-endian format). The content of the 802.15.4 extended source address field 416 is the IEEE 802.15.4 extended address associated with the sender of a given message.

[0083] The TREL message 400 may include an 802.15.4 extended destination address field 418, which is a 64-bit field (big-endian format). The 802.15.4 extended destination address field 418 is included when the TREL packet type is unicast or Ack. The content of the 802.15.4 extended destination address field 418 is the IEEE 802.15.4 destination address associated with the receiver of a given message.

[0084] The TREL message 400 includes an 802.15.4 MAC frame field 420, which is a variable-length field. The 802.15.4 frame field 420 includes an IEEE 802.15.4 frame, which includes an 802.15.4 MAC header, MAC payload, and MAC footer. The encapsulated 802.15.4 MAC frame is the same as that transmitted using the 802.15.4 radio. The 802.15.4 frame field 420 is included when the TREL packet type (Typ 408) is unicast or broadcast.

[0085] The Thread Radio Encapsulation Link (TREL) layer 318 sets the IPv6 source address of the TREL message to the link-local address assigned to the Thread interface (a link-local address derived from the MAC extended address used on the IEEE 802.15.4 radio). When the IEEE 802.15.4 MAC frame 420 contains a destination address that is an extended address or short address other than the broadcast address, the TREL layer 318 sets the IPv6 destination address field 418 to the link-local address assigned to the Thread interface of the destination node (the link-local address is derived from the MAC extended address of the IEEE 802.15.4 radio assigned to the receiving node of the message).

[0086] In an alternative for a broadcast message, when the IEEE 802.15.4 MAC frame contains a broadcast destination address (0xffff), the TREL layer 318 sets the IPv6 destination address of the TREL message to the link-local all TREL interfaces multicast address.

[0087] In another alternative for broadcast messages, the TREL layer 318 uses the feature of the IEEE 802.15.4 MAC frame security configuration that separates messages for discovery from normal data communication. All messages for discovery disable MAC frame security or utilize MAC key ID mode 2. All data communication uses MAC key ID mode 1. The TREL link layer 308 identifies IEEE 802.15.4 MAC discovery frames based on the destination address set to the broadcast address (0xffff) and the MAC frame security set to disable or enable MAC key ID mode 2. When transmitting an IEEE 802.15.4 MAC discovery frame, the TREL layer 318 sets the IPv6 destination address of the TREL message to the link-local all-TREL-interfaces multicast address.

[0088] In one aspect, when transmitting a 6LoWPAN frame to a broadcast address but the frame is not an IEEE 802.15.4 discovery frame, the TREL layer 318 of the device sends unicast TREL messages to each neighbor to which the device has synchronized. The TREL layer 318 sets the IPv6 destination address to the link-local address of the Thread interface assigned to each neighbor. The encapsulated 802.15.4 MAC frame remains unchanged and carries the broadcast address. In another aspect, the TREL device can be configured with a neighbor list. This configuration can be manual (e.g., by an administrator) or automatic (e.g., using DNS-SD).

[0089] The Thread network uses 6LoWPAN to fragment (compress) IPv6 datagrams that do not fit within a single link frame. A simple implementation would use the same maximum transmission unit (MTU) on both the TREL and 802.15.4 links (e.g., a maximum packet size of 127 bytes (aMaxPHYPacketSize)). When the final destination of a 6LoWPAN frame is an adjacent device, the TREL layer 318 can choose to use a larger MTU that reflects the actual capabilities of the TREL interface. When a 6LoWPAN frame does not carry a 6LoWPAN mesh header, its final destination is an adjacent device.

[0090] When a 6LoWPAN frame carries a 6LoWPAN mesh header, the TREL layer 318 uses the same MTU as 802.15.4 (e.g., 127 bytes of aMaxPHYPacketSize). A 6LoWPAN frame carrying a 6LoWPAN mesh addressing header can be forwarded over multiple hops, some of which can occur over an IEEE 802.15.4 radio. As a result, the TREL layer 318 must use the minimum MTU for 6LoWPAN frames that traverse multiple hops.

[0091] Rather than transmitting IEEE 802.15.4 acknowledgment frames, the TREL layer 318 uses TREL Ack packets. When the packet type is unicast, the TREL packet has an "A" field 406 set to the value 1, and there is an entry in the TREL pending acknowledgment set set for the destination.

[0092] The TREL Ack packet includes: (i) an IPv6 source address set to the IPv6 destination address of the packet being acknowledged, (ii) a packet number field 414 set to the same value as the value set in the packet being acknowledged, (iii) an IPv6 destination address set to the IPv6 source address of the packet being acknowledged, (iv) an 802.15.4 extended source address field 416 set to the 802.15.4 extended destination address of the packet being acknowledged, and (v) an 802.15.4 extended destination address field 418 set to the 802.15.4 extended source address of the packet being acknowledged.

[0093] The TREL device allows the multi-link PHY layer 316 to process the next queued message immediately after successfully submitting a message to the interface of the TREL layer 318. The TREL network stack 300 does not implement retransmission because it assumes that the underlying link technology (e.g., Wi-Fi) implements its own retransmission logic. Not waiting for acknowledgments allows the TREL layer 318 to take advantage of the aggregation techniques provided by the underlying link technology (e.g., Wi-Fi), which can greatly improve throughput and channel utilization.

[0094] The TREL layer 318 uses TREL Ack packets to update the TREL pending acknowledgment set. For each transmission for which an acknowledgment is requested, the TREL layer 318 increments the current pending Ack value in the associated neighbor pending acknowledgment tuple. The TREL pending acknowledgment set maintains the number of pending acknowledgments for the current and previous time windows. The TREL layer 318 periodically advances the time window by the period of TREL_PENDING_ACK_WINDOW. At the start of each time window, each neighbor pending acknowledgment tuple (i) reduces the priority value of the associated neighbor in the PHY priority set by multiplying the value of the previous pending Ack by the value of PHY_PREF_TREL_TX_FAILURE_DECREASE, (ii) sets the previous pending Ack to be equal to the current pending Ack, and (iii) sets the current pending Ack to a zero value.

[0095] When the TREL packet 400 is received, the TREL layer 318 further processes the packet: (i) if the value in the type field 408 is one of the defined types, including broadcast, unicast, or Ack, (ii) if the value in the type field 408 is set to Ack and the A field 406 is set to zero, (iii) if the destination PAN ID is the broadcast PAN ID (0xffff) or matches the PAN ID configured on the Thread interface, (iv) if the 802.15.4 extended source address 416 does not match the extended address assigned to the Thread interface (to discard packets originating from the device itself), and (v) if the type 408 is unicast, then the 802.15.4 extended destination address 418 matches the extended address assigned to the Thread interface.

[0096] The TREL layer 318 applies the same IEEE 802.15.4 frame security processing to the encapsulated 802.15.4 frame as specified in the Thread Specification, Version 1.2, Section 7.2. The TREL layer 318 uses a different MAC key from the IEEE 802.15.4 PHY 322. The TREL layer 318 derives the MAC key from the Thread master key using the HMAC-based Extract and Expand Key Derivation Function (HKDF) (as specified in IETF RFC5869) using SHA-256 (as specified in IETF RFC6234) as follows:

[0097] HKDF-Extract(

[0098] salt = thrKeySequenceCounter|“ThreadSequencedMasterKey”,

[0099] IKM = thrMasterKey)->PRK (1)

[0100] HKDF-Expand(PRK, info = ”ThreadOverWiFiKey”, L = 16)->TREL MAC Key (2)

[0101] The thrKeySequenceCounter value is represented using big-endian byte ordering. The frame counters between the TREL layer 318 and the IEEE 802.15.4 PHY 322 are maintained separately.

[0102] When a device using the TREL network stack 300 performs mesh link establishment (MLE), the device may include a link layer frame counter TLV (Type-Length-Value) in the MLE message. The device sets the value of the link layer frame counter TLV to the maximum outgoing link layer frame counter value of the PHY supported by the device, and all PHYs are updated to use the same value included in the link layer frame counter TLV. When storing the link layer frame counter value received in the link layer frame counter TLV of a given neighbor, the TREL network stack 300 updates all PHYs with the received frame counter value.

[0103] On each receipt of an MLE message, a device using the TREL network stack 300 performs an update process on the set of PHY priorities associated with the PHY on which the message was received. If the device successfully completes MLE message security processing and MLE frame counter processing, the priority value of the associated neighbor is incremented. If MLE frame counter processing fails, the priority value of the associated neighbor is also incremented if (i) an MLEDeviceDescriptor exists, (ii) the auxFrameCounter is equal to the storedFrameCounter, and (iii) the duration since the storedFrameCounter was last updated is less than MLE_DUPLICATE_PREFERENCE_UPDATE_DURATION.

[0104] When incremented, the priority value of the associated neighbor is incremented by PHY_PREF_TREL_RX_SUCCESS_INCREASE when received via the TREL layer 318, or by PHY_PREF_802154_RX_SUCCESS_INCREASE when received via the IEEE802.15.4 radio.

[0105] The initial 6LoWPAN datagram_tag value after a reboot is not defined in IETF RFC4944. Thus, after an adjacent node is reset, the device needs to always accept the first 6LoWPAN frame it receives with a fragmented header. On each receipt of an MLE message, if (i) an MLEDeviceDescriptor exists, (ii) the device successfully completes MLE message security processing and MLE frame counter processing, and (iii) the MLE command type is one of MLE sub ID request, MLE sub update request, or MLE link request, the device removes the associated neighbor frame tuple.

[0106] Example method

[0107] According to one or more aspects of Thread over Internet Protocol, refer to Figure 5The example method 500 is described. Generally, any components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods can be described in the general context of executable instructions stored on a computer-readable storage memory local and / or remote to a computer processing system, and the implementation can include software applications, programs, functions, and the like. Alternatively or additionally, any functionality described herein can be performed at least in part by one or more hardware logic components, such as, but not limited to, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-chips (SoCs), complex programmable logic devices (CPLDs), and the like. The order in which method blocks are described is not intended to be construed as limiting, and any number of the described method blocks can be combined or skipped in any order to implement a method or an alternative method.

[0108] Figure 5 An example method 500 showing threads over Internet Protocol is presented, which generally involves determining a preferred physical layer for communication by nodes in a thread network. At block 502, a node in the thread network transmits a first IPv6 (6LoWPAN) frame over a low-power wireless personal area network using a first physical layer to a neighbor node. For example, a node (e.g., TREL devices 220, 222) transmits a first 6LoWPAN frame to a neighbor node (e.g., router 206, end device 208, or border router 106) using a first physical layer, such as transmitting the first 6LoWPAN frame in an IEEE 802.15.4 MAC frame using IEEE 802.15.4 PHY. For example, an adjacent node can be reached via at least one PHY of the node.

[0109] At block 504, the node transmits the first 6LoWPAN frame to the neighbor node using a second physical layer. For example, the node transmits the first 6LoWPAN frame to a neighbor node (e.g., Wi-Fi device 210 or Ethernet device 214) using a second physical layer (e.g., Wi-Fi or Ethernet), such as transmitting the first 6LoWPAN frame encapsulated in an IEEE 802.15.4 MAC frame, which is encapsulated in a TREL message format 400 and further encapsulated in a UDP frame and an IPv6 packet.

[0110] At block 506, the node determines a first preference value of the neighbor node using the first physical layer. For example, based on one or more acknowledgments received from the neighbor node for transmissions made using the first physical layer, the node determines the first preference value for the neighbor node to communicate using the first physical layer.

[0111] At block 508, the node determines a second preference value for a neighbor node using a second physical layer. For example, based on one or more acknowledgments received from the neighbor node for transmissions made using the second physical layer, the node determines the second preference value for the neighbor node to communicate using the second physical layer.

[0112] At block 510, the node compares the first preference value and the second preference value to determine a preferred physical layer for communication. For example, the node compares the first and second preference values recorded in the PHY preference set and determines a preferred physical layer for communicating with the neighbor node, such as selecting the physical layer with the maximum preference value.

[0113] At block 512, the node transmits a second 6LoWPAN frame to the neighbor node using the preferred physical layer. For example, the node transmits a second 6LoWPAN frame to the neighbor node using the preferred PHY.

[0114] Example Environments and Devices

[0115] Figure 6 An example network environment 600 is shown in which aspects of Thread over Internet Protocol may be implemented. Generally, environment 600 includes a home local area network (HAN) 200 implemented as part of a home or other type of structure, the home local area network having any number of wireless network devices configured for communication in a wireless network. For example, the wireless network devices may include a thermostat 602, a hazard detector 604 (e.g., for smoke and / or carbon monoxide), a camera 606 (e.g., indoor and outdoor), a lighting unit 608 (e.g., indoor and outdoor), and any other type of wireless network device 610 implemented inside and / or outside of the structure 612 (e.g., in a home environment). In this example, the wireless network devices may also include any of the previously described devices, such as the border router 106, and any devices implemented as router device 206 and / or terminal device 208.

[0116] In environment 600, any number of wireless network devices may be implemented for wireless interconnection to communicate and interact wirelessly with each other. The wireless network devices are modular, intelligent, multi-sensing, network-connected devices that can be seamlessly integrated with each other and / or with a central server or cloud computing system to provide any of a variety of useful automation goals and implementations. Refer Figure 7 to illustrate and describe examples of wireless network devices that may be implemented as any of the devices described herein.

[0117] In an implementation, the thermostat 602 may include detecting ambient climate characteristics (e.g., temperature and / or humidity) and controlling the HVAC system 614 in the home environment Learning thermostat. The learning thermostat 602 and other network-connected devices "learn" by capturing the settings of the occupants of the device. For example, the thermostat learns the preferred temperature set points in the morning and evening, when the occupants of the structure go to sleep or wake up, and when the occupants typically go out or are at home.

[0118] The hazard detector 604 can be implemented to detect the presence of a hazardous substance or a substance indicating a hazardous substance (e.g., smoke, fire, or carbon monoxide). In an example of wireless interconnectivity, the hazard detector 604 can detect the presence of smoke, indicating a fire in the structure, in which case the hazard detector that first detects the smoke can broadcast a low-power wake-up signal to all connected wireless network devices. Other hazard detectors 604 can then receive the broadcast wake-up signal and initiate a high-power state for hazard detection, as well as wireless communication for receiving alert messages. Additionally, the lighting unit 608 can receive the broadcast wake-up signal and be activated in the area where the hazard is detected to illuminate and identify the problem area. In another example, the lighting unit 608 can be activated in one lighting color to indicate a problem area or zone in the structure, such as a detected fire or break-in, and activated in a different lighting color to indicate a safe area and / or an escape route out of the structure.

[0119] In various configurations, the wireless network device 610 can include an entryway interface device 616 that operates in conjunction with a network-connected door lock system 618 and detects a person approaching or leaving a location, such as the outer door of the structure 612 and responds. The entryway interface device 616 can interact with other wireless network devices based on whether a person has approached or entered the smart home environment. The entryway interface device 616 can control doorbell functionality, notify of a person's approach or departure via an audio or visual device, and control the settings of a security system, such as activating or deactivating the security system as the occupants come and go. The wireless network device 610 can also include other sensors and detectors, such as detecting ambient lighting conditions, detecting room occupancy status (e.g., using an occupancy sensor 620), and controlling the power and / or dim state of one or more lights. In some cases, the sensors and / or detectors can also control a fan, such as the power state or speed of a ceiling fan 622. Additionally, the sensors and / or detectors can detect occupancy in a room or enclosed space and control the power supply to a power outlet or device 624, such as if the room or structure is unoccupied.

[0120] The wireless network device 610 may also include connected appliances and / or controlled systems 626, such as refrigerators, stoves and ovens, washing machines, dryers, air conditioners, pool heaters 628, irrigation systems 630, security systems 632, etc., as well as other electronic and computing devices, such as televisions, entertainment systems, computers, intercom systems, garage door openers 634, ceiling fans 622, control panels 636, etc. When plugged in, the appliance, device, or system may announce itself to the home local area network as described above and may be automatically integrated with the controls and devices of the home local area network, such as in the home. It should be noted that the wireless network device 610 may include devices that are physically located outside the structure but within the wireless communication range, such as devices that control the pool heater 628 or the irrigation system 630.

[0121] As described above, the HAN 200 includes a border router 106 that is connected to an external network interface outside the HAN 200 for communication. The border router 106 is connected to an access point 110, and the access point 110 is connected to an access network 108, such as the Internet. Cloud services 112 connected via the access network 108 provide services related to and / or using the devices within the HAN 200. For example, the cloud services 112 may include applications for connecting end-user devices 638 (such as smart phones, tablet computers, etc.) to devices in the home local area network, processing and presenting data obtained in the HAN 200 to the end user, linking devices in one or more HANs 200 to the user accounts of the cloud services 112, provisioning and updating devices in the HAN 200, etc. For example, a user may use a network-connected computer or portable device (such as a mobile phone or tablet device) to control the thermostat 602 and other wireless network devices in the home environment. In addition, the wireless network devices may communicate information to any central server or cloud computing system via the border router 106 and the access point 110. Data communication may be performed using any of a variety of custom or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6LoWPAN, Thread, etc.) and / or by using any of a variety of custom or standard wired protocols (CAT6 Ethernet, HomePlug, etc.).

[0122] Any wireless network device in the HAN 200 can be used as a low-power and communication node to create the HAN 200 in a home environment. Each of the low-power nodes of the network, in addition to emitting their own messages, can periodically emit messages about what they sense and other low-power nodes in the environment, and these messages can be repeated to convey the messages from node to node (i.e., from device to device) throughout the home local area network. The wireless network device can be implemented to save power, especially when battery-powered, using a low-power communication protocol to receive messages, translate the messages into other communication protocols, and send the translated messages to other nodes and / or a central server or cloud computing system. For example, an occupancy and / or ambient light sensor can detect the occupants in a room and measure the ambient light, and activate a light source when the ambient light sensor 640 detects that the room is dark and when the occupancy sensor 620 detects that someone is in the room. Additionally, the sensor can include a low-power wireless communication chip (e.g., an IEEE 802.15.4 chip, a Thread chip, a ZigBee chip), which periodically emits messages about the occupancy of the room and the amount of light in the room, including an immediate message consistent with the occupancy sensor detecting the presence of someone in the room. As described above, these messages can be wirelessly sent from node to node (e.g., network-connected device to network-connected device) within the home environment using the home local area network, and sent to a central server or cloud computing system via the Internet.

[0123] In other configurations, various wireless network devices can act as "trip wires" for an alarm system in a home environment. For example, in the case where an intruder avoids detection by alarm sensors located at windows, doors, and other entry points of a structure or environment, an alarm can still be triggered by receiving messages of occupancy, motion, heat, sound, etc. from one or more low-power mesh nodes in the home local area network. In other implementations, when a person transitions from one room to another within a structure, the home local area network can be used to automatically turn on and off the lighting unit 608. For example, a wireless network device can detect a person moving through the structure and convey a corresponding message via a node of the home local area network. Using the message indicating which rooms are occupied, other wireless network devices receiving the message can be activated and / or deactivated accordingly. As described above, the home local area network can also be used to provide exit lighting in an emergency, such as by turning on the appropriate lighting unit 608 leading to a safe exit. The light unit 608 can also be turned on to indicate the direction along an exit route that a person should follow to safely leave the structure.

[0124] Various wireless network devices can also be implemented to integrate with and communicate with the wearable computing device 642, such as can be used to identify and locate the occupant of the structure and accordingly adjust temperature, lighting, audio systems, etc. In other implementations, RFID sensing (e.g., a person with an RFID bracelet, necklace, or key fob), synthetic vision technology (e.g., a camera and a facial recognition processor), audio technology (e.g., voice, sound pattern, vibration pattern recognition), ultrasonic sensing / imaging technology, and infrared or near field communication (NFC) technology (e.g., a person wearing an infrared or NFC-capable smart phone), as well as rule-based inference engines or artificial intelligence techniques, which draw useful conclusions about the location of the occupant in the structure or environment from the sensed information.

[0125] In other implementations, the personal comfort local area network, personal health local area network, personal security local area network, and / or other such human-oriented functionality of the service robot can be enhanced by logically integrating with other wireless network devices and sensors in the environment according to rule-based inference techniques or artificial intelligence techniques to achieve better performance of these functionalities. In an example related to the personal health area, the system can utilize rule-based inference and artificial intelligence techniques to detect whether a household pet is moving towards the current location of the occupant (e.g., using any one of the wireless network devices and sensors). Similarly, the hazard detector service robot can be notified that the temperature and humidity levels in the kitchen are rising and, in the case of inferring that any small increase in the surrounding smoke level is likely due to cooking activities rather than a genuine hazard situation, temporarily increase the hazard detection threshold, such as the smoke detection threshold. Any service robot configured for any type of monitoring, detection, and / or service can be implemented as a mesh node device on the home local area network, compliant with the wireless interconnect protocol for communicating on the home local area network.

[0126] The wireless network device 610 can also include an alarm 644 with network connectivity for each individual occupant of the structure in the home environment. For example, the occupant can customize and set the alarm device for wake-up times, such as for the next day or the next week. Artificial intelligence can be used to consider the occupant's reaction when the alarm goes off and reason about the preferred sleep pattern over a period of time. Then, the individual occupant can be tracked on the home local area network based on the individual's unique signature, which is determined based on data obtained from sensors located in the wireless network device, such as including ultrasonic sensors, passive IR sensors, etc. The occupant's unique signature can be based on a combination of movement patterns, voice, height, size, etc., as well as using facial recognition technology.

[0127] In an example of wireless interconnectivity, an individual's wake-up time can be associated with thermostat 602 to control the HVAC system in an efficient manner to preheat or precool the structure to desired sleep and wake-up temperature settings. Preferences can be learned over time, such as by capturing the temperatures set in the thermostat when the person goes to sleep and wakes up. The data collected can also include biometric indicators of the individual, such as breathing patterns, heart rate, movement, etc., from which inferences can be made based on the data in combination with data indicating when the person actually wakes up. Other wireless network devices can use this data to provide other automation goals, such as adjusting thermostat 602 to preheat or precool the environment to desired settings, and turning lights 608 on or off.

[0128] In an implementation, wireless network devices can also be used for sound, vibration, and / or motion sensing, such as detecting running water and making inferences about water usage in the home environment based on algorithms and mappings of water usage and consumption. This can be used to determine the signature or fingerprint of each water source in the home and is also referred to as "audio fingerprinting of water usage". Similarly, wireless network devices can be used to detect the faint sounds, vibrations, and / or movements of harmful pests such as rats and other rodents, as well as termites, cockroaches, and other insects. The system can then notify the occupant of suspected pests in the environment, such as with a warning message to help facilitate early detection and prevention.

[0129] Environment 600 can include one or more wireless network devices that act as a hub 646. Hub 646 can be a general-purpose home automation hub or a dedicated hub, such as a security hub, an energy management hub, an HVAC hub, etc. The functionality of hub 646 can also be integrated into any wireless network device, such as a network-connected thermostat device or a border router 106. Hosting functionality on hub 646 in structure 612 can improve reliability when the user's Internet connection is unreliable, can reduce the latency of operations that would normally have to connect to cloud service 112, and can meet system and regulatory constraints regarding local access between wireless network devices.

[0130] In addition, example environment 600 includes a network-connected speaker (network-connected auxiliary device) 648. The network-connected speaker 648 provides voice assistance services, including voice control of network-connected devices. The functionality of hub 646 can be hosted in the network-connected speaker 648. The network-connected speaker 648 can be configured to communicate via wireless mesh network 202, Wi-Fi network 204, or both.

[0131] Figure 7FIG. 0 shows an example wireless network device 700, which may be implemented as any wireless network device (node) in a home local area network (Thread network, Fabric network, Weave network, CHIP network) according to one or more aspects of Thread over Internet Protocol as described herein. Device 700 may be integrated with electronic circuitry, a microprocessor, memory, input-output (I / O) logic control, communication interfaces and components, and other hardware, firmware, and / or software to implement the device in the home local area network. Additionally, wireless network device 700 may be implemented with a variety of components, such as any number of different components and combinations thereof further described with reference to the example devices shown in Figure 8 and combinations thereof.

[0132] In this example, wireless network device 700 includes a low-power microprocessor 702 and a high-power microprocessor 704 (e.g., a microcontroller or a digital signal processor) that process executable instructions. The device also includes input-output (I / O) logic control 706 (e.g., including electronic circuitry). The microprocessors may include integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and components in other implementations in silicon and / or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or additionally, the device may be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry, which may be implemented using processing and control circuitry. The low-power microprocessor 702 and the high-power microprocessor 704 may also support one or more different device functionalities of the device. For example, the high-power microprocessor 704 may perform computationally intensive operations, while the low-power microprocessor 702 may manage less complex processes, such as detecting hazards or temperature from one or more sensors 708. The low-power processor 702 may also wake up or initialize the high-power processor 704 for computationally intensive processes.

[0133] One or more sensors 708 may be implemented to detect various properties such as acceleration, temperature, humidity, water, power supply, proximity, external movement, device movement, sound signals, ultrasonic signals, light signals, fire, smoke, carbon monoxide, Global Positioning Satellite (GPS) signals, radio frequency (RF), other electromagnetic signals or fields, etc. Thus, sensors 708 may include any one or combination of a temperature sensor, a humidity sensor, a hazard-related sensor, other environmental sensors, an accelerometer, a microphone, an optical sensor, up to and including a camera (e.g., a charge-coupled device or video camera, an active or passive radiation sensor, a GPS receiver, and a radio frequency identification detector). In an implementation, the wireless network device 700 may include one or more primary sensors, as well as one or more secondary sensors, such as primary sensors that sense data critical to the core operation of the device (e.g., sensing temperature in a thermostat or sensing smoke in a smoke detector), while the secondary sensors may sense other types of data (e.g., movement, light, or sound) that may be used for energy efficiency goals or automation goals.

[0134] The wireless network device 700 includes a memory device controller 710 and a memory device 712, such as any type of non-volatile memory and / or other suitable electronic data storage device. The wireless network device 700 may also include various firmware and / or software, such as an operating system 714 maintained by the memory as computer-executable instructions and executed by a microprocessor. The device software may also include a TREL network stack application 716 that implements aspects of the TREL network stack 300 for Thread over Internet Protocol. The wireless network device 700 further includes a device interface 718 interfaced to another device or peripheral component, and includes an integrated data bus 720 that couples the various components of the wireless network device for data communication between the components. The data bus in the wireless network device may also be implemented as any one or combination of different bus structures and / or bus architectures.

[0135] The device interface 718 may receive input from a user and / or provide information to the user (e.g., as a user interface), and the received input may be used to determine settings. The device interface 718 may also include mechanical or virtual components responsive to user input. For example, a user may mechanically move a sliding or rotatable component, or may detect movement along a touchpad, and such movement may correspond to an adjustment of the device's settings. Physical and virtual movable user interface components may allow a user to set settings along a portion of an apparent continuum. The device interface 718 may also receive input from any number of peripheral devices, such as buttons, keypads, switches, microphones, and imagers (e.g., camera devices).

[0136] The wireless network device 700 may include a network interface 722, such as a home local area network interface for communicating with other wireless network devices in a home local area network, a wired network device (e.g., an Ethernet-connected device), and an external network interface for network communication such as via the Internet. The wireless network device 700 also includes a wireless radio system 724 for wireless communication with other wireless network devices via the home local area network interface and for multiple different wireless communication systems. The wireless radio system 724 may include Wi-Fi, Bluetooth TM , mobile broadband, BLE, and / or point-to-point IEEE 802.15.4. Each different radio system may include radio devices, antennas, and chipsets implemented for a particular wireless communication technology. The wireless network device 700 also includes a power supply 726, such as a battery and / or connecting the device to line voltage. An AC power supply may also be used to charge the device's battery.

[0137] Figure 8 An example system 800 is shown that includes an example device 802, which may be implemented as any wireless network device that implements aspects of Thread over the Internet Protocol as described in reference to the previous Figure 1-7 . The example device 802 may be any type of computing device, client device, mobile phone, tablet computer, communication, entertainment, gaming, media playback, and / or other type of device. Additionally, the example device 802 may be implemented as any other type of wireless network device configured to communicate on a home local area network, such as a thermostat, a hazard detector, a camera, a light unit, a commissioning device, a router, a border router, a stitching router, a stitching device, an end device, a leader, an access point, and / or other wireless network devices.

[0138] The device 802 includes a communication device 804 that supports device data 806, such as wired and / or wireless communication of data communicated between devices in a home local area network, data being received, data scheduled for broadcast, data packets of data, data synchronized between devices, etc. The device data may include any type of communication data, as well as audio, video, and / or image data generated by applications executing on the device. The communication device 804 may also include a transceiver for cellular phone communication and / or for network data communication.

[0139] Device 802 also includes an input / output (I / O) interface 808, such as a data network interface that provides connections and / or communication links between devices, data networks (e.g., home local area networks, external networks, etc.), and other devices. The I / O interface can be used to couple the device to any type of component, peripheral device, and / or accessory device. The I / O interface also includes a data input port through which any type of data, media content, and / or input can be received, such as user input to the device, as well as any type of communication data, and audio, video, and / or image data received from any content and / or data source.

[0140] Device 802 includes a processing system 810, which can be implemented at least partially in hardware, such as using any type of microprocessor, controller, etc. that processes executable instructions. The processing system can include integrated circuits, programmable logic devices, logic devices formed using one or more semiconductors, and components in other implementations in silicon and / or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or additionally, the device can be implemented using any one or a combination of software, hardware, firmware, or fixed logic circuitry, which can be implemented using processing and control circuitry. Device 802 can also include any type of system bus or other data and command transfer system that couples the various components within the device. The system bus can include any one or a combination of different bus structures and architectures, as well as control and data lines.

[0141] Device 802 also includes a computer-readable storage memory 812, such as a data storage device that is persistent storage accessible by a computing device and provides data and executable instructions (e.g., software applications, modules, programs, functions, etc.). The computer-readable storage memory described herein does not include propagated signals. Examples of computer-readable storage memory include volatile and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that maintains data for access by a computing device. The computer-readable storage memory can include various implementations of random access memory (RAM), read-only memory (ROM), flash memory, and other types of storage memory in various memory device configurations.

[0142] The computer-readable storage memory 812 provides storage for device data 806 and various device applications 814, such as an operating system that is maintained with the computer-readable storage memory as a software application and executed by the processing system 810. The device applications can also include a device manager, such as any form of control application, software application, signal processing and control module, code derived from a particular device, a hardware abstraction layer for a particular device, and so on. In this example, the device applications also include a TREL network stack application 816 that implements the TREL network stack 300 in accordance with aspects of threads over the Internet Protocol, such as when the example device 802 is implemented as any of the wireless network devices described herein.

[0143] The device 802 also includes an audio and / or video system 818 that generates audio data for an audio device 820 and / or display data for a display device 822. The audio device and / or display device includes any device that processes, displays, and / or otherwise renders audio, video, display, and / or image data (such as the image content of a digital photograph). In an implementation, the audio device and / or display device is an integrated component of the example device 802. Alternatively, the audio device and / or display device is an external, peripheral component of the example device. In various aspects, at least a portion of the techniques described for threads over the Internet Protocol can be implemented in a distributed system, such as on a "cloud" 824 within a platform 826. The cloud 824 includes and / or represents a platform 826 for services 828 and / or resources 830.

[0144] The platform 826 abstracts the underlying functionality of the hardware, such as server devices (e.g., included in the services 828) and / or software resources (e.g., included as resources 830), and connects the example device 802 to other devices, servers, etc. The resources 830 can also include applications and / or data that can be utilized when performing computer processing on a server remote from the example device 802. Additionally, the services 828 and / or resources 830 can facilitate subscriber network services, such as via the Internet, a cellular network, or a Wi-Fi network. The platform 826 can also be used to abstract and scale resources to serve the demand for resources 830 implemented via the platform, such as in terms of interconnected devices having functionality distributed throughout the system 600. For example, this functionality can be implemented in part at the example device 802 and via the platform 826 that abstracts the functionality of the cloud 824.

[0145] Describe some of the following examples:

[0146] Example 1: A method for a node in a network to determine a preferred physical layer for communication, the method comprising:

[0147] Transmit a first Internet Protocol version 6, IPv6, 6LoWPAN frame over a low - power wireless personal area network to a neighbor node using a first physical layer;

[0148] Transmit the first 6LoWPAN frame to the neighbor node using a second physical layer;

[0149] Determine a first priority value of the neighbor node using the first physical layer;

[0150] Determine a second priority value of the neighbor node using the second physical layer;

[0151] Compare the first priority value and the second priority value to determine a preferred physical layer for communication; and

[0152] Transmit a second 6LoWPAN frame to the neighbor node using the preferred physical layer.

[0153] Example 2: The method of Example 1, wherein transmitting the first 6LoWPAN frame to the neighbor node using the first physical layer includes:

[0154] Transmit the first 6LoWPAN frame in an IEEE 802.15.4 media access control, MAC frame.

[0155] Example 3: The method of Example 1 or Example 2, wherein transmitting the first 6LoWPAN frame to the neighbor node using the second physical layer includes:

[0156] Encapsulate the first 6LoWPAN frame in an IEEE 802.15.4 MAC frame;

[0157] Encapsulate the IEEE 802.15.4 MAC frame in a transport protocol frame; and

[0158] Transmit the transport protocol frame in an Internet Protocol packet.

[0159] Example 4: The method of Example 3, wherein the second physical layer is a Wi - Fi physical layer or an Ethernet physical layer.

[0160] Example 5: The method of Example 3, wherein the transport protocol is a Transmission Control Protocol, TCP or a User Datagram Protocol, UDP.

[0161] Example 6: The method of Example 3, wherein the Internet Protocol is an Internet Protocol version 4, IPv4 protocol or an Internet Protocol version 6, IPv6 protocol.

[0162] Example 7: The method of any of the foregoing examples, the method further comprising:

[0163] Receive one or more acknowledgment packets from the neighbor node using the first physical layer, the second physical layer, or both the first physical layer and the second physical layer.

[0164] Example 8: The method of Example 7, wherein receiving one or more acknowledgment packets from a neighbor node comprises:

[0165] Receiving one or more Thread Radio Encapsulation Link, TREL, acknowledgment packets from a neighbor node.

[0166] Example 9: The method of Example 7, wherein a first priority value of a first physical layer is based on one or more acknowledgments received from a neighbor node for a transmission using the first physical layer, and wherein a second priority value of a second physical layer is based on one or more acknowledgments received from a neighbor node for a transmission using the second physical layer.

[0167] Example 10: The method of Example 9, wherein comparing the first priority value and the second priority value to determine a preferred physical layer for communication comprises:

[0168] Selecting the physical layer having the maximum priority value as the preferred physical layer.

[0169] Example 11: The method of Example 9, wherein the first priority value and the second priority value are equal, and wherein comparing the first priority value and the second priority value to determine a preferred physical layer for communication comprises:

[0170] Selecting the physical layer having the lowest power profile for transmitting an IEEE 802.15.4 data request frame; or

[0171] Selecting the physical layer having the highest channel capacity for transmitting frames other than IEEE 802.15.4 data request frames.

[0172] Example 12: The method of any of the foregoing examples, the method further comprising:

[0173] Storing the first priority value and the address of the neighbor node in a Physical Layer, PHY, priority set; and

[0174] Storing the second priority value and the address of the neighbor node in the PHY priority set.

[0175] Example 13: The method of Example 12, wherein the address is an IEEE 802.15.4 extended address.

[0176] Example 14: The method of any of the foregoing examples, the method further comprising:

[0177] Recording outstanding acknowledgments for a first 6LoWPAN frame of the transmission and a second 6LoWPAN frame of a second transmission in a Thread Radio Encapsulation Link TREL outstanding acknowledgment set.

[0178] Example 15: The method of Example 14, wherein the outstanding acknowledgments are recorded in a tuple that includes:

[0179] The extended address of the neighbor node;

[0180] The number of outstanding acknowledgments in the current time window;

[0181] The number of outstanding acknowledgments in the previous time window; and

[0182] The packet number to be used when transmitting the next packet to the neighbor node.

[0183] Example 16: The method of any of the foregoing examples, wherein the first physical layer is an IEEE 802.15.4 physical layer.

[0184] Example 17: The method of any of the foregoing examples, wherein the network is a Thread network.

[0185] Example 18: An electronic device, comprising:

[0186] A first network interface;

[0187] A second network interface;

[0188] One or more processors; and

[0189] A memory that includes instructions executable by the one or more processors to perform any of the methods of Examples 1 to 17.

[0190] Example 19: The electronic device of Example 18, wherein the first network interface is an IEEE 802.15.4 network interface.

[0191] Example 20: The electronic device of Example 18 or Example 19, wherein the second network interface is a Wi-Fi interface or an Ethernet interface.

[0192] Example 21: A computer-readable storage medium including instructions that, when executed by a processor, cause performance of the method as described in any of Examples 1 to 17.

[0193] Although aspects of Thread over Internet Protocol have been described in language specific to features and / or methods, the subject matter of the appended claims need not be limited to the specific features or methods described. Instead, the specific features and methods are disclosed as example implementations of Thread over Internet Protocol, and other equivalent features and methods are intended to fall within the scope of the appended claims. Additionally, various different aspects have been described, and it should be understood that each described aspect can be implemented independently or in combination with one or more other described aspects.

Claims

1. A method for a node in a wireless personal area network implementing a thread specification to determine a preferred physical layer for communication, the method comprising: Transmitting a first Internet Protocol version 6, IPv6, 6LoWPAN frame on a low-power wireless personal area network to a neighbor node using a first physical layer; Transmitting the first 6LoWPAN frame to the neighbor node using a second physical layer; Determining a first preference value of the neighbor node for the first physical layer based on one or more acknowledgment packets received from the neighbor node for the transmission using the first physical layer; Determining a second preference value of the neighbor node for the second physical layer based on one or more Thread Radio Encapsulation Link, TREL, acknowledgment packets received from the neighbor node for the transmission using the second physical layer; Comparing the first preference value and the second preference value to determine a preferred physical layer for communication, including selecting the physical layer with the maximum preference value as the preferred physical layer; And Transmitting a second 6LoWPAN frame to the neighbor node using the preferred physical layer.

2. The method according to claim 1, wherein Transmitting the first 6LoWPAN frame to the neighbor node using the first physical layer includes: Transmitting the first 6LoWPAN frame in an IEEE 802.15.4 Media Access Control, MAC, frame.

3. The method according to claim 1, wherein Transmitting the first 6LoWPAN frame to the neighbor node using the second physical layer includes: Encapsulating the first 6LoWPAN frame in an IEEE 802.15.4 MAC frame; Encapsulating the IEEE 802.15.4 MAC frame in a transport protocol frame; and Transmitting the transport protocol frame in an Internet Protocol packet.

4. The method according to claim 3, wherein The second physical layer is a Wi-Fi physical layer or an Ethernet physical layer.

5. The method according to claim 3, wherein, The transport protocol is the Transmission Control Protocol, TCP, or the User Datagram Protocol, UDP, and wherein the Internet Protocol is the Internet Protocol version 4, IPv4, protocol or the Internet Protocol version 6, IPv6, protocol.

6. The method according to claim 1, wherein, The first preference value and the second preference value are equal, and wherein comparing the first preference value and the second preference value to determine the preferred physical layer for communication includes: Selecting the physical layer with the lowest power distribution for transmitting an IEEE 802.15.4 data request frame; or Selecting the physical layer with the highest channel capacity for transmitting frames other than the IEEE 802.15.4 data request frame.

7. The method according to claim 1, further comprising: Storing the first preference value and the address of the neighbor node in a Physical Layer, PHY, preference set; And Storing the second preference value and the address of the neighbor node in the PHY preference set.

8. The method according to any one of claims 1-7, further comprising: Recording outstanding acknowledgments for the transmitted first 6LoWPAN frame and the transmitted second 6LoWPAN frame in a Thread Radio Encapsulation Link, TREL, outstanding acknowledgment set.

9. The method according to claim 8, wherein The outstanding acknowledgments are recorded in a tuple, the tuple including: The extended address of the neighbor node; The number of outstanding acknowledgments in the current time window; The number of outstanding acknowledgments in the previous time window; and The packet number to be used when transmitting the next packet to the neighbor node.

10. The method according to claim 1, wherein, The first physical layer is an IEEE 802.15.4 physical layer.

11. An electronic device, comprising: A first network interface; A second network interface; One or more processors; And A memory including instructions executable by the one or more processors to perform the method according to any one of claims 1 to 10.

Images