1. Internet of Things
Amr El Mougy
Alaa Gohar

2. Data Collection from Sensor Networks

3. Data Collection from BLE Sensors
BLE sensors are standalone. Data collection has to be done from each sensor individually
Mainly two methods for BLE data collection:
Smartphones (public sensing)
Gateway
Communication is typically one way
Configuration parameters are allowed in the reverse direction

4. Comparison of Gateways and Smartphones
Fixed data collection point  reliable
Reliability depends on the smartphone density
Medium cost
Low cost
Requires an additional device to configure the sensors
Can send configuration commands from the phone
Depending on the type, it can support WiFi, cellular connection, or both
Always supports WiFi and cellular connections
Always participates in the data collection
Participation depends on the user’s willingness
Dedicated for data collection
Data collection competes with other applications
Typically has stable power source
Battery-powered

5. Structure of BLE Gateway
Processor/Application Host
API
BLE
Stack Profiles
TCP/IP
BLE
Physical/Link Layers
Ethernet Stack
Cellular Stack
WiFi Stack

6. Gateway Types Payload Extraction Packet Encapsulation (Data Pipe)
BLE Attribute
WiFi Packet
Handle
UUID
Value
WiFi - H
IP-H
TCP-H
Value
BLE Attribute
Handle
UUID
Value
WiFi Packet
WiFi - H
IP-H
TCP-H
Handle
UUID
Value

7. 6LoBLE: IPv6 over BLE Gateways
Internet Protocol Support Service (IPSS) replaces the GAP protocol
It defines Central/Peripheral roles for gateway and sensors
Applications
IPSS
UDP/TCP
GATT
IPv6
ATT
6LoBLE
Internet
BLE L2CAP
BLE Link Layer
6LN connections
BLE Physical Layer

8. Prefix and Router Discovery
6LoBLE Operations
IPv6 address auto- configuration based on MAC address
Neighbor solicitation/ advertisement support address registration
Support for header compression
Router Solicitation
Prefix and Router Discovery
Router Advertisement
Neighbor Solicitation
Address Registration
Neighbor Advertisement

9. Public Sensing
The smartphone acts as a gateway supporting a similar stack to the one in Slide 5
The connection is opportunistic: sensor can only transfer data if a smartphone is present
No guarantee this will happen for every data packet

10. Reliable Delivery for Public Sensing
Start
Sensor wakes up, schedules next sleep ?
Yes
Expired Timers?
Yes
Retransmit old packets
New packets?
Yes
Send packet, start timer No No No No
Sleep event arrived?
Yes
Packet arrives at smartphone
End
Start Drop Timer
Drop ACK
Send ACK to sensor
Stop timer, remove packet
Yes
Send packets, stop timers
Connect to cloud?
Yes
ACK arrives at sensor
timer expired? No
Packets received at cloud No
Drop timer Expired?
Yes No
Connect to Sensor?
Connect to phone? No
Yes No
Start Drop Timer
Send ACKs
Yes
ACKs received at smartphone
Drop packet
Go to end

11. Data Collection from ZigBee Sensors
Smartphones generally do not support ZigBee
All ZigBee networks have a PAN coordinator where all data is collected
From there the data can uploaded to the Internet
Thus, the coordinator can act as a gateway

12. The Node Deployment Problem
Problem Statement: What is the optimum placement of sensor nodes in order to satisfy the requirements of a certain application?
This placement needs to ensure that all required attributes are sensed and all nodes have a path to the PAN coordinator (the coverage and connectivity problems)
Sensors are modeled as a circular disk with sensing range Rs metres and communication range Rc metres Rc
Rs is determined by the sensing hardware while Rc is determined by transceiver Rs

13. The Node Deployment Problem
Nodes go into sleep mode periodically and their batteries die
Conclusion  not all deployed nodes may be active at all time
Thus, redundancy is required in the network (deploy more nodes than needed)
The problem now is known as the k-coverage and k-connectivity problems:
every point must be covered by at least k sensors
every sensor must have k different paths to the coordinator

14. Examples 1-coverage, 1-connectivity 1-coverage, 4-connectivity
Strip pattern used as building block for 1-coverage and 1-connectivity network
** F. Wang and J. Liu, “Networked Wireless Sensor Data Collection: Issues, Challenges, and Approaches,” IEEE Communication Surveys and Tutorials, Vol. 13, No. 4, 2011.

15. Node Deployment for Area Coverage
Goal is cover every point in the area with at least k sensors
Research has discovered the following pattern to be the universal element pattern for 1-coverage and k-connectivity (k ≤ 6)
Where d1 and d2 are parameters that depend on Rc and Rs
** F. Wang and J. Liu, “Networked Wireless Sensor Data Collection: Issues, Challenges, and Approaches,” IEEE Communication Surveys and Tutorials, Vol. 13, No. 4, 2011.

16. Examples
** F. Wang and J. Liu, “Networked Wireless Sensor Data Collection: Issues, Challenges, and Approaches,” IEEE Communication Surveys and Tutorials, Vol. 13, No. 4, 2011.

17. ** F. Wang and J. Liu, “Networked Wireless Sensor Data Collection: Issues, Challenges, and Approaches,” IEEE Communication Surveys and Tutorials, Vol. 13, No. 4, 2011.

18. Node Deployment for Location Coverage
Goal is to cover specific points in an area with at least k sensors
These locations may be sparse, thus requiring relay nodes
Needs to consider the nature of traffic so as not to over-consume the batteries of certain relay nodes
Example: how to optimally distribute N relay nodes if you have 2 sources S1 producing 60% of the data and S2 producing 40% of the data: S1 S2 S1 S2
1 3 N
1 3 N
1 3 N
1 3 N - Δ V V
1 3 N + Δ
1 3 N S0 S0

19. Data Delivery Models
Event-driven: data is generated in response to an event. Data from several sensors may be highly correlated. Fusion techniques often employed
Query-driven: network is interactive. Only sends data on demand
Continuous-based: real-time data. Network is always sending data
Time-driven: data is collected periodically from the environment
Transmitted data may be loss-tolerant or not
Internet routing protocols are not suitable for sensor networks since they do not consider energy efficiency

20. RPL: Routing for LLNs
Directed Acyclic Graph (DAG) - a directed graph with no cycles exist.
Destination Oriented DAG (DODAG) - a DAG rooted at a single destination.

21. RPL Instances Traffic in LLNs is typically one-to-many or many-to-one
RPL instance builds a DODAG rooted at one node to optimize routing
Rank defines the position of the node in the DODAG
Each RPL instance optimizes a particular routing metric towards a node
This metric may be a combination of several cost metrics
Metrics may be link properties (reliability, delay, bandwidth, etc.) or node properties (remaining battery power, buffer capacity, etc.)
Networks may run several concurrent instances, with an ID for each

22. RPL Control Messages
RPL denes a new ICMPv6 message with three possible types:
DAG Information Object (DIO) - carries information that allows a node to discover an RPL Instance, learn its configuration parameters and select DODAG parents
DAG Information Solicitation (DIS) - solicit a DODAG Information Object from a RPL node
Destination Advertisement Object (DAO) - used to propagate destination information upwards along the DODAG.

23. Instance Creation and Routing
Root nodes periodically send link-local multicast DIO messages
Stability or detection of routing inconsistencies influence the rate of DIO messages
Nodes listen for DIOs and use their information to join a new DODAG, or to maintain an existing DODAG
Nodes may use a DIS message to solicit a DIO
Based on information in the DIOs the node chooses parents that minimize path cost to the DODAG root
Route Construction
Up routes towards nodes of decreasing rank (parents)
Down routes towards nodes of increasing rank
Nodes inform parents of their presence and reachability to descendants
Source route for nodes that cannot maintain down routes
Forwarding Rules
All routes go upwards and/or downwards along a DODAG
When going up, always forward to lower rank when possible, may forward to sibling if no lower rank exists
When going down, forward based on down routes

24. Traffic Flows Up towards the DAG root for many-to-one
Down away from the DAG root for one-to-many
Point-to-point via up*down*

25. RPL Example R=0 R=0 R=0 A A A B C D B C D B C D R=1 R=1 R=1 R=1 R=1
DIO Messages
DAO Messages B C D B C D B C D
R=1
R=1
R=1
R=1
R=1
R=1
DIO Messages E F B
R=0
R=0
Unused link A A
Final Topology
DIO Messages
DIO Messages B C D B C D
R=1
R=1
R=1
R=1
R=1
R=1
DAO Messages E F B E F B
R=2
R=2
R=2
R=2
R=2
R=2

26. DODAG Repair
Link between G and C fails  choose parent with lower rank
Multicast DRQ message on all connected edges and wait for DRP message
Handling of DRQ message
– If Rank => Rank_DRQ
Record reverse route,
Forward DRQ to a parent
– If Rank < Rank_DRQ
Generate a DRP message,
Forward DRP to DRQ transmitter
Handling of DRP message
– Decrease rank if necessary
– Update Rank_DRP field of DRP
– Forward DRP to next hop
DODAG is locally repaired when a DRP message reaches DRQ message generator

27. Downward Destinations and Destination Advertisement
Nodes inform parents of their presence and reachability to descendants by sending a DAO message
Node capable of maintaining routing state  Aggregate routes
Node incapable of maintaining routing state  attach a next-hop address to the reverse route stack contained within the DAO message

28. Downward Destinations and Destination Advertisement
H sends a DAO message to F indication the availability of H, F adds the next-hop and forwards the message to I
G sends a DAO message to F indication the availability of G, F adds the next-hop and forwards the message to I
F sends a DAO message to I indication the availability of F
I aggregates the routes and sends a DAO advertising (F-I)