See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/354767350

Toward Future Internet of Things Experimentation and Evaluation

Article in IEEE Internet of Things Journal · June 2022

DOI: 10.1109/JIOT.2021.3114540

CITATIONS READS
7 486

5 authors, including:

Thiago Bueno Arismar Cerqueira Sodré Junior

Instituto Nacional de Telecomunicações Instituto Nacional de Telecomunicações
10 PUBLICATIONS 35 CITATIONS 58 PUBLICATIONS 331 CITATIONS

SEE PROFILE SEE PROFILE

Rodrigo Da Rosa Righi Antonio Marcos Alberti

Universidade do Vale do Rio dos Sinos Instituto Nacional de Telecomunicações
324 PUBLICATIONS 4,282 CITATIONS 159 PUBLICATIONS 1,117 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Antonio Marcos Alberti on 28 September 2021.

The user has requested enhancement of the downloaded file.

 1

Towards Future Internet of Things Experimentation

and Evaluation
Thiago B. da Silva1 , Ramon S. Chaib1 , Arismar Cerqueira S. Jr.2 , Rodrigo da R. Righi3 , and Antonio M. Alberti1

Abstract—The Internet of Things (IoT) and its current IETF To fulfill the IoT futuristic vision, a path has been to
and IEEE dual stack model have been facing limitations, re- develop a dual stack for IoT [7], with many adaptations in the
quiring applications to overcome tough constraints by their own, application layer [13]. In this scope, IEEE and IETF proposed
narrowing the full potential of this concept. For instance, the IoT
dual stack model does not entirely address or support perennial a double stack model based on IEEE 802.15.4 and IPv6
naming, immutable data provenance, data accountability, mobil- [14]. Nonetheless, today’s Internet architecture has several
ity support, and services’ self-organization. On the other hand, limitations to accommodate many IoT demands [10], jeopar-
Future Internet Architecture (FIA) research emerges as a viable dizing technological developments through a bottleneck [15].
candidate to compensate these gaps through evolutionary and Some researchers argue this double-stacking solution does not
revolutionary efforts. Regardless the FIA proposal model, this
field lacks a suitable environment that enables the performance address IoT overall challenges, such as mobile heterogeneous
experimentation and evaluation of distinct protocols and architec- connectivity (mobility without losing the identity) [15]–[17];
tures fairly and transparently. This article proposes a novel IoT information freshness (delivery on time); name-based service
experimentation and evaluation environment based on a low-cost self-organization (persistent service names and life-cycling)
and open-source solution. The proposed environment integrates [18]; and trustable and certified provenance of data [11], [19].
technologies of containers, IoT nodes emulation, and network
simulation to evaluate the current IoT dual stack and a promising Under the banner of Future Internet Architecture (FIA)
FIA approach called XIA. Moreover, this work combines the research [15], [20], alternative architectures seek to address
mentioned disjointed technologies, exploiting Docker containers, this stagnation and constant patching problem. Through clean-
Contiki open-source operational system for IoT, and Cooja the slate proposals, novel projects aim at solving from scratch
IoT network simulator. In this way, it addresses the objective of long time and intrinsic limitations from the current Internet.
fostering an honest experimentation and evaluation environment
for FIAs. Experimental results demonstrate the feasibility and Even though there is no universal agreement, these disjointed
effectiveness of this approach, broadening this field and sowing revolutionary efforts offer an option to the Internet’s status
a path to work with other FIAs. quo. To illustrate, some FIAs address open IoT challenges in
Index Terms—Internet of Things, Future Internet, XIA, Con- their original design. To illustrate, Named-Data Networking
tainer, Experimentation, 6LowPAN and IPv6. (NDN) [21] and NovaGenesis (NG) [2] have been proposing
and demonstrating efforts for attaining this goal recently.
In contrast, others seem to dismiss what is expected to be
I. I NTRODUCTION
the future of network devices: trillions of small sensors and

T HE Internet is a fundamental infrastructure in the con-

temporary world and its current design is based on the
paradigms of TCP/IP technology [1]. Through this model, new
actuators, from a myriad of sizes [11], [22]–[24]. In this
scope, eXpressive Internet Architecture (XIA) is a preeminent
example in the field [4].
protocols and technologies have arisen over the past decades Another major challenge relates to the benchmark of each
to meet society’s needs over diverse applications. However, FIA based on the complexity to ascertain them impartially.
as innovations emerges, they need to take advantage of an Several stable tools assess the TCP/IP model in terms of la-
ossified core and new challenges intrinsically arise from this tency, jitter, and packet loss. Nonetheless, these tools generally
fact, i.e. due to the current Internet design limitations [2]–[4]. do not estimate FIAs performance once they comprise distinct
To exemplify, one can cite the IoT proposal [5]–[7] that assumptions. Besides, some are not open-source, hampering
aims to massively connect a myriad of sensors and actuators adjustments or presenting a high cost to consider new stacks
to the Internet, achieving the convergence of the physical and on their source code. Therefore, the community lacks flexible
digital worlds. This massive number can generate consider- methods and tools to advance experimentation and evaluation
able network control and management traffic [6]–[9], once of novel architectures that scale reasonably.
each unknown packet flow may require complex decisions to Focusing on these gaps, this article proposes a novel Future
achieve their target, hindering the overspread of sensible data, Internet of Things Experimentation and Evaluation Environ-
compromising reliability, and agile forwarding [10]–[12]. ment (FIoTE3), suitable for current and future Internet archi-
1 ICT Lab., Inatel, Av. João de Camargo 510, Santa Rita do
tectures. At this moment, it exploits two individual scenarios:
Sapucaı́, MG, Brazil. [email protected]; • Scenario 1 - A hybrid XIA/IPv6 scenario with a XIA
[email protected]; [email protected] XDP/XIP gateway to IPv6/6LowPAN for supporting in-
2 Lab WOCA, Inatel, Av. João de Camargo 510, Santa Rita do Sapucaı́,
teroperable XIA services in legacy IoT motes.
MG, Brazil. [email protected]
3 PPGIA. Unisinos, CEP: 93.022-000, São Leopoldo, RS, Brazil. • Scenario 2 - A pure UDP/IPv6 and UDP/IPv6/6LowPAN
[email protected] network with emulated IoT motes and services.
 2

A. Motivation II. BACKGROUND

This article represents an extension of our previous work This section provides a background on key components
from 2017 [25]. As presented, the current Internet stack faces for the current FIoT experimentation and evaluation: (i) IoT
several challenges. One way to address this relates to draw a and tools for its performance evaluation, including Contiki
path to a multi-architecture Internet [26] . We investigate the embedded OS, Cooja for IoT devices emulation and wireless
interoperability of distinct projects and protocols in the same network simulation, and Docker containers for virtualization;
environment. The authors foresee a future where specialized (ii) XIA; (iii) other FIAs; and (iv) aspects related to FIoT
proposals coexist and perform the best service they can fulfill. concept.
Another motivation is the IoT’ relevance, wherein we
project that it will encompass the majority of data traffic A. IoT and Tools for its Performance Evaluation
in the future [27]–[29] . Furthermore, XIA remains widely
The IEEE 802.15.4 defines low-power wireless personal
unexplored for IoT to the best of our knowledge, despite of
area network (LowPAN) communication protocol [7], [30].
its importance for the future Internet (FI) community. It is
This standard delimits low-cost and simple communication
an open-source project that presents an exceptional prototype.
networks for wireless connectivity in restricted applications.
Even though it might not be the best alternative for IoT, we
Typically, this network encompasses cooperative devices that
consider this as an opportunity to evaluate it with our special-
connect physical environments to real-world applications, e.g.
ized IoT gateway. Therefore, XIA’s core remains unchanged
wireless sensors. Its main advantages are the easiness of
while assessing a paradigm not covered in its original design.
installation, data transfer reliability, short-range operation, low
FIoTE3 creates a test scenario, evaluating different archi-
cost, and decent battery life while maintaining a suitable
tectures with expandable topologies, collecting their behavior
protocol [6]. Similarly, the Internet engineering task force
and storing their results under the same procedure. Moreover,
(IETF) group has created the 6LoWPAN concept stemmed
FIoTE3 is a novel and customized tool for FIA, as it relies on
from the idea that IP should be applied even to the smallest
available open-source technologies, which anyone can edit and
devices. Hence, it has defined header and tunnel mechanisms
adapt it to their best interests. While the most current Internet
for IPv6 packet traffic over IEEE 802.15.4 [31].
and FIA experimentation and evaluation environments employ
IoT enthusiasts widely accept Cooja network simulator
Virtual Machines (VMs), our proposal exploits containerized
[32], which enables anyone to numerically investigate wireless
applications with emulated and simulated components.
networks of varying sizes, encompassing emulated devices that
incorporate sensors and/or actuators, commonly called Motes.
B. Research Contributions Cooja facilitates to develop, debug, and evaluate IoT projects
This article main contributions are as follows: [32] at varying emulated hardware details level [33].
• A measurement methodology for current and future Inter- Contiki is an IoT open-source OS that allows the connection
net experimentation, evaluation, and comparison focused of microcontrollers (8051 up to ARM) to the Internet, making
on IoT applications. This work includes how to instantiate it a powerful tool for complex wireless systems [33], [34].
components, measure results, and adjust the scale of the Besides, it supports IPv6 along with 6LoWPAN and routing
scenarios. Comparisons between current Internet and FI protocol for low-power and lossy networks (RPL) standards.
from client applications up to IoT gateways are available. Docker [35] is an open-source tool that automates container
• Design of an innovative environment converging disjoint deployment. Upon isolating applications from others in a
tools that encompass containerized, emulated, and sim- typical computer [36], this platform provides a lightweight and
ulated network components. The environment deploys fast environment. In addition, it presents an efficient workflow
isolated network components that foster the evaluation and the required portability to run the same code regardless
of IPv6 Internet and the XIA stack. of the hardware supporting it [36]. Binary images support
• A specialized IoT gateway service that enables the eval- containers, which can contain one or more running processes
uation of FIoT. The aim is to create an alternative way [36]. Every container starts from an image, presenting a
of experimenting/evaluating new architectures without layered format built step by step using a series of instructions.
modifying their source code and integrate legacy sen- Containers are handily portable, managed, and shared [36].
sor/actuator nodes. Through proper modifications, this
gateway can handle other FIA alternatives. B. eXpressive Internet Architecture
XIA is an FIA project with native support for many endpoint
C. Paper Organization types, i.e. a type is an entity that connects to the network. This
The article remainder is organized as follows. Section II solution bases on an evolutionary principle, accommodating
grasps on a brief background discussion. Then, Section III any and yet new unforeseen principal types (PT) over time
covers related works in terms of FIA, FIoT proposals and [4]. Generally speaking, this solution relies on four essential
an analysis of its current state-of-the-art. Sections IV and V ideas to make its design scalable and secure [37]–[39].
present the proposed FIoTE3 and its methodology for IPv6 1) Principal Types: XIA applications may use one or
and XIA. Section VI reports the results and compares IPv6 more PTes to express their intention using unique eXpressive
and XIA performance for IoT. Section VII outlines the lessons identifiers (XID)s guiding the network regarding specific func-
learned. Finally, VIII concludes the article. tions required. Each PT has its communication and processing
 3

semantics, required to forward packets with their address type, cycling, unique identification, mobility, joint content, services,
while being defined by their intrinsic (identifier-based) security and things orchestration [2]. In NG, any physical resource
properties. The specification of each PT must also encompass may be represented by named services. In [2], the following
the related packet processing logic, along with a globally ingredients have been integrated to support FIoT: (i) name-
unique XID. New applications and protocols can exploit the based publish/subscribe of IoT data from network cache; (ii)
XIA legacy types once new PTes are introduced, without contract-based operation of IoT services; (iii) software-defined
further modifications in the physical network to support them. control and management of IoT devices; (iv) decoupling of IoT
This fact enables incremental deployment of native network devices identifiers from locators (ID/Loc splitting).
support without further changes to endpoints. Named-data networking (NDN) focuses on the data rather
2) Flexible addressing scheme: XIA provides a built- than the traditional TCP/IPs host-centric approach [43]. Data-
in mechanism called fallbacks to enable the incremental centrism aims directly at securing the data itself rather than the
deployment of new functions. For example, XIA relies on data storage, exchange, or processing [44]. Each data portion
this mechanism when a legacy router has to handle a new has its globally unique name and its forwarding/routing is
PT. Hence, fallbacks allow communicating parties to specify based on a given requested name [45]. Focusing on its naming
alternative actions if routers cannot operate under the primary scheme, NDN employs a unique and hierarchically structure
intent [4]. In other words, alternative IDs are employed to that conveys the relationship and context between the data
forward/route packets, in the worst case using autonomous elements and its storage [21], [43].
domains, service IDs (SID)s, content IDs, and host IDs. Another example of ICN is MobilityFirst (MF) [46]. This ar-
3) Intrinsically safe identifiers: XIA ensures security with- chitecture has mobility and trustworthiness as its main corner-
out compromising expressiveness. In particular, PTes, used in stones [47]. Moreover, it assumes that the exponential growth
XIA source and destination addresses, must be intrinsically of the number of mobile devices will generate significant
secure, granting cryptography derived from the associated traffic that would burden the current Internet model [48]. This
communication entities in a principal type-specific manner, is because of the diversity of mobile devices, which are not
making them self-certifying. This allows reporting entities exclusive to smartphones, but also encompasses other wireless
to assess more accurately the security and integrity of their gadgets [47], such as wireless sensors, machine-to-machine
transfers. For example, a publisher can ensure that the network interactions, vehicular scenarios, and e-Health applications.
delivers specific bytes to intended recipients [4].
4) eXpressive Internet Protocol: The eXpressive Internet
D. Future Internet of Things
Protocol (XIP) replaces IPv4/IPv6, being independent of the
PT. XIPs define the packet header, the packet processing IoT is one of the latest evolution of the Internet that
logic at network nodes, and the address formats based on incorporates a diverse range of devices, such as sensors and
XIDs. XIP’s key element is the flexible format for specify- actuators, and services deployed by different stakeholders for
ing multiple paths to a target principal, allowing backward supporting a variety of applications in smart environments.
fallbacks that may use a more traditional autonomous system The information captured by things presents an unprecedented
and host-based communication [4]. XIA allows senders to opportunity to solve large-scale issues in diverse domains, fos-
express their intention by specifying a typed XID as part of tering valuable smart-environment services. Examples include
the XIP destination address. A recursive XID-based routing precision agriculture, smart health, manufacturing, and cities
improves scalability and eliminates the need to support global [49].
reachability for all types. At each hop, the router can decide Considering IoT devices, the majority has limited comput-
whether it understands the PT’s intent, properly routing a given ing power, given the nature of their hardware. This halts the
packet without searching through the rest of the hierarchy development of many protocol stacks directly on these devices
scope. This concept is called iterative refinement of intent. [6] since many current and novel approaches typically require
superior computing power. For instance, the HTTP/TCP/IPv6
stack has been modified for IoT, since embedding it with-
C. Other Future Internet Architectures
out modifications is quite challenging for many IoT device
Recursive InterNetwork Architecture (RINA) starts from the families [6]. On the other hand, FIoT can be defined as “an
premise that networks are just inter-process communication IoT build from the synergistic integration of revolutionary
(IPC) [40]. Therefore, it provides IPC for applications running and evolutionary networking paradigms to support connected
in distributed systems, generalizing the local IPC model [41]. things” [2]. The next section covers how FIAs are addressing
In contrast to the current Internet model, RINA is based on IoT, giving rise to the term FIoT.
a single layer abstraction, which creates recursively repeated
distributed IPC facility (DIF) as required by the network
III. H OW FIA S A DDRESS I OT?
designer, providing IPC services to other DIFs or applications
above, i.e. a distributed application facility (DAF). This section covers works that relates with this research.
NovaGenesis (NG) aims at the exchanging, processing and The selection of articles is narrowed to FIAs that exploit IoT
storage of data, including the network caching [2], [42]. and its experimentation. Table I synthesizes the research works
It integrates state-of-the-art ingredients to create a generic concerning FIoT. To the best of our knowledge, this article is
framework to handle naming, name resolution, entities life the first effort covering this literary review of FIA and IoT.
 4

Regarding design principles, RINA focuses on Virtual Net- lated nodes in the context of the Fed4FIRE+ experimentation
work Function (VNF) for recursive and standardized IPC. facility. Ethernet technology has connected IRATI RINA DIFs
This approach is interesting for IoT devices security and transporting video, voice over IP, file sharing, etc. IRATI
services connectivity. Meanwhile, NG adopts a “everything as RINA is further advanced by Grasa et al. [64], wherein they
a service” paradigm, which includes protocol implementations, build an open-source implementation. This paper mentions a
allowing dynamic layering via service composition. Uniquely lightweight version of RINA called rlite, which is a C/C++
identified VNFs can be connected to provide Service-Centric open-source implementation of RINA for Linux and runs
Networking (SCN). NG also implements an ICN overlay using over UDP, Wi-Fi, and Ethernet. For Wi-Fi connectivity, the
publish/subscribe communication model, which is interesting Linux hostapd software implement access point (AP) functions
for cache-based IoT data distribution. NovaGenesis, therefore, for registered IPC processes. The rlite repository1 includes a
integrates ICN and SCN to support unique and unlimited iden- detailed tutorial in how to start using RINA with Wi-Fi.
tification, localization, and delivery of architectural entities, The experimentation and evaluation environment for
a feature very important for the future IoT. XIA is also not NovaGenesis (NG-FIoT) encompasses an embedded
centered on a specific architectural citizen, rather providing lightweight implementation of NG stack in the IoT device
an expansible solution based on principal types. XIA provides called Embedded Proxy/Gateway Service (EPGS) [2].
similar ICN and SCN convergence for IoT. RINA can be seen Proxy/Gateway/Controller Service (PGCS) represents EPGS,
as an SCN approach, while NDN is usually referred to as an which negotiates IoT devices’ capabilities to interested IoT
ICN approach, treating content as the primary citizen. The applications. EPGS runs in a proprietary EventOS operating
support for VNFs is not the main objective in NDN, although system developed for NXP LPC 1769. In [2], two LPC1769
this proposal allows named services. As you can see, each (ARM Cortex-M3) with up to 32 kbits of SRAM memory
approach drives one or more aspects of FIoT requirements. has connected to a notebook via a Wi-Fi access point. PGCS
Diversity also happens in the communication model. RINA provides IoT gateway service over Wi-Fi for these two
has adopted a location-independent model for data forward- EPGSes. More recent developments have extended PGCS
ing. In this way, IoT data can follow a path that connects for LoRa and ZigBee. PGCS manages devices’ Wi-Fi/IEEE
IPC instances in the same layer, covering from end devices 802.15.4 operating channels, as well as the VLAN ID of the
up to gateways and data center equipment. NG generalizes incoming frames [3]. Results from [2] indicate that NG-FIoT
forwarding/routing by providing a generic packet header and has fewer memory requirements than a stack with RPL
ID/Loc splitting for all entities (including the ones in IoT), and 6LowPAN and performs IoT data exchanging in a few
enabling routing on domain, hosts, operating systems, and milliseconds in a local network domain. A control plane to
services’ IDs. NDN has by default a pull-based communication change IEEE 802.15.4 RF channels has been done in [3].
model, wherein the receiver expresses its interest in the desired NDN is probably the most popular FIoT, being adapted
content. For IoT, push-based communication is being provided. for IoT in many ways. Concerned with constrained embedded
XIA provides multiple communication models at the network devices, Shang et al. [43] adapts NDN into RIOT-OS, i.e. an
layer, allowing Expressive Internet Protocol (XIP) to run on OS for constrained IoT platforms, generating the NDN-RIOT.
IoT equipment. In XIA transport layer, client/server model This version provides NDN’s key features even on limited
has default support. Many current IoT approaches bases on hardware, where it can use IEEE 802.15.4 and the traditional
the publish/subscribe model asynchronous communication. In Ethernet stacks. The presented demo application is embedded
this context, only NG offers something similar to current into a 32-bit ARM Cortex-M0+ with 32 KB of RAM and
techniques, e.g. Message Queue Telemetry Transport (MQTT). 48MHz and a 32-bit ARM Cortex-M3 with 64KB of RAM and
The next line of Table I summarizes related work on how 72MHz microcontrollers and requires 40KB of flash memory.
each FIA specifically has addressed IoT so far. Starting from The first deployment of NDN with IoT in real environments
RINA, a RINA-based IoT architecture is defended by Rizinski has spread 60 nodes through several rooms and buildings from
et al. [50]. While presenting RINA’s benefits, it also addresses their university [58]. Each node has a CC1100 radio chip
main IoT challenges, including interoperability, packet frag- operating at 869MHz and several sensors, while a monitoring
mentation, cost, and security. Unfortunately, the paper does and management Ethernet link interconnects them to a docker
not cover a performance evaluation. station. In this setup, there are a single content producer
Ramezanifarkhani et al. develop a survey [51] on how RINA and multiple consumers that use wireless communication to
addresses IoT challenges. They focuses on protocol stacking, request hierarchical data. Thus, it is examined the results in
repeated network functions in different layers, addressing, terms of ICN caching, energy consumption, and the wireless
security, and attack mitigation. Hence, a list provides twenty broadcast deployed. Moreover, the authors compare the exper-
features that RINA offers for IoT security. A more concrete iment with the current stack for IoT, i.e. 6LowPAN/RPL/UDP.
scenario and performance evaluation is missing. NDNoT [55] is an effort to adapt the NDN architecture
Maffione et al. [52] develop a Software Development Kit considering the IoT stack. There are several changes, yet it fol-
(SDK) for an open-source RINA implementation called “In- lows NDN-RIOT premises of ensuring security, naming, and
vestigating RINA as an Alternative to TCP/IP (IRATI).” IRATI packet restrictions. One of its highlights is designing a protocol
enables RINA experimentation over IP, Ethernet, and Wi-Fi, capable of supporting NDN and IoT devices, conveying their
and it has been evaluated in a distributed cloud provider.
Perell et al. [53] developed a RINA scenario with 37 emu- 1 https://github.com/rlite/rlite
 5

Table I
F UTURE I NTERNET OF T HINGS APPROACHES .

Aspects RINA NovaGenesis NDN XIA MF

Named data is the corner-
Named service-oriented stone. Each IoT data portion Support for multiple PTs, in-
Everything is IPC. Recursive Mobility and trustworthiness
resources. Flexible naming has a single globally unique cluding domains, hosts (IoT
protocol layers grants comm. as cornerstones. A hybrid sys-
scheme, name resolution and name and hierarchical nam- devices), services and data.
and services. Provides a fixed tem that decouples things and
name bindings to manifest ing structure conveys IoT en- Flexible transition to novel
set of customizable VNF in data identifiers, which are
Design entities relationship. Names tities relationships. Decouples principals in routing. Alterna-
every IPC, which could be perennial, from the locators,
princi- are unique in a given scope, content identifiers from loca- tives to TCP (Xstream and
optimized for IoT. Focuses on which are temporary. A flat
ples which enhances IoT data tors. Packets identify desired XChunkP), UDP (XDP) and
securing layers and their pro- GUID for all entities. A global
provenance. Distributed gateway data by their names. IP (XIP) allows FIoT. Named
cesses. Allow flexible nam- name resolution service to re-
naming resolution, which Popular IoT data is temporally entities and name resolution.
ing, including unique identifi- solve GUIDs to locators.
allows to resolve things IDs stored in network cache. For Mobility supported by ID/Loc
cation of instances.
to Locs. IoT, push comm. model adap- splitting.
tation is required.
Publish/Subscribe model Multiple comm. models via
A location-independent model Pull- and push-based comm.
for services comm. Other PTs. The transport layer is Pull-based communication.
Comm. for IoT data forwarding is driven by IoT consumers.
models can be implemented. similar to the current Inter- Distributed on the path
Model envisioned. Data follows the Distributed on the path in-
Distributed out of path net, supporting client/server in-networking caching.
path of IPC instances in a DIF. networking caching.
in-networking caching. model.
• NDN architecture into
RIOT-OS [43] .
• NDN architecture into IoT
stack [55].
• IoT stack based on RINA
• Lightweight implementa- • NDN evaluation with • An information-centric ap-
[50].
tion of the NG architecture Python and Raspberry-Pi proach called SoftStage for
• Detailed description on how
into the IoT stack [2] . [55]. mobile vehicular content
RINA addresses IoT chal-
• Spectrum management sys- • NDNoT library for RIOT delivery based on edge
Approach lenges [51].
tem with NG, Wi-Fi and and Arduino OS [56]. caching and XIA stack [62].
for • SDK for IRATI — • A MF IoT Platform [59]–
IEEE 802.15.4 [3]. • Arduino ATmega2560, sen- Data chunks have been
future a RINA open-source [61], [63], with support for
• Convergence of cognitive sors, and Ubuntu 14.04 have transferred from XCache to
Internet implementation [52]. mobility, service discovery,
radio network (CRN), IoT been employed in a NDN a requesting application us-
of • RINA evaluation scenario and pub/sub model.
and a future Internet for scenario for IoT [57]. ing content IDs and a proto-
things with 37 emulated
low-cost embedded cooper- • A real life CCN experiment col similar to TCP. Experi-
nodes over Ethernet
ative sensing and cognitive with up to 60 nodes spread ments have employed XIA
in the Fed4FIRE+
radio architecture for IoT several rooms, floors, and prototype on Click modular
experimentation facility
applications [54]. buildings [58]. router.
[53].
• NDN IoT Platform [59]–
[61] with support for mo-
bility, service discovery, and
pub/sub model.

NDN has been evaluated

Experimentation
RINA has been evaluated with with physical devices, VMs, Virtual and physical devices. MF has been evaluated
NovaGenesis has been eval-
and physical devices and VMs and containers with emulated An emulated vehicle to in- through simulations, which
uated with physical devices,
perfor- with emulated hosts. Regard- hosts. Regarding FIoT frastructure scenario was em- have consisted of a smart
VMs and Docker containers.
mance ing FIoT applications, it has applications, it has presented ployed to evaluate mobile campus, smart bus, and
A scenario with FIoTE3 is un-
evalua- experimented with up to 37 a real deployment with up to content distribution. XIA ran 20x20 IoT sensor node grid
der development.
tion emulated nodes. 60 nodes in a laboratory and natively on Wi-Fi link layer. scenarios.
simulated experiments.

capabilities into network services abstractions and representing with heterogeneous devices, mobility, and named content.
each device response as JSON. Besides, it has presented In specific, MF is not originally suitable for IoT because
a smart home application with Python and the Raspberry- of its long 20-byte GUID and required computation and
Pi toolkit. Advancing, authors from [56] present a work in storage power. Therefore, Li et al. designed a gateway that
progress for a flexible NDNoT library for Arduino hardware translates GUIDs into a 2-byte locally unique ID (LUID) for
with RIOT and an IoT network that can be controlled from IoT domains. This mechanism allows MF-IoT to ensure the
Android, Linux, or macOS systems. In another work [57], MF’s global reach-ability with this persistent and accessible
Divya et al. consider NDNoT into smart health applications. identifier, wherein border gateways promote the mapping
A prototype for remote monitoring and diagnosis of patient between GUIDs and LUIDs, resolving the names for any
healthcare and wellness takes advantage of NDN mobility and packet destined to its domain [63]. Meanwhile, NDN also does
security and the NDNoT stack. This prototype has several not support the pub/sub model. In [59], the authors validate
sensors, an Arduino ATmega2560 that transfers data to a the NDN-IoT and MF-IoT through a simulation of a smart
mobile Ubuntu 14.04 personal computer through a wireless campus with a substantial number of IoT devices and a smart
LAN. school bus that is movable. In [60], Zhang et al. focused on a
simulation to analyze the service discovery performance with
Proposing to unify ICN and IoT through a unique plat, Li ndnSIM for NDN and NS3-based MF. Lastly, they investigate
et al. [59]–[61] have proposed works that leverage the benefits a simulated network domain with up to 20x20 sensor nodes
of ICN for IoT, establishing procedures for service and device grid, with the 802.15.4 standard and 250 kbps of bandwidth in
discovery, enabling pub/sub model and routing. In [59], they [61]. Through these experiments, they have analyzed several
have focused on an ICN-IoT platform that integrates NDN network aspects in terms of throughput, delivery success rate,
(NDN-IoT) and MF (MF-IoT), which is capable of dealing
 6

and overhead for comparing the performance of IP with resources required and exploiting open-source tools, FIoTE3
UDP/6LowPAN, NDN-IoT, and MF-IoT. In sum, they pointed becomes a feasible environment for most computer network
that both architectures have similar performance results, yet laboratories. Running in a cloud environment is also possible,
MF-IoT has the upper hand due to its better overhead and but it is not a requirement. If used in a public or private
routing performance. cloud computing environment, the solution can be scaled up
Table I also points out that physical and virtual machines by optimizing the number of physical machines and Docker
are the predominant environment for evaluating future IoT containers employed.
proposals. So far, only NG and NDN have employed Docker As far as the authors know, this is the first effort at develop-
containers. However, the diversity of methodology and evalua- ing a fair environment to experimentation and evaluation for
tion scenarios is common. Works like FIoTE3 are imperative to FI and the current Internet stack. In this way, we do not have
improve FIoT evaluation, improving fair comparison between any other candidate to present as benchmarks to our proposal.
scenarios. As can be seen, some FIAs, such as NDN and NG,
have already provided light versions of their stacks. However,
two paths are possible considering architectures that do not
offer this: (i) develop these versions on your own, which is an A. Design Choices
utter issue; or (ii) evaluate these novel FIA implementations in This subsection describes decisions taking while designing
scenarios that present IoT gateways. In the latter, the feasibility FIoTE3. First of all, Contiki was selected for IoT Motes
requires fewer adaptations of the FIA stack, yet it is more operating system (OS), since it is one of the most used OS
limited in terms of evaluation. Still, this option can be seen for IoT. Moreover, Contiki provides a dynamic structure that
as a first step in experimenting with new architectures, paving allows programs and drivers to be replaced at the run-time,
the way for valuable lessons and the final adaptation of clean which is a differential from other OSs, such as TinyOS [34].
slate protocol stacks for IoT. In addition, Contiki enables the deployment of applications
This is exactly the case for XIA. The FIA community inter- with Texas Instruments Sensor Tags CC2650, which are cheap
est is significant, but the architecture lacks an embedded ver- tags available in many IoT labs.
sion for IoT devices. In addition, XIA’s XIP headers are larger
Similarly to Contiki, Cooja was employed to meet the
than the current IoT protocols, such as ZigBee, Bluetooth
requirements of flexibility in experimentation. Cooja is a
Low Energy (BLE), and 6LoWPAN. Based on these facts, this
widely used IoT simulator and it is conveniently integrated
work evaluates XIA interoperation with current IoT protocols
with Contiki [65]. Besides, it allows to run slightly different
by implementing a novel XIA/IPv6/6LowPAN gateway. This
programs or different versions of the same software on sensor
gateway enables experimentation and comparative evaluations.
nodes [34], being these emulated or physical. The Docker plat-
Despite its compelling characteristics for IoT, XIA is one of
form was selected to enable the virtualization of components.
the least explored architecture for FIoT.
Containers present advantages when compared to VMs.
In conclusion, each FIA is unique once each project ad-
vocates for disjointed ingredients that build its proposals. A Regarding the link layer technology, 6LoWPAN was se-
unique environment for evaluating every case is a distant aim. lected due to its simple integration into the Cooja and to the
However, FIoTE3 could add other FIAs under its scope with fact that 6LoWPAN is the only protocol that is encompassed
some adjustment. As FIoTE3 grows, it must develop updates into the IETF stack for IoT. Moreover, it can be a fair candidate
to incorporate new architectures into its domain. Another to compare with the XIA architecture. The Cooja IoT Mote
observation drawn is that every FIoT research only considers firmware is a 6LoWPAN Echo Server, i.e. an Echo-Server
its architecture proposal. Hence, they do not contrast its results that receives UDP packets and returns back to the source.
with other FIA candidates. Probably the fact of disjointed Therefore, UDP was also chosen for FIoTE3.
ingredients or an impartial analysis impact. Finally, XIA was the architecture chosen to be integrated
into this work, since it is a well-documented project, has a
functional prototype, and a wide range of applications [37],
IV. F UTURE I NTERNET OF T HINGS E XPERIMENTATION [66]. Even though, XIA has not been applied to the IoT in
AND E VALUATION E NVIRONMENT
any literature work yet (to the best of our knowledge). This
FIoTE3 is an environment for architectures and proto- is, therefore, an excellent open research opportunity.
cols experimentation and evaluation. Following its current It is crucial to highlight that all FIoTE3 components are
benchmarks, FIoTE3 aims to encompass open-source tools, virtual and emulated. Only one physical computer (Fig. 1)
virtualizing most of its resources and adapting to most com- can be used to deploy all the environment, however it can be
puter hardware as possible. One of the major concerns of fully distributed in many computers. The evaluated network
this work is to develop a standard scenario with a simple is divided in two portions: (i) the IoT portion with Cooja
topology for data collection, monitoring and uncomplicated emulated Contiki IoT Motes and simulated wireless 6LowPAN
configuration mechanisms, which implements fair criteria for IoT network; and (ii) the access network portion that is fully
distinct architectures. The solution aims to be very cheap. implemented by a virtual Docker Ethernet bridge, accommo-
FIoTE3 leverages scalability and flexibility while executing dating the IoT Clients for data requests into the IoT portion.
a number of components over commodity physical com- The bridge between the two portions is made by a Docker
putational power. By diminishing the specialized physical container that runs a Gateway.
 7

B. Architecture the IoT Motes capable to reach and route packets. The
6LowPAN network is simulated by the Cooja tool. The
FIoTE3 encompasses five components that are implemented Border Router is a modified IoT Mote that translates IPv6
as Docker images on the network access portion of the to simulated 6LowPAN.
environment. These are the IoT Client, Gateway, Client Router,
The main difference between the proposed scenarios (Figs.
Gateway Router, and the Main Server. Each component is net-
1-a and -b) lies in the fact that IPv6 Echo-Client is ready
worked via container bridges forming a hierarchical network
to connect with the IoT Motes, naturally. For other protocol
topology. The communication follows the client/server model,
stacks, such as XIA, Gateway Services must be deployed on
wherein the IoT Client is the client and the IoT Mote is the
the Gateway component to translate protocols and achieve
server. This topology can be scaled by improving the numbers
effective communication. Each Gateway Service represents a
of Containers. The architecture encompasses the following
Cooja IoT Mote (Echo-Server) running in the Gateway and
components (as illustrated in Figs. 1-a and -b):
each Echo-Server is located through its mote’s IPv6 address
• Main Server: It is a interconnection point for the access and UDP port number. On its own, the Gateway Service is
network, routing traffic from all Client/Gateway Routers. crucial to translate UDP/IPv6 to any protocol that may act as
It deploys a name resolution service (NRS) in XIA and a plugin to the FIoTE3 scope in the future. For comparison
a DNS service for IPv6. It is configured as a Docker purposes, this service is similar to a network bridge that
Data Volume to store testing results and exchange con- enables the communication between distinct architectures.
figuration files between containers. A Data Volume is a Therefore, FIoTE3 becomes expansible once new specific
directory within one or more containers that bypasses Gateway Services can be added. A Border Router inside Cooja
the Docker storage system, interacting directly with the connects each IoT Mote to exactly one Gateway Service.
host file system and providing many useful features for
persistent or shared experimentation data. C. Integration with XIA
• Client/Gateway Routers: Gateway and Client Routers For the hybrid XIA/IPv6 scenario (Scenario 1), Fig. 1-a, a
are identical and implement the same network routing XIA IoT Client (Echo-Client) was developed using XDP over
function to forward packets to and from IoT Clients and XIP over Ethernet. Gateways host a Cooja instance to emulate
Gateways, respectively. Both use the same Docker Image. IoT motes. A border router connects each mote to exactly one
• Gateways: Gateways run Cooja tool to simulate the IoT gateway services, which translates UDP/IPv6 to XDP/XIP and
wireless portion of the network and to run a Gateway vice-versa.
Service when required (only for Scenario 1), translating The IoT Mote (Echo-Server) runs the same code for Sce-
XIA protocols to UDP/IPv6. narios 1 and 2, receiving UDP/IPv6/6LowPAN requests and
• Gateway Service: As long as the emulated motes in answering them to the IoT Clients (Echo-Client) in the access
Cooja do not directly support FIAs, a Gateway Service network. A Gateway Service translates XDP to and from UDP,
is required to translate FIA protocols into IPv6 in the as well as XIP to and from IPv6. More specifically, the IoT
IoT portion of the network. Multiple Gateway Services Client in the Scenario 1 runs a XIA-Prototype [37] on a Linux
(one for each IoT Mote) run on a Gateway container. Ubuntu container, which is a modified version of the Click
Each Gateway Service registers a name in the NRS. Modular Router [67] to enable the data collection by randomly
The Gateway Service also performs delay and error selecting Echo-Servers via the NRS, generate a payload and
measurements for more accurate results collection, but run a certain number of trials. This XIA IoT Client application
only for packets coming from the IoT network portion. facilitates the deployment, but generates some overhead and
The measures of each request are stored in another file additional complexity. The XIA Echo-Client uses the XDP for
saved in the IoT Client’s Server Data Volume. data transport.
• IoT Clients and Motes: IoT Clients are containers that The Gateway Services are responsible for the transport
run an Echo-Client component for requesting data from between the IoT and the XIA networks. The Gateway Service
a random selected (via NRS or DNS) IoT Mote inside assigns a SID to the XDP service, registering its Echo-
Cooja. An IoT Mote is an emulated Contiki node with an Server locator in the NRS and forwarding the incoming XDP
Echo-Server that answer XDP (in XIA) or UDP requests packet payload to an Echo-Server through the UDP protocol.
from the IoT Client. Performance measurements of each Moreover, the Gateway Service waits for a timeout period to
request are stored in the Main Server Data Volume. forward any UDP packet’s payload that the Echo-Server may
• Border Router: The IoT Network access point is made reply to the source SID in the pattern of the XDP packet. This
by a Cooja simulated mote inside Cooja, which is enables the Gateway Service to support not only communi-
configured as a Border Router connected directly to cation between Echo-Clients and Echo-Servers but also the
the Gateway through the tunslip6 application from the development of other XIA applications to communicate with
Contiki repository. This creates an IPv6/Serial tunnel to new or existing UDP applications. The Gateway Service is
the Border Router serial port, which is responsible for developed using C and Python socket APIs for XIA (Xsocket
routing IoT Network packets (it has a specific firmware API), providing bootstrap and supporting network services. In
to perform this function). Therefore, the Border Router is other words, XIA is deployed in the Gateway Service, as the
not an Echo-Server and it does not represent a Gateway XIP network protocol stack acts as a bridge between XIA and
Service, yet it provides an address table that contains IPv6/6LowPAN domains.
 8

Figure 1. All FIoTE3 components can run as Docker containers. More physical machines can distribute the processing load. Cloud computing can deploy
larger setups. Docker Ethernet bridge connects components in different containers within a single physical machine domain. Cooja tool runs inside the Gateway
container. The Gateway Router connects Gateways to the Main Server only for name resolution and experiment data storage purposes. FIoTE3 evaluation
scenarios: a) Scenario 1: Hybrid XIA + IPv6 use case, where the Gateway Services translate the communication protocols b) Scenario 2: For comparison
purposes, a Pure IPv6 architecture, where UDP over IPv6/6LowPAN connects all domains. This case does not require the Gateway Service.

V. E VALUATION M ETHODOLOGY B. Scenario and Input Parameters Definition

Firstly, FIoTE3 requires selecting the architecture scenario
This section presents a methodology for IoT/FIoT exper- to evaluate. At this moment, there are two ready scenarios.
imentation, evaluation, and performance comparison. In the One of them is the hybrid XIA/IPv6 scenario with an XIA
following subsections, the proposed methodology is presented, XDP/XIP gateway to IPv6/6LowPAN, hereafter called Sce-
accordingly to the following steps: (i) physical environment nario 1 (as illustrated in Fig. 1-a). For the second, FIoTE3
preparation; (ii) scenario and input parameters definition; (iii) simulates a pure UDP/IPv6 and UDP/IPv6/6LowPAN network
containers and virtual network execution; (iv) scenario config- (as depicted in Fig. 1-b), referenced as Scenario 2. For this
uration; (v) conducting experiments and results collection; and prototype, the user must input the parameters present in Table
(vi) containers releasing. To reproduce experiments carried out II. This table standardizes the topology conceiving in terms
in this article, one must download the open-source version of of c for IoT Clients, g for Gateways, and L for the Data
FIoTE32 and run the tool with the same parameters. Size parameters. Fig. 2 exemplifies the input parameters in a
generic network topology. In this case, there are two Gateway
Routers (G = 2) with two Gateways (g = 2) each and two
A. Physical Environment Preparation Client Routers (C = 2) with two Clients (c = 2) each. In the
default configuration, each test has a Gateway that emulates a
The selection of the physical machines to run FIoTE3 is the total of 10 motes, from which one is the Border Router. Each
first step in the evaluation methodology. For large scenarios, IoT Client issues a total of 10,000 requests per test. Afterward,
several physical machines could be employed locally or in the quantity of IoT Clients, Client/Gateway Routers, and
a public/private cloud. In this article, we have selected the Gateways alters to evaluate the FIoTE3 scalability.
physical machine available in our laboratory. This is a Dell
PowerEdge 7640, with two processors Intel R Xeon TM Silver C. Containers and Virtual Network Execution
4114 10 Core and 256GB (8x32GB) RDIMM DDR4 2667 FIoTE3 main script handles Docker containers deploy-
MT/s. ment, instantiation of internal processes, and bootstrapping
of Docker images. All containers receive the setup infor-
2 FIoTE3 is available at https://github.com/monrapps/XIoT. mation through environment variables, so it reproduces truly
 9

Figure 2. FIoTE3 Evaluation scenario. FIoTE3 establishes a given network topology based on the input parameters (c, C, g, G, and L) to build the desired
architecture evaluation scenario. The number of IoT Motes (m) and Main Server is fixed in this version.

the overall network and software configurations. A Results receives an IoT Mote table and, then, FIoTE3 initializes a
Gathering function collects the performance data from the Gateway Service for each table in Scenario 1. After all Motes
physical machine(s) that performs the tests. have a Gateway Service, the Gateway container executes the
Initially, FIoTE3 creates a Docker Data Volume in the Main application until the Main Script stops it. For Scenario 2, the
Server to store the experiment results and then configure the DNS server registers the address of each IoT Mote in the form
Server network. After this, FIoTE3 sets the Network settings of m.g.G.
and boots the NRS. The Main Server route packets and resolve
names until interrupted by the Main Script. Following, it D. Deployment and Results Collection
initializes each Gateway Router and its g Gateways. The The test scenarios evaluate the FIoTE3 performance in
Gateway Network then connects these g Gateways to their terms of overall network delay, packet loss, and CPU usage.
respective Gateway Router. Afterward, FIoTE3 establishes the Therefore, the authors investigate these metrics under three
link that allows the connection between a Gateway Router and specific cases by varying a topology parameter of IoT Clients,
the Main Server. This process repeats until FIoTE3 sets up Gateways, or Packet Size for both hybrid XIA/IPv6 and the
all Gateways and Gateways Routers. Similarly, it starts up the pure UDP/IPv6 networks. The first case evaluates the Main
IoT Clients Network, connects c IoT Clients to their respective Server’s behavior and delay profile under a growing topology
Client Router, which joins the Main Server network. of IoT Clients with a single and constant IoT Server network
domain. The second case considers an expanding topology that
Table II increases the IoT Servers domains, where the Gateway Service
C OMPONENTS OF FI OTE3. can interact with a group of IoT Clients through a Client
Number of IoT Clients per Client Routers IoT Clients c Router. In other words, a larger IoT domain is fragmented
Number of Gateways per Gateways Routers Gateways g into smaller and specific IoT domains to split the network
Number of IoT Motes per Gateway Motes m traffic and processing load. The last case assesses the overall
Number of Client Routers Client Routers C
impact of increasing the packet size in a controlled topology.
Number of Gateway Routers Gateway Routers G
Size of the payload in bytes Data Size L Summarizing, the three cases encompass the following setup:
Number of Requests Requests r • In the first, the number of Clients varies. In this setup, 5
Client Routers connect to a variable number of Clients,
Following the startup process, the Gateway container starts totalizing 5 to 35 Clients in the topology. The number of
the Cooja firmware and the tunslip after establishing the Gateways Routers (G=5) is constant, serving 10 Gate-
simulated virtual wireless network settings. Border Router ways (g), adding a total of 50 Gateways and 500 Motes.
 10

There are always 1 Border Router and 9 IoT Motes (m) VI. R ESULTS AND D ISCUSSION
for each Gateway. In other words, 50 Cooja instances In this section, FIoTE3 has been employed to eval-
emulate 10 IoT Motes inside. Data size packets (L) are uate aforementioned Scenarios: XIA interoperability with
also stable in 8 bytes; IPv6/6LoWPAN (Scenario 1); and pure IPv6/6LowPAN with
• In the second, the number of Gateways (g) varies from 1 UDP connectivity (Scenario 2) with distinct topological con-
up to 12. In this topology, 5 Gateway Routers (G) connect figurations.
each set of Gateways to the Main Server, providing a total
number of Gateways from 5 up to 60. As a consequence,
the total number of IoT Motes changes from 50 up to A. Hybrid XIA and UDP/IPv6/6LowPAN: Scenario 1
600. Besides, there are always 5 Clients (c) for each one 1) Delay Analysis for Increasing Number of Clients: The
of the 5 Client Routers (C), computing 25 Clients that Total Delay (round trip time) is the sum of two partial
exchange data packets (L) of 8 bytes; delays measured components accordingly to network clouds
• At last, the packet size modifies in fixed values of 8, 16, illustrated in Fig. 1-a: (i) UDP/IPv6/6LowPAN Delay and
32, and 64 bytes (L). The remaining topology parameters (ii) XDP/XIP (XIA) Delay. As Fig. 3-a shows, the delay
are g=10, G=5, c=5 and C=5. in the UDP/IPv6/6LowPAN segment remains almost constant
A function collects the related data to each execution and when the number of IoT Clients increases from 5 up to 35,
stores these samples on the Docker Data Volume while the showing that the data requests replies have almost the same
IoT Clients are still running. When the Main Script shuts all performance inside the UDP/IPv6/6LowPAN IoT portion. For
IoT Clients down, it also copies all files from the Data Volume the XIA access network portion, the experienced delay in-
to a database located in the local machine. Notice that even creases linearly with the number of active Clients. The more
though packet loss may occur during each trial, they are not clients, the more simultaneous requests that are waiting for a
relevant once the application resends them. response at the Gateway. The packets arriving at one Gateway
1) Network Delay: The network delay evaluates the average Service are placed in a queue, while previous packets are being
Round Trip Time (RTT) that an IoT Client experiences while processed and forwarded. Therefore, the XIA access network
having a request fulfilled by an IoT Mote. For FIoTE3 scope, it delay increases linearly as the number of IoT Clients increases.
considers a successful transmission whenever a reply achieves 2) Delay Analysis for Increasing Number of IoT Motes:
its origin without a timeout. Therefore, it calculates the latency Due to some restrictions from the Cooja’s Border Router, we
by the difference between the arrival (ta) and departure (td) have increased the number of Gateways with a fixed value of
time in the same clock reference. FIoTE3 defines packet losses IoT Motes per component. Hence, this avoids considerable
when the RTT is longer than the timeout or when it detects a packet loss once each Gateway has 10 Motes. We have
corrupted packet. A test finishes when FIoTE3 fulfills all the investigated broader numbers of IoT Motes per Gateway, but
configured requests. Through the obtained latencies, FIoTE3 experiments resulted in relevant packet loss. This practice is a
calculates the simple average between all samples, considering common situation in IoT setups, in which Border Routers are
the total of successfully received packets, which is the same limited to store few bytes in memory.
(r) input parameter. Equation 1 calculates the Network Delay The effect of adding more IoT Motes (and Gateways to
as follows: serve them), while keeping the number of IoT Clients constant,
is shown in Fig. 3-b for the UDP/IPv6/6LowPAN and XIA
Pr
i=0 tai − tdi network portions delay. The UDP Delay remains almost con-
N etworkDelay = (1) stant in 200 ms as the number of IoT Motes increases. On the
r
other hand, the XIA network portion delay grows linearly as
2) CPU Usage: FIoTE3 samples several values of CPU the number of IoT Motes increases. In conclusion, increasing
usage via the Linux command top during each run. After the the number of Motes/Gateways has fewer impacts on the UDP
application ends, FIoTE3 estimates a simple average based on network side than on the XIA average delay. Again, this results
these samples. The CPU Usage evaluates the processing load depends on the Gateway Service performance.
as the number of Gateways and IoT Clients varies. 3) Delay Analysis for Increasing Packet Size: As can be
3) Packet Loss: Packet loss occurs when a packet is re- seen in Fig. 3-c, the total average network delay increased
ceived with a time longer than its timeout, a packet times slightly due to the packet payload size. It was about 1s for the
out without reaching its destination, or when the application case when the packets have a payload of 64 bytes.
detects a corrupted packet. The Border Router is naturally
limited in terms of emulated hardware and the IPv6 tunnel,
i.e. tunslip. Note this is a natural behavior in IoT. Usually, the B. Pure IPv6/6LowPAN Network: Scenarios Comparison
Border Routers are capable of forwarding one packet for one In this Subsection, the total results previously obtained
network route. Thus, Border Routers drop an incoming packet for Scenario 1 (Fig. 1-a) are contrasted with a pure
when another is already being processed. In other words, there IPv6/6LowPAN scenario (Scenario 2), i.e. without XIA. In
is a probability of packet losses associated with more than one the pure UDP/IPv6/6LowPAN scenario, there is no Gateway
IoT Mote. It is crucial to note that this is a limitation of the Service for translating XIA XDP/XIP to UDP/IPv6, and vice-
hardware emulated in the Cooja tool, and overcoming this versa. Previous results are reproduced again in every graphic
limitation requires modifying the firmware of that node. to facilitate comparison with Scenario 1.
 11

UDP/IPv6/6LowPAN
XIA Access
Total

1250 1200 1200

1000 960 960

Delay (ms)

750 720 720

500 480 480

250 240 240

0 0 0
0 10 20 30 40 0 155 310 465 620 0 18 36 54 72
IoT Clients
IoT Motes Packet Size (bytes)

Figure 3. Hybrid XIA + IPv6 delay profile, where each set of points correspond to a given network domain. Please refer to Figure 1-a).

Pure IPv6
Hybrid XIA + IPv6

1250 1200 1200

1000 960 960

Total Delay (ms)

750 720 720

500 480 480

250 240 240

0 0 0
0 10 20 30 40 0 155 310 465 620 0 18 36 54 72
IoT Clients IoT Motes Packet Size (bytes)

Figure 4. Total delay comparison between Pure IPv6 and Hybrid XIA+IPv6 networks by varying a given parameter at a time.
Pure IPv6
Hybrid XIA + IPv6

70 70 70

56 56 56
CPU Usage (%)

42 42 42

28 28 28

14 14 14

0 0 0
0 10 20 30 40 0 155 310 465 620 0 18 36 54 72
IoT Clients IoT Motes Packet Size (bytes)

Figure 5. CPU Usage comparison between Pure IPv6 and Hybrid XIA+IPv6 by Pure
varying
IPv6 a given parameter at a time. This graph follows Figure 4 legend.
Hybrid XIA + IPv6

12 30 12

10
9 22.5
Packet Loss (%)

6 15 6

4
3 7.5
2

0 0 0
0 10 20 30 40 0 155 310 465 620 0 18 36 54 72
IoT Clients IoT Motes Packet Size (bytes)

Figure 6. Packet Loss comparison between Pure IPv6 and Hybrid XIA+IPv6 by varying a given parameter at a time. This graph follows Figure 4 legend.
 12

1) Delay Analysis: Fig. 4-a reproduces the results for suffers from an increased delay by dropping fewer packets,
Total Delay in the network when varying the number which relates to the packet queue in its Gateway Service. Fig.
of IoT Clients. The Total Delay was lower for pure 6-b shows the packet loss while increasing the number of IoT
UDP/IPv6/6LowPAN, with roughly 250 ms, when compared motes. At first, more motes means more servers to answer
to the hybrid XIA&IPv6, which varies from 770 ms up to requests in Cooja. As a consequence, the packet loss reduces.
1.2 s. The worst-case Total Delay happens with 35 clients. However, losses rise considerably when the number of motes
In Scenario 1, the packets wait until a previous return. Only exceeds 450 motes for the pure IPv6 scenario. The reason is
then, the next packet goes to its IoT Mote. This behavior is the same. There is no Gateway Service to buffer packets that
associated with the XIA-Prototype Xsocket implementation. compete for service on the Border Router and for a collision-
Therefore, this result has no relation to the Gateway Service free path to an IoT mote inside Cooja. This behavior is not
developed in this article. Certainly, the efficiency difference related to the lack of docker containers, network throughput, or
between the two architectures and their implementations also hardware resources. In this way, since the docker bridge uses
impacts. UDP/IPv6 have decades of improvement and run at the physical network card for packet exchanges, the aggregated
the Linux Kernel. XIA runs in user space employing virtual traffic is kept well below its capacity. In future research, we
routers, naturally presenting more limitations. Meanwhile, we intend to modify the Border Router and the traffic forwarding
discuss modifications in XIA architecture to improve perfor- solution with tunslip6 to avoid high packet losses in the case
mance for IoT in Section VII. of pure IPv6. We will also modify the FIoTE3 to enable a
Fig. 4-b reports results for Total Delay while varying the detailed throughput analysis, which is a feature that the current
number of IoT Motes (and serving Gateways). The number of prototype does not cover reliably. Finally, Fig. 6-c depicts
Clients is kept constant and equal to 25. In Scenario 2, we packet losses for different packet sizes. Both scenarios increase
can observe that the Total Delay reduces as the same amount packet losses for larger packets.
of requests (traffic load) is overspread to a massive Gateway
number and associated IoT Motes. This behavior did not occur VII. L ESSONS L EARNED , L IMITATIONS AND E XTENSIONS
in Scenario 1 due to the overhead of both: i) the Gateway In this section, we discuss how FIoTE3 can be extended to
Service required to translate XDP/XIP to/from UDP/IPv6; ii) solve some of its current limitations and support other FIA
the limitation in XIA-Prototype Xsocket implementation. architectures. We explore lessons learned regarding FIoTE3
Fig. 4-c reproduces obtained Total Delay when varying design, its scalability, and XIA architecture with IoT. Besides,
packet sizes. The effect of the Gateway Service is notable FIoTE3 improvements ranges from emulated IoT devices and
in XIA+IPv6 since larger packets require more resources to link layer protocols until multiple FIA support.
be tread. In contrast, Scenario 2 presents a more flat response.
2) Required CPU Usage: Figure 5-a depicts the effect of A. Experiment Scalability
increasing the number of Client applications in CPU usage.
For both scenarios, this growth has little impact. Most of the The largest scale test performed was with 600 emulated
CPU expenditure relates to the 50 Gateways and 500 Motes motes. It consumed around 65% CPU. There is still some
employed in all cases. However, the result is quite different margin to expand the number of emulated nodes. To scale ex-
when the number of IoT Motes rises. Figure 5-b shows that the periments to scenarios larger than this requires distribution of
IoT Motes and serving Gateways change has a linear impact processing to several physical machines. This can be done by
on CPU usage for both scenarios. The CPU power demand modifying the tool to connect the Docker networks on several
boosts with the number of gateways. In turn, so are the number machines. The scenario developed in Docker allows running
of Cooja instances and emulated motes. Finally, Figure 5-c FIoTE3 on public computing clouds, such as Amazon Web
demonstrates that packet size has little effect on CPU usage Services, with few modifications. However, cloud assessment
during experiments, through a flat curve. for larger scenarios is a target for future work. Therefore, the
3) Packet Loss Analysis: Fig. 6-a shows a comparison of elasticity of the solution’s computational resources to larger-
the percentage of packet loss as the number of IoT Clients scale scenarios remains to be assessed in future works.
varies, keeping 50 Gateways and 500 IoT motes active. For this
case, packet loss in XIA + IPv6 (Scenario 1) is much smaller B. XIA Overhead
than the presented results for pure IPv6 (Scenario 2). These xia-core [37] has proved to be very stable in all tests
losses occur in the Cooja Border Router when the same IoT performed. The name resolution system has been useful for
Mote is accessed simultaneously by more than one Client. This resolving device and service names up to other XIDs. How-
limitation is diminished in the hybrid XIA + IPv6 scenario ever, many researchers consider XIA packet headers too large
because its Gateway Service presents a buffer. Therefore, it to be used in IoT devices. In our first evaluation scenario, XIA
prevents network overload and, so, significant packet losses. In was employed only in the access network, i.e. between the IoT
other words, this service manages the packet flow by emitting data Client and the XIP/IPv6 Gateway. Therefore, IoT devices
new packets only when it receives the IoT Mote reply from a did not embed XIA. However, a possible solution for using
previously IoT Server request. In contrast, there is no Gateway XIA in IoT networks is to employ header compression [4], in
Service in the pure IPv6 scenario, leading to substantial packet a way similar to what happens in IPv6 with 6LowPAN.
loss in this case. In this way, the Gateway Router discards Another possibility is to create some lightweight IoT-
countless packets when it is busy. Nonetheless, Scenario 1 specific principal, like a mote ID (MID). This new principal
 13

Figure 7. Expanding FIoTE3 for NovaGenesis (NG): a) Scenario 3: The Proxy/Gateway/Controller Service (PGCS) runs inside all containers to encapsulate
NG packets directly over Docker Ethernet bridge. PGCS is also capable of routing messages to other containers. The Name Resolution and Network Cache
Service (NRNCS) implements a NG web with publish/subscribe communication model. The Gateway PGCS translates NG packets to/from UDP/IPv6. b)
Scenario 4: NG over IPv6/6LowPAN is employed to reach IoT Motes, in which an embedded proxy gateway service (EPGS) implements a lightweight NG
stack for IoT [2]. The Gateway service is not required, since PGCS can forward
. packets directly to Cooja’s border router via tunslip6

could replace other XIDs when forwarding inside the IoT C. IoT Devices and Link Layer
devices portion. Besides, these MIDs could apply the IEEE Some FIoTE3 components act as bottlenecks to the eval-
extended unique identifiers (EUI), with 48 or 64 bits. Addi- uated networks. Although the packet loss experimented due
tionally, the number of principals supported in the IoT domain to the low capacity of the Border Router emulates a natural
could be reduced, as well as the fallback feature could be situation that can happen in IoT, future evaluations may require
deactivated, giving rise to an XIA-Lite approach. Interestingly, other scenarios with minimal or no loss. Therefore, FIoTE3
our Gateway Service implementation already does a mapping should contemplate other options of Border Router. Alongside
among XIA and IPv6/6LowPAN addresses, a feature that could this, the current FIoTE3 implementation employs MSP430
extend its scope to support other XIA principals, like MID. emulated motes, which required great computational capacity
Moreover, we could explore reducing the XID field in the in physical machines to support. With this aim, FIoTE3 could
XIP header (160 bits) to smaller values only at the IoT portion. integrate other IoT Motes to provide lightweight deployments.
For example, the IoT XID could present 32, 48, or 64 bits Moreover, it is possible to emulate Motes at the software level
representing the original 160-bits XID field. This approach using Cooja type Motes, which involves few modifications in
has the advantage of preserving existing XIDs inside the IoT the Cooja project, freeing up enough computational capacity
scope, yet in a smaller size. In this case, the XIA-core name consumed by the Gateways. Nonetheless, FIoTE3 can further
service could be extended to support XIDs translations (from encompass Bluetooth Low Energy (BLE), IEEE 802.15.4, and
160 bits up to smaller sizes and vice-versa), similarly to a NAT LoRa protocols to provide a comparison with 6LowPAN.
function. Fallbacks could use reduced XIDs. Notwithstanding,
MIDs could employ either EUI-48 or EUI-64.
In [68], XIA transport over heterogeneous networks has D. Multiple Architectures: Extending for NovaGenesis
been evaluated. Wired and wireless network segments are The current FIoTE3 version supports hybrid XIA-IPv6 and
connected using transfer access points (TAPs). To achieve pure IPv6 scenarios. Future work can explore other FIAs.
end-to-end connectivity, an XIA transfer layer is applied over FIoTE3 can support other projects by implementing specific
segments. In [69], XIA segments have adopted Catnap to network connections for Docker and specialized Gateway
support mobile devices battery savings, a feature that could Services. That is, we acknowledge this clear path to broaden
be adapted to support IoT requirements. the tool and allow fair comparisons between architectures.
 14

Considering the NG architecture as an example, FIoTE3 services on the XIA access network. Another decisive FIoTE3
can easily encompass this IoT-friendly early project [2]. expansion relates to the possibility to embed other FIAs’
FIoTE3’s Gateway can deploy a PGCS instance to represent, instances in Cooja IoT motes. Therefore, this work fosters the
translate packet formats, or even control devices in an IoT experimentation and evaluation of IoT scenarios with current
domain. Besides, FIoTE3 can present a hybrid UDP/IPv6/NG and future technology, aiming at further integration with
and pure NG scenarios. In the first, the payload of NG smart environments, e.g. smart cities, houses, etc. Nonetheless,
publish/subscribe-based application messages can be accom- improvements are required to: (i) eliminate undesirable packet
modated as UDP segments over IPv6 by a Gateway Service losses in Cooja’s Border Router and tunslip6 forwarding;
(Fig. 7-a). On the latter, each IoT Mote executes a single (ii) reliably monitor throughput in all components; and (iii)
EPGS instance, which establishes a contract to its domain experiment with other scenarios, topologies and architectures.
PGCS at the Gateway PGCS node, allowing data exchange Different from other current Internet experimentation tools
between the NG IoTTestApp, the Gateway PGCS, and the and testsbeds [70]–[72], FIoTE3 offers resources to enable
EPGS-based mote inside Cooja. (Fig. 7-b). Regarding the IoT the creation of virtual environments with a flexible topology
communication protocol, the PGCS and EPGS convert their for the execution of IoT test scenarios, restrained only by the
NG messages into the desired link-layer technology, such as physical machines that deploy the environment. The obtained
Ethernet, IPv6, or 6LoWPAN. Comparing this approach with results demonstrate that FIoTE3 can be a feasible alternative
the XIA use case, NG PGCSes replaces XIA routers, which encompassing new FIAs.
are also software-based packet routers. Besides, NG requires
a Name Resolution and Network Cache Service (NRNCS) ACKNOWLEDGMENTS
to provide name resolution and temporary storage of IoT
messages in the NG access network. This work was partially supported by RNP, with resources
from MCTIC, Grant No. No 01245.010604/2020-14, under
Brazil 6G project of the Radiocommunication Reference Cen-
VIII. C ONCLUSIONS ter (Centro de Referência em Radiocomunicações - CRR)
This work presents a Future Internet of Things Experimen- of the National Institute of Telecommunications (Instituto
tation and Evaluation Environment (FIoTE3). The proposed Nacional de Telecomunicações, Inatel), Brazil; and in part
virtual networking architecture emulates and simulates an IoT by the Coordenação de Aperfeiçoamento de Pessoal de Nı́vel
access network with variable components, allowing anyone Superior (CAPES) - Finance Code 001. The authors also thank
to experiment with custom protocols. Our proposal takes CNPq and FAPEMIG.
advantage of open-source tools and Docker containers that
display mostly no extra cost, allowing anyone to reproduce R EFERENCES
the shown results by downloading the proposed tool from
[1] B. M. Leiner, V. G. Cerf, D. D. Clark, R. E. Kahn, L. Kleinrock, D. C.
GitHub. In our view, this environment can also become a rele- Lynch, J. Postel, L. G. Roberts, and S. Wolff, “A brief history of the
vant educational tool for computer networking-related classes, internet,” SIGCOMM Comput. Commun. Rev., vol. 39, no. 5, p. 2231,
helping people advance their research in a pandemic time Oct. 2009.
[2] A. M. Alberti, G. D. Scarpioni, V. J. Magalhães, A. C. S.
at an economical cost. Moreover, the proposed methodology Jr., J. J. P. C. Rodrigues, and R. da Rosa Righi, “Advancing
facilitates the evaluation and comparison of two use-cases with novagenesis architecture towards future internet of things,” IEEE
hybrid XIA/IPv6/6LowPAN and pure IPv6/6LowPAN stacks IoT Journal, vol. 6, no. 1, pp. 215–229, 2019. [Online]. Available:
https://doi.org/10.1109/JIOT.2017.2723953
for IoT. The tool is expansible to other use-cases. [3] A. M. Alberti, M. M. Bontempo, J. R. dos Santos, A. C. S.
The evaluation of new proposals for the Internet is a Jr., and R. da Rosa Righi, “Novagenesis applied to information-
common demand. Sooner or later, the current TCP/IP stack centric, service-defined, trustable iot/wsan control plane and spectrum
management,” Sensors, vol. 18, no. 9, p. 3160, 2018. [Online].
will need to be replaced, just as all other human technologies Available: https://doi.org/10.3390/s18093160
are. In some predictions, the Internet that we know so far [4] D. Han, A. Anand, F. Dogar, B. Li, H. Lim, M. Machado, A. Mukundan,
will be an infrastructure shared by several specialized distinct W. Wu, A. Akella, D. G. Andersen, J. W. Byers, S. Seshan, and
P. Steenkiste, “Xia: Efficient support for evolvable internetworking,”
architectures. For now, we can prepare ourselves for that NSDI’12, USENIX Association, pp. 23–23, 2012.
future. Environments and methodologies for evaluating alter- [5] K. Ashton, “That ’Internet of Things’ Thing,” RFID Journal, Jun. 2009.
natives to the current Internet need to be standardized, open- [6] M. R. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. A. Grieco,
G. Boggia, and M. Dohler, “Standardized protocol stack for the internet
source, competitive, and easy to be modified to encompass of (important) things,” IEEE Communications Surveys Tutorials, vol. 15,
new proposals. This work contributes to this aim, leveraging no. 3, pp. 1389–1406, 2013.
terms, concepts, and scenarios that may be known and set as [7] J. W. Hui and D. E. Culler, “Extending ip to low-power, wireless
personal area networks,” IEEE Int. Comp., vol. 12, no. 4, pp. 37–45,
a standard someday by the network and FIA community. July 2008.
This work might be the first effort for evaluating the [8] S. Challa, A. K. Das, P. Gope, N. Kumar, F. Wu, and A. V.
interoperability of XIA XDP/XIP and UDP/IPv6/6LowPAN Vasilakos, “Design and analysis of authenticated key agreement
scheme in cloud-assisted cyberphysical systems,” Future Generation
via an IoT gateway. This solution allows comparison among Computer Systems, vol. 108, pp. 1267–1286, 2020. [Online]. Available:
current and future approaches. The performance of the https://www.sciencedirect.com/science/article/pii/S0167739X17326328
XIA prototype with software routing was close to the pure [9] J. Srinivas, A. K. Das, M. Wazid, and A. V. Vasilakos, “Designing
secure user authentication protocol for big data collection in iot-based
UDP/IPv6/6LowPAN case. Besides, the Gateway Service intelligent transportation system,” IEEE Internet of Things Journal,
proved to be an effective solution to represent 6LoWPAN vol. 8, no. 9, pp. 7727–7744, 2021.
 15

[10] Q. Jing, A. V. Vasilakos, J. Wan, J. Lu, and D. Qiu, “Security [31] S. Deering and R. Hinden, “Internet protocol, version 6
of the internet of things: Perspectives and challenges,” Wirel. Netw., (ipv6) specification,” Internet Requests for Comments, The
vol. 20, no. 8, p. 24812501, Nov. 2014. [Online]. Available: Internet Society, RFC 2460, December 1998. [Online]. Available:
https://doi.org/10.1007/s11276-014-0761-7 https://tools.ietf.org/html/rfc2460
[11] Z. Yan, P. Zhang, and A. V. Vasilakos, “A survey on trust [32] F. Osterlind, A. Dunkels, J. Eriksson, N. Finne, and T. Voigt, “Cross-
management for internet of things,” Journal of Network and Computer level sensor network simulation with cooja,” in 31st IEEE Conference
Applications, vol. 42, pp. 120–134, 2014. [Online]. Available: on Local Computer Networks, Nov 2006, pp. 641–648.
https://www.sciencedirect.com/science/article/pii/S1084804514000575 [33] Contiki. (2017, Mar.) Contiki website. [Online]. Available:
[12] C. Lin, D. He, X. Huang, K.-K. R. Choo, and A. V. Vasilakos, “Bsein: http://www.contiki-os.org/
A blockchain-based secure mutual authentication with fine-grained [34] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki - a lightweight and
access control system for industry 4.0,” Journal of Network and flexible operating system for tiny networked sensors,” in 29th Annual
Computer Applications, vol. 116, pp. 42–52, 2018. [Online]. Available: IEEE Intl. Conf. on Local Computer Networks, Nov 2004, pp. 455–462.
https://www.sciencedirect.com/science/article/pii/S1084804518301619 [35] C. Boettiger, “An introduction to docker for reproducible research,”
[13] C. Bormann, A. P. Castellani, and Z. Shelby, “Coap: An application SIGOPS Oper. Syst. Rev., vol. 49, no. 1, pp. 71–79, Jan. 2015. [Online].
protocol for billions of tiny internet nodes,” IEEE Internet Computing, Available: http://doi.acm.org/10.1145/2723872.2723882
vol. 16, no. 2, pp. 62–67, 2012. [36] J. Turnbull, The Docker Book: Containerization is the new virtualization.
[14] Z. Sheng, S. Yang, Y. Yu, A. V. Vasilakos, J. A. Mccann, and K. K. James Turnbull, 2014.
Leung, “A survey on the ietf protocol suite for the internet of things: [37] XIA-Project. Xia-project website. [Online]. Available:
standards, challenges, and opportunities,” IEEE Wireless Communica- https://github.com/XIA-Project/xia-core/wiki
tions, vol. 20, no. 6, pp. 91–98, 2013. [38] W. Ding, Z. Yan, and R. H. Deng, “A survey on future internet security
[15] A. M. Alberti, “A conceptual-driven survey on future internet require- architectures,” IEEE Access, vol. 4, pp. 4374–4393, 2016.
ments, technologies, and challenges,” Journal of the Brazilian Computer [39] M. Ambrosin, A. Compagno, M. Conti, C. Ghali, and G. Tsudik,
Society, vol. 19, no. 3, pp. 291–311, 2013. “Security and privacy analysis of national science foundation future
[16] F. M. Abduljalil and S. K. Bodhe, “A survey of integrating ip mobility internet architectures,” IEEE Communications Surveys Tutorials, vol. 20,
protocols and mobile ad hoc networks,” IEEE Communications Surveys no. 2, pp. 1418–1442, 2018.
Tutorials, vol. 9, no. 1, pp. 14–30, 2007. [40] J. Day, Patterns in Network Architecture: A Return to Fundamentals.
[17] S. Jangirala, A. K. Das, and A. V. Vasilakos, “Designing secure [41] S. Vrijders, D. Staessens, D. Colle, F. Salvestrini, E. Grasa, M. Tarzan,
lightweight blockchain-enabled rfid-based authentication protocol for and L. Bergesio, “Prototyping the recursive internet architecture: the
supply chains in 5g mobile edge computing environment,” IEEE Trans- irati project approach,” IEEE Network, vol. 28, no. 2, pp. 20–25, 2014.
actions on Industrial Informatics, vol. 16, no. 11, pp. 7081–7093, 2020. [42] A. M. Alberti, M. A. F. Casaroli, D. Singh, and
[18] Q. Wu, Z. Li, J. Zhou, H. Jiang, Z. Hu, Y. Liu, and G. Xie, “Sofia: R. da Rosa Righi, “Naming and name resolution in the future
toward service-oriented information centric networking,” IEEE Network, internet: Introducing the novagenesis approach,” Future Gener.
vol. 28, no. 3, pp. 12–18, 2014. Comput. Syst., vol. 67, pp. 163–179, 2017. [Online]. Available:
[19] C. Partridge, “Helping a future internet architecture mature,” SIGCOMM https://doi.org/10.1016/j.future.2016.07.015
Comput. Commun. Rev., vol. 44, no. 1, pp. 50–52, Dec. 2013. [43] W. Shang, A. Afanasyev, and L. Zhang, “The design and implemen-
[20] J. Pan, S. Paul, and R. Jain, “A survey of the research on future internet tation of the ndn protocol stack for riot-os,” in 2016 IEEE Globecom
architectures,” Comm. Magazine, IEEE, vol. 49, no. 7, pp. 26 –36, 2011. Workshops (GC Wkshps), 2016, pp. 1–6.
[21] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy, P. Crowley, [44] M. Chowdhury, A. Gawande, and L. Wang, “Secure information sharing
C. Papadopoulos, L. Wang, and B. Zhang, “Named data networking,” among autonomous vehicles in ndn,” in 2017 IEEE/ACM 2nd Intl. Conf.
SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, p. 6673, Jul. 2014. on IoT Design and Implementation (IoTDI), 2017, pp. 15–26.
[Online]. Available: https://doi.org/10.1145/2656877.2656887 [45] J. Luo, C. Wu, Y. Jiang, and J. Tong, “Name label switching paradigm
[22] T. Qiu, N. Chen, K. Li, M. Atiquzzaman, and W. Zhao, “How can for named data networking,” IEEE Communications Letters, vol. 19,
heterogeneous internet of things build our future: A survey,” IEEE no. 3, pp. 335–338, 2015.
Communications Surveys & Tutorials, vol. 20, no. 3, pp. 2011–2027, [46] I. Seskar, K. Nagaraja, S. Nelson, and D. Raychaudhuri, “MobilityFirst
2018. Future Internet Architecture Project,” in 2011 Asian Internet Engineering
[23] M. Wazid, A. K. Das, V. Bhat K, and A. V. Vasilakos, Conference (AINTEC), Bangkok, Thailand, 2011, pp. 1–3. [Online].
“LAM-CIoT: Lightweight authentication mechanism in cloud- Available: https://doi.org/10.1145/2089016.2089017
based IoT environment,” Journal of Network and Computer [47] D. Raychaudhuri, K. Nagaraja, and A. Venkataramani, “MobilityFirst:
Applications, vol. 150, p. 102496, 2020. [Online]. Available: a robust and trustworthy mobility-centric architecture for the future
https://www.sciencedirect.com/science/article/pii/S108480451930356X internet,” ACM SIGMOBILE Mobile Computing and Communications
[24] B. Bera, S. Saha, A. K. Das, and A. V. Vasilakos, “Designing blockchain- Review, vol. 16, pp. 2–13, 12 2012.
based access control protocol in iot-enabled smart-grid system,” IEEE [48] A. Baid and D. Raychaudhuri, “Wireless access considerations for the
Internet of Things Journal, vol. 8, no. 7, pp. 5744–5761, 2021. mobilityfirst future internet architecture,” in 2012 35th IEEE Sarnoff
[25] R. P. S. Chaib and A. M. Alberti, “A simple solution for iot Symposium, 2012, pp. 1–5.
experimentation in the context of future internet architectures,” in [49] E. Bertino, K.-K. R. Choo, D. Georgakopolous, and S. Nepal, “Internet
Anais do VIII Workshop de Pesquisa Experimental da Internet do of things (iot): Smart and secure service delivery,” ACM Trans. Internet
Futuro. Porto Alegre, RS, Brasil: SBC, 2017. [Online]. Available: Technol., vol. 16, no. 4, pp. 22:1–22:7, Dec. 2016. [Online]. Available:
https://sol.sbc.org.br/index.php/wpeif/article/view/2607 http://doi.acm.org/10.1145/3013520
[26] J. A. T. Gavazza, J. C. Melo, T. B. da Silva, A. M. Alberti, P. F. [50] M. Rizinski, J. Day, and L. Chitkushev, “Iot architecture based on rina,”
Rosa, F. de Oliveira Silva, F. L. Verdi, and J. A. Suruagy, “Future in 2020 23rd Conference on Innovation in Clouds, Internet and Networks
internet exchange point (fixp): Enabling future internet architectures and Workshops (ICIN), 2020, pp. 41–45.
interconnection,” in Advanced Information Networking and Applications, [51] T. Ramezanifarkhani and P. Teymoori, “Securing the internet of things
L. Barolli, F. Amato, F. Moscato, T. Enokido, and M. Takizawa, Eds. with recursive internetwork architecture (rina),” in 2018 Intl. Conference
Cham: Springer International Publishing, 2020, pp. 703–714. on Computing, Networking and Commun. (ICNC), 2018, pp. 188–194.
[27] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and [52] V. Maffione, F. Salvestrini, E. Grasa, L. Bergesio, and M. Tarzan, “A
M. Ayyash, “Internet of things: A survey on enabling technologies, software development kit to exploit rina programmability,” in 2016 IEEE
protocols, and applications,” IEEE Communications Surveys Tutorials, International Conference on Communications (ICC), 2016, pp. 1–7.
vol. 17, no. 4, pp. 2347–2376, 2015. [53] J. Perello, A. Lopez, and D. Careglio, “Experimenting with real
[28] F. Cirillo, D. Gmez, L. Diez, I. Elicegui Maestro, T. B. J. Gilbert, application-specific qos guarantees in a large-scale rina demonstrator,” in
and R. Akhavan, “Smart city iot services creation through large-scale 2019 22nd Conference on Innovation in Clouds, Internet and Networks
collaboration,” IEEE Internet of Things Journal, vol. 7, no. 6, pp. 5267– and Workshops (ICIN), 2019, pp. 31–36.
5275, 2020. [54] A. M. Alberti, D. Mazzer, M. Bontempo, L. H. [de Oliveira],
[29] T. B. d. Silva, E. S. d. Morais, L. F. F. d. Almeida, R. d. Rosa Righi, R. [da Rosa Righi], and A. C. Sodr], “Cognitive radio
and A. M. Alberti, Blockchain and Industry 4.0: Overview, Convergence, in the context of internet of things using a novel future
and Analysis. Singapore: Springer Singapore, 2020, pp. 27–58. internet architecture called novagenesis,” Computers & Electrical
[30] “IEEE 802.15.4-2020 - IEEE Standard for Low-Rate Wireless Net- Engineering, vol. 57, pp. 147 – 161, 2017. [Online]. Available:
works,” IEEE Standards Association (IEEE SA), Standard, May 2020. http://www.sciencedirect.com/science/article/pii/S004579061630180X
 16

[55] A. Bannis and J. Burke, “Creating a secure, integrated home network of Thiago Bueno da Silva is a Master candidate at
things with named data networking,” Rep. NDN-35, pp. 335–338, 2015. INATEL, Brazil. He received a Control and Au-
[56] Z. Zhang, E. Lu, Y. Li, L. Zhang, T. Yu, D. Pesavento, J. Shi, and tomation Engineering B.Sc. Degree from INATEL,
L. Benmohamed, “Ndnot: A framework for named data network of Technology Management Certificate from UCSB,
things,” in 5th ACM Conference on ICN, ser. ICN 18. New York, U.S.A, and Electronics Technician Degree from ETE
NY, USA: Association for Computing Machinery, 2018, p. 200201. FMC, Brazil. Besides, he has worked with R&D,
[Online]. Available: https://doi.org/10.1145/3267955.3269019 Supply Chain, Logistics, and Industrial Networks.
[57] D. Saxena, V. Raychoudhury, and N. SriMahathi, “Smarthealth-ndnot: Nowadays, he has been researching and publishing
Named data network of things for healthcare services,” in Proceedings of papers related with Future Internet, Software De-
the 2015 Workshop on Pervasive Wireless Healthcare, ser. MobileHealth fined Networks, Industry 4.0, and Smart Cities.
15. New York, NY, USA: Association for Computing Machinery, 2015,
p. 4550. [Online]. Available: https://doi.org/10.1145/2757290.2757300
[58] E. Baccelli, C. Mehlis, O. Hahm, T. Schmidt, and M. Whlisch, “Infor- Ramon P. dos Santos Chaib is an software devel-
mation centric networking in the iot: Experiments with ndn in the wild,” oper at Nouvenn LLC. since 2017. In 2014, Ramon
in ICN 2014 - Proceedings of the 1st Intl. Conf. on Information-Centric was a researcher at ICT Laboratory of INATEL. He
Networking, 2014. received his B. Sc. Degree in Computer Engineering
[59] S. Li, Y. Zhang, D. Raychaudhuri, and R. Ravindran, “A comparative from the INATEL in 2011 and M. Sc. Degree also
study of mobilityfirst and ndn based icn-iot architectures,” in 10th from INATEL in 2017. In 2010 he has developed
International Conference on Heterogeneous Networking for Quality, a Battery Monitoring System (BMS) that nowadays
Reliability, Security and Robustness, 2014, pp. 158–163. runs on the Brazilian navy submarines. He currently
[60] S. Li, Y. Zhang, D. Raychaudhuri, R. Ravindran, Q. Zheng, L. Dong, works developing security solutions for network
and G. Wang, “Iot middleware architecture over information-centric communications.
network,” in 2015 IEEE Globecom Workshops (GC Wkshps), 2015, pp.
1–7.
[61] S. Li, J. Chen, H. Yu, Y. Zhang, D. Raychaudhuri, R. Ravindran, H. Gao,
L. Dong, G. Wang, and H. Liu, “Mf-iot: A mobilityfirst-based internet Arismar Cerqueira S. Jr. received his Ph. D.
of things architecture with global reach-ability and communication degree from Scuola Superiore SantAnna-Italy in
diversity,” in 2016 IEEE First International Conference on Internet-of- 2006 and has been Invited Professor from many
Things Design and Implementation (IoTDI), 2016, pp. 129–140. world-recognized universities, such as Max-Planck
[62] J. Wang, C. Xu, X. Wang, W. Li, Z. Li, S. Jiang, and P. Steenkiste, Institute-Germany, Danish Technical University-
“Softstage: Content staging for vehicular content delivery in the expres- Denmark, Univeristy of Oulu-Finland and Scuola
sive internet architecture,” in 2019 IEEE 39th International Conference Superiore SantAnna-Italy. He has been Associate
on Distributed Computing Systems (ICDCS), 2019, pp. 891–900. Professor from INATEL since 2011 and is a holder
[63] J. Chen, S. Li, H. Yu, Y. Zhang, D. Raychaudhuri, R. Ravindran, of 10 patents, has transferred 25 products to the
H. Gao, L. Dong, G. Wang, and H. Liu, “Exploiting icn for realizing industry and has published 250 scientific papers.
service-oriented communication in iot,” IEEE Communications Maga-
zine, vol. 54, no. 12, pp. 24–30, 2016.
[64] E. Grasa, M. Tarzan, L. Bergesio, B. Gastn, V. Maffione, Rodrigo da Rosa Righi is assistant professor and
F. Salvestrini, S. Vrijders, and D. Staessens, “Irati: researcher at University of Vale do Rio dos Sinos,
Open source rina implementation for linux,” Software Brazil. Rodrigo concluded his post-doctoral studies
Impacts, vol. 1, p. 100003, 2019. [Online]. Available: at KAIST - Korea Advanced Institute of Science
http://www.sciencedirect.com/science/article/pii/S266596381930003X and Technology, under the following topics: RFID
[65] K. Roussel, Y.-Q. Song, and O. Zendra, “Using cooja for wsn and cloud computing. He obtained his PhD degree
simulations: Some new uses and limits,” in Proceedings of the 2016 in Computer Science from the UFRGS University,
International Conference on Embedded Wireless Systems and Networks, Brazil, in 2005. His research interests include load
ser. EWSN ’16. USA: Junction Publishing, 2016, pp. 319–324. balancing and process migration. Finally, he is a
[Online]. Available: http://dl.acm.org/citation.cfm?id=2893711.2893790 member of the IEEE and ACM.
[66] A. e. a. Anand, “Xia: An architecture for an evolvable and trustworthy
internet,” in 10th ACM Workshop on Hot Topics in Networks, ser.
HotNets-X. New York, NY, USA: ACM, 2011, pp. 2:1–2:6. [Online]. Antonio Marcos Alberti is an associate professor
Available: http://doi.acm.org/10.1145/2070562.2070564 at the Instituto Nacional de Telecomunicações (INA-
[67] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. TEL), Brazil, since 2004. In 2012, Antonio was
Kaashoek, “The click modular router,” ACM Trans. Comput. Syst., a visiting researcher at ETRI, in South Korea. He
vol. 18, no. 3, p. 263297, Aug. 2000. [Online]. Available: received the M.Sc. and Ph.D. degrees in Electrical
https://doi.org/10.1145/354871.354874 Engineering from Unicamp, Campinas, SP, Brazil,
[68] “The eXpressive Internet Architecture: Architecture and Research in 1998 and 2003, respectively. Since 2008, he is
Overview,” Carnegie Mellow University, Overview, 2016. designing and implementing a future Internet archi-
[69] F. R. Dogar, P. Steenkiste, and K. Papagiannaki, “Catnap: Exploiting tecture called NovaGenesis. Since 2013 he has been
high bandwidth wireless interfaces to save energy for mobile acting as a Coordinator of ICT Lab. at INATEL.
devices,” in 8th Intl. Conf. on Mobile Systems, Applications, and
Services, ser. MobiSys ’10. New York, NY, USA: Association
for Computing Machinery, 2010, p. 107122. [Online]. Available:
https://doi.org/10.1145/1814433.1814446
[70] A. Stajkic, M. D. Abrignani, C. Buratti, A. Bettinelli, D. Vigo, and
R. Verdone, “From a real deployment to a downscaled testbed: A
methodological approach,” IEEE Internet of Things Journal, vol. 3,
no. 5, pp. 647–657, 2016.
[71] M. Chernyshev, Z. Baig, O. Bello, and S. Zeadally, “Internet of things
(iot): Research, simulators, and testbeds,” IEEE Internet of Things
Journal, vol. 5, no. 3, pp. 1637–1647, 2018.
[72] B. R. Al-Kaseem, Y. Al-Dunainawi, and H. S. Al-Raweshidy, “End-to-
end delay enhancement in 6lowpan testbed using programmable network
concepts,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 3070–3086,
2019.

View publication stats