Iotivity Demo Networking Laboratory 2/37 Iotivity Target

Sungkyunkwan University

IoTivity

Presenter: Dzung Tien Nguyen Networking Laboratory, 83345 [email protected]

 Incompatibility of platforms: Manufacturers are providing a large number of IoT devices. Those devices could be based on Linux, Android, Adruino, iOS, etc. To let them work together requires a hub/controller to interpret (or ‘translate’) the data, commands.

 Difficulty in cooperation between industries (smart home, automotive, industrial automation, healthcare etc.)

IoTivity demo Networking Laboratory 2/37 IoTivity target

 To provide a common open source framework for Discovery and Connectivity. In addition to that, Device management and Data management are mentioned as services

 To ensure interoperability among products and services, regardless of maker and across multiple industries, e.g. Consumer, Enterprise, Industrial, etc. The interaction might be made between WIFI, Bluetooth, Zigbee, Z-wave devices and so forth

 To provide the common code bases/APIs to accelerate innovation, besides the open standard and specifications

 Supporting Linux (compiled), Android (Compiled), Tizen, Adruino, Yocto, iOS, Windows (unsuccessful)

IoTivity demo Networking Laboratory 3/37 The framework

IoTivity demo Networking Laboratory 4/37 The stack architecture

IoTivity demo Networking Laboratory 5/37 Protocol: CoAP

 Is Constrained Application Protocol for constrained resource environment  Is a simple and compact binary mapping of REST  Provides asynchronous notifications, publish-subscribe, resource discovery  Work in CLIENT/SERVER context  Each entity can be both CLIENT/SERVER at the same time  IoTivity is using CoAP

http://iot-datamodels.blogspot.kr/ IoTivity demo Networking Laboratory 6/37 More about CoAP

 Most IoT systems use UDP. However, since UDP is neither stable nor reliable, it needs to combine with another application protocol to improve the stability

 CoAP stands for Constrained Application Protocol, is a client-server application layer protocol designed for resource-constrained devices (i.e. low power, small, need to control remotely)

 CoAP is like HTTP (document transfer protocol), but with multicast, low overhead and simplicity.

 CoAP can easily be translated to HTTP. CoAP is built on top of UDP (not TCP) and supports the scalable web services

IoTivity demo Networking Laboratory 7/37 Resource Discovery

IoTivity demo Networking Laboratory 8/37 CoAP: observation

 CoAP extends the HTTP request model with the ability to observe a resource. ► When the observe flag is set on a CoAP GET request, the server may continue to reply after the initial document has been transferred. ► This allows servers to stream state changes to clients as they occur. Either end may cancel the observation.

 Example of a resource: a light controller, a garage door opener ► Resources might be organized in a hierarchical manner (tree form)  E.g. /fridge/  Light1  Light2  Fan  Sensor1  Sensor2

IoTivity demo Networking Laboratory 9/37 More on IoTivity

 Current release: 0.9.2, open source  Getting started: https://www.iotivity.org/documentation/linux/getting- started  Number of joined companies: 50+, including Intel, Samsung, …  Still in development phase, not a production-ready product  Discussion forum: ► https://jira.iotivity.org/browse/IOT-124 ► View is available ► Registering seems not open

IoTivity demo Networking Laboratory 10/37 The virtual machine

 Ubuntu 14.04  Username/passwd: mc2015/123  Gcc4.9  Eclipse with Android SDK v.19 / 20 / 21 (required); Android NDK, Gradle  Dependencies: ► python2.7, scons ► Jre ► Boost, …

IoTivity demo Networking Laboratory 11/37 Build the framework

 Source code inside the VM is prebuilt with the following options: ► scons TARGET_OS=linux TARGET_ARCH=x86 TARGET_TRANSPORT=IP ► scons TARGET_OS=android TARGET_ARCH=armeabi TARGET_TRANSPORT=IP

 To add more source file (e.g. to folder resource/examples) and recompile: ► Inside the folder, modify Sconscript ► From root directory execute:  scons resource/examples

IoTivity demo Networking Laboratory 12/37 Before getting started

 Generating the doxygen ► doxygen –g iotdoc ► vim iotdoc  RECURSIVE=YES  CREATE_SUBDIRS=YES  GENERATE_LATEX=NO ► doxygen iotdoc

IoTivity demo Networking Laboratory 13/37 Client/Server basis

 Server ► Init the configuration ► Register resource  Entity handlers for handling request (GET/PUT/POST/OBSERVE)

 Client ► Client configuration ► Functions for PUT/GET/POST/OBSERVE and its callbacks

IoTivity demo Networking Laboratory 14/37 InitOICStack config

 Initialize the configuration mode of the ‘thing’ ► ServiceType: InProc, OutOfProc ► ModeType: Server/Client/Both ► IPAddress: 0.0.0.0 means broadcast ► ClientConnectivityType: port number ► QualityOfService: LowQoS, MidQos, HighQos, NaQos (in OCApi.h)

IoTivity demo Networking Laboratory 15/37 [SERVER] Define a resource

 Member variables

 Constructor

IoTivity demo Networking Laboratory 16/37 [SERVER] Register the resource

 C++ API ► OCStackResult OC::OCPlatform::registerResource(…); ► OCEntityHandlerResult entityHandler(std::shared_ptr request)

IoTivity demo Networking Laboratory 17/37  Application calls the library function

 On finishing the task, the library function trigger the associated callback at the same tier with the call

IoTivity demo Networking Laboratory 18/37 Find Resource

 On the findResource(), the get() request is sent out (multicast) to all the vicinity IoT devices

 Each device processes the query and responds if it satisfies the request filter

 Parameters: "oic/res?rt=core.light" including URI path (“/oc/core”) and URI query (“rt=core.light”) ► “/oic/res” is the OIC Virtual resources supported by every OIC device (octypes.h)

IoTivity demo Networking Laboratory 19/37 Scheme 1: Simple discovery

myClient myServer

OCResource foundResource()

get() GET

OCRepresentation onGetCallback()

IoTivity demo Networking Laboratory 20/37 [CLIENT] Find Resource

 FindResource syntax

std::ostringstream requestURI; requestURI << OC_RSRVD_WELL_KNOWN_URI << "?rt=core.light"; OCStackResult result = OCPlatform::findResource("", requestURI, CT_DEFAULT, FindCallback);

 FindResource ‘s Callback

void foundDevice(std::shared_ptr resource){ if(resource){ std::cout << "Got one" << resource->host() << resource->uri() << std::endl; } }

//host() return string coap://: //source: OCResource.cpp

IoTivity demo Networking Laboratory 21/37 [Client] Get

 Trigger GET request

OCStackResult result = resource->get(getMap, g); if(OC_STACK_OK != result) { std::cout << "Get resource error!" << std::endl; }

 Process onGetCallback

void onGetCallback(const HeaderOptions& hO, const OCRepresentation& rep, const int eCode){ if (eCode == OC_STACK_OK){ std::cout << "GET request was successful" << std::endl; std::cout << "\tPower value: " << rep.getValueToString("power") << std::endl; }else{ std::cout << "Error in GET callback" << std::endl; } }

IoTivity demo Networking Laboratory 22/37 [SERVER] OnGetRequest

 On receiving GET request, the resource server get() its representation and sendResponse back to the requester using OCPlatform API

if (requestType == "GET") { std::cout << "\tReceived GET request\n"; pResponse->setResourceRepresentation(lightResource::get()); if(OC_STACK_OK == OC::OCPlatform::sendResponse(pResponse)) { ehResult = OC_EH_OK; } }

IoTivity demo Networking Laboratory 23/37 Scheme 2: PUT request

myput myServer

put()

entityHandler (requestType == “PUT”) OCResource onPUTCallback()

get() GET

OCRepresentation onGetCallback()

IoTivity demo Networking Laboratory 24/37 [CLIENT] PUT

 PUT is to send the next state to the resource  Send the new desired state of type OCRepresentation to the resource

//do the PUT OCRepresentation repToPut; repToPut.setUri("/a/light"); for (auto i = 0; i < 10; i++){ if (i%2 == 0) repToPut.setValue("power", std::string("off")); else repToPut.setValue("power", std::string("on")); put(myClient::lightResources, repToPut); sleep(3); }

IoTivity demo Networking Laboratory 25/37 Scheme 3: OBSERVE request

myput myObserverServer myObserverClient

findResource() put() and Observe()

- entityHandler(requestType == “PUT”) - notifyObserver()

Get server’s state changes

IoTivity demo Networking Laboratory 26/37 Usecase: send other

 In IoTivity, devices are in CLIENT/SERVER modes, and the connections are of type Client-Server ► The available messages are GET/PUT/POST/OBSERVE  Look at the signature of those functions:

OCStackResult OCResource::get(const QueryParamsMap &, GetCallback attributeHandler)

OCStackResult OCResource::put(const OCRepresentation & representation, const QueryParamsMap & queryParametersMap, PutCallback attributeHandler)

OCStackResult OCResource::post(const OCRepresentation & representation, const QueryParamsMap & queryParametersMap, PostCallback attributeHandler)

OCStackResult OCResource::observe(ObserveType observeType, const QueryParamsMap & queryParametersMap, ObserveCallback observeHandler)

 In OCApi.h: typedef map:: QueryParamsMap;

IoTivity demo Networking Laboratory 27/37 Back to OnGetCallback

 With OCRepresentation which will be sent back to the client, we can carry any data with user-defined field name ► In the example, “power” is the field name

void onGetCallback(const HeaderOptions& hO, const OCRepresentation& rep, const int eCode){ if (eCode == OC_STACK_OK){

std::cout << "\tPower value: " << rep.getValueToString("power") << std::endl; } else{ std::cout << "Error in GET callback" << std::endl; } }

IoTivity demo Networking Laboratory 28/37 Scheme 4: user-defined GET

myQuery myQuery Client Server

get()

IoTivity demo Networking Laboratory 29/37 To be modified

 Add extra info to GET message

QueryParamsMap getMap; getMap["energyLevel"] = "100"; getMap["IP"] = myClient::myIP4Address;

 Add energy level to resource’s representation

l_rep.setEnergy("energyLevel", l_energy);

IoTivity demo Networking Laboratory 30/37 Extract info

 From server side: calling API to get the queryParams of type std::map

std::string requestType = request->getRequestType(); std::map queryParams = request->getQueryParameters(); auto requestRepresentation = request->getResourceRepresentation();

for(auto it = queryParams.cbegin(); it != queryParams.cend(); it++) { std::cout << it->first << " : " << it->second << std::endl; // it->first = Text “energyLevel” // it->second = the actual value }

 Client: ► Ocrepresentation.getValueToString(“energyLevel”)

IoTivity demo Networking Laboratory 31/37 Approach to the project

 Creation of an array for storing resources in the vicinity  Requesting residual energy from neighbors, selecting the highest (e.g. using GET)  Utilizing the PUT message to send data to an end point ► Defining new field in the OCRepresentation (e.g. “mode” = “aggregation”/”put”) ► On the server side:

if (requestType == "PUT") { recvmsg = request->getResourceRepresentation(); if (recvmsg.getValueToString("mode") == "aggregation") { //do something here } }

 Making your aggregation algorithms (e.g. taking average of all the “Temperature” received) and then sending to the sink

IoTivity demo Networking Laboratory 32/37 Sungkyunkwan University

Things-manager

Extra example

 Follow this link: https://wiki.iotivity.org/getting_started_iotivity_services_for_android_0_9 _1  Path for android SDK: ► Iotivity/extlibs/android/sdk/android-sdk/  Path for android NDK: ► Iotivity/extlibs/android/ndk/android-ndk/  Link for installing android plugin for eclipse: ► https://dl-ssl.google.com/android/eclipse/

IoTivity demo Networking Laboratory 34/37 Topology

 Context: ► All the devices connect to the Access point ► Light resources and registered

► Android clients interacts with the resources:  PUT, OBSERVE  Scheduled PUT

IoTivity demo Networking Laboratory 35/37 IoTivity demo Networking Laboratory 36/37 IoTivity demo Networking Laboratory 37/37