Tybscitsem 5 Archofiotunit 123

UNIT 1
IoT An Architectural Overview
1.1 Building an architecture
o architecture refers to the description of the main conceptual elements, the actual elements
of a target system, how they relate to each other, and principles for the design of the
architecture.
o A conceptual element refers to an intended function, a piece of data, or a service. An actual
element, meanwhile, refers to a technology building block or a protocol.
o The term “reference architecture” relates to a generalized model that contains the richest
set of elements and relations that are of relevance to the domain “Internet of Things.”
o The applied architecture is then the blueprint used to develop the actual system solution
o An architecture can be described in several different views to capture specific properties

that are of relevance to model, and the views chosen.
o functional view, deployment view, process view, and information view.
o The problem domain establishes the foundation for the subsequent solutions. It is common
to partition the architecture work and solution work into two domains, each focusing on
specific issues of relevance at the different levels of abstraction
o The top level of the triangle is referred to here as the “problem domain” (“domain model”
in software engineering).
o These constraints can be technical, like limited power availability in wireless sensor nodes,
or non-technical, like constraints coming from legislation or business.
o The lower level is referred to as the solution domain. This is where design objectives and
principles are established, conceptual views are refined, required functions are identified,
and where logical partitions of functionality and information are described.
o Often this is where a logical architecture is defined, or network architecture in the form of a
network topology diagram is produced.
WE-IT TUTORIALS CLASSES FOR BSC-IT AND BSC-CS (THANE) 8097071144/55, WEB www.weit.in
1
munotes.in
TYBSC-CS SEM 5 (ARCHITECTING OF IOT) 2018-19 NOTES
FOR PROGRAMS AND SOLUTION REFER CLASSROOM NOTES
1.2 Main design principles and needed capabilities
Within existing work for deriving requirements and creating architectures or reference models for
IoT and M2M
three primary sources can been identified.

• Two of them are the larger European 7th Framework Program research projects, SENSEI
(2013) and IoT-A (2013),
o approach taken in SENSEI was to develop an architecture and technology building
blocks that enable a “Real World integration in a future Internet.”
• the third being the result of a standardization activity driven by ETSI in their Technical
Committee (TC) M2M (ETSI M2M TC 2013).
• These sources have been selected, as they represent state-of-the-art in terms of creating
more complete architectures for the IoT and M2M.
overall IoT architecture objective
• The overall design objective of IoT architecture shall be to target a horizontal system of
real-world services that are open, service-oriented, secure, and offer trust.
• Design for reuse of deployed IoT resources across application domains Design for a set of
support services that provide open service-oriented capabilities and can be used for
application development and execution.
• Furthermore, well-defined service interfaces and application programming interfaces
(APIs) are required to facilitate application development, as are the appropriate Software
Development Kits (SDK).
• Design for different abstraction levels that hide underlying complexities and
heterogeneities.
o The first thing that needs to be provided is a set of mechanisms that ensure security
and trust.
o Authentication and authorization of access to use services as well as to be able to
provide services is then a second requirement.
o The third requirement is the capability to be able to do auditing and to provide
accountability so that stakeholders can enforce liability if the need occurs.
• Design for ensuring trust, security, and privacy.
• Design for scalability, performance, and effectiveness.
• Design for evolvability, heterogeneity, and simplicity of integration.
• Design for simplicity of management.
o Autoconfiguration and autoprovisioning are key and well-known means that can
ease deployment of IoT devices, and are also very important to lower operating
expenditures (OPEX).
• Design for different service delivery models.
o Cloud and virtualization technologies play a key enabler role in delivering future IoT
services.
• Design for lifecycle support
o The lifecycle phases are: planning, development, deployment, and execution.
Management aspects include deployment efficiency, design time tools, and run-time
management.
2
munotes.in
1.3 An IoT architecture outline
Functional layers and capabilities of an IoT solution

Asset layer
• This layer is, strictly speaking, not providing any functionality within a target solution, but
represents the reason for any IoT application.
• Assets are instrumented with embedded technologies that bridge the digital realm with the
physical world, and that provide the capabilities to monitor and control the assets as well as
providing identities to the assets.
Resource Layer
• provides the main functional capabilities of sensing, actuation, and embedded identities.
Sensors and actuators in various devices that may be smartphones or Wireless Sensor
Actuator Networks (WSANs), M2M devices like smart meters, or other sensor/actuator
nodes, deliver these functions.
Communication Layer
• Communication Layer is to provide the means for connectivity between the resources on
one end and the different computing infrastructures that host and execute service support
logic and application logic on the other end.
Service Support Layer
• IoT applications benefit from simplification by relying on support services that perform
common and routine tasks
• can provide uniform handling of the underlying devices and networks, thus hiding
complexities in the communications and resource layers.
Data and Information Layer
• provides a more abstract set of functions as its main purposes are to capture knowledge and
provide advanced control logic support.
• Key concepts here include data and information models and knowledge representation in
general, and the focus is on the organization of information.
Application Layer
• There is an open-ended array of different applications, and typical examples include smart
metering in the Smart Grid, vehicle tracking, building automation, or participatory sensing
(PS).
Business Layer
• focuses on supporting the core business or operations of any enterprise, organization, or
individual that is interested in IoT applications.
• This is where any integration of the IoT applications into business processes and enterprise
systems takes place.
3
munotes.in
In addition to the functional layers, three functional groups cross the different layers, namely
Management, Security, and IoT Data and Services.
• Management, as the name implies, deals with management of various parts of the system
solution related to its operation, maintenance, administration, and provisioning.
• Security is about protection of the system, its information and services, from external
threats or any other harm.
• Data and Service processing can, from a topological perspective, be done in a very
distributed fashion and at different levels of complexity.
1.4 Standards considerations

The primary objective of any technology oriented standardization activity is to provide a set of
agreed-upon specifications that typically address issues like achieving interoperability in a market
with many actors and suppliers.
first consideration is that standards are developed across a number of different industries. There
are a number of standardization organizations and bodies, both proper Standards Development
Organizations (SDO) as well as special interest groups and alliances that develop standards
specifications.
• Different national and international bodies ratify standards by SDOs, whereas standard
specifications developed by special interest groups and alliances are normally agreed-upon
and adopted by market actors such as technology manufacturers.
second consideration is that some standardization activities define entire systems or parts of
systems, and other standards organizations target development of specific pieces of technologies,
for instance, specific protocols.
• System standards can address a 3G mobile communication network as defined within the
3rd Generation Partnership Project (3GPP) or standards towards the Smart Grid as done by
the National Institute of Standards and Technology (NIST).
third and final consideration is about the lifecycle process of standards. Many times, standards are
emerging as a result of collaborative research involving both academia and industry.
• Full forms
o Standards Development Organizations (SDO)
o International Telecommunications Union (ITU)
o International Organization for Standardization (ISO)
o European Telecommunications Standards Institute (ETSI)
o European Committee for Electrotechnical Standardization (CENELEC)
o World Wide Web Consortium (W3C)
o Internet Engineering Task Force (IETF)
o Information and Communications Technology (ICT)
o 3rd Generation Partnership Project (3GPP)
o National Institute of Standards and Technology (NIST)
o Request For Comments (RFC)
4
munotes.in
Architecture-State of the Art

2.1 Introduction
describe a combination of a reference model and a reference architecture. A reference model is
a model that describes the main conceptual entities and how they are related to each other,
while the reference architecture aims at describing the main functional components of a system
as well as how the system works, how the system is deployed, what information the system
processes, etc.
2.2 State of the art
The M2M system architectures are naturally more communication-oriented, while the IoT-
related reference architectures and models are more holistic in their scope.
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 endto- end viewpoint.
The technical committee consisted of representatives from telecom network operators,

equipment vendors, administrations, research bodies, and specialist companies.
ETSI M2M high-level architecture

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) while other functional groups lack specific topological placement.
5
munotes.in
There are two main domains, a network domain and a device and gateway domain.
ETSI M2M High-Level Architecture
The Device and Gateway Domain contains the following functional/topological entities:
• M2M Device: This is the device of interest for an M2M scenario, for example, a
device with a temperature sensor.
• 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.
The Network Domain contains the following functional/topological entities:

• Access Network: this is the network that allows the devices in the Device and
Gateway Domain to communicate with the Core Network.
• Core Network: ( IP connectivity, Roaming.)
• M2M Service Capabilities: These are functions exposed to different M2M
Applications through a set of open interfaces.
• M2M Applications: These are the specific M2M applications (e.g. smart
metering) that utilize the M2M Service Capabilities through the open
interfaces.
• Network Management Functions: These are all the necessary functions to
manage the Access and Core Network (e.g. Provisioning, Fault Management,
etc.).
• M2M Management Functions: These are the necessary functions required to
manage the M2M Service Capabilities on the Network Domain while the
6
munotes.in
management of an M2M Device or Gateway is performed by specific M2M

Service Capabilities.
The SCL is a collection of functions that are exposed 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:
1. DSCL (Device Service Capabilities Layer),
2. GSCL (Gateway Service Capabilities Layer), and
3. NSCL (Network Service Capabilities Layer).
ETSI M2M service capabilities

All the possible Service Capabilities (where “x” is N(etwork), G(ateway), and D(evice))
1. Application Enablement (xAE). The xAE service capability is an application facing

functionality and typically provides the implementation of the respective interface
• NAE implements the mIa Interface
• GAE and DAE implement the dIa interface
2. Generic Communication (xGC). The NGC is the single point of contact for
communication towards the GSCL and DSCL. It provides transport session
establishment and negotiation of security mechanisms, potentially secure
transmission of messages, and reporting of errors such as transmission errors.
7
munotes.in
3. Reachability, Addressing, and Repository (xRAR). This is one of the main service
capabilities of the ETSI M2M architecture. The NRAR hosts mappings of M2M Device
and Gateway names to reachability information (routable address information such
as IP address and reachability status of the device such as up or down), and
scheduling information relating to reachability, such as whether an M2M Device is
reachable between 10 and 11 o’clock.
4. Communication Selection (xCS): This capability allows each xSCL to select the best
possible communication network when there is more than one choice or when the
current choice becomes unavailable due to communication errors.
5. Remote Entity Management (xREM). The NREM provides management capabilities
such as Configuration Management (CM) for M2M Devices and Gateways (e.g.
installs management objects in device and gateways), collects performance
management (PM) and Fault Management (FM) data and provides them to NAs or
M2M Management Functions, performs device management to M2M Devices and
Gateways such as firmware and software (application, SCL software) updates, device
configuration, and M2M Area Network configuration.
6. SECurity (xSEC). These capabilities provide security mechanisms such as M2M
Service Bootstrap, key management, mutual authentication, and key agreement
(NSEC performs mutual authentication and key agreement while the GSEC and DESC
initiate the procedures), and potential platform integrity mechanisms.
7. History and Data Retention (xHDR). The xHDR capabilities are optional capabilities,
in other words, they are deployed when required by operator policies. These
capabilities provide data retention support to other xSCL capabilities (which data to
retain) as well as messages exchanged over the respective reference points.
8. Transaction Management (xTM). This set of capabilities is optional and provides
support for atomic transactions of multiple operations. An atomic transaction
involves three steps: (a) propagation of a request to a number of recipients, (b)
collection of responses, and (c) commitment or roll back whether all the
transactions successfully completed or not.
9. Compensation Broker (xCB). This capability is optional and provides support for
brokering M2M-related requests and compensation between a Customer and a
Service Provider.
10. Telco Operator Exposure (NTOE). This is also an optional capability and provides
exposure of the Core Network service offered by a Telecom Network Operator.
11. Interworking Proxy (xIP). This capability is an optional capability and provides
mechanisms for connecting non-ETSI M2M Devices and Gateways to ETSI SCLs.
ETSI M2M interfaces

The main interfaces mIa, dIa, and mId
• mIa: This is the interface between a Network Application and the Network Service
Capabilities Layer (NSCL).
• dIa: This is the interface between a Device Application and (D/G)SCL or a Gateway
Application and the GSCL.
• mId: This is the interface between the Network Service Capabilities Layer (NSCL) and the
GSCL or the DSCL.
ETSI M2M resource management

8
munotes.in
• The ETSI M2M architecture assumes that applications (DA, GA, NA) exchange
information with SCLs by performing CRUD (Create, Read, Update, Delete) operations
on a number of Resources following the RESTful (Representational State Transfer)
architecture paradigm.
• In addition to the CRUD operations, ETSI M2M defines two more operations: NOTIFY
and EXECUTE. The NOTIFY
International Telecommunication Union - Telecommunication sector view

• The ITU-T IoT domain model includes a set of physical devices that connect directly or
through gateway devices to a communication network that allows them to exchange
information with other devices, services, and applications.
• The devices in this model include mandatory communication capabilities and optional
sensing, actuation, and processing capabilities in order to capture and transport information
about the things.
o Application Layer the ITU-T IoT model considers this layer as the host of specific IoT
applications (e.g. remote patient monitoring).
o The Service & Application Support Layer (otherwise known as Service Support and
Application Support Layer) consists of generic service capabilities used by all IoT
applications, such as data processing and data storage, and specific service
capabilities tailored to specific application domains, such as e-health or telematics.
o The Network Layer provides networking capabilities such as Mobility Management,
Authentication, Authorization, and Accounting (AAA), and Transport Capabilities
such as connectivity for IoT service data.
o The Device Capabilities include, among others, the direct device interaction with
the communication network and therefore the Network Layer Capabilities, the
indirect interaction with the Network Layer Capabilities through Gateway Devices,
any ad hoc networking capabilities, as well as low-power operation capabilities (e.g.
capability to sleep and wakeup) that affect communications.
9
munotes.in
Internet Engineering Task Force architecture fragments

6LoWPAN (IPv6 over Low-power WPAN), CoRE (Constrained RESTful Environments), and
ROLL (Routing Over Low power and Lossy networks).
a different part of the communication stack of a constrained device.
• modified Open Systems Interconnection (OSI) model

• 6LoWPAN layer designed to adapt IPv6 packets to IEEE 8021.5.4/Bluetooth Low Energy
(BLE)/DECT Low Energy packets.
• 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.
• 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.
Open Geospatial Consortium architecture

The Open Geospatial Consortium (OGC 2013) is an international industry consortium of
a few hundred companies, government agencies, and universities that develops publicly
available standards that provide geographical information support to the Web, and
wireless and location-based services.
10
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), and sensor services that follow the Service-Oriented
Architecture (SOA) paradigm, as is the case for all OGC-standardized services.
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), which include a model
and an XML schema for describing sensor and actuator systems and
processes
▪ 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.
2.3 IoT reference Model

An ARM consists of two main parts:
• a Reference model and
• a Reference Architecture.
A reference model describes the domain using a number of sub-models.

• The domain model of an architecture model captures the main concepts or entities in the
domain in question, in this case M2M and IoT.
• common language references are established, the domain model adds descriptions about
the relationship between the concepts.
• 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.
• 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.
11
munotes.in
• An M2M and IoT system contain communicating entities, and therefore the corresponding
communication model needs to capture the communication interactions of these entities.
main component of an ARM is the Reference Architecture.

• A System Architecture is a communication tool for different stakeholders of the system.
• describing an architecture for M2M and IoT systems involves the presentation of the
multiple facets of the systems in order to satisfy the different stakeholders.
• The high-level abstraction is called Reference Architecture as it serves as a reference for
generating concrete architectures and actual systems
• A concrete architecture can be further elaborated and mapped into real world
components by designing, building, engineering, and testing the different components of
the actual system.
From reference to concrete architectures and actual systems.
12
munotes.in
IoT Reference Model.
2.4 IoT reference model

2.4.1 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.
Model notation and semantics

• use the Unified Modeling Language (UML) (OMG 2013, NoMagic 2013)
Class diagrams in order to present the relationships between the main
concepts of the IoT domain model.
Main concepts
• The IoT is a support infrastructure for enabling objects and places in the
physical world to have a corresponding representation in the digital
world.
• The reason why we would like to represent the physical world in the
digital world is to remotely monitor and interact with the physical world
using software.
• In the digital world, a parking spot is a variable with a binary value
(“available” or “occupied”). The parking lot payment station also needs
to be represented in the digital world in order to check if a recently
parked car owner actually paid the parking fee.
For the IoT Domain Model, three kinds of Device types are the most
important:
13
• Sensors: These are simple or complex Devices that typically involve a

transducer that converts physical properties such as temperature into
electrical signals.
• Actuators: 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).
• Tags: Tags in general identify the Physical Entity that they are attached
to. In reality, tags can be Devices or Physical Entities but not both, as the
domain model shows. An example of a Tag as a Device is a Radio
Frequency Identification (RFID)
It is important to note that IoT Services can be classified into three main classes
according to their level of abstraction:
• Resource-Level Services typically expose the functionality of a Device by
exposing the on-Device Resources. In addition, these services typically
handle quality aspects such as security, availability, and performance issues.
• 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.
• Integrated Services are the compositions of Resource-Level and Virtual
Entity-Level services, or any combination of both service classes.
Further considerations
Identification of Physical Entities is important in an IoT system in order for
any User to interact with the physical world though the digital world.
(a) primary identification that uses natural features of a Physical
Entity
(b) secondary identification when using tags or labels attached to the
Physical Entity
2.4.2 Information model
• information is defined as the enrichment of data (raw values without relevant or
usable context) with the right context, so that queries about who, what, where, and
when can be answered.
• The attribute values are updated as a result of the associated services to a Virtual
Entity. The associated services, in turn, are related to Resources and Devices as seen
from the IoT Domain Model.
• Virtual Entity object contains simple attributes/properties:
o entityType to denote the type of entity, such as a human, car, or room (the
entity type can be a reference to concepts of a domain ontology, e.g. a
carontology);
o a unique identifier; and zero or more complex attributes of the class
Attributes.
o The Virtual Entity in the IoT Information Model is described with only a few
simple attributes, the complex Attribute associated with sensor/actuator/
tag services.
• attributes or properties that could exist in a Virtual Entity description
o Location and its temporal information are important because Physical
Entities represented by Virtual Entities exist in space and time. These
14
munotes.in
properties are extremely important when the interested Physical Entities

are mobile (e.g. a moving car)
o Even non-moving Virtual Entities contain properties that are dynamic with
time, and therefore their temporal variations need to be modeled and
captured by an information model.
o Information such as ownership is also important in commercial settings
because it may determine access control rules or liability issues.
• The Services in the IoT Domain Model are mapped to the Service Description in
the IoT Information Model.
o Service type, which denotes the type of service, such as Big Web Service or
RESTful Web Service. Web Application Description Language (WADL),
RESTful Web Services, Web Services Description Language (WSDL).
o Service area and Service schedule are properties of Services used for
specifying the geographical area of interest for a Service and the potential
temporal availability of a Service, respectively.
o Associated resources that the Service exposes.
o Metadata or semantic information used mainly for service composition.
• IoT Information Model also contains Resource descriptions
o Resource name and identifier for facilitating resource discovery.
▪ Resource type (a) a sensor resource (b) an actuator resource
▪ Free text attributes or tags
▪ on-Device resource or network resource.
▪ Location information
▪ Associated Service information
▪ Associated Device description information
2.4.3 Functional model
• The IoT Functional Model aims at describing mainly the Functional Groups (FG) and
their interaction with the ARM, while the Functional View of a Reference
Architecture describes the functional components of an FG, interfaces, and
interactions between the components.
IoT-A Functional Model
15
• The need for communicating Devices and digital artifacts was the motivation for the
Communication FG.
• The need to compose simple IoT services in order to create more complex ones, as
well as the need to integrate IoT services (simple or complex) with existing
Information and Communications Technology (ICT) infrastructure, is the main driver
behind the introduction of the Service Organization and IoT Process Management
FGs respectively.
• Device functional group
o contains all the possible functionality hosted by the physical Devices that
are used for instrumenting the Physical Entities
• Communication functional group
o communication mechanisms used by the relevant Devices in an actual
system in order to transfer information to the digital world components
or other Devices.
• IoT Service functional group
o The IoT Service FG corresponds mainly to the Service class from the IoT
Domain Model, and contains single IoT Services exposed by Resources
hosted on Devices or in the Network (e.g. processing or storage
Resources).
• Virtual Entity functional group
o corresponds to the Virtual Entity class in the IoT Domain Model, and
contains the necessary functionality to manage associations between
Virtual Entities with themselves as well as associations between Virtual
Entities and related IoT Services, i.e. the Association objects for the IoT
Information Model.
• IoT Service Organization functional group
o all functional components that support the composition and
orchestration of IoT and Virtual Entity services. Moreover, this FG acts as
a service hub between several other functional groups such as the IoT
Process Management
• IoT Process Management functional group
o The IoT Process Management FG is a collection of functionalities that
allows smooth integration of IoT-related services
• Management functional group
o Support functions such as management of ownership, administrative
domain, rules and rights of functional components, and information
stores are also included in the Management FG.
• Security functional group
o include privacy mechanisms such as anonymization of collected data,
anonymization of resource and Service accesses (Services cannot deduce
which Human User accessed the data), and un-linkability (an outside
observer cannot deduce the Human User of a service by observing
multiple service requests by the same User).
• Application functional group
o The Application FG is just a placeholder that represents all the needed
logic for creating an IoT application.
• Modular IoT functions
16
o The Functional Model, as well as the Functional View of the Reference

Architecture, contains a complete map of the potential functionalities for
a system realization.
2.4.4 Communication model

• 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 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).
2.4.5 Safety, privacy, trust, security model

The fact that Human Users are part of the system that could potentially harm
humans if malfunctioning, or expose private information, motivates the Safety and
Privacy needs for the IoT Reference Model and Architecture.
• Safety
o System safety is highly application- or application domain-specific,
and is typically closely related to an IoT system that includes
actuators that could potentially harm animate objects (humans,
animals).
• Privacy
o Because interactions with the physical world may often include
humans, protecting the User privacy is of utmost importance for an
IoT system.
• Trust
o “Generally, an entity is said to ‘trust’ a second entity when the first
entity makes the assumption that the second entity will behave
exactly as the first entity expects.” This definition includes an
“expectation” which is difficult to capture in a technical context.
• The necessary aspects of a trust model according to IoT-A
o Trust Model Domains (maintaining trust relationships
for every pair)
o Trust Evaluation Mechanisms (trust level of a Device)
o Trust Behavior Policies (behavior between interacting
entities)
o Trust Anchor (trust level of a third entity.)
o Federation of Trust (trust relationships between entities
with different Trust Models)
IoT Reference Architecture
2.5 Introduction
Reference Architecture is a starting point for generating concrete architectures and actual
systems.
Views are useful for reducing the complexity of the Reference Architecture blueprints by
addressing groups of concerns one group at a time.
17
munotes.in
• 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.
2.6 Functional view

It consists of the Functional Groups (FGs) presented earlier in the IoT Functional Model,
each of which includes a set of Functional Components (FCs).
IoT Functional View.

• Device and Application functional group
o 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:
• Hop-by-Hop Communication 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.
• The hop-by-hop FC is responsible for transmission and reception of physical and
MAC layer frames to/from other devices. This FC has two main interfaces:
o (a) one “southbound” to/from the actual radio on the device, and
o (b) one “northbound” to/from the Network FC in the Communication FG.
18
munotes.in
• Network FC is responsible for message routing & forwarding and the necessary
translations of various identifiers and addresses.
o between network layer identifiers to MAC and/or physical network
identifiers
o 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)
o 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 (IPv4 to IPv6
translation)
• End-to-End Communication FC is responsible for end-to-end transport of
application layer messages through diverse network and MAC/PHY layers.
o This FC is responsible for hosting any necessary proxy/cache and any
protocol translation between networks with different
transport/application layer technologies. HTTP-CoAP proxy, which
performs transport-layer protocol translation.
IoT Service functional group
• IoT Service FG consists of two FCs:
o The IoT Service FC and
o the IoT Service Resolution FC:
• The IoT Service FC
o is a collection of service implementations, which interface the related and
associated Resources.
o For a Sensor type of a Resource, the IoT Service FC includes Services that receive
requests from a User and returns the Sensor Resource value in synchronous or
asynchronous (e.g. subscription/notification) fashion.
o The services corresponding to Actuator Resources receive User requests for
actuation, control the Actuator Resource, and may return the status of the
Actuator after the action.
• The IoT Service Resolution FC
o contains the necessary functions to realize a directory of IoT Services that allows
dynamic management of IoT Service descriptions and
discovery/lookup/resolution of IoT Services by other Active Digital Artifacts.
o Dynamic management includes methods such as creation/update/ deletion
(CUD) of Service description, and can be invoked by both the IoT Services
themselves, or functions from the Management FG (e.g.bulk creation of IoT
Service descriptions upon system start-up).
Virtual Entity functional group

o The Virtual Entity FG contains functions that support the interactions between Users and
Physical Things through Virtual Entity services.
o The following FCs are defined for realizing these functionalities
o The Virtual Entity Service FC enables the interaction between Users and Virtual
Entities by means of reading and writing the Virtual Entity attributes (e.g. the GPS
coordinates of a room)
19
o The Virtual Entity Registry FC maintains the Virtual Entities of interest for the
specific IoT system and their associations.
o The Virtual Entity Resolution FC maintains the associations between Virtual Entities
and IoT Services, and offers services such as creating/reading/updating/deleting
associations as well as lookup anddiscovery of associations. (finding devices)
o The Virtual Entity and IoT Service Monitoring FC includes:
▪ functionality to assert
▪ discover new associations
▪ continuous monitoring
IoT process management functional group

o The IoT Process Management FG aims at supporting the integration of business
processes with IoT-related services.
o It consists of two FCs:
o The Process Modeling FC (modeling a business process that utilizes IoT-related
services)
o The Process Execution FC (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

o The Service Organization FG acts as a coordinator between different Services offered by
the system. It consists of the following FCs:
o The Service Composition FC manages the descriptions and execution
environment of complex services consisting of simpler dependent services.
o The Service Orchestration FC resolves the requests coming from IoT Process
Execution FC
o The Service Choreography FC is a broker for facilitating communication among
Services using the Publish/Subscribe pattern.
Security functional group

o The Security FG contains the necessary functions for ensuring the security and privacy
of an IoT system. It consists of the following FCs:
o The Identity Management FC manages the different identities of the involved
Services or Users in an IoT system in order to achieve anonymity by the use of
multiple pseudonyms.
o The Authentication FC verifies the identity of a User and creates an assertion
upon successful verification.
o The Authorization FC manages and enforces access control policies.
o The Key Exchange & Management FC is used for setting up the necessary
security keys between two communicating entities in an IoT system.
o The Trust & Reputation FC manages reputation scores of different interacting
entities in an IoT system and calculates the service trust levels.
Management functional group

o The Management FG contains system-wide management functions that may use
individual FC management interfaces.
o The Fault FC detects, logs, isolates, and corrects system-wide faults if possible.
20
munotes.in
o The Member FC manages membership information about the relevant entities in an IoT
system, such as capabilities, ownership, and access rules & rights.
o The State FC (logs) 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
o The Reporting FC is responsible for producing compressed reports
2.7 Information view

The information view consists of
o the description of the information handled in the IoT System, and
o the way this information is handled in the system
(how information is created, processed, and deleted), and the information handling components
Information description
o Virtual Entity context information, i.e. the attributes (simple or complex) as
represented by parts of the IoT Information model (attributes that have values and
metadata such as the temperature of a room).
o 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.
o Virtual Entity descriptions in general, which contain not only the attributes coming from
IoT Devices (e.g. ownership information).
o Associations between Virtual Entities and related IoT Services.
o Virtual Entity Associations with other Virtual Entities (e.g. Room #123 is on Floor #7).
o Device Descriptions such as device capabilities (e.g. sensors, radios).
Information flow and lifecycle

the flow of information in an IoT system follows two main directions.
o 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
o from the application or part of a larger system information it follows a context-
reduction process until it reaches the consumer types of devices (e.g. actuators).
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.
The presentation of information handling in an IoT system assumes that FCs exchange and
process information. The exchange of information between FCs follows the interaction patterns
21
munotes.in
Information exchange patterns
o 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.
o Request/Response: An FC A sends a request to another FC B and receives a response
from B after A serves the request.
o Subscribe/Notify: Multiple subscriber components (SA, SB) can subscribe for
information to a component C, and C will notify the relevant subscribers when the
requested information is ready
o 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).
2.8 Deployment and operational view
The Deployment and Operational View depends on the specific actual use case and
requirements
Devices view as Physical Entities deployed in the parking lot, as well as the occupancy sign.
o There are two sensor nodes (#1 and #2), each of which are connected to eight metal/car
presence sensors.
o The two sensor nodes are connected to the payment station through wireless or wired
communication.
o 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.)
o The occupancy sign also acts as a communication gateway for the actuator node (display
of free parking spots), and we assume that because of the deployment, a direct
connection to the payment station is not feasible
o The two main applications connected to this management system are human user
mobile phone applications and parking operation center applications.
22
Parking Lot Deployment and Operational View, Devices.
23
munotes.in
Parking Lot Deployment & Operational View, Resources, Services, Virtual Entities, Users.
2.9 Other relevant architectural views

The two most important are the Physical Entity View and the Context View.
o The Physical Entity View describes the Physical Entities from the IoT Domain Model in
terms of physical properties (e.g. dimensions for spaces/ objects).
o the Context View should capture external entitiesinteracting with the system, impact of
the system on its environment, external entity properties/identities, system scope and
responsibilities
UNIT 2
• At the bottom layer is the market or application domain, which may be smart grid, connected
home, or smart health, etc.
• The second layer consists of sensors that enable the application. Examples of such sensors are
temperature sensors, humidity sensors, electric utility meters, or cameras.
• The third layer consists of interconnection layer that allows the data generated by sensors to be
communicated, usually to a computing facility, data center, or a cloud. There the data is
aggregated with other known data sets such as geographical data, population data, or economic
data. The combined data is then analyzed using machine learning and data mining techniques.
To enable such large distributed applications, we also need the latest application level
collaboration and communication software, such as, software defined networking (SDN),
services oriented architecture (SOA), etc.
• Finally, the top layer consists of services that enable the market and may include energy
management, health management, education, transportation etc.
• In addition to these 7 layers that are built on the top of each other, there are security and
management applications that are required for each of the layers and are, therefore, shown on
the side.
24
3.0 IoT Data Link Layer and Network Layer Protocols:
3.1 physical (PHY) and MAC layer protocols

3GPP MTC 3rd generation partnership project technologies and machine type communications
MTC refers to small amounts of data that are communicated between machines (devices to
back-end services and vice versa) without the need for any human intervention. In the 3rd
Generation Partnership Project (3GPP), MTC is used to refer to all M2M communication (Jain et
al. 2012). Thus, they are interchangeable terms.
3.2 IEEE 802.15

• IEEE 802.15.4 is the most commonly used IoT standard for MAC. It defines a frame format,
headers including source and destination addresses, and how nodes can communicate with
each other. The frame formats used in traditional networks are not suitable for low power
multi-hop networking in IoT due to their overhead.
• IEEE802.15.4e was created to extend IEEE802.15.4 and support low power communication.
• MAC features
• Slotframe Structure: frame structure is designed for scheduling and telling each node what
to do. A node can sleep, send, or receive information. In the sleep mode, the node turns off
its radio to save power and stores all messages that it needs to send at the next
transmission opportunity. When transmitting, it sends its data and waits for an
acknowledgment. When receiving, the node turns on its radio before the scheduled
receiving time, receives the data, sends an acknowledgement, turn off its radio, delivers the
data to the upper layers and goes back to sleep.
• Scheduling: The standard does not define how the scheduling is done but it needs to be built
carefully such that it handles mobility scenarios. It can be centralized by a manager node
which is responsible for building the schedule, informing others about the schedule and
other nodes will just follow the schedule.
• Synchronization: Two approaches can be used: acknowledgment-based or frame-based
synchronization. In acknowledgement-based mode, the nodes are already in communication
25
munotes.in
and they send acknowledgment for reliability guarantees, thus can be used to maintain
connectivity as well. In frame-based mode, nodes are not communicating and hence, they
send an empty frame at pre-specified intervals (about 30 second typically).
• Channel Hopping: IEEE802.15.4e introduces channel hopping for time slotted access to the
wireless medium. Channel hopping requires changing the frequency channel using a pre-
determined random sequence.
• Network formation: Network formation includes advertisement and joining components. A
new device should listen for advertisement commands and upon receiving at least one such
command, it can send a join request to the advertising device. In a centralized system, the
join request is routed to the manger node and processed there while in distributed systems,
they are processed locally. Once a device joins the network and it is fully functional, the
formation is disabled and will be activated again if it receives another join request.
3.4 IEEE 802.11

• IEEE 802.11ah is a light (low-energy) version of the original IEEE 802.11 wireless medium access
standard. It has been designed with less overhead to meet IoT requirements. IEEE 802.11
standards (also known as Wi-Fi) are the most commonly used wireless standards. They have
been widely used and adopted for all digital devices including laptops, mobiles, tablets, and
digital TVs. However, the original WiFi standards are not suitable for IoT applications due to
their frame overhead and power consumption. Hence, IEEE 802.11 working group initiated
802.11ah task group to develop a standard that supports low overhead, power friendly
communication suitable for sensors.
• MAC layer features
o Synchronization Frame: A station is not allowed to transmit unless it has valid medium
information that allows it to capture the medium and stop packet exchange by others. It
can know such information if it receives the duration field packet correctly. If it does not
receive it correctly, then it should wait for a duration called Probe Delay. Probe Delay
can be configured by the access points in 802.11ah and announced by transmitting a
synchronization frame at the beginning of the time slot.
o Efficient Bidirectional Packet Exchange: This feature allows the sensor device to save
more power by allowing both uplink and downlink communication between the access
point and the sensor and allowing it to go to sleep as soon as it finishes the
communication.
o Short Mac Frame: The normal IEEE 802.11 frame is about 30 bytes, which is too large
for IoT applications. IEEE 802.11ah mitigates this problem by defining a short MAC
frame with about 12 bytes.
o Null Data Packet: In IEEE 802.11 the control frames, such as Acknowledgment (ACK)
frames, are about 14 bytes and have no data, which adds a lot of overhead. IEEE
802.11ah mitigates this problem by replacing the ACK frame with a preamble, a tiny
signal.
o Increase Sleep Time: 802.11ah is designed for low-power sensors and, hence, it allows a
long sleep period of time and waking up infrequently to exchange data only.
3.5 WirelessHART
• WirelessHART is a datalink protocol that operates on the top of IEEE 802.15.4 PHY and adopts
Time Division Multiple Access (TDMA) in its MAC. It is a secure and reliable MAC protocol that
26
munotes.in
uses advanced encryption to encrypt the messages and calculate the integrity in order to offer
reliability.
• consists of a network manager, a security manager, a gateway to connect the wireless network
to the wired networks, wireless devices as field devices, access points, routers and adapters. The
standard offers end-to-end, per-hop or peer-to- peer security mechanisms. End to end security
mechanisms enforce security from sources to destinations while per-hop mechanisms secure it
to next hop only
3.5 Z-Wave
• Z-Wave is a low-power MAC protocol designed for home automation and has been used for IoT
communication, especially for smart home and small commercial domains. It covers about 30-
meter point-to-point communication and is suitable for small messages in IoT applications, like
light control, energy control, wearable healthcare control and others. It uses CSMA/CA for
collision detection and ACK messages for reliable transmission. It follows a master/slave
architecture in which the master control the slaves, send them commands, and handling
scheduling of the whole network
3.6 Bluetooth Low Energy

• Bluetooth low energy or Bluetooth smart is a short range communication protocol with PHY and
MAC layer widely used for in-vehicle networking. Its low energy can reach ten times less than
the classic Bluetooth while its latency can reach 15 times. Its access control uses a contention-
less MAC with low latency and fast transmission. It follows master/slave architecture and offers
two types of frames: adverting and data frames. The Advertising frame is used for discovery and
is sent by slaves on one or more of dedicated advertisement channels. Master nodes sense
advertisement channels to find slaves and connect them. After connection, the master tells the
slave its waking cycle and scheduling sequence. Nodes are usually awake only when they are
communicating and they go to sleep otherwise to save their power
3.7 Zigbee Smart Energy

• ZigBee smart energy is designed for a large range of IoT applications including smart homes,
remote controls and healthcare systems. It supports a wide range of network topologies
including star, peer-to-peer, or cluster-tree. A coordinator controls the network and is the
central node in a star topology, the root in a tree or cluster topology and may be located
27
anywhere in peer-to-peer. ZigBee standard defines two stack profiles: ZigBee and ZigBee Pro.
These stack profiles support full mesh networking and work with different applications allowing
implementations with low memory and processing power. ZigBee Pro offers more features
including security using symmetric-key exchange, scalability using stochastic address
assignment, and better performance using efficient many-to-one routing mechanisms
3.8 DASH7
• DASH7 is a wireless communication protocol for active RFID that operates in globally available
Industrial Scientific Medical (ISM) band and is suitable for IoT requirements. It is mainly
designed for scalable, long range outdoor coverage with higher data rate compared to
traditional ZigBee. It is a low-cost solution that supports encryption and IPv6 addressing. It
supports a master/slave architecture and is designed for burst, lightweight, asynchronous and
transitive traffic. Its MAC layer features
• Filtering: Incoming frames are filtered using three processes; cyclic redundancy check (CRC)
validation, a 4-bit subnet mask, and link quality assessment. Only the frames that pass all
three checks are processed further.
• Addressing: DASH7 uses two types of addresses: the unique identifier which is the EUI-64 ID
and dynamic network identifier which is 16-bit address specified by the network
administrator.
• Frame format: The MAC frame has a variable length of maximum 255 bytes including
addressing, subnets, estimated power of the transmission and some other optional fields.
4.0 Network Layer

4 .1 IPv4
• Internet Protocol Version 4 (IPv4) is the fourth revision of the Internet Protocol and a widely
used protocol in data communication over different kinds of networks. IPv4 is a connectionless
protocol used in packet-switched layer networks, such as Ethernet. It provides the logical
connection between network devices by providing identification for each device. There are
many ways to configure IPv4 with all kinds of devices – including manual and automatic
configurations – depending on the network type.
• IPv4 is based on the best-effort model. This model guarantees neither delivery nor avoidance of
duplicate delivery; these aspects are handled by the upper layer transport.
• IPv4 is defined and specified in IETF publication RFC 791. It is used in the packet-switched link
layer in the OSI model.
• IPv4 uses 32-bit addresses for Ethernet communication in five classes: A, B, C, D and E. Classes A,
B and C have a different bit length for addressing the network host. Class D addresses are
reserved for multicasting, while class E addresses are reserved for future use.
4.2 Ipv6
• An Ipv6 address uses 128 bits as opposed to 32 bits in IPv4.
• IPv6 addresses are written using hexadecimal, as opposed to dotted decimal in IPv4.
• Because an hexadecimal number uses 4 bits this means that an IPv6 address consists of 32
hexadecimal numbers.
• These numbers are grouped in 4’s giving 8 groups or blocks. The groups are written with a :
(colon) as a separator.
• group1:group2: ……etc…. :group8
28
munotes.in
4.3 6LoWPAN
• IPv6 over Low power Wireless Personal Area Network (6LoWPAN) is the first and most
commonly used standard in this category. It efficiently encapsulates IPv6 long headers in
IEEE802.15.4 small packets, which cannot exceed 128 bytes. The specification supports different
length addresses, low bandwidth, different topologies including star or mesh, power
consumption, low cost, scalable networks, mobility, unreliability and long sleep time. The
standard provides header compression to reduce transmission overhead, fragmentation to meet
the 128-byte maximum frame length in IEEE802.15.4, and support of multi-hop delivery.
Frames in 6LoWPAN use four types of headers:
• No 6loWPAN header (00),
• Dispatch header (01),
• Mesh header (10) and
• Fragmentation header (11).
• In No 6loWPAN header case, any frame that does not follow 6loWPAN specifications is
discarded.
• Dispatch header is used for multicasting and IPv6 header compressions.
• Mesh headers are used for broadcasting; while
• Fragmentation headers are used to break long IPv6 header to fit into fragments of
maximum 128-byte length.
4.4 6TiSCH
• 6TiSCH working group in IETF is developing standards to allow IPv6 to pass through Time-Slotted
Channel Hopping (TSCH) mode of IEEE 802.15.4e datalinks.
• It defines a Channel Distribution usage matrix consisting of available frequencies in columns and
time-slots available for network scheduling operations in rows. This matrix is portioned into
chucks where each chunk contains time and frequencies and is globally known to all nodes in
the network.
• The nodes within the same interference domain negotiate their scheduling so that each node
gets to transmit in a chunk within its interference domain. Scheduling becomes an optimization
problem where time slots are assigned to a group of neighboring nodes sharing the same
application. The standard does not specify how the scheduling can be done and leaves that to
be an application specific problem in order to allow for maximum flexibility for different IoT
applications. The scheduling can be centralized or distributed depending on application or the
topology used in the MAC layer
4.5 DHCP
• DHCP Architecture
o The DHCP architecture consists of DHCP clients, DHCP servers, and DHCP relay agents on
a network. The clients interact with servers using DHCP messages in a DHCP
conversation to obtain and renew IP address leases.
• DHCP Client Functionality
o A DHCP client is any network-enabled device that supports the ability to communicate
with a DHCP server in compliance with RFC 2131, for the purpose of obtaining dynamic
leased IP configuration and related optional information.
29
• Lease Durations
o When a scope is created, the lease duration is set to eight days by default. However
there are situations when the administrator might want to change the lease duration.
• DHCP Messages
• DHCPDiscover
o Broadcast by a DHCP client when it first attempts to connect to the network. The
DHCPDiscover message requests IP address information from a DHCP server.
• DHCPOffer
o Broadcast by each DHCP server that receives the client DHCPDiscover message and has
an IP address configuration to offer to the client. The DHCPOffer message contains an
unleased IP address and additional TCP/IP configuration information, such as the subnet
mask and default gateway. More than one DHCP server can respond with a DHCPOffer
message. The client accepts the best offer, which for a Windows DHCP client is the first
DHCPOffer message that it receives.
• DHCPRequest
o Broadcast by a DHCP client after it selects a DHCPOffer. The DHCPRequest message
contains the IP address from the DHCPOffer that it selected. If the client is renewing or
rebinding to a previous lease, this packet might be unicast directly to the server.
• DHCPAck
o Broadcast by a DHCP server to a DHCP client acknowledging the DHCPRequest message.
At this time, the server also forwards any options. Upon receipt of the DHCPAck, the
client can use the leased IP address to participate in the TCP/IP network and complete
its system startup. This message is typically broadcast, because the DHCP client does not
officially have an IP address that it can use at this point. If the DHCPAck is in response to
a DHCPInform, then the message is unicast directly to the host that sent the
DHCPInform message.
• DHCPNack
o Broadcast by a DHCP server to a DHCP client denying the client’s DHCPRequest message.
This might occur if the requested address is incorrect because the client moved to a new
subnet or because the DHCP client’s lease has expired and cannot be renewed.
• DHCPDecline
o Broadcast by a DHCP client to a DHCP server, informing the server that the offered IP
address is declined because it appears to be in use by another computer.
• DHCPRelease
o Sent by a DHCP client to a DHCP server, relinquishing an IP address and canceling the
remaining lease. This is unicast to the server that provided the lease.
• DHCPInform
o Sent from a DHCP client to a DHCP server, asking only for additional local configuration
parameters; the client already has a configured IP address.
• DHCP Lease Process
o A DHCP-enabled client obtains a lease for an IP address from a DHCP server. Before the
lease expires, the DHCP client must renew the lease or obtain a new lease. Leases are
retained in the DHCP server database for a period of time after expiration. By default,
this grace period is four hours and cleanup occurs once an hour for a DHCP server
running Windows Server 2003. This protects a clients lease in case the client and server
are in different time zones, the internal clocks of the client and server computers are
not synchronized, or the client is off the network when the lease expires.
30
• Obtaining a New Lease

o A DHCP client initiates a conversation with a DHCP server when it is seeking a new lease,
renewing a lease, rebinding, or restarting. The DHCP conversation consists of a series of
DHCP messages passed between the DHCP client and DHCP servers. The following figure
shows an overview of this process when the DHCP server and DHCP client are on the
same subnet.
4.6 ICMP
• ICMP (Internet Control Message Protocol) is an error-reporting protocol network devices like
routers use to generate error messages to the source IP address when network problems
prevent delivery of IP packets. ICMP creates and sends messages to the source IP address
indicating that a gateway to the Internet that a router, service or host cannot be reached for
packet delivery. Any IP network device has the capability to send, receive or process ICMP
messages.
• ICMP is not a transport protocol that sends data between systems.
• While ICMP is not used regularly in end-user applications, it is used by network administrators
to troubleshoot Internet connections in diagnostic utilities including ping and traceroute.
• One of the main protocols of the Internet Protocol suite, ICMP is used by routers, intermediary
devices or hosts to communicate error information or updates to other routers, intermediary
devices or hosts. The widely used IPv4 (Internet Protocol version 4) and the newer IPv6 use
similar versions of the ICMP protocol (ICMPv4 and ICMPv6, respectively).
4.7 RPL
• RPL offers different level of security by utilizing a Security field after the 4-byte ICMPv6 message
header. Information in this field indicates the level of security and the cryptography algorithm
used to encrypt the message. RPL offers support for data authenticity, semantic security,
protection against replay attacks, confidentiality and key management. Levels of security in RPL
include Unsecured, Preinstalled, and Authenticated. RPL attacks include Selective Forwarding,
Sinkhole, Sybil, Hello Flooding, Wormhole, Black hole and Denial of Service attacks.
4.8 CORPL
• An extension of RPL is CORPL, or cognitive RPL, which is designed for cognitive networks and
uses DODAG topology generation but with two new modifications to RPL. CORPL utilizes
opportunistic forwarding to forward the packet by choosing multiple forwarders (forwarder set)
and coordinates between the nodes to choose the best next hop to forward the packet to.
DODAG is built in the same way as RPL. Each node maintains a forwarding set instead of its
parent only and updates its neighbor with its changes using DIO messages. Based on the
updated information, each node dynamically updates its neighbor priorities in order to
construct the forwarder set
4.9 CARP
• Channel-Aware Routing Protocol (CARP) is a distributed routing protocol designed for
underwater communication. It can be used for IoT due to its lightweight packets. It considers
link quality, which is computed based on historical successful data transmission gathered from
neighboring sensors, to select the forwarding nodes.
• There are two scenarios: network initialization and data forwarding.
o In network initialization, a HELLO packet is broadcasted from the sink to all other nodes
in the networks.
31
o In data forwarding, the packet is routed from sensor to sink in a hop- by-hop fashion.
Each next hop is determined independently.
• The main problem with CARP is that it does not support reusability of previously collected data.
In other words, if the application requires sensor data only when it changes significantly, then
CARP data forwarding is not beneficial to that specific application. An enhancement of CARP was
done in E-CARP by allowing the sink node to save previously received sensory data. When new
data is needed, E-CARP sends a Ping packet which is replied with the data from the sensors
nodes. Thus, E-CARP reduces the communication overhead drastically
UNIT 3
Transport layer protocols
5.1 TCP
• TCP is a connection-oriented protocol, which means a connection is established and maintained
until the application programs at each end have finished exchanging messages. It determines
how to break application data into packets that networks can deliver, sends packets to and
accepts packets from the network layer, manages flow control, and—because it is meant to
provide error-free data transmission—handles retransmission of dropped or garbled packets as
well as acknowledgement of all packets that arrive.
• when a Web server sends an HTML file to a client, it uses the HTTP protocol to do so. The HTTP
program layer asks the TCP layer to set up the connection and send the file. The TCP stack
divides the file into packets, numbers them and then forwards them individually to the IP layer
for delivery. Although each packet in the transmission will have the same source and
destination IP addresses, packets may be sent along multiple routes. The TCP program layer in
the client computer waits until all of the packets have arrived, then acknowledges those it
receives and asks for the retransmission on any it does not (based on missing packet numbers),
then assembles them into a file and delivers the file to the receiving application.
• Retransmissions and the need to reorder packets after they arrive can introduce latency in a TCP
stream. Highly time-sensitive applications like voice over IP (VoIP) and streaming video generally
rely on a transport like User Datagram Protocol (UDP) that reduces latency and jitter (variation
in latency) by not worrying about reordering packets or getting missing data retransmitted.
5.2 MPTCP
• The core idea of multipath TCP is to define a way to build a connection between two hosts and
not between two interfaces (as standard TCP does).
• For instance, Alice has a smartphone with 3G and WiFi interfaces (with IP addresses 10.11.12.13
and 10.11.12.14) and Bob has a computer with an Ethernet interface (with IP address
20.21.22.23).
• In standard TCP, the connection should be established between two IP addresses. Each TCP
connection is identified by a four-tuple (source and destination addresses and ports). Given this
restriction, an application can only create one TCP connection through a single link. Multipath
TCP allows the connection to use several paths simultaneously. For this, Multipath TCP creates
one TCP connection, called subflow, over each path that needs to be used.
32
The purpose of the different protocol operations are:

• to handle when and how to add/remove paths (for instance if there's a connection lost of some
congestion control)
• to be compatible with legacy TCP hardware (such as some firewalls that can automatically reject
TCP connections if the sequence number aren't successive)
• to define a fair congestion control strategy between the different links and the different hosts
(especially with those that doesn't support MPTCP)
Multipath TCP adds new mechanisms to TCP transmissions:

• The subflow system, used to gather multiple standard TCP connections (the paths from one host
to another). Subflows are identified during the TCP three-way handshake. After the handshake,
an application can add or remove some subflows (subtypes 0x3 and 0x4).
• The MPTCP DSS option contains a data sequence number and an acknowledgement number.
These allow receiving data from multiple subflows in the original order, without any corruption
(message subtype 0x2)
• A modified retransmission protocol handles congestion control and reliability.
5.3 UDP
• UDP (User Datagram Protocol) is an alternative communications protocol to Transmission
Control Protocol (TCP) used primarily for establishing low-latency and loss-tolerating
connections between applications on the internet.
• UDP is an ideal protocol for network applications in which perceived latency is critical, such as
in gaming and voice and video communications, which can suffer some data loss without
adversely affecting perceived quality. In some cases, forward error correction techniques are
used to improve audio and video quality in spite of some loss.
• UDP can also be used in applications that require lossless data transmission when the
application is configured to manage the process of retransmitting lost packets and correctly
arranging received packets. This approach can help to improve the data transfer rate of large
files compared to TCP.
• In the Open Systems Interconnection (OSI) communication model, UDP, like TCP, is in Layer 4,
the transport layer. UDP works in conjunction with higher level protocols to help manage data
transmission services including Trivial File Transfer Protocol (TFTP), Real Time Streaming
Protocol (RTSP), Simple Network Protocol (SNP) and domain name system (DNS) lookups.
• User datagram protocol features
• The user datagram protocol has attributes that make it advantageous for use with applications
that can tolerate lost data.
• It allows packets to be dropped and received in a different order than they were transmitted,
making it suitable for real-time applications where latency might be a concern.
• It can be used for transaction-based protocols, such as DNS or Network Time Protocol.
• It can be used where a large number of clients are connected and where real-time error
correction isn't necessary, such as gaming, voice or video conferencing, and streaming media.
5.4 DCCP
• Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol.
DCCP implements reliable connection setup, teardown, Explicit Congestion
Notification (ECN), congestion control, and feature negotiation.
33
• DCCP provides a way to gain access to congestion-control mechanisms without having to

implement them at the application layer. It allows for flow-based semantics like in Transmission
Control Protocol (TCP), but does not provide reliable in-order delivery. Sequenced delivery
within multiple streams as in the Stream Control Transmission Protocol (SCTP) is not available in
DCCP. A DCCP connection contains acknowledgment traffic as well as data traffic.
Acknowledgments inform a sender whether its packets have arrived, and whether they were
marked by Explicit Congestion Notification (ECN). Acknowledgements are transmitted as reliably
as the congestion control mechanism in use requires, possibly completely reliably.
• DCCP is useful for applications with timing constraints on the delivery of data. Such applications
include streaming media, multiplayer online games and Internet telephony. In such applications,
old messages quickly become useless, so that getting new messages is preferred to resending
lost messages.
• DCCP can also serve as a general congestion-control mechanism for UDP-based applications, by
adding, as needed, mechanisms for reliable or in-order delivery on top of UDP/DCCP. In this
context, DCCP allows the use of different, but generally TCP-friendly congestion-control
mechanisms.
• DCCP has the option for very long (48-bit) sequence numbers corresponding to a packet ID,
rather than a byte ID as in TCP. The long length of the sequence numbers aims to guard against
"some blind attacks, such as the injection of DCCP-Resets into the connection"
5.5 SCTP
• The Stream Control Transmission Protocol (SCTP) is a computer networking communications
protocol which operates at the transport layer and serves a role similar to the popular
protocols TCP and UDP.
• SCTP provides some of the features of both UDP and TCP: it is message-oriented like UDP and
ensures reliable, in-sequence transport of messages with congestion control like TCP. It differs
from those protocols by providing multi-homing and redundant paths to increase resilience and
reliability.
• In the absence of native SCTP support in operating systems, it is possible to tunnel SCTP over
UDP as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without
modification In the absence of native SCTP support in operating systems, it is possible
to tunnel SCTP over UDP as well as to map TCP API calls to SCTP calls so existing applications can
use SCTP without modification
• SCTP applications submit their data to be transmitted in messages (groups of bytes) to the SCTP
transport layer. SCTP places messages and control information into separate chunks (data
chunks and control chunks), each identified by a chunk header. The protocol can fragment a
message into a number of data chunks, but each data chunk contains data from only one user
message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to
the Internet Protocol, consists of a packet header, SCTP control chunks (when necessary),
followed by SCTP data chunks (when available).
• One can characterize SCTP as message-oriented, meaning it transports a sequence of messages
(each being a group of bytes), rather than transporting an unbroken stream of bytes as does
TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is
passed to the receiving application process in one operation. In contrast, TCP is a stream-
oriented protocol, transporting streams of bytes reliably and in order. However TCP does not
allow the receiver to know how many times the sender application called on the TCP transport
passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a
34
queue of bytes waiting to go out over the network, rather than having to keep a queue of
individual separate outbound messages which must be preserved as such.
• The term multi-streaming refers to the capability of SCTP to transmit several independent
streams of chunks in parallel, for example transmitting web page images together with the web
page text. In essence, it involves bundling several connections into a single SCTP association,
operating on messages (or chunks) rather than bytes.
• Features of SCTP include:

• Reliable transmission of both ordered and unordered data streams.
• Multihoming support in which one or both endpoints of a connection can consist of more
than one IP address, enabling transparent fail-over between redundant network paths.
• Delivery of chunks within independent streams eliminate unnecessary head-of-line blocking,
as opposed to TCP byte-stream delivery.
• Explicit partial reliability.
• Path selection and monitoring to select a primary data transmission path and test the
connectivity of the transmission path.
• Validation and acknowledgment mechanisms protect against flooding attacks and provide
notification of duplicated or missing data chunks.
5.6 TLS
Transport Layer Security (TLS) – and its predecessor, Secure Sockets Layer (SSL), which is now
deprecated by the Internet Engineering Task Force (IETF) – are cryptographic protocols that
provide communications security over a computer network Several versions of the protocols find
widespread use in applications such as web browsing, email, instant messaging, and voice over
IP (VoIP). Websites are able to use TLS to secure all communications between their servers and web
browsers.
The TLS protocol aims primarily to provide privacy and data integrity between two or more
communicating computer applications. When secured by TLS, connections between a client (e.g., a web
browser) and a server (e.g., wikipedia.org) have one or more of the following properties:
• The connection is private (or secure) because symmetric cryptography is used to encrypt the
data transmitted. The keys for this symmetric encryption are generated uniquely for each
connection and are based on a shared secret negotiated at the start of the session. The server
and client negotiate the details of which encryption algorithm and cryptographic keys to use
before the first byte of data is transmitted. The negotiation of a shared secret is both secure
(the negotiated secret is unavailable to eavesdroppers and cannot be obtained, even by an
attacker who places themselves in the middle of the connection) and reliable (no attacker can
modify the communications during the negotiation without being detected).
• The identity of the communicating parties can be authenticated using public-key cryptography.
This authentication can be made optional, but is generally required for at least one of the
parties (typically the server).
• The connection is reliable because each message transmitted includes a message integrity check
using a message authentication code to prevent undetected loss or alteration of the data
during transmission
Client-server applications use the TLS protocol to communicate across a network in a way designed to
prevent eavesdropping and tampering.
35
Since applications can communicate either with or without TLS (or SSL), it is necessary for the client to
indicate to the server the setup of a TLS connection. One of the main ways of achieving this is to use a
different port number for TLS connections, for example port 443 for HTTPS. Another mechanism is for
the client to make a protocol-specific request to the server to switch the connection to TLS; for example,
by making a STARTTLS request when using the mail and news protocols.
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using
a handshaking procedure. The protocols use a handshake with an asymmetric cipher to establish not
only cipher settings but also a session-specific shared key with which further communication is
encrypted using a symmetric cipher. During this handshake, the client and server agree on various
parameters used to establish the connection's security:
• The handshake begins when a client connects to a TLS-enabled server requesting a secure
connection and the client presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the
client of the decision.
• The server usually then provides identification in the form of a digital certificate. The certificate
contains the server name, the trusted certificate authority (CA) that vouches for the authenticity
of the certificate, and the server's public encryption key.
• The client confirms the validity of the certificate before proceeding.
• To generate the session keys used for the secure connection, the client either:
• encrypts a random number with the server's public key and sends the result to the
server (which only the server should be able to decrypt with its private key); both
parties then use the random number to generate a unique session key for subsequent
encryption and decryption of data during the session
• uses Diffie–Hellman key exchange to securely generate a random and unique session
key for encryption and decryption that has the additional property of forward secrecy: if
the server's private key is disclosed in future, it cannot be used to decrypt the current
session, even if the session is intercepted and recorded by a third party.
This concludes the handshake and begins the secured connection, which is encrypted and decrypted
with the session key until the connection closes. If any one of the above steps fails, then the TLS
handshake fails and the connection is not created.
5.7 DTLS
Datagram Transport Layer Security (DTLS) is a communications protocol that
provides security for datagram-based applications by allowing them to communicate in a way that is
designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on
the stream-oriented Transport Layer Security (TLS) protocol and is intended to provide similar security
guarantees. The DTLS protocol datagram preserves the semantics of the underlying transport — the
application does not suffer from the delays associated with stream protocols, but has to deal
with packet reordering, loss of datagram and data larger than the size of a datagram network packet.
Session Layer Protocols

This section reviews standards and protocols for message passing in IoT session layer proposed by
different standardization organizations. Most of the IP applications, including IoT applications use TCP or
UDP for transport. However, there are several message distribution functions that are common among
many IoT applications; it is desirable that these functions be implemented in an interoperable standard
ways by different applications.
36
6.1 HTTP
• HTTP stands for Hypertext Transfer Protocol. It's the network protocol used to deliver virtually
all files and other data (collectively called resources) on the World Wide Web, whether they're
HTML files, image files, query results, or anything else. Usually, HTTP takes place through TCP/IP
sockets
• A browser is an HTTP client because it sends requests to an HTTP server (Web server), which
then sends responses back to the client. The standard (and default) port for HTTP servers to
listen on is 80, though they can use any port.
• What are "Resources"?
• HTTP is used to transmit resources, not just files. A resource is some chunk of information that
can be identified by a URL (it's the R in URL). The most common kind of resource is a file, but a
resource may also be a dynamically-generated query result, the output of a CGI script, a
document that is available in several languages, or something else.
• Like most network protocols, HTTP uses the client-server model: An HTTP client opens a
connection and sends a request message to an HTTP server; the server then returns a response
message, usually containing the resource that was requested. After delivering the response, the
server closes the connection (making HTTP a stateless protocol, i.e. not maintaining any
connection information between transactions).
6.2 CoAP
The Constrained Application Protocol (CoAP) is another session layer protocol designed by IETF
Constrained RESTful Environment (Core) working group to provide lightweight RESTful (HTTP) interface.
Representational State Transfer (REST) is the standard interface between HTTP client and servers.
However, for lightweight applications such as IoT, REST could result in significant overhead and power
consumption. CoAP is designed to enable low-power sensors to use RESTful services while meeting their
power constrains. It is built over UDP, instead of TCP commonly used in HTTP and has a light mechanism
to provide reliability. CoAP architecture is divided into two main sublayers: messaging and
request/response. The messaging sublayer is responsible for reliability and duplication of messages
while the request/response sublayer is responsible for communication. CoAP has four messaging modes:
confirmable, non- confirmable, piggyback and separate. Confirmable and non-confirmable modes
represent the reliable and unreliable transmissions, respectively while the other modes are used for
request/response. Piggyback is used for client/server direct communication where the server sends its
response directly after receiving the message, i.e., within the acknowledgment message. On the other
hand, the separate mode is used when the server response comes in a message separate from the
acknowledgment, and may take some time to be sent by the server. As in HTTP, CoAP utilizes GET, PUT,
PUSH, DELETE messages requests to retrieve, create, update, and delete, respectively
37
6.3 XMPP
Extensible Messaging and Presence Protocol (XMPP) is a messaging protocol that was designed originally
for chatting and message exchange applications. It was standardized by IETF more than a decade ago.
Hence, it is well known and has proven to be highly efficient over the internet. Recently, it has been
reused for IoT applications as well as a protocol for SDN. This reusing of the same standard is due to its
use of XML which makes it easily extensible. XMPP supports both publish/ subscribe and request/
response architecture and it is up to the application developer to choose which architecture to use. It is
designed for near real-time applications and, thus, efficiently supports low-latency small messages. It
does not provide any quality of service guarantees and, hence, is not practical for M2M
communications. Moreover, XML messages create additional overhead due to lots of headers and tag
formats which increase the power consumption that is critical for IoT application. Hence, XMPP is rarely
used in IoT but has gained some interest for enhancing its architecture in order to support IoT
applications
6.4 AMQP
The Advanced Message Queuing Protocol (AMQP) is another session layer protocol that was designed
for financial industry. It runs over TCP and provides a publish/ subscribe architecture which is similar to
that of MQTT. The difference is that the broker is divided into two main components: exchange and
queues. The exchange is responsible for receiving publisher messages and distributing them to queues
based on pre-defined roles and conditions. Queues basically represent the topics and subscribed by
subscribers which will get the sensory data whenever they are available in the queue
38
6.5 MQTT
Message Queue Telemetry Transport (MQTT) was introduced by IBM in 1999 and standardized by OASIS
in 2013. It is designed to provide embedded connectivity between applications and middleware on one
side and networks and communications on the other side. It follows a publish/subscribe architecture,
where the system consists of three main components: publishers, subscribers, and a broker. From IoT
point of view, publishers are basically the lightweight sensors that connect to the broker to send their
data and go back to sleep whenever possible. Subscribers are applications that are interested in a
certain topic, or sensory data, so they connect to brokers to be informed whenever new data are
received. The brokers classify sensory data in topics and send them to subscribers interested in the
topics.
oneM2M
oneM2M is a global organization that creates requirements, architecture, API specifications, security
solutions and interoperability for Machine-to-Machine and IoT technologies.
oneM2M specifications provide a framework to support a wide range of applications and services such
as smart cities, smart grid, connected car, home automation, public safety, and health.
oneM2M standard employs a simple horizontal, platform architecture that fits within a three layer
model comprising applications, services and networks. In the first of these layers, Application Entities
(AEs) reside within individual device and sensor applications. They provide a standardized interface to
manage and interact with applications. Common Services Entities (CSEs) play a similar role in the
services layer which resides between the applications layer and the in the network layer. The network
layer ensures that devices and sensors and applications are able to function in a network-agnostic
manner.
In the oneM2M functional architecture two basic types of entities are defined. One is an AE (short for
Application Entity) and the other is a CSE (short for Common Services Entity). In this use case, the lights
and smartphone each host an AE. Also an IN-CSE (short for Infrastructure Node CSE) is hosted in the
cloud by the oneM2M Service Provider and a MN-CSE (short for Middle Node CSE) is hosted on the
Home Gateway.
39
The oneM2M defined Mca reference point is used to interface an AE and CSE. The oneM2M
defined Mcc reference point is used to interface CSEs. In this use case, the Mca reference point is used
between the Light ADN-AEs and home gateway MN-CSE and between the Smartphone AE and IN-CSE.
The Mcc reference point is used between the home gateway MN-CSE and Cloud service platform IN-CSE.
In summary, applications used in the current use case are classified as follows:
• ADN-AE1: an application embedded in Light#1 with capabilities to control Light#1 and interact
with the home gateway MN-CSE through Mca reference point.
• ADN-AE2: an application embedded in Light#2 with capabilities to control Light#2 and interact
with the home gateway MN-CSE through Mca reference point
• IN-AE: a smartphone application embedded in the smartphone device with capabilities to
interact directly with the cloud service platform IN-CSE through Mcc reference point and
thereby remotely control Light#1 and Light#2.
• MN-AE: a gateway application embedded into the home gateway that interacts with MN-CSE
through Mca reference point.
ETSI M2M
ETSI Machine-to-Machine communications is an application agnostic standard containing an overall end
to end M2M functional architecture, identifying the functional entities and the related reference points.
It describes a resources-based architecture that can be used for the exchange of data and events
between machines involving communications across networks without requiring human intervention
The ETSI M2M High Level Architecture picture shows that this is a distributed system: the M2M Service
Capabilities are both at network level (M2M Service Capabilities in the Network Domain) and at local
level (M2M Service Capabilities in the M2M Gateway and in the M2M Device). These Service Capabilities
are the set of functionalities defined in the specification and are used to put in communication
applications among them; both network applications, and gateway and device applications. In essence
the goal of this architecture is "to provide the functionalities for the management of interactions
between entities (i.e. applications) involving communication across networks without requiring human
intervention" as it is described in the ETSI M2M definition of M2M.
40
In order to standardize the procedures that can be used for enabling these entities (i.e. applications) to
communicate the ETSI M2M specifications have defined a number of Reference Points and the
operations that can be used for this communication. These Reference Points are:
• mIa - M2M application interface: it is used by the Network Applications (NA) to communicate
with the Network Service Capability Layer (NSCL)
• dIa - Device application interface: it is used by the Device and Gateway Applications (DA and GA)
to communicate with the local service capabilities, i.e. Device Service Capability Layer (DSCL)
and Gateway Service Capability Layer (GSCL)
• mId - M2M to device interface: it is used for the inter-SCLs communication
41
The main operations that can be performed using these interfaces deal with the concept of M2M
Resource. A "resource" can be roughly described as a shared memory area that can be used for
exchanging data among applications. The resources can be created by an application within an SCL (at
network, gateway or device level), and can be read, updated, subscribed, notified, announced,
discovered, deleted by the same or other applications (provided they have the permissions to perform
the actions requested). Resources can be created and used freely across the ETSI M2M architecture.
Looking at the following example of a weather forecast system including applications and sensors, a
resource can be created by a Device or a Gateway Application at local level, in a GSCL (e.g. "temp"
resource) or in a DSCL (e.g. "pressure" resource), or it can be created at network level in the NSCL (e.g.
"average temp" or "humidity" resources). Network Applications can discover and access resources
created both at network level and at local level, and they can create resources too (e.g. "weather
forecast" resource).
42
munotes.in
OMA
OMA Lightweight M2M is a protocol from the Open Mobile Alliance for M2M or IoT device
management. Lightweight M2M enabler defines the application layer communication protocol between
a LWM2M Server and a LWM2M Client, which is located in a LWM2M Device. The OMA Lightweight
M2M enabler includes device management and service enablement for LWM2M Devices. The target
LWM2M Devices for this enabler are mainly resource constrained devices. Therefore, this enabler makes
use of a light and compact protocol as well as an efficient resource data model. It provides a choice for
the M2M Service Provider to deploy a M2M system to provide service to the M2M User. It is frequently
used with CoAP
OMA Lightweight M2M is designed to:
• Provide Device Management functionality over sensor or cellular networks
• Transfer service data from the network to devices
• Extend to meet the requirements of most any application
43
munotes.in

Tybscitsem 5 Archofiotunit 123

Uploaded by

Copyright:

Available Formats

Tybscitsem 5 Archofiotunit 123

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tybscitsem 5 Archofiotunit 123

Uploaded by

Copyright:

Available Formats

UNIT 1

IoT An Architectural Overview

1.1 Building an architecture

o An architecture can be described in several different views to capture specific properties

1.2 Main design principles and needed capabilities

three primary sources can been identified.

overall IoT architecture objective

1.3 An IoT architecture outline

Functional layers and capabilities of an IoT solution

1.4 Standards considerations

Architecture-State of the Art

European Telecommunications Standards Institute M2M/oneM2M

The technical committee consisted of representatives from telecom network operators,

ETSI M2M high-level architecture

ETSI M2M High-Level Architecture

The Network Domain contains the following functional/topological entities:

management of an M2M Device or Gateway is performed by specific M2M

ETSI M2M service capabilities

1. Application Enablement (xAE). The xAE service capability is an application facing

ETSI M2M interfaces

ETSI M2M resource management

International Telecommunication Union - Telecommunication sector view

Internet Engineering Task Force architecture fragments

a different part of the communication stack of a constrained device.

• modified Open Systems Interconnection (OSI) model

Open Geospatial Consortium architecture

2.3 IoT reference Model

A reference model describes the domain using a number of sub-models.

main component of an ARM is the Reference Architecture.

From reference to concrete architectures and actual systems.

IoT Reference Model.

2.4 IoT reference model

Model notation and semantics

• Sensors: These are simple or complex Devices that typically involve a

properties are extremely important when the interested Physical Entities

IoT-A Functional Model

o The Functional Model, as well as the Functional View of the Reference

2.4.4 Communication model

2.4.5 Safety, privacy, trust, security model

IoT Reference Architecture

2.6 Functional view

IoT Functional View.

Virtual Entity functional group

IoT process management functional group

Service Organization functional group

Security functional group

Management functional group

2.7 Information view

Information flow and lifecycle

Information exchange patterns

o Push: An FC A pushes the information to another FC B provided that the contact

2.8 Deployment and operational view

Parking Lot Deployment and Operational View, Devices.

2.9 Other relevant architectural views

3.0 IoT Data Link Layer and Network Layer Protocols:

3.1 physical (PHY) and MAC layer protocols

3.2 IEEE 802.15

3.4 IEEE 802.11

3.6 Bluetooth Low Energy