Exploiting content centric networking to develop topic-based, publish–subscribe MANET systems

Ad Hoc Networks xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

Ad Hoc Networks

journal homepage: www.elsevier .com/locate /adhoc

Exploiting content centric networking to develop topic-based,publish–subscribe MANET systems

http://dx.doi.org/10.1016/j.adhoc.2014.07.0201570-8705/� 2014 Elsevier B.V. All rights reserved.

⇑ Corresponding author.E-mail addresses: [email protected] (A. Detti), Dimitri.

[email protected] (D. Tassetto), [email protected](N.B. Melazzi), [email protected] (F. Fedi).

Please cite this article in press as: A. Detti et al., Exploiting content centric networking to develop topic-based, publish–subscribesystems, Ad Hoc Netw. (2014), http://dx.doi.org/10.1016/j.adhoc.2014.07.020

Andrea Detti a,⇑, Dimitri Tassetto a, Nicola Blefari Melazzi a, Francesco Fedi b

a CNIT University of Rome ‘‘Tor Vergata’’, Electronic Engineering Dept., Italyb Sistemi Software Integrati, R&D Dept., Italy

a r t i c l e i n f o a b s t r a c t

Article history:Received 7 March 2014Received in revised form 15 July 2014Accepted 29 July 2014Available online xxxx

Keywords:MANETPublish subscribeInformation centric networkContent centric network

Mobile Ad-hoc NETworks (MANETs) connect mobile wireless devices without an underly-ing communication infrastructure. Communications occur in a multi-hop fashion, usingmobile devices as routers. Several MANET distributed applications require to exchangedata (GPS position, messages, pictures, etc.) by using a topic-based publish–subscribeinteraction. Participants of these applications can publish information items on a giventopic (identified by a name) and can subscribe to a topic to receive the related publishedinformation. An efficient dissemination of publish–subscribe data in MANET environmentsdemands for robust systems, able to face radio resource scarcity, network partitioning, fre-quent topology changes. Many MANET publish–subscribe systems have been proposed sofar in the literature assuming an underlying TCP/IP network.

In this paper, we discuss the benefits of building a MANET publish–subscribe systemexploiting Content Centric Networking (CCN) technology, rather than TCP/IP. We showhow CCN functionality, such as in-network caching and multicasting can be used to achievean efficient and reliable data dissemination in MANET environments, including the supportof delay tolerant delivery. We present different design approaches, describe our topic-based publish–subscribe CCN system, and report the results of a performance evaluationstudy carried out with real software in an emulated environment. The emulation environ-ment is based on Linux virtual machines. The performance evaluation required also a CCNMANET routing engine, which we developed as a plug-in of the OLSR Linux daemon.

� 2014 Elsevier B.V. All rights reserved.

1. Introduction

The TCP/IP protocol suite is designed to push data to aremote host identified by an address. This host-centricservice is not perfectly tailored for information-centricapplications (e.g. web browsing) that require to pullinformation identified by names, regardless of the source

of information. Users are interested in receiving ‘‘what’’they requested, and do not care ‘‘who’’ provides it.

Nowadays, information-centric applications are themost used in the Internet, as well as in sensor andad-hoc networks. The need of efficiently support them ontop of a host-centric TCP/IP network has given rise to theintroduction of many incompatible proprietary content-oriented services (name-based routing, caching, multicast-ing, data replication, and so on) offered, e.g., by ContentDelivery Networks [1].

Information Centric Network (ICN) is an emerging par-adigm aimed at supporting content-oriented services inany kind of network: wide and local area networks [5],

MANET

http://dx.doi.org/10.1016/j.adhoc.2014.07.020

mailto:[email protected]






http://www.sciencedirect.com/science/journal/15708705

http://www.elsevier.com/locate/adhoc


TCP-UDP/IP

Topic-basedpub-sub system(discovery, etc.)

Topic-basedpub-sub applica�on

Address-based push API

Topic-based pub-sub API Implementa�on

effort in CCN MANET

CCN(mul�cast, caching,

dtn,etc.)

Name-based req-res API

paper contribu�on

Fig. 1. Functional architecture of a topic-based publish–subscribe systemover CCN.

2 A. Detti et al. / Ad Hoc Networks xxx (2014) xxx–xxx

mobile ad-hoc or mesh networks [15], delay tolerant net-works, sensor networks [35], etc. ICN rethinks network ser-vices by putting information dissemination at the center ofthe network-layer design. Rather than creating networkpipes between hosts identified by addresses, ICN deliversinformation (or contents) identified by names. A userexpresses an interest for a content to the ICN ApplicationProgramming Interface (API) and the underlying ICN func-tionality takes care of routing-by-name the contentrequest towards the best source (be it the original one, areplica server, or an in-network cache) and of sending backthe related data.

The ICN concept dates back to 1999, when the TRIADarchitecture was proposed [3]. However, the interest inICN has been rather limited until 2009, with few contribu-tions from the research community. In 2009, Jacobson et al.presented an ICN architecture named Content-CentricNetwork (CCN) [4], aka Named Data Network (NDN), sup-ported by an open-source implementation, named CCNx[7]. This work quickly renewed the interest in ICN researchand most of current ICN work uses or is related to the CCNarchitecture.

CCN research mostly applies to wide area staticnetwork scenarios. However, CCN functionalities aredeemed to be effective also in Mobile Ad-hoc NETworks(MANETs). In fact, many MANET applications require toexchange data (GPS position, messages, pictures, etc.) byusing a publish–subscribe interaction scheme [9], whichis information-centric in nature. Publishers characterizetheir information items with a set of attributes, and sub-scribers register their interests in receiving only thoseinformation items whose attribute match a given criterion,regardless of who is the publisher. Publishers and subscrib-ers are decoupled in space (they do not need to know ofeach other), and in time (they do not need to be active atthe same time). Such decoupling simplifies mobility anddisconnected operations, which are typical of MANETs.Moreover, one-to-many delivery can exploit intrinsicbroadcast properties of the wireless channel.

The simplest publish–subscribe scheme is the so called‘‘topic-based’’ one, in which the only attribute of an infor-mation item is its being part of a given topic. Participantsof a topic-based publish–subscribe system can publishinformation items on a topic and can subscribe to a topicto receive the related published information items. Topicsare identified by a name (e.g. ‘‘foo.news’’), and publishingan information on a topic T implies its distribution to theusers subscribed to T.

A more complex publish–subscribe scheme is the ‘‘con-tent-based’’ one, in which publishers can characterize theinformation items with many attributes and subscriberscan express complex conditions of interest. For instance asubscriber could be interested in information items regard-ing all cars with price less than 20 k€. Content-based pub-lish–subscribe systems are more complex than topic-basedones and their design is rather different.

The main contribution of this paper is to show how CCNfunctionality can be exploited to easily setup an efficientand resilient topic-based publish–subscribe system forMANETs. As shown in Fig. 1, we propose a topic-based pub-lish–subscribe system that uses the service of a CCN. We

Please cite this article in press as: A. Detti et al., Exploiting content centsystems, Ad Hoc Netw. (2014), http://dx.doi.org/10.1016/j.adhoc.2014.0

use hierarchical names to address topic information itemsand this makes it possible to exploit the in-network cach-ing and multicast functionality offered by CCN to achievelow delay and delivery efficiency. Moreover, through adynamic configuration of CCN forwarding tables, we carryout a data muling functionality. Moving devices can usethis functionality to transport information items amongdisconnected part of the networks, thus realizing the delaytolerant delivery [26] typical of Delay Tolerant Networks(DTNs).

Our findings are based on the practical developmentexperience that we gained by using CCN as the underlyinglayer of the BEE DDS middleware [13], which is a specificimplementation of the Object Management Group (OMG)specification of the Data Distribution Service for Real TimeSystem [8]. We discuss design approaches, present somedetails of our pull-based system and report the results ofa performance evaluation study carried out in an emulatedenvironment, based on Linux virtual machines.

To evaluate the system performance, we had to developour own CCN routing engine for MANET, since availableCCN routing software tools, e.g. [6,34], are designed forfixed networks. The routing engine is developed as anopen-source OLSR plug-in [23], which configures CCN rout-ing tables according to a shortest path strategy. The plug-inmay be of interest to other researchers, independentlyfrom the specific results presented in this paper.

As for the organization of the paper, in Section 2 wedescribe the CCN architecture and briefly revise some pub-lish–subscribe literature works. In Section 3 we motivatethe use of CCN to realize publish–subscribe systems overMANETs and discuss the related research challenges. InSection 4 we discuss several approaches to build a pub-lish–subscribe system over CCN. In Section 5 and 6 wedescribe our publish–subscribe system and routing engine,respectively. In Section 7 we report a performance evalua-tion study and in Section 8 we draw our conclusions. Finallywe present some additional performance results in anAppendix A.

2. Related work

2.1. Information Centric Networking

Information Centric Networking (ICN) is a networkingapproach that addresses content by names, instead oflocations, at the network layer, and combines in-network

ric networking to develop topic-based, publish–subscribe MANET7.020


TCP-UDP/IP

Topic-basedpub-subsystem

(mul�cast, caching, discovery, etc..)

Topic-basedpub-sub applica�on

Address-based push API

Topic-based pub-sub API Implementa�on

effort in TCP-UDP/IP MANET

Fig. 2. Functional architecture of a topic-based publish–subscribe systemover TCP/IP.

A. Detti et al. / Ad Hoc Networks xxx (2014) xxx–xxx 3

storage, multiparty communication and data centric secu-rity within a unique network framework aimed at provid-ing efficient content distribution. So far several ICNarchitectures have been proposed. The paper [37] surveysseveral architectures that differ on how they implementICN key functionality, such as:

– Naming – ICN names are location independent; differentarchitectures adopt different naming schemes. Some ofthem, like CCN, use hierarchical names; whereas otherones (like PURSUIT or MobilityFirst) use flat names. Thischoice is usually related to the scalability of the under-lying routing or resolution system.

– Content routing – To forward a content request towardsa content source some architectures, like CCN or CONET[37], use on-path name-based routing tables and rout-ing-by-name functionality; whereas other ones, likePURSUIT or MobilityFirst, use an off-path resolutionsystem e.g. based on DHT.

– Security – ICN architecture embed security informationin the content. Some architectures, like CCN, decouplesecurity information from the names and this allowsusing human readable names; security information,e.g. signature, is inserted in the header of network dataunits and the system requires a PKI. Conversely, otherarchitectures, like DONA or NetInf (or SAIL in [37]),use self-certified names that include an hash of the pub-lic key of the publisher in the name. These architecturesdo not requires a PKI, but names are not humanreadable.

– Communication primitives – Most architectures use arequest-response communication primitive; an excep-tion is PURSUIT that supports publish–subscribe com-munication primitives by means of a fixed networkinfrastructure formed by Rendezvous nodes organizedthrough a DHT, and a global Topology Manager.

We adopt the CCN solution and we briefly recall it in thenext section.

2.2. Content Centric Network (CCN)

A CCN provides users with information items exposedby unique names. Information items (or contents) maybe small data, chunks of files, etc. A name that uniquelyidentifies an information item is formed by a hierarchy ofstrings, aka components, separated by a ‘‘/’’ character. Thegeneric naming scheme is ccnx:/component#1/. . ./compo-nent#n. For the sake of simplicity we omit the default pre-fix ‘‘ccnx:/’’ in what follows.

To fetch an information item, a client sends an Interestmessage that includes the name of the information item.Then, the CCN network finds a source and sends back theinformation item to the client within a Data message(aka Content Object).

Fig. 3 shows the model of a CCN node. A name-basedForwarding Information Base (FIB) is used to route-by-name Interest messages using a prefix match strategy.A FIB entry contains a name prefix and a list of upstreamfaces on which the Interest message may be forwarded toreach a source of information. A face is a generalization


of the concept of interface and may be a connection to anext-hop CCN node or directly to an application party.For instance, in Fig. 3 Interests message for informationitems whose names contain the prefix ‘‘foo.news/P1’’ areforwarded on face 2. The FIB entries are configured throughthe CCN API, either manually or by a name-based routingprotocol, not specified by the CCN architecture.

During the forwarding process of Interest messages, aCCN node leaves reverse path information <name – down-stream faces> in a Pending Interest Table (PIT), where adownstream face is the face from which an Interest comesfrom. For instance, in Fig. 3 the node has received from thefaces 0 and 1 the Interest messages for ‘‘foo.news/P1/2’’and ‘‘foo.news/P1/3’’. When an Interest reaches a nodehaving the requested information item (either in the cacheor in a local application), the node sends back the informa-tion item within a Data message. The Data message is rou-ted on the downstream path by consuming the reversepath information previously left in the PITs. If not con-sumed by a Data message, PIT entries expire after a timeout period.

CCN nodes temporarily store the forwarded Data mes-sages in a cache memory (e.g. foo.new/P1/1 in Fig. 3),named Content Store. The content store has a limited stor-ing capacity and its use is controlled by a cache replace-ment policy, such as Least Recently Used (LRU), LeastFrequently Used (LFU) or First Input First Output (FIFO).

If a node receives an Interest message related to acached information item, the item is sent back immedi-ately, without further forwarding the Interest message.Since caching occurs on all network nodes rather than onlyon edge nodes, this caching approach is usually referred toas in-network caching.

In case of concurrent Interest messages regarding thesame information item, a CCN node forwards only the firstreceived Interest message and stores in the PIT the set ofdownstream faces from which it received the next Inter-ests. When the node receives the related Data message, itrelays a copy of it towards all such downstream faces. Indoing so a CCN node carries out a network-level multicastdistribution.

CCNx [7] is a CCN implementation for Linux, Mac OSand Android platforms. The node model is implementedin C language, whereas the CCN API consists mainly of awide set of Java libraries. The faces are, for the time being,UDP or TCP sockets. CCN functionality can be used either



Cache - Content Store (CS)

Name Prefix Data

foo.news/P1/1 …

Forwarding Informa�on Base (FIB)

Upstream Faces

foo.news/P1 2

Pending Interest Table (PIT)

Downstream Faces0,1foo.news/P1/2

Face 2

Face 1

Face 0

foo.news/P1/3

Interest

Data

Data

Interest

Interest

Data

0,1

Publiserfoo.news/P1

Subscriber offoo.news

Subscriber offoo.news

Name Prefix

Name Prefix

Fig. 3. Model of CCN node.


hop-by-hop (CCN deployed in each node of the network) orin an overlay fashion (CCN deployed in a subset of nodesconnected by sockets).

2.3. Publish–subscribe systems

Publish–subscribe systems have been widely analyzedin the literature both for wired and wireless TCP/IP scenar-ios [16]. In case of wired TCP/IP networks, a traditionalapproach uses an always-on infrastructure of messageBrokers, which act as access points for publishers and sub-scribers, and store and forward information items frompublishers to interested subscribers through an overlaydistribution tree. Examples of such systems are [22,24].

In case of mobile ad-hoc networks these systems do notfit well, since they are not meant to support frequenttopology reconfigurations caused by mobility. Since pub-lish–subscribe is a form of multicast communication, froma publisher to many subscribers, many MANET approachesfocus on the building and maintenance of a tree routingstructure. For instance in [17], the authors studied the treeconstruction problem, proposed a related algorithm andanalyzed it through simulation. Similar studies are[18–21]. Other structure-less MANET publish–subscribesystems provide information dissemination through opti-mized flooding or gossiping [32], since they consider toocomplex to maintain a distribution structure.

In the context of Delay Tolerant Networks (DTNs), pub-lish–subscribe systems use nodes as data mules and takeadvantage of contact graph or of social relationships forrouting purposes [33].

Whereas all the systems presented above use TCP/IP (ordirectly the MAC layer) as the underlying network service,some recent papers study publish–subscribe systemsdeployed on top of a CCN architecture. In [10,11] authorspropose CCN publish–subscribe systems for fixed networksin which: (i) subscribers setup a multicast distribution treeamong CCN nodes by enhancing CCN with a name-basedSubscription Table [11] or by using permanent entries in


the PIT [10]; (ii) publishers push information items on sucha tree. To the best of our knowledge, this is the first paperthat exploits CCN for publish–subscribe MANET systems.

3. Motivations and challenges for using CCN in publish–subscribe MANET systems

The advantages of using CCN and in general the infor-mation centric network paradigm in fixed networks havebeen thoroughly discussed [2]; in this section we motivatethe use of this technology to realize topic-based publish–subscribe MANET systems, and discuss what we need toadd to CCN for this purpose.

3.1. Why CCN for publish–subscribe systems in MANETs?

To ease the development of publish–subscribe applica-tions, an application-developer usually exploits the API ofan underlying publish–subscribe system or middleware,such as DDS [8], JEDI [22] or Java Message Service [24].These systems provide developers with a publish–subscribe abstraction that hides the complexity of data dis-semination. The resulting functional architecture is shownin Fig. 2: TCP-UDP/IP layers expose an address-based/pushAPI (aka Socket) to the publish–subscribe system, whichdelivers information items from publishers to subscribersin an efficient and reliable way, and exposes to applicationdesigners a publish–subscribe API.

The realization of a publish–subscribe system on top ofthe TCP-UDP/IP API requires the development of a set ofcontent-oriented functionalities, including: a discoverymechanism that identifies the IP addresses of topic pub-lishers and/or subscribers, a protocol to express interestin specific information items (those of a topic) and retrievethem, a multicast distribution mechanism for efficient datadispatching, caching functionality, etc. In addition, thedesign of these functionalities is dependent on the targetednetwork environment.




Many literature papers discuss the design of publish–subscribe systems for MANETs (see [16] for a survey).However, most of them are studied only by means of sim-ulations; the few papers reporting actual implementationdo not make available the related software. In this context,the actual deployment of a topic-based publish–subscribeMANET application currently requires to develop boththe application logic and the underlying publish–subscribesystem (Fig. 2).

With respect to the publish–subscribe system develop-ment, we note that CCN natively offers most of therequested content-oriented functionalities, and its imple-mentation is open source and well documented [7]. There-fore, we believe it is convenient to use CCN since it stronglyreduces the effort of developing a topic-based publish–subscribe system. CCN provides multicast and in-networkcaching features which are very useful in critical networkenvironments, such as in MANETs. Moreover, CCN mobilenodes may store-carry-and-forward missing informationitems to subscribers located in parts of the network tempo-rarily disconnected by publishers, by using their caches.This opportunistic data muling is native in CCN and, aswe will see, it only requires a simple configuration of theCCN routing table.

3.2. Why CCN by itself is not sufficient to support publish–subscribe applications?

Albeit the CCN content-oriented functionalities are ofundeniable usefulness to publish–subscribe applications,the CCN API exposes them through a request (Interest) –response (Data) communication primitive, specificallydesigned for on-demand content delivery rather than forpublish–subscribe data dissemination. Using the Interest-Data interaction provided by the CCN API, a user mayrequest a ‘‘single’’ information item identified by nameand the content is sent back if ‘‘already’’ published. Con-versely, the subscriber of a topic-based publish–subscribeapplication demands for a ‘‘sequence’’ of information itemsidentified by the topic name, and these information itemswill be published ‘‘after’’ the subscription time. Conse-quently, the request-response CCN API cannot be used byitself to support publish–subscribe applications and wehave to introduce additional functionalities between theCCN layer and the publish–subscribe application, aimedat enhancing CCN with topic-based publish–subscribefunctionality.

Table 1Naming schemes.

Description Scheme Example

Topic prefix topic-name foo.newsPublisher prefix topic-name/publisher-id foo.news/

P1Information

item nametopic-name/publisher-identifier/sequence-number

foo.news/P1/1

4. Design choices

The development of a CCN topic-based publish–subscribe system requires specifying a naming schemeand a data dissemination model. This section describesthe general solutions that we envisaged; in Section 5 wewill present the proposed system as a whole and in details.

4.1. Naming scheme

Naming is the first design choice of a CCN-based systemor application. A proper naming choice reduces the


footprint on the routing plane and eases implementationthrough the CCN API.

A simple, nevertheless effective, naming scheme forinformation items of a topic-based publish–subscribe sys-tem is: topic-name/publisher-id/sequence-number. Thetopic-name component uniquely identifies a topic. Thepublisher-id component uniquely identifies the publisherof the topic (e.g. its MAC address or a random number).The sequence-number component is an incremental num-ber that uniquely identifies the information items issuedby a topic publisher. Overall, Table 1 reports the namingscheme that we consider.

4.2. Dissemination model

We envisage three different models to transfer informa-tion items from publishers to subscribers: pull, push, orhybrid push/pull. In this section we qualitatively describethese approaches, assuming the presence of a CCN routingprotocol that distributes routing prefixes and properly con-figures the CCN FIB of the nodes.

4.2.1. Pull modelThe Pull model can be deployed by using the plain CCN

architecture and its characteristic are:

(1) the CCN FIB of nodes contain entries related to pub-lisher prefixes that are used to route Interests ofinformation items toward relevant publishers;

(2) subscribers pull the information items produced bypublishers.

A CCN MANET routing protocol fills the FIBs of thenodes so that Interest messages containing the publisherprefix are forwarded towards the related publisher. Forinstance, in case of a proactive MANET routing protocol, apublisher may start the dissemination of routingannouncements containing the publisher prefix, similarlyto what happens in the case of BGP announcements of IPprefixes. This case is reported in Fig. 4, where the routingengine of publisher P1 announces the publisher prefix‘‘foo.news/P1’’. The announcement is disseminated by therouting protocol, which inserts the publisher prefix in theFIBs of the network nodes. Thus, for instance, the FIB ofnode N2 is filled with the entry ‘‘foo.new/P1’’ that uses face4 towards N1 as next-hop. In Section 6 we report a CCNMANET routing protocol, which we devised to supportour solution; nevertheless the pull model is independentof the CCN routing protocol.



S1

P1 N2

S2

InS1 (“foo.news/P1/1”)

Announce“foo.news/P1”

N1


S1

P1 N2

S2

Da(“foo.news/P1/1”)

N1


S1

P1 N2

S2


N1


1 2 3 4

5

68

7

Prefix Faces use

foo.news/P1/1 5,6 pull

PIT

Prefix Faces use

foo.news/P1 4 pull

FIB

Fig. 4. Pull model (In = Interest, Da = Data).


To fetch information items, subscribers send requests(i.e. Interests) for the next information items that will begenerated by the publisher and wait for the emission ofthe items. In Fig. 4(top) subscribers S1 and S2 request thefirst information item ‘‘foo.news/P1/1’’. The networkroute-by-name Interest messages towards the publisher.When the publisher produces the information item(Fig. 4-middle), the network sends it back within a Datamessage, using the multicast dispatching tree built bythe Interest messages. After the reception of the informa-tion item, the subscribers issue the request for the nextinformation item by increasing by one the sequence num-ber, then wait for it and so forth (see Fig. 4-bottom).

It is to be noted that the PIT entry lifetime is limited tofew seconds, so the multicast dispatching tree built byInterest messages has to be periodically renewed. Thisimplies the use of a polling mechanism, and Interest mes-sages have to be periodically resent, until the publishergenerates the requested information item. Polling is anundeniable inefficiency, but, by re-sending Interest mes-sages, subscribers refresh the topology of the multicastdispatching tree realized by the PITs; and this refreshoperation is anyhow necessary in any MANET multicastdistributing system, to cope with node mobility. In otherwords, the CCN MANET routing protocol is used to updatethe unicast routes from subscribers to publishers, whilethe Interest polling mechanism is exploited to updatethe multicast distribution trees from publishers tosubscribers.


4.2.2. Push modelThe characteristics of this dissemination model are:

(1) the CCN FIB of nodes contain entries related to topicprefixes that are used to route information items of atopic (new CCN Push messages) towards the rele-vant subscribers;

(2) publishers push the produced information items tothe subscribers.

A CCN routing protocol used in the MANET fills the FIBsof the nodes so that information items whose name con-tain a topic prefix are forwarded towards the subscribersof the relevant topic. For instance, in case of a proactiveMANET routing protocol, a subscriber may start the dis-semination of routing announcements containing the topicprefix (e.g. ‘‘foo.news’’) and the routing protocol uses theseannouncements to setup in the FIB a multicast dispatchingtree from publisher to subscribers.

When a publisher generates an information item, thenetwork uses the FIB entries to route-by-name the infor-mation items towards all subscribers. It is noteworthy that,differently from the pull model, in this case multicast dis-patching uses the FIB rather than the PIT.

To support the push model, CCN requires the introduc-tion of a new CCN message and of an appropriate multicastforwarding mechanism based on FIB information. The newdata-unit, here named Push message, is equal to a Datamessage but is forwarded using the FIB, rather than the




PIT. A Push message is relayed on each face that has a FIBprefix matching with the enclosed name and without stor-ing any status in the PIT. This modus operandi resemblesthe IP multicast forwarding, with the difference that it iscarried out using the name-based CCN FIB, rather thanthe address-based IP FIB.

For instance, in Fig. 5(top) we have two subscribers thatannounce the topic name ‘‘foo.news’’ on the CCN routingplane. Accordingly, a CCN routing protocol configures theFIBs of the nodes so that they forward the Push messageswith prefix ‘‘foo.news’’ towards the announcing subscrib-ers. The publisher P1 generates the first information item‘‘foo.news/P1/1’’ and inserts it in a Push message. Thismessage is forwarded (and in case cached) by intermediatenodes towards S1 and S2.

4.2.3. Hybrid push/pull modelThe Push model is theoretically more efficient than the

Pull approach since it does not have to poll Interests, anddo not use Interests at all. However, the Push approachlacks a fundamental aspect of publish–subscribe systems:the possibility of receiving information items also whenpublisher and subscriber are not connected at the produc-tion time or in case of data loss. This makes the Push modelintrinsically unreliable.

To provide reliability, a Push/Pull hybrid model may beused, in which Pull is only invoked to retrieve missingitems (e.g. inferred by out-of-delivery). In this case, therouting plane should handle routes toward both publishers(for Pull) and subscribers (for Push). For instance in Fig. 5(middle and bottom), subscriber S2 lost the first transmit-ted Data ‘‘foo.news/P1/1’’ and requests its retransmissionthrough an Interest-Data interaction with the N2 cache.

Retransmissi

P1

Pu(“foo.news/P1/

N1

Pu(“foo.news/P1/1”)

P1 N1


P1 N1

Ca“f

Prefix

foo.news

foo.news/

1 2 3 4

Fig. 5. Push and hybrid approaches (In


5. TPS-CCN: our Topic-based Publish–Subscribe CCNsystem

In this section we present our proposal for a Topic-based Publish–Subscribe CCN system (TPS-CCN). TPS-CCNfollows the naming scheme in Table 1 and it is based onthe Pull model presented in Section 4.2.1. TPS-CCN canprovide reliable and unreliable delivery. In the reliable case,the system guarantees the delivery of any informationitems, whereas in the unreliable case the loss of informa-tion items may occur.

The protocol stack is shown in Fig. 1. CCN is used inevery node; Interest and Data messages are routed-by-name hop-by-hop and thus CCN is the actual networklayer of the system, rather than IP. Data transfers betweenneighboring nodes are supported by UDP/IP CCN faces.Clearly the presence of UDP/IP in the stack increases thestratification overhead and complexity. However, we pointout that the UDP/IP layer is not strictly required by theTPS-CCN system since it only exploits the CCN API; butwe used UDP/IP in our prototype because the currentimplementation of CCN is unable to operate directly onthe MAC layer.

The TPS-CCN system is characterized by four proce-dures: Data Publish, Data Pull, Publisher Discovery andSync, and Delay Tolerant Mode. These procedures are exe-cuted on top of the CCN application programming interface(API).

5.1. Data Publish

The Data Publish procedure is executed by a TPS-CCNpublisher to make information items available to related

on (hybrid)

S1

N2

S2

1”)

S1

N2

S2

Announce“foo.news”

S1

N2

S2

che hit foroo.news/P1/1”

Faces use

5,6 push

P1 4 pull

5

68

7

FIB

= Interest, Da = Data, Pu = Push).



Cache - Content Store (CS)

Forwarding Informa�on Base (FIB)

Upstream Faces

room1.temp/P1 2

Pending Interest Table (PIT)

Downstream Faces0,1foo.news/P1/2

Face 2

Face 1

Face 0

foo.news/P1 0xc

Publisher (foo.news/P1)

Name Prefix

Name Prefix

Name Prefix

Data…

CCN node

Name Prefix

foo.news/P1/2

Name Prefix Data…foo.news/P1/1

Informa�on Item Repository (IIR)

Pending Interest Repository (PIR)

room1.temp/P1/9 2

Face 0xc

room1.temp/P1/8

Datasource

Fig. 6. Model of CCN node with a TPS-CCN publisher.


TPS-CCN subscribers. As shown in Fig. 6, the TPS-CCN pub-lisher is a CCN application connected to the underlyingCCN node through a local face, e.g. 0xc. The CCN FIB hasan entry related to the publisher prefix (e.g. ‘‘foo.news/P1’’) that points to the local face. The publisher has anInformation Item Repository (IIR) and a Pending InterestRepository (PIR). The data source stores each new informa-tion item in the IIR. In the case shown in Fig. 6 the sourcehas published and stored in the IIR the information item‘‘foo.news/P1/1’’. Differently from the Content Store, theIIR is a storage module that is completely controlled bythe publisher. Conversely, the publisher cannot controlwhat is stored by the Content Store since it is a cache forany forwarded Data, whose policy is internal to the CCNnode.

In case of an unreliable publish–subscribe system, theIIR only contains the last published information item. Incase of a reliable system, the IIR contains all the informa-tion items that have been published since a periodtime not greater than a reliability timeout. In case thereliability timeout is configured greater than maximumpublisher-subscriber disconnection period, then anypublished item is surely delivered. Clearly, a greater dis-connection period requires a greater memory for the IIR.However, in MANET environments the disconnectionperiod should be reasonable small (e.g. in the order ofminutes) to make feasible the applicability of currentmemory technology.

When a node receives an Interest message for a localTPS-CCN publisher and the related Data message is notcontained in the Content Store, the node uses the FIB toforward the Interest to the publisher application and alsostores reverse route information in the PIT. When theTPS-CCN publisher receives an Interest message, if therequested information item is available in the IIR, it isimmediately sent back to the underlying CCN node, whichwill forward it, consuming the related PIT entry. Con-versely, if the item is not available, because it has not beenproduced yet, then the Interest is stored in the PIR. Forinstance, in Fig. 6, the publisher has received an Interest


for the item ‘‘foo.news/P1/2’’ that is not yet publishedand this Interest is stored in the PIR (and also in the PIT).

The PIR is used to deliver an information item at theproduction time and without waiting for the next Interestpolling from the subscriber. Indeed, when a new informa-tion item is produced, if there is a pending Interest in thePIR, then the information item is immediately sent backto the CCN node, which will use the PIT information to for-ward the item towards the subscribers.

We note that the information contained in the PIR is asubset of that contained in the underlying PIT. However,the CCN API does not provide access to the contents ofthe PIT; thus, without the PIR, the TPS-CCN publisherwould be unaware of subscribers waiting for publishedinformation until the next Interest polling. The PIR entriesexpire after a time-out equal to the PIT one.

5.2. Data Pull

The Data Pull procedure is executed by a TPS-CCN sub-scriber to pull information items from the publishers. Incase of multiple publishers for the same topic, a subscribersets up a set of Data Pull procedures, one for each pub-lisher. The main difference with respect to Section 4.2.1is the introduction of a receiver window that makes it pos-sible to speed up data transfer in case of long round triptimes. Through a polling mechanism, a subscriber continu-ously maintains in the network a window W of Interests,referring to the next W information items that the sub-scriber wishes to fetch from a publisher. If W is equal to1, the interaction resembles to a receiver-driven stop-and-wait ARQ flow control mechanism, and thus the max-imum throughput is one information item per round triptime. If W is greater than one, the maximum throughputis obviously W items per round trip time and the flow con-trol mechanism resembles a receiver-driven Go-Back-NARQ.

Fig. 7 reports an example of Interest Data flow betweenthe subscriber S1 and the publisher P1. We consider areceiver window with size W = 2. At the beginning of the




interaction, the subscriber sends two Interest messages foritems n.1 and n.2, whose names are ‘‘foo.news/P1/1’’ and‘‘foo.news/P1/2’’ respectively. After a one-way transferdelay, the Interest messages reach the publisher, whichhas not yet published the related information items. At thismoment, the subscriber has two Interests in the networkfor the next two missing items. After some time, P1 pub-lishes the ‘‘foo.news/P1/1’’ information item and sendsthe related Data message. When S1 receives the Data mes-sage, it sends the Interest for the third item ‘‘foo.news/P1/3’’, so as maintaining in the network two Interests of thenext two missing items (‘‘foo.news/P1/2’’ and ‘‘foo.news/P1/3’’). After a polling timeout the Interest of ‘‘foo.news/P1/2’’ is re-emitted by the subscriber. This polling timeoutis equal to the timeout used by the network nodes toremove stale Interests from the PIT (aka Interest Lifetime).After a while, the publisher concurrently publishes theitems ‘‘foo.news/P1/2’’ and ‘‘foo.news/P1/3’’. Since W = 2,these two items have the related Interest pending in thenetwork and can be immediately sent back within Datamessages. When Data messages are received, the sub-scriber sends the Interest for next two missing segments,i.e. ‘‘foo.news/P1/4’’ and ‘‘foo.news/P1/5’’, and so forth.

5.3. Publishers Discovery and Sync

To pull information items from a publisher, a subscribershould know the name of published items, i.e. the compo-nents: (i) topic name (e.g. ‘‘foo.news’’), (ii) publisher-id(e.g. P1) and (iii) sequence number of the last producedinformation item. Assuming that the topic name is knowna priori, the subscriber periodically executes the PublisherDiscovery and Sync procedure to retrieve or update the lat-ter components.

The publisher-id component is derived by inspectingthe CCN FIB entries that contain the topic name(e.g. ‘‘foo.news’’). Indeed, the second component of these

In (“foo.news/P1/1”)

P1S1



PollingTimeOut

�me

Publica�on offoo.news/P1/1

One-way delay

Da (“foo.news/P1/1”)

In (“foo.news/P1/2”)Publica�on offoo.news/P1/2foo.news/P1/3

Da (“foo.news/P1/2”)Da (“foo.news/P1/3”)

In (“foo.news/P1/4”)In (“foo.news/P1/5”)

Fig. 7. Flow control with W = 2.


entries is the publisher-id. For instance in Fig. 4 the FIBcontains the entry ‘‘foo.news/P1’’, thus P1 is the pub-lisher-id of a publisher of the topic ‘‘foo.news’’.

After the discovery of the publisher-id component, asubscriber retrieves from the publisher its publishing status,i.e. the sequence number of the last published item and, incase of a reliable system, the sequence number of the old-est information item contained in the IIR. The publisherstores this control information in the IIR, by identifying itwith a unique name, known a priori by the subscribers.The related naming scheme is: topic-name/publisher-id/status (e.g. ‘‘foo.news/P1/status’’). A subscriber periodicallyfetches the publisher status by using the plain Interest-Data interaction. Since the publisher status is a dynamicdata whose name instead does not change, to avoid cach-ing inconsistency, the Data message that transports thepublisher status is configured as not-cacheable.

5.4. Delay tolerant network mode

The Delay Tolerant Network (DTN) mode is a distinctiveoperational mode of TPS-CCN system that is implementedby managing the entries of the CCN FIB. The DTN modeenables subscribers to receive information items evenwhen they are in a part of the network disconnected fromthe publisher one. The DTN mode can be triggered when asubscriber becomes aware of being disconnected from thepublisher. This can be inferred by the failure of a PublisherDiscovery procedure.

We present the DTN mode with an example. As shownin Fig. 8(top), in Normal mode (no DTN) the FIB ofsubscriber S2 has an entry for the publisher prefix ‘‘foo.-news/P1’’ that uses face 8 (unicast UDP socket), connectingS2 to the next node N2 of the path toward the publisher.When this path disappears because of network fragmenta-tion, face 8 is removed from the FIB by the routing proto-col, and the next Publisher Discovery procedure fails. Inthis condition, the subscriber cannot fetch published infor-mation since the generated Interests do not match any FIBentry and are not forwarded. However, information itemscould be available in the cache of a neighbor node. Toexploit this possibility, in case of a Publisher Discoveryfailure, a proximity FIB entry is added, with a face pre-configured as a multicast UDP socket. In this way, Interestmessages are radio broadcasted to all neighbor nodes thatsend back the information item, if they have it in the cache.

As shown in Fig. 8(middle and bottom), when S2 is inDTN mode it has a FIB entry for ‘‘foo.news/P1’’ pointingto face 10, which is a multicast socket. On this face, nodeS2 periodically sends the Interest message for the nextexpected item, i.e. ‘‘foo.news/P1/1’’. When S1 receives theData from N2, it stores the message in its cache. Then,assuming that S1 moves towards S2 and S1 and S2 get con-nected, the Interest sent by S2 on the multicast interfacereaches S1; then S1 sends back the cached Data. Thus, S2receives the information item even if it is disconnectedfrom the publisher. This delivery approach is also knowin the literature as ‘‘data muling’’ (where S1 is the mule)or ‘‘store carry and forward’’, and it is the core of delay tol-erant network forwarding mechanisms able to work infragmented networks.



S1

N2

S24

5

6 8 (unicast)

7

Prefix Faces use

foo.news/P1 8 pullFIB

S1

N2

S2

Prefix Faces use

foo.news/P1 10 pull

10 (mul�cast)

S1

N2

S2

Data from cache

Data cached



FIB

10 (mul�cast)

Normal mode

DTN mode

DTN mode

DTN mode

Fig. 8. DTN mode (In = Interest, Da = Data).


6. OLSR based CCN routing engine

TPS-CCN requires a CCN routing protocol. To the bestof our knowledge, implementations of CCN routing proto-cols for MANET are not available, even if some analyticaland simulation studies can be found e.g. in [29,30]. Thus,to test the effectiveness of TPS-CCN we developed aMANET CCN routing protocol. Our protocol is based onthe well-established OLSRd Linux daemon [28] of theOLSR protocol [27], enhanced by a new plug-in, namedCCNInfo, which distributes the location of each name pre-fix, i.e. the IP address of the announcing node. Combiningname prefix locations with the IP routing table providedby OLSR, a routing engine running on each node canreadily determine the next-hop for each announced nameprefix, i.e. the entries of the CCN FIB. As a result, the pro-tocol sets up CCN multi-hop routes, following the short-est path identified by OLSR. This OLSR evolutionaryapproach may not be the best in terms of efficiency,but it is practical, simple and effective. The usefulnessof the proposed routing tool (available in [23]) goesbeyond the performance test of our TPS-CCN, as it canbe used in any other framework needing a MANET CCNrouting mechanism.

The functional components of the routing toolare reported in Fig. 9. Each node has OLSRd and a


routing-by-name engine module. A User (the TPS-CCN sys-tem in our case) announces a name prefix, communicatingit to CCNinfo. The plug-in creates a CCNInfo OLSRannounce message (see [23], readme file), which containsthe tuple <nPrefix, destIP>, where nPrefix is the name pre-fix and destIP is the IP address of the announcing node.This message is flooded by OLSRd to all network nodesby using its default forwarding algorithm.

On each node, a routing-by-name engine module col-lects the received announcements in the nPrefix-to-destIPtable, whose entries have a validity period; after that theyare removed, if not refreshed. For each destIP, the routingengine derives which is the IP address of the next hop nodeby using the IP routing table provided by the OLSRd TxtInfoplug-in. The tuple <destIP, nextHopIP> is collected in thedestIP-to-nextHopIP table, which resembles an IP routingtable of entries with a /32 network mask.

Combining the information available in the two tables,nPrefix-to-destIP and destIP-to-nextHopIP, the routingengine computes which is the IP address of the next hopnode for each announced name prefix (nPrefix-to-nextHo-pIP computation); then these relationships are pushed inthe CCN FIB. To follow topology changes, the announce-ments are periodically resent, the destIP-to-nextHopIPtable is periodically refreshed, and the CCN FIB computa-tion is periodically repeated.



nPrefix to destIPtable

received prefix announcements

destIP to nextHopIPtable

nPrefix to nextHopIP

computa�on

/32 IP rou�ng table

CCN FIB

CCNx API

Rou�ng by Name Engine

User (e.g. TPS-CCN system)

CCNInfo TxtInfo

local prefixannouncements

remote prefixannouncements

OLSRd

Fig. 9. OLSR based CCN routing tool.


For instance, in Fig. 10 node P1 has IP address192.168.0.3 and announces the name prefix ‘‘foo.news/P1’’. Node S1 stores this information in the nPrefix-to-destIP. The destIP-to-nextHopIP table of node S1 indicates192.168.0.2 (N1) as next hop node towards 192.168.0.3(P1); thus, the CCN FIB is configured so that the upstreamface for ‘‘foo.news/P1’’ is an UDP socket towards 192.168.0.2 (N1).

P1 N1

192.168192.168.0.3

Prefix destIP

foo.news/P1 192.168.0.3

nPRefix to destIP


de

19

19

Prefix F

foo.news/P1 7CCNFIB

Fig. 10. CCNInfo routing


7. Performance evaluation

In this section we report a performance evaluation ofa Java implementation of the TPS-CCN system. We usedthe CCN implementation (aka CCNx) v0.7.2, OLSR withour CCNInfo plugin [23] and an emulation environmentmade up of Linux containers, whose setup has beencontrolled by the Common-Open-Research-Emulator(CORE) [14].

The aim of the performance evaluation is to understandthe effectiveness of TPS-CCN functionalities taking intoaccount MANET connectivity problems. To show theadvantages brought about by data muling, in-networkcaching and multicast of TPS-CCN, we also implementeda ‘‘basic’’ topic-based publish–subscribe system that onlyuses UDP sockets to transfer information items.

Fig. 11 shows the components of the UDP-based sys-tem. A publisher has a FIFO transmission queue for eachsubscriber. Each information item generated by the sourceis inserted in each queue. Each queue is controlled by anautonomous transfer process that sends queued items tothe related subscriber through UDP unicast sockets. Weimplemented both a reliable and an unreliable UDP-basedsystem. In the reliable case the first item of the queue issent to the subscriber within a UDP datagram; when theitem is received, the subscriber sends back an applicationlevel ACK message through an UDP message; the transmis-sion of the item is repeated by the publisher each PTO secuntil the ACK message is received, then the item isremoved from the queue and the next queued item istransferred. In the unreliable case the first item of thequeue is sent within a UDP datagram and immediatelyremoved from the queue, independently of its reception.

S1

192.168.0.1.0.2

stIP nextHopIP

2.168.0.2 direct

2.168.0.3 192.168.0.2

destIP to nextHop

aces IP

192.168.0.2

7

engine example.



S1

Datasource

FIFO of S1

FIFO of S2

FIFO of Sn

.

.

.

S2

Sn

Data

Ack

Data Data

Ack

Data

Ack

Publisher

Fig. 11. UDP-based publish–subscribe system.


We consider several scenarios whose configurationparameters are shown in Table 2. A possible use case of thisscenario is a group of Unmanned Ground Vehicles (UGV)reconnoitering a critical area (e.g. in the aftermath of adisaster). The real-time computing complexity of ouremulator limits to 15 the maximum number of nodes.Nevertheless, such a number is sufficient to understand

Table 2Emulation parameters.

Parameter Value

ScenarioN. nodes 15Mobility model Random way pointSpeed 2 m/s constantPause 5 s constantArea Up to 200 m � 200 mRadio 802.11 g at 54 Mbps constantTx range 50 mN. Publishers/topics {1, 2 or 3} with one publisher per

TopicN. Subscribers N. nodes – N. Publishers, uniformly

distributed on TopicsTraffic One new information item every 1.1 s

per publisherTest duration 20 min

CCN and TPS-CCNCCN cache size No-cache or 100 information-itemsTPS-CCN Polling Time Out

(PTO)4 s

TPS-CCN discovery timeout

3 * PTO

TPS-CCN reliabilitytimeout

5 min

TPS-CCN receiver windowW

3

RoutingProtocol type OLSR (OLSRd daemon)OLSR hello interval 1 sOLSR TC interval 3 sOLSR TC redundancy 2OLSR MPR coverage 7OLSR CCNInfo plugin

announce interval5 s

OLSR CCNInfo pluginannounce validity

200 s


the impact of TPS-CCN functionalities on performances,at least in a small scale MANET environment.

An emulation lasts for 20 min. During the first 18 min,the publishers generate a new information item every1.1s. The next two minutes are used to allow the possible‘‘delay-tolerant’’ delivery of last published informationitems through network movement. In doing so, weobtained the delivery of all published information itemsin case of reliable systems.

The measured performance parameters are: the meandelay between publishing time and receiving time, alsoknown as delivery delay; the ratio between the numberof received and sent information items, also known asdelivery ratio; and the number of packets transmitted bynetwork nodes (including OLSR routing data), normalizedto the number of delivered packets. The latter is a measureof the system efficiency in delivering information items.

At a first glance the area of the scenario (up to200 m � 200 m) may appear rather small if compared withthe radio coverage (50 m). However, we measured a signif-icant difference between radio connectivity and networkconnectivity (i.e. two nodes are connected if the routingprotocol can setup a radio path between them). It is thenetwork connectivity that impacts application perfor-mance. Fig. 12 reports the probability of having networkconnectivity between two random nodes. We consider dif-ferent mobility traces, for different lengths of the side ofthe scenario area and different numbers of nodes. To mea-sure the network connectivity, each node randomlyextracts a destination per second and sends an IP PING toit; if the PING is successful there is network connectivity.For an area of 200 m � 200 m the network connectivity isquite low because the routing protocol is not able toquickly reconfigure network paths, even though we usedOLSRd configuration parameters deemed to fit MANETscenarios.

Given these results we consider it meaningless to inves-tigate the performance of TPS-CCN for areas greater than200 m � 200 m, since TPS-CCN mechanisms are meant forMANETs scenarios in which the presence of an end-to-endpath is not a very rare event (the DTN mode helps in caseof partitioning but should not be the main mode of

Fig. 12. Network connection probability.




operation). Extremely sparse MANET scenarios wouldrequire procedures not included in TPS-CCN, such as con-trolled data replication [25] (and not only the simple en-route caching), DTN routing rather than plain OLSR [31],monitoring of node contacts, etc.

In what follows we present some of the results obtainedfor reliable and unreliable systems. Additional results arereported in Appendix A.

7.1. Reliable publish–subscribe system

In this section we focus on a reliable topic-based pub-lish–subscribe system, in which all published informationitems are, sooner or later, delivered in order to subscribers.To understand the effect of the TPS-CCN and CCN function-alities we consider:

– a TPS-CCN ‘‘Full’’ configuration, with data muling (i.e.DTN mode enabled), in-network caching (provided byCCN level caches) and multicast distribution functional-ities (provided by CCN PIT mechanisms);

– a TPS-CCN ‘‘no-DTN’’ configuration, with in-networkcaching and multicast distribution functionalities;

– a TPS-CCN ‘‘no-DTN/no-cache’’ configuration, with onlymulticast distribution functionalities;

– the ‘‘UDP-Acked’’ publish–subscribe system, withoutany of the above functionalities.

Fig. 13 reports the delivery delay in case of 2 topics ver-sus the length of the area side. The increase of the area sideleads to a valuable grow of the delivery delays due theincreasing occurrence of network partitioning events,which may disconnect publishers from subscribers formany seconds.

The performance difference between the Full and no-DTN configurations is due to the exploitation of data mul-ing. When DTN mode is disabled (no-DTN) subscriberslocated in parts of the network disconnected from the pub-lisher do not receive information items, even though theitems could be available on the CCN cache of close nodes.

Fig. 13. Mean delivery delay, reliable mode, 2 topics, 15 nodes.


Disconnected subscribers should wait that mobility createsan end-to-end path with the publisher to receive missingitems, and this waiting time increases the delay withrespect to the Full case, in which subscribers can fetch datafrom neighboring caches. We remind that disconnectionperiods are due not only to an actual absence of a radiopath, but also to reconfiguration lags of the routing proto-col. For instance, we measured that when two nodes get inradio coverage, then OLSRd spends about 3 s to recognizethis connectivity condition. In the 200 m � 200 m case, dis-connection periods occur frequently, and for both radioand routing issues. By decreasing the area, the durationof disconnection periods decreases as well and routingreconfiguration lags tend to be the principal disconnectioncause. Obviously, the shortening of disconnection periodsreduces the effectiveness of data muling as confirmed bythe results of Fig. 13, in which the Full vs. no-DTN perfor-mance gap tends to vanish as the scenario area decreases.

The performance difference between the no-DTN andthe no-DTN/no-cache configurations is due to the exploita-tion of CCN caches. The presence of in-network cachesreduce the length of the network path traversed by an infor-mation item to reach a subscriber, with a consequent reduc-tion of the delivery delay. The advantage of network pathreduction increases with the area of the scenario. In the200 m � 200 m case the network path reduction is valuableand the lack of CCN caches causes a considerable increase ofthe delivery delay. For smaller area side, network paths tendto shorten and caches produce a small reduction of the pathlength; thus, the no-DTN and no-DTN/no-cache configura-tions tend to show similar performance.

The performance difference between the no-DTN/no-cache and UDP-Ack is due to the network multicast dis-tribution provided by CCN PIT. The greater the networkpaths (as in the 200 m � 200 m case), the greater is theperformance benefit.

We can conclude that TPS-CCN provides better delaycontrol for large areas, in which path lengths and disconnec-tion periods are relevant. Clearly, delivery delays may behigh in case of fairly disconnected scenarios (e.g. 200 m �200 m), since we are considering a reliable publish–subscribe system and a long time may elapse before a sub-scriber gets connected with the publisher or finds the datain a neighbor cache (only for Full configuration).

Fig. 14 reports the mean delivery delay versus the num-ber of topics, in case of 15 nodes, for the 200 m � 200 mscenario. In the UDP-Ack case, performance is rather inde-pendent from the number of topics, since this solution isbased on point-to-point transmissions. Conversely, in theother three TPS-CCN configurations, there is a slight per-formance degradation at the increase of the number of top-ics. This is motivated by the smaller effectiveness of CCNcaching and multicasting at the decrease of the numberof subscribers per-topic (see Table 2), i.e. of the numberof users interested to the same information item.

By lowering the number of subscribers, the distributionof an information item involves a lower number of net-work nodes and a lower number of in-network caches.Such a lower replication of information items decreasesboth the probability of finding the item in a cache andthe number of data mules. In addition, by lowering the



1 2 30

0.5

1

1.5

2

2.5

3

3.5

4

4.5x 10

4

number of topics

mea

n de

liver

y de

lay

(ms)

no DTN

no DTNno cacheFull

UDP Ack

Fig. 14. Mean delivery delay, reliable mode, 200 m � 200 m, 15 nodes.


number of subscribers the effectiveness of a multicast dis-tribution with respect to a unicast one (e.g. the UDP-Ack)tends to vanish. Overall, we can conclude that the effective-ness of the TPS-CCN functionalities increases with the scale ofthe distribution.

Fig. 15 reports the number of packets transmitted bynetwork nodes (including OLSR data), normalized to thenumber of delivered packets vs the area size. Performancedifferences show up at the increase of the area. With respectto the no-DTN configuration, the Full one may consumemore network packets since, when a subscriber is discon-nected from the publisher, it sends out Interest messagesto probe the presence of information items in neighboringcaches; this does not happen in the no-DTN configuration.With respect to the no-DTN/no-cache case, in large areasthe DTN overhead tends to be compensated by the ineffi-ciencies due to the absence of in-network caches.

Fig. 16. Delivery ratio, unreliable mode, 200 m � 200 m, 15 nodes.

7.2. Unreliable publish–subscribe system

In this section we analyze an unreliable publish–sub-scribe system. Again, we consider four configurations: Full,no-DTN, no-DTN/no-cache, and UDP without Ack.

100 150 2000

1

2

3

4

5

6

7

8

area side (m)

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

no DTNno DTNno cacheFull

UDP Ack

Fig. 15. Number of transmitted packets per delivered information item,reliable mode, 2 topics, 15 nodes.


Figs. 16 and 17 show the delivery ratio in an area of200 m � 200 m versus the number of topics, and in caseof 2 topics versus the length of area side, respectively.The delivery ratio is the rate between the overall numberof information items received by subscribers and the over-all number of items that the subscribers would havereceived in absence of loss (e.g. due to the temporaryabsence of network connectivity). The difference betweenthe Full and the no-DTN cases is rather limited and thisimplies that the impact of data muling on delivery ratiois limited too. Conversely, the difference between the no-DTN case and the no-DTN/no-cache case is valuable, espe-cially for large areas. Therefore CCN caches have a relevantimpact on delivery ratio. Without cache, the delivery ratioperformance resembles the one of the simple UDP system.

Fig. 16 shows that the performance of CCN configura-tions decreases at the increase of the number of topics.As we already discussed for the reliable system, this isdue to a decrease of the TPS-CCN effectiveness at thereduction of the number of subscribers per topic. More-over, the performance differences reported in Fig. 17 indi-cate (again) that the effectiveness of TPS-CCN increaseswith the area side.

Fig. 17. Delivery ratio, unreliable mode, 2 topics, 15 nodes.




Fig. 18 reports the mean delivery delay in case of anarea of 200 m � 200 m versus the number of topics.Fig. 19 reports the delivery delay in case of 2 topics versusthe length of area side. These results could be misunder-stood if we do not take into account that delays areevaluated only on delivered information items, and thatdifferent configurations provide a different number ofdeliveries (Fig. 16), especially for large areas. Exploitingthe CCN caches available in the Full and no-DTN configura-tions, the subscribers are able to gather missing informa-tion items even several seconds after the emission time.Therefore, the delivery ratio is high but delivery delaysmay be very long and this increases the mean delay value.

However, if delays are not suitable for the application,CCN makes it possible to configure the maximum storingtime of an information item in a cache. In absence ofcaches (no-DTN/no-cache and UDP) either the informationitem is successfully delivered when emitted or it is lost.Thus, the number of delivered information items is low,but all delays are short. In some configurations, the delaytends to slightly decrease as the number of topics

1 2 30

0.5

1

1.5

2x 10

4

number of topics

mea

n de

liver

y de

lay

(ms)

no DTNno cache

no DTN

UDPwithoutAck

Full

Fig. 18. Mean delivery delay, unreliable mode, 200 m � 200 m, 15 nodes.

100 150 2000

0.5

1

1.5

2x 10

4

area side (m)

mea

n de

liver

y de

lay

(ms)

Full no DTNno DTNno cache

UDPwithoutAck

Fig. 19. Mean delivery delay, unreliable mode, 2 topics, 15 nodes.


increases. This is related to the decrease of the deliveryratio: indeed a lower number of aged items are delivered.

8. Conclusions

The use of an Information Centric Networking technol-ogy like CCN simplifies the development of topic-basedpublish–subscribe systems, while providing valuableperformance in terms of service reliability and latency incritical mobile environments, like MANETs. Indeed, datamuling, caching and multicasting are very useful in theseconditions and they are built-in in CCN.

Pull and Push are the two dissemination models onwhich publish–subscribe CCN systems may be based. ThePull approach can be developed by using the CCN architec-ture without modifying it, but requires polling, which ingeneral leads to an undesirable overhead. However, in caseof MANETs, polling is used also to refresh the topology ofthe dispatching multicast tree, which otherwise shouldbe done with other means. Following this consideration,we have developed a pull based publish–subscribe system,namely TPS-CCN. The performance evaluation of ourTPS-CCN system shows that the effectiveness of the CCNfunctionality increases with the area side and with thenumber of subscribers, i.e. with the distribution scale.And both these aspects are promising.

Acknowledgments

This works is partially founded by BEE SAFE, a PORPuglia (Italy) research project lead by Sistemi SoftwareIntegrati, a Finmeccanica Company, by the EU-JP co-fundedProject GreenICN (FP7 grant agreement N. 608518 andNICT Contract N. 167) and by the EU CONFINE project(FP7 grant agreement N. 288535). We thank Claudio Pisafor the implementation of the CCNInfo OLSR plugin.

Appendix A: additional performance results

A.1. Comparison with IP reliable multicast

In this section we compare the TPS-CCN ‘‘Full’’ configu-ration operating in reliable mode with IP reliable multicast.IP reliable multicast is a traditional way to supporttopic-based publish–subscribe with IP means. Each topicis associated to a multicast group and to a related multicastdistribution tree. Publishers send information itemsthrough IP multicast packets that are received by subscrib-ers that belong to the multicast distribution tree. Weimplemented this IP multicast distribution by using theOLSRd BMF plugin and the OpenPGM tool [12], an opensource implementation of the Pragmatic General Multicast(PGM) protocol. Both tools are used with their default con-figuration and we used the ‘‘daytime’’ command of Open-PGM to generate and send information items. OpenPGMis the only implementation of a distributed one-to-manydelivery system that we could find available on the Web,even if other multicast protocols, better tailored forMANET, have been proposed (e.g. [36]), as well as topic-based publish–subscribe systems.



100 150 2000

0.5

1

1.5

2

2.5

3

3.5

4x 10

4

area side (m)

mea

n de

liver

y de

lay

(ms)

Full

IP reliable multicast

Fig. 20. Mean delivery delay, reliable mode, 2 topics, 15 nodes.

100 150 2000

1

2

3

4

5

6

7

8

area side (m)

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

Full IP reliable multicast

Fig. 21. Number of transmitted packets per delivered information item,reliable mode, 2 topics, 15 nodes.

1 2 30

0.5

1

1.5

2

2.5

3

3.5

4x 10

4

number of topics

mea

n de

liver

y de

lay

(ms)

Full

IP reliable multicast

Fig. 22. Mean delivery delay, reliable mode, 200 m � 200 m, 15 nodes.

1 2 30

2

4

6

8

10

number of topics

tx p

acke

t per

del

iver

ed in

form

atio

n ite

m

IPreliablemulticast

Full

Fig. 23. Number of transmitted packets per delivered information item,reliable mode, 200 m � 200 m, 15 nodes.

0 1 2 3 4 50

1000

2000

3000

4000

5000

6000

7000

8000

9000

0 1 2 3 4 50

50

100

150

200

receiver window W

mea

n de

liver

y de

lay

(ms)

Area 100m x 100m Area 200m x 200m

Fig. 24. Mean delivery delay, unreliable mode, 1 topic, 15 nodes versusreceiver window W.



In all tests all published items have been indeed deliv-ered. Fig. 20 shows that, with respect to IP multicast,TPS-CCN reduces the latency as the coverage areaincreases, i.e. when network connectivity decreases. Thisreduction is mainly due to CCN in-network caching andTPS-CCN data muling.

Fig. 21 reports the packets transmitted by the devicesper delivered item. When the network is likely fully con-nected at one hop (i.e. in the 100 m case), IP reliable mul-ticast generates the lowest amount of packets, since itexploits MAC broadcast frames, while TPS-CCN uses UDP/IP unicast sockets (unless when in DTN mode) and MACunicast frames. As the area increases, the network is morefragmented, the number of retransmissions increases andin-network caching makes the retransmission path ofTPS-CCN shorter than the one of IP reliable multicast,which is necessarily rooted at the source. This reductionof path length tends to compensate the inefficiency ofusing unicast sockets and the difference between the num-ber of transmitted packets decreases.



0 1 2 3 4 50

1

2

3

4

5

6

7

receiver window W

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

0 1 2 3 4 50

1

2

3

4

5

6

7Area 100m x 100m Area 200m x 200m

Fig. 25. Number of transmitted packets per delivered information item,unreliable mode, 1 topic, 15 nodes versus receiver window W.

1 2 30

2

4

6

8

10

number of topics

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

Full

no DTNno cache

UDP Ackno DTN

Fig. 26. Number of transmitted packets per delivered information item,reliable mode, 200 m � 200 m, 15 nodes.

1 2 30

2

4

6

8

10

12

14

16

number of topics

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

Full

no DTN no DTNno cache

UDP without Ack

Fig. 27. Number of transmitted packets per delivered information item,unreliable mode, 200 m � 200 m, 15 nodes.

100 150 2000

2

4

6

8

10

12

area side (m)

tx p

acke

ts p

er d

eliv

ered

info

rmat

ion

item

Full

no DTN

no DTNno cache

UDP without Ack

Fig. 28. Number of transmitted packets per delivered information item,unreliable mode, 2 topics, 15 nodes.


Figs. 22 and 23 report the same performance measure-ments versus the number of topics. Also in this case thelatency of TPS-CCN is better than the one of IP reliable mul-ticast, while the number of transmitted packets per deliv-ered item is similar.

A.2. Analysis of receiver window

In this section we analyze the impact of the receiverwindow size W used by subscriber flow control mecha-nism on the performance (Fig. 7). We report the simplecase of a system with one topic and TPS-CCN ‘‘Full’’ config-uration operating in unreliable mode. The derived observa-tions also hold for system with two and three topics and incase of reliable operative mode, although related resultsare not reported here.

Fig. 24 reports the mean delivery delay versus W withan area size equals to 100 m and 200 m. As the receiverwindow W increases, the delay tends to decreases, but


beyond W = 3 the delay reduction is very limited. Fig. 25reports the number of transmitted packets per deliveredinformation item. By increasing W we have an increase ofthis merit figure, i.e. a reduction of the delivery efficiency,since subscribers maintain in the network an higher num-ber W of Interest, which are periodically resent to refreshthe publisher-to-subscriber multicast dispatching tree.We note a quick growth between W = 3 and W = 4. Com-paring Figs. 24 and 25 we observe that W = 3 provides adelay/efficiency trade-off.

A.3. Additional results on delivery efficiency

In this section we report the number of transmittedpackets per delivered information item measured in thecases examined in Sections 7.1 and 7.2. As discussed inSection 7, these results confirm that TPS-CCN full configu-ration provides valuable results in terms of delivery effi-ciency (see Figs. 26–28).




References

[1] R. Buyya, M. Pathan, A. Vakali, Content Delivery Networks, Springer,2008.

[2] D. Trossen, M. Sarela, K. Sollins, Arguments for an information-centric inter-networking architecture, ACM Comput. Commun. Rev.(2010). April.

[3] M. Gritter, D.R. Cheriton, TRIAD: A New Next-Generation InternetArchitecture. Technical Report, July 2000, <http://gregorio.stanford.edu/triad/>.

[4] V. Jacobson, D.K. Smetters, J.D. Thornton, et al. Networking namedcontent, proc. of ACM CoNEXT., 2009.

[5] A. Detti, M. Pomposini, N. Blefari-Melazzi, S. Salsano, Supporting theweb with an information centric network that routes by name,Comput. Networks 56 (17) (2012) 3705–3722.

[6] M. Hoque, S.O. Amin, A. Alyyan, B. Zhang, L. Zhang, L. Wang, NLSR:named-data link state routing protocol, in: Proc. of ACM SIGCOMM2013, ICN Workshop, Hong-Kong, August 12, 2013.

[7] CCNx Project Web Site <www.ccnx.org>.[8] Object Management Group, Data Distribution Services for Real Time

Systems, Version 1.2, OMG, January 2007.[9] P.T. Eugster, P.A. Felber, R. Guerraoui, A. Kermarrec, The many faces

of publish/subscribe, ACM Comput. Surv. 3 (2) (2003).[10] A. Carzaniga, M. Papalini, A.L. Wolf, Content-based publish/subscribe

networking and information-centric networking, in: Proc. of ACMSIGCOMM 2011, ICN Workshop, Toronto, Canada, 19 August 2011.

[11] J. Chen, M. Arumaithurai, L. Jiao, X. Fu, K.K. Ramakrishnan, COPSS: AnEfficient Content Oriented Publish/Subscribe System, In: Proc. ofACM/IEEE Symposium on Architectures for Networking andCommunications Systems (ANCS), 2011.

[12] OpenPGM Implementation. <https://openpgm.googlecode.com/files/libpgm-5.2.122.tar.bz2>.

[13] BEE DDS. <http://www.beedds.com>.[14] Common Open Research Emulator (CORE). <http://

www.nrl.navy.mil/itd/ncs/products/core>.[15] M. Varvello, I. Rimac, U. Lee, L. Greenwald, V. Hilt, On the design of

content-centric manets, in: Proc. of WONS’2011, Bardonecchia, Italy,Jan. 2011.

[16] R. Baldoni, A. Virgillito, Distributed event routing in publish/subscribe communication systems: a survey, DIS, Universita’ diRoma ‘‘La Sapienza’’, Tech. Rep., 2005.

[17] Yongqiang Huang, Hector Garcia-Molina, Publish/Subscribe TreeConstruction in Wireless Ad-Hoc Networks, Mobile DataManagement, Springer, Berlin, Heidelberg, 2003.

[18] Sèbastien Baehni, Chirdeep Singh Chhabra, Rachid Guerraoui,‘‘Frugal Event Dissemination in a Mobile Environment’’Middleware 2005, Springer, Berlin Heidelberg, 2005.

[19] Y. Huang, H. Garcia-Molina, Publish/subscribe in a mobileenvironment, in: Proc. of 2nd ACM International Workshopon Data Engineering for Wireless and Mobile Access (MobiDE),2001.

[20] E. Anceaume, A.K. Datta, M. Gradinariu, G. Simon, Publish/subscribescheme for mobile networks, in: Proc. of the 2002 Workshop onPrinciples of Mobile Computing (POMC 2002).

[21] G.P. Picco, G. Cugola, A.L. Murphy, Efficient content-based eventdispatching in the presence of topological reconfiguration, in: Proc.of 23rd International Conference on Distributed Computing Systems(ICDCS 2003), 19–22 May 2003, Providence, RI, USA.

[22] G. Cugola, E. Di Nitto, A. Fuggetta, The JEDI event-basedinfrastructure and its application to the development of the OPSSWFMS, in: IEEE Transactions on Software Engineering, vol. 27, no. 9,pp. 827, 850, Sep 2001.

[23] Source Code of OLSR CCN Routing Tool. <http://netgroup.uniroma2.it/Andrea_Detti/OlsrCCN/OLSR-CCN-Routing.tar.gz>.

[24] M. Hapner, R. Burridge, R. Sharma, J. Fialli, K. Stout, Java MessageService, Sun Microsystems Inc., Santa Clara, CA, 2002.

[25] T. Spyropoulos, K. Psounis, C.S. Raghavendra, Spray and wait: anefficient routing scheme for intermittently connected mobilenetworks, in: Proc. of the 2005 ACM SIGCOMM Workshop onDelay-Tolerant Networking (WDTN ‘05). ACM, New York, NY, USA,pp. 252-259.

[26] Kevin Fall, A delay-tolerant network architecture for challengedinternets, in: Proc. of the ACM SIGCOMM, 2003.


[27] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol, IETFRFC 3626.

[28] OLSRd Project. <https://www.olsr.org>.[29] Varvello, Matteo, et al., On the design of content-centric MANETs, in:

Proc. of IEEE Wireless On-Demand Network Systems and Services(WONS), 2011.

[30] A. Marica, A. Molinaro, G. Ruggeri, E-CHANET: routing, forwardingand transport in information-centric multihop wireless networks,Comput. Commun. 36 (7) (2013) 792–803.

[31] J. Ott, D. Kutscher, C. Dwertmann, Integrating DTN and MANETrouting, in: Proceedings of the 2006 SIGCOMM Workshop onChallenged Networks, ACM, 2006.

[32] R. Baldoni, R. Beraldi, G. Cugola, M. Migliavacca, L. Querzoni,Structure-less content-based routing in mobile ad hoc networks,in: Proc. of IEEE International Conference on Pervasive Services(ICPS’05), 2005.

[33] P. Costa, C. Mascolo, M. Musolesi, G.P. Picco, Socially-aware routingfor publish–subscribe in delay-tolerant mobile ad hoc networks,IEEE J. Sel. Areas Commun. 26 (5) (2008) 748–760.

[34] L. Wang, A.K.M.M. Hoque, C. Yi, A. Alyyan, B. Zhang, OSPFN: An OSPFbased routing protocol for Named Data Networking, University ofMemphis and University of Arizona, Tech. Rep. <http://new.named-data.net/wp-content/uploads/TROSPFN.pdf>, July 2012.

[35] Ren Zhong, Mohamed A. Hail, H. Hellbruck. CCN-WSN-A lightweight,flexible Content-Centric Networking protocol for wireless sensornetworks, in: Proc. of IEEE Eighth International Conference ofIntelligent Sensors, Sensor Networks and Information Processing,2013.

[36] L. Junhai, Y. Danxia, X. Liu, F. Mingyu, A survey of multicastrouting protocols for mobile ad-hoc networks, in: IEEECommunications Surveys & Tutorials, vol. 11, no. 1, First Quarter2009, pp. 78–91.

[37] G. Xylomenos, C. Ververidis, V. Siris, N. Fotiou; C. Tsilopoulos, X.Vasilakos, K. Katsaros, G. Polyzos George, A Survey of Information-Centric Networking Research, in: Communications Surveys &Tutorials, IEEE, vol. 16, no. 2, Second Quarter 2014, pp. 1024–1049.

Andrea Detti (http://netgroup.uniroma2.it/people/faculties/andrea-detti/) is an assistantprofessor of the Department of ElectronicEngineering of the University of Rome ‘‘TorVergata’’. The research activity of Andrea Dettispans on different topics in the area of com-puter networks and copes with frameworkdesign, analytical modeling, performanceevaluation through simulation and test-bed.He is co-author of more than 50 papers onjournals and conference proceedings, mainlyregarding information-centric, software-

defined, overlay, wireless and optical networks. Currently sis the researcharea is focused on information-centric (or data-centric, content-centric)network (ICN), software defined networks (SDN).
Andrea Detti has worked and works on the several competitive interna-tional projects. Some of them are: EU-JP FP7 GreenICN 2013/2015 (energyefficient ICN), EU FP7 2013/2014 CONFINE (coordinator of two proposalsadmitted to the funding within the first and second open-call, ICN andSDN topics), EU FP7 2012/2013 OFELIA (ICN over SDN), FP7 (2010/2013)CONVERGENCE (pub-sub ICN), EU FP7 2010/2013 FLAVIA (Virtualizablewireless future Internet), EU FP6 2004/2005 E2R (End-to-end reconfigu-rability), EU FP7 2006/2008 SMS (Simple Mobile Service), etc. Further-more, since 2006 Andrea Detti is scientific coordinator of severalindustrial projects (funded by Telecom Italia and SSI/Finmeccanica),which regard the support of data-centric publish–subscribe paradigmover mobile ad-hoc networks (MANET), Delay Tolerant Network (DTN)and cellular network. Andrea Detti is guest editor of two special issuesabout information-centric for the following journals: (1) Elsevier Com-puter Network, (2) Journal of Internet Technology. And he served asreviewers of numerous journal and conference (mainly ACM, IEEE, Else-vier).

http://refhub.elsevier.com/S1570-8705(14)00151-6/h0005






http://gregorio.stanford.edu/triad/

http://gregorio.stanford.edu/triad/




https://www.ccnx.org



http://www.beedds.com

http://www.nrl.navy.mil/itd/ncs/products/core

http://www.nrl.navy.mil/itd/ncs/products/core









http://netgroup.uniroma2.it/Andrea_Detti/OlsrCCN/OLSR-CCN-Routing.tar.gz






https://www.olsr.org







http://new.named-data.net/wp-content/uploads/TROSPFN.pdf

http://new.named-data.net/wp-content/uploads/TROSPFN.pdf

http://netgroup.uniroma2.it/people/faculties/andrea-detti/

http://netgroup.uniroma2.it/people/faculties/andrea-detti/



Dimitri Tassetto is a PhD student at theUniversity of Rome ‘‘Tor Vergata’’. Hisresearch interests are on the distribution andutilization of cognitive information in wire-less mobile networks. Accordingly his studiesfocussed on recovery, use and distribution ofenvironmental information. Redarding thedistribution, he is considering pub-subapproach on top of Information Centric Net-work technologies.

Nicola Blefari-Melazzi (http://blefari.eln.uni-roma2.it) is a Full Professor of Telecommuni-cations at the University of Rome ‘‘TorVergata’’, Italy. He is the Director of theDepartment of Electronic Engineering. He hasparticipated in over 30 international projects;he has been the principal investigator of threecooperative EU funded projects. He has beenan evaluator for many research proposals(both in the 6th and in the 7th EU FPs) and areviewer for numerous EU projects. He isauthor/coauthor of about 180 papers, in

international journals and conference proceedings. His research interestslie in the performance evaluation, design and control of telecommuni-cations networks.


Francesco Fedi (PhD) is Technical Head ofSistemi Software Integrati research on theData Distribution Service (DDS) middleware.His research interests span on the support ofDDS in MANET environments and on the useof DDS system to in complex systems withunmanned vehicles and robots. He has coor-dinated several national research projects andhas been involved in several EU projects.


http://blefari.eln.uniroma2.it

http://blefari.eln.uniroma2.it


Documents

Exploiting content centric networking to develop topic-based, publish–subscribe MANET systems