Publish-Subscribe Communication in BuildingManagement Systems over Named Data Networking

Wentao Shang∗, Ashlesh Gawande†, Minsheng Zhang†, Alexander Afanasyev‡,Jeffrey Burke∗, Lan Wang† and Lixia Zhang∗

∗UCLA{wentao,lixia}@cs.ucla.edu, jburke@remap.ucla.edu

†University of Memphis{agawande,mzhang4,lanwang}@memphis.edu

‡Florida International Universityaa@cs.fiu.edu

Abstract—Publish-subscribe (pub-sub) has been recognized asa common communication pattern in IoT applications. In thispaper we present ndnBMS-PS, a distributed pub-sub communi-cation framework for building management systems (BMS), animportant area of IoT, over the Named Data Networking (NDN)architecture. ndnBMS-PS utilizes distributed NDN repositoriesto store and republish large quantities of BMS data that can beconsumed by different applications. It employs a data synchro-nization mechanism to aggregate multiple data streams publishedby multiple sensing devices and achieve efficient notificationof new data for the consumers. ndnBMS-PS also providesdata authentication by utilizing NDN’s security building blocks.This design exercise demonstrates that the information-centricarchitecture enables a simple design for complex IoT systems andprovides superior system efficiency and security over TCP/IP-based alternatives.

I. INTRODUCTION

Enterprise Building Automation and Management System(EBAMS, or BMS for short) is a key IoT application used byenterprises to monitor building environment and lower costs. Atypical BMS deployment may spread across multiple buildingson an enterprise campus, potentially with tens of thousandsof sensors installed on the premises to monitor electricity,lighting, temperature, humidity, and many other environmentalmeasurements. Recent years have witnessed an extensive effortby both industry and research communities to adapt or enhancethe current TCP/IP architecture to support BMS, yet manychallenges remain. For example, sensing devices may haveintermittent connectivity and use duty cycles to save energy,while IP communication assumes a devices being “always on”model, and the associated channel-based security requires thetwo communicating end points be online at the same time.Moreover, it is tedious and error-prone to manually set up andmanage IP-based BMS systems as IP addresses do not reflectthe relationship among the entities in the system, includingthe sensing devices, sensor data, environment being sensed,operators, and other users.

We believe that the above challenges intrinsically come fromthe incongruity between TCP/IP’s basic communication andsecurity model and the functional requirements of IoT appli-cations [1]. In contrast, several built-in architectural features in

Named Data Networks (NDN), including expressive naming,data-centric security, and in-network caching, can be utilizedto directly address the identified challenges and enable one tobuild scalable and secure IoT applications [2], [3] over NDN.

For a proof of concept, we have designed a publish-subscribe communication framework called ndnBMS-PS forBMS environments over the NDN architecture [4]–[6]. Wehave implemented ndnBMS-PS on the NDN platform [7]and evaluated it using our emulation tool Mini-NDN. Thiswork serves as a case study to illustrate i) the use of NDNarchitectural features to develop a specific IoT application,and ii) the unique application design patterns that arise froma data-centric communication model.

The core functionality of a building management system isthe production and consumption of sensing data. As such, amajor design challenge is how to enable individual applica-tions to retrieve sensing data of their interest in real time. Notethat (1) the number of sensors and consumers can potentiallybe very large; (2) each data-consuming application may beinterested in a different subset of the sensing data; and (3)sensors and consumers may not be online at the same time.To address these data communication challenges, ndnBMS-PSleverages distributed NDN data repositories (repos in short) asintermediaries to decouple data production and consumption,and incorporates an efficient pub-sub mechanism (built ontop of NDN’s request-response primitives) for consumersto subscribe to arbitrary data sets of interest (Section III).Through this design exercise we also demonstrate the utility ofNDN Sync protocols (Section II) in facilitating distributed dataproduction and subscription in a data-centric communicationmodel.

Security is critical for building management systems.ndnBMS-PS ensures data authenticity using a hierarchicaltrust model to verify the signature in each piece of receiveddata (Section III-E). The authentication policy is encoded ina trust schema that leverages the expressive power of datanaming [8]. This data-centric security model differs fromTCP/IP’s channel-based security model in a fundamental way:it ensures that the security protection stays with the data itself,without dependency on the secure channels (e.g., a TLS/DTLS

1

session) between communicating entities.In the remainder of this paper, we first give some back-

ground on this work (Section II), and then present our systemdesign (Section III) and evaluation (Section IV). We alsoreview the literature of pub-sub systems proposed for otherICN architectures (Section V). Finally we conclude the paperand address future work in Section VI.

II. BACKGROUND

A. Data Acquisition and Access in BMS

In a typical BMS deployment, sensors are often hardwiredto smart panels or controllers that are connected to a com-mon high-speed backbone network, usually physically and/orlogically isolated from other internal and external networks.Future BMS may also incorporate wireless sensors that areassociated with a wired aggregator, or even connect low-cost,wireless sensors directly to the network.

In such systems, different types of sensors continuouslygenerate a large amount of measurements such as roomtemperature, power consumption, and chilled water flow. Dueto limited storage and processing capability on typical panelsand controllers, those measurement data have historically beencollected into dedicated storage at the enterprise level andarchived for certain period of time (typically one or two years)in order to serve different data analytics applications.

Enterprise level BMS requires advanced data access sup-port to meet various application requirements including thefollowing:

• Different consumers may be interested in different sens-ing data. Requiring direct communication between eachsensor - consumer pair would not scale well.

• Consumer applications may run on diverse platformsranging from high-end servers, smartphones, to embeddedsystems. These applications consume the sensor data atdifferent times and speeds and may not always be onlinewhen new data is produced.

• Different applications may have different semantics indata consumption. For example, some applications maybe interested only in the latest data generated in real time,while others would want to periodically receive a fewrandom samples from a batch of collected data.

B. NDN and BMS

NDN is a new Internet architecture that provides data-centric communication at the network layer. NDN implementsan asynchronous request-response communication pattern thatnaturally decouples data producers and consumers. It definestwo types of network layer packets: Interest and Data. Eachdata producer assigns a unique and semantically meaningfulname to every Data packet it generates. Each consumer issuesan Interest packet with a data name or name prefix, whichis forwarded based on the name (prefix). For each receivedInterest, NDN forwarders use forwarding strategies [9] todecide where to forward the Interest by taking into accountthe usage policies, the forwarding table, and the measurementfrom previous forwarding decisions. When an Interest meets a

Data packet with a matching name, the Data packet is returnedto the consumer.

Every Data packet carries a cryptographic signature, se-curely binding the content to the name, which ensures integrityand provenance of the data. As such, NDN Data packetscan be retrieved from either original data producers, manageddata storages (repos), or opportunistic caches, enabling asyn-chronous data production/consumption and significantly im-proving the overall scalability and efficiency in data delivery.NDN data is also immutable: any change to a piece of existingdata produces a new version of the data with a different name.

NDN brings several important benefits to the design andimplementation of BMS. First, NDN forwards Interest andData packets using the application-layer names, which elimi-nates the need to configure BMS networks with IP addresses,a significant simplification when a BMS system is madeof a large number of sensors, actuators, and controllers.Second, NDN’s data-centric security mechanism inherentlysecures every produced piece of data, instead of relying onphysical/logical isolation and communication channel security.Finally, the in-network storage including forwarder caches andrepos reduces the query load on sensors and improves thescalability of the BMS data communication.

Our previous work on NDN-BMS [10] designed a BMS dataacquisition system over NDN and demonstrated the design ofthe data namespace, collection of the data from off-the-shelfdevices into NDN repositories (repos), and data security viapacket signatures and encryption-based access control. How-ever, NDN-BMS does not support publish-subscribe communi-cation model to enable efficient and timely delivery of newlypublished data to consumers who subscribe to multiple butdifferent subset of sensing data simultaneously. In comparison,ndnBMS-PS develops a generic pub-sub communication sup-port as a data transport service on top of the data acquisitionsystem to facilitate heterogeneous consumer applications inaccessing sensing data.

C. Data Synchronization in NDN

Data synchronization (Sync) is an important building blockfor distributed applications. While distributed applications maydiffer in their specific goals and communication patterns,they share a common need for synchronizing the applicationdatasets among multiple parties. Since distributed applicationsare a generalization of 2-party communications, one may viewSync as a generalization of end-to-end reliable data deliveryamong multiple parties.

NDN is particularly suited in supporting multi-party com-munication synchronizations. Since communication in NDNis based on fetching named data, and there is a unique andsecured binding between a name and its content, thereforeNDN Sync protocols can simply focus on the synchronizationof the dataset names. Once all the entities in the sameapplication obtain an identical set of data names, then they canindividually decide on when to fetch which data published byothers.

2

NDN Sync protocols bridge the gap between NDN networklayer’s datagram Interest-Data exchange primitive and theapplication layer’s need for data sharing among multipleparticipants, in a way remotely analogous to the role ofTCP which bridges the gap between IP’s datagram serviceand applications’ need for reliable delivery in today’s In-ternet. However, Sync differs from the existing end-to-endreliable transport protocols, such as TCP, in three fundamentalways. First, Sync synchronizes application-named datasetsamong multiple parties, while a TCP connection delivers bytestreams identified by its two endpoints. Second, nodes runningSync can fetch data by names from anywhere the matchingdata items are found, since the security is attached to thedata instead of data container or communication channel.Third, Sync does not require all communicating parties tobe interconnected at the same time, while a TCP connectiondelivers byte streams between two communicating endpointssynchronously (i.e. both must be online at the same time).The ability to reconcile dataset differences asynchronously isespecially useful in constrained environments with sleepingnodes and intermittent connectivity.

Several Sync protocols have been proposed for the NDNarchitecture [11], including ChronoSync [12], iSync [13] andPSync [14]. In ChronoSync, producers in a Sync grouppublish data that are identified by each producer’s name anda monotonically increasing sequence number.1 The state ofthe dataset is concisely represented as a list of key-valuepairs that maps each producer’s name to its latest sequencenumber. The ChronoSync protocol disseminates the digest ofthis list via multicast so that everyone in the Sync group candetect any inconsistency of its local state and retrieve newlyproduced data accordingly. iSync uses Invertible Bloom Filter(IBF) [15] to represent a set of arbitrary names by storing thehash values of the data names in the IBF. Each producer iniSync periodically advertises the digest of its IBF. Whoeverhas a different digest can fetch the IBF from the producer,extract new hash values using IBF subtraction, and requestthe actual data names corresponding to those hashes from theproducer.

PSync has a unique feature of allowing consumers tosynchronize with producers on specific subset of the datanamespace, which is particularly suited for ndnBMS-PS. Sim-ilar to ChronoSync, PSync assumes data names from each datastream contain a name prefix and a monotonically increasingsequence number. Different from ChronoSync, PSync usesan IBF to encode the set of the latest data name from allstreams, this use of IBF allows PSync to extract differencesbetween two participants more efficiently than ChronoSync.The consumers can subscribe to any subset of the data streamsand receive the latest data generated in those streams. Eachconsumer maintains both its own list of subscribed data streamprefixes (called subscription list), which is efficiently encoded

1This does not reduce the generality of the protocol since the applicationscan encapsulate the data objects named under different naming conventionsin the sequentially named data packets.

1. Sync Interest: name = /<routable-prefix>/psync/<sub-list>/<old-IBF>

2. Data: name = /<routable-prefix>/psync/<sub-list>/<old-IBF>/<new-IBF>content = <updated data name>

3. Interest to fetch update:name = <updated data name>

4. Data: name = <updated data name>content = <updated data>

…

Consumer Producer

Fig. 1: PSync message exchanges between consumer and pro-ducer (<sub-list> is the consumer’s subscription list encodedin Bloom filter, while <old-IBF> and <new-IBF> are theproducer’s previous and current dataset state encoded in IBF)

by a Bloom filter, and the latest IBF it has received fromproducers.

Figure 1 illustrates the PSync message exchanges betweena consumer and a producer. The producer encodes the latestdata names from all its data streams in an IBF, which isupdated upon all new data production. When the producerreceives a PSync Interest from a consumer which containsboth the subscription list and the consumer’s IBF, it can filterout the changes relevant to the consumer, and send backthe corresponding IBF. Because PSync includes consumers’subscription information and producer’s dataset state explicitlyin the Interest/Data exchange, it minimizes the soft-stateinformation kept by the producer.

In addition to the pub-sub functionality, PSync can alsobe used to support full synchronization among a group ofparticipants. Therefore, if one sets up multiple data repositories(repos) to collect sensing data, the repos can run PSynsto synchronize their dataset, so that consumers can retrieveupdates from any of the repos that host the same sensordataset, enabling a multi-repo pub-sub framework in ndnBMS-PS.

III. SYSTEM DESIGN

ndnBMS-PS is a pub-sub communication framework de-signed to support data access over NDN in a typical enterpriseBMS. In this section, we present our design assumptions, goalsand detailed design.

A. Design Assumptions and Goals

We make the following design assumptions based on theBMS data access requirements stated in Section II-A.

First, we assume that the BMS sensors are hardwired tosome smart panel or controller that speaks the NDN protocolon the enterprise network. The panels gather the readings fromthe sensors and package them into NDN Data packets.

Second, since the panels usually have limited storage, theyneed to transfer data to a long-term storage device, i.e.,

3

NDN repo [16], for data archiving and access. The reposare the core components in ndnBMS-PS that coordinate thecommunication between sensors and applications. We expectthe repos to run on servers with enough storage to host thedata generated by the sensors they are serving. The repos areconnected to the enterprise network via NDN and stay onlineto process pub-sub requests. They typically have no constrainton computation capability or energy budget.

Third, the consumers in the BMS include data acquisitionapplications running on servers, laptops, and smartphones, aswell as controller logics on the smart panels that monitor thedata created by other panels. Mobile consumers on laptopsand smartphones may have intermittent network connectivity(e.g., when the user closes the laptop or put the smartphoneapp into background) and thus do not always stay online. Theymay also experience other types of constraints such as low-power CPU and limited storage.

The ndnBMS-PS design aims to achieve the followinggoals:

• Scalability: the framework should support a large numberof sensing data streams and consumers with arbitrarysubscription relations.

• Availability: the framework should provide redundancyand automatic failover to enable producers publishingnew data and consumers fetching updates as long as asubset of the pub-sub repos are running.

• Security: the framework should enable authentication forthe communication between producers, consumers, andpub-sub repos, and support data encryptions as neededfor content confidentiality. 2

B. Design Overview

ndnBMS-PS provides a pub-sub communication frameworkon top of our earlier work NDN-BMS [10] to address thechallenges in BMS data consumption. Each sensor’s datapoints form a data stream, which is published under an NDNname prefix by the smart panel connected to the sensor. Toovercome intermittent connectivity and resource (e.g., CPU,storage, and energy) limitations, sensors publish their datainto a nearby NDN repo for archiving and access. In orderto provide redundancy and efficiency of data retrieval, sensordata is typically replicated in multiple repos. The repos serv-ing a particular replicated dataset and consumer applicationsinterested in that dataset form a pub-sub group. For example,five buildings may publish their data to three nearby repos; therepos synchronize their data with each other, so that consumerscan obtain the data for any of the buildings from any repo.

Consumer applications in a pub-sub group may subscribeto any subset of the BMS data streams that are identifiedby the stream name prefixes, and pull updates from one ofthe pub-sub repos about the newly published data in theirsubscribed data streams. ndnBMS-PS uses PSync protocolto support the communication between the consumers and

2The ndnBMS-PS framework can make use of name-based access controlas described in [17].

the pub-sub repos. For example, a pub-sub group may gen-erate data under the prefix /Company/Building1/Electricity,where each pub-sub repo stores data streams with prefixesof the form /Company/Building1/Electricity/⟨panel⟩/⟨device⟩/⟨metric⟩/. Suppose a consumer is interested only in Panel 2’sdata, it can subscribe to that panel’s name prefixes using PSyncso that its pull requests will be answered whenever there arenew data points generated under those name prefixes. Basedon the notification information, the applications can then makelocal decisions of whether to retrieve the data, which can bedone through regular NDN Interest-Data exchanges.3

All data packets in ndnBMS-PS are authenticated using ahierarchical trust model expressed in the NDN names, whichis aligned with real-world physical or logical structures such ascampus buildings and enterprise management (Section III-E).The sensor data may be encrypted for access control [10], inwhich case the data decryption keys (which may be refreshedperiodically) are also distributed to the consumers as datastreams over ndnBMS-PS.

ndnBMS-PS can support complex pub-sub relationship be-tween many producers and consumers by aggregating thesensor data and the consumer requests at the pub-sub repos.As such, the repos are a core component in the ndnBMS-PS framework. The number of repos in a pub-sub group istypically determined by the deployment scenario. For example,a small pub-sub group running inside a single building andgenerating a few dozens of data streams may need only twoor three repos to support adequate data replication, while alarge pub-sub group spanning across the whole campus mayneed five or more repos to collect BMS data from differentlocations and serve many consumer applications.

Figure 2 shows the modules inside a repo. The BMSpanels and aggregators continuously publish streams of sensorreadings which are pulled into remote repos using the datainterface for archiving in the data store. The Replicationinterface monitors the addition of new data in the data storeand synchronizes the group dataset with other repos using thefull sync API of PSync. The Pub-sub interface enables theconsumer applications to subscribe to different data streamsusing the partial sync API of PSync. Each consumer requestsfor data updates based on its own schedule and decidesindependently whether to fetch the new data according to theapplication semantics. Finally, the data interface handles datafetching Interests from the applications.

Multiple pub-sub groups can be deployed independentlyon the campus network to support different applications andservices either around the same location or across differentbuildings, as illustrated in Figure 3. Different pub-sub groupscan also be concatenated together, with the BMS applicationssubscribing to and processing the input data in one group andpublishing the output data in another group.

3If the data size is small, the notification message may optionally includethe new data point(s) to avoid extra messages and delay.

4

Fig. 2: System modules inside the repo

Fig. 3: Deployment of three pub-sub groups on an enterprisecampus network that serve different types of BMS data:electricity, temperature, and water flow

C. Data Publication and Acquisition

The BMS panels in a pub-sub group usually publish datapoints that are relevant to a class of data acquisition applica-tions with similar functionality. The data points are groupedinto streams by their name prefixes (which also serve as streamidentifiers). Figure 4 shows an example of data names in a pub-sub group with two electrical panels. The group is identifiedby the prefix /BigCompany/Building1/Electricitywhich indicates this pub-sub group provides power usagedata for Building1 on the campus of BigCompany. Eachpanel manages different appliances in the room (e.g., heater,vent, switches, plugs, projector, speaker, etc.) and continuouslygenerates voltage and current readings for those appliances.ndnBMS-PS requires the last component of the data name tobe a unique sequence number that gets incremented by onefor each new data point within a stream.

There can be a number of means to collect BMS data pointsinto the repos. In ndnBMS-PS, the data producers use the RepoInsertion Protocol [18] to notify the repos to retrieve the datawhen they are generated (shown as step À in Figure 5). Eachpanel interacts with only one of the repos in the pub-sub groupduring data insertion. To allow automatic failover in the face

/BigCompany/Building1/Electricity

/BigCompany/Building1/Electricity/Panel1/Heater/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Heater/Current/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Vent/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Vent/Current/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Switches/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Switches/Current/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Plugs/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel1/Plugs/Current/{1,2,3,…}

/BigCompany/Building1/Electricity/Panel2/Projector/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel2/Projector/Current/{1,2,3,…}/BigCompany/Building1/Electricity/Panel2/Speaker/Voltage/{1,2,3,…}/BigCompany/Building1/Electricity/Panel2/Speaker/Current/{1,2,3,…} …

Data Streams:

Pub-Sub Group Prefix:

Fig. 4: Example of data names in a pub-sub group

Subscription

Filtered Updates

App1

Sub

scrip

tion

Filte

red

Upd

ates

App2

R2

R1

R0

Rep

o In

sert C

md

Data

Transfe

r

Panel1

Data

Data

Data

Data

Repo Insert Cmd

Data Transfer

Panel2

replication

replication

replication

Data

`a

a

b

Publish:

/…/Panel1/Heater/Voltage

Subscribe:

/…/Panel1/Heater/Voltage

Fig. 5: Data flow in a pub-sub group

of repo failure, the repos in the same group announce the samename prefix in order to receive notifications from the panels.The NDN forwarders in the network will use the Best Routeforwarding strategy [19] to direct each data insertion requesttoward the closest repo. The repo receiving the data insertionrequest will send an Interest to the data producer to retrievethe data.

Once the repo retrieves the data point, it will replicate thedata in the background to other repos in the same groupusing PSync’s full sync API (shown as step Á in Figure 5).Rather than synchronizing the sensor data streams directly inthe PSync group, the repo publishes a Data packet under itsown name prefix which “wraps” the sensor data names inthe content, and synchronizes this “repo data” instead. Thisadditional level of indirection ensures that the size of thePSync state maintained by every repo is proportional to thenumber of repos in the group rather than the number of datastreams. Another important benefit is that when many sensorsgenerate data points at the same time, the repo can batchmultiple new sensor data names in one repo data packet inorder to improve the efficiency of the sync process. Figure 6shows an example of the repo data including its name and

5

Name: /BigCompany/Building1/Electricity/Repo/Repo1/<seq#>

Content: {/<Group-Prefix>/Panel1/Heater/Voltage/<seq#>,

/<Group-Prefix>/Panel1/Heater/Current/<seq#>,

/<Group-Prefix>/Panel1/Plugs/Voltage/<seq#>,

/<Group-Prefix>/Panel1/Plugs/Current/<seq#>,

…

}

Group Prefix

Fig. 6: Example of repo data published through PSync’s fullsync API for replication among repos

content which contains a snapshot of the latest data names forall the data streams in the repo.

When other repos receive the notification of the new sensordata names published by some repo via PSync, they willsend Interests that carry a forwarding hint [20] pointing tothe repo’s unicast name prefix in order to retrieve the sensordata packets from that repo, to avoid the Interests reachingthe data producer directly. Alternatively, the repo may includethe wire-encoded sensor data packet inside the repo data itpublishes and synchronizes via PSync. This saves the round-trip for others to retrieve the sensor data packet. After receivingthe new sensor data, all repos insert the data to their localdata store. The PSync partial sync producer running at thePub-sub interface listens to the repo insert event and informsany subscribed consumers with the updated IBF and missingnames.

D. Data Subscription

Data subscription in ndnBMS-PS allows the consumerapplications to receive updates efficiently from a subset ofthe data streams published in the pub-sub group. Behindthe scene, the consumers use PSync Interest messages toretrieve the latest data name of each subscribed stream fromthe repos. Once they obtain the new data name with thelatest sequence number, the consumers can decide whether tofetch the new data according to the application requirements(which corresponds to step  in Figure 5). The separationof the notification of names from the retrieval of actual dataallows ndnBMS-PS to accommodate different data consumingsemantics (e.g., sequential fetching, latest-data first, randomsampling, etc.) without forcing every consumer to receive allthe data.

The subscription state of the consumer consists of two parts:(a) the list of name prefixes of the subscribed data streams and(b) the latest state of the whole dataset known by the consumer(which may not be up to date). In PSync, the subscription listis encoded as a Bloom Filter (BF) due to its space efficiency.4

The state of the repo is represented using an Invertible BloomFilter (IBF) computed over the latest names in the data streams

4There can be other ways to encode the name prefixes, for example, a range[NP1, NP2] can efficiently represent all the name prefixes between two nameprefixes NP1 and NP2 based on some ordering criteria.

stored at the repo, which is sent back to the consumers inPSync reply messages (see Figure 1). When a repo receivesnew data (either from the BMS panels or from other pub-subrepos via the PSync replication channel), it replaces the dataname of the updated stream in the IBF with the latest one.

When requesting for updates in the subscribed data streams,the consumer sends its current state (including the BF-encodedsubscription list and the previously received IBF) in therequest. To generate a PSync reply, the repo subtracts thereceived IBF from its own IBF to detect the streams that havebeen updated, filters the updated streams with the subscriptionlist, and returns the latest data names of the subscribed streamsto the consumer. Since the sequence number in the data namecontinuously increases, the name of the latest data can serveas an implicit notification of all the previous data published inthe same stream. The reply carries the repo’s latest IBF, whichis used by the consumer to replace its IBF and “advance” itsdata consumption state.

An important design benefit of using PSync in ndnBMS-PS is that the consumer’s subscription state is maintained bythe consumer itself rather than stored in the pub-sub repos.This allows the repos to remain stateless about the consumersubscription information, which reduces the amount of statethat the repos have to maintain. It also enables the consumersto retrieve updates over the PSync protocol from any of therepos that are synchronized for the same set of data streams(using PSync’s full sync API) without worrying about lossof subscription state or having to wait for the consumer statesynchronization among the repos. Multiple repos in the samepub-sub group use the same name prefix to receive PSyncInterests, and the network will always forward the consumers’PSync Interest to the nearest available repo.

E. Data Authentication

In ndnBMS-PS, the public keys of all the entities (panels,user devices, and repos) are certified using a hierarchicaltrust model expressed with the names of the signing keys.Signatures generated by the trusted entities are verified byfollowing the certification chain up to a common trust anchoror, eventually, the BMS root key. The key signing chain forthe panels is aligned with the hierarchical structure of theirphysical locations in the enterprise buildings, as is shownin Figure 7a. The key signing chain for the user devicesis instead aligned with the logical management hierarchy inthe enterprise, which is shown in Figure 7b. The repo usesa different key for each pub-sub group it participates in,following the principle of least privilege. The repo key issigned by the pub-sub group key, which is further signed by thebuilding key or the BMS root key (see Figure 7c), dependingon whether the pub-sub group is located in a single buildingor spans across the campus.

The data publishing process requires the mutual authenti-cation between the producers and the pub-sub repos: on onehand, the repos need to authenticate the sensor data beforeadding them to the local storage; on the other hand, the produc-ers need to verify that the confirmation in the Repo Insertion

6

/BigCompany/BMS/key

/BigCompany/Building1/key

/BigCompany/Building1/Electricity/Panel1/key

/BigCompany/Building1/Electricity/Panel1/Heater/Voltage/<seq#>

Signs

Signs

Signs

BMS Root Key:

Building Key:

Device Key:

Device Data:

(a) Sensor certification chain

/BigCompany/BMS/key

/BigCompany/DepartmentA/key

/BigCompany/DepartmentA/Alice/key

/BigCompany/DepartmentA/Alice/Phone/key

Signs

Signs

Signs

BMS Root Key:

Department Key:

Employee Key:

User Device Key:

(b) User device certification chain

/BigCompany/BMS/key

/BigCompany/Building1/key

/BigCompany/Building1/Electricity/key

/BigCompany/Building1/Electricity/Repo/Repo1/key

Signs

Signs

Signs

/BigCompany/Building1/Electricity/Repo/Repo1/<seq#>

BMS Root Key:

Building Key:

Pub-Sub Group Key:

Repo Key:

Repo Data:

Signs

(c) Pub-sub repo certification chain

Fig. 7: BMS certification chain examples

process [18] comes from a legitimate repo in order to makesure the data is successfully archived in the pub-sub group. Theconsumers also need to authenticate the PSync replies fromthe repos and the sensor data fetched from the network. Inaddition, the repos need to authenticate each other during thePSync message exchanges. In a traditional TCP/IP-based pub-sub system, implementing such complicated authenticationsteps would require TLS channels between all communicatingparties. In contrast, the data-centric security paradigm and theexpressive naming in NDN enable a more powerful and elegantsolution with a simple, hierarchical trust model that allowsNDN nodes to authenticate any data produced on the network.

IV. EVALUATION IN MINI-NDNWe implemented the proposed system on the NDN plat-

form [7] and evaluated it using our emulation tool Mini-NDN [21]. Our experiment topology (Figure 8) is based onthe UC Berkeley campus core network [22], which has twocore routers connected to border routers and every edge routerconnected to both core routers for robustness. Each edge routeris connected to a number of repos and consumers. The linkspeed between routers is 1Gbps and propagation delay isuniformly distributed between 10 and 30 microseconds. Toemulate unreliable wireless links, we made 20% of the linksbetween consumers and edge routers lossy with a loss rate of1% (some experiments have a higher loss rate). Every repocollects data from a number of producers (BMS panels), eachgenerating a stream of data with random inter-arrival times

Fig. 8: Emulation evaluation topology for BMS system

between 1 and 5 minutes. Each data consumer subscribes toa fixed number of randomly chosen set of data streams.

To evaluate how well the system scales with the number ofmonitored buildings and end users, our experiments includevarying number of data streams, data consumers and repos.We focus on the data fetching delay, i.e., the delay from whena data point is produced to when the data is obtained by aconsumer that has subscribed to the data, which includes up tofour delay components: (a) the delay for the producer to insertthe data into the repo, (b) the delay to propagate the data fromthe producer’s repo to the repo with which the consumer issync’ed (if the two repos are different), (c) the delay to informthe consumer of the new data name, and (d) the delay for theconsumer to fetch the data. In the first part, the producersuse the Repo Insertion Protocol that takes 1.5 RTT to inserta Data packet into a repo, which is typically constant in ouremulation environment. Therefore our experiments measureonly the latter three parts of the delay. Below we present ourexperiment results.

A. Number of Data Streams per Repo

In this experiment, we run five repos and vary the numberof data streams per repo from 500 to 1500. We then measurethe data fetching delay across 20 consumers, each subscribingto 200 data streams, over a 10-minute time period. We presentour results using the Tukey boxplot, i.e., the two ends of thewhiskers represent the lowest data point within 1.5 IQR of thelower quartile and the highest data point within 1.5 IQR of theupper quartile, respectively.

We can see in Figure 9 that (1) the lowest data fetchingdelays are slightly over 9 ms, which correspond to the caseswhere the consumer subscribes to the same repo into whichthe producer inserts data; (2) the median delay increases onlyfrom 0.05 second to 0.06 second while the number of streamsgrows from 500 to 1500 per repo; and (3) the 75th-percentiledelay is below 0.15 second and the highest whisker endpoint

7

Fig. 9: Data delay vs. number of streams per repo (5 repos,20 consumers, 1% link loss rate)

Fig. 10: Data delay vs. number of repos (1000 datastreams/repo, 1% link loss rate)

is around 0.32 second for 1400 streams per repo. These resultsdemonstrate that the system scales very well when the overalldata production rate increases.

B. Number of Repos

We varied the number of repos from 5 to 10 while keepingthe other parameters fixed (e.g., 1000 data streams per repoand 200 subscriptions per consumer) in the second experiment.Note that we also maintain a fixed ratio between consumersand repos here, i.e., 12 consumers/repo. One can observe fromFigure 10 that the data fetching delay remains stable as thenumber of repos increases, suggesting that we can scale outour system to store more data streams and serve consumersby adding more repos.

C. Number of Consumers

In the third experiment, we varied the number of consumersfrom 20 to 120, while maintaining 10 repos and 1000 datastreams per repo. Figure 11 suggests that the data fetchingdelay does not increase significantly even though we increasethe number of consumers by a factor of 6. This is due totwo reasons: (1) the consumers interact with the repos usingthe PSync protocol, which does not maintain per-consumer

Fig. 11: Data delay vs. number of consumers (10 repos, 1000data streams/repo, 1% link loss rate)

Fig. 12: Data delay under different loss rates (10 repos, 1000data streams/repo, 120 consumers)

state and uses IBF to do efficient set difference operations;and (2) the consumer-repo delay and its variations are muchsmaller than those in the repos’ data synchronization process.In our current prototype, the pub-sub repo is implementedas a single-thread process that has to process the consumerrequests sequentially. We believe the performance differencein these experiments can be further improved once we changethe repo’s PSync module to be multi-threaded.

D. Link Loss Rate

In the final experiment, we varied the link loss rate from2% to 10%, while running 10 repos with 1000 data streamsper repo and 120 consumers. Note that we set 20% of theconsumer links to be lossy. If the requested data is lost, aconsumer retransmits the Interest up to 3 times if it does notget the data. The results in Figure 12 show that the higher lossrates did not have much impact on the data fetching delay.This is because the lost data is already cached at the edgerouter and can be easily recovered in the next retry.

V. RELATED WORK

Several frameworks have been proposed so far forICN architectures to support end-to-end pub-sub semantics.

8

COPSS [23] achieves pub-sub communication using push-based multicast mechanism similar to PIM-SM. When pub-lishing data, the publisher sends a publication message to-wards some Rendezvous Point (RP). The publication messagecontains the Content Descriptor (CD) of the published infor-mation. The CD is a hierarchical name that allows subscriptionat different granularities. COPSS adds the Subscription Table(ST) to the NDN forwarders to keep track of downstream datasubscribers. The subscriber sends a subscription message to-wards the RP to establish a forwarding path. Forwarders alongthe path will record the subscribed CD and the downstreaminterface in the ST using bloom filters. The data from thepublisher is then pushed to all subscribers following ST entriesinstead of PIT entries as in normal NDN forwarding.

iHEMS [24] modifies the NDN routers to implement per-sistent subscription using long-lived forwarding information.The subscribers send subscription requests that persist in therouter’s PIT for some time t. Any data published during thattime t will be forwarded to the subscribers without consumingthe PIT entry. The authors of iHEMS acknowledge that persis-tent PIT entry may affect the traffic control and flow balancing,but argue that the problem can be mitigated by choosing thepersistence interval t very carefully. To support secure groupcommunication, iHEMS proposes to encrypt confidential datawith a group key shared among the publishers and subscribers.In addition, iHEMS relies on dedicated directory service tomaintain the list of data names published in the network,through which the publishers and subscribers discover eachother.

Both COPSS and iHEMS allow more than one data packetreturned for each pending Interest over a single link, es-sentially breaking the flow balance principle of NDN [25].Although this approach reduces the number of interests, it issusceptible to congestion and denial-of-service attacks.

PSIRP/PURSUIT [26] is an ICN architecture that pro-vides native pub-sub support at the network layer. InPSIRP/PURSUIT, the data (or information) is identified bya pair of flat labels: the rendezvous identifier (RID) and thescope identifier (SID). To publish information, the publisherneeds to choose the scope for the publication and createthe RID for the publication. Then the publication messagecontaining the RID and the SID is forwarded to the rendezvousnode within the scope of SID, which will store and managethe RID. A subscriber first learns about the RID and SID,then issues the subscription request to the rendezvous pointof that RID. A forwarding path is then created between thepublisher and the subscriber (through the rendezvous point)and future information will be sent over this channel. Thepacket forwarding in PSIRP/PURSUIT can be implementedefficiently using MPLS-style label matching.

ndnBMS-PS differs fundamentally from the above proposalsin the following aspects: (1) it is built on top of NDN’sInterest-Data exchange semantics and achieves efficient sub-scription without breaking the flow balance principle by ag-gregating multiple subscriptions into a single PSync Interest;(2) it is designed specifically for the BMS environments

and takes into account the practical requirements such ashierarchical naming and trust management, data archiving andreplication, efficient subscription to multiple data streams, andaccommodation for different data consuming semantics, all ofwhich are essential to the BMS applications.

HoPP [27] was recently proposed for pub-sub in ICN-based IoT networks. It uses Content Proxies (CP) to decoupleproducers and consumers similar to how Repos are used inndnBMS-PS. However, it introduces a Prefix AdvertisementMessage to set up FIB entries for the CPs, and a NameAdvertisement Message to propagate data from producers tothe CPs. In contrast, ndnBMS-PS does not rely on intermediatenodes to process any special messages; the Sync and Repoprotocols run on application nodes (consumers, producers andrepos) using basic interest/data exchanges.

VI. CONCLUSION

In this paper we present ndnBMS-PS, a distributed pub-subcommunication framework for building management systemsover NDN. ndnBMS-PS extends our previous work on securedata acquisition in NDN-BMS to support data subscriptionsfrom consumer applications running on different platformsand with interests in different data as well as different dataconsumption semantics. PSync, a new addition to NDN’s datasync arsenal, enables ndnBMS-PS to replicate collected sensordata across multiple repos to provide adequate redundancy andscalable data retrieval, and it allows data consumers to receivenotifications of new sensor readings generated by multipleBMS panels. Last but not least, all sensor data readings, aswell as all packets generated by the repos, are authenticatedthrough cryptographic signatures and can be verified througha hierarchical trust model.5

ndnBMS-PS is a comprehensive pub-sub design based onNDN’s Interest-Data primitive. It retains the fundamentaldesign principles of the NDN architecture such as flow bal-ancing and hierarchical naming. This design exercise furtherconfirms (a) the expressive power of naming in NDN, suchas embedding the building hierarchy and sensor types inthe prefixes of the pub-sub groups; (b) the usefulness ofnaming conventions, such as the use of sequence numbers toimprove the efficiency of data synchronization; (c) the utilityof NDN Sync protocols, which simplifies application designand supports asynchronous multi-party data sharing; and (d)the simplicity of data authentication using a hierarchical trustmodel based on hierarchical data naming and organizationaland system relationships.

ACKNOWLEDGMENT

This work has been supported by the National Sci-ence Foundation, under awards CNS-1344495, CNS-1629769,CNS-1345318, and CNS-1629922.

5Data confidentiality and access control can also be supported using dataencryption, as is described in our previous work [10], or the more recentName-based Access Control [28].

9

REFERENCES

[1] W. Shang, Y. Yu, R. Droms, and L. Zhang, “Challenges in IoTNetworking via TCP/IP Architecture,” NDN Project, Tech. Rep. NDN-0038, February 2016.

[2] W. Shang, A. Bannis, T. Liang, Z. Wang, Y. Yu, A. Afanasyev, J. Thomp-son, J. Burke, B. Zhang, and L. Zhang, “Named Data Networkingof Things,” in Proceedings of 1st IEEE International Conference onInternet-of-Things Design and Implementation (IoTDI), 2016.

[3] Y. Zhang, D. Raychadhuri, L. A. Grieco, E. Baccelli, J. Burke,R. Ravindran, G. Wang, B. Ahlgren, and O. Schelen, “Requirementsand Challenges for IoT over ICN,” Internet Engineering TaskForce, Internet-Draft draft-zhang-icnrg-icniot-requirements-01, Apr.2016, work in Progress. [Online]. Available: https://tools.ietf.org/html/draft-zhang-icnrg-icniot-requirements-01

[4] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,and R. L. Braynard, “Networking Named Content,” in Proceedings ofthe 5th International Conference on Emerging Networking Experimentsand Technologies, 2009.

[5] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy, P. Crowley,C. Papadopoulos, L. Wang, and B. Zhang, “Named Data Networking,”SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 66–73,Jul. 2014.

[6] A. Afanasyev, T. Refaei, L. Wang, and L. Zhang, “A Brief Introductionto Named Data Networking,” in IEEE MILCOM 2018.

[7] NDN Project Team, “NDN Codebase Platform,” http://named-data.net/codebase/platform/.

[8] Y. Yu, A. Afanasyev, D. Clark, kc claffy, V. Jacobson, and L. Zhang,“Schematizing Trust in Named Data Networking,” in Proceedings ofthe 2nd International Conference on Information-Centric Networking,September 2015.

[9] C. Yi, A. Afanasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang,“A Case for Stateful Forwarding Plane,” Computer Communications,vol. 36, no. 7, pp. 779–791, Apr. 2013.

[10] W. Shang, Q. Ding, A. Marianantoni, J. Burke, and L. Zhang, “SecuringBuilding Management Systems using Named Data Networking,” IEEENetwork, vol. 28, no. 3, pp. 50–56, May 2014.

[11] W. Shang, Y. Yu, L. Wang, A. Afanasyev, and L. Zhang, “A Survey ofDistributed Dataset Synchronization in Named-Data Networking,” NDNProject, Technical Report NDN-0053, May 2017.

[12] Z. Zhu and A. Afanasyev, “Let’s ChronoSync: Decentralized datasetstate synchronization in Named Data Networking,” in 2013 21st IEEEInternational Conference on Network Protocols (ICNP), Oct 2013.

[13] W. Fu, H. Ben Abraham, and P. Crowley, “Synchronizing Namespaceswith Invertible Bloom Filters,” in ACM/IEEE Symposium on Architec-tures for Networking and Communications Systems (ANCS), May 2015.

[14] M. Zhang, V. Lehman, and L. Wang, “Scalable Name-based DataSynchronization for Named Data Networking,” in Proceedings of theIEEE Conference on Computer Communications (INFOCOM), May2017.

[15] D. Eppstein, M. T. Goodrich, F. Uyeda, and G. Varghese, “What’sthe Difference?: Efficient Set Reconciliation Without Prior Context,” inProceedings of the ACM SIGCOMM 2011 Conference, 2011.

[16] NDN Project Team, “repo-ng: Next generation of NDN repository,”https://github.com/named-data/repo-ng, 2017.

[17] Z. Zhang, Y. Yu, S. K. Ramani, A. Afanasyev, and L. Zhang, “NAC:Automating access control via Named Data,” in Proc. of MILCOM, Oct.2018.

[18] NDN Project Team, “Basic Repo Insertion Protocol,” http://redmine.named-data.net/projects/repo-ng/wiki/Basic Repo Insertion Protocol,2014.

[19] A. Afanasyev, J. Shi, B. Zhang, L. Zhang, I. Moi-seenko, Y. Yu,W. Shang, Y. Huang, J. P. Abraham, S. DiBenedetto, C. Fan, C. Pa-padopoulos, D. Pesavento, G. Grassi, G. Pau, H. Zhang, T. Song,H. Yuan, H. B. Abraham, P. Crowley, S. O. Amin, V. Lehman, andL. Wang, “NFD Developer’s Guide,” NDN Project, Tech. Rep. NDN-0021, Revision 10, July 2018.

[20] A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, “SNAMP:Secure namespace mapping to scale NDN forwarding,” in Proceedingsof 18th IEEE Global Internet Symposium (GI 2015), April 2015.

[21] NDN Project Team, “Mini-NDN Website,” http://minindn.memphis.edu.[22] University of California, Berkeley, “Campus network core topology,”

https://nettools.net.berkeley.edu/pubtools/legacy/net/netinfo/newmaps/campus-topology.pdf, 2016.

[23] J. Chen, M. Arumaithurai, L. Jiao, X. Fu, and K. K. Ramakrishnan,“COPSS: An Efficient Content Oriented Publish/Subscribe System,” inSeventh ACM/IEEE Symposium on Architectures for Networking andCommunications Systems (ANCS), Oct 2011.

[24] J. Zhang, Q. Li, and E. M. Schooler, “iHEMS: An information-centricapproach to secure home energy management,” in 2012 IEEE ThirdInternational Conference on Smart Grid Communications (SmartGrid-Comm), Nov 2012.

[25] NDN Project Team, “NDN Protocol Design Principles,” http://named-data.net/project/ndn-design-principles/.

[26] N. Fotiou, P. Nikander, D. Trossen, and G. C. Polyzos, “Developing in-formation networking further: From PSIRP to PURSUIT,” in BroadbandCommunications, Networks, and Systems. Springer, 2010, pp. 1–13.

[27] C. Gundogan, P. Kietzmann, T. C. Schmidt, and M. Wahlisch, “HoPP:Robust and Resilient Publish-Subscribe for an Information-Centric In-ternet of Things,” in Proceedings of the IEEE Conference on LocalComputer Networks (LCN), 2018.

[28] Y. Yu, A. Afanasyev, and L. Zhang, “Name-Based Access Control,”NDN Project, Tech. Rep. NDN-0034, Revision 2, Jan. 2016.

10