Antonio M. Alberti A. Head of ICT Lab., Inatel, Brazil Rodrigo da R. Righi, Eduardo S. dos Reis Computer Science, Unisinos, Brazil Victor Chang Leeds Beckett University, United Kingdom Víctor Méndes Muñoz Universitat Autonoma de Barcelona, UAB, Spain Converging Future Internet, “Things”, and Big Data: An Specification Following NovaGenesis Model
26
Embed
Converging Future Internet, “Things”, and Big Data: An Specification Following NovaGenesis Model
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Antonio M. Alberti A. Head of ICT Lab., Inatel, Brazil
Rodrigo da R. Righi, Eduardo S. dos Reis Computer Science, Unisinos, Brazil
Victor Chang Leeds Beckett University, United Kingdom
Víctor Méndes Muñoz Universitat Autonoma de Barcelona, UAB, Spain
Converging Future Internet, “Things”, and Big Data: An Specification Following NovaGenesis Model
Initiatives to converge IoT and Big data: SENSEI, FI-WARE, SmartSantander.
THE PROBLEM
Open Challenges: many IoT challenges, like security, trust, privacy, software-control, to name a few, will require more than incremental solutions or the application of models already established.
Status Quo: current cloud and networking technologies and their protocols are inherently limited for several expected scenarios (Pan et al., 2011).
Dependence to HTTP/TCP/IP: these approaches solidly depend on current Internet support, since they all use RESTFul APIs for IoT services.
(c) Antonio Alberti 2016, Inatel - All rights reserved.
Our Approach: To converge IoT, Big Data and “Clean Slate” Future Internet:
To solve IoT open challenges without more incremental work.
To employ more deep redesigns to solve security, efficiency, flexibility, heterogeneity, naming and energy constrains on current protocol stacks.
THE PROPOSAL
(c) Antonio Alberti 2016, Inatel - All rights reserved.
We are developing a new architecture called NovaGenesis and applying it to IoT/Big Data scenarios.
NovaGenesis is a Convergent Information Architecture that:
(1) It cohesively integrates information exchanging (networking) and information processing/storage (cloud computing and big data) - fixed and mobile.
(2) Its services can publish sensor device’s data in distributed hash tables (DHTs) employing self-verifying naming (SVNs) for all existences and contract-based trust network formation.
In this paper, we specify the data path from devices to the cloud, employing NovaGenesis emerging paradigms.
We specify how the “things” sensed information are subscribed by a big data service (BDS) and injected in Spark big data platform using future Internet.
THE PROPOSAL
(c) Antonio Alberti 2016, Inatel - All rights reserved.
Uses natural language names (NLNs) to name uniform resource locators (URLs), hosts (IP addresses) and transport layer ports (in sockets).
This is human-friendly, but the intrinsic binding to physical world entities depends on the correct and unambiguous understanding of these names (Ghodsi et al. 2011).
Information centric networking (ICN) proposes self-verifying names (SVNs) as an alternative to NLNs (Ahlgren et al., 2012), so making possible to check the relationship between the named entity and the name at any time.
NovaGenesis “clean slate” design employs SVNs for all entities, including “things”, services, hosts, domains, content, data.
The RESTFul interfaces (e.g. NGSI-9/10) are dynamic and allow a service to establish service level agreements (SLAs) with other instantiated services of the architecture.
However, contract-based operation is typically not obligatory.
For instance, in FIWARE generic enablers are not required to establish SLAs one another.
NovaGenesis forces all services to establish contracts (SLAs) before information exchanging, forming trust networks among services that take care of IoT data.
‣ FI-WARE Limitations: Contract-Based Service Composition
(c) Antonio Alberti 2016, Inatel - All rights reserved.
Future
Owner publishes! Internet!
Receiver!subscribes
only the desired content.!
(c) Antonio Alberti 2014, Inatel - All rights reserved.
Minimization of spam problem!!
COMMUNICATION MODEL
(c) Antonio Alberti 2016, Inatel - All rights reserved.
Local Net 2!
ID=143.106.52.3!LOC=143.106.52.3!
ID=10.0.0.3!LOC=10.0.0.3!
Local Net 1!
MOBILITY
Today
(c) Antonio Alberti 2016, Inatel - All rights reserved.
ID=FFFF12211243865…!LOC=FEFEF1421412411…!
ID=FFFF12211243865…!LOC=AAAA2734573453…!
Local Net 2!Local Net 1!
Future
MOBILITY
(c) Antonio Alberti 2016, Inatel - All rights reserved.
Social Devices!
Representatives!
SOCIAL DEVICES
“THINGS” NEED SERVICES TO REPRESENT THEM TOWARDS CONTRACT-BASED
TRUSTABLE SELF-ORGANIZATION (c) Antonio Alberti 2016, Inatel - All rights reserved.
Current Proof-of-the-Concept Implementation
HOST 2 HOST 1
PGSPSS HTSApp PGSGIRS
HOST 3
HTSPGS
HOST 4
HTSPGS
Publish/subscribe (pub/sub) Service: Does the rendezvous among publishers/subscribers. Has an application programming interface (API), which has 5 primitives: 1. Publishes a NB (and a content, if
any); 2. Subscribes a NB (and content, if
any); 3. Notifies peer services about NB
(and content) published; 4. Revokes a publication; 5. Delivers name bindings and related
con- tents.
Generic indirection resolution service (GIRS): Selects a hash table service (HTS) to store name bindings and to cache content. Proxy/Gateway Service (PGS): Encapsulates NovaGenesis messages directly over Ethernet/Wi-Fi/Bluetooth.
Extending NovaGenesis for IoT/Big Data Convergence
“THINGS” DATA CENTER
PGCSBDS
EPGS
EPGS
EPGS
MCS
PGCS
EPGS
ACCESS NETWORKS
NRS
SPARK
Name Resolution Service (NRS): Integrates PSS, GIRS and HTS. Embedded Proxy/Gateway Service (EPGS): An embedded version of current PGS. Proxy/Gateway/Controller Service (PGCS): An extended version of current PGS with Controller-as-a-Service functionality.
Management and Control Service (MCS): Implements the classical areas of management in NovaGenesis.
Big Data Service (BDS): Interoperates with Spark big data platform. Publishes analytics results to other NovaGenesis services.
Extending NovaGenesis for IoT/Big Data Convergence
NG Layer NG Layer
802.15.4
NG Layer
802.15.4 Ethernet
App Layer
MCS
EPGS
NG Layer
PGCS PGCS
Ethernet
App Layer
NRS
BDS
TCP/IP
App Layer
PGCS
SPARK
Ethernet
SSHPUB/SUB
PUB/SUB
Extending NovaGenesis for IoT/Big Data Convergence
EPGS PGCS NRS BDSPGCS SPARK
a
bab
c
c cdd
f fgg
jjkkk
hhi
ii
l lmm
n n noo
pp p p
qq r
stt
(a) Say “hello” for candidate peer services. (b) Receives and answers the “hello”. (c) EPGS publishes a service offer (SLA). (d) NRS notifies the PGCS about the SLA. (e) (missing in figure) (f) PGCS subscribes the SLA. (g) NRS delivers the SLA. (h) PGCS accepts the SLA and publishes an acceptance information
object (AIO). (i) NRS notifies the EPGS about AIO. (j) BDS searches for a PGCS and receives keywords about the
PGCS. (k) BDS publishes an SLA to PGCS, which is notified by NRS. (l) PGCS subscribes the service offer. (m) NRS delivers the service offer. (n) PGCS accepts the SLA and publishes an AIO. (o) BDS subscribes the AIO. (p) EPGS publishes raw data to BDS. (q) BDS subscribes the raw data. (r) BDS inserts the data on Spark. (s) BDS perform analytics on Spark (t) BDS publishes analytics on NRS.
We proposed the concept and reported the specification of a model to integrate big data, cloud computing, IoT device-control-as-a-service, and IoT services.
The proposed model is based on NovaGenesis, a “clean slate” future Internet proposal.
New services have been specified to create a data path from NovaGenesis “things” up to a big data service (BDS) that interoperates with Spark big data.
Nowadays, we are implementing EPGS and PGCS.
Future work: (i) implementation of BDS and MCS; (ii) performance evaluation of the convergent architecture specified in this paper; (iii) elasticity and scalability tests; (iv) evaluate latency and efficiency of proposed control/management model; (v) to monitor and evaluate service reputation; (vi) explore security advantages of proposed model; (vii) implement and evaluate NG benefits for disaster recovery scenarios; and (viii) evaluate NG integration to other big data platforms besides Spark.
THE CONCLUSION
(c) Antonio Alberti 2016, Inatel - All rights reserved.