A Keyword-based ICN-IoT Platform

Onur Ascigil, Sergi Reñé, George Xylomenos,* Ioannis Psaras, George Pavlou

University College London, UK*Athens University of Economics and Business, Greece

ACM ICN 2017, Berlin, Germany27th September 2017

The rest of the paper is organized as follows. In Section 2 wediscuss the tab-based ICN routing scheme upon which our work isbased, while in Section 3 we describe our proposed IoT platform.Preliminary performance results about three proposed functionplacement strategies are presented in Section 4. We discuss relatedwork in Section 6 and conclude and discuss futurework in Section 7.

2 TAG-BASED ICN ROUTINGOur keyword-based platform has been inspired by TagNet, an ICNarchitecture using tags to name content items at the global level,albeit without function execution facilities [6]. In this section wepresent TagNet and explain how our platform diverges from it, dueto its focus on IoT and edge computing.

In TagNet, data are identi�ed by content descriptors, while nodesare identi�ed by host locators. Content descriptors are sets of location-independent tags, chosen by the applications, so as to best describeindividual content. A descriptor is represented as a Bloom �lter,created by hashing multiple times each tag into a �xed size bit vec-tor, and then OR-ing the bit vectors of the tags. To see if a tag hasbeen added to a descriptor, we see if the bits set to 1 in the tag area subset of those in the descriptor. With content descriptors of 192bits and 7 hash functions and no more than 15 tags per descriptor,false positives are extremely rare [7].

The matching relation in TagNet is de�ned as a subset relationbetween sets of tags. A descriptor R in a content request matchesa content item C if the request includes all tags (and maybe more)of the publication (R ◆ C). For example, a request with descrip-tor {temperature, Floor1} would match an item with descriptor{Floor1}. In our platform, we use the reverse relation, that is, match-ing implies that (C ◆ R), as we want a request for {temperature} tomatch a content item {temperature, Floor1}, so as to allow groupsof content items to be expressed in a compact manner.

TagNet uses trees for routing, but since using a single tree for allrouting can lead to stretched routes between some nodes, multipletrees are used, so packets need to include a tree identi�er in theirheader. For each tree, a node maintains a list of the descriptorsannounced by all the nodes reachable through that neighbor, thatis, a list of Bloom �lters. When a router receives a packet with arequest descriptor R, it forwards the packet towards each neighborthat has announced a matching descriptor, making sure that thetotal fanout of the request will not exceed a limiting factor k . Thegoal is to �nd a single item matching the request. In our platform,we expect to receive multiple content items with a single requestfor further processing, therefore matching uses the reverse rulethan TagNet, which leads to more matches, and we do not limit thefanout - we can potentially reach the entire tree.

When a content request reaches a matching data item, the itemneeds to be returned to the requester. While in NDN requests leavebreadcrumbs behind them, in TagNet they are forwarded over thesame tree used for the request. To achieve this, the nodes in eachtree are labeled using the TZ algorithm [8], which allows any nodeto forward a packet using only the TZ-label of that node and theTZ-label of the destination. In TagNet then, each request carriesthe TZ-label of the requester, called the host locator of that node,to allow data items to be returned without maintaining per requeststate in the network. In our platform, we only use a single tree

rooted at the border router between the IoT area and the Internet,with requests traveling down the tree and responses traveling upthe tree, leading to greatly simpli�ed routing.

3 KEYWORD-BASED ICN-IOTIn this section we provide a description of our keyword-basedICN-IoT platform. We describe the naming scheme developed forour platform, the forwarding operation for requests and responses,three di�erent strategies for data retrieval and processing, andprovide a step-by-step example.

3.1 Naming scheme

Hierarchical Partz }| {/a/b/c/| {z }

Domain location�

Function tagz}|{f:tag| {z }

Network function

�Hashtagsz }| {

#tag1, #tag2| {z }IoT information

Figure 1: Keyword-based Names

Our naming scheme needs to (a) locate an IoT domain across theInternet, (b) identify (individual of groups of) data values withinthat domain and (c) express processing requirements over thesevalues. Taking these features into account, names are composed ofthree parts (see Figure 1):

Hierarchical Part. It names the IoT domain that the infor-mation belongs to, using the hierarchical naming schemeof NDN; as NDN matches pre�xes, it o�ers compatibilitywith NDN outside the IoT domain. Network administratorscan de�ne their own hierarchical name spaces, enablingcommunication between di�erent campuses or networkingdomains e.g., /ucl/london/bloomsbury/.

Function tags. It consists of a single (mandatory) functiontag, which describes the function that should process theset of IoT data described by the hashtags. If no processingis desired, an identity function tag is used.

Hashtags. It comprises a set of hashtag-like keywords, whichare used to describe the IoT data that need to be retrievedfor processing by the function. The semantics of the hash-tags depend on the data provided by the local sensors; wecan even have tags describing processed data, rather thanthe raw data produced by the sensors.

In the example of the BMS application, the complete nameincluded in a user request can have the �xed hierarchical part/ucl/london/bloomsbury naming the UCL London campus, thefunction name f:average and the hashtags #RobertsBuilding,#Temperature; these indicate that we want to get the average ofthe temperature sensors in the Roberts Building. The correspond-ing data items are gathered and processed by the network, and therequester eventually receives the average value.

3.2 Request and Content RoutingThe routing operation in our platform is a hybrid, based on a modi-�ed version of the tag-based routing [7] for the local IoT domainand regular NDN forwarding [9] outside that domain. The modi-�cations assume that the goal of the system is processing a set ofIoT data in the local domain, before a result is sent to the Internet,using a �exible and scalable keyword-based naming scheme.

2

IoT Status Quo: Isolation of Things

Long RTTsDifficult to manage

Lots of Messages

Problem Statement

• Facts– IoT data sets can become huge over time– IoT data items are produced at the edge– IoT data need processing– IoT data may be useful to many applications

• Goals– Bring processing close to the data– Allow applications to share data and results

Naming IoT Data

• Hierarchical approach to naming is too rigid!• Picture a Building Management System

– Data can be named on a location basis• /building/floor/room/…

– Data can be named on a data-type basis• /temperature/building/floor/…

• How to accommodate different applications?– How to ease data/result sharing?

Sketch of Keyword-Based IoT

Data Sharing& Reuse

Local Processingbased on Named

Functions

Subset of Filtered Data sent to cloud

Impossible to do with IP!

Keyword-based IoT: Overview

• Virtual split: IoT domain vs. Internet domain– Realised by an IoT domain border gateway

• IoT domain: data named by keywords– {temperature, building, room, …}– Keywords encoded by hashing– Names encoded as Bloom filters

• Internet domain: domains named hierarchically– /fub/campus/cs

Keyword-based IoT: Name structure

The rest of the paper is organized as follows. In Section 2 wediscuss the tab-based ICN routing scheme upon which our work isbased, while in Section 3 we describe our proposed IoT platform.Preliminary performance results about three proposed functionplacement strategies are presented in Section 4. We discuss relatedwork in Section 6 and conclude and discuss futurework in Section 7.

2 TAG-BASED ICN ROUTINGOur keyword-based platform has been inspired by TagNet, an ICNarchitecture using tags to name content items at the global level,albeit without function execution facilities [6]. In this section wepresent TagNet and explain how our platform diverges from it, dueto its focus on IoT and edge computing.

In TagNet, data are identi�ed by content descriptors, while nodesare identi�ed by host locators. Content descriptors are sets of location-independent tags, chosen by the applications, so as to best describeindividual content. A descriptor is represented as a Bloom �lter,created by hashing multiple times each tag into a �xed size bit vec-tor, and then OR-ing the bit vectors of the tags. To see if a tag hasbeen added to a descriptor, we see if the bits set to 1 in the tag area subset of those in the descriptor. With content descriptors of 192bits and 7 hash functions and no more than 15 tags per descriptor,false positives are extremely rare [7].

The matching relation in TagNet is de�ned as a subset relationbetween sets of tags. A descriptor R in a content request matchesa content item C if the request includes all tags (and maybe more)of the publication (R ◆ C). For example, a request with descrip-tor {temperature, Floor1} would match an item with descriptor{Floor1}. In our platform, we use the reverse relation, that is, match-ing implies that (C ◆ R), as we want a request for {temperature} tomatch a content item {temperature, Floor1}, so as to allow groupsof content items to be expressed in a compact manner.

TagNet uses trees for routing, but since using a single tree for allrouting can lead to stretched routes between some nodes, multipletrees are used, so packets need to include a tree identi�er in theirheader. For each tree, a node maintains a list of the descriptorsannounced by all the nodes reachable through that neighbor, thatis, a list of Bloom �lters. When a router receives a packet with arequest descriptor R, it forwards the packet towards each neighborthat has announced a matching descriptor, making sure that thetotal fanout of the request will not exceed a limiting factor k . Thegoal is to �nd a single item matching the request. In our platform,we expect to receive multiple content items with a single requestfor further processing, therefore matching uses the reverse rulethan TagNet, which leads to more matches, and we do not limit thefanout - we can potentially reach the entire tree.

When a content request reaches a matching data item, the itemneeds to be returned to the requester. While in NDN requests leavebreadcrumbs behind them, in TagNet they are forwarded over thesame tree used for the request. To achieve this, the nodes in eachtree are labeled using the TZ algorithm [8], which allows any nodeto forward a packet using only the TZ-label of that node and theTZ-label of the destination. In TagNet then, each request carriesthe TZ-label of the requester, called the host locator of that node,to allow data items to be returned without maintaining per requeststate in the network. In our platform, we only use a single tree

rooted at the border router between the IoT area and the Internet,with requests traveling down the tree and responses traveling upthe tree, leading to greatly simpli�ed routing.

3 KEYWORD-BASED ICN-IOTIn this section we provide a description of our keyword-basedICN-IoT platform. We describe the naming scheme developed forour platform, the forwarding operation for requests and responses,three di�erent strategies for data retrieval and processing, andprovide a step-by-step example.

3.1 Naming scheme

Hierarchical Partz }| {/a/b/c/| {z }

Domain location�

Function tagz}|{f:tag| {z }

Network function

�Hashtagsz }| {

#tag1, #tag2| {z }IoT information

Figure 1: Keyword-based Names

Our naming scheme needs to (a) locate an IoT domain across theInternet, (b) identify (individual of groups of) data values withinthat domain and (c) express processing requirements over thesevalues. Taking these features into account, names are composed ofthree parts (see Figure 1):

Hierarchical Part. It names the IoT domain that the infor-mation belongs to, using the hierarchical naming schemeof NDN; as NDN matches pre�xes, it o�ers compatibilitywith NDN outside the IoT domain. Network administratorscan de�ne their own hierarchical name spaces, enablingcommunication between di�erent campuses or networkingdomains e.g., /ucl/london/bloomsbury/.

Function tags. It consists of a single (mandatory) functiontag, which describes the function that should process theset of IoT data described by the hashtags. If no processingis desired, an identity function tag is used.

Hashtags. It comprises a set of hashtag-like keywords, whichare used to describe the IoT data that need to be retrievedfor processing by the function. The semantics of the hash-tags depend on the data provided by the local sensors; wecan even have tags describing processed data, rather thanthe raw data produced by the sensors.

In the example of the BMS application, the complete nameincluded in a user request can have the �xed hierarchical part/ucl/london/bloomsbury naming the UCL London campus, thefunction name f:average and the hashtags #RobertsBuilding,#Temperature; these indicate that we want to get the average ofthe temperature sensors in the Roberts Building. The correspond-ing data items are gathered and processed by the network, and therequester eventually receives the average value.

3.2 Request and Content RoutingThe routing operation in our platform is a hybrid, based on a modi-�ed version of the tag-based routing [7] for the local IoT domainand regular NDN forwarding [9] outside that domain. The modi-�cations assume that the goal of the system is processing a set ofIoT data in the local domain, before a result is sent to the Internet,using a �exible and scalable keyword-based naming scheme.

2

• Functionality– Hierarchical Part: Locate IoT domain across Internet– Function Tag: Express processing (if needed)– Hashtags: Identify data values within IoT domain

• Example– /fub/campus/cs f: average #temperature,#foyer

Keyword-based IoT: Operation

• Outside IoT domain: ignore Function & Hashtags• Inside IoT domain: ignore Hierarchical Part• Logical IoT topology is a tree

– Physically or via spanning tree algorithm• Propagate and replicate Interest downstream

– As in TagNet, but reversing the rules• Execute function to merge result upstream

– If no matching data: NACK sent back

Function Placement – Naïve

LC

GW GW

BR

GW GW GWGW

Campus

Floor

Building

Area

Room

#flr1

#bldng1

#area1

#bldng2

#flr2

#rm1 #rm2

#flr1 #flr2

#area1 #bldng1 #flr1 #avg_temp

GW GW

#...#...

Data Data

Result

Function Placement – Minimum Transfer

LC

GW GW

BR

GW GW GWGW

Campus

Floor

Building

Area

Room

#flr1

#bldng1

#area1

#bldng2

#flr2

#rm1 #rm2

#flr1 #flr2

#area1 #bldng1 #flr1 #avg_temp

GW GW

#...#...

Data Data

Result

Function Placement – Least Congested

LC

GW GW

BR

GW GW GWGW

Campus

Floor

Building

Area

Room

#flr1

#bldng1

#area1

#bldng2

#flr2

#rm1 #rm2

#flr1 #flr2

#area1 #bldng1 #flr1 #avg_temp

GW GW

#...#...

Data Data

Result

Simulations

• Regular tree: height: 3, branching: 10– E.g., 10 floors, 10 areas, 10 devices: 1111 nodes

• More cores as we move towards root• 100 apps simulated

– Each app asks data from up to five random nodes– CPU time is random (mean 100 ms) but fixed per app– All data items are of the same size– Each link has 3 ms propagation delay– Requests generated so as to not overload root

Preliminary Results

�

������

������

������

������

��������������������������

���� �������� ����� ��������� �����

���

�����������������������

��������

����� � ����� � ����� � ����� �

�

���

�

���

�

���

�

���� �������� ����� ��������� �����

������������

����������

��������

�

���

���

���

���

���

���� �������� ����� ��������� �����

��������������������

�������

��������

Issues for Discussion

• IoT Domain Size– Too large domains will make Bloom filters saturate

• Routing Scheme Limitations– TagNet routing would allow execution not on the tree

• Expressing Time Constraints– Information Time Tags to select Data (and Results)

• Security and Privacy– Combine with Proxy Re-encryption (Fotiou et al.)

Summary

• Flexible naming/processing for ICN-IoT– CCN/NDN names across the Internet– Keyword-based names inside IoT domain– Function tags to locally aggregate data

• TagNet inspired matching to locate data– Single tree and reverse matching rule

• NFN inspired execution to aggregate data– Tree-based execution placement strategies