UNIT 2

IoT Architecture
 M2M high-level ETSI architecture
The European Telecommunications Standards Institute (ETSI)

• This high-level architecture is a combination of both a

functional and topological view showing some
functional groups (FG) clearly associated with pieces of
physical infrastructure (e.g. M2M Devices, Gateways).

• There are two main domains, a network domain and a

device and gateway domain.

• The boundary between these conceptually separated

domains is the topological border between the physical
devices and gateways and the physical communication
infrastructure (Access network).
M2M High Level ETSI Architecture
 Device and Gateway Domain
• The Device and Gateway Domain contains the following functional or
topological entities:

 M2M Device:
 This is the device of interest for an M2M scenario, for example, a
device with a temperature sensor.
 An M2M device which can be sensors / smart appliances connects
to the Network Domain either directly or through an M2M Gateway
that collect and send data / perform specific tasks.

 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 device that provides connectivity for M2M

Devices in an M2M Area Network towards the Network Domain.
 Network Domain
• Access Network: This is the network that allows the devices in
the Device and Gateway Domain to communicate with the Core
Network. Example Access Network Technologies are fixed (xDSL,
HFC) and wireless Satellite, GERAN, UTRAN, E-UTRAN W-LAN,
WiMAX).

• Core Network: It manages the data flow and ensures reliable

communication between devices and application. Examples of
Core Networks are 3GPP Core Network and ETSI TISPAN Core
Network. It provides the following functions:
• IP connectivity.
• Service and Network control.
• Interconnection with other networks.
• Roaming.
 M2M Service Capabilities: These are functions
exposed to different M2M Applications through a set
of open interfaces. It provides tools and services that
manage communication, data storage and security for
M2M application.

 M2M Applications: These are the specific M2M

applications (e.g. smart metering) that utilize the
M2M Service Capabilities through the open interfaces.
It process data from M2M devices such as monitoring
applications or automation systems.
 Network Management Functions: These are all the
necessary functions to maintain and manage the Access and
Core Network (e.g. Provisioning ( Setting up & Configuring
network resources(ie., assigning IP address) , Fault
Management ( Identifying and fixing network issues,
Performance Monitoring, Security Management etc.)
effectively.

 M2M Management Functions: These are the necessary

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.
• These are the necessary functions required to manage the M2M
Service Capabilities on the Network Domain.
• 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. It ensures that communication
between M2M Devices / Gateways and M2M Service Capabilities in
the network domain is secure.

• M2M Authentication Server (MAS): This is the safe execution

environment where permanent security credentials such as the
M2M Root Key are stored. It provides authentication services to
verify, identify of M2M Devices, Gateways and Service Capabilities
before allowing communication.
• The most relevant entities in the ETSI M2M
architecture are the M2M Nodes and M2M
Applications.

• An M2M Node can be a Device M2M, Gateway

M2M, or Network M2M Node.

• An M2M Application is the main application logic

that uses the Service Capabilities to achieve the
M2M system requirements.
• The application logic can be deployed on a Device (Device Application, DA),
Gateway (Gateway Application, GA) or Network (Network Application, NA).

• The SCL (Service Capability Layer) is a collection of functions that enables the
M2M application to interact with devices, gateways and networks through the
open interfaces or reference points mIa, dIa, and mId (ETSI M2M TC 2013b).

• Because the main topological entities that SCL can deploy are the Device,
Gateway, and Network Domain, there are three types of SCL:
– DSCL (Device Service Capabilities Layer)
• Resides on device domain.
• Provides functions for M2M devices interact with others.
– GSCL (Gateway Service Capabilities Layer)
• Resides on gateway domain.
• Acts as bridge between multiple devices and network.
– NSCL (Network Service Capabilities Layer).
• Resides on network domain.
• Provides centralized service for applications and gateway.

• SCL functions utilize underlying networking capabilities through technology-

specific interfaces.
– mia (interface between M2M application and SCL)
– dia (interface between M2M devices and SCL)
– mid ( interface between SCLs in different domains)
 IETF architecture for IoT
[Internet Engineering Task Force architecture]

•IETF develops standards and protocols for the Internet of Things (IoT).
•The IETF's IoT architecture includes specifications, working groups, and an
advisory group.
IETF architecture for IoT
[Internet Engineering Task Force architecture]
Specifications
• 6LoWPAN (IPv6 over Low-power WPAN)
• CoRE (Constrained RESTful Environments)
• ROLL (Routing Over Low power and Lossy networks).

• Each set of specifications makes an attempt to address a different part of the communication
stack of a constrained device.

• One layer called Application Support which includes the Presentation and Session Layers
combined. one intermediate layer is introduced: the Adaptation Layer

Adaptation Layer

• It positioned between the Physical/Data Link and the Network Layer and whose main
function is to adapt the Network Layer packets to Phy/Link layer packets among others.

• An example of an adaptation layer is the 6LoWPAN layer designed to adapt IPv6 packets to
IEEE 802.15.4/Bluetooth Low Energy (BLE)/DECT Low Energy packets.
Application Support
• An example of an Application Support Layer is IETF Constrained
Application Protocol (CoAP), which provides reliability and RESTful
operation support to applications; however, it does not describe the
specific names of resources a node should host.

• The IETF CoAP draft specification describes the Transport and

Application Support Layers, which essentially defines the transport
packet formats, reliability support on top of UDP, and a RESTful
application protocol with GET/PUT/POST/DELETE methods similar to
HTTP with CoAP clients operating on CoAP server resources.

• A CoAP server is just a logical protocol entity, and the name “server”
does not necessarily imply that its functionality is deployed on a very
powerful machine; a CoAP server can be hosted on a constrained
device.
Working groups
• CoRE Link Format
• Resource Directory

CoRE Link Format

• The CoRE Link Format specification describes a discovery method for the CoAP
resources of a CoAP server.

• For example, a CoAP client sending a request with the GET method to a specific well
defined server resource (./well-known/core) should receive a response with a list of
CoAP resources and some of their capabilities (e.g. resource type, interface type).

• The CoRE interface specification describes interface types and corresponding

expected behavior of the RESTful methods.

• The IETF stack for IoT does not currently include any specifications that are similar to
the profile specifications of other IoT technologies such as ZigBee

• Profile specification means a document that describes a list of profile names and their
mappings to specific protocol stack behavior, specific information model, and specific
serialization of this information model over the relevant communication medium.
• An example of a profile specification excerpt would mandate that
an exemplary “Temperature” profile:
(a) should support a resource called /temp,
(b) the resource /temp must respond to a GET method request
from a client, and
(c) the response to a GET method request shall be a temperature
value in degrees Celsius formatted as a text string with the format
“,temperature value encoded in a decimal number ._C”

Resource Directory
• A Resource Directory is a CoAP server resource (/rd) that maintains
a list of resources, their corresponding server contact information
(e.g. IP addresses or fully qualified domain name, or FQDN), their
type, interface, and other information similar to the information
that the CoRE Link Format document specifies.
• An RD functions as a meeting point mechanism for CoAP Server resource
descriptions, in other words, for devices to publish the descriptions of the
available resources and for CoAP clients to locate resources that satisfy
certain criteria such as specific resource types. (e.g. temperature sensor
resource type).

• Resource Directory is a meeting point mechanism for CoAP Server resource

descriptions, a Mirror Server is a meeting point mechanism for CoAP Server
resource presentations.

• A Mirror Server is a CoAP Server resource (/ms) that maintains a list of

resources and their cached representations (Figure 6.8b).

• A CoAP Server registers its resources to the Mirror Server, and upon
registration a new mirror server resource is created on the Mirror Server
with a container (mirror representation) for the original server
representation.

• The original CoAP Server updates the mirror representation either

periodically or when the representation changes.
• A CoAP Client that retrieves the mirror representation receives the latest
updated representation from the original CoAP Server. The Mirror Server is
useful when the CoAP Server is not always available for direct access.

• An example of such a CoAP Server is one that resides on a real device

whose communication capabilities are turned off in order to preserve
energy, e.g. batterypowered radio devices whose radio and/or processor
goes to sleep mode.

• Typically, a Mirror Server is hosted on a device or machine that is always

available.

• The IETF CoRE workgroup has included the fundamentals of a mapping

process between HTTP and CoAP in the IETF CoAP specification as well as a
set of guidelines for the interworking between HTTP and CoAP.

• The main is the different transport protocols used by the HTTP and CoAP:
HTTP uses TCP while CoAP uses UDP.
• HTTP Client sends an HTTP request to a CoAP server (Figure 6.9a)
through a Gateway Device hosting an HTTP-CoAP Cross Proxy.

• The Gateway Device connects to the Internet via an Ethernet

cable using a LAN, and on the CoAP side the CoAP server resides
on a Sensor/Actuator (SAN) based on the IEEE 802.15.4 PHY/MAC.

• The HTTP request needs to include two addresses, one for

reaching the Cross Proxy and one for reaching the specific CoAP
Server in the SAN.

• The request is in plain text format and contains the method

(GET). It traverses the IPv4 stack of the client, reaches the
gateway, traverses the IPv4 stack of the gateway and reaches the
Cross proxy
• The request is translated to a CoAP request (binary format)
with a destination CoAP resource
coap://s.coap.example.com/foo, and it is dispatched in the
CoAP stack of the gateway, which sends it over the SAN to
the end device.

• A response is sent from the end device and follows the

reverse path in the SAN in order to reach the gateway

• The Cross proxy translates the CoAP response code to the

corresponding HTTP code, transforms the included media,
creates the HTTP response, and dispatches it to the HTTP
client.
 OGC Architecture
Open Geospatial Consortium architecture
• The Open Geospatial Consortium (OGC 2013) is an international
industry 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.

• OGC includes, among other working groups, the Sensor Web

Enablement (SWE) (OGC SWE 2013) domain working group, which
develops standards for:

• sensor system models (e.g. Sensor Model Language, or

SensorML)
• sensor information models (Observations & Measurements,
or O&M)
• sensor services that follow the Service-Oriented
Architecture (SOA) paradigm
• Sensor System Models
These describe the structure and behavior of sensors.

• Sensor Information Models

These define how sensor observations and
measurements are structured.

• Sensor Services (SOA-based)

Sensor services allow interaction with sensors over a
network using Service-Oriented Architecture
(SOA).
 +
• 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.

OGC SWE includes the following standards:

 SensorML and Transducer Model Language (TML),
 Observations and Measurements (O&M)
 SWE Common Data model
 Sensor Observation Service (SOS)
 Sensor Planning Service (SPS)
 PUCK
• SensorML and Transducer Model Language (TML), which include a model and an XML
schema for describing sensor and actuator systems and processes; for example, a system
that contains a temperature sensor measuring temperature in Celsius, which also involves
a process for converting this measurement to a measurement with Fahrenheit units.

• Observations and Measurements (O&M), which is a model and an XML schema for
describing the observations and measurements for a sensor (Observations and
Measurements, O&M).

• SWE Common Data model: for describing low-level data models (e.g. serialization in
XML) in the messages exchanged between OGC SWE functional entities.

• Sensor Observation Service (SOS), which is a service for requesting, filtering, and
retrieving observations and sensor system information.

• Sensor Planning Service (SPS), which is a service for applications requesting a user-
defined sensor observations and measurements acquisition.

• PUCK, which defines a protocol for retrieving sensor metadata for serial port (RS232) or
Ethernet-enabled sensor devices.
• OGC follows the SOA paradigm, there is a registry (CAT) that maintains the
descriptions of the existing OGC services, including the Sensor Observation
and Sensor Planning Services.

• Upon installation the sensor system using the PUCK protocol retrieves the
SensorML description of sensors and processes, and registers them with
the Catalog so as to enable the discovery of the sensors and processes by
client applications.

• The Sensor System also registers to the SOS and the SOS registers to the
Catalog.

• A client application #1 requests from the Sensor Planning Service that the
Sensor System be tasked to sample its sensors every 10 seconds and
publish the measurements using O&M and the SWE Common Data model
to the SOS.
• Another client application #2 looks up the Catalog, aiming at locating an
SOS for retrieving the measurements from the Sensor System.

• The application receives the contact information of the SOS and requests
from the sensor observations from the specific sensor system from the
SOS.

• As a response, the measurements from the sensor system using O&M and
the SWE Common Data model are dispatched to the client application #2.

• The main objective of the OGC standards is to enable data, information,

and service interoperability.
 IOT Reference Model
• The IoT Reference Model aims at establishing a common grounding and a
common language for IoT architectures and IoT systems.

• A reference model describes the domain using a number of sub-models (Figure

7.1).

domain model
• The domain model of an architecture model captures the main concepts or
entities in the domain, the domain model adds descriptions about the
relationship between the concepts.

information model
• These concepts and relationships serve the basis for the development of an
information model because a working system needs to capture and process
information about its main entities and their interactions.

functional model
• A working system that captures and operates on the domain and information
model contains concepts and entities of its own, and these need to be described
in a separate model, the functional model.
• An M2M and IoT system contain communicating entities, and therefore the
corresponding communication model needs to capture the communication
interactions of these entities.

• The foundation of the IoT Reference Model is the IoT Domain Model, which
introduces the main concepts of the Internet of Things like Devices, IoT
Services and Virtual Entities (VE), and it also introduces relations between
these concepts.

• Based on the IoT Domain Model, the IoT Information Model has been
developed. It defines the structure (e.g. relations, attributes) of IoT related
information in an IoT system on a conceptual level without discussing how
it would be represented.

• The information pertaining to those concepts of the IoT Domain Model is

modelled, which is explicitly gathered, stored and processed in an IoT
system, e.g. information about Devices, IoT Services and Virtual Entities.
Functional Model

• The IoT Functional Model identifies groups of functionalities, of

which most are grounded in key concepts of the IoT Domain Model.

• A number of these Functionality Groups (FG) build on each other,

following the relations identified in the IoT Domain Model.

• The Functionality Groups provide the functionalities for interacting

with the instances of these concepts or managing the information
related to the concepts, e.g. information about Virtual Entities or
descriptions of IoT Services.

• The functionalities of the FGs that manage information use the IoT
Information Model as the basis for structuring their information.
• A key functionality in any distributed computer system is the
communication between the different components.

• The IoT Communication Model introduces concepts for

handling the complexity of communication in heterogeneous
IoT environments. Communication also constitutes one FG in
the IoT Functional Model.

How It Works Together:

• The IoT Domain Model provides the basic concepts.
• The IoT Information Model manages data related to those concepts.
• The IoT Functional Model defines how functionalities operate based on the
concepts.
• The IoT Communication Model ensures data is transferred efficiently.
 IoT Domain Model

• An IoT domain model is a way to describe and organize

important concepts in the Internet of Things (IoT).

• It defines:
• Key concepts (e.g., sensors, devices, users, services).
• Basic attributes (e.g., name, identifier).
• Relationships between concepts (e.g., "Services expose
Resources").
• Data exchange rules for smooth interaction across systems.

• Its main goal is to create a shared understanding of

how IoT systems work.
• Model Notation and Semantics
– To visualize the domain model, we use class diagrams,
which consist of:
• Classes (boxes representing concepts like "Sensor" or
"Service").
• Attributes (details inside the boxes, like sensor type).
• Relationships (lines or arrows showing how classes interact).

– Common relationships in IoT models:

1. Generalization ("is-a" relationship) → A subclass
inherits properties from a parent class. (e.g., a
Temperature Sensor “is-a” Sensor).
2. Aggregation ("has-a" relationship) → (e.g., a parking
lot "has-a" payment station).
3. Composition → (e.g., if a car is removed, its parking
ticket also vanishes).
4. Association →. (e.g., a user "uses" a parking app).
5. Realization → One class provides functionality defined by
another. (e.g., a service "implements" a specific function).
• Class diagrams are used to represent relationships between
different classes in a IoT system.
• Generalization (or "is-a" Relationship)
– A subclass inherits properties from a parent class.
• A solid line with a hollow triangle pointing towards the parent class.
• It represents inheritance, where Class B is a specialized version
(subclass) of Class A (superclass).
• Example: If Class A = Vehicle and Class B = Car, then Car "is-a" Vehicle.

• Aggregation ("has-a" Relationship – Whole-Part Relationship)

– One class contains another but they can exist separately.
• A line with a hollow diamond at one end.
• It shows a whole-part relationship where Class A contains objects of
Class B, but Class B can exist independently of Class A.
• Example: A Library (Class A) has Books (Class B), but Books can exist
without a Library.
• Composition (Strong Whole-Part Relationship)
– One object depends on another. If the whole is deleted,
the part disappears too.
• A line with a solid black diamond at one end.
• A stronger whole-part relationship than aggregation, meaning Class B
cannot exist without Class A.
• Example: A House (Class A) contains Rooms (Class B). If the House is
destroyed, the Rooms also cease to exist.

• Association (Basic Relationship Between Two Classes)

-Simple connection between classes
• A plain line connecting two classes.
• Represents a generic relationship where Class A is related to Class B.
• Example: A Student (Class A) is enrolled in a Course (Class B).
• Directed Association (Navigable Relationship)
• A line with an arrowhead pointing towards the associated class.
• The arrow shows which direction the relationship is navigable.
• Example: A Customer (Class A) places Orders (Class B), meaning
Orders can be traced back to Customers, but not necessarily the
other way around.

• Reflexive Directed Association

• A line with an arrowhead starting and ending at the same class.
• Indicates that objects of a class can be associated with other
objects of the same class.
• Example: A Person (Class A) can be a friend of another Person
(Class A).
• Reflexive Aggregation
• A hollow diamond pointing back to the same class.
• A class contains objects of the same class.
• Example: A Company (Class A) has multiple
Departments (Class A).

• Realization (Implementation Relationship)

• A dashed line with a hollow triangle pointing towards
the class that defines the functionality.
• It indicates that Class B implements the behavior
specified by Class A.
• Example: An Interface (Class A) is implemented by a
Concrete Class (Class B).
• Multiplicity (Cardinality in Associations)
• Numbers or ranges (e.g., 1, 0..1, 1..*) near the ends of
association lines.
• Defines how many instances of one class relate to instances
of another class.
• Multiplicity helps define how many objects are related
between classes.
• Example: In Figure 7.4:
• “1” means exactly one instance.
• “0..” or “” means zero or more instances.
• “1..*” means at least one instance.
• A Student (1) is enrolled in multiple Courses (*).
Physical World vs. Digital World
• Physical World vs. Digital World
Representation
• Physical World: The actual parking lot with
physical parking spots, cars, payment stations,
and an availability sign.
• Digital World: The virtual counterpart where each
parking spot, availability sign, and payment
station is represented digitally as variables,
database entries, or counters.
• IoT-enabled Smart Parking System
• The parking lot with 16 parking spots is monitored using
IoT devices that translate physical state changes into
digital updates.
• Key Components:
1. Parking Spots (Physical) → Virtual Parking Spot (Digital)
1. Each parking spot in the physical world is mapped to a digital
variable that holds a binary value:
1. "Available" (spot is free)
2. "Occupied" (spot is taken)
2. Availability Sign (Physical) → Real-Time Updates
(Digital)
• The electronic road sign shows real-time empty spot
count, which is updated based on sensor data.
3. Payment Station (Physical) → Digital
Verification (Digital)
1.The payment system checks whether the driver
has paid, linking the physical act of payment to a
digital transaction record.
Mobile Application for Users
2.Frequent customers use a smartphone app that
provides real-time parking spot availability before
they arrive.
3.This demonstrates how users can interact with
digital representations of physical objects
remotely.
IoT Domain Model and Interaction
Key Concepts in IoT
• Physical Entity:
• The real-world object (e.g., parking spot, car, availability sign).
• Virtual Entity:
• A Virtual Entity can be a database entry, a geographical model
(mainly for places), an image or avatar, or any other Digital
Artifact.
• The digital representation of the physical entity (e.g., a
database entry for each parking spot).
• Synchronization: The digital representation must always
reflect the real-world status in real time.
• Types of IoT Devices
1. Sensors (Data Collection)
– These are simple or complex Devices that typically involve a transducer that converts
physical properties such as temperature into electrical signals.
– These Devices include the necessary conversion of analog electrical signals into
digital signals, e.g. A video camera can be example of a complex sensor that could
detect and recognize people.
– Example: Cameras, infrared sensors, or weight sensors.
2. Actuators (Action Execution)
– These are also simple or complex Devices that involve a transducer that converts
electrical signals to a change in a physical property (e.g. turn on a switch or move a
motor).
– These Devices also include potential communication capabilities, storage of
intermediate commands, processing, and conversion of digital signals to analog
electrical signals.
– Example: Changing the availability sign dynamically.
3. Tags (Identification)
– Tags in general identify the Physical Entity that they are attached to.
– Example: RFID tags for automatic payment processing and QR Code.
• Resources are software components that provide data for,
or are endpoints for, controlling Physical Entities.
• Resources can be of two types, on-Device resources and
Network Resources.
• Resources are of two types:
– An on-Device Resource is typically hosted on the Device itself
and provides information, or is the control point for the Physical
Entities that the Device itself is attached to. On-Device resources
like sensor data retrieval or actuator to control the digital or
physical world, storage with limited capacity.
– The Network Resources are software components hosted
somewhere in the network or cloud. Network Resources
like services on cloud to perform large data
processing like data aggregation, computation or
storage in cloud.
• Resources can be of several types:
– sensor resources that provide sensor data,
– actuator resources that provide actuation
capabilities or actuator state (e.g. “on”/“off”),
– processing resources that get sensor data as input
and provide processed data as output,
– storage resources that store data related to Physical
Entities, and
– tag resources that provide identification data of
Physical Entities.
 IoT Service Levels
• IoT Services can be classified into three main classes according to their level of
abstraction:

1. Resource-Level Services typically expose the functionality of a Device by

exposing the on-Device Resources. Handle low-level hardware interactions (e.g.,
parking sensors detecting an empty spot).

2. Virtual Entity-Level Services provide information or interaction capabilities

about Virtual Entities, and as a result the Service interfaces typically include an
identity of the Virtual Entity. (e.g., checking parking availability in the mobile app).

3. Integrated Services are the compositions of Resource-Level and Virtual Entity-

Level services, or any combination of both service classes. (e.g., integrating
payment verification with parking availability).
 Identification of Physical Entities in IoT
• For a User (driver or parking system administrator) to interact
with the physical world through the digital system, each
Physical Entity (e.g., parking spots, vehicles, payment
stations) must have a unique identification.
• Types of Identification in IoT:
(a) primary identification that uses natural features of a
Physical Entity, and
(b) secondary identification when using tags or labels
attached to the Physical Entity
 Communication model
• The IoT Communication Model explains how
different parts of an IoT system communicate
with each other. It helps identify:

1. Identifying Communication Endpoints

2. Who are the Communication Endpoints?
3. Communication Between Users, Services,
and Devices
4. Role of Gateways in IoT Communication
5. Moving Services & Resources to the
Cloud
1. Identifying Communication Endpoints
The communication model for an IoT Reference Model consists of the
identification of the endpoints of interactions, traffic patterns (e.g. unicast vs.
multicast), and general properties of the underlying technologies used for
enabling such interactions.

• The IoT communication model helps define who communicates with

whom and how data flows between them.
• It also looks at how messages are sent:
– Unicast (one device to one service, e.g., a smartwatch sending heart
rate data to a phone).
– Multicast (one device to multiple services, e.g., a security camera
streaming footage to multiple viewers).

• It is used to identify the endpoints of the communication paths

• Endpoints are the start and end points of communication.
• Example: A smart thermostat (Device) communicates with a cloud-based
weather service (Service).
2. Who Are the Communication Endpoints?

The potential communicating endpoints or entities are the

Users, Resources, and Devices from the IoT Domain Model

Users include Human Users and Active Digital Artifacts

(Services, internal system components, external applications).
Resources include data, services and capability of those
devices.
Devices include sensors, actuators and other connected
hardwares.

Devices with a Human-Machine Interface mediate the

interactions between a Human User and the physical world
(e.g. keyboards, mice, pens, touch screens, buttons,
microphones, cameras, eye tracking, and brain wave
interfaces, etc.), and therefore the Human User is not a
communication model endpoint.
• 3. Communication Between Users,
Services, and Devices

• The User (Active Digital Artifact, Service)-to-

Service interactions include the User-to-Service
and Service-to-Service interactions as well as the
Service-Resource-Device interactions.

• The User-to-Service and Service-to-Service

communication is typically based on Internet
protocols and one or both Services are hosted in
Service-to-Service interactions on
constrained/low-end Devices such as embedded
systems.
4. Role of Gateways in IoT
Communication
The communication model for these
interactions includes several types of
gateways (e.g., network, application layer
gateways) to bridge between two or more
disparate communication technologies.

The Devices may be so constrained that

they cannot host the Services, while the
Resources could be hosted or not
depending on the Device capabilities
5. Moving Services & Resources to the
Cloud
This inability of the Device to host Resources
or Services results in moving the
corresponding Resources and/or Services out
of the Device and into more powerful
Devices or machines in the cloud