Intelligent PAN Migration in Wireless Mesh Networks

Abstract

The technology described in this application relates to intelligent migration between PANs of a wireless mesh network. In one embodiment, the 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 related to the stability of the second PAN differs by at least a margin from a first instability factor related to the stability of the first PAN. The node sends a migration notification message indicating that the node is performing a migration to neighboring nodes in the first PAN and receives, from the neighboring nodes in the first PAN, a request for the node to stay in the first PAN. The node applies one or more rules for rejecting a request for the node to stay in the first PAN and proceeds with the completion of the migration based on rejecting the request.

Description

Technical Field

[0001] Some of the embodiments described in the present application 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 having pairwise connections, which together form a wireless mesh through which the nodes can communicate with each other. More specifically, a plurality of nodes are connected together to form a group known as a personal area network (PAN), where each PAN is coordinated by a respective PAN coordinator, and the nodes within a PAN provide communication routing services or other services to other nodes within that PAN. Each PAN coordinator may communicate directly or indirectly with a head-end system, which may, as a whole, provide services to the wireless mesh network.

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

[0004] For example, a node may move from a first PAN to a second PAN when it determines that the instability factor of the second PAN is sufficiently better (e.g., lower by a predetermined margin) than the instability factor of the first PAN to which the endpoint currently belongs. In making this decision, the endpoint requests to leave the first PAN and join the second PAN. SUMMARY OF THE INVENTION PROBLEM TO BE SOLVED BY THE INVENTION

[0005] The present disclosure provides intelligent PAN migration in a wireless mesh network. MEANS FOR SOLVING THE PROBLEM

[0006] In one example described in this application, the method includes a node connected to a first personal area network (PAN) receiving packets from a second PAN other than the first PAN. Based on the packets, 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 indicating that the node is performing a migration to neighboring nodes in the first PAN and receives from the neighboring nodes in the first PAN a request for the node to stay in the first PAN. In response to the request, the node applies one or more rules for rejecting the request for the node to stay in the first PAN and proceeds with the completion of the migration based on rejecting the request.

[0007] In another example described in this application, the system includes a target node and neighboring nodes, both of which are connected to a first PAN. The target node is configured to identify a destination PAN as a migration target and send a notification to one or more neighboring nodes that the target node is performing a migration to the destination PAN. The neighboring nodes are configured to receive the notification from the target node and determine a reason for opposing the migration of the target node, the reason being selected from a predefined set of reasons. The neighboring nodes are further configured to send a request to the target node to end the migration. The target node is further configured to leave the first PAN and join the destination PAN based on prioritizing an expected improvement in stability resulting from the migration over the reason associated with the request from the neighboring nodes.

[0008] In yet another example described in the present application, the 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 that cause the processor to perform operations when executed by the processor. The operations include receiving packets from a second PAN other than the first PAN and, based on the packets, determining that at least by a margin, a second instability factor related to the stability of the second PAN is different from a first instability factor related to the stability of the first PAN. The operations include sending a migration notification message indicating that the computing device is performing a migration to neighboring nodes in the first PAN and receiving a request from the neighboring nodes in the first PAN for the computing device to stay in the first PAN. The operations further include applying to the request one or more rules for rejecting a request for the computing device to stay in the first PAN and completing the migration to the second PAN based on rejecting the request.

[0009] These exemplary aspects and features are not intended to limit or define the subject matter described herein, but rather are referred to in order to provide examples that assist in understanding the concepts described in the present application. Other aspects, advantages, and features of the subject matter described herein will become apparent by reading the entire present application.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

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

[0012] As described above, a target node (i.e., a specific node) in a wireless mesh network can migrate from a first personal area network (PAN) to a second PAN when it is determined that the stability in the second PAN is sufficiently better than the stability in the first PAN. However, currently, there are various drawbacks to the way PAN migration is performed. For example, when the target node detaches from the first PAN, the previous child nodes of the target node are left without a parent and then must immediately find the position of each new parent. In some cases, there may be no node in the first PAN that has an appropriate signal strength regarding the child nodes to operate as a new parent. The child node may be an important node in that the service it provides is considered very important to the wireless mesh network. It is not desirable to leave an important node without a parent. In short, if the target node unilaterally selects to detach from the PAN and does so without warning, this can put the rest of the PAN in an undesirable situation and may damage the wireless mesh network as a whole.

[0013] Some of the embodiments described in this application address these problems of existing PAN migration techniques. In some embodiments, the target node is capable of at least two migration modes, which are referred to in this application as the hard migration mode and the soft migration mode. Using the hard migration mode, also referred to in this application as hard migration, the target node notifies its neighboring nodes (e.g., its child nodes or other reachable nodes) in its current PAN of its intention to perform a migration, and those neighboring nodes have the opportunity to object. Using the second migration mode, also referred to in this application as soft migration, the target node notifies its neighboring nodes and the PAN coordinator, and further, the target node performs a gradual migration that allows it to start the process of joining another PAN while continuing to provide services to its current PAN, thus improving stability from a unilateral perspective while allowing nodes in its current PAN to perform pre-adjustments if necessary. In either migration mode, the target node may re-evaluate its decision to perform a migration based on feedback from other nodes. Thus, in contrast to existing techniques where migration is unilaterally determined based solely on a comparison of instability factors, some of the embodiments described in this application consider a wide range of factors and, if necessary, provide a smoother transition for the affected nodes.

[0014] Example of a wireless mesh network supporting multiple migration modes Figure 1 is a diagram of a wireless mesh network 100 according to several embodiments described in the present application. As shown in Figure 1, the wireless mesh network 100 may include two or more PANs 110, such as a first PAN 110a and a second PAN 110b. An exemplary PAN 110 includes each PAN coordinator 115 and one or more nodes 120. Each node 120 may be an endpoint such as a demand meter, but it is not necessary. In some embodiments, each node 120 may be a computing device such as a demand meter, a gateway, or any other computing device having a wireless device and capable of participating in communication in the wireless mesh network 100. Also as shown in Figure 1, an embodiment of the wireless mesh network 100 includes a head-end system 130. The head-end system 130 provides one or more services to the nodes 120, such as pushing firmware updates or collecting utility usage or other data for processing and billing.

[0015] In some embodiments, the wireless mesh network 100 may include various types or classes of nodes 120. Such classes may include, for example, critical, battery-operated, or normal. In some embodiments, critical nodes 120 are nodes that perform services that are considered critical (e.g., by an administrator), such as performing a distributed access (DA) service for the PAN 110 or the wireless mesh network 100 or the utility network as a whole. If a critical node 120 shuts down or loses its communication ability with other nodes 120 in the wireless mesh network 100, the critical functions of the wireless mesh network 100 will be affected. Battery-operated nodes 120 are nodes that operate on battery power rather than being wired to an external power source. If a node 120 does not belong to any other specified class (e.g., critical or battery-operated), the node 120 may be considered a normal node 120.

[0016] In some embodiments, the PAN coordinator 115 of PAN110 maintains node data regarding nodes 120 in PAN110. For example, when a node 120 joins PAN110, the new parent of the nodes within PAN110 sends information regarding the node 120 to the PAN coordinator 115. For example, that information may be routed to the PAN coordinator 115 via the connected node 120 for each pair of PAN110. When the node 120 leaves PAN110, 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 PAN110 and their relationships to each other. Accordingly, the node data may include a mesh tree indicating the relationships between the parents and child nodes 120 of PAN110.

[0017] In the embodiment 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. As shown by the lines connecting node 120 in FIG. 1, a given node 120 is directly connected in pairs to other nodes 120 within the shared PAN. For example, the connectivity between two nodes 120 in PAN 110 is due to the fact that the wireless signal strength of each such node is sufficient for the two nodes 120 to be able to communicate directly with each other. Thus, such two nodes 120 are considered neighboring nodes 120. In the embodiment of FIG. 1, node A-5 is directly connected to nodes A-4 and A-6, and thus is a neighboring node 120 to each of nodes A-4 and A-6, also called a neighbor. Specifically, nodes A-5 and A-4 are neighboring nodes 120 to each other, and nodes A-5 and A-6 are also neighboring nodes 120 to each other. More generally, with respect to a given node 120, a neighboring node 120 may be a node 120 that shares the PAN 110 with the given node 120, and the given node 120 and the neighboring node 120 can receive transmission signals from each other.

[0018] In some embodiments, a given node 120 is the parent or child of another node 120. Generally, when the first and second nodes 120 are in the vicinity and communication 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, is transmitted via the first node 120, the first node 120 is considered 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 the embodiment of FIG. 1, node B-1 is the PAN coordinator 115 of PAN B and the parent node 120 for node B-2, and thus it is the child node 120 for node B-1. Similarly, node A-6 is the child node 120 for node A-5, which is the child node 120 for node A-4, which is the child node 120 for node A-1, which is the PAN coordinator 115 of PAN A. As will be described in detail later, these relationships among the nodes 120 of the PAN 110 can play a given role in the migration between PANs 110.

[0019] According to some embodiments, migration may include the target node 120 leaving the first PAN 110 and joining the second PAN 110. The second PAN 110 is also referred to as the destination PAN 110. There are various techniques for enabling the target node 120 to join a PAN 110 such as the destination PAN 110, and one or more of such techniques may be used in the embodiments described in the present application. For example, to join a PAN 110, the target node listens for beacons 140. The beacon 140 is a management packet that is distributed throughout the wireless mesh network 100 for management purposes such as maintaining channel synchronization among the wireless devices of multiple nodes 120. In some embodiments, when the target node 120 receives a beacon 140 from a PAN 110, the target node 120 starts the joining process by sending a joining request. This may include advertising itself to the node 120 that is the source of the beacon 140 received by the target node 120. The target node 120 may then perform an association process by authenticating itself to other nodes 120 and providing information about itself to other nodes 120. The other nodes 120 then transmit the provided information to the PAN coordinator 115, which stores the information in its node data. In some embodiments, upon completion of these tasks, the target node 120 becomes part of the PAN 110. Other techniques for joining a PAN 110 are also possible and are within the scope of the present disclosure.

[0020] As described above, the target node 120 of the wireless mesh network 100 can perform migration from the first PAN 110, which is its current PAN 110 at the start of migration, to the second PAN 110. In some embodiments, the target node starts migration when it detects 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 target node 120 currently belongs. For example, the instability factor may be a numerical value calculated by the target node 120 that determines whether to perform migration. In that case, if the first instability factor of the first PAN differs from the second instability factor of the second PAN by a predetermined margin (e.g., a predetermined value greater than 0), and if the second instability factor indicates improved stability compared to the first PAN 110, the target node 120 may start migration to the second PAN 110.

[0021] Accordingly, to determine whether to perform migration, the target 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: namely, routing cost, link quality, the number of nodes in the PAN 110, and the historical data (e.g., packet success rate) of the PAN 110. For example, the target 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 likelihood of instability, and thus low stability or a low likelihood of stability. In that case, the instability factor may have a positive correlation with the routing cost and the number of nodes 120, and a negative correlation with the link quality and the packet success rate. Alternatively, in other embodiments, if a high instability factor indicates low instability or a low likelihood of instability, and thus high stability or a high likelihood of stability, the instability factor may have a negative correlation with the routing cost and the number of nodes 120, and a positive correlation with the link quality and the packet success rate. Various embodiments are possible and are within the scope of the present disclosure. Throughout the entirety of the present disclosure, it is assumed that a high instability factor indicates high instability and thus low stability, but it will be understood that the opposite may also be true.

[0022] There are various techniques and metrics for measuring and representing routing cost, link quality, and the number of nodes 120 in the technology, and one or more of such technical metrics may be used. For example, the routing cost may be defined as the number of hops to reach a particular other node in the PAN 110, such as the PAN coordinator 115, may be defined as the average number of hops to reach other nodes in the PAN 110, or may be defined as the latency when sending a message to the PAN coordinator 115 and receiving a response back from the PAN coordinator 115. For example, the link quality may be defined as the strongest signal strength (e.g., expressed in decibels) of the nodes 120 in the PAN 110 that are neighboring nodes 120 to the target node 120, or the link quality may be defined as the average signal strength with respect to such neighboring nodes 120. In some embodiments, the PAN coordinator 115 may maintain node data regarding the nodes 120 in the PAN 110 and also provide the number of nodes 120 in the PAN 110 to the target node 120. For example, the PAN coordinator 115 provides this information to the target node 120 on demand or periodically, such as by including it in the beacon 140.

[0023] As an addition to or an alternative to what has been described above, when determining the instability factor for PAN 110, the target node 120 may consider the historical data regarding that PAN 110. For example, the historical data may be the packet success rate within PAN 110. There are various techniques in the art for determining the packet success rate, and one or more of such techniques may be used. In some embodiments, the target node 120 may maintain in its local storage the historical data describing the packet success of the communications in which the target node 120 is involved. For example, for each data packet transmitted by the target node 120 for which an expected positive response is not received, the target node 120 may consider it a failure, and for each data packet transmitted by the target node 120 for which an expected positive response is received, the target node 120 may consider it a success. The target node 120 may maintain information indicating such successes and failures for the purpose of calculating the instability factor so as to determine the packet success rate.

[0024] In some embodiments, even after migration between PANs 110, when the target node 120 determines the instability factor of a PAN 110 other than the one to which the target node 120 currently belongs, the target node 120 may maintain information indicating the packet success rate regarding one or more PANs 110 to which the target node 120 no longer belongs so as to utilize the packet success rate thereof. Additionally or alternatively, in some embodiments, neighboring nodes 120 from other PANs having signals reachable by the target node 120 may communicate information indicating their own packet success rates (e.g., in their beacons 140). This may provide the target node 120 with additional historical data to be used when calculating the instability factor of a PAN 110 other than the one to which the target node 120 currently belongs.

[0025] In some embodiments, the target 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 packet success rate. Specifically, for example, the target node 120 may calculate the instability factor I according to the following formula.

[0026] [Number]

[0027] Here, C, L, N, and R are the routing cost, link quality, the number of nodes in the PAN 110, and the packet success rate in the PAN 110, respectively, and α, β, γ, and δ are the respective weights for the routing cost, link quality, the number of nodes in the PAN 110, and the packet success rate. The target node 120 may maintain each value of the weights internally for use as needed. In some embodiments, the weights may be determined and adjusted as needed based on the importance assigned (e.g., by an administrator) to each factor of the instability factor. In some embodiments, the value of each weight may be based on the classification of the target node 120 (e.g., battery operation, important, or normal). In some embodiments, the value of the weights is fixed for a given PAN 110, but additionally or alternatively, the value of each weight may vary for each node 120 or for each PAN 110.

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

[0029] In some cases, the constant migration of nodes 120 between PANs 110 in the wireless mesh network 100 can lead to overall instability. Thus, in some embodiments, the target node 120 starts migration only after the migration criteria are met. The migration criteria may be considered satisfied when (a) a predetermined waiting period has elapsed since the last migration of the target node, and (b) the second instability factor of a second PAN 110 other than the current PAN 110 of the target node is sufficiently better (e.g., lower) by at least a predetermined margin than the first instability factor of the current PAN 110 of the target node. Thus, in some embodiments, after its last migration between PANs 110, the target node 120 does not migrate between PANs 110 during the waiting period (e.g., one day). After migration, the target node 120 may stay in its new PAN 110 for at least a time equal to the waiting period. After the waiting period, the target node 120 may calculate each instability factor for one or more other PANs 110 that are the source of the beacons 140 received by the target node 120 due to being within the signal reach. For each such instability factor calculated for a different PAN 110, the target node 120 may determine whether to start migration by comparing the instability factor to the instability factor calculated for the current PAN 110.

[0030] In some embodiments, when the target node 120 receives a migration request from its child node 120, the target node 120 modifies its migration criteria. For example, the migration request is a request from the child node 120 for the target node 120 to migrate such that the child node 120 can migrate with the target node 120 while maintaining the target node 120 as its parent. 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 a predetermined criterion may request the migration of the parent node 120, and the request may cause the migration criteria of the parent node 120 to be modified. For example, if a node 120 that is an important node 120 or a battery-operated node 120 has only one neighborhood that will become its parent node 120, and if the node 120 calculates an instability factor for the current PAN 110 that meets an instability threshold (e.g., is greater than or equal to an insufficient instability threshold), the node 120 may send a request to its parent to migrate to another PAN 110. In some embodiments, the instability threshold may vary based on the classification of the node 120.

[0031] When receiving such a request, the parent node 120 may modify its migration criteria regarding selecting the destination PAN 110 for migration. For example, the parent node 120 may end the waiting period, thereby enabling earlier migration, and the parent node 120 may also change (e.g., reduce) its margin used to determine whether the instability factor of another PAN indicates a level with a sufficiently improved stability. These changes to the migration criteria may enable the parent node 120 to select a destination PAN 110 that might not otherwise be considered sufficiently stable as a migration destination. After discovering and selecting the destination PAN 110, the parent node 120 may notify the child node 120 about the PAN identifier (ID) of the destination PAN 110. The child node 120 may then perform appropriate operations to migrate to the destination PAN 110 together with the parent node 120. For example, the child node 120 may move to the destination PAN 110 using the hard migration mode or the soft migration mode.

[0032] When determining to perform a migration (i.e., when the migration criteria are met), regardless of whether the migration is instructed by a request from the child node 120, the target node 120 may select a migration mode to be used during the migration. In some embodiments, the target node 120 may have two or more migration modes such as the hard migration mode and the soft migration mode, or the target node 120 may have only one migration mode or others. Generally, the hard migration mode may result in a more abrupt switch between PANs 110 compared to the soft migration mode. Details about each migration mode will be described in detail later in this disclosure.

[0033] Examples of Selecting between Migration Modes and Migration Modes FIG. 2 is a flowchart of a method 200 for determining whether to perform migration and, if so, selecting a migration mode, according to some embodiments described in the present application. The method 200 shown in FIG. 2 may be implemented in software, hardware, or a combination of software and hardware. The method 200 shown in FIG. 2 and described below is intended to be exemplary and non-limiting. FIG. 2 shows various processing operations performed in a particular sequence or order, but this is not intended to be limiting. In certain alternative embodiments, the processing may be executed in a different order, or operations may be excluded or added, or some operations may be executed in parallel. In some embodiments, the target node 120 performs this method 200 or something similar when determining whether to perform migration between the PANs 110 and how to do so.

[0034] As shown in FIG. 2, in block 205, the target node 120, which is part of the first PAN 110, waits for the end of the waiting period. Here, the waiting period started when the target node 120 joined the first PAN 110 via migration or otherwise. During this waiting period, the target node 120 does not need to calculate its instability factor or the instability factors of the other PANs 110. In some embodiments, if the target node 120 receives a beacon 140 from another PAN 110 during the waiting period, the target node 120 does not need to use the information in that beacon 140 to calculate the instability factor of the other PAN 110. For the purpose of PAN migration, the target node 120 may ignore the beacon 140. However, as described above, if the target node receives a migration request from the child node 120, the waiting period may end early, or rather, be shortened to a zero period.

[0035] Finally, the waiting period ends. For example, the waiting period may end due to the entire original duration of the waiting period having elapsed, or the waiting period may end due to the target node 120 receiving a migration request from a child node 120. After the waiting period, at block 210, the target node 120 considers beacons from other PANs 110 for potential migration.

[0036] At block 215, the target node 120 receives a beacon 140 from another PAN 110 other than the first PAN 110. At block 220, the target node 120 calculates the instability factor of the other PAN 110 based on the information in the beacon 140 and, in some embodiments, based on information maintained by the target node 120 itself. For example, the target node 120 calculates the instability factor of the other PAN 110 as a function of the route cost of the other PAN 110, the link quality between the target node 120 and the node 120 that is the source of the received beacon 140, the number of nodes 120 in the other PAN 110, and the packet success rate of the other PAN 110. In some embodiments, the route cost and the number of nodes 120 may be included in the beacon 140, and the target node 120 may determine the link quality based on the signal strength of the signal of the node 120 that is the source of the received beacon 140. As described above, the packet success rate may be based on data maintained by the target node 120, or based on data included in the beacon 140, or otherwise received from the node 120 that is the source of the received beacon 140.

[0037] In block 225, the target node 120 calculates a first instability factor for the first PAN 110 which is the PAN 110 to which the target node 120 currently belongs. For example, as described above, the target node 120 calculates the first instability factor of the first PAN 110 as a function of the root cost of the first PAN 110 maintained by the target node 120, the link quality between the target 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 packet success rate of the first PAN 110. Although this block 225 is shown as being performed after block 220 in FIG. 2, the target node 120 may calculate the instability factor of the first PAN 110 at various times in this method 200. For example, the target node 120 may calculate the first instability factor each time it receives a beacon 140 regarding the first PAN 110, or the target node 120 may calculate the first instability factor when a waiting period has elapsed. Additionally or alternatively, the target node 120 may calculate the first instability factor each time the target node 120 calculates an instability factor for another PAN 110 considered as the destination PAN 110.

[0038] In decision block 230, the target node 120 determines whether the instability factor for the other PAN 110 calculated in block 225 is sufficiently better than the first instability factor calculated in block 220. As described above, the instability factor of the other PAN 110 may be considered to be sufficiently better than the first instability factor if the instability factor of the other PAN 110 is at least a predetermined margin lower than the first instability factor.

[0039] If the instability factors of other PAN110s are not sufficiently better than the first instability factor, method 200 returns to block 210 and listens for additional beacons 140 from PAN110s other than the first PAN110. Since the instability factors of PAN110s can change over time, the target node 120 may later reconsider the PAN110s that have already been regarded as the destination PAN110, and the target node 120 may, additionally or alternatively, consider PAN110s that have not yet been considered. However, in decision block 230, if the instability factors of other PAN110s are considered to be sufficiently better than the first instability factor, method 200 proceeds to decision block 235, where it may determine a migration mode for migrating to another PAN110 that will be the destination PAN110.

[0040] In some embodiments, the migration mode is based on one or more of the following. The node classification of the target node 120, the first instability factor of the first PAN110, or whether a beacon 140 has been received recently (e.g., within a predefined short time range) from the neighboring nodes 120 of the destination PAN110. The following are non-limiting examples of techniques used to select a migration mode.

[0041] In decision block 235, the target node 120 determines its own classification (e.g., critical, battery-operated, or normal). In some embodiments, each node 120 is programmed with information indicating its classification, and thus the target node may simply check this information to determine its classification. If the target node 120 is battery-operated, in block 240, the target node 120 initiates migration using the hard migration mode. However, if the target node 120 is critical, in block 245, the target node 120 initiates migration using the soft migration mode. If the target node 120 is normal, method 200 proceeds to decision block 250.

[0042] In decision block 250, the target node 120 determines that it is a normal node 120, and the target node 120 further determines whether its network stability is high or low. If a high instability factor indicates a lack of stability, this may be regarded as equivalent to determining whether the first instability factor is lower or higher than the mode threshold. If the stability of the first PAN 110 is low (for example, if the first instability factor is higher than the mode threshold), in block 255, the target node 120 starts the migration using the hard migration mode. However, if the stability of the first PAN 110 is high (for example, if the first instability factor is lower than the mode threshold), in decision block 260, the target node 120 determines whether it has received a beacon 140 regarding the destination PAN 110 from the neighboring node 120 in the destination PAN 110. Receiving the beacon 140 from the neighboring node 120 is information indicating the existing trust between the target node 120 and the devices within the destination PAN 110. If the beacon 140 is received, in block 265, the target node 120 starts the migration using the hard migration mode. Otherwise, in block 270, the target node 120 starts the migration using the soft migration mode.

[0043] As described above, the target node 120 may be capable of hard migration (i.e., using the hard migration mode), soft migration (i.e., using the soft migration mode), or both. For example, a node 120 that is a battery-operated node 120 may be capable of only hard migration, a node 120 that is an important node 120 may be capable of only the soft migration mode, and a node 120 in the normal mode may be capable of both hard and soft migration, and thus may select between the two modes when performing the migration.

[0044] Example of Hard Migration As described above, in some embodiments, the hard migration mode is more abrupt than the soft migration mode. Specifically, in some respects, the target node 120 for migrating 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 conserve the resources of the target node 120, but as a result, for a short period of time, the target node 120 will not be a full participant in any of the PANs 110 in the wireless mesh network 100. In contrast, soft migration may include a gradual shift in which the target node 120 can participate in both the first PAN 110 and the second PAN 110 for a short period of time in some respects, facilitating continuous or nearly continuous connectivity. Hard migration may be beneficial for battery-operated nodes 120 that need to conserve energy, and may also be beneficial for normal nodes 120 that detect particularly low stability in the first PAN 110, such that there is little benefit in remaining in the first PAN 110 during the gradual shift.

[0045] In some embodiments, hard migration includes a notification period. To initiate a hard migration from the first PAN 110 to the second PAN 110, the target node 120 may broadcast a migration notification message indicating the expiration time for that notification period. For example, the expiration time may be indicated as a timestamp, or as a timeout related to the time when the migration notification message is sent. The expiration time may define when the target node 120 starts its actual departure from the first PAN 110 and sends a join request to the second PAN 110. During the notification period, the target node 120 may consider objections to its choice to perform the migration.

[0046] In some embodiments, the migration notification message notifies neighboring nodes 120 including child node 120 about the decision to perform migration by the target node. Due to this notification, child node 120 and other neighboring nodes 120 may determine how to respond to a potential migration. For example, child node 120 of target node 120 may start searching for a new parent node 120 in the first PAN 110 or a different PAN 110. Additionally or alternatively, each node 120 may maintain a neighbor list that identifies its neighboring nodes, and in response to receiving a migration notification message, neighboring nodes 120 of target node 120 may begin to update their respective neighbor lists to exclude target node 120.

[0047] In some embodiments, based on one or more of such predetermined reasons for such objections, and if such objections are, in fact, a request for target node 120 to remain in the first PAN 110, neighboring nodes 120 may object to the migration of target node 120. As an example, if child node 120 of target node 120 cannot reach (i.e., via a wireless signal) any potential new parent node 120 in the first PAN 110 or another PAN 110, child node 120 may object to the migration. As another example, child node 120 may object to the migration if child node 120 is an important node 120, or if child node 120 is involved in an important task, such as when child node 120 is in the middle of a firmware download. Here, if child node 120 is required to discover a new parent, the firmware download needs to be restarted, or packets of the firmware download are lost. If child node 120 objects to the migration, child node 120 may send a negative acknowledgment (NACK) message indicating the objection and its reason to target node 120. However, if child node 120 has no objections, child node 120 may send an affirmative acknowledgment (ACK) message to target node 120, but it is not necessary to send it.

[0048] If the target node 120 does not receive any objections (e.g., represented by a NACK message) from neighboring nodes 120 before the expiration time, the target node 120 may proceed with hard migration as described below. However, if the target node 120 receives one or more objections, the target node 120 may decide whether to terminate the hard migration. In some embodiments, the target node 120 applies a set of rules for deciding whether to terminate the hard migration based on the received objections. The rules may encode a set of priorities for the nodes. For example, if the target node 120 receives an objection from a child node 120 that cannot find a new parent node 120 in the first PAN 110 or another PAN 110, the target node 120 may terminate the hard migration before actually leaving the first PAN 110 or joining the second PAN 110. In that case, the lack of another suitable parent for the child node 120 takes precedence over the improved stability that the target node 120 would experience through migration. Additionally or alternatively, if the target node 120 receives objections from a predetermined percentage (e.g., 75%) of its child nodes 120, the target node 120 may terminate the hard migration before leaving the first PAN 110 or joining the second PAN 110. In that case, the high objection rate is assigned a higher priority than the improved stability that the target node 120 would experience through migration. If the target node 120 terminates the hard migration, soft migration may still be optional as described below.

[0049] However, if the target node 120 is facing maximum packet drops, such as when the instability factor of the first PAN110 is higher than the mode threshold, the target node 120 may decide to proceed with hard migration regardless of the objections. In that case, regardless of the reason for the objections, the target node 120 may not be able to reliably provide communication routing or other services to its neighboring nodes 120 within the first PAN110. In that case, the high risk of packet drops in the current state takes precedence over objections from other nodes 120. Thus, ending the migration offers no substantial benefits, and therefore, the target node 120 may proceed with hard migration.

[0050] If the target node 120 terminates the hard migration due to one or more objections received from neighboring nodes 120, the target node 120 may send an end notification message to each neighboring node 120 that objected to the migration. For example, the target node 120 may send a unicast message to each such neighboring node 120 indicating that the hard migration has been terminated, or the target node 120 may broadcast a message notifying the neighboring nodes 120 that the hard migration has been terminated.

[0051] Examples of Soft Migration In some embodiments, soft migration is more gradual than hard migration in that the activities associated with detaching from the first PAN110 and joining the second PAN110 start at an earlier point in the migration process. At a given point in time, the target node 120 that is to be migrated from the first PAN110 to the second PAN110 via soft migration may be associated with both the first PAN110 and the second PAN110 in some respects and perhaps participating in both. In contrast to hard migration, soft migration can ensure that the target node 120 remains connected to other nodes 120 in the wireless mesh network 100 throughout the migration process. Soft migration can be particularly beneficial in cases where (a) the target node 120 is a critical node 120 operating as such, or (b) the target node 120 is the parent of one or more critical nodes 120 or a target node 120 that is executing a critical task such as a firmware download. Soft migration can also potentially result in smoother execution of services to or from normal nodes 120 during soft migration and can also be beneficial to normal nodes 120 when the first PAN110 has a high stability (e.g., a low instability factor) as there is no need to conserve power as in the case of battery-operated nodes 120.

[0052] In some embodiments, the soft migration includes a notification period. This notification period may be shorter than, but not necessarily so, the notification period used during hard migration. To initiate a soft migration from the first PAN 110 to the second PAN 110, the target node 120 may broadcast a migration notification message indicating the expiration time for its notification period. For example, the expiration time may be indicated as a timestamp or a timeout length. The expiration time may define when the target node 120 stops providing services (e.g., communication routing) for the first PAN 110 and removes the neighboring node 120 in the first PAN 110 from its neighborhood list. During the notification period, the target node 120 may consider objections to its choice to perform the migration from the first PAN 110 to the second PAN 110.

[0053] In some embodiments, the migration notification message notifies neighboring nodes 120, including child nodes 120, about the decision of the target node to perform a migration. Due to this notification, the child nodes 120 and other neighboring nodes 120 may decide how to respond to the potential migration. For example, a child node 120 of the target node 120 may start searching for a new parent node 120 in the first PAN 110 or a different PAN 110. Additionally or alternatively, neighboring nodes 120 may begin to update their respective neighborhood lists of their neighboring nodes 120 to exclude the target node 120.

[0054] In some embodiments, such an objection may be based on one or more of a set of predetermined reasons, and such an objection may be, in fact, a requirement for the target node 120 to remain in the first PAN 110. In this case, the neighboring node 120 may oppose the migration of the target node 120. As an example, if the child node 120 of the target node 120 cannot reach (e.g., by a wireless signal) a potential new parent node 120 in the first PAN 110 or another PAN 110, the child node 120 may oppose the migration. As another example, if the child node 120 is an important node 120, or if the child node 120 is involved in an important task, such as when the child node 120 is in the middle of a firmware download, the child node 120 may oppose the migration. When the child node 120 opposes the migration, the child node 120 may send a NACK message indicating the opposition and the reason to the target node 120. If the child node 120 has no objection, the child node 120 may send an ACK message to the target node 120, but it is not necessary to send it. In some embodiments, the possible reasons for opposition may be the same as or similar to those used during the hard migration described above.

[0055] In some embodiments, the target node 120 also sends a coordinator notification message indicating an expiration time to the PAN coordinator of the first PAN 110. In contrast, during hard migration, there is no need to send a notification message to the PAN coordinator 115. During the notification period, the PAN coordinator 115 may determine the effect that the migration of the target node 120 has on the PAN 110. As described above, the PAN coordinator 115 may maintain information indicating the mesh tree of the node 120 in the PAN 110. Thus, the PAN coordinator 115 may check the position of the target node 120 within the mesh tree and identify the subtree having the target node 120 as its root. During the notification period, the PAN coordinator 115 may send a subtree notification message to the node 120 in that subtree. The nodes 120 in the subtree may be the direct and indirect child nodes 120 of the target node 120 and thus may be affected by the migration of the target node leaving the first PAN 110. Without the subtree notification message, some of these nodes 120 that are not neighboring nodes 120 of the target node 120 may be left without migration-related information and may later be affected by communication delays if the migration is completed. However, as a result of the subtree notification message, these nodes 120 may start searching for a new parent node 120 within the first PAN 110 or in another PAN 110 of the wireless mesh network 100.

[0056] As an addition or alternative to the above, the PAN coordinator 115 may oppose the migration of the target node 120, and such opposition is substantially a request for the target 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 losing the target node 120 will have a negative impact on the stability of the PAN 110. For example, such a decision by the PAN coordinator may be made when the PAN coordinator 115 determines that one or more critical nodes 120 no longer have a reliable communication path to the PAN coordinator 115 without the associated target node 120. As another example, the PAN coordinator 115 may calculate the current instability factor for the first PAN 110 and the expected instability factor for the first PAN 110 without the target node 120. If the expected instability factor indicates a reduced stability compared to the current instability factor, or if the expected instability factor meets (e.g., is higher than) a threshold value, the PAN coordinator 115 may conclude that the migration of the target node 120 will have a negative impact on the stability of the first PAN 110. If the PAN coordinator 115 determines that the migration will actually have a negative impact on the stability of the first PAN 110, the PAN coordinator 115 may oppose the migration by sending a coordinator NACK message to the target node 120. The coordinator NACK message may indicate the reason why the PAN coordinator opposes the migration.

[0057] In some embodiments, the target node 120 determines whether to proceed with migration on its own. To make this decision, the target node 120 may apply a set of rules to the current situation of the target node, including, for example, a first instability factor or any received objections. For example, if the target node 120 receives an objection from a child node 120 that cannot find a new parent node 120, the target node 120 may terminate the soft migration. Additionally or alternatively, if the target node 120 receives objections for other reasons, such as being an important node 120 or being involved in an important task, from a predetermined percentage (e.g., 50%) of the child nodes, the target node 120 may terminate the soft migration. Additionally or alternatively, if the target node 120 receives a coordinator NACK message from the PAN coordinator 115, the target node 120 may give significant weight to that coordinator NACK message and, for example, delay or terminate the soft migration.

[0058] However, if the target node is facing maximum packet drops, such as when the instability factor of the first PAN 110 is higher than the mode threshold, the target node 120 may decide to proceed with the soft migration regardless of the objections. In that case, regardless of the reason for the objections, the target node 120 may not be able to reliably provide communication routing or other services to its neighboring nodes 120 within the first PAN 110.

[0059] If the target node 120 chooses to end the soft migration, the target node 120 may send a coordinator end notification message to the PAN coordinator 115. Additionally or alternatively, the target node 120 may send an end notification message to each neighboring node 120 that opposed the migration. For example, the target node 120 may send a unicast message indicating that the soft migration has ended to each such neighboring node 120. In some embodiments, when ending the soft migration, if the target node 120 has already started its joining process, the target node 120 may end the joining process of joining the second PAN 110, and the target node 120 may, in anticipation of the migration, remove information indicating any node 120 in the second PAN 110 that has already been added to its neighbor list. After ending the soft migration, the PAN 110 may defer further migration attempts for, for example, a predetermined period of time.

[0060] In some embodiments, the messages transmitted between the target node 120 and the neighboring nodes 120 to facilitate hard or soft migration are MAC (Media Access Control) layer messages. For example, the messages transmitted 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 end message, and a message from a child node 120 requesting the migration of the parent. Table 1 below shows an exemplary format of the MAC layer messages that can be used for each of such messages between neighboring nodes 120 as described in the present application.

[0061]

Table 1

[0062] In some embodiments, when the MAC layer message is a migration notification message, bits 0 to 2 of octet 1 of the MAC layer message are set to values other than 000. Also, when the MAC layer message is an end notification message, the value of octet 1 is 000. Table 2 below shows examples of the meanings of various possible values of the bits in octet 1.

[0063]

Table 2

[0064] In some embodiments, the following additional notations 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 to 5. Bit 4 of octet 1 is a boolean variable indicating whether the reason flag in octet 6 is valid. Bit 5 indicates whether bit 6 is valid, and if so, bit 6 is a boolean variable indicating whether the MAC layer message is an ACK message or a NACK message. Bit 7 may be reserved for future use or used for some other purpose. In some embodiments, when bit 5 is not set, octets 2 to 3 are valid, and in that case, octets 2 to 3 indicate the expiration time of the notification period. Octets 4 to 5 may be used to notify the child node 120 about the PAN ID of the destination PAN110, and octets 4 to 5 may also be used to respond to the child node 120 that requested the migration so as to notify the child node 120 of the destination PAN110. Octet 6 may be used for the reason flag to indicate the reason for opposing the migration by the neighboring node 120.

[0065] In some embodiments, the MAC layer messages between the target node 120 and its PAN coordinator 115, or between other nodes 120 and the PAN coordinator 115, may take 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 end notification message. Table 3 below shows an exemplary format of these MAC layer messages.

[0066]

Table 3

[0067] 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 for the target node 120. Bits 5-7 of octet 1 are reserved or used for some other purpose. Octets 2-8 may indicate the address of the target node 120. In some embodiments, either a short address or a long address may be used. For example, if the wireless mesh network 100 is large enough such that the use of a long address may be required to ensure the uniqueness of the address, a long address may be used.

[0068] Exemplary method for performing hard migration Figure 3 is a flowchart of a method 300 for performing hard migration according to some embodiments described in the present application. The method 300 shown in Figure 3 may be implemented as software executed by one or more processors of a computer system, or implemented in hardware, or implemented in a combination of software and hardware. The method 300 shown in Figure 3 and described below is intended to be exemplary and non-limiting. Figure 3 shows various processing operations performed in a particular sequence or order, but this is not intended to be limiting. In certain alternative embodiments, the processing may be performed in a different order, or operations may be excluded or added, or some operations may be performed in parallel. In some embodiments, the target node 120 may execute the method 300 of Figure 3, or a similar method, in response to determining to perform migration to the destination PAN 110 by hard migration.

[0069] Before the start of this method 300, the target node 120 selects the destination PAN 110 that is the destination for migration from the first PAN 110, and also the target node 120 selects hard migration as the migration mode for this particular migration. As shown in Figure 3, in block 305, the target node 120 notifies the neighboring nodes 120 about the migration, for example, by broadcasting a migration notification message. In some embodiments, the migration notification message indicates an expiration time for the notification period. Further, in some embodiments, the target node 120 has not yet started leaving the first PAN 110 or joining the destination PAN 110.

[0070] In block 310, after being notified about the migration, each neighboring node 120 of the target node 120 determines whether it has a reason to oppose the migration of the target node 120. For example, each neighboring node 120 may have a predefined set of reasons, which, if applicable, enable the neighboring node 120 to oppose the migration. If one of such reasons is true, the neighboring node 120 opposes the migration by sending a negative response message indicating the reason for opposition to the target node.

[0071] Accordingly, in block 315, the target node 120 receives the objections sent by its neighboring nodes 120 if any. In decision block 320, the target node 120 determines whether to continue or terminate the hard migration. This decision may be based on the received objections, or more specifically, on the reasons indicated regarding such objections. Specifically, for example, the target node 120 determines whether to terminate the migration by applying a set of rules (i.e., conditions) to the objections.

[0072] If the target node 120 decides to terminate the hard migration, in block 325, the target node 120 may instead attempt a soft migration to the destination PAN 110. In that case, the target node 120 may execute the method 400 shown in FIG. 4 or something similar to perform the soft migration. However, if the target node 120 decides to continue the hard migration, in block 330 of method 300, the target node 120 stops providing services (e.g., communication routing) to the first PAN 110 and stops advertising the beacon 140 of the first node 120. In block 335, the target node 120 sends a join request to the nodes 120 of the destination PAN 110 to start joining the destination PAN 110.

[0073] Exemplary Method for Performing Soft Migration FIG. 4 is a flowchart of a method 400 for performing soft migration according to some embodiments described in the present application. The method 400 shown in FIG. 4 may be implemented as software executed by one or more processors of a computer system, implemented in hardware, or implemented in a combination of software and hardware. The method 400 shown in FIG. 4 and described below is intended to be exemplary and non-limiting. FIG. 4 shows various processing operations performed in a particular sequence or order, but this is not intended to be limiting. In certain alternative embodiments, the processing may be performed in a different order, or operations may be excluded or added, or some operations may be performed in parallel. In some embodiments, the target node 120 may execute the method 400 of FIG. 4, or a similar method, in response to determining to perform migration to the destination PAN 110 by soft migration.

[0074] Before the start of this method 300, the target node 120 selects a destination PAN 110 that is the destination for performing migration from the first PAN 110, and the target node 120 also selects soft migration as the migration mode for this particular migration. In some embodiments, soft migration may be selected after a failed hard migration, but alternatively, the target node 120 may initially determine that soft migration is appropriate instead of hard migration.

[0075] As shown in FIG. 4, in block 405, the target node 120 notifies neighboring nodes 120 about the migration, for example, by broadcasting a migration notification message. In some embodiments, the migration notification message indicates the expiration time of the notification period. In block 410, without waiting for the expiration time to arrive, the target node 120 stops transmitting beacons 140 and other management packets in the first PAN 110, and the target node 120 also sends an association request to the destination PAN 110, which starts the process of associating with the destination PAN 110. However, the target node 120 may continue to provide services to the first PAN 110, for example, by routing communications to its direct and indirect child nodes 120. In this regard, the target node 120 is transitioning between the first PAN 110 and the destination PAN 110, but does not need to be a full participant in either. However, in some embodiments, various activities that cause the target node 120 to end the soft migration may still occur during the soft migration.

[0076] Although not shown as a block in FIG. 4, if the process of associating with the destination PAN 110 fails at any point in method 400 for the soft migration, the soft migration fails as a whole, and thus the target node 120 may end the soft migration. When ending the soft migration, the target node 120 may resume transmitting beacons 140 and other management packets in the first PAN 110, and the target node 120 may also remove any nodes 120 that were added to the list during the soft migration from the destination PAN 110 from its list of neighboring nodes 120.

[0077] In block 415, after being notified about the migration, each neighboring node 120 of the target node 120 determines whether it has a reason to oppose the migration. For example, each neighboring node 120 may have a predefined set of reasons which, if applicable, enable the neighboring node 120 to oppose the migration. If one of such reasons is true, the neighboring node 120 may oppose the migration by sending a NACK message indicating the reason for opposition to the target node 120.

[0078] In block 420, the target node 120 receives the objections, if any, raised by its neighboring nodes 120. In decision block 425, the target node 120 determines whether to continue or terminate the soft migration. This decision may be based on the received objections, or more specifically, on the reasons indicated with respect to such objections. In some embodiments, for example, the target node 120 applies a set of rules (i.e., conditions) to the objections to determine whether to continue or terminate the soft migration. If the target node 120 decides to terminate the soft migration, in block 430, the target node 120 may (1) resume advertising the beacon 140 of the first PAN 110, end the joining process to join the destination PAN 110, and remove the information indicating any node 120 in the second PAN 110 that was already added to its neighbor list in anticipation of the migration. In some embodiments, after terminating the soft migration, the PAN 110 may delay further attempts at migration, for example, for a predefined period of time.

[0079] When the target node 120 decides to continue the soft migration, at block 435, the target node 120 notifies the PAN coordinator 115 of the first PAN 110 about the migration, for example, 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 target node 120 about the migration, for example, by sending a subtree notification message to each direct and indirect child node 120 of the target node 120, to ensure that these nodes 120 are aware of the potential migration. This enables such nodes 120 to search for each new parent node 120 if necessary. In some embodiments, the direct and indirect child nodes 120 may reply with a NACK message to the PAN coordinator 115 if applicable. Additionally or alternatively, at block 445, the PAN coordinator 115 determines whether to oppose the migration. For example, if the PAN coordinator 115 determines that the stability of the first PAN 110 is negatively affected by the target node 120 leaving the first PAN 110, the PAN coordinator 115 may oppose the migration. This decision may be notified, for example, by any NACK message received by the PAN coordinator 115 or by the PAN coordinator's own analysis of the mesh tree of the PAN 110.

[0080] In block 450, the PAN coordinator 115 transmits to the target node 120 information indicating an affirmative response or an objection in the form of a negative response. For example, if the PAN coordinator 115 has no reason to oppose the migration (e.g., if there is no substantial negative impact on PAN stability), the PAN coordinator 115 may send a coordinator ACK message to the target node 120. The coordinator ACK message may have a format similar to that shown in Table 3 above. In that case, the PAN coordinator 115 may represent the lack of such objection 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 target node 120 to the PAN coordinator 115. However, if the PAN coordinator 115 determines that there is a reason to oppose the migration, the PAN coordinator 115 may send a coordinator NACK message to the target node 120. Similar to the coordinator ACK message, the coordinator NACK message may take the form of the MAC layer message 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 target node 120 in the coordinator notification message, thereby indicating a negative response.

[0081] In decision block 455, when the target node 120 receives feedback from the PAN coordinator 115 (e.g., either a coordinator ACK message or a coordinator NACK message), the target node 120 determines whether to end, delay, or continue the soft migration. In some embodiments, the PAN coordinator 115 has the ability to control the nodes 120 of the PAN 110, including the target node 120. Thus, the PAN coordinator 115 may be able to stop or delay the migration, and in such embodiments, the target node 120 follows any such request from the PAN coordinator 115. Additionally or alternatively, the target node 120 may apply a set of rules to the feedback from the PAN coordinator 115. If the PAN coordinator sends a NACK message indicating a temporary reason (e.g., one or more indirect child nodes 120 are not critical nodes 120 but are in the middle of performing a critical task such as a firmware download), in block 460, the target node 120 may delay the completion of the soft migration. In that case, the target node 120 may continue the soft migration after an additional waiting period has elapsed. During this additional period, the target node 120 may resume transmitting the beacon 140 for the first PAN 110 and may or may not end the joining to the destination PAN 110. In that case, the target node 120 may stop transmitting the beacon 140 again and, after the additional waiting period, may start the joining to the destination PAN 110. However, if the reason the PAN coordinator opposes is not necessarily temporary (e.g., when a critical node 120 loses communication with the PAN coordinator 115 due to migration, or when the target node 120 has multiple battery-operated nodes 120 as children), the target node 120 may end the soft migration, for example, in block 430 of the illustrated method 400.

[0082] However, if the PAN coordinator 115 does not oppose the migration, in block 465, the target node 120 completes the soft migration. For this purpose, the target node 120 completes the authentication and association regarding the destination PAN 110 and stops the execution of services for the first PAN 110.

[0083] Exemplary computing system operating as a node FIG. 5 is a diagram of an embodiment of a computing system 500 operating as a node 120 in a wireless mesh network 100 according to some embodiments described in the present application. For example, the computing system 500 may operate as the target node 120, the PAN coordinator 115, or any other node 120 in the wireless mesh network 100. The computing system 500 may be a general-purpose computing device or a dedicated-purpose computing device such as a supply and demand meter or a gateway. The computing system 500 according to the illustrated embodiment includes a processor 502 communicatively connected 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 ASIC (application-specific integrated circuit), an FPGA (field-programmable gate array), or other suitable processing devices. The processor 502 may include one or more processing devices.

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

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

[0086] 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 by one or more input / output (I / O) interfaces 508. The computing system 500 also includes one or more buses 506. The bus 506 communicatively connects one or more components of the computing system 500.

[0087] An example of the computing system 500 includes a network interface device 510, such as a wireless device. The network interface device 510 includes one or more devices suitable for establishing a wired or wireless data connection to other computing devices in the wireless mesh network 100. Non-limiting examples of the network interface device 510 include an Ethernet (registered trademark) network adapter, a WiFi (registered trademark) (Wireless Fidelity) device, an NFC (Near-Field Communication) device, a Wi-SUN (Wireless Smart Utility Network) device, a radio frequency (RF) device, a ZigBee (registered trademark) device, or some other communication device. Using the network interface device 510, the computing system 500 may communicate with other nodes of the wireless mesh network 100 and thus may perform the operations described herein.

[0088] Overall Consideration In order to provide a detailed understanding of the subject matter recited in the claims, numerous specific details are set forth in this specification. However, one of ordinary skill in the art will understand that the subject matter recited in the claims may be practiced without these specific details. In other instances, well-known methods, devices, or systems known to those of ordinary skill in the art have not been described in detail so as not to obscure the subject matter recited in the claims.

[0089] The features described in this application are not limited to any particular hardware architecture or configuration. A computing device may include any suitable device consisting of components that provide results conditional on one or more inputs. A suitable computing device includes a computer system based on a general-purpose microprocessor that accesses stored software (i.e., computer-readable instructions stored on the memory of a computer system), and this software programs or configures the computing system so that it becomes a special computing device that implements one or more aspects of the subject matter of this application from a general-purpose computing device. In the software used to program or configure the computing device, any suitable programming, scripting, other type of language, or combination of languages may be used to implement the disclosure contained in this application.

[0090] Aspects of the methods disclosed in this application may be executed in the operation of such a computing device. The order of the blocks presented in the above embodiments may be changed, for example, the blocks may be rearranged, combined, and / or divided into sub-blocks. A plurality of predetermined blocks or a plurality of processes may be executed in parallel.

[0091] The use of "adapted to" or "configured to" in this application is intended to be an open and inclusive term that does not exclude a device adapted or configured to perform additional tasks or steps. Further, the use of "based on" is intended to be open and inclusive in that a process, step, calculation, or other operation "based on" one or more described conditions or values may in fact be based on additional conditions or values beyond those described. The headings, lists, and numbers included in this application are for the sole purpose of simplifying the description and are not intended to be limiting.

[0092] While the subject matter of the present application has been described in detail with respect to its specific embodiments, those skilled in the art will recognize that, by understanding what has been described above, such modifications, variations, and equivalents of such embodiments can be readily made. Accordingly, it should be understood that the present disclosure is presented for purposes of illustration and not limitation, and does not exclude including such modifications, variations, and / or additions related to the subject matter of the present application, as will be readily apparent to those skilled in the art.

Claims

1. A node connected to a first personal area network (PAN) receives packets from a second PAN other than the first PAN, based on the packets, determines that at least a margin of a second instability factor related to the stability of the second PAN is different from a first instability factor related to the stability of the first PAN, sends a migration notification message indicating that the node is performing migration to neighboring nodes in the first PAN, receives a request from a neighboring node in the first PAN for the node to stay in the first PAN, applies, by the node, one or more rules for rejecting the request for the node to stay in the first PAN to the request, and completes migration to the second PAN based on rejecting the request, a method.

2. The migration notification message indicates a notification period during which the node accepts a request from a neighboring node for the node to stay in the first PAN, and the method further includes the node sending a join request to the second PAN after expiration of the notification period. The method according to claim 1.

3. The migration notification message indicates a notification period during which the node accepts a request from a neighboring node for the node to stay in the first PAN, and the method further includes the node sending a request to join the second PAN before expiration of the notification period. The method according to claim 1.

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

5. Selecting between the first migration mode and the second migration mode for the migration is based on the first instability factor. The method according to claim 4.

6. Based on the above node being classified as a node operating on battery power, the above node selects the above first migration mode for the above migration. The method according to claim 4. **Claim 7** Based on the above node being classified as a critical node, the above node selects the above second migration mode for the above migration. The method according to claim 6. **Claim 8** As a result of the above node being unable to complete the above migration in the above first migration mode, the above node selects the above second migration mode. The method according to claim 4. **Claim 9** Further comprising calculating the above first instability factor based on the success rate of history packets in the above first PAN. The method according to claim 1. **Claim 10** The above method further comprises the above node sending a notification of migration to the PAN coordinator of the above first PAN, and the above node receiving, from the above PAN coordinator, a request for the above node to terminate the above migration. The method according to claim 1. **Claim 11** Determining that the above second instability factor differs from the above first instability factor by at least the above margin based on the above packet comprises the above node receiving a migration request from a child node of the above node, reducing the above margin based on the above migration request to obtain an updated margin, and determining that the above second instability factor differs from the above first instability factor by at least the above updated margin. The method according to claim 1. **Claim 12** A system comprising a target node connected to a first personal area network (PAN) of a wireless mesh network and neighboring nodes of the above node, wherein the above target node identifies a destination PAN as a migration target, and is configured to send a notification to one or more neighboring nodes that the above target node is performing a migration to the above destination PAN, the above neighboring nodes being connected to the above first PAN, and the above neighboring nodes receiving the above notification from the above target node, and determining a reason for opposing the migration of the above target node, the reason being selected from a predefined set of reasons. configured to send a request to end the migration to the target node, wherein the target node is further configured to leave the first PAN and join a destination PAN based on prioritizing an expected improvement in stability due to the migration over a reason associated with a request from the neighboring node, a system. **Claim 13** wherein the target node delays the migration based on an additional request from a PAN coordinator of the first PAN, The system according to claim 12. **Claim 14** wherein, to identify the destination PAN as a target of the migration, the target node calculates a first instability factor of the first PAN based on a routing cost, a link quality, a number of nodes in the first PAN, and a packet success rate of the first PAN, and is further configured to determine that a second instability factor differs from the first instability factor by at least a margin, The system according to claim 12. **Claim 15** wherein the target node is configured to perform the migration using a first migration mode, wherein the node is configured to perform the migration using a second migration mode, and the node selects between the first migration mode and the second migration mode based on at least one of a classification of the target node and a value of the first instability factor, The system according to claim 14. **Claim 16** wherein, to determine that the second instability factor differs from the first instability factor by at least the margin, the target node receives a migration request from a child node of the node, reduces the margin based on the migration request to an updated margin, and is further configured to determine that the second instability factor differs from the first instability factor by at least the updated margin, The system according to claim 14. **Claim 17** A computing device connected to a first personal area network (PAN) of a wireless mesh network, wherein the computing device comprises a processor configured to execute computer-readable instructions, A memory configured to store computer-readable instructions that, when executed by the processor, cause the processor to perform operations including the following operations, and The operations are Receiving a packet from a second PAN other than the first PAN; Based on the packet, determining that a second instability factor related to the stability of the second PAN is different by at least a margin from a first instability factor related to the stability of the first PAN; Sending a migration notification message indicating that the computing device is performing migration to a neighboring node in the first PAN; Receiving, from a neighboring node in the first PAN, a request for the computing device to stay in the first PAN; Applying to the request one or more rules for rejecting the request for the computing device to stay in the first PAN; Completing migration to the second PAN based on rejecting the request. A computing device.

18. The migration notification message indicates a notification period during which the computing device accepts, from a neighboring node, a request to stay in the first PAN, The operations further include sending a joining request to the second PAN after the expiration of the notification period. The computing device according to claim 17.

19. The migration notification message indicates a notification period during which the computing device accepts, from a neighboring node, a request to stay in the first PAN, The operations further include sending a request to join the second PAN before the expiration of the notification period. The computing device according to claim 17.

20. Determining that the second instability factor is different by at least the margin from the first instability factor based on the packet includes Receiving a migration request from a child node of the computing device; Reducing a threshold difference based on the migration request; Determining that the second instability factor is different by at least the threshold difference from the first instability factor. The computing device according to claim 17.

Images