4/11/2019

Unit-II
INTERNET OF THINGS
By

Dr. Ch. Samson

Professor &Head, Dept of IT

IOT_UNIT-II_MVSR 1

1
 4/11/2019

IoT Architecture -
State of the Art

The ITU-T IoT domain model includes a set of physical
devices that connect directly or through gateway devices
to a communication network that allows them to exchange
information with other devices, services, and applications.
The physical world of things is reflected by an information
world of virtual things that are digital representations of
the physical things (not necessarily a one-to-one mapping
because multiple virtual things can represent one physical
thing).
The devices in this model include mandatory
communication capabilities and optional sensing,
actuation, and processing capabilities in order to capture
and transport information about the things
IOT_UNIT-II_MVSR 2

2
 4/11/2019

IoT Architecture -
State of the Art

IOT_UNIT-II_MVSR 3

3
 4/11/2019

IoT Architecture -
State of the Art

The ITU-T IoT model considers the Application Layer as
the host of specific IoT applications (e.g. remote patient
monitoring).
The Service & Application Support Layer otherwise known
as Service Support and Application Support Layer)
consists of generic service capabilities used by all IoT
applications, such as data processing and data storage,
and specific service capabilities tailored to specific
application domains, such as e-health or telematics.
The Network Layer provides networking capabilities such
as Mobility Management, Authentication, Authorization,
and Accounting (AAA), and Transport Capabilities such as
connectivity for IoT service data.
IOT_UNIT-II_MVSR 4

4
 4/11/2019

IoT Architecture -
State of the Art

The Device Layer includes Device Capabilities and
Gateway Capabilities. The Device Capabilities include,
among others, the direct device interaction with the
communication network and therefore the Network Layer
Capabilities, the indirect interaction with the Network Layer
Capabilities through Gateway Devices, any ad hoc
networking capabilities, as well as low-power operation
capabilities (e.g. capability to sleep and wakeup) that affect
communications
The Gateway Device Capabilities include multiple protocol
support and protocol conversion in order to bridge the
Network Layer capabilities and the device communication
capabilities.
IOT_UNIT-II_MVSR

5
 4/11/2019

IoT Architecture -
State of the Art

In terms of Management Capabilities, these include the
typical FCAPS (Fault, Configuration, Accounting,
Performance, Security) model of capabilities as well as
device management (e.g. device provisioning, software
updates, activation/deactivation), network topology
management (e.g. for local and short range networks),
and traffic management.
Specific management functionality related to a specific
application domain is also included among the
Management Capabilities.
With respect to the Security Capabilities, this layer
represents a grouping of different Security Capabilities
required by other layers.
IOT_UNIT-II_MVSR 6

6
 4/11/2019

IoT Architecture -
State of the Art

The capabilities are grouped generically, such as AAA and
message integrity/confidentiality support, and specifically,
such as ones that are tailored to the specific application,
e.g. mobile payment.

IOT_UNIT-II_MVSR 7

7
 4/11/2019

Reference Model and Architecture -

IOT_UNIT-II_MVSR 8

8
 4/11/2019

IoT Architecture -
State of the Art

An ARM consists of two main parts: a Reference model
and a Reference Architecture. For describing an IoT ARM,
we have chosen to use the IoTA ARM (Carrez et al. 2013)
as a guide because it is currently the most complete
model and reference. However, a real system may not
have all the modeled entities or architectural

IOT_UNIT-II_MVSR 9

9
 4/11/2019

From Ref Models to Concrete

architectures and actual systems

IOT_UNIT-II_MVSR 10

10
 4/11/2019

IoT Architecture -
State of the Art

IOT_UNIT-II_MVSR 11

11
 4/11/2019

IoT Architecture -
State of the Art

The

IOT_UNIT-II_MVSR 12

12
 4/11/2019

IoT domain model

IOT_UNIT-II_MVSR 13

13
 4/11/2019

IoT Information model

IOT_UNIT-II_MVSR 14

14
 4/11/2019

IoT information model

IOT_UNIT-II_MVSR 15

15
 4/11/2019

IoT Functional Model

IOT_UNIT-II_MVSR 16

16
 4/11/2019

IoT Information model

IOT_UNIT-II_MVSR 17

17
 4/11/2019

IoT Architecture -
State of the Art

IOT_UNIT-II_MVSR 18

18
 4/11/2019

Deployment and operational view

IOT_UNIT-II_MVSR 19

19
 4/11/2019

Deployment and operational view

The Figure 8.8 depicts the Devices view as Physical
Entities deployed in the parking lot, as well as the
occupancy sign.
There are two sensor nodes (#1 and #2), each of which
are connected to eight metal/car presence sensors.
The two sensor nodes are connected to the payment
station through wireless or wired communication.
The payment station acts both as a user interface
for the driver to pay and get a payment receipt as well as
a communication gateway that connects the two sensor
nodes and the payment interface physical devices
(displays, credit card slots, coin/note input/output, etc.)
with the Internet through Wide Area Network (WAN)
technology.
IOT_UNIT-II_MVSR 20

20
 4/11/2019

Deployment and operational view

The occupancy sign also acts as a communication
gateway for the actuator node (display of free parking
spots), and we assume that because of the deployment, a
direct connection to the payment station is not feasible
(e.g. wired connectivity is too prohibitive to be deployed or
sensitive to vandalism).
The physical gateway devices connect through a WAN
technology to the Internet and towards a data center
where the parking lot management system software is
hosted as one of the virtual machines on a Platform as a
Service (PaaS) configuration.
The two main applications connected to this management
system are human user mobile phone applications and
parking operation center applications.
IOT_UNIT-II_MVSR 21

21
 4/11/2019

Real world/Technical design constraints

The IoT will see additional circuitry built into a number of

existing products and machines from washing machines
to meters.
The operational environments and the criticality of the
information transmitted to and from these products,
however, will present some unconventional challenges
and design considerations.
The IoT will allow for the development of novel
applications in all imaginable scenarios.
The technical design of any M2M or IoT solution requires
a fundamental understanding of the specificity of the
intended application and business proposition, in addition
to heterogeneity of existing solutions.
IOT_UNIT-II_MVSR 22

22
 4/11/2019

Real world/Technical design constraints

Developing an end-to-end instance of an M2M or IoT
solution requires the careful selection, and in most cases,
development of a number of complementary technologies.
Assuming that the system designer has selected the
appropriate communications technologies to bridge the
device and application domains (likely standard Internet
Protocol (IP)-based methods), he or she must consider
the application at several levels: the device (or M2M Area
Network; i.e. hardware), representation (i.e. data and
visualization thereof), and interaction (i.e. local or remote
control).

IOT_UNIT-II_MVSR 23

23
 4/11/2019

Data representation and visualization

Each IoT application has an optimal visual representation
of the data and the system.
Data that is generated from heterogeneous systems has
heterogeneous visualization requirements.
There are currently no satisfactory standard data
representation and storage methods that satisfy all of the
potential IoT applications.
Data-derivative products will have further ad hoc
visualization requirements.
New information sources, such as those derived from
integrated data streams from various logically correlated
IoT applications, will present interesting representation
and visualization challenges.
IOT_UNIT-II_MVSR 24

24
 4/11/2019

Interaction and remote control

To exploit remote interaction and control over IoT
applications, connectivity that spans the traditional
Internet (i.e. from anywhere) on the side of the application
manager, or other authorized entity, to the end-point (i.e.
an embedded device), continues to be a challenging
problem.
Aside from authentication and availability challenges, for
most constrained devices, heterogeneous software
architectures, such as event-based operating systems
running on devices with significantly varying concurrency
models, continue to pose significant challenges from a
remote management perspective.

IOT_UNIT-II_MVSR 25

25
 4/11/2019

Interaction and remote control

Elements of Device Management, specifically
reprogramming and reconfiguration of deeply embedded
devices, will be required, particularly for devices deployed
in inaccessible locations.
This requires, among others, reliability, availability,
security, energy efficiency, and latency performance,
to be satisfactory while communicating across complex
distributed systems.
Another significantly under-researched topic is the
definition and delivery of end-to-end quality of service
(QoS) metrics and mechanisms in IoT type applications.

IOT_UNIT-II_MVSR 26

26
 4/11/2019

Interaction and remote control

These will be necessary if Service Agreements (SA) or
Service Level Agreements (SLA) are to be defined in the
case of service provisions for IoT applications which may
or may not be desirable to the application owner.
This will be situation-specific. End-to-end latency, security,
reliability, availability, times between failure and repair,
responsibility, etc., are all likely to feature in such
agreements.

IOT_UNIT-II_MVSR 27

27
 4/11/2019

Thank you

IOT_UNIT-II_MVSR 28

28