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 2013
© 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
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
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
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
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
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
Figure 1 — Physical entities of a sensor network
© ISO/IEC 2013 – All rights reserved 3
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
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
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
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
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
[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
© ISO/IEC 2013 – All rights reserved 7
Table 3 — The decoder for the quantizer shown in Figure 4
Input Binary Codeword Quantizer Output Level
000 y
001 y
010 y
011 y
100 y
101 y
110 y
111 y
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
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
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 is beyond the scope of this part of ISO/IEC 29182.
Wherever appropriate, other standards should be cited.
6.4 Service providers
These are entities that interact with one or more sensor networks and provide some basic services to
the users of these sensor networks and more specifically to the sensor network applications running
on the user machines. For example, sensor network applications such as national air traffic control and
battlefield command and control rely on some basic services related to weather and climate monitoring.
These applications may get weather information from service providers providing such information and
forecasting services.
6.5 Users
These are the entities that ultimately consume the high level information provided by sensor networks.
Sensor network applications, such as environmental monitoring and battlefield command and control,
run on the user machines. As pointed out in Subclause 6.4, these applications may rely on certain basic
10 © ISO/IEC 2013 – All rights reserved
services provided by service providers. The user may have capabilities for visualizing the information
produced by sensor network applications. It should also be pointed out that in case of simpler sensor
networks, the applications may run on lower layer entities and even on sensor nodes.
7 Functional entities
7.1 Sensor node hardware layer
7.1.1 Overview
The sensor node hardware layer is the collection of functionalities dealing with sensing, actuation, and
power sources in a sensor node. Obviously, sensing is the main function of a sensor node, but it may also
have actuation capabilities. Sensing and actuation take place strictly in sensor nodes, but other physical
entities require power sources also. While those entities often have access to line electricity, the issue of
power generation in sensor nodes deserves special attention because they may have to live off batteries
for a long time or harvest energy.
7.1.2 Data acquisition
This is the fundamental function of sensors. Each sensor measures some physical attribute of the
environment in which it is located and converts those measurements into digital data. Some details on
the operation of a sensor have been given in Subclause 6.1.2. Data acquisition is the collective task of
observing and measuring the environment and producing digital data based on the measurements.
7.1.3 Actuation
In the context of a sensor network, this is the process through which a user may affect the physical
world that the sensors observe and measure. Not all sensor networks are equipped with actuators.
There are some sensor networks that simply observe and measure some attributes of the physical world
without trying to affect it. One may regard a sensor network that employs actuators as a closed loop
control system. Each actuator receives control commands/signals from higher functional layers of the
sensor network and causes some object to move. The notion of how to affect a possibly “large” physical
world through use of a number of actuators in a way that meets the user’s goals and expectations is a
challenging problem and in a sense the dual of the sensor data fusion problem.
7.1.4 Power generation / energy harvesting
Not all sensor networks harvest energy. A sensor network with battery-operated sensor nodes will
have a limited lifetime. It will die and stop functioning when a sufficient number of its nodes run out of
battery. One way of mitigating this problem is to periodically replace the batteries. However, this is not
convenient and it can be costly in case of a large sensor network. One other way is through use of energy
harvesting, where a sensor node uses some means of extracting energy from the environment in which
it is located. The most prominent example of energy harvesting is through use of solar cells. Another
possibility is through use of wind turbines.
7.2 Basic functions layer
7.2.1 Overview
Aside from data communications and data storage, the functional entities described under this entity
are strictly associated sensor nodes. Sensor nodes do data communications and data storage, but so do
other physical entities in the SNRA. Beyond sensing, actuation, and power generation, there are some
basic tasks that sensor nodes need to do. Those functionalities are grouped under “basic functions layer”
and are described next.
© ISO/IEC 2013 – All rights reserved 11
7.2.2 Data processing
A sensor node may employ various algorithms to process the raw data acquired by its sensors.
Averaging and filtering (linear or nonlinear) for removing additive or speckle noise are examples of
these algorithms. Data aggregation and data compression are other examples motivated by the fact that
the communication bandwidth – particularly in the case of wireless sensor nodes – is often a scarce
commodity. Therefore, it makes sense to process the raw data and reduce the volume of the data that
has to be communicated to neighbouring sensor nodes or a centralized processing entity that receives
data from all nodes in the network. The notion of sufficient statistics is well understood in the statistics
literature. The idea is to process the raw data and extract from it a much smaller data set, called the
processed data, which captures the “essence” of the raw data. Mathematically speaking, the optimum
decision based on the sufficient statistics would be as good as the optimum decision based on the raw
data in its entirety. One example that illustrates the use of sufficient statistics is detecting presence of
hostile forces in an area under military surveillance using many sensors. One can either transmit the raw
data from all sensors to a processing entity or transmit the sufficient statistics. If the optimum decision
rule regarding the presence of hostile forces based on the smaller data set has the same probabilities of
detection and false alarm, or more generally the same Receiver Operating Curve (ROC), as the optimum
decision rule based on the raw data, then the smaller data set is called a sufficient statistics. Along the
same lines, feature extraction is another type of processing that attempts to reduce the volume of the
data that has to be sent by the sensor nodes to other entities. A good example for feature extraction is in
the context of image and video data, where some important features of an image or video clip, such as
presence of certain objects, is captured and transmitted in lieu of sending every single pixel in the image
or all frames in the video clip.
Another aspect of data processing is data presentation and format. There has to be some agreed upon
way of interpreting the data exchanged by various entities. For example, when raw temperature data
are sent by one sensor node to another node or the central processing entity, there has to be a header
that specifies the units for temperature, e.g. Celsius vs. Fahrenheit, and perhaps the resolution of the
sensor. This requires presence of data presentation functions that add extra information to basic sensor
measurements in order to put the data in context.
7.2.3 Data communications
Data communications takes place between various physical entities in a sensor network as suggested by
Figures 1-3 in ISO/IEC 29182-1. The communications can be through a wire or an air interface (wireless)
and various protocols can be used for communications between various entities. The primary mode of
information exchange in the backbone is wired communications. In addition, the sensor nodes use wired
communications in certain deployments, for example sensors deployed in some buildings. Wireless
communications offer many advantages, among which are support for mobility and ease of deployment.
However, one has to deal with Radio Frequency (RF) interference issues, and it is physically easier to
eavesdrop on wireless transmissions.
The Internet uses the Internet Protocol (IP) at the network layer, but communications between some
entities in a sensor network – e.g. inter-sensor-node communications – may not be IP-based due to the
relatively large overhead of the IP. IEEE 802.15.4a, ZigBee, and IEEE 802.11 are some of the wireless
communications standards commonly used for inter-sensor-node communications. These standards deal
with the Physical (PHY) and Medium Access Control (MAC) layers of the protocol stack. Likewise, there
are a variety of standards that could be used by an access network. In the case of a wired access network,
Ethernet is the dominant Local Area Network (LAN) standard. There is a wide choice when it comes
to wireless communications standards. Examples include Bluetooth, IEEE 802.11 Wireless Local Area
Network (WLAN), and cellular telephony standards, such as 3G wireless standards (e.g. Universal Mobile
Telecommunications System (UMTS) and High Speed Packet Access (HSPA)) and 4G wireless standards
(e.g. Long Term Evolution (LTE) and Worldwide Interoperability for Microwave Access (WiMAX)).
Naturally, when it comes to data communications, a designer needs to specify other protocols used at
the higher layers of the OSI model, in particular network and transport layers. It is not the intent of this
part of ISO/IEC 29182 to address all aspects of data communications, as there are many other standards
that deal with those aspects.
12 © ISO/IEC 2013 – All rights reserved
7.2.4 Data storage
A sensor node may have storage for storing its raw/processed sensor data for some period of time. This
is useful in looking for “trends” in the acquired data or more generally for use by the data processing
algorithms that typically need more than just the latest sensor measurements.
There is data storage in other entities of a sensor network, e.g. historical database of events maintained
by service providers. This aspect is addressed elsewhere in this part of ISO/IEC 29182.
7.2.5 Hardware drivers
Device drivers are commonly used in a computer system to enable communications between the
computer and the devices connected to it. Similarly, they can be found in sensor nodes so that the node
can operate sensors and actuators. They work in conjunction with the processor at the sensor node.
7.2.6 Sensor/actuator identification
The presence and types of sensors and actuators at a sensor node can be specified via the Transducer
[3]
Electronic Data Sheets (TEDS) defined in the ISO/IEC/IEEE 21450 standard and the ISO/IEC/
[4]
IEEE 21451 series of standards . A TEDS contains information on sensor or actuator identification (ID),
physical units (such as degrees Celsius in case of temperature), measurement range, calibration, and
location (which might be updated by a self-localization capability such as Global Positioning System (GPS)
in case of a mobile sensor / actuator), user-specified information, manufacturing-related information,
and more. The TEDS is a means of self-identification and self-description of sensors and actuators, as
well as self-configuration of sensor systems. It simplifies field installation, upgrade, and maintenance
of sensors and actuators in systems, thus enabling sensor “plug and play” in instruments and networks.
7.3 Service layer
7.3.1 Overview
The functionalities described under Subclause 7.3 are distributed across many physical entities in the
sensor network, including sensor nodes, service providers, and users. In general, a variety of services
are available in a sensor network that are used by various applications running on the sensor network.
7.3.2 Common services
7.3.2.1 Overview
The services described below are common in the sense that they support a variety of sensor node
applications.
7.3.2.2 Communications support functions
Communications and networking require some support functions across various layers of the protocol
stack. For example, at the PHY layer there is need for error correction coding. At the network layer
there is routing, which can be computationally intensive in ad hoc and mesh sensor networks. Network
formation is another communications support function at the network layer. This is an important
functionality in ad hoc and mesh sensor networks, through which a sensor node discovers who its
neighbours are that it can communicate with.
7.3.2.3 Self-localization
More often than not, sensor data are more useful and meaningful if it is tagged with the time and location
at which it was acquired. Time synchronization is addressed in Subclause 7.3.2.7. As for localization,
some expensive sensor nodes may have a GPS receiver embedded in them. In that case, the sensor node
would know its location and the time through reception of messages from GPS satellites. More generally,
© ISO/IEC 2013 – All rights reserved 13
the same functionalities are provided by the Global Navigation Satellite System (GNSS). GNSS, however,
would work only if the GNSS receiver is in Line-Of-Site (LOS) of at least 4 GNSS satellites. Therefore, GNSS
would work and provide localization capability if the sensor node is located outdoors, excluding urban
canyons, and more generally not in GPS-/GNSS-denied environments. Another drawback of GPS/GNSS is
its high power consumption, which makes it unsuitable for most sensor nodes that are expected to run
on battery power for a long time.
Fortunately, there are other methods by which sensor nodes can self-localize. This is an active area
of research and development, but suffice it to say that there are RF methods (e.g. Time Of Arrival
(TOA), Angle Of Arrival (AOA), Received Signal Strength (RSS) based methods, and Radio Frequency
IDentification (RFID)), Inertial Measurement Units (IMUs), magnetometers, altimeters, Doppler radar,
and many other sensors that can be used for localization, particularly in indoor environments. The task
of combining various sensor outputs in order to arrive at an accurate estimate of the sensor node’s
location is a data fusion problem, which once again is the subject of active research.
There are also cooperative localization methods that solve for the locations of all sensor nodes in the
network jointly as opposed to solving for each node’s location independently. This results in more
accurate location solutions, because one can take advantage of simple geometric facts such as the triangle
inequality. Once again, there are both centralized and distributed cooperative localization algorithms.
7.3.2.4 Service/resource discovery
Service Discovery Protocols (SDPs) are used to determine what sensor network services are available.
For example, one may wish to determine if there is an unoccupied parking spot locator service when
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...