social sensor cloud: an architecture meeting cloud-centric iot … · 2014-07-15 · survey of...
TRANSCRIPT
tknlogo
Social Sensor Cloud: An Architecture MeetingCloud-centric IoT Platform Requirements
9th KuVS NGSDP Expert Talk
Thomas Menzel Niels Karowski Daniel Happ Vlado HandziskiAdam Wolisz
Telecommunication Networks Group, TU Berlin
2014-04-09
Thomas Menzel Social Sensor Cloud April 2014 1
tknlogo
The Internet of Things
Connect everything and everyone everywhere to everything andeveryone else
Platform abstracting services of trillions of interconnected devices
Providing interoperability in face of heterogeneity
Enabling diverse applications over a shared hardware resourcesubstrate
Thomas Menzel Social Sensor Cloud April 2014 2
tknlogo
The Cloud
Computing resources as utility with elastic demand matching
Core enablers:
Server virtualizationReliable distributed storageFast networking
Benefits
FlexibilityReliabilityPay-as-you-go
Thomas Menzel Social Sensor Cloud April 2014 3
tknlogo
Cloud-supported Internet of Things
Cloud services as abstraction layer for IoT
Popular approach followed by many academic and commercialplatforms
Thomas Menzel Social Sensor Cloud April 2014 4
tknlogo
Existing Solutions
ETSI (one)M2M, Xively, Etherios, SENSEI, Sensor Andrew,FI-WARE, OSIOT, Axeda, OpenIoT, EVRYTHNG, RuBAN,openHAP, ioBridge . . .
Architecture
Natural decompositionExplicit differentiation: data generators vs. consumers (but: Xively,ETSI M2M)
Value-added services
Data storageVirtual sensorsDevice management
Application-side Platform Access
ProtocolsEncoding formatsInteraction patterns
Thomas Menzel Social Sensor Cloud April 2014 5
tknlogo
Shortcomings of Existing Solutions
Service APIs:
Insufficient support for low-latency real-time data streamingInsufficient system integration for event-triggered interaction patterns
Rigid decoupling
Missing support for cross-layer optimizationDevice tier operation not adapted to QoS requirements of runningapplications leading to reduced lifetime of battery operated sensors
Storage-centricity
Focus on archival of all generated data, independent from real level ofinterest in the dataRequires high initial investments and operational costs
Thomas Menzel Social Sensor Cloud April 2014 6
tknlogo
SSC Project Goals
Reference system architecture . . . addressing these shortcomings
Prototypical implementation
Evaluation
Thomas Menzel Social Sensor Cloud April 2014 7
tknlogo
SSC Approach
Natural decomposition . . .
Differentiation:
Fine-grained architectureFeatures of the offered services and APIs
Thomas Menzel Social Sensor Cloud April 2014 8
tknlogo
SSC Architecture Overview
Thomas Menzel Social Sensor Cloud April 2014 9
tknlogo
High-Level Architecture Concept
Functional decomposition in four tiers
Application TierCloud Service Tier (CST)Cloud MoM Tier (CMT)Sensor Device Tier (SDT)
Interaction via three well-defined APIs
Open Sensor Application APIOpen Sensor Service APIOpen Sensor Device API
Thomas Menzel Social Sensor Cloud April 2014 10
tknlogo
Cloud Service Tier
Simple development of IoT applications
Fast and flexible discovery
Discovery of servicesDiscovery of data streams
Efficient data delivery
SynchronousEvent-triggeredLow-latency streaming
Value-added services
Aggregation of multiple streamsSpecification of composite eventsQuery injection and reconfiguration
Thomas Menzel Social Sensor Cloud April 2014 11
tknlogo
Main Cloud Service Tier Components
Thomas Menzel Social Sensor Cloud April 2014 12
tknlogo
Cloud MoM Tier
Efficient data dissemination
Flexible publish / subscribe service fordissemination of data and control metadata
Dynamic cross-layer optimization
Merging of overlapping sensor data queriesand piggybacking of notifications andadvertisementsCalculation of a query ”cost” metric based onexpected system effortsExpressing latency requirements allowingintelligent caching and larger freedom toreschedule/combine/defer queries
Thomas Menzel Social Sensor Cloud April 2014 13
tknlogo
Main Cloud MoM Tier Components
Thomas Menzel Social Sensor Cloud April 2014 14
tknlogo
Sensor Device Tier
Integration of heterogenous sensor technologies
Standardized data interface, sensor descriptionand discovery
Horizontal and vertical discovery
Based on proactive advertisementsInverts the current poll/crawling methodMetadata for parametric-based searchLow-frequency data for data-based search
Device network optimization
Flexible data cachingDynamic device parameter adaptation
Thomas Menzel Social Sensor Cloud April 2014 15
tknlogo
Main Sensor Device Tier Components
Thomas Menzel Social Sensor Cloud April 2014 16
tknlogo
End.
Thank You!
Comments/ Questions?
Thomas Menzel Social Sensor Cloud April 2014 17
Survey of Cloud-centric IoT Platforms
Thomas Menzel, Niels Karowski, Daniel Happ, Vlado Handziski, Adam WoliszTechnische Universität Berlin, Telecommunication Networks Group (TKN)
{menzel, karowski, happ, handziski, wolisz}@tkn.tu-berlin.de
Summary—The Internet of Things (IoT) platforms supportrapid development of applications focused on gaining enhancedawareness and control of the physical environment. In contrast tothe traditional, vertically integrated model, IoT platforms aim atsupporting a much broader set of applications on top of a sharedhardware base of diverse sensing and actuation devices. In thiswork we survey several IoT solutions and extract their featuresalong different design dimensions. We address several limitationsin these existing platforms. Finally, we present our recent workon a novel IoT platform that deals with these shortcomings,developed in the context of the Social Sensor Cloud project.
I. CLOUD-CENTRIC IOT PLATFORMS
In the envisioned Internet of Things (IoT) solutions, hugeamounts of data from billions of interconnected devices willhave to be distributed in an efficient manner, imposing newchallenges on the communication and processing infrastruc-ture. Cloud computing is well positioned to meet gracefullythese requirements thanks to its flexibility, reliability andusage-based cost model. We therefore expect future IoT plat-forms to be cloud-centric with a similar general architectureas the one shown in Figure 1 [1]. At high-level, sensor datafrom the device tier is sent to a cloud-based service tier, whichprovides access to the data as well as additional serviceslike data storage, analysis, aggregation, etc. to user facingapplications.
In Section II, we present the results of our survey ofseveral prominent academic and commercial IoT platforms.We extract the most important characteristics of their Appli-cation Programming Interfaces (APIs) that capture the diverserequirements imposed on the service tier. In Section III, webriefly introduce the Social Sensor Cloud (SSC) [2] project inwhich we have defined a new IoT architecture that addressesidentified shortcomings in the existing solutions.
II. IOT PLATFORM ANALYSIS
We have surveyed several prominent IoT solutions andextracted their features along different design dimensions,e.g. platform architecture, offered value-added services, andapplication side platform access. Table I provides a list of thesurveyed IoT platforms.
IoT DeviceTier
IoT
Dev
ice
API
CloudService Tier
IoT
Serv
ice
API
IoT
App
licat
ion
Fig. 1: General architecture of a Cloud centric IoT platform.
The vast majority of surveyed platforms explicitly dif-ferentiate between data generators and consumers, offeringseparate APIs for interacting with the devices from one side,and the served applications from the other. As a result, theircoarse architecture is similar to the one depicted in Figure 1.Xively is an example of a different approach that uses aunified API towards the generators and consumers of data.In almost all platforms, gateways are used to mediate andintegrate devices that lack native IP connectivity. Despitetheir importance for implementing Cyber-Physical Systemsapplications, actuator devices are explicitly supported only byfew academic solutions.
Value-added services such as data storage, virtual sensorsand device management, represent another important dimen-sion for comparison.
Data storage services archive information generated bydevices as part of the offered services of the IoT platform.The storage of data allows IoT providers to offer additionalfunctionalities such as historical search operations and dataaggregation. This service is supplied by the majority of theanalyzed IoT platforms, even though some platforms (e.g.openHAB) do not provide integrated storage solutions but re-sort to transparent integration with external services to achievethe same goal.
The concept of virtual sensors enables the combination ofmultiple sources of information into a composite data source.Data generated by different physical devices can be processedand presented as a new source of information. A commonexample of a virtual sensor is the computation of the dew point.Information about temperature and relative humidity measuredby different sensors can be combined in order to compute thedew point and the result can be offered as a new data source, avirtual dew point sensor. In the surveyed platforms, the conceptof virtual sensors is mostly prevalent in the area of research-oriented solutions, e.g. Sensor Andrew, and standardizationactivities (ETSI M2M, OSIOT and OpenIoT), while it is lessrepresented in the commercial area (with the exception of theopen-source openHAB platform).
Due to the envisioned high number of connected devicesan important service of an IoT platform is to support users inmanaging their devices, starting from adding and removingsingle devices to handling batches of devices. Such devicemanagement services are offered by all analyzed IoT plat-forms.
Providing uniform access to the gathered, processed andstored device data is one of the core responsibilities of everyIoT platform. We identified protocols to interact with theplatforms, encoding format and interaction pattern as keyfeatures for characterizing application-side platform access ofthe IoT platforms as shown in Table I:
• Protocols – All current platforms support RESTfulHTTP access. Only a selected few also offer moreefficient access via (Web)Sockets or raw MoM inter-faces.
• Encoding – XML and JSON are the leading dataencoding formats and many platforms support both.
• Interaction – In addition to simple request/responsecommands, many platforms also offer more flexibleinteraction patterns and mechanisms such as sub-scription to configurable data feeds or streams andnotification in case of application defined events usingpush messages.
TABLE I: Application side platform access.
Protocols Encoding Interaction
HT
TP
Raw
MoM
Other XM
L
JSO
N
Other Req
/Res
p
Pub/
Sub
Push
ETSI (one)M2M [3] X CoAP X X X X XXively [4] X X Socket X X CSV X X XEtherios [5] X X X X XSENSEI [6] X SIP X X X XSensor Andrew [7] X X X CSV X X XFI-WARE [8] X X X X X XOSIOT [9] X X CoAP X X X XAxeda [10] X X propr. X X ASN.1 X X XOpenIoT [11] X Socket X X CSV X X XEVRYTHNG [12] X X XRuBAN [13] X X X X XopenHAB [14] X X X X X X XioBridge [15] X X X X X
While some of the evaluated platforms make use ofthe underlying networks’ QoS capabilities, only Axeda usesmessage priorization and only OpenIoT targets QoS supportbetween the application and device tiers. Furthermore, onlySENSEI and OpenIoT try to increase the platform efficiencyby leveraging cross layer/tier optimization approaches.
III. SOCIAL SENSOR CLOUD
We have so far described several academic and commer-cial IoT platforms. Nevertheless, we believe that there aresome important shortcomings in these existing solutions. Mostplatforms offer limited service APIs that lack support forevent-triggered interaction patterns. Their request/reply andpolling focus leads to unnecessary sampling, high latencyand communication costs especially over bandwidth limitedlinks and reduced lifetime of battery-powered devices. Themajority of platforms also follows a very rigid decouplingbetween the different architectural tiers, thus missing on op-portunities for cross-layer/tier optimization such as expressionof latency, reliability and cost requirements that can be usedto improve the efficiency of the platform, especially in thedevice tier with many battery-operated devices operating underconstrained communication and energy budgets. Finally, mostof the platforms follow a storage-centric operation modelfocused on archival of all data generated by the connecteddevices, an approach that is not scalable to the massive numberof envisioned interconnected devices, due to the high initialinvestment and operational costs for storage.
In the context of the Social Sensor Cloud (SSC) [2]project, we are currently working on a novel IoT platform
Clo
ud
MoM
Tie
rC
loud
S
ervi
ce T
ier
App
licat
ion
Tier
Sen
sor
Dev
ice
Tier
Open Sensor Device API
Open Sensor Service API
Subscription Manager
Cost Manager
Sensor Discovery
Custom Services Sensor
Data CacheMoM Broker
Service Search Engine
Service Managers
Stream Search Engine
Open Sensor Application API
Mobile Apps.
Native Clients
Web Apps.
Data-bases
Streaming Manager
On
Clo
ud
Sensor Network Car Phone
Device Manager802.15.4
#1802.15.4
#2802.15.1
#1EN13757-4
#1
Subscription Manager
Parameter Manager Resolver
Caching/ProcessingManager
On
Pre
mis
eO
n C
lient
Fig. 2: SSC architecture overview.
that addresses these shortcomings from the point of view ofscalability, efficiency and supported services. The architectureof the platform is based on the functional decomposition infour tiers as shown in Figure 2.
The highest tier of the architecture, the Application Tier,encapsulates the different user-facing applications to be devel-oped on top of value added services provided by the CloudService Tier. It therefore technically does not belong to ourproposed platform. To meet different application requirements,developers may express latency requirements as well as otherQoS parameters using the Open Sensor Application API.
The Cloud Service Tier (CST) reduces the complexity ofdeveloping IoT applications residing in the Application Tier byhosting cloud-based value added services and providing fastand flexible data stream and service discovery. The ServiceSearch Engine provides the search possibility of the valueadded services, e.g. aggregation of multiple data streams,possibility to specify composite events as well as query injec-tion and reconfiguration. Each provided service is representedby a Service Manager. The discovery of data streams isa native service supplied by the CST through the StreamSearch Engine and Streaming Manager. The Open SensorApplication API of the CST offers a synchronous REST-based web-interface as well as a Websockets interface whichallows applications to receive event-based push notificationsusing pre-defined expressions instead of applying continuouspolling to check for updates. Furthermore, in order to guar-antee efficient data delivery besides supporting synchronousrequest/response interaction and event-triggered notifications, araw content-based publish/subscribe interface provides accessfor high-performance applications.
The Cloud MoM Tier (CMT) is the central tier supportingefficient data dissemination using a flexible publish/subscribe
service as well as point-to-point communication for the distri-bution of data and control metadata. The central componentof the publish/subscribe service is the MoM Broker whichconnects producers and consumers of data. A major goalof the SSC platform is the shared utilization of sensors bymultiple applications. Requests of applications with specifiedand similar QoS requirements are merged by the SubscriptionManager to avoid unnecessary sensor sampling by devices. Toprevent applications from using the highest QoS always, theCost Manager may be utilized to associate “costs” to e.g. eachdata retrieval. A Sensor Discovery Manager subscribes to pro-active advertisement messages transmitted by devices in theSensor Device Tier and stores the obtained data in a SensorData Cache in order to provide sensor search functionality.Historical search is enabled by low-frequency data streamsperiodically sent from devices. To support the huge number ofenvisioned IoT devices, only aggregated data, e.g. minimum,maximum, average, is stored in the CMT.
The Sensor Device Tier (SDT) enables not only the integra-tion of heterogeneous device technologies using a standardizeddata interface, but also provides the functional basis to supportthe novel services of the upper SSC tiers. Application-side QoSrequirements are managed by the Subscription Manager whilethe Parameter Manager stores the controllable parametersof the connected networks and devices. The matching isperformed by the Resolver and the resulting parameters areapplied by the Device Manager and the Caching/ProcessingManager who forwards the data accordingly to the upper tiervia the Open Sensor Device API. Instead of applying the oftenused method of polling and crawling for new devices, thedevice discovery is based on pro-active advertisements.
IV. CONCLUSIONS
In this paper we have surveyed several prominent IoTsolutions and extracted their features along different design di-mensions such as the properties of their platform architecture,offered value-added services, and application side platformaccess. All current platforms support RESTful HTTP accessand few also offer more efficient access via (Web)Sockets orraw MoM interfaces. XML and JSON are the leading dataencoding formats. We claim that there are several limitationsin the existing IoT platforms such as lacking support of QoSand cross layer optimization. In the context of the SocialSensor Cloud project, we are currently working on a novelIoT platform that addresses these shortcomings from the pointof view of scalability, efficiency and supported services.
REFERENCES
[1] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet ofThings (IoT): A vision, architectural elements, and future directions,”Future Generation Computer Systems, 2013.
[2] Ssc. [Online]. Available: http://www.azeti.net/social_sensor_cloud.html[3] Etsi m2m. [Online]. Available: http://www.etsi.org/
technologies-clusters/technologies/m2m[4] Xively. [Online]. Available: http://xively.com[5] Etherios. [Online]. Available: http://www.etherios.com[6] Sensei. [Online]. Available: http://sensei-project.eu[7] Sensor andrew. [Online]. Available: http://sensor.andrew.cmu.edu[8] Fi-ware. [Online]. Available: http://www.fi-ware.eu[9] Osiot. [Online]. Available: http://osiot.org
[10] Axeda. [Online]. Available: http://axeda.com[11] Openiot. [Online]. Available: http://openiot.eu[12] Evrythng. [Online]. Available: http://evrythng.com[13] Ruban. [Online]. Available: http://www.davranetworks.com[14] openhab. [Online]. Available: http://openhab.org[15] iobridge/realtime.io. [Online]. Available: http://www.iobridge.com