idnits 2.17.1 draft-robles-t2trg-functionalitydescription-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2019) is 1852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7547' is defined on line 318, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 T2T Research Group M. Robles 3 Internet-Draft Aalto 4 Intended status: Informational B. Silverajan 5 Expires: September 27, 2019 TAU 6 March 26, 2019 8 IoT Semantic Functionality Description 9 draft-robles-t2trg-functionalitydescription-00 11 Abstract 13 This document defines firstly functionality levels for IoT devices 14 that describe the device capabilities at the granularity of devices, 15 objects and resources. It additionally presents a metric to measure 16 the functional similarity between the manageable properties of any 17 two IoT devices, called Functionality Distance (FD), which is defined 18 as the indication of the extent to which one device can be 19 substituted for the other. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 27, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Functionality Levels . . . . . . . . . . . . . . . . . . . . 3 57 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Functionality Distance . . . . . . . . . . . . . . . . . . . 5 59 4.1. LwM2M Resource Semantic Distance (LwRSD) . . . . . . . . 7 60 4.2. Web of Things Semantic Functionality Distance(WoTSFD) . . 7 61 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Informative References . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Internet of Things (IoT) involves the interconnection of a variety of 71 heterogeneous devices. Managing these diverse sets of devices is 72 however extremely challenging. In certain usage scenarios, it is 73 essential to identify the IoT devices that have semantically similar 74 properties as a group and control them with a single management 75 command, so that they can substitute for each other in case any of 76 them fails. IoT devices may be employed by the device owner in 77 operational contexts or usage scenarios that were not originally 78 envisioned at production time by the device vendor. 80 This document defines firstly functionality levels for IoT devices 81 that describe the device capabilities at the granularity of devices, 82 objects and resources. It additionally presents a metric to measure 83 the functional similarity between the manageable properties of any 84 two IoT devices, called Functionality Distance (FD). FD calculates a 85 specific distance between the two devices, with the said distance 86 being an indication of the extent to which one device can be 87 substituted for the other. In experimental evaluations [LwRSD], the 88 results show that this mechanism successfully uncovers similarities 89 between resources that are not that straightforward at first glance. 90 For example, network connected TVs, smart speakers and light-bulbs 91 can be used as emergency warning systems in a building. 93 2. Functionality Levels 95 An IoT device can be considered to be semantically composed as a set 96 of objects, with each object being a set of resources. The resource 97 is an atomic piece of device information that can be managed. This 98 document presents three level of functionalities as shown in 99 Figure 1: Device Functionality, Object Functionality, Resource 100 Functionality, that together delineate the complete functionality of 101 the device. (TODO provides specific definition for each one) 103 +----------------------------------------+ 104 | | 105 | DEVICE FUNCTIONALITY | 106 | | 107 | | 108 +----------------------------------------+ 109 | | 110 | OBJECT FUNCTIONALITY | 111 | | 112 | | 113 +----------------------------------------+ 114 | | 115 | RESOURCE FUNCTIONALITY | 116 | | 117 | | 118 +----------------------------------------+ 120 Figure 1: Functionality Levels. 122 The Devices could present different functionalities, for example, the 123 one that is given by the Manufacturer and then, the user can define 124 different functionalities for the devices. For example, Figure 2 125 depicts a device composed of 2 objects. The manufacturer provides 126 Functionality 1 (composed of both objects, and their resources), as 127 well as Functionality 2 (composed only of object 2 and resource 3). 128 Upon obtaining ownership of the device, the user defines two 129 additional functionalities: Functionality 3 (composed only of object 130 1 and resource 2) and Functionality 4 (composed of object 1, resource 131 1 and object 2, resource 3). 133 +-----------------------+ +---------------------------------------+ 134 | | |Functionality Given by the Manufacturer| 135 | Device 1 | | | 136 | | |Functionality 1: | 137 +-----------------------+ | Object 1(Resource1, Resource 2) | 138 | | | Object 2 (Resource 1, Resource 3) | 139 +-----------------------+ | | 140 |-| Object 1 || |Functionality 2: | 141 |-| || |Object 2: (Resource 3) | 142 |-| || +---------------------------------------+ 143 |-| +---------------+ || 144 |-| | Resource 1 | || 145 |-| +---------------+ || 146 |-| || 147 |-| +---------------+ || 148 |-| | Resource 2 | || 149 |-| +---------------+ || 150 |-| || +-----------------------------------------+ 151 +-----------------------+ | Functionality Given by the User | 152 | | | | 153 +-----------------------+ | Functionality 3: Object1(Resource 2) | 154 |-| Object 2 || | | 155 |-| +--------------+ || | Functionality 4: Object1 (Resource 1), | 156 |-| | Resource 1 | || | Object 2 (Resource 3) | 157 |-| +--------------+ || | | 158 |-| || | | 159 |-| +---------------+ || +-----------------------------------------+ 160 |-| | Resource 3 | || 161 |-| +---------------+ || 162 |-| || 163 |-----------------------| 164 +-----------------------+ 166 Figure 2: Functionality Configuration 168 3. Use cases 170 Some use cases where defining Functionalities and FDs for grouping 171 and managing IoT devices are presented here: 173 o Alert in case of fire: The goal in this use case is to group the 174 devices that present some type of features that can be used to 175 alert a user in case of fire. 177 o Reduction of the sound in a room: The goal in this use case is to 178 identify (group) devices that produce some type of sound like 179 audio, buzzer and turn them off. 181 o Event Notification to a disabled person: The goal in this use case 182 is to find the devices that present features that can be used for 183 disabled people to get information about the environment. For 184 example for a deaf person, we are interested in grouping devices 185 that can notify to that person about events, such as the 186 dishwasher stop, through a sighted-sensor like light-bulb change 187 color. 189 o TODO add more use cases. 191 4. Functionality Distance 193 In certain usage scenarios, it is required to identify the IoT 194 devices that have similar properties as a group and control them with 195 a single management command. This can not only lead to efficiency 196 gains at the protocol level, but also improve the overall user 197 experience. As an example, consider the case of a fire emergency in 198 a smart building. In such a scenario, it would be useful to group 199 all Internet-connected IoT devices that have any output capability, 200 to warn the users in their vicinity about the danger of a fire, so 201 that they can substitute for each other if any of them fails. 203 One way to address the above requirement is to calculate the 204 relatedness between devices through what we call functionality 205 distance. The functionality distance in this document is defined as 206 the capability between two devices to perform the same function. We 207 define a set of contextual requirements, e.g., the device should be 208 able to alert in case of fire, and based on that we define weights to 209 each resource. Then, we calculate the distance between the resources 210 as per the contextual requirements. 212 The method that calculates the semantic distance between two objects 213 should have these properties: 215 o The objects that are equal semantically should have distance of 0. 217 o The objects that are quite close semantically should have distance 218 close to 0 220 o The objects that are far semantically should have distance close 221 to 1. 223 o The objects that are not related semantically should have distance 224 of 1. 226 o The distance between object A and B should be the same that 227 between the object B and A. 229 o The method should be able to be adapted to any type of environment 230 and objects. 232 The Functionality Distance metric considers the following components: 234 1. A Set of Contextual Requirements (SCoRq): These requirements have 235 the function to fulfill one or more goals, e.g., I have a goal to 236 group devices that are able to alert about a fire. Namely, these 237 requirements help to identify the relevance of a property to 238 fulfill the goal, e.g. a device with a dimmable feature allows 239 alerts in case of fire by changing the color of the device. In 240 this scenario, a property that indicates if the device has a 241 dimmable feature has more relevance than the property that define 242 the name of the device. SCoRq is defined as a set of properties. 243 The amount of properties of a SCoRq is indicated with tr. SCoRq 244 = {pr_1, pr_2, ..., pr_{tr}}, 246 2. The weight assigned to the resource property (p): Indicates the 247 relevance of the property to fulfill a goal, namely the 248 contextual requirement (SCoRq). The values close to 1 for p 249 indicate that the property is relevant to fulfill the contextual 250 requirement and values close to 0 indicate that the relevance is 251 minimal, e.g., a dimmable property is going to have p = 0.95, 252 since it is relevant to alert in case of fire. On the other 253 hand, the name of the device does not provide useful information 254 since it can be an arbitrary name, then the weight should not be 255 high, we could assign a value of p = 0.10. 257 3. Direct Links (DL) between resources: If two resources have the 258 same property, it implies that there exists a link (Direct Link) 259 between them, e.g., if a Smart Tv object and a light bulb both 260 have a dimmable property, it means that there exists a link 261 between the Smart Tv and the light bulb. The value of the DL is 262 the weight assigned to a property. 264 The relatedness between properties of two devices is defined as 265 FD(a,b)= (n-dl)/(1+SDL(a,b)), where "n" is the total number of 266 properties, "dl" is the total number of direct links between 267 properties and "SDL" indicates the Sum of all Direct Links between 268 properties of two devices. 270 The mechanisms described in this document have been applied to two 271 research papers described in the following subsections to two 272 specific architectures. 274 4.1. LwM2M Resource Semantic Distance (LwRSD) 276 This metric is applied to LWM2M protocol, the metric is called LwM2M 277 Resource Semantic Distance (LwRSD) [LwRSD] 279 4.2. Web of Things Semantic Functionality Distance(WoTSFD) 281 The metric is applied also to Web of Things in a metric that is 282 called Web of Things Semantic Functionality Distance(WoTSFD) [WoTSFD] 284 5. Future Work 286 Future work considers these work items: 288 1. Adding a terminology section 290 2. Being able to express the functionality of a device, object or 291 resource as repeatable metadata or as part of the data model 293 3. Suitability for purpose: Allowing Device A to discover the 294 functionalities of adjacent devices to discover the most suitable 295 device in an operating environment, based on the needs of Device A. 297 6. IANA Considerations 299 TBD 301 7. Security Considerations 303 TBD 305 8. Acknowledgments 307 TBD 309 9. Informative References 311 [LwRSD] "M. I. Robles, N. Beijar and N. C. Narendra, "Measuring 312 Semantic Distance between LWM2M Resources," 2017 IEEE 313 International Conference on Internet of Things (iThings) 314 and IEEE Green Computing and Communications (GreenCom) and 315 IEEE Cyber, Physical and Social Computing (CPSCom) and 316 IEEE Smart Data (SmartData), Exeter, 2017, pp. 625-634". 318 [RFC7547] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and U. 319 Herberg, "Management of Networks with Constrained Devices: 320 Problem Statement and Requirements", RFC 7547, 321 DOI 10.17487/RFC7547, May 2015, 322 . 324 [WoTSFD] "M. I. Robles, B. Silverajan and N. C. Narendra, "Web of 325 Things Semantic Functionality Distance," Accepted for 326 publication to 2019 IEEE 26th International Conference on 327 Telecommunications, 2019". 329 Authors' Addresses 331 Maria Ines Robles 332 Aalto University 333 Espoo 334 Espoo 02760 335 Finland 337 Email: maria.robles@aalto.fi 339 Bilhanan Silverajan 340 Tampere University 341 Kalevantie 4 342 Tampere, FI 33100 343 FI 345 Email: bilhanan.silverajan@tuni.fi