M.

Sc – INTERNET OF THINGS
SEMESTER-I

INTRODUCTION TO INTERNET OF
THINGS

MSC-IOT-103
All rights reserved. No Part of this book may be reproduced or transmitted, in any form or by
any means, without permission in writing from Mizoram University. Any person who does
any unauthorized act in relation to this book may be liable to criminal prosecution and civil
claims for damages. This book is meant for educational and learning purposes. The authors of
the book has/have taken all reasonable care to ensure that the contents of the book do not
violate any existing copyright or other intellectual property rights of any person in any
manner whatsoever. In the event the Authors has/ have been unable to track any source and if
any copyright has been inadvertently infringed, please notify the publisher in writing for
corrective action.

© Team Lease Edtech Pvt. Ltd.

All rights reserved. No Part of this book may be reproduced in any form without permission
in writing from Team Lease Edtech Pvt. Ltd.
Unit – 3: An Architectural Overview of IoT 88
UNIT – 3: AN ARCHITECTURAL OVERVIEW OF IOT

Structure
3.1 Learning Objectives
3.2 Introduction
3.3 Building an architecture
3.4 Main design principles and needed capabilities
3.5 IoT Architecture outline
3.6 Standards considerations
3.7 Reference model and architecture
3.8 Various architectural views
3.8.1 Functional view
3.8.2 Information view
3.9 Other relevant architectural views
3.9.1 The Physical Entity View
3.9.2 The Context View
3.10 Constraints affecting design in IoT world
3.11 Summary
3.12 Self-Assessment Questions
3.13 Suggested readings

3.1 OBJECTIVES

After studying this unit students will be able to:

 Outline building an IoT architecture and its Main design principles,

 Outline standard considerations while building an architecture
 Describe reference Architecture and Reference Model of IoT.
 Evaluate Various architectural views of IoT such as Functional, Information,
Operational, and Deployment.
 Describe how the Technical design Constraints are affecting the real IoT world.
3.2 INTRODUCTION

The word “architecture” has much explanation. This chapter comes up with an introduction to
how we can use the term “architecture”, and then, how it co-relates to problems, interesting
applications, and actual M2M/IoT solutions. An architecture mainly refers to the main
conceptual elements description, the real elements of a target system, how they are associated
with each other, and principles needed for the architecture design. A conceptual element
involves an intended function, a data piece, or a service. An actual or real element refers to a
technology building block or a protocol. The term "reference architecture" refers to a broad
model that includes the most comprehensive collection of elements and relationships
applicable to the "Internet of Things." Or looking to solve a specific problem or construct a
target program, such as an instance built from a subset of the reference architecture, the
reference architecture has been used as a guide to design an applied architecture.

3.3 BUILDING AN ARCHITECTURE

The applied architecture and reference architecture is used to develop the actual system
solution (Figure 3.1)

Figure 3.1

An architecture can be explained in many different kinds of views to capture particular

properties that are associated with the model, and the views chosen here are the functional
view, process view, information view, and deployment view. To create a model for the
reference architecture, one is required to bring overall objectives for the architecture and also
design principles. After a greater understanding of the actual problem domain, these
objectives and principles are obtained and can be done using the identification of recurring
problems or type solutions, and then, extracting design patterns which are common. The
problem domain has brought the foundation for the subsequent solutions. It is more general to
divide the architecture work and solution work into two different domains, each may address
particular issues related to the different levels of abstraction (Figure 3.2).

Problem domain

The top-level in the triangle describing the “problem domain”. The main goal of this domain
is to understand the applications, for example, using scenario building and use case analysis
for deriving requirements. Additionally, constraints are also identified with this. These
constraints are technical such as limited power availability in wireless sensor nodes, and also
non-technical, such as constraints coming from legislation or business.

Figure 3.2

Solution Domain

The solution domain will be defined at a lower level. Design goals and concepts are defined,
required functions are specified, conceptual perspectives are refined, and logical functio ns
and information partitions are established. More ever here is the place for a logical
architecture to be defined, or network architecture in the form of a network topology diagram
has been produced. Identifying relevant technology elements, such as operating systems and
protocols or protocol stacks, is also important at this stage. Finally, a system architecture
captures the entire system solution, which includes actual software and hardware elements as
well as documentation on how they will be designed, deployed, and provisioned.
3.4 MAIN DESIGN PRINCIPLES AND NEEDED CAPABILITIES

IoT architecture's overall goal is to create a horizontal structure of real-world networks that
are transparent, service-oriented, stable, and trustworthy. The design principles have a set of
interpretations and further expectations on needed technology solutions that follows.

i) Design for reuse of deployed IoT resources across different application domains.
Deployed IoT resources shall be able to be used in a wide range of various kinds of
applications. This tells that devices can be made application-independent and that the
basic services they exhibit in terms of sensing and actuation can be done in a
consistent way. The Benefit of a system design will be to provide an abstracted view
of these basic underlying services.
ii) Design for a set of support services that allow open service-oriented capabilities and
have been used by application development and execution. In general, the support
services will act as a representative environment for a donor where IoT applications
will be developed, as well as support for a few core service features that are critical
from an IoT perspective. Mechanisms for authorized use of services and resources,
authentication, and related identity protection will all be part of the open IoT
environment. Accessing IoT resources, publishing and exploring resources, tools for
modeling contextual data and data relevant to real-world objects, and capabilities to
include different layers of abstracted and complex services are among the main
support services required from an IoT perspective. Finally, details, event filtering, and
analytics, as well as complex service composition and resolution of mixed sensing
and actuation, should all be considered.
iii) Design for different abstraction levels which are hidden underlying heterogeneities
and complexities. As we have already seen, classic IoT solutions can involve a huge
number of various devices and associated sensor modalities, and involve a large set of
a variety of actors providing services and information that require to be composed and
accessed with different levels of aggregation. A system design may extremely benefit
from providing the necessary abstractions of underlying technologies, and data and
service representation, also granularity of information and services. This will make
system integrators and application developers ease their burden.
iv) Design for sensing and actors perform on different roles of providing and using
services across various business domains and value chains. As explored in earlier
chapters, there are many opportunities in the business context where IoT solutions are
deployed and running. IoT solutions shall run across a set of departments within an
enterprise, or a group of enterprises in a value system, even be provided in a truly
open environment. The first thing that requires is to provide a set of mechanisms that
assures security and trust. In turn, trust and identity man-management that refers to
the distinct stakeholders is a basic requirement. a second requirement is authentication
and authorization of access to use services and also be able to provide services. The
capability to be able to do auditing and to provide accountability so that stakeholders
can impose liability if the need occurs is the third requirement. The next basic
requirement is to ensure interoperability. This has been required at different levels
across the interaction points between the stakeholders. These various primary
requirements also giving opportunities for new market roles, like aggregator roles,
broker roles, and clearinghouses, all well known in other existing markets.
v) Design for ensuring trust, security, and privacy. Trust within IoT often implicit
reliability, which ensuring the availability of services and also dependability of the
services, and that data. security and privacy are the critical barriers for IoT adoption
and represent key areas to address when building solutions. Privacy is needed to be
ensured using the anonymization of data. Still, the authorities and agencies will need
support to get access to data and information for national security or public safety.
vi) Design for scalability, performance, and effectiveness.
Sensor information will be consisting of broader range of various characteristics. Data
may be very infrequent (e.g., alarms or detected abnormal events). Scalability is
inclusive of a large number of devices and amounts of data produced which are
required to be processed or stored. Performance aspects of importance include
consideration of mission-critical applications.
vii) Design for evolvability, heterogeneity, and simplicity of integration. Technology
is conditionally evolving, and has given the nature of IoT deployments in that devices
and sensor nodes are expected to be operational and in the field for several years.
Since especially device-oriented technologies used across industries are very
different, handling heterogeneity is also important. Integrate legacy devices by many
different protocols becomes a necessity, and gateways of various types and with
 different capabilities will be a necessity to expose the capabilities of legacy devices
uniformly.
viii) Design for simplicity of management. One of the potential barriers for IoT
adaptation, simplicity of management is a crucial capability that needs to be precisely
taken care of when designing IoT solutions. To ease deployment of IoT devices,
autoconfiguration and auto-provisioning are playing a key role, and are also very
important to lower operating expenditures (OPEX).
ix) Design for different service delivery models. IoT with the broad range of possible
applications clearly benefits from elasticity in the deployment of solutions, all to meet
the long-tail aspect. Cloud and virtualization technologies play a key role in
delivering future IoT services.
x) Design for lifecycle support. planning, development, deployment, and execution are
the phases of the lifecycle. The most important aspects of management are
implementation performance, design-time tools, and run-time management.
Taking into account these design concepts, detailed use cases, and targeted
implementations, it is important to define criteria that form the basis for
comprehensive architectural design.

3.5 AN IOT ARCHITECTURE OUTLINE

Like IoT solutions, there is no single commonly recognized view of IoT architecture.
Attempting to create a single architecture results in a large range of discretionary and
contractual conditions, which vary depending on the issue or implementation in question.
Even then, by recommending a single vision of the main functional capabilities, the defined
core features that are needed when constructing an M2M or IoT solution can now be held
together in a broader sense. see Figure 3.3 which provides high-level summary of the topic.

Figure 3.3

Asset Layer

The lowest level layer includes the real-world entities that are subject to being monitored and
controlled and also having digital representations and identities. Assets can also be a more
virtual character, being subjective representations of parts of the real world that are of interest
to a person or an organization.

Resource Layer

This layer provides the critical functionalities of sensing, actuation, and embedded identities.

Communication Layer

This layer allows communication between services and the various computing infrastructures
that host and execute service support and application logic. Different types of networks
realize the connectivity, such as a Local Area Network (LAN) and a Wide Area Network
(WAN).

Service Support Layer

This Layer support services that perform a common and routine tasks that are provided by
this layer. Generally, data storage for anything from raw information to knowledge
representations, and processing capabilities like data and event capture, filtering, and stream
processing are different core common services for many IoT applications.
Data and Information Layer

The primary goal of this layer is to provide a more abstract set of functions as are to capture
knowledge and allows advanced control logic support.

Application Layer

This Layer, in turn, provides the specific IoT applications. There is an open-ended array of
different applications, such as smart metering in the Smart Grid, vehicle tracking, building
automation.

Business Layer

The final layer in the architecture outline, which supports the operations of any enterprise,
organization, or individual that is interested in IoT applications.

Management

deals with the management of various parts of the system solution associated with its
operation, administration, maintenance, and provisioning. it inclusive of management of
devices, the general Information Technology (IT) infrastructure, communications networks,
and also configuration and provisioning data, the performance of services delivered, etc.

Security

It is ensuring the protection of the system, its information, and services, from external threats.
Security measures are generally needed across all layers because they will provide
communication and information security. The Main capabilities are Trust and identity
management, and authentication and authorization.

Data and Services

Here processing happens from a topological perspective, can be done in a very distributed
manner and at various levels of complexity. Basic event filtering and simpler aggregation,
like data averaging, can happen in individual sensor nodes in WSANs, contextual metadata
(like location and temporal information) can be added to sensor readings, and further
aggregation may happen higher up in the network topology. This functional group hence
represents the vertical flow of data into knowledge, the abstraction of data and services in
different levels, and the processing of extracting knowledge.
3.6 STANDARDS CONSIDERATIONS

The main goal of any technology-related standardization activity is to allow a group of

agreed-upon specifications that address issues typically like achieving interoperability in a
market with many actors and suppliers.

The standards are developed across various kinds of industries. There are many
standardization organizations and bodies, both proper Standards Development Organizations
(SDO) and also special interest groups that develop standards specifications. Various national
and international bodies ratify standard,

Figure 3.4 The Landscape Of M2m And Iot Standardization.

by SDOs, whereas Standard requirements formed by special interest groups and alliances are
usually accepted and implemented by market actors such as technology manufacturers.

Examples of international SDOs are:

 The International Telecommunications Union (ITU)

 The International Organization for Standardization (ISO),
 The European Telecommunications Standards Institute (ETSI)

European Committee for Electrotechnical Standardization (CENELEC) Other independent

international standardization organizations:

 The World Wide Web Consortium (W3C)

 The Internet Engineering Task Force (IETF).

From an M2M and IoT perspective, will find a difference between standards developed
within the Information and Communications Technology (ICT) industry, and standards
developed within a specific industry segment, like the Health, Transportation, or Electricity
industry segments.

The ICT industry has been developing technologies that are targeting in used by different
other industry segments, and the applied IoT industry segments make use of the ICT
standards to varying degrees in developing their standards. Some standardization activities
focus on the implementation of particular pieces of technology, such as specific protocols,
while others define whole processes or portions of systems. The phase of a standard's
lifecycle.

Standards are typically formed as a result of joint studies between academia and industry. An
another side, technology selection for standardization has happened as part of regulatory or
legislative processes.

Within the European Union, the European Commission has been issued Mandates that can
have a direct impact on the choice of technology, which hence precedes any subsequent
standardization activity. So finally, technology selection not only happens in the process of
standardization.

3.7 REFERENCE MODEL AND ARCHITECTURE

It uses multiple sub-models to characterize the domain, as seen in (Figure 3.5). The key
principles or entities in the associated domain are captured in the domain model of an
architecture model. The domain model adds descriptions about the relationship between the
definitions as these common language references start. The architecture of a knowledge
model is built on the basis of these principles and relationships.

Figure 3.5: IoT Reference Model.

The system collects data and works on the information model domain, which has its own set
of definitions and entities that must be represented in a different model, the functional model.
Since M2M and IoT systems may include interacting entities, the resulting communication
model must capture these entities' communication interactions.

3.7.1 IoT Reference Model

3.7.1.1 IoT domain model

In the case of the Internet of Things, a domain model describes the key principles of a certain
area of interest. Even if the details of an ARM can shift or evolve over time, these principles
are supposed to remain constant. It encapsulates the fundamental characteristics and
relationships between the principles. The domain model can also be used to facilitate human
correspondence through domains.

Model notation and semantics

To describe the domain model, the Unified Modeling Language (UML) Class diagrams are
used, to present the relationships between the main concepts of the IoT domain model. The
Class diagrams contain boxes that represent the various classes of the model connected by
continuous lines or arrows. Arrows or lines represent relationships between the respective
classes. Each class is a descriptor of a set of objects which have similar structure, behavior,
and relationships. A class contains a name such as class A in figure 3.6, and a set of attributes
and operations. Only the class name and attributes are needed for the description of the IoT
domain model. In notation representation, a box with two rooms, one consists of the class
name and the other has attributes.

Figure 3.6

Three kind of Devices are essential for defining IoT Domain Model:
1. Sensors: These are either basic or complex devices that use a transducer to transform
physical properties such as temperature into electrical signals. These Devices convert analog
electrical signals into digital signals, For example, a video camera is a complex sensor that
could detect and recognize people.

2. Actuators: These are basic and complicated devices that use a transducer to
transform electrical signals into a physical property transition, such as turning on a switch or
moving a motor. These Devices were inclusive of potential communication capabilities,
processing, storage of intermediate commands, and conversion of digital signals to analog
electrical signals.

3. Tags: Tags typically identify the Physical Entity which is attached to. Tags are either
Physical Entities or Devices but not both, as the domain model shows. A good example is an
RFID(Radio Frequency Identification) tag, while a tag as a physical entity is a paper-printed
immutable barcode or Quick Response (QR) code. Either electronic Devices or a paper-
printed entity tag contains a unique identifier that can be read using optical means (bar
codes/QR codes) or radio signals (RFID tags). In the case of writable RFID tags, the reader
Device is usually a sensor, except in some cases, a sensor and an actuator together.

3.7.1.2 Information model

The IoT Information Model, like the IoT Domain Model, can be expressed using UML
diagrams. Each class in a UML diagram has zero or more attributes, as previously stated.
These attributes are basic forms such as integers or text strings, and they are represented by
red text under the class name. The IoT Information Model keeps track of the most important
details about Virtual Entities and their properties. These characteristics can be static or
dynamic, and they can be entered into the device in a variety of ways, including manually
entering data or reading data from a sensor connected to the Virtual Entity. The Relationship
class in the high-level IoT information model provides information about the unique
relationship between a Virtual Entity and a related Service.

3.7.1.3 Functional model

The Functional View of a Reference Architecture explains the interfaces, functional elements
of an FG, and relationships between the components, while the IoT Functional Model's key
purpose is to explain the Functional Groups (FG) and their relationship with the ARM. The
Functional View is drawn from the Functional Model and high-level specifications in most
cases. These Functional Groups have been explained deeply in functional view.

Figurer 3.7(The Functional model)

3.7.1.4 Communication model

Identification of connection endpoints, traffic characteristics such as unicast vs. multicast,

and common properties of the underlying technology used to have such connections are all
part of the communication model for an IoT Reference Model. The IoT Domain Model's
potential communicating endpoints (entities) are Users, Devices, and Resources.

3.7.1.5 Safety, privacy, trust, security model

Safety: Device security is application- or domain-specific, and it's usually linked to an IoT
machine with actuators that may theoretically affect living things (humans, animals). A
designer of the device or system should follow the below two steps:

1. Identification of hazards followed by,

2. The mitigation plan.

Privacy: The most important aspect of an IoT framework is to protect user privacy. Identity
Management, Authentication, Authorization, and Trust & Reputation are the practical
elements that can be used to achieve privacy.
Trust: “Generally, an entity is said to „trust' a second entity because the first entity believes
that the second entity will behave precisely as the first entity expects,” according to the
Internet Engineering Task Force (IETF) Internet Security Glossary (Shirey 2007). As can be
seen, trust and reputation can be expressed by a ranking. The behavior of technological
components engaging with each other is then influenced by this ranking.

3.7.2 Reference Architecture.

A system architecture is a coordination medium for the system's different stakeholders.

Stakeholders (developers, component and device administrators, stakeholders, vendors, and
customers) all have varying views on a common system, depending on their needs and
experiences with it. As a result, when defining an architecture for M2M and IoT frameworks,
the various stakeholders must be satisfied. Reference Architecture, as seen in Figure 3.8, is a
high-level abstraction that acts as a reference for creating specific structures and real
structures.

A Reference Architecture captures the components of an architecture that are used to track
and communicate with the real environment, such as instructions, design rules, and required
pieces. The whole process is iterative, as seen in the diagram, which ensures that the real
implemented system in the field offers useful input for design and technical decisions, as well
as possible future possibilities and existing system limitations, which are fed back to the
concrete architectures. The general essentials of various concrete architectures will then be
combined and added to the Reference Architecture's progression.

Through planning, constructing, engineering, and analyzing the various components of the
actual structure, a concrete architecture can be further elaborated and mapped into real-world
components. The whole process is iterative, as the real implemented implementation in the
field offers invaluable input on design and technical decisions, existing system constraints,
and possible future opportunities that are fed back to the conceptual architectures, as seen in
the diagram.

The IoT architecture model is interconnected with the IoT Reference Architecture as shown
in Figure 3.9. This figure depicts two facets of the IoT ARM:

(a) how to create an IoT ARM actually,

(b) how to use these to building actual systems.

Figure 3.8
 Architecture Reference
Model (ARM)

IoT Reference
Model
understand

guides

steer
Unified IoT Reference
Requirements Architecture

guides with
extrapolate
Best P ractices
Compliant
Business Scenarios, Application define
define Domain-Specific
existing architectures & specific
Architectures
stakeholders Requirements

Steps in order to create an ARM Steps to use an ARM

From reference to concrete architectures and actual system

 Figure 3.9 Iot Reference Model And Reference Architecture Dependencies.

(Figure 3.9) The IoT reference model guides the process of creating an IoT Reference
Architecture because it includes at least the IoT Domain model that impacts several
architecture components.

3.8 VARIOUS ARCHITECTURAL VIEWS

Represent the Reference Architecture as a set of architectural views

• Functional View: Describing what the system does, and also its main functions.
• Information View: Description of the information and data that the system can
handles.
• Deployment and Operational View: Description of the real-world components of the
system like devices, network routers, servers, etc.

3.8.1 Functional view

Figure 8.1 depicts the functional view of the IoT Reference Architecture. It is made up of
Functional Groups (FGs), each of which contains a set of Functional Components (FCs). It's
important to note that not all FCs are used in an IoT architecture.

FIGURE 3.10 Iot Functional View.

 Device and Application functional group
 Device FG
It contains the Sensing, Actuation, Tag, Processing, Storage FCs, and simple components.
These components represent the device resources that are attached to the physical entities.
 Application FG
It includes stand-alone applications for iOS, Android, and Windows Phone, as well as
Business Applications that link the IoT device to an enterprise system.
 Communication functional group
End-to-end connectivity, network communication, and hop-by-hop communication are all
functional elements of the Communication FG.
i) Hop-by-Hop Communication It applies as devices and messages must travel through
the mesh from node to node (hop-by-hop) before they meet a gateway node, which, if
necessary, forwards the message to the Internet. This FC has two main interfaces:
 1.to/from the actual radio on the device one “southbound”, and
 2.to/from the Network FC one “northbound” in the Communication
FG.

ii) Network FC is in charge of message routing and forwarding, as well as the required
translations of identifiers and addresses. If and only if the higher levels above the
networking layer use node or service identifiers, translations have taken place
between MAC and/or physical network identifiers and network layer identifiers
between network layer addresses and high-level human-readable host/node identifiers
between node/service identifiers and network locators
iii) The End-to-End Communication FC is responsible for the end-to-end transport of
application layer messages via various network and MAC/PHY layers.
 IoT Service functional group

The IoT Service FG contains two FCs: The IoT Service FC and the IoT Service Resolution
FC
i) IoT Service FC
This FC is made up of utility implementations that link similar and related
Resources. This FC has Services for a Sensor style Resource that accept requests
from a User and return the Sensor Resource value in a synchronous or
asynchronous manner, such as subscription/notification.
ii) The IoT Service Resolution FC
 This FC includes the functions needed to create an IoT Services directory that allows
for complex control of IoT Service descriptions as well as discovery, lookup, and
resolution of IoT Services through other Active Digital Artifacts.

 Virtual Entity functional group

This FG provides a set of functions that enable users to communicate with physical objects
through the use of Virtual Entity resources.

 Process Management functional group

This FG is responsible for the integration of business processes with IoT-related services.
It consists of two FCs:
 The Process Modelling FC provides the right tools for modeling a business process
that utilizes IoT-related services.
 The Process Execution FC contains the implementation environment for the Method
Modelling FC's process templates, which implements such processes using the
Service Organisation FG to resolve high-level application specifications to particular
IoT resources.

 Service Organization functional group

The Service Composition FC is in charge of managing the descriptions and operation

environment of large systems that are composed of smaller based services. A service that
provides the average of values from many basic Sensor Services is an example of a complex
composed service. The IoT Process Execution FC sends requests to the Service Orchestration
FC, which it handles.
The Service Choreography FC

It is a broker for providing communication among Services using the Publish/Subscribe

pattern. The Choreography FC is subscribed by the users and Services interested in
specific IoT-related services and also facilitating the desirable service attributes even if
the desired services do not exist.
 Security functional group

The Security FG provides critical functions for ensuring an IoT system's security and privacy.
The following FCs are included in it:
The Identity Management FC In an IoT device operated by this FC, the various names of
the involving Services or Users.

The Authentication FC When a User's identity is successfully verified, an assertion is made.

The Authorization FC Access management procedures are managed and enforced. It

enables providers to control regulations, as well as make decisions and compel them to use
limited resource access privileges. In an IoT scheme, Key Exchange & Management helps
you to set up the required security keys for two interacting entities.

The Trust & Reputation FC Manages and measures the provider confidence levels based
on the credit ratings of different participating actors in an IoT environment.

Management functional group

This FG is responsible for the management of the system as a whole. It consists of the
following FCs:
i) The Configuration FC In an IoT environment, this is where the configuration of the
FCs and Devices is held. The part collects and preserves the current configuration of
all FCs and equipment in a historical archive, distinguishing between current and
historical configurations.
ii) The Fault FC Specific part fault detection activates fault analysis and fault recovery
procedures in the Fault FC, which ensures the Fault FC detects, logs, isolates, and
corrects system-wide faults.
iii) The Member FC In an IoT scheme, it handles participation details for the relevant
bodies.
iv) The State FC is similar to Configuration FC in that it gathers and logs state
information from current FCs, which can be used for fault detection, performance
estimation, and forecast, as well as billing.
v) The Reporting FC It is responsible for generating compact reports about the device
state depending on the data.
3.8.2 Information view
The view of the information consists of
(a) The definition of the information handled by the IoT system;
(b) the manner in which the information was handled by the system;
in other words, the information life cycle and flow, such as how the information is produced,
stored, and deleted, and the information handling components.
Information Description

The knowledge that is treated by an IoT method. Virtual entity background information, such
as attributes (simple or complex) represented by sections of the IoT Information model. The
performance of IoT Service itself is another major part of the information provided by the
IoT device. A sensor or a tag service, for example. Descriptions of the virtual entity in
general, which not only include attributes coming from IoT Devices (e.g. ownership
information). Associations of Virtual Entities with other Virtual Entities (e.g., Room #12 is
on Floor #7) The type of resource (e.g. sensor), identity, related Services, and Devices may
all be included in Resource Descriptions. Descriptions of devices, such as their functionality
(e.g. sensors, radios). Composed Service descriptions that follow the model of a complicated
service being made up of simplified services. The phases of a business process using other
IoT-related resources are described by the IoT Business Process Model. Keys, identity pools,
policies, confidence models, credibility ratings, and other security details For
fault/performance purposes, configuration snapshots, reviews, membership records, and so
on, management information such as state information derived from organizational FCs is
used.

Information flow and lifecycle

Figure 3.11 depicts the procedure. Changes in the physical properties of the Physical Entities
of Interest are converted into electrical signals by sensors on the devices. On the unit level,
these electrical signals are converted into one or more values (Figure 3.11a). The metadata
information, such as units of measurement, timestamps, and location information, is then
added to these values (Figure 3.11b). A software feature (Resource) on the computer or on
the network provides these enhanced values. The resource shows that IoT Services are
working hard to formalize access to this enriched data (Figure 3.11c). At this stage, basic
attributes like location and time are used to interpret the data, and this sort of metadata is
always sufficient for some IoT applications or usage in larger systems. As this enhanced
information is further correlated with certain Physical Entities in the form of Virtual Entity
characteristics such as basic or complex, static or dynamic, it becomes background
information. Help information such as associations between certain attributes and IoT
Services adds to the Virtual Entity's context information (Figure 3.11d).
 Figure 3.11

Information handling
The exchange of information between FCs follows the interaction patterns as shown in
Figure 3.12
 A B
A B
Request

Push Response

T ime

(a) (b)

SA SB C SA SC B P

Subscribe Subscribe
Subscribe
Subscribe
Notify Notify
Notify
Publish

Notify

Figure 3.12
• Push: If the contact information for component B is already configured in component
A, an FC (A) will attempt to push information to another FC (B), and component B should
listen for those information pushes.
• Request/Response: FC (A) sends a message to another FC (B), and B responds after
A has served the request. The relationship is generally synchronous since A must wait for
an answer from B before moving on to the next step/task. However, in practice, this
constraint can be achieved by having parts of component A wait while other parts perform
other tasks. Component B could be required to accommodate simultaneous requests and
responses from several modules, putting additional demands on the system or network that
hosts the FC.
Subscribe/Notify:
Multiple subscriber components (SA, SB) will subscribe for information from component
C, and C will alert the relevant subscribers when the requested information is available.
This is usually asynchronous, so after each subscriber receives the content, they can go
 about their business. However, in order to receive the asynchronous answer, a subscriber
must have certain listening components. The state records, such as which subscribers
requested which information and their contact information, must also be maintained by the
aim variable C. The Subscribe/Notify pattern is used where one component is the host of
information required by several other components. The subscribers only need to create a
Subscribe/Notify relationship with one part after that. From the perspective of the
subscribers, the Publish/Subscribe approach is a more flexible option if one or more
components are knowledge sources or hosts.
• Publish/Subscribe: A third party, known as broker B, mediates subscription and
publishing between information consumers (subscribers) and information producers
(Pub/Sub pattern) (publishers). Subscribers such as SA and SB ask the broker about the
information they want to use, and the broker explains the information's various assets. The
broker moves the published content to the subscribers whose needs fit the published
information, and the publisher publishes information and metadata to the broker.

3.8.3 Deployment and operational view

The Deployment and Operational View is determined by the use case and specifications. The
Devices view as Physical Entities installed in the parking lot, as well as the occupancy
symbol, are seen in Figure 3.13. Each of the eight metal/car presence sensors is attached to
one of two sensor nodes (node#1 and node#2). Wireless or wired networking has been used
to link the two sensor nodes to the payment station. The payment station serves as a user
interface for the driver to pay and receive a payment receipt, as well as a networking portal
that uses Wide Area Network (WAN) infrastructure to link the two sensor nodes and the
payment interfaces physical equipment, such as screens, credit card slots, coin/note
input/output, and so on, to the Internet. The occupancy symbol also serves as a contact link

between the actuator node

Mobil

Interne
Senso P ar
r kin
Node g
#2 Op
erat
ion
P ayment
station
WAN link
Short range
 Figure 3.13 Parking Lot Deployments And Operational View, Devices.

and the outside world (display of free parking spots). The physical gateway devices link to
the Internet and a data center through WAN technology, where the parking lot management
system software is hosted as virtual machines. The primary applications connected to this
management system are human user mobile phone applications and parking operation center
applications.

3.9 OTHER RELEVANT ARCHITECTURAL VIEWS

Aside from the functional views, there are a few others that are important for a machine to
have:
 The Physical Entity View
 The Context View.

3.9.1 The Physical Entity View

Describes Physical Entities from the IoT Domain Model in terms of physical properties (e.g.
dimensions for spaces/objects). The relationship between Physical Entities is described in the
classification of Physical Entities (an entity is included in the other and maybe stationary in a
specific location or mobile). A large number of possibilities for Physical Entities cannot be
captured in a Reference Architecture, Even though, an architect requires to outline all the
details of the Physical Entities from the beginning to assess if any Physical Property affects
the rest of the architectural views and models. This view “describes the dependencies,
relationships, and interactions between the system with its environment such as systems,
people, external entities with which it interacts.”

3.9.2 The Context View

It captures external entities interacting with the system, external entity properties, system
impact on its environment, system scope and responsibilities, and so on. Since it establishes
the problem's boundary conditions, this view is often built at the start of the design process,
and the possibilities for external entities and their interactions with an IoT system which vary
depending on the situation. For example, the dimensions of the parking spots will come into a
Physical Entity property, and the fact that there are sixteen parking spots physically placed in
a possibly gated parking lot, the fact that there is an occupancy display near the parking lot on
the roadside, and other details outline both Physical Entity properties as well as relationships
between the system and its environment.

3.10 CONSTRAINTS AFFECTING DESIGN IN IOT WORLD

Real-World Design Constraints

i) Devices and Networks:
with certain functionality suitable to IoT applications the devices that form networks in the
M2M Area Network domain must be selected, or designed, The devices should have an
energy source such as batteries, computational capability like an MCU, suitable
communications interface such as a Radio Frequency Integrated Circuit (RFIC) and front end
RF circuitry, program and data(memory) and sensing or actuation capability. These must be
integrated in this manner so that the functional requirements of the desired application can be
satisfied with additional non-functional requirements.
ii) Functional Requirements:
1. particular sensing and actuating capabilities
2. Sensing principle and data requirements are necessary when applying for real-world
application. in Some cases, continuous sampling of sensing data is required whereas
in other cases sampling after specific intervals is required.
3. The parameters such as higher network throughput, data loss, energy use, etc are
decided based on sensing principles.
iii) Sensing and communications field:
The sensing field is to be responsible for sensing in local areas or distributed sensing. The
distance between sensing points is also a principal factor to be considered. The physical
environment has a suggestion on the communications technologies selected and the reliability
of the system in operation thereafter. Devices should be placed enough closeness to
communicate. suppose if the distance is too great, routing devices may be required to
communicate.
iv) Programming and embedded intelligence:
Devices in the IoT are heterogeneous like various computational architectures, inclusive of
MCUs (8-, 16-,32-bit, ARM, 8051, RISC, Intel, etc.), signal conditioning (e.g.ADC), and
memory (ROM/ RAM, etc.), communications media, peripheral components like sensors,
actuators, buttons, screens, LEDs, etc.
An application programmer always should consider the hardware selected or designed, and
its capabilities.
v) Application-level logic decides:
1. the sampling rate of the sensor,
2. the local processing performed on sensor readings,
3. reporting rate, and the management of the communications protocol stack.The
programmers have to reconfigure and reprogram devices if any change in devices In
IoT applications.
vi) Power:
Power is a vital thing for any embedded or IoT device. Based on the type of
application, power may be provided used from the mains, batteries, or hybrid power
sources. Power requirements of the application are modeled earlier to deployment.
This allows the designer to estimate the maintenance cost over time.
vii) Gateway: Gateway devices or proxies are selected according to the requirement of
data transitions.
viii) Nonfunctional requirements:
The non-functional requirements are technical and non-technical. There are follows
1. Regulations:
• prior permissions are essential for the applications which need placing
nodes in public places.
• Radio Frequency (RF) legislation will limit the amount of power that
transmitters can transmit.
2. Ease of use, installation, maintenance, accessibility: This pertains to unit
positioning, placement, configuration, site surveying, and physical usability for
maintenance.
3. Physical constraints:
 easy Integration of additional electronics into an existing system
 Suitable packaging
 Antenna type and size
 Type of power supply
ix) Financial cost: Financial cost considerations are as follows:
x) Component Selection: Generally, the use of these devices in the M2M Area Network
domain is to decrease the overall cost burden. However, there are research and
 development costs likely to be sustained for individual application in the IoT that
needs device development or integration. Developing small quantities of devices is
expensive.
xi) Integrated Device Design: An integrated computer must be generated after the
storage, sensors, actuators, computing, memory, control, networking, physical, and
other functional and non-functional specifications have been taken into account.
xii) Data representation and visualization: Almost every IoT program has a visually
appealing description of the data and device. The visualization specifications for data
produced by heterogeneous systems are diverse. There are currently no suitable
uniform data representation and storage mechanisms that meet the needs of all
possible IoT applications.

3.11 SUMMARY

The main objective of this chapter is to make us clearly understand the design principles and
needed capabilities of IoT architecture. The outline of the IoT architecture also helps us to
make the right decision in designing and choosing the IoT infrastructure. The standard
considerations are very important in determining this strategy. The concept of the Reference
model and its architecture builds a new era while choosing the architecture. Constraints
affecting the design in IoT aspects are explained here with all the major challenges. We will
discuss Web of Things (WoT) in the next chapter.

3.12 SELF ASSESSMENT QUESTIONS

A. Descriptive questions

Short Questions

1. What is the Internet of Things (IoT)?

2. What are all the components required to design IoT Devices?
3. which device we called IoT devices? Explain with an example?

4. List some international SDOs.

5. Explain different Characteristics of IoT

Long Questions

1. Main design principles and needed capabilities of IoT

 2. Explain the functional layers and capabilities of the IoT solution in detail?
3. Discuss IoT reference Model in IoT
4. Details Various views of IoT Architecture
5. Show how the exchange of information between FCs happened?

B. Multiple Choice Questions

1. In the different levels of abstraction problem Domain located in

a. Lower level

b. Middle level

c. Top level

d. None of the option above

2. Which layer is responsible for providing the critical functionalities of sensing, actuation?

a. Asset Layer

b. Resource Layer

c. Communication Layer

d. Service support Layer

3. W3C stands for

a. World Wide Web Consortium

b. World Wide Web Committee
c. World Wide Web Council
d. World Wide Web Communication

4. Converts physical properties into electrical signals

a. Sensors
b. Actuators
c. Tags
d. Bluetooth
5. The IoT Information Model is represented using

a. Dataflow diagram
b. UML diagram
c. State transition Diagram
d. None of these

6. Description of the information and data that the system can handle refers

a. Functional View
b. Informational view
c. Deployment view
d. Operational view

7. The Functional Component__________is responsible for performing message routing and

forwarding

a. Network FC
b. End-to-End communication FC
c. IoT Service FC
d. Process modeling FC

8. The Service Choreography FC responsible for

a. providing communication among Services using the Publish/Subscribe pattern

b. provides the right tools for modeling a business process
c. creates an assertion upon successful verification of the identity of a User.
d. manages reputation scores of various interacting entities in an IoT system

9. __________regulations can control the power with which transmitters can broadcast.

a. Radio Frequency (RF)

b. Bluetooth
c. NFC
d. RFID
Answers

1-c, 2-a, 3-a, 4-a, 5-b, 6-b, 7-a, 8-a, 9-a,

3.13 SUGGESTED READING

Reference books

 Vijay Madisetti and ArshdeepBahga, “Internet of Things (A Hands-on-Approach)”,

VPT
 Francis daCosta, “Rethinking the Internet of Things: A Scalable Approach to
Connecting Everything”, 1 st Edition, Apress Publications,
 Cuno Pfister, Getting Started with the Internet of Things, O‟Reilly Media, ISBN: 978-
1-4493- 9357-1

Websites:

 https://www.edureka.co/blog/iot-tutorial/
 https://www.guru99.com/iot-tutorial.html
 https://pluto- men.com/insights/everything- you- need-to-know-about-web-of-things/
 https://webofthings.org/2017/04/08/what- is-the-web-of-things/