BLE Node Failure Detection and Route Switching

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for handling node failure in Bluetooth Low Energy (BLE) networks are energy and resource intensive, particularly concerning for battery-powered nodes and large, dense networks where network updates can be time-consuming.

Innovation Solution

A method that detects failed nodes, switches to alternative paths, updates hop counts, and broadcasts information packets to neighboring nodes to recalculates and invalidate routes using failed nodes, ensuring efficient data delivery and reducing energy consumption.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If current methods for handling node failure are used, then network self-healing capability is maintained, but energy consumption and resource usage increase significantly

Engineering Contradiction:
Improvenetwork self-healing capabilityVSAvoidenergy consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent applies preliminary action by pre-calculating and storing alternative routes before node failure occurs. When a node fails, the pre-computed alternative routes are immediately activated without requiring real-time recalculation, thus maintaining network self-healing capability while minimizing energy consumption and resource usage.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If network updates are performed frequently to maintain up-to-date information, then network robustness improves, but time consumption and resource overhead increase

Engineering Contradiction:
Improvenetwork robustnessVSAvoidtime consumption
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements periodic action by updating network information only when necessary - specifically when node failures are detected. Instead of continuous or frequent updates, the system performs targeted updates at intervals triggered by actual events, maintaining network robustness while reducing time consumption and resource overhead associated with unnecessary updates.

Inventive Principle:
Principle #19Periodic action

3Speed

If alternative routes are pre-calculated for all possible failures, then response time to node failure improves, but network complexity and memory requirements increase

Engineering Contradiction:
Improveresponse timeVSAvoidnetwork complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The patent applies local quality by calculating and storing alternative routes only for locally relevant scenarios - specifically for failures of one-hop neighboring nodes. Instead of pre-calculating all possible failure scenarios across the entire network, each node maintains alternative route information only for its immediate neighborhood, reducing network complexity and memory requirements while still achieving fast response times for local failures.

Inventive Principle:
Principle #3Local quality

Data Source

PatentEP3813311B1On-demand table and route update after a node failure in a wireless network
Publication Date: 2023.08.30 CARRIER CORP
  • EP3813311B1 patent drawingFigure 1~2
  • EP3813311B1 patent drawingFigure 3~4
  • EP3813311B1 patent drawingFigure 5

AI summary

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, the hop count of the third node, wherein the third node is the next hop on the second path; generating an information packet at the first node, 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 neighbouring nodes (N1, N3, N6) of the first node; storing, at each of the one-hop neighbouring nodes that receives the information packet, the unique ID of the failed node (N1) and the hop count of the first node; recalculating, at each of the one-hop neighbouring nodes that receives the information packet, the hop count, wherein if the hop count at a one-hop neighbouring node is recalculated to be different from the hop count prior to receiving the information packet the one-hop neighbouring node generates a second information packet comprising the new hop count of the one-hop neighbouring node and broadcasts the second information packet to one or more of its own one-hop neighbouring nodes.