UNIT-5

SUB CODE: KOT 601

SUB NAME: IoT ARCHITECTURE AND PROTOCOLS
SYLLABUS
• Service Layer Protocols & Security : Service Layer -oneM2M, ETSI
M2M, OMA, BBF – Security in IoT Protocols – MAC 802.15.4 ,
6LoWPAN, RPL, Application Layer
oneM2M
• The Internet of Things (IoT) has enabled a wide range of connected
devices, sensors, and platforms to communicate with each other,
creating a network of interconnected devices.

• To achieve this interoperability and connectivity, a standardized

framework is required.

• The oneM2M standard is an initiative that aims to provide a common

platform for IoT devices and services to communicate with each
other.
oneM2M
• oneM2M is a global standard for Machine to Machine (M2M)
communications and the IoT.
• It was established in 2012, and it is based on the work of a number of
existing standards organizations.
• oneM2M provides a common framework for IoT devices, platforms,
and services to communicate with each other.
• The main goal of oneM2M is to ensure interoperability between
different IoT devices and services.
oneM2M
• oneM2M Architecture:
• The oneM2M architecture is based on a horizontal layering approach
that consists of four layers:
oneM2M
• oneM2M Architecture:
• Application Layer: The application layer is responsible for managing the IoT
applications and services that interact with the oneM2M platform.
• Platform Services Layer: The platform services layer provides a set of
common services that are used by IoT applications and services, such as
security, device management, and data management.
• Infrastructure Layer: The infrastructure layer provides the underlying
network and computing infrastructure required to support IoT applications
and services.
• Device Layer: The device layer consists of the IoT devices and sensors that
are connected to the oneM2M platform.
oneM2M
• Benefits of oneM2M in IoT:
• Interoperability: oneM2M provides a common platform for IoT devices and
services to communicate with each other, enabling interoperability
between different IoT devices and platforms.
• Scalability: oneM2M can support a large number of devices and services,
making it well suited for large-scale IoT deployments.
• Security: oneM2M provides a set of security mechanisms that can be used
to secure IoT communications and data.
• Flexibility: oneM2M is a flexible standard that can be adapted to different
IoT use cases and requirements.
• Global Reach: oneM2M is a global standard that can be used by IoT
deployments worldwide, ensuring compatibility between different regions
and countries.
oneM2M
• Limitations of OneM2M in IoT:
• Complexity: OneM2M's hierarchical architecture can be complex to
implement and maintain.
• Compatibility: OneM2M is not compatible with all IoT devices and
services, requiring the use of gateways or translators to translate
between OneM2M and other protocols.
• Adoption: OneM2M is a relatively new standard, and its adoption
may be limited in some industries.
oneM2M
• In conclusion, OneM2M is a promising standard for IoT applications,
offering several advantages such as interoperability, scalability,
security, and standardization. However, it also has some limitations,
particularly in terms of complexity, compatibility, and adoption.
Overall, OneM2M is well suited for IoT deployments where
interoperability, security, and scalability are critical, and where
additional security measures can be implemented to ensure secure
messaging.
ETSI M2M
• The Internet of Things (IoT) has gained significant attention in recent
years as it has become increasingly popular to use interconnected
devices to automate and optimize a variety of processes.
• To support this, a range of standards and protocols have been
developed to ensure interoperability and facilitate the development
of IoT applications. One of these standards is ETSI M2M.
• ETSI M2M is a standard developed by the European
Telecommunications Standards Institute (ETSI) to provide a common
platform for the interoperability of different IoT devices and services.
It is a set of specifications and guidelines that define the
requirements for M2M (machine-to-machine) communication.
ETSI M2M
• Features/Advantages of ETSI M2M:
• Interoperability: ETSI M2M provides a common platform for different IoT
devices and services to communicate with each other, regardless of the
underlying network technology.
• Scalability: ETSI M2M is highly scalable, enabling it to support a large
number of devices and services.
• Security: ETSI M2M provides built-in security features, including
authentication, authorization, and encryption.
• Device management: ETSI M2M provides a standardized way of managing
IoT devices, including registration, discovery, and configuration.
ETSI M2M
• Limitations of ETSI M2M in IoT:
• Complexity: ETSI M2M's specifications and guidelines can be complex
to implement and maintain.
• Compatibility: ETSI M2M is not compatible with all IoT devices and
services, requiring the use of gateways or translators to translate
between ETSI M2M and other protocols.
• Adoption: ETSI M2M is a relatively new standard, and its adoption
may be limited in some industries.
ETSI M2M
• ETSI M2M architecture
• The ETSI M2M architecture is designed to provide a standardized
framework for machine-to-machine (M2M) communications in the Internet
of Things (IoT). It is a layered architecture that defines the key components
and interfaces necessary for M2M communications. The ETSI M2M
architecture comprises the following layers:

• Application Layer: This layer includes the M2M applications that use the
ETSI M2M platform for communication. The applications communicate
with the platform using standard protocols, such as HTTP or CoAP, and use
ETSI M2M APIs to interact with other components of the architecture.
ETSI M2M
• ETSI M2M architecture
• Service Layer: This layer provides services to M2M applications, such as
device management, data management, and security. The services are
exposed as RESTful APIs, and applications can use them to manage and
interact with M2M devices.
• Network Layer: This layer provides connectivity for M2M devices, including
cellular networks, Wi-Fi, Ethernet, and others. The network layer also
includes gateways that provide translation between different network
technologies and protocols.
• Device Layer: This layer includes M2M devices that connect to the network
layer. The devices can be sensors, actuators, or other types of devices that
collect or act on data. The devices are managed by the service layer and
can be configured, monitored, and updated remotely.
ETSI M2M
• ETSI M2M architecture
• The ETSI M2M architecture also includes several interfaces that
enable communication between the layers. These interfaces include:
• M2M Service Interface: This interface provides access to M2M
services in the service layer.
• Device Management Interface: This interface enables the service layer
to manage M2M devices in the device layer.
• Application Service Interface: This interface enables M2M
applications to interact with the service layer.
• Network Service Interface: This interface provides access to network
services in the network layer.
ETSI M2M
ETSI Architecture
ETSI M2M
• ETSI M2M architecture
• The ETSI M2M architecture is designed to be modular and flexible,
allowing different components to be added or removed as needed. It
is also designed to be scalable and secure, with built-in security
features such as authentication, authorization, and encryption.
• Overall, the ETSI M2M architecture provides a comprehensive
framework for M2M communications in the IoT, enabling
interoperability, scalability, and security across different devices,
networks, and applications.
OMA
• OMA (Open Mobile Alliance) is a standards organization that develops
specifications for mobile and IoT devices.
• In the context of IoT, OMA has developed several standards that
define communication protocols, data models, and device
management techniques. These standards are intended to enable
interoperability between different IoT devices and platforms.
OMA
• Some of the key standards developed by OMA for IoT include:
• Lightweight M2M (LwM2M): This is a device management protocol
that enables remote management of IoT devices. It is designed to be
lightweight and efficient, making it suitable for use in constrained
environments. LwM2M defines a set of standard objects and
interfaces for device management, and it uses CoAP as its underlying
protocol.
• OMA DM (Device Management): This is a device management
protocol that is used in mobile devices and IoT devices. It enables
remote management of devices over various types of networks,
including cellular, Wi-Fi, and Ethernet. OMA DM defines a set of
standard objects and interfaces for device management, and it uses
HTTP or CoAP as its underlying protocol.
OMA
• Some of the key standards developed by OMA for IoT include:
• OMA Lightweight Machine-to-Machine (OMA LwM2M) Enabler: This
is a set of specifications that define a standardized framework for IoT
device management. It includes specifications for device
management, data management, and security.
• OMA LwM2M Enabler is designed to be scalable and flexible, allowing
it to support a wide range of IoT devices and applications.
• OMA SensorThings API: This is a standard API for IoT sensors and
devices that collect data. It provides a standardized way to access and
manage sensor data, making it easier to integrate data from different
sources. SensorThings API is based on RESTful principles and uses
JSON as its data format.
OMA
• The OMA architecture consists of several layers, each with a specific
function:
• Application layer: This layer contains the applications and services that run
on the IoT devices. The application layer interacts with the services
provided by the server layer.
• Server layer: This layer provides the services that manage and control the
IoT devices. The server layer consists of several components, including the
device management server, data management server, and security server.
• Gateway layer: This layer provides connectivity between the IoT devices
and the server layer. The gateway layer may include devices such as
routers, gateways, and access points.
• Device layer: This layer consists of the hardware and firmware that make
up the IoT devices. The device layer interacts with the services provided by
the server layer through the application layer.
BBF
• BBF (Broadband Forum) is a global consortium of over 100 industry
leading companies that develop and promote broadband network
technologies, including those related to the Internet of Things (IoT).
• The BBF's work in the IoT space is focused on defining standards and
best practices for connecting IoT devices to broadband networks,
enabling the development of more reliable, scalable, and secure IoT
solutions.
BBF
• The BBF's IoT work is organized around several key areas:
• Device management: The BBF's work in this area is focused on
developing standards and best practices for managing large numbers
of IoT devices connected to broadband networks. This includes
defining protocols for device discovery, configuration, firmware
updates, and diagnostics.
• Security: The BBF recognizes the importance of security in IoT
deployments and has developed a range of security standards and
best practices for IoT devices and networks. These include guidelines
for securing IoT devices, as well as protocols for secure
communication between devices and the network.
BBF
• Data analytics: The BBF is working to develop standards and best
practices for collecting, analyzing, and using data generated by IoT
devices. This includes developing standards for data formats,
protocols for data transfer and storage, and best practices for data
analytics and machine learning.
• Interoperability: The BBF is committed to promoting interoperability
between IoT devices and networks. This includes developing
standards for device interoperability, as well as protocols for
interoperable data exchange and communication.
BBF
• One of the BBF's key contributions to the IoT space is its Open Broadband
– IoT (OB-IoT) project, which aims to define a standardized architecture for
IoT deployments on broadband networks. The OB-IoT architecture consists
of several layers, each with a specific function:
• Device layer: This layer consists of the IoT devices themselves, as well as
the software and firmware that enable them to connect to broadband
networks. The BBF has developed standards and best practices for device
management, security, and data analytics in this layer.
• Gateway layer: This layer provides connectivity between IoT devices and
the broadband network. Gateways may be dedicated devices or integrated
into broadband modems or routers. The BBF has developed standards and
best practices for gateway management, security, and interoperability.
BBF
• Network layer: This layer includes the broadband network
infrastructure, including switches, routers, and other network
devices. The BBF has developed standards and best practices for
network management, security, and interoperability.
• Application layer: This layer includes the applications and services
that run on top of the broadband network, including cloud-based
services and analytics platforms. The BBF has developed standards
and best practices for application development, security, and
interoperability.
BBF
• The OB-IoT project is supported by a range of BBF members, including
network operators, equipment vendors, and service providers. The
project aims to accelerate the development and deployment of IoT
solutions on broadband networks, promoting interoperability,
security, and scalability.
• In addition to the OB-IoT project, the BBF is involved in a range of
other initiatives related to IoT, including the development of
standards and best practices for smart home networks, smart cities,
and industrial IoT deployments.
BBF
• Key standards and specifications developed by the BBF:
• TR-069 is a specification developed by the BBF for the management
of broadband networks. It provides a standard protocol for the
remote management of network devices, including IoT devices.
• TR-069 specification enables the management of devices over a wide
range of network types, including Ethernet, Wi-Fi, and cellular
networks. The specification supports a range of management
functions, including configuration, software updates, and
performance monitoring.
BBF
• Key standards and specifications developed by the BBF:
• The User Services Platform (USP) is a specification developed by the
BBF for the management of IoT devices. USP is designed to provide a
standard, secure, and scalable framework for the management of IoT
devices, including those that are deployed in homes and businesses.
• The USP specification is based on the TR-069 protocol and provides a
standardized framework for the management of IoT devices,
regardless of the type of network they are connected to.
• USP includes a range of management functions, including device
discovery, configuration, and software updates. It also includes
support for remote diagnostics, troubleshooting, and security
management.
BBF
• Key standards and specifications developed by the BBF:
• G.hn is a standard developed by the BBF for the provision of high
speed broadband services over any wired home network, including
powerline, coaxial, and telephone line networks.
• G.hn provides a standard protocol for the transmission of data over
these networks, enabling the delivery of high-speed broadband
services to IoT devices.
• The G.hn standard has been widely adopted by the industry and is
being used by many service providers to deliver broadband services
to homes and businesses.
BBF
• Key standards and specifications developed by the BBF:
• FAN (Fixed Access Network) is a specification developed by the BBF for the
management of broadband access networks. FAN provides a standardized
framework for the management of broadband access networks, including
those that are used for the delivery of IoT services.
• FAN includes a range of management functions, including network
discovery, topology discovery, and service discovery. It also includes
support for network security, device management, and service
management.
• FAN has been adopted by the industry and is being used by many service
providers to manage their broadband access networks. It is also being used
to manage IoT networks, providing a standardized framework for the
management of IoT devices.
BBF
• Key standards and specifications developed by the BBF:
• Open Broadband - Broadband Access Abstraction (OB-BAA)-OB BAA
is a specification developed by the BBF for the management of
broadband access networks.
• OB-BAA provides a standardized framework for the management of
broadband access networks, including those that are used for the
delivery of IoT services.
• OB-BAA includes a range of management functions, including
network discovery, topology discovery, and service discovery. It also
includes support for network security, device management, and
service management.
 Security in IoT Protocols – MAC 802.15.4
• The IEEE 802.15.4 specification uses Advanced Encryption Standard (AES)
with a 128-bit key length as the base encryption algorithm for securing its
data.
• Established by the US National Institute of Standards and Technology in
2001, AES is a block cipher, which means it operates on fixed-size blocks of
data.
• The use of AES by the US government and its widespread adoption in the
private sector has helped it become one of the most popular algorithms
used in symmetric key cryptography. (A symmetric key means that the
same key is used for both the encryption and decryption of the data.)
• In addition to encrypting the data, AES in 802.15.4 also validates the data
that is sent. This is accomplished by a message integrity code (MIC), which
is calculated for the entire frame using the same AES key that is used for
encryption.
 Security in IoT Protocols – MAC 802.15.4
• Enabling these security features for 802.15.4 changes the frame
format slightly and consumes some of the payload.
• Using the Security Enabled field in the Frame Control portion of the
802.15.4 header is the first step to enabling AES encryption.
• This field is a single bit that is set to 1 for security.
• Once this bit is set, a field called the Auxiliary Security Header is
created after the Source Address field, by stealing some bytes from
the Payload field.
Security in IoT Protocols – MAC 802.15.4
 Security in IoT Protocols – MAC 802.15.4
• The IEEE 802.15.4-2011 standard provides security services at the
MAC layer.
• The IEEE 802.15.4 standard support various security modes at the
MAC layer.
• The available security modes are distinguished by the security
guarantees provided and by the size of the integrity data employed.
Security in IoT Protocols – MAC 802.15.4
 Security in IoT Protocols – MAC 802.15.4
• Fig. illustrates the application of security to an IEEE 802.15.4 link-layer
data frame. A protected frame is identified by the Security Enabled Bit
field of the Frame Control field being set at the beginning of the
header.
 Security in IoT Protocols – MAC 802.15.4
• The Auxiliary Security Header is employed only when security is used,
and identifies how security is applied to the frame.
• In the Auxiliary Security Header, the Security Control field identifies
the Security Level mode from the modes identified in Table I, and how
the cryptographic key required to process security for the link-layer
frame is to be determined by the sender and receiver.
• The standard employs 128-bit keys that may be known implicitly by
the two communication parties, or on the other end determined from
information transported in the Key Source and Key Index subfields of
the Key Identifier field.
• The Key Source subfield specifies the group key originator, and the
Key Index subfield identifies a key from a specific source.
 Security in IoT Protocols – MAC 802.15.4
• Fundamental security requirements are assured by security at the
MAC by:
• Confidentiality: Security as currently defined by IEEE 802.15.4 is
optional, given that an application may opt for no security or for
security at others layers of the protocol stack. For applications
requiring only confidentiality of link layer communications, the
transmitted data may be encrypted using AES (Advanced Encryption
Standard) in the Counter (CTR) mode.
• Data Authenticity and Integrity: Applications requiring authenticity
and integrity of link-layer communications may use one of the
security modes employing AES in the Cypher Block Chaining (CBC)
mode, which produces a Message Integrity Code (MIC) or Message
Authentication Code (MAC) appended to the transmitted data.
 Security in IoT Protocols – MAC 802.15.4
• Fundamental security requirements are assured by security at the
MAC by:
• Confidentiality, Data Authenticity and Integrity: The CTR and CBC
modes may be jointly employed using the combined Counter with
CBC-MAC AES/CCM encryption mode, which in IEEE 802.15.4 is used
to support confidentiality as well as data authenticity and integrity for
link-layer communications.
 Security in IoT Protocols – 6LoWPAN
• No security mechanisms are currently defined in the context of the
6LoWPAN adaptation layer, but the relevant documents include discussions
on the security vulnerabilities, requirements and approaches to consider
for the usage of network layer security.
• 6LoWPAN by itself does not offer any mechanisms for security. However,
relevant documents include discussion of security threats, requirement and
approach to consider in IoT network layer.
• For example, RFC 4944 discusses the possibility of duplicate EUI-64
interface addresses which are supposed to be unique [RFC4944]. RFC 6282
discusses the security issues that are raised due to the problems
introduced in RFC 4944 [RFC6282]. RFC 6568 addresses possible
mechanisms to adopt security within constrained wireless sensor devices
[RFC6568]. In addition, a few recent drafts in [6Lo] discuss mechanisms to
achieve security in 6loWPAN.
 Security in IoT Protocols – RPL
• The RPL specification defines secure versions of the various routing
control messages, as well as three basic security modes.
• Fig. illustrate the format of a secure RPL control message,
transporting a Security field after the 4-byte ICMPv6 message header.

Secure RPL control message

 Security in IoT Protocols – RPL
• The high order bit of the RPL Code field identifies whether or not
security is applied to a given RPL message, which may thus be a
secure DIS, DIO, DAO or DAOACK message.
• The format of the Security field is illustrated in Fig.

Security section of a secure RPL control message

 Security in IoT Protocols – RPL
• The information in the Security field indicates the level of security and
the cryptographic algorithms employed to process security for the
message.
• What this field doesn’t include is the security—related data required
to process security for the message, for example a Message Integrity
Code (MIC) code or a signature.
 Security in IoT Protocols – RPL
• Support of Integrity and Data Authenticity: The current RPL
specification defines the employment of AES/CCM with 128-bit keys
for MAC generation supporting integrity, and of RSA with SHA-256 for
digital signatures supporting integrity and data authenticity.
• The LVL (Security Level) field indicates the provided packet security
and allows for varying levels of data authentication and, optionally, of
data confidentiality.
 Security in IoT Protocols – RPL
• Support of Semantic Security and Protection Against Replay Attacks:
A Consistency Check (CC) control message enables a sensing node to
issue a challenge-response with the goal of validating another node’s
current counter value.
• Semantic security and protection against packet replay attacks is
provided with the help of the Counter field, which may be used to
transport a timestamp, as indicated by the T
 Security in IoT Protocols – RPL
• Security Modes in RPL: As previously discussed, RPL defines how
security is applied to routing control messages, and the current
specification also defines the following three security modes:
• Unsecured: in this mode no security is applied to routing control
messages, and this is the default usage mode of RPL.
• Preinstalled: this security mode may be employed by a device using a
preconfigured symmetric key in order to join an existent RPL instance,
either as a host or a router. This key is employed to support
confidentiality, integrity and data authentication for routing control
messages.
 Security in IoT Protocols – RPL
• Security Modes in RPL:
• Authenticated: this security mode is appropriate for devices
operating as routers. A device may initially join the network using a
preconfigured key and the preinstalled security mode, and next
obtain a different cryptographic key from a key authority with which it
may start functioning as a router. The key authority is responsible for
authenticating and authorizing the device for this purpose.
 Security in IoT Protocols – Application Layer
• Application-layer communications are supported by the CoAP
protocol, currently being designed by the Constrained RESTful
Environments (CoRE) working group of the IETF.

• A. Application-Layer Communications With CoAP The CoAP protocol

implements a set of techniques to compress application layer
protocol metadata without compromising application inter-
operability, in conformance with the representational state transfer
(REST) architecture of the web.
 Security in IoT Protocols – Application Layer
• The CoAP Protocol defines bindings to DTLS (Datagram Transport-
Layer Security) to secure CoAP messages, along with a few mandatory
minimal configurations appropriate for constrained environments.
Support for Confidentiality, Authentication, Integrity, NonRepudiation
and Protection Against Replay Attacks.
• The adoption of DTLS implies that security is supported at the
transport-layer, rather than being designed in the context of the
application-layer protocol. DTLS provides guarantees in terms of
confidentiality, integrity, authentication and non-repudiation for
application-layer communications using CoAP. DTLS is in practice TLS
with added features to deal with the unreliable nature of UDP
communications.
 Security in IoT Protocols – Application Layer
• Fig. illustrates the availability of payload space for applications in IEEE
802.15.4 and 6LoPWAN communication environments in the
presence of CoAP and DTLS. Once the initial DTLS handshake is
completed, DTLS adds a limited per-datagram overhead of 13 bytes,
not counting any initialization vectors