IOT

1. INTERNET OF THINGS
ARCHITECTURE
Dr.G.Balamurugan
Assistant Professor
Department of Computing Technologies
SRM Institute of Science and Technology
Kattankulathur Campus
Chengalpattu-603203

2. Internet of Things
IoT is an infrastructure of interconnected physical entities, systems
and information resources together with the intelligent services
which can process and react information of both the physical world
and the virtual world and can influence activities in the physical world.

3. EMERGING IoT
• The emerging “Internet of Things”
is a series of consumer, industrial,
public sector and hybrid networks
that are collectively use the
Internet to create closed loop
networks for connecting the cyber
physical devices operational
technology with sensors,
controllers, gateways and services

4. Many related vertical and horizontal activities
AIOTI
ALLIANCE FOR INTERNET OF THINGS INNOVATION

5. Heterogeneous Architectures

6. Reference Architecture For IoT
• IoT devices are inherently connected – A model is needed to specify interactions
with the devices
• An architecture is needed to “overcome” complexity and “achieve” scalability
• Devices are expect to interact with themselves and the environment, continually –
An architecture is need to achieve high-availability and support deployment across
highly-heterogeneous computational platforms
• Devices may not be designed for continuous “everyday” usage – An architecture is
needed to support remote, automatic and managed updates of the IoT devices.
• IoT devices are likely to be used for collecting and analyzing data – An architecture is
need for managing the identity and access control for IoT devices to ensure privacy

7. Generic Reference Model, technologies,
• IoT-A, is a “generic” architectural
reference model, by the European
Lighthouse Integrated Project,
envisioned as foundations for
reasoning about architectural
principles and design guidelines for
the emerging IoTs.

9. Layers of IoT Architecture
• The complexity of IoT solution architectures can be a formidable challenge for
IoT adoption.
• Interestingly, the basic architecture of IoT by using the different layers in the
architecture for Internet of Things solutions.
• The four types of models which explain the architecture of Internet of Things
solutions include,
• 3 layer architecture
• 4 layer architecture
• 5 layer architecture
• 7 layer architecture

10. Layers of IoT Architecture
• The 3 layer architecture offers the most basic impression of how an IoT
network should look like.
• However, the 3-layer model could not cover other important aspects related to
the operations of IoT networks.
• The 5-layer architecture presents an extended high-level overview of how IoT
solutions should work by improving on the 3-layer architecture.
• The 4 layer architecture offers a representation of the technical structure of an
IoT solution with details of important components.
• Finally, the 7-layer architecture for the Internet of Things offers a
comprehensive framework for the implementation of IoT solutions.

11. Internet of Things Reference Architecture (IoT RA)

12. IoTReference Architecture
–GoalsandObjectives
• IoT RA outlines “what” the
overall structure approach
for the construction of IoT
systems and indicates
“how” the architecture and
its domains or entities will
operate
Reference
Architecture
Conceptual
Model
Reference
Model
It defines a common structure and
definitions describing the concepts and
relationships with the IoT systems
An abstract framework for understanding
relationships among entities of an
environment and for developing
consistent specifications supporting that
environment

13. IoT RA
Structure
• CM contains
common entities and
their relationships
• RM provides the
basis to define
different
architectures views
Architecture view
Characteristics
Conceptual Model Reference Model
Architecture View
Abstracted and generated to build
Creates
Clause Structure
Develops

14. Conceptual Model
Concepts Overall Model
Conceptual Model
Build

15. Reference Model and Architecture Views
Architecture Views
Functional View
System View
Communication View
Information View
Usage View
Reference Model
Domain Concept
is based on
uses

16. Characteristics
Grouping 1st Level
IoT System
Characteristics
Auto-configuration
Function and management capabilities separation
Highly distributed systems
Network communication
Network management and operation
Real-time capability
Self-description
Service subscription

17. Characteristics
IoT Service Characteristics
Content-Awareness
Location-Awareness
Time-Awareness
IoT Component Characteristics
Composability
Discoverability
Modularity
Network connectivity
Shareability
Unique identification

18. IoT Characteristics
Compatibility
Legacy support
Well defined components
Usability
Flexibility
Manageability
Robustness
Accuracy
Reliability
Resilience
Security
Availability
Confidentiality
Integrity
Safety
Protection of Personally Identifiable
Information
Privacy

19. Autoconfiguration Characteristic
• Description
• Ability to automatically reconfigure a device based on the interworking of predefined rules
• Relevance to IoT
• Autoconfiguration is useful for IoT systems, as there are many and varied components that
can change over time
• It allows automatic maintenance and elimination of faulty component.

20. Real-Time Capability
• Description
• Realtimeliness refers to a mode of operation where computation can control, monitor or
respond in a timely manner to an external process when it occurs
• Relevance to IoT
• IoT systems may require stream processing, which requires acting on data events in
progress in order to react “appropriately”
• Example – Process control requires monitoring of and acting on a number of parameters,
including temperature , flow, pressure or status of a device.

21. IoT Conceptual Model
• CM defines the concepts of, and relationships among, the entities within IoT
systems, in a generic, abstract and simple way.
• The overall model of IoT entities and their relationships
• The key concepts in a typical IoT system
• The relationships between the entities, especially between digital entities and their
physical entities
• Identifies the actors and where they are located
• Specifies how things and services collaborate via the network

22. CM – Overall Model for IoT Concepts
IoT-User
Entity
Human User
Human
Digital User
Component
Virtual Entity
Digital Entity
Physical Entity
Entity
Tag
Identifier
Application Service
Data
Source Sensor Actuator
IoT Device
Component
IoT-Gateway
Component
Network
Entity
Is a
Is a
Interacts using Is contained within
Is a Uses
Represents Has
Contains
Monitors
Acts on
Interacts with
Interacts through
Interacts with
Uses
Connects
Interacts through
Is a
Is a
Interacts through Interacts with

23. CM – Entity and Domain Concepts
Entity
Physical
Entity
Digital
Entity
Network
Entity
IoT-User
Domain
Contains
Is a
Is a
Is a
Is a
Has
Contains
Interacts with
Contains
Includes

24. CM – Domain Interactions
Domain A Domain B
Interacts with

25. CM – Domain Composition
Domain A
Domain B
Contains
Domain C
Contains

26. CM → RM
Transforming Concept into a Model

27. Security
and
Privacy
Entity-based IoT RM
Resource &
Interchange
System
Application
Service System
Operation &
Management
System
Physical Entity, including human
IoT Devices
(Include sensors, actuators, and tags)
IoT Gateway
(local services and data)
IoT Users
(Include Human, Devices/HMI)
Network
Tags
PeerSystems

28. © ISO/IEC CD 30141 – All rights reserved
Physical Entity Domain (PED)
User Domain (UD)
Operations & Management
Domain (OMD)
Application Service
Domain (ASD)
Resource & Interchange
Domain (RID)
Sensing & Controlling Domain (SCD)
Domain-based IoT RM

29. Inside-Domain
Functions
Cross-Domain
Functions
User Interface
Life Cycle
Management
Business
Support
API & Portal Resource Interchange
Business Services Analytics Access Control
Logic & Rules Resource Management
LocalModeling Asset Management Executor
NetworkAccess
Sensing Identification Actuation
User Domain
Operation & Management
Domain
Application Service
Domain
IoT Resource &
Interchange domain
Security & Safety
Management
Sensing &
Controlling
Domain
Physical Entity Domain
Security
Safety
&
Resilience
Trust
&
Privacy
Connectivity
Interoperability
Dynamic
composition
&
Automated
Interoperability
Regulation Management
Domain Composition

30. CM, RM AND RA
Interplay and Relationship

31. Relationship between CM, RM and RA
• IoT Domains are derived from the stakeholders, hardware and software:
CM -> RM -> RA
IoT Reference Model – Domain Based
IoT Reference Model
(Entity Based)
IoT Conceptual Model
IoT RA
System
View
IoT RA
Usage View
IoT RA
Information
View
IoT RA
Functional
View
IoT RA
Communication
View

32. IoT RA System View
Human
Users
HMI
User
Interface
Devices
Digital
User
User Domain
IoT Resource and Interchange Domain
Interchange
System
Resource
Management
System
Access
Management
System
Application Service Domain
Business
Service
System
Resource
Service
System
Operation and Management Domain
Operation
System
Regulation
Management
System
IoT
Gateway
Local
Control
System
Actuator
Sensor
Controlled Physical
Objects
Sensed Physical Objects
Physical Entity Domain
Sensing and Control
Domain
User Net Service Net Proximity Net
Access Net

33. Functional Model

34. Functional Model – Information Flow

35. Communication View

36. IoT Architecture
A State of Art

37. Internet of Things
State of the Art
•Several Reference Architectures and Models exist both for M2M and IoT systems.
• Four most popular ones are discussed here from which the Architecture Reference
Model (ARM) has borrowed concepts and functions.
•An Architecture Reference Model (ARM) is useful as a tool that establishes a common
language across all the possible stakeholders of an M2M or IoT system.
•The most common Reference architectures that are referred in the show are:
1. European Telecommunications Standards Institute M2M/oneM2M
2. International Telecommunication Union - Telecommunication sector view
3. Internet Engineering Task Force architecture fragments
4. Open Geospatial Consortium architecture

38. Internet of Things
1. European Telecommunications Standards Institute M2M/oneM2M
 The European Telecommunications Standards Institute (ETSI) in 2009 formed a
Technical Committee (TC) on M2M topics aimed at producing a set of standards for
communication among machines from an end to-end viewpoint.
 The ETSI M2M standards are based on specifications from ETSI as well as other
standardization bodies such as:
The IETF (Internet Engineering Task Force),
3GPP (3rd Generation Partnership Project),
OMA (Open Mobile Alliance), and
BBF (Broadband Forum).

39. Internet of Things
1. European Telecommunications Standards Institute M2M/oneM2M
 The first M2M standards were released in early 2012.
 While in middle of 2012, seven ICT organizations formed One M2M
partnership project in order to develop M2M specifications, promote the
M2M

40. Internet of Things
1. European Telecommunications Standards Institute M2M/oneM2M

41. Internet of Things
1. European Telecommunications Standards Institute M2M/oneM2M
The Device and Gateway Domain contains the following functional/topological entities:
 M2M Device
 M2M Area Network
 M2M Gateway
The Network Domain contains the following functional/topological entities:
Access Network Network Management Functions
Core Network M2M Management Functions
M2M Service Capabilities M2M Service Bootstrap Function
M2M Applications M2M Authentication Server

42. Internet of Things
2. International Telecommunication Union - Telecommunication sector view
The ITU-T has been active on IoT standardization since2005
It was renamed to Joint Coordination Activity on IoT.

43. Internet of Things
2. International Telecommunication Union - Telecommunication sector view

44. Internet of Things
2. International Telecommunication Union - Telecommunication sector view
The ITU-T IoT model considers Application layer as the host of specific
IoT applications (e.g. remote patient monitoring).
» The Service & Application Support Layer consists of generic service
capabilities used by all IoT applications, such as data processing and data
storage.
» The Network Layer provides networking capabilities such as Mobility
Management, Authentication, Authorization, and Accounting (AAA).
* The Device Layer includes Device Capabilities and Gateway
Capabilities.

45. Internet of Things
3. Internet Engineering Task Force architecture fragments
The scope and specifications is shown in Figure, and it is clear that each set of
specifications makes an attempt to address a different part of the communication
stack of a constrained device.

46. Internet of Things
3. Internet Engineering Task Force architecture fragments
The Framework has:
The modified Open Systems Interconnection (OSI) model in which several layers are merged
because of the implementation on constrained devices.
Moreover, one intermediate layer between Physical Layer and Data Layer Link is introduced
having name as Adaptation Layer.
An example of an Application Support Layer is IETF Constrained Application Protocol (CoAP).
 The framework describes the Transport and Application Support Layers, which essentially defines
the transport packet formats

47. Internet of Things
4. Open Geospatial Consortium architecture
The Open Geospatial Consortium (OGC 2013) is an international
industry consortium of a few hundred companies, government agencies,
and universities that develops publicly available standards that provide
geographical information support to the Web, and wireless and location-
based services.

48. Internet of Things
4. Open Geospatial Consortium architecture
OGC includes:
The sensor web enablement (SWE) (OGC SWE 2013) domain working
group, which develops standards for sensor system models (eg. Sensor
model language, or sensor ml),
Sensor information models (observations & measurements, or O&M),
and
Sensor services that follow the service-oriented architecture (SOA)
paradigm , as is the case for all OGC-standardized services.

49. Internet of Things
4. Open Geospatial Consortium architecture
The functionality that is targeted by OGC SWE includes:
Discovery of sensor systems and observations that meet an application’s criteria.
Discovery of a sensor’s capabilities and quality of measurements.
Retrieval of real-time or time-series observations in standard encodings.
Tasking of sensors to acquire observations.
Subscription to, and publishing of, alerts to be issued by sensors or sensor
services based upon certain criteria

50. Internet of Things
4. Open Geospatial Consortium architecture
OGC SWE includes the following standards:
 Sensor ML and Transducer Model Language (TML).
 Observations and Measurements (O&M).
 SWE Common Data model.
 Sensor Observation Service (SOS).
 Sensor Planning Service (SPS).
 PUCK.

51. Internet of Things
4. Open Geospatial Consortium architecture

52. Internet of Things
IoT Architecture

53. Internet of Things
•Reference Model and Architecture

54. Internet of Things
Reference Model and Architecture
Overview:
An ARM consists of two main parts:
1. A reference model and
2. A reference architecture.
IoT ARM is currently the most complete model and reference architecture.
However, a real system may not have all the modeled entities described in
the architecture.

55. Internet of Things
Reference Model and Architecture
Overview:
1. IoT Reference Model
A reference model describes the domain using a number of sub-models.
An Information Model - The domain model adds descriptions about the
relationship between the concepts which serve the basis for the
development of an information model.
A working system that captures and operates on the domain and
information model contains concepts and entities of its own, is described
as a functional model.

56. Internet of Things
Reference Model and Architecture

57. Internet of Things
Reference Model and Architecture
Overview:
2. IoT Reference Architecture
A System Architecture is a communication tool for different stakeholders of the system.
Describing an architecture for M2M and IoT systems involves the presentation of the
multiple facets of the systems.
A Reference Architecture captures the essential parts of an architecture, such as design
principles, guidelines, and required parts.
A concrete architecture can be elaborated and mapped into real world components by
designing, building, engineering, and testing the different components of the actual
system.

58. Internet of Things
Reference Model and Architecture
Overview:
3. IoT Reference Model & Architecture Dependencies
The IoT architecture model is related to the IoT Reference Architecture as
shown in Figure on next slide.
The figure shows two facts of the IoT ARM:
(a) How to actually create an IoT ARM, and
(b) How to use it with respect to building actual systems.

59. Internet of Things

60. Internet of Things
loT Reference Architecture
IoT Reference Architecture is a starting point for generating concrete architectures and
actual systems.
A Reference Architecture serves as a guide for one or more concrete system architects.
The Reference Architecture is presented as a set of given architectural views:
1. Functional View: Description of what the system does , and its main functions.
2. Information View: Description of the data and information that the system handles.
3. Deployment and Operational View: Description of the main real world components
of the system such as devices, network routers, servers, etc.

61. Internet of Things- Functional View

62. Internet of Things
loT Reference Architecture
Functional view
Device functional group
The Device FG contains all the possible functionality hosted by the
physical Devices that are used for instrumenting the Physical Entities.
This Device functionality includes sensing , actuation, processing, storage,
and identification components, the sophistication of which depends on the
Device /capabilities.

63. Internet of Things
loT Reference Architecture
Functional view
Communication functional group
The Communication FG abstracts all the possible communication
mechanisms used by the relevant Devices in an actual system in order to
transfer information to the digital world components or other Devices.
 Examples of such functions include wired bus or wireless / mesh
technologies through which sensor Devices are connected to Internet
Gateway Devices.

64. Internet of Things
loT Reference Architecture
Functional view
IoT Service functional group
The IoT Service FG corresponds mainly to the Service class from the IoT
Domain Model, and contains single IoT Services exposed by Resources
hosted on Devices or in the Network
(e.g. processing or storage Resources).
Support functions such as directory services, which allow discovery of
Services and resolution to Resources, are also part of this FG.

65. Internet of Things
loT Reference Architecture
Functional view
Service Organization functional group
The purpose of the IoT Service Organization FG is to host all functional components
that support the composition and orchestration of IoT and Virtual Entity services.
Moreover, this FG acts as a service hub between several other functional groups such
as the IoT Process Management FG.
The Service Organization FG supports the association of Virtual Entities with the
related IoT Services, and contains functions for discovery, composition, and
choreography of services.

66. Internet of Things
loT Reference Architecture
Functional view
Security functional group
The Security FG contains the necessary functions for ensuring the security and privacy of an IoT system.
It contains the given FGs:
 The Identity Management FC
The Authentication FC
The Authorization FC
The Key Exchange & Management FC
The Trust & Reputation FC

67. Internet of Things
loT Reference Architecture
Functional view
Management functional group
The Configuration FC maintains the configuration of the FC’s and the Devices in an IoT
system.
The component collects the current configuration of all the FCs and devices, stores it in a
historical database, and compares current and historical configurations.
It contains the given FCs:
The Fault FC
The Member FC
The State FC
The Reporting FC

68. Internet of Things
loT Reference Architecture
Functional view
Application functional group
The Application FG is just a placeholder that represents all the needed
logic for creating an IoT application .
It is a tray of Pseudocodes of various applications that need to collaborate.

69. Internet of Things
IoT Reference Architecture
Functional view
Modular IoT Functions
The Functional View of the Reference Architecture, contains a complete
map of the potential functionalities for a system realization.
The FGs are organized in such a way that more complex A functionalities
can be built based on simpler ones, thus making the model modular.

70. Internet of Things
IoT Architecture
•Technical Design Constraints

71. Internet of Things
Technical Design Constraints:
The IoT will see additional circuitry built into a number of existing
products and machines from washing machines to meters.
For manufacturers of products that typically contain electronic
components, this process will be relatively straightforward.
The operational environments and the criticality of the information
transmitted to and from these products, will present some unconventional
challenges and design considerations.

72. Internet of Things
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.
This can be both a difficult conceptual problem and integration challenge.
* Functional Requirements
* Sensing and Communication Fields
* Programming and embedded intelligence
* Power and Gateway
* Non-functional Requirements
* Financial Cost
* Data Representation and Visualization
* Interaction and Remote Control

73. Internet of Things
Technical Design Constraints:
Functional Requirement:
This is the basis of the application. Sensors, broadly speaking, are difficult to categorize
effectively because:
* In many cases, sensing may be prohibitively expensive or unjustifiable at scale.
* The variety in sensing is very high - Given a particular phenomenon of interest, there
are often numerous sensors capable of detecting the same phenomenon, but have
widely varying characteristics.
* Sensing principle and data requirements are also of essence when considering the
real-world application.

74. Internet of Things
Technical Design Constraints:
Sensing and Communication Field:
The physical environment has an implication on the communications
technologies selected and the reliability of the system in operation.
Devices may become intermittently disconnected due to the time varying,
stochastic nature of the wireless medium.
Certain environments may be fundamentally more suited to wireless
propagation than others.

75. Internet of Things
Technical Design Constraints:
Programming and Embedded Intelligence:
Devices in the IoT are fundamentally heterogeneous.
Careful implementation of the (embedded) software is required to ensure
that the device operates as desired.
For heterogeneous devices, the embedded software will vary by device.

76. Internet of Things
Technical Design Constraints:
Power:
Depending on the application, power may be provided by the mains, batteries,
or conversion from energy scavengers (often implemented as hybrid power
sources).
Gateway:
The Gateway is typically more straightforward to design, but there are very
few effective M2M or IoT Gateway devices available on the market today.

77. Internet of Things
Technical Design Constraints:
Non-Functional Requirements:
There are a number of non-functional requirements that need to be satisfied
for every application.
These are technical and non-technical:
Regulations,
Ease of use, installation, maintenance, accessibility, and
Physical constraints .

78. Internet of Things
Technical Design Constraints:
Financial Cost:
Financial cost considerations are as follows:
Component Selection - There are research and development costs likely
to be incurred for each individual application in the IoT that requires
device development or integration. Developing devices in small quantities
is expensive.
Integrated Device Design - The PCB design will require specific
attention to be paid in the RFIC manufacturer during development, or in
the integration of an additional Integrated Circuit (IC).

79. Internet of Things
Technical Design Constraints:
Data Representation and Visualization:
Data that is generated from heterogeneous systems has heterogeneous
visualization requirements.
There are currently no satisfactory standard data representation and storage
methods

80. Internet of Things
Technical Design Constraints:
Interaction and Remote Control:
Connectivity that spans the traditional Internet to connect the application
manager, or other authorized entity, to the end-point such as an embedded
device, continues to be a challenging problem.
Aside from authentication and availability challenges, heterogeneous
software architectures, continue to pose significant challenges from a
remote management perspective.
Elements of Device Management, will be required, particularly for devices
deployed in inaccessible locations.

81. Management
Generic
Management
Capabilities
Capabilities
Specific
Management
Capabilities
Application
Layer
IoT
Applications
Service Support
& Application
Support Layer
Specific Support
Capabilities
Generic Support
Capabilities
Network
Layer
Networking Capabilities
Transport Capabilities
Device
Layer
Specific Support
Capabilities
Generic Support
Capabilities
Security
Generic
Security
Capabilities
Capabilities
Specific
Security
Capabilities
IoT Advanced Model
Device
Layer
Specific Support
Capabilities
Generic Support
Capabilities

82. Reference Architectural Model
Industry 4.0
Basic RAMI is extended by security capabilities – Security is built into each layer and each dimension
Next-generation Industrial Manufacturing Systems
A Reference
model for all
participants
involved in
Industry 4.0
discussions

83. INTEL Architecture

85. Various Working Groups for Innovation and
interoperability
Working Group (Active Since) Charter Founding Members
IPSO Alliance (Sep 2008)
Establish Internet Protocol (IP) as the network to interconnect
smart objects, and allow existing infrastructure to be readily used
without translation gateways or proxies
ARM, Atmel, Bosch, Cooper, Dust
Networks, EDF, Ericsson, Freescale et
al
IoT-A (2010-2013)
Developed an architectural reference model to allow seamless
integration of heterogeneous IoT technologies into a coherent
architecture to realize ‘Internet of Things’ rather than ‘Intranet of
Things’
ALU, Hitachi, IBM, NEC, NXP, SAP,
Siemens, and universities – “Mission
Accomplished late 2013”
oneM2M (2012)
Develop technical specifications for a common M2M Service
Layer to allow connectivity between devices and various M2M
applications, to realize horizontally integrated Internet-of-Things
Leading ICT standards bodies namely
ETSI, ARIB, TTC, ATIS, TIA, CCSA and
TTA
AllSeen Alliance (2013)
Collaborate for an open, universal IoT software framework across
devices and industry applications, based on AllJoyn open source
project, originally developed by Qualcomm but now released to
community developers
Qualcomm, in collaboration with
Linux Foundation
Industrial Internet Consortium (Mar
2014)
Accelerate development and adoption of intelligent industrial
automation for public usecases
AT&T, Cisco, GE, Intel, IBM

86. Various Working Groups for Innovation
and interoperability
Working Group (Active Since) Charter Founding Members
HyperCat (May 2014)
Develop an open specification for IoT that will make data available in a
way that others could make use of it, through a thin interoperability
layer.
ARM, BT, IBM, Intel, Living
PlanIT, et al
Open Interconnect Consortium
(Jul 2014)
Define interoperable device communication standards (for peer-to-
peer, mesh & bridging, reporting & control etc.) across verticals, and
provide an open source implementation
Atmel, Broadcom, Dell, Intel,
Samsung and Wind River
IEEE P2413 (Jul 2014)
Create a standard interoperability architecture and define commonly
understood data objects, for information sharing across IoT
systems; Standardization targeted by 2016
IEEE; collaborating with
oneM2M, ETSI and other
SDOs to evolve joint
standards
Thread (2014)
Create an open, secure, simple, power-efficient protocol, based on
robust mesh network that runs over standard 802.15.4 radios, and
can support a wide variety of home products
ARM, Freescale, Nest,
Samsung, Silicon Labs, Yale
OMA LWM2M (2014)
Proposed a new Light-weight M2M protocol standard, based on
client-server model for remote management of M2M devices and
related service enablement
OMA

87. THANK YOU