Download Lect 4 - ROLL

Internet of Things
Amr El Mougy
Alaa Gohar
Data Collection from Sensor Networks
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:
1. Smartphones (public sensing)
2. Gateway
 Communication is
typically one way
 Configuration
parameters are
allowed in the
reverse direction
Comparison of Gateways and Smartphones
Gateway
Smartphone
Fixed data collection point  reliable
Reliability depends on the smartphone
density
Low cost
Can send configuration commands from the
phone
Always supports WiFi and cellular
connections
Participation depends on the user’s
willingness
Data collection competes with other
applications
Battery-powered
Medium cost
Requires an additional device to configure
the sensors
Depending on the type, it can support WiFi,
cellular connection, or both
Always participates in the data collection
Dedicated for data collection
Typically has stable power source
Structure of BLE Gateway
Processor/Application Host
API
BLE
Stack Profiles
BLE
Physical/Link Layers
TCP/IP
Ethernet Stack
Cellular Stack
WiFi Stack
Gateway Types
 Payload Extraction
WiFi Packet
BLE Attribute
Handle
UUID
Value
WiFi - H
IP-H
TCP-H
Value
 Packet Encapsulation (Data Pipe)
BLE Attribute
Handle
UUID
Value
WiFi Packet
WiFi - H
IP-H
TCP-H
Handle
UUID
Value
6LoBLE: IPv6 over BLE Gateways
Internet Protocol Support Service
(IPSS) replaces the GAP protocol
It defines Central/Peripheral roles
for gateway and sensors
Internet
Applications
IPSS
UDP/TCP
GATT
IPv6
ATT
6LoBLE
BLE L2CAP
6LN connections
BLE Link Layer
BLE Physical Layer
6LoBLE Operations
IPv6 address autoconfiguration based on MAC
address
Neighbor solicitation/
advertisement support address
registration
Support for header
compression
Router Solicitation
Router Advertisement
Prefix and
Router Discovery
Neighbor Solicitation
Neighbor Advertisement
Address
Registration
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
Reliable Delivery for Public Sensing
Start
Sensor wakes
up, schedules
next sleep
?
Yes
Expired
Timers?
Sleep
event
arrived?
timer
expired
?
Connect
to
Sensor?
Yes
Send packet,
start timer
Packet arrives at smartphone
Start Drop
Timer
Stop timer,
remove packet
Yes
No
New
packets?
No
End
ACK arrives
at sensor
Yes
No
Yes
Send ACK
to sensor
Drop ACK
Retransmit
old packets
No
No
No
Yes
Start Drop
Timer
Send
ACKs
ACKs received
at smartphone
Yes
Send packets,
stop timers
Packets
received at
cloud
Connect
Yes
to
phone?
Connect
to cloud?
No
No
Drop
timer
Expired?
Yes
Drop packet
Go to end
No
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
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
Rs is determined by the sensing hardware
while Rc is determined by transceiver
Rc
Rs
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
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.
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.
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.
** F. Wang and J. Liu, “Networked Wireless Sensor Data Collection: Issues, Challenges, and Approaches,” IEEE Communication Surveys and Tutorials, Vol. 13, No. 4, 2011.
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
1
3
1
3
N
V
S2
N
S1
1
3
1
3
N
S2
N-Δ
V
1
3
S0
N
1
3
S0
N+Δ
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
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.
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
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.
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
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*
RPL Example
R=0
A
A
DIO Messages
B
C
R=0
R=0
A
DAO Messages
D
R=1
B
R=1
C
R=1
D
R=1
B
C
D
R=1
R=1
DIO Messages
F
E
B
R=0
R=0
Unused link
A
A
DIO Messages
DIO Messages
R=1
B
C
R=1
Final Topology
D
R=1
R=1
B
C
R=1
D
R=1
DAO Messages
E
R=2
F
R=2
B
R=2
E
R=2
F
R=2
B
R=2
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
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
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)