Towards a Resource Slice Interoperability Hub for IoT

Towards a Resource Slice
Interoperability Hub for IoT
Hong-Linh Truong
Faculty of Informatics, TU Wien, Austria
hong-linh.truong@tuwien.ac.at
http://rdsea.github.io
3rd Globe-IoT@IC2E, 17 April, 2018, Orlando 1

Acknowledgements:
Supported by
H2020 Inter-IoT (http://www.inter-iot-project.eu/)
Lingfan Gao and Michael Hammerer for
implementating prototypes and creating demos

Outline
 Motivating examples and approach
 Key concepts
 Architecture and components
 Prototype and demo
 Conclusions and future work

Related work and our approach
 IoT Interoperability problem is known, but
 addressed through the deployment of services and
components after a long cycle of software
development and operation
 hard to dynamically reconfigure and support
opportunistic interoperability solutions
 lack of customization: interoperability are also user-
specific problems, not just standardization issues
 often isolated from runtime services management
 Our contributions: dynamic solutions based on
ensembles/resource slices

Motivating scenarios
 Many things can establish very fast: querying camera,
downloading video, transferring data and launching analytic
components
 Large-scale on-demand video analytics need responsive and
reactive interoperability w.r.t data conversion, protocol
translations and data contracts

Motivating scenarios
 Similar issues: data contract, conversion, quality of data, and transfer protocols
 But interoperability cannot work without network engineering and data protection

Key requirements
 Cross systems and cross layers:
 Interoperability is not just needed IoT resources
 We need IoT, network functions and cloud resources
 A combination of issues w.r.t. data, protocols, contracts,
service quality, etc.
 Developer goals:
 Reduce time to establishing interoperability solutions
 Configure suitable components to deal with interoperability
 Deploy and provision interoperable bridges
 Address application-specific concerns
 Aim to develop full automatic solutions

Ensemble and its resource slice
 Resources: data streams, analytics, broker, storage, etc.
 Any existing software and service supporting
interoperability is also a resource
 A composition of “non-Interoperable components“ can
create a virtual resource for interoperability
„interoperability bridge“ as a resource
Resource slice
Resource slice concept and related papers: http://sincconcept.github.io/

Key concepts
 Client c specifies a resource slice: RS(c)
 We make the resource slice interoperable,
creating RSi(c) from RS(c)
 We focus on resources can be represented by
data points and control points with suitable
metadata: resource is r(DP,CP,MT)
 DP (data points), CP (control points), MT (metadata)
 A service provider must provide enough metadata of its
resources
 We must be able to deploy a software artifact supporting
interoperability on-demand

Examples
 DP(r)= {dpa,dpc} return all videos and the current
video, and CP(r)={cpp } put video to a storage
 A service S can provide a set of R={ri} allow to use
DP(r) and CP(r)
 Examples of slices
 RS(c) ={ri, GoogleStorage, FaaS}
 RS(c) ={ri, Kafka, Trigger, Container}
 Our interoperable slice structures: many-to-one, one-to-
one, one-to-many
 Augment RS(c) with IBE(c)={ibei} RSi(c)through
analytics, recommendation and composition

Integration requirements for
dynamic interoperability
 Resource providers:
 Instances of resource providers provisioning
resources
 Resources and providers can be controlled at
runtime
 Repository for artifacts for interoperability
 Artifacts can be instantiated into the right
environments
 E.g., a middleware service for performing protocol
translation, a data pipeline for covering data, or a
function for filtering IoT data

Resource Slice Interoperability Hub
architecture

Enriching Client’s Resource slice
 Dynamic interoperability solutions cover
 Interoperability analytics
 Recommendation and composition
 Resource provisioning and configuration
 Metadata focused on runtime aspects
 Data quality, data delivery, data compliance regulations, data
transfer protocols
 Interactions for interoperability
 Data transformation
 Protocol translation for data delivery
 Data contract assurance

Resource abstractions and
metadata for interoperability
 Extension of our HINC model [FICloud 2016]
 Added new metadata for interoperability context: DataPoint,
ControlPoint, ExecutionPolicy, DataQuality, and Connectivity

Metadata
 Typical resource metadata and “interoperabity
metadata” but in an extensible model
 We have more interesting novel aspects of
metadata reflecting dynamics for interoperability
solutions, e.g., quality, contract, delivery
frequency (related to V* of data) rather than
traditional static “protocols” and “formats”

Examples of metadata
 Resource type
• SENSOR, ACTUATOR; MESSAGEQUEUE, FIREWALL, FILE_STORAGE, VPN,
CONTAINER, VIRTUALMACHINE
• FAAS, INTEROPERABILITY_BRIDGE, DATA_TRANSFORMATION,
PROTOCOL_TRANSLATION
 Protocols:
 REST, MQTT, AMQP, CoAPP
 IP, LoRaWAN, NB-IOT
 Data access patterns: PubSub (fan-out), ReqResp, Queue
 Data contract
 Data quality: ACCURACY, TIMELINENESS, etc.
 Data delivery: FREQUENCY (e.g. sampling rates)
 Execution policy and data regulation: e.g., within EU
 Data format: CSV, JSON, AVRO, RDF

Resource metadata at runtime
Sensor encapsulated in datapoints
Software artifact for interoperability
*Some sensitive information removed

Key steps in interaction in solving
interoperability
Key steps are reflected in interoperability analytics,
recommendation and provisioning

Provisioning and Configuration
 Microservices with containers and virtual
machines suitable for IoT, network functions
and clouds
 Extensibility
 not all services are developed by us
 Leverage static interoperability solutions at runtime
 Different layers and models, e.g.,
 Long running services based on specific protocols, like
messaging, storage, queues, and REST web services
 Function-as-a-service, based on event triggers
 Batch workflow/pipeline styles

Examples with Base Transceive
Station Slice
Other examples of runtime operations:
 Network functions like firewall can be added into the pipeline
 Traffics at NFV can be reengineered.

Current prototype
 rsiHub prototype
 https://github.com/SINCConcept/HINC
 Examples of resource providers, including for
interoperability solutions
 https://github.com/rdsea/IoTCloudSamples
 Video demo
 A slice with BTS with data transformation
 https://storage.googleapis.com/demovideorsihub/de
mo_1080.mp4
 By Lingfan Gao and Michael Hammerer

Conclusions and future work
 Dynamic interoperability solutions fill the gap
 Provide on-demand solutions (short time to develop)
 Opportunities to utilizing existing solutions with
others
 But we need to consider system-as-a-whole:
“resource slice” view
 Future work
 Interoperability analytics and recommendation
 Further metadata development
 DevOps IoT Interoperability as a software
engineering approach for IoT interoperability

Thanks for your
attention!
Hong-Linh Truong
Faculty of Informatics
TU Wien, Austria
rdsea.github.io

Towards a Resource Slice Interoperability Hub for IoT

More Related Content

What's hot (20)

Similar to Towards a Resource Slice Interoperability Hub for IoT (20)

More from Hong-Linh Truong (20)

Recently uploaded (20)

Towards a Resource Slice Interoperability Hub for IoT