Skip to main content

Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Hiroyuki BABA , Izaya Miyake , Jun Matsumura , Yoshiki Ishida
Last updated 2018-11-15
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Internet Research Task Force                                     H. Baba
Internet-Draft                                   The University of Tokyo
Intended status: Informational                                 I. Miyake
Expires: May 19, 2019                                    IoT Square Inc.
                                                            J. Matsumura
                                                          BizMobile Inc.
                                                               Y. Ishida
                                       Japan Network Enabler Corporation
                                                       November 15, 2018

   Study Report on a Framework for Cloud Inter-connection toward the
                           Realization of IoT


   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.

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

   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 May 19, 2019.

Baba, et al.              Expires May 19, 2019                  [Page 1]
Internet-Draft            IoT Interconnections             November 2018

Copyright Notice

   Copyright (c) 2018 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
   ( 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Draft Framework for Cloud Inter-connection  . . . . . . . . .   3
   3.  Interconnection Agreement . . . . . . . . . . . . . . . . . .   4
   4.  IoT Device Operation Confirmation and Monitoring  . . . . . .   5
   5.  Interconnection HUB . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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

Baba, et al.              Expires May 19, 2019                  [Page 2]
Internet-Draft            IoT Interconnections             November 2018

   services, enabling one cloud with aforementioned IoT Devices to
   connect with another cloud with IoT Devices, have already been

   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.

2.  Draft Framework for Cloud Inter-connection

   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:

      (1) Inter-connection Agreement

      Commercial cloud inter-connection requires some kind of contracts
      without any doubt.  Such contracting procedures are very common in
      the Internet market.  However, manufacturers of home appliances
      and housing equipment have no experience and they feel worried.

      (2) Operation Confirmation and Operation Monitoring of IoT Devices

      Once being cloud-connected, it is necessary that not products of
      one manufacture but also ones made by others are operated with
      commands sent out of one's cloud server.  At the development stage
      of services and during operation of the services, the operation
      monitoring of one's IoT Devices being connected with other's cloud
      group just with commands of one's.

Baba, et al.              Expires May 19, 2019                  [Page 3]
Internet-Draft            IoT Interconnections             November 2018

      (3) Inter-connection Infrastructure

      Currently a large number of manufacturers proceed with activities
      in getting appliances and equipment that used to operate on a
      standalone basis connected to the Internet.  Those pieces of
      appliances and equipment are independent of each other, namely
      "silos".  Therefore, in case of connecting all those pieces with
      one another, the number of ways to connect needs to be N(N-1)/2.
      To do this, much resources shall be required.  As was seen in
      telephone and the Internet, if HUBs connecting with one another
      are put in place, this issue would be less cumbersome to some

   The framework, comprising of above three points, shall be explained
   in details in the following chapter.

3.  Interconnection Agreement

   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

Baba, et al.              Expires May 19, 2019                  [Page 4]
Internet-Draft            IoT Interconnections             November 2018

   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

4.  IoT Device Operation Confirmation and Monitoring

   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

Baba, et al.              Expires May 19, 2019                  [Page 5]
Internet-Draft            IoT Interconnections             November 2018

   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

   In interviewing with IoT service providers, their capacity to process
   users' claims involves the following three functions.

      1) Monitoring fault incidents;

      2) Fault isolation; and

      3) On-site fault recovery capability

   As of now, generally operational confirmation and monitoring
   functions comprise the following items.

      1) Alive monitoring of IoT Devices through confirmation on ping
      signal communications;

      2) Understanding of fault situations and history by remote reading
      of equipment log; and

      3) Alarm monitoring beyond pre-set threshold levels such as data
      traffic volume

   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.

5.  Interconnection HUB

   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.

Baba, et al.              Expires May 19, 2019                  [Page 6]
Internet-Draft            IoT Interconnections             November 2018

[Pattern 1]                        |     IoT HUB   |
   +------+    +--------------+    |               |
   | IoT  +----+ Private |App|+----+| Cloud |      |
   |Device|    | Cloud        |    || Driver|      |
   +------+    +--------------+    |               |
             <----------------+    |               |
                   Inter-Cloud|    |               |
               Interconnection|    |               |
             <----------------+    |               |
   +------+    +--------------+    |               |
   | IoT  +----+ Private |App|+----+| Cloud |      |
   |Device|    | Cloud        |    || Driver|      |
   +------+    +--------------+    |               |
                       Application-Cloud Interconnection
                      <--------------------------------->    [Pattern 4]
                                   |               |   +---------------+
              <---------------+    |        | Web |+---+ Application   |
                  Device-Cloud|    |        | API ||   | (B2C/Service) |
               Interconnection|    |               |   +---------------+
              <---------------+    |               |
[Pattern 2]                        |               |
   +------+                        |               |
   | IoT  +------------------------+| Thing |      |
   |Device|                        || Driver|      |
   +------+                        |               |
                                   |               |
[Pattern 3]                        |               |
   +------+     +-------------+    |               |
   | IoT  |     |    Gateway  |    |               |
   |Device+-----+| Thing |    +----+               |
   |      |     || Driver|    |    |               |
   +------+     +-------------+    |               |
                                   | Database      |
                                   |   Directory   |
                                   |   Description |
                                   |    Sekisyo    |
                                   |    Service[1] |

                      Figure 1: Structure of IoT HUB.

   Of course, in the IoT world, similar arrangements to connect among
   cloud groups are possible.  There is one difference from the era of

Baba, et al.              Expires May 19, 2019                  [Page 7]
Internet-Draft            IoT Interconnections             November 2018

   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 continues
   with its research, recognizing requirements for infrastructures for
   interconnection of those items.

      [Pattern 1] Service providers with their private cloud connecting
      with IoT devices,

      [Pattern 2] preparing device drivers to IoT devices,

      [Pattern 3] supplying gateways which connect IoT devices, and

      [Pattern 4] application and service providers with with others IoT

6.  Security Considerations

   Regarding security, pattern 2 of service providers specified in
   Chapter 5 may contain some vulnerability and thus precaution is

7.  Privacy Considerations

   Regarding privacy, Chapter 2 touches upon concerns on privacy among
   inter-connected service providers in case of fault isolation after
   IoT Device malfunctioning.

Baba, et al.              Expires May 19, 2019                  [Page 8]
Internet-Draft            IoT Interconnections             November 2018

8.  Acknowledgement

   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.

9.  Normative References

   [1]        Baba, H., Ishida, Y., Amatsu, T., Kunitake, K., and K.
              Maeda, "Problems in and among industries for the prompt
              realization of IoT and safety considerations", 2018,

   [2]        Baba, H., Ishida, Y., Amatsu, T., Masuda, H., Ogura, S.,
              and K. Kunitake, "Report on Problem Solving Experiment for
              Realization of Web-API-based IoT", 2018, <draft-baba-iot-

Authors' Addresses

   Hiroyuki Baba
   The University of Tokyo
   Institute of Industrial Science
   4-6-1 Komaba
   Meguro-ku, Tokyo  153-8505


   Izaya Miyake
   IoT Square Inc.
   Hibiya Parkfront.
   2-1-6, Uchisaiwai-cho
   Chiyoda-ku, Tokyo  100-0011


Baba, et al.              Expires May 19, 2019                  [Page 9]
Internet-Draft            IoT Interconnections             November 2018

   Jun Matsumura
   BizMobile Inc.
   Kanda Business Cube 3F
   5-1, Kandatomiyama-cho
   Chiyoda-ku, Tokyo  101-0043


   Yoshiki Ishida
   Japan Network Enabler Corporation
   7F S-GATE Akasaka-Sanno.
   1-8-1 Akasaka
   Minato-ku, Tokyo  107-0052


Baba, et al.              Expires May 19, 2019                 [Page 10]