UNIT III
1. IoT Architecture -State of the Art
1. A reference model is a model that describes the main conceptual entities and how they
are related to each other,
2. reference architecture aims at describing the main functional components of a system as
well as how the system works, how the system is deployed(to be used for a particular
purpose), what information the system processes, etc.
State of the art
• 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.
2. high-level architecture
M2M Device:
• An M2M device connects to the Network Domain either directly or through an M2M
Gateway
• Direct connection:
• The M2M Device is capable of performing registration, authentication,
authorization, management, and provisioning to the Network Domain.
• Direct connection also means that the M2M device contains the appropriate
physical layer to be able to communicate with the Access Network.
M2M Gateway:
• This is the case when the M2M device does not have the appropriate physical layer,
compatible with the Access Network technology, and therefore it needs a network
domain proxy.
• The M2M Gateway acts as a proxy for the Network Domain and performs the
procedures of authentication, authorization, management, and provisioning.
• An M2M Device could connect through multiple M2M Gateways.
M2M Area Network:
• This is typically a local area network (LAN) or a Personal Area Network (PAN) and
• provides connectivity between M2M Devices and M2M Gateways
M2M Gateway:
• The M2M Gateway contains M2M Applications and M2M Service Capabilities.
• The M2M Gateway may also provide services to other legacy devices that are not visible
to the Network Domain.
• The device that provides connectivity for M2M Devices in an M2M Area Network
towards the Network Domain.
Access Network:
• The network that allows the devices in the Device and Gateway Domain to communicate
with the Core Network.
Core Network:
• IP connectivity.
• Service and Network control.
• Interconnection with other networks.
• Roaming.
M2M Service Capabilities:
• Functions use underlying Core Network functions, and their
• objective is to abstract the network functions for simpler applications.
M2M Applications:
• M2M applications (e.g. smart metering) that utilize the M2M Service Capabilities
through the open interfaces.
Network Management Functions:
• functions to manage the Access and Core Network
M2M Management Functions:
• Functions required to manage the M2M Service Capabilities on the Network Domain
• while the management of an M2M Device or Gateway is performed by specific M2M
Service Capabilities.
There are two M2M Management functions:
• M2M Service Bootstrap Function (MSBF):
• The MSBF facilitates the bootstrapping of permanent M2M service layer
security credentials in the M2M Device or
• Gateway and the M2M Service Capabilities in the Network Domain.
• M2M Authentication Server (MAS):
• safe execution environment where permanent security credentials such as
the M2M Root Key are stored.
• Any security credentials established on the M2M Device or Gateway are
stored in a secure environment such as a trusted platform module
3. Architecture Reference Model
4. Reference Model and Architecture
An ARM consists of two main parts:
1. a Reference model and
2. a Reference Architecture.
• A reference model describes the domain using a number of sub-models
5. From Reference to concrete architecture and actual system
6. IOT Reference architecture and reference model dependency
7. IOT Reference Model
IoT domain model
• The domain model captures the basic attributes of the main concepts and the relationship
between these concepts.
• A domain model also serves as a tool for human communication between people
working in the domain in question and between
• people who work across different domains.
IoT Reference Architecture
⚫ The Reference Architecture is a starting point for generating concrete architectures
and actual systems.
⚫ A concrete architecture addresses the concerns of multiple stakeholders of the actual
system, and it is typically presented as a series of views that address different stake-
holder concerns.
⚫ Views are useful for reducing the complexity of the Reference Architecture
blueprints by addressing groups the concerns of one group at a time.
8. Views
⚫ the Reference Architecture is presented as a set of architectural views
⚫ Functional View: Description of what the system does, and its main functions.
⚫ Information View: Description of the data and information that the system handles.
⚫ Deployment and Operational View: Description of the main real world components of
the system such as devices, network routers, servers, etc.
9. IoT Functional View
Device and Application functional group
⚫ Device FG contains the Sensing, Actuation, Tag, Processing, Storage FCs, or simply
components.
⚫ These components represent the resources of the device attached to the Physical
Entities of interest.
⚫ The Application FG contains either standalone applications (e.g. for iOS, Android,
Windows phone), or Business Applications that connect the IoT system to an Enterprise
system.
Communication functional group
⚫ The Communication FG contains the End-to-End Communication, Network
Communication, and Hop- by-Hop communication components:
⚫ The Hop-by-Hop Communication(a principle of controlling the flow of data in a
network) is applicable in the case that devices are equipped with mesh radio
networking technologies such as IEEE 802.15.4 for which messages have to traverse the
mesh from node- to-node (hop-by-hop) until they reach a gateway node which forwards
the message (if needed) further to the Internet.
Network FC
⚫ The Network FC is responsible for message routing & forwarding and the necessary
translations of various identifiers and addresses.
⚫ The translations can be (a) between network layer identifiers to MAC and/or physical
network identifiers,
⚫ (b) between high-level human readable host/node identifiers to network layer addresses
(e.g. Fully Qualified Domain Names (FQDN) to IP addresses, a function implemented
by a Domain Name System (DNS) server),
⚫ (c) translation between node/service identifiers and network locators in case the higher
layers above the networking layer use node or service identifiers that are decoupled
from the node addresses in the network (e.g. Host Identity Protocol)
End to End Communication
⚫ The End-to-End Communication FC is responsible for end-to-end transport of
application layer messages through diverse network and MAC/PHY layers.
⚫ In turn, this means that it may be responsible for end- to-end retransmissions of missing
frames depending on the configuration of the FC.
⚫ For example, if the End-to-End Communication FC is mapped in an actual system to a
component implementing the Transmission Control Protocol (TCP) protocol, reliable
transfer of frames dictates the retransmission of missing frames
Virtual Entity functional group
⚫ The Virtual Entity FG contains functions that support the interactions between Users
and Physical Things through Virtual Entity services.
⚫ An example of such an interaction is the query to an IoT system of the form, “What is
the temperature in the conference room Titan?”
⚫ The Virtual Entity is the conference room “Titan,” and the conference room attribute of
interest is “temperature.”
IoT process management functional group
⚫ The IoT Process Management FG aims at supporting the integration of business
processes with IoT-related services.
⚫ It consists of two FCs:
⚫ The Process Modeling FC provides that right tools for modeling a business process that
utilizes IoT-related services.
⚫ The Process Execution FC contains the execution environment of the process models
created by the Process Modelling FC and executes the created processes by utilizing the
Service Organization FG in order to resolve high-level application requirements to
specific IoT services.
Service Organization functional group
⚫ The Service Composition FC manages the descriptions and execution environment of
complex services consisting of simpler dependent services.
⚫ An example of a complex composed service is a service offering the average of the
values coming from a number of simple Sensor Services.
⚫ The Service Orchestration(a careful arrangement of something to achieve a
particular result,) FC resolves the requests coming from IoT Process Execution FC or
User into the concrete IoT services that fulfil the requirements.
⚫ The Service Choreography FC is a broker for facilitating communication among
Services using the Publish/Subscribe pattern.
Security functional group
⚫ The Security FG contains the necessary functions for ensuring the security and
privacy of an IoT system. It consists of the following FCs:
⚫ The Identity Management FC manages the different identities of the involved Services
or Users in an IoT system in order to achieve anonymity.
⚫ The Authentication FC verifies the identity of a User and creates an assertion upon
successful verification.
⚫ The Authorization FC manages and enforces access control policies. It provides
services to manage policies (CUD), as well as taking decisions and enforcing them
regarding access rights of restricted resources. The term “resource” here is used as a
representation of any item in an IoT system that needs a restricted access.
⚫ Such an item can be a database entry (Passive Digital Artifact), a Service interface, a
Virtual Entity attribute (simple or complex), a Resource/Service/Virtual Entity
description, etc.
⚫ The Key Exchange & Management is used for setting up the necessary security keys
between two communicating entities in an IoT system. This involves a secure key
distribution function between communicating entities.
⚫ The Trust & Reputation( the general belief or opinion) FC manages reputation scores
of different interacting entities in an IoT system and calculates the service trust levels.
Management functional group
⚫ The Management FG contains system-wide management functions that may use
individual FC management interfaces. It is not responsible for the management of each
component, rather for the management of the system as a whole.
It consists of the following FCs:
⚫ The Configuration FC maintains the configuration of the FCs and the Devices in an IoT
system (a
subset of the ones included in the Functional View).
⚫ The component collects the current configuration of all the FCs and devices, stores it in a
historical database, and compares current and historical configurations.
⚫ The component can also set the system-wide configuration (e.g. upon initialization),
which in turn translates to configuration changes to individual FCs and devices.
⚫ The Fault FC detects, logs, isolates, and corrects system-wide faults if possible. This
means that individual component fault reporting triggers fault diagnosis and fault
recovery procedures in the Fault FC.
⚫ The Member FC manages membership information about the relevant entities in an IoT
system. Example relevant entities are the FGs, FCs, Services, Resources, Devices, Users,
and Applications. Membership information is typically stored in a database along with
other useful information such as capabilities, ownership, and access rules & rights,
which are used by the Identity Management and Authorization FCs.
⚫ The State FC is similar to the Configuration FC, and collects and logs state information
from the current FCs, which can be used for fault diagnosis, performance analysis and
prediction, as well as billing purposes. This component can also set the state of the other
FCs based on system-wise state information.
⚫ The Reporting FC is responsible for producing compressed reports about the system
state based on input from FCs.
10. Information view
⚫ The information view consists of
⚫ (a) the description of the information handled in the IoT System, and
⚫ (b) the way this information is handled in the system; in other words, the information
lifecycle and flow (how information is created, processed, and deleted), and the
information handling components.
⚫ The pieces of information handled by an IoT system it can be
⚫ Virtual Entity context information, i.e. the attributes (simple or complex) as represented
by parts of the IoT Information model.
⚫ IoT Service output itself is another important part of information generated by an IoT
system. For example, this is the information generated by interrogating a Sensor or a
Tag Service
Information flow and lifecycle
⚫ On a high level, the flow of information in an IoT system follows two main directions.
⚫ From devices that produce information such as sensors and tags, information follows a
context-enrichment process until it reaches the consumer application or part of the larger
system, and from the application or part of a larger system information it follows a
context- reduction process until it reaches the consumer types of devices.
⚫ Devices equipped with sensors transform changes in the physical properties of the
Physical Entities of Interest into electrical signals.
⚫ These electrical signals are transformed in one or multiple values (Figure 8.2a) on the
device level.
⚫ These values are then enriched with metadata information such as units of measurement,
timestamp, and possibly location information (Figure 8.2b).
⚫ These enriched values are offered by a software component (Resource) either on the
device or the network. The Resource exposes certain IoT Services to formalize access to
this enriched information (Figure 8.2c).
⚫ At this point, the information is annotated with simple attributes such as location and
time, and often this type of metadata is sufficient for certain IoT applications or for the
use in certain larger systems.
⚫ This enriched information becomes context information as soon as it is further associated
with certain Physical Entities in the form of Virtual Entity attributes (simple or complex,
static or dynamic).
⚫ Further support information such as Associations between certain attributes and IoT
Services further enriches the context information of the Virtual Entity (Figure 8.2d)
⚫ enrichment occurs in applications or larger systems that employ,
⚫ for example, data analytics, machine learning, and knowledge management, which
produces actionable information.
Information handling
⚫ An IoT system is typically deployed to monitor and control Physical Entities.
⚫ Monitoring and controlling Physical Entities is in turn performed by mainly the Devices,
Communication, IoT Services, and Virtual Entity FGs in the functional view.
⚫ Push: An FC A pushes the information to another FC B provided that the contact
information of the component B is already configured in component A, and component
B listens for such information pushes.
⚫ Request/Response: An FC A sends a request to another FC B and receives a response
from B after A serves the request
⚫ Subscribe/Notify: Multiple subscriber components (S A , S B ) can subscribe for
information to a component C, and C will notify the relevant subscribers when the
requested information is ready.
⚫ This is typically an asynchronous information request after which each subscriber can
perform other tasks.
⚫ The Subscribe/Notify pattern is applicable when typically one component is the host of
the information needed by multiple other components.
⚫ Publish/Subscribe: In the Publish/Subscribe (also known as a Pub/Sub pattern), there is
a third component called the broker B, which mediates subscription and publications
between subscribers (information consumers) and publishers (or information producers).
⚫ Subscribers such as SA and SB subscribe to the broker about the information they are
interested in by describing the different properties of the information.
Real-World Design Constraints
⚫ 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.
Devices and networks
⚫ devices that form networks in the M2M Area Network domain must be selected, or
designed, with certain functionality in mind.
⚫ At a minimum, they must have an energy source (e.g. batteries, increasingly EH),
computational capability (e.g. an MCU), appropriate communications interface (e.g. a
Radio Frequency Integrated Circuit (RFIC) and front end RF circuitry), memory
(program and data), and sensing (and/or actuation) capability.
_____________________________________________________________________________
11. Deployment and operational view
Above Figure 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.) The occupancy sign also acts as a communication gateway for the actuator node
(display of free parking spots),
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 configuration.
The two main applications connected to this management system are human user mobile
phone applications and parking operation center applications.
We assume that the parking operation center manages several other parking lots using
similar physical and virtual infrastructure. Figure shows two views super imposed, the
deployment and functional views, for the parking lot example Services appear in the
figure because an IoT system is typically part of a larger system.
Starting from the Sensor Devices, as seen earlier, Sensor Node #1 hosts Resource
#11_#18, representing the sensors for the parking spots #01_#08, while earlier Sensor
Node #2 hosts Resource #21_#28, representing the sensors for the parking spots
#09_#16.
We assume that the sensor nodes are powerful enough to host the IoT Services #11_#18
and #21_#28 representing the respective resources.
Functional requirements
⚫ Specific sensing and actuating capabilities are basic functional requirements.
⚫ This is the basis of the application. Sensors, broadly speaking, are difficult to categorize
effectively.
⚫ Selecting a sensor that is capable of detecting a particular phenomenon of interest is
essential. The sensor may directly measure the phenomenon of interest (e.g.
temperature), or may be used to derive data or information about the phenomenon of
interest, based on additional knowledge (e.g. a level of comfort).
Sensing and communications field
⚫ The sensing field is of importance when considering both the phenomenon to be sensed
(i.e. Is it local or distributed?) and the distance between sensing points.
⚫ The physical environment has an implication on the communications technologies
selected and the reliability of the system in operation thereafter.
⚫ Devices must be placed in close enough proximity to communicate.
⚫ Where the distance is too great, routing devices may be necessary.
⚫ Devices may become intermittently disconnected due to the time varying, stochastic
nature of the wireless medium.
Programming and embedded intelligence
⚫ Devices in the IoT are fundamentally heterogeneous.(consisting of different parts or type)
⚫ An application programmer must consider the hardware selected or designed, and its
capabilities.
⚫ The ability to reconfigure and reprogram devices is still an unresolved issue for the
research community in sensor networks, M2M, and the IoT.
Power
⚫ Power is essential for any embedded or IoT device. Depending on the application, power
may be provided by the mains, batteries, or conversion from energy scavengers (often
implemented as hybrid power sources).
