GENERIC ARCHITECTURES Of Internet of Things APPLICATIONS

1. GENERIC ARCHITECTURES Of Internet of Things APPLICATIONS University of Belgrade, School of Electrical Engineering

2. The Internet of Things (IoT) Vision • Includes different sets of technologies for collecting real-world observations, by connecting sensors, actuators, RFIDs, and mobile phones to the Internet • Includes applications from various domains: • Smart environment (homes, cities, industry, …) • Transportation and logistics • Healthcare • Environmental monitoring

3. Growth of the Number of IoT Devices • Gartner predicts 21 billion sensor devices by 2020 • Ericsson forecasts 28 billion devices by 2021:

4. Growth of the Number of IoT Developers

5. Introduction: The Generic IoT Architecture

6. The IoT Architecture Layers • Data or Perception Layer • contains heterogeneous devices, as the sources of real-world observations:sensors, sensor nodes, RFIDs, Single Board Computers, ... • Processing Layer • Processing, aggregation, storing, and distribution of collected sensor data • Application Layer • User applications running different messaging and communications protocols

7. Sensor Data Collection Patterns • Acquisitional data collection • Sensor data collection at defined time intervals • Event-driven data collection • Data observation upon detection of the defined event • Real-time data streaming • data sampled at a specific time rate

8. The Data/Perception Layer • Sensor nodes • Devices equipped with sensors and/or actuators, constrained computational, and communication capabilities • Wireless Sensor Networks • Wirelessly interconnected sensor nodes • IEEE 802.15.4, ZigBee, 6LoWPAN, Bluetooth protocols • Single Board Computers (SBC) • Devices with more computational and power resources than sensor nodes, with attached sensors through USB, supporting WiFi and TCP/IP protocol • Arduino, Raspberry Pie

9. Sensor Nodes • Limited computational, communication, and power resources • Small interval of activity, long idle intervals • Computation – communication tradeoff (for low frequency processors) • The similar energy is consumed for executing 1000 instructions as for sending one bit of information • Running lightweight OS – TinyOS, Contiki, FreeRTOS • Processors running from 4MHz to hundreds of MHz

10. The Major IoT Connectivity Protocols

11. The Most Popular OSes for IoT

12. Gateway • Hardware device that is connected to the Internet and provides access to a WSN • Ranging from SBC running Embedded Linux to full-size desktop computers • Responsible for: • Collecting, annotating, and publishing sensor data • Serving sensor data requests • Protocol translation • Running middleware component

13. The Processing Layer • Three popular organizations: • IoT platform oriented • Massive scalability • Message-broker oriented • Medium scalability • Gateway-based • Small scalability

14. The IoT Platform Oriented Architecture

15. The IoT Service Interfaces • Standard IoT Application Layer Protocols • MQTT, XMPP, AMQP, DDS • REST • Standard Web services • Open Geospatial Consortium (OGC) – Sensor Web Enablement (SWE) • SPARQL Endpoint – • Serving semantic queries

16. OGC SWE • OGC SWE – Set of specifications and interfaces • Sensor Observation Service – SOS • Sensor Event Service – SES • Sensor Planning Service – SPS • Observation & Measurements - O&M

17. IoT Cloud • Platform as a Service (PaaS) model • IoT Cloud offers almost unlimited storage and computational resources • Data are stored for later use, such asdata analysis using data mining algorithms • IoT Cloud could contain different BigData platforms and tools: • Apache Spark, Apache Kafka, Apache Storm… • Examples: Xively, Nimbits

18. Semantic Sensor Data • Providing context information with raw sensor data • Represented using Resource Description Framework (RDF) • RDF Serialization Formats: • RDF/XML, RDF/JSON, N-Triples, Turtle • Significant overhead in message (payload) size when RDF are serialized by certain encodings

19. Semantic Sensor Network Ontology • Standardized by World Wide Web Consortium (W3C)

20. Stimulus-Sensor-Observation: Pattern

21. Semantic-Based Integration of Sensor Networks • Enablement of horizontal solutions • Data fusion • Semantic spatio-temporal queries

22. Database-Centered Approach • All sensor data are kept in a database • Ability of aggregate queries, as well as spatio-temporal queries • Semantic queries • Poor scalability if centralized database systems are used

23. Query Translation Approach • Data are kept in native (compact) format • User (semantic) queries are translated to query language of sensor data source • Query result is converted to the user data format, i.e. RDF • Drawbacks: • Multiple conversion and translation of queries and data • EU FP7 SemSorGrid4Env, 2011

24. Sensor Virtualization Approach • Sensors are represented by an abstract data model • Clients directly communicate with sensor devices over defined interfaces • Multiple sensor data models could exist in parallel • Drawback: Sensor devices should handle multiple user requests • XGSN, EU FP7 Sensei, EU FP7 IoT-A

25. Service-Composition Approach • Users are able to specify data streams with desired characteristics • The system will try to compose a data flow by connecting processing elements with appropriate sensor data sources • Semantic descriptions of processing elements and sensor data sources • System S by IBM – the process of solving a requesttakes about 2sec

26. IoT Platform/Cloud - Requirements • Handling sensor Big Data • Huge volume of data • Very intensive creation of new data • Combining recent data with historical data • Performing data mining algorithms • Combining sensor data with social networks data • Challenge of indexing sensor data • It was similar at the beginning of World Wide Web

27. Continuous Query Processing • A query engine continuously processes sensor data streams • Produces complex, aggregated, and derived data • Hybrid systems aiming to combine recent sensor data with historical sensor data that are stored by standard RDF triple stores • Some solutions can process up to 100000 triples per second • CQELS, C-SPARQL, EP-SPARQL, SPARQLstream

28. Applications with Semantic Queries

29. Message Broker/Web Server Architectures

30. IoT Applications Protocols • Pull-based approaches • Clients issue requests to a server, and the server responds with data • Synchronous data delivery • Push-based approaches • The server sends data to clients immediately upon their availability • Asynchronous data delivery • Publish/subscribe message passing

31. Pull-Based Communication • REST • HTTP methods: GET, POST, PUT, DELETE • Resources are referred by URIs • Standard Web service • Web Service Description Language (WSDL) and Simple Object Access Protocol (SOAP) • Remote Object Method Call • Constrained Application Protocol (CoAP) • Designed with the aim to provide REST to constrained devices

32. Push-based Communication • HTTP Long-polling • A server holds the connection until new data are available • HTTP Streaming • A server appends new data to a response message that is never terminated • TCP sockets • Bidirectional connections using TCP • WebSockets • Aimed for using by Web clients by upgrading HTTP requests

33. Publish/Subscribe Messaging • Message broker is a server component that dispatches published messages to subscribed clients • Publishers send messages that are associated to certain topic • Consumers receive messages from message broker, if the messages are published to that topic • Different policies of message routing between publishers and consumers • Protocols: MQTT, AMQP, XMPP, DDS

34. Message Broker • Standalone server component that could be either Java or native applications • Clients could establish connections over: • HTTP binding • TCP sockets • WebSocket (Web clients) • Quality of Service can be specified • Message persistence strategy • How messages should be handled after their delivery ?

35. Message Queue Telemetry Transport (MQTT) • Designed by IBM in 1999 for lightweight Machine to Machine (M2M) communication • Goals: Minimal bandwidth requirements, code footprint size, power consumption requirements, message data overhead • TCP/IP based • Binary Messages • Topics can have hierarchical names separated with a slash (/) • Example: wsn1/sensors/temperature/temp1 • Software are available through Eclipse Paho Project • Used by Facebook chat

36. Advanced Message Queuing Protocol (AMQP) • Created in 2003 by financial industry, and in 2014 AMQP 1.0 adopted as an ISO and IEC standard • Exchange of binary messages • Ensures reliable communication with three-modes of message-delivery: at-most-once, at-least-once, and exactly-once • Four available message routing: • Direct – Routing to only one queue, • Fanout – Routing to every associated queue • Topic – Routing according to binding keys and wildcards • Header – Routing according to header attributes

37. Extensible Messaging and Presence Protocol (XMPP) • Developed in 1999 for instant messaging • Lightweight implementations for constrained devices, μXMPP and XMPP client for mbed • Protocol exchanges XML messages called stanzas • Core protocol are extended by 300 specifications • XEP-0206: XMPP over Bidirectional-streams Over Synchronous HTTP (, XEP-0060: Publish-Subscribe, XEP-0323: Internet of Things - Sensor Data, and IETF’ RFC 7395: XMPP Subprotocol for WebSocket • Used by Google Talk and currently by WhatsApp(with some variations)

38. Data Distribution Service (DDS) • Proposed by Object Management Group (OMG) • Specifies middleware communication protocol and Application Programming Interface (API) in Java and C++ • Serverless architecture – only discovery and routing components • Data-Centric Publish-Subscribe (DCPS) model • Topics of certain data types that applications want either to publish or receive. • Interface Definition Language (IDL) is used for defining data types • TCP and UDP are supported, but no WebSockets

39. IoT Messaging Protocols Comparison

40. IoT Applications Protocol Popularity

41. Message Encodings • Text-based message encodings • Data are represented in human-readable format • Examples: XML, JSON, RDF (RDF/XML, N-Triples, Turtle) • Binary message encodings • Designed to reduce message size, and to efficiently object graph structures • Lacks in interoperability • Examples: Efficient XML Interchange (EXI), Binary JSON Formats (BSON , BJSON , and UBJSON),Google Protocol Buffer (Colfer, Protostuff), Binary RDF (RDSZ, HDT), Adobe Message Format (AMF)

42. IoT Web Application Performance Evaluation • Latency requirements for some IoT applications could be very rigorous • Update frequency in closed-loop control could vary between 10ms and 100ms • Test Application is from the public-district heating domain • Sensor observations are generated at 1Hz rate • Test applications are implemented on HTML5, Adobe Flash, Microsoft Silverlight platforms

43. Test Application Sensor Data Model

44. Performance Evaluation Analysis

45. IoT HTML5 Application Test Results

46. IoT Applications Latency Comparison

47. IoT Messaging Latency Comparison

48. IoT Messaging Throughput Rate

49. Suggestions for IoT Application Development • JSON is the most appropriate message encoding because of web browsers optimizations • WebSocket is mature technology • MQTT is most appropriate messaging protocol for majority IoT applications • MQTT disadvantage: Mosquitto message broker bug with publishing messages over WebSocket! • DDS achieved the highest message rate

50. IoT Semantic Platform Research Directions • Current RDF Triple Stores • Designed for Linked Data that are mostly static data • Research Towards Highly Distributed RDF Triple Store • Predicate-based solution • Only two indexes per RDF triple: PSO, POS • Predicate-related maps are distributed among computational nodes • Query execution plan- data flow graph • Acyclic Directed Graph with semantic sensor data flow • Reduction and mapping nodes -