(1) SeamBlue is a framework that enables seamless Bluetooth Low Energy (BLE) connection migration for unmodified IoT devices between multiple gateways. (2) It uses static program analysis to automatically identify the state variables needed to capture a snapshot of the BLE connection state, avoiding manual code inspection. (3) Upon a device moving out of range, the current gateway extracts the connection information, disseminates it to candidate gateways, and the new gateway can then recreate the connection state and continue serving the device without disrupting the connection.

1. SeamBlue:
Seamless Bluetooth Low Energy Connection
Migration for Unmodified IoT Devices
Wil Shen
2018/07/17

2. Reference
• “SeamBlue: Seamless Bluetooth Low Energy Connection Migration
for Unmodified IoT Devices”, Proceeding EWSN ’17 Proceedings of
the 2017 International Conference on Embedded Wireless Systems
and Networks, Pages 132-143, February 20 – 22, 2017

3. Outline
• Introduction of connection migration
• SeamBlue Framework
– Workflow
– Design Details
• Evaluation
• Conclusion

4. Introduction of connection migration -
Usage Scenario
Hospitals:
1. Patients can be localized and tracked
2. Physiological signals (HR) can be monitored
using a network of gateways deployed
3. Continuous monitoring and uninterrupted
services by connecting to nearby gateways.
Theme Parks:
1. Parents can monitor and locate their missing kids
via their mobile phone.
2. A passport for just about everything in the park.
3. Store credit card information to facilitate
transactions.
Magical Wristband

5. Seamless BLE Connectivity architecture

6. Challenges to BLE Connection Migration
Unmodified IoT Devices
• billions of IoT devices are already in use  no
changes
• Only change the BLE implementation of the
gateways
Identifying State Variables
• (bad) Manually browsing a large code base (up to
100K lines of code)
• (good) automatically finding
Gateway Selection for Connection
Transfer
• Not all the gateways in a network should be a
receiver of this information.
• A subset of gateways are selected
Secure and Fast Connection Transfer
• An adversary cannot obtain information and
impersonate a legitimate gateway. T
• The connection transfer should be fast enough
so that the services are not disrupted.
• The current gateway may need to establish a
trust relationship with that untrusted gateway

7. The Paper Proposed
A framework ensures seamless communication
• unmodified, BLE-enabled mobile IoT device
• without requiring pairing-bonding and connections to individual gateways.
A systematic approach for identifying connection state
• Static program analysis for BLE code base
• pairing-bonding and connection information
Two approaches for capturing a snapshot of connection state
• full stack cloning
• partial stack cloning
Gateway Selection
• the most suitable gateway for transferring information

8. SeamBlue Overview
A framework ensures seamless communication
A systematic approach for identifying connection state
Two approaches for capturing a snapshot of connection state
Gateway Selection

9. Step 1 - Performs static analysis on BLE source code and the
identified set of variables (that are required for connection transfers)

10. Manual Static Code Analysis?
• Cost 80+ man-hours.
• Connection States = program variables and objects
 are spread over different layers of BLE stack.
s1
s2
s3
s4
s5

11. Automatic Static Code Analysis
• Converted BLE code to intermediate representation (IR) using LLVM compiler
• build complete call graph
• Direct function call - build the control flow graph (CFG) from the IR
• Indirect function call - Use points-to analysis to find the all possible targets of any
indirect call in the program.

12. Automatic Static Code Analysis
The LLVM Compiler Infrastructure
• 非常模組化的編譯器
LLVM IR
C program

13. Control-flow graph (CFG)

14. Automatic Static Code Analysis
Packet Reception – from recv packet() to accept payload() call
• Functions in call chain - context and field sensitive inter-procedural points to analysis
• The set of basic blocks containing accept_payload() – intra-procedural post-
dominance frontier (PDF)
• Extract path constraints (branch instructions) from block
• Variables associated with path constraints  connection state variable

15. Dominance Frontier
• Node 5’s dominated region
is shown in grey
• Edges 6 -> 4; 8 -> 5; 8 -> 13;
and 7 -> 12 crossed the
border
•  Nodes 4, 5, 12, 13 form
the dominance frontier of
node 5.
支配節點

16. Automatic Static Code Analysis
accept_payload() -> packet processing functions (gateway generates events)
• Call-graph - To slice the code base into specific portions which process the
packet – points-to analysis
• Identify local/global variables that are defined
• Resolve local-variable aliasing

17. Resultant Set of Connection State Variable

18. BLE Stack Cloning
• Partial Stack Cloning required an additional
connection request for updating Link Layer values

19. Step 2 – the current gateway extracts
a set of pairing-bonding information from the connection
instrument the BLE
implementation to
obtain runtime values

20. Step 3 – disseminates the information
to a set of candidates gateways

21. Disseminates information
• (1) Pairing and bonding with
gateway A
• (2) gateway A shares pairing-
bonding information with the
gateways B, C, D, and E.

22. Step 4 – add the IoT device as a bonded(?) device.
but do not
initiate a connection

23. if two devices want to exchange data securely
• Pairing process - two devices exchange their identity information to
set up the trust and then establish the encryption keys for future
data exchange.
– By Security Manager Protocol (SMP)
• Identity Resolving key (IRK), 128bit
• Connection Signature Resolving Key (CSRK), 128bit
• Long Term Key (LTK), 128bit
• Encrypted Diversifier (EDIV), 16bit
• Random Number (RAND), 64bit
• Bonding process: storing the keys created during pairing for use in
subsequent connections in order to form a trusted device pair.

24. Step 5 – Perceiving the device moves out of it range

25. Ping-pong effect.
to estimate the
moving direction
(a) Subsequent gateway selection and
connection transfer as the user with
device moves from gateway A to D.
(b) Gateways selection and ping-pong
effect.
Common region
SeamBlue –
(1) Motion Predication
(2) Delay tolerant approach

26. Step 6 – identifies and transfers the snapshot

27. Step 7 – creates required objects related to connection, stores
information into NONVOL
the peripheral seamlessly connected to the subsequent gateway

28. Evaluation
• 1. Success rate of BLE connection migration is
measured
– Ping-pong effect is evaluated.
• 2. Overhead of SeamBlue

29. Experimental Setup - device
x5

30. Experimental Setup - Testbed
• Hanging Nexus 5 as IoT
gateways
• Any physical space is shared
by at most two gateways.
• some areas fall within the
ranges of more than two
gateways.

31. Experimental Setup - Applications
• BLE peripherals - nRF Connect
application
– Periodically sends packet of size
20bytes every second
• Gateways – a custom application
for Heart Rate monitoring service

32. Evaluation Result 1 –
BLE Connection Migration Success Rate
• 100% in our testbed - we found every connection
migration request successful when IoT devices are
both static and moving at different speeds

33. Ping-Pong Effect
• Connection Switch Times: 2X rate with the number of common
regions.
• SeamBlue – with motion predication  reduce half times

34. Evaluation Result 2 – Migration Cost
Extra bytes required for connection migration
• Both sends 512bytes for bonding
• Full stack cloning sends 2048 bytes
Time required for adding a peripheral as a bonded device
• Requires the gateway to load the device information from NVRAM
Time required for transferring state variables
• to transfer the state variables over WiFi.
Time required for connection migration
Packet loss

35. Time required for adding a peripheral as a
bonded device
Higher CPU speed and memory

36. Time Required for Transferring State Variables
the control plane packet losses increases with users mobility, the time
required for all the scenarios increases slightly with the increase of the
users moving speed.

37. Time Required For Connection Migration
(1) extract the values of connection related variables
(2) send this information to the next gateways securely
(3) decrypt the received information
(4) update the connection related state variables.

38. Number of packets lost
• Data packets are sent with 1 second time interval
loss of at most 2 packets

39. Conclusion
• Static analysis module (CFG !!!)
• A gateway selection mechanism (?)
• Reduces both communication overhead and
latency