Project CS 2017-01-12 ~1min 11 students Project CS course Industrial partners 2017-01-12

Outline Background System overview Implementation Demo Future work    Outline Background System overview Implementation Demo Future work ~1.5min Very basic Using prefixes instead of IPs. Caching In contrast to IP-based, host-oriented, Internet architecture, content centric networking (CCN) emphasizes content by making it directly addressable and routable. Endpoints communicate based on named data instead of IP addresses. CCN is characterized by the exchange of content request messages (called "Interests") and content return messages (called "Content Objects").

GreenIoT project ~2 min What is greenIoT Inova + kommun    GreenIoT project ~2 min What is greenIoT Inova + kommun Testbed in uppsala Relation between greenIoT and our stuff

Project Description ~2 min In the context of greenIoT check website, introduction of the project

Content centric networking    Content centric networking FIB Forwarding Information Base Store information about what face to follow to find a given name PIT Pending Interest Table Store information about what interests are pending ~1.5min Very basic Using prefixes instead of IPs. Caching In contrast to IP-based, host-oriented, Internet architecture, content centric networking (CCN) emphasizes content by making it directly addressable and routable. Endpoints communicate based on named data instead of IP addresses. CCN is characterized by the exchange of content request messages (called "Interests") and content return messages (called "Content Objects"). There are three types of routing tables in CCN. The network routes the interest based on the name using longest matching prefix, which is an algorithm used by routers to select an entry from a forwarding table CS Content Store Buffer content objects for potential reuse

Goals Deployment of CCN sensors CCN network    Goals Deployment of CCN sensors CCN network Integrate with GreenIoT project ~1.5min Very basic Using prefixes instead of IPs. Caching In contrast to IP-based, host-oriented, Internet architecture, content centric networking (CCN) emphasizes content by making it directly addressable and routable. Endpoints communicate based on named data instead of IP addresses. CCN is characterized by the exchange of content request messages (called "Interests") and content return messages (called "Content Objects").

System overview

Project CS 2016 Testbed Sensors BR1 DS Client Relay BR2 DB Broadcasting CCN interest - content object communication DB

Relays List of immediate neighbors (Faces) List of forwarding entries based on prefixes Forwards interests through faces Forwards content based on pending interests Caches all content for specified duration

CCN Router Software CCN-Lite UDP IP Ethernet Options Option choice What it already has We have added..

A B Send back to X Add to cache Interest Object /sensor1/1 Send content to A Forward to B FIB FIB /sensor1 B /sensor1 Q PIT PIT /sensor1/1 X /sensor1/1 A CACHE CACHE /sensor1/1 /sensor1/1

Directory Service Python-based Keeps track of active relays, sensors and border-routers Manages the forwarding plane of the CCN network Provides clients with list of addressable prefixes

DS BR1 BR2 DB Available sensors request! Fetch info from DB Construct JSON with relevant information and send back to client New sensor registered! New border-router registered! Add sensor info to DB Calculate shortest path from each relay to border-router… Update FIB of each relay with the neighbor along that path BR1 New sensor goes online Inform DS! What prefixes can I address? BR2 Broadcasting CCN interest - content object communication DB

Register Service Register Service starts up Register service creates an SenML object from the information that was included in the sensors register content object Register service creates an SenML object from the information that was included in the sensors register content object SenML is sent to DS with UDP message New sensor goes online Request sensor information: /p/sensor_mac/regist Assign location: /p/sensor_mac/regist/location New sensor goes online Register Service starts up Request DS ip address via CCN New sensor goes online Request sensor information: /p/sensor_mac/regist Register Service starts up Request DS ip address via CCN DS ip received and start up completed

Register Service Registers a sensor to the DS when it goes online Removes a sensor from the DS when it goes offline Register Services Config File defines the location of the Border Router

CC2650 SensorTag Less text more pictures

Sensor Software SensorTag CC2650 runs Contiki Limited Cache Small Buffers Static IPv6 addresses 6lowPan protocol Dynamic CCN prefix Sensor CC2650 is running Contiki Caches a limited number of Content Objects Static + unique IPv6 addresses 6lowPan protocol Prefix (say something here)?

Prefix Configuration The sensor physical location should not matter, it should only produce values At the same time the sensor should respond only to certain prefixes. They should have a flexibility to adapt in multiple locations without having to flash them again The prefix should be able to be modified dynamically on the fly depending in which room the sensor is used

Prefix Configuration Initially and every 15 loops the sensor produces /p/macaddress/regist This content object contains sensors measurements and sensor information (model etc) Keyword regist followed by location indicates a registration request /p/macaddress/regist/location Now the prefix contains the location as part of the prefix /p/location/macaddress/sequence_no

Border Router Zolertia RE-Mote Sparrow border router by SICS Routes to all sensors in its radius Refreshes its neighbors list every 30 seconds Zolertia RE-Mote Sparrow border router by SICS Routes to all sensors in its radius Refreshes its neighbors list every 10 mins - way too long, we will change that

CCN-Datastore

Storing of sensor data BR1 DB BR2

CCN-MQTT Machine-to-machine connectivity protocol Broker, subscriber and publisher Publisher Broker Subscriber

Publish sensor data Subscribe to all published data /p/# Subscribe to all data in a single location /p/location/# Subscribe to all data from a single sensor /p/location/macaddress/# Subscribe to a single data point /p/location/macaddress/sequence_no BR1 MQTT- Broker BR2 DB

Subscribe to GreenIoT sensor data Subscribe to topic iot-2/type/greenviot/# Insert data into MongoDB database Insert data into the local relay’s cache

Named functions DB Historical data: /nfn/his/location Predicted data: /nfn/pre/location DB

Android application Uses CCN-Lite How does it use CCN-Lite App idea here? or after Relay as a service? App idea here I think. App Idea, took time to come up with, lot of discussions with all partners Main interface, simple, made for basic users to follow the original app idea to find lunch places Info for areas and sensors come from the SDS, nothing is hardcoded Data used for the smiley is meant to be noise, but we use light - because of the drivers + handy for the demo When we click on a card: expanded card More details about which sensors and their values (light, temperature, humidity), the name of the sensor (uri) and the link to another screen to request pas values for that sensors that we will see in the demo Prediction graph shows past and predicted data for the area for this day - usinge machine learning ?. Depending on the time of the day you will see more history and less prediction. Both are fetched from the database when the card is expanded. End with how it uses ccn-lite

Relay as a service CCN Gateway Relay 192.168.1.100:9695 Service 127.0.0.1:9695 Running CCN relay in a service Seprate app … X.X.X.X:xxxx Applications A B

Demo Main application Sensor test application THE SENSORS UPDATE EVERY 30 SEC Begin with main app. Launch with no area, request info from SDS, show the sensors appearing. What should the light/smiley values be ? One sensor covered, the other in the open Explain the light values, Say that we are covering the second sensor as well, it will update within the next 30 seconds - explain the update rate ? show card expansion, explain that the data is fetched when the card is expanded, scroll the graph around. Show the second screen, explain and show we can choose a date and fetch data from a specific sensor to see past values. Back to main screen, show the updated smiley. To the second app Sensor test application

Conclusion

Future Work Include microphone values Request future values Distributed datastore Multiple DS

Q&A thank, now we will start a question and answer session, in this session we would really like to get your opinions of the issues we’ve discussed in our presentation, specifically if we should move forward with the python solution to the SDS or the separate custom CCN relays, also whether or not we should use time or sequences numbers to build a contiguious namespace, so hopefully we can address those issues, but we can begin with questions for the audience, and if you would like to answer either of our questions or share any advice we would greatly appreciate it