Internet DRAFT - draft-robles-t2trg-functionalitydescription
draft-robles-t2trg-functionalitydescription
T2T Research Group M. Robles
Internet-Draft Aalto
Intended status: Informational B. Silverajan
Expires: September 27, 2019 TAU
March 26, 2019
IoT Semantic Functionality Description
draft-robles-t2trg-functionalitydescription-00
Abstract
This document defines firstly functionality levels for IoT devices
that describe the device capabilities at the granularity of devices,
objects and resources. It additionally presents a metric to measure
the functional similarity between the manageable properties of any
two IoT devices, called Functionality Distance (FD), which is defined
as the indication of the extent to which one device can be
substituted for the other.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Robles & Silverajan Expires September 27, 2019 [Page 1]
Internet-Draft similarfunctionality March 2019
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functionality Levels . . . . . . . . . . . . . . . . . . . . 3
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Functionality Distance . . . . . . . . . . . . . . . . . . . 5
4.1. LwM2M Resource Semantic Distance (LwRSD) . . . . . . . . 7
4.2. Web of Things Semantic Functionality Distance(WoTSFD) . . 7
5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Internet of Things (IoT) involves the interconnection of a variety of
heterogeneous devices. Managing these diverse sets of devices is
however extremely challenging. In certain usage scenarios, it is
essential to identify the IoT devices that have semantically similar
properties as a group and control them with a single management
command, so that they can substitute for each other in case any of
them fails. IoT devices may be employed by the device owner in
operational contexts or usage scenarios that were not originally
envisioned at production time by the device vendor.
This document defines firstly functionality levels for IoT devices
that describe the device capabilities at the granularity of devices,
objects and resources. It additionally presents a metric to measure
the functional similarity between the manageable properties of any
two IoT devices, called Functionality Distance (FD). FD calculates a
specific distance between the two devices, with the said distance
being an indication of the extent to which one device can be
substituted for the other. In experimental evaluations [LwRSD], the
results show that this mechanism successfully uncovers similarities
between resources that are not that straightforward at first glance.
For example, network connected TVs, smart speakers and light-bulbs
can be used as emergency warning systems in a building.
Robles & Silverajan Expires September 27, 2019 [Page 2]
Internet-Draft similarfunctionality March 2019
2. Functionality Levels
An IoT device can be considered to be semantically composed as a set
of objects, with each object being a set of resources. The resource
is an atomic piece of device information that can be managed. This
document presents three level of functionalities as shown in
Figure 1: Device Functionality, Object Functionality, Resource
Functionality, that together delineate the complete functionality of
the device. (TODO provides specific definition for each one)
+----------------------------------------+
| |
| DEVICE FUNCTIONALITY |
| |
| |
+----------------------------------------+
| |
| OBJECT FUNCTIONALITY |
| |
| |
+----------------------------------------+
| |
| RESOURCE FUNCTIONALITY |
| |
| |
+----------------------------------------+
Figure 1: Functionality Levels.
The Devices could present different functionalities, for example, the
one that is given by the Manufacturer and then, the user can define
different functionalities for the devices. For example, Figure 2
depicts a device composed of 2 objects. The manufacturer provides
Functionality 1 (composed of both objects, and their resources), as
well as Functionality 2 (composed only of object 2 and resource 3).
Upon obtaining ownership of the device, the user defines two
additional functionalities: Functionality 3 (composed only of object
1 and resource 2) and Functionality 4 (composed of object 1, resource
1 and object 2, resource 3).
Robles & Silverajan Expires September 27, 2019 [Page 3]
Internet-Draft similarfunctionality March 2019
+-----------------------+ +---------------------------------------+
| | |Functionality Given by the Manufacturer|
| Device 1 | | |
| | |Functionality 1: |
+-----------------------+ | Object 1(Resource1, Resource 2) |
| | | Object 2 (Resource 1, Resource 3) |
+-----------------------+ | |
|-| Object 1 || |Functionality 2: |
|-| || |Object 2: (Resource 3) |
|-| || +---------------------------------------+
|-| +---------------+ ||
|-| | Resource 1 | ||
|-| +---------------+ ||
|-| ||
|-| +---------------+ ||
|-| | Resource 2 | ||
|-| +---------------+ ||
|-| || +-----------------------------------------+
+-----------------------+ | Functionality Given by the User |
| | | |
+-----------------------+ | Functionality 3: Object1(Resource 2) |
|-| Object 2 || | |
|-| +--------------+ || | Functionality 4: Object1 (Resource 1), |
|-| | Resource 1 | || | Object 2 (Resource 3) |
|-| +--------------+ || | |
|-| || | |
|-| +---------------+ || +-----------------------------------------+
|-| | Resource 3 | ||
|-| +---------------+ ||
|-| ||
|-----------------------|
+-----------------------+
Figure 2: Functionality Configuration
3. Use cases
Some use cases where defining Functionalities and FDs for grouping
and managing IoT devices are presented here:
o Alert in case of fire: The goal in this use case is to group the
devices that present some type of features that can be used to
alert a user in case of fire.
o Reduction of the sound in a room: The goal in this use case is to
identify (group) devices that produce some type of sound like
audio, buzzer and turn them off.
Robles & Silverajan Expires September 27, 2019 [Page 4]
Internet-Draft similarfunctionality March 2019
o Event Notification to a disabled person: The goal in this use case
is to find the devices that present features that can be used for
disabled people to get information about the environment. For
example for a deaf person, we are interested in grouping devices
that can notify to that person about events, such as the
dishwasher stop, through a sighted-sensor like light-bulb change
color.
o TODO add more use cases.
4. Functionality Distance
In certain usage scenarios, it is required to identify the IoT
devices that have similar properties as a group and control them with
a single management command. This can not only lead to efficiency
gains at the protocol level, but also improve the overall user
experience. As an example, consider the case of a fire emergency in
a smart building. In such a scenario, it would be useful to group
all Internet-connected IoT devices that have any output capability,
to warn the users in their vicinity about the danger of a fire, so
that they can substitute for each other if any of them fails.
One way to address the above requirement is to calculate the
relatedness between devices through what we call functionality
distance. The functionality distance in this document is defined as
the capability between two devices to perform the same function. We
define a set of contextual requirements, e.g., the device should be
able to alert in case of fire, and based on that we define weights to
each resource. Then, we calculate the distance between the resources
as per the contextual requirements.
The method that calculates the semantic distance between two objects
should have these properties:
o The objects that are equal semantically should have distance of 0.
o The objects that are quite close semantically should have distance
close to 0
o The objects that are far semantically should have distance close
to 1.
o The objects that are not related semantically should have distance
of 1.
o The distance between object A and B should be the same that
between the object B and A.
Robles & Silverajan Expires September 27, 2019 [Page 5]
Internet-Draft similarfunctionality March 2019
o The method should be able to be adapted to any type of environment
and objects.
The Functionality Distance metric considers the following components:
1. A Set of Contextual Requirements (SCoRq): These requirements have
the function to fulfill one or more goals, e.g., I have a goal to
group devices that are able to alert about a fire. Namely, these
requirements help to identify the relevance of a property to
fulfill the goal, e.g. a device with a dimmable feature allows
alerts in case of fire by changing the color of the device. In
this scenario, a property that indicates if the device has a
dimmable feature has more relevance than the property that define
the name of the device. SCoRq is defined as a set of properties.
The amount of properties of a SCoRq is indicated with tr. SCoRq
= {pr_1, pr_2, ..., pr_{tr}},
2. The weight assigned to the resource property (p): Indicates the
relevance of the property to fulfill a goal, namely the
contextual requirement (SCoRq). The values close to 1 for p
indicate that the property is relevant to fulfill the contextual
requirement and values close to 0 indicate that the relevance is
minimal, e.g., a dimmable property is going to have p = 0.95,
since it is relevant to alert in case of fire. On the other
hand, the name of the device does not provide useful information
since it can be an arbitrary name, then the weight should not be
high, we could assign a value of p = 0.10.
3. Direct Links (DL) between resources: If two resources have the
same property, it implies that there exists a link (Direct Link)
between them, e.g., if a Smart Tv object and a light bulb both
have a dimmable property, it means that there exists a link
between the Smart Tv and the light bulb. The value of the DL is
the weight assigned to a property.
The relatedness between properties of two devices is defined as
FD(a,b)= (n-dl)/(1+SDL(a,b)), where "n" is the total number of
properties, "dl" is the total number of direct links between
properties and "SDL" indicates the Sum of all Direct Links between
properties of two devices.
The mechanisms described in this document have been applied to two
research papers described in the following subsections to two
specific architectures.
Robles & Silverajan Expires September 27, 2019 [Page 6]
Internet-Draft similarfunctionality March 2019
4.1. LwM2M Resource Semantic Distance (LwRSD)
This metric is applied to LWM2M protocol, the metric is called LwM2M
Resource Semantic Distance (LwRSD) [LwRSD]
4.2. Web of Things Semantic Functionality Distance(WoTSFD)
The metric is applied also to Web of Things in a metric that is
called Web of Things Semantic Functionality Distance(WoTSFD) [WoTSFD]
5. Future Work
Future work considers these work items:
1. Adding a terminology section
2. Being able to express the functionality of a device, object or
resource as repeatable metadata or as part of the data model
3. Suitability for purpose: Allowing Device A to discover the
functionalities of adjacent devices to discover the most suitable
device in an operating environment, based on the needs of Device A.
6. IANA Considerations
TBD
7. Security Considerations
TBD
8. Acknowledgments
TBD
9. Informative References
[LwRSD] "M. I. Robles, N. Beijar and N. C. Narendra, "Measuring
Semantic Distance between LWM2M Resources," 2017 IEEE
International Conference on Internet of Things (iThings)
and IEEE Green Computing and Communications (GreenCom) and
IEEE Cyber, Physical and Social Computing (CPSCom) and
IEEE Smart Data (SmartData), Exeter, 2017, pp. 625-634".
Robles & Silverajan Expires September 27, 2019 [Page 7]
Internet-Draft similarfunctionality March 2019
[RFC7547] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and U.
Herberg, "Management of Networks with Constrained Devices:
Problem Statement and Requirements", RFC 7547,
DOI 10.17487/RFC7547, May 2015,
<https://www.rfc-editor.org/info/rfc7547>.
[WoTSFD] "M. I. Robles, B. Silverajan and N. C. Narendra, "Web of
Things Semantic Functionality Distance," Accepted for
publication to 2019 IEEE 26th International Conference on
Telecommunications, 2019".
Authors' Addresses
Maria Ines Robles
Aalto University
Espoo
Espoo 02760
Finland
Email: maria.robles@aalto.fi
Bilhanan Silverajan
Tampere University
Kalevantie 4
Tampere, FI 33100
FI
Email: bilhanan.silverajan@tuni.fi
Robles & Silverajan Expires September 27, 2019 [Page 8]
