Source-linked AI summary
Deconstructing BLE Multi-hop: a Model-based Approach to Quantifying the Challenges
Bozheng Pang, José Alamos, Thomas C. Schmidt, Matthias Wählisch
TL;DR
Clock drift’s impact on BLE multi-hop performance is not fully understood, despite prior empirical reports of the problem. This paper models collision probabilities among connections managed by one device and validates its models experimentally. It finds that drift’s impact persists in most cases and that collisions recur at a fixed frequency over the long term.
Problem
The impact of clock drift on BLE multi-hop performance is not fully understood, although prior work identified drift as a performance problem in a specific deployment.
Source: §I · p. 1Method
The paper develops a mathematical model of collisions among BLE connections managed by a single device and validates the model and its simplification through experiments.
Source: §I · p. 1Results
A BLE multi-hop network cannot eliminate clock drift’s impact in most cases, and drift-caused collisions occur at a fixed frequency over the long term.
Source: §I · p. 1Takeaways & Limitations
Current BLE standards are unsuitable for efficient multi-hop networks, and parameter fine-tuning is insufficient to address collision issues.
Source: §IX · p. 10
Abstract
from arXiv · showhide
Bluetooth Low Energy (BLE) was originally designed for point-to-point communication, but BLE multi-hop networks have attracted academic and industrial interest. Multi-hop communication, however, introduces desynchronized nodes to the network due to the difference in individual clocks. In this paper, we study the impact of clock drift on a BLE multi-hop network. The aim is to find out if a BLE multi-hop network can be properly set up, why, and how. For this goal, we develop a mathematical model to quantify the collision probability among BLE connections managed by a single device. We provide a simplified version of the model for constrained deployment. The impact of clock drift and our mathematical model are validated through practical experiments. Afterward, we find that a BLE multi-hop network cannot eliminate the impact of clock drift in most cases. Moreover, from a long-term point of view, the collision between BLE connections occurs with a fixed frequency. We further analyze the limitation of using BLE to form multi-hop networks, and propose possible solutions, such as topology limitation, changes to BLE stack or hardware. This paper is a clear and quantitative problem statement on the limitations of using BLE in multi-hop networks.
I. INTRODUCTION
BLE’s point-to-point design and strict timing requirements complicate flexible multi-hop deployments when commodity-device clock drift desynchronizes schedules. The paper addresses this gap with a deployment-independent collision model and a simplified version for constrained devices.
I. INTRODUCTION
- BLE was designed for point-to-point communication, yet its broad use in IoT deployments makes it a candidate for network access.Source: §I · p. 1
- Multi-hop topologies can multiplex connections, but time-triggered BLE requires parallel schedules that hardware imperfections and clock drift make difficult to guarantee.Source: §I · p. 1
- Prior work identified drift empirically and proposed artificial drift acceleration for a specific deployment; this paper contributes a deployment-independent theoretical model and a lower-complexity version for constrained devices.The simplified model is reported to reduce computational complexity without significant errors.Source: §I · p. 1
A. Basic Knowledge
- A BLE connection uses recurring intervals and anchor points, with the peripheral calibrating its schedule to the central’s benchmark schedule [10].Each interval contains a connection event, and the central and peripheral must follow the shared schedule strictly.Source: A. Basic Knowledge · p. 2
B. Challenge in Multi-hop
Multiple central schedules can create collisions when a device participates in multiple BLE connections. The paper develops a model to quantify that risk and offers a simplified version for constrained deployments.
B. Challenge in Multi-hop
- With multiple centrals, a device must manage multiple schedules, creating potential collisions for devices involved in multiple connections.Source: B. Challenge in Multi-hop · p. 2
- When one peripheral calibrates to two central schedules, their differences can make its anchor points drift over time and cause connection-event collisions.The passage describes a typical setup with equal default connection intervals.Source: B. Challenge in Multi-hop · p. 2, Figure 1 · p. 2
III. MATHEMATICAL MODEL
- The mathematical model quantifies collision probability across multiple connections managed by one BLE device, extending from a simple topology to more complex cases.A graphical method is also introduced to make the model easier to understand.Source: §III · p. 2
- The simplified model is intended to avoid impractical computational complexity when implemented on constrained IoT devices.Source: §III · p. 2
- The model calculates collision probabilities for the two connections separately because equal collision counts can yield different probabilities when their interval values differ.Source: §III · p. 2, Figure 2 · p. 2
A. Overlap Probability
The section defines a collision probability from overlapping connection events and derives how to calculate it across possible anchor-point combinations. The calculation uses periodic anchor ranges and treats connection intervals and event lengths as static.
A. Overlap Probability
- Collision probability is the ratio of overlapped connection events to total connection events.An overlap occurs when one connection event ends later than the other event’s anchor point.Source: A. Overlap Probability · p. 2
- Two connection events overlap when x2 < x1 + CE1 and x1 < x2 + CE2, where x1 and x2 are anchor points and CE1 and CE2 are event lengths.Source: A. Overlap Probability · pp. 2–3
- Anchor points x1 and x2 need only range over [0, CI1] and [0, CI2], since their periodicity makes combinations outside those ranges redundant.Source: A. Overlap Probability · p. 3
- A double integral of an indicator for the overlap condition counts possible overlap cases as x1 and x2 vary over their ranges.The indicator is 1 when x1 − x2 lies between −CE1 and CE2, and 0 otherwise.Source: A. Overlap Probability · p. 3
- Connection intervals and event lengths are treated as static variables, although event lengths depend on the application.Source: A. Overlap Probability · p. 3
- For CI1 < CI2, Equation 4 calculates connection 1’s overlap probability by comparing overlap cases with all possible anchor-point combinations; equal intervals are excluded.The paper excludes CI1 = CI2 because it causes connection shading, as empirically shown in prior work.Source: A. Overlap Probability · p. 3
B. Collision Probability
The model uses anchor-point geometry to quantify overlap and collision probabilities between two BLE connections. It treats the two connections separately, extending the calculation for the connection with the larger interval to capture additional overlaps.
B. Collision Probability
- The red-area fraction of an anchor-point plot gives the overlap probability: each point represents a pair of initial anchor points, and the red region marks overlap.The plot uses x1 and x2 over the ranges [0, CI1] and [0, CI2]; the area ratio gives an accurate probability, while sampling estimates it with Monte Carlo.Source: B. Collision Probability · pp. 3–4
- Adding connection intervals generates the anchor-point combinations; their pattern repeats after the least common multiple of the intervals.With intervals of 50 ms and 120 ms, the repetition period is 600 ms, producing 12 points for connection 1.Source: B. Collision Probability · p. 4
- For connection 1, the overlap probability also gives its collision probability because all possible starting points produce uniformly distributed anchor-point combinations.The model finds the collision probability by taking the red-area fraction of the whole plot.Source: B. Collision Probability · p. 4
- For the connection with the larger interval, Figure 5 adds red regions to capture overlaps that Figure 4 misses.An interval of 120 ms accommodates 2.4 intervals of 50 ms, so a pair with no overlap in Figure 4 can still overlap later.Source: B. Collision Probability · p. 4, Figure 5 · p. 4
- The model calculates collision probability for both connections; Equation 5 scales Equation 4 by CI2/CI1 for connection 2.The two probabilities describe how frequently each connection collides with the other.Source: B. Collision Probability · p. 4
C. Multiple Connections
For a device managing more than two BLE connections, the model extends its pairwise collision calculations to estimate each connection’s total collision probability. It treats connection establishments as independent.
C. Multiple Connections
- The model extends the pairwise collision calculations to a device managing more than two BLE connections.It applies Equations 4 and 5 between every pair of connections.Source: C. Multiple Connections · p. 4
- For connection i, Pi denotes the probability it experiences at least one collision with another connection.The model obtains this overall probability from the pairwise probabilities Pij.Source: C. Multiple Connections · pp. 4–5
- The model calculates Pi by combining the probabilities of avoiding each pairwise conflict, assuming connections are established independently.The independence assumption reflects the randomness of connection initialization through advertising and scanning.Source: C. Multiple Connections · p. 5
IV. SIMPLIFIED MATHEMATICAL MODEL FOR CONSTRAINED DEPLOYMENT
The simplified model approximates collision probabilities with a lightweight ratio for constrained devices. Its accuracy depends on connection-event lengths, and the long-term probabilities remain the same with or without clock drift.
IV. SIMPLIFIED MATHEMATICAL MODEL FOR CONSTRAINED DEPLOYMENT
- The simplified ratio approximates connection 1’s collision probability using a parallelogram area derived from the two connection-event lengths.The area uses the sum of CE1 and CE2 multiplied by CI1; the authors motivate the approximation as less computationally demanding than integral calculation.Source: §IV · p. 5
- 0.1289 (Equation 4) versus 0.1343 (approximation) for connection 1; the error is 0.0054 with 8.056 ms events and 50 ms and 120 ms intervals.The authors describe this error as negligible for this example.Source: §IV · p. 5
- 0.3093 (connection 2) versus 0.3222 (approximation), with error 0.0129; the larger interval can correspond to greater collision probability and an unstable network.The example uses the same 8.056 ms events and 50 ms and 120 ms intervals.Source: §IV · p. 5
- The approximation extends to more than two connections by substituting approximate pairwise probabilities; over the long term, collision probabilities are the same with or without clock drift.The authors state that environmental factors make clock drift challenging to predict and say this invariance is later validated against simulations.Source: §IV · p. 5
V. ANALYSIS OF CLOCK DRIFT AND IMPACT IN PRACTICE
Before validating the mathematical model, the authors use practical experiments to illustrate clock drift’s impact.
V. ANALYSIS OF CLOCK DRIFT AND IMPACT IN PRACTICE
- Practical experiments illustrate the impact of clock drift before the mathematical model is validated.The passage describes the experiment’s purpose, but gives no experimental findings.Source: §V · p. 5
A. Experiment Setup
The experiments test when clock drift affects BLE multi-hop links across star, two-central, chain, and four-connection setups. Drift-related collisions and connection loss appear when a device is not central for all its connections, and become more frequent with more connections.
A. Experiment Setup
- The setup uses three experiments to compare a star control, two topologies with relative drift, and a five-device case with four connections on one node.All connections use 1M PHY, a 100 ms interval, and 4.028 ms connection events on RIOT running on Adafruit Feather nRF52840 Sense boards.Source: A. Experiment Setup · pp. 5–6
B. Results
- In the three-device star control, the two connections on the central node show no relative drift and no disconnections during the 2-hour experiment.Their anchor-point difference remains around 15 ms, above the 4.028 ms connection-event duration; retransmissions are higher on one node, possibly because of interference or BLE-stack self-conflict.Source: B. Results · p. 6
- When a peripheral manages connections to two centrals, anchor-point gaps vary and collisions at or below 4.028 ms coincide with retransmissions and disconnections.The alternate topology in experiment (2) shows similar results, indicating that changing connection roles or topology does not eliminate the observed impact.Source: B. Results · p. 6
- With four connections on a node, differing drift speeds bring connection events into collision, with more frequent disconnections and sharply increased retransmissions.Reconnection places anchor points at random times, and the experiment reports more disconnections than in the earlier setups.Source: B. Results · p. 7
VI. VERIFICATION OF MATHEMATICAL MODEL
The verification experiments compare measured overlap probabilities with the model’s theoretical and approximated results across two multi-hop topologies and varied connection intervals. They use least-common-multiple tracking to observe relative anchor-point movement when intervals differ.
VI. VERIFICATION OF MATHEMATICAL MODEL
- The verification compares measurements against theory and approximation in two topologies where a device is not central for all its connections.The experiments vary connection intervals and packet counts to test settings beyond the equal-parameter case examined earlier.Source: A. Experiment Setup · p. 7
A. Experiment Setup
- In the two-central scenario, one interval stays at 50 ms while the other varies from 60 ms to 260 ms; each connection event lasts 4.028 ms.Overlap probabilities are measured for each interval combination and compared with the model’s theory and approximation.Source: A. Experiment Setup · p. 7
- In the chain topology, one interval is fixed at 100 ms and the other ranges from 105 ms to 125 ms; each connection event lasts 8.056 ms.Because establishment times are uncontrolled and intervals differ, the experiment tracks relative movement using the least common multiple of the intervals.Source: A. Experiment Setup · pp. 7–8
B. Results
Across two interval-varying scenarios, measured overlap probabilities resemble the model’s theoretical and approximated results, with reported maximum errors around 1%. The paper positions its graphic model as addressing a gap in prior BLE multi-hop work and reports that practical experiments validate its accuracy.
B. Results
- In both scenarios, measured overlap probabilities resemble the theoretical and approximated results, validating the model across different connection parameters.Measurements converge to theory; convergence takes around 1 hour in scenario (1) and around 3 hours in scenario (2).Source: B. Results · p. 8
- The maximum P21 measurement–theory error is around 1% in scenario (1) at a 210 ms interval and around 1% again in scenario (2).Source: B. Results · p. 8
VII. RELATED WORK
- Earlier BLE multi-hop clock-drift work was empirical; this paper introduces a mathematical model intended to cover general deployment cases.The related-work discussion identifies Petersen et al. as the first to report the impact of clock drift in BLE multi-hop networks.Source: §VII · p. 8
- The paper frames BLE multi-hop limitations as a periodic pulse-train problem and proposes a graphic method to simplify the mathematical procedure.It reports that practical experiments validate the model and that the simplification does not impact its accuracy.Source: §VII · p. 9
VIII. DISCUSSION
Collision avoidance depends on topology and scheduling control: a central-managed star can avoid collisions, while other topologies require additional mechanisms or changes to BLE standards or hardware. Reducing collisions through connection-parameter changes also trades off throughput, scalability, flexibility, or latency.
VIII. DISCUSSION
- Reducing collision risk by shortening connection events, reducing connections per device, or increasing connection intervals sacrifices throughput, scalability and flexibility, or latency.The collision probability depends on connection events, connection intervals, and the number of connections on each device.Source: §VIII · p. 9
A. Can a BLE Multi-hop Network Avoid Collision?
- A central-managed star is the only topology that can manage multiple BLE connections without collisions, because its connections share a schedule with zero relative drift.The device managing the connections must be the central.Source: A. Can a BLE Multi-hop Network Avoid… · p. 9
- Line and tree topologies may achieve little or no collision if devices are peripherals in at most one connection, act as centrals for their other connections, and adjust anchor points.Without these steps and mechanisms, line and tree topologies introduce collisions.Source: A. Can a BLE Multi-hop Network Avoid… · p. 9
- Mesh and fully connected BLE networks cannot avoid collisions without changing the standard or hardware, because peripherals cannot adjust their connection schedules or anchor points.The paper proposes software or hardware changes to mitigate this limitation.Source: A. Can a BLE Multi-hop Network Avoid… · p. 9
- Giving every BLE device control over anchor points could remove the line-or-tree limitation by allowing connection schedules to be adjusted.This would require changing the BLE standard.Source: A. Can a BLE Multi-hop Network Avoid… · p. 10
- Adding transceivers could shift the collision problem from hardware occupation to interference between BLE connections; the paper notes that interference can still reduce reliability.The authors also suggest full-duplex wireless communication as a further reliability improvement.Source: A. Can a BLE Multi-hop Network Avoid… · p. 10
B. Can a BLE Multi-hop Network Manage Its Collision Frequency?
For static connection setups, collision frequency is fixed, and interval constraints can reduce some collision patterns but limit the number of connections a device can properly manage. The conclusion proposes topology, protocol, and hardware changes, with implementation and Wi-Fi-interference evaluation left for future work.
B. Can a BLE Multi-hop Network Manage Its Collision Frequency?
- For static connection setups, collision frequency is fixed, so BLE designers should constrain parameters to prevent short-term continuous or long-term high-frequency collisions.The paper identifies three potential constraints on connection intervals.Source: B. Can a BLE Multi-hop Network Manage… · p. 10
- Connection intervals too close together relative to long connection events can cause 10 to 20 continuous collisions once two connections begin to collide.The paper recommends choosing interval values with connection-event lengths in mind.Source: B. Can a BLE Multi-hop Network Manage… · p. 10
- A small least common multiple between two connection intervals can produce recurring collisions; mutually prime intervals or a large least common multiple can avoid long-term high-frequency collisions.The paper gives 80 ms and 120 ms as an impracticable pair with a least common multiple of 240 ms.Source: B. Can a BLE Multi-hop Network Manage… · p. 10
- A large difference between two intervals can raise collision probability for the connection with the larger interval, so intervals should stay within a range set by event lengths and collision probability.The lower bound prevents continuous overlaps; the upper bound limits collision probability for connections with large intervals.Source: B. Can a BLE Multi-hop Network Manage… · p. 10
- Current BLE synchronization cannot handle clock drift in multi-hop contexts, and the needed constraints limit the connections a device can properly manage.Knowing the constraints still lets designers determine whether connection settings are feasible.Source: B. Can a BLE Multi-hop Network Manage… · p. 10
IX. CONCLUSIONS AND FUTURE WORK
- The conclusion finds current BLE standards unsuitable for efficient multi-hop networks and proposes topology limits, anchor-point control or encoding mechanisms, and extra transceivers.Parameter tuning may help short-term issues but remains insufficient.Source: §IX · p. 10
- Future work includes implementing proposed protocol and transceiver changes and evaluating BLE multi-hop performance under Wi-Fi interference.Source: §IX · p. 10