| Internet Research Task Force | H. Baba |
| Internet-Draft | The University of Tokyo |
| Intended status: Informational | I. Miyake |
| Expires: November 18, 2019 | IoT Square Inc. |
| J. Matsumura | |
| BizMobile Inc. | |
| Y. Ishida | |
| Japan Network Enabler Corporation | |
| May 17, 2019 |
Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
draft-baba-iot-interconnection-02
This paper describes issues for solutions through cloud inter-connection to structural problems, which are called as "silo effects" found in cloud-connected electric home appliances, housing equipment and sensors in the face of increasingly accelerated connection of them. Specifically, this paper explains an inter-connection agreement considered to be required for enhancement of cloud inter-connection, what performance guarantee as well as IoT supervising and management should be, necessity of inter-connection HUB which is able to provide inter-connection amongst the preponderance of private cloud groups.
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 November 18, 2019.
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 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.
To date, based on the results of interviews with "Things" companies, the authors of this paper, the Autors, issued a Problem Statement on IoT [1], and reported on an experiment of WebAPI [2]. With further interviewing and experiments, various requirements specification on a base for securing cloud inter-connection in the anticipated IoT society become clearer.
Currently, the use of various connected devices, hereinafter "IoT Devices" is largely expected to become a using scene of IoT, and such IoT Device manufacturers operates their private cloud groups, the "Cloud", where IoT Devices are connected one after another. It depends on the manufactures whether API of one cloud is open to a third party or whether the cloud remains closed just for itself just like a "silo". However, it is expected that API be open by manufacturers in charge to third parties in the near future and a large variety of values shall be created through cloud inter-connection of IoT Devices that are connected to the other cloud groups with a similar structure. Several cloud inter-connection services, enabling one cloud with aforementioned IoT Devices to connect with another cloud with IoT Devices, have already been provided.
Thus, by combining cloud-connected IoT Devices, or "connected Things", just like toy blocks being built freely through cloud inter-connection, the era for creating a variety of benefits for users seems to approach us.
As far as users select and handle connected Things on their own response, there are not any significant issues. However, those whom you cannot expect IT literacy like elder people should be able to get access to benefits from IoT. If we stand on such an assumption, there seem to be many open issues.
The Authors conducted interviews with 9 market players including IoT service providers and those who were preparing to provide IoT services and undertook research and summarized issues that those players felt with regard to cloud inter-connection. In parallel with other researching experience, we discussed on what framework would be required for doing IoT service provider businesses at smart houses. This paper outlines the findings from such discussions.
Not assuming the style where users enjoy combination of the use of IoT Devices like DIY but assuming the one where so called service providers offer IoT services to users on a "do-it-for-me (DIFM)" manner, issues different from DIY style become more patent in the light of responsibility for customers and business continuity. Those issues are well diversified but may be summarized into three core categories as follows:
The framework, comprising of above three points, shall be explained in details in the following chapter.
In the era of IoT, it is desirable to facilitate contracting between businesses smoothly by preparing a boilerplate format for an interconnection agreement in advance. As described in the previous chapter, because of the lack of experience in home appliances and housing equipment manufacturers, needless to say, any guidelines or formats would give great comfort to them. The benefits from an interconnection agreement are to define responsibility of each contracting party and clarify consent of the parties.
For example, manufacturers of gas cookers have been working on operational linkage between a gas cooker and air conditioner in order to harness the increase of room temperature. Possibly a universal remote controller may be linked with a gas cooker and then the user can of course operate an air conditioner with the gas cooker controller. However, unless there is consent from the manufacturer of the air conditioner on this link operation, the gas cooker manufacturer seems to hesitate to pursue this due to his feeling that this is not a fair business behavior.
Following precedents in the Internet, the contents of the interconnection agreement include demarcation of responsibility, procedures in operation and maintenance, cost allocation, technical specifications, and general prohibitions. In addition to such contents, however, the interconnection agreement becomes significantly valuable by proving that participating parties formally agree upon commercial terms of cloud inter-connection.
Of course, the agreement stipulates terms on malfunctioning of IoT Devices. For example, there is a structure where an energy management application located in a cloud group of lighting equipment of Manufacturer A gives a command to a cloud group of air conditioning equipment of Manufacturer B. By chance, one air conditioner starts malfunctioning and the user may call a customer service of Manufacturer A that provides DIFM energy management services to the user. In this case, problems are 1) how the fault can be isolated and 2) how this user's report can be transferred to Manufacturer B if the fault is identified to come from the other service provider, namely Manufacturer B.
In case of one manufacture Authors interviewed with, regarding 1) above, the provider asks the user confirm the lighting operation by its universal remote controller. If operates, the manufacturer process the user's report for the moment as a problem of Manufacturer A. If not operates, the user report could be handled as a problem of Manufacturer B. Manufacture A does not escalate the user's report to Manufacture B in case of 2) above. At a glance, this behavior of Manufacture A may not be sincere, but this is related with the treatment of personal information. Nowadays, manufacturers collect personal information of the user only in case they really need such information. Following this information policy, if a lighting remote controller does not operate the air conditioner, problem of Manufacture B is suspected. However, Manufacturer A does not ask the user for his/her personal information. Instead, they ask the user to call Manufacturer B once again.
Because there are very extraordinary restrictions on transfer of personal information among service providers in many countries, aforementioned treatment of users has to prevail. Contrarily this treatment is totally opposite to a direction of the one-stop services that users generally look for.
Regarding cloud inter-connection, several opinions on issues in business continuity were heard. Namely, in case of formulating DIFM services containing services provided by others, the DIFM service providers are concerned with adverse impacts of the suspension or cancellation of other providers' services on his/her DIFM services. The interconnection agreement does not make other providers promise to continue the provision of the services to the DIFM providers. However, the agreement possibly defines responsibility of advance notification and a certain lead time for countermeasure formulation. Therefore, the interconnection agreement is meaningful in this regard.
As was mentioned before, it is prerequisite to secure function of operation confirmation of related IoT Devices in DIFM business in its services development and in processing claims of users during service provision. Even in the experimental service development stage, it is often necessary to identify where a fault occurs and how to isolate the fault in case that IoT Device does not perform as it is expected. This articulates an issue related to inter-operability which is the purpose of inter-connection. Especially, fault identification and capacity to recover the identified faults are very significant issues.
In interviewing with IoT service providers, their capacity to process users' claims involves the following three functions.
As of now, generally operational confirmation and monitoring functions comprise the following items.
However, if the number of IoT Devices increases rapidly from now on, a set of aforementioned simple monitoring functions may not be efficient in terms of recovery capacity and cost competitiveness. It is necessary to re-examine the scalability of current operation and monitoring systems carefully and introduce required new technologies for effective operational monitoring of widely proliferated IoT Devices from now on.
When a large number of manufacturers start the operation of independent cloud groups, their mutual interconnection becomes more and more complex as is mentioned before. Telephone and the Internet are supported with so called interconnection gateway switch and IX structures, achieving inter-connection among service providers.
Of course, in the IoT world, similar arrangements to connect among cloud groups are possible. There is one difference from the era of telephone and the Internet. This is no existence of inter-connection communication protocols such as SS#7 and BGP4 here.
During the interviews with the providers, no one mentioned the necessity of standardization of inter-cloud interconnection communication protocols. Contrarily, many providers told that they would utilize whatever they can use in an extremely businesslike manner. Actually already existing inter-cloud interconnection services do not specially focus on this issue. So it is considered that interconnection HUBs would necessarily be structured in way HUBs accommodate various different kinds of protocols. In order to connect different protocols that respective cloud group utilize with one another, the HUB side needs to be equipped with a driver module matching each of the cloud groups to be connected. Authors call this as a "printer driver model."
And according to a research of Authors, interconnection services already put in place tend to take similar patterns such as inter-cloud interconnection and application-cloud connection. Therefore it is necessary to proceed with interconnections with different patterns in order to make it more universal.
Service providers as a bussiness that Authors are considering are at least the following four patterns. The University of Tokyo has proceeded a research, recognizing requirements for infrastructures for interconnection of those items.
As a result, we verified the effectivness and flexibility of a new architecture. The architecture has a common interface named Interface-R within IoT-HUB, and all devices are connected to the HUB by defining the drivers for R-interface.
+-------------------+
[Pattern 1] | IoT HUB |
+------+ +--------------+ | |
| IoT +----+ Private |App|+----+| Cloud | |
|Device| | Cloud | || Driver| |
+------+ +--------------+ | + |
<----------------+ | | |
Inter-Cloud| | Interface-R |
Interconnection| | |
<----------------+ | |
+------+ +--------------+ | |
| IoT +----+ Private |App|+----+| Cloud | |
|Device| | Cloud | || Driver| |
+------+ +--------------+ | + |
| | |
| Interface-R |
| |
Application-Cloud Interconnection
<------------------------------------->[Pattern 4]
| | +-------------+
<---------------+ | | Web |+-+Application |
Device-Cloud| | | API || |(B2C/Service)|
Interconnection| | + | +-------------+
<---------------+ | | |
| Interface-R |
[Pattern 2] | |
+------+ | |
| IoT +------------------------+| Thing | |
|Device| || Driver| |
+------+ | + |
| | |
| Interface-R |
[Pattern 3] | |
+------+ +-------------+ | |
| IoT | | Gateway | | |
|Device+-----+| Thing | +----+ |
| | || Driver| | | |
+------+ +-------------+ | |
| Database |
| Directory |
| Description |
+-------++----------+
||
+-------++------+
| Sekisyo |
| Service[1] |
+---------------+
Figure 1: Structure of IoT HUB.
This method is designed to interconnect IoT Devices, the connectable system is not limited to IoT Device. It can be connected with almost no limitations, such as a block chain engine or a system for data storage. As a result, it can be expected to contribute to the development of new economy such as utilization of data. For example, by setting the unit price for each operation of the IoT Device, costs for deployment of IoT devices are reocovable. Or by using this HUB as a branch point on the data transmission path, new business player such as a data storage provider can be involved in the connection between the IoT Device business companies.
Regarding security, pattern 2 of service providers specified in Chapter 5 may contain some vulnerability and thus precaution is required.
Regarding privacy, Chapter 2 touches upon concerns on privacy among inter-connected service providers in case of fault isolation after IoT Device malfunctioning.
This paper contains findings of the study funded by the Ministry of Internal Affairs and Communications of Japan as well as research activities of IoT Committee of Internet Association Japan. We hereby touch upon such facts and show our gratitude to those who relate to the study and committee activities.