ETSI TR 101 584 V2.1.1 (2013-12)

Machine-to-Machine communications (M2M); Study on Semantic support for M2M Data

DTR/SmartM2M-017ed211

General Information

• Status: Published
• Publication Date: 17-Dec-2013
• Technical Committee: SmartM2M - Smart M2M
• Current Stage: 12 - Completion
• Due Date: 27-Dec-2013
• Completion Date: 18-Dec-2013
• Mandate: M/441

Standards Content (Sample)

Technical Report
Machine-to-Machine Communications (M2M);
Study on Semantic support for M2M Data

2 ETSI TR 101 584 V2.1.1 (2013-12)

Reference
DTR/SmartM2M-00017ed211
Keywords
interworking, M2M, semantic
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 101 584 V2.1.1 (2013-12)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 9
4 Introduction to semantic information on M2M data . 9
4.1 Problem description . 9
4.2 Benefits of semantic annotation . 10
4.3 What constitutes semantic information and how can it be structured . 10
4.3.1 Heuristic view . 10
4.3.2 Option 1: Standardized Data Types with implicitly defined semantics . 11
4.3.3 Option 2: Standardized Data Types with some defined semantics . 11
4.3.4 Option 3: eXtensible Markup Language (XML) . 12
4.3.5 Option 4: Ontologies . 12
4.3.6 A concrete approach for ETSI M2M . 12
4.3.7 Summary . 15
4.4 Semantic M2M and OBIX mapping . 15
4.5 How is semantic content introduced into the ETSI M2M System. 19
4.6 Existing work on semantics that could apply to ETSI M2M . 20
4.6.1 Overview . 20
4.6.2 Existing semantic projects . 20
5 Use cases for creation, management and usage of semantic information in the ETSI M2M System . 20
5.1 Overview . 20
5.2 Detailed use cases . 20
5.2.1 Use Case 1 - Home Control . 20
5.2.1.1 General Use Case Description. 20
5.2.1.2 Stakeholders . 21
5.2.1.3 Pre-conditions . 21
5.2.1.4 Flow of the use case . 21
5.2.1.5 Post-conditions . 21
5.2.1.6 Potential new requirements from this use case. 22
5.2.2 Use Case 2 - Device plug and play . 22
5.2.2.1 General Use Case Description. 22
5.2.2.2 Stakeholders . 22
5.2.2.3 Pre-conditions . 22
5.2.2.4 Flow of the use case . 22
5.2.2.5 Post-conditions . 22
5.2.2.6 Potential new requirements from this use case. 23
6 Summary of all potential requirements . 23
7 Potential architecture alternatives . 23
7.1 Device Abstraction . 23
7.1.1 Architecture . 23
7.1.2 Interworking with legacy devices (d) through abstract devices . 24
7.1.2.1 Native Resource . 25
7.1.2.2 Abstract Resource . 26
7.1.3 Gateway Resource Abstraction (GRA) capability . 26
7.1.4 Subscription of Abstract Resources . 26
7.1.5 Mapping Principle . 27
ETSI
4 ETSI TR 101 584 V2.1.1 (2013-12)
7.1.6 Abstract Resource Management (Add/Remove/Replacement) . 28
8 Conclusions . 28
Annex A: Application design support for semantic M2M data WI . 29
A.1 References . 29
A.2 Application design . 29
A.2.1 SCL base . 29
A.2.2 Resource name . 30
A.2.3 Containers. 30
A.2.4 Access rights . 31
A.2.5 Search strings . 31
A.2.6 Content types . 31
A.2.7 Partial addressing . 31
A.2.8 Expiration time . 31
A.2.9 Maximum URI length . 32
A.3 Impacts on semantic M2M data . 32
History . 33

ETSI
5 ETSI TR 101 584 V2.1.1 (2013-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Machine-to-Machine communications
(M2M).
The present document may be referenced by other TRs and Technical Standards (TS) developed by ETSI TC M2M.
The present document is a TR and therefore, the content is informative, but when this TR is referenced by a TS, the
referenced clauses may become normative with respect to the content of the referencing TS.
ETSI
6 ETSI TR 101 584 V2.1.1 (2013-12)
1 Scope
The present document is motivated by the fact that within the ETSI M2M System semantic information needs to be
available on M2M data that is transferred within the M2M system. Through such semantic information M2M data can
be discovered by applications that do not have prior knowledge on them. The capability of the ETSI M2M System to
enable applications to discover, interpret and use M2M data from different sources is considered essential for creating
high-level M2M services and to develop open markets for M2M data.
• In this study pre-normative work is conducted in order to facilitate normative specification work in ETSI M2M
Rel.-2 or later.
• The study analyses benefit, feasibility and potential requirements for the support of semantic information on
application related M2M Resources in the M2M system.
The ETSI M2M system would, however, only provide a means to create and handle such semantic information
in the ETSI M2M system; ETSI M2M continues to stay independent of 'vertical' markets who in general would
define the semantics of M2M data related to their field of expertise.
• The study creates use cases that illustrate provisioning and usage of such semantic information and that
demonstrate the benefit for the M2M ecosystem.
• It investigates on the kind and amount of semantic information that would become available in the M2M
system, keeping in mind a trade-off between complexity and usability.
• It investigates discovery mechanisms for semantic information in the ETSI M2M System. This should take
into account how existing solutions from other standards or research could be used within the ETSI M2M
architecture.
• It considers on issues of ownership/responsibility for application related M2M Resources in the case that the
M2M system can provide semantic information on them. This needs to take into account the need for support
of different levels of data privacy and confidentiality.
This study relates to WI 0014 (TR 102 966 [i.11] - Interworking between the M2M Architecture and M2M Area
Network technologies), as a further step in the abstraction of LAN technologies and devices. Existing relevant standards
are taken into account and the study aspires to benefit from inputs of related research projects.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
ETSI
7 ETSI TR 101 584 V2.1.1 (2013-12)
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 102 725: "Machine-to-Machine communications (M2M); Definitions".
[i.2] [Guarino, 98] Formal Ontology in Information Systems.
NOTE: Available at: http://www.loa.istc.cnr.it/Papers/FOIS98.pdf.
[i.3] W3C: XML Technology.
NOTE: Available at: http://www.w3.org/standards/xml/.
[i.4] W3C: Semantic Web.
NOTE: Available at: http://www.w3.org/standards/semanticweb/.
[i.5] W3C: OWL Web Ontology Language.
NOTE: Available at: http://www.w3.org/standards/techs/owl.
[i.6] W3C: SPARQL Current Status.
NOTE: Available at: http://www.w3.org/standards/techs/sparql#w3c_all.
[i.7] W3C: Resource Description Framework (RDF).
NOTE: Available at: http://www.w3.org/RDF/.
[i.8] W3C: W3C Semantic Sensor Network Incubator Group.
NOTE: Available at: http://www.w3.org/2005/Incubator/ssn.
[i.9] IETF RFC 1738: "Uniform Resource Locators (URL)".
[i.10] ETSI TS 102 690: "Machine-to-Machine communications (M2M); Functional architecture".
[i.11] ETSI TR 102 966: "Machine-to-Machine Communications (M2M); Interworking between the
M2M Architecture and M2M Area Network technologies".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 102 725 [i.1] and the following apply.
NOTE: A term defined in the present document takes precedence over the definition of the same term, if any, in
TR 102 725 [i.1].
Abstract Application Information Model: information model of common functionalities abstracted from a set of
Device Application Information Models
Abstraction: process of mapping between a set of Device Application Information Models and an Abstract Application
Information Model according to a specified set of rules
Application Information Model: information model of an Application, including data and methods
NOTE: An Application Information Model may have Representations expressed in specific operational protocols.
attribute: characteristic of an Entity
NOTE 1 Also called "property", "characteristics", "characteristics".
ETSI
8 ETSI TR 101 584 V2.1.1 (2013-12)
NOTE 2: The state of an Entity is determined by its Attributes
EXAMPLE: Name, Time, Location.
Concept: fundamental category of existence
NOTE: Also called "entity type", "category", "subsystem", "class".
EXAMPLE: Person, Car, 4-Wheel-Drive, Ford Explorer. ®
Device Application Information Model: technology (e.g. ZigBee ) specific Information Model of the physical device
entity: an instance of a Concept
Management Plane: part of the ETSI M2M System that carries the operations and administration traffic required for
network management
EXAMPLE: Software download, Statistic collection, Set/Get of parameters that provide policy or configuration
settings. Any and all network management functions are provided by a service provider.
ontology: formal specification of a conceptualization, that is defining Concepts as objects with their properties and
relationships versus other Concepts
Operational Plane: part of the ETSI M2M System that offers capabilities (methods, data) that are needed for
delivering the intended services (M2M Services and Application Services) from/by the Network Domain, Devices and
Gateways
physical entity: tangible element that is intrinsic to the environment, and that is not specific to a particular M2M
application in this environment
NOTE: Depending on the environment, the physical entity may be an appliance, a piece of furniture, somebody, a
room of a building, a car, a street of a city, etc. To be part of the M2M/IoT architecture, a physical entity
does not need to be connected through a direct network interface, or even to be identified through a
universal identification scheme such as RFID/EPC global, provided it can be sensed by sensors that are
supposed to be deployed in this environment, and possibly acted upon by actuators.
physical entity proxy: contextually identifies and represents a physical entity; it implements an executable version of
the informational model of the physical entity and serves as an intermediary towards applications, providing them an
interface for control and monitoring of this entity with the primitives defined in the corresponding model
NOTE: Proxies representing individual physical entities are all distinct software components at the same
hierarchical level and do not contain one another, even if the corresponding entities have such
containment relationships; for example the proxy of a room will not contain the proxy of a an appliance,
even if this appliance is inside the room.
relation: specifies how Concepts (objects) are related to other objects stating a relationship among Concepts
NOTE: Also called "relationship", "interrelation" relations are part of an Ontology.
EXAMPLE: "is-part-of", "is-subtype-of".
Representation: expression of an Application Information Model in terms of the operational protocol of a specific ®
technology (e.g. ETSI M2M, ZigBee .)
Representation Interworking: process of mapping and synchronizing multiple Representations of an Application
Interface
Set Of Things Representation: group of Thing Representations that share a common property or functionality
NOTE: A Thing Representation can belong to several Set Of Things Representations.
EXAMPLE: It can contain Thing Representations of:
• Things that radiate heat (radiators, electric appliances and even human beings);
• Things that provide lighting (lights, display screens and windows).
ETSI
9 ETSI TR 101 584 V2.1.1 (2013-12)
Thing: element of the environment that is individually identifiable in the M2M system
Thing Representation: instance of the informational model of the Thing in the M2M System
NOTE A Thing Representation provides means for applications to interact with the Thing.
Translation: combination of Abstraction and Representation Interworking
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 102 725 [i.1] and the following apply.
NOTE: An abbreviation defined in the present document takes precedence over the definition of the same
abbreviation, if any, in TR 102 725 [i.1].
OWL Web Ontology Language
RDF Resource Description Framework
4 Introduction to semantic information on M2M data
4.1 Problem description
Release 1 of ETSI M2M defines a Service Capability Layer which is enabling transport of M2M data between devices
or gateways and network applications. Release 1 provides an abstraction layer hiding the heterogeneity of M2M access
networks and provides means for secure data transport. By design choice, the ETSI M2M Rel.1 SCL is handling only
data containers without any knowledge of the data contained. The advantages of this approach are:
• a clean separation of data transport from data handling;
• focus on the generic, commonly needed functions of an SCL - thus avoiding applications-specific functionality
to be included into the ETSI M2M standards.
More precisely, the current release assumes that applications know all details of the device installation they interact
with, e.g.:
• how devices are identified as being useful/relevant for the application;
• what actions are performed by the device (e.g. what kind of data can be provided by the devices);
• how to interpret the data delivered by the devices.
While Rel. 1 of ETSI M2M already opens a lot of opportunities in the M2M area, there are a number of limitations:
• the common-place vertically integrated, but isolated M2M applications are now replaced by M2M applications
which are re-using a common data transport, but which are still vertically integrated and isolated from each
other;
• device and application need to agree beforehand on a common definition of the exchanged containers as well
as on the contained data. This makes re-use of M2M data across different applications difficult;
• there are only very limited functions in Rel.1 to discover which data are available in an SCL;
• there is no support in the SCL to enable an open market of data, e.g. in which data owner publish (sell) their
data and independent data users provide applications that make use of the data;
• limited chances for ETSI M2M compliant platform providers to enable value-added services re-using M2M
data;
• limited opportunities for treating different kinds of M2M data with different Quality-of-Service or by charging
differently for them.
ETSI
10 ETSI TR 101 584 V2.1.1 (2013-12)
For operators and providers of an ETSI M2M compliant platform this is limiting their ability for offering new and
innovative business models.
To overcome these limitations
• data transmitted in M2M services need both, the semantics and the level of abstraction, that could make it
possible to provide them as a pool of common data available in a given environment and to share them
between different applications, without these applications needing to know beforehand the specifics of these
data (units, metadata, context, etc.);
• the physical entities that are sensed and acted (e.g. appliances, people, cars, rooms of a building, or more
generally self-contained subsystems of a larger system that makes up the target environment) need to be
modelled with a level of abstraction allowing the M2M system to treat them as generic entities, intrinsic to the
environment and not tied to a specific M2M application.
4.2 Benefits of semantic annotation
By providing means to understand M2M data, the available business models can be greatly enhanced. For example,
through offering additional semantic information about the data, platform provider can enable (and potentially charge
for) the discovery of devices and data by semantic specification. Another possible business that can be provided would
be to provide derived information from the provided raw data through intelligent processing, e.g. analysing the data,
aggregating data across many different data sources, or to provide interpreted data as an additional service.
Support for semantically annotated M2M data and related advanced operations like discovery or resolution from
real-world entities to sensors/resources and vice versa will for example enable the following:
• re-use of M2M data by many applications - data can be "brokered" by the M2M Service Provider;
• "write-once run-anywhere" applications (which automatically adapt to the specific device installation);
• simplified configuration of M2M applications and more intelligent adaptation to changing situations;
• easy adaptation in case of failures/changes of the available sensor sets;
• easy creation of generic tools (e.g. for visualization, data processing).
Such 'intelligent' applications will require some notion and modelling of the 'real world' in which they provide services.
For example M2M applications are not interested in sensors and actuators themselves, but in what is being sensed by
the sensors, or acted upon by actuators. The relevant level of abstraction for M2M data pooling should thus not be
confined to individual sensors and actuators. It should rise to the level of physical entities that are being sensed by
sensors and acted upon by actuators. Depending on the environment, these entities may be appliances, people, cars,
rooms of a building, or more generally self-contained subsystems of a larger system that makes up the target
environment. These entities are generic, intrinsic to the environment and not tied to a specific M2M application. They
can be legacy appliances or completely passive "things" that need not be directly connected through a network interface,
or not even to be identified through a universal identification scheme (such as RFID/EPC global).
However, in the context of ETSI M2M only those entities need to be considered, that can interact with the ETSI M2M
System. For example a "room" entity can be sensed by the sensors in that room.
4.3 What constitutes semantic information and how can it be
structured
4.3.1 Heuristic view
Figure 1 shows the hierarchy of semantic information, ranging from raw data to real-world context information. As the
picture explains, we are looking at two kinds of data. First the data handled by an ETSI M2M System, e.g. a measured
value. Secondly, the data that is describing a specific sensor including information on what kind of measurement is
returned and what information in which context is actually measured. Both kinds of information are needed for the
semantic support of M2M data.
ETSI
11 ETSI TR 101 584 V2.1.1 (2013-12)
application
data description device description
meaning-
fulness John’s body measures
real-world
temperature John’s body
context
temperature
measures a
physical
temperature
temperature
type value
in Celsius
algebraic
float returns a
type
float
sensor_18
raw data
Figure 1: semantic information hierarchy
Note that the top level of the semantic hierarchy assumes a model of real-world context. Typically, such a context
model would consider the world to be composed of physical entities, and the state of the world is determined by the
attributes of these entities. In figure 1 the entity would be "John", while the attribute would be "body temperature".
The support of ETSI M2M release 1 for semantic annotation of data is limited to the specification of a MIME type of
data containers, which corresponds to the second lowest level. On the device description side, there is no support for
semantic annotations at all.
Adding semantic information to a system can be done in various forms. In the following we discuss a few possible
options. The goal is to explain in this study what can be done and through that to enable a decision how best to add
semantic information. (See for example the Semantic Web lecture at http://www.sti-
innsbruck.at/teaching/curriculum/semantic-web/ for a good overview about the semantic web).
4.3.2 Option 1: Standardized Data Types with implicitly defined semantics
Traditionally, communication systems have standardized data types to be commonly used between various applications.
The semantic of this information might be defined through the respective standard. Unfortunately, this implicit mapping
of a data type to a specific semantic meaning is not always given and might lead to errors.
EXAMPLE: The traditional email address "[e-mail]" has a clear implicit semantics. Email addresses
can be used when composing and sending emails. Unfortunately, email adresses have been used as
identifier for user and devices in computer systems that do not necessarily provide a mailbox with
the given email address. So the implicitly given semantics ("you can send an email to this
address") is broken. In an M2M system, this relying on an implicitly given semantics can lead to
errors.
4.3.3 Option 2: Standardized Data Types with some defined semantics
RFC 1738 [i.9] defines the syntax and semantic of the Uniform Resource Locator (URL). A URL has the format:

:
The part defined the usage of the URL and also determines how the is interpreted.
The following schemes are reserved and define a mapping between the scheme and respective defined Internet
protocols:
ftp           File Transfer protocol
http          Hypertext Transfer Protocol
gopher         The Gopher protocol
ETSI
12 ETSI TR 101 584 V2.1.1 (2013-12)
mailto         Electronic mail address
news          USENET news
nntp          USENET news using NNTP access
telnet         Reference to interactive sessions
wais          Wide Area Information Servers
file          Host-specific file names
prospero        Prospero Directory Service
As an example, the URL "mailto:[e-mail]" specifies an address to which mails can be sent. The syntactically
similar "ftp:[e-mail]" defines an FTP server that should be accessed using the account "user". These examples
show that semantics can be explicitly given as part of the naming or addressing schemes.
4.3.4 Option 3: eXtensible Markup Language (XML)
XML is a framework for defining markup languages. It is used to describe arbitrary complex data structures. XML
defines a common syntax to represent data in an ordered, labelled tree. Similar to the Option 1, an XML-based markup
language first defines the syntax of the data, not the semantics. XML Schemas enable a syntactical verification that a
certain XML document is adhering to the defined schema.
As XML is more expressive with its ordered, labelled tree, there are again the possibilities of explicitly defining
semantics through labels or annotations in the XML tree. As XML is a framework for defining markup languages, these
newly defined languages can define the semantic aspects of its elements.
See [i.3].
4.3.5 Option 4: Ontologies
An ontology represents knowledge as a set of concepts and the relationship between the concepts. Thus using an
ontology semantic concepts can be described. Annotating information with ontology references links the information to
these concepts. On this basis, semantic tools and mechanisms like reasoning can be employed.
The following technologies are typically used as a basis for describing ontologies:
• Uniform Resource Identifier (URI): identifies things and concepts in the semantic web
�URIs are used to identify resources in the semantic web. see [i.4];
• RDF: Resource Description Framework: an XML-based markup-language to represent the triples (subject;
predicate; object) see [i.7]
�RDF is used to make statements about resources;
• OWL (Ontology Web Language): a language to represent Ontologies in the Web (see [i.5]);
• SPARQL: Query language for RDF triples (see [i.6]).
For further details please refer to the respective W3C standards [i.3] to [i.7].
4.3.6 A concrete approach for ETSI M2M
An M2M system is set up to acquire data from a large-scale physical system and control it in return. Shared sensors and
actuators are distributed as monitoring and control points through this physical system.
A set of entities, subsystems of the overall physical system, are defined as the components of the overall physical
system that are relevant for controlled and monitored by the targeted application. These subsystems are distinct physical
entities which are fully-fledged physical systems in their own right. The overall physical system is made up of the
composition of these physical subsystems for what is relevant to the application at hand. The sensors and actuators are
not target entities themselves they are used just as transparent intermediaries.
ETSI
13 ETSI TR 101 584 V2.1.1 (2013-12)
A target subsystem is defined as a self-contained subset of the overall target physical system or process that can be
individually monitored and actuated, either indirectly through sensors and actuators or directly, if it is equipped with its
own network connection. These two possibilities are not actually exclusive, and a subsystem with a network connection
may still need to be monitored/controlled through complementary external sensors and actuators because the network
connection does not provide access to the required data or functionality.
If we take as an application example home/building energy management, the overall physical system is in this case the
home or building itself, and examples of the target physical subsystems are:
• appliances and devices including all types of pieces of home or office equipment;
• rooms of the building;
• Components of the building (including walls, roof, openings, etc.), as long as it makes sense to deal with them
individually rather than as parts of a larger subsystem.
These mostly non-digital subsystems have to be integrated in the supervisory M2M system in a way similar to what is
done with regular networked entities. This means they have to be identified and matched to an existing model that can
be specific or generic, exact or approximate.
Figure 2 shows a possible modelisation of a home subsystem, which would be composed of an Appliance-category and
of a Room-category subsystem.
Subsystem
Appliance
Room
Duration of
Mode of
Usage Electrical operation Usage mode
occupancy Energy occupancy
semi- multi-
ON-OFF Manual/ Non
long-lived transient
periodic permanent one person
ON-OFF Autonomous heated room
random User-directed person heated
STANDBY
LCD Washing Portable Photovoltaic
Laptop Fridge
machine Livingroom Toillette bathroom dining room bedroom
Display Heater panel
Living-room generic model
Washing machine model
-HAVC state
empty social
-time
OFF
-HAVC
heat
activity
-N of P
-Water m
water state
o
-Water c
-time
wash
o
-Water c
watching -HAVC state
occupied
-HAVC
TV -time
Stand
rinse state -N of P
by
-N of P
Eating
spin
-Water m
tumble-
dry
-Temperature
Figure 2: Ontology comprising two categories of subsystems (rooms and appliances)
for the home environment
Architectural consideration
One of the goals of using semantic is to take into account 'things' in the M2M system. The idea is not to limit the M2M
system to the consideration of a sensor network but to extend into an infrastructure that supports un-digitized "thing-
computer" interfaces inspired from ambient and context-aware "human-computer" interfaces as if they were regular
devices.
Devices can be identified by approximation to a very generic model, and the system should be able to integrate them on
the basis of this minimal information.
ETSI
14 ETSI TR 101 584 V2.1.1 (2013-12)
For example, a camera is a single sensor that acquires data. The latter are analyzed by a "thing" recognition and
monitoring software. We can consider then that every individual thing or physical entity within the field of view of this
camera becomes a "networked thing", provided it can be recognized and monitored by this software This means it can
have a presence on the M2M system, without requiring an RFID tag or even a digital optical code (such as a 1D or 2D
barcode) for this. Thus the range of things that may become indirectly connected to the network can extend much
further than sensor devices themselves, to all things that are individually identifiable by a sensor.
As the counterparts of sensors, actuators transduce numerical variables into physical ones. They enact modifications of
the physical environment and the effects of these are either sensed directly by sensors, or indirectly, through passive
things which are modified by the actuators. These new physical "actuator-to-thing" links complement the "sensor-to-
thing" links.
The notion of bilateral "sensor to thing" links presented above is a simple abstraction of the multilateral reality of
context sensing that should apply for the identification and monitoring of things.
Networked "things" may then comprise all "stuff" that can be sensed by pattern recognition software operating on top of
these federated sensors working together, potentially overcoming their individual limitations.
When using basic sensors such as passive infrared, door contact or electrical sensors, both the detection of temporal
coincidence of events from different sensors (as potentially coming from the same physical entity) and the application
of simple filtering rules to these multi-sensor events are used. The consolidation of these events will then depend on the
corresponding model of the originating physical entity.
An ICT system is set up to acquire data from a large-scale physical system and may control it in return. Shared sensors
and actuators are distributed as monitoring and control points through this physical system; they are not target entities
themselves, but rather some transparent intermediaries. The ICT system will "shadow" each of these nodes individually
through matching software components (proxies) that will offer the required interfaces to the Things in this
environment. The ICT system should have the capability to provide an automatic association with the entity proxy of
the interfaces to the subset of sensors and actuators used as intermediaries for the monitoring and control of a given
entity.
This can be illustrated through the reference architecture in figure 3.

Figure 3: Reference architecture of the ICT system incorporating physical entities
ETSI
15 ETSI TR 101 584 V2.1.1 (2013-12)
An additional separate layer of "entity groups" is needed to represent aggregation or containment relationships between
physical entities, with a 1-to-n or n-to-1 mapping to the physical entity layer. An entity group representation may thus
link to several physical entities or a physical entity may link to several entity group representations.
If we take home energy management as an example, examples of the physical entities would be:
• appliances and devices of all types, including all pieces of legacy home equipment, such as a lamp, PC, etc.;
• rooms of the home;
• energy-relevant components of the home such as walls, windows.
The physical entity "lamp" may then be mapped to two entity group representations:
• "heating entities" group representation;
• "entities producing light" group representation.
For monitoring an entity, an application can obtain the instantaneous state of this entity as the discrete state of the
corresponding entity proxy. This discrete state is estimated as a result of the fusion, aggregation, consolidation and
classification of data from sensors associated with the entity.
For control purposes, an application can effect a change in the state of an entity through the entity proxy that relays this
high-level state-change control order to low-level control data for the associated actuators.
Non-digital entities such as pieces of furniture, pets, or the home occupants themselves have to be identified and
matched to an existing model that can be specific or generic, exact or approximate.
Example for monitoring of real-world entities that have mains connection:
• As for legacy appliances whose only available interface is that of their mains connection, this interface makes
it possible to identify these appliances through the characteristic features of the patterns exhibited by their
electric power consumption through an electric power sensor (like e.g. an oven showing a steady plateau
pattern whereas a washing machine has characteristic peaks and troughs). When these appliances are identified
and enrolled into the extended home network in this way, it becomes possible to monitor and control them as
specific or semi-generic entities, even though this control is limited to the mains interface.
4.3.7 Summary
The descri
...