 Hi everyone, so I'm going to explain with my colleague UK and we are working in the same team of Liotative Projects. What is it that you contact us if you have a question? So I will just explain a very typical use case and the end-to-end solution about bi-curve and infrastructure. So I will explain what is the utility and how to prototype the infrastructure. And then we will explain more about the cities. So for the lighting room I will maybe show it later because it's a little messy and there are problems. So what I want is to solve the problem I have when I crash on my bike. I think that the city lights are very important. So I want to find a way to find out the defective city lights. We provide an healthy solution to do this and eventually get the right person to make the decision to get the city lights fixed. That's the problem I'm going to make from this. So I made a short video about the problem. We have a car under the city light and there is a sensor on it. We try to measure the illuminance and it's off and we have to send it right. So here is my rig and I'm showing that I have a different device that you can imagine in a car. So we have the GPS unit which is here Raspberry Pi Zero. And there is an IoT TV server on it which is sharing the position to whoever wants to listen to it. So I have a client on the phone which is displaying the position on the map. The phone is just to explain. So on the other side I have the box very near the illuminance sensor. Brightness sensor is running on Raspberry Pi 2 and on the AGL automotive spectrum. And I have also a relay to control the front light of the car. So when you put this together, you have what you need for this problem. So what I want to show is that this green is the city light. And if I hide my sensor with this piece of black, then the front lights are turning on. And in the end there is a notification to the cloud telling that there is something happening now. So the first row with the little spots we will see is illuminance in Le Mans. And then the position latitude and longitude. So we have three numbers. And I'm just telling you that I'm not collecting all the data every time I can. Just here the service is probably a problem. So then once the data is in this cloud, you can imagine a service to show this on the map. So if I show it again, yes. So this is an A2 sensor and I will explain later how to deal with this. So there is two actions. One is to turn around the car front light and send a notification to the city or wherever it can. And also all the resources can be controlled by a different device. So here I have a smartwatch for a new type of system. And if I want to turn on my light or whatever, I'm not telling this is something. This is a reward. It's a thing that technically you can do. So I will explain now in detail what, if you want to do it again, how can you do it? So first let me introduce what is an open connectivity foundation. So this is a group that aims to provide all the software, to provide connectivity between devices. And the first goal of this group is to provide a real specification. We're not reinventing the wheel. There is already an existing solution and we're just trying to put it together to get something useful and finish it and that was many use cases. We are relying on the co-op protocol. And we are also, the test civilization is done using the CBO format. And the other goal of this group is to provide and sponsor the implementation of the specification. So this is, there is a very close relationship between open connectivity foundation and high utility. Because in the standard, if it's in the standard, this means that they are doing it before. And in other ways, this is specification, open standard, open source implementation and the IPHE and tool and things. So if you want to create a product, I will recommend you to join the group and to get a certification on top of this. If you are making a product that's supposed to do something, probably you can interact with other people who are supposed to go through this. And I will explain it. So let's get on the protocol side. So it's a restful design. You have some initiation server side and client side. And then there is a discovery mechanism. This means that there is a server which is providing services and any client can discover the services and do some action about changing the state of the resource so it gets the value of it. So this is a back and forth integration. And some mechanism which is very interesting is the observation nature. This means that what if a resource is changing and your high-end resource playground will be aware of the logic. So you don't have to implement your own voting logic. It's a very good system. So particularly you can run on a modern system with a CPU. Also we are supporting low constraint devices. And there is another subproject for very low constraint devices. So you can have very wide range from microcontroller to computer or mobile phone. Today it's integrated in many systems. We have the Python, the Gemini, MGR and many other systems. And we are going to make some progress to try to make it easier for everyone. So the core part is a C library using a protocol. And the footprint is about 100K so you can fit into a microcontroller. When I say on top of it we have a C++ API which is providing more objective entities facilities. And as like this we have all those services. We speak about how can we provide more services than just a basic solution. So let's get back to writing. So I'm not a JavaScript developer but I wanted to explain it in JavaScript because it's quite a compact code and it gives you the idea of the logic. So if you are seeing half code developer you can do the same thing. So just using it in JavaScript. And because we have some bindings to Node.js. So this is a great contribution for them. Node.js is quite interesting because there is a huge community and you have a lot of pre-modules ready to be used. So you just need to install it using the package manager and it will assist them. It's based on the C version of IoT. So if I get back to my program. So first it's about the sensor. So there is no black magic here. So I'm just using an I2C sensor. And there is somebody made a package to support it. So you just need to initialize it on Raspberry Pi. It is an I2C bus and it's a bus. There is just one torsion. It's just right which is just about the value. Now we are talking about blindness. And we want to make something run since maybe instead of we are making the wheel of CF it's proposing a lot of model to define things. So maybe you can have a look at what's inside this repository and if the model you are talking about is not a really no matter. In the case of the Illuminance wheel somebody did this and we have a normalized Illuminance object called I2C resource sensor in Illuminance which is describing that the Illuminance is just on the wheel. So we are just reusing these names. If you want to create yours you can propose some Illuminance. So let's back to the connectivity. We have this Illuminance and we want to share it to whoever wants to be aware about this. We are creating an IoTT server and using Node.js we need to import the module. IoTT know the low level. We initialize it as a server and we had some configuration flag to say that this device is observable by the users. So each time it is changing we can just send a notification and everyone will be aware. So this is just a flag and a function. So if we are in JavaScript there is an update event on the sensor which is modifying the resource. So the listeners is clear inside. So first we have to discover the resource and once it's formed then we can handle it and try to work with it. So on my code once I found the resource if the resource is identified by this pass Illuminance resource we are like this is just a sample I can just start watching for it and on each update event I will process it. So that's not simple. So first you have to find it and then you have to listen to the update process. So the last part of this presentation is sending back the data to the cloud. So I will give a demonstration on the cloud which is a cloud designed for IoT solution by Samsung and to use it there is a different approach but I use Node.js 1 which is the base of this project and I have to install an HTTP REST client and then I can just send the message. So first I have to declare my device on this cloud backend and once I get some identification codes I can send the data back to it. So in my case the data is just Illuminance value. I kept reusing the OCF model name because you have to declare it different so you can do anything. So here is a preview about what we are doing here. So in the yellow box we have this Illuminance object which is identified by a URI. One of its properties is a value under the Illuminance property name for the position it's the same and for the anti-cloud we are sending an object which is a composition of the Illuminance and the initial position. So that's just here again. The basic rule is on the right. This means that if Illuminance is below some threshold this means it's too dark then we are just sending the message to the cloud. And we are doing this on each change of the Illuminations and so on. So I have a link which is doing this which thanks a lot. I think, yeah I show it now I think it's done for zero. Maybe I explain about anti-cloud but there is also another project in the AT&T called the AT&T Cloud. It's an action on the AT&T Cloud and the services. So one of the major developments last year having AT&T was the AT&T National Cloud. Motivation for this work basically we want to turn our local outcome connectivity to the internet to certain party service providers and to remove resource client. The other motivation is to support them much with their superior connection. So if you look at this architecture this is actually what we have at this moment the basic infrastructure for cloud. We have region cloud region cloud is our small cloud here which is scattering basically everywhere if we can do it around the world that would be the case. Then all the scattering region cloud will connect to our global cloud so the functionality in the region cloud basically the main thing is cloud interface server. What it does is basically it accepts the connections from all activity devices and then you know receive all the notifications afterwards they send all the restful messages to connect the pipelines. The main functionality that's actually the core part of this cloud interface is we actually based on AT&T framework and on the top we added cloud over TCP support. As Phil mentioned earlier basically you know activity is highly in the global cloud we have introduced a cloud server this is the other to achieve the other goal basically it's just the support of the user level authentication. So what happens is if as a user you use your smart device your rich device that we call rich device to go to your third party service provider like Google, Facebook, get your token and then you send your token to the account server through your cloud interface server to the account server. The account server gets this information and then you connect to your third party provider like Facebook and Google again get your user information. This user information will be stored in the account server so basically the account server has all your user has all your user identity and information afterwards so it will send the response back to your cloud to the device. With the account server in place basically we managed to be able provide the interface for the third party authentication provider like Google, Facebook to extend their user identity to the activity cloud. And for think cloud concept for think cloud is constrained devices with very limited resources and memories will rely on the resource directory to store in the middle to do their cloud actions. So what does is the think device basically publish their resource to resource directory and the resource directory after the resource directory after the resource directory got the results from the devices from then on it will act on behalf of the devices to answer to respond to any resource request. We also introduced the message queue server this is basically we actually kind of want to inline pops up so we also have a pops up functionalities so basically you can do whatever you do with pops up you can create a public you can update your message and you can subscribe or delete a public. So basically this is what we have now for cloud. With this cloud in place basically we really make the use cases scenarios for activity to the next level. This service is another side of the function from an activity. So the basic goal for this time is to make the application developers life easier. So we wrapped all the functional possible resource related functionalities hide all the lower level complexity the complexity part of the base code and then wrap them into C++ APIs. So what we have here resource container. This resource container basically provides a way for non-OCF devices to integrate into OCF ecosystem by providing a resource boundary. So you know you do within the boundary you do actually you do protocol mapping. So for example if I have a because in an activity we use a message queue over cloud so you can connect an activity device to an MQTT device you need to create a resource boundary within them you know based on resource container template to make some work. And notification basically is as the name said really we are caching and monitoring the status features of the resource and send the updates to observers. Resource calculation is abstract layer on top of the base layer. So it's really just a resource and any resource related under layer APIs we actually wrap them up as providing a C++ API. And scene manager. The concept of scene here is a collection. So when you think like in my house every room has a light. So all the light are put together as a thing called light thing. So if I bring it away for a business trip what I do is I send the notification to every light what I do is just send one notification to the scene manager who will do the rest for you. The last one is easy setup. So easy setup basically is you know like in LTE devices they could have multiple devices which support different connectivity that can close. So it's easy setup we actually provide two stage one is embodying others provision. So if I give you an example we have a new speaker out the box without UI and the new speaker connects to your home access point. So what you have here is using your mobile phone. The mobile phone is already in your home network. So what you have here is the mobile phone will you find the access information of the speaker either via Bluetooth or just scan the QR code and set up a temporary connection and then it will then send the access point information to the speaker where all your source will be viewed here. This is the embodying stage which means that you are home. The mobile phone will push the access point or the password access point address to the speaker. So basically Open Connectivity Foundation establishes standard specification to address the interoperability issues in IoT. OCF sponsors Open Source Project IoT to do the implementation of the specification. And then once the implementation is done OCF will step in again to certify all the devices which has those implementations. And Phil has also worked with you through the IoT team node it's really the bridge to bridging our IoT to native code to web services interface. And then you might also see the article cloud where I'm really good at it and then we work through the native cloud services. So yeah, I can show the demonstration again. So we take the demonstration. So the demonstration is about this high to C right sensor and if I change I cover this so the relay is turning off. So the message has been sent. So maybe I can, either we can answer questions or I can also show you some extra stuff related to the project. Yeah, let's do one or two questions. Any more? So this is what I've done before after previous presentation. Okay, yeah. Any questions? Okay, thanks a lot. Nice explanation.