ISO/IEC 29182-4:2013
(Main)Information technology — Sensor networks: Sensor Network Reference Architecture (SNRA) — Part 4: Entity models
Information technology — Sensor networks: Sensor Network Reference Architecture (SNRA) — Part 4: Entity models
The purpose of the ISO/IEC 29182 series is to provide guidance to facilitate the design and development of sensor networks, improve interoperability of sensor networks, and make sensor network components plug-and-play, so that it becomes fairly easy to add/remove sensor nodes to/from an existing sensor network. ISO/IEC 29182-4 presents models for the entities that enable sensor network applications and services according to the Sensor Network Reference Architecture (SNRA).
Technologies de l'information — Réseaux de capteurs: Architecture de référence pour réseaux de capteurs — Partie 4: Modèles des entités
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29182-4
First edition
2013-07-15
Information technology — Sensor
networks: Sensor Network Reference
Architecture (SNRA) —
Part 4:
Entity models
Technologies de l’information — Réseaux de capteurs: Architecture de
référence pour réseaux de capteurs —
Partie 4: Modèles des entités
Reference number
ISO/IEC 29182-4:2013(E)
©
ISO/IEC 2013
---------------------- Page: 1 ----------------------
ISO/IEC 29182-4:2013(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2013 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 29182-4:2013(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Overview . 2
6 Physical entities. 6
6.1 Sensor nodes . 6
6.2 Gateways .10
6.3 Other networks .10
6.4 Service providers .10
6.5 Users .10
7 Functional entities .11
7.1 Sensor node hardware layer.11
7.2 Basic functions layer .11
7.3 Service layer .13
7.4 Application layer .16
7.5 Cross-layer management.17
Bibliography .22
© ISO/IEC 2013 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 29182-4:2013(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies
casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 29182 consists of the following parts, under the general title Information technology — Sensor
networks: Sensor Network Reference Architecture (SNRA):
— Part 1: General overview and requirements
— Part 2: Vocabulary and terminology
— Part 3: Reference architecture views
— Part 4: Entity models
— Part 5: Interface definitions
— Part 7: Interoperability guidelines
The following part is under preparation:
— Part 6: Applications
iv © ISO/IEC 2013 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 29182-4:2013(E)
Introduction
A wide range of applications has been proposed for sensor networks. In practice, however, sensor
networks have been built and deployed for a relatively small number of applications. This is partly due
to the lack of a business case for certain applications and partly due to technical challenges in building a
non-trivial sensor network of reasonable complexity. The main reason for this impediment is the multi-
disciplinary expertise – such as sensors, communications and networking, signal processing, electronics,
computing, and cyber security – required to design a sensor network. Presently, the design process is
so complex that one can leverage little from one sensor network design to another. It appears as if one
has to start from almost scratch every time one wishes to design and deploy a sensor network. Yet,
upon closer inspection, there are many commonalities in instantiations of sensor networks that realize
various applications. These commonalities include similarities in the choice of network architecture and
the entities/functional blocks that are used in the architecture.
The purpose of the ISO/IEC 29182 series is to
— provide guidance to facilitate the design and development of sensor networks,
— improve interoperability of sensor networks, and
— make sensor network components plug-and-play, so that it becomes fairly easy to add/remove
sensor nodes to/from an existing sensor network.
The ISO/IEC 29182 series can be used by sensor network designers, software developers, system
integrators, and service providers to meet customer requirements, including any applicable
interoperability requirements.
The ISO/IEC 29182 series comprises seven parts. Brief descriptions of these parts are given next.
ISO/IEC 29182-1 provides a general overview and the requirements for the sensor network reference
architecture.
ISO/IEC 29182-2 provides definitions for the terminology and vocabulary used in the reference
architecture.
ISO/IEC 29182-3 presents the reference architecture from various viewpoints, such as business,
operational, system, technical, functional, and logical views.
This part of ISO/IEC 29182 categorizes the entities comprising the reference architecture into two
classes of physical and functional entities and presents models for the entities.
ISO/IEC 29182-5 provides detailed information on the interfaces among various entities in the reference
architecture.
ISO/IEC 29182-6 provides detailed information on the development of International Standardized Profiles.
ISO/IEC 29182-7 provides design principles for the reference architecture that take the interoperability
requirements into account.
There are no requirements for compliance in the ISO/IEC 29182 series. Users should ensure that
the sensor nodes, and the related sensor network, are compliant with the application or deployment
governing body.
© ISO/IEC 2013 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 29182-4:2013(E)
Information technology — Sensor networks: Sensor
Network Reference Architecture (SNRA) —
Part 4:
Entity models
1 Scope
This part of ISO/IEC 29182 presents models for the entities that enable sensor network applications and
services according to the Sensor Network Reference Architecture (SNRA).
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 29182-2, Information technology — Sensor networks: Sensor Network Reference Architecture
(SNRA) — Part 2: Vocabulary and terminology
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29182-2 apply.
4 Abbreviated terms
3G 3rd Generation
4G 4th Generation
GNSS Global Navigation Satellite System
GPS Global Positioning System
ICT Information and Communication Technology
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
IT Information Technology
LBS Location-Based Services
MAC Medium Access Control
OSI Open Systems Interconnection
PHY Physical
PII Personally Identifiable Information
© ISO/IEC 2013 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 29182-4:2013(E)
QoS Quality of Service
RF Radio Frequency
RFID Radio Frequency IDentification
SCM Source Configuration Management
SDP Service Discovery Protocol
SNRA Sensor Network Reference Architecture
TEDS Transducer Electronic Data Sheet
5 Overview
The purpose of this part of ISO/IEC 29182 is to provide basic information about and high-level models
for various entities that comprise a sensor network. Entities can be roughly categorized into two classes,
physical and functional. Physical entities are pieces of hardware and actual devices or components
thereof that form the network, such as sensor nodes and gateways. For example, while a sensor node is a
physical entity, so are any of the sensors in that node. A functional entity, on the other hand, represents a
certain task that may be carried out on one or more types of physical entity. For example, data acquisition
and collaborative information processing are both functional entities. While the former is carried out by
the sensors, the latter is done “collaboratively” by sensor nodes, service providers, and users (or their
machines, to be more precise). Routing and authentication are other examples of functional entities.
More often than not, functional entities are pieces of code that run on physical entities.
Each entity model presented in this document is a description of the function/role of that entity. An
attempt has been made to provide more detailed models for entities that are specific to sensor networks
and typically not found in general-purpose communication networks. Examples of such physical entities
include sensors and actuators. Similarly, more detailed models have been provided for functional entities
such as data processing, self-localization, group management/clustering, collaborative information
processing, and device management. A more detailed model may include an input-output relationship
for what the entity does, some features of the entity that characterize its capabilities, and a taxonomy of
various ways in which the entity may be implemented.
Figures 1 and 2 provide an overall view of the entities modelled in this document. Figure 1 is an
[1] [2]
amalgamation of Figure 3 in ISO/IEC 29182-1 and Figure 4 in ISO/IEC 29182-3 . It shows the physical
entities that form a sensor network and how these entities are connected to each other. The blow-up part
of the figure is borrowed from ISO/IEC 29182-3 and it shows the internal structure of a sensor node.
It implies that actuator(s), although associated with sensor nodes, may not physically reside in sensor
nodes. The rest of the figure comes from ISO/IEC 29182-1 and it depicts a more complex instantiation
of a sensor network than the other cases presented in Figures 1 and 2 in ISO/IEC 29182-1. Figure 2 is
the same as Figure 7 in ISO/IEC 29182-3. It has been reproduced in this document for ease of reference.
2 © ISO/IEC 2013 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 29182-4:2013(E)
Figure 1 — Physical entities of a sensor network
© ISO/IEC 2013 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 29182-4:2013(E)
Figure 2 — Functional entities of a sensor network
The distinction between physical and functional entities in a sensor network and how they relate to each
other can at times be confusing. Table 1 is an attempt to remedy this problem. It shows all the physical
entities a functional entity could be associated with. The word “could” has been used here, because
some physical entities may not be present in a given sensor network. For example, if there are no service
providers in the overall architecture, which would be the case in a stand-alone sensor network, then
one cannot say that there is an association between the collaborative information processing functional
entity and service providers. In other words, the reader is urged to think of Table 1 as representative of
certain possibilities, but not covering all possible ways of which entities might be present in the sensor
network and how they might be configured.
4 © ISO/IEC 2013 – All rights reserved
---------------------- Page: 9 ----------------------
Users
Service providers
Backbone network
Other
networks
Access networks
Gateways
Power supply
Memory
Processor
Sensor
nodes
Communications module
Actuators
Sensors
Service layer Application
Basic func-
Cross-layer management
layer
tions layer
Functional entities
ISO/IEC 29182-4:2013(E)
Table 1 — Interrelationships between physical and functional entities in a sensor network
Physical entities
Data acquisition ●
Sensor node
Actuation ●
hardware layer
Power generation / energy harvesting ●
Data processing ● ● ●
Data communications ● ● ● ● ● ●
Data storage ● ● ●
Hardware drivers ● ● ●
Sensor/actuator identification ● ● ●
Communications support functions ● ● ● ● ● ● ● ●
Self-localization ● ● ● ●
● ● ●
Service/resource discovery
Common
Data management ● ● ● ●
services
● ● ● ● ●
Code management
Time synchronization ● ● ● ●
● ● ● ●
Group management / clustering
● ●
Domain specific services
● ●
Applications
● ● ● ●
Software agent
● ● ●
Rules engine
● ● ● ● ●
Collaborative information processing
● ● ● ●
Device management
● ● ● ● ● ● ●
Resource management
● ●
Service management
Network management ● ● ● ● ●
● ● ● ● ● ●
Security management
Privacy management
Safety management
● ● ● ●
Business management
● ● ● ● ● ● ● ●
QoS management
● ● ● ● ● ●
System monitoring
© ISO/IEC 2013 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 29182-4:2013(E)
6 Physical entities
6.1 Sensor nodes
6.1.1 Overview
As it was stated earlier and depicted in the upper part of Figure 1, a sensor node comprises several sub-
entities whose models are presented next. Note that the actuator(s), if at all present, may not physically
reside inside the sensor node.
6.1.2 Sensors
A sensor measures a physical attribute, such as temperature, humidity, or level of carbon monoxide in
the air, and converts it into an electric voltage/current. This conversion may be direct or indirect. While
in the former case the attribute is directly converted into an electric voltage/current, in the latter case
the attribute is converted into a sequence of one or more intermediate attributes before finally getting
converted into an electric voltage/current. For example, a thermometer may measure temperature and
convert it into physical displacement of some object and then convert that displacement into an electric
voltage/current. The sensor output voltage/current may be in analog or digital form. In the former case
an analog to digital converter (ADC) is used to convert the analog electric voltage/current into a finite-
length sequence of bits (binary digits) that constitutes a binary representation of the voltage/current.
Therefore, an appropriate model for a sensor with analog output is an input-output relationship that
characterizes the conversion from the attribute being measured by the sensor into the output electric
voltage/current. The relationship may occasionally be characterized through a mathematical formula
or more frequently through a xy-plot. For example, Figure 3 shows the output voltage of a temperature
sensor versus the input temperature. As the temperature increases, the output voltage decreases, which
is an indication of a negative temperature coefficient.
Figure 3 — Input-output relationship of a temperature sensor
On the other hand, an appropriate model for a sensor with digital output is a quantizer input-output plot
or table. The former is a staircase xy-plot that represents the analog physical attribute on the horizontal
axis and the analog value represented by the sensor binary output on the vertical axis. Figure 4 shows
a quantizer input-output plot.
6 © ISO/IEC 2013 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 29182-4:2013(E)
Figure 4 — Input-output relationship for an 8-level non-uniform quantizer
Alternatively, two tables may be used to characterize the same input-output relationship as well as to
specify the binary codewords used by the quantizer. For example, any temperature between 18 and
18.1 °C may be represented by the binary codeword “10110101”, and in turn 18.05 °C may be used as
the representative value for that temperature range and the associated binary codeword. Tables 2 and
3 show, respectively, the operations of the encoder and decoder of the quantizer depicted in Figure 4.
Table 2 — The encoder for the quantizer shown in Figure 4
Quantizer Input Range Output Binary Codeword
(−∞, b ) 000
1
[b , b ) 001
1 2
[b , b ) 010
2 3
[b , b ) 011
3 4
[b , b ) 100
4 5
[b , b ) 101
5 6
[b , b ) 110
6 7
[b , ∞) 111
7
© ISO/IEC 2013 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 29182-4:2013(E)
Table 3 — The decoder for the quantizer shown in Figure 4
Input Binary Codeword Quantizer Output Level
000 y
1
001 y
2
010 y
3
011 y
4
100 y
5
101 y
6
110 y
7
111 y
8
The models presented above are deterministic in nature and as such ignore presence of measurement
noise in the sensor. A model that takes these aspects into account may be of the form
X = a S + N
where
S is either a deterministic or random variable representing the physical attribute being
measured by the sensor,
a is a conversion/scaling factor,
N is a random variable representing measurement noise, and
X is the sensor output electric voltage/current.
When using a stochastic sensor model like the above, one needs to specify the conversion/scaling factor
a and the probability distribution for additive noise N. When the physical attribute being measured is
modelled by a random variable S, it is necessary to provide the joint probability distribution of S and the
noise random variable N. Usually, but not always, S and N are assumed to be statistically independent.
In case of a sensor with a digital output, the quantizer used by the sensor needs to be characterized per
earlier discussion.
In case of all the models discussed above, it is also necessary to specify the range of input values – i.e. the
range of values for the physical attribute – over which the sensor functions. Finally, in case of a sensor
node with multiple sensors, a model needs to be provided for each sensor used in the node.
6.1.3 Actuators
Roughly speaking, an actuator functions in a manner that is the inverse of how a motion sensor functions.
It takes an electric voltage/current, in analog or digital form, as input/command and causes some motion
(translation, rotation), thereby moving or changing the orientation of the object being controlled by a certain
amount. In many cases, the electric voltage/current is first converted to hydraulic pressure and it’s the latter
that causes motion. This parallels the discussion of direct or indirect conversion in the case of sensors.
It is straightforward to develop a deterministic model for an actuator following a line of thought similar to
that presented in Subclause 6.1.2. An actuator with an analog input electric voltage/current is modelled
by a xy-plot and a range of values for the input. The simplest way to model an actuator with digital input
is through the use of a table that shows the motion values for all possible binary input strings. This
would work for small-size tables. If the binary string is more than a few bits long, then a functional form
would be the appropriate model. In such a case, the function operates on the decimal value represented
by the binary input string to the actuator and converts that into motion.
8 © ISO/IEC 2013 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 29182-4:2013(E)
Similarly, a stochastic model for an actuator would take the form
X = a s + N
where
s is the deterministic input/command to the actuator,
a is a conversion/scaling factor, and
N is a random variable characterizing any randomness in actuator operation as the same
input may not always result in exactly the same motion.
6.1.4 Communications module
A sensor node may have more than one mechanism for communicating with other sensor nodes and
possibly a gateway. These mechanisms may be wired or wireless. The communications module houses
all these mechanisms. Detailed modelling of the communications mechanisms in a sensor node is beyond
the scope of this part of ISO/IEC 29182. Such modelling should include at least the physical and data link
layers in the Open Systems Interconnection (OSI) model and possibly the network and transport layers.
Appropriate standards should be cited to characterize the protocol layers.
6.1.5 Processor
A sensor node, especially if it uses multiple sensors, typically has a processor that may be used for
pre-processing raw sensor data. This could include data aggregation, feature extraction, data fusion,
and even collaborative processing of data captured not at just the node under discussion but also at
other nodes communicating with it. The communications module and functionalities such as security
services at a sensor node require computational capabilities. In general, the term “smart sensor” – which
is commonly used – implies that there is a good bit of processing capability at the sensor node. From a
functional point of view, many entities require processing and computational capabilities. These include
Basic Functions Layer (BFL), Service Layer (SL), Application Layer (AL), and Cross-Layer Management
(CLM), which are described later under Functional Entities.
A detailed architectural model for the processor is not needed for characterizing sensor node capabilities.
Perhaps all that is needed is a simple characterization using FLOPS (FLoating OPerations per Second)
and the number of processors (dual, quad, etc.) to specify the computational power of the node.
6.1.6 Memory
The storage capabilities of a sensor node can be characterized with two numbers: the size of its hard
drive (slower access memory) and the size of its faster electronic memory.
6.1.7 Power supply
Sensor nodes are typically battery-powered. Therefore, the battery voltage and its longevity,
characterized in terms of milliampere-hours, need to be specified. Some sensor nodes use a sleep
mechanism that allows them to go to “sleep” most of the time and “wake up” only occasionally to do what
a sensor node does – data acquisition, processing, and reporting through communications with other
entities. In such cases it might be useful to characterize the recharging capabilities of the batteries,
because batteries recharge when they are not in use.
A battery-operated sensor node may also use some form of energy harvesting, which needs to be
characterized in order to estimate how long the sensor node may last.
In certain applications, sensor nodes are powered with line electricity. In such cases, it is useful to
specify the power consumption of the sensor node.
© ISO/IEC 2013 – All rights reserved 9
---------------------- Page: 14 ----------------------
ISO/IEC 29182-4:2013(E)
Power supplies – whether they are batteries or Alternating Current (AC) adaptors – are typically bulky
and constitute a major fraction of the weight and size of a sensor node. Therefore, it is useful to specify
the size and weight of the power supply.
6.2 Gateways
Gateways facilitate communications between a sensor network and another network or another
sensor network. If present in the overall architecture, gateways reside in physical proximity of sensor
nodes. A gateway employs one protocol for communicating with a sensor network and another for
communicating with the other network, whether it is another sensor network or a backbone network. In
the latter case, the communications are either direct or through an access network. Just as in the case of
the communications module used in sensor nodes (cf. Subclause 6.1.4), a full specification and modelling
of the communications protocols used by a gateway is beyond the scope of this part of ISO/IEC 29182.
Wherever appropriate, other standards should be cited.
6.3 Other networks
6.3.1 Overview
“Other networks” refers to the networks in the SNRA other than sensor networks. These are the
networks that make it possible for a sensor network to communicate with its users through service
providers, particularly when the users and service providers are not physically co-located with the
sensor network. Other networks include access networks and the backbone network that are described
next. Note that there is no need for “other networks” in a stand-alone sensor network, as shown in
[1]
Figure 1 of ISO/IEC 29182-1 .
6.3.2 Access networks
An access network provides connectivity between the backbone network and a gateway in the SNRA.
Examples of access networks include a WiFi network, a cellular telephony network (such as 3G/4G (3rd
Generation/4th Generation) Wireless), and simply an Ethernet in the case of a gateway that is hard-
wired to the backbone network. The modelling of an access network is beyond the scope of this part of
ISO/IEC 29182. Wherever appropriate, other standards should be cited.
6.3.3 Backbone network
The most obvious backbone network is the Internet. Another example would be an intranet, if the data
from the sensors is going to be consumed “locally” and not to be accessed by other networks. In general,
a backbone network provides connectivity among a large number of possibly geographically dispersed
communicating entities. It is typically wired, even though wireless backbone networks have also been
proposed. The modelling of the backbone network
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.