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: Smartphones (public sensing) Gateway Communication is typically one way Configuration parameters are allowed in the reverse direction

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

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

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

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

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

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? 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

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 Rc Rs is determined by the sensing hardware while Rc is determined by transceiver 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 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

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 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

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)