User Tools

Site Tools


proposal_for_iotivity_cloud

IoTivity Cloud

This is a contribution proposal about cloud/server interface of OIC devices. Current implementation of IoTivity is hard to expose their resources to other internet services like Facebook or Google. So, we think this feature will enriches the OIC device functionality and add more accessibility.

Architecture

Resource Server/Client: IoTivity enabled devices that initiate session using CoAP over TCP/TLS to Cloud Interface server which scattered over the world.

Region Cloud/Cloud Interface: Region based server that accepts connection from clients, receive notification data and send REST message through connected pipelines. They are clustered by global cloud.

Global Cloud: This main cloud clusters region clouds using provided API like publish/discover resources. The account server supports interfaces that other OAuth2.0 enabled authentication providers can extend their user’s identity to OIC cloud. OIC resource server/client can guide user that they can register their devices using one of authentication providers which registered to account server.

3rd Party Cloud (TBD): Service provider that control to, receive data from region cloud and global cloud.

Scenario

1. Suppose that customer try to install new product which is resource server. The resource server requests user to put his credential. If the device has suitable interfaces then he can put his ID/PW to retrieve access code to register. If the device has no interfaces, he can push valid token using alternative methods like NFC or WiFi Direct. This proposal doesn’t specify how to get access code from authentication providers.

2. Once the resource server has published, resource client can see and control the resource server even they are not connected to the same cloud interface server. They can communication over the region.

3. (TBD) 3rd Party service provider also sees and controls the resource server if user binds his credential to those services. This feature also required to have access control that user can set limits of accessibility.

Feature

Contribution approach

Cloud side

  • Server base stack
    • Use Netty framework ( http://netty.io )
    • CoAP over TCP encoder/decoder
    • Part of Cloud Interface and Resource Directory server
  • Cloud Interface server
    • Server side OAuth2.0 handshake protocol implementation
    • Keep-Alive resource server that client can check TCP session.
    • Relay handler that clients can communicate when they are connected different CI server.
  • Resource Directory server
    • Provides resource registration, discovery, update and delete to CI server.
    • Stores resource information to physical database.
  • Account server
    • Manage user and access tokens.
    • (TBD) Scattered or centralized

Device side

  • Sample client application
    • Client side OAuth2.0 handshake protocol implementation
    • Keep-Alive resource client
    • Send resource registration/discovery request

References

  • Keep-Alive

To ensure that the TCP connection between device and cloud is still alive, device or cloud should send application level Keep-Alive messages. (Please refer the Core Specification Project B documents ( 12.6. CoAP serialization over TCP ))

  • The reason to support application layer Keep-Alive are as follows :
    • Kernel level TCP KeepAlive only guarantees that a connection is alive at the network layer, but not at the application layer.
    • Interval of TCP KeepAlive is configurable only using kernel parameters and is OS dependent. ( eg. 2 hours by default in Linux )
  • Detailed Features
    • Use Fixed Ping resource
      • URI: /oic/ping, Type ID: oic.wk.ping, Interfaces: oic.if.rw
    • Fixed Interval Time
      • Start from 2 minutes and increases in multiples of 2 up to 64 minutes.
    • Disconnect logic
      • OIC Client does not receive the response with 1 minutes.
      • OIC Server does not receive a PUT request within interval time.
  • Base Layer Changes
    • Support a resource of type oic.wk.ping
    • Maintain the OIC Device Information connected by CoAP over TCP to send KeepAlive message.
  • Netty Framework
  • Netty is an asynchronous event-driven application/framework making it easy for users to write network socket programs. Originally It was developed by JBoss, and now being developed and maintained by the Netty Project Community. It supports HTTP, websocket, SSL/TLS and so on.
  • Official home page : http://netty.io/
proposal_for_iotivity_cloud.txt · Last modified: 2017/01/03 01:47 by Phil Coval