EP4732526A1 - Thread border router offload - Google Patents

Abstract

Techniques and devices for maintaining network connectivity on a Thread network are described in which a network coprocessor performs functions of a Thread border router (TBR) network stack and one or more layers of a host network stack offloaded from an application processor system. The network coprocessor maintains bidirectional connectivity and discovery on the Thread network using the offloaded TBR network stack and the offloaded host network stack layers, while the application processor system is in a sleep or a low-power state.

Description

THREAD BORDER ROUTER OFFLOAD

BACKGROUND

[0001] Using wireless networking to connect devices to each other, and to cloud-based services, is increasingly popular for sensing environmental conditions, controlling equipment, and providing information and alerts to users. Many devices on wireless networks are designed to operate for extended periods of time on battery' -power, which limits the available computing, user interface, and radio resources in these devices.

[0002] A Thread border router (TBR). or Thread hub. is a network device that connects a Thread network to other IP-based networks, such as Wi-Fi or Ethernet. For a hub or hosted device, such as a connected or smart TV, the TBR is usually attached to a powerful host system-on-chip (SoC) to provide connectivity from the Thread network to adjacent IP -networks and the Internet. This SoC or application processor (AP) usually consumes significant amounts of power and therefore needs to be put in a sleep or suspend state when idle to allow it to reduce its energy consumption and/or to meet regulatory' and sustainability requirements. However, frequent wakeups of the SoC are required due to constant multicast Domain Name System (mDNS) on a Wi-Fi network and/or to maintain bidirectional connectivity’ and discovery to/from a Thread network. The transition of the SoC from sleep to wake also increases the latency of the network responses. There are opportunities to reduce power consumption for an SoC while maintaining the latency performance for network responses.

SUMMARY

[0003] This summary is provided to introduce concepts of Thread border router offload, generally related to providing connectivity' using multiple networking technologies in a fabric network for IPv6 communication. The concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0004] In aspects, methods, devices, systems, and means for Thread border router offload are described for maintaining network connectivity' on a Thread network in which a network coprocessor performs functions of a Thread border router (TBR) network stack and one or more layers of a host network stack offloaded from an application processor system. The network coprocessor maintains bidirectional connectivity and discovery' on the Thread network using the offloaded TBR network stack and the offloaded host network stack layers, while the application processor system is in a sleep or a low-power state. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Aspects of Thread border router offload are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:

FIG. 1 illustrates an example network environment in which various aspects of Thread border router offload can be implemented.

FIG. 2 illustrates an example environment in which various aspects of Thread border router offload can be implemented.

FIG. 3 illustrates an example system with which aspects of Thread border router offload can be implemented.

FIG. 4 illustrates an example system with which aspects of Thread border router offload can be implemented.

FIG. 5 illustrates an example initialization sequence with which aspects of Thread border router offload can be implemented.

FIG. 6 illustrates an example of offloading a Thread Radio Encapsulation Link (TREL) with which aspects of Thread border router offload can be implemented.

FIG. 7 illustrates an example of offloading a Thread border agent with which aspects of Thread border router offload can be implemented.

FIG. 8 illustrates an example of offloading multicast forwarding with which aspects of Thread border router offload can be implemented.

FIG. 9 illustrates an example of offloading IPv6 address subscriptions with which aspects of Thread border router offload can be implemented.

FIG. 10 illustrates an example method for a network node in accordance with one or more aspects of the techniques described herein.

FIG. 11 illustrates an example method for a network node in accordance with one or more aspects of the techniques described herein.

FIG. 12 illustrates an example method for a network node in accordance with one or more aspects of the techniques described herein.

FIG. 13 illustrates an example method for a network node in accordance with one or more aspects of the techniques described herein.

FIG. 14 illustrates an example method for a network node in accordance with one or more aspects of the techniques described herein.

FIG. 15 illustrates an example environment in which aspects of the techniques described herein can be implemented. FIG. 16 illustrates an example wireless network device that can be implemented in a home area network in accordance with one or more aspects of the techniques described herein.

FIG. 17 illustrates an example system with an example device that can implement aspects of Thread border router offload.

DETAILED DESCRIPTION

[0006] This document illustrates approaches to offloading portions or all of Thread border router and host network protocol stacks from an SoC or AP. While the described techniques are presented in the context of Wi-Fi and Thread networks, the techniques can be generalized to any “stub network’’ technology. A stub network refers to another network technology that does not route beyond devices directly attached to that stub network. For example, the mDNS, Internet Protocol version 6 (IPv6) control traffic, and/or Internet Control Message Protocol version 6 (ICMPv6) from a host network stack and a Thread Border Router network stack can be offloaded from the SoC or AP onto a wireless integrated circuit (radio integrated circuit, radio IC) that performs the functions of the offloaded layers of the network stack. This offloading allows the SoC or AP to sleep or suspend and thereby reduce the overall system energy⁷ consumption, improve latency, and reduce the CPU load of the SoC or AP of a host device (e.g., a hub device). The sleep state or suspended state or a low-power state refers to a state in which a power consumption of the application processor system is lower than the power consumption of the application processor system while operating in a non-sleep or high-power state (e.g., a state in which the application processor system provides an extended or full functionality⁷ as compared to the sleep state or suspended state or low-power state of the application processor system). The wireless integrated circuit needs to handle all of the Thread border router’s functionality, including bidirectional discovery and connectivity⁷, on behalf of the host. This is different from an implementation that runs a full stack of the TBR on the host and a separate radio controller in a wireless chip to provide over-the-air communication.

Example Environment

[0007] FIG. 1 illustrates an example network environment 100 in which aspects of Thread border router offload can be implemented. The network environment 100 (e.g., a fabric network, a Thread network, a Matter network, a Weave network) includes one or more network segments that form a home area network (HAN) such as a HAN 200, described below with respect to FIG. 2. The HAN includes wireless network devices 102 that are disposed about a structure 104, such as a house, and are connected by one or more wireless and/or wired network technologies, as described below. The HAN includes a border router 106 that connects the HAN to an external network 108 (access network 108), such as the Internet, through a home router or access point 1 10.

[0008] To provide user access to functions implemented using the wireless network devices 102 in the HAN, a cloud service 112 connects to the HAN via border router 106, via a secure tunnel 114 through the external network 108 (access network 108) and the access point 1 10. The cloud service 112 facilitates communication between the HAN and internet clients 116, such as apps on mobile devices, using a web-based application programming interface (API) 118. The cloud service 112 also manages a home graph that describes connections and relationships between the wireless network devices 102, elements of the structure 104, and users. The cloud service 1 12 hosts controllers which orchestrate and arbitrate home automation experiences, as described in greater detail below.

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

[0010] The wireless network devices 102 in the HAN may be from a single manufacturer that provides the cloud service 112 as well, or the HAN may include wireless network devices 102 from partners. These partners may also provide partner cloud services 122 that provide services related to their wireless network devices 102 through a partner Web API 124. The partner cloud service 122 may⁷ optionally or additionally provide services to internet clients 116 via the web-based API 118, the cloud service 112, and the secure tunnel 114.

[0011] The network environment 100 can be implemented on a variety of hosts, such as battery-powered microcontroller-based devices, line-powered devices, and servers that host cloud services. Protocols operating in the wireless network devices 102 and the cloud service 112 provide a number of services that support operations of home automation experiences 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 notification, historical data logging and preservation, cryptographically controlled security groups, time synchronization, network and service pairing, and software updates.

[0012] FIG. 2 illustrates an example environment (e.g., a fabric network, a Weave network, a Matter network) in which various aspects of Thread border router offload can be implemented. The 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) implementing the Thread Specification, in particular the Thread Specification 1.0, 1.1, 1.2, 1.3, or any later 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) implementing the IEEE 802.11 standard, in particular the IEEE 802.11 standard of 1997 and/or any later version such as 802.11b, 802.11g, 802.1 In, 802.11ac, 802.11ax, 802. Had, 802.11ay, and 802.11be. 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 routers 206 and end devices 208. The routers 206 and the end devices 208, each include a mesh network interface for communication over the mesh network segment 202. The routers 206 receive and transmit packet data over the mesh network interface. The routers 206 also route traffic across the mesh network segment 202. The end devices 208 are devices that can communicate using the mesh network segment 202, but lack the capability, beyond simply forwarding to its parent router 206, to route traffic in the mesh network segment 202. 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 WiFi device 210 includes a Wi-Fi network interface for communication over the Wi-Fi network segment 204. Optionally or additionally, the HAN 200 can include an Ethernet network segment 212 that includes one or more Ethernet devices 214 that connect to the border router 106 or the access point 110. The Ethernet network segment 212 may be compatible with the IEEE 802.3 standard of any version, e.g., 802.3cu or any prior version.

[0013] 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 communication over the mesh network segment 202 and a Wi-Fi network interface for communication over 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., the cloud service 112) via the access network 108, such as the Internet, through a home router or access point 110. [0014] The devices in the mesh network segment 202, the Wi-Fi network segment 204, and the Ethernet network segment 212 use standard IP routing configurations to communicate with each other through transport protocols such as the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP). When the devices in the mesh network segment 202, the Wi-Fi network segment 204 and/or the Ethernet network segment 212 are provisioned as part of a Weave network, a fabric network, or a Matter network, the devices can communicate messages over those same UDP and/or TCP transports.

Thread Border Router Offloading

[0015] FIG. 3 illustrates an example of a system 300 with which aspects of Thread border router offload can be implemented. In an aspect, an SoC 302 (AP 302) includes a host operating system 304 and application(s) 306. One or more applications 306 interact with a host network stack 308 (a host network protocol stack 308), a Wi-Fi network stack 310, and a Thread border router network stack 312 (a Thread network protocol stack 312) to provide connectivity to Wi-Fi network(s) (e.g., the Wi-Fi network segment 204), the HAN 200, the Internet 108, and/or cloud sendees 112, using the Wi-Fi radio IC 320 and/or the Thread radio IC 322. The Wi-Fi network stack 310 and the Thread border router network stack 312 include the lower layers of their respective network protocol stacks (e.g., the link layer protocols).

[0016] The Thread border router network stack 312 uses services of the host network stack 308, such as mDNS 314, Android Packet Filtering 316 (APF 316), and/or an IPv6/ICMPv6 layer 318, to maintain bidirectional connectivity and discover}' on a Thread network (e.g., wireless mesh network segment 202) for devices that have been commissioned to the Thread network, typically by an application 306 on the SoC 302. Additionally or optionally mDNS 312 may be used in a standalone manner, in combination with Android Packet Filtering 316 (APF 316), or APF 316 may be used in place of mDNS 314.

[0017] For example, the mDNS component 314 interacts with the Wi-Fi network stack to optimize performance, such as by configuring Android Packet Filters 316 (APF 316) to only receive specific mDNS queries and/or automatically respond with predetermined responses to specific mDNS queries. The Thread border router network stack 312 supports components of the Thread Border Router such as Mesh Link Establishment (MLE), Thread Management Framework (TMF), Service Registration Protocol (SRP), DNS-based Service Discovery (DNS-SD), Advertising Proxy, DNS-SD Discovery Proxy, and the like.

[0018] In aspects, a portion of the border routing functionality is resident in the host network stack 308, such as DNS-based service discovery (DNS-SD) and IPv6/ICMPv6. For example, the DNS-SD includes mDNS for supporting DNS-SD with legacy Wi-Fi/Ethemet hosts, SRP for allowing Thread border routers to publish services, an Advertising Proxy to publish Thread sendees on the Wi-Fi and/or Ethernet side, Discovery Proxy for Thread devices to discover sen ices on the Wi-Fi/Ethemet side, and a DNS resolver for Thread devices to discover sen ices via traditional DNS. The IPv6/ICMPv6 provides IP reachability between Thread, and Wi-Fi and/or Ethernet links. An offloading implementation can be configured to offload various combinations of these components to a network coprocessor 414 (multi-radio IC 414) that performs the functions of the various combinations of these offloaded components.

[0019] In a conventional implementation, the SoC 302 must be powered-up and/or woken- up for the Thread network stack 312 to use the services of the host stack 308 for Thread border routing, increasing the overall power consumption of the system 300.

[0020] FIG. 4 illustrates an example of a system 400 with which aspects of Thread border router offload can be implemented. In an aspect, an SoC 402 (AP 402) includes the host operating system 304 and the application(s) 306. One or more applications 306 interact with a modified host network stack 408, a Wi-Fi network stack 410, and an optional Thread shim interface 412 to provide connectivity to Wi-Fi network(s) (e.g., the Wi-Fi network segment 204), the HAN 200, the Internet 108, and/or cloud services 112, using a network coprocessor 414. Optionally and in alternatives, the modified host network stack 408 may be a host network stack 308 implementation that is modified to support offloading, but it can still be a full stack implementation configured for offloading or not offloading based on a run-time decision. In a further alternative example, the modified host network stack 408 may be a Thread border router host stack 408 that implements portions of the Thread border router stack that are not offloaded to a network coprocessor 414.

[0021] In one aspect, the network coprocessor 414 executes functions of the offloaded network stack layers 416, that includes the mDNS 314, Android Packet Filtering 316 (APF 316), and/or an IPv6/ICMPv6 layer 318, and a Wi-Fi radio 418. Optionally or additionally, the network coprocessor 414 may include additional radios, such as a Bluetooth/BLE radio. Optionally or additionally, the Wi-Fi radio 418 can be Wi-Fi radio IC that is external to the network coprocessor 414. Additionally or optionally, mDNS 314 may be used in combination with Android Packet Filtering 316 (APF 316) or APF 316 may be used in place of mDNS 314.

[0022] In a further aspect (not illustrated), the functions of the APF 316 can be split between the SoC 402 and the network coprocessor 414. For example, an API for the APF 316 and a byte-code generator for the APF 316 can be included in the SoC 402. The byte code compiled by the byte-code generator is downloaded to the packet filter function of the APF 316 that is included in the offloaded host network stack layers 416 where the byte code is executed to filter packets. [0023] The network coprocessor 414 also includes the Thread border router network stack 312 and a Thread radio 420. When the SoC 402 is powered-up, the application(s) 306 communicate with the Thread border router host stack 312 via the optional Thread shim interface 412 that acts as an interface or shim layer between the application(s) 306 and the lower layers of the Thread network protocol stack in the Thread border router network stack 312. The Thread border router network stack 312 supports components of the Thread Border Router such as Mesh Link Establishment (MLE), Thread Management Framework (TMF), Service Registration Protocol (SRP), DNS-based Service Discovery (DNS-SD), Advertising Proxy, DNS-SD Discovery Proxy, and the like. One or more of these components may be offloaded to the offloaded host network stack layers 416.

[0024] In an aspect, the Thread border router host stack 312 in the network coprocessor 414 uses the rnDNS 314, the Android Packet Filtering 316 (APF 316), and/or the IPv6/ICMPv6 layer 318, in the offloaded host network stack layers 416 to maintain bidirectional connectivity and discovery on a Thread network (e.g., wireless mesh network segment 202) while the SoC 402 can be placed in an idle or suspend mode or put into a sleep state to reduce system power consumption. In an example, Thread border router network stack 312 can use a shared memory or a dual-ported memory (e.g., dual-ported static random access memory) to access layers in the offloaded host network stack layers 416 to manage packets.

[0025] In an alternative aspect to reduce system power consumption, a portion of the Thread border router network stack 312 can be offloaded to the network coprocessor 414 with the remaining (upper) layers of the Thread border router network stack 312 remaining in the SoC 402. In a further alternative aspect to reduce system power consumption, the SoC 302 is modified to utilizing a low-power, always-on-island or always-on domain for the rnDNS 312 on the host SoC 302 and offloading the Thread border routing functionalities to a Thread co-processor device that includes the Thread border router network stack 312 and a Thread radio 418.

[0026] In another alternative aspect to reduce system power consumption, the portions of the Thread border router network stack 312 used for Thread mesh maintenance and border routing are located on a low-power island of the SoC 302 and using the Thread radio IC 322 for connectivity to the Thread network. In a further alternative aspect to reduce system power consumption, the portions of the Thread border router network stack 312 used for Thread mesh maintenance are retained on a wireless coprocessor IC and border routing features (Service Registration Protocol (SRP), IPv6 prefix routing/prefix management, or the like) are located on a low-power island of the SoC 302.

[0027] In a further alternative aspect to reduce system power consumption, the device hosting the Thread border router network stack 312 can determine if there is another Thread border router operating on the Thread network and change its role to reduce power consumption, such as changing its role from that of a border router to that of an end device. In another alternative aspect to reduce system power consumption, the Thread border router can route to Ethernet (instead of Wi-Fi) with the Thread border router network stack 312 located on a low-power island of the SoC 302.

[0028] In a further aspect, the TBR and application host may appear as a single IPv6 interface on the Wi-Fi network or as multiple IPv6 interfaces on the Wi-Fi network. Using multiple IPv6 coordination between the TBR and application host.

System Initialization

[0029] FIG. 5 illustrates an example initialization sequence as generally related to the SoC 402 initializing the network coprocessor 414 and determining the capabilities of the network coprocessor 414. The modified host network stack 408 (e.g., Thread border router host stack 408) operates with a specific type of Thread network co-processor (e.g., the network coprocessor 414). For example, the SoC 402 uses a capability detection mechanism to detect the capability of the netw ork co-processor and then determines what portion of a Thread border router network stack to offload to the co-processor. For example, if it detects that the coprocessor only contains radio capability (such as illustrated in FIG. 3), then no offload will be done and the Thread border router stack (host network stack 308) in the Soc 402 is used for border router network operations. If the SoC 402 detects that the network coprocessor is a Thread network coprocessor (e.g., the network coprocessor 414) that contains an offloaded host network stack 416, then it will offload the performance of the functions of Thread network maintenance, including MLE and TMF. to the Thread network coprocessor (e.g., the network coprocessor 414).

[0030] In aspects, the SoC 402 issues a reset to the network coprocessor 414 at 505. At 510, the netw ork coprocessor 414 responds to the SoC 402 with a return reset status that indicates that the network coprocessor 414 is powered on. At 515, the SoC 402 requests a co-processor version from the network coprocessor 414. At 520, the network coprocessor 414 responds to the SoC 402 by returning a version string that indicates a version of the network coprocessor 414. At 525, the SoC 402 requests the capabilities of the netw ork coprocessor 414. At 530, the network coprocessor 414 responds to the SoC 402 by reluming an indication of the capabilities of the network coprocessor 414. The SoC 402 uses the returned indication of the capabilities of the network coprocessor 414 to determine if the network coprocessor 414 contains the capability to perform the functions of an offloaded host netw ork stack 416. Offloading Examples

[0031] FIG. 6 illustrates an example of offloading a Thread Radio Encapsulation Link (TREL). Some blocks in FIG. 6 are omitted from the SoC 402 and the network coprocessor 414 for the sake of illustration clarity . In aspects, a Thread Radio Encapsulation Link (TREL) protocol 605 enables transmission of 6L0WPAN frames over IP link technologies, including Wi-Fi and Ethernet. The TREL protocol 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 Media Access Control (MAC) frames. As TREL requires access to an infrastructure network interface (e.g., Wi-Fi, Ethernet). TREL works in cooperation with the Thread Border Router host stack.

[0032] At 602 and after a TREL link is established, the Thread border router (TBR) host stack 408 sets a source address and a destination address for TREL communication on the Thread border router network stack 312 in the network coprocessor 414. For example, the Thread border router host stack 408 sets an IP source address (e.g., 192. 168.0.2:: A) and an IP destination address (e.g., 192.168.0.3: :B) on the Thread border router network stack 312.

[0033] At 604, the Thread border router host stack 408 calls the API of the APF 316 to add a fdter on the offloaded host network stack layers 416 to forward IP packets, addressed to the source address, to the Thread border router network stack 312 in the network coprocessor 414.

[0034] At 606, the TREL protocol layer 605 forwards a TREL frame to a peer at the destination address using the offloaded host network stack layers 416. For example, the TREL protocol layer inserts a Thread IP packet as a payload into a UDP packet and forwards the UDP packet to the offloaded host network stack layers 416, which forward the UDP packet over an IP network interface, such as a Wi-Fi or Ethernet network interface.

[0035] FIG. 7 illustrates an example of offloading a Thread border agent. Some blocks in FIG. 7 are omitted from the SoC 402 and the network coprocessor 414 for the sake of illustration clarity⁷. In aspects, the Thread border agent acts as a bridge between an external Thread network commissioner device (e.g., a smart phone) and a Thread network to manage the Thread network (e.g., to commission Thread devices to join the Thread network). To support this, the Border Agent listens on a UDP port on an infrastructure network link (e.g., a Wi-Fi network to which the commissioner device is also connected).

[0036] If the functions of the border agent are not offloaded from the SoC 402 and performed by⁷ the network coprocessor 414, the TBR host stack directly listens on an ephemeral UDP port on the infrastructure network interface. The TBR host stack can directly pass a received packet from this connection to a handler of these messages from the commissioner device. However, the performance of the functions of the border agent can be offloaded to the network coprocessor 414. [0037] The TBR host stack 408 initiates the start or stop of border agent functionality. When starting the border agent, the TBR host stack 408 binds to an ephemeral port (e.g., referred to as “:MC”) on the infrastructure network interface (e.g., a Wi-Fi or Ethernet network interface). At 702. the TBR host stack sends a Spinel command to the TBR network stack 312 including an indication of the bound port in the Spinel command. The TBR network stack 312 starts the border agent 705 using the indication of the bound port (:MC). After starting the border agent 705, the TBD network stack 312 returns a response to the TBR host stack indicating the success or failure of starting the border agent 705.

[0038] At 704, if the border agent 705 is successfully started, the TBR host stack 408 will call the API of the APF 316 to add a filter on the offloaded host network stack layers 416 to forward IP packets, addressed to the clink local Wi-Fi address>::MC to the TBR network stack 312.

[0039] At 706. when the offloaded host network stack layers 416 receives an IP packet that addressed to the “clink local Wi-Fi address>::MC,” the IP packet is forwarded to the TBR network stack 312 and is handled by the border agent 705. When the border agent 705 needs to send a communication to the external commissioner device, the border agent 705 assembles a UDP packet with the source port set as “MC’ and passes the UDP packet to the offloaded host network stack layers 416 for transmission to the external commissioner device.

[0040] FIG. 8 illustrates an example of offloading multicast forwarding. Some blocks in FIG. 8 are omitted from the SoC 402 and the network coprocessor 414 for the sake of illustration clarity. In aspects, a function provided by Thread backbone routers (BBR) provides multicast forwarding to Thread devices. Thread devices can register as IPv6 multicast address listeners (for higher than realm-local scopes) to the Thread BBR which adds the registration to a Thread BBR multicast listener table. When the Thread BBR receives any multicast packets whose destination matches any item in the multicast listener table, the Thread BBR forwards the multicast packet to the Thread network and to the Thread device that registered this multicast address.

[0041] If this portion is not offloaded from the SoC 402, the multicast packets will first be received by the TBR host stack 408 through the offloaded host network stack layers 416. The TBR host stack 408 forwards those matched packets to the Thread network. This requires the SoC 402 to remain in a powered-up state to handle multicast forwarding. The offloading reduces overall system power consumption for multicast forwarding.

[0042] At 802, a Thread device registers an IPv6 multicast address using a Multicast Protocol for Low-Power and Lossy Networks (MPL) protocol. At 804, the backbone router 805 updates the multicast listener table and synchronizes the update to the TBR host stack 408. [0043] The TBR host stack 408 will set the multicast forwarding rules on the infrastructure link (for the offloaded host network stack layers 416). At 806, the TBR host stack 408 calls the API of the APF 316 to add a filter on the offloaded host network stack layers 416 to forward multicast packets that match the multicast listener table to the TBR network stack 312.

[0044] At 808, the APF 316 on the SoC 402 will update the filter on the offloaded host network stack layers 416 so that the new forwarding rule takes effect. At 810, when a multicast packet is received through and processed by the offloaded host network stack layers 416, if the received multicast packet matches the APF rule, it will be forwarded to the TBR network stack 312 for forwarding to the subscribing Thread device.

[0045] FIG. 9 illustrates an example of offloading IPv6 address subscriptions. Some blocks in FIG. 9 are omitted from the SoC 402 and the network coprocessor 414 for the sake of illustration clarity. In aspects, in the host/radio co-processor architecture illustrated in FIG. 3, all IPv6 addresses in the Thread stack are mapped to the host stack, causing all traffic addressed to a Thread node to be delivered to the host, no matter whether or not the host subscribes to the address. This affects both unicast and multicast IP packets. With TBR network stack 312 being offloaded from the SoC 402 and performed by the network coprocessor 414, the TBR host stack 408 only subscribes to unicast addresses and multicast addresses in which the host is interested. For example, the SoC 402 can remain in a lower-power, sleep state when network traffic destined to mesh local addresses is processed by the network coprocessor 414.

[0046] At 902, the TBR host stack subscribes to addresses of interest to the host by registering them via Spinel protocol with the IPv6 layer 905 in the TBR network stack 312. At 904, the TBR network stack 312 receives unicast or multicast IPv6 packets. Based on the destination address in the received IPv6 packets, the TBR network stack 312 determines to wakeup the SoC 402 if the host has subscribed to the destination address. If the host has not subscribed to the destination address, the TBR network stack 312 does not wake-up the SoC 402 and forw ards the IPv6 packet to any nodes that have subscribed to the destination address (e.g., a node on the Thread network).

Example Methods

[0047] Example methods 1000-1400 are described with reference to FIGs. 10-14 in accordance with one or more aspects of Thread border router offload. Generally, any of the 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 may be described in the general context of executable instructions stored on computer-readable storage memory’ that is local and/or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation. Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like. The order in which the method blocks are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order or skipped to implement a method or an alternate method.

[0048] FIG. 10 illustrates example method(s) 1000 of Thread border router offload as generally related to maintaining network connectivity on a Thread network in accordance with aspects of the techniques described herein. At block 1002, a network coprocessor (a network coprocessor integrated circuit (IC)) performs functions of a Thread border router (TBR) network stack and one or more layers of a host network stack offloaded from an application processor system.. For example, the network coprocessor (e.g., the network coprocessor 414 performs functions of a Thread border router (TBR) network stack (e.g., Thread border router network stack 312) and one or more layers of a host network stack (e.g., offloaded host network stack layers 416) offloaded from an application processor system (e.g., the SoC 402).

[0049] At block 1004, the network coprocessor maintains bidirectional connectivity and discovery' on a Thread network using, the offloaded TBR network stack and the offloaded host network stack layers, while the application processor system is in a sleep or a low-power state. For example, the network coprocessor 414 maintains bidirectional connectivity’ and discovery on a Thread network using the TBR network stack 312 that uses offloaded portions of the host stack (e.g., mDNS 314, APF 316, and/or IPv6/ICMPv6 318), while the application processor system (e.g., SoC 402) is in a sleep or a low-power state.

[0050] FIG. 11 illustrates example method(s) 1100 of offloading a Thread Radio Encapsulation Link (TREL) in accordance with aspects of the techniques described herein. At block 1102, an offloaded Thread border router (TBR) network stack receives a source address and a destination address for TREL communication from a TBR host stack. For example, the offloaded Thread border router (TBR) net ork stack (e.g. , offloaded Thread border router network stack 312) receives a source address and a destination address for TREL communication from a TBR host stack (e.g., TBR host stack 408).

[0051] At block 1104, the offloaded Thread border router (TBR) network stack forwards a TREL frame to a peer at the destination address using the offloaded host network stack layers. For example, the offloaded Thread border router (TBR) network stack forwards a TREL frame to a peer at the destination address using offloaded host network stack layers (e.g., the offloaded host network stack layers 416). The TBD network stack forwards the TREL frame by inserting a Thread Internet Protocol (IP) packet as a payload of a User Datagram Protocol (UDP) packet and forwarding the UDP packet to the peer at the destination address using the offloaded host network stack layers.

[0052] FIG. 12 illustrates example method(s) 1200 of offloading a Thread border agent in accordance with aspects of the techniques described herein. At block 1202, offloaded host network stack layers receive an IP packet addressed to an indicated port at a link local address. For example, the offloaded host network stack layers (e.g., the offloaded host network stack layers 416) receive an IP packet addressed to an indicated port at a link local address (e.g., <link local Wi-Fi address>::MC).

[0053] At block 1204, a border agent sends a communication to an external commissioner device using the indicated port. For example, the border agent (e.g., the border agent 705) sends a communication to an external commissioner device using the indicated port, by assembling a UDP packet with the source port set as “MC” and passes the UDP packet to the offloaded host network stack layers for transmission to the external commissioner device.

[0054] FIG. 13 illustrates example method(s) 1300 of offloading multicast forwarding in accordance with aspects of the techniques described herein. At block 1302, a backbone router (BBR) receives a registration of an IPv6 multicast address from a Thread device. For example, a backbone router (e.g., the backbone router 805) receives a registration of an IPv6 multicast address from a Thread device and registers the IPv6 multicast address using a Multicast Protocol for Low- Power and Lossy Networks (MPL) protocol.

[0055] At block 1304, the BBR updates a multicast listener table to include the received IPv6 multicast address. For example, the BBR updates a multicast listener table, included in the TBR network stack 312, to include the received IPv6 multicast address.

[0056] At block 1306, the BBR synchronizes the update of the multicast listener table to a TBR host stack. For example, the BBR synchronizes the update of the multicast listener table to the TBR host stack (e.g., the TBR host stack 408) in the SoC 402.

[0057] At block 1308, the offloaded host network stack layers add a filter to forward multicast packets, which match entries in the multicast listener table, to the TBR network stack. For example, based on receiving APF (e.g., APF 316) byte code from the SoC, the offloaded host network stack layers add a filter to forward multicast packets, which match entries in the multicast listener table, to the TBR network stack (e.g., the TBR network stack 312).

[0058] At block 1310, the offloaded host network stack layers receive a multicast packet and at block 1312, if the received multicast packet matches the registered IPv6 multicast address, the offloaded host network stack layers forward the received multicast packet to the TBR network stack for forwarding to the Thread device. For example, the offloaded host network stack layers receive a multicast packet, and if the received multicast packet matches the registered IPv6 multicast address, the offloaded host network stack layers forward the received multicast packet to the TBR network stack for forwarding to the Thread device that subscribed to the multicast address.

[0059] FIG. 14 illustrates example method(s) 1400 of offloading IPv6 address subscriptions in accordance with aspects of the techniques described herein. At block 1402, an IPv6 layer in an offloaded TBR network stack receives one or more subscriptions to addresses of interest from a TBR host stack using a Spinel protocol. For example, an IPv6 layer (e.g., the IPv6 layer 905) in an offloaded TBR network stack (e.g., the offloaded TBR network stack 312) receives one or more subscriptions to addresses of interest from a TBR host stack (e.g., TBR host stack 408) using a Spinel protocol.

[0060] At block 1404, the IPv6 layer registers the addresses of interest in the IPv6 layer. For example, the IPv6 layer registers the addresses of interest included in a Spinel protocol message in the IPv6 layer.

[0061] At block 1406, the IPv6 layer receives an IPv6 packet that includes one of the addresses of interest. For example, the TBR network stack receives unicast or multicast IPv6 packets at the IPv6 layer.

[0062] At block 1408, based on the reception of the one of the addresses of interest, the TBR network stack wakes the application processor system from the sleep or low-power state. For example, the TBR network stack determines to wake-up the SoC (e.g., the SoC 402) if the host has subscribed to the destination address.

[0063] At block 1410, the IPv6 layer forwards the IPv6 packet to the TBR host stack. For example, after waking the SoC, the TBR network stack forw ards the IPv6 packet to the TBR host stack (e.g., the TBR host stack 408).

Example Environments and Devices

[0064] FIG. 15 illustrates an example environment 1500 in which aspects of Thread border router offload can be implemented. Generally, the environment 1500 includes the home area network (HAN) 200 implemented as part of a home or other type of structure with any number of wireless network devices that are configured for communication in a wireless network. For example, the wireless network devices can include a thermostat 1502, hazard detectors 1504 (e.g., for smoke and/or carbon monoxide), cameras 1506 (e.g., indoor and outdoor), lighting units 1508 (e.g., indoor and outdoor), and any other types of wireless network devices 1510 that are implemented inside and/or outside of a structure 1512 (e.g., in a home environment), such as a smart or connected television. In this example, the wireless network devices can also include any of the previously described devices, such as a border router 106, as well as any of the devices implemented as a router device 206, and/or as an end device 208.

[0065] In the environment 1500, any number of the wireless network devices can be implemented for wireless interconnection to wirelessly communicate and interact with each other. The wireless network devices are modular, intelligent, multi-sensing, network-connected devices that can integrate seamlessly with each other and/or with a central server or a cloud-computing system to provide any of a variety of useful automation objectives and implementations. An example of a wireless network device that can be implemented as any of the devices described herein is shown and described with reference to FIG. 16.

[0066] In implementations, the thermostat 1502 may include a Nest® Learning Thermostat that detects ambient climate characteristics (e.g., temperature and/or humidity) and controls aHVAC system 1514 in the home environment. The learning thermostat 1502 and other network-connected devices “learn” by capturing occupant settings to the devices. For example, the thermostat learns preferred temperature set-points for mornings and evenings, and when the occupants of the structure are asleep or awake, as well as when the occupants are typically away or at home.

[0067] A hazard detector 1504 can be implemented to detect the presence of a hazardous substance or a substance indicative of a hazardous substance (e.g., smoke, fire, or carbon monoxide). In examples of wireless interconnection, a hazard detector 1504 may 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 of the connected wireless network devices. The other hazard detectors 1504 can then receive the broadcast wake-up signal and initiate a high-power state for hazard detection and to receive wireless communications of alert messages. Further, the lighting units 1508 can receive the broadcast wake-up signal and activate in the region of the detected hazard to illuminate and identify the problem area. In another example, the lighting units 1508 may activate in one illumination color to indicate a problem area or region in the structure, such as for a detected fire or break-in, and activate in a different illumination color to indicate safe regions and/or escape routes out of the structure.

[0068] In various configurations, the wireless network devices 1510 can include an entry way interface device 1516 that functions in coordination with a network-connected door lock system 1518, and that detects and responds to a person’ s approach to or departure from a location, such as an outer door of the structure 1512. The entry way interface device 1516 can interact with the other wireless network devices based on whether someone has approached or entered the smart-home environment. An entry way interface device 1516 can control doorbell functionality, announce the approach or departure of a person via audio or visual means, and control settings on a security system, such as to activate or deactivate the security system when occupants come and go. The wireless network devices 1510 can also include other sensors and detectors, such as to detect ambient lighting conditions, detect room-occupancy states (e.g., with an occupancy sensor 1520), and control a power and/or dim state of one or more lights. In some instances, the sensors and/or detectors may also control a power state or speed of a fan, such as a ceiling fan 1522. Further, the sensors and/or detectors may detect occupancy in a room or enclosure and control the supply of power to electrical outlets or devices 1524, such as if a room or the structure is unoccupied.

[0069] The wireless network devices 1510 may also include connected appliances and/or controlled systems 1526, such as refrigerators, stoves and ovens, washers, dryers, air conditioners, pool heaters 1528, irrigation systems 1530, security systems 1532, and so forth, as well as other electronic and computing devices, such as televisions, entertainment systems, computers, intercom systems, garage-door openers 1534, ceiling fans 1522, control panels 1536, and the like. When plugged in, an appliance, device, or system can announce itself to the home area network as described above and can be automatically integrated with the controls and devices of the home area network, such as in the home. It should be noted that the wireless network devices 1510 may include devices physically located outside of the structure, but within wireless communication range, such as a device controlling a swimming pool heater 1528 or an irrigation system 1530.

[0070] As described above, the HAN 200 includes a border router 106 that interfaces for communication with an external network, outside the HAN 200. The border router 106 connects to an access point 110, which connects to the access network 108, such as the Internet. A cloud service 112, which is connected via the access network 108, provides services related to and/or using the devices within the HAN 200. By way of example, the cloud service 112 can include applications for connecting end user devices 1538, such as smartphones, tablets, and the like, to devices in the home area network, processing and presenting data acquired in the HAN 200 to end users, linking devices in one or more HANs 200 to user accounts of the cloud sen-ice 112, provisioning and updating devices in the HAN 200, and so forth. For example, a user can control the thennostat 1502 and other wireless network devices in the home environment using a network- connected computer or portable device, such as a mobile phone or tablet device. Further, the wireless network devices can communicate information to any central server or cloud-computing system via the border router 106 and the access point 110. The data communications can be carried out using any of a variety of custom or standard wireless protocols (e.g., Wi-Fi, ZigBee for low power, 6L0WPAN, Thread, etc.) and/or by using any of a variety of custom or standard wired protocols (CAT6 Ethernet, HomePlug, etc.).

[0071] Any of the wireless network devices in the HAN 200 can sen e as low-power and communication nodes to create the HAN 200 in the home environment. Individual low-power nodes of the network can regularly send out messages regarding what they are sensing, and the other low-powered nodes in the environment - in addition to sending out their own messages - can repeat the messages, thereby communicating the messages from node to node i.e., from device to device) throughout the home area network. The wireless network devices can be implemented to conserve power, particularly when battery-powered, utilizing low-powered communication protocols to receive the messages, translate the messages to other communication protocols, and send the translated messages to other nodes and/or to a central server or cloudcomputing system. For example, an occupancy and/or ambient light sensor can detect an occupant in a room as well as measure the ambient light, and activate the light source when the ambient light sensor 1540 detects that the room is dark and when the occupancy sensor 1520 detects that someone is in the room. Further, the sensor can include a low-power wireless communication chip (e.g., an IEEE 802. 15.4 chip, a Thread chip, aZigBee chip) that regularly sends out messages regarding the occupancy of the room and the amount of light in the room, including instantaneous messages coincident with the occupancy sensor detecting the presence of a person in the room. As mentioned above, these messages may be sent wirelessly, using the home area network, from node to node (e.g., network-connected device to network-connected device) within the home environment as well as over the Internet to a central server or cloud-computing system.

[0072] In other configurations, various ones of the wireless network devices can function as ‘'tripwires” for an alarm system in the home environment. For example, in the event a perpetrator circumvents detection by alarm sensors located at windows, doors, and other entry points of the structure or environment, the alarm could still be triggered by receiving an occupancy, motion, heat, sound, etc. message from one or more of the low-powered mesh nodes in the home area network. In other implementations, the home area network can be used to automatically turn on and off the lighting units 1508 as a person transitions from room to room in the structure. For example, the wireless network devices can detect the person’s movement through the structure and communicate corresponding messages via the nodes of the home area network. Using the messages that indicate which rooms are occupied, other wireless network devices that receive the messages can activate and/or deactivate accordingly. As referred to above, the home area network can also be utilized to provide exit lighting in the event of an emergency, such as by turning on the appropriate lighting units 1508 that lead to a safe exit. The light units 1508 may also be tumed-on to indicate the direction along an exit route that a person should travel to safely exit the structure.

[0073] The various wireless network devices may also be implemented to integrate and communicate with wearable computing devices 1542. such as may be used to identify and locate an occupant of the structure, and adjust the temperature, lighting, sound system, and the like accordingly. In other implementations, RFID sensing (e.g., a person having an RFID bracelet, necklace, or key fob), synthetic vision techniques (e.g., video cameras and face recognition processors), audio techniques (e.g., voice, sound pattern, vibration pattern recognition), ultrasound sensing/imaging techniques, and infrared or near-field communication (NFC) techniques (e.g., a person wearing an infrared or NFC-capable smartphone), along with rules-based inference engines or artificial intelligence techniques that draw useful conclusions from the sensed information as to the location of an occupant in the structure or environment.

[0074] In other implementations, personal comfort-area networks, personal health-area networks, personal safety-area networks, and/or other such human-facing functionalities of service robots can be enhanced by logical integration with other wireless network devices and sensors in the environment according to rules-based inferencing techniques or artificial intelligence techniques for achieving better performance of these functionalities. In an example relating to a personal health-area, the system can detect whether a household pet is moving toward the current location of an occupant (e.g., using any of the wireless network devices and sensors), along with rules-based inferencing and artificial intelligence techniques. Similarly, a hazard detector service robot can be notified that the temperature and humidity levels are rising in a kitchen, and temporarily raise a hazard detection threshold, such as a smoke detection threshold, under an inference that any small increases in ambient smoke levels will most likely be due to cooking activity and not due to a genuinely hazardous condition. Any service robot that is configured for any ty pe of monitoring, detecting, and/or servicing can be implemented as a mesh node device on the home area network, conforming to the wireless interconnection protocols for communicating on the home area network.

[0075] The wireless network devices 1510 may also include a network-connected alarm clock 1544 for each of the individual occupants of the structure in the home environment. For example, an occupant can customize and set an alarm device for a wake time, such as for the next day or week. Artificial intelligence can be used to consider occupant responses to the alarms when they go off and make inferences about preferred sleep patterns over time. An individual occupant can then be tracked in the home area netw ork based on a unique signature of the person, w hich is determined based on data obtained from sensors located in the wireless network devices, such as sensors that include ultrasonic sensors, passive IR sensors, and the like. The unique signature of an occupant can be based on a combination of patterns of movement, voice, height, size, etc., as well as using facial recognition techniques.

[0076] In an example of wireless interconnection, the wake time for an individual can be associated with the thermostat 1502 to control the HVAC system in an efficient manner so as to pre-heat or cool the structure to desired sleeping and awake temperature settings. The preferred settings can be learned over time, such as by capturing the temperatures set in the thermostat before the person goes to sleep and upon waking up. Collected data may also include biometric indications of a person, such as breathing patterns, heart rate, movement, etc., from which inferences are made based on this data in combination with data that indicates when the person actually wakes up. Other wireless network devices can use the data to provide other automation objectives, such as adjusting the thermostat 1502 so as to pre-heat or cool the environment to a desired setting and tuming-on or turning-off the lights 1508.

[0077] In implementations, the wireless network devices can also be utilized for sound, vibration, and/or motion sensing such as to detect running water and determine inferences about water usage in a home environment based on algorithms and mapping of the water usage and consumption. This can be used to determine a signature or fingerprint of each water source in the home and is also referred to as "‘audio fingerprinting water usage.” Similarly, the wireless network devices can be utilized to detect the subtle sound, vibration, and/or motion of unwanted pests, such as mice and other rodents, as well as by termites, cockroaches, and other insects. The system can then notify an occupant of the suspected pests in the environment, such as with warning messages to help facilitate early detection and prevention.

[0078] The environment 1500 may include one or more wireless network devices that function as a hub 1546. The hub 1546 may be a general -purpose home automation hub, or an application-specific hub, such as a security hub, an energy management hub, an HVAC hub, and so forth. The functionality of a hub 1546 may also be integrated into any wireless network device, such as a network-connected thermostat device or the border router 106. Hosting functionality on the hub 1546 in the structure 1512 can improve reliability when the user's internet connection is unreliable, can reduce latency of operations that would normally have to connect to the cloud sendee 112, and can satisfy⁷ system and regulatory⁷ constraints around local access between wireless network devices.

[0079] Additionally, the example environment 1500 includes a network-connected speaker (network-connected assistant device) 1548. The network-connected speaker 1548 provides voice assistant sendees that include providing voice control of network-connected devices. The functions of the hub 1546 may be hosted in the network-connected speaker 1548. The network-connected speaker 1548 can be configured to communicate via the wireless mesh network 202, the Wi-Fi network 204, or both.

[0080] FIG. 16 illustrates an example wireless network device 1600 that can be implemented as any of the wireless network devices (nodes) in a home area network (Thread network, fabric network. Weave network, Matter network) in accordance with one or more aspects of Thread border router offload as described herein. The device 1600 can be integrated with electronic circuitry', microprocessors, memory', input output (I/O) logic control, communication interfaces and components, as well as other hardware, firmw are, and/or software to implement the device in a home area network. Further, the wireless network device 1600 can be implemented with various components, such as with any number and combination of different components as further described with reference to the example device shown in FIG. 17.

[0081] In this example, the wireless network device 1600 includes a low-power microprocessor 1602 and a high-power microprocessor 1604 (e.g., microcontrollers or digital signal processors) that process executable instructions. The device also includes an input-output (I/O) logic control 1606 (e.g., to include electronic circuitry). The microprocessors can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any' one or combination of software, hardware, firmware, or fixed logic circuitry' that may be implemented w'ith processing and control circuits. The low-power microprocessor 1602 and the high-power microprocessor 1604 can also support one or more different device functionalities of the device. For example, the high-power microprocessor 1604 may execute computationally intensive operations, whereas the low-power microprocessor 1602 may manage less-complex processes such as detecting a hazard or temperature from one or more sensors 1608. The low-power processor 1602 may also wake or initialize the high-power processor 1604 for computationally intensive processes.

[0082] The one or more sensors 1608 can be implemented to detect various properties such as acceleration, temperature, humidity', water, supplied power, proximity⁷, external motion, device motion, sound signals, ultrasound signals, light signals, fire, smoke, carbon monoxide, global-positioning-satellite (GPS) signals, radio frequency (RF), other electromagnetic signals or fields, or the like. As such, the sensors 1608 may include any one or a combination of temperature sensors, humidity sensors, hazard-related sensors, other environmental sensors, accelerometers, microphones, optical sensors up to and including cameras (e.g., charged coupled-device or video cameras, active or passive radiation sensors, GPS receivers, and radio frequency identification detectors. In implementations, the wireless network device 1600 may include one or more primary sensors, as well as one or more secondary sensors, such as primary sensors that sense data central to the core operation of the device (e.g., sensing a temperature in a thermostat or sensing smoke in a smoke detector), while the secondary' sensors may sense other types of data (e.g., motion, light or sound), which can be used for energy-efficiency objectives or automation objectives.

[0083] The wireless network device 1600 includes a memory device controller 1610 and a memory device 1612, such as any type of a nonvolatile memory' and/or other suitable electronic data storage device. The wireless network device 1 00 can also include various firmware and/or software, such as an operating system 1614 that is maintained as computer executable instructions by the memory and executed by a microprocessor. The device software may also include a network stack application 1616 that implements aspects of Thread border router offload. The wireless network device 1600 also includes a device interface 1618 to interface with another device or peripheral component and includes an integrated data bus 1620 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 a combination of different bus structures and/or bus architectures.

[0084] The device interface 1618 may receive input from a user and/or provide information to the user (e.g.. as a user interface), and a received input can be used to determine a setting. The device interface 1618 may also include mechanical or virtual components that respond to a user input. For example, the user can mechanically move a sliding or rotatable component, or the motion along a touchpad may be detected, and such motions may correspond to a setting adjustment of the device. Physical and virtual movable user-interface components can allow the user to set a setting along a portion of an apparent continuum. The device interface 1618 may also receive inputs from any number of peripherals, such as buttons, a keypad, a switch, a microphone, and an imager (e.g., a camera device).

[0085] The wireless network device 1600 can include network interfaces 1622, such as a home area network interface for communication with other wireless network devices in a home area network, wired network devices (e.g., Ethernet-connected devices), and an external network interface for network communication, such as via the Internet. The wireless network device 1600 also includes wireless radio systems 1624 for wireless communication with other wireless network devices via the home area network interface and for multiple, different wireless communications systems. The wireless radio systems 1624 may include Wi-Fi, Bluetooth™, Mobile Broadband, BLE, and/or point-to-point IEEE 802. 15.4. Each of the different radio systems can include a radio device, antenna, and chipset that is implemented for a particular wireless communications technology. The wireless network device 1600 also includes a power source 1626, such as a battery and/or to connect the device to line voltage. An AC power source may also be used to charge the battery of the device.

[0086] FIG. 17 illustrates an example system 1700 that includes an example device 1702, which can be implemented as any of the wireless network devices that implement aspects of Thread border router offload as described with reference to the previous FIGs. 1-16. The example device 1702 may be any type of computing device, client device, mobile phone, tablet, communication, entertainment, gaming, media playback, and/or other type of device. Further, the example device 1702 may be implemented as any other type of wireless network device that is configured for communication on a home area network, such as a thermostat, hazard detector, camera, light unit, commissioning device, router, border router, j oiner router, joining device, end device, leader, access point, and/or other wireless network devices.

[0087] The device 1702 includes communication devices 1704 that enable wired and/or wireless communication of device data 1706, such as data that is communicated between the devices in a home area network, data that is being received, data scheduled for broadcast, data packets of the data, data that is synched between the devices, etc. The device data can include any type of communication data, as well as audio, video, and/or image data that is generated by applications executing on the device. The communication devices 1704 can also include transceivers for cellular phone communication and/or for network data communication.

[0088] The device 1702 also includes input/output (I/O) interfaces 1708, such as data network interfaces that provide connection and/or communication links between the device, data networks (e.g., ahome area network, external network, etc.), and other devices. The I/O interfaces can be used to couple the device to any type of components, peripherals, and/or accessory devices. The I/O interfaces also include data input ports via which any type of data, media content, and/or inputs can be received, such as user inputs to the device, as well as any type of communication data, as well as audio, video, and/or image data received from any content and/or data source.

[0089] The device 1702 includes a processing system 1710 that may be implemented at least partially in hardware, such as with any type of microprocessors, controllers, and the like that process executable instructions. The processing system can include components of an integrated circuit, programmable logic device, a logic device formed using one or more semiconductors, and other implementations in silicon and/or hardware, such as a processor and memory system implemented as a system-on-chip (SoC). Alternatively or in addition, the device can be implemented with any one or combination of software, hardware, firmware, or fixed logic circuitry that may be implemented with processing and control circuits. The device 1702 may further include any type of a system bus or other data and command transfer system that couples the various components within the device. A system bus can include any one or combination of different bus structures and architectures, as well as control and data lines.

[0090] The device 1702 also includes computer-readable storage memory 1712, such as data storage devices that can be accessed by a computing device, and that provide persistent storage of data and executable instructions (e.g., software applications, modules, programs, functions, and the like). The computer-readable storage memory described herein excludes propagating signals. Examples of computer-readable storage memory' include volatile memory' and non-volatile memory', fixed and removable media devices, and any suitable memory device or electronic data storage that maintains data for computing device access. 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.

[0091] The computer-readable storage memory 1712 provides storage of the device data 1706 and various device applications 1714, such as an operating system that is maintained as a software application with the computer-readable storage memory' and executed by the processing system 1710. The device applications may also include a device manager, such as any form of a control application, software application, signal processing and control module, code that is native to a particular device, a hardware abstraction layer for a particular device, and so on. In this example, the device applications also include a network stack application 1716 that implements aspects of Thread border router offload, such as when the example device 1702 is implemented as any of the wireless network devices described herein.

[0092] The device 1702 also includes an audio and/or video system 1718 that generates audio data for an audio device 1720 and/or generates display data for a display device 1722. The audio device and/or the display device include any devices that process, display, and/or otherwise render audio, video, display, and/or image data, such as the image content of a digital photo. In implementations, the audio device and/or the display device are integrated components of the example device 1702. Alternatively, the audio device and/or the display device are external, peripheral components to the example device. In aspects, at least part of the techniques described for Thread border router offload may be implemented in a distributed system, such as over a “cloud"’ 1724 in a platform 1726. The cloud 1724 includes and/or is representative of the platform 1726 for services 1728 and/or resources 1730.

[0093] The platform 1726 abstracts underlying functionality of hardware, such as server devices (e.g., included in the services 1728) and/or software resources (e.g., included as the resources 1730), and connects the example device 1702 with other devices, servers, etc. The resources 1730 may also include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the example device 1702. Additionally, the services 1728 and/or the resources 1730 may facilitate subscriber network services, such as over the Internet, a cellular network, or Wi-Fi network. The platfonn 1726 may also serve to abstract and scale resources to service a demand for the resources 1730 that are implemented via the platform, such as in an interconnected device aspect with functionality distributed throughout the system 600. For example, the functionality may be implemented in part at the example device 1702 as well as via the platform 1726 that abstracts the functionality of the cloud 1724.

[0094] In the following some examples are described:

Example 1 : A method of maintaining network connectivity on a Thread network by a network coprocessor, the method comprising: performing, by the network coprocessor, functions of a Thread border router (TBR) network stack and one or more layers of a host network stack offloaded from an application processor system; and maintaining bidirectional connectivity and discovery on the Thread network using, the offloaded TBR network stack and the offloaded host network stack layers, while the application processor system is in a sleep or a low-power state.

Example 2: The method of claim 1, wherein the TBR network stack includes a Thread Radio Encapsulation Link (TREL) protocol, the method further comprising: receiving, from a TBR host stack and by the offloaded TBR network stack, a source address and a destination address for TREL communication; and forwarding, by the offloaded TBR network stack, a TREL frame to a peer at the destination address using the offloaded host network stack layers.

Example 3 : The method of example 2, wherein the forwarding of the TREL frame to the peer comprises: inserting a Thread Internet Protocol (IP) packet as a pay load of a User Datagram Protocol (UDP) packet; and forwarding the UDP packet to the peer at the destination address using the offloaded host network stack lavers. Example 4: The method of example 2 or example 3, further comprising: filtering, by the offloaded host network stack layers, received IP packets addressed to the source address; and forwarding the filtered packets to the TBR network stack.

Example 5 : The method of any one of examples 2 to 4, wherein the source address and the destination address are IPv6 addresses.

Example 6: The method of any one of the preceding examples, wherein the offloaded TBR network stack includes a border agent, the method further comprising: receiving, by the offloaded host network stack layers, an IP packet addressed to an indicated port at a link local address; and sending a communication to an external commissioner device, by the border agent, using the indicated port.

Example ?: The method of example 6, wherein the sending of the communication to the external commissioner device further comprises: assembling a UDP packet with a source port set to the indicated port; and forwarding the UDP packet to the external commissioner device using the offloaded host network stack layers.

Example 8: The method of example 6 or example 7, further comprising: receiving a Spinel command, by the offloaded TBR network stack, the Spinel command including the indicated port; in response to receiving the Spinel command, starting the border agent, by the offloaded TBR network stack, using the indicated port; and returning a response to a TBR host stack indicating a success or a failure of starting the border agent.

Example 9: The method of any one of the preceding examples, wherein the TBR network stack includes a backbone router, the method further comprising: receiving a registration of an IPv6 multicast address from a Thread device; updating a multicast listener table to include the received IPv6 multicast address; synchronizing the update of the multicast listener table to a TBR host stack; adding a filter on the offloaded host network stack layers to forward multicast packets, which match entries in the multicast listener table, to the TBR network stack; receiving a multicast packet by the offloaded host network stack layers; and if the received multicast packet matches the registered IPv6 multicast address, forwarding the received multicast packet to the TBR network stack for forwarding to the Thread device.

Example 10: The method of any one of the preceding examples, the method further comprising: receiving, by an IPv6 layer in the TBR network stack, one or more subscriptions to addresses of interest from a TBR host stack using a Spinel protocol; registering the addresses of interest in the IPv6 layer; receiving an IPv6 packet that includes one of the addresses of interest; based on the receiving the one of the addresses of interest, waking the application processor system from the sleep or low-power state; and forwarding the IPv6 packet to the TBR host stack.

Example 11: The method of any one of the preceding examples, wherein the offloaded host network stack layers include one or more of: a multicast domain name service (mDNS); an Android packet filtering (APF) sendee; an Internet Protocol version 6 (IPv6) network protocol; or an Internet Control Message Protocol version 6 (ICMPv6).

Example 12: An apparatus comprising a processor, the processor configured to perform the method of any one of the preceding examples.

Example 13: A system comprising a network processor that includes : one or more layers of a Thread border router (TBR) network stack offloaded from an application processor system; one or more layers of a host network stack layers offloaded from the application processor system; a Thread radio connected to the TBR network stack; and the system configured to: maintain bidirectional connectivity and discovery on a Thread network using, the offloaded TBR network stack and the offloaded host network stack layers, while an application processor system is in a sleep or a low power state. Example 14: The system of example 13, wherein the host network stack layers include one or more of: a multicast domain name service (mDNS); an Android packet filtering (APF) service; an Internet Protocol version 6 (IPv6) network protocol; or an Internet Control Message Protocol version 6 (ICMPv6).

Example 15: The system of example 13 or example 14, further comprising: a Wi-Fi radio coupled to the host network stack layers.

Example 1 : The system of example 15, wherein the TBR network stack, the host network stack layers, the Thread radio, and the Wi-Fi radio are included in an integrated circuit (IC).

Example 17: The system of any one of examples 13 to 16, further comprising: the application processor system including a processor and memory'; the memory’ including: one or more applications; a Wi-Fi network protocol stack; and a Thread offload manager, the Thread offload manager being executable by the processor to provide an interface between the one or more applications and the TBR network stack.

Example 18 The system of example 17, wherein the TBR network stack, the host network stack layers and the Thread radio maintain bidirectional connectivity' and discovery' on the Thread network while the application processor system is in a sleep or low-power state.

[0095] Although aspects of Thread border router offload have been described in language specific to features and/or methods, the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as example implementations of Thread border router offload, and other equivalent features and methods are intended to be within the scope of the appended claims. Further, various different aspects are described, and it is to be appreciated that each described aspect can be implemented independently or in connection with one or more other described aspects.

Claims

CLAIMS What is claimed is:

1. A method of maintaining network connectivity on a Thread network by a network coprocessor, the method comprising: performing, by the network coprocessor, functions of a Thread border router (TBR) network stack and one or more layers of a host network stack offloaded from an application processor system; and maintaining bidirectional connectivity and discovery on the Thread network, using the offloaded TBR network stack and the offloaded host network stack layers, while the application processor system is in a sleep or a low-power state.

2. The method of claim 1, wherein the TBR network stack includes a Thread Radio Encapsulation Link (TREL) protocol, the method further comprising: receiving, from a TBR host stack and by the offloaded TBR network stack, a source address and a destination address for TREL communication; and forwarding, by the offloaded TBR network stack, a TREL frame to a peer at the destination address using the offloaded host network stack layers.

3. The method of claim 2, wherein the forwarding of the TREL frame to the peer comprises: inserting a Thread Internet Protocol (IP) packet as a payload of a User Datagram Protocol (UDP) packet; and forwarding the UDP packet to the peer at the destination address using the offloaded host network stack layers.

4. The method of claim 2 or claim 3, further comprising: filtering, by the offloaded host network stack layers, received IP packets addressed to the source address: and forwarding the filtered packets to the TBR network stack.

5. The method of any one of claims 2 to 4, wherein the source address and the destination address are IPv6 addresses.

6. The method of any one of the preceding claims, wherein the offloaded TBR network stack includes a border agent, the method further comprising: receiving, by the offloaded host network stack layers, an IP packet addressed to an indicated port at a link local address; and sending a communication to an external commissioner device, by the border agent, using the indicated port.

7. The method of claim 6, wherein the sending of the communication to the external commissioner device further comprises: assembling a UDP packet with a source port set to the indicated port; and forwarding the UDP packet to the external commissioner device using the offloaded host network stack layers.

8. The method of claim 6 or claim 7, further comprising: receiving a Spinel command, by the offloaded TBR network stack, the Spinel command including the indicated port; in response to receiving the Spinel command, starting the border agent, by the offloaded TBR network stack, using the indicated port; and returning a response to a TBR host stack indicating a success or a failure of starting the border agent.

9. The method of any one of the preceding claims, wherein the TBR network stack includes a backbone router, the method further comprising: receiving a registration of an IPv6 multicast address from a Thread device; updating a multicast listener table to include the received IPv6 multicast address; synchronizing the update of the multicast listener table to a TBR host stack; adding a filter on the offloaded host network stack layers to forward multicast packets, which match entries in the multicast listener table, to the TBR network stack; receiving a multicast packet by the offloaded host network stack layers; and if the received multicast packet matches the registered IPv6 multicast address, forwarding the received multicast packet to the TBR network stack for forwarding to the Thread device.

10. The method of any one of the preceding claims, the method further comprising: receiving, by an IPv6 layer in the offloaded TBR network stack, one or more subscriptions to addresses of interest from a TBR host stack using a Spinel protocol; registering the addresses of interest in the IPv6 layer; receiving an IPv6 packet that includes one of the addresses of interest; based on the receiving the one of the addresses of interest, waking the application processor system from the sleep or low-power state; and forwarding the IPv6 packet to the TBR host stack.

11. The method of any one of the preceding claims, wherein the offloaded host network stack layers include one or more of: a multicast domain name service (mDNS); an Android packet filtering (APF) service; an Internet Protocol version 6 (IPv6) network protocol; or an Internet Control Message Protocol version 6 (ICMPv6).

12. An apparatus comprising a processor, the processor configured to perform the method of any one of the preceding claims.

13. A system comprising a network processor that includes: one or more layers of a Thread border router (TBR) network stack offloaded from an application processor system; one or more layers of a host network stack layers offloaded from the application processor system; a Thread radio connected to the TBR network stack; and the system configured to: maintain bidirectional connectivity and discovery on a Thread network using, the offloaded TBR network stack and the offloaded host network stack layers, while an application processor system is in a sleep or a low power state.

14. The system of claim 13, wherein the host network stack layers include one or more of: a multicast domain name sen ice (mDNS); an Android packet filtering (APF) service; an Internet Protocol version 6 (IPv6) network protocol; or an Internet Control Message Protocol version 6 (ICMPv6).

15. The system of claim 13 or claim 14, further comprising: a Wi-Fi radio coupled to the host network stack layers.

16. The system of claim 15, wherein the TBR network stack, the host network stack layers, the Thread radio, and the Wi-Fi radio are included in an integrated circuit (IC).

17. The system of any one of claims 13 to 16, further comprising: the application processor system including a processor and memory; the memoi)' including: one or more applications; a Wi-Fi network protocol stack; and a Thread offload manager, the Thread offload manager being executable by the processor to provide an interface between the one or more applications and the TBR network stack.

18. The system of claim 17, wherein the TBR network stack, the host network stack layers and the Thread radio maintain bidirectional connectivity and discovery' on the Thread network while the application processor system is in a sleep or low-power state.