Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -

Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

भारतीय मानक IS 18004 (Part 1) : 2021

Indian Standard

आई ओ टी सिस्टम
भाग 1 रेफेरेंस आर्कि टे क्चर

IoT System
Part 1 Reference Architecture

ICS 35.020

© BIS 2021

भारतीय मानक ब्रयू ो

B U R E A U O F I N D I A N S TA N D A R D S
मानक भवन, 9 बहादरु शाह ज़फर मार्ग, नई िदल्ली – 110002
MANAK BHAVAN, 9 BAHADUR SHAH ZAFAR MARG
NEW DELHI-110002
         www.bis.gov.in  
www.standardsbis.in

June 2021  Price Group 9

 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

Smart Infrastructure Sectional Committee, LITD 28

FOREWORD
This Indian Standard was adopted by the Bureau of Indian Standards, after the draft finalized by the Smart
Infrastructure Sectional Committee, had been approved by the Electronics and Information Technology Division
Council.
In the formulation of this standard, considerable assistance has been derived from the following publications:
a) ISO/IEC 30141 : 2018 Internet of Things (IoT) — Reference Architecture
b) ITU-T Y.3056 Framework for bootstrapping of devices and applications for open access to trusted
services in distributed ecosystems
c) TEC 30001 : 2020 oneM2M Functional Architecture
d) TEC-TR-SN-M2M-009 – Release 01 Recommendations for IoT / M2M Security (Technical report)
The IoT Concept Model Diagram and Definitions used in this document are adapted from the ISO/IEC 30141,
the Functional Architecture has been adapted from ITU-T Y.3056, and The Common Service Layer architecture
has been adapted from the TEC 30001 : 2020. The Classification of Use Cases (Cl 8.2.2) is derived from
TEC-TR-SN-M2M-009.
The IoT Reference Architecture described in this Standard aims to fulfil the broad requirements identified
in IS 18004-6 Functional Requirements of IoT Systems (under development) and TEC 30002 : 2020
oneM2M-Requirements.
The Department of Telecommunications, Ministry of Communications, Government of India vide Gazette
Notification No. G.S.R. 1131(E) dated 5th September, 2017 has amended the Indian Telegraph Rules, 1951
(Amendment 2017) to introduce Mandatory Testing & Certification of Telecom Equipment (MTCTE). As per
MTCTE, every telecom equipment must undergo mandatory testing and certification before its sell or import.
The requirements for the security management (8.2) has been set to fulfil the requirements for the MTCTE.
The Composition of the panel, LITD 28/P9 and the sectional committee, LITD 28 responsible for the formulation
of this standard is given at Annex C.
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Contents

 Pages

0 INTRODUCTION ... iii

0.1 Background ... iii
0.2 Motivation & Objectives ... iii

1 SCOPE ... 1

2 REFERENCES ... 1

3 TERMINOLOGY, SYMBOLS AND ABBREVIATIONS ... 1

3.1 Terminology ... 1
3.2 Abbreviations ... 1

4 OVERVIEW ... 1
4.1 IoT Concept Model ... 1
4.2 IoT Reference Model ... 2
4.3 IoT Reference Architecture ... 2

5 IOT CONCEPT MODEL ... 2

6 IOT REFERENCE MODELS ... 4

6.1 Domain Based Reference Model ... 4
6.2 Entity based IoT reference model ... 5

7 IOT REFERENCE ARCHITECTURE ... 6

7.1 IoT Architecture Layers and Planes ... 6
7.1.1 Physical Layer ... 6
7.1.2 Network Layer ... 6
7.1.3 Common Service Layer ... 6
7.1.4 Application Layer ... 7
7.1.5 Functional Plane ... 7
7.1.6 Data and Security Management Plane ... 7
7.1.7 Standards, Certification and Compliance Plane ... 8
7.2 IoT Functional Architecture ... 8
7.3 Entity based components and functional blocks ... 9
7.4 Sematic Interoperability ... 9
7.5 Functional description of the Semantics CSF ... 9

8 IOT DEPLOYMENT VIEWS ... 10

8.1 General ... 10
8.1.1 IoT Role Based View ... 10
8.1.2 IoT System Deployment View ... 10

i
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

 Pages

8.2 IoT Security Management View ... 12

8.2.1 End point security and classification ... 13
8.2.2 Classification of Use Cases ... 13
8.2.3 Authentication and Authorization framework ... 15
8.2.4 Trust framework ... 15

ANNEX A USE CASE BASED REQUIREMENT CATEGORISATION ... 16

ANNEX B BROAD FUNCTIONAL REQUIREMENTS ... 17

ANNEX C COMMITTEE COMPOSITION ... 18

BIBLIOGRAPHY ... 21

LIST OF FIGURES
Fig. 1 The progression of the IoT Ecosystem Standard ... 2
Fig. 2 IoT Concept Model [Source: ISO/IEC 30141] ... 3
Fig. 3 Domain based IoT reference Model ... 5
Fig. 4 Entity based IoT Reference Model ... 6
Fig. 5 IoT Service Layer Architecture ... 7
Fig. 6 IoT Functional Architecture ... 8
Fig. 7 IoT Role Based View ... 11
Fig. 8 IoT System Deployment View ... 11
Fig. 9 Node based Deployment Architecture View ... 12
Fig. 10 End point device identity and security assurance ... 14
Fig. 11 IoT/ M2M Identification, Authentication and Authorization ... 15
Fig. 12 Trust Centre framework ... 15

LIST OF TABLES
Table 1 Functions of Common Service Layer ... 9
Table 2 Classification of IoT Devices ... 16

ii
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

0 INTRODUCTION systems involved with performing towards the ICT RA

specifications. The IoT RA focuses on the three key
0.1 Background principles enshrined in the ICT RA, namely:
The Internet of Things (IoT) or Machine to Machine a) Interoperability — Refers to the ability of
(M2M) ecosystem generally comprises of devices diverse systems and components to work
and/or sensors which generate information in the together, even as parts from diverse set of
form of data which flows through various electronic suppliers are substituted and integrated;
communication means to a set of Digital Infrastructure b) Composability — Refers to the ability to
for storing, forwarding, analysis, and subsequent combine discrete components into a complete
actions by humans or machines including actuators. system to achieve a set of goals and objectives;
and
0.2 Motivation & Objectives
c) Harmonization — Refers to achieving
IoT is considered to be a significant element of the digital compatibility between technologies and
infrastructure and is an integral part of the ‘Unified systems, even when they at first appear
digital infrastructure ICT Reference Architecture incompatible.
(ICTRA) defined in IS 18000. Therefore, it is necessary
The Standard is useful for anyone involved in the
to provide a special focus on the standardization of the
design, development, deployment, and implementation
IoT Ecosystem.
or certification of an IoT device, network or application
This Standard recommends a blueprint for realizing the ecosystem. Further, the IoT Reference Architecture
digital infrastructure required for scalable, secure and assists in obtaining the objectives of IS 18000,
globally interoperable IoT solutions. The IoT Reference which are to provide a unified digital infrastructure
Architecture described in this Standard includes a architecture that can serve as a template for both the
concept model, reference models, architectures and city administrators and those who are the consumers
deployment views, along with references to global of such IoT and ICT based solutions, as well as the IoT
standards and specifications, such as to facilitate an and ICT solution providers who develop and deploy
orderly proliferation of the IoT Ecosystem. such solutions.

A significant other motivation is to ensure that the

IoT sub-systems seamless integrate with the sub-

iii
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

This page has been intentionally left blank

 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Indian Standards
IOT SYSTEM
PART 1 REFERENCE ARCHITECTURE

1 SCOPE 3 TERMINOLOGY, SYMBOLS AND

ABBREVIATIONS
This Indian Standard describes the Internet of Things
(IoT) Reference Architecture, that comprises IoT 3.1 Terminology
Concept Model, IoT Reference Models (Domain based For the purpose of this standard, the definitions given in
IoT reference model, Entity based IoT reference model) IS 18000 : 2020 and ISO/IEC 30141 shall apply.
and IoT Deployment Views.
3.2 Abbreviations
IoT Concept Model and Reference models elaborate
the interactions between various entities, both digital API Application Programmable Interface
and non-digital. CSF Common Service Function
2 REFERENCES FA Functional Architecture
IoT Internet of Things
The standards given below contain provisions which,
JSON JavaScript Object Notation
through reference in this text, constitute provisions of
this standard. At the time of publication, the editions M2M Machine-to-Machine
indicated were valid. All standards are subject to OTP One-time-password
revision, and parties to agreements based on this
standard are encouraged to investigate the possibility RA Reference Architecture
of applying the most recent editions of these standards.’ RM Reference Model
IS 18000 : 2020 Unified Digital Infrastructure ICT SEM CSF Semantics (SEM) Common Service
Reference Architecture Function
IS 18002 Unified Digital Infrastructure SP Service Provider
(Part 1) : 2021 Data Layer Part 1 Reference TSP Telecommunications Service Provider
Architecture XML Extensible Markup Language
ISO/IEC 30141 Internet of Things (loT) -
Reference Architecture
4 OVERVIEW
TEC 30001 : oneM2M Functional Architecture
2020 Internet of Things (IoT) refers to a vast and growing
collection of devices and applications that are
TEC 30003 : oneM2M-Security Solutions connecting every part of our lives today. The IoT use
2020 cases are spread into smart city, smart grid, smart home
TEC 30004 : oneM2M-Service Layer Core and building, digital agriculture, smart manufacturing,
2020 Protocol intelligent transport system, e-Health etc. IoT is a
TEC 30009 : oneM2M-HTTP Protocol Binding general reference to many enabling technologies
2020 including sensing, networking, communications, data
management, control, analytics etc. The IoT Reference
TEC 30010 : oneM2M-MQTT protocol binding Architecture described in this standard comprises a set
2020 of models, architectures and views, the overall structure
TEC 30015 : oneM2M-Testing Framework of which is depicted in Fig. 1.
2020
4.1 IoT Concept Model
TEC 30020 : oneM2M-WebSocket Protocol
2020 Binding The IoT concept model is an abstract, implementation
ITU-T Y.3056  ramework for bootstrapping
F independent representation of the actors, entities,
(2021) of devices and applications for interactions and enforcements required for
open access to trusted services in supporting the requirements and use cases in the IoT
distributed ecosystems ecosystem.

1
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 1 The progression of the IoT Ecosystem Standard

4.2 IoT Reference Model b) IoT System Deployment View

The IoT reference model describes the important c) IoT Security Management View
domains and the entities within the domains. It also 5 IOT CONCEPT MODEL
presents the three types of interactions between the
domains that are important to the IoT ecosystem: For the IoT Conceptual Model, reference is drawn
human-machine interactions, machine-machine towards ISO/IEC 30141 : 2018, 8.3 providing the high
interactions and inter-domain interactions. Two level IoT Concept Model which describes the common
approaches have been adopted while arriving at the structure and definitions for describing the concepts,
IoT Reference Model namely Domain based Reference relationships, and behaviour within an IoT system.
Model and Entity based Reference Model. The primary objective of the IoT concept Model is
to provide a common structure and definitions for
4.3 IoT Reference Architecture
describing the concepts of, and relationships among,
The IoT Reference Architecture is described through the entities within IoT systems.
the IoT Functional Architecture and the IoT Service
The IoT Concept Model benefits the emerging
Layer Architecture.
requirements from a wide array of Use Cases belonging
4.4 IoT Deployment Views to an ever growing industrial, home and governmental
sectors as well as Smart City use cases covering
For the implementation of the IoT System, the IoT Safety and Surveillance, Health, Education, Energy,
Reference Architecture needs to be realised using clear Utilities, Transportation, Governance, Sustainability
definitions of the roles, the subsystems which include and Buildings. It aims to be generic, abstract and
the device and data management subsystems and also simple in order to address the various IoT use cases in a
the security management system. A set of deployment standardised manner across all vertical domains.
views are provided to assist the implementation of
the IoT system using the IoT Reference Architecture. The IoT Concept Model shown in Fig. 2 presents the
The following deployment views are provided in the relationships between the entities, including Digital
document: Entities and their Physical Entities. It also illustrates
how things and services collaborate via the network.
a) IoT Role Based View

2
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 2 IoT Concept Model [Source: ISO/IEC 30141]

An Entity is anything (both physical and non-physical) electronic appliances to closed or open environments. A
that has a distinct and independent existence. Every Physical Entity is a specialization of entity. A Physical
entity has a unique identity. Entity can contain other physical entities.
A Digital Entity is a computational or data element of An IoT-User is a user of an IoT system, which can
an IoT system. These elements include applications, be human or non-human. An IoT-User is part of an
services, virtual entities, data stores, IoT devices and IoT system. An IoT-User is a specialization of entity
IoT gateways. A Digital Entity is a specialization representing a human user or digital user.
of Entity. A Digital Entity can contain other Digital
Entities. A Network is the infrastructure that connects a set
of Digital Entities, enabling communication of data
A Physical Entity is a discrete, identifiable and between them. A network is a specialization of entity.
observable part of the physical environment.
Physical Entities can be almost any physical object Most entities in IoT, especially Physical Entities
or environment; from humans or animals to cars; (“things”), have an Identity. An Identifier is a set of
from store or logistics chain items to computers; from attributes of the entity that can be used to uniquely

3
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

identify the entity in a context. An entity can have more The Concept Model also addresses the Field Security
than one identifier, but it requires at least one unique Management requirements given in clause 8.11.6 of
identifier within any Identity Context through which it IS 18000, which requires that the IoT devices
can be accessed. For example, the identity information are genuine, the firmware and/or software are not
from a tag can be used as an identifier to identify the compromised and that they are authenticated, authorized
Physical Entity to which it is attached. and managed using security keys so as to be protected
against cyber-attacks throughout the lifecycle.
Entities which interact via networks do so by exposing
one or more endpoints on a network. A network 6 IOT REFERENCE MODELS
connects endpoints. A Service exposes one or more
endpoints by which it can be invoked. An endpoint has 6.1 Domain Based Reference Model
one or more network interfaces. Services, which are
located remotely, can be reached by endpoints through The IoT Domain based Reference Model (RM)
network interfaces across a communication network. depicted in Fig. 3 is shown as a set of entities within
Endpoints exist on one or more networks. well-defined domains which interact with each other
whilst being governed by a set of Policy, Regulatory,
A Service is a set of distinct capabilities provided Governmental Guidelines, and Standards.
through a defined interface. A service can be composed
of other services. A service is typically implemented as In order to provide a sustainable, interoperable,
software. A service defines network interfaces and is standardised and scalable framework for the
exposed by an endpoint. A service interacts with other proliferation of the IoT Use Cases, these concept model
entities via one or more networks. A service may or envisages the need for IoT Reference Models which can
may not be used to develop implementation models for various
use cases across sectors.
a) interact with IoT gateways or IoT devices
b) interact with other services The Entities in the Domain based IoT RM represent both
Physical and Digital entities as they form a relationship
c) use data stores
with each other including the devices, networks,
Data associated with services, IoT devices and with IoT platforms and applications as illustrated in Fig. 3. Though
gateways can be held in a Data Store used by one or Fig. 3 depicts the interactions between domains, the
more entities. actors and entities have however been shown here
within the domains for exemplification.
An Application is a software entity or system that
offers a collection of functions and solutions designed The following domains are important from the
to help IoT users perform particular tasks or to handle perspective of a standardised IoT Ecosystem:
particular types of IT problems. An application can use a) Device / Network Domain
one or more services. An application can be used by
b) Consumer Domain
a human user (via a human-machine interface (HMI))
or by a digital user (via an API). The Services and c) Provider Domain
Applications are illustrated in the Reference Models d) Service / Application Domain
described in 6.1 (see Fig. 3). e) Standards / Policy / Regulatory / Governance
An interface is defined as a named set of operations that Domain
characterize the behaviour of an entity and is specifically f) Trust Establishment, Registration, Certification
a set of operations and associated parameters which can Domain
be used by one Digital Entity to request actions from
It acknowledges the existence of multiple entities,
another Digital Entity.
including but not limited to Device Manufacturer, App
The Concept Model also addresses the OT Asset Developer, Device or App Buyer, Device or App User,
Management as given in clause 8.11.2 of IS 18000, Various Service Providers, System Integrators, Trust
which requires that the management of all IT or non-IT Providers, Regulators, Registration and Certification
field device should be protected and managed. Every Authorities and Application Verticals etc.
such device should be easily identifiable through a well-
In Fig. 3, the horizontal domains have been depicted
defined asset tagging mechanism, maintained in an
using rectangular shapes with rounded edges having
asset registry using the asset tag as the key, identifying
dotted boundaries. The two vertical domains have
asset ownership and custodian. The registry must
been represented using sharp edged rectangles with
maintain the entire lifecycle of the asset, right from its
dotted boundaries. The horizontal domains are more or
procurement, installation, maintenance to disposal of a
less specific to the actors or entities depicted therein
device.
and have interactions with more than one domain.

4
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 3 Domain based IoT reference Model

The vertical domains are the ones which encompass contained within the individual domains. The
the entire IoT ecosystem and are mainly driven by arrows depicting these interactions, therefore,
standards, policy, regulatory frameworks, governance do not cross the domain boundary and that
etc. There are two pillars shown at the two sides of the signifies that the interactions are between the
diagram which germinate from the model contained entirety of the domains.
within. They are:
6.2 Entity based IoT reference model
a) IoT Reference Architecture
b) IoT Deployment Views The entity based IoT Reference Model is shown in
Fig. 4. While the Domain based IoT Reference Model
The following three types of interactions are used in described the domains from the perspective of HMI,
Fig. 3: M2M and D2D interactions, it is also necessary to
a) Human to Machine Interaction (HMI) — consider the physical and digital entities and the
These are mainly the interactions between interactions between them. The concept of layers is
human entities with machines or subsystems. introduced in this description in the following way:
The arrows depicting these interactions cross a) Users or Application Layer — This layer
the domain boundary which signifies that the contains the State/Corporate Entity, Consumer
interactions are between the actors and/or Entity and Governance Entity
entities within a specific domain to other actors b) Services Layer — This layer contains the IoT/
and/or entities. M2M Data Management Entity and IoT/M2M
b) Machine to Machine Interaction (M2M) — Service Entity
These are the interactions between machines/ c) Network Layer — This layer contains the
subsystems mainly between the actors or various Network Entities of an IoT ecosystem
entities of the Device/Network Domain and namely Public Network, M2M Area Network
the Service/Application Domain. The arrows (also known as Personal Area Network) and
depicting these interactions also cross the Captive Network.
domain boundary signifying such interactions.
d) Physical Layer — This layer contains the
c) Domain to Domain Interaction (D2D) — physical Entities that are Sensors/Actuators
These are the interaction between the domains and IoT/M2M Devices/Gateways
and does not indicate any specific actor or entity

5
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 4 Entity based IoT Reference Model

The layers, along with the related entities, cut across 7.1 IoT Architecture Layers and Planes
and operate at three planes, namely:
Fig. 5 shows an abstract view of the IoT Reference
a) IoT/M2M Functional Plane, Architecture that comprises four layers. It also
b) IoT/M2M Standards Certification and demonstrates the interaction between the different
Compliance Plane layers both at the horizontal and vertical level.
c) IoT/M2M Data and Security Management The architecture is technology agnostics such
Plane that it gives guidance to architect an IoT System.
Each layer of the IoT Reference Architecture
7 IOT REFERENCE ARCHITECTURE is explained as below.
7.1.1 Physical Layer
The IoT Reference Architecture (IoT RA) is derived
from the two reference models described in 6 which Consists of “things” that have independent existence
described the Domains, Entities and their interactions. and consists of sensors, actuators, gateway devices
that capture the real time and offline data from the
The IoT System implemented in the city shall adhere environment.
to the Unified Digital infrastructure (UDI) properties
defined in IS 18000 and the data principles defined in 7.1.2 Network Layer
Table 1 of IS 18002.
This layer encapsulates the different communication
The various layers and planes described in 6 are further technologies and protocols that constitute an IoT
detailed in a layered architecture. The IoT Reference Network as suggested by the domain-based reference
Architecture is created from a deployment perspective, model mentioned in 6.1.
it provides for the implementation of the individual
7.1.3 Common Service Layer
components and the interaction between the different
layers. Each layer talks to the other layer as shown in As the name suggests, this layer is the common service
Fig. 5 below without ignoring any one of them. Each of utility layer for the IoT platform. All the necessary
the layers is technology agnostic. functions of any IoT Ecosystem is contained here that

6
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

can be provided as a service. These are called Common Plane provides the management aspect of the entire IoT
Service Functions (CSFs). Example of such Common ecosystem be it the Digital Infrastructure Management,
Service Functions are registration and authorization; Agreements, Contracts, Workflow Management etc.
secured data exchange; location services; notification The ‘Reliability’ of an IoT System, which is the ability
and event detection services; data storage and data to perform the intended function in the prescribed
exchanges; and Semantics (This module enable conditions for a specific period of time that can be
applications to manage semantic information and measured in various metric form such as Quality of
provide functionalities based on this information). Service, Availability of Service etc. is one of the key
Refer TEC 30001 : 2020, TEC 30004 : 2020, and deliverables of this plane and that cut across all the
TEC 30003 : 2020 for the Common Service Layer and components of all the four layers.
its constituent Common Service Functions.
7.1.6 Data and Security Management Plane
This layer provides the APIs to access the physical
entities and exchange data between the physical entities. Data and Security Management Plane covers the
aspects of Security and its association with Data that
7.1.4 Application Layer is generated by the IoT Ecosystem. Security in the IoT
Ecosystem has another dimension in the perspective of
This Layer encapsulates the components which are Safety. Safety in IoT parlance is defined as a condition
providing the interfaces or visualisation which enables in which the IoT System operates without causing any
the Human to Machine Interactions. The Digital injury or damage to human health either directly or
Entities which add meaning to the things are contained indirectly or posing any risk to the environment Safety
in this layer that may also provide user interfaces that is a major concern for the IoT systems not only with
act as a dashboard for the end users and interacts with respect to the human beings but also to other living
the Common Service Layer. beings and environment as it interacts and applies
7.1.5 Functional Plane control mechanism for the physical world. Safety can
not be compromised at any entity starting from the
The said four layers perform the functions on any or all physical entity to the application entity. A wrong data
of the three planes depicted in Fig. 5. The Functional captured by a physical entity can lead to wrong control

Fig. 5 IoT Service Layer Architecture

7
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

mechanism at the application levels and may lead to 7.2 IoT Functional Architecture
safety issues not only to human lives but also to the
environment where the IoT system is operating. The IoT Functional Architecture (FA) is shown in
Fig. 6. The IoT FA is derived from TEC 30001 :
Similar to the Cybersecurity ecosystem, the Security 2020, and in alignment with TEC 30004 : 2020 and
of an IoT System can be defined as the condition in TEC 30003 : 2020. The IoT FA defines five nodes
which there is no compromise of data while flowing in (see note), five functions and four reference points.
or out of the IoT System. This includes the information The reference points are called RPa, RPc, RPn and
systems involved, the physical systems, and the are further suffixed with numerals to show the distinct
controlling systems. interfaces between nodes.
Information Security is the major threat in the context a) RPa is the reference point between the
of the IoT System. IoT Systems pose a big challenge in Application Functions and Common Service
terms of Information Security as they are distributed Functions.
and connected and hence create a big challenge as b) RPd is the reference point between the cyber-
there may be a huge number of IoT systems installed physical device and common service function.
in the network. Any compromise in one of the IoT c) RPc is the reference point between two
systems makes the complete network vulnerable. common service functions within a realm
The main objective to have Safety and Security d) RPo is the reference point between two
across the IoT Reference Architecture is to ensure the common service functions outside each other’s
Confidentiality, Integrity and Availability of the IoT realm
Systems.
C2 is the reference point between two common service
7.1.7 Standards, Certification and Compliance Plane functions and N1 is the reference point between device
Standards, Certification and Compliance Plane binds functions and network functions. All four functions
all the components of the IoT ecosystem with the will interact with each other based on these reference
standards, its certification methods and compliance when points. There is another block parallel to the common
it is mandated or recommended. The policies, regulations service function that may be called a supporting/utility
and legal aspects are all covered under this plane and function block that only interacts with the CSF and
thus establishes a framework that binds the entire this supporting /utility function is out of the scope of
ecosystem. the IoT RA.

Fig. 6 IoT Functional Architecture

8
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

7.3 Entity based components and functional blocks of the data. However, as there are several ontologies
for describing each distinct Thing, we need semantic
Table 1 lists out the different functions of Common interoperability mechanisms to perform common data
Service Layer with a brief explanation. mapping across the various utilized formats (e.g. XML
or JSON) and ontology alignment.
7.4 Sematic Interoperability
7.5 Functional description of the Semantics CSF
In the IoT ecosystems, the various devices and
applications operate without adequate compatibility with The architectural model assumed in this standard is
products from different manufacturers. For example, based on the generic architecture for the Common
Smart Street Light application provided by one vendor Service Layer in Fig. 5. The core functionality
does not work seamlessly with the lights provided by supporting semantics resides at various common
another vendor. This leads to a vendor locked-in siloed service entities, providing services to the application
environment. standards resolve this issue by enabling entities interacting with other common service
horizontal and vertical communication, operation, and entities.
programming across devices and platforms, regardless
of their model or manufacturer. Though standardised The Semantics (SEM) Common Service Function
common service layer solves this problem to a great (CSF) enables semantic information management
extent in order to utilize the full potential of the and provides the related functionality based on
interoperable IoT ecosystem, standardised semantic this semantic information. The functionality
annotations, mashups and semantic reasoning is of this CSF is based on semantic descriptions.
necessary. The commonly agreed information models This functionality is also enabled by other, more
and ontologies for the data produced by the IoT devices, generic, resources and procedures described in
that are processed by the interfaces or are included in TEC 30001 : 2020 and further referenced in this
the exchanged data can provide the required meaning specification. The main features of the SEM CSF

Table 1 Functions of Common Service Layer

Sl Functions Description
No.

1 Registration (REG) This function will enable the registration of the Applications (and each instance of the
application) with the CSF
2 Discovery (DIS) This function allows the application to discover the resources (devices as well as
applications) within the CSF
3 Security (SEC) This module ensures security of the data as well as communication
4 Group Management (GM) CSF allows the application to create groups for different IoT devices to initiate a
common action for the group
5 Data Management and Repository (DMR) This block manages the storage of data within the CSF and facilitates data exchange
within the applications
6 Subscription and Notification (S&N) The module is responsible for notifying applications about data arrival or events. The
individual application needs to subscribe for such notification.
7 Device Management (DM) This module is responsible for the management of devices based on different
technologies such as TR069, LWM2M, OMA-DM
8 Application and Service Management The management of applications and service subscriptions is done by this module
(ASM)
9 Location (LOC) The location services and data management are taken care by the Location entity in
the CSF
10 Network Service Exposure (NSE) This module facilitates the IoT System to choose the optimal network for application
& device triggering.
11 Communication Management and The module is responsible for the frequency and the channels of the communication
Delivery Handling (CMDH) taking place in the IoT System.
12 Service Charging & Accounting (SCA) This module is responsible for providing charging data for billing and accounting
purpose.
13 Transaction Management (TM) This module takes care of the scheduling of a transaction, locking and unlocking of
resources targeted by a transaction.

9
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

are listed in clause 10.2.14 of TEC 30001 : 2020 to end IoT Services including devices,
and further detailed in 6 and 7 of this standard. The connectivity and applications, undertakes
SEM CSF includes specialized functional blocks such the custodian KYC, provisions the
as SPARQL engine, repositories for ontologies and IoT/M2M Services for retail, enterprise
semantic descriptions, which may be implemented via and government beneficiaries.
permanent or temporary Semantic Graph Stores, etc. 2) Operates the IoT/M2M Services.
8 IOT DEPLOYMENT VIEWS d) The Network Service Provider fulfils all of the
following criteria:
8.1 General 1) Provides Connectivity and related services
for IoT/M2M Service Providers.
In order to implement the IoT System following the
IoT Reference Architecture, it is important to describe 2) Operates an Underlying Network. Such
and understand the roles which are necessary to be an Underlying Network could, for
played by the corresponding stakeholders. Similarly, example be a licensed telecom network
the functional blocks described in 7 shall have to be or an unlicensed Machine to machine
expanded in a way that can touch upon all the necessary connectivity network
components of practical deployment. Also, as the e) The Device Manufacturers fulfil all the
device, data security and privacy aspects are paramount following criteria:
in the IoT ecosystem, it is prudent to have a very precise 1) Manufacturers/Provides the devices
and crisp specification for security implementation in a (sensors/actuators/gateways) in the field
real IoT world. 2) Conforms to the specifications of the
This objective is being met by the following three standards as applicable in the IoT/M2M
views that have been presented in this section: ecosystem
a) IoT Role Based View All the above roles are having mapping to various
b) IoT Systems Deployment View layers as defined in the IoT RA and are governed by
the Governance, Regulations and Standards entities as
c) IoT Security Management View defined in the IoT Reference Model.
8.1.1 IoT Role Based View
8.1.2 IoT System Deployment View
The three layered IoT Reference Architecture described
From the deployment standpoint, the layered
in 7 gets manifest in various deployment views. A
architectures facilitate the understanding of roles,
generic form of the deployment view is illustrated in
functions, positions, and the abstraction of different
Fig. 7 which is developed keeping in mind the key
hardware, software and networking entities. Fig. 8
stakeholders from the perspective of the roles played
gives an elaborate view of the entities and functions
by them towards the service delivery and consumption
involved in the deployment of the IoT ecosystem.
standpoint of the IoT ecosystem as presented in Fig. 7.
These roles are purely functional and may coincide or The deployment view is the layered representation
clubbed with any other role. of the way the IoT devices, associated applications,
service functions and other related entities interact
The roles depicted in Fig. 7 are described as follows: with each other. The associated functions and
a) The User (individual or company) fulfils all of other related entities like Information Technology
the following criteria: Service Management (ITSM), Disaster Recovery
and Business Continuity Management (BCM), Data
1) Lawfully subscribes to an IoT/M2M
Centre Network Management System (DCNMS),
solution.
Configuration Management, Microservice
b) The Application Service Provider fulfils all of Management and Orchestration, Autoscaling and CI/
the following criteria: CD (Continuous Integration/Continuous Deployment)
1) Registers the Application, gets etc. though extremely important, are implementation
it certified as per the provisions specific entities and hence are out of scope of this
of the law, and provides it as standard.
an IoT/M2M Application Service.
This deployment view is derived from the IoT Service
2) Operates IoT/M2M Applications. Layer Architecture and IoT Functional Architecture.
c) The IoT/M2M Service Provider fulfils all of TEC 30001 : 2020, TEC 30004 : 2020, TEC 30009 :
the following criteria: 2020, TEC 30010 : 2020, TEC 30020 : 2020 were also
1) Obtains the required registrations and referred to for validating the deployment scenarios with
certifications for the provisioning of end reference to the specifications contained therein.

10
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 7 IoT Role Based View

Fig. 8 IoT System Deployment View

11
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

8.1.2.1 Node based Deployment Architecture view would also connect to the common service
layer in the infrastructure domain. More often
An IoT application deployment as per the IoT Reference than not they are termed as the aggregation
Architecture would have the following nodes: gateways.
a) Field domain sensor nodes: These are the field d) Service Providers’ Domain Infrastructure:
domain nodes connecting the sensors and/or The core infrastructure that would provide the
actuators directly using a wired interface. They majority of the services as articulated as part
communicate to the Common Service Layer of the common service layer. For the sake of
through one or more Gateway nodes using any differentiation from the field domain common
form of network connectivity. service layer, this infrastructure is termed
b) Level one Gateways: These are the nodes that as Common Service Platform of the Service
connect to one or more types of sensors and/ Provider.
or actuators and may have multiple instances
of the applications with the business logic of A simplistic illustration of IoT application deployment
the respective vertical segments being catered using the above nodes following the IoT RA is given
to by them. These nodes can connect to the in Fig. 9 which is in harmony with TEC 30001 : 2020,
common service layer of the nodes placed TEC 30004 : 2020, TEC 30009 : 2020, TEC 30010 :
hierarchically above them either in the field 2020, TEC 30020 : 2020 and also with TEC 30003 :
domain or in the infrastructure domain i.e. 2020.
the Service Providers’ domain having core 8.2 IoT Security Management View
infrastructure.
c) Level two Gateways: These are the Gateway The Security management shall adhere to the following
nodes that must have the field domain form of requirements (refer TEC 30003 : 2020 for more details):
common service layer and would essentially a) Unique identification and registration of IoT
connect to the field domain sensor nodes Devices and Applications framework based on
either directly or through level one gateways a trust framework permitting sectoral, national
or through another level two gateway. They and international registrars

Fig. 9 Node based Deployment Architecture View

12
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

b) Registration of Service Providers to the EID) by the sectoral registrar (for example
respective trust authorities, registrars (Telecom vahan or AIS140 backend server) using bi-
Service Providers, Machine to Machine Service directional authentication based on keys and
Providers, Application Service Providers) certificates stored on the secure element of the
c) Classification of Use Cases and differential trust device (secure authentication channel)
requirements based on these classifications n) Custodian verification and Know Your
d) Identification and registration of IoT/ M2M Customer (KYC) norms for devices using
Applications and the M2M Devices, tamper embedded and tamper resistant roots of
resistant roots of trust for mission critical and trust shall be simplified if the inherent trust
sensitive use cases capabilities of the device and service provider
are used. The M2M SP/ TSP shall be allowed
e) Mandatory testing and certification of all
to access the manufacturer’s data lawfully
connected devices and applications by the
published on the servers of sector registrar
Original Equipment Manufacturer in India or
servers by the manufacturer, by using their
the person importing telegraph (device) for
authenticated user access provided by the trust
sale in India as per Gazette Notification No.
registrar.
G.S.R. 1131(E) dated 5th September, 2017 of
Department of Telecommunications, Ministry o) For the pluggable SIM that can be changed
of Communications, Government of India. in the field by the customer, the custodian-
machine KYC shall follow the digital KYC
f) The connectivity elements shall be compliant
processes as specified by the department of
to the relevant Generic Requirements(GR),
telecommunications from time to time.
Interface Requirements(IR) and Essential
Requirements (ER) published by TEC. p) The KYC may be completed by the TSP/ M2M
SP digitally and remotely, if using its private
g) Mutual Authentication and Authorization of
key to retrieve the secure triplet from the
security nodes belonging to service providers,
secure element, and having that information
application providers and registrars using
verified by the custodian using an one-time-
online and real time systems
password (OTP) to the mobile number of the
h) Frequent and regular mutual authentication custodian registered with the sector registrar as
between devices and the servers receiving and an owner of the machine.
hosting the data from the device
8.2.1 End point security and classification
i) Remote management and configuration shall
be compliant to national and international The End Point Devices are an essential component
standards like ETSI TS 101 181 V8.9.0 or and enabler for security, it is required to establish the
OMA DM (wireless) or BBF TR-69 (wireline) assurance level of End Point devices, as they manifest
j) Location information requirement for mission themselves in different forms with unique requirements
critical use cases of the use cases they serve.
k) Identities and information elements that The end point device identity and security assurance
are private and sensitive to users, networks requirement is shown in Fig. 10.
or service providers shall be transported
encrypted and transformed such that the real 8.2.2 Classification of Use Cases
identities are only known to the party that
owns the private data and not to agencies that The use cases may be classified as per clause 7.1.2 of
are transporting or processing the information. TEC-TR-SN-M2M-009 as reproduced below:
l) Principles of ‘secure by design’ and ‘end The most important aspect of M2M / IoT Security is in
to end encryption’ shall be applicable, how it is able to protect the data generated by the end
security algorithms and key management for points and the applications that use the end point data
encryption and signing shall be based on use to create services. The classifications of IoT / M2M Use
case classification and minimum requirements Cases, and the proposed mandatory recommendations,
as specified by the relevant regulations. are in the context of the said primary objective of M2M
m) Device identity, may be linked to the globally / IoT data protection
unique, tamper resistant identity provided by a a) Use Case categories
TSP/ M2MSP, provided that the tamper resistant
secure element of the device is provisioned with 1) Mission Critical, High QoS, Sensitive
the custodian (for example Aadhaar), machine Information [CQS]
(for example vehicle chassis number) and 2) Mission Critical, High QoS, Non Sensitive
communication identity (for example IccID/ Information [CQN]

13
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Fig. 10 End point device identity and security assurance

3) Non Critical, Best Effort, Sensitive collect or manage information private to

Information [NBS] individuals
4) Non Critical, Best Effort, Non Sensitive 2) All Use Cases serving the public at large
Information [NBN] from non-governmental infrastructure
5) Mission Critical, Best Effort, Sensitive for services such as Emergency Services,
Information [CBS] Disaster Response, Health Services,
Industrial Safety, Transport Services that
6) Mission Critical, Best Effort, Non
do not collect or manage information
Sensitive Information [CBN]
private to individuals
7) Non Critical, High QoS, Sensitive
d) Non Critical, Best Effort, Sensitive Information
Information [NQS]
[NBS]
8) Non Critical, High QoS, Non Sensitive
1) All Use Cases serving a private individual
Information [NQN]
from governmental or non-governmental
b) Mission Critical, High QoS, Sensitive infrastructure that affect non critical
Information [CQS] information for day to day use but
1) All Use Cases serving individual users collect or manage Personally Identifiable
from governmental or non-governmental Information [PII] or Privacy Protected
infrastructure that affect health, safety Information [PPI]
or security such as Personal Vehicle e) Non Critical, Best Effort, non-Sensitive
Automotive Solutions, Metering Information [NBN]
Solutions, Home Automation and Safety
1) All Use Cases serving the public at large
etc that collect or manage Personally
from governmental or non-governmental
Identifiable Information [PII] or Privacy
infrastructure that affects non critical
Protected Information [PPI]
information for day to day use that does not
c) Mission Critical, High QoS, non-Sensitive in any way collect or manage information
Information [CQN] private to individuals
1) All Use Cases serving the public at f) Other Classifications
large from Governmental Infrastructure
1) Several other combinations of Criticality,
such as Emergency Services, Disaster
Quality of Service and Data Sensitivity
Management, Public Safety, Smart
are possible which can generate further
Cities, Intelligent Transport Systems,
classifications
Automotive Solutions, Financial Services
(ATMs, PoS, Payment Terminals, Identity g) IoT Application shall be classified as per
Terminals), Health Services (ICDS, classification at (a) above and prominently
Hospital Management) that do not display this classification on Portals and Apps
for the user to be correctly informed
14
 Page/Clause No Corrections required
1Free Standard
Front provided
cover page
by BIS via Add
BSBICS
Edge NoPrivate
– 35.020Limited to Sai Charan Majji -
2 4.4
Gurugram([email protected]) Add a182.72.87.162
space after 4.4 [for non-commercial use only].
3 Fig 11 Partial figure is black. Replace it with the figure given below the
IS 18004 (Part 1) : 2021
table.
4 Committee Replace “Hawlett Packard Enterprise” with “Hewlett Packard
8.2.3 Authentication and Authorization framework is shown in Fig. 12. This framework shall allow the
composition Enterprise” in the main composition
registration of connected devices and applications,
The authentication
5 and authorization
Panel compositionof connected
Add “(Convener) after the name “Mr AurindamofBhatt acharya”
devices and applications may be as per the ITU-T vulnerability assessment and management security
Y.3056. The functional architecture as defined in 9 of lifecycle of all IoT/ M2M devices and applications.
ITU-T Y.3056 is reproduced in Fig. 11. The Information flows may be considered as per ITU-T
The corrections are also marked in the pdf file.
8.2.4 Trust framework Y.3056, which includes the process of registration
Figure 11 and transfer, or other such guidelines as published by
The framework for interaction between national trust sectoral authorities from time to time.
centre, sectoral registrars and international registrars

Fig. 11 IoT/ M2M Identification, Authentication and Authorization

Fig. 12 Trust Centre framework

15
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

ANNEX A
USE CASE BASED REQUIREMENT CATEGORISATION

The IoT System Reference Architecture addresses the l) Smart Home

IoT Use Cases and Requirements referenced to the m) Citizen Engagement Platform
following standards, gazettes and technical reports
n) Distribution Automation
a) IS 18004-6 Requirements for Internet of o) Industrial Automation
Things (under development)
p) Smart Health
b) TEC 30002 : 2020 oneM2M-Requirements
c) Gazette Notification No. G.S.R. 1131(E) In IoT/M2M, a device is an electronic element with
dated 5th September, 2017 of Department communication capabilities. This standard attempts
of Telecommunications, Ministry of to classify the devices in the IoT ecosystem in the
Communications, Government of India, and following way:
d) Use Cases described in TEC-TR-SN- Table 2 classifies the devices based on its compute
M2M-009 – Release 01 Recommendations for capability, the presence of Operating System and the
IoT / M2M Security (Technical report) methodology used for communication (in purely IP
While capturing the requirements across a wide or non-IP way). Such categorisation or classification
variety of divergent domains, that serve as a basis of of IoT devices is done in order to come up with an
the reference architecture described in this standard, architectural reference model which along with the
the following domains were considered as candidate main functional entities derived from the use cases can
verticals to represent the entire spectrum of vertical define the reference architecture that may help towards
domains. The detailed requirements for IoT system is the implementation of IoT solutions.
specified in IS 18004 (Part 6) IoT System Functional Here the categorization or classification of devices do
Requirements (Under development) not differentiate between sensing and actuating devices
a) Electricity Utility and general devices. This categorization is purely on
b) Water Utility the basis of the processing capabilities and the way the
devices communicate. So, those devices which may be
c) Water Management termed as passive devices for example, ID tags using
d) Gas identification technologies such as radio frequency
e) Smart Street Light identification (RFID) or near field communication
f) Surveillance (NFC), applied to a disposable package, are not
included as part of devices categorised as IoT devices.
g) Environment The rationale behind this is the fact that these passive
h) Traffic Management devices would require devices with compute and
i) Transportation communication capabilities to obtain, process and
j) ICCC communicate the data to the other entities in the
ecosystem.
k) Solid Waste Management

Table 2 Classification of IoT Devices

Sl Communication
Device Type Compute Capacity OS
No.# Methodology
1 High Constrained Devices 8/16 bit Microcontroller NO Non-IP/IP
2 Constrained Device 16/32 bit Microcontroller NO/RTOS Non-IP/IP
3 Small Compute Device Single core 32 bit Microprocessors yes IP
4 Medium Compute Device Single/Dual core 32/64 bit Microprocessors yes IP
5 Large Compute Device Multi core(>2) 64 bit Microprocessors yes IP
6 Virtual Machine/Server Multi core VMs/Dockers/Servers yes IP

16
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

ANNEX B
BROAD FUNCTIONAL REQUIREMENTS

The broad functional requirements are being covered Applications and /or from the IoT System would be
as a separate standard IS 18004 (Part 6) (under covered in the Data Analytics Requirements. It would
development). However, the summary of the same is also lay down the requirements from the IoT system
being captured here to give a high level view to the to support a standardized format for the rules/policies
readers about the functional requirements fulfilled by used to define service logic.
the IoT System RA. Following list gives the different
categories in which the functional requirements are The importance of Security for the IoT System is
identified and articulated. paramount. While the overall digital as well as physical
ecosystem has to follow elaborate security guidelines,
a) Overall System Requirements it is equally important to identify and elaborate the
b) Management Requirements security requirements for the IoT System so that the
c) Semantics Requirements fulfilment of the same can be a standardised practice
for any entity getting onboarded.
d) Data Analytics Requirements
e) Security Requirements Even though the IoT system does not and shall not
f) Charging Requirements be prescriptive about the monetisation aspects of
the IoT deployments, it is important for the sake of
g) Operational Requirements
standardisation to define the Charging Requirements
h) Communication Management Requirements so that the IoT System is able to support collection
The Overall System requirements would be covering of charging specific information related to the
the generic requirements of registration, onboarding, individual services facilitated by the IoT System (such
communication and data handling etc. by the IoT as Data Management, Device Management and/or
System. Connectivity Management), Collection of charging
specific information with concurrent resource usage
The management requirement would be providing the and support mechanisms to facilitate correlation of
comprehensive requirements of management of the charging information (e.g. of a User) collected for
devices within the IoT ecosystem. This would also IoT Services, IoT Application Services and services
cover the management of the software entities. provided by Underlying Network Operators.

Semantics are extremely important for the Following the deployment of the IoT System, it is
interoperability within the IoT ecosystem and essential to standardize the operational aspects of the
also for seamless sharing of data within the IoT IoT System. It therefore, becomes necessary to capture
system. This would be covering Ontology Related and define all such essential requirements which are
Requirements,Semantics Annotation Requirements, mandatory to operationalize any IoT System.
Semantics Query Requirements, Semantics Mashup
Requirements and Semantics Reasoning Requirements Last but not the least, the communication management
etc. requirements are also equally important for any
IoT System. While the IoT RA is agnostic to any
The ability of the IoT System to support capabilities communication technology, the generic communication
(e.g. processing function) for performing IoT data management needs shall have to be fulfilled for efficient
analytics based on semantic descriptions from IoT handling and distribution of IoT data.

17
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

ANNEX C
( Foreword )

COMMITTEE COMPOSITION

Organization Representative(s)

Indian Institute of Science, Bengaluru Prof Bharadwaj Amrutur (Chairman)

Standardization Testing and Quality Certification Ms Lipika Kaushik
(STQC)
Shrama Technologies Pvt Ltd, Bengaluru Mr Amarjeet Kumar
Treasure Data Mr Kumaar Guhan
Amravati Smart City Development Corporation Mr Siddharth Ganesh
Limited, Mumbai
Centre for Development of Telematics, New Delhi Mr Aurindam Bhattacharya
Ms Anupama Chopra (Alternate)
Criterion Network Labs, Bengaluru Mr Jayaprakash Kumar
Mr Krishna Kumar Lohati (Alternate)
CyanConnode Private Limited, Bengaluru Mr Manish Widhani
Mr Deepak Nimare (Alternate)
ERNET India, New Delhi Mr Paventhan Arumugam
Ericsson India Private Limited, Gurugram Mr Sendil Kumar Devar
Esri India Technologies Private Limited, Noida Ms Seema Joshi
Vijay kumar (Alternate)
Hewlett Packard Enterprise Mr Devarajan R.
Manukumar Nair (Alternate)
IEEE India, Bengaluru Mr Srikanth Chandrasekaran
Mr Munir Mohammed (Alternate)
India Smart Grid Forum, New Delhi Mr Reji Kumar Pillai
Ms Parul Shribatham (Alternate)
Indian Institute of Science, Bengaluru Mr Vasanth Rajaraman
Intel Technology India Private Limited, Bengaluru Mr C. Subramanian
Mr Anantha Narayanan (Alternate I)
Mr Sidhartha Mohanty (Alternate II)
Ministry of Housing and Urban Affairs, New Delhi Kunal Kumar
Mr Padam Vijay (Alternate)
Narnix Technolabs Private Limited, New Delhi Mr N. Kishor Narang
National Institute of Urban Affairs, New Delhi Ms Lavanya Nupur
National Smart Grid Mission, Ministry of Power, Mr Arun Misra
Gurugram Smt Kumud Wadhwa (Alternate I)
Mr Gyan Prakash (Alternate II)
PHYTEC Embedded Private Limited, Bengaluru B. Vallab Rao
Qualcomm India Private Limited, Bengaluru Dr Vinosh Babu James
Dr Punit Rathod (Alternate)
Renesas Electronics, Bengaluru Ravindra Chaturvedi
Saurabh Goswami (Alternate)

18
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Organization Representative(s)

Schneider Electric’s industrial software business - Mr Gourav Kumar Hada

AVEVA, Mumbai
SESEI, New Delhi Mr Dinesh Chand Sharma
Secure Meters Limited, Gurugram Mr Uttam Kotdiya
Mr Kaustubh Patil (Alternate I)
Mr Puneet khurana (Alternate II)
Mr Anil Mehta (Alternate III)
Senra Tech Private Limited, New Delhi Dhiraj Kumar
Ankush Kochhar (Alternate)
Siemens Limited, Mumbai Mr Manoj Belgaonkar
Mr Ravi Madipadga (Alternate I)
Mr Pradeep Kapoor (Alternate II)
Mr Vikram Gandotra (Alternate III)
System Level Solutions (India) Private Limited, Anand Mr Dipen Parmar
Mr Foram Modi (Alternate)
Tata Consultancy Services Limited, Mumbai Mr Ramesh Balaji
Mr Debashis Mitra (Alternate)
Tata Consulting Engineers Limited, Navi Mumbai Mr Jagdish Shivraj Shige
Mr Manoj Kumar (Alternate)
Tejas Networks Limited, Bengaluru Dr Kanwar Jit Singh
Telecommunication Engineering Center, New Delhi Mr Rajeev Kumar Tyagi
Mr Sushil Kumar (Alternate I)
Mr Uttam Chand (Alternate II)
eGovernments Foundation, Bengaluru Mr Krishnakumar Thiagarajan
In personal capacity Mr Anish P. K.
In personal capacity Prof Suptendranath Sarbadhikari
BIS Director General Ms Reena Garg, Scientist ‘F’ and Head (Electronics and IT)
[ Representing Director General (Ex-officio) ]

Member Secretary
Shri Manikandan K.
Scientist ‘D’ (Electronics and IT), BIS

19
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

Panel involved in the Finalization - LITD 28/P9 IoT Reference Architecture

Organization Representative(s)

Centre for Development of Telematics, New Delhi Mr Aurindam Bhattacharya (Convener)

CyanConnode Private Limited Mr Deepak Nimare
EU Project SESEI Mr Dinesh Chand Sharma
GE Healthcare Mr Rahul K Gupta
Gill Instruments Private Limited, Bengaluru Mr Gurjeet Gill
Hewlett Packard Enterprise India Pvt Ltd Mr R. Devarajan
innowear.hk Mr Chandan
Landis+Gyr Limited, Noida Mr Tanmay Kathpalia
Landis+Gyr Limited, Noida Ms Sonali Srivastava
National Institute of Urban Affairs, New Delhi Ms Lavanya Nupur
Secure Meters Limited, Gurugram Mr Uttam Kotdiya
Sensorise Digital Services Private Limited, Noida Mr Sharad Arora
Shrama Technologies Pvt Ltd Mr Amarjeet Kumar
ST Microelectronics Mr Raunaque Mujeeb QUAISER
Telecommunication Engineering Center, New Delhi Mr Sushil Kumar
Tejas Networks Ltd Dr Kanwar Jit SIngh
KPMG Ms Neetika Chhabra
Tech M Ms Ruchi Bamba

20
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

IS 18004 (Part 1) : 2021

BIBLIOGRAPHY

1 IS 18004-6 Requirements for Internet of Things (under development)

2 ISO/IEC 30118-1 : 2018 Information technology — Open Connectivity Foundation (OCF)
Specification — Part 1 : Core specification
3 TEC-TR-SN-M2M-009 – Recommendations for IoT / M2M Security (Technical report Release 01)
4 TEC 30001 – 30040TEC Standards for IoT/M2M Ecosystems
5 TEC 30002 : 2020 oneM2M Requirements
6 TEC 30005 : 2020 oneM2M Management Enablement (OMA)
7 TEC 30006 : 2020 oneM2M Management enablement (BBF)
8 TEC 30011 : 2020 oneM2M Common Terminology
9 TEC 30012 : 2020 oneM2M Base Ontology
10 TEC 30014 : 2020 oneM2M LWM2M Interworking
11 TEC 30023 : 2020 oneM2M Home Appliances Information Model and Mapping
12 MTCTE: https://www.tec.gov.in/mandatory-testing-and-certification-of-telecom-equipments-mtcte
13 ETSI TS 101 181 V8.9.0 (2005-06) Technical Specification, Digital cellular telecommunications system
(Phase 2+); Security mechanisms for SIM application toolkit; Stage 2 (3GPP TS 03.48 version 8.9.0
Release 1999)

21
 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

This page has been intentionally left blank

 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

This page has been intentionally left blank

 Free Standard provided by BIS via BSB Edge Private Limited to Sai Charan Majji -
Gurugram([email protected]) 182.72.87.162 [for non-commercial use only].

Bureau of Indian Standards

BIS is a statutory institution established under the Bureau of Indian Standards Act, 2016 to promote harmonious
development of the activities of standardization, marking and quality certification of goods and attending to
connected matters in the country.

Copyright

BIS has the copyright of all its publications. No part of these publications may be reproduced in any form without
the prior permission in writing of BIS. This does not preclude the free use, in the course of implementing the
standard, of necessary details, such as symbols and sizes, type or grade designations. Enquiries relating to
copyright be addressed to the Director (Publications), BIS.

Review of Indian Standards

Amendments are issued to standards as the need arises on the basis of comments. Standards are also reviewed
periodically; a standard along with amendments is reaffirmed when such review indicates that no changes are
needed; if the review indicates that changes are needed, it is taken up for revision. Users of Indian Standards
should ascertain that they are in possession of the latest amendments or edition by referring to the latest issue of
‘BIS Catalogue’ and ‘Standards: Monthly Additions’.
This Indian Standard has been developed from Doc No.: LITD 28 (17304).

Amendments Issued Since Publication

Amend No. Date of Issue Text Affected

BUREAU OF INDIAN STANDARDS

Headquarters:
Manak Bhavan, 9 Bahadur Shah Zafar Marg, New Delhi 110002
Telephones: 2323 0131, 2323 3375, 2323 9402 Website: www.bis.gov.in
Regional Offices: Telephones
Central : Manak Bhavan, 9 Bahadur Shah Zafar Marg
NEW DELHI 110002 { 2323 7617
2323 3841
Eastern : 1/14 C.I.T. Scheme VII M, V.I.P. Road, Kankurgachi
KOLKATA 700054 { 2337 8499, 2337 8561
2337 8626, 2337 9120
Northern : Plot No. 4-A, Sector 27-B, Madhya Marg
CHANDIGARH 160019 { 265 0206
265 0290
Southern : C.I.T. Campus, IV Cross Road, CHENNAI 600113
{ 2254 1216, 2254 1442
2254 2519, 2254 2315
Western : Manakalaya, E9 MIDC, Marol, Andheri (East)
MUMBAI 400093 { 2832 9295, 2832 7858
2832 7891, 2832 7892
Branches : AHMEDABAD. BENGALURU. BHOPAL. BHUBANESHWAR. COIMBATORE.
DEHRADUN. DURGAPUR. FARIDABAD. GHAZIABAD. GUWAHATI.
HYDERABAD. JAIPUR. JAMMU. JAMSHEDPUR. KOCHI. LUCKNOW.
NAGPUR. PARWANOO. PATNA. PUNE. RAIPUR. RAJKOT. VISAKHAPATNAM.
Published by BIS, New Delhi