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