Enhanced link loss detection and parent reselection for power limited accessories

Abstract

The invention provides an enhanced link loss detection and parent reselection for power limited accessories. An apparatus configured to process a data request based on signaling received from a sub-device, determine whether an activity context with the sub-device exists based on data stored in firmware, and determine whether to respond to the data request based on whether an activity context with the sub-device exists.

Description

Background Art

[0001] A parent device can interact with a sleep end device (SED) (e.g., a child device), which includes a variety of connected smart home devices such as locks, thermostats, and sensors. The Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard defines the technical specifications for low-rate, low-power wireless personal area networks (WPANs). Emerging protocols use the 802.15.4 standard for smart home use cases.

[0002] SEDs are typically battery powered and are highly power constrained. Minimization of SED power usage is an ongoing concern in the art. SEDs send periodic media access control data request frames to a powered device that acts as the parent of the SED. During the initial attachment procedure, the SED selects a parent. All communications to and from the SED are then routed through the parent. Maintenance of parent-child links is critical for reliable communication and battery usage of the SED. Enhanced parent-child link maintenance procedures are needed in the art to address limitations of existing parent-child link maintenance, including link loss detection and recovery time, power consumption, compatibility, overhead, and reliability. Summary of the invention

[0003] Some example embodiments relate to an apparatus having a processing circuit configured to: process a data request based on signaling received from a sub-device, determine whether there is an active context with the sub-device based on data stored in firmware, and determine whether to respond to the data request based on whether there is the active context with the sub-device.

[0004] Some example embodiments relate to a wireless communication device having: a transceiver circuit configured to communicate with a sub-device; and a processing circuit communicatively coupled to the transceiver circuit and configured to: process a data request based on signaling received from the sub-device, determine whether an active context exists between the wireless communication device and the sub-device based on data stored in firmware, and determine whether to respond to the data request based on whether the active context exists with the sub-device.

[0005] Some example embodiments relate to a method performed by a parent device, the method comprising: processing a data request based on signaling received from a child device, determining whether the parent device has an active context with the child device based on data stored in firmware of the parent device, and determining whether to respond to the data request based on whether the parent device has the active context with the child device. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 Example network arrangements are shown according to various example embodiments.

[0007] Figure 2 An example parent device is shown according to various example embodiments.

[0008] Figure 3 A parent-child arrangement is shown according to various example embodiments.

[0009] Figure 4 A call flow between a parent device and a SED is shown according to various example embodiments.

[0010] Figure 5 Methods for operations performed by a parent device in a parent-child relationship with a SED device are shown according to various example embodiments. DETAILED DESCRIPTION

[0011] Example embodiments may be further understood with reference to the following description and associated drawings, wherein like elements have the same reference numerals. Example embodiments relate to improved parent behavior for SED link degradation scenarios.

[0012] The example embodiments are described with respect to a parent device. However, reference to a parent device is provided for illustrative purposes only. The example embodiments may be used with any electronic component that can establish a connection with a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the parent device described herein is used to represent any electronic component.

[0013] Operations and logic for enhancing parent-child link loss detection and parent reselection are disclosed herein. In recent years, the popularity of smart home devices has grown and is expected to continue to grow rapidly in use. Standards such as Thread, Matter, and Zigbee have increased interoperability between various parent devices and SEDs (e.g., child devices).

[0014] The SED selects a parent device during the initial attach procedure. All communications to and from the SED are routed through the parent device. As described above, optimal maintenance of the parent-child link is critical to reliable communications with the SED and reduced battery usage of the SED.

[0015] There may be situations where the parent and child devices do not completely lose communication between each other, but signal interference results in packet loss and a low-quality connection. Unlike a total signal loss that would trigger a parent reselection procedure by the child device, a bad parent-child connection may persist and waste both signaling time and limited child battery capacity.

[0016] Several existing parent-child link maintenance procedures have been implemented; however, each has various limitations that reduce its effectiveness. The Thread 1.1 standard defines that a child update request message is sent periodically by the child. The child update message has a large signaling overhead. In addition, link failure detection and link failure recovery operations occur on the order of minutes.

[0017] The Thread 1.2 standard defines an enhanced keep-alive mechanism using an acknowledgement message (ACK) for periodic data requests. A parent device using Thread 1.2 can remove the child context but can still send an ACK in response to a data request message sent by the child. This implementation has a negative impact on signaling reliability and child battery performance. The Thread 1.3.1 standard defines a child supervision procedure in which the parent device must periodically send null frames to the child to maintain an inactive link. Both the parent and child devices must be Thread 1.3.1 compatible, which may not always be the case when the parent and child devices are from different original equipment manufacturers (OEMs). In addition, this implementation has the overhead of exchanging additional null frames and synchronization supervision related parameters.

[0018] The exemplary embodiment provides a way to manage the parent-child relationship so that when the parent device removes the child context, the child device is promptly notified that the parent-child relationship no longer exists. When the parent device no longer acknowledges the data request sent by the child device when performing the link maintenance procedure, the child device is notified.

[0019] Figure 1 An example network arrangement 100 according to various example embodiments is shown. The example network arrangement 100 includes a parent device 110. The parent 110 can be any type of electronic component configured to communicate via a network, such as a home hub, a mobile phone, a tablet computer, a desktop computer, a smart phone, an embedded device, a wearable device, an Internet of Things (IoT) device, etc. The actual network arrangement may include any number of parent devices. Therefore, for illustrative purposes, only an example with one parent device 110 is provided. The parent device 110 can act as a parent of a child device (such as a sleep terminal device (SED)). The network configuration 100 includes SED 102, SED 106, and SED 108. Each of SED 102-108 can be a child device of the parent device 110. Each of SED 102-108 can be a SED of the same type, or a SED of a different type. For example, SED 102 can be a smart lock, SED 106 can be a door sensor, and SED 108 can be a smart thermostat. In other variations, SEDs 102-108 may have substantially the same functionality as parent device 110. In still further variations, SEDs 102-108 may have a reduced feature set compared to parent device 110. Thus, a parent device may include any wireless communication device.

[0020] Typically, parent device 110 may have a larger battery capacity or may have access to line power (eg, may be pluggable) than SEDs 102-108, which may be battery-constrained devices. However, this relative battery capacity is not a requirement of example embodiments.

[0021] Parent device 110 may be configured to communicate with one or more networks, such as a Wi-Fi network, a cellular network, etc. As described above, all communications of SEDs 102-108 may be routed through parent device 110. Thus, parent device 110 and each of SEDs 102-108 may communicate via a wireless short-range communication protocol.

[0022] To provide a non-limiting example, the parent device 110 may be a smart home hub, such as a smart speaker connected to a home Wi-Fi network that allows communication access to the parent device 110. The SED 108 may be a thermostat in the home. The owner of the home (e.g., a user) may be in a remote location and may want to access the thermostat 108 to change the temperature in the home before the owner returns home. The user may communicate with the thermostat 108 via an application on the user's mobile phone. The communication may be routed through the public Internet to the home Wi-Fi network to the smart home hub 110, which may then send the communication to the thermostat 108 via a short-range protocol connection.

[0023] Figure 2 An example parent device 110 is shown according to various example embodiments. Figure 1 The parent device 110 is described with reference to the network arrangement 100 of FIG. The parent device 110 may represent any electronic device and may include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. The other components 230 may include, for example, an audio input device, an audio output device, a data acquisition device, a port for electrically connecting the parent device 110 to other electronic devices, a sensor for detecting the status of the parent device 110, and the like.

[0024] The processor 205 may be configured to execute multiple engines of the parent device 110. For example, the engine may include an SED engine 235 for performing operations related to managing the connection between the parent device 110 and the child SED device, including but not limited to updating the child table, moving the child table to firmware, and determining whether to send an ACK to the child based on the child table. Examples of these operations will be described in more detail below.

[0025] The above-mentioned engine as an application (e.g., program) executed by the processor 205 is only an example. The functionality associated with the engine may also be represented as an independent combined component of the parent device 110, or may be a modular component coupled to the parent device 110, for example, an integrated circuit with or without firmware. For example, an integrated circuit may include an input circuit for receiving a signal and a processing circuit for processing the signal and other information. The engine may also be embodied as an application or multiple independent applications. In addition, in some parent devices, the functionality described for the processor 205 is split between two or more processors (such as a baseband processor and an application processor). The example implementation scheme may be implemented in any of these or other configurations of the parent device.

[0026] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by parent 110. Display device 215 may be a hardware component configured to display data to a user, and I / O device 220 may be a hardware component that enables user input. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touch screen).

[0027] The transceiver 225 may be a hardware component configured to establish a connection with one or more networks, such as a Wi-Fi network or a cellular network. The transceiver 225 may be configured with a network interface card that allows a wired connection to one or more networks (e.g., an Ethernet connection) or may be wirelessly connected to one or more networks. As described above, the parent device 110 may also communicate with the SED device via a wireless short-range connection. Therefore, the transceiver 225 may operate on a variety of different frequencies or channels (e.g., a set of continuous frequencies). The transceiver 225 includes a circuit configured to transmit and / or receive signals (e.g., control signals, data signals). Such signals may be encoded with information that implements any of the methods described herein. The processor 205 may be operably coupled to the transceiver 225 and configured to receive signals from and / or transmit signals to the transceiver 225. The processor 205 may be configured to encode and / or decode signals (e.g., signaling from a base station of a network) for implementing any of the methods described herein.

[0028] Example embodiments disclose operations and logic for enhancing link loss detection. A parent device (e.g., parent device 110) can remove the context of a child device (e.g., any one of SEDs 102-108). This may occur for a variety of reasons, such as link degradation. Removing the SED context is not equivalent to deleting or blocking communication with the SED. Existing implementations allow the parent device to continue to respond to data requests from the SED despite the SED context being removed. The reason for this unwanted behavior is related to the speed at which the parent device must respond to data requests sent by the SED. The IEEE standard requires that the parent device respond to IEEE 802.15.4 data requests in the order of 192 μs (microseconds). This short time length is not enough for the parent device to check whether the data request is from a child whose context has been removed. In the absence of sufficient time to check the child context, the parent device responds to the child with an ACK, even though the child context has been removed due to link degradation. These ACKs waste signaling and battery for both the parent and child devices. In addition, continuing to receive ACKs prevents the child from initiating a parent reselection procedure.

[0029] Figure 3 A parent-child arrangement 300 is shown according to various example embodiments. The arrangement 300 includes a parent device 301, which may include features and functionality substantially similar to the parent device 110, and an SED 320. The parent device 301 includes a host processor 302 and firmware 306. As described above, because the standard requires that the parent device 301 respond quickly to data requests from the SED 320, the processing of the data request is performed in the firmware 306, for example, requiring the data request to be processed by the host processor 302 may result in the parent device 301 not responding within the standard specified time of 192 μs.

[0030] During normal operation, the SED 320 will use the data request transmitter 314 to transmit a data request to the parent device 301. The frame receive (Rx) interrupt handler 310 implemented in the firmware 306 of the parent device 301 receives the data request. The frame Rx interrupt handler 310 can execute an interrupt service routine (ISR) to process the received frame. The 802.15.3 ACK generator 312 implemented in the firmware 306 of the parent device 301 can then generate an ACK and transmit the ACK in response to the SED 320.

[0031] As described above, there may be instances where a parameter of the communication link between the parent device 301 and the SED 320 is below a predefined threshold, causing the parent device 301 to remove the context of the SED 320, e.g., the parent device 301 is no longer the parent of the SED 320. Such instances may include degradation of the link quality of the communication link between the parent device 301 and the SED 320 (e.g., below a predefined threshold). Link quality may be measured in parameters including, for example, received signal strength indication (RSSI), signal to interference plus noise ratio (SINR), packet delivery rate (PDR), bit error rate (BER), etc. Also as described above, because the parent device 301 is required by the standard to respond to a data request within a short amount of time (e.g., 192 μs), the firmware 306 cannot send a data request to the host processor 302 to check the context of the SED 320 (e.g., whether the context of the SED 320 is removed). Therefore, the parent device 301 will respond to the data request even if the context of the SED 320 has been removed.

[0032] Example embodiments address this issue by having the host processor 302 maintain the child table 308 in the firmware 306, which may allow the firmware 306 to check whether the context of a child (eg, SED 320) has been removed.

[0033] The host processor 302 of the parent device 301 may, for example, execute the SED engine 235 described above. Executing the SED engine 235 may cause the host processor 302 to implement child context maintenance procedures 304. These child context maintenance procedures 304 may include adding contexts for children, removing contexts for children, etc. The child context maintenance procedures 304 may also include maintaining a child table 308 in the firmware 306 of the parent device 301. The child table 308 may contain information about all contexts corresponding to active (e.g., linked) child devices. Figure 3 In the example of FIG. 3 , if SED 320 is an active child of parent device 301, child table 308 may include an entry for SED 320. However, if host processor 302 removes the context of SED 320, the entry will be removed from child table 308.

[0034] Because child table 308 is maintained in firmware 306, parent device 301 can access child table 308 when responding to a data request from SED 320. For example, if parent device 301 receives a data request from SED 320, firmware 306 can check child table 308 to determine whether the parent device has an active context with SED 320 before generating and transmitting an ACK for the data request.

[0035] If the context is active, the parent device 301 may generate and transmit an ACK in response to the data request. However, if the context is inactive, e.g., there is no entry for the SED 320 in the child table 308, the parent device 301 will not transmit an ACK to the SED 320. If the SED 320 does not receive the ACK, this will cause the ACK handler 316 of the SED 320 to trigger a link loss procedure and initiate a parent reselection procedure 318 to set up a child relationship with another parent device (or the same parent device 301 if the poor link quality is only a temporary problem). The following reference is made to Figure 4 The calling process and Figure 5 Other examples of the operation of parent device 301 and SED 320 are described in detail below.

[0036] Example embodiments may improve power usage of both the parent device and the SED by stopping further ACK and data requests after the parent device removes the context of the SED.Example embodiments do not require the parent or SED to be on the same protocol version / type or from the same OEM.

[0037] Figure 4 4 shows a call flow 400 between a parent device 404 and a SED 402 according to various example embodiments. The call flow 400 further describes operations performed by the parent device 404 and the child 402. The parent device 404 can be similar to the parent device 301 and the SED 402 can be similar to the reference 402. Figure 3 Depicted SED 320. For purposes of example call flow 400, SED 402 and parent device 404 have established a parent-child link before call flow 400 begins, e.g., parent device 404 has an entry for SED 402 in a child table (e.g., child table 308) stored in firmware.

[0038] At 406, SED 402 transmits a data request (eg, an IEEE 802.15.4 data request) to parent device 404 as part of a routine link maintenance procedure.

[0039] In 407, parent device 404 determines whether SED 402 is in the firmware sub-table. For the purposes of this example, it may be considered that the entry for SED 402 is in the firmware sub-table.

[0040] In 408, parent device 404 transmits an ACK frame to SED 402. The ACK frame is part of a typical link maintenance procedure between parent device 404 and SED 402.

[0041] In 410, parent device 404 removes the context associated with SED 402. This may occur for a variety of reasons, such as link degradation. As part of the child context maintenance procedure, parent device 404 may update the firmware table to remove the entry for SED 402.

[0042] In 412, SED 402 transmits another data request (e.g., an IEEE 802.15.4 data request) to parent device 404. In 413, parent device 404 determines whether SED 402 is in the firmware sub-table. In this case, parent device 404 removed the context of SED 402 in 410, so in determination 413, parent 404 did not find SED 402 in the firmware sub-table.

[0043] In 414 , parent device 404 refrains from transmitting an ACK to SED 402 based on determination 413 .

[0044] In 415, SED 402 initiates a parent reselection procedure because it did not receive an ACK from parent device 404 within a standardized period of time.

[0045] Figure 5 A method 500 for operations performed by a parent device (e.g., parent device 110) in a parent-child relationship with an SED device (e.g., any of SED devices 102-108) is shown according to various example embodiments. Figure 1 and Figure 2 The method 500 is described from the perspective of the parent device 110, but it should be understood that the example method 500 may be implemented by any parent device.

[0046] The parent device 110 updates its firmware with a child context table in 502. The child context table contains context information about the currently linked child SED.

[0047] In 504, the parent device 110 determines that the link between itself and the child has fallen below a threshold. In some variations, the threshold is predefined and static. In other variations, the threshold may be dynamically defined based on factors such as link quality, parent and / or child battery status, and SED type and / or capabilities.

[0048] The parent device 110 removes the child associated with the link degradation from the child context table in 506. Any other SEDs that have not fallen below the threshold remain linked with the parent device 110 and are not removed from the child context table.

[0049] In 508, the parent device 110 receives a data request from the removed child. The data request may be an IEEE 802.15.4 data request. In 510, the parent device 110 does not send an ACK to the removed child in response to the data request.

[0050] Example

[0051] In a first embodiment, a method includes processing a data request based on signaling received from a sub-device, determining whether there is an active context with the sub-device based on data stored in firmware, and determining whether to respond to the data request based on whether there is the active context with the sub-device.

[0052] In a second embodiment, according to the method of the first embodiment, the method further comprises: when the active context with the sub-device exists, generating an acknowledgement (ACK) as a response to the data request for transmission to the sub-device.

[0053] In a third embodiment, according to the method of the first embodiment, the method further comprises: when there is no active context with the child device, suppressing a response to the data request.

[0054] In a fourth embodiment, according to the method of the first embodiment, the sub-device includes a dormant terminal device.

[0055] In a fifth embodiment, according to the method of the first embodiment, the data request comprises an IEEE 802.15.4 data request.

[0056] In a sixth embodiment, the method according to the first embodiment, wherein determining whether to respond to the data request is performed within 192 microseconds from receiving the data request.

[0057] In a seventh embodiment, the method according to the first embodiment, wherein the data stored in the firmware includes a sub-table.

[0058] In an eighth embodiment, according to the method of the seventh embodiment, the method further comprises establishing the activity context with the sub-device and storing an indication of the activity context in the sub-table.

[0059] In a ninth embodiment, according to the method of the eighth embodiment, the method further includes determining that a parameter of the communication link with the sub-device is below a threshold, removing the active context for the sub-device, and removing the indication of the active context from the sub-table.

[0060] In a tenth embodiment, according to the method of the ninth embodiment, the threshold value is a predetermined value.

[0061] In an eleventh embodiment, according to the method of the ninth embodiment, the threshold is based on link quality, battery status of the apparatus, sub-device battery status, sub-device type, or sub-device capability.

[0062] In a twelfth embodiment, a processor is configured to perform any one of the fifth to eleventh embodiments.

[0063] In a thirteenth embodiment, a processor is configured to perform any one of the fifth to eleventh embodiments.

[0064] In a fourteenth embodiment, a wireless communication device is configured to implement any one of the fifth to eleventh embodiments.

[0065] Those skilled in the art will appreciate that the example embodiments described above may be implemented with any suitable software configuration or hardware configuration or combination thereof. Example hardware platforms for implementing the example embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, etc. The example embodiments of the above methods may be embodied as a program comprising lines of code stored on a non-transitory computer-readable storage medium, which, when compiled, may be executed on a processor or microprocessor.

[0066] Although this patent application describes various embodiments, each having different features in various combinations, those skilled in the art will understand that any feature of an embodiment may be combined with features of other embodiments in any manner not publicly denied or with features that are not functionally or logically inconsistent with the operation or function of the device of the embodiments disclosed herein.

[0067] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0068] It will be apparent to those skilled in the art that various modifications may be made to the present disclosure without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is intended to cover modifications and variations of the present disclosure, provided that these modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. An apparatus, comprising a processing circuit, wherein the processing circuit is configured to: processing the data request based on signaling received from the child device; determining whether there is an active context with the child device based on data stored in the firmware; as well as Whether to respond to the data request is determined based on whether the activity context with the child device exists.

2. The apparatus of claim 1 , wherein the processing circuit is further configured to: When the active context with the sub-device exists, an acknowledgement (ACK) is generated as a response to the data request for transmission to the sub-device. 3 . The apparatus of claim 1 , wherein the processing circuit is further configured to: suppress a response to the data request when there is no active context with the child device. The apparatus according to claim 1 , wherein the sub-device comprises a dormant terminal device.

5. The apparatus of claim 1, wherein the data request comprises an IEEE 802.15.4 data request.

6. The apparatus of claim 1, wherein the processing circuit determines whether to respond to the data request within 192 microseconds from receipt of the data request. The apparatus of claim 1 , wherein the data stored in firmware comprises a sub-table.

8. The apparatus of claim 7, wherein the processing circuit is further configured to: Establishing the activity context with the child device; An indication of the activity context is stored in the sub-table.

9. The apparatus of claim 8, wherein the processing circuit is further configured to: determining that a parameter of a communication link with the sub-device is below a threshold; removing the activity context for the child device; and The indication of the active context is removed from the sub-table.

10. The apparatus according to claim 9, wherein the threshold value is a predetermined value.

11. The apparatus of claim 9, wherein the threshold is based on link quality, a battery status of the apparatus, a sub-device battery status, a sub-device type, or a sub-device capability.

12. A wireless communication device, comprising: a transceiver circuit configured to communicate with the sub-device; and a processing circuit communicatively coupled to the transceiver circuit and configured to: processing the data request based on the signaling received from the child device; determining whether an active context exists between the wireless communication device and the sub-device based on data stored in firmware; as well as Whether to respond to the data request is determined based on whether the activity context with the child device exists.

13. The wireless communication device of claim 12, wherein the processing circuit is further configured to: When the active context with the sub-device exists, an acknowledgement (ACK) is generated as a response to the data request for transmission to the sub-device.

14. The wireless communication device of claim 12, wherein the processing circuit is further configured to suppress responding to the data request when the active context with the child device does not exist.

15. The wireless communication device of claim 12, wherein the sub-device comprises a dormant terminal device.

16. The wireless communication device of claim 12, wherein the data request comprises an IEEE 802.15.4 data request.

17. The wireless communication device of claim 12, wherein the processing circuit determines whether to respond to the data request within 192 microseconds from receiving the data request.

18. The wireless communication device of claim 12, wherein the data stored in firmware comprises a sub-table.

19. The wireless communication device of claim 18, wherein the processing circuit is further configured to: establishing the activity context with the child device; and An indication of the activity context is stored in the sub-table.

20. A method performed by a parent device, the method comprising: processing the data request based on signaling received from the child device; determining whether the parent device has an active context with the child device based on data stored in firmware of the parent device; as well as Whether to respond to the data request is determined based on whether the parent device has the activity context with the child device.

Images