Idea Transcript
Toward a Definition of Internet of Things Roberto Minerva, IEEE IoT Initiative Chair – TIMLab
08 - 10 June 2016
EDGE COMPUTING
The Philosophy of an All-IP Network (and 5G is an all-IP network) End – to – End Principle for IP networks “mechanisms should not be enforced in the network if they can be deployed at end nodes, and that the core of the network should provide general services, not those tailored to specific applications” Clarks & Reed from MIT
Stupid Network
Autonomous SubSystems
Intelligent EndPoints E-E protocol
With All-IP Networks, intelligence (and services) moves to the edge
Anything will be a node ! •
•
Intel has unveiled a WiFi sliver of silicon that can be part of a normal microprocessor chip. We can expect that wherever we find a microprocessor (e.g. in over 70% of toys, to name just one area) we will find embedded connectivity.
Roberto Saracco http://www.blog.telecomfuturecentre.it/
A trend in devices: integration of communication, processing, storage and sensing/actuation capabilities This a is a big challenge from devices: how can we take advantage in terms of services and application of this power in a single node ?
Nodes will connect each other in unpredictable ways Aggregation 2
Aggregation 3
1 2
Aggregation 1
3
Network
Node Aggregation at time t1
3
• Increasing richness and complexity at the edge of networks • D2D Communications
1
Aggregation 2
Aggregation 1
2 Node Aggregation at time t2
http://muxware.net/sol_mesh.php
Disruption at the Edge of Networks
Advances in embedded communications and computing (and the down-spiraling of costs) will make available an incredible amount of resources at the edge of networks (where “intelligence” has migrated); Imagine anything becoming a low cost s/w router with processing and storage capabilities; Software functions/services, running on generalpurpose hardware, will transform edge networks into a land of distributed clouds, with plenty of local virtual resources (operated even by diverse Players); Clouds of Virtual Machines at the Edge, we can call them
FOG Networks,
Ephemeral Networks,
…
Example: RouteBricks
Bonomi, Flavio, et al. "Fog computing and its role in the internet of things." Proceedings of the first edition of the MCC workshop on Mobile cloud computing. ACM, 2012.
Example of Egde Communications Fog Computing
http://www.slideshare.net/Angelo.Corsaro/20141210-fog http://www.slideshare.net/Angelo.Corsaro/20141210-fog
8
Edge Networking: a couple of issues How to induce an altruistic behavior in nearby nodes
How to dominate the complexity of these networks?
b/c > k The ratio of benefit, b, to cost, c, of altruistic act has to exceed the degree, k, i.e., a value related to the number of neighbors per individual When Edge/Ephemeral networks (or Smart Environments) will show clear benefits of local communications and sharing, then they will be serious competitors of Telecoms
From: A simple rule for the evolution of cooperation on graphs and social networks H. Ohtsuki et alii
How to “Induce” an Altruistic Behavior in Networks?
Autonomic-cognitive features •
•
At the edge, a sheer number of nodes and high dynamicity will determine a level of “complexity” compromising the use of traditional management and control planes (e.g. due scalability, performance, etc.) This will require deploying autonomic/cognitive capabilities both into equipment (local control loops) and in the management-control functions • 0-Touch Network in the core (helping reducing the issues of configuration and management and pushing for flat networks) • Self-Organizing Networks at the Edge
Disruption in Edge Networks
Edge networks can be built and programmed in the same way as today end systems! Edge will look like a federation of Clouds…and also Cloud Computing will become “commodities” This will be a fertile space for innovating the ICT-Telco biz
A step towards “Smart Environments”, deployed by Several Actors (e.g., Operators in conjunction with the Public Administrations or Customers) Federation and Brokering of Resources
Examples of potential tasks for an Operator:
Broker of available resources
Virtualize a Resource in the Network (servitization)
Anchor point for allowing local environments to communicate
Mirroring the “Edge Complexity” to enable Third Parties to create services;
Managing and orchestrating a “sea of virtual resources” while the workloads and Customers’ demands of VMs fluctuate in real time.
Edge Complexity, Brokering, Smart Environments
Edge Computing: Virtualization + Sofwarization + Autonomics
Some Consequences 1. Network is “programmable” by services 2. Network is self-organized (towards 0 Opex) 3. Network is Virtualized and de-perimetrized (towards 0 Capex) 4. Servitization, products becoming services by means of the ICT infrastructure 5. Important Infrastructural Role of Users 6. Networks as Smart Environments
Module 9: Edge Computing What is the end to end principles? Why is it important? How would you describe an edge network? – Can you provide an example ? – (e.g., Car platooning, Robot coordination, drones cooperations, …) Is there a relationship between peer to peer technologies and edge computing? And differences? (overlay vs. physical)
15
COMMUNICATION …
TSP/MSC Communication Networks and Services (ComNETS)
Communication Takeaways (1) A Network of Networks
A huge complex system Billions of smart objects
Communication Takeaways (2)
Understand the fundamental role of Terminals and Devices
6/15/2016
The Intelligent is at the EDGE (Put in the Net only valuable functions)
5G as an enabler
Communication Takeaways (3)
http://www.slideshare.net/titidelparis/supelec-m2-m-iot-course-1-update-2013part-1-v06
Module 10: Communications Takeaways Is the concept of complex system applicable to IoT? When? (For large systems under different administrative domains) What is a network of networks? How many different nodes ? How can you manage them? Is the concept of self-organization relevant in IoT ?
20
Characterization of IoT
Software
Services System Mgmt
Communication
Network Sensor
Gateway
Server
Characterization of Sensors ?> examples.getStateName 41
South Dakota
Representation State Transfer (REST definition from Fielding)
"Representation State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use." - Roy Fielding www.xfront.com/REST.ppt
Why is it called "Representation State Transfer"? Client
http://www.boeing.com/aircraft/747
Resource
Fuel requirements Maintenance schedule ...
Boeing747.html The Client references a Web resource using a URL. A representation of the resource is returned (in this case as an HTML document). The representation (e.g., Boeing747.html) places the client application in a state. The result of the client traversing a hyperlink in Boeing747.html is the access to another resource. The new representation places the client application into yet another state. Thus, the client application changes (transfers) state with each resource representation --> Representation State Transfer! www.xfront.com/REST.ppt
Representational State Transfer (REST) REST is a set of architectural principles for designing and implementing distributed systems. It proposes the use of web-based interfaces that are described in XML and handled through HTTP The REST Principles are: – A stateless client-server protocol – A set of well defined operations (e.g., GET, POST, PUT, and DELETE) to perform functions on resources – A Universal Syntax for resource identification (resources are identified by URIs) – Use of XML or HTML for describing pieces of information and their links. REST is at the core of Web Application Development From wikipedia.org
A Method invocation with REST
http://www.ExampleCurrencyBrokerage.com/convert? =us-dollar&value=100&target=pound
Module 14: APIs and the http protocol What is XML-RPC? What is the definition of REST ?
72
Middleware
(cont.)
Definition: a simple layer aiming at simplifying the RPC programming between heterogeneous systems Marshaling (parameter “translation”) Definition of Interfaces Mapping to two or more Operating Systems I/F
Stub App
App
OS Adapter Middleware
Middleware
OS
OS
HW
HW
Heterogeneous Operating Systems means more complexity
Middleware
(cont.)
Goal: to allow the remote communication between many software programs largely distributed
App Middleware
App
App
OS Middleware
HW
Middleware
OS
OS
HW
HW
App
I need to communicate with a specific service
Middleware OS App
HW App
Middleware
Middleware
OS
OS
HW
App
HW
Middleware OS App
HW
Middleware OS HW
App Middleware OS HW
App Middleware OS HW
Middleware
(cont.) It is here
I need to communicate with this specific service
Appl. Appl.
I/F
I/F
St ub
Loc atio n
OS Adapter
App Middleware
I/F Stub
App
App
OS
I/F
Middleware
HW
Location
Middleware
OS
OS
HW
HW
App Middleware OS
OS Adapter
App
HW App
Middleware
Middleware
OS
OS
HW
App
HW
Middleware OS App
HW
Middleware OS HW
App Middleware OS HW
App Middleware OS HW
Middleware
(cont.)
Goal: to support RPC programming between many heterogeneous systems Middleware as a distributed platform Introduction of a generic service: location of applications
I/F Location
App
App
I/F Stub
App
OS Adapter Middleware Middleware Middleware Middleware Middleware OS
OS
OS
HW
HW
HW
Middleware
(cont.) App
App
Goal: to allow the remote communication between many software programs largely distributed
App
Middleware
Middleware
Middleware
OS
OS
OS
HW
HW
HW
App Middleware OS App
HW App
Middleware
Middleware
OS
OS
HW
App
HW
Middleware OS App
HW
Middleware
!
App
App
OS HW
Middleware
Middleware
OS
OS
HW
HW
App
App
App
App
Middleware
Middleware
OS
OS
OS
HW
HW
HW
Middleware
App
Middleware
Middleware
OS
OS
HW
App
HW
Middleware
App
OS
Middleware
HW
OS
?
App
HW App
Middleware
App
App
Middleware
Middleware
App Middleware
Middleware
OS
OS
OS
OS
OS
HW
HW
HW
HW
App
HW
App
Middleware Middleware
OS App
OS
HW
App
HW Middleware App
OS HW
App
Middleware OS
App
Middleware
Middleware
OS
OS
HW
OS App
HW
HW
Middleware
HW
Middleware OS App
HW
Middleware OS
!
App
HW
App Middleware
Middleware
OS
OS
HW
HW
App Middleware OS HW
Middleware
(cont.)
Goal: to support RPC programming between many heterogeneous systems Middleware as a distributed platform Introduction of a generic service: location of applications Identification and routing of services Load Balancing I/F
I/F
I/F
Load B
Locatio n
Stub
OS Adapter
App
App
App
Middleware Middleware Middleware Middleware Middleware OS
OS
OS
HW
HW
HW
Middleware
(cont.) Who are you ?
I want to use a specific service
Appl. Appl.
I/F
I/F
St ub
Loc atio n
OS Adapter App Middleware
I/F Stub
App
App
OS
I/F
Middleware
HW
Location
Middleware
OS
OS
HW
HW
App Middleware OS
OS Adapter
App
HW App
Middleware
Middleware
OS
OS
HW
App
HW
Middleware OS App
HW
Middleware OS HW
App Middleware OS HW
App Middleware OS HW
Middleware
(cont.)
Goal: to support RPC programming between many heterogeneous systems Middleware as a distributed platform Introduction of a generic service: location of applications Identification and routing of services Load Balancing Identification & Authorization
I/F
I/F
I/F
I/F
I&A
Load B
Locatio n
Stub
OS Adapter
App
App
App
Middleware Middleware Middleware Middleware Middleware OS
OS
OS
HW
HW
HW
Middleware
(cont.) App
App
Goal: to allow the introduction of new services
App
Middleware
Middleware
Middleware
OS
OS
OS
HW
HW
HW
App Middleware OS App
HW App Middleware
OS
OS
HW
App
I can provide service ABCD
Middleware
HW
Middleware OS App
HW
Middleware
App
App
OS HW
Middleware
Middleware
OS
OS
!
App Middleware OS
HW
HW App Middleware
HW
App
App
App
Middleware
OS
OS
HW
HW
Middleware
Middleware
OS
OS
HW
App
HW
Middleware
App
OS Middleware
HW
OS App
HW App
Middleware
App
App
Middleware
Middleware
App Middleware
Middleware
OS
OS
OS
OS
OS
HW
HW
HW
HW
App
HW
App
Middleware Middleware
OS App
OS
HW
App
HW Middleware OS HW
App
App Middleware OS
App
Middleware
HW
Middleware
OS
OS
HW
OS App
HW
Middleware
HW
Middleware OS App
HW
Middleware OS App
HW
App Middleware
Middleware
OS
OS
HW
HW
App Middleware OS HW
Middleware
(cont.)
Goal: to support RPC programming between many heterogeneous systems Middleware as a distributed platform Introduction of a generic service: location of applications Identification and routing of services Load Balancing Identification & Authorization Brokering and Dynamic Association
I/F
I/F
I/F
I/F
I/F
I&A
Broker
Load B
Locatio n
Stub
OS Adapter
App
App
App
Middleware Middleware Middleware Middleware Middleware OS
OS
OS
HW
HW
HW
Middleware
(cont.) App
App
Goal: to secure the infrastructure and the communication
App
Middleware
Middleware
Middleware
OS
OS
OS
HW
HW
HW
App Middleware OS App
HW App Middleware
OS
OS
HW
App
I’m a security risk
Middleware
HW
Middleware OS App
HW
Middleware
App
App
OS HW
Middleware
Middleware
OS
OS
HW
HW App
App
App
App
Middleware
Middleware
OS
OS
OS
HW
HW
HW
App
Middleware
Middleware
Middleware
OS
OS
HW
App
HW
Middleware
App
OS
Middleware
!
OS HW App
HW App Middleware
App
App
Middleware
Middleware
App Middleware
Middleware
OS
OS
OS
OS
OS
HW
HW
HW
HW
App
HW
App
Middleware Middleware
OS App
OS
HW
OS HW
App
HW
Middleware
App
App Middleware OS
App
Middleware
HW
Middleware
OS
OS
HW
OS App
HW
Middleware
HW
Middleware OS App
HW
Middleware OS App
HW
App Middleware
Middleware
OS
OS
HW
HW
App Middleware OS HW
Middleware
(cont.)
Goal: to support RPC programming between many heterogeneous systems Middleware as a distributed platform Introduction of a generic service: location of applications Identification and routing of services Load Balancing Identification & Authorization Brokering and Dynamic Association Security Services I/F
I/F
I/F
I/F
I/F
I/F
Securit y
Broker
I&A
Load B
Locatio n
Stub
OS Adapter
App
App
App
Middleware Middleware Middleware Middleware Middleware OS
OS
OS
HW
HW
HW
Enriching the Middleware Platform
I/F
I/F
I/F
I/F
I/F
I/F
I/F
PROT OCOL
Securit y
Broker
I&A
Load B
Locatio n
Stub
OS Adapter OS
Specific or Proprietary Protocol
Network Element
Middleware
(cont.)
And many more services can be introduced – Generic ones (related to the platform working) – Problem domain specific
Middleware can be very complex
Protocol Dependence of the Middleware There is a strong dependence of middleware from the underlying protocols – Protocol expressive power can be abstracted by the middleware, i.e., part of protocol possibilities is hidden inside the middleware – Middleware can add functionalities to the protocols (i.e., functionalities that are not provided by the protocol) – A plain mapping between a protocol and a component not necessarily introduces a different state machine for the sw component (supporting the API) – Middleware can aggregate two or more protocols into a component, usually a composite state machine is created that is different from the two state machines of the single protocols. This may cause a loss in expressiveness
Protocol Dependence of the Middleware (cont.)
Application
Application
Application
LinkInstance
Upper Layer
Interface Instance
Abstraction should support different levels of granularity
Component Connector
LinkInstance
Basic Communication Layer
Aggregated Layer
LinkInstance Interface Instance
Interface Instance
Interface Instance
Interface Instance
Component
Component
Component
Component
Connector
Connector
Connector
Connector
Interface Instance
Interface Instance
Interface Instance
Interface Instance
Aggregation of protocols can lead to loss of functionalities LinkInstance Interface Instance
Interface Instance
Component
Component
Component
Component
Component
Component
Connector
Connector
Connector
Connector
Connector
Connector
SubArchInstance
SubArchInstance
SubArchInstance
SubArchInstance
SubArchInstance
SubArchInstance
END OF PROTOCOLS, APIS AND MIDDLEWARE 89
Module 15: Middleware 2 Can you list a few Middleware services? Can you differentiate between a service and an application? What is the protocol dependence of Middleware?
90
How Smart Objects will communicate
Client – Server model disregards the network aspects and can lead to a tragedy of commons (misuse of common networking resources) Network Intelligence (e.g., IMS) is a hierarchical model based on the assumption that control has to be exerted by a few specialized control nodes
Other mechanisms (message based like PubSub) can be more attractive for IoT
This is a reason for different IoT protocols … Is it there a single communication paradigm for IoT ?
91
Interactions with Things Ideally: • Few Primitives as in M2M_XML •Percept •Command •Response •Exception •Property • Simple Control: Events and Commands • Simple Semantic
(e.g., sensors)
Controller
Sensor Percept (temperature = 15^) Percept (temperature = 14^) Percept (temperature = 10^)
Command (“Start Heating”) Response (OK) Actuator
Many protocols are currently used: SensorML, COAP, MQTT, … each one adhering to a communication paradigm. Another Protocol Battle ? Figure from: http://www.wearable.ethz.ch/context_recognition.0.html 92
https://entrepreneurshiptalk.wordpress.com/2014/01/29/the-internet-of-thingprotocol-stack-from-sensors-to-business-value/
IoT Protocol Landscape
93 TSP/MSC Communication Networks and Services (ComNETS)
A Bit of Protocols
http://blog.zuehlke.com/en/iot-for-tiny-devices-lets-talk-mqtt-sn/
Constrained Application Protocol (CoAP) uses a REST-like approach offering resources with unique URI’s for consumption by CoAP clients or the setting and update of such resources.
MQTT (formerly Message Queue Telemetry Transport) is a publish-subscribe based "light weight" messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a "small code footprint" is required and/or network bandwidth is limited.
CoAP - Constrained Application Protocol • Constrained Application Protocol
•
•
• http://www.slideshare.net/zdshelby/coap-tutorial
95
•
(CoAP) is a software protocol to be used in simple electronics devices that allows them to communicate interactively over the Internet. It is targeted for small low power sensors, switches, valves and similar components that need to be controlled or supervised remotely, through standard Internet networks. CoAP is an application layer protocol that is intended for use in resource-constrained internet devices, such as WSN nodes. CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity Source: Wikipedia
CoAP (2)
http://www.slideshare.net/zdshelby/coap-tutorial 96
COAP Services
http://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison
Message Queuing Telemetry Transport
http://www.slideshare.net/BryanBoyd/mqtt-austin-api
MQTT (formerly Message Queuing Telemetry Transport) is a publish-subscribe based "light weight" messaging protocol for use on top of the TCP/IP protocol. It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited. The publish-subscribe messaging pattern requires a message broker. The broker is responsible for distributing messages to interested clients based on the topic of a message 98
MQTT
http://www.slideshare.net/BryanBoyd/mqtt-austin-api
99
http://www.slideshare.net/BryanBoyd/mqtt-austin-api
MQTT / Quality of Service
http://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison 100
MQTT vs. COAP Comparison MQTT and CoAP are both useful as IoT protocols, but have fundamental differences. MQTT is a many-to-many communication protocol for passing messages between multiple clients through a central broker. It decouples producer and consumer by letting clients publish and having the broker decide where to route and copy messages. While MQTT has some support for persistence, it does best as a communications bus for live data. CoAP is, primarily, a one-to-one protocol for transferring state information between client and server. While it has support for observing resources, CoAP is best suited to a state transfer model, not purely event based. MQTT clients make a long-lived outgoing TCP connection to a broker. This usually presents no problem for devices behind NAT. CoAP clients and servers both send and receive UDP packets. In NAT environments, tunnelling or port forwarding can be used to allow CoAP, or devices may first initiate a connection to the head-end. MQTT provides no support for labelling messages with types or other metadata to help clients understand it. MQTT messages can be used for any purpose, but all clients must know the message formats up-front to allow communication. CoAP, conversely, provides inbuilt support for content negotiation and discovery allowing devices to probe each other to find ways of exchanging data. Both protocols have pros and cons, choosing the right one depends on your application. http://www.eclipse.org/community/eclipse_newsletter/2014/february/article2.php 101
Advanced Message Queuing Protocol (AMQP) The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-to-point and publish-and-subscribe), reliability and security Source Wikipedia
102 http://www.slideshare.net/javierarilos/rabbitmq-intromsgingpatterns
http://www.sensorsmag.com/networking-communications/asensor-model-language-moving-sensor-data-internet-967
Sensor Model Language
SensorML provides standard models and an XML encoding for describing sensors and measurement processes. SensorML can be used to describe a wide range of sensors,. Functions supported include • sensor discovery • sensor geolocation • processing of sensor observations • a sensor programming mechanism • subscription to sensor alerts Source: wikipedia
Protocol Comparison
http://www.eetimes.com/author.asp?doc_id=1326169 104
Module 16: communications paradigms and IoT protocols What are some of the used communication paradigms in IoT ? What are some high level protocols used in IoT? Can you related a protocol to its communication paradigm?
105
FROM PROTOCOLS TO PLATFORMS 106
IoT Protocols Stack and initial Platform
107
Available inhttp://postscapes.com/internet-of-things-protocols Source: Butler project
Contiki Contiki is an open source operating system for networked, memory-constrained systems with a particular focus on lowpower wireless Internet of Things devices. Examples of where Contiki is used include street lighting systems, sound monitoring for smart cities, radiation monitoring systems, and alarm systems. Despite providing multitasking and a built-in TCP/IP stack, Contiki only needs about 10 kilobytes of RAM and 30 kilobytes of ROM. A full system, complete with a graphical user interface, needs about 30 kilobytes of RAM
108
http://www.mdpi.com/1424-8220/11/6/5900?trendmd-shared=0 Sensors 2011, 11(6), 5900-5930; doi:10.3390/s110605900
Protothreads Protothreads are cooperatively scheduled. This means that a Contiki process must always explicitly yield control back to the kernel at regular intervals. Contiki processes may use a special protothread construct to block waiting for events while yielding control to the kernel between each event invocation.
109
http://slideplayer.com/slide/2881229/
TinyOS
Sensor as a small computer it needs an Operating System
http://www.slideshare.net/snecute/tinyos
• • • • •
110
Modular • Components provide simple functions by means of well defined interfaces Event-Based Model Completely not Blocking Tasks are not-preempitive and run in FIFO order It is power efficient and it makes the sensor sleep asap
RIoT RIOT is a microkernel based architecture for distributed embedded systems with a strong focus on the Internet of Things Wireless Sensor Networks. The kernel is real-time capable and supports full multi-threading. Furthermore, it provides mutexes as well as synchronous and asynchronous message passing for interprocess communication. The scheduler is priority-based and uses a tickless timer system.
111
http://www.des-testbed.net/content/riot
ARM Operating System for IoT
http://hexus.net/tech/news/software/75357-arm-looks-supercharge-internet-things-mbed-os/ 112
Module 17: IoT Operating Systems What are the feature of an IoT operating system? Do you find similarities between the presented solutions? And what are the major differences? Can you relate these Operating System to Middleware? Are they the same?
113
The software for (Vertical and Horizontal Middleware) IoT
A further Step to Platforms
115
http://www.slideshare.net/AllSeenAlliance/wearables-and-iot-strategy
http://i.cmpnet.com/commsdesign/csd/2003/jul03/feat1-jul03-fig1.gif
Each Node (a mote) is a small computer A back-end platform for programmability
http://research.cens.ucla.edu/projects/2006/Systems/Tenet/figure_1.gif
Programming Wireless Sensor Networks
The Typical IoT Setup • Sensors, smart things will produce many data • Proprietary solutions based on different standards or no standard at all • Great Local Complexity • Service Center closed and proprietary (Vertical Solutions)
Server Aggregator
Eventi/Comandi
Sensors
There is the need to: • Decouple the local solutions form the in-network one (from a technical and business perspective – Virtualization and standardization) • Integrate data produced by sensors with the User Data Space 117
Towards IoT Platforms
Strong Emphasis on: • Programmability • Security • Data Analytics 118
http://www.networkworld.com/article/2687240/internet-of-things/internet-ofthings-roundtable-experts-discuss-what-to-look-for-in-iot-platforms.html
IoT Eclipse
119
http://www.slideshare.net/Eurotechchannel/kuram2miotgateway
Programmable Architecture Kura
http://www.slideshare.net/Eurotechchannel/kuram2miotgateway
120
IoT Eclipse
121
Allseen Architecture – based on alljoyn
From peer to peer communication to IoT architecture
http://www.slideshare.net/AllSeenAlliance/lfcs15-burns-v4 122
Allseen
123
Towards IoT Platforms Strong integration of sensing and data analysis
124 http://www.stagrp.com/internet-of-things/
Web Services and Sensors
http://www.commandinformation.com/blog/?p=73
Virtual Sense
Source: VirtualSense
An example - EPC Global
Applications: • • • • • • •
Logistics Supply chain Consumer Electronics Defense and Aerospace Media & Entertainment Automotive ...
Platforms
• Very focused solution • Vertical Application Domains http://java.sun.com/developer/technicalArticles/Ecommerce/rfid/sjsrfid/epcnetwork.gif
A Software Architecture for EPC Global • Interoperability issues
Signal Processing in Node Environment (SPINE)
http://spine.tilab.com/papers/2007/WhitePaper.pdf
Module 18: IoT platforms What are the advantages of the platforms? How do they compare to Operating systems? Are they specific or have a general applicability ? List the IoT platform that seems to you more general
130
IOT MIDDLEWARE 131
The Software Issue: What Platform for IoT Networks (the middleware and softwarization challenge) Apps Apps Apps
A choice between vertical and specialized platforms vs. horizontal and general purpose ones
Application Framework
IoT Platform Services
A Framework for developing Applications Distributed OS (comprising Local OSes) Sensors / Actuators/ Smart Objects
Sensor as a small computer it needs an Operating System providing for basic functions
Mobile Sensor API is an example of middleware service for Wireless Sensor Networks
Obviously there are many OSes for IoT (e.g., Contiki, …) Many European Projects are working towards this vision
g Layering as a fundamental architectural principle
A few Layering Principles emerging
Middleware for IoT
https://www.cs.virginia.edu/wsn/vigilnet/
• Layering • Components and APIs 134
Oracle’s view on Middleware for IOT
http://www.slideshare.net/junsukseo946/0-2-oracle 135
ALMANAC Smart City Platform architecture • Information aggregation •
Virtualization
http://www.in-jet.dk/en/articles.php?article_id=24
136
IoT-A Architecture
• • • •
http://iot-datamodels.blogspot.it/2012/09/data-models-for-internet-of-things5.html 137
Virtualization Management Security Orchestration
Web of Things
http://webofthings.org/2011/12/01/phd-web-of-things-app-archi/
An IoT Middleware View Terminal to Cloud Relationship
App Ecosystem Service/Apps Value
Mobile Device Platform
API Middleware Functions
Autonomics and Self Organization Communication Engine (e.g., event based)
Brokering of Virtual Objects Data Management
Objects management Objects Registry
API
API
Extensive Objects Virtualization
Native Operating System
Terminal to Capillary Relationship
Programmability Value
API
Ecosystem Value
Comm Value
Always Best Connected Comm. Processing
Things
Platform Value
Communications
T a g
Sensors
Tags
Storage
Others
Telco Building Blocks
Module 19: IoT Middleware platforms What are the services offered by relevant IoT middleware? What are their major differences? Can you relate the middleware platform to a specific communication paradigm?
140
STANDARDS 141
IEEE P2413 Scope •
•
This standard defines an Architectural Framework for the IoT, including descriptions of various IoT domains, definitions of IoT domain abstractions, and identification of commonalities between different IoT domains. The Architectural Framework for IoT provides: •
•
reference model that defines relationships among various IoT domains (e.g., transportation, healthcare, etc.) and common architecture elements reference architecture that: • builds upon the reference model • defines basic architectural building blocks and their ability to be integrated into multi-tiered systems • addresses how to document and mitigate architecture divergence.
•
blueprint for data abstraction and the quality "quadruple" trust that includes protection, security, privacy, and safety.
IEEE P2413 Definitions • The Group accepted the definition of the “Thing”: Apps & Services
Security Function/Method
The “Thing”
Properties Information Exchange
Notes: • Things, Apps, and Services can be integrated into what would be abstracted as a “Thing” • Information exchange could be “horizontal” (subscribe/publish as an example) or vertical, or both • Properties could be real or virtual
IEEE P2413 Levels of abstractions Level of Abstraction
IEEE P2413 Architectural Framework Reference Model Reference Architecture Applications and Services Universal Thing Description
Physical entity
Dish- Washing Lighting Guitar Weather washer machine system
Coffee Pressure Etc. maker transmitter
Universal Thing Description Who am I Who makes me What can I do Where do you go to get more info Who is asking What language do I talk
...
Things
Scope & Objectives Common set of Service Layer capabilities Access independent view of end-to-end services Open /standard interfaces , APIs and protocols Security, privacy, and charging aspects Reachability and discovery of applications Interoperability, including test and conformance specifications Identification and naming of devices and applications Management aspects (including remote management of entities Next Slides: courtesy of Enrico Scarrone – Telecom Italia
oneM2M – The Service Layer IoT Device Host
IoT Service Provider
Source
IoT Device
IoT Infrastructur IoT Server e
(Connected Living)
IoT Device Application
IoT Embedded Service Layer
Network
Application
Application Layer
IoT Service Platform
Service Layer
Network Layer 3G, 4G, LTE-M LoRa, Sigfox, Onramp
Break the silos and simplify the environment Pipe#2
Pipe#N
1 Application, 1 Network 1 (or few) types of Device
1 Application, 1 Network 1 (or few) types of Device
1 Application, 1 Network 1 (or few) types of Device
Business Application
Business Application
Business Application
Pipe#1
Horizontal (based on common Layer) Applications share common infrastructure, environments and network elements Business Application#1
Business Application# i
Business Application#N
Common Application Infrastructure Transport Network (mobile, fixed, Powerline ..)
Transport Network (mobile, fixed, Powerline ..)
Transport Network (mobile, fixed, Powerline ..) Transport Network 2
Transport Network 1 Gateway
Gateway
Gateway
Local NW
Local NW
Local NW
Devic e
147
Devic e
Devic e
IP Gatewa y
Local NW Devic e
Devic e
Devic e
Devic e
& provide the Interworking framework Simplification does not means one solution! Legacy technologies will continue to exist and needs to be integrated Specific technologies will be required in several sectors, for technical and commercial reasons TC SmartM2M solution is an interworking framework by means of a strict separation between communication and semantics aspects
oneM2M – The Service Layer Automotive Application
Home Application
Energy Application
Health Application
Common Service Layer Common functions applicable to different application domains Communication Devices & Hardware
Communication Technologies & Protocols
Communication Networks Automotive
Home
Energy
Health
Main Technical Specifications Requirements TS-0002
Functional Architecture
Definitions & Acronyms
Service Layer Core Protocols
(WI-0002)
(WI-0003)
(WI-0009)
TS-0001
(WI-0001)
TS-0011
TS-0004
HTTP Protocol Binding
CoAP Protocol Binding
Management Enablnt - OMA
Management Enablnt - BBF
(WI-0013)
(WI-0012)
(WI-0010)
(WI-0010)
TS-0009
TS-0008
MQTT Protocol Binding TS-0010 (WI-0014)
Security Solutions TS-0003 (WI-0007)
TS-0005
TS-0006
Service Components TS-0007 (WI-0011)
+ binding with web socket (under development) +full testing suite (under development) ftp://ftp.onem2m.org/Work Programme/
oneM2M: It is all about information management and sharing Service Enablement
Data Management
Management
Services
Services
Connectivity
Connectivity
Connectivity
Devices
Devices
Devices
Connectivity
Deployment
Integration
OneM2M standard is based on a “Store and Share” resource based paradigm. The data may be made available in the platform to the other applications, interested application are notified by means of subscription Privacy is ensured by a strict Access Control Management, which relies on underlying network security, providing a secure light solution oneM2M is heavily reusing underlying network functionalities, including TR069 and OMA DM management, LCS, subscription management, QoS, Charging, etc. OneM2M release 1 has been released January 2015.
Common Service Functions Registration
Discovery
Security
Group Management
Data Management & Repository
Subscription & Notification
Device Management
Application & Service Management
Communicatio n Management
Network Service Exposure
Location
Service Charging & Accounting
Module 20: Standardization What is an architectural framework and why is it impotant? What are the major functionalities (common services) to support in a IoT framework?
153
ONEM2M IN A NUTSHELL: PRINCIPLES, FUNCTIONS, ARCHITECTURE & API
oneM2M is Common API
Application Layer
Service Layer
AE
AE
Mca
Mca
Mca
CSE
CSE
CSE
Mcn Network Layer
AE
NSE
Mcc Underlying Network
Device
Mcn Mcn NSE Gateway
Mcc Underlying Network
Mcn
CSE Mcc’
NSE Server
Entities
AE (Application Entity), CSE (Common Services Entity), NSE (Network Service Entity
Reference Point
Mca, Mcn, Mcc and Mcc’
Other Service providers Server
OneM2M architecture entities AE: Application Entity, containing the application logic of the M2M solution like home management functions, fleet management, blood sugar monitoring CSE: Common Service Entity containing a set of common service functions (CFE) that are common to a broad range of M2M environment (verticals). This is the main part of the oneM2M specification CSF: Common Service Functions included in a CSE, CSFs can be mandatory or optional, CSF can contain sub-functions (mandatory or optional) NSE: Network Service Entity, provides network services to the CSE, like device triggering, device management support, location services. These services are related to the underlying network capabilities
156
OneM2M architecture Reference points Mca- Reference Points: the interface point between the AE and the CSE, the Mca point provides the M2M applications access to the common services included in the CSE. The AE and CSE my be co-located in the same physical entity or not Mcc- Reference Points: This is the reference point between two CSEs. The Mcc reference point shall allow a CSE to use the services of another CSE in order to fulfil needed functionality. Accordingly, the Mcc reference point between two CSEs shall be supported over different M2M physical entities. The services offered via the Mcc reference point are dependent on the functionality supported by the CSEs Mcn- Reference Points: This is the reference point between a CSE and the Underlying Network Services Entity. The Mcn reference point shall allow a CSE to use the services (other than transport and connectivity services) provided by the Underlying Network Services Entity in order to fulfil the needed functionality. Mcc‘- Reference Point: interface between two M2M service providers, As similar as possible to the Mcc reference point. But due to the nature of inter-M2M Service Provider communications, some differences are anticipated.
157
Full architecture: allowed configurations
Titolo della Relazione
oneM2M in a nutshell OneM2M is an IoT Interworking Framework • Designed to interwork with legacy, proprietary and sector solution. This is based on a separation between protocol interworking and semantic interworking. • Semantic interworking is already present in oneM2M Release 1, extention to full semantic support will be completed in oneM2M Release 2.
OneM2M is an IoT common Service Enablement layer • • • •
Service independent Distruibuited (Devices, Gateways, Network servers) Application portability Flexible: AE can have a specific client or connect directly to gateways or network server • Data can be stored in Devices, gateways or network server almost trasparently
oneM2M in a nutshell Main Characteristics • • • • • • • •
URI identification (and separation from IP addressing) IP based (irrelevant the version, IPv4 or IPV6) Network independent (but network aware!) REST approach Application protability Device and subscription management Accounting and charging HTTP/COAP/MQTT transport
Peculiary functions • • • • •
Store and share paradigm Data management and historization Separation among Security and Privacy Flexible deployment (large, small, distributed, centralized) Network functionality re-use (Location, Device Management, Security, etc)
Module 21: oneM2M What are the functional entities and their reference points? – What is a functional architecture?
What are the major characteristics of oneM2M ?
161
Industrial Internet Consortium
162
Sources: Architecture of Industrial Internet by S. Mellor And IIC reference architecture http://www.iiconsortium.org/IIRA-1-7-ajs.pdf
IIC - Functional View
163
Key System Functionalities
164
Module 22: Industrial Internet Consortium What is the aim of the Industrial Internet Consortium? What are some major functionalities for supporting the Industrial Internet?
165
Agenda – Internet of Things The Context of IoT A Definition of IoT A few Challenges of IoT What Things are … Networks of Things Technologies of Communications – – – – –
Access Technologies Protocols SW Platforms Middleware Standards
IoT Challenges – Identity, Data, and Ownership – Complex System – Business Issues – Social Issues
Virtual Continuum IOT Scenarios The IEEE IoT Initiative
IoT, Identity and Data: a Conundrum
Where are the Data: Wireless Sensor Network Aggregation
http://www.mdpi.com/1424-8220/9/6/4845/ag
http://www.easinet.cn/photo/coalmine.jpg
Plenty of Data … distributed locally and remotely Aggregation function and dispatching functions are fundamental
How Many Nodes, How Many Messages, How Much Bandwidth ? The Bandwidth challenge …
•
•
•
Gateways/Aggregators will greatly reduce the number of messages forwarded on public networks
60
Multimedia (video) will be the major cause for traffic Many objects/nodes will come with communications already paid for (i.e., embedded communications) Pure bit transport is not a big value for Operators
52,56 36,50
Equivalent Volume as the one generated by 20 M users (3 min phone call per day)
40 30
21,90
20 10 0
169
10 M Aggregators Message size: 10 kB
50
Millions GB/Year
•
Issue: low average traffic, but highly impulsive traffic (e.g., spikes of messages when containers ships enter in a harbor)
0,11
13
0,37 2 10
3,65
3 4 100 600
5 6 1000 1440
Message / Day
How much Data (and traffic)?
= 2.33 MB /Day
= 12.2 MB /Day
= 27 Byte /s
= 141 Byte /s
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-indexvni/white_paper_c11-520862.html#Trend_3_Measuring_Mobile_IoE
Module 23: IoT and Connectivity Is connectivity a viable business model for IoT? Why ? What will the biggest source of traffic be in the future?
171
Where is the Value then ? Knowledge Information Data
• Relationships • Inference • Aggregation • Personalization
The Big Data Challenge …
172
The Data and Knowledge Path
Examples of (simple) metadata
http://www.kcoyle.net/meta_purpose.html
•Abstraction & richness of information •New Usages
Data Mining From Data To Information Extracting Value from Data
http://www.ais.uni-bonn.de/images/Neural_Abstraction_Pyramid.png 175
The Semantic Web Representing Data and deriving Knowledge
However Big Data is all about non structured data
http://www.w3.org/2000/Talks/1206-xml2k-tbl/
176
DataWeb
(ref.: The Dataweb: An Introduction to XDI - White Paper for the OASIS XDI Technical Committee)
Linking the data and protecting them
The goal of XDI is to enable data from any data source to be identified, exchanged, linked, and synchronized into a machine-readable dataweb using XML documents just as content from any content source can linked into the human-readable Web using HTML documents today. 177
MetaData and Multimedia
Extracting Information from different types of data
http://www.fim.uni-passau.de/fim/fakultaet/lehrstuehle/verteilte-informationssysteme/forschung/content-adaptation.html 178
► Data
have to be exchanged between different networks ►There will be the need to have network capabilities
►
Data will create complex relationships ► ► ►
►
► Data
Self-organizing systems MetaData Trust, Security and Privacy New control Patterns
will be everywhere
►There is the need to transform data into useful information
►
Security and Trustiness will become more and more important ►
179
How reliable are data? How secure?
http://4.bp.blogspot.com/_gRI2ONg6q6k/SQddil-kw_I/AAAAAAAAAAo/jIpsSSGkn50/s1600-h/Ambient+Computing.png
Some Consequences
Module 24: the data path Where value can be extracted from? What is metadata? What are some technologies for extracting information from data?
180