Advancing NovaGenesis Architecture Towards Future ... - IEEE Xplore

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2017.2723953, IEEE Internet of Things Journal 1

Advancing NovaGenesis Architecture Towards Future Internet of Things Antonio M. Alberti1 , Gabriel D. Scarpioni1 , Vaner J. Magalhães1 , Arismar Cerqueira S. Jr.2 , Joel J. P. C. Rodrigues1,3 , Senior Member, IEEE, and Rodrigo da R. Righi4

Abstract—Internet of things (IoT) has been deeply challenging current Internet and emerging architectures, including 5G and Future Internet. Many architectural limitations, such as weak security, data distribution efficiency, provenance and traceability of sources, excessive human intervention, lack of interoperability and service-awareness in devices configuration, have been exposed and called the society attention. This paper addresses these limitations by properly integrating five strategies: (i) efficient IoT data exchanging, storage and processing via information-centric networking (ICN); (ii) contract-based IoT services composition; (iii) software-control/management of IoT devices accordingly to the services requirements; (iv) naming and name resolution of the physical and virtual entities, proving identifier/locator splitting and contextualized self-organization; (v) name-based routing and network caching. Considering the current stateof-the art, the main paper contributions can be summarized as follows: proposal of a novel service-defined architecture, in which device configurations are a reflex of the real service needs (given by established contracts); combination of ICN benefits with named-services; and perennial identification of IoT devices, services, and data using self-verifiable naming. All integration work has been supported by a convergent architecture called NovaGenesis, demonstrating its viability as an alternative for the current IoT architectures. A proof-of-concept prototype has been implemented in laboratory under real conditions. The experimental results indicate competitive performance in terms of data transfer, memory and CPU consumption. Embedded NovaGenesis has smaller RAM and ROM requirements when compared to a similar RPL + 6LowPAN stack. Data exchanging has been performed in few milliseconds in a local area network. Index Terms—Internet of things, Future Internet, 5G, information-centric networking, service-oriented architecture, software-defined networking

I. I NTRODUCTION

T

HE Internet scale and role have changed considerably from its original purposes [1], [2] due to the fact it was opened to the general public for plenty of applications. Many patch-work solutions were applied to extend its scope, e.g. IPSec, mobile IP (MIP) and IPv6, as well as the most recent ones focused on connecting constrained devices to the Internet, such as constrained application protocol (CoAP), IPv6 over low power wireless personal area network (6LowPAN) and 1 National Institute of Telecommunications (Inatel), Av. Jo˜ ao de Camargo 510, Santa Rita do Sapuca´ı, MG, Brazil. [alberti,

gabrield,vaner]@inatel.br; [email protected] 2 Lab WOCA - Inatel - Av. Jo˜ ao de Camargo 510, Santa Rita do Sapuca´ı, MG, Brazil. [email protected] 3 Instituto de Telecomunicac ¸ o˜ es, Portugal; ITMO University, SaintPetersburg, Russia; University of Fortaleza (UNIFOR), Fortaleza-CE, Brazil. 4 Programa Interdisciplinar de P´ os-Graduaça˜ o em Computaça˜ o Aplicada. Universidade do Vale do Rio dos Sinos, CEP: 93.022-000, São Leopoldo, RS, Brazil. [email protected]

routing protocol for low power and lossy networks (RPL). These evolutionary extensions aim at fulfilling the Internet of things (IoT) vision, which can be defined as the efforts to bring billions of ordinary things to the Internet. In this context, the current Internet technologies will be inadequate to fully support these multifaceted exponential growths on the number of devices, mobility, interactivity, content, security and privacy issues. Several initiatives have emerged worldwide to reshape the Internet under the Future Internet (FI) banner [3], [4]. Future Internet means any Internet-like network that could emerge in the future. This includes evolutionary approaches, in which the fundamental protocols of the current Internet are maintained and new ideas are incrementally introduced, or revolutionary approaches, in which its architecture is redesigned from scratch. Independently of the evolution path, the work in FI has being used as reference for the 5G architectures. For instance, the FI public-private partnership (PPP)[5] is feeding the 5G-PPP [6] initiative in Europe. Examples of evolutionary FI architectures (FIAs) that encompass IoT scope are: FIWARE [7], DIAT [8] and OpenIoT [9]. FIWARE provides a platform to integrate services (called generic enablers - GE) via next generation service interfaces (NGSIs). NGSI-9/NGSI-10 is based on RESTful application programming interfaces (APIs). The distributed Internet-like architecture for things (DIAT) [8] is a deliverable of the iCore FP7 funded project. Its main aims are: (i) to deal with heterogeneity of IoT devices; (ii) zero configuration of new devices and services; (iii) self-management of data/services, including autonomic composition; (iv) control policy model for security and privacy. The architecture is focused on autonomous data collection, processing, semantic annotation and decision making with minimal human intervention. Finally, the OpenIoT objective is to provide a middleware platform for semantic interoperability of heterogeneous IoT scenarios integrated to cloud computing. It is supported by W3C semantic sensor networks (SSNs) standard for representing physical and virtual world sensors. OpenIoT addresses the problem of combining data streams from different IoT scenarios. Revolutionary approaches (also named “clean slate” proposals) emerge to circumvent limitations of the current Internet technologies, such as: limited namespaces (lack of support for novel namespaces [10]) and name resolution (DNS resolves names among few namespaces) [11], [12], [13], node mobility (without loss of identity) [14], persistent content identification and efficient content distribution [1], [11], [13], self-verifying naming (SVN) to provide intrinsically secure networks [11], [12], [13], dynamic and self-organizing protocol stacking [12],

2327-4662 (c) 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.


[15] and software-based network control and operation [15], [16]. In essence, the aforementioned evolutionary approaches suffer from these limitations and revolutionary proposals precisely focus on addressing these limitations with deep redesigning. Typically, revolutionary architectures employ one or more of the following paradigms: information-centric networking (ICN) [1], [11], [13], service-oriented architecture (SOA) [11], [17], software-defined networking (SDN) [16], servicecentric networking (SCN) [18], network function virtualization (NFV) [15], [19], self-verifying naming [12], [11], [20], identifier/locator (ID/Loc) splitting [21], and distributed name resolution. However, it is quite surprisingly that very few revolutionary initiatives are covering IoT – despite the fact that probably the large majority of devices in FI will be connected things. NovaGenesis (NG) [12], [22] is a “clean slate” architecture that has been considering IoT as a key design ingredient, since its beginning in 2008. It is the first architecture that covers the design space presented in Table I, because it includes support for several ingredients typically addressed in a standalone fashion. This paper proposes the concept of a future Internet of things (FIoT) build over the NG model, which can be defined as: an Internet of things build from the synergistic integration of revolutionary and evolutionary networking paradigms. In this context, the article objective is twofold: (i) to demonstrate the NG viability for FIoT; (ii) to demonstrate NG as an alternative to the current IoT architectures. Its main contributions are: • Integration of aforementioned paradigms usually found separately in FI/5G/IoT architectures. As it will be demonstrated latter, this work goes deeply than previous work [1], [7], [8], [9], [11], [13], [23] when integrating the design dimensions presented in Table I. • “Semantic rich” and context-based orchestration of services and applications. Although this feature is present in the other proposals, NG provides an unique natural language and self-verified name bindings that foster trustable self-organization. In the context of IoT, applications can discover and contract sensors through intermediary services that negotiate in their names. • Configuration of IoT devices accordingly to the service contracts. This approach extends the current state-ofthe-art on software-defined technologies towards a new concept called service-defined architecture (SDA). Device configurations reflect the real needs of services and applications (via dynamic contracts), more broadly than only configuring traffic flow tables as in traditional SDN [16]. • Network caching of IoT data to improve scalability and efficiency of IoT data distribution for services. This solution allows asynchronous access to IoT data, as well as trustable sharing of information among services and applications. • Name-based routing and self-verifying naming for provenance of IoT sources and data integrity. For the first time, name-based routing of data samples from an IoT sensor up to a client application (that is dynamically demanding

•

•

for it) is demonstrated in laboratory. Integration of service-oriented architecture paradigms with information-centric design, enabling services to discovery possible peers and contracting them by employing the trustable mechanisms of ICN. The NG proposal extends the state-of-the-art on taking advantage of ICN for IoT [24]. This article demonstrates some of these advantages in a real scenario. Demonstration of an unique API for interoperability of things, services, and data. This feature is solely present in NovaGenesis. TABLE I D ESIGN SPACE CONSIDERED IN THIS PAPER .

Dimension D1 D2 D3 D4

D5 D6 D7 D8 D9 D10 D11 D12

Description Interoperability of things, services and data. Devices operation (mngt and control). Network caching of contents and name bindings. Name-based routing, in which content, services, domains, hosts, among other names are employed as identifiers or locators of communicating peers. Service-oriented design including service life-cycling. Semantic and context-awareness. Security and access control for things, services and data. Appropriate support for entities naming and name resolution. Cloud-based infrastructure. Autonomic operation with context-based decision making. Identifier and locator splitting, meaning different names are used for identifying and locating entities. Contract-based orchestration.

The remainder of the manuscript will first present research efforts related to this work in Section II. Section III will present NovaGenesis fundamental concepts, design and current implementation, whereas Section IV specifies a set of new services to advance NovaGenesis towards FIoT. This section also provides a discussion on how these services interact among them, ranging from things raw data transmission up to distributed data storage. Section V discusses the benefits of applying NG for FIoT. Section VI provides an experimental scenario to demonstrate the NG performance in a real IoT application (temperature monitoring in laboratory). More than one million samples have been transferred during approximately eight days using only NG over Wi-Fi. Temperature samples have been exchanged in a few milliseconds. Finally, Section VII presents final remarks and conclusions. II. R ELATED W ORK Several IoT proposals have been investigated to determine how they relate to the scope of this paper. A design space delimited by the dimensions presented in Table I has been considered for selecting relevant works. A. Evolutionary Approaches 1) FIWARE: It is the technological platform of the FIPPP initiative with a standardized service platform (dimension D5 in Table I) to enable smart application development for several sectors in economy [7]. FIWARE proposal integrates:



(i) OpenStack cloud computing operating system to orchestrate pools of compute, storage and networking resources throughout a data center (D9); (ii) Orion context-broker (CB), which provides a publish/subscribe model for data/context dissemination (D6); (iii) complex event processing (CEP) using IBM proactive technology online (PROTON) to enable real time response for changing conditions in the physical world; (iv) big data analytics via Telefônica Cosmos; (v) RESTful standards from open mobile alliance (OMA); (vi) a catalogue of dozens of compatible services (called generic enablers – GEs). Orion is a GE that enables registration of context producer devices, update of data/context information (e.g. updates of temperature measurements), notification of context changes ( for example the temperature changes) and querying for data/context. Other FIWARE GEs (like Cosmos or PROTON) subscribe for data/context changes. When a change occurs, the Orion CB notifies the interested services. FIWARE also encompasses a big data GE called Cosmos, which is based on Hadoop. Finally, the backend device management (BDM) GE configures, operates and monitors IoT devices, exposing legacy technologies (standardized or proprietary) to the CB via NGSI-9/10 interfaces (D2). FIWARE also supports security with access control (D7). 2) DIAT: the distributed Internet-like architecture for things (DIAT) [8] is focused on: (i) IoT devices heterogeneity and its configuration (D1); (ii) access control and policy enforcement for architectural components (D7); (iii) autonomic management of data and services (D2 and D10). The idea is to reduce human intervention while collecting, processing and semantically annotating data (D6). Situation- and contextawareness are addressed. Physical devices are represented by virtual objects (VOs) that facilitate their dynamic recognition, composition, and adaptation. VOs can be aggregated to form a composite virtual object (CVO). CVOs provide tiny services that interoperate with applications (D5). Self-orchestration (D10) is achieved based on context-aware decision making. VCOs mash up VOs and/or other VCOs accordingly to service needs, scheduling actions towards collaboratively accomplishing a service request. DIAT receives task requests from users and allocates appropriate services to handle them, by means of a feature called automatic service creation. Furthermore, DIAT includes a security management (SM) component (D7) that employs expressive policies (with meaning) to model, provide and enforce the access control. There are representations for data, identities, context, roles, structure and behavior. The SM runs into an IoT daemon, which can be simplified for lightweight devices. DIAT offers protocol adaptation and data exposition based on smart objects, a.k.a. virtual objects. Dynamic compositions and semantic-based resource access and control are provided by DIATs’ VCOs. It supports automatic service creation and related policy management service (D10), two features usually not covered by IoT middlewares. DIAT employs metadata for service discovery and selection in order to accomplish a task. In general, the autonomic approach is much more complete than the imperative ones found in other designs. 3) OpenIoT: it provides a platform for context-based (D6) interoperability of IoT and cloud computing scenarios (D1

and D9) [9]. It employs W3C SSNs standard for representing physical and virtual nodes, and encompasses data stream aggregation and IoT services interoperability, supporting data collection, filtering and contextualization from heterogeneous sensors. The linked data concept is employed to relate data sets. Visualization tools are included to enable easy development of convergent IoT/cloud applications. The platform supports semantic annotation (D6) of raw data and its unity of measurement. Detailed sensor information is captured using ontology and data from smart objects are stored in resource description format (RDF). Several APIs provide access to information, while smart objects can be configured via wrappers (D2), supporting sensor with serial communication, UDP, HTTP, etc. OpenIoT employs a middleware called cloud-based publish/subscribe middleware for IoT (CUPUS), which encompasses a cloud-based data processing service. The approach also supports a privacy and security module for user management, authentication, and authorization (D7). B. Revolutionary Approaches Evolutionary approaches are solidly dependent on the current Internet architecture, since they use RESTful APIs that rely on HTTP over TCP over IP. Additionally, the IoT constrained energy environment has been driving Internet community to create an alternative stack for IoT. Protocols like 6LowPAN, CoAP and RPL have emerged in this context. Although reducing the number of transmitted bytes and energy footprint, they still follow the same principles used in current Internet design. Therefore, they are subject to the same limitations and restrictions [12], [22]. In the next subsections, IoT approaches based on novel paradigms are going to be explored. 1) Information-Centric Networking: Internet usage patterns have shifted from host-oriented to content-oriented. However, its name resolution service (DNS) lacks on supporting content replication, movement and location awareness. ICN contends for content identifier/locator (ID/Loc) splitting [21], thus addressing dimension D11 in Table I. Content ID/Loc splitting enables persistent identification of contents independently of locators. They are cached in the network and accessed by their unique IDs (dimension D3). Routing can be performed using content names instead of host names, employing a technique called name based routing (NBR) (D4). Although ICN can be applied over TCP/IP, recent experiments (Baccelli et al. [25]) demonstrated its applicability for IoT, providing advantages over 6LowPAN/IPv6/RPL stack in terms of energy fingerprint and memory usage. They have ported CCN-Lite – a Linux open source implementation of named-data networking (NDN) [23], [26] Future Internet architecture – to RIOT operating system. Lindgren et al. contend that ICN can be beneficial to IoT in many cases, depending on applications [27]. Amadeo et al. have exploited NDN architecture advantages for IoT [28]. NDN is a content-centric networking (CCN) proposal defined by Jacobson et al. [23]. NDN defends the current Internet secures connections, not content. NDN secures content independently of connection security addressing dimension D7 in Table I. Moreover, it provides network caching of contents



(D3) and communication is driven by receivers that forward interest packets containing the name of the desired information objects. Routers maintain a pending interest table (PIT) for contents that have been requested (D4). When some interest packet founds a proper source, data packets are delivered in the reverse path fulfilling content caches (D3). Further requests do not need to go to the source anymore. They are delivered from caches, reducing latency and improving content distribution efficiency. Amadeo et al. [28] argue that NDN can be easily deployed at WSANs. 2) Software-Defined Networking: SDN provides more agility on the network operation (D2), consequently increases the role of software in Internet architecture. It enables new technologies to be deployed at software level, as applications of a network operating system (NOS) – an analogy to the computers operating systems. The distributed states at equipment control plane are replaced by a logically centralized network view, which is implemented in a software controller. The logically centralized controller configures flow tables at the network piece of equipment using a configuration protocol. OpenFlow (OF) is the first standard protocol developed for this purpose. Thus, it is TCP/IP dependent. There is no limitation on the kind of networking functions a software-controller can configure (addressing other control and management functions in dimension D2). In fact, in many scenarios flow tables are not the main concern. IoT requires many other important configurations, such as sensor sampling rates, addresses, operation bandwidth, channeling, firmware updates. The extension of the SDN scope to these IoT functionalities can catalyze software-controllers adoption in IoT. Luo et al. [29] proposed the software-defined wireless sensor networks (SD-WSN). The idea is to decouple data and control planes in WSN nodes, employing a sensor OpenFlow (SOF) protocol to provide communication between the two planes. Flow tables in sensor nodes are configured by an OF software-controller. SOF adopts two solutions for raw data flow creation on sensor nodes: redefinition of flow tables using OF extensible match (OXM), which defines new flow match rules for IoT technologies, like ZigBee, and support of micro IP stacks on sensor nodes. TinySDN [30] enables multiple software-controllers to configure IoT nodes’ flow tables. This approach is based on TinyOS for providing the following features: (i) in-band control channel (contrary to wired OF implementations in which the control channel is out of the band); (ii) tolerance of high latency on control messages; (iii) support for small link layer frames, e.g. ZigBee; (iv) energy efficient operation. Vilalta et al. [31] propose the combination of SDN and NFV to orchestrate IoT services at the edge nodes of smart places. When an IoT gateway is demanding for data processing, it requests the creation of virtual machines (VMs) at some edge computing provider. The gateway then selects the proper VM for each required service, configuring network traffic flows accordingly. The same authors also proposed an SDN-enabled security framework for detecting and mitigating malware traffic in IoT [32].

3) Identification/Location Splitting and Name Resolution: mobile sensors (motes) have an important role in IoT. MIPv6 provides the support for host mobility in current Internet stack by using two IP addresses: one to identify the host and other to locate it (the difference between identifiers and locators will be explored on Section III-A2). Ramirez et al. [21] argued the problems behind this approach are: increased overhead; seamless mobility support; resilience and survivability; security. Some “clean slate” proposals adopt ID/Loc splitting (D11) as a key ingredient in architectures. Examples are eXpressive Internet architecture (XIA) [11] and MobilityFirst [14]. ID/Loc employs two namespaces: one for IDs and another for locators. Name resolution is required to resolve ID into locators (D8). ID/Loc is not restricted to content or hosts. It can be extended to other entities, for example operating systems (OSs) and their processes [12]. For this aim, architectures have been pushed to support as many as namespaces as the number of individually identified entity classes. Name resolution should also be extended for relating IDs and locators at many architectural levels. 4) Service-Oriented Architecture and Service-Centric Networking: Software engineering plays a fundamental role on the scope of services and applications. As a consequence, one must consider software engineering is itself changing from component-based to service-oriented, giving rise to what has been called service-centrism [17]. The argument is everything can be considered as a service, e.g. infrastructure-as-a-service (IaaS). This paradigm is also known as Internet of services (IoS). Services are dynamically orchestrated by the composition of distributed software utilities (D5). Therefore, their life cycles include service description, search, selection, negotiation, admission, configuration, management, and releasing. The paradigm of developing software-as-a-service (SaaS) is frequently associated with SOA approach, which has already been employed in cloud computing, specially founded in web services. Examples of “clean slate” SOA are: XIA [11] and recursive internetworking architecture (RINA) [15]. Service-centric networking means to build networks where services communicate using service names (D11) [18], rather than combining host addresses and transport layer port numbers. SCN should support persistent service naming, replication, mobility, and chaining. An open challenge is to apply SCN ideas to IoT. C. Research Opportunities After analyzing the representative related works, it worths to highlight there is a lack of proposals that can integrate the design dimensions presented in Table I. Such approaches should provide ingenious support for IoT requirements, specially to the following concerns: (i) interoperability of things, services, and data; (ii) autonomous, service-driven operation, and management of things; (iii) efficient data distribution via network caching; (iv) name-based routing for mobility and perennial identification of data; (v) appropriate services life-cycling; (vi) context-awareness; (vii) unlimited namespaces and name resolution; among other benefits given by supporting Table I issues. The next section presents NovaGenesis architecture and its components, detailing how it brings such benefits.



III. N OVAG ENESIS NovaGenesis (NG) [12], [22] project started in 2008 with the following question in mind: imagine there is no Internet, how could one design it using the best contemporary technologies? NG scope includes not only data exchanging (like any other networking technology), but also data processing and storage (including networking cache). Its design considered a set of state-of-the-art ingredients, focusing on synergistically integrating them. Its aim was to create a generic framework that could deal with naming, life-cycling, persistent identification, location-independency, joint content, services and things coordination. Physical devices and their software representatives constitute what has been called a “smart object”. A. Fundamental Concepts NG is based on a set of fundamental concepts that are required to better understand its design and contributions. 1) Naming, Self-Verifiable Names, Name Resolution and Network Caching: names that carry some meaning are defined as natural language names (NLNes). The role of naming on architectures security and trust has been recently evaluated by Ghodsi et al. [20]. A name is obtained at the output of a hashing algorithm - a self-verifying name (SVN). The binary input of the hash function can be the existence itself (e.g. computer program executable, source code, or data chunks) or other binary input related to the entity being named (e.g. entities’ immutable attributes). Since SVNes are hash codes, they carry no meaning for people. NG embraces not only NLNes, but also SVNes to identify entities as possible communication targets in some scope. Naming is generically treated, enabling to accommodate any possible name, with any naming convention, hierarchical or flat [12]. NG approach employs an unlimited number of namespaces linked by means of name bindings. A name binding (NB) is a mapping among two or more names, typically implemented as a vector of the form: < key; value(s) >. A NB can relate a name to an object or a name to other names. Fig. 1 illustrates a name binding graph. The edges are NBs, while the vertices are NLNes or SVNes. For example, Domain 1 name is bound to Mote 2, Router 1, Gateway 2, Mote 4 and Domain 2 names. One can use the tuple < Domain 1; Gateway 1 > to represent that Domain 1 contains a Gateway 1. In this context, name resolution consists on resolving a name to other bound names. For example, the name Router 1 is bound to the names OS 6 and OS 7, while OS 6 can be resolved to Process 10 and Process 11. 2) Identification and Localization: formally, an identifier unambiguously separates an existence from others in a certain name scope [33]. The name or namespace scope is the set of all objects that it may had been applied [34]. Considering Fig. 1, an scope can be denoted by the name “Domain 2” and existences inhabiting this domain belong to this namespace. The name “Process 7” uniquely separates a computer program from others in the same scope. Therefore, it is an identifier for this software at Domain 2 scope. This solution meets ICN and SCN requirements presented on Sections II-B1 and II-B4.

In contrast, a locator is a name that points to a position where an entity can inhabit or be attached; it should provide a notion of distance of this position to other positions in the same space. In Fig. 1, the name pair (-22.909938, 47.062633) provides an approximate distance to the name pair (-23.088677, -47.208954). Both names point to positions in the global geographic coordinate system. Therefore, these names can be considered as locators. Interestingly, the distance can be given in terms of number of hops in the name graph. For example, the name Sensor 5 is two hops (two name bindings) away from Domain 1 name and three hops from Router 1 name. This illustrates that depending on the adopted space, a multitude of names can be valid as locators. Mobility can be provided by decoupling the names that identify from the ones that locate [21]. It means to use one name to identify and another one to locate. 3) Services and Contracts: a service is a virtual entity aimed at processing, exchanging, or storing information [22]. As a consequence, a computer program (or a process) is a service. Typically, protocols are implemented as services at host computers for a long time. The emergence of virtualization and everything as a service (XaaS) [17] are replacing traditional hardware by virtual functions. This is already a reality in many 5G architecture proposals [35], [36]. These functionalities (e.g. synchronization and retransmission) are more flexibly implemented using field programmable gate array (FPGA) or software-defined radio (SDR) to favor the software-based control and management. NovaGenesis approach employs microservices to implement network stack. Service life-cycling demands a contract-based model, where the limits, responsibilities, clauses to be respected, criteria for completion and other aspects are defined in a service level agreement (SLA) [17]. A contract is an SLA among services, which is established with minimum human intervention, follows the pre-established conditions. 4) Proxies, Gateways, and Controllers: a proxy is a service that represents other entities for dynamic resource compoFlow 2

Flow 1

Process 11 Process 12

Process 10 090112AA

OS 6

OS 10 180972AA

Router 1

Domain 1

Gateway 2

(-22.909938, -47.062633)

Mote 4 Sensor 1 OS 2

201206AA

110335AA

191239AA

Process 4 Process 3 190478AA

Sample 3 291074AA

Fig. 1. Graph of names and their bindings representing entities relationships in computer systems including IoT devices, services and data.



sition. In the context of IoT, a proxy can be seen as a “smart object” that exposes the device(s) capabilities and available resources towards SLA establishment to interested services. A gateway is a translator or an entrance/exiting point among different technologies. An IoT gateway is responsible to drain raw data to the Internet; in many cases providing data aggregation and semantic annotation. Finally, a controller is a service that controls or executes the decision making regarding the configurations of physical resources or other services. NovaGenesis model contends for a more general application of SDN ideas in IoT context, i.e. to employ software-controllers to configure other functionalities than frame forwarding. B. Current Implementation A NovaGenesis prototype has been under development since 2012. It is based on the three software components: (i) a name resolution and networking cache service (NRNCS); (ii) a proxy/gateway/controller service (PGCS) for message encapsulation over link layer technologies, such as Ethernet, Wi-Fi, and IEEE 802.15.4; (iii) user applications. To facilitate understanding, a summary of NG terminology is shown on Table II. 1) Name resolution and networking cache service (NRNCS): This service is responsible to implement name bindings and associated content exchanging and storing. It has a distributed hash table (DHT) that stores name bindings published and subscribed. While publishing a name binding to DHT, a service defines whose other services are authorized to subscribe this NB. Therefore, NBs are only accessible to authorized services. When a service initializes, it publishes bindings among several NLNes and SVNes (a sub-graph of names), exposing its names to other services. NRNCS was implemented using three distributed services (as illustrated in Fig. 2): • Publish/subscribe service (PSS) In the current implementation, a publish/subscribe communication model for NG services was adopted. Services can publish NBs and associated content to other services through sending a message to an instance of a PSS. PSS forwards the messages for networking cache. Content (data chunks) are associated to name bindings, linking information objects to their names. The PSS API can been seen as a socket layer, which has six primitives: (i) to publish NB (with associated data, if any); (ii) to publish NB/data and notify other services about a publication; (iii) to subscribe a NB/data; (iv) to subscribe a NB/data and notify other services about a subscription; (v) to deliver a subscribed NB/data; (vi) to revoke a NB/data publication. In summary, PSS can be seen as a distributed API, accessed via PSS identifiers (independent of its locators). • Generic indirection resolution service (GIRS) - This service receives pub/sub messages from PSS and forwards them to a hash table instance, in which NBs and data are in fact stored. Therefore, the GIRS is an intermediate service among PSS and HTS instances. GIRS calculates the remainder of the NB key division by the number of HTS instances, selecting an HTS instance to store the NB according to result of this calculation.

Hash table service (HTS) Implements a hash table (HT) data structure creating a DHT system based on selfverifying names. This service stores name bindings and related contents in a distributed way. HTS provides suitable performance when retrieving stored name bindings. As an example of storage, consider the content named Sample 3 at Mote 4 in Fig. 1. This content will be stored as a file in a folder of an HTS instance. A name binding < 291074AA, Sample 3 > can relate the SVN of the content to its NLN. 2) Proxy/gateway/controller service (PGCS): PGCS aimed at message forwarding and routing over link layer. It provides: message encapsulation over already established networking technologies, such Wi-Fi or Bluetooth; a proxy service to represent other NG services inside an OS; and bootstrapping functionalities to initialize a domain. PGCS enables PSS, GIRS and HTS discovery during initialization. Since an address is a name that denotes the position to where an existence can inhabit or be attached, PGCS relays on HTS to store namebindings among already established address formats (e.g. a real world or an emulated MAC Ethernet) and/or NG addresses. PGCS also has an internal hash table in which it copies/locally stores discovered NBs. Independently of the address format used to connect PGCSes, inside NG all the communication is ID-oriented. Additionally to the gateway functionality, PGCS publishes NBs about NG services inside an OS to other PGCSes in the same domain. 3) User Applications: User services (or applications – Apps) can expose NBs/data to other services via PSS API. Thus, other services can subscribe a services’ NBs and content. •

C. Message Format NG messages have a format similar to session initiation protocol (SIP) messages. They contain several command lines and a payload (not obligatory). There is a blank line separating both portions, when necessary, and the command lines portion is composed by a set of command lines, which can be dynamically expanded according to the need. They are formatted as: ng -command –alternative version [ < n type E1 E2 E3 E4 ... En > ]

where -command is the action to be done. -alternative selects among alternatives in the action to be done. version selects the desired version of implementation. [ ] indicates one or more vectorial arguments. n is the number of elements in an argument. type is the type of the elements in an argument. E1 E2 E3 E4 ... En are the elements of an argument.

IV. N OVAG ENESIS T OWARDS F UTURE I OT This section introduces new NG services for IoT, specifying their operation into five steps: initialization; exposition and discovery; service offering; service acceptance; and raw data publishing. A. New NG Services for IoT 1) Embedded Proxy/Gateway Service (EPGS): this service is a minimal NG implementation to run embedded in an



TABLE II N OVAG ENESIS TERMINOLOGY. Term Name Identifier Locator Name Binding (NB) Process Block Message CommandLine Service Hash Table (HT) Gateway (GW) Proxy/Gateway (PG) Hash Table Service (HTS) Generic Indirection Resolution Service (GIRS) Publish/Subscribe Service (PSS) Proxy/Gateway/Controller Service (PGCS)

Meaning A set of natural language or engineered symbols attributed to entities. A name that is unique in some scope. A name that offers the notion of distance in a space. A binding among names. A computer program with several internal Blocks and its Actions. The smallest named structure inside a process. It encompasses several Actions. The protocol data unit of NovaGenesis. A script containing commands and parameters to be performed at the receiver. A synonym for a Process aimed at exchanging, processing, and/or storing information in any computational substrate. A Block that implements a hash table to store name bindings. A Block that implements inter Block and inter Process communication. A Block inside the PGS Process that implements message forwarding to other peer PGSes. A Process that stores and retrieves name bindings at domain level. A service that selects an HTS to store a name binding or content. A Process that does the rendezvous among name bindings or content publishers/subscribers. A Process that represents some core services in a certain computer. Also, it is a gateway for other PGCSes. NRNCS - NAME RESOLUTION AND NETWORK CACHE SERVICE

EventOS

EPGS

EMBEDDED SOFTWARE

PUB/SUB API “NG SOCKET”

Linux PGCS

HTS

PSS

GIRS

App

PGCS

App

Proxy/ Gateway (PG)

D. Hash Table (HT)

Pub/Sub (PS)

Indirec. Resol. (IR)

Core

Proxy/ Gateway (PG)

Core

Hash Table (HT)

Hash Table (HT)

Hash Table (HT)

Hash Table (HT)

Hash Table (HT)

Hash Table (HT)

Hash Table (HT)

Gateway (GW)

Gateway (GW)

Gateway (GW)

Gateway (GW)

Gateway (GW)

Gateway (GW)

Gateway (GW)

Raw socket

Shm

Raw socket

Shared Memory

Wi-Fi

Sensor

Linux

Wi-Fi

Host

Wi-Fi

Host

Fig. 2. The NovaGenesis current prototype. The sensor supports an embedded proxy/gateway service (EPGS) running in EventOS to introduce IoT devices to NG architecture. The host computers run NG core processes at Linux OS. Name resolution and network caching service (NRNCS) is composed by three components: publish/subscribe service (PSS), generic indirection resolution service (GIRS) and hash table service (HTS). Every host should run a proxy/gateway/controller service (PGCS) instance for encapsulation of NovaGenesis messages over link layer technologies, e.g. Wi-Fi. PSS creates a NG “socket” for client applications (Apps). An App publishes and subscribes name bindings and contents via this PSS NG “socket”. The socket address is informed to all services during bootstrapping procedures. The PGCS sells EPGS features to one or more client applications.

IoT node. It generates nodes’ self-verifiable names as well as a descriptor of the hardware features and functionalities, storing them in a local HT. Furthermore, it sends a periodic “hello” message that exposes EPGS names as well as its MAC address to possible peers. It encapsulates NG messages over Wi-Fi, forwarding messages to the PGCS. EPGS exposes IoT device OS and hardware features to NG services. Sensed raw data is published to NRNCS via PGCS (data plane) and configurations are subscribed from NRNCS (control plane). 2) PGCS for IoT: PGCS has been extended in order to be an IoT gateway for one or more sensors and/or actuators

nodes. It has the responsibility to disclosure PSS names, thus EPGS(es) can use its API. PGCS is able to encapsulate a message to a peer EPGS, using a link layer protocol. Finally, PGCS acts as a software-controller of EPGS’s represented devices. In other words, PGCS publishes control information to EPGS(es) it has contracts. For example: (i) change devices Wi-Fi channel; (ii) change the VLAN ID of the frames coming from device; (iii) change sensing frequency or resolution. 3) IoT Client: The client application (named IoTTestApp) is the target of the raw data collected by one or more IoT devices. It uses the PSS API to subscribe from NRNCS the



Fig. 3. Specification of NG IoT services. Initialization, exposition, discovery, EPGS service offering, PGCS service acceptance and data publishing steps.



raw data collected by EPGS/PGCS. Its operation is contractbased and requires exposition and discovery of PGCS(es). B. Functioning of the New NG Services 1) Initialization: Fig. 3 specifies how NG IoT services initialize. A novel embedded operating system called EventOS [37] has been adopted for providing IoT devices information to EPGS. EPGS generates devices SVNes based on EventOS information. Three NLNes are generated for host, OS and EPGS. EPGS forwards a “hello” message via Wi-Fi broadcast containing its NLNes, SVNes and nodes’ MAC addresses. A 32 bits Murmurhash3 [38] algorithm has been employed to generate SVNes. PGCS receives the “hello” and stores the forwarded NBs in its local HT, generating a confirmation message to the discovered EPGS. In addition, PGCS has a “hello” procedure that can start independently of EPGSes. This “hello” contains the names required to communicate with PSS. After receiving those names, EPGS keeps them locally and it is ready to use the PSS API. Fig. 3 also specifies the initialization of the client application. However, in this case, no network interface is used, since intra node service communication employs a shared memory implemented using OS calls. The application calculates its SVNes using the same hash function and adds them to the NLNes in the “hello” message. PGCSes have a well know shared memory ID (shmid) that is used by services to start communicating with PGCS. Nevertheless, this “hello” message contains a pair of additional shmids that will be used in further communications. PGCS will use its local HT data structure to store the discovered services. PGCS acknowledges the successful reception of the App local OS “hello”. 2) Exposition and Discovery: the early exchange of intra OS “hello” messages enables applications to discovery PSS API. Fig. 3 defines a mechanism for PSS’ SVNes discovery. The client application sends a query directly to PGCS asking for PSS names. PGCS replies with the required data. Now, the client application is able to use the PSS API to publish its keywords, like “client application IoT raw data”. PGCS can also disclosure its role of proxy/gateway/controller. Both services share its role by publishing NBs via PSS API. App can query for “semantics rich” keywords, for instance “IoT proxy gateway controller”, helping it to find potential partners capable to measure a physical variable, e.g. the temperature of a room. By comparing received name bindings with pre-configured tags, the client application determines fitness of candidate peers and can now publish a service offer to PGCS. Simultaneously, PGCS also looks for potential clients for the raw data EPGS produces. This SLA-based model creates a trustable path for IoT data chaining and control/management of physical resources. Things configuration reflects services needs – a novel paradigm called service-defined networks. 3) Service Offering: it is the first step in the SLA establishment. In Fig. 3, EPGS publishes an offer to PGCS with the notification option enabled. PSS forwards this information to GIRS and HTS (not shown in figure), which stores the offer as a file in its local HT data structure. PGCS receives the publication notification and subscribes the offer. NRNCS

delivers the service offer to EPGS, which evaluates it. This offer is from an EPGS that searches for a PGCS that can “sell” its sensor capabilities to other NovaGenesis services, like IoTTestApp for example. App publishes a service offer to PGCS with the notification option enabled. Similarly, PSS notifies PGCS, which subscribes the offer information object. The NRNCS delivers the offer to PGCS, which analyses it, checking whether PGCS can provide the required measures. Let’s assume a temperature measure made once a second in Celsius degrees. 4) Service Acceptance: after analyzing service offers and deciding on accepting them, PGCS publishes two service acceptance objects, as illustrated in Fig. 3. One is for EPGS and the other is for the client application. NRNCS notifies these services, which subscribe the acceptance objects. NRNCS delivers them to EPGS and App, where they are locally stored. This procedure finishes SLA establishment among services in the raw data IoT chain. 5) Publishing Raw Data: the last step in specification is raw data publishing and subscribing. The measured data is delivered by sensors hardware to EPGS, which publishes a JSON file containing the data and notifies the partner client App about this file SVN. App subscribes every published JSON file from NRNCS using its name. The JSON file is temporarily stored on the network cache provided by HTS. This facilitates IoT data distribution with integrity and provenance check, since App can verify the SVN of the received JSON file. The JSON file is kept at HTS until the App revokes EPGS publication. V. B ENEFITS OF N OVAG ENESIS FOR FI OT This section returns to the twelve dimensions presented in Table I, discussing the gaps covered by a FIoT supported by NovaGenesis, as following: • D1 - Interoperability of (i) things – via smart object concept; (ii) services – by employing a service-oriented ecosystem; (iii) data – through metadata published together with information objects. NG offers an unique API for communication among all services, favoring interoperability of heterogeneous devices, platforms, data and applications. Typically, more than one system (with different APIs) is employed to this goal. • D2 - Customized configuration and management of physical devices via their software representatives. NG extends software-defined paradigm towards exposing hardware capabilities to services, enabling “rich” orchestration of resources. The gap here is to reduce the distance between devices configuration and services need, i.e. to configure equipment with service awareness. • D3 - Distributed storage of data and information objects to improve scalability and efficiency of sharing. NovaGenesis aligns to the advantages of ICN for IoT. This is not present at FIWARE, OpenIoT, DIAT, TinySDN and RINA. The challenge in this case is to take advantage of ICN to improve sensor data distribution to authorized services. • D4 - Routing based on entities name as supported by ICN. NG generalizes name-based routing (NBR) over



TABLE III C OMPARISON AMONG PROPOSALS FOR BUILD - IN SUPPORT FOR DESIGN DIMENSIONS .

Characteristic Interoperability (D1) Software-based control/mngt. (D2) Network caching (D3) Name based routing (D4) Service-oriented (D5) Context-awareness (D6) Security (D7) Naming and name resolution (D8) Cloud-based infrastructure (D9) Autonomic operation (D10) ID/Loc splitting (D11) Contract-based compose-ability (D12)

•

•

•

•

•

•

FIWARE [7] yes yes no no yes yes yes no yes no no no

Evolutionary DIAT [8] yes yes no no yes yes yes no yes yes no no

link layer as presented in Subsection III-B. None of the reviewed IoT approaches provides NBR for IoT from sensor to applications combining SOA and ICN. NBR allows routing on secure identifiers [20], addressing IoT security and traceability problems. D5 - SOA-driven IoT services/applications ecosystem. NG encompasses self-organizing IoT services aimed at reducing human intervention. Services discover and contract one another by using names and their bindings. NG approach is similar to DIAT, but it includes ICN paradigms. Its aim is to support complete IoT services life-cycling following SOA principles. D6 - “Semantics rich” and context-based orchestration of services and applications. NG allows context-aware selforganization. FIWARE, DIAT and OpenIoT support this feature as well. Nonetheless, NG is the unique approach that performs this integrating contract-based orchestration and secure naming. Therefore, the orchestration is done considering perennial identifiers of the involved entities. D7 - Secure access to devices, services and contextualized data. Novel techniques based on SVNes can improve entities security and trust as contended by Ghodsi et al. [20]. NovaGenesis supports not only SVNes, but also NLNes. NG is the unique FIA that applies hierarchical hybrid naming resolution for IoT scenarios. This feature addresses the gaps of provenance and integrity of data. D8 - Emerging scenarios require extending naming capabilities to other entities, such as data objects [23], [11], [13] and services [18]. Only FIAs are addressing this gap. NG provides hierarchical, distributed, jointly name resolution and network caching service to support unlimited namespaces and resolution capabilities [12]. NG is the first architecture that integrates things, services and data name resolution for smart places. D9 - Cloud-based service life-cycling, including elastic computational resources. NovaGenesis design is aligned to dynamic instantiation at cloud or fog computing. Elastic provisioning of IoT services is an important requirement for smart places. D10 - Autonomic operation of services and applications. In the current implementation (Subsection III-B), NG pro-

OpenIoT [9] yes yes no no yes partially yes no yes no no no

XIA [11] yes no yes yes no yes yes yes unsure no yes no

Revolutionary NDN [28] no no yes partially no partially yes partially unsure no partially no

NG [12] yes yes yes yes yes yes yes yes yes partially yes yes

vides semi-autonomic service composition. Future versions will include autonomic decision cycles like DIAT. • D11 - ID/Loc is the definitely solution for mobility [21]. NG is the unique ICT architecture that supports unlimited ID/Loc splitting for all its entities. This enables entities to move without loosing their identity, which is an important requirement for IoT. It addresses the problem of guaranteeing provenance of data while moving, e.g. how to guarantee the origin of data coming from a connected implant that changes identifiers while moving? • D12 - Contract-based operation to improve service trustworthiness. All services in NG (even things representatives) are dynamically composed accordingly to the published service level agreements (SLAs). NG is the first contract-based smart places architecture. The goal is to provide IoT services trustworthiness, improving security and privacy of data. Table III provides a qualitative comparison of evolutionary and revolutionary proposals for IoT requirements. From this comparison, it becomes evident NG is the first approach to cover all of the design dimensions required for IoT. VI. E XPERIMENTAL R ESULTS An experimental scenario similar to Fig. 2 has been deployed. The main difference is that the computer in the right has been removed, as reported in the experimental setup shown in Fig. 4. Two NXP LPC1769TM devices are connected to the desktop PC via an Wi-Fi access point. LPC1769 has an ARM Cortex-M3 with up to 32 kbits of SRAM memory. The software used on this development was the LPCXpressoTM v7.7.2 379. Considering there are not widely adopted benchmarks to evaluate IoT data/service life-cycling, this paper explores a room-temperature-as-a-service (RTaaS) scenario in which an application looking for temperature measures (IoTTestApp) contracts sensors via its software representatives (PGCSes). Temperature measurements are provided from two sensors at every second. The aim of this experiment is not optimizing energy footprint of heating, ventilation or air conditioning (HVAC) systems as performed by Serra et al. [39] or Guerrieri et al. [40]. It is to demonstrate RTaaS while integrating ICN, SOA, SDN and NFV paradigms.



(ac:22:0b:13:01:34). The third command line contains a SVN (hash of the two previous command lines), so that any authorized service can check its integrity. B. Exposition and Discovery

Fig. 4. Experimental scenario: (i) NovaGenesis core services and IoT client application (IoTTestApp) running in the laptop; (ii) two NovaGenesis embedded proxy/gateway service (EPGS) running in NXPs LPC1769 devices in the left and right (the USB cables are used only to power up the nodes); (iii) Wi-Fi access point used to connect NG services.

A. Initialization As specified in Fig. 3, a “hello” message is sent by the PGCS to the EPGS. This message has been captured from PGCS log, as shown in Fig. 5. The NG message first line always contains the information required to forward/route messages. The main advantage of this verbose protocol is debugging. In future versions, source coding could be applied to reduce overhead. The name 28FD4420 denotes the space that limits forwarding/routing in a NG domain. In other words, this message is limited to the domain named by 28FD4420. The second argument (vector) of the ng msg cl 0.1 command line contains a tuple of SVNes calculated for the host (0BD95286), OS (ED12F3ED), process (7E764DC1) and an internal component called proxy/gateway (4D623F20), respectively. The third argument is fulfilled with “empty” strings to indicate the destination of the message is unknown. This message is broadcasted by the desktop computer. The second command line in Fig. 3 presents the “hello” itself. The first three elements of the argument vector are SVNes from internal components of the PGCS, namely: GW, HT and Core. The last three elements contain details of the link layer technology (Wi-Fi), interface at the OS (wlan0) and MAC address of PGCS’s host (ac:22:0b:c9:df:3b). A third argument is used to inform a tuple of four SVNes from PSS. This tuple enables EPGS to publish name bindings and raw data to PSS. The third command line contains an SVN (hash of the two previous command lines), so that any authorized service can check its integrity. A “hello” message was also sent from EPGS to PGCS as captured at PGCS log (Fig. 6). The second argument of the ng −msg −−cl 0.1 command line contains a tuple of SVNes calculated for the host (4C7CF9B2), OS (5F472DA7), and process (1A53F830), respectively. The fourth element is NULL. The third argument is also fulfilled with “empty” strings to indicate that the destination of the message is unknown. This message is broadcasted by the LPC1769. The second command line in Fig. 6 is the “hello”. The first two elements of this command line are NULL because they are not required for the EPGS. The last three elements inform the link layer technology used (Wi-Fi), the interface at the OS (wlan0) and the MAC address of EPGS’s host

Both PGCS and client application expose a set of keywords and SVNes to facilitate discovery. Fig. 7 contains a PGCS log capture with an “exposition” message. The target of this message is PSS, identified by the tuple < 0BD95286 ED12F3ED 8E8B52EC 7EA46815 >. Every ng −p −−b 0.1 command line publishes a name binding to PSS. For example, the fifth command line relates the hash of the word “Gateway” to the SVN of PGCS (7E764DC1). Any search on the hash of the word “Gateway”, i.e. 2AA3A2EF, will return this process SVN. This enables the client application to discover this PGCS process via PSS. The client application then searches for candidate peers using this hash code. C. Service Offering This procedure is specified in the last part of the diagram from Fig. 3. EPGS forwards a “service offer” message to PSS, which notifies PGCS. Remember PSS’s SVN tuple was obtained during initialization. The second command line of this message should contain a publication with notification primitive, which instructs PSS to notify PGCS accordingly to its SVN tuple. The “service offer” is forwarded as an attached .txt file. D. Service Acceptance PGCS accepts the offer by publishing a “service acceptance” to EPGS. EPGS is notified about this “service acceptance” file and subscribes it. HTS delivers the subscribed “service acceptance” as captured in Fig. 8. The payload of this message contains SVNes of the IoT client application to whose raw data samples should be published. Note the primitive ng −d −−b 0.1 on the second command line. It is a name binding or content delivery primitive. E. Publishing Raw Data Raw data starts to be send from EPGS to the final application only after all SLAs are set (a few milliseconds in a LAN). Fig. 9 shows a capture of a “raw data publishing” message sent from EPGS to PSS, containing a notify primitive to the client application. IoTTestApp is notified about this JSON measure file and subscribes it. Provenance and integrity of samples are guaranteed by the hash of the “Measures.json” file and SVNes of the publishing service, the EPGS program. Fig. 10 contains a WiresharkTM capture of a similar message. Fig. 11 presents the room temperature measured at two sensors during approximately 189.6 hours of experimentation accordingly to the setup reported in Fig. 4. A total of 1,296,000 samples were collected. The mean room temperature was estimated as 29.3108 °C. Fig. 12 depicts the mean round trip time (RTT) at IoTTestApp while subscribing a Measure.json file from PSS. The mean value was 6,97 ms. The error bars report the worst and best values according to 95% confidence



ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED 7E764DC1 4D623F20 > < 4 s empty empty empty empty > ] ng -hello --ihc 0.2 [ < 6 s A4324A2D AB9B70B4 57ECEB4F Wi-Fi wlan0 ac:22:0b:c9:df:3b > < 4 s 0BD95286 ED12F3ED 8E8B52EC 7EA46815 > ] ng -scn --seq 0.1 [ < 1 s 1A81A5E3 > ]

Fig. 5. A hello message sent by the PGCS to the EPGS. ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 4C7CF9B2 5F472DA7 1A53F830 NULL > < 4 s empty empty empty empty > ] ng -hello --ihc 0.2 [ < 5 s NULL NULL Wi-Fi wlan0 ac:22:0b:13:01:34 > ] ng -scn --seq 0.1 [ < 1 s 604007EC > ]

Fig. 6. A hello message sent by EPGS to PGCS. ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED ng -p --b 0.1 [ < 1 s 2 > < 1 s BEE09CC1 > < 1 s 7E764DC1 ng -p --b 0.1 [ < 1 s 1 > < 1 s BEE09CC1 > < 1 s PGCS > ] ng -p --b 0.1 [ < 1 s 2 > < 1 s D051B60B > < 1 s 7E764DC1 ng -p --b 0.1 [ < 1 s 1 > < 1 s D051B60B > < 1 s Core > ] ng -p --b 0.1 [ < 1 s 2 > < 1 s 2AA3A2EF > < 1 s 7E764DC1 ... ng -p --b 0.1 [ < 1 s 9 > < 1 s Host > < 1 s 0BD95286 > ] ng -p --b 0.1 [ < 1 s 2 > < 1 s OS > < 1 s ED12F3ED > ] ng -message --type 0.1 [ < 1 s 1 > ] ng -message --seq 0.1 [ < 1 s 35 > ] ng -scn --seq 0.1 [ < 1 s EBF2BD6B > ]

7E764DC1 57ECEB4F > < 4 s 0BD95286 ED12F3ED 8E8B52EC 7EA46815 > ] > ] > ] > ]

Fig. 7. An “exposition” message sent by PGCS to PSS, exposing its keywords, e.g. Proxy, Gateway, Controller, Wi-Fi. ng ng ng ng ng ng ng ng

-m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED CDEF1454 E7BBD07C > < 4 s 0BD95286 ED12F3ED D86EFEE6 5330DB1E > ] -d --b 0.1 [ < 1 s 18 > < 1 s A895E6DA > < 1 s Service_Accepted_201980197.txt > ] -info --payload 0.1 [ < 1 s Service_Accepted_201980197.txt > ] -d --b 0.1 [ < 1 s 2 > < 1 s A895E6DA > < 3 s 57ECEB4F ED12F3ED 7E764DC1 > ] -d --b 0.1 [ < 1 s 9 > < 1 s A895E6DA > < 1 s 0BD95286 > ] -message --type 0.1 [ < 1 s 1 > ] -scn --ack 0.1 [ < 2 s 6F9E9073 23E05ACD > ] -scn --ack 0.1 [ < 2 s 6DF0F93F F6D1984F > ]

There is a payload of 45 bytes

Fig. 8. A “service acceptance” message delivered from HTS to EPGS. ng ng ng ng ng ng

-m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 4C7CF9B2 5F472DA7 1A53F830 NULL > < 4 s 0BD95286 ED12F3ED 8E8B52EC 7EA46815 > ] -p --notify 0.1 [ < 1 s 18 > < 1 s 94BF74F8 > < 1 s Measures.json > < 5 s pub 0BD95286 ED12F3ED 372ED1C1 EFCD1EC5 > ] -info --payload 0.1 [ < 1 s Measures.json > ] -message --type 0.1 [ < 1 s 1 > ] -message --seq 0.1 [ < 1 s 2 > ] -scn --seq 0.1 [ < 1 s CC34CC24 > ]

{Temperature: 26}

Fig. 9. A “raw data publish” message published from the EPGS to the IoTTestApp containing a temperature sample.

interval. Both figures have been under sampled for the sake of clarity. These delay results demonstrate NG can be an alternative for established IoT stacks and even for novel architectures, such as NDN (CCN Lite) and XIA. Measurements of this order of magnitude are consistent with that expected for the transfer of sensor samples to a client application on a LAN environment. F. CPU and Memory Consumption This subsection reports the CPU and memory consumption of NovaGenesis running in EventOS at LPC1769. Table IV shows the proposed solution memory requirements at the IoT mote. There are two measurements of the memory required in a node: (i) complete memory, which encompasses EventOS, the Wi-Fi stack, the NXP LPC 1769 drivers, an EPGS wrapper

and EPGS itself; (ii) standalone EPGS memory, without the other components. Both ROM and RAM measurements have been estimated by the compiler employed. Table IV also reproduces results obtained in Baccelli et al. [25] for CCNLite. Standalone EPGS has a smaller RAM requirement than CCN-Lite. The complete NG stack occupies 8,720 bytes of RAM, which is in a range adequate for IoT. According to [25], RPL + 6LoWPAN has a RAM requirement of 27,739 bytes at RIOT on MSBA2 hardware. The complete NG prototype has a decrease of 68% in RAM requirement when compared to [25]. Regarding ROM, NG stack is larger than CCNLite, possibly due to the additional functions provided for service life-cycling. Nevertheless, NG has a smaller ROM requirement than the one estimated by Baccelli et al. [25] for RPL + 6LoWPAN, which is 53,412 bytes. In other words, the



Fig. 12. Mean subscription round trip time from IoTTestApp to NRNCS.

“hello” step requires 1,898,091 CPU cycles to be performed. Since functions are completely different, is is not possible to infer about the faster approach. However, NovaGenesis values are in the same order of magnitude, which means it can be considered as an alternative. TABLE IV Fig. 10. A fragment of the “raw data publishing” as sent by EPGS to IoTTestApp and captured by WiresharkTM .

C OMPARISON OF NG

AND CCN-L ITE ( REPRODUCED FROM MEMORY AND CPU USAGE .

Memory

CPU cycles

Memory

Fig. 11. Temperature measurements during approximately 189.6 hours.

proposed prototype has experienced a decrease of 20% when compared to RPL + 6LoWPAN. The number of CPU cycles consumed by the processor to perform the tasks predicted in the FIoT scenario is also presented in Table IV. CPU cycles have been captured using a development and debug tool called cycle delta. It encompasses a variable that returns the number of CPU cycles spent between two program breakpoints, carefully selected to estimate EPGS functions performance. Table IV presents the CPU cycles for every step performed at EPGS life-cycle. For instance, the

CPU cycles

[25])

NovaGenesis (EventOS on LPC1769) Complete ROM (bytes) 42,440 Standalone ROM (bytes) 25,328 Complete RAM (bytes) 8,720 Standalone RAM (bytes) 2,108 RunHello 1,898,091 RunExposition 3,833,896 RunServiceOffer 3,375,442 RunServiceAcceptance 2,348,335 PubData 2,491,954 CCN-Lite (RIOT on MSBA2) ROM (bytes) RAM (bytes) memcmp ssse3 ccnl nonce find or append ccnl i prefixof c dehead ccnlcoreRXiorc ccnl extract prefix nonce ppkd memcpy ssse3

16,628 5,112 14,002,814 7,525,050 4,062,659 1,462,304 956,238 895,590 845,042

VII. C ONCLUDING R EMARKS This work has proposed the concept and reported a successful implementation of a Future Internet of things approach based in a novel architecture called NovaGenesis (NG). Different from the related work, NovaGenesis integrates paradigms usually separately found in FI/5G/IoT architectures. Information-centric networking (ICN) has been adopted for raw data processing, caching and exchanging, improving scalability and efficiency of IoT data distribution



for services. Service-oriented architecture has been selected to implement IoT services and their life-cycles with “semantic rich” and context-based orchestration. ICN and SOA have been integrated to enable service discovery and contracting using name-based routing and perennial identification of entities. Self-verifying naming has been adopted for provenance of IoT sources and data integrity. Unlimited namespaces have been provided to support natural language (e.g. keywords) and self-verifying names (e.g. hash codes) for all architectural entities. Integrated name resolution for things, gateways, hosts, services and data have also been demonstrated. In addition to the state-of-the-art, NG enabled IoT devices to be configured accordingly to service contracts. In other words, services expose things capabilities to other services, enabling servicedefined configuration of things’ parameters and functionalities – a novel paradigm called service-defined architecture. NovaGenesis applicability has been demonstrated by implementing a project pilot, in which named data (room temperature samples) were transferred under the umbrella of SLA-based service orchestration, with provenance and integrity guarantees. IoT resource exposition, services discovery/contracting and self-verifying named data have been transferred, stored (in network cache) and delivered to requesting application. The experimental results demonstrate NG can be applied to IoT, providing RAM and ROM advantages when compared to RPL + 6LoWPAN, as measured by Baccelli et al. [25]. The measured delays are compatible with IoT applications. Future work includes: (i) extending the model to other IoT technologies; (ii) scalability, elasticity and performance evaluation in large scale; (iii) integration with big data and cloud computing; (iv) evolution of service ecosystem; (v) comparison to other FIAs. ACKNOWLEDGMENTS This work was partially supported by Finep/Funttel Grant No. 01.14.0231.00, under the Radiocommunication Reference Center (Centro de Referência em Radicomunicaço˜ es - CRR) project of the National Institute of Telecommunications (Instituto Nacional de Telecomunicaço˜ es), Brazil, by Government of Russian Federation, Grant 074-U01, by National Funding from the FCT – Fundaça˜ o para a Ciência e a Tecnologia through the UID/EEA/500008/2013 Project. Authors also thank to CNPq, CAPES, and FAPEMIG for their support. R EFERENCES [1] B. Ahlgren, P. Aranda, P. Chemouil, S. Oueslati, L. Correia, H. Karl, M. Söllner, and A. Welin, “Content, connectivity, and cloud: ingredients for the network of the future,” Communications Magazine, IEEE, vol. 49, no. 7, pp. 62–70, July 2011. [2] T. Leighton, “Improving performance on the internet,” Commun. ACM, vol. 52, no. 2, pp. 44–51, Feb. 2009. [3] A. M. Alberti, “A conceptual-driven survey on future internet requirements, technologies, and challenges,” Journal of the Brazilian Computer Society, vol. 19, no. 3, pp. 291–311, 2013. [4] C. Partridge, “Helping a future internet architecture mature,” SIGCOMM Comput. Commun. Rev., vol. 44, no. 1, pp. 50–52, Dec. 2013. [5] “Future internet - public-private partnership.” [Online]. Available: https://www.fi-ppp.eu/ [6] 5G-PPP, “5g - public-private parnership.” [Online]. Available: https://5gppp.eu/

[7] F. Ramparany, F. G. Marquez, J. Soriano, and T. Elsaleh, “Handling smart environment devices, data and services at the semantic level with the fi-ware core platform,” in 2014 IEEE International Conference on Big Data (Big Data), Oct 2014, pp. 14–20. [8] C. Sarkar, A. U. Akshay, R. V. Prasad, A. Rahim, R. Neisse, and G. Baldini, “DIAT: A scalable distributed architecture for IoT,” in IEEE Internet of Things Journal, vol. 2, no. 3, jun 2015, pp. 230–239. [9] J. Soldatos, N. Kefalakis, M. Hauswirth, M. Serrano, J. P. Calbimonte, ˇ M. Riahi, K. Aberer, P. P. Jayaraman, A. Zaslavsky, I. P. Zarko, L. Skorin-Kapov, and R. Herzog, OpenIoT: Open source internet-ofthings in the cloud. Cham: Springer International Publishing, 2015, vol. 9001, pp. 13–25. [10] R. Atkinson, S. Bhatti, and S. Hailes, “Evolving the internet architecture through naming,” Selected Areas in Communications, IEEE Journal on, vol. 28, no. 8, pp. 1319–1325, October 2010. [11] D. Han, A. Anand, F. Dogar, B. Li, H. Lim, M. Machado, A. Mukundan, W. Wu, A. Akella, D. G. Andersen, J. W. Byers, S. Seshan, and P. Steenkiste, “Xia: Efficient support for evolvable internetworking,” in Proc. of the 9th USENIX Conf. on Networked Systems Design and Implementation, ser. NSDI’12. USENIX, 2012, pp. 23–23. [12] A. M. Alberti, M. A. F. Casaroli, D. Singh, and R. da Rosa Righi, “Naming and name resolution in the future internet: Introducing the novagenesis approach,” Future Generation Computer Systems, vol. 67, pp. 163 – 179, 2017. [13] C. Dannewitz, D. Kutscher, B. Ohlman, S. Farrell, B. Ahlgren, and H. Karl, “Network of information (netinf) - an information-centric networking architecture,” Comput. Commun., vol. 36, no. 7, pp. 721– 735, Apr. 2013. [14] J. Li, Y. Shvartzshnaider, J. A. Francisco, R. P. Martin, K. Nagaraja, and D. Raychaudhuri, “Delivering internet-of-things services in mobilityfirst future internet architecture,” in 2012 3rd IEEE International Conference on the Internet of Things, Oct 2012, pp. 31–38. [15] S. Vrijders, D. Staessens, D. Colle, F. Salvestrini, E. Grasa, M. Tarzan, and L. Bergesio, “Prototyping the recursive internet architecture: the irati project approach,” IEEE Net., vol. 28, no. 2, pp. 20–25, March 2014. [16] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “Openflow: Enabling innovation in campus networks,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp. 69–74, Mar. 2008. [17] L. Sun, Y. Li, and R. A. Memon, “An open iot framework based on microservices architecture,” China Communications, vol. 14, no. 2, pp. 154–162, February 2017. [18] E. Nordström, D. Shue, P. Gopalan, R. Kiefer, M. Arye, S. Ko, J. Rexford, and M. J. Freedman, “Serval: An end-host stack for service-centric networking,” in NSDI, S. D. Gribble and D. Katabi, Eds. USENIX Association, 2012, pp. 85–98. [19] S. Sun, M. Kadoch, L. Gong, and B. Rong, “Integrating network function virtualization with sdr and sdn for 4g/5g networks,” IEEE Network, vol. 29, no. 3, pp. 54–59, May 2015. [20] A. Ghodsi, T. Koponen, J. Rajahalme, P. Sarolahti, and S. Shenker, “Naming in content-oriented architectures,” in Proceedings of the ACM SIGCOMM Workshop on Information-centric Networking, ser. ICN ’11. New York, NY, USA: ACM, 2011, pp. 1–6. [21] W. Ramirez, X. Masip-Bruin, M. Yannuzzi, R. Serral-Gracia, A. Martinez, and M. Siddiqui, “A survey and taxonomy of id/locator split architectures,” Computer Networks, vol. 60, pp. 13 – 33, 2014. [22] A. M. Alberti, D. Mazzer, M. M. Bontempo, L. H. de Oliveira, R. da Rosa Righi, and A. C. Sodré Jr., “Cognitive radio in the context of internet of things using a novel future internet architecture called novagenesis,” Computers & Electrical Engineering, vol. 57, pp. 147– 161, January 2017. [23] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, “Networking named content,” in Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies, ser. CoNEXT ’09. New York, NY, USA: ACM, 2009, pp. 1–12. [Online]. Available: http://doi.acm.org/10.1145/1658939.1658941 [24] K. Pentikousis, B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. B. Davies, A. Molinaro, and S. Eum, “Information-Centric Networking: Baseline Scenarios,” RFC 7476, Mar. 2015. [Online]. Available: https://rfc-editor.org/rfc/rfc7476.txt [25] E. Baccelli, C. Mehlis, O. Hahm, T. C. Schmidt, and M. Wählisch, “Information centric networking in the iot: Experiments with ndn in the wild,” in Proc. of the 1st ACM Conf. on Information-Centric Networking, ser. ACM-ICN ’14. New York, NY, USA: ACM, 2014, pp. 77–86. [26] S. H. Bouk, S. H. Ahmed, D. Kim, and H. Song, “Named-datanetworking-based its for smart cities,” IEEE Communications Magazine, vol. 55, no. 1, pp. 105–111, January 2017.



[27] A. Lindgren, F. B. Abdesslem, O. Schelen, A. M. Malik, and B. Ahlgren, “Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT,” Internet Engineering Task Force, Internet-Draft draftlindgren-icnrg-efficientiot-03, Jul. 2015, work in Progress. [28] M. Amadeo, C. Campolo, A. Iera, and A. Molinaro, “Named data networking for iot: An architectural perspective,” in 2014 European Conf. on Networks and Communications (EuCNC), June 2014, pp. 1–5. [29] T. Luo, H. P. Tan, and T. Q. S. Quek, “Sensor openflow: Enabling software-defined wireless sensor networks,” IEEE Communications Letters, vol. 16, no. 11, pp. 1896–1899, November 2012. [30] B. T. de Oliveira, L. B. Gabriel, and C. B. Margi, “Tinysdn: Enabling multiple controllers for software-defined wireless sensor networks,” IEEE Latin America Trans., vol. 13, no. 11, pp. 3690–3696, Nov 2015. [31] R. Vilalta, A. Mayoral, D. Pubill, R. Casellas, R. Mart´ınez, J. Serra, C. Verikoukis, and R. Muñoz, “End-to-end sdn orchestration of iot services using an sdn/nfv-enabled edge node,” in 2016 Optical Fiber Communications (OFC), March 2016, pp. 1–3. [32] R. Vilalta, R. Ciungu, A. Mayoral, R. Casellas, R. Martinez, D. Pubill, J. Serra, R. Munoz, and C. Verikoukis, “Improving security in internet of things with software defined networking,” in 2016 IEEE Global Communications Conference (GLOBECOM), Dec 2016, pp. 1–6. [33] W. Chun, T.-H. Lee, and T. Choi, “Yanail: yet another definition on names, addresses, identifiers, and locators,” in Proceedings of the 6th International Conference on Future Internet Technologies, ser. CFI ’11. New York, NY, USA: ACM, 2011, pp. 8–12. [34] J. Day, Patterns in Network Architecture: A Return to Fundamentals. [35] F. Yang, H. Wang, C. Mei, J. Zhang, and M. Wang, “A flexible three clouds 5g mobile network architecture based on nfv sdn,” China Comm., vol. 12, no. Supplement, pp. 121–131, December 2015. [36] S. Ruffini, P. Iovanna, M. Forsman, and T. Thyni, “A novel sdn-based architecture to provide synchronization as a service in 5g scenarios,” IEEE Comm. Magazine, vol. 55, no. 3, pp. 210–216, March 2017. [37] E. Frigieri, G. Scarpioni, and M. Mokarzel, “Eventos.” [Online]. Available: https://github.com/edielsonpf/EventOS [38] F. Yamaguchi and H. Nishi, “Hardware-based hash functions for network applications,” in IEEE Int. Conf. on Networks (ICON), 2013, pp. 1–6. [39] J. Serra, D. Pubill, A. Antonopoulos, and C. Verikoukis, “Smart hvac control in iot: Energy consumption minimization with user comfort constraints,” The Scientific World Journal, vol. 2014, p. 11, 2014. [40] A. Guerrieri, J. Serra, D. Pubill, C. Verikoukis, and G. Fortino, Intra Smart Grid Management Frameworks for Control and Energy Saving in Buildings. Cham: Springer International Publishing, 2015, pp. 131–142.

Antonio Marcos Alberti is an associate professor and researcher at the Instituto Nacional de Telecomunicaço˜ es (INATEL), Brazil, since 2004. In 2012, Antonio was a visiting researcher at Future Internet Department of ETRI, in South Korea. He received the M.Sc. and Ph.D. degrees in Electrical Engineering from Campinas State University (Unicamp), Campinas, SP, Brazil, in 1998 and 2003, respectively. Since 2008, he is designing and implementing a future Internet architecture called NovaGenesis. He has authored or coauthored over 96 papers in refereed international journals and conferences. Since 2013 he has been acting as a Coordinator of Information and Communications Technologies (ICT) Laboratory at INATEL.

Gabriel Dias Scarpioni graduated in Electrical Engineering at the Instituto Nacional de Telecomunicaço˜ es (INATEL) in 2012. Since 2011, he has been a system specialist in embedded systems at Inatel Competence Center.

Vaner J. Magalhães was born in Santa Rita do Sapuca´ı, Minas Gerais, Brazil, in 1982. He received the B.S. degree in Computing Engineering from Federal University of Itajubá, Itajubá, Minas Gerais, Brazil. From 2007 to 2014, he was Software Engineer for mobile devices at Motorola, Sony-Ericsson and Samsung. Since 2014, he has been an System Specialist at INATEL working with Ericsson products. He is member of ICT Lab and his research interests include IoT and Future Internet architectures.

Arismar Cerqueira S. Jr. received his B. Sc. Degree in Electrical Engineering from the Federal University of Bahia-Brazil in 2001, M. Sc. Degree from Unicamp-Brazil in 2002 and Ph. D. degree from Scuola Superiore SantAnna-Italy in 2006. He has been Invited Researcher and Professor from many world-recognized universities, such as University of Bath-UK (2004, 2005 and 2007), MaxPlanck Institute-Germany (2010), Danish Technical University-Denmark (2013) and Scuola Superiore SantAnna-Italy (2015). He was Associate Professor from the State University of Campinas (Unicamp), from March 2009 to August 2011, when he joined the National Institute of Telecommunications (Inatel) from Brazil to work in the same position. Since 2009 he has been acting as a Coordinator of R&D Projects on diverse areas of telecommunications, including Antennas, 5G Networks, Radars and Microwave Photonics. He is a holder of 08 patents, has transferred 17 products to the industry and has published 170 scientific papers.

Joel J. P. C. Rodrigues [S01, M06, SM06] is professor at the National Institute of Telecommunications (Inatel), Brazil and senior researcher at IT, Portugal. He has been professor at UBI, Portugal and visiting professor at UNIFOR. He received the Academic Title of Aggregated Professor in informatics engineering from UBI, the Habilitation in computer science and engineering from the University of Haute Alsace, France, a PhD degree in informatics engineering and an MSc degree from the UBI, and a five-year BSc degree (licentiate) in informatics engineering from the University of Coimbra, Portugal. He is the leader of NetGNA Research Group (http://netgna.it.ubi.pt), the President of the scientific council at ParkUrbis Covilhã Science and Technology Park, the Past-Chair of the IEEE ComSoc TCs on eHealth and on Communications Software, Steering Committee member of the IEEE Life Sciences Technical Community. He is the editor-in-chief of three international journals and editorial board member of several journals. He has authored or coauthored over 500 papers in refereed international journals and conferences, 3 books, and 2 patents. He is member of the Internet Society, an IARIA fellow, and a senior member ACM and IEEE.

Rodrigo da Rosa Righi is assistant professor and researcher at University of Vale do Rio dos Sinos, Brazil. Rodrigo concluded his post-doctoral studies at KAIST - Korea Advanced Institute of Science and Technology, under the following topics: RFID and cloud computing. He obtained his PhD degree in Computer Science from the UFRGS University, Brazil, in 2005. His research interests include load balancing and process migration. Finally, he is a member of the IEEE and ACM.
