Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Challenges
Discovery
Physicalobjects
Dealingwith places
Dataservices
Powersource?
Distri-bution
Delaytolerance
Asynchrony
Unreliablemessaging
Security
Integrity
Privacy
Owner’sOthers’
Trust
Provenance
Gover-nance
Autonomy
Decen-tralization
Sharingthings
Usability
Identifying
Visualizing
Manip-ulating
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 126
ResearchApproach
Require-ments
Datastreams
Loggingdata
Decen-tralization
Governance
Explicitmodeling
Causality
Integrity
Privacy
Account-ability
Enactment
Autonomyrespecting Asyn-
chronous
Decoupled
Supportstracing
Gover-nance
Sharingthings
Normativebasis
Vividmodeling
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 127
Contract Net Protocol: 1Announce
Sensor Sensor Sensor
Sensor Manager Sensor
Sensor Sensor Sensor
advertise advertise advertise
advertise advertise
advertise advertise advertise
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 128
Contract Net Protocol: 2Bid
Sensor Sensor Sensor
Sensor Manager Sensor
Sensor Sensor Sensor
bid
bid
bid bid
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 129
Contract Net Protocol: 3Award
Sensor Sensor Sensor
Sensor Manager Sensor
Sensor Sensor Sensor
award
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 130
Contract Net Protocol Evaluated
I Generic protocolI Can apply recursively
I Supports important propertiesI Robustness against sensor failureI Robustness against connectivity failureI Incorporating economic features
I Not well specifiedI Confuses interaction and internal reasoningI Limited to two-party interactions
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 131
Main Architectural Elements
Things Middleware Applications Users
DiscoverySelection
Sensors StorageUser
Interface yActuators Monitoring Reasoner x
Control
IoT emphasizes ownership
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 132
Decentralization Calls for a Multiagent ArchitectureEach agent represents an autonomous party, contains a reasoner; interact within Org
Org
UserInterface
UserInterface
KnowledgeBase
Agent AgentKnowledge
Base
StreamProcessing
StreamProcessing
Adapter& Thing
Adapter& Thing
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 133
Emerging Standards Support Decentralization in Principle
Application
AuthenticationBootstrapping
ServiceCapability
Gateway
Device
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 134
Based on ETSI draft TS 102 690, May 2014, 〈http://docbox.etsi.org/smartM2M/Open/Latest_Drafts/〉
Comparing Traditional Web and IoT ProtocolsFrom ReST to Constrained RESTful Environments (CoRE)
HTTP Application layerMQTTCoAP
TCP Transport layer UDP
IPv4IPv6
Network layer6LoWPAN
Zigbee
EthernetWiFi
Data link layer IEEE 802.15.4
InformationResource
Thing
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 135
Protocol: MQTTNee Message Queue Telemetry Transport
I OASIS standard as of November 2014, v3.1.1
I Focused on machine-to-machine communications
I Asynchronous
I Data parsimoniousI Small set of primitives, including
I PublishI SubscribeI Create and cancel subscriptionsI Configure “last will and testament” (LWT) notifications
I Detect disconnections without a disconnect messageI Send configured LWT notifications
I Three QoS levels (separately specified by sender and receiver)0 At most once; message: publish; no message ID needed1 At least once; resend with dup bit until puback received2 Exactly once; server stores, then forwards to receivers
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 136
CoAP: Constrained Application Protocol
I IETF RFC 7252, June 2014
I Asynchronous
I Data parsimonious
I Supports URIs
I Supports resource discovery from server
I HTTP-like verbs: get, put, post, delete
I Small set of request and response typesI Communication patterns
I CachingI Block transfer of large content
I QoS support (message types)I Confirmable con: require acknowledgmentI Nonconfirmable non: do not require acknowledgmentI Duplicates to be ignored by receiver
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 137
CoAP Tooling: Copper Plugin for FirefoxDisco
very
Commands
Headers
Payload
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 138
Credit: Matthias Kovatsch, 〈http://people.inf.ethz.ch/~mkovatsc/copper.php〉
AMQP: Advanced Message Queuing Protocol
I OASIS standard as of October 2012, v1.0
I Protocol—distinguish from an API such as JMS
I Decouples communications from destination address
I Long-lived conversationsI Variety of communication patterns
I InterceptI DelegateI Multiplex and demultiplex
I Upcoming improvementsI Traffic flow and QoSI Decentralized deployment and governanceI Multiple underlying protocols
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 139
AMQP Exchange Space Abstraction
Sensor Broker Broker Consumer
Local AreaExchange
Wide AreaExchange
Local AreaExchange
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 140
Based on work with Ocean Observatories Initiative, UCSD Scripps
XMPP: Extensible Messaging and Presence ProtocolOriginally meant for collaboration and content sharing
I Adapted and enhanced for IoT via XMPP Extension Protocols
I XEP-0323: Internet of Things – Sensor Data, v0.4, March 2015I Describes protocols and data formats for variety of needs
I Request sensor reading and responses theretoI Requests with multiple responsesI Requests to multiple thingsI Discovery: what features (including services) a thing supports
I Different from discovery of a thing
I Specification of quality of data value (termed QoS), e.g.,I Missing, estimated, manually read, delayed, invoiced, . . .
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 141
XMPP: Extensible Messaging and Presence Protocol
I XEP-0347: Internet of Things – Discovery, v0.3, November 2014I Uses JID or Jabber ID or an XMPP address for various resources
I RegistriesI Provisioning serversI Things
I Specifies protocols and data formats forI Finding a registryI Registering a thing: a thing registers itself
I Specifies secret data for registrationI May provide the same data via a sticker (QR-code) on a physical thingI Public things remain searchable after being claimed
I Owner claiming a thing (by supplying the secrets)I Only claimed, currently owned, things can be searched
I Removing a thing from a registryI Disowning or relinquishing a thing
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 142
Cloud StorageEliminate need to set up complex storage services from scratch
I On demand
I Variety of dataservices
I NoSQL (andNewSQL) databases
I Alternative toACID databases
I Tradeoff strongconsistency forlow latency
Cloud Storage
Database
File system
ReplicationLoad
balancing
Contentdelivery
networking
Memorycache
Sensors
Data
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 143
Cloud ServicesQuerying and transforming data
I Structured Query Language (SQL)
I Rule engines
I Complex event processing (CEP)I Streaming SQL
I Continuous queriesI SQL-interface for event processing
I MapReduce programming
I Hosting and executing custom programs
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 144
ETSI’s Service Capability LayerOn top of connectivity: holdall for functional, security, and governance aspects
I CommunicationI Semisynchronous: quick ack followed by full answerI AsynchronousI Works on top of another protocol, e.g., HTTP and CoAP
I Service capabilitiesI RegistrationI Access controlI AuthenticationI Data transferI Subscribe and notifyI Handling groups
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 145
Fog ComputingCisco’s term for decentralized or “ground-level” variant of cloud computing
I Intermediary between things and the cloud (data centers)
I Place computing, storage, services near the edgeI Process data closer to where it originates
I Many devices talk to one anotherI Improve latency and throughput
I Improves treatment of autonomy with gains inI Local governanceI Security
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 146
Event-Driven ArchitectureConsume and produce event streams
I Event attributes: ID, timestamp, and content values
Sensor 0
Sensor 1 Rule A Rule B
Sensor 2
(Alerts) (Threats)
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 147
Linked Data Highlights
I Web-based identity and networkI URIs identify resourcesI Deferencing a URI produces a resource descriptionI Resources link to other resources
I Web-based semanticsI Encoded in a Semantic Web language, such as the Resource
Description Framework, RDF
I Exploit underlying architecture, e.g., Domain Name System and Webservers, to locate resources
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 148
Linked Data for IoTSensor data is worthless unless linked to something else!
I Describe thingsI Link thing descriptions to one anotherI Enable thing discovery
I Describe the information produced by things
I Describe how to configure thingsI Enable things to exchange semantic information
I Facilitate reasoningI Promote interoperability
I Supported by standards that incorporate URIsI CoAP, ETSI’s Service Capability Layer
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 149
Realizing IoT
Asyn-chrony
Publish-subscribe
Topics
Streams
Selection Registering
Discovering
Descrip-tion
QoS spec-ification
Enactment
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 150
SelectionCriteria
Device
Sensedattribute
Perfor-mance
Latency
Through-put
Quality
Precision
Powerprofile
Datavolume
Envi-ronment
Location
Nearbydevices
Mobility
Contextawareness
Vehicles
Approach
Semanticquery
Similarity
EconomicSocialOwner oroperator
Reputation
Price
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 151
SemanticDescriptions
Ontologies
Content
Qualityof service
Social re-lationships
Semanticservice de-scriptions
InputsOutputs
Precon-ditions
ResultsInteractiondescrip-
tions
Data types
Protocols
Normativeexpec-tations
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 152
History-BasedSelection
Reputation
Sharing
Main-taining
Trust
Engen-dering
Estimating
CredibilityProvenance
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 153
Sensor WebEnablementStandards
Services
Registry
Obser-vation
Alert sub-scription
Planning
Notificationdialogue
Infor-mationmodels
SWEcommon
data model
SensorML v2.0,Feb 2014
Obser-vations
and mea-surements
AssociatedtopicsLocation,
v1.2,Sep 2008
Indoorgeospatialmarkup,
Dec 2014
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 154
Credit: OGC Network, 〈http://www.ogcnetwork.net/〉
Safety: Approved Access UnsafeRemoved local conflict between accept and reject
Approved Access Unsafe {role Reques te r , C o n t r o l l e r , Sourceparameter out ID key , out item , out outcomeprivate token , v a l u e //REMOVED: r e s p o n d e d
R e q u e s t e r 7→ C o n t r o l l e r : r e q u e s t [ out ID , out i tem ]C o n t r o l l e r 7→ R e q u e s t e r : a c c e p t [ in ID , in
item , out token ] // , out r e s p o n d e dC o n t r o l l e r 7→ R e q u e s t e r : r e j e c t [ in ID , in item , out outcome ]
// , out r e s p o n d e dC o n t r o l l e r 7→ Source : ask [ in ID , in item , in token ]Source 7→ R e q u e s t e r : p r o v i d e [ in ID , in item , in token , out
v a l u e , out outcome ]}
I controller can send both accept and reject
I Thus outcome can be bound twice in the same enactment
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 155
Liveness: Approved Access Minus AskOmitted the ask message
Approved Access Minus Ask {role Reques te r , C o n t r o l l e r , Sourceparameter out ID key , out item , out outcomeprivate token , responded , v a l u e
R e q u e s t e r 7→ C o n t r o l l e r : r e q u e s t [ out ID , out i tem ]C o n t r o l l e r 7→ R e q u e s t e r : a c c e p t [ in ID , in item , out token , out
r e s p o n d e d ]C o n t r o l l e r 7→ R e q u e s t e r : r e j e c t [ in ID , in item , out outcome ,
out r e s p o n d e d ]// C o n t r o l l e r 7→ Source : ask [ in ID , in item , in token ]Source 7→ R e q u e s t e r : p r o v i d e [ in ID , in item , in token , out
v a l u e , out outcome ]}
I If controller sends reject, the enactment completes
I If controller sends accept, the enactment deadlocks
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 156
Safety and Liveness Violations
R C S
Approved Access Unsafe
Safety Violation
request
accept
ask
reject
provide
R C S
Approved Access Minus Ask
Liveness Violation
request
accept
provide
Cannot occur
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 157
IoT Hourglass: Few Platforms for Many ApplicationsBenefit from the upper layers; excitement from the lower layer
Consumers Providers
Applications
Platforms
Infrastructure
Devices
Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2015 158