Unified Communications in IoT, Evolutionary Aspects and the Role of Information-centric Networking
Download as PPT, PDF0 likes106 views
This document discusses unified communications in the Internet of Things (IoT) and the role of publish/subscribe models. It provides an overview of the NDN-IoT framework, which aims to bring IoT semantics to network layers by naming things and operations. The document compares the NDN and publish-subscribe broker models, describes the NDN stack and packet format, and provides examples of NDN implementation in IoT. It also discusses performance aspects and challenges of integrating NDN and IoT, such as mobility, in-network caching, and naming.
Unified Communications in IoT, Evolutionary Aspects and the Role of Information-centric Networking
- 1. 1 Unified Communications in IoT Evolutionary Aspects and the Role of Publish/Subscribe Models Rute C. Sofia (rute.sofia@ulusofona.pt) 2018.10.29 Sabbatical project in cooperation with Siemens AG CT, TUM (Chair of Network Architectures and Services)
- 2. Agenda • The NDN-IoT framework • cooperation with TUM, Siemens AG CT, and COPELABS, University Lusófona •Internet end-to-end perspective • Communication with Things and People •IoT environments • Main environments • Features and Requirements • TCP/IP Stack evolution • IoT Architectural Design, main Requirements •IoT Communication Aspects • Main protocols • Interoperability Aspects • Brief ICN Introduction • IoT and ICN Interworking • Why? • Stack and packet formats • Examples • Challenges 2
- 3. The NDN*-IoT Framework Cooperation Overview 3
- 4. Internet End-to-End and IoT Where are Things ? Network Access Provider: NAP Sells network access to the user (line, Internet services) Sells service transportation – service providers Used to sell services also – currently partners with service providers Sells personalized services (e.g. SocialTV) Service providers Internet Service Providers Application Service Providers WISP – Wireless Internet Service Providers OTT – Over-the-Top Providers 4
- 5. Internet End-to-End and IoT Communication between Things ? Services •From an end-to-end perspective: • Things are close to people (Customer Premises) • The “cloud” integrates Layer 2 and Layer 3 devices • Services reside on an IP backbone Internet 5
- 6. Internet End-to-End and IoT Communication between Things 6
- 7. IoT Environments Industrial vs. Consumer 7
- 8. IoT Environments Features, Relative Importance 8
- 9. IoT Environments Examples, Consumer/Personal; Industrial 9
- 10. IoT Architectural Design Requirements IIoT 10
- 11. IoT Architectural Design Requirements Main Requirements,CIoT 11
- 12. IoT Architectural Design, Evolution TCP/IP Stack Evolution 12 •PHY: more heterogeneity, longer distances, point-to- point • Network: IPv6, interconnection, interoperability • Transport: move from TCP to UDP • Application: messaging protocols instead of HTTP
- 13. IoT Communication Aspects CoAP, Web of Things 13 •CoAP: Constrained Application Protocol (IETF RFC 7252) • Provides suppport for IoT, complementary to HTTP •Request-response •Designed for M2M applications (e.g., Monitoring) *Ishaq, Isam, David Carels, Girum K. Teklemariam, Jeroen Hoebeke, Floris Van den Abeele, Eli De Poorter, Ingrid Moerman, and Piet Demeester. "IETF standardization in the field of the internet of things (IoT): a survey." Journal of Sensor and Actuator Networks 2, no. 2 (2013): 235-287. http://coap.technology/ V. Loga, Internet of Things Protocols, 6LowPan and CoAP. Aalto University, presentation. 2015 *
- 14. IoT Communication Aspects Messaging In IoT 14 • Event or time-driven •Fragment •Producer and consumer can run independently • Publish information to all interested in it • Modular • Can scale well (Deployment and support for parallel) P Apps produce messages Exchange filter and route messages Queues store and forward messages Apps consume messages Broker (Server)Clients Clients
- 15. IoT Communication Aspects Messaging In IoT – AMQP as Example 15 • AMQP: advanced Queueing messaging protocol • Async, open, ubiquitous, adaptable • On commodity hardware, supports 10-25 thousand messages per second • JP Morgan sends 1 billion AMQP messages per day • Security • 3 levels of permissions • Can be used on top pf SSL • Broker gives abstraction (and a single point of failure) * RabbitMQ
- 16. IoT Communication Aspects Messaging In IoT - AMQP 16 Producer C3 Key “green” X M1, M2 Queue green (Direct Exchange) •Information is routed to the specific queue •All consumers subscribing that queue get the information Queue orange C2
- 17. IoT Communication Aspects Messaging In IoT - AMQP 17 Producer C3 Key “green” X M1, M2 Queue green (Fan Out Exchange) •Sends information to all queues •Different queues can be configured to handle messages differently M1, M2 Queue orange C2
- 18. IoT Communication Aspects Messaging In IoT - AMQP 18 Producer C3 Key “green.orange” X M1, M2 Queue green.* (Topic Exchange) •Sends information to queues based on “topics”. •Flexible •Multiple categories at once (less messages sent) M1 Queue *. orange C2
- 19. IoT Communication Aspects Messaging In IoT - MQTT 19 Producer Publish “21C” on Topic “Rooms/ temperature” C2 • MQTT: Message Queue Telemetry Protocol • True publish/subscribe – no queues • Low overhead • Common namespace – little security! Subscribe Rooms/temperature Subscribe Outdoor/temperature 21 C Brokers
- 20. IoT Communication Aspects Other Approaches: DDS 20 •DDS: Data Distribution Service • No broker, de-centralized communication Medagliani, Paolo & Leguay, Jeremie & Duda, A & Rousseau, Franck & Duquennoy, Simon & Raza, Shahid & Ferrari, Gianluigi & Gonizzi, Pietro & Cirani, Simone & Veltri, L & Montón, Màrius & Domingo Prieto, Marc & Dohler, M & Villajosana, I & Dupont, O. (2014). Internet of Things Applications - From Research and Innovation to Market Deployment. https://www.researchgate.net/publication/278798179_Internet_of_Things_Applications_- _From_Research_and_Innovation_to_Market_Deployment
- 21. IoT Communication Aspects Other Approaches: OPC-UA, Industrie 4.0 21 •OPC-UA: Open Platform Communications Unified Architecture • 1990 – OPC (automation) • Service-oriented approach • Supports Client/server and publish/subscriber communication • de facto standard for automation and M2M in Industrie 4.0 • Main advantage: interoperability • Main drawback: clients outside plants require ports open • Solution: rely on publish/subscribe brokers approach (e.g., MQTT) *A. Newman, L. Wiesniwiesky, O. Givehchi, J. Jasperneite. Utilizing OPC UA as comprehensive communication technology for Cyber Physical Production Systems. 9th International Workshop on Service-Oriented Cyber-Physical Systems in Converging Networked Environments (SOCNE). 2015. *
- 22. IoT Communication Aspects OPC-UA, Publish/subscriber Approaches 22 *https://readthedocs.web.cern.ch/display/ICKB/OPC-UA+Summary •Cloud: N to M support; interoperability with e.g., AMQP • Locally: 1 to N support, follows UDP directives for Time Sensitive Networks
- 23. IoT Communication Aspects Where Are We? 23
- 24. IoT Communication Aspects Where are We? 24 • No single architecture BUT • Communications are moving towards publish/subscriber abstractions • IIoT and CIoT bring in different requirements • New scenarios: connected cars, family safety – personal IoT Service-oriented approaches require a look into information-centric publish/subscriber models Focus on Data, not Things
- 25. 25 Information-Centric Networking How Data Dissemination Works •Change of network abstraction from “named host” to “named content” •Security built-in: secures content and not the hosts •Mobility is present by design Fundamentals: Replace Packets with Data Objects and Interests Replace Addresses with Object Names
- 26. Brief Introduction to ICN ICN vs. TCP/IP • Same type of protocolar stack (hourglass): IP/Information Centric layers are the narrow waist. • Both architectures rely on packets • IP Datagrams • ICN budles (chunks of data) • Both architectures rely on a specific namespace for data delivery • IP hierachical addressing • ICN, application namespace • Security • IP, no integrated security • ICN, security primitives directly at the narrow waist (every data packet is signed). • Routing • IP sends packets to host addresses (host reachability) • ICN relies on Interest packets to fetch data packets • IP (by definition) has a stateless data plane. NDN has a stateful data plane • Mobility-friendly (abstraction and naming; hosts are not identified) 26
- 27. Brief Introduction to ICN CCN to Named Data Networking CCN (PARC & Friends) 2009 Named-Data Networking Open, coordinated by UCLA (2014) hICN Cisco, 2017 Part of the NSF Future Internet Architecture FIA initiative Goal: design the next generation Internet Architecture NDN is one of four multi-institution teams funded in 2010-13, and 2014-16, ~$15M http://named-data.net http://github.com/named-data 27
- 28. The main idea: Name the data, not the hosts! ..so you just tell the network what you want.. ..and let the network find it for you Christos Papadopoulos Colorado State University 28 Brief Introduction to ICN Main Idea
- 29. Brief Introduction to ICN NDN Packets 29 There are two (main) packet types: Interest (a question, request for content) – Similar to HTTP “GET” Data (an answer, serves content) – similar to HTTP “RESPONSE” Both are encoded in an efficient binary XML No fixed length Communication Consumer ‘broadcasts’ an interest over any available communications media: want ‘/parc.com/van/presentation.pdf’ Interest identifies a collection of data All data items whose name has the interest as a prefix. Anything that hears the interest and has an element of the collection can respond with it: Here is ‘/parc.com/van/presentation.pdf/p1’ <data> Data that matches an interest ‘consumes’ it.
- 30. 30 Interest Interest Interest Content ContentContent Content Interest Brief Introduction to ICN Named-Based Routing 30
- 31. • No “source address” in content interests – Not needed for routing • Traffic monitoring less effective for non- global adversaries Interest Interest Interest Content ContentContent Content Interest Does not see the interest Does not see the interest Brief Introduction to ICN Data, Channel, User Privacy 31
- 32. Brief Introduction to ICN Naming Example 32 Names and meaning Like IP, NDN imposes no semantics on names. ‘Meaning’ comes from application, institution and global conventions: Examples: /parc.com/people/van/presentations/CCN /parc.com/people/van /thisRoom/projector Use hierarchical, aggregately names to locate and share data Reflect some organizational structure of their origin Scaling Lookups are longest match (like IP prefix lookups) which helps guarantee log(n) state scaling for globally accessible data. Although NDN names are longer than IP identifiers, their explicit structure allows lookups as efficient as IP’s.
- 33. Brief Introduction to ICN NDN Node Architecture 33 Three Data Structures Forwarding Information Base (FIB) Used to forward Interest packets towards potential sources of matching data. Identical to an IP FIB except the list of output faces (can have multiple sources) Content Store (CS) Same as the buffer memory of an IP router, yet different replacement policy Maximize data sharing (in IP , point-to-point conversations) Pending Interest Table (PIT) Keeps track of Interest packets that were sent upstream towards sources. Each CCN entity has 3 main data structures Content Store, Pending Interest Table, Forwarding Information Base Uses multicast/broadcast Uses “longest prefix matching” lookup for content names
- 34. IoT and NDN Interworking Why? 34 •Bring IoT Semantics to the network layers • Name Things and operations on Things • “Living room frontal view feed”, “CO level in kitchen” • “Living room frontal view feed”, “CO level in kitchen” • “max/min/avg pH of soil in specific point of US soil grid” • Focus on DATA associated with Things • Secure data directly • Latest updates, ACM ICN 2017 tutorial • http://conferences.sigcomm.org/ac m-icn/2017/files/tutorial-ndn- ccnlite-riot/1-ICN-intro.pdf
- 35. IoT and NDN Interworking NDN vs. Publish-Subscribe Broker Model NDN MQTT Model Publish-Subscribe Publish-subscribe Broker Model Stack NDN or IP Requires IP Naming Expressive Host based Security Integrated authentication; optional encryption-based control - Forwarding Name based, multiple strategies, inherent multihoming (1 Face multiple interfaces) Host based Caching In-network - Reporting Frequency Interest based Individual sensor based Communication Model Pull (can be extended to push) Push Mobility Supported (in-cache networking) No support (handled by TCP/IP)
- 36. IoT and NDN Interworking Stack and Packet Format* 36 *https://named-data.net/wp-content/uploads/2015/11/ndn-0035-1-creating_secure_integrated.pdf https://www.nist.gov/sites/default/files/documents/itl/antd/Lan_Wang.pdf
- 37. IoT and NDN Interworking Stack and Packet Format* 37 *https://named-data.net/wp-content/uploads/2015/11/ndn-0035-1-creating_secure_integrated.pdf
- 38. IoT and NDN Interworking Implementation: NDN RIOT* 38 *http://conferences.sigcomm.org/acm-icn/2017/files/tutorial-ndn-ccnlite-riot/5-NDN-RIOT.pdf NDN RIOT is a project support by HAW Hamburg; INRIA, Florida International University; Zühlke GmbH
- 39. IoT and NDN Interworking Example, 1-Hop 39
- 40. IoT and NDN Interworking Performance Aspects 40 http://conferences.sigcomm.org/acm-icn/2017/files/tutorial-ndn-ccnlite-riot/5-NDN-RIOT.pdf
- 41. IoT and NDN Interworking Performance Aspects 41
- 42. IoT and NDN Interworking ETSI M2M Adaptation Amadeo, Marica and Briante, Orazio and Campolo, Claudia and Molinaro, Antonella and Ruggeri, Giuseppe, "Information-centric networking for M2M communications: Design and deployment", Computer Communications 89-90 (2016), pp. 105--116. 2016 •Interoperability towards ETSI M2M architecture principles • Naming Scheme •Requirement for small packets
- 43. IoT and ICN Interworking Which Role for ICN? Overall Advantages for IoT Environments •Integrated security; •In-network caching; I •Decentralization; •Flexible forwarding strategies; •Interface abstraction, which assists sharing of IoT data between devices as well as between applications and services. For IIoT, several challenges: •in-plant communication is mostly for real- time control •Static environments •1-hop usually •Interoperability is required *Bengt Ahlgren (SICS), "ProjectGreenIoT: An Energy-Efficient IoT Platform for Open Data and Sustainable Development" (2018).
- 44. IoT and ICN Interworking Challenges I MOBILITY • Producer and consumer should be handled equally from a mobility management perspective • Mobility anticipation mechanisms can reduce signaling and improve producer mobility support • Naming in ICN is hierarchical and independent of location. • Still, the common way to handle naming is to associate with routing domains, e.g. “/tum.de/videos/”. This may affect routing • Middleware would benefit from naming guidelines IN NETWORK CACHING • Currently, strategies are based on fixed networks • Need to take into consideration the temporary nature of data (data transiency)
- 45. IoT and ICN Interworking Challenges II NAMING • Applications select naming schemes – naming is opaque to routing • Hierarchical and flat schemes are possible • NDN adopts 1-dimensional hierarchical naming and lookup operations based on longest-prefix matching • Multi-dimensional naming is relevant (location, period scopes) • Multi-dimensional naming translation into longest-prefix matching (for routing) is under development • No consensus on semantics adoption • Richer semantics may bring in security issues (e.g., allow leakages of personal information • Obfuscation must not endanger other NDN functonality, e.g., routing PULL AND PUSH BASED COMMUNICATIONS • Pull communication is not enough to support even-triggered or periodic communications • Push based models need to be adjusted to serve IoT requirements MULTI-PARTY DATA SYNCHRONIZATION • NDN supports N to M communication • Guarantees delivery even if connectivity is intermittent • Does not guarantee synchronization among consumers • Data set synchronization is required, for instance, in Smart Health or Connected Vehicles scenarios • A few options available: Chronosync, VectorSync (abstractions between middleware and network primitives)
- 46. 46