Switching PANs while maintaining parent/child relationships

Information

  • Patent Grant
  • 10609573
  • Patent Number
    10,609,573
  • Date Filed
    Tuesday, May 8, 2018
    6 years ago
  • Date Issued
    Tuesday, March 31, 2020
    4 years ago
Abstract
Systems and methods for managing nodes in mesh networks are provided. A parent node may switch PANs and coordinate the switch with its child nodes. The parent node and its child nodes may maintain timing synchronization information for a current PAN and a new PAN. The parent node and its child nodes may switch to the new PAN using the same switching time.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. Ser. No. 15/974,499 and U.S. Ser. No. 15/974,541, both of which are filed concurrently herewith and are incorporated herein by reference for all purposes.


FIELD OF THE INVENTION

This invention relates to managing nodes in mesh networks, and in particular to maintaining parent/child relationships when switching PANs.


BACKGROUND

A PAN architecture may have a hysteresis in network topology to prevent thrashing when there is a temporary disruption in the network, such as a temporary loss of backhaul connection. However, some systems and devices cannot tolerate a temporary loss of backhaul connection and need to switch PANs once the backhaul connection becomes unavailable.


Generally, a root node does not routinely communicate the status of the backhaul connection to the other nodes in the PAN. Instead, each node has to determine the state of the backhaul connection by sending upper layer messages and receiving a response from the backhaul. Since a node cannot send an upper layer message until it joins a PAN, a node cannot determine the status of the backhaul connection prior to joining. A node that requires a backhaul connection may join a PAN and then determine that a backhaul connection is unavailable.


A node that determines that the backhaul connection for its current PAN is unavailable, may determine that it needs to switch PANs. However, the node may not have direct visibility to another PAN, which may delay the switch to a different PAN.


When a node switches PANs, any child nodes remain with the current PAN by finding a new parent node or switch to the new PAN by unjoining the current PAN and joining the new PAN. This process is time consuming and causes the child node to be unavailable until it locates a new parent or completes the unjoining/joining process.


SUMMARY

Aspects of the invention provide improvements to the way that a node determines the status of a backhaul connection and joins or switches to a PAN with an available backhaul connection. Additional aspects of the invention provide a more efficient way to switch PANs when a node has a child node. The node may bring its child node with it when it switches regardless of the reason for the switch.


A node may consider the status of a backhaul connection prior to joining a PAN. The node may be a critical node that requires an available backhaul connection. The status of the backhaul connection may be included in a layer 2 message, such as a beacon. In one example, backhaul status information is included in an information element in the beacon.


Once a critical node joins a PAN, a critical path may be established from the critical node to the root of the PAN. In one example, layer 3 messages, such as DAO messages are used to establish the critical path. Nodes along the critical path may seek to join a new PAN when the backhaul connection for the current PAN becomes unavailable.


When a node switches to a new PAN, it may coordinate the switch with its child nodes. The switching node identifies a new PAN and obtains timing synchronization information for the new PAN. The switching node sends timing synchronization information for the new PAN and a time for switching to the new PAN to its child nodes. The switching node and the child nodes maintain timing synchronization information for both the current PAN and the new PAN. At the time for switching, the switching node and its child nodes switch to the new PAN. A node may coordinate the switch to the new PAN with its child node whenever a switch occurs. The coordination is not limited to a switch based on a loss of a backhaul connection.


These illustrative aspects and features are mentioned not to limit or define the invention, but to provide examples to aid understanding of the inventive concepts disclosed in this application. Other aspects, advantages, and feature of the present invention will become apparent after review of the entire application.





BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the present disclosure are better understood when the following Detailed Description is read with reference to the accompanying drawings, where:



FIG. 1 illustrates two PANs and an unjoined critical node according to one aspect of the invention.



FIG. 2 illustrates a critical node joined to a PAN according to one aspect of the invention.



FIG. 3 illustrates a loss of a backhaul connection for a PAN according to one aspect of the invention.



FIG. 4 illustrates a critical node switching to a different PAN according to one aspect of the invention.



FIG. 5 illustrates a parent node switching to a different PAN according to one aspect of the invention.



FIG. 6 illustrates a parent node and its child nodes switching to a different PAN according to one aspect of the invention.



FIG. 7 illustrates communications between a joining node and two PANs according to one aspect of the invention.



FIG. 8 illustrates an exemplary node according to one aspect of the invention.





DETAILED DESCRIPTION

The present invention is directed to systems and methods for managing nodes in mesh networks, including joining a critical node to a PAN, creating and maintaining a critical path, PAN switching by critical path nodes, and maintaining parent/child relationships when switching PANs. A critical node may consider the status of the backhaul connection for a PAN prior to joining the PAN. Once joined, a critical path from the critical node to the root is identified and nodes along the critical path, including the critical node, may attempt to join a new PAN if the backhaul connection for the current PAN becomes unavailable. The status of the backhaul connection for a PAN may be communicated in an information element (IE) in a beacon. If a critical path node is a parent node with one or more child nodes and it switches PANs, then the critical path node and the child nodes may switch PANs while maintaining their parent-child relationship. A parent node may maintain its parent-child relationship with its child node when it switches PANs for reasons other than a loss of a backhaul connection.


Critical Node and Critical Path



FIG. 1 illustrates two PANs, PAN A and PAN B. Node 110 is the root for PAN A and node 150 is the root for PAN B. PAN A includes nodes A-1 through A-6 and PAN B includes nodes B-1 and B-2. Backhaul connection 104 connects PAN A with a central system 102 and backhaul connection 106 connects PAN B with the central system. Although not shown in FIG. 1, there may be any number of intervening devices between a PAN and the central system 102.


Node 110 and node 150 monitor the status of their respective backhaul connections and include information about the status of their backhaul connections in their beacons. In one example, they determine whether they are connected to an NTP server and if so, determine that their backhaul connection is available. Other implementations may consider other factors to determine whether their backhaul connection is available or unavailable including, but not limited to, connection to a specific system or server or connection to a time source. Each node includes its current backhaul status information in an IE in its respective beacon. The IE may be a new IE or may be an existing IE. If an existing IE is used, then the backhaul status information may be appended to the IE. Any type of IE that includes backhaul status information is referred to herein as a backhaul status IE. The backhaul status information may be conveyed in one bit where a first value indicates that the backhaul connection is available and a second value indicates that the backhaul connection is unavailable or unknown. In some implementations, the backhaul status information includes additional information, such as how long the backhaul connection has been in its current state. For example, a timestamp indicating the time of the last status change may be used. In the example illustrated in FIG. 1, the backhaul connection 104 is available and the backhaul connection 106 is unavailable.


In FIG. 1, node N is a critical node that is not joined to either PAN. A critical node is a node that requires a backhaul connection. It may not be able to wait for the backhaul connection to reconnect if it becomes available. One example of a critical node is a node associated with DA (Distribution Automation) equipment, such as line sensors, switches, and re-closers. A node may be designated as a critical node upon installation or may be designated as a critical node after installation.


Node N receives Beacon A from PAN A and Beacon B from PAN B. In this example, Beacon A includes a backhaul status IE that indicates that backhaul connection 104 is available and Beacon B includes a backhaul status IE that indicates that backhaul connection 106 is unavailable. Since node N is a critical node, it joins PAN A. Critical nodes may be configured to avoid joining a PAN with an unavailable backhaul connection, even though other factors, e.g., rank, load, etc. may be favorable to joining the PAN.



FIG. 2 illustrates PAN A after node N joins. After node N joins, it sends a DAO message that identifies node N as a critical node. In one example, node N sets a bit in the DAO flag field to indicate that it is a critical node. Based on the DAO message, node 110, which is the root for PAN A, determines a critical path for node N and stores information describing the critical path for node N, i.e., the path including node N, node A-5, node A-4, and node A-1. The root may send a DAO-ACK message to Node N with a bit set to indicate that a critical path is in place.


In some implementations, as each node between the root and Node N receives the DAO-ACK message, the node checks the bit and determines that it is a critical path node. If a node does not support critical path nodes, then after it receives the message, it does not forward the message. Instead, it may discard the message or send an error message.


Node N may use other types of messages or other fields to indicate that it is a critical node including, but not limited to an indication in a hop-by-hop extension header of an IPv6 message. In one example, Node N sets a bit in a hop-by-hop extension header to indicate that it is a critical node and is requesting a critical path. When node A-5 supports critical path nodes, it receives the message, checks the bit, enters a pre-critical path state, and forwards the message to the next node. This process repeats until the message reaches the root of PAN A. When the root sends a message back to Node N indicating that a critical path is in place, the nodes between the root and Node N may examine the message and transition from a pre-critical path state to a critical path state.


Since PAN A may be a wireless mesh network, the critical path for node N may change. If the critical path changes, then the critical path for node N may include additional or different nodes. The critical path information maintained by the root and the critical path status of each node affected by the change are updated to reflect the change in the critical path.


After node N joins PAN A, it generates and sends beacons that include a backhaul status IE. Node N obtains the information for the backhaul status IE from the beacons that it receives from its parent node A-5 or other nodes in PAN A.


Loss of Backhaul Connection and Critical Path



FIG. 3 illustrates the scenario where PAN A's backhaul connection becomes unavailable and PAN B's backhaul connection is available. When node 110 detects that its backhaul connection is unavailable, then it may generate a beacon, Beacon A, that includes backhaul status information in the backhaul status IE. The information regarding the status of the backhaul connection is propagated through the network until node N receives a beacon with a backhaul status IE indicating that the backhaul connection for PAN A is unavailable. Since node N is a critical node, it may begin searching for a new PAN to join once it determines that the backhaul connection for its current PAN is unavailable. If node N receives a beacon from a different PAN, such as Beacon B from PAN B, it may consider whether the backhaul connection for PAN B is available when determining whether to switch PANs. If it decides to switch PANs, then it may follow a similar process to that described above in connection with FIGS. 1 and 2 for joining PAN B. In this instance, the other nodes joined to PAN A may remain joined to PAN A, as shown in FIG. 4.


When node N joins PAN B, its parent node, node A-5 determines that node N is no longer a child node. In one example, node N sends a disassociation message to node A-5 prior to joining PAN B to inform node A-5 of the switch. Node N determines whether it has any other child nodes that are critical nodes or critical path nodes. If it does not have any other child nodes that are critical nodes or critical path nodes, then it determines that it is no longer on a critical path and sends a DAO message indicating that it is no longer a critical path node. Similarly, if node A-4 has no child nodes that are critical nodes or critical path nodes, then it sends a DAO message indicating that is it no longer a critical path node. If node A-1 has no child nodes that are critical nodes or critical path nodes, then it sends a DAO message to its parent node, node 110, and node 110 removes the critical path for node N. Node A-5 may remain a critical path node if it has another child node, e.g. Node A-6, that is a critical node or critical path node. In this situation, node 110 stores critical path information for Node A-6. Once a node, e.g. node A-5, is no longer a critical path node, then it may remain joined to its current PAN or switch to a target PAN based on factors other than the status of the backhaul connection for its current PAN and a target PAN.


In some instances, a critical node may only rarely receive a beacon from another PAN. Once a node on the critical path receives a beacon from another PAN with an available backhaul connection while the backhaul connection for the current PAN is unavailable, it may switch PANs. For example, if node A-5 receives a beacon from node A-4 or another node in PAN A with a backhaul status IE indicating that the backhaul connection for PAN A is unavailable, then node A-5 may search for a different PAN to join. Since node A-5 is on a critical path, it may be more aggressive in seeking a different PAN than if it weren't on a critical path. In some implementations, the node considers its RPL layer in determining how aggressively to seek a different PAN. For example, a layer 1 node may be less aggressive than a lower layer node.


If node A-5 receives a beacon from a different PAN, such as Beacon B from PAN B, it may determine whether to switch PANs based on whether the backhaul connection for PAN B is available. When the backhaul connection for PAN B is available, node A-5 joins PAN B, as shown in FIG. 5. FIG. 5 illustrates that after node A-5 joins PAN B, its child nodes, node A-6 and node N may not be joined to either PAN A or PAN B. Since node A-5 is not a critical node and does not have a child node that is a critical node in FIG. 5, it does not identify itself as a critical node or a critical path node after joining PAN B. In some implementations, node A-6 and node N each execute a separate joining process. Each node may rejoin PAN A by finding a new parent node, join PAN B through node A-5 (its PAN A parent node), or join PAN B by finding a different parent node. Since node N is a critical node and the backhaul connection for PAN A is unavailable, node N joins PAN B. In the scenario where node N joins PAN B as a child node of node A-5, node N sends a DAO message that identifies node N as a critical node. A critical path is established in a manner similar to that discussed above in connection with FIG. 2.


In some implementations, a secondary backhaul connection, such as Ethernet or cellular, may be available. If so, when a critical path node receives a beacon with a backhaul status IE indicating that the backhaul connection is unavailable, then the node may choose to remain on the current PAN and use the secondary backhaul connection.


If the backhaul status IE indicates that the backhaul connection is unavailable and includes information about how long the backhaul connection has been unavailable, then a critical path node may consider how long the backhaul connection has been unavailable when determining when to switch to a new PAN.


Although the foregoing examples discuss the use of the backhaul status IE in connection with critical nodes, the backhaul status IE may be used whenever backhaul status information is useful. It is not limited to use by critical path nodes.


Maintaining Parent-Child Relationship when Switching PANs


A node may maintain existing parent-child relationships when it switches to a new PAN. The switch may occur because a backhaul connection is lost or for any other reason.


Continuing with the example of FIG. 3, node A-5 may bring its child nodes with it when it joins PAN B. Once node A-5 determines that it is going to switch to a target PAN, then the node maintains timing synchronization information for both its current PAN, e.g. PAN A, and its target PAN, e.g., PAN B. Node A-5 obtains the timing synchronization information for the target PAN from a beacon in the target PAN. Node A-5 communicates the timing synchronization information for the target PAN to its child nodes node A-6 and node N, as well as a time when it plans to switch to the target PAN. The timing synchronization information and the switch time may be communicated in a beacon from node A-5. For example, IEs in the beacon currently provide information about the network and include absolute slot number, channel hopping sequence, and timeslot offset information. An IE in the beacon may be modified to include a PAN switching timestamp. Only nodes that recognize node A-5 as their parent node may act upon the timing synchronization information and the switch time. Once nodes A-6 and node N receive the beacon with the timing synchronization information and the switch time, the nodes maintain timing synchronization information for both PAN A and PAN B. At the switch time, node A-5 and its child nodes, node A-6 and node N, switch from PAN A, as shown in FIG. 3, to PAN B, as shown in FIG. 6. After the switch, node A-5 may send a DIS message to node B-2 to trigger a DIO message from node B-2. In response to the DIO message, node A-5 may send a DAO message that indicates that its child node, node N, is a critical node and that node A-5 is on a critical path. Once node A-5 receives a DAO-ACK message, it may send a DIO message to its child nodes that it brought from PAN A, e.g., node A-6 and node N, via a unicast, multicast, or broadcast method so that the child nodes may obtain a new network prefix.


After the nodes switch to PAN B, the critical path includes node A-5, node B-2, node B-1, and node 150. By switching node A-5, node A-6, and node N to the target PAN together, the timing and network connectivity are maintained and the availability of the child nodes, e.g., node A-6 and node N, is improved.


The parent-child relationship between nodes may be maintained when the parent node determines that it is switching to a target PAN for any reason. It is not limited to the situation where the parent node is a critical path node or when the switch is based on a backhaul connection status.


Communications Between Critical Node and PAN



FIG. 7 illustrates a critical node 704 seeking to join a PAN. The node 704 initially determines whether to join a PAN corresponding to mesh network 702. At 710, the backhaul connection for network 702 becomes unavailable. Subsequently at 712, the border router or root node for network 702 communicates the loss of backhaul connection to the network. In one example, the border router sends a beacon with a backhaul status IE indicating that the backhaul connection is unavailable. Critical node 704 begins listening for beacons at 714 to find a network to join. At 716, node 704 receives a beacon from network 702. The beacon includes a backhaul status IE indicating that network 702 has lost its backhaul connection. Since node 704 is a critical node, it continues to listen for additional beacons to find a network with an available backhaul connection.


At 720, the backhaul connection for a PAN corresponding to mesh network 706 is available. At 722, the border router for network 706 communicates the availability of the backhaul connection to the network. In one example, the border router sends a beacon with a backhaul status IE indicating that the backhaul connection is available. At 724, node 704 receives a beacon from network 706. Since the beacon from network 706 indicates that the backhaul connection is available, node 704 determines that it will try to join network 706. Node 704 and network 706 conduct a message exchange 726, 728 at layer 2. The message exchange may include an association request and an association response message. Other types of message exchanges are also possible. Once joined at layer 2, node 704 and network 706 conduct another message exchange at layer 3. For example, node 704 may send a DAO message indicating that it is a critical node and a node within network 706 may respond with a DAO-ACK message.


At 734, the backhaul connection for network 706 becomes unavailable. Subsequently at 736, the border router for network 706 communicates the loss of backhaul connection to the network. At 738, a beacon from network 706 indicates that the backhaul connection for network 706 is unavailable. In response to receiving the beacon, node 704 begins searching for a new PAN at 740.


Although FIG. 7 uses a beacon to communicate backhaul status information, other implementations may use a different type of message including, but not limited to, another type of layer 2 message or a propriety frame.


Exemplary Node



FIG. 8 illustrates an exemplary node 800. The node may include a processor 802, memory 804, and a transceiver device 820 each communicatively coupled via a bus 806. The components of node 800 can be powered by an A/C power supply or a low energy source, such as a battery (not shown). The transceiver device 820 can include (or be communicatively coupled to) an antenna 808 for communicating with other nodes. In some examples, the transceiver device is a radio-frequency (“RF”) transceiver for wirelessly transmitting and receiving signals.


The processor may include a microprocessor, an application-specific integrated circuit (“ASIC”), a state machine, a field programmable gate array (“FPGA”) or other suitable computing device. The processor can include any number of computing devices and can be communicatively coupled to a computer-readable media, such as memory 804. The processor can execute computer-executable program instructions or access information stored in memory to perform operations, such as those described herein. The instructions may comprise processor-specific instructions generated by a compiler and/or an interpreter from code written in any suitable computer-programming language. When instructions, such as those provided in a critical path module 814, are executed, they may configure the node to perform any of the operations described herein. Although the processor, memory, bus, and transceiver device are depicted in FIG. 8 as separate components in communication with one another, other implementations are possible. The systems and components discussed herein are not limited to any particular hardware architecture or configuration.


While the present subject matter has been described in detail with respect to specific aspects thereof, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily produce alterations to, variations of, and equivalents to such aspects. Accordingly, it should be understood that the present disclosure has been presented for purposes of example rather than limitation, and does not preclude inclusion of such modification, variations, and/or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art.

Claims
  • 1. A method for switching PANs (Personal Area Networks), wherein a first parent node and at least one child node are joined to a first PAN, comprising: maintaining, by the first parent node, timing synchronization with the first PAN;identifying, by the first parent node, a second PAN;obtaining, by the first parent node, timing synchronization information for the second PAN;maintaining, by the first parent node, timing synchronization with both the first PAN and the second PAN;transmitting, by the first parent node, a message to the at least one child node, wherein the message includes synchronization information for the second PAN;switching, by the first parent node, from the first PAN to the second PAN; andmaintaining, by the first parent node, a parent-child relationship with the at least one child node.
  • 2. The method of claim 1, further comprising: after switching from the first PAN to the second PAN, transmitting, by the first parent node, a DIS (DODAG (Destination-Oriented Directed Acyclic Graph) Information Solicitation) message to a second node in the second PAN, wherein the second node is a parent node of the first parent node.
  • 3. The method of claim 2, further comprising: receiving, by the first parent node, a DIO (DODAG Information Object) message from the second node; andin response to receiving the DIO message, transmitting a DAO (Destination Advertisement Object) message to the second node, wherein the DAO message indicates that the first parent node is a critical path node.
  • 4. The method of claim 3, further comprising: receiving, by the first parent node, a DAO-ACK (Destination Advertisement Object Acknowledgement) message from the second node; andin response to receiving the DAO-ACK message, transmitting a second DIO message to the at least one child node.
  • 5. The method of claim 1, wherein the message further comprises a time for switching from the first PAN to the second PAN and wherein switching from the first PAN to the second PAN comprises switching at the time for switching.
  • 6. The method of claim 1, wherein the first parent node is a critical path node, further comprising: prior to obtaining, by the first parent node, timing synchronization information for the second PAN, determining, by the first parent node, that a backhaul connection for the first PAN is unavailable.
  • 7. The method of claim 1, wherein transmitting a message comprises transmitting, by the first parent node, a beacon.
  • 8. A method for switching PANs (Personal Area Networks), wherein a parent node and a first child node are joined to a first PAN, comprising: maintaining, by the first child node, timing synchronization with the first PAN;receiving, by the first child node, a message from the parent node, wherein the message includes synchronization information for a second PAN and a switching time;maintaining, by the first child node, timing synchronization with both the first PAN and the second PAN;switching, by the first child node, from the first PAN to the second PAN at the switching time; andmaintaining, by the first child node, a parent-child relationship with the parent node in the second PAN.
  • 9. The method of claim 8, further comprising: after switching from the first PAN to the second PAN, receiving a DIO (DODAG (Destination-Oriented Directed Acyclic Graph) Information Object) message from the parent node; andobtaining, by the first child node, a new network prefix.
  • 10. The method of claim 8, wherein the message from the parent node is a beacon, further comprising: after receiving, by the first child node, the beacon from the parent node, determining whether the first child node is a child node of the parent node prior to maintaining timing synchronization with both the first PAN and the second PAN.
  • 11. A network comprising: a first parent node;a first child node; anda second child node,wherein the first parent node has a parent-child relationship with the first child node and the second child node in a first PAN (Personal Area Network);wherein the first parent node is operable for: identifying a second PAN;obtaining timing synchronization information for the second PAN;maintaining timing synchronization with both the first PAN and the second PAN;transmitting a message to the first child node and the second child node that includes synchronization information for the second PAN and a switching time; andswitching to the second PAN at the switching time.
  • 12. The network of claim 11, further comprising: a root node, wherein the root node provides a backhaul connection for the first PAN,wherein the first parent node is further operable for: determining that the backhaul connection for the first PAN is unavailable before transmitting the message to the first child node and the second child node that includes synchronization information for the second PAN and the switching time.
  • 13. The network of claim 11, wherein the first child node is operable for: receiving the message that includes synchronization information for the second PAN and a switching time from the first parent node;maintaining timing synchronization with both the first PAN and the second PAN; andswitching to the second PAN at the switching time.
  • 14. The network of claim 13, wherein the first child node is further operable for: after receiving the message that includes synchronization information for the second PAN and a switching time from the first parent node, determining that the parent-child relationship exists between the first parent node and the first child node prior to switching to the second PAN at the switching time.
  • 15. The network of claim 11, wherein the first parent node is further operable for: after switching to the second PAN, transmitting a DIS (DODAG (Destination-Oriented Directed Acyclic Graph) Information Solicitation) message to a fourth node in the second PAN, wherein the first parent node is a child node of the fourth node in the second PAN;receiving a DIO (DODAG Information Object)message from the fourth node;in response to receiving the DIO message, transmitting a DAO (Destination Advertisement Object) message to the fourth node;receiving a DAO-ACK (Destination Advertisement Object Acknowledgement) message from the fourth node; andtransmitting a second DIO message to the first child node and the second child node.
  • 16. The network of claim 11, further comprising: a third node; anda fourth node, wherein the third node is a parent node to the fourth node, andwherein the fourth node is operable for: receiving the message that includes synchronization information for the second PAN and a switching time from the first parent node;determining that no parent-child relationship exists between the first parent node and the fourth node;maintaining timing synchronization with the first PAN; andremaining on the first PAN after the switching time.
US Referenced Citations (103)
Number Name Date Kind
6735630 Gelvin et al. May 2004 B1
7502354 Maufer Mar 2009 B1
7802015 Cheifot et al. Sep 2010 B2
7835301 Maufer Nov 2010 B1
7978691 Cole Jul 2011 B1
8095172 Cole et al. Jan 2012 B1
8244249 Everson et al. Aug 2012 B1
8571005 Vleugels Oct 2013 B1
8693453 Priyantha et al. Apr 2014 B2
8891497 Vleugels Nov 2014 B1
9270761 Logue et al. Feb 2016 B1
9622089 Ngo et al. Apr 2017 B1
9692658 Guo et al. Jun 2017 B2
9699708 Alexander et al. Jul 2017 B2
9860677 Agerstam et al. Jan 2018 B1
10045290 Vleugels et al. Aug 2018 B2
10277686 Bhandari et al. Apr 2019 B2
10313197 Stamatakis Jun 2019 B1
10356618 Conant et al. Jul 2019 B2
10383018 Cheng et al. Aug 2019 B2
10404572 Fuste Vilella et al. Sep 2019 B1
10405319 Shao et al. Sep 2019 B2
20040151193 Rune et al. Aug 2004 A1
20050015644 Chu et al. Jan 2005 A1
20060116170 Brahmbhatt et al. Jun 2006 A1
20060215601 Vleugels et al. Sep 2006 A1
20070140239 Bauer et al. Jun 2007 A1
20070171859 Brahmbhatt et al. Jul 2007 A1
20070211681 Sun et al. Sep 2007 A1
20070254604 Kim Nov 2007 A1
20080070614 Ogushi et al. Mar 2008 A1
20090059816 Reza et al. Mar 2009 A1
20090122733 Ruy et al. May 2009 A1
20090252134 Schlicht et al. Oct 2009 A1
20100124196 Bonar et al. May 2010 A1
20100177660 Essinger et al. Jul 2010 A1
20100177703 Dacosta et al. Jul 2010 A1
20100208662 Fuste et al. Aug 2010 A1
20110116414 Lee et al. May 2011 A1
20110149720 Phuah et al. Jun 2011 A1
20110176464 Warner Jul 2011 A1
20110176469 Kim et al. Jul 2011 A1
20120026890 Banka et al. Feb 2012 A1
20120117268 Shaffer et al. May 2012 A1
20120155463 Vasseur et al. Jun 2012 A1
20120158981 Desai et al. Jun 2012 A1
20120290730 Desai et al. Nov 2012 A1
20130163407 Sinha et al. Jun 2013 A1
20140029434 Wang et al. Jan 2014 A1
20140092753 Vasseur et al. Apr 2014 A1
20140098685 Shattil Apr 2014 A1
20140126423 Vasseur et al. May 2014 A1
20140219133 Dasgupta et al. Aug 2014 A1
20140281670 Vasseur et al. Sep 2014 A1
20140376405 Erickson et al. Dec 2014 A1
20150023155 Shanmugavadivel et al. Jan 2015 A1
20150023205 Vasseur et al. Jan 2015 A1
20150092530 Kelsey et al. Apr 2015 A1
20150109961 Patil et al. Apr 2015 A1
20150124650 Misra et al. May 2015 A1
20150156738 Guo et al. Jun 2015 A1
20150163828 Vandwalle et al. Jun 2015 A1
20150181309 Shepherd et al. Jun 2015 A1
20150186642 Cruz Mota Jul 2015 A1
20150200810 Vasseur et al. Jul 2015 A1
20150304920 Cootey Oct 2015 A1
20150319555 Cordeiro Nov 2015 A1
20150327261 Thubert et al. Nov 2015 A1
20150372875 Turon et al. Dec 2015 A1
20150382275 Pragada et al. Dec 2015 A1
20160006837 Reynolds et al. Jan 2016 A1
20160021013 Vasseur et al. Jan 2016 A1
20160021017 Thubert et al. Jan 2016 A1
20160044522 Ludlow et al. Feb 2016 A1
20160066183 Conant et al. Mar 2016 A1
20160094398 Choudhury et al. Mar 2016 A1
20160112518 Haleem et al. Apr 2016 A1
20160112941 Desai et al. Apr 2016 A1
20160128043 Shuman et al. May 2016 A1
20160134468 Hui May 2016 A1
20160164725 Wu et al. Jun 2016 A1
20160309330 Moon Oct 2016 A1
20170041954 Tsai et al. Feb 2017 A1
20170070993 Ngo et al. Mar 2017 A1
20170111846 Kang Apr 2017 A1
20170150368 Ngo et al. May 2017 A1
20170155703 Hao et al. Jun 2017 A1
20170156149 Lin et al. Jun 2017 A1
20170195136 Ghosh et al. Jul 2017 A1
20170257129 Egner et al. Sep 2017 A1
20170273002 Chen et al. Sep 2017 A1
20170279829 Vasseur et al. Sep 2017 A1
20170347283 Kodaypak Nov 2017 A1
20170359148 Richardson et al. Dec 2017 A1
20170374560 Judge et al. Dec 2017 A1
20180026891 Vasseur et al. Jan 2018 A1
20180123963 Thubert et al. May 2018 A1
20180167948 Egner et al. Jun 2018 A1
20180176853 Chen et al. Jun 2018 A1
20180213460 Adella et al. Jul 2018 A1
20180316746 Shattil Nov 2018 A1
20180376400 Chaki et al. Dec 2018 A1
20190246444 Kanzaki et al. Aug 2019 A1
Foreign Referenced Citations (4)
Number Date Country
2330776 Jun 2011 EP
2901657 Aug 2015 EP
2006138122 Dec 2006 WO
2012109478 Aug 2012 WO
Non-Patent Literature Citations (10)
Entry
U.S. Appl. No. 15/974,499, Non-Final Office Action dated Apr. 24, 2019, 11 pages.
Alvi et al., On Route Maintenance and Recovery Mechanism of RPL, 13th International Wireless Communications and Mobile Computing Conference (IWCMC), IEEE, 2017, pp. 1933-1938.
Chen et al., Service-Aware Node Migration for Low-Power and Lossy Networks, IP.Com Journal, IP.Com Inc., Nov. 2, 2017, 15 pages.
International Application No. PCT/US2019/027798, International Search Report and Written Opinion dated Jun. 27, 2019, 16 pages.
International Application No. PCT/US2019/029813, International Search Report and Written Opinion dated Jul. 8, 2019, 14 pages.
Winter et al., RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, draft-ietf-roll-rpl-18.txt, Feb. 4, 2011 Internet Engineering Task Force, IETF, XP015073823, Feb. 4, 2011, pp. 1-80.
U.S. Appl. No. 15/974,499, Notice of Allowance, dated Aug. 14, 2019, 7 pages.
Ancillotti et al., “RPL Routing Protocol in Advanced Metering Infrastructures: An Analysis of the Unreliability Problems”, Sustainable Internet and ICT for Sustainability (SustainIT), Oct. 4, 2012, pp. 1-10.
PCT Application No. PCT/US2019/030138, International Search Report and Written Opinion, dated Aug. 28, 2019, 13 pages.
U.S. Appl. No. 15/974,541 , Non-Final Office Action, dated Sep. 18, 2019, 33 pages.
Related Publications (1)
Number Date Country
20190349786 A1 Nov 2019 US