© 2017 IEEE. �is is author’s version of this work. It is posted here by permission of IEEE for you personal use. Not for redistribution. �ede�nitive version was published in the proceedings of 1st IEEE International Conference on Internet-of-�ings Design and Implementation(IoTDI), 2017.

Breaking out of the Cloud: Local Trust Management andRendezvous in Named Data Networking of ThingsWentao Shang

UCLALos Angeles, CA 90095wentao@cs.ucla.edu

Zhehao WangUCLA REMAP

Los Angeles, CA 90095zhehao@remap.ucla.edu

Alexander AfanasyevUCLA

Los Angeles, CA 90095aa@cs.ucla.edu

Je� BurkeUCLA REMAP

Los Angeles, CA 90095jburke@remap.ucla.edu

Lixia ZhangUCLA

Los Angeles, CA 90095lixia@cs.ucla.edu

ABSTRACTMany emerging IoT approaches depend on cloud services to facili-tate interoperation of devices and services within them, even whenall the communicating entities reside in the same local environ-ment, as in many “smart home” applications. While such designso�er a straightforward way to implement IoT applications usingtoday’s TCP/IP protocol stack, they also introduce dependencies onexternal connectivity and services that are unnecessary and o�enbri�le. �is paper uses the design of an IoT-enabled home enter-tainment application, dubbed Flow, to demonstrate how the NamedData Networking (NDN) architecture enables cloud-independentIoT applications. NDN enables local trust management and ren-dezvous service, which play a foundational role in realizing otherIoT services. By employing application-de�ned naming rather thanhost-based addressing at the network layer, and securing data di-rectly, NDN enables straightforward and robust implementation ofthese two core functions for IoT networks without cloud connec-tivity. At the same time, NDN-based IoT designs can employ cloudservices to complement local system capabilities. A�er describingthe design and implementation of Flow, together with a discussionon preliminary generalization of the design, as an evaluation thepaper conducts a brief thought exercise of how Flow could be real-ized using two popular IoT frameworks, Amazon’s AWS IoT serviceand the Apple HomeKit framework, and compares that with thereal implementation over NDN.

CCS CONCEPTS•Networks →Network architectures; Network protocol de-sign; •Computer systems organization→Embedded and cyber-physical systems;

KEYWORDSNamed-Data Networking, Internet-of-�ings, Cloud-independence

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permi�ed. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior speci�c permission and/or afee. Request permissions from permissions@acm.org.IoTDI 2017, Pi�sburgh, PA, USA© 2017 ACM. 978-1-4503-4966-6/17/04. . .$15.00DOI: 10.1145/3054977.3054993

ACM Reference format:Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and LixiaZhang. 2017. Breaking out of the Cloud: Local Trust Management andRendezvous in Named Data Networking of �ings. In Proceedings of �e2nd ACM/IEEE International Conference on Internet-of-�ings Design andImplementation, Pi�sburgh, PA, USA, April 18-21, 2017 (IoTDI 2017), 11 pages.DOI: 10.1145/3054977.3054993

1 INTRODUCTIONInternet-of-�ings (IoT) technologies are being rapidly adoptedin the consumer electronics market. �ere has been increasingdeployment of “smart” devices in the home environment to cre-ate interactive, human-in-the-loop applications and services. Inaddition to their use in traditional home automation systems, IoTtechnologies have also been applied to home entertainment–forexample, with wireless inertial sensors used to track user bodymovement in sports games. Combined with emerging virtual andaugmented reality technologies, IoT o�ers the promise of immersiveand interactive experience for end-users. Common requirementsfor such systems include:

• Integration of heterogeneous devices and services fromdi�erent vendors;

• Interactive user experience that emphasize real-time feed-back loops;

• Easy installation and con�guration; and• Security protection, due to tight integration with the home

network.Many IoT frameworks and ecosystems have been proposed over

the last few years to facilitate the development ofmore sophisticatedapplications like these. �ey typically provide a similar set offramework-level services, including user and device authenticationand authorization, device and service discovery, device onboardingand management, publish-subscribe messaging, and remote access.On top of these common services, IoT developers can further designand implement application-speci�c functionality. Fig. 1 shows acommon hierarchical architecture of IoT services, where “namedentities” refer to users, devices, and applications that require trustmanagement and utilize rendezvous services to get interconnectedinto a coherent home IoT system.

Existing home IoT systems o�en depend on cloud-based servicesprovided by device vendors and/or service providers to implement

IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and Lixia Zhang

Named Entity

Trust Management Rendezvous

Device Management

Pub-sub Messaging

Resource Discovery

Access Control

Gateway Interface

Control Automation

Machine Learning

Persistent Storage

Web Integration

Event Monitoring

Framework

Applications

Figure 1: Hierarchical architecture of IoT services.

the framework services and application functions needed in a localIoT environment.1 Such dependency on the cloud, for what couldbe inherently local functionality, introduces potential negative im-pacts:

• �e home IoT system requires connectivity to the cloudto manage local devices and users; the user cannot installnew devices or authorize new users if connectivity to thecloud is lost.

• With cloud-based services, control and resource accesscommands go through the cloud, which acts as the ren-dezvous point, even when the command issuer resides inthe same local network as the target device. �is introducesadditional delays that may hurt interactive applications.

• Cloud-based services expose data from the home environ-ment to external parties, introducing potential security andprivacy risks.

• A simple error in the cloud can unnecessarily bring downservices to a large number of IoT systems.

In this paper, we present an alternative approach by leveragingthe Named Data Networking (NDN) architecture [3, 12]. We focuson enabling IoT functions to be achieved locally, with support foroptional cloud services. Building upon our previous work in [4],this paper identi�es trust management and rendezvous as twofoundational building blocks of all IoT services, as shown in Fig-ure 1. It develops a speci�c design and implementation using NDNprimitives.

In Section 2, we �rst give an overview of representative IoTecosystems and outline their dependencies on the cloud. We thendescribe in more detail these two foundational IoT services, trustmanagement and rendezvous, which provide the basis for boot-strapping other services. We show that both of them can be sup-ported more e�ciently in IoT networks under the Named DataNetworking architecture (Section 3). �e key idea behind such acloud-independent architecture design is to leverage NDN’s name-based forwarding to directly operate on well-established names inthe local context. �is enables straightforward solutions for trustmanagement, via schematized trust, and rendezvous, via distributeddataset synchronization.

1Cloud services also support features, such as voice recognition, which can be di�cultto achieve locally; such advanced services are not critical to the overall design of IoTsystems and thus not our focus in this paper.

�e rest of the paper is organized as follows. Sections 4 and 5present the design and implementation of Flow, an IoT-augmentedhome entertainment application, as a realization of the proposedIoT approach using NDN. While this implementation focuses onan interactive home entertainment application, we believe thatour approach should be generally applicable to traditional homeautomation systems and many other IoT subdomains. To providea qualitative evaluation, Section 6 presents a brief comparison be-tween Flow and how a similar application could be approachedusing AWS IoT and Apple HomeKit services, two popular TCP/IP-based IoT frameworks.

2 BACKGROUND2.1 Existing IoT EcosystemsMany current IoT architectures and frameworks, such as Blue-tooth [2], ZigBee [14], and Google�read [9], have primarily focusedon achieving device-to-device connectivity and interoperability. Forexample, Bluetooth de�nes a seven-layer protocol stack and howtwo devices can connect to each other over either point-to-point ormesh networks, discover the other’s capabilities through applica-tion layer pro�les, and exchange application data called a�ributes.Designed as silos, these architectures cannot interoperate with eachother without a special gateway or translator deployed in between,limiting development and innovation of IoT technologies.

As IoT systems become more powerful and more complex, thereis a growing demand for more comprehensive application-layerframeworks that can integrate and manage di�erent types of de-vices across di�erent communication technologies, enable moreintelligent application logic involving a large number of devices,and provide simpli�ed user experience in operating such systems.In this subsection, we brie�y review a few popular IoT applicationframeworks that emerged in the last three years.

AllJoyn2 (20133) and IoTivity4 (2015) are generic IoT applicationframeworks that aim to bridge various IoT transport technologiesand provide a common language for applications and services. �eyboth o�er standardized interfaces for common IoT services such asdevice management, resource discovery, application-layer messag-ing, access control, etc.. While they started with an emphasis onproximal (i.e., local-area) communications, they also de�ne gatewayinterfaces for connecting to external services both locally and inthe cloud. As lower-level frameworks, they do not mandate speci�csolutions for trust management and rendezvous, but provide com-mon protocol interfaces for developers to design and implementapplications and services that run either locally or remotely in thecloud.

AWS IoT5 (2015), Google Weave6 (2015), Azure IoT Suite7 (2015),and Samsung Smart�ings8 (2014) are examples of cloud-centric IoTecosystems that are bound to speci�c cloud service providers andtheir implementations of all common IoT services, from authenti-cation and device management to data processing and application

2h�ps://allseenalliance.org3�e number in parentheses indicates the year of initial public announcement.4h�ps://www.iotivity.org5h�ps://aws.amazon.com/iot/6h�ps://developers.google.com/weave/7h�ps://azure.microso�.com/en-us/suites/iot-suite/8h�ps://www.smar�hings.com

Local Trust Management and Rendezvous in Named Data Networking of Things IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA

hosting. �rough tight integration with the cloud, those ecosystemsprovide simple and centralized solutions for trust management andrendezvous. To make devices and applications securely discoverand communicate with each other, the user typically registers all lo-cal IoT devices and applications with the remote cloud service. �ecloud then handles the tasks of device authentication and catalogmaintenance of the functionality available in the local environment.Another bene�t of such cloud-centric architectures is easy integra-tion with advanced services requiring data access or processingpower unavailable in the local environment, such as search, voicerecognition, and data analytics needed by large-scale IoT systemsincluding precision agriculture and industrial control.

A notable recent trend among such cloud-centric architectures isto move certain IoT applications and services into the local networkand execute them on a local hub in order to tolerate intermi�entcloud connectivity. For example, Amazon, Google, and Samsung allcreated their own home hub devices to connect local IoT devices andperform simple home automation tasks. �e recently announcedAWS Greengrass9 (2016) even allows part of the AWS IoT controlplane to be hosted on a local server, essentially creating a privatecloud service close to the IoT deployment. However, local data (e.g.,sensor reading, device status, system con�g, etc.) still need to besynchronized to the remote cloud to be consumed by cloud-hostedservices.

Apple HomeKit10 (2014) can be viewed as an example of thisrecent trend. HomeKit is designed as an IoT framework speci�-cally for home automation applications that interact with Apple-certi�ed IoT devices. Di�erent from the pure cloud-centric ecosys-tems mentioned above, HomeKit’s design enables and encourageslocal communications. �e framework stores the home con�gura-tion in a local database which is synchronized across the devicesthat are hosting HomeKit apps (e.g., a user’s iPhone or Apple TV).A�er obtaining permissions from the user, HomeKit apps on any ofthose devices can access the database to discover and communicatewith the home devices directly over the local network. Hence, therendezvous service is provided locally through database synchro-nization so that each device has complete knowledge of the homenetwork. However, HomeKit still relies on Apple’s iCloud servicefor device authentication and trust management: each user andeach new device must be authenticated through Apple and obtainiCloud IDs �rst. In addition, the replication of the home con�gu-ration database across user’s Apple devices is done indirectly viaiCloud. Moreover, remote access from outside the home networkrequires tunneling the messages through iCloud to a local hub (e.g.,an Apple TV) inside the home network.

Table 1 summarizes the approaches taken by di�erent IoT ar-chitectures and ecosystems in providing the trust managementand rendezvous services. Note that all of them are built on top ofthe TCP/IP protocol stack, therefore have to provide the mappingservices to resolve named entities to speci�c IP addresses, eitherremotely in the cloud DNS service or locally via some zero-con�gprotocol such as mDNS.

9h�ps://aws.amazon.com/greengrass/10h�p://www.apple.com/ios/home/

Table 1: Comparison of existing IoT architectures andecosystems.

Trust management RendezvousBluetooth P2P peering None (P2P)ZigBee Pre-shared master key Broadcast

Google �read L2 network-wide key NoneAllJoyn / IoTivity Interface only Interface only

AWS IoT Cloud service Cloud serviceGoogle Weave Cloud service Cloud serviceAzure IoT Suite Cloud service Cloud service

Samsung Smart�ings Cloud service Cloud serviceApple HomeKit Cloud service Database sync

2.2 Named Data Networking of �ingsNamed Data Networking (NDN) is a future Internet architectureunder development. NDN replaces host-addressed IP packets withnamed data as the new narrow waist of the “hourglass” protocolstack. Each data object has a hierarchical name that serves as theunique identi�er within the application context where the data ispublished and consumed. To request a data object, one sends anInterest packet carrying a pre�x of the data name. NDN forwardersforward the Interest packet towards where the data may be found.Each forwarder along the path records the Interest and its incominginterface in a local Pending Interest Table (PIT). When a matchingData packet is encountered, either in a forwarder’s cache or fromthe original producer, the Data packet is returned to the requesterby following the reverse path of the Interest as recorded in the PITsof the nodes along the path; those nodes may store a copy of theData packet in their local caches a�er forwarding, to be used tosatisfy future requests for the same data. �e Data packet carries acryptographic signature generated by its producer, together withthe name of the signing key. �is allows the data consumer to verifythe provenance of received data regardless of its source.

In our previous paper [4], we described that, by naming andsecuring the things and data directly at the network layer, howNDN is able to provide a more straightforward and secure solutionto IoT networking as compared to TCP/IP:

• �e Interest-Data exchange model in NDN closely resem-bles the RESTful protocols such as HTTP and CoAP thatare widely adopted in today’s IoT systems.

• Name-based forwarding simpli�es the network stack byremoving the extra step of resolving application names tonetwork identi�ers (e.g., IP and MAC addresses).

• Data-centric security is more e�cient and IoT-friendlythan the channel-based or physical/logical isolation-basedalternatives.

• Ubiquitous in-network data caching helps improve thee�ciency of information dissemination, especially for re-source constrained IoT environments.

In [4] we also described various higher-level protocols built on topof NDN to achieve framework functionalities such as bootstrappingand discovery, trust management, access control, multi-party com-munication, and global integration. �e major di�erences betweenNDN- and IP-based IoT architectures are illustrated in Fig. 2. Werefer readers to [4] for a complete discussion.

IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and Lixia Zhang

IPpackets

v4, v6, 6LoWPAN

Middleware / FrameworksCOAP MQTT HTTP ...

TCP UDP ...

ethernet Zigbee ...

copper radio optical...

CSMA BT 802.15.4 ...

Request-Reponsefor Named Data

copper radio optical...

Strategy

Security, Storage

Name, Data, TrustConventions for IOT

IoT Applications

DataChunks

BT 802.15.4 802.11 UDP...

DTLS TLS ...

IoT Applications ...

Forwarded by host interface address Forwarded directly on names

Secures channels

Secures data

Configured based onL3 and L2 addresses

Configured usingname prefixes

IP-based Approaches Named Data Networking

Figure 2: Protocol stack comparison of NDN and TCP/IP.

Expanding on our previous work, our goal in this paper is todemonstrate the design and implementation of a speci�c IoT systembased on NDN. In particular, we will illustrate how to leveragenaming within the local context to achieve trust management andrendezvous in an IoT network, which further enables a variety oflocal IoT applications and services.

3 CLOUD-INDEPENDENT IOT OVER NDNIn this section, we brie�y review the IoT services commonly sup-ported by remote cloud infrastructure. �en we discuss how thesame functionality can be achieved more e�ciently by leveraginglocal trust management and rendezvous over the NDN architecture.

3.1 IoT and the cloudIoT applications and services o�en require a set of common servicesto be provided by the application-layer frameworks, as shown inFig. 1:

• Identitymanagement, authentication and authorization, mak-ing up the trust management subsystem for users, devicesand services and, in connection-oriented models, accesscontrol;

• Rendezvous and resource discovery, enabling applicationsto �nd the devices and services they need;

• Device management, to handle onboarding, monitoring,con�guration changes, so�ware upgrades, etc. for con-stituent devices;

• Application data messaging, which supports data exchangethrough mechanisms including publish-subscribe (pub-sub), streaming, etc.; and

• Gateways to external networks, bridging a local IoT networkto external services such as data storage and analytics, aswell as the public Internet (including mobile devices) ingeneral.

As we discussed in Section 2.1, most IoT ecosystems today relyon the cloud to implement part or all of those framework services.For example, in AWS IoT, cloud services play several critical rolesthat cover all of the above aspects of an IoT platform. AWS acts as anidentity provider, issuing security credentials for users and devices;it provides authorization services, whereby device certi�cate issuedby AWS contains the resource access policies prescribed by theuser; and it handles device management and rendezvous, where

Router

IoT Network

MobileIoT App

Device

Device

Device

IdentityManager

AuthorizationServer

MobileIoT App

DataStorage

Cloud

Central Hub

DeviceManager Pub-sub

Broker MachineLearning

Figure 3: Typical cloud-centric IoT architecture

all devices in the IoT system register with and report to AWS,which also collects state for all devices and makes it available toapplications. All messages between IoT devices and services aretunneled through the cloud for pub-sub dispatching. AWS can hostapplications that consume the IoT data and trigger actions whencertain events happen. Users can access the IoT network frompublic Internet, the messages are also tunneled through AWS viathe message brokers.

A typical cloud-centric IoT architecture is depicted in Fig. 3.�e cloud provides a convenient “central hub” for managing theinterconnections of all the devices in an IoT system. By transferringthe control to the cloud, a cloud-centric IoT architecture simpli�esthe system con�guration and management tasks for users, butsacri�ces the opportunity of using local communication to achievehigher reliability and e�ciency. It requires local data traverse theglobal network unnecessarily. In “human-in-the-loop” applicationscenarios, control messages from the user’s smartphone are �rstrouted to the cloud for authentication and logging before beingforwarded to the IoT device. �is extra latency may negativelyimpact real-time, interactive applications, such as IoT-augmentedhome entertainment experiences. Furthermore, the exposure oflocal IoT devices and private data to the global network can bea potential security risk, making all users depend on the cloudservice providers to protect their data and enforce access controlproperly. �e connectivity to the remote servers in the cloud canalso be a single point of failure. For example, a user of a home IoTsystems cannot install or re-con�gure devices at home or accesshome network from public Internet if the connectivity from herhome to the cloud is down, or if the cloud service experiences anoutage [1].

3.2 Rethinking IoT Service ArchitectureAmong the IoT framework services shown in Figure 1, two playfoundational roles:

(1) Trust management, which authenticates IoT system en-tities (users, devices, and applications), and authorizes howthey may interact with each other; and

Local Trust Management and Rendezvous in Named Data Networking of Things IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA

(2) Rendezvous, which provides a means for di�erent entitiesto discover and interconnect with each other, over eitherlocal or global networks.

Independent from the lower layer addressing scheme, trust man-agement and rendezvous at the application layer are built on theconcept of named entities. �e application-layer names are ei-ther speci�ed by the users or auto-generated by the devices andapplications. �ose names serve as the entities’ identi�ers in anIoT system and allow those entities to refer to each other and in-teroperate. To enable authentication, the identity names must beassociated with some form of credentials such as user passwordsor public key certi�cates. �erefore application-layer trust policiescan be composed in terms of names meaningful at the applicationlayer, rather than low-level device identi�ers and raw key materials.Named entities also provide the basis for rendezvous: an entitycan discover other entities on the same network by learning theirnames.

Other IoT services can be bootstrapped from these two core ser-vices. As an example, device management is based on discovery (viarendezvous) and mutual trust establishment to enable communica-tion between devices and managing services; resource discoveryis a natural extension of rendezvous, enhanced by the ability toverify a resource’s origin a�er the discovery; pub-sub messagingand external gateways both require the interplay of rendezvous andauthentication functions. Note that those services may be interde-pendent; together they form a framework layer, on top of whichIoT developers can create high-level applications and services.

A major bene�t of hosting IoT services and applications in thecloud is simpli�ed user experience, especially if the system has todeal with the complexity of registering devices with some local con-troller, connecting devices with local and remote applications, andmanaging security credentials – such operations can be too compli-cated for ordinary home users to handle. However, we believe theabove-mentioned complexity is an artifact of existing implemen-tations use of the TCP/IP protocol stack, rather than an intrinsicnature of IoT systems in general. As we illustrate in Sections 4 and 5,the usability problem can indeed be addressed in an NDN-basedimplementation, which directly utilizes human-friendly, hierar-chical naming in supporting rendezvous and trust managementservices. Human-friendly naming enables intuitive understandingof the trust relationship among devices and applications for ordi-nary users, and a hierarchical naming structure provides propercontexts to facilitate applications in expressing and exploring theorganization of the IoT system, further enabling automated trustmanagement and rendezvous tools.

Unfortunately, the TCP/IP protocol stack o�ers IP addresses asthe �rst-order names for devices and services,11 accompanied byper-device or per-service public keys for (D)TLS authentication.Semantically meaningful names, such as URLs, reside at application-layer only, and have to be resolved to addresses or port numberswhen the applications access data or services via the network. Nu-meric names are straightforward for machines to operate on, butcontain no semantic meaning that can be leveraged to make trust

11For example, it is a common practice in cloud computing to assign one or morevirtual IPs (VIPs) to identify cloud services.

decisions, to support rendezvous, or to provide intuitive under-standing for human users and application developers.

�e NDN architecture o�ers an elegant solution to the namingproblem at the network layer. It allows the IoT services to bedescribed locally and in a decentralized way without sacri�cingsecurity, functionality, �exibility, and usability, as described in thenext subsection.

3.3 Achieving Local IoT Functions with NDN�e NDN architecture bootstraps local IoT communication by nam-ing the entities in the context of the local IoT network. Instead ofobtaining their identities from cloud service providers, the entitiesin the IoT network create local identities associated with asymmet-ric cryptographic keys that are certi�ed by a local trust anchor. �eidentity certi�cates are all published as Data packets in the localNDN network under the identity namespace. �e trust anchor istypically a root key created by the owner of the IoT system andstored securely on a local authentication server such as a controlhub or a TPM-equipped smartphone.

Note that a local entity may also have other identities for externalcommunications. For example, a device may have a manufacture-issued identi�er that is used for signing the device status report orretrieving so�ware/�rmware updates; users may also have publicidentities (e.g., OpenIDs) that can be used for initial authenticationwhen new users are added to the system. �e practice of using dif-ferent identi�ers for di�erent purposes is aligned with the principleof least privilege.

A�er the local identities are created, the NDN-IoT architectureleverages two powerful tools to provide the two fundamental ser-vices: using schematized trust [10] for local trust management, anddistributed sync (e.g., [13]) for local rendezvous.

3.3.1 Trust management. IoT system trust policies can be for-mally described using trust schema to specify the relations betweendata names and signing key names using a domain-speci�c lan-guage designed for pa�ern matching on NDN names. �e NDNso�ware platform provides tools that automatically sign and ver-ify the Data packets according to a given trust schema, which arepre-de�ned and can be integrated into the applications throughclient libraries.12 �e trust schema of IoT applications can list thelocal trust anchors and specify the trust relationship between localdata and key names, which can be enforced within the scope of thelocal network without the intervention of cloud services. If needed,the trust schema can also include external trust anchors (e.g., thepublic keys of a trusted cloud provider) according to the applicationrequirements.

3.3.2 Rendezvous. NDN Sync protocols such as ChronoSync [13]allow multiple devices to synchronize the namespace of the shareddataset without relying on central servers. �is mechanism pro-vides a convenient rendezvous solution where the application pre-�xes and device identities are published under a well-known localnamespace and synchronized across multiple devices in the IoT net-work. �e synchronization protocol can bene�t from local multicastcommunication for e�ciency, it may also work in a peer-to-peer

12Trust-schema can also be modi�ed dynamically and redistributed to relevant entitiesin the same way as any other named, signed data.

IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and Lixia Zhang

fashion when multicast is not supported by the constrained de-vices.13 For large-scale IoT systems, multiple sync groups can becreated under separate namespaces to insulate independent subsys-tems.

�rough support for decentralized trust management and ren-dezvous, anNDN-based IoT architecture enables cloud-independencewhile providing essential IoT services. Applications can still bene-�t from cloud services whenever needed, such as archiving data,performing complex data analysis jobs, or accessing advanced ser-vices like search and voice recognition. In fact, NDN simpli�esthe integration with the external networks by using the universalInterest-Data exchange primitive for data communication. Cloudservices become an optional component, rather than a requiredpiece of the architecture.

Automated local trust management and rendezvous should alsoimprove user experience by limiting the only manual step of con-�guration during device setup to a local one–registering the devicewith the local trust anchor, e.g. by scanning the barcode of a newlypurchased device.Once the trust is established and a local certi�cateis generated, the IoT devices and applications can communicatewith each other, exchange useful information, or discover newdevices and applications without human intervention or cloud con-nectivity.

4 FLOW: A HOME ENTERTAINMENTEXPERIENCE OVER NDN

In this section, we describe the design of Flow, a home entertain-ment experience that leverages NDN to realize a cloud-independent,IoT-supported application, and conclude by summarizing the com-ponents of a generalized NDN-IoT framework developed based onthis design. Flow is a prototype of a multi-user “exploration game”,in which participants navigate and interact with a virtual worldrendered in a game engine using a combination of inputs:

(1) Indoor positioning: participants’ positions in physical space,detected by indoor positioning (person tracking), modifythe virtual landscape;

(2) Wearable sensing: participants directly control orientationof the environment’s virtual camera using gyroscopes con-nected to microcontrollers, which can be worn or carried;

(3) Mobile phone interface: participants interact with the vir-tual environment through controls on their smartphone,for example to share social media images in the virtualenvironment.

In addition to various types of IoT devices and the game engine,the system on which Flow is built also includes an authenticationserver (AS) that performs local trust management. �e AS can beimplemented as an app on the owner’s smartphone, or a servicedaemon on a dedicated control hub (e.g., the home router).

Figure 4 shows a typical deployment scenario of Flow in a homenetwork. NDN interconnectivity between di�erent componentsis supported over Ethernet and Wi-Fi, through the home Wi-Firouter in a hub-and-spoke topology. Sensor devices with limitednetworking capability (e.g., the gyroscope in Fig. 4) may be bridged

13See [6] for detailed discussion on the issue with multicast in IoT.

Home Network

HomeRouter

GyroscopeSensor

PersonTracking

Game Engine

BTLEGyroscopeController

Figure 4: Typical deployment of the Flow home entertain-ment experience.

via a helper device. We assume all devices can reach each otherover NDN, which is trivial in a hub-and-spoke topology.14

4.1 Naming and IdentityIn Flow, data from the IoT things used by the application are namedusing three namespaces:

• Application namespace: a local namespace for publishingand accessing application data, e.g., gyroscope readingsneeded to control the environment;

• Device namespace: a local namespace for publishing deviceidentity certi�cates and metadata;15

• Manufacturer namespace: a global namespace created bythe IoT device vendors and for trust bootstrapping.

Fig. 5 shows an example of the Flow namespace. In addition tothese three namespaces which name devices, things and their data,note the discovery branch under the local root pre�x, which is usedfor device rendezvous and for application pre�x discovery. Detailsof its functionality are described later.

�e device and application namespaces both have as their root ahome pre�x that is either context-dependent (e.g., “/AliceHome” asin Fig. 5) or globally reachable (e.g., “/att/ucla/dorm1/301”).

�e application namespace starts with a unique instance name(e.g., “/AliceHome/flow1”) created by the application at installa-tion. Data produced by each component is named under an appli-cation label con�gured by the developer (e.g. “/AliceHome/flow1/tracking1”). �e application label also contains a metadata sub-tree containing the device name that serves this data (e.g. “/AliceHome/flow1/tracking1/_meta/_device”).

Devices publish their local identity certi�cates under the devicenamespace (e.g., “/AliceHome/devices”). �ey also publish meta-data (pro�le) information in the “_meta/_app” branch under thedevice identity pre�x, including, for example, the application data

14A routing protocol may be required if a sensor mesh topology is deployed inside thehome network.15Device metadata could include information about devices and their capabilities aswell as bindings to application names.

Local Trust Management and Rendezvous in Named Data Networking of Things IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA

/AliceHome Home prefix

devices flow1 App instance name

gyro1 tracking1Application label

data

rfduinos/123

_meta _meta

_app _device seq#

run_id

tracks track_hint

track#

seq#

timestamp

ID-CERT

authenticationserver

/com/RF-digital/

RFduino

Manufacturer prefix

visualization1

schemas

Manufacturer namespace Device namespace Application namespace

SN12345 updates

software firmware

version# version#

discovery

apps devices

digest# digest#

flow1

version#

Figure 5: Example namespace within the home environment where Flow is deployed.

pre�xes they use to publish. �e device namespace of an authen-tication server also contains the trust schema of currently activeapplications. Schema and trust relationship details are describedlater in this section.

�emanufacturer namespace falls under vendor-speci�c pre�xesthat are independent from the home network’s local pre�x. We en-vision that manufacturers will have globally unique names for theirproducts used during bootstrapping, over-the-air updates, and sim-ilar processes. Manufacturers publish their own certi�cates underthis globally unique pre�x so that the devices can authenticate thedata coming from the vendors such as so�ware/�rmware updatesand service noti�cations.16 In the research prototype of Flow, alldevices are con�gured with vendor-provided identity names andpro�les in their initial provisioning, before being connected to thehome network. �ese are used for device onboarding.

4.2 Trust ManagementFlow demonstrates a multi-step process for trusting new devicesin a home IoT network and enabling their data to be used in anapplication. First, a device is assigned a device-level name and addedto the trust hierarchy for things in the home. �en, it is con�guredwith one or more application-level names for its data, and thesenames are added to application trust hierarchies. Finally, the deviceis con�gured to respond to requests in application namespaces.

�e authentication server acts as the trust anchor. It can becoordinated with but does not depend on a remote cloud services.While the devices and users may have public identities outside thehome environment, they all need to obtain local identities that arecerti�ed by the authentication server (AS) before they can startinteracting with other local entities.17

�e process of establishing a trust relationship between a newdevice and the home through the AS is similar to the Bluetooth

16Reachability of data in this pre�x is not addressed here but can be accomplishedthrough encapsulation supported by the home router, for example.17�e public identities may be used to assist the onboarding process, but will notbe required for local communication once the initial con�guration has �nished. Forexample, a new user can authenticate with the AS using her public identity (e.g.,OpenID or Google/Facebook account) before creating her local identity that is usedsolely by the home environment.

Device AS

Interest: /[device-prefix]/cmd/add/[ts]

Data: content={“status”: “200”}Interest: /[as-prefix]/cert_req/{key name, key bits}

Enter shared secret

Data: content={signed certificate}

Interest: /[as-prefix]/ID-CERT/[ts]

Cert request

Data: content={gateway certificate}

Verify ID-Cert

Generate ID-Cert

Fetch AS Cert

Figure 6: Bootstrap trust relationship for new device.

pairing process. To bootstrap a new device, the user—or a con�gura-tion application on her behalf—provides a shared secret and a localdevice name. �e shared secret may be a device barcode, identitycommunicated by NFC, or simply a PIN number. �e AS sends acommand Interest to the device, signed using a key derived fromthe shared secret, to ask that it generate a public/private key pairassociated with the device’s new name on the local network. �edevice replies with a Data packet containing an identity certi�caterequest, also signed by the shared secret. �e AS generates theidentity certi�cate based on this request. �e device, now part ofthe trust hierarchy, can advertise its services or participate in anapplication over the local network. �is process is illustrated inFig. 6. If the device has been issued a public identity certi�cate byits vendor, the AS may optionally authenticate its public identity,e.g., by asking the device to sign an AS-generated challenge.

Applications in Flow are “installed” in a similar way to devices,with the AS signing both identity certi�cates and trust schemafor the application. �e application’s trust schema expresses whatdevice identities are authorized to publish under what applicationpre�xes and is published as a normal Data object on the local NDNnetwork. For example, in Fig. 5 “flow1” is a speci�c Flow instanceand “schema” branch contains the trust schema of this instance. �eschema name includes a monotonic version number at the end, sowhen there is a change in the schema a newer version is published.

IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and Lixia Zhang

Producer AS

Interest: /[as_prefix]/requests/{app_prefix, app_name, cert_name}

Data: content={“status”: “200”}

Consumer

Interest: /[as_prefix]/[app_name]/schema/exclude=[last_received_ts]

Data: content={trust_schema_string}

/AliceHome/devices/as1/

/AliceHome/devices/raspberry_pi/234

/AliceHome/flow1/gyro1/data/#seq

signs

signs

AS identity (trust anchor)

Device identity in “/AliceHome”

Application data produced by that device

Producer authorization &Consumer trust schema update

Trust relationship example

Figure 7: Schematized trust between producers and con-sumers.

�e technical details of how to specify a trust schema are describedin [10].

When a device that produces data is installed, it sends a commandInterest to the AS that includes the application pre�x it intends topublish under and its own local identity. If the request to publishdata in the home network is granted, the AS will update the trustschema with the authentication rules for data published by thisdevice. �e rule binds a device identity with the application pre-�xes it’s authorized to publish under.18 Schematized trust enables�ne-grained control over what devices can publish what data forwhich application instances. Consumer devices fetch the latesttrust schema over the network via NDN and follow the rules toauthenticate the data packets published in the network. �e pro-ducer authorization process, as well as an example of the resultingtrust relationship, is shown in Fig. 7, in which the AS signs a deviceidentity, and the device signs a piece of application data it publishes.

4.3 RendezvousFlow also demonstrates a name-based, distributed rendezvousmech-anism for devices and applications to discover each other overNDN. As described in the previous section, the key idea is tosynchronize the set of device and application names (called therendezvous dataset) across the devices in the network that areinterested in learning about them. �e synchronization processutilizes the decentralized and serverless ChronoSync [13] proto-col to e�ectively synchronize pre�xes of active devices and appli-cations under “/AliceHome/discovery/devices” and “/AliceHome/discovery/apps” sub-namespaces, respectively.

When a new device is installed in the Flow system, it joinsboth the “devices” and “apps” sync groups and announces its localidentity and application pre�xes in the rendezvous dataset, whichis propagated via ChronoSync across the network. Applicationsrunning on each device look up the local copy of the rendezvousdataset directly using a common API. Once an application obtains18�is binding addresses potential collision in application labels–for example, bydefault the AS does not authorize a second device to publish under an applicationnamespace claimed by another.

the name pre�x of the target device or application, it can followthe namespace structure described in 4.1 to construct Interestsfor fetching the certi�cates and metadata, enabling it to bootstraphigh-level service communication.

4.4 Generalizing IoT functionality in NDN�rough the design of Flow, we explored how to use NDN to providethe functionality discussed in Section 3.1 without reliance on anycloud services, and generalized it in a framework called NDN-IoT,which provides the following features besides trust managementand rendezvous services:

• Device management: In addition to device onboarding andbootstrapping, NDN-IoT also supports device monitoringby publishing device status (e.g., power level, CPU/memoryusage, so�ware/�rmware versions, etc.) periodically. �einformation can be visualized by a user-friendly dashboardapplication running on the user’s smartphone or computerwhich sends out Interests to fetch the status of interesteddevices either periodically or on demand.

• Pub-sub messaging: �e pub-sub messaging protocol inNDN-IoT currently supports two types of application datanaming schemes. If the publisher names the data using con-tinuous sequence numbers (e.g. “/AliceHome/flow1/gyro1/data/[0,1,2,...]”), the subscribers pipeline their Inter-ests, following a built-in congestion control algorithm, tofetch the data using full names that include the trailing se-quence numbers. If the data name contains timestamp (e.g.“/AliceHome/devices/pc1/_status/20170104T1130”) thatcannot be predicted, the subscribers issue Interests usingthe pre�xes of the data (excluding the timestamp compo-nent) periodically or immediately a�er the previous datais received, in order to keep outstanding PIT entries inthe network. Some of the authors are involved in an on-going research project that investigates the use of syncprotocols for implementing pub-sub semantics in IoT envi-ronment [7].

• Gateways to external network and services: �e local IoTsystem can request data from the public Internet usingglobally reachable names. Meanwhile, its local data canbe made available to the public Internet by publishing un-der a globally reachable name pre�x directly or having agateway service that generates data named under a glob-ally reachable pre�x to encapsulate data from the localsystem (e.g. “/att/ucla/dorm1/301/flow1/gyro1/data/1”→ “/AliceHome/flow1/gyro1/data/1”).

• Access control: NDN-IoT provides access control capabil-ity using the Name-based Access Control framework [11],which encrypts the content of the data and passes thedecryption key to authorized consumers only (encryptedseparately with each consumer’s public key). �e detailedspeci�cation of the access control protocol for NDN-IoT iscurrently under development.

5 IMPLEMENTATIONWe have implemented the NDN-IoT framework and a prototypeof the Flow entertainment system to verify the design introduced

Local Trust Management and Rendezvous in Named Data Networking of Things IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA

in the previous section. �e implementation follows a modularstructure and di�erentiates between the framework-level servicesthat we believe are common to many home IoT systems and thefunctionality that supports Flow-speci�c application logic. �eNDN-IoT framework is implemented as a set of libraries usingJavaScript, Python, C# and C++. It is built on top of the NDNCommon Client Libraries [8], providing further abstractions tofacilitate application development in a home IoT environment.

In our prototype, each of the Flow application components isimplemented as the following:

(1) Indoor positioning: We use OpenPTrack19, a multi-cameraperson tracking system. �eNDNproducer for OpenPTrack20(wri�en in C++) publishes the position of each person ata 30Hz rate, along with lower rate metadata about activetracks.

(2) Wearable sensing: We use an RFduino 22301 with gyro-scope MPU6050 a�ached to provide virtual camera control.�e RFduino cannot perform asynchronous signing oper-ations quickly enough, so we introduced a Raspberry Picontroller as a gateway for bridging RFduino to the NDNhome network. �e data exchanged between RFduino andRaspberry Pi is signed with a shared secret key negoti-ated a�er Bluetooth pairing. �e Raspberry Pi generatesa public/private key pair on behalf of the RFduino to beassociated with the RFduino’s device identity. �e RFduinoruns a minimum NDN producer, implemented with thendn-cpp-lite library21, which generates data at roughly2Hz rate. When new data is generated, the RFduino pushesthe data (signed by the pre-negotiated shared secret) tothe Raspberry Pi controller over the Bluetooth LE channel.�e controller receives the data, repackages the data andsigns the data using RFduino’s private key, and then pub-lishes the data on the home network. �e RFduino datapublishing process is shown in Fig. 8.

(3) Mobile phone interface: We employ an Android phone thatloads a control webpage (wri�en in NDN.JS [5]) in a mo-bile browser to interact with the virtual environment. �ephone sends out two types of command Interests: the �rstone matches an OpenPTrack track ID with that of themobile, and the second one drops an image onto the vir-tual environment where the user’s avatar is standing. IDmatching is introduced so that the visualization knows thelocation of the user’s avatar (identi�ed by a track ID) whenan image drop command Interest is issued by the sameuser (identi�ed by the mobile’s ID).

(4) Visualization: We use the Unity3D22 game engine for visu-alization. �e game engine runs C# NDN data consumersthat receive person tracking and virtual camera controldata, and a producer that receives image dropping com-mand Interests from the mobile Web interface.

�e implementations for both NDN-IoT framework and Flowapplication are available online23. We installed two instances of

19h�p://openptrack.org/about/20h�ps://github.com/OpenPTrack/ndn-opt/21h�ps://github.com/named-data/ndn-cpp/22h�ps://unity3d.com23h�ps://github.com/remap/ndn-�ow

RFduino Pi AS

BTLE paring &shared secret negotiation

Report device identity andsymmetric key K

(signed with shared secret) Generate public/private key pair for RFduino

Push data (signed by K)

Repackage data and sign with RFduino private key

Bluetooth LE NDN over Wi-Fi

Register RFduinoproducer with AS

Figure 8: RFduino data publishing with assistance of Rasp-berry Pi controller

the Flow application testbed at UCLA and Huawei. Fig. 9 shows adiagram of the system and its message �ows a�er all devices arebootstrapped with an authentication server, which in our installa-tion is running on another Raspberry Pi device.

6 EVALUATIONIn this section, we qualitatively compare Flow and the NDN-IoTframework with conceptual implementations of a similar gamingsystem over AWS IoT and Apple HomeKit (using TCP/IP architec-ture). �e goal of this side-by-side comparison is to highlight thedi�erences between the proposed architecture and the current prac-tice in the industry, and to articulate how the cloud-independentIoT system can bene�t from the NDN architecture. Fig. 10 showsthree di�erent designs of home entertainment system over AWSIoT, Apple HomeKit, and NDN-IoT, respectively.

As shown in Fig. 10a, all the local devices must be certi�ed bythe AWS IoT Registry service in order to join the IoT system. Ap-plication data generated by the person tracking device and theuser smartphone go through the pub-sub message brokers (e.g., viaMQTT) in the cloud, which then routes the messages to the gameengine back in the local network, or other AWS services in thecloud according to user-de�ned rules. �ere is a signi�cant amountof work performed by the AWS infrastructure to map user-de�neddevice names to the endpoints of the underlying TLS tunnels, main-tain state about device con�guration and latest status, present aconsistent view of the local IoT network to all applications and ser-vices both locally and in the cloud, manage the pub-sub relationshipbetween data producers and consumers, and enforce authenticationand access control policies during message forwarding.

Being the least cloud-dependent among the existing IoT ecosys-tems, HomeKit limits an application like Flow’s dependency on thecloud to two key services only: authenticating devices and usersduring the bootstrap phase, and synchronizing the home con�gu-ration database across multiple devices. �e game engine devicein Fig. 10b can look up its local copy of that database to discoverthe person tracking device and gyroscope sensor in the same localnetwork. �ere is a separate auto-con�guration process based onmDNS to discover network addresses and set up secured connec-tions among devices over local Wi-Fi or Ethernet. Although its

IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA Wentao Shang, Zhehao Wang, Alexander Afanasyev, Je� Burke, and Lixia Zhang

1A. Unity asks for a “track_hint”

1B. names when asking for a track location

Indoor Positioning: OpenPTrackApplication prefix: /AliceHome/flow1/tracking1Device name: /AliceHome/devices/ubuntu/123

Bridging RFduino: RaspPi2 (ble central)Application prefix: /AliceHome/flow1/gyros/gyro1

Device prefix: /AliceHome/devices/rpi2/456

Wearable sensing: RFduino/Gyro(ble peripheral)

Visualization: Unity3DApplication prefix: /AliceHome/flow1/visualization1/

Device name: /AliceHome/devices/osx/234

Mobile Phone Interface: Android web browserDevice name: /AliceHome/devices/phone/345

2A. Mobile phone sends command interest and initiates "track matching" of phone's

ID to Track ID provided by OPT

2B. command interest to control the dropping of images in Unity

Packetized NDN data with HMAC signature

3A. Unity asks for gyroscope data, produced by RaspberryPi helper on behalf of RFduinos connected via Bluetooth LE

Application prefix:

Figure 9: Application components and message �ows in Flow

HomeRouter

PersonTracking

Home Network

AWS IoT

Secu

red

Conn

ectio

n

Authentication& Authorization

AWS S3/DynamoDBDevice

Gateway

AWS Lambda

MessageBroker

RuleEngine

Game Engine

Publish Publish

Subscibe

DeviceRegistry

(a) A conceptual implementation over AWS IoT

HomeRouter

PersonTracking

HomeKit-enabled Home Network

Apple iCloud

Secu

red

Conn

ectio

n

Identity &Authentication

Home ConfigDatabase

Home D

ataba

se S

ync

Data

Data

(b) A conceptual implementation over HomeKit

Home Network

HomeRouter

PersonTracking

GyroscopeSensor

Game Engine

GyroscopeController

Sync/Pub-Sub/NDN

Sync/P

ub-S

ub/N

DN

Sync/Pub-Sub/NDN

Sync

/Pub

-Sub

/NDN

CloudService

Internet

NDN

AuthenticationServer

BTLE

NDN

RemotePeer

NDN

(c) �e actual implementation over NDN-IoT

Figure 10: Comparison of IoT-enabled home entertainment systems over three di�erent ecosystems.

reliance on cloud services is signi�cantly reduced as compared tothe AWS-based system, the HomeKit-based implementation stillsu�ers from usability problem when the home network is discon-nected. Without cloud connectivity, the user would not be ableto add new devices or invite new users. Further, con�gurationchanges made to the existing devices would not be synchronized to

other local devices, leading to an inconsistent view of the systemamong IoT applications and services.

Compared to the two cloud-based systems, the Flow applicationand NDN-IoT framework depicted in Fig. 10c show the followingadvantages:

Local Trust Management and Rendezvous in Named Data Networking of Things IoTDI 2017, April 18-21, 2017, Pi�sburgh, PA, USA

• Users can add or remove IoT devices (e.g., upgrading toa new game control stick) at any time without requiringconnectivity to the public Internet.

• New devices are discoverable by existing applications andservices as soon as it obtains certi�cation for its local iden-tity and starts advertising itself in the local “discovery”sync group.

• Messages exchanged between the game controller and thegame engine are forwarded over the local network (typ-ically relayed through the home Wi-Fi access point) andexperience minimum delay, improving real-time gamingexperience.

• In the case of online gaming, the data generated by remoteplayers is retrieved in the same way as the local data isconsumed. �e Interest-Data exchange between players indi�erent geo-locations can be forwarded along the short-est path through the Internet between the players’ homenetworks, without relaying through the cloud service.

• Like all other NDN applications, the Flow game systemsecures the data itself at production, which gives the appli-cations full control over how their data is protected, ratherthan depending on remote services in the cloud to executetheir security policies correctly.

7 CONCLUSION AND FUTUREWORK�e Internet-of-�ings bring a revolution to local communicationsas much as in global communication. However the intrinsic lim-itations in the address-based TCP/IP architecture, and its lack ofsecurity support in particular, make cloud-based IoT implementa-tions a “path of least resistance”. As IoT becomes an essential partof our everyday life, the implications of its cloud-dependency mustbe addressed. As we were �nalizing this paper, a benign operationalerror brought down Amazon cloud service [1] and impacted a largenumber of IoT services as well as other applications. �is incidentreminds us that cloud services are not immune to failures, furtherunderscoring the value of this work. Robust solutions are also likelyto expand the market to the long tail of dwellings (from houseboatsto motorhomes), and to “the next billion” in the emerging marketswith challenging communications conditions, where the cloud maybe accessible but not always reliable.

It is with these opportunities in mind that we have developed thecloud-independent design described in this paper. We have shown aspeci�c design for the two fundamental functions in IoT, trust man-agement and rendezvous, in a way that is independent from, but canreadily incorporate, cloud-based services. As a proof of evidence,we have implemented a running home entertainment application.We built our solution on top of Named Data Networking archi-tecture, assuring resiliency of local “smart” IoT features in face ofexternal failures. At the heart of the design are application-de�ned

hierarchically named and secured data packets exchanged at thenetworking level, from which trust management and rendezvouscan be built.

Signi�cant challenges remain for the IoT and NDN research com-munities, many of which have been mentioned earlier. For example,designs for easy-to-use, encryption-based access control in net-works with heterogeneous computational capabilities of individualdevices remain to be developed, as do designs for global accessto the manufacturer namespaces in our examples. Application de-velopment paradigms for Named Data Networking of �ings, andNDN applications in general, largely remain as an open area offuture research.

ACKNOWLEDGMENTS�is work is partially supported by the National Science Foundationunder award CNS-1345318 and CNS-1455850, and by FutureweiTechnologies.

REFERENCES[1] Amazon Web Services. 2017. Summary of the Amazon S3 Service Disruption in

the Northern Virginia (US-EAST-1) Region. h�ps://aws.amazon.com/message/41926/. (March 2017).

[2] Bluetooth Special Interest Group (SIG). 2014. Bluetooth Speci�cation Version4.2. (Dec 2014). Available at h�ps://www.bluetooth.com.

[3] Van Jacobson, Diana K. Sme�ers, James D.�ornton, Michael F. Plass, Nicholas H.Briggs, and Rebecca L. Braynard. 2009. Networking Named Content. In Proceed-ings of the 5th ACM International Conference on Emerging Networking Experimentsand Technologies (CoNEXT). 1–12.

[4] W. Shang, A. Bannis, T. Liang, Z. Wang, Y. Yu, A. Afanasyev, J. �ompson, J.Burke, B. Zhang, and L. Zhang. 2016. Named Data Networking of �ings (InvitedPaper). In Proceedings of the 1st IEEE International Conference on Internet-of-�ingsDesign and Implementation (IoTDI). 117–128.

[5] Wentao Shang, J. �ompson, M. Cherkaoui, J. Burkey, and Lixia Zhang. 2013.NDN.JS: A JavaScript client library for Named Data Networking. In Proceedingsof IEEE INFOCOMM 2013 NOMEN Workshop. 399–404.

[6] Wentao Shang, Yingdi Yu, Ralph Droms, and Lixia Zhang. 2016. Challenges in IoTNetworking via TCP/IP Architecture. Technical Report NDN-0038. NDN Project.

[7] Wentao Shang, Minsheng Zhang, Alexander Afanasyev, Je� Burke, Lan Wang,and Lixia Zhang. 2017. Publish-Subscribe Communication in Building Manage-ment Systems over Named Data Networking. (2017). Manuscript submi�ed toACM TCPS Special Issue on Internet of �ings.

[8] Je� �ompson and Je� Burke. 2014. NDN Common Client Libraries. TechnicalReport NDN-0024, Revision 1. NDN Project.

[9] �read Group. 2015. �read Stack Fundamentals. White Paper. (July 2015).Available at h�p://threadgroup.org/.

[10] Yingdi Yu, Alexander Afanasyev, David Clark, kc cla�y, Van Jacobson, and LixiaZhang. 2015. Schematizing Trust in Named Data Networking. In Proceedings ofthe 2nd ACM International Conference on Information-Centric Networking (ICN).177–186.

[11] Yingdi Yu, Alexander Afanasyev, and Lixia Zhang. 2016. Name-Based AccessControl. Technical Report NDN-0034, Revision 2. NDN Project.

[12] Lixia Zhang, Alexander Afanasyev, Je�rey Burke, Van Jacobson, kc cla�y, PatrickCrowley, Christos Papadopoulos, Lan Wang, and Beichuan Zhang. 2014. NamedData Networking. ACM SIGCOMM Computer Communication Review (CCR) 44,3 (July 2014), 66–73.

[13] Zhenkai Zhu and A. Afanasyev. 2013. Let’s ChronoSync: Decentralized DatasetState Synchronization in Named Data Networking. In Proceedings of the 21st IEEEInternational Conference on Network Protocols (ICNP). 1–10.

[14] ZigBee Alliance. 2012. ZigBee Speci�cation. ZigBee Document 053474r20.(September 2012). Available at h�p://www.zigbee.org.