idnits 2.17.1 draft-baba-iot-webapi-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2020) is 1296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force H. Baba 3 Internet-Draft The University of Tokyo 4 Intended status: Informational Y. Ishida 5 Expires: March 13, 2021 Japan Network Enabler Corporation 6 T. Amatsu 7 H. Masuda 8 Tokyo Electric Power Company, Inc. 9 S. Ogura 10 Intel K.K. 11 K. Kunitake 12 BroadBand Tower, Inc. 13 September 9, 2020 15 Report on Problem Solving Experiment for Realization of Web-API-based 16 IoT 17 draft-baba-iot-webapi-07 19 Abstract 21 The University of Tokyo (UOT) is currently performing a demonstration 22 experiment in COMMA House, the experimental smart-house owned by UOT 23 and used as a connected house. The things installed in the house 24 (Things) are operated using applications on smartphones and other 25 devices. The various Things in the smart-house are operated online 26 via a Web API that has been created as a prototype. This report is 27 an overview of the experimental demonstration, which is gradually 28 clarifying that Web API should be effective for solving issues for 29 IoT. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 13, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Structure of Web API . . . . . . . . . . . . . . . . . . . . 3 67 3. Demonstration Tests with Prototype Web API . . . . . . . . . 5 68 4. Advantages of Web API with the structure . . . . . . . . . . 5 69 4.1. Security for IoT appliances/devices and the consideration 70 of privacy for obtained data . . . . . . . . . . . . . . 6 71 4.2. Mapping of the physical world and the virtual world . . . 6 72 4.3. Mismatch between the digenesis of ICT technology and the 73 duration of the use of the Things . . . . . . . . . . . . 6 74 4.4. Speed of standardization of specifications and a large 75 number of specifications . . . . . . . . . . . . . . . . 6 76 4.5. Interconnectivity, responsibility demarcation points, and 77 quality assurance in general . . . . . . . . . . . . . . 6 78 4.6. Evolution of the product design policy . . . . . . . . . 7 79 4.7. Change in the design paradigm from enclosure of users to 80 design that is more open . . . . . . . . . . . . . . . . 7 81 4.8. The problem with increased cost and monetization . . . . 7 82 4.9. Security in society and consideration of privacy . . . . 7 83 5. Survey on worldwide trends . . . . . . . . . . . . . . . . . 7 84 6. Future challenges . . . . . . . . . . . . . . . . . . . . . . 8 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 Outline of Web API and COMMA House 94 COMMA House, the smart-house, was built at the Komaba Research Campus 95 of UOT in 2011, with the intention of conducting research into 96 energy, including HEMS and heat insulation performance. The smart- 97 house is intended for demonstrations, equipped with solar power 98 generation equipment and household lithium ion batteries. The 99 research team arranged the system under discussion with multiple 100 businesses so that the concurrent development of value-added 101 applications can be materialized for the acceleration of the 102 dispersion of smart-houses because energy-related applications alone 103 are not sufficient for their consistent dissemination. 105 It is presupposed that the value-added apps will be developed by 106 third parties that are not directly related to the Things in smart- 107 houses and installed in smartphones/tablets. As part of the joint 108 research with private companies, UOT implemented Web API as a 109 prototype, to enable flexible manipulation of the appliances within 110 the smart-house from the devices. Value-added apps allow you to 111 manipulate the appliances within the smart-house. In addition, such 112 apps were implemented in other demonstrative smart-houses around 113 Japan so that installed appliances could be operated based on the 114 same mechanism. The results confirmed that the Web API was capable 115 of absorbing differences in communications media and protocols for 116 operating Things installed in different smart-houses. 118 Many issues with the realization of IoT have already been reported. 119 Web API may be a solution to some of those issues. 121 2. Structure of Web API 123 Figure 1 shows the structure of a prototype Web API implemented by 124 UOT. The structure has two things of note, which are expected to 125 greatly benefit the realization of IoT. 127 (1) Application to Web API 129 It is often said that a special communications protocol should be 130 prepared for the operation of the Things. However, the cost for 131 learning or additional resources can be avoided if an existing 132 standard protocol is available. This will be a favorable 133 situation for application developers. Accordingly, the structure 134 of prototype Web API permits access from applications with 135 standard protocols, such as HTTP and JSON, which are usually used. 137 (2) Web API to Things 139 The Internet of Things, IoT, is a system that connects everything 140 via the Internet. Needless to say, the Things are limitlessly 141 varied in their prices, with differences of up to five or six 142 digits. One might naturally think that the manufacturing cost 143 would increase if the existing Things that are not networked were 144 connected to the Internet. It would be unreasonable to try to 145 unite the communications protocols for operating the Things. In 146 other words, the acceptable additional cost is naturally different 147 between the Thing worth one dollar and one worth a thousand 148 dollars. Namely, a single communications protocol will not 149 suffice to address the difference. 151 Virtual Driver 152 Machines Softwares 153 Block Block Things alpha 154 +------------+----------+ +----------+ 155 | | +-+ | +------+ | 156 | | |A+-------------------->Firm A| | 157 | | +-+ | +------+ | 158 | | +-+ | +------+ | 159 | +-----+ | |B+-------------------->Firm B| | 160 +-------->alpha+-------> +-+ | +------+ | 161 | | +-----+ | +-+ +-------------+ | +------+ | 162 | | | |C+-->Private Cloud+--->Firm C| | 163 | | | +-+ +-------------+ | +------+ | 164 | | | | | | 165 | | | +-+ +--------+ | +------+ | 166 | | | |Z+-->InfraRed+-------->Firm Z| | 167 +----+ | | | +-+ +--------+ | +------+ | 168 |apps+---+ +------------+----------| +----------+ 169 +----+ | | | +-+ 170 | | | |a+---------+ +----------+ 171 | | | +-+ | | +------+ | 172 | | +-----+ | +-+ +---------->Firm a| | 173 +-------->beta +------> |b+------+ | +------+ | 174 | +-----+ | +-+ | | +------+ | 175 | | +-+ +------------->Frim b| | 176 | | |d+---+ | +------+ | 177 | | +-+ | | +------+ | 178 +------------+----------+ +---------------->Firm d| | 179 | +-----+ | | | +------+ | 180 | |gamma| | | +----------+ 181 | +-----+ | | Things beta 182 +------------+----------+ 184 Figure 1: Structure of Web API at University of Tokyo. 186 A prototype Web API is based on the idea that various communications 187 protocols can be used. It does not matter to users whether the 188 communications protocols are united or not. They are satisfied as 189 long as the Things operate properly. This is similar to the case 190 where users do not find it to be an inconvenience if printer 191 manufacturers have different types of driver software for operating a 192 printer and for printing data from the computer. For this reason, 193 the authors tentatively call the structure of Web API on the Things 194 side the printer driver model. It is assumed that manufacturers of 195 the Things would provide the driver software when the time of IoT 196 arrives. 198 3. Demonstration Tests with Prototype Web API 200 The following Things were used. They have different communications 201 protocols for their operations. For some, signals of infrared ray 202 remote controllers were emulated for operation. 204 Electric windows 206 Electric blinds 208 Lighting (ECHONET Lite/Hue) 210 Air conditioners (ECHONET Lite and infrared ray) 212 Fans 214 Applications developed for the appliances above by third parties are 215 as follows: 217 Control of windows/air conditioners according to the weather 219 Control of the indoor environment according to the sleeping status 220 of users 222 Control of lighting to respond to early earthquake warnings, such 223 as lights turning on 225 These applications were easily applied to other smart-houses by 226 making changes to the driver portion, after they were implemented at 227 COMMA House, regardless of the different types of appliances. 229 4. Advantages of Web API with the structure 231 The previously mentioned basic advantages of Web API can help solve 232 issues in [ID-baba-iot-problems] for the achievement of IoT as 233 follows: 235 4.1. Security for IoT appliances/devices and the consideration of 236 privacy for obtained data 238 IoT services are assumed to involve combined appliances and systems 239 in many different industries. Under such circumstances, it is 240 important to set responsibility demarcation points to maintain 241 security. Being called the printer driver model, Web API is expected 242 to effectively clarify who should update and what should be updated 243 to maintain security. Web API would enable the control of privacy 244 for the obtained data, because it is a mechanism to access all 245 appliances. 247 4.2. Mapping of the physical world and the virtual world 249 Significant labor is required to link applications to the Things. 250 The use of a considerable amount of labor can be avoided by making 251 the Web API intermediary a series of tasks comprised of installation, 252 linking, and calibration, and by performing the tasks like software 253 operations. 255 4.3. Mismatch between the digenesis of ICT technology and the duration 256 of the use of the Things 258 The ICT technology used for mobile phones is subject to alteration 259 every few years, while the entrance doors are usually used for twenty 260 to thirty years. If Web API is the intermediary, it will absorb the 261 mismatch between the ICT and the life of Things. 263 4.4. Speed of standardization of specifications and a large number of 264 specifications 266 There are still a high number of specifications to be introduced into 267 IoT appliances/devices. Additional specifications are under 268 consideration. Such a wide variety of options should not be 269 overlooked. However, the companies that produce and provide services 270 are not necessarily familiar with the specifications, just being 271 users of the specifications. The Web API that is compared to a 272 printer driver model would support the activities of the companies 273 that produce and provide services while they are not bothered by the 274 specifications for operating the Things similar to the users of 275 printers for computers. 277 4.5. Interconnectivity, responsibility demarcation points, and quality 278 assurance in general 280 IoT services are expected to become multifarious through 281 collaboration based on open innovation in the future. In this case, 282 interconnectivity will be secured, and open innovation will be 283 accelerated if Web API is used as an intermediary and a point of 284 responsibility demarcation. 286 4.6. Evolution of the product design policy 288 In the time of IoT, it is anticipated that Things will change from 289 those packed with many functions to those with simplified functions 290 that are allowed to exhibit their versatility through applications. 291 Again, in this case, if interconnectivity is accelerated and 292 responsibility demarcation points are clarified as stated above, then 293 the collaboration will be accelerated between the providers of the 294 Things and the application producers because of the easy-to- 295 understand structure of Web API. 297 4.7. Change in the design paradigm from enclosure of users to design 298 that is more open 300 Same as Section 4.6 above. 302 4.8. The problem with increased cost and monetization 304 In some cases, companies hesitate to enter the IoT appliances market 305 because of the increased cost for conversion into IoT, the 306 effectiveness of which can be hard to see. More providers will be 307 able to develop services/applications based on IoT appliances, 308 appliances will do away with more complicated incorporation/ 309 implementation than necessary and providers will be able to reduce 310 costs while adding more advantages if connection via Web API is 311 materialized. 313 4.9. Security in society and consideration of privacy 315 A socially acceptable system is required in order to transmit and 316 store varied data collected from IoT appliances and appropriately 317 provide consent. However, it is difficult to solve the issues if 318 data is gathered unsystematically. Web API may help to manage such 319 data and solve problems as a system for accessing all appliances. 321 5. Survey on worldwide trends 323 The world is moving towards the widespread use of Web API. In todays 324 world, having a strong API strategy is not just good software 325 practice; it is a powerful business practice and the key to apps that 326 connect the Internet of Things (IoT). Some examples of business 327 strategies based around an API: 329 - Amazon has built a multibillion-dollar revenue business in 330 Amazon Web Services (AWS), leveraging powerful API-based elements 331 such as EC2. 333 - Google Maps would be a much smaller business if the only access 334 were directly through its website. 336 - Twitter has opened up an entire class of businesses and 337 analytical modules by sharing its data API and platform. 339 - Even Salesforce.com, with over 800,000 developers and more than 340 2.5 million applications on the Force.com platform, proudly states 341 that API calls drive more than 60 percent of total traffic to the 342 site. 344 6. Future challenges 346 Those who are interested in Web API with the aforementioned structure 347 are now collaborating in preparation for the creation of Web API with 348 open specifications. For this, UOT is working to provide the 349 opportunity for a discussion that allows private companies to be 350 involved. 352 7. Security Considerations 354 Security issues are described in Section 4.1 and Section 4.9. 356 8. IANA Considerations 358 This document has no actions for IANA. 360 9. Normative References 362 [ID-baba-iot-problems] 363 Baba, H., Ishida, Y., Amatsu, T., Kunitake, K., and K. 364 Maeda, "Problems in and among industries for the prompt 365 realization of IoT and safety considerations", 2020, 366 . 368 Authors' Addresses 369 Hiroyuki Baba 370 The University of Tokyo 371 Institute of Industrial Science 372 4-6-1 Komaba 373 Meguro-ku, Tokyo 153-8505 374 Japan 376 Email: hbaba@iis.u-tokyo.ac.jp 378 Yoshiki Ishida 379 Japan Network Enabler Corporation 380 7F S-GATE Akasaka-Sanno. 381 1-8-1 Akasaka 382 Minato-ku, Tokyo 107-0052 383 Japan 385 Email: ishida@jpne.co.jp 387 Takayuki Amatsu 388 Tokyo Electric Power Company, Inc. 389 1-1-3 Uchisaiwai-cho 390 Chiyoda-ku, Tokyo 100-8560 391 Japan 393 Email: amatsu.t@tepco.co.jp 395 Hiroshi Masuda 396 Tokyo Electric Power Company, Inc. 397 1-1-3 Uchisaiwai-cho 398 Chiyoda-ku, Tokyo 100-8560 399 Japan 401 Email: masuda.hiroshi1p@tepco.co.jp 403 Shintaro Ogura 404 Intel K.K. 405 Kokusai Bldg. 5F 406 3-1-1 Marunouchi 407 Chiyoda-ku, Tokyo 100-0005 408 Japan 410 Email: shintaro.ogura@intel.com 411 Koichi Kunitake 412 BroadBand Tower, Inc. 413 Hibiya Parkfront. 414 2-1-6, Uchisaiwai-cho 415 Chiyoda-ku, Tokyo 100-0011 416 Japan 418 Email: kokunitake@bbtower.co.jp