1.
1
An Overview of The IoT Lab @COPELABS
Exploring and Evaluating Communication Paradigms in IoT
Rute C. Sofia (rute.sofia@ulusofona.pt)
2019.01.09
DEISI, University Lusófona – MEISI Seminars, room S.0.10

2.
Agenda
• The IoT Lab – Motivation and Overview
•Internet end-to-end perspective
• Communication with Things and People
•IoT environments
• Main environments
• Features and Requirements
• TCP/IP Stack evolution
• IoT Architectural Design, main Requirements
•IoT Communication Aspects
• Main protocols
• Interoperability Aspects
• Information-centric networking for IoT
•The IoT Lab @COPELABS
• Testbed phases
• Software
• Status
• Where we Want to Go
• Different team elements and roles
2

3.
The IoT Lab
Motivation and Overview
3

4.
Internet End-to-End and IoT
Where are Things ?
Network Access Provider: NAP
Sells network access to the user (line, Internet services)
Sells service transportation – service providers
Used to sell services also – currently partners with service providers
Sells personalized services (e.g. SocialTV)
Service providers
Internet Service Providers
Application Service Providers
WISP – Wireless Internet Service
Providers
 OTT – Over-the-Top Providers
4

5.
Internet End-to-End and IoT
Communication between Things ?
Services
•From an end-to-end perspective:
• Things are close to people
(Customer Premises)
• The “cloud” integrates Layer 2 and
Layer 3 devices
• Services reside on an IP backbone
Internet
5

6.
Internet End-to-End and IoT
Communication between Things
6

7.
IoT Environments
Industrial vs. Consumer
7

8.
IoT Environments
Examples, Consumer/Personal; Industrial
8

9.
IoT Architectural Design Requirements
IIoT
9

10.
IoT Architectural Design Requirements
Main Requirements,CIoT
11

11.
IoT Architectural Design, Evolution
TCP/IP Stack Evolution
11
•PHY: more heterogeneity,
longer distances, point-to-
point
• Network: IPv6,
interconnection,
interoperability
• Transport: move from TCP to
UDP
• Application: messaging
protocols instead of HTTP

12.
IoT Communication Aspects
CoAP, Web of Things
12
•CoAP: Constrained Application Protocol (IETF RFC 7252)
• Provides suppport for IoT, complementary to HTTP
•Request-response
•Designed for M2M applications (e.g., Monitoring)
*Ishaq, Isam, David Carels, Girum K. Teklemariam, Jeroen Hoebeke, Floris Van den Abeele, Eli De Poorter, Ingrid Moerman,
and Piet Demeester. "IETF standardization in the field of the internet of things (IoT): a survey." Journal of Sensor and
Actuator Networks 2, no. 2 (2013): 235-287.
http://coap.technology/
V. Loga, Internet of Things Protocols, 6LowPan and CoAP. Aalto University, presentation. 2015
*

13.
IoT Communication Aspects
Messaging In IoT
13
• Event or time-driven
•Fragment
•Producer and consumer can run independently
• Publish information to all interested in it
• Modular
• Can scale well (Deployment and support for parallel)
P
Apps produce
messages
Exchange filter and route messages
Queues store and forward messages
Apps consume
messages
Broker (Server)Clients
Clients

14.
IoT Communication Aspects
Messaging In IoT – AMQP as Example
14
• AMQP: advanced Queueing messaging protocol
• Async, open, ubiquitous, adaptable
• On commodity hardware, supports 10-25 thousand messages per second
• JP Morgan sends 1 billion AMQP messages per day
• Security
• 3 levels of permissions
• Can be used on top pf SSL
• Broker gives abstraction
(and a single point of failure)
* RabbitMQ

15.
IoT Communication Aspects
Messaging In IoT - AMQP
15
Producer
C3
Key “green.orange”
X
M1, M2
Queue green.*
(Topic Exchange)
•Sends information to
queues based on
“topics”.
•Flexible
•Multiple categories at
once (less messages
sent)
M1
Queue *. orange
C2

16.
IoT Communication Aspects
Messaging In IoT - MQTT
16
Producer
Publish “21C” on Topic “Rooms/ temperature”
C2
• MQTT: Message Queue Telemetry Protocol
• True publish/subscribe – no queues
• Low overhead
• Common namespace – little security!
Subscribe Rooms/temperature
Subscribe
Outdoor/temperature
21 C
Brokers

17.
IoT Communication Aspects
Other Approaches: DDS
17
•DDS: Data Distribution
Service
• No broker, de-centralized
communication
Medagliani, Paolo & Leguay, Jeremie & Duda, A & Rousseau, Franck & Duquennoy, Simon & Raza, Shahid & Ferrari, Gianluigi &
Gonizzi, Pietro & Cirani, Simone & Veltri, L & Montón, Màrius & Domingo Prieto, Marc & Dohler, M & Villajosana, I & Dupont, O.
(2014). Internet of Things Applications - From Research and Innovation to Market Deployment.
https://www.researchgate.net/publication/278798179_Internet_of_Things_Applications_-
_From_Research_and_Innovation_to_Market_Deployment

18.
IoT Communication Aspects
Other Approaches: OPC-UA, Industrie 4.0
18
•OPC-UA: Open Platform
Communications Unified
Architecture
• 1990 – OPC (automation)
• Service-oriented approach
• Supports Client/server and
publish/subscriber
communication
• de facto standard for
automation and M2M in
Industrie 4.0
• Main advantage: interoperability
• Main drawback: clients outside
plants require ports open
• Solution: rely on
publish/subscribe brokers
approach (e.g., MQTT)
*A. Newman, L. Wiesniwiesky, O. Givehchi, J. Jasperneite. Utilizing OPC UA as comprehensive communication technology
for Cyber Physical Production Systems. 9th International Workshop on Service-Oriented Cyber-Physical Systems in Converging
Networked Environments (SOCNE). 2015.
*

19.
IoT Communication Aspects
OPC-UA, Publish/subscriber Approaches
19
*https://readthedocs.web.cern.ch/display/ICKB/OPC-UA+Summary
•Cloud: N to M support;
interoperability with e.g.,
AMQP
• Locally: 1 to N support,
follows UDP directives for
Time Sensitive Networks

20.
IoT Communication Aspects
Where Are We?
20

21.
IoT Communication Aspects
Where are We?
21
• No single architecture BUT
• Communications are moving towards publish/subscriber abstractions
• IIoT and CIoT bring in different requirements
• New scenarios: connected cars, family safety – personal IoT
Service-oriented approaches require a look into
information-centric publish/subscriber models
Focus on Data, not Things

22.
22
Information-Centric Networking
How Data Dissemination Works
•Change of network abstraction
from “named host” to “named
content”
•Security built-in: secures content
and not the hosts
•Mobility is present by design
Fundamentals:
Replace Packets with Data
Objects and Interests
Replace Addresses with Object
Names

23.
Brief Introduction to ICN
CCN to Named Data Networking
CCN
(PARC & Friends)
2009
Named-Data
Networking
Open, coordinated
by UCLA (2014)
hICN
Cisco, 2017
Part of the NSF Future Internet Architecture FIA
initiative
Goal: design the next generation Internet
Architecture
NDN is one of four multi-institution teams
funded in 2010-13, and 2014-16, ~$15M
http://named-data.net
http://github.com/named-data
23

24.
The main idea: Name the data, not the hosts!
..so you just tell the network what you want..
..and let the network find it for you
Christos Papadopoulos
Colorado State University
24
Brief Introduction to ICN
Main Idea

25.
Brief Introduction to ICN
NDN Packets
25
 There are two (main) packet types:
 Interest (a question, request for content) –
Similar to HTTP “GET”
 Data (an answer, serves content) – similar to
HTTP “RESPONSE”
 Both are encoded in an efficient binary XML
 No fixed length
Communication
 Consumer ‘broadcasts’ an interest over any available communications media:
 want ‘/parc.com/van/presentation.pdf’
 Interest identifies a collection of data
 All data items whose name has the interest as a prefix.
 Anything that hears the interest and has an element of the collection can respond with it:
 Here is ‘/parc.com/van/presentation.pdf/p1’ <data>
 Data that matches an interest ‘consumes’ it.

26.
26
Interest
Interest Interest
Content
ContentContent
Content
Interest
Brief Introduction to ICN
Named-Based Routing
26

27.
• No “source address” in content interests
– Not needed for routing
• Traffic monitoring less effective for non-global
adversaries
Interest
Interest Interest
Content
ContentContent
Content
Interest
Does not see the
interest
Does not see the
interest
Brief Introduction to ICN
Data, Channel, User Privacy
27

28.
Brief Introduction to ICN
NDN Node Architecture
28
Three Data Structures
 Forwarding Information Base (FIB)
 Used to forward Interest packets towards potential
sources of matching data.
 Identical to an IP FIB except the list of output faces
(can have multiple sources)
 Content Store (CS)
 Same as the buffer memory of an IP router, yet
different replacement policy
 Maximize data sharing (in IP , point-to-point
conversations)
 Pending Interest Table (PIT)
 Keeps track of Interest packets that were sent
upstream towards sources.
 Each CCN entity has 3 main data structures
 Content Store, Pending Interest Table, Forwarding
Information Base
 Uses multicast/broadcast
 Uses “longest prefix matching” lookup for content
names
Content Store
Pending Interest
Table (PIT)
Forwarding Information
Base (FIB)
CCN Forwarding Engine
Face 1
Wireless
Wired
Application
Face 2
Face 3
CCN Forwarding
Logic

29.
IoT and NDN Interworking
NDN vs. Publish-Subscribe Broker Model
NDN MQTT
Model Publish-Subscribe Publish-subscribe Broker Model
Stack NDN or IP Requires IP
Naming Expressive Host based
Security Integrated authentication; optional
encryption-based control
-
Forwarding Name based, multiple strategies,
inherent multihoming (1 Face
multiple interfaces)
Host based
Caching In-network -
Reporting Frequency Interest based Individual sensor based
Communication Model Pull (can be extended to push) Push
Mobility Supported (in-cache networking) No support (handled by TCP/IP)

30.
IoT and NDN Interworking
Stack and Packet Format*
30
*https://named-data.net/wp-content/uploads/2015/11/ndn-0035-1-creating_secure_integrated.pdf

31.
IoT and NDN Interworking
Why?
31
•Bring IoT Semantics to the network
layers
• Name Things and operations on Things
• “Living room frontal view feed”, “CO
level in kitchen”
• “Living room frontal view feed”, “CO
level in kitchen”
• “max/min/avg pH of soil in specific
point of US soil grid”
• Focus on DATA associated with Things
• Secure data directly
• Latest updates, ACM ICN 2017 tutorial
• http://conferences.sigcomm.org/ac
m-icn/2017/files/tutorial-ndn-
ccnlite-riot/1-ICN-intro.pdf

32.
IoT and NDN Interworking
Implementation: NDN RIOT*
32
*http://conferences.sigcomm.org/acm-icn/2017/files/tutorial-ndn-ccnlite-riot/5-NDN-RIOT.pdf
NDN RIOT is a project support by HAW Hamburg; INRIA, Florida International University; Zühlke GmbH

33.
IoT and NDN Interworking
Example, 1-Hop
33

34.
IoT and NDN Interworking
Performance Aspects
34
http://conferences.sigcomm.org/acm-icn/2017/files/tutorial-ndn-ccnlite-riot/5-NDN-RIOT.pdf

35.
IoT and NDN Interworking
Performance Aspects
35

36.
IoT Lab
Testbed
36
IoT Gateway
IoT Broker
Internet
iotclient6
iotgw1 – 12.0.0.170
COPELABS
iotgw2 – 12.0.0.171
iotclient4 – 12.0.0.141
Iotclient 2 – 12.0.0.139
Iotclient3 – 12.0.0.140
Iotclient5 – 12.0.0.142
…
NDN Worldwide testbed
COPELABS NDN router
CoAP, MQTT, OPC-UA, …
NDN with and without IP
CoAP, MQTT, OPC-UA …
NDN with and without IP
CoAP, AMQP
Note: IPv4 and IPv6 accessible
Gateways will be accessible from the internet

37.
IoT Lab
Testbed – Which Software?
37
Operating Systems
•Clients: Ubuntu, Raspbian, RioT,
Android
•Gateway/brokers: Raspbian and RiOT;
Ubuntu
Communication protocols:
• Same WLAN or via the Cloud
• IP-based: CoAP, AMQP, MQTT,
OPC-UA, etc.
• Information-centric: Named Data
Networking
Broker software: RabbitMQ
• Open Source message broker
• Supports HTTP and several IP-
based messaging protocols
(AMQP, MQTT, STOMP)
IoT Gateway
•ThingsBoard (supports broker)
•OpenIoT

38.
IoT Lab
Phase I Testbed – Which KPIs?
38
Power consumption on consumer, producers and broker/gateway
RTT – Round Trip Time
• End-to-end
• From gateway/broker to consumers
• From producers to gateway/broker
Number of bytes vs packets (for specific connections or msg syze)
• Overhead vs message size
• Message rate: number of msgs that can be sent over a period of time (ex:
seconds)
Packet Loss: assurance of message arrivel (percentage of sucess – sucess rate)

39.
IoT Lab
Where we Want to Go (2019)
39
-Facilitate performance evaluation of
communication aspects in IoT
- Interconnected with other testbeds, e.g.,
Named Data Networking; FIT-IoT
- Develop an IoT experimental Lab for students to
develop their research work
- First, second, third cycles
- Contribute to interoperability aspects, by
supporting better mediation and translation
between different protocols
- Better understanding of Pros and Cons of NDN
vs IP-based Communications
• Integrated security;
• In-network caching; I
• Decentralization;
• Flexible forwarding strategies;
• Interface abstraction, which assists sharing
of IoT data between devices as well as
between applications and services.
Contribute to performance analysis
•Different protocols, which advantages and
disadvantages

40.
IoT Lab
The Role of the Different Team Elements
40

41.
41