UNIT2_PPT.ppt
- 1. Module 2 IOT COMMUNICATION MODEL AND PROTOCOLS
- 2. Outline Connectivity Protocols β’6LoWPAN β’IEEE 802.15.4 β’Zigbee β’Wireless HART β’ZβWave β’ISA 100 β’NFC
- 3. Outline Data Protocols: β’ Message Queue Telemetry Transport (MQTT) β’ Constrained Application Protocol (CoAP) β’ Advanced Message Queuing Protocol (AMQP) β’ XMPP β Extensible Messaging and Presence Protocol.
- 4. 6LoWPAN Introduction β’Lowβpower Wireless Personal Area Networks over IPv6. β’Allows for the smallest devices with limited processing ability to transmit information wirelessly using an Internet protocol. β’Allows lowβpower devices to connect to the Internet. β’Created by the Internet Engineering Task Force (IETF) β RFC 5933 and RFC 4919.
- 5. Features of 6LoWPANs β’ Allows IEEE 802.15.4 radios to carry 128βbit addresses of Internet Protocol version 6 (IPv6). β’ Header compression and address translation techniques allow the IEEE 802.15.4 radios to access the Internet. β’ IPv6 packets compressed and reformatted to fit the IEEE 802.15.4 packet format. β’ Uses include IoT, Smart grid, and M2M applications.
- 6. Addressing in 6LoWPAN 64βbit addresses: globally unique 16 bit addresses: PAN specific; assigned by PAN coordinator IPv6 multicast not supported by 802.15.4 IPv6 packets carried as link layer broadcast frames
- 7. 6LoWPAN
- 8. 6LoWPAN
- 9. 6LoWPAN
- 10. 6LoWPAN
- 11. 6LoWPAN
- 12. β’ LOADng Routing β’ Derived from AODV(Ad hoc On demand Distance Vector) and extended for use in IoT. β’ Basic operations of LOADng include: β’ Generation of Route Requests (RREQs) by a LOADng Router (originator) for discovering a route to a destination, β’ Forwarding of such RREQs until they reach the destination LOADng Router, β’ Generation of Route Replies (RREPs) upon receipt of an RREQ by the indicated destination, and unicast hopβbyβhop forwarding of these RREPs towards the originator. 6LoWPAN
- 13. β’ LOADng Routing β’ Derived from AODV and extended for use in IoT. β’ Basic operations of LOADng include: β’ Generation of Route Requests (RREQs) by a LOADng Router (originator) for discovering a route to a destination, β’ Forwarding of such RREQs until they reach the destination LOADng Router, β’ Generation of Route Replies (RREPs) upon receipt of an RREQ by the indicated destination, and unicast hopβbyβhop forwarding of these RREPs towards the originator. 6LoWPAN
- 14. β’ If a route is detected to be broken, a Route Error (RERR) message is returned to the originator of that data packet to inform the originator about the route breakage. β’ Optimized flooding is supported, reducing the overhead incurred by RREQ generation and flooding. β’ Only the destination is permitted to respond to an RREQ. β’ Intermediate LOADng Routers are explicitly prohibited from responding to RREQs, even if they may have active routes to the sought destination. β’ RREQ/RREP messages generated by a given LOADng Router share a single unique, monotonically increasing sequence number. 6LoWPAN
- 15. 6LoWPAN β’ RPL(Routing Protocol for LOW Power and Lossy Networks) Routing β’ Distance Vector IPv6 routing protocol for lossy and low power networks. β’ Maintains routing topology using low rate beaconing. β’ Beaconing rate increases on detecting inconsistencies (e.g. node/link in a route is down). β’ Routing information included in the datagram itself. β’ Proactive: Maintaining routing topology. β’ Reactive: Resolving routing inconsistencies.
- 16. β’ RPL separates packet processing and forwarding from the routing optimization objective, which helps in Low power Lossy Networks (LLN) β’ RPL supports message confidentiality and integrity. β’ Supports DataβPath Validation and Loop Detection β’ Routing optimization objectives include β’ minimizing energy β’ minimizing latency β’ satisfying constraints (w.r.t node power, bandwidth, etc.) 6LoWPAN
- 17. β’ RPL operations require bidirectional links. β’ In some LLN scenarios, those links may exhibit asymmetric properties. β’ It is required that the reachability of a router be verified before the router can be used as a parent. 6LoWPAN
- 18. Functionality-based IoT Protocol Organization β’ Connectivity (6LowPAN, RPL) β’ Identification (EPC, uCode, IPv6, URIs) β’ Communication / Transport (WiFi, Bluetooth, LPWAN) β’ Discovery (Physical Web, mDNS, DNSβSD) β’ Data Protocols (MQTT, CoAP, AMQP, Websocket, Node) β’ Device Management (TRβ069, OMAβDM) β’ Semantic (JSONβLD, Web Thing Model) β’ Multiβlayer Frameworks (Alljoyn, IoTivity, Weave, Homekit)
- 19. MQTT β’ Introduction β’ Message Queuing Telemetry Transport. β’ ISO standard (ISO/IEC PRF 20922). β’ It is a publishβsubscribeβbased lightweight messaging protocol for use in conjunction with the TCP/IP protocol. β’ MQTT was introduced by IBM in 1999 and standardized by OASIS in 2013. β’ Designed to provide connectivity (mostly embedded) between applications and middleβwares on one side and networks and communications on the other side.
- 20. MQTT β’ A message broker controls the publishβsubscribe messaging pattern. β’ A topic to which a client is subscribed is updated in the form of messages and distributed by the message broker. β’ /home/room/temperature β’ Designed for: β’ Remote connections β’ Limited bandwidth β’ Smallβcode footprint
- 21. MQTT Components
- 22. MQTT Methods
- 23. MQTT
- 24. MQTT Communication β’ The protocol uses a publish/subscribe architecture (HTTP uses a request/response paradigm). β’ Publish/subscribe is eventβdriven and enables messages to be pushed to clients. β’ The central communication point is the MQTT broker, which is in charge of dispatching all messages between the senders and the rightful receivers. β’ Each client that publishes a message to the broker, includes a topic into the message. The topic is the routing information for the broker.
- 25. MQTT Communication β’ Each client that wants to receive messages subscribes to a certain topic and the broker delivers all messages with the matching topic to the client. β’ Therefore the clients donβt have to know each other. They only communicate over the topic. β’ This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
- 26. MQTT Topics β’ A topic is a simple string that can have more hierarchy levels, which are separated by a slash. β’ A sample topic for sending temperature data of the living room could be house/livingβroom/temperature. β’ On one hand the client (e.g. mobile device) can subscribe to the exact topic or on the other hand, it can use a wildcard.
- 27. MQTT Topics β’ The subscription to house/+/temperature would result in all messages sent to the previously mentioned topic house/livingβ room/temperature, as well as any topic with an arbitrary value in the place of living room, such as house/kitchen/temperature. β’ The plus sign is a single level wild card and only allows arbitrary values for one hierarchy. β’ If more than one level needs to be subscribed, such as, the entire subβtree, there is also a multilevel wildcard (#). β’ It allows to subscribe to all underlying hierarchy levels. β’ For example house/# is subscribing to all topics beginning with house.
- 28. Message format of MQTT protocol β’ All the messages of MQTT have a small code footprint, hence it is popular as a lightweight messaging protocol. Each MQTT message consists of the following: β’ Fixed header (2 bytes) β’ Optional variable header β’ Message payload (<= 256MB) β’ Quality of Service (QoS) level 28
- 29. β’ MQTT supports one-to-one, one-to-many, and many- to-many communication. β’ By lowering the amount of data transmitted, MQTT makes itself a perfect protocol for constrained IoT devices. β’ Message payloads are encoded in binary. In an open network where the recipient is from a different manufacturer will face issues decoding it as there is no information of how message payload is encoded. 29
- 30. Quality of Service level for MQTT protocol β’ The quality of service levels determines how the content is managed. MQTT uses three different QoS levels. It is important to choose the right QoS level for every message because it determines how the client and server communicate to deliver the message. The QoS levels of MQTT are as follows: β’ QoS 0 : Messages delivered per the best efforts of the operating environment, but message loss can occur β’ QoS 1 : Messages delivery assured but duplicates can be created β’ QoS 2 : Message to deliver exactly once β’ MQTT provides us with an option to set the appropriate QoS level, but remember, higher the QoS, lower the performance. 30
- 31. Security of MQTT protocol β’ MQTT allows you to pass username and password as an MQTT packet. Encryption of a message across the network can be handled independently of MQTT with Secure Sockets Layer (SSL). β’ It has a minimal authentication feature built in. Username and password are sent as clear text. To make it secure, Secure Sockets Layer (SSL)/ Transport Layer Security (TLS) must be employed, but SSL/TLS is not a lightweight protocol. β’ Many industry experts believe MQTT will play a major role in IoT by contributing to fields such as inventory tracking, and medical IoT.. 31
- 32. MQTT Applications β’ Facebook Messenger uses MQTT for online chat. β’ Amazon Web Services use Amazon IoT with MQTT. β’ Microsoft Azure IoT Hub uses MQTT as its main protocol for telemetry messages. β’ The EVRYTHNG IoT platform uses MQTT as an M2M protocol for millions of connected products. β’ Adafruit launched a free MQTT cloud service for IoT experimenters called Adafruit IO.
- 33. CoAP Constrained Application Protocol β’ Introduction β’ CoAP β Constrained Application Protocol. β’ Web transfer protocol for use with constrained nodes and networks. β’ Designed for Machine to Machine (M2M) applications such as smart energy and building automation. β’ Based on RequestβResponse model between endβpoints β’ ClientβServer interaction is asynchronous over a datagram oriented transport protocol such as UDP
- 34. CoAP Constrained Application Protocol β’ The Constrained Application Protocol (CoAP) is a session layer protocol designed by IETF Constrained RESTful Environment (CoRE) working group to provide lightweight RESTful (HTTP) interface. β’ Representational State Transfer (REST) is the standard interface between HTTP client and servers. β’ Lightweight applications such as those in IoT, could result in significant overhead and power consumption by REST. β’ CoAP is designed to enable lowβpower sensors to use RESTful services while meeting their power constraintshtweight RESTful (HTTP) interface.
- 35. CoAP Constrained Application Protocol β’ Built over UDP, instead of TCP (which is commonly used with HTTP) and has a light mechanism to provide reliability β’ CoAP architecture is divided into two main subβlayers: β’ Messaging β’ Request/response β’ The messaging subβlayer is responsible for reliability and duplication of messages, while the request/response subβlayer is responsible for communication. β’ CoAP has four messaging modes: β’ Confirmable β’ Nonβconfirmable β’ Piggyback β’ Separate
- 36. CoAP Position
- 39. CoAP Request-Response Model β’ Confirmable and nonβconfirmable modes represent the reliable and unreliable transmissions, respectively, while the other modes are used for request/response. β’ Piggyback is used for client/server direct communication where the server sends its response directly after receiving the message, i.e., within the acknowledgment message. β’ On the other hand, the separate mode is used when the server response comes in a message separate from the acknowledgment, and may take some time to be sent by the server. β’ Similar to HTTP, CoAP utilizes GET, PUT, PUSH, DELETE messages requests to retrieve, create, update, and delete, respectively
- 41. CoAP Request-Response Model Features β’ Reduced overheads and parsing complexity. β’ URL and contentβtype support. β’ Support for the discovery of resources provided by known CoAP services. β’ Simple subscription for a resource, and resulting push notifications. β’ Simple caching based on maximum message age
- 42. AMQP Introduction β’ Advanced Message Queuing Protocol. β’ Open standard for passing business messages between applications or organizations. β’ Connects between systems and business processes. β’ It is a binary application layer protocol. β’ Basic unit of data is a frame. β’ ISO standard: ISO/IEC 19464
- 43. AMQP
- 44. AMQP Features
- 45. AMQP Features
- 46. Message Delivery Guarantees β’ Atβmostβonce β’ each message is delivered once or never β’ Atβleastβonce β’ each message is certain to be delivered, but may do so multiple times β’ Exactlyβonce β’ message will always certainly arrive and do so only once
- 47. AMQP Frame Types β’ Nine AMQP frame types are defined that are used to initiate, control and tear down the transfer of messages between two peers: β’ Open (connection open) β’ Begin (session open) β’ Attach (initiate new link) β’ Transfer (for sending actual messages) β’ Flow (controls message flow rate) β’ Disposition (Informs the changes in state of transfer) β’ Detach (terminate the link) β’ End (session close) β’ Close (connection close)
- 48. AMQP Components