On-demand tables and route updates after node failure in wireless networks

Abstract

The subject of the invention is "On-demand table and route update after node failure in a wireless network". A method for a network 300 comprising a plurality of nodes, comprising: detecting at a first node (N2) that a second node (N1) is a failed node; recording at the first node that the second node is a failed node and that a first path is unavailable; switching at the first node to a second path, the second path comprising a third node (N6); checking at the first node a hop count of the third node, wherein the third node is a next hop on the second path; generating at the first node an information packet, wherein the information packet comprises a unique ID of the failed node and the hop count of the first node; broadcasting the information packet from the first node (N2) to one or more one-hop neighboring nodes (N1, N3, N6) of the first node; storing at each of the one-hop neighboring nodes that received the information packet the unique ID of the failed node (N1) and the hop count of the first node; re-computing at each of the one-hop neighboring nodes that received the information packet the hop count, wherein if the hop count at a one-hop neighboring node is re-computed to be different from the hop count before receiving the information packet, the one-hop neighboring node generates a second information packet comprising the new hop count of the one-hop neighboring node and broadcasts the second information packet to one or more of its own one-hop neighboring nodes.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to Bluetooth networks, in particular to a method for handling node failure in a Bluetooth Low Energy network. BACKGROUND

[0002] The Low Energy (BLE) specification is a set of standards for a wireless network technology that operates within the 2.4-2.4835 GHz Industrial, Scientific and Medical (ISM) band. In contrast to traditional or "classic" Bluetooth® devices, BLE is designed to significantly reduce power consumption.

[0003] Applications for the BLE specification include healthcare, security, fitness and home entertainment. Within these applications, devices can communicate with other BLE devices in the network using the Bluetooth mesh profile. Each device in the network is able to pass data between other devices in the network, creating a so-called "mesh".

[0004] According to the specification, BLE devices operate across 40 channels in the 2.4 GHz band, each mapped to a set of RF (Radio Frequency) channel index values 0, 1,..., 39. Channels 0 to 36 are used for transmission of data, while channels 37, 38 and 39 are used for transmission of advertising (ADV) events.

[0005] The term "node" as used herein can refer to any device that can have BLE capability. Such devices can include a smartphone, a smart socket, a light bulb, a laptop, a home entertainment device or any other device that can connect to a BLE network. A node can also be able to communicate in other wireless networks, such as a Wi-Fi(RTM) network or a cellular network. A node can also be able to communicate via the Internet through such networks.

[0006] Some networks can be self-healing, meaning that in the event of a node failure in the network, the network is able to bypass the failed node to ensure that data packets can still be delivered to their destination. However, current methods for doing so are energy and resource intensive, which can be of particular concern for networks that include battery-powered nodes or for large and dense networks where network updates can be time-consuming. SUMMARY

[0007] ​From a first aspect, the invention provides a method for a network comprising a plurality of nodes, comprising: detecting, at a first node, that a second node is a faulty node; recording, at the first node, that the second node is a faulty node and that a first path comprising the second node is unavailable; switching, at the first node, to a second path, the second path comprising a third node; checking, at the first node, a hop count of the third node, wherein the third node is a next hop on the second path; generating, at the first node, an information packet, wherein the information packet comprises a unique ID of the faulty node and the hop count of the first node; broadcasting the information packet from the first node to one or more one-hop neighboring nodes of the first node; storing, at each of the one-hop neighboring nodes receiving the information packet, the unique ID of the faulty node and the hop count of the first node; and re-computing, at each of the one-hop neighboring nodes receiving the information packet, the hop count, wherein if the hop count at a one-hop neighboring node is re-computed to be different from the hop count before receiving the information packet, the one-hop neighboring node generates a second information packet comprising a new hop count of the one-hop neighboring node and broadcasts the second information packet to one or more of its own one-hop neighboring nodes.

[0008] The advantage of the invention is to improve the robustness and response time of a wireless network in case of node failure. This method ensures that network information is kept up to date, enabling each node in the network to select a working route through the network to save energy and resources and avoid faulty nodes. This is particularly important in networks where some or all nodes are limited by battery power.

[0009] From a second aspect, the invention provides a Bluetooth Low Energy (BLE) network comprising a plurality of nodes, comprising: a first node; a second node; and one or more neighboring nodes, wherein the neighboring nodes are one hop distance from the first node; wherein the first node is configured to detect that the second node is a faulty node, record that the second node is a faulty node and that a first path is unavailable, switch to a second path, the second path comprising a third node, check a hop count of the third node, wherein the third node is a next hop on the second path, generate an information packet, wherein the information packet comprises a unique ID of the faulty node and the hop count of the first node, and broadcast the information packet to one or more one-hop neighboring nodes; and wherein each of the one-hop neighboring nodes receiving the information packet is configured to store the unique ID of the faulty node and the hop count of the first node, and re-compute the hop count, wherein if the hop count at a one-hop neighboring node is re-computed to be different from the hop count before receiving the information packet, the one-hop neighboring node generates a second information packet comprising a new hop count of the one-hop neighboring node and broadcasts the second information packet to one or more of its own one-hop neighboring nodes.

[0010] Viewed from a third aspect, the present application provides a computer program product comprising instructions which, when executed within a Bluetooth Low Energy network comprising a plurality of nodes, will configure the network to operate in accordance with the method of the first aspect.

[0011] Optional features which can be combined with the method of the first aspect, the network of the second aspect or the computer program product of the third aspect are described below.

[0012] A BLE device can comprise any device which has the ability to communicate with other devices using Bluetooth Low Energy transmissions. Such devices can include smart phones, smart sockets, light bulbs, laptops, access control systems and home entertainment devices. The BLE device can be a member of a BLE network. The BLE network can comprise a head node or gateway, wherein the head node is capable of performing protocol translation to pass data from the BLE network to another network to which the head node is connected. The other network can comprise a cellular network, the Internet, a local intranet and a cloud network.

[0013] In a BLE network, a BLE device which is a member of the network can be referred to as a node. The network can comprise any number of nodes and can be distributed such that the head node is connected to at least one node. Each node in the network can be connected directly to the head node or via at least one other node to the head node. In this way, the head node is capable of communicating with all nodes in the BLE network and vice versa.

[0014] All nodes in the network can be considered to be downstream or downlink with respect to the head node and, conversely, the head node can be considered to be upstream or uplink to the other nodes in the network. The structure of the network can be such that data can travel from the head node and through other intermediate nodes before reaching a destination node. In this way, an intermediate node can be upstream to some nodes and can be downstream to other nodes. Nodes at the edge of the network can be referred to as end nodes. Data transmitted from the head node to an intermediate node or end node can be considered to travel downstream or downlink. Data transmitted from an end node or intermediate node in the direction of the head node can be considered to travel upstream or uplink.

[0015] The BLE network can be configured to allow BLE devices to join and leave the network in operation. The skilled person will readily appreciate that the BLE network can be configured to be reconfigured to take account of new devices joining the network or current devices leaving the network. The skilled person will also readily appreciate that the BLE network can be configured to reconfigure itself to take account of changes in the physical location of the BLE devices in the network and / or to optimise the network for efficient data transfer between the devices.

[0016] The distance of any particular node from the head node can be defined by the number of nodes through which data must travel to reach the particular node. For example, a node in direct communication with the head node can be considered to be one "hop" from the head node. Likewise, a first node in communication with the head node via a second node can be considered to be two "hops" from the head node. In this latter case, the second node can be considered to be downstream of the head node and also upstream of the first node. In this way, it is possible to define how many hops away any particular node is from the head node. The number of hops is independent of the physical distance between nodes. A node that is one hop away from a particular node can be referred to as a neighbor of the particular node.

[0017] The hop distance of a particular node can change due to reconfiguration of the network. Such reconfiguration can occur for any number of reasons, including but not limited to: optimization of the network; in response to changes in the number of nodes in the network; and physical movement of nodes in the network.

[0018] The hop distance of a particular node can be stored in the memory of the node as identification data for the node. Other identification data can include the node ID (identification) number or MAC (Media Access Control) address of the node. The node can store identification data for other nodes in the network, such as neighboring nodes. The node ID can be a unique identification of the node.

[0019] The first path of the first node can be part of a longer path from an initial sending node to a destination node, where the sending node can be considered to be the node from which the data packet originates. Alternatively, the sending node can be considered to be any node from which data is sent. The destination node can be considered to be the node to which the data packet is intended to arrive. Alternatively, the destination node can be any node that receives the data packet. The path of the data packet can include a number of hops through a number of nodes to reach the destination node. The node(s) on the path between the sending node and the destination node can be referred to as intermediate nodes. The terms "path" and "route" can be used interchangeably.

[0020] Typically, the path between the sending node and the destination node can require as few intermediate nodes as possible, and can even require no intermediate nodes at all. From any one node in the network, there can be multiple paths for sending data along to reach the destination node. The node will typically select a path based on the lowest hop count, but can also determine which path to use by considering other parameters, such as: RSSI (Received Signal Strength Indication); battery power of the node; workload and traffic congestion in the network as a whole or in the local neighborhood of the node; or whether the next node in the path is part of a subnetwork and whether that subnetwork is the same subnetwork as the current node is in.

[0021] Nodes in the network can extract information from the routing table. The routing table contains information about the network topology. Nodes can extract information from the routing table, such as node IDs or routing paths for data delivery.

[0022] The on-demand table update method can be more clearly defined as comprising: generating an information packet; broadcasting the information packet from the first node to one-hop neighboring nodes of the first node; and re-computing a hop count at each of the one-hop neighboring nodes that received the information packet, wherein if the hop count at a one-hop neighboring node is re-computed to be different from the hop count before receiving the information packet, the one-hop neighboring node triggers an on-demand table update.

[0023] The purpose of the on-demand table update can be to inform one-hop neighbors of a particular node about changes that have occurred in the network. The update can be triggered by one of the following conditions: if the first node discovers a faulty node, or if the first node re-computes its hop count and the new hop count is different from the previous hop count. One or both of these conditions can trigger the on-demand table update.

[0024] A faulty node can be discovered when a sending node attempts to send a data packet along a route to a node and finds that the delivery is unsuccessful. Thus, if the delivery of a data packet is unsuccessful due to a faulty node, an on-demand update is triggered. The discovery of a faulty node can comprise the sending node declaring that, to its knowledge, the next hop in the path along which it is sending data packets has failed since the sending node was unable to establish any connection with the faulty node for a certain period of time.

[0025] When the first node triggers the on-demand table update, it generates a broadcast information packet. The information packet can comprise the hop distance of the first node and the node IDs of any faulty nodes that have been discovered. The first node then sends the information packet to each of its one-hop neighbors. Upon receiving the information packet, the second node updates the hop distance of the first node from which the packet was sent and re-computes its own hop distance. If the hop distance of the second node has changed, the on-demand table update is triggered recursively and the second node generates and broadcasts a new broadcast information packet. In addition, the second node can store the IDs of any faulty nodes and check if any of the faulty nodes is a one-hop neighbor of the second node. If so, the second node is configured to invalidate routes that use the neighboring faulty node, such that those routes are not selected for future data packet delivery.

[0026] The broadcast information packets can have a lower priority than the data packets that trigger the on-demand update, and thus the information packets can be sent after the data packets or potential failure notification packets. This is because the network is configured to deliver the data packets to their final destination as quickly as possible. Furthermore, if additional node failures are discovered, the node is able to include new information about the failed node ID and its re-computed hop count in one information packet, rather than generating and sending multiple information packets for each node failure encountered.

[0027] The potential failure notification packets can be part of a possible multi-path failure recovery method. The potential failure notification packets can be a packet class with a higher priority than the current data packets. The potential failure notification packets can be sent back to the original source of the message in order to inform the source node about the failed node and the inability to perform delivery of the data packets through the current path to the final destination node. Upon receiving the potential failure notification packet, the original source node can then select an alternative path for delivering the data packets to the final destination node.

[0028] The number of one-hop neighbors connected to a particular node can depend on the topology and density of the network. In some cases, this number can be high, and thus the time and energy required to broadcast information packets to each of these nodes in case of an on-demand update can be too resource intensive. In such cases, the node can be configured to perform a ranking of its one-hop neighbors. This ranking can be based on different parameters, such as: hop distance; whether they are members of a subnet within a wider network; and received signal strength indication (RSSI). In this way, the node can rank each of its one-hop neighbors according to one or more of these parameters to determine which nodes are the ones with higher importance in the network. Such importance can be determined according to these parameters and taking into account the data throughput and connectivity of these nodes. It can be imagined that it would be urgent to update the nodes that are most frequently used or in a position in the network with the most connectivity, with information related to the failed node, so that data packets passing through these nodes can avoid delays in reaching their destination. The proposed ranking method aims to find more relevant neighboring nodes for the alternative paths around the failed node, while reducing the information packet broadcast overhead cost. The information packets can then be sent only to a subset of on-hop nodes starting from the highest ranked nodes. A larger number of networks can be updated by a larger subset, but this can also result in higher latency and energy usage for the delivery of the data packets that trigger the network update. The subset size can depend on the level of network update desired, which can take into account the network density, node connectivity, and available data paths.

[0029] The recovery of a failed node can be integrated back into the network through a network reset which serves to refresh all information and all routes of all neighbours of the newly recovered node. Alternatively, the recovered node can follow a join protocol to be re-integrated in the network, for example by informing its neighbours that it is newly available and thus all routes using it as an intermediate node are brought back to normal. Other methods of re-integrating a recovered node are known to the skilled person and can be used depending on the specific parameters of the network.

[0030] In addition to on-demand table updates, the network can also make use of on-demand route update methods to deal with node failures in the network. Whereas on-demand table updates involve updating nodes in the network with the status and information about a specific node, on-demand route update methods instead involve providing updates of the failure routes that data packets can take through the network. The updates can be triggered under specific circumstances or can occur continuously, with the latter being more resource intensive than the former but having the advantage of ensuring that the network is up to date throughout the entire network.

[0031] One condition for triggering an on-demand route update can be the detection of a failed node. When a sending node discovers a failed node during the delivery of a data packet, the link between the sending node and the failed node can be recorded as unavailable at the sending node. The sending node can then check the routing tables of the network to determine whether the link is used by other routes that have been created on both the uplink and downlink. If so, an on-demand route update is triggered.

[0032] The on-demand route update can comprise sending an information packet from the sending node to the original source of the path that includes the link, if the failed link is part of an uplink route, or to the head node if the link is part of a downlink path. When the final node to which the information packet is being sent receives the information packet, the final node invalidates the notified path so that the path containing the failed link is not used in future data deliveries. Any intermediate nodes between the sending node and the final node can also record the path containing the failed link as invalid.

[0033] The information packet in the on-demand route update can have a lower priority than the original data packet, meaning that if two packets are to be sent from the same node, the information packet is sent after the data packet.

[0034] The advantage of using on-demand route updates in conjunction with on-demand table updates is that in the event of a failed node being discovered in the network, the network can be more comprehensively updated. This can allow the network to be more adaptable in response to node failures and able to self-heal to ensure effective and efficient data delivery through the network without the need for external operators to constantly maintain the system. BRIEF DESCRIPTION OF DRAWINGS

[0035] Some embodiments of this disclosure will now be described by way of example only and with reference to the accompanying drawings, in which:

[0036] Figure 1 An exemplary BLE network is shown.

[0037] Figure 2 A pair of BLE devices are shown.

[0038] Figure 3 An exemplary network on which the on-demand table update method of the present invention can be executed is illustrated.

[0039] Figure 4 An exemplary network on which the on-demand routing update method of the present invention can be executed is illustrated.

[0040] Figure 5 A schematic view of a pair of BLE devices is shown. Detailed Implementation

[0041] Figure 1 An example BLE network 100 is shown, where network 100 is depicted as a tree. Head node 102 forms the "root" of network 100, while devices in the BLE network form the "branches" of the network. Some BLE devices are not directly connected to head node 102; instead, they are connected via branch nodes. This means that any transmission sent from head node 102 may have to be passed through another BLE node before reaching its destination node.

[0042] Figure 2 A first node 200 and a second node 202 are shown. The first node 200 and the second node 202 can be any two neighboring nodes in the BLE network 100. Here, the term "neighboring" means that the first node 200 and the second node 202 are configured to communicate directly with each other, rather than through an intermediate node. Each node can determine its position relative to other nodes in the BLE network 100 by storing identification information about its neighbors. Neighboring nodes can be defined as those nodes that are directly connected to nodes in the network 100. The identification information may include hop distance and a unique node ID.

[0043] The on-demand table update method will now be described as acting on, for example, Figure 3The example network 300 comprises a head node NH and a plurality of nodes N1-N8, wherein nodes N1 and N5 are one hop away from the head node NH. Nodes N2 and N6 are two hops away from the head node NH via N1 and N5, respectively, nodes N3 and N7 are three hops away from the head node NH via N2 and N6, respectively, and nodes N4 and N8 are four hops away from the head node NH via N3 and N6, respectively. Furthermore, nodes N2 and N6 are one hop away from each other, as are nodes N3 and N7 and nodes N4 and N8.

[0044] Node N2 wants to send a data packet to the head node NH via path #1. In attempting to do so, N2 finds that node N1 has failed and the data packet cannot be received correctly. At this point, node N2 updates the information for node N1, marking the link N1-N2 as unusable. Node N2 then re-computes its own hop distance and finds that the hop distance has changed from 2 (via N1) to 3 (via N6). Since at least one of the conditions is met, the on-demand table update is triggered, although in this case both conditions are met. Thus, node N2 generates a broadcast information packet and first tries to push the data packet via node N6 through its second path #2, since this data packet has a higher priority. After this delivery is completed, the information packet can be serviced.

[0045] In this example, the network is very small and simple and thus there is no need to use the ranking of the adjacent one-hop nodes and the information packet can be sent to all neighbors (N3 and N6). Upon receiving the information message, nodes N3 and N6 update the hop count distance for node N2 and re-compute their own hop distances. The hop distance of node N6 does not change, since it relies on node N5. On the other hand, node N3 has changed its hop distance from 3 to 4, since the path from node N3 to the head node NH relies on node N2.

[0046] Furthermore, if node N3 has information about all intermediate nodes on the path between node N3 and the head node NH, then node N3 is configured to invalidate this path, since it contains the failed node N1. Node N3 is then configured to select an alternative path to the head node NH that bypasses the failed node N1. This can be repeated at the other nodes that receive the information packet and thus all nodes that receive the information packet will invalidate any paths stored at those nodes that contain the failed node N1.

[0047] The change in hop distance at node N3 triggers an on-demand update at node N3, and node N3 generates another information broadcast packet. This packet is sent to each of node N3's neighbors (nodes N2, N4, and N7). Since nodes N2 and N7 have paths to the head node NH that do not depend on node N3, the hop distance at these nodes does not change. However, the path from node N4 to the head node NH depends on node N3, and so N4 then changes the hop distance from node N4 from 4 to 5. This change in hop distance then triggers an on-demand update at node N4. This process continues until no more hop distance changes occur.

[0048] In addition to on-demand table updates, network 300 can also utilize an on-demand route update method to handle node failures in network 300. While on-demand table updates involve updating nodes in network 300 with status and information about a particular node, the on-demand route update method instead involves providing updates of the failed routes that data packets can take through network 300. Network 300 can use on-demand route updates in place of or in addition to the on-demand table updates described above. Figure 4 The same network 300 as in Figure 3 is shown, and illustrates how on-demand route updates are performed.

[0049] One condition for triggering an on-demand route update is the detection of a failed node. When sending node N2 discovers failed node Nl during the delivery of a data packet, the link between sending node N2 and failed node Nl can be recorded as unusable at sending node Nl. Sending node Nl can then check the routing tables of network 300 to determine if the link is used by other routes that have been created on both the uplink and downlink of sending node N2. If so, an on-demand route update is triggered.

[0050] The on-demand route update includes sending an information packet from sending node Nl to the original source of the path that included the link, if the failed link was part of an uplink route (such as leaf node N4), or to the head node NH if the link was part of a downlink path. When the final node to which the information packet is being sent receives the information packet, the final node invalidates the notified path so that the path containing the failed link is not used in future data deliveries. Any intermediate nodes between the sending node and the final node also record the path containing the failed link as invalid.

[0051] In this example, node N3 also uses the unavailable link N1-N2 in its path #1. Therefore, node N3 will invalidate this path. In future packet delivery, node N3 will use its path #2, which has node N7 as an intermediate node. Node N4 follows the same trend as node N3, because node N4 invalidates its path #1 through node N3, and it will use its path #2 through node N8. For ease of viewing, Figure 4 Node N4's path is not shown in the middle.

[0052] Figure 5 A pair of BLE devices 500, 510 are illustrated that can utilize the methods discussed above. The BLE devices 500, 510 can be any suitable known type of device, and they are modified compared to known devices to operate according to the methods as set forth above. The first BLE device 500 includes a processor 502, a memory unit 504, a radio 506, and an antenna 508. A computer program product for performing the methods described herein can be stored as an application in the memory unit 504. The memory unit 504 can be a hard disk drive, solid state, or optical memory source. The processor 502 is configured to access and execute software, applications, and data stored on the memory unit 504.

[0053] The radio 506 is configured to receive and transmit BLE signals via the antenna 508. The processor 502 is configured to interface with the radio 506, and the application can be configured to control the radio 506 and antenna 508 when executed on the processor 502.

[0054] The second BLE device 510 includes similar hardware and operation as the first BLE device 500. The antenna 508 of the first BLE device 500 is configured to communicate with the antenna 518 of the second BLE device 510.

Claims

1. A method for a network (300) comprising a plurality of nodes, comprising: detecting at a first node (N2) that a second node (N1) is a faulty node; recording at the first node that the second node is a faulty node and that a first path is unavailable; switching at the first node to a second path, the second path comprising a third node (N6); checking at the first node a hop count of the third node, wherein the third node is a next hop on the second path from the first node, and the hop count is a number of hops to a head node (NH); generating at the first node an information packet, wherein the information packet comprises a unique ID of the faulty node and the hop count of the first node; broadcasting the information packet from the first node (N2) to one or more one-hop neighboring nodes (N1, N3, N6) of the first node; storing at each of the one-hop neighboring nodes that receives the information packet the unique ID of the faulty node (N1) and the hop count of the first node; recalculating at each of the one-hop neighboring nodes that receives the information packet a hop count, wherein if the hop count at a one-hop neighboring node is recalculated to be different from the hop count before receiving the information packet, the one-hop neighboring node generates a second information packet comprising a new hop count of the one-hop neighboring node and broadcasts the second information packet to one or more of the one-hop neighboring nodes of the one-hop neighboring node itself.

2. The method of claim 1, wherein the first node attempts to send a data packet from the first node to the second node along the first path, wherein the second node is a faulty node, and the data packet is not successfully sent to the second node.

3. The method of claim 1 or 2, wherein the hop count of the first node is updated if the third node has a hop count that is different from the hop count of the second node.

4. The method of claim 1 or 2, wherein the first node broadcasts the information packet to all of the more one-hop neighboring nodes of the first node.

5. The method of claim 1 or 2, wherein the first node is configured to rank each one-hop neighbor of the first node's one-hop neighbors according to parameters including: hop distance; whether the one-hop neighbor is a member of a subnet within a wider network (300); and a received signal strength indication (RSSI).

6. The method of claim 5, wherein the first node sends the information packet to a subset of the total number of one-hop neighboring nodes starting with the highest ranked one-hop neighboring node.

7. The method of claim 1 or 2, wherein the first node utilizes on-demand route updates, the on-demand route updates comprising: if the faulty link is part of an uplink route, the second information packet is sent from the first node to the original source of the path comprising the link, or if the link is part of a downlink path, to the head node (NH), wherein when the destination node of the second information packet receives the second information packet, the destination node invalidates the notified path, such that the path containing the faulty link is not used for future data delivery.

8. The method of claim 7, wherein any intermediate nodes between the first node and the destination node record the path containing the faulty link as being invalid.

9. The method of claim 7, wherein the second information packet has a lower priority than other data packets.

10. The method of claim 1 or 2, wherein the first path is the path along which data packets travel from a source node to a destination node.

11. The method of claim 10, wherein the first path comprises one or more intermediate nodes.

12. A Bluetooth Low Energy (BLE) network (300) comprising a plurality of nodes, the plurality of nodes comprising: a first node (N2); a second node (N1); and one or more neighboring nodes (N1, N3, N6), wherein the neighboring nodes are one hop distance from the first node; wherein the first node is configured to: detect that the second node (N1) is a faulty node, record that the second node is a faulty node and that a first path is unavailable, switch to a second path, the second path comprising a third node, check a hop count of the third node, wherein the third node is the next hop on the second path from the first node and the hop count is the number of hops to a head node (NH), generate an information packet, wherein the information packet comprises a unique ID of the faulty node and the hop count of the first node, and broadcast the information packet to one or more one hop neighboring nodes; and wherein each of the one hop neighboring nodes (N1, N3, N6) that receive the information packet is configured to store the unique ID of the faulty node and the hop count of the first node, and recalculate the hop count, wherein if the hop count at the one hop neighboring node is recalculated to be different from the hop count before receiving the information packet, the one hop neighboring node generates a second information packet comprising the new hop count of the one hop neighboring node and broadcasts the second information packet to one or more of the one hop neighboring nodes of itself.

13. The Bluetooth Low Energy (BLE) network (300) of claim 12, wherein the network (300) is configured to operate according to the method of any one of claims 1 to 11.

14. A computer program product comprising instructions which, when executed within a Bluetooth Low Energy (BLE) network (300) comprising a plurality of nodes, will configure the network (300) to operate according to the method of any one of claims 1 to 11.

Images