Smart PAN migration in technical field of wireless mesh networks

Abstract

Techniques described herein relate to intelligent migration between personal area networks (PANs) of a wireless mesh network. In one example, a method includes receiving, by a node connected to a first PAN, a packet from a second PAN. Based on the packet, the node determines that a second instability factor associated with stability of the second PAN and a first instability factor associated with stability of the first PAN differ by at least a margin. The node sends a migration notification message to a neighboring node in the first PAN indicating that the node is migrating, and receives a request from the neighboring node in the first PAN that the node remains in the first PAN. The node applies one or more rules to reject a request that the node remains in the first PAN, and continues to complete the migration based on rejecting the request.

Description

Technical Field

[0001] Some embodiments described herein relate to wireless mesh networks, and more particularly, to intelligent personal area network (PAN) migration of endpoints in a wireless mesh network. Background Art

[0002] Typically, a wireless mesh network includes various nodes with paired connections that together form a wireless mesh network through which the nodes can communicate with each other. More specifically, the nodes are connected together to form a group known as a personal area network (PAN), where each PAN is coordinated by a corresponding PAN coordinator, and the nodes within the PAN provide communication routing services or other services to other nodes in the PAN. Each PAN coordinator can communicate directly or indirectly with a head-end system, which can provide services to the wireless mesh network as a whole.

[0003] In a low-power or lossy wireless mesh network, the PAN selection of a given node can determine whether the node is able to perform its operations efficiently. For example, if the current PAN of a node that is an endpoint is unstable, such that the resource cost of routing data packets is high or such that the link quality (i.e., reachability) between neighboring nodes is too low, then the endpoint may not be able to participate in communications in a timely manner. For example, if the endpoint is a utility meter and the wireless mesh network is a smart meter network, instability in the PAN to which the utility meter belongs can cause the utility to fail to correctly report utility usage. As such, nodes can migrate from one PAN to another within the wireless mesh network to improve stability within the wireless mesh network.

[0004] For example, upon determining that the instability factor of the second PAN is sufficiently better (eg, lower by a margin) than the instability factor of the first PAN to which the endpoint currently belongs, the node may migrate from the first PAN to the second PAN. Upon making this determination, the endpoint leaves the first PAN and requests to join the second PAN. Summary of the invention

[0005] In one embodiment described herein, a method includes receiving, by a node connected to a first area network (PAN), a packet from a second PAN other than a first PAN. Based on the packet, the node determines that a second instability factor related to the stability of the second PAN differs from a first instability factor related to the stability of the first PAN by at least a margin. The node sends a migration notification message to a neighboring node in the first PAN indicating that the node is migrating, and receives a request from the neighboring node in the first PAN for the node to remain in the first PAN. The node applies one or more rules to the request to deny the request for the node to remain in the first PAN, and based on denying the request, proceeds to complete the migration.

[0006] In another embodiment described herein, a system includes a subject node and a neighboring node, both connected to a first PAN. The subject node is configured to identify a destination PAN as a migration target and send a notification to one or more neighboring nodes that the subject node is migrating to the destination PAN. The neighboring nodes are configured to receive the notification from the subject node and determine a reason selected from a set of predetermined reasons for rejecting the migration of the subject node. The neighboring nodes are also configured to send a request to the subject node to terminate the migration. The subject node is also configured to exit the first PAN and join the destination PAN based on prioritizing an expected improvement in stability due to the migration over reasons associated with the request from the neighboring nodes.

[0007] In another embodiment described herein, a computing device is connected to a first PAN of a wireless mesh network. The computing device includes a processor and a memory. The processor is configured to execute computer-readable instructions, and the memory is configured to store computer-readable instructions, which, when executed by the processor, cause the processor to perform the following operations. The operation includes receiving a packet from a second PAN other than the first PAN, and determining based on the packet that a second instability factor related to the stability of the second PAN and a first instability factor related to the stability of the first PAN differ by at least a margin. The operation also includes sending a migration notification message indicating that the computing device is migrating to a neighboring node in the first PAN, and receiving a request from a neighboring node in the first PAN for the computing device to remain in the first PAN. The operation also includes applying one or more rules to the request to deny the request for the computing device to remain in the first PAN, and based on the denial of the request, continuing to complete the migration to the second PAN.

[0008] Mentioning these illustrative aspects and features is not intended to limit or define the presently described subject matter, but rather to provide examples to aid in understanding the concepts described in this application. Other aspects, advantages, and features of the presently described subject matter will become apparent after reviewing the entire application. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] These and other features, aspects and advantages of the present disclosure will be better understood when the following detailed description is read with reference to the accompanying drawings.

[0010] Figure 1 is a diagram of a wireless mesh network according to some embodiments described herein.

[0011] Figure 2 is a flow chart of a method for determining whether to migrate, and if so, selecting a migration mode, according to some implementations described herein.

[0012] Figure 3is a flow chart of a method for performing a hard migration according to some implementations described herein.

[0013] Figure 4 is a flow chart of a method for performing a soft migration according to some implementations described herein.

[0014] Figure 5 is a diagram of a computing system that can act as a node in a wireless mesh network according to some implementations described herein. DETAILED DESCRIPTION

[0015] As described above, a subject node (i.e., a particular node) in a wireless mesh network can migrate from a first area network (PAN) to a second area network when it is determined that the stability in the second area network (PAN) is sufficiently superior to the stability of the first area network. However, there are various disadvantages to the way PAN migration currently occurs. For example, when the subject node leaves the first PAN, the former child nodes of the subject node are without a parent node, and then must suddenly locate their respective new parent nodes. In some cases, there may be no node in the first PAN that has sufficient signal strength relative to the child node to act as a new parent node. The child node may even be a critical node because the service it provides is considered critical to the wireless mesh network. It is undesirable to leave a critical node without a parent node. In short, when the subject node unilaterally chooses to leave the PAN, and does so without warning, this may put the rest of the PAN in an undesirable situation that may harm the wireless mesh network as a whole.

[0016] Some embodiments described herein address these problems of existing PAN migration technologies. In some embodiments, the subject node can have at least two migration modes, referred to herein as hard migration mode and soft migration mode. Using the hard migration mode (also referred to herein as hard migration), the subject node notifies its neighboring nodes (e.g., its child nodes or other reachable nodes) in its current PAN of its migration intention, and those neighboring nodes have the opportunity to refuse. Using the second migration mode (referred to herein as soft migration), the subject node notifies its neighboring nodes and the PAN coordinator, and additionally, the subject node performs a gradual migration, enabling it to start the joining process with another PAN while continuing to provide services to its current PAN, thereby improving stability from a unilateral perspective while enabling nodes in its current PAN to make expected adjustments as needed. Using either migration mode, the subject node can re-evaluate its migration decision based on feedback from other nodes. Therefore, compared with the prior art that unilaterally determines migration based solely on a comparison of instability factors, some embodiments described herein consider a wider range of factors and provide a smoother transition for affected nodes if necessary.

[0017] Example of a wireless mesh network supporting migration mode

[0018] Figure 1 is a diagram of a wireless mesh network 100 according to some embodiments described herein. Figure 1 As shown, the wireless mesh network 100 may include two or more PANs 110, such as a first PAN 110a and a second PAN 110b. The example PAN 110 includes a corresponding PAN coordinator 115 and one or more nodes 120. Each node 120 may, but need not be, an endpoint such as a utility meter. In some embodiments, each node 120 may be a computing device, such as a utility meter, a gateway, or some other computing device having a radio and capable of participating in communications in the wireless mesh network 100. Also as shown in FIG. Figure 1 As shown, the example of wireless mesh network 100 includes a head-end system 130. Head-end system 130 provides one or more services to nodes 120, such as pushing out firmware updates or collecting utility usage or other data for processing and billing.

[0019] In some embodiments, the wireless mesh network 100 may include various types or categories of nodes 120. Such categories may include the following: critical, battery operated, or conventional. In some embodiments, a critical node 120 is a node that performs services that are considered critical (e.g., by an administrator), such as performing distributed access (DA) services for the PAN 110 or for the wireless mesh network 100 or the utility network as a whole. If a critical node 120 were to shut down or lose the ability to communicate with other nodes 120 in the wireless mesh network 100, critical functions of the wireless mesh network 100 would be impaired. A battery operated node 120 is a node that runs on battery power rather than being wired to an external power source. If a node 120 does not belong to some other designated category (e.g., critical or battery operated), the node 120 may be considered a conventional node 120.

[0020] In some embodiments, a PAN coordinator 115 of a PAN 110 maintains node data about nodes 120 in the PAN 110. For example, when a node 120 joins the PAN 110, the new parent node of the node within the PAN 110 sends information about the node 120 to the PAN coordinator 115. For example, the information may be routed to the PAN coordinator 115 by the paired connected nodes 120 of the PAN 110. If a node 120 leaves the PAN 110, the parent node 120 of the node 120 may similarly notify the PAN coordinator 115. The PAN coordinator 115 may store this information in a set of node data that describes all nodes 120 in the PAN 110 and their relationships to each other. The node data may thus include a mesh tree that indicates the relationships between parent nodes and child nodes 120 of the PAN 110.

[0021] exist Figure 1 In the example of FIG. 1 , nodes A-1, A-2, A-3, A-4, A-5, and A-6 belong to PAN A, which has node A-1 as its PAN coordinator 115, and nodes B-1 and B-2 belong to PAN B, which has node B-1 as its PAN coordinator 115. Figure 1 As shown by the lines connecting nodes 120 in FIG. 1 , some nodes 120 are directly connected to other nodes 120 within the shared PAN in pairs. For example, the connectivity between two nodes 120 of PAN 110 is due to the radio signal strength of each such node being sufficient to enable the two nodes 120 to communicate directly with each other. Such two nodes 120 are therefore considered to be neighboring nodes 120. Figure 1 In the example of , node A-5 is directly connected to nodes A-4 and A-6, and is therefore a neighboring node 120, also referred to as a neighbor, of each of nodes A-4 and A-6. Specifically, nodes A-5 and A-4 are nodes 120 that are neighboring to each other, and nodes A-5 and A-6 are also nodes 120 that are neighboring to each other. More generally, with respect to a given node 120, a neighboring node 120 may be a node 120 that shares a PAN 110 with the given node 120, and the given node 120 and the neighboring node 120 may receive transmission signals from each other.

[0022] In some embodiments, some nodes 120 are parent nodes or child nodes of other nodes 120. Generally, if a first and a second node 120 are neighbors, and communications from the second node 120 to the PAN coordinator 115 or the head-end system 130, or from the PAN coordinator 115 or the head-end system 130 to the second node 120 are passed through the first node 120, then the first node 120 is considered to be the parent node 120 of the second node 120. Thus, the parent node 120 communicatively connects the child node 120 to the PAN coordinator 115. For example, in Figure 1 , node B-1 is the PAN coordinator 115 of PAN B and is the parent node 120 of node B-2, which is therefore the child node 120 of node B-1. Similarly, node A-6 is the child node 120 of node A-5, which is the child node 120 of node A-4, which is the child node 120 of node A-1, which is the PAN coordinator 115 of PAN A. As described in more detail below, these relationships between nodes 120 of PAN 110 may play a role in migration between PANs 110.

[0023] According to some embodiments, migration may involve the subject node 120 leaving the first PAN 110 and joining the second PAN 110, which is also referred to as the destination PAN 110. Various techniques exist for enabling the subject node 120 to join a PAN 110, such as the destination PAN 110, and one or more such techniques may be used in the embodiments described herein. For example, to join the PAN 110, the subject node listens for beacons 140. Beacons 140 are management packets distributed throughout the wireless mesh network 100 for management purposes, such as maintaining channel synchronization between the radios of the nodes 120. In some embodiments, upon receiving the beacon 140 from the PAN 110, the subject node 120 initiates the joining process by sending a join request, which may involve advertising itself to the node 120 from which the subject node 120 received the beacon 140. The subject node 120 may then authenticate itself to the other nodes 120 and perform an association process, such as by providing information about itself to the other nodes 120. The other nodes 120 then pass the provided information to the PAN coordinator 115, which stores the information in its node data. In some implementations, completion of these tasks causes the subject node 120 to become part of the PAN 110. Other techniques for joining the PAN 110 are also possible and within the scope of the present disclosure.

[0024] As described above, the subject node 120 of the wireless mesh network 100 may migrate from the first PAN 110 to the second PAN 110, the first PAN 110 being the current PAN 110 when the migration starts. In some embodiments, the subject node initiates the migration when detecting that the second instability factor associated with the second PAN 110 is sufficiently better than the first instability factor associated with the first PAN to which the subject node 120 currently belongs. For example, the instability factor may be a value calculated by the subject node 120 that determines whether to migrate. In this case, if the first instability factor of the first PAN differs from the second instability factor of the second PAN by more than a margin (e.g., a predetermined value greater than zero), and if the second instability factor indicates improved stability compared to the first PAN 110, the subject node 120 may initiate the migration to the second PAN 110.

[0025] Therefore, in order to determine whether to migrate, the subject node 120 may be configured to calculate an instability factor. In some embodiments, the instability factor of the PAN 110 is based on one or more of the following factors: routing cost, link quality, the number of nodes in the PAN 110, or historical data of the PAN 110 (e.g., grouping success rate). For example, the subject node 120 may calculate the instability factor as a function of one or more (e.g., all) of these factors. In some embodiments, a high instability factor indicates high instability or a high probability of instability, and therefore indicates low stability or a low probability of stability. In this case, the instability factor may be positively correlated with the routing cost and the number of nodes 120, and negatively correlated with the link quality and the grouping success rate. Alternatively, in other embodiments, if a high instability factor indicates low instability or a low probability of instability, and therefore indicates high stability or a high probability of stability, the instability factor may be negatively correlated with the routing cost and the number of nodes 120, and positively correlated with the link quality and the grouping success rate. Various embodiments are possible and within the scope of the present disclosure. Throughout portions of this disclosure, it is assumed that a high instability factor indicates high instability and therefore low stability, but it is understood that the reverse is also true.

[0026] Various techniques and metrics exist in the art for measuring and representing routing costs, link quality, and the number of nodes 120, and one or more of such techniques and metrics may be used. For example, routing costs may be defined as the number of hops to reach a particular other node in the PAN 110, such as the PAN coordinator 115; as the average number of hops to reach other nodes in the PAN 110; or as the latency to send a message to the PAN coordinator 115 and receive a response back from the PAN coordinator 115. For example, link quality may be defined as the strongest signal strength (e.g., in decibels) of nodes 120 in the PAN 110 that are neighbors of the subject node 120, or link quality may be defined as the average signal strength to these neighboring nodes 120. In some embodiments, the PAN coordinator 115 maintains node data about the nodes 120 in the PAN 110, and may provide the subject node 120 with the number of nodes 120 in the PAN 110. For example, the PAN coordinator 115 provides this information to the subject node 120 as needed or periodically, such as by inclusion in a beacon 140.

[0027] In addition or in lieu of the above, when determining the instability factor of the PAN 110, the subject node 120 may consider historical data about the PAN 110. For example, the historical data may be the packet success within the PAN 110. Various techniques exist in the art for determining the packet success, and one or more of such techniques may be used. In some embodiments, the subject node 120 may maintain historical data in its local memory that describes the packet success of communications involving the subject node 120. For example, for each data packet that the subject node 120 sends and does not receive an expected positive acknowledgement, the subject node 120 may consider it a failure, and for each data packet that the subject node 120 sends and does receive an expected positive acknowledgement, the subject node 120 may consider it a success. The subject node 120 may maintain such indications of success and failure in order to determine the packet success for calculating the instability factor.

[0028] In some embodiments, even after migration between PANs 110, the subject node 120 may maintain an indication of the grouping success of one or more PANs 110 to which the subject node 120 no longer belongs, in order to utilize the grouping success in determining instability factors for PANs 110 other than the PAN 110 to which the subject node 120 currently belongs. Additionally or alternatively, in some embodiments, nearby nodes 120 from other PANs that have signals that can reach the subject node 120 may transmit (e.g., in their beacons 140) indications of their own grouping success. This may provide the subject node 120 with additional historical data to use in calculating instability factors for PANs 110 other than the PAN 110 to which the subject node 120 currently belongs.

[0029] In some embodiments, the subject node 120 calculates the instability factor of the PAN 110 as a function of the routing cost, link quality, the number of nodes in the PAN 110, and the success rate of grouping. Specifically, for example, the subject node 120 may calculate the instability factor As shown below:

[0030]

[0031] In the above, and are respectively routing cost, link quality, number of nodes in PAN 110 and grouping success rate in PAN 110; and and are respective weights for routing cost, link quality, number of nodes in PAN 110, and grouping success rate. The subject node 120 may maintain the respective weight values ​​internally for use as needed. In some embodiments, the weights may be determined and adjusted as needed based on the importance of each factor attributed to the instability factor (e.g., by an administrator), and in some embodiments, the respective weight values ​​may be based on the classification of the subject node 120 (e.g., battery powered, critical, or conventional). In some embodiments, the weight values ​​are fixed for a given PAN 110, but additionally or alternatively, the respective weight values ​​may vary for each node 120 or each PAN 110.

[0032] In some embodiments, the subject node 120 calculates a first instability factor of a first PAN 110 to which the subject node 120 belongs and a second instability factor of a second PAN 110 to which the subject node 120 does not belong, and the subject node 120 compares the two instability factors when determining whether to migrate from the first PAN 110 to the second PAN 110. For example, if the subject node 120 determines that the second instability factor is lower than the first instability factor (i.e., indicating less instability and greater stability) by more than a margin, the subject node 120 may initiate migration from the first PAN 110 to the second PAN 110.

[0033] In some cases, the constant migration of nodes 120 between PANs 110 in the wireless mesh network 100 may result in overall instability. Therefore, in some embodiments, the subject node 120 initiates migration only after the migration criteria are met. The migration criteria may be considered met when (a) a waiting period has passed since the last migration of the subject node, and (b) a second instability factor of a second PAN 110 other than the subject node's current PAN 110 is sufficiently better (e.g., lower) than the first instability factor of the subject node's current PAN 110 by at least a margin. Therefore, in some embodiments, the subject node 120 does not migrate between PANs 110 within a waiting period (e.g., one day) after its last migration between PANs 110. After migration, the subject node 120 may stay in its new PAN 110 for a time at least equal to the waiting period. After the waiting period, the subject node 120 may calculate the corresponding instability factors of one or more other PANs 110 from which the subject node 120 receives beacons 140 due to being within signal range. For each such instability factor calculated for a different PAN 110, the subject node 120 may compare the instability factor with the instability factor calculated for the current PAN 110 to determine whether to initiate migration.

[0034] In some embodiments, the subject node 120 modifies its migration criteria upon receiving a migration request from a child node 120 of the subject node 120. For example, the migration request is a request from the child node 120 for the subject node 120 to migrate so that the child node 120 can migrate with the subject node 120 while maintaining the subject node 120 as its parent node. The child node 120 may request migration to improve its own connectivity within the wireless mesh network 100. In some embodiments, only nodes 120 that meet certain criteria may request migration of the parent node 120 and have the request modify the migration criteria of the parent node 120. For example, if a node 120 that is a critical node 120 or a battery-powered node 120 has only one neighbor, which in this case would be its parent node 120, and if the node 120 has calculated an instability factor for the current PAN 110 that meets an instability threshold (e.g., greater than or equal to an insufficient instability threshold), the node 120 may send a request to its parent node to migrate to another PAN 110. In some implementations, the instability threshold may vary based on the classification of the node 120 .

[0035] Upon receiving such a request, the parent node 120 may modify its migration criteria when selecting a destination PAN 110 to migrate to. For example, the parent node 120 may terminate the waiting period, thereby achieving faster migration, and the parent node 120 may modify (e.g., reduce) the margin used to determine whether the instability factor of another PAN indicates a sufficiently improved stability level. These modifications to the migration criteria may enable the parent node 120 to select a destination PAN 110 that otherwise may not be considered sufficiently stable for the migration destination. After finding and selecting the destination PAN 110, the parent node 120 may notify the child node 120 of the PAN identifier (ID) of the destination PAN 110. The child node 120 may then take appropriate actions to migrate to the destination PAN 110 with the parent node 120. For example, the child node 120 may migrate to the destination PAN 110 using a hard migration mode or a soft migration mode.

[0036] Upon determining to migrate (i.e., the migration criteria have been met), the subject node 120 may select a migration mode to use during the migration, regardless of whether the migration was prompted by a request from a child node 120. In some implementations, the subject node 120 may be capable of two or more migration modes, such as a hard migration mode and a soft migration mode, or the subject node 120 may be capable of only one migration mode or the other. Typically, the hard migration mode may result in a more abrupt switch between PANs 110 than the soft migration mode. The details of each migration mode are described in more detail later in this disclosure.

[0037] Migration modes and examples of choosing between them

[0038] Figure 2 is a flow chart of a method 200 for determining whether to migrate, and if so, selecting a migration mode, according to some embodiments described herein. Figure 2 The method 200 depicted in FIG. 2 can be implemented in software, hardware, or a combination of software and hardware. Figure 2 The method 200 presented in and described below is intended to be illustrative and not limiting. Figure 2 Various processing operations are depicted as occurring in a particular sequence or order, but this is not intended to be limiting. In some alternative examples, processing may be performed in a different order, operations may be excluded or added, or some operations may be performed in parallel. In some implementations, subject node 120 performs method 200 or a similar method when determining whether and how to migrate between PAN 110.

[0039] like Figure 2 As shown, at block 205, the subject node 120 as part of the first PAN 110 waits for a waiting period to end, wherein the waiting period begins when the subject node 120 joins the first PAN 110 via migration or other means. During the waiting period, the subject node 120 does not need to calculate its instability factor or the corresponding instability factor of the other PAN 110. In some embodiments, if the subject node 120 receives a beacon 140 from another PAN 110 during the waiting period, the subject node 120 does not need to use the information in the beacon 140 to calculate the instability factor of the other PAN 110. For the purpose of PAN migration, the subject node 120 can ignore the beacon 140. However, as described above, if the subject node receives a migration request from the child node 120, the waiting period can be terminated early, or in other words, can be shortened to zero.

[0040] Eventually, the waiting period ends. For example, the waiting period may end because the entire original time length of the waiting period has elapsed, or the waiting period may end because the subject node 120 receives a migration request from a child node 120. After the waiting period, at block 210, the subject node 120 considers beacons from other PANs 110 for potential migration.

[0041] At block 215, the subject node 120 receives a beacon 140 from another PAN 110 other than the first PAN 110. At block 220, the subject node 120 calculates an instability factor for the other PAN 110 based on information in the beacon 140, and in some examples, based on information maintained by the subject node 120 itself. For example, the subject node 120 calculates the instability factor for the other PAN 110 as a function of the routing cost of the other PAN 110, the link quality between the subject node 120 and the node 120 from which the beacon 140 is received, the number of nodes 120 in the other PAN 110, and the grouping success rate of the other PAN 110. In some implementations, the routing cost and the number of nodes 120 may be included in the beacon 140, and the subject node 120 may determine the link quality based on the signal strength of the signal of the node 120 from which the beacon 140 is received. As described above, the grouping success may be based on data maintained by the subject node 120 , or may be based on data included in the beacon 140 or otherwise received from a node 120 receiving the beacon 140 .

[0042] At block 225, the subject node 120 calculates a first instability factor for the first PAN 110, the first PAN 110 being the PAN 110 to which the subject node 120 currently belongs. For example, as described above, the subject node 120 calculates the instability factor for the first PAN 110 as a function of the routing cost of the first PAN 110, the link quality between the subject node 120 and one or more other nodes 120 in the first PAN 110, the number of nodes 120 in the first PAN 110, and the grouping success rate of the first PAN 110 maintained by the subject node 120. Although block 225 is not described in detail, the subject node 120 may be used to calculate the instability factor for the first PAN 110. Figure 2 200 as occurring after block 220, but the subject node 120 may calculate the instability factor for the first PAN 110 at various points in the method 200. For example, the subject node 120 may calculate the first instability factor each time a beacon 140 of the first PAN 110 is received, or the subject node 120 may calculate the first instability factor upon expiration of a waiting period. Additionally or alternatively, the subject node 120 may calculate the first instability factor each time the subject node 120 calculates an instability factor for another PAN 110 that is considered to be the destination PAN 110.

[0043] At decision block 230, the subject node 120 determines whether the instability factor of the other PAN 110 calculated at block 220 is substantially superior to the first instability factor calculated at block 225. As described above, if the instability factor of the other PAN 110 is lower than the first instability factor by at least a predetermined margin, then the instability factor of the other PAN 110 may be considered substantially superior to the first instability factor.

[0044] If the instability factors of the other PANs 110 are not sufficiently superior to the first instability factor, the method 200 returns to block 210 to listen for additional beacons 140 from PANs 110 other than the first PAN 110. Because the instability factors of PANs 110 may change over time, the subject node 120 may later reconsider a PAN 110 that has been considered as a destination PAN 110, and the subject node 120 may additionally or alternatively consider a PAN 110 that has not yet been considered. However, if at decision block 230, the instability factors of the other PANs 110 are considered sufficiently superior to the first instability factor, the method 200 may proceed to decision block 235 to determine a migration mode for migrating to the other PAN 110, which is now the destination PAN 110.

[0045] In some implementations, the migration pattern is based on one or more of: a node classification of the subject node 120, a first instability factor of the first PAN 110, or whether a beacon 140 has been recently received (e.g., within a predetermined short time frame) from a neighboring node 120 of the destination PAN 110. The following are non-limiting examples of techniques for selecting a migration pattern.

[0046] At decision block 235, the subject node 120 determines its own classification (e.g., critical, battery powered, or conventional). In some embodiments, each node 120 is programmed with an indication of its classification, and therefore, the subject node can simply check the indication to determine its classification. If the subject node 120 is battery powered, then at block 240, the subject node 120 initiates migration using a hard migration mode. However, if the subject node 120 is critical, then at block 245, the subject node 120 initiates migration using a soft migration mode. If the subject node 120 is conventional, the method 200 proceeds to decision block 250.

[0047] At decision block 250, the subject node 120 has determined that it is a regular node 120, and therefore, the subject node 120 further determines whether its network stability is high or low. In the event that a high instability factor indicates a lack of stability, this may be equivalent to determining whether the first instability factor is below or above the mode threshold. If the stability of the first PAN 110 is low (e.g., the first instability factor is above the mode threshold), then at block 255, the subject node 120 initiates migration using the hard migration mode. However, if the stability of the first PAN 110 is high (e.g., the first instability factor is below the mode threshold), then at decision block 260, the subject node 120 determines whether it has received a beacon 140 of the destination PAN 110 from a neighboring node 120 in the destination PAN 110. Receiving a beacon 140 from a neighboring node 120 is an indication that trust exists between the subject node 120 and the devices within the destination PAN 110. If a beacon 140 is received, then at block 265, the subject node 120 initiates migration using the hard migration mode. Otherwise, at block 270, the subject node 120 initiates the migration using the soft migration mode.

[0048] As described above, the subject node 120 may be capable of hard migration (i.e., using hard migration mode), soft migration (i.e., using soft migration mode), or both. For example, a node 120 that is a battery-powered node 120 may only be capable of hard migration, a node 120 that is a critical node 120 may only be capable of soft migration mode, and a node 120 that is a normal mode may be capable of both hard migration and soft migration, and thus may select between the two modes when migrating.

[0049] Example of a hard migration

[0050] As described above, in some embodiments, the hard migration mode is more abrupt than the soft migration mode. Specifically, at a certain moment, the subject node 120 that migrates from the first PAN 110 to the second PAN 110 via hard migration may simply stop participating in the first PAN 110 and then join the second PAN 110. This can save resources of the subject node 120, but may result in a brief period during which the subject node 120 is not a full participant in any PAN 110 in the wireless mesh network 100. In contrast, soft migration may involve a gradual transfer, in which in some aspects, the subject node 120 may participate in both the first PAN 110 and the second PAN 110 for a short period of time to facilitate continuous or near-continuous connectivity. Hard migration may be beneficial for battery-powered nodes 120 that need to conserve energy and for conventional nodes 120 that detect particularly low stability in the first PAN 110, so that there will be little benefit to staying in the first PAN 110 during the gradual transfer.

[0051] In some embodiments, hard migration involves a notification period. To initiate a hard migration from a first PAN 110 to a second PAN 110, the subject node 120 may broadcast a migration notification message indicating an expiration time of the notification period. For example, the expiration time may be indicated as a timestamp or a timeout relative to the time when the migration notification message was sent. The expiration time may define when the subject node 120 begins its actual exit from the first PAN 110 and sends a join request to the second PAN 110. During the notification period, the subject node 120 may consider a rejection of its migration selection.

[0052] In some embodiments, the migration notification message notifies neighboring nodes 120, including child nodes 120, of the migration decision of the subject node. As a result of the notification, the child nodes 120 and other neighboring nodes 120 can determine how to respond to the potential migration. For example, the child nodes 120 of the subject node 120 can begin searching for a new parent node 120 in the first PAN 110 or a different PAN 110. Additionally or alternatively, each node 120 can maintain a neighbor list identifying its neighboring nodes, and in response to receiving the migration notification message, the neighboring nodes 120 of the subject node 120 can begin updating their respective neighbor lists to exclude the subject node 120.

[0053] In some embodiments, the neighboring nodes 120 may reject the migration of the subject node 120 if such rejection is based on one or more predetermined reasons and such rejection is actually a request for the subject node 120 to remain in the first PAN 110. For example, if the child node 120 of the subject node 120 cannot reach (i.e., via radio signals) any potential new parent node 120 in the first PAN 110 or another PAN 110, the child node 120 may reject the migration. For another example, if the child node 120 is involved in a critical task, for example, if the child node 120 is a critical node 120 or if the child node 120 is in the middle of a firmware download such that the firmware download will need to be restarted or packets of the firmware download will be discarded if the child node 120 needs to find a new parent node, the child node 120 may reject the migration. If the child node 120 rejects the migration, the child node 120 may send a negative acknowledgement (NACK) message to the subject node 120, which indicates the rejection and the reason for the rejection. However, if the child node 120 does not reject, the child node 120 may, but need not, send a positive acknowledgement (ACK) message back to the subject node 120 .

[0054] If the subject node 120 does not receive any rejections (e.g., as expressed in a NACK message) from a neighboring node 120 before the expiration time, the subject node 120 may perform a hard migration as described below. However, if the subject node 120 receives one or more rejections, the subject node 120 may determine whether to terminate the hard migration. In some embodiments, the subject node 120 applies a set of rules to determine whether to terminate the hard migration based on the received rejections. The rules may encode a set of priorities for the node. For example, if the subject node 120 receives a rejection from a child node 120 that cannot find a new parent node 120 in the first PAN 110 or another PAN 110, the subject node 120 may terminate the hard migration before actually leaving the first PAN 110 or joining the second PAN 110. In this case, the lack of another suitable parent node in the child node 120 has a higher priority than the improved stability that the subject node 120 will experience through migration. Additionally or alternatively, if the subject node 120 receives rejections from a predetermined percentage (e.g., 75%) of child nodes 120, the subject node 120 may terminate the hard migration before leaving the first PAN 110 or joining the second PAN 110. In this case, the high rejection rate is assigned a higher priority than the improved stability that the subject node 120 will experience through the migration. If the subject node 120 terminates the hard migration, soft migration may still be an option, as described below.

[0055] However, if the subject node 120 faces maximum packet drops, such as in the case where the instability factor of the first PAN 110 is above the mode threshold, the subject node 120 may decide to proceed with the hard migration despite the rejection. In this case, regardless of the reason for the rejection, the subject node 120 may not be able to reliably provide communication routing or other services to its neighboring nodes 120 within the first PAN 110. In this case, the high risk of packet drops in the current state outweighs the rejection from other nodes 120. Therefore, there will be no substantial benefit in terminating the migration, and the subject node 120 may therefore proceed with the hard migration.

[0056] If the subject node 120 terminates the hard migration due to one or more rejections received from neighboring nodes 120, the subject node 120 may send a termination notification message to each neighboring node 120 that rejected the migration. For example, the subject node 120 may send a unicast message to each such neighboring node 120 to indicate that the hard migration is terminated, or the subject node 120 may broadcast a message to notify nearby nodes 120 that the hard migration is terminated.

[0057] Example of soft migration

[0058] In some embodiments, soft migration is more gradual than hard migration because the activities involved in leaving the first PAN 110 and joining the second PAN 110 begin at an earlier point in the migration process. At some point, the subject node 120 that migrates from the first PAN 110 to the second PAN 110 via soft migration may be associated with and may participate in the first PAN 110 and the second PAN 110 in some respects. In contrast to hard migration, soft migration can ensure that the subject node 120 remains connected to other nodes 120 in the wireless mesh network 100 throughout the migration process. Soft migration may be beneficial, particularly (a) for a critical node 120 that acts as a subject node 120 or (b) for a subject node 120 that is a parent node of one or more critical nodes 120 or a parent node of one or more nodes 120 that perform critical tasks (such as firmware downloads). In situations where the first PAN 110 has high stability (eg, low instability factor), soft migration may also benefit regular nodes 120 because service to or from regular nodes 120 may potentially proceed more smoothly during soft migration and may not require power conservation as battery-powered nodes 120 do.

[0059] In some embodiments, soft migration involves a notification period. The notification period can be, but need not be, shorter than the notification period used during hard migration. In order to initiate a soft migration from a first PAN 110 to a second PAN 110, the subject node 120 may broadcast a migration notification message indicating an expiration time of the notification period. For example, the expiration time may be indicated as a timestamp or a timeout length. The expiration time may define when the subject node 120 stops providing services (e.g., routing communications) for the first PAN 110 and removes the neighboring node 120 in the first PAN 110 from its neighbor list. During the notification period, the subject node 120 may consider a rejection of its choice to migrate from the first PAN 110 to the second PAN 110.

[0060] In some embodiments, the migration notification message notifies neighboring nodes 120, including child nodes 120, of the migration decision of the subject node. As a result of the notification, the child nodes 120 and other neighboring nodes 120 can determine how to respond to the potential migration. For example, the child nodes 120 of the subject node 120 can begin searching for a new parent node 120 in the first PAN 110 or a different PAN 110. Additionally or alternatively, the neighboring node 120 can begin updating its corresponding neighbor list of its own neighboring node 120 to exclude the subject node 120.

[0061] In some embodiments, if such rejection is based on one or more of a set of predetermined reasons, and such rejection is actually a request for the subject node 120 to remain in the first PAN 110, the neighboring node 120 may reject the migration of the subject node 120. For example, if a child node 120 of the subject node 120 cannot reach (e.g., via a radio signal) a potential new parent node 120 in the first PAN 110 or another PAN 110, the child node 120 may reject the migration. For another example, if the child node 120 is involved in a critical task, for example, if the child node 120 is a critical node 120 or if the child node 120 is in the middle of a firmware download, the child node 120 may reject the migration. If the child node 120 rejects the migration, the child node 120 may send a NACK message to the subject node 120, which indicates the rejection and the reason for the rejection. If the child node 120 does not reject, the child node 120 may, but need not, send an ACK message back to the subject node 120. In some embodiments, the possible reasons for the rejection may be the same or similar to the reasons used during hard migration, as described above.

[0062] In some embodiments, the subject node 120 also sends a coordinator notification message indicating the expiration time to the PAN coordinator of the first PAN 110. In contrast, during a hard migration, a notification message does not need to be sent to the PAN coordinator 115. During the notification period, the PAN coordinator 115 may determine the impact that the migration of the subject node 120 will have on the PAN 110. As described above, the PAN coordinator 115 may maintain an indication of a mesh tree of nodes 120 in the PAN 110. The PAN coordinator 115 may therefore check the location of the subject node 120 within the mesh tree and identify a subtree with the subject node 120 as its root. During the notification period, the PAN coordinator 115 may send a subtree notification message to the nodes 120 in the subtree. The nodes 120 in the subtree may be direct and indirect child nodes 120 of the subject node 120, and may therefore be affected by the migration of the subject node away from the first PAN 110. Without the subtree notification message, some of these nodes 120 that are not neighboring nodes 120 of the subject node 120 may not have information about the migration and may subsequently suffer communication delays if the migration is completed. However, as a result of the subtree notification message, these nodes 120 may begin searching for a new parent node 120 within the first PAN 110 of the wireless mesh network 100 or in another PAN 110.

[0063] In addition or in lieu of the above, the PAN coordinator 115 may deny the migration of the subject node 120, and such denial is effectively a request for the subject node 120 to remain in the first PAN 110. For example, the PAN coordinator 115 may determine from its analysis of the mesh tree of the PAN 110 that the loss of the subject node 120 will negatively impact the stability of the PAN 110. For example, if the PAN coordinator 115 determines that one or more critical nodes 120 no longer have a reliable communication route to the PAN coordinator 115 without the participation of the subject node 120, the PAN coordinator may make this determination. For another example, the PAN coordinator 115 may calculate a current instability factor of the first PAN 110 and an expected instability factor of the first PAN 110 without the subject node 120. If the expected instability factor indicates reduced stability compared to the current instability factor, or if the expected instability factor satisfies a threshold (e.g., is above a threshold), the PAN coordinator 115 may conclude that the migration of the subject node 120 will negatively impact the stability of the first PAN 110. If the PAN coordinator 115 determines that the migration does negatively impact the stability of the first PAN 110, the PAN coordinator 115 may reject the migration by sending a coordinator NACK message to the subject node 120. The coordinator NACK message may indicate the reason why the PAN coordinator rejected the migration.

[0064] In some embodiments, the subject node 120 decides on its own whether to continue the migration. To make this decision, the subject node 120 can apply a set of rules to the current situation of the subject node, including, for example, a first instability factor or any rejections received. For example, if the subject node 120 receives a rejection from a child node 120 that cannot find a new parent node 120, the subject node 120 can terminate the soft migration. Additionally or alternatively, if the subject node 120 receives a rejection from a predetermined percentage (e.g., 50%) of child nodes for other reasons (e.g., as a key node 120 or participating in a key task), the subject node 120 can terminate the soft migration. Additionally or alternatively, if the subject node 120 receives a coordinator NACK message from the PAN coordinator 115, the subject node 120 can give a large weight to the coordinator NACK message and can, for example, delay or terminate the soft migration.

[0065] However, if the subject node faces maximum packet drops, such as when the instability factor of the first PAN 110 is above the mode threshold, the subject node 120 may determine to proceed with the soft migration despite the rejection. In this case, regardless of the reason for the rejection, the subject node 120 may not be able to reliably provide communication routing or other services to its neighboring nodes 120 within the first PAN 110.

[0066] If the subject node 120 chooses to terminate the soft migration, the subject node 120 may send a coordinator termination notification message to the PAN coordinator 115. Additionally or alternatively, the subject node 120 may send a termination notification message to each neighboring node 120 that rejected the migration. For example, the subject node 120 may send a unicast message to each such neighboring node 120 to indicate that the soft migration is terminated. In some embodiments, when terminating the soft migration, if the joining process has already begun, the subject node 120 may terminate the joining process to join the second PAN 110, and the subject node 120 may remove the indication of any node 120 in the second PAN 110 that has been added to its neighbor list in anticipation of the migration. After terminating the soft migration, the PAN 110 may postpone any further migration attempts, such as for a predetermined period of time.

[0067] In some embodiments, the message sent between the subject node 120 and the neighboring node 120 to facilitate hard migration or soft migration is a media access control (MAC) layer message. For example, the message sent via the MAC layer to facilitate migration may include one or more of the following: a migration notification message, an ACK message, a NACK message, a migration termination message, and a message from the child node 120 requesting migration of the parent node. Below, Table 1 shows an example format of a MAC layer message, which can be used for each such message between neighboring nodes 120, as described herein:

[0068]

[0069] In some implementations, if the MAC layer message is a migration notification message, bits 0-2 of octet 1 of the MAC layer message are set to a value other than 000, and if the MAC layer message is a termination notification message, the value of octet 1 is 000. Table 2 below shows examples of the meaning of various possible values ​​of the bits in octet 1:

[0070]

[0071] In some embodiments, the following additional indications are used in the MAC layer message: Bit 3 of octet 1 is a Boolean variable indicating the validity (i.e., inclusion) of the PAN ID in octets 4-5; Bit 4 of octet 1 is a Boolean variable indicating whether the cause flag in octet 6 is valid; Bit 5 indicates whether bit 6 is valid, and if valid, bit 6 is a Boolean variable indicating whether the MAC layer message is an ACK message or alternatively a NACK message; and Bit 7 is reserved for future use or may be used for some other purpose. In some embodiments, if bit 5 is not set, octets 2-3 are valid, and in this case, octets 2-3 indicate the expiration time of the notification period. Octets 4-5 may be used to notify the child node 120 of the PAN ID of the destination PAN 110, and octets 4-5 may be used to respond to a child node 120 that has requested migration in order to notify the child node 120 of the destination PAN 110. Octet 6 may be used for a cause flag, such as indicating the reason for rejecting the migration of the neighboring node 120.

[0072] In some embodiments, the MAC layer messages between the subject node 120 and its PAN coordinator 115 or between other nodes 120 and the PAN coordinator 115 may adopt a format different from that described above. These messages may include a coordinator notification message, a subtree notification message, a coordinator ACK message, a coordinator NACK message, and a coordinator termination notification message. Table 3 below indicates an example format of these MAC layer messages:

[0073]

[0074] In some embodiments, the migration type in bits 0-2 of octet 1 may be defined as provided in Table 2; bit 3 of octet 1 indicates whether octets 2-8 are valid; bit 4 of octet 1 indicates whether octets 2-8 (if valid) indicate a short address or a long address of subject node 120; and bits 5-7 of octet 1 are reserved or used for some other purpose. Octets 2-8 may indicate the address of subject node 120. In some embodiments, either a short address or a long address may be used; for example, a long address may be used if wireless mesh network 100 is large enough that a long address may be needed to ensure uniqueness of the address.

[0075] Example method for implementing a hard migration

[0076] Figure 3 is a flow chart of a method 300 for performing a hard migration according to some embodiments described herein. Figure 3 The method 300 depicted in can be implemented in software executed by one or more processors of a computer system, in hardware, or in a combination of software and hardware. Figure 3 The method 300 presented in and described below is intended to be illustrative and not limiting. Figure 3 Various processing operations are depicted as occurring in a particular sequence or order, but this is not intended to be limiting. In certain alternative examples, processing may be performed in a different order, operations may be excluded or added, or some operations may be performed in parallel. In some embodiments, in response to determining to migrate to the destination PAN 110 by way of a hard migration, the subject node 120 may perform Figure 3 Method 300 or a similar method.

[0077] Before the method 300 begins, the subject node 120 has already selected a destination PAN 110 to migrate from the first PAN 110, and the subject node 120 has already selected hard migration as the migration mode for this particular migration. Figure 3 As shown, at block 305, the subject node 120 notifies its neighboring nodes 120 of the migration, such as by broadcasting a migration notification message. In some embodiments, the migration notification message indicates an expiration time of the notification period. In addition, in some embodiments, the subject node 120 has not yet initiated leaving the first PAN 110 or joining the destination PAN 110.

[0078] At block 310, after being notified of the migration, each neighboring node 120 of the subject node 120 determines whether it has a reason to reject the migration of the subject node 120. For example, each neighboring node 120 may have a predetermined set of reasons that, if true, allow the neighboring node 120 to reject the migration. If one of the reasons is true, the neighboring node 120 rejects the migration by sending a negative acknowledgement message to the subject node indicating the reason for the rejection.

[0079] Thus, at block 315, the subject node 120 receives the rejection sent by its neighboring node 120 (if one has been made). At decision block 320, the subject node 120 determines whether to continue or terminate the hard migration. The decision may be based on the received rejection, or more specifically, on the reason indicated by such a rejection. Specifically, for example, the subject node 120 applies a set of rules (i.e., conditions) to the rejection to determine whether to terminate the migration.

[0080] If the subject node 120 determines to terminate the hard migration, then at block 325, the subject node 120 may attempt a soft migration to the destination PAN 110. In this case, the subject node 120 may perform Figure 4Soft migration may be performed by the method 400 or similar methods shown. However, if the subject node 120 determines to proceed with hard migration, then at block 330 of method 300, the subject node 120 stops providing services (e.g., routing communications) to the first PAN 110 and stops advertising the beacon 140 of the first node 120. At block 335, the subject node 120 sends a join request to the node 120 of the destination PAN 110 to initiate joining the destination PAN 110.

[0081] Example method for implementing soft migration

[0082] Figure 4 is a flow chart of a method 400 for performing a soft migration according to some embodiments described herein. Figure 4 The method 400 depicted in can be implemented in software executed by one or more processors of a computer system, in hardware, or in a combination of software and hardware. Figure 4 The method 400 presented in and described below is intended to be illustrative and not limiting. Figure 4 Various processing operations are depicted as occurring in a particular sequence or order, but this is not intended to be limiting. In certain alternative examples, processing may be performed in a different order, operations may be excluded or added, or some operations may be performed in parallel. In some embodiments, in response to determining to migrate to the destination PAN 110 by way of a soft migration, the subject node 120 may perform Figure 4 Method 400 or a similar method.

[0083] Prior to the start of the method 300, the subject node 120 has selected a destination PAN 110 to migrate to from the first PAN 110, and the subject node 120 has selected soft migration as the migration mode for this particular migration. In some implementations, soft migration may have been selected after a failed hard migration, but alternatively, the subject node 120 may have initially determined that soft migration is appropriate instead of hard migration.

[0084] like Figure 4As shown, at box 405, the subject node 120 notifies its neighboring nodes 120 of the migration, such as by broadcasting a migration notification message. In some embodiments, the migration notification message indicates the expiration time of the notification period. At box 410, without waiting for the expiration time to arrive, the subject node 120 stops sending beacons 140 and other management packets in the first PAN 110, and the subject node 120 sends a join request to the destination PAN 110, which begins the process of joining the destination PAN 110. However, the subject node 120 can continue to serve the first PAN 110, such as by routing communications to and from its direct and indirect child nodes 120. At this point, the subject node 120 transitions between the first PAN 110 and the destination PAN 110, but does not need to be a full participant in either one. However, in some embodiments, various activities can still occur during the soft migration, which will cause the subject node 120 to terminate the soft migration.

[0085] Although in Figure 4 4. Although not shown as a box in FIG. 4, if the process of joining the destination PAN 110 fails at any point in the method 400 for soft migration, the soft migration as a whole fails, and the subject node 120 may therefore terminate the soft migration. Upon terminating the soft migration, the subject node 120 may resume sending beacons 140 and other management packets in the first PAN 110, and the subject node 120 may remove from its list of neighboring nodes 120 any nodes 120 that were added to the list from the destination PAN 110 during the soft migration.

[0086] At block 415, after being notified of the migration, each neighboring node 120 of the subject node 120 determines whether it has a reason to reject the migration. For example, each neighboring node 120 may have a predetermined set of reasons that, if true, allow the neighboring node 120 to reject the migration. If one of these reasons is true, the neighboring node 120 may reject the migration by sending a NACK message to the subject node 120, which may indicate the reason for the rejection.

[0087] At block 420, the subject node 120 receives rejections (if any) made by its neighboring nodes 120. At decision block 425, the subject node 120 determines whether to continue or terminate the soft migration. The decision may be based on the rejection received, or more specifically, based on the reason indicated by such rejection. In some embodiments, for example, the subject node 120 applies a set of rules (i.e., conditions) to the rejection to determine whether to continue or terminate the soft migration. If the subject node 120 determines to terminate the soft migration, then at block 430, the subject node 120 may (1) resume beacons 140 announcing the first PAN 110, terminate the join process for joining the destination PAN 110, and remove indications of any nodes 120 in the second PAN 110 that have been added to its neighbor list in anticipation of the migration. In some embodiments, after terminating the soft migration, the PAN 110 may postpone any further migration attempts, such as for a predetermined period of time.

[0088] If the subject node 120 decides to proceed with the soft migration, then at block 435, the subject node 120 notifies the PAN coordinator 115 of the first PAN 110 of the migration, such as by sending a coordinator migration notification message to the PAN coordinator 115. At block 440, after being notified, the PAN coordinator 115 notifies the subtree of the subject node 120 of the migration, such as by sending a subtree notification message to each direct and indirect child node 120 of the subject node 120, to ensure that these nodes 120 are aware of the potential migration. This may enable such nodes 120 to search for corresponding new parent nodes 120, if necessary. In some embodiments, if applicable, the direct and indirect child nodes 120 may send a NACK message back to the PAN coordinator 115. Additionally or alternatively, at block 445, the PAN coordinator 115 determines whether to reject the migration. For example, if the PAN coordinator 115 determines that the stability of the first PAN 110 will be negatively affected by the subject node 120 leaving the first PAN 110, the PAN coordinator 115 may reject the migration. This determination may be informed, for example, by any NACK messages received by the PAN coordinator 115 or by the PAN coordinator's own analysis of the mesh tree of the PAN 110 .

[0089] At block 450, the PAN coordinator 115 sends an indication of a positive acknowledgement or a rejection in the form of a negative acknowledgement to the subject node 120. For example, if the PAN coordinator 115 has no reason to reject the migration (e.g., if there is no substantial negative impact on PAN stability), the PAN coordinator 115 may send a coordinator ACK message back to the subject node 120. The coordinator ACK message may have a format similar to that shown in Table 3 above. In this case, the PAN coordinator 115 may express its non-rejection by including in the MAC layer message the same migration type (i.e., soft migration) as indicated in the coordinator notification message sent by the subject node 120 to the PAN coordinator 115. However, if the PAN coordinator 115 determines a reason for rejecting the migration, the PAN coordinator 115 may send a coordinator NACK message back to the subject node 120. Similar to the coordinator ACK message, the coordinator NACK message may take the form of a MAC layer message, as shown in Table 3. However, in the case of the coordinator NACK message, the indicated migration type may be different from the migration type indicated by the subject node 120 in the coordinator notification message, thereby indicating a negative acknowledgement.

[0090] At decision block 455, upon receiving feedback from the PAN coordinator 115 (eg, a coordinator ACK message or a coordinator NACK message), the subject node 120 determines whether to terminate, delay, or continue the soft migration. In some embodiments, the PAN coordinator 115 has control over the PAN 110 (including the subject node 120). Therefore, the PAN coordinator 115 is able to stop the migration or delay the migration, and in such an embodiment, the subject node 120 complies with any such request from the PAN coordinator 115. Additionally or alternatively, the subject node 120 may apply a set of rules to the feedback from the PAN coordinator 115. If the PAN coordinator sends a NACK message, which indicates a temporary reason (for example, one or more indirect child nodes 120 are not critical nodes 120, but are in the process of performing a critical task such as firmware download), then in block 460, the subject node 120 may delay the completion of the soft migration. In this case, the subject node 120 may continue the soft migration after the additional waiting period has passed. During the additional period, the subject node 120 may, but need not, resume sending the beacon 140 of the first PAN 110 and terminate joining the destination PAN 110. In this case, the subject node 120 may stop sending the beacon 140 again and start joining the destination PAN after the additional waiting period. 110. However, if the reason for the PAN coordinator's rejection is not necessarily temporary (e.g., the critical node 120 will lose communication with the PAN coordinator 115 due to the migration, or the subject node 120 has multiple battery-powered nodes 120 as child nodes), the subject node 120 may terminate the soft migration, such as at block 430 of the illustrated method 400.

[0091] However, if the PAN coordinator 115 does not reject the migration, then the subject node 120 completes the soft migration at block 465. To this end, the subject node 120 completes authentication and association with the destination PAN 110 and stops performing services for the first PAN 110.

[0092] Example computing system acting as a node

[0093] Figure 51 is a diagram of an example of a computing system 500 acting as a node 120 in a wireless mesh network 100 according to some embodiments described herein. For example, the computing system 500 may act as a subject node 120, a PAN coordinator 115, or some other node 120 in the wireless mesh network 100. The computing system 500 may be a general-purpose computing device or a special-purpose computing device, such as a utility meter or a gateway. The depicted example of the computing system 500 includes a processor 502 communicatively coupled to one or more memory devices 504. The processor 502 executes computer executable program code stored in the memory device 504. Examples of the processor 502 include a microprocessor, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another suitable processing device. The processor 502 may include one or more processing devices.

[0094] The memory device 504 includes suitable non-transitory computer-readable media for storing data, program code, or both. Computer-readable media may include electronic, optical, magnetic, or other storage devices capable of providing computer-readable instructions or other program code to the processor. Non-limiting examples of computer-readable media include disks, memory chips, read-only memories (ROMs), random access memories (RAMs), optical storage devices, magnetic tapes or other magnetic storage devices, or another medium from which a processing device can read instructions.

[0095] In some implementations, computing system 500 executes program code that configures processor 502 to perform one or more of the operations described herein. The program code includes, for example, instructions for implementing one or more of: a hard migration subsystem 522 for performing a hard migration as described herein; a soft migration subsystem 524 for performing a soft migration as described herein; or a migration manager 520 for determining whether to migrate, selecting a destination PAN 110 for migration, and initiating hard migration subsystem 522 or soft migration subsystem 524 to perform a hard migration or a soft migration, respectively. The program code may reside in memory device 504 or a suitable computer-readable medium and may be executed by processor 502 or other suitable processor.

[0096] The computing system 500 may include one or more external or internal devices, such as input or output devices. For example, the computing system 500 is shown as having one or more input / output ("I / O") interfaces 508. One or more buses 506 are also included in the computing system 500. The bus 506 communicatively couples one or more components of the computing system 500.

[0097] An embodiment of computing system 500 includes a network interface device 510, such as a radio. Network interface device 510 includes one or more devices suitable for establishing a wired or wireless data connection with other computing devices in wireless mesh network 100. Non-limiting examples of network interface device 510 include an Ethernet network adapter, a wireless fidelity (WiFi) device, a near field communication (NFC) device, a wireless smart utility network (Wi-SUN) device, a radio frequency (RF) device, a ZigBee device, or some other communication device. Using network interface device 510, computing system 500 can communicate with other nodes of wireless mesh network 100, and thus can perform the operations described herein.

[0098] General considerations

[0099] Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will appreciate that the claimed subject matter may be practiced without these specific details. In other cases, methods, devices, or systems known to those of ordinary skill in the art are not described in detail in order to avoid obscuring the claimed subject matter.

[0100] The features discussed herein are not limited to any particular hardware architecture or configuration. A computing device may include any suitable arrangement of components that provide a result conditioned on one or more inputs. Suitable computing devices include a multi-purpose microprocessor-based computer system that accesses stored software (i.e., computer-readable instructions stored on a computer system's memory) that programs or configures the computing system from a general-purpose computing device to a dedicated computing device that implements one or more aspects of the present subject matter. Any suitable programming, scripting, or other type of language or combination of languages ​​may be used to implement the teachings contained herein in software for programming or configuring a computing device.

[0101] Aspects of the methods disclosed herein may be performed in the operation of such a computing device. The order of the blocks presented in the above examples may be changed; for example, the blocks may be reordered, combined and / or decomposed into sub-blocks. Certain blocks or processes may be executed in parallel.

[0102] The use of "suitable for" or "configured to" herein is meant to be open and inclusive language, which does not exclude devices that are suitable for or configured to perform additional tasks or steps. In addition, the use of "based on" is meant to be open and inclusive, because a process, step, calculation or other action "based on" one or more stated conditions or values ​​may be based on additional conditions or values ​​beyond the stated conditions or values ​​in practice. The headings, lists and numbers included herein are for ease of explanation only and are not meant to be limiting.

[0103] Although the subject matter has been described in detail with respect to specific aspects of the subject matter, it should be understood that those skilled in the art, after obtaining an understanding of the foregoing, can easily produce changes, modifications and equivalents to these aspects. Therefore, it should be understood that the present disclosure has been presented for the purpose of illustration and not limitation, and does not exclude the inclusion of such modifications, changes and / or additions to the subject matter, which are obvious to those of ordinary skill in the art.

Claims

1. A method comprising: receiving, by a node connected to a first area network PAN, a packet from a second PAN other than the first PAN; determining, based on the grouping, that a second instability factor associated with the stability of the second PAN differs from a first instability factor associated with the stability of the first PAN by at least a margin; sending a migration notification message to a neighboring node in the first PAN indicating that the node is migrating; receiving, from the neighboring node in the first PAN, a request for the node to remain in the first PAN; applying, by the node, one or more rules to the request to deny the request by the node to remain in the first PAN; as well as Based on rejecting the request, migration to the second PAN is completed.

2. The method according to claim 1, wherein: The migration notification message indicates a notification period during which the node will accept requests from neighboring nodes for the node to remain in the first PAN, and the method further includes sending, by the node, a join request to the second PAN after expiration of the notification period.

3. The method according to claim 1, wherein: The migration notification message indicates a notification period during which the node will accept requests from neighboring nodes for the node to remain in the first PAN, and the method further includes sending, by the node, a request to join the second PAN before expiration of the notification period.

4. The method according to claim 1, wherein: The node is configured to perform migration using a first migration mode, and wherein the node is configured to perform migration using a second migration mode, and wherein the node selects between the first migration mode and the second migration mode.

5. The method according to claim 4, wherein: A selection is made between the first migration mode and the second migration mode for the migration based on the first instability factor.

6. The method according to claim 4, wherein: The node selects the first migration mode for the migration based on the classification of the node as a battery-powered node.

7. The method according to claim 6, wherein: The node selects the second migration mode for the migration based on the classification of the node as a critical node.

8. The method according to claim 4, wherein: The node selects the second migration mode because the node fails to complete migration in the first migration mode.

9. The method of claim 1, further comprising calculating the first instability factor based on historical packet success in the first PAN.

10. The method of claim 1, further comprising sending, by the node, a migration notification to a PAN coordinator of the first PAN, wherein the node receives a request from the PAN coordinator for the node to terminate the migration.

11. The method according to claim 1, wherein: Determining, based on the grouping, that the second instability factor differs from the first instability factor by at least the margin comprises: Receiving, by the node, a migration request from a child node of the node; reducing the margin to an updated margin based on the migration request; and It is determined that the second instability factor differs from the first instability factor by at least the updated margin.

12. A system comprising: A subject node connected to a first area network PAN of a wireless mesh network, wherein the subject node is configured to: identifying the destination PAN as a target for the migration; and sending a notification to one or more neighboring nodes that the subject node is migrating to the destination PAN; and a neighboring node of the node, wherein the neighboring node is connected to the first PAN and is configured to: receiving the notification from the subject node; determining a reason selected from a set of predetermined reasons for rejecting migration of the subject node; and Sending a request to terminate the migration to the subject node; The subject node is further configured to exit the first PAN and join the destination PAN based on prioritizing an expected improvement in stability due to the migration over reasons associated with the request from the neighboring node.

13. The system according to claim 12, wherein: The subject node delays the migration based on an additional request from a PAN coordinator of the first PAN.

14. The system according to claim 12, wherein: In order to identify the destination PAN as the target of the migration, the subject node is further configured to: calculating a first instability factor of the first PAN based on routing cost, link quality, the number of nodes in the first PAN, and a grouping success rate of the first PAN; as well as A second instability factor is determined to differ from the first instability factor by at least a margin.

15. The system of claim 14, wherein: The subject node is configured to perform migration using a first migration mode, and wherein the node is configured to perform migration using a second migration mode, and wherein the node selects between the first migration mode and the second migration mode based on at least one of a classification of the subject node or a value of the first instability factor.

16. The system of claim 14, wherein: In order to determine that the second instability factor differs from the first instability factor by at least the margin, the subject node is further configured to: receiving a migration request from a child node of the node; reducing the margin to an updated margin based on the migration request; as well as It is determined that the second instability factor differs from the first instability factor by at least the updated margin.

17. A computing device connected to a first area network (PAN) of a wireless mesh network, the computing device comprising: a processor configured to execute computer-readable instructions; a memory configured to store the computer-readable instructions, which, when executed by the processor, cause the processor to perform operations comprising: receiving a packet from a second PAN other than the first PAN; determining, based on the grouping, that a second instability factor associated with the stability of the second PAN differs from a first instability factor associated with the stability of the first PAN by at least a margin; sending a migration notification message to neighboring nodes in the first PAN indicating that the computing device is migrating; receiving, from the neighboring node in the first PAN, a request for the computing device to remain in the first PAN; applying one or more rules to the request to deny the request for the computing device to remain in the first PAN; and Based on rejecting the request, migration to the second PAN is completed.

18. The computing device of claim 17, wherein: The migration notification message indicates a notification period during which the computing device is to accept requests from neighboring nodes for the computing device to remain in the first PAN, and the operations further include sending a join request to the second PAN after expiration of the notification period.

19. The computing device of claim 17, wherein: The migration notification message indicates a notification period during which the computing device is to accept requests from neighboring nodes for the computing device to remain in the first PAN, and the operations further include sending a request to join the second PAN before expiration of the notification period.

20. The computing device of claim 17, wherein: Determining, based on the grouping, that the second instability factor differs from the first instability factor by at least the margin comprises: receiving a migration request from a child node of the computing device; reducing a threshold difference based on the migration request; and It is determined that the second instability factor differs from the first instability factor by at least the threshold difference.

Images