user-centric context data collection and provision harnessing content-centric networking paradigm

INTERNATIONAL JOURNAL OF NETWORK MANAGEMENTInt. J. Network Mgmt 2014; 24: 48–69Published online 21 November 2013 in Wiley Online Library (wileyonlinelibrary.com) DOI: 10.1002/nem.1851

User-centric context data collection and provision harnessingContent-Centric Networking paradigm

Sin-seok Seo,1 Joon-Myung Kang,2,*† Alberto Leon-Garcia,2 Yoonseon Han3

and James Won-Ki Hong1,3

1Department of Computer Science and Engineering, POSTECH (Pohang University of Science and Technology), Korea2Department of Electrical and Computer Engineering, University of Toronto, Canada

3Division of IT Convergence Engineering, POSTECH (Pohang University of Science and Technology), Korea

SUMMARY

A comprehensive context management approach is necessary in the era of ubiquitous technologies, andefficient context data collection is one of the most fundamental and important processes for realizing com-prehensive context management. Traditional context data collection approaches are based on TransmissionControl Protocol (TCP) or User Datagram Protocol (UDP) over Internet Protocol (IP), which has severaldisadvantages, such as lack of efficient mobility support, security and data transfer efficiency. Content-Centric Networking (CCN), on the other hand, provides advantages in terms of mobility, security andbandwidth efficiency in comparison with IP. In this paper, we introduce our user-centric comprehensivecontext management framework, and propose a secure and efficient context data collection and provisionapproach based on the framework using CCN as a network and transport layer. This context collectionapproach provides a flexible security mechanism by introducing three levels of security type. It alsoprovides bandwidth efficiency by taking advantage of CCN’s content caching; performance evaluationresults show that our approach can reduce bandwidth consumption up to 99% for pull and up to 46% forpush in comparison to a UDP/IP-based system. Our approach also provides advantages in supportingmobility and leveraging multiple interfaces. Copyright © 2013 John Wiley & Sons, Ltd.

Received 6 March 2013; Revised 18 August 2013; Accepted 2 October 2013

1. INTRODUCTION

Various new types of valuable context data are becoming available thanks to recent improvements insensing- and mobile-related technologies, such as smartphones [1], Internet of Things (IoTs) [2], U-Health [3] and Intelligent Transportation Systems (ITSs) [4]. For example, accurate location data ofa user can be easily obtained from the user’s smartphone equipped with a GPS sensor, and the locationdata can be utilized for useful services, such as a service that recommends nearby shopping mallsoffering discounts. These useful context data related to a user’s environment are becoming availablemore readily from different context domains,1 including mobile devices, smart homes, wearablesensors or social networking services.With respect to the improvements, a substantial research effort to manage and utilize context data

obtained from various sensors has been proposed [1,3–8]. The main concern of these existingapproaches is utilizing context data obtained from a single domain. For instance, Chon and Cha [7]proposed a smartphone application that provides a user’s precise location by using contexts obtainedfrom only a smartphone domain, and Kim et al. [8] proposed a smart home service that infers a user’s

*Correspondence to: Joon-Myung Kang, Department of Electrical and Computer Engineering, University of Toronto,Toronto, Ontario M5S 3G4, Canada.†E-mail: [email protected] define a domain as a collection of sensors that are located in a specific device, such as a smartphone, or an area, such as ahouse, to collect context data.

Copyright © 2013 John Wiley & Sons, Ltd.

49CONTEXT COLLECTION AND PROVISION HARNESSING CCN

sleeping status by using contexts obtained from only a smart home domain. However, if we considerthese different context domains are interconnected via a specific user, then we can provide more usefuland novel context-aware services by aggregating and associating the diverse types of context data dis-tributed over multiple domains around a user. Accordingly, we need a comprehensive context manage-ment approach that governs multiple context domains related to a specific user at the same time.Let us describe the benefits of the comprehensive context management in a formal way as follows:

Di ¼ si1; si2…; sijg 1≤ i≤mð Þ�(1)

Ci ¼ ci1; ci2…; cikf g (2)

I Dið Þ ¼ Ci (3)

I D1ð Þ∪I D2ð Þ…∪I Dmð Þ ¼ C1∪C2∪…∪Cm (4)

I D1∪D2…∪Dmð Þ ¼ C1∪C2∪…∪Cm∪Cα (5)

Di represents an ith domain, which consists of j sensors, and there exist m domains. Ci represents aset of contexts that are inferred using raw data obtained from sensors of Di; I(Di) is a function thatinfers Ci from Di. Equation 4 represents a single domain context management approach, in which caseeach Ci is inferred separately from Di. This approach can obtain simply a union of all the separate con-texts, i.e. C1�Cm, and additional context inference is not possible. Equation 5, on the other hand, rep-resents a comprehensive context management approach that governs multiple domains at the sametime, and it can infer additional context, Cα, in comparison with equation 4. The opportunity for theinference of Cα stems from the fact that the inference function, I(Di), can utilize additional data, whichare not available in a single domain approach, for inferring new contexts in two ways: (a) integrateduse of multiple sensor data obtained from two or more domains and (b) recursive use of contexts,which are inferred from two or more domains, to infer more abstract contexts.Figure 1 shows an example of the comprehensive context management approach. In this example, a user is

related to two context domains, which are a smartphone and a smarthome, and each domain has its own sen-sors. Using a single domain context management approach, either the smartphone or the smarthome domaincan provide only separate contexts, such as the user’s location from the smartphone domain or existence of auser (but does not know who the user is unless the user is the only resident) in a specific room from thesmarthome domain. If we use the comprehensive approach, on the other hand, we can provide additional con-texts, i.e. Cα, by combining data obtained from the two domains. For example, we can infer a specific user’sexact activity at home (i.e. a father is watching TV with his son in the living room). This is possible by com-bining the user’s location context from the smartphone and appliance states context from the smarthome.To realize the comprehensive context management, we have proposed a user-centric context

management framework [9] that aggregates and associates diverse types of context data obtained frommultiple domains, including other users’ domains, around a specific user. By applying this comprehen-sive approach, we can provide more convergent, diverse, and ubiquitous context-aware services incomparison with traditional single domain context management approaches.A fundamental and important step for comprehensive context management is context data collec-

tion. Traditionally, most context data collection approaches have used Transmission Control Protocol(TCP) or User Datagram Protocol (UDP) over Internet Protocol (IP) as a network and transport layer.IP-based applications, however, have to implement additional functionalities to provide mobility,security or data transfer efficiency. To overcome these limitations, Content-Centric Networking

Figure 1. An example of comprehensive context management

Copyright © 2013 John Wiley & Sons, Ltd. Int. J. Network Mgmt 2014; 24: 48–69DOI: 10.1002/nem

50 S.-S. SEO ET AL.

(CCN) [10] has been proposed as a new approach for data communications that focuses on the contentitself rather than the destination host. We envision that CCN is a promising candidate for context datacollection and provision because it has the following advantages. First, CCN can reduce bandwidthconsumption by providing long-term cache placed in a CCN node like Content Delivery Networks(CDNs) [10,11]. Second, CCN provides an inherent and flexible security mechanism that can be usedto protect private and important context data [10,12–14]. Third, CCN supports better mobility thantraditional IP-based approaches because the CCN naming scheme is independent from the locationof content [10,14,15]; this is desirable for highly mobile devices like smartphones. Finally, CCNcan take full advantage of multiple interfaces, e.g. WiFi and 3G, for collecting context data becauseCCN has a loop-free content delivery mechanism [10,16].In this paper, we introduce our user-centric comprehensive context management framework [9], and

propose a secure and efficient context data collection and provision approach based on the frameworkusing CCN as a network and transport layer. The proposed approach mainly consists of four modules:Security, Resource Management, Context Collection and Context Provision. The Security Moduleprovides basic concepts and information for context data protection. It introduces concepts of threetypes of security for fine-grained context data protection: Provider-, Collector- and Group-based.The Resource Management Module governs the relationships between context collectors and pro-viders. It consists of Registration, Maintenance and De-registration processes; each of the processesmakes a decision referring to the information provided by the Security Module. The ContextCollection and Provision Modules actually collect or provide context data with four different optionsfor either context data pull or push. These four options have advantages and disadvantages in terms ofbandwidth consumption, cache efficiency, initial transport delay and processing overhead.Our approach provides flexible and inherent security by encrypting every item of context data

with three different types of encryption key. The three key types allow administrators or users toapply an appropriate level of protection on their context data depending on their value and charac-teristics. Moreover, the proposed approach provides efficiency in terms of bandwidth consumptionby taking advantage of CCN’s content-centric data transfer approach; evaluation results show thatour approach can reduce bandwidth consumption up to 99% for pull and up to 46% for push com-pared to a UDP/IP-based system. Our approach also incorporates CCN’s fundamental advantages,including mobility and applicability of multiple interfaces.The remainder of this paper is organized as follows. Section 2 introduces basic concepts and

advantages of CCN relevant to this paper. Section 3, the main part of this paper, describes our contextmanagement framework, detailed design for context collection and provision, and an illustrative exam-ple using the proposed design. Section 4 describes evaluation results of the proposed approach andSection 5 introduces related work. Lastly, Section 6 concludes this paper.

2. CONTENT-CENTRIC NETWORKING

This section introduces CCN’s basic concepts and advantages. CCN [10] is an information or content-centric data communication model proposed as an alternative to the traditional TCP/IP-based Internet.CCN is concerned about content itself for data delivery rather than the destination host that has thecontent. In CCN, there are two packet types: Interest and Content Object. The Interest packet is usedfor requesting content and it contains Content Name to identify the content. The Content Object packetis used for delivering the requested content and it contains Content Name, Signature, Signed Info andthe actual Data. A Content Object packet is transmitted only in response to an Interest packet; thus theyare one-for-one and maintain a strict flow balance. To obtain content, a consumer sends an Interestpacket with a Content Name, and any node that has the content that matches with the Name canrespond with a Content Object packet.Each CCN node maintains a Content Store, which acts as a long-term cache, to re-provide the

contents that have previously passed through the node in response to requests that solicit the samecontents. Accordingly, the more requests there exist for the same content, the more efficient CCN isin terms of bandwidth consumption.



AContent Name is a binary object composed of a number of components and it typically has a hierarchicalstructure. The following is an example of a Content Name that is converted to a human readable form:

• /www.postech.ac.kr/videos/GangNamStyle-POSTECH.avi/720p

Note that a component of a Content Name can take any form of data and this characteristic can beused for pushing small volumes of data from a content provider to a consumer using an Interest packet.To provide protection and trust of content, CCN incorporates the notion of content-based security.

In CCN, data and their publisher’s digital signature are encapsulated together within a Content Objectpacket to enable a data consumer to authenticate the publisher. In addition, private data are protectedfrom unauthorized accesses by means of encryption. These features make possible CCN’s dynamiccontent-caching capabilities. The protection level of the data can vary depending on the encryptionmethod because CCN does not mandate a specific security or encryption model. This flexibility ofthe protection level allows CCN to accommodate diverse security requirements from various network-ing applications, including context data collection and provision.

3. U-COUDE OVER CCN FOR CONTEXT COLLECTION AND PROVISION

In this section, we present our user-centric context management framework, named U-CoUDE, and wepropose a context collection and provision method based on the framework using CCN as a networkand transport layer.

3.1. U-CoUDE

U-CoUDE [9], which stands for User-centric Context manager for Ubiquitous and DistributedEnvironments, provides basic concepts, a technology-neutral information model and a high-levelarchitecture to comprehensively manage distributed context data in a user-centric manner. Its role isto aggregate and associate diverse types of context data distributed over multiple domains and toprovide the collected and processed context data to various context-aware applications. U-CoUDEhas hierarchical concepts and relationships among context sensors and U-CoUDE entities, as shownin Figure 2(a). There are three levels in the hierarchy: Domain, User and Social levels. In the Domainlevel, a Domain U-CoUDE entity directly collects context data from sensors or indirectly from otherDomain entities. The Domain entity collects, infers and provides context data obtained within a spe-cific domain. In the User level, a User U-CoUDE entity collects context data from Domain entitiesor from other User entities. The User entity collects, aggregates, infers and provides context dataobtained from multiple domains, including other users’ domains, that are related to the user. Lastly,in the Social level, a number of User U-CoUDE entities that are socially related can form a group.Figure 2(b) is an architecture of a U-CoUDE entity; each U-CoUDE entity in Figure 2(a) commonly

follows this architecture regardless of the hierarchy level, except for one fact: the NormalizationModule exists only in a Domain U-CoUDE entity. A U-CoUDE entity (i) collects context data fromvarious sensors as well as other U-CoUDE entities (Context Collection), (ii) translates different formsof context data into a standardized common form (Normalization), (iii) filters and saves newly obtainedcontext data by applying predefined rules (Filtering), (iv) aggregates and associates context data to inferabstract and high-level contexts (Inference) and, finally, (v) provides collected and inferred context datato various types of context-aware applications, including other U-CoUDE entities (Context Provision).A Resource Management Module maintains a list of available context sensors and registered U-CoUDEentities, and it provides the list to Context Collection and Provision Modules. A Security Module con-trols Context Collection and ProvisionModules to protect private and sensitive context data of a user. Inthis architecture, Security, Resource Management, Context Collection and Context Provision Modulesare directly related to context collection and provision processes (bold lined boxes in Figure 2b); wewill describe detailed designs of these modules in the latter part of this section.To clarify the scope of our work in this article, Figure 3 shows a logical standpoint of U-CoUDE in

the Open System Interconnect (OSI) layer; U-CoUDE corresponds to an Application layer and it cancommunicate with other entities, such as sensors and context-aware applications, by utilizing Network


http://www.postech.ac.kr/videos/GangNamStyle-POSTECH.avi/720p

Figure 2. U-CoUDE hierarchies and entity architecture: (a) U-CoUDE hierarchies; (b) U-CoUDEentity architecture

52 S.-S. SEO ET AL.

and Transport layer functionalities. In this research, we collect and provide context data using CCN asa network and transport layer leveraging CCN’s various advantages. Note that our proposal does notrequire modification of CCN. Instead, it utilizes CCN as a network and transport layer to efficientlycollect and provide context data.A U-CoUDE entity has the role of either a context provider or a context collector. It is also possible

that the entity has roles of both a context provider and a context collector at the same time. For exam-ple, a Domain-level U-CoUDE entity collects context data directly from sensors as a context collector,while it provides the collected and processed data to User-level U-CoUDE entities as a context


Figure 3. U-CoUDE and CCN in OSI layer

Table 1. Notations

Notation Description

U U-CoUDE entity (U = {C,P})C U-CoUDE entity that has a role of a context collectorP U-CoUDE entity that has a role of a context providerUR U-CoUDE entity that has a relationship with U as C or P

(If U is P then UR is C, and vice versa)IDU Identifier of UNU Human-readable name of UEk(D) Encrypted data of D with encryption key, k


provider. Considering these concepts, Table 1 defines basic notations used in the remainder of thispaper. Lastly, the basic CCN naming scheme for the proposed approach is as follows:

• /domain/u-coude/ IDU/u-coude module/operation/operation-specific parameters

3.2. Security module

Each context that is collected and provided by a U-CoUDE entity requires different levels of protec-tion. For example, accurate location data of a user require high-level protection because they are verysensitive and private, whereas temperature data from a public place require low-level protection. Tosatisfy the different levels of security demands, U-CoUDE provides three security types: (i)Provider-based; (ii) Group-based; and (iii) Collector-based.In Provider-based security, context data are encrypted with a provider’s symmetric key (skP) that is

inherent to the provider and shared between the provider and its registered collectors; an skP is sharedfrom a provider to a collector in a resource registration process (explained in Section 3.3). Therefore,every collector that is registered to the provider can access the Provider-based security context data bydecrypting them using skP. As a result, Provider-based security yields good bandwidth and delay perfor-mances because CCN’s data caching is applicable for all the registered collectors, whereas it providesnormal data protection because its symmetric key, skP, is shared with all of its registered collectors.In Collector-based security, context data are encrypted with a symmetric key (skCP) that is unique

between a provider and a collector; an skCP is generated by a collector and shared with a provider in a re-source registration process (explained in Section 3.3). Therefore, only a corresponding collector can accessthe Collector-based security context data that is encrypted with skCP. As a result, Collector-based securityprovides the best data protection among the three security types, whereas it yields normal bandwidth anddelay performances because CCN’s data caching is applicable for only the corresponding collector.In the Group-based security, context data are encrypted with a group’s symmetric key (skG); U-

CoUDE entities can form a group and share the skG among them.2 Only the group members can access

2U-CoUDE takes advantage of existing approaches for a group formation and its key management, such as Virtual Private Com-munity (VPC) suggested by Kim and Lee [13], rather than reinventing the wheel.


54 S.-S. SEO ET AL.

the Group-based security context data by decrypting them with the skG. This means that CCN’s datacaching is applicable only within the group members. As a result, the bandwidth and delay perfor-mance of the Group-based security is dependent on the number of group members, and it providesmedium data protection compared to the other two security types.Figure 4 illustrates the three types of symmetric keys that are shared between a provider, P1, and

four collectors, C1 – C4, which form two groups: G1 and G2. The provider and all of the collectorsshare the same symmetric key, skP1 , for Provider-based security, while the symmetric keys, skC1P1 –

skC4P1, for Collector-based security are different from each other according to the unique relationshipsbetween the provider and four collectors. Lastly, the group members of each group share the groupkey, skG1 and skG2 , only within the group. If C1�C4 request the same Provider-based security typecontexts, P1 encrypts the requested context data using skP1 and sends the identically encrypted datato C1�C4; caching is applicable for all the collectors in this case. Whereas, if C1�C4 request thesame Collector-based security type contexts, P1 separately encrypts the requested context data fourtimes using skC1P1 � skC4P1 even the requested context data are the same, and P1 separately sendsthe differently encrypted data to C1�C4; caching is possible but inapplicable among differentcollectors. Finally, for Group-based security, caching advantage is effective only within the groupmembers, i.e. C1, C2, and P1 using skG1 ; and C3, C4, and P1 using skG2 .The Security module shown in Figure 5 contains two parts: Policy Administration API and Security

Policy. The former provides the basic CRUD (Create, Read, Update, and Delete) operations to managethe Security Policy. The latter provides information for the three security types and it consists of three

Figure 4. Symmetric keys between a collector and a provider in accordance with three types of security

Figure 5. Security module



sub-policies: Context Provision Policy (CPP), Context Collection Policy (CCP), and Context GroupPolicy (CGP).The CPP controls the Resource Management Module to verify whether the resource management-

requests are coming from authorized collectors. It also controls the Context Provision Module toprovide context data to only authorized and registered collectors. For the controls, the CPP containsthe following information:

• CPP-CL: (IDC, NC, domain C, pkC), a list of trustworthy collectors, where pkC is a public key ofthe C; pkC is used in a resource registration process to get P to authenticate C.• CPP-CT: {ContextType, SecurityType, ( IDsCauth IDsGauth

�� )}, a list of providable context types andtheir security metadata, where IDsCauth and IDs

Gauth are lists of identifiers of collectors and groups that have

the authority to collect the ContextType respectively; they are optional depending on the SecurityType.

The CCP controls the Resource Management Module to restrict the resource management-requeststo be generated and sent only to appropriate providers. It also controls the Context Collection Moduleto request context data only to appropriate and registered providers, and to verify whether pushed con-text data from providers are legitimate. For the controls, the CCP contains the following information:

• CCP-PL: (IDP, NP, domain P, pkP), a list of trustworthy providers, where pkP is a public key of theP; pkP is used in a resource registration process to get C to authenticate P.• CCP-CT: {IDP, ContextType, SecurityType, (IDG)}, a list of obtainable context types and their

security meta-data per a provider, where IDG is optional depending on the SecurityType.3

The CGP provides group-related information to the Context Provision and Collection Modules.Based on the CGP, these two modules can decide whether a related U-CoUDE entity (UR) is a legiti-mate member of the claiming group, or can decide which skG has to be used for en/decryption of contextdata in which case the SecurityType is Group-based. The CGP contains the following information:

• (IDG, NG, skG, IDsGMem), a list of groups in which U is included, where IDG is an identifier of agroup G, NG is a human-readable name of the G, skG is a symmetric key for en/decryption of contextdata, and IDsGMem is a list of identifiers of U-CoUDE entities that are members of this group excludingIDU itself.

3.3. Resource management module

Figure 6 illustrates three main processes of the Resource Management Module and its interactions withthe other modules. The main processes of the module include (i) Registration, (ii) Maintenance and (iii)De-registration. Figure 6 also shows both the Context Collectors List (CL) and Context Providers List(PL) that are interacting with the three processes; they are lists of registered context collectors and pro-viders to the U-CoUDE entity, respectively. More specifically, CL contains a list of (IDC, skCP, α, β, γ)and PL contains a list of (IDP, skCP, skP, α, β, γ), where α, β, and γ are availability-check-parameters(explained in Section 3.3.2). CL and PL are complementary to Security Policy, and they are connectedvia an ID. In comparison to Security Policy, CL and PL are lists of only registered collectors and pro-viders, while Security Policy, especially CCP and CPP, is information about qualified collectors andproviders regardless whether they are currently registered or not. As a result, CL and PL are moredynamic than Security Policy.

3.3.1. Resource registrationResource registration is a process, from the perspective of a context collector C, for registering acontext provider to collect context data. Similarly, from the perspective of a context provider P, it isa process for registering a context collector to provide context data. As a result of the registration

3IDG has to be specified when the SecurityType is Group-based because U-CoUDE allows a collector, C, and a provider, P, to begrouped together for two or more groups at the same time. For example, C and P can form a group for a family while they aremembers of a co-workers group.


Figure 6. Resource management module

56 S.-S. SEO ET AL.

process, C adds an item about the new P to PL, and P adds an item about the new C to CL. Thedetailed registration process is as follows:

1. C gets IDP and pkP from CCP-PL2. C generates skCP and saves it to PL with the IDP

3. C sends an Interest packet that has the following name to P:• /domain/u-coude/IDP/resourceManagement/registration/EpkP skCP

� �/EskCP IDC;DSC

� �/nonce

4. P gets skCP by decrypting EpkP skCP� �

with its private key

5. P gets IDC and DSC by decrypting EskCP IDC;DSC� �

with the obtained skCP

6. P checks whether C is eligible to receive context data from P by referring to CPP-CLA. If eligible:

• P saves the received skCP and IDC to CL• P sends a Content Object packet containing EskCP (skP, CPP-CT PC, α, β, γ) to C• C decrypts EskCP (skP, CPP-CT PC, α, β, γ) with the skCP

• C saves the skP, α, β, and γ to PL; and CPP-CT PC to CCP-CTB. If not:

• P sends a Content Object packet containing a denial message to C• C discards P-related information in PL

where DSC is the C’s digital signature and CPP-CT PC is a part of P’s CPP-CT that is directly relatedonly to C. In procedure 4, only P can decryptEpkP skCP

� �with its private key, hence C can assure that P

is the only entity that can obtain skCP. Once skCP is shared between C and P, they can implicitlyauthenticate each other using the key, because it is unique as long as their relationship lasts. In proce-dure 6, similarly, P can assure that the Interest packet sender is genuine C by verifying DSC using pkC

from CPP-CL. We adopt the notion of sending both skCP, which is encrypted with pkP, and therequired information, which is encrypted with the skCP, as parts of an Interest packet’s name (proce-dure 3–5) from Jacobson et al. [14]. The nonce is added as the last part of the name to guaranteethe Interest packet to be delivered to the intended P by giving uniqueness to the name of the Interest.4

After finishing the registration process, a collector maintains provider-related information in bothPL and CCP-CT, and a provider maintains collector-related information in CL. Referring to the infor-mation, a collector collects context data from appropriate providers and a provider provides contextdata to eligible collectors. The detailed context collection and provision processes are described inSection 3.4.

4An Interest packet without nonce can possibly fail to be delivered to intended P due to CCN’s content caching in situationswhere registration, de-registration and re-registration occur continuously in a short period of time.



3.3.2. Resource maintenanceResource maintenance deals with two aspects: information update and availability check. The infor-mation update is a process that a U-CoUDE entity notifies its information change to the registeredU-CoUDE entities, and the registered entities update their database with the notified information.The information update process and its relevant parameters vary depending on a process initiator.When the initiator is C, the relevant parameter is skCP, and the update process is as follows:

1. C sends an Interest packet containing the following name to P:• /domain/u-coude/IDP/resourceManagement/collectorInfoUpdate/IDC/EskCP

newskCP� �

/nonce2. P updates CL with the updated skCP.3. P sends back a Content Object packet containing an acknowledgement message.

When the initiator is P, the relevant parameters are skP, CPP-CT PC, α, β, or γ, and the updateprocess is as follows:

1. P sends an Interest packet that has the following name to C:• /domain/u-coude/IDC/resourceManagement/providerInfoUpdate/IDP/

EskCPnew skP

� ��CPP-CT PC|α|β|γ))/nonce

2. C updates either PL or CCP-CT depending on the updated information.3. C sends back a Content Object packet containing an acknowledgement message.

The availability check is a process that a U-CoUDE entity checks the liveness of the registered U-CoUDE entities. It makes use of three parameters: α, β and γ. The α is a time threshold for checkingtemporary disability of the registered U-CoUDE entity or the transport network. The β is a time thresh-old for determining de-registration. Finally, the γ is a time parameter used for periodically sendingavailability check message at the time in between α and β. These values have to be determined by Pand informed to C considering conditions such as rates of context update, conditions of transportnetwork and importance of context data. The availability check process is as follows:

1. U maintains a timer τ for each registered UR.2. The timer τ is set to 0 when a packet (either Interest or Content Object) is received from the UR.3. If the τ exceeds α:

• U stops trying to collect/provide context data from/to UR.• U then periodically sends an availability check message every γ to UR.• If τ exceeds β, where β> α, then U removes UR from either CL or PL.

3.3.3. Resource de-registrationResource de-registration is a process, from C’s perspective, for removing an item of P in both PL andCCP-CT to stop collecting context data from the P. It is also a process, from P’s perspective, for re-moving an item of C in CL to stop providing context to C. The de-registration process can be initiatedby either C or P; the detailed processes of each case are as follows:

• De-registration Process Initiated by C:1. C sends an Interest packet that has the following name to P:

– /domain/u-coude/IDP/resourceManagement/deregistration/collector/IDC/EskCP IDC� �

/nonce2. P sends back a Content Object packet containing an acknowledgement message and removes

C-related information from CL.3. C removes P-related information from both PL and CCP-CT

• De-registration Process Initiated by P:1. P sends an Interest packet that has the following name to C:

– /domain/u-coude/IDC/resourceManagement/deregistration/provider/IDP/EskCP IDP� �

/nonce2. C sends back a Content Object packet containing an acknowledgement message and removes

P-related information from both PL and CCP-CT.3. P removes C-related information from CL.


58 S.-S. SEO ET AL.

3.4. Collection and provision modules

In CCN, data transport is basically pull-based, i.e. a data consumer requests data via an Interest packet,and a data producer provides the requested data via a Content Object packet (Figure 7a). To collectcontext data, however, U-CoUDE has to support both pull and push depending on the characteristicsof context data. To do so, U-CoUDE adopts three different methods for push: (i) Long-lived InterestPush (Figure 7b) [15]; (ii) Embedded Interest Push (Figure 7c) [14], and (iii) 4-way Handshake Push(Figure 7d) [17]. Each push method has its own advantages and disadvantages in terms of delaysensitivity, data throughput efficiency and processing overhead. U-CoUDE employs the pull and threepush context collection methods, and the remainder of this section describes them in detail.

3.4.1. PullThe pull operation in U-CoUDE corresponds to the basic data acquisition flow of CCN; C requestscontext data by sending an Interest packet containing the name of the requested context data to P,and P replies to the Interest by sending a Content Object packet containing the requested context data(Figure 7a). The detailed pull process is as follows:

1. C checks PL and CCP-CT to request appropriate context data; then, it sends an Interest packetcontaining the following name to P:• /domain/u-coude/IDP/contextProvision/pull/(IDC|IDG/)ContextType/TimeFrom/TimeTo(/nonce)

2. P receives the Interest packet and checks CL and CPP-CT whether the context request is valid:A. If valid, P checks the availability of the requested context data:

A-a. If available:• P encrypts Context Value and its obtained Time (CVT) depending on the security type:

– Provider-based: EskP CVTð Þ– Collector-based: EskCP CVTð Þ– Group-based: EskG CVTð Þ

• P sends a Content Object packet that contains the encrypted CVT to C.• C receives the Content Object packet, decrypts the data and saves the CVT.

A-b. If not available:• P sends a Content Object packet that contains an error message to C.

B. If not valid, P sends a Content Object packet that contains an error message to C.

In the name of the Interest packet (of procedure 1), either IDC or IDG is required when the securitytype of the requested context data is Collector-based or Group-based, respectively. They are used by Pto select the key to encrypt the context data. Note that the context requesting name does not specify thesecurity type, because it is synchronized between C and P in the resource registration and maintenanceprocesses. TimeFrom and TimeTo are time parameters for restricting the temporal range of the re-quested context data. Finally, nonce is optionally added to the name when the requested Interest packethas to be delivered directly to the intended P by giving uniqueness to the name of the Interest.

3.4.2. Long-lived interest push (LIP)LIP is similar to the normal pull in CCN, as shown in Figure 7(b), except for the following two points:(i) the requesting Interest packet has a longer lifetime than pull; and (ii) P and C defer processing of the

(a) Pull (b) LIP (c) EIP (d) 4HP

Figure 7. Flows of Interest and Content Object packets in four context collection types: (a) Pull; (b) Long-lived Interest Push (LIP); (c) Embedded Interest Push (EIP); and (d) four-way Handshake Push (4HP)



Interest when the requested context data are not immediately available. These features allow C to sendan Interest packet that requests context to P before the requested context is actually acquired; thismakes possible for LIP to work as push. Accordingly, LIP is suitable for pushing delay-sensitivecontext data. LIP, however, also introduces additional processing overheads to CCN routers to main-tain larger Pending Interest Table (PIT) and to U-CoUDE entities (both C and P) to maintain pendingcontext data requests. The detailed LIP process is as follows:

1. C checks PL and CCP-CT to request appropriate context data; then, it sends an Interest packetcontaining the following name to P:• /domain/u-coude/IDP/contextProvision/LIP/(IDG|IDC/)ContextType/TimeAfter.5

2. P receives the Interest packet and checks CL and CPP-CT whether the context request is valid:A. If valid, P checks the availability of the requested context data.Aa. If available:

• P encrypts Context Value and its obtained Time (CVT) depending on the security type:– Provider-based: EskP CVTð Þ– Collector-based: EskCP CVTð Þ– Group-based: EskG CVTð Þ:

• P sends a Content Object packet that contains the encrypted CVT to C.• C receives the Content Object packet, decrypts the data and saves the CVT.

Ab. If not available:• P suspends the process until the requested context data are available; once they become

available, then P goes to the step 2Aa.• Cmaintains the context request entry until the requested context data are obtained from P.

B. If not valid, P sends a Content Object packet that contains an error message to C.

3.4.3. Embedded interest push (EIP)EIP delivers context data from P to C by using an Interest packet that has the name that contains con-text data itself (Figure 7c). Note that the CCN name can contain any type of data including contextdata. The detailed EIP process is as follows:

1. P obtains new context data, then decides whether to EIP the data to C by referring to CL andCPP-CT.

2. If P has decided to EIP the context data, it sends an Interest packet containing the followingname to C depending on the security type:• Provider-based: /domain/u-coude/IDC/contextCollection/EIP/IDP/ContextType/EskP CVTð Þ• Collector-based: /domain/u-coude/IDC/contextCollection/EIP/IDP/ContextType/EskCP CVTð Þ• Group-based: /domain/u-coude/ IDC/contextCollection/EIP/ IDP/ContextType/ IDG/

EskG CVTð Þ3. C receives the Interest packet, decrypts the data and saves the CVT.4. C sends a Content Object packet containing the same name without data to P.

EIP is intuitive, easy to implement and suitable for pushing delay-sensitive context data, whereas itrequires higher bandwidth than the other push methods. The reason for the higher bandwidth usage istwofold. First, EIP cannot utilize CCN’s data-caching advantages because P has to deliver context datato each C using a separate Interest packet containing the context data even if the data are same forevery C. The second reason is that the replying Content Object from C to the EIP Interest packet alsocarries the same name containing context data; i.e. the context data is delivered as a name in a ContentObject packet from C to P unnecessarily.

3.4.4. Four-way handshake push (4HP)4HP consists of two parts: push notification and pull (Figure 7d). In the push notification part, P sendsan Interest packet to C to notify that it has obtained new context data that needs to be pushed to C.

5In LIP, at most one requested context data item that is generated after the TimeAfter time parameter is pushed.


60 S.-S. SEO ET AL.

Then, C sends a Content Object packet that has no data to meet CCN’s flow balance requirements—one Interest generates one Content Object. The latter part of 4HP is same with the normal pull process.The detailed 4HP process is as follows:

1. P obtains new context data, then it decides whether to 4HP the data to C by referring to CL andCPP-CT.

2. If P has decided to 4HP, it sends an Interest packet containing the following name to C:• /domain/u-coude/IDC/contextCollection/4HP/IDP/ContextType/TimeFrom/TimeTo

3. C receives the Interest packet and sends a Content Object packet without data to P.4. The remainder of the 4HP process follows the same procedures of pull in Section 3.4.1.

Unlike LIP, 4HP does not burden CCN routers and U-CoUDE entities, nor does it require highbandwidth, unlike EIP. However, it introduces additional delay for pushing context data because itconsists of the two phases. Accordingly, 4HP is suitable for pushing non-delay-sensitive context data.

3.5. An illustrative example

This subsection provides an illustrative example, based on Figure 4, of collecting and providing con-text data using the proposed method. In this example, there is a family, which consists of four mem-bers: father (C1), mother (C2), son (C3) and daughter (C4), and there is a home context provider P1. P1

provides context data including temperature and power consumption of home, and son’s location.Father, mother and P1 form a group parents (G1), and son, daughter and P1 form a group children(G2). We assume that P1 is a legitimate context provider for C1�C4, and C1, C2 and C3 are registeredto P1, but C4 is not registered yet.Table 2 shows Security Policies, CL and PL of each U-CoUDE entity in the example. CPP-CL of P1

specifies trustworthy collectors, which are C1�C4. CPP-CT specifies context types and their securitymetadata of which P1 provides. For example, the PowerConsumption context is provided to only

Table 2. Security polices, CL, and PL of U-CoUDE entities in the example

Enitity Type Contents

P1 CPP-CL (C1, Father, domainC1 , pkC1 ), (C2, Mother, domainC2 , pkC2 ),(C3, Son, domainC3 , pkC3 ), (C4, Daughter, domainC4 , pkC4 )

CPP-CT (Temperature, Provider-based, EIP), (PowerConsumption, Group-based, Pull, G1),{Son’sLocation, Collector-based, 4HP, (C1, C2, C3)}

CGP {G1, Parents, skG1 , (C1, C2)}, {G2, Children, sk

G2 , (C3, C4)}CL (C1, sk

C1P1 , α1, β1, γ1), (C2, skC2P1 , α2, β2, γ2), (C3, sk

C3P1 , α3, β3, γ3)

C1 CCP-PL (P1, Home, domainP1 , pkP1 )CCP-CT (P1, Temperature, Provider-based, EIP), (P1, Son’sLocation, Collector-based, 4HP),

(P1, PowerConsumption, Group-based, Pull, G1)CGP {G1, Parents, sk

G1 , (C2, P1)}PL (P1, sk

C1P1 , skP1 , α1, β1, γ1)

C2 CCP-PL (P1, Home, domainP1 , pkP1 )CCP-CT (P1, Temperature, Provider-based, EIP), (P1, Son’sLocation, Collector-based, 4HP),

(P1, PowerConsumption, Group-based, Pull, G1)CGP {G1, Parents, sk

G1 , (C1, P1)}PL (P1, sk

C2P1 , skP1 , α2, β2, γ2)

C3 CCP-PL (P1, Home, domainP1 , pkP1 )CCP-CT (P1, Temperature, Provider-based, EIP), (P1, Son’sLocation, Collector-based, 4HP)CGP {G2, Children, sk

G2 , (C4, P1)}PL (P1, sk

C3P1 , skP1 , α3, β3, γ3)

C4 CCP-PL (P1, Home, domainP1 , pkP1 )CCP-CT no itemCGP {G2, Children, sk

G2 , (C3, P1)}PL no item



group G1 via Pull using Group-based encryption. CGP of P1 specifies group-related information and ithas two items because P1 is a member of both G1 and G2. Lastly, CL contains a list of registeredcollectors, which are C1�C3. Note that C4 is not in the CL but is in the CPP-CL; this means thatC4 is not registered currently but it could be registered later.C1�C4 have only one trustworthy provider, P1, so their CCP-PLs are the same and it contains only

one item about P1. CCP-CTs of C1�C4 vary depending on P1’s CPP-CT. For example, C1 and C2 areeligible to obtain all the three context types that P1 provides while C3 is eligible for only two contexttypes. CGPs of C1�C4 follow the P1’s CGP in a similar fashion. Lastly, PLs of C1�C3 specify reg-istered provider, which is P1 in this case. Note that C4 has no item in both CCP-CT and PL because C4

has not been registered to any provider yet.Under this situation, the following describes a context collection and provision process when P1

gets new Temperature context data:

1. P1 refers to CL and CPP-CT, and knows the Temperature data have to be delivered to C1�C3

using EIP.2. P sends Interest packets containing the following names to C1�C3:

• C1: /domainC1 /u-coude/IDC1 /contextCollection/EIP/IDP1 /Temperature/EskP1 CVTð Þ• C2: /domainC2 /u-coude/IDC2 /contextCollection/EIP/IDP1 /Temperature/EskP1 CVTð Þ• C3: /domainC3 /u-coude/IDC3 /contextCollection/EIP/IDP1 /Temperature/EskP1 CVTð Þ

3. C1�C3 receive the Interest packet, decrypt the data and save the CVT.4. C1�C3 send a Content Object packet containing the same name without data to P1.

The following describes a context collection and provision process when P1 gets new Son’s Loca-tion context data:

1. P1 refers to CL and CPP-CT, and knows the Son’sLocation data have to be delivered to C1�C3 using 4HP.

2. P1 sends an Interest packet containing the following name to C1�C3:• C1: /domainC1 /u-coude/IDC1 /contextCollection/4HP/IDP1 /Son’sLocation/TimeFrom/TimeTo• C2: /domainC2 /u-coude/IDC2 /contextCollection/4HP/IDP1 /Son’sLocation/TimeFrom/TimeTo• C3: /domainC3 /u-coude/IDC3 /contextCollection/4HP/IDP1 /Son’sLocation/TimeFrom/TimeTo

3. C1�C3 receive the Interest packet and send a Content Object packet without data to P1.4. C1�C3 check PL and CCP-CT to pull the Son’s Location and send Interest packets containing thefollowing names to P1:

• C1: /domainP1 /u-coude/IDP1 /contextProvision/pull/IDC1 /Son’sLocation/TimeFrom/TimeTo• C2: /domainP1 /u-coude/IDP1 /contextProvision/pull/IDC2 /Son’sLocation/TimeFrom/TimeTo• C3: /domainP1 /u-coude/IDP1 /contextProvision/pull/IDC3 /Son’sLocation/TimeFrom/TimeTo

5. P1 receives the Interest packets and checks CL and CPP-CT whether the context request is valid.6. P1 encrypts the CVT with a Collector-based symmetric key:

• C1: EskC1P1 CVTð Þ• C2: EskC2P1 CVTð Þ• C3: EskC3P1 CVTð Þ

7. P1 sends Content Object packets that contain the encrypted CVT to C1�C3.8. C1�C3 receive the Content Object packet, decrypt the data and save the CVT.

4. EVALUATION

This section describes quantitative and qualitative evaluations of the proposed approach by comparingit to a traditional UDP/IP-based system. We chose UDP/IP, which does not support a reliability mech-anism unlike TCP/IP, for the comparisons considering CCN’s reliability mechanism is premature fornow. The quantitative evaluation was carried out under a simulation environment using ndnSIM [18].The ndnSIM is an open source module, which is designed to work with the NS-3 simulator, forsimulating CCN-based approaches. We ran the simulations on two different topologies; the first


62 S.-S. SEO ET AL.

topology was designed to reflect a simple case, so that we could easily identify the characteristics ofour approach, and the second topology was designed to reflect a more realistic case, which coversmultiple domains. In the simulations, we set the average context data size to 512 bytes. This sectionalso describes qualitative comparisons of our approach with UDP/IP in terms of four categories.Figure 8 shows the simple network topology for the evaluation; there are m collectors C0�Cm� 1,

which are connected to the CCN router R0, and one provider P0, which is connected to the CCN routerR1. C0�Cm� 1 and P0 form n disjoint groups (P0 is not visually included as a group member in Figure 8for simplicity) and each group contains the same number of collectors as its members. We measuredbandwidth consumption at a link between R0 and R1, in which case all collectors C0�Cm� 1 collectedthe same context from P0 once. Note that this topology was designed to be as simple as possible toeasily identify the characteristics of our context collection and provision approaches (i.e. Pull, LIP,EIP and 4HP).Figure 9(a) shows a comparison of the bandwidth consumption in the case where the context collec-

tion type was fixed to pull and the security type was varied; CCN-P, CCN-G, and CCN-C representcases where only one security type of Provider-, Group- and Collector-based exists, respectively,and CCN-M represents a case where the proportion of the three security types was 1:1:1. We fixedthe number of groups to 10 for both CCN-G1 and CCN-M1, and to 30 for both CCN-G2 and CCN-M2 (the number of groups influence neither CCN-P nor CCN-C). CCN-P showed the lowest and con-stant bandwidth consumption (717 bytes) regardless of the number of collectors. This is because theProvider-based security type can fully utilize CCN’s caching feature. Both CCN-G1 and CCN-G2showed steady bandwidth consumption, 7,310 bytes and 21,930 bytes respectively, similar to theCCN-P case because the bandwidth consumption of Group-based security type is affected by theexisting number of groups; CCN-G2 consumed three times more bandwidth than CCN-G1. CCN-M1, CCN-M2, UDP/IP-Pull and CCN-C’s bandwidth consumptions were linearly increasing withthe number of collectors. Note that CCN-C consumed the most bandwidth because it cannot utilizeCCN’s caching at all, like a UDP/IP case, and CCN’s average packet overhead is slightly larger thanUDP/IP’s overhead. Nevertheless, we insist that the slightly larger bandwidth consumption of CCN-Ccompared to UDP/IP-Pull is negligible considering the additional advantages of CCN including secu-rity and mobility. We also think that the case where only Collector-based security type exists (i.e.CCN-C case in the figure) is uncommon because the most of context data are valuable when theyare shared.Figure 9(b) shows a comparison of the bandwidth consumptions in the case where the context

collection type was push (EIP, 4HP, and LIP) and the proportion of the three security types was fixedto 1:1:1; the number of groups was fixed to 10 for both LIP-1 and 4HP-1, and to 30 for both LIP-2 and4HP-2 (the number of groups does not influence the performance of EIP). LIP showed the lowest andlinearly increasing bandwidth consumption following the growth of the number of collectors. 4HP-1showed similar bandwidth consumption to UDP/IP-Push and 4HP-2 showed slightly higher bandwidth

Figure 8. A simple topology for performance evaluations


(a) Pull

(b) Push

Figure 9. Bandwidth consumption (y) versus number of collectors (x) in the simulation using a simpletopology: (a) pull; (b) push


consumption than UDP/IP-Push. EIP consumed higher bandwidth compared to the other pushmethods because its Interest and Content Object packets both have to contain context data as a partof their names. Therefore, we have to be careful of using EIP considering its higher bandwidth consump-tion, even though the EIP is intuitive, simple, easy to implement and suitable for pushing delay-sensitivecontext data.Figure 10 shows a realistic network topology that covers multiple domains for the simulation; there are

three providers P0�P2 and 105 collectors C0�C104; 60 collectors are connected to R2, 30 are connectedto R1 and 15 are connected to R4. We assume that three disjoint groups exist and each group contains thesame number of collectors and all the providers as its members. We measured average bandwidth con-sumption at links between two routers (i.e. R0�R1, R0�R2, R0�R3 and R1�R4), in which case allthe collectors collected context data from the three providers over 20 s and the context collection intervalwas 1 s.

Figure 10. A topology covers multiple context domains for performance evaluations


64 S.-S. SEO ET AL.

Figure 11 shows the average bandwidth consumptions of our proposed context collectionmethods that were simulated on the topology shown in Figure 10. We also measured the averagebandwidth consumption of UDP/IP-Pull and Push; solid and dotted lines in Figure 11 represent theresults of them for the comparison. The overall bandwidth consumption trends were similar to thesimple topology case (Figure 9) regardless of measurement points while the volumes of bandwidthconsumption were different. Pull/LIP consumed less bandwidth than UDP/IP for all cases exceptthe Collector-based case. 4HP consumed less bandwidth than UDP/IP for Provider- andGroup-based cases, while it consumed similar amount of bandwidth for Mixed case and morebandwidth for Collector-based case. Lastly, EIP consumed more bandwidth than UDP/IP regardlessof security type.Table 3 summarizes overall reduction percentages of bandwidth consumption between our approach

and the UDP/IP-based one from the first simulation results (Figure 9). Our approach reduced band-width consumption by 41–99% for context data pull and by 29–46% for push. For CCN-C and4HP-2, our approach consumed slightly more bandwidth, which are 14% and 18% respectively, thanUDP/IP; we think the slightly larger bandwidth consumption is negligible considering additionaladvantages of CCN. Lastly, EIP consumed 135% more bandwidth than UDP/IP, hence it is suitablefor pushing only delay-sensitive and low volume context data.In addition to the quantitative evaluation, we also qualitatively evaluated our approach by

comparing it to UDP/IP in terms of four categories as shown in Table 4. To provide a secure datacommunication between a context provider and a collector, UDP/IP has to employ an additionalapplication layer protocol, but our CCN-based approach provides inherent and flexible securityvia three security types: Provider-, Collector- and Group-based. Our approach also supportsmobility better than UDP/IP thanks to CCN’s location independent and content-centric namingscheme [10,14,15]; CCN does not need to bind a layer 3 identity (i.e. IP address) to layer 2identity (e.g. MAC address), and CCN name represents content itself rather than a host, whichhas the content. These characteristics make it easier to support destination mobility whilesupporting source mobility remains as a challenging issue [19]. Our CCN-based approach can takeadvantage of multiple interfaces. For example, most of the latest smartphones are equipped with

Figure 11. Average bandwidth consumption (y) versus context collection methods (x) in the simulationusing a realistic topology: (a) link between R0 and R1; (b) link between R0 and R2; (c) link between R0

and R3; (d) link between R1 and R4


Table 3. Overall bandwidth consumption reduction between proposed CCN- and UDP/IP-based approachesfrom the first simulation results; normalized using UDP=IP�Proposed

UDP=IP �100; parenthesized values mean increase ofbandwidth consumption

Pull Push

Category Reduction (%) Category Reduction (%)

CCN-C (14) EIP (135)CCN-M2 41 4HP-2 (18)CCN-M1 55 4HP-1 (1)CCN-G2 79 LIP-2 29CCN-G1 93 LIP-1 46CCN-P 99

Table 4. Qualitative comparison between the proposed approach and UDP/IP

Category UDP/IP Proposed

Security Require additional methods Inherent and flexibleMobility Hard to support Easy to supportMultiple interfaces Hard to utilize Easy to utilizeBandwidth consumption Linearly increase Vary depending on choices


several network interfaces, such as 3G, WiFi and Bluetooth; we can use the three interfaces at thesame time for collecting context data. It is difficult for UDP/IP to take advantage of multiple in-terfaces since UDP/IP is restricted to forwarding on spanning trees, whereas CCN can take full ad-vantage of multiple interfaces since CCN packets cannot loop [10,16]. This is a desirable featurenot only for fast and robust context data collection but also for mobility. Lastly, bandwidth con-sumption of UDP/IP increases linearly when the number of context collectors increases, whereasour approach consumes much less bandwidth than UDP/IP in most cases. Our approach also pro-vides several options with different security levels (i.e. Provider-, Collector- and Group-based) andcontext provision methods (i.e. Pull, LIP, 4HP and EIP) that can be chosen to reflect characteristicsof context data.Table 5 shows comparisons of the four CCN-based context collection methods in terms of band-

width consumption, cache efficiency, initial transport delay and processing overhead. EIP has highbandwidth consumption, because it pushes data as a part of name in an Interest packet, and the corre-sponding Content Object packet contains the same name that has the same data; this means that thedata are transported twice from a sender to a receiver and from the receiver to the sender unnecessarily.4HP has medium bandwidth consumption, because it consists of two phases: push notification andpull. In term of cache efficiency, Pull and LIP can fully utilize CCN’s cache feature, but 4HP orEIP does not; 4HP’s push notification phase or EIP’s push Interest packet has to be delivered to eachdata consumer separately, even though all the delivered data are identical. The difference between 4HPand EIP is that 4HP’s latter part, pull, can take advantage of CCN’s cache feature, whereas EIP cannot.These relative superiorities among the context collection methods are changed when we consider

Table 5. Comparisons of the four context collection methods

Category PullPush

LIP 4HP EIP

BW consumption Low Low Medium HighCache efficiency High High Medium n/aInitial transport delay Medium Low High LowProcessing overhead Low High Medium Low


66 S.-S. SEO ET AL.

initial transport delay and processing overhead. LIP or EIP has low initial transport delay, because theypush context data immediately without any pre-required phases. On the other hand, Pull has to requestdata via an Interest packet to receive the data, and 4HP has to pass a push notification phase to receivethe actual data via a pull phase. Finally, when we consider processing overhead, LIP has high overheadbecause it burdens CCN routers to maintain larger Pending Interest Table (PIT), and burdens U-CoUDE entities to maintain pending data requests. 4HP also has higher processing overhead than Pullor EIP, because it consists of two phases, which means double workloads to transport context data. Onthe contrary, Pull or EIP follows CCN’s basic data transport mechanism, so they do not incur addi-tional processing overhead. In short, we have to carefully choose an appropriate context data collectionmethod considering characteristics of context data, because each context collection method has its ownadvantages and disadvantages.

5. RELATED WORK

Efficient context data management plays an important role for both intelligent network managementand useful end-user services. For intelligent network management, Famaey et al. [20] proposed asemantic communications bus that employs ontologies and semantic reasoning to support filteringof network context based on meaning. Through the bus, autonomic network elements exchange impor-tant context data with each other to help in making their autonomic decisions. For useful end-userservices, Mun et al. [21] proposed Personal Data Vaults (PDVs) as an architecture for securelycollecting and providing individual users’ private data. They implemented and applied the PDV archi-tecture for two applications: tracking a user’s locations and collecting a user’s sleep quality-relatedcontext data. Seo et al. [1] also developed a smartphone application that changes the configuration set-tings of a smartphone in response to context changes. The major shortcoming of these approaches isthat they dealt with context data obtained only from a single domain (e.g. a smartphone). To providecomprehensive context management, Chen et al. [22] proposed a broker-centric agent architecture forsupporting context-aware systems. The broker maintains and manages a shared contextual model onbehalf of a community of agents. Korpipää et al. [23] suggested a context management frameworkwhich manages contextual entities as a centralized server. These context management approaches,however, did not have processes that deal with the different types of contexts obtained from themultiple domains. They also did not provide an explicit security mechanism that can protect user’sprivate context data. On the other hand, our context management framework, U-CoUDE, comprehen-sively manages contexts obtained from multiple domains with considerations about normalization andprotection of heterogeneous context data.Existing context data collection and management approaches did not pay much attention to

mobility, security, and data transfer efficiency because these characteristics are dependent on theunderlying network and transport layer protocols. On the contrary, our CCN-based approachsupports a secure and efficient context data collection and provision mechanism thanks to CCN’sinherent advantages that are exploitable without additional help of an application layer. Here, weintroduce several CCN-based applications that take advantages of CCN’s beneficial features likeour proposal. Kim et al. [13] proposed a CCN-based application that shares data within a privatecommunity, such as a family. The application provides better bandwidth performance due toCCN’s caching capability and better protection of private data due to CCN’s inherent security.Wang et al. [24] applied CCN to vehicle-to-vehicle (V2V) communications. The most challengingissue in V2V communications is addressing, and the authors proposed an addressing solution forV2V communications by utilizing CCN’s flexible naming scheme. Jacobson et al. [25] proposedan information-sharing platform that requires neither centralized infrastructure nor always-onInternet connectivity. It was possible due to CCN’s content-centric nature and support of dynamicrouting. Mathieu et al. [11] proposed a CCN-based social network application, which significantlyreduces network load and improves response time to get the content up to 60% depending on thenetwork topology and the cache efficiency. They argued that CCN paradigm was a good fit withthe behavior of social networking services.



6. CONCLUDING REMARKS

A comprehensive context management approach is necessary in the era of ubiquitous technologies andefficient context data collection is one of the most fundamental and important processes for realizingthe comprehensive context management. In this paper, we have introduced our comprehensive user-centric context management framework, U-CoUDE, and have proposed a context data collectionand provision approach based on the U-CoUDE framework using CCN. The proposed context collec-tion approach is secure because it encrypts every context data using an encryption key that is sharedbetween a context provider and a collector. The three security types, which are Provider-, Collector-and Group-based, allow administrators or users to apply an appropriate level of protection on theirprivate context data. In addition, the approach is efficient in terms of bandwidth consumption becauseit utilizes CCN’s caching advantages. In the performance evaluation results, we have shown that ourapproach has significantly reduced bandwidth consumption in comparison to a UDP/IP-based one.Our approach also provides advantages in supporting mobility and leveraging multiple interfaces.As future work, we will further evaluate our approach considering mobile wireless constraints, such

as battery and storage. Moreover, we will design and implement the remaining modules in our U-CoUDE entity architecture, which are Normalization, Filtering and Inference (thin lined boxes inFigure 2b). Then, we will apply our approach to real-life applications including context-awaresmarthome and home network management systems. We expect that our approach will provide funda-mental functionalities for context-aware network and service management.

ACKNOWLEDGEMENTS

This research was partly supported by the MSIP (Ministry of Science, ICT&Future Planning), Korea,under the ITRC (Information Technology Research Center) support program supervised by the NIPA(National IT Industry Promotion Agency) (NIPA-2013-H0301-13-3002) and by the Smart Applicationson Virtual Infrastructure (SAVI) project funded under the National Sciences and Engineering ResearchCouncil of Canada (NSERC) Strategic Networks grant number NETGP394424-10.

REFERENCES

1. Seo S, Kwon A, Kang J-M, Strassner J, Hong JW-K. PYP: design and implementation of a context-aware configurationmanager for smartphones. In Proceedings of the 1st International Workshop on Smart Mobile Applications (SmartApps’11), San Francisco, CA, 12–15 June 2011.

2. Atzori L, Lera A, Morabito G. The Internet of things: a survey. Computer Networks 2010; 54(15): 2787–2805.3. Wang H, Choi H, Agoulmine N, Deen MJ, Hong JW-K. Information-based sensor tasking wireless body sensor networks in

healthcare systems. In Proceedings of the 6th International Conference on Network and Service Management (CNSM ’10),Niagara Falls, Canada, 25–29 October 2010; 517–522.

4. Koulakezian A, Leon-Garcia A. CVI: connected vehicle infrastructure for ITS. In Proceedings of IEEE 22nd InternationalSymposium on Personal, Indoor and Mobile Radio Communications (PIMRC ’11), Toronto, Canada, 11–14 September2011; 750–755.

5. Kang J-M, Strassner J, Seo S, Hong JW-K. Autonomic personalized handover decisions for mobile services in heteroge-neous wireless networks. Computer Networks 2011; 55(7): 1520–1532.

6. Roy N, Das SK, Julien C. Resource-optimized quality-assured ambiguous context mediation framework in pervasive envi-ronments. IEEE Transactions on Mobile Computing 2012; 11(2): 218–229.

7. Chon Y, Cha H. Lifemap: a smartphone-based context provider for location-based services. IEEE Pervasive Computing2011; 10(2): 58–67.

8. Kim J, Choi H, Wang H, Agoulmine N, Deen MJ, Hong JW-K. POSTECH’s U-Health smart home for elderly monitoringand support. In Proceedings of the 2nd International Workshop on Interdisciplinary Research on E-Health Services andSystems (IREHSS ’10), Montreal, Canada, 14 June 2010; 1–6.

9. Seo S, Kang J-M, Han Y, Hong JW-K. Context management for user-centric context-aware services over pervasivenetworks. In Proceedings of the 14th Asia-Pacific Network Operations and Management Symposium (APNOMS ’12),Seoul, Korea, 25–27 September 2012; 1–4.

10. Jacobson V, Smetters DK, Thornton JD, Plass MF, Briggs NH, Braynard RL. Networking named content. InProceedings of the 5th ACM International Conference on Emerging Networking EXperiments and Technologies(CoNEXT ’09),Rome, Italy, 1–4 December 2009; 1–12.


68 S.-S. SEO ET AL.

11. Mathieu B, Truong P, You W, Peltier J-F. Information-centric networking: a natural design for social network applications.IEEE Communications Magazine 2012; 50(7): 44–51.

12. Smetters D, Jacobson V. Securing network content. Technical Report TR-2009-1, Palo Alto Research Center, October2012.

13. Kim D, Lee J. CCN-based virtual private community for extended home media service. IEEE Transactions on ConsumerElectronics 2011; 57(2): 532–540.

14. Jacobson V, Smetters DK, Briggs NH, Plass MF, Stewart P, Thornton JD, Braynard RL. VoCCN: voice-over content-centric networks. In Proceedings of the ACM International Workshop on Re-Architecting the Internet (ReArch ’09), Rome,Italy, 1 December 2009; 1–6.

15. Zhu Z, Wang S, Yang X, Jacobson V, Zhang L. ACT: audio conference tool over named data networking. In Proceedings ofthe ACM SIGCOMM Workshop on Information-Centric Networking (ICN ’11), Toronto, Canada, 19 August 2011; 68–73.

16. Udugama A, Zhang X, Zaki Y, Goerg C, Timm-Giel A. Disjoint path discovery in CCN Networks. Presentation inCCNxCon ’12, Sophia Antipolis, France, 12 September 2012. Available: http://www.ccnx.org/wp-content/uploads/2012/08/3Udugama.pdf [25 October 2013].

17. Kim J, Jang M, Bae Y, Lee B-J. Named content sharing in virtual private community. In Proceedings of the 9th IEEEConsumer Communications and Networking Conference (CCNC ’12), Las Vegas, NV, 14–17 January 2012; 50–51.

18. Afanasyev A, Moiseenko I, Zhang L. ndnSIM: NDN simulator for NS-3. Technical Report NDN-0005, Rev. 2, Named DataNetworking (NDN) Project, October 2012.

19. Hermans F, Ngai E, Gunningberg P. Global source mobility in the content-centric networking architecture. In Proceedingsof the 1st ACM Workshop on Emerging Name-Oriented Mobile Networking Design: Architecture, Algorithms, and Appli-cations (NoM ’12), Hilton Head Island, SC, 11 June 2012; 13–18.

20. Famaey J, Latre S, Strassner J, Turck FD. Semantic context dissemination and service matchmaking in future networkmanagement. International Journal of Network Management 2012; 22(4): 285–310.

21. Mun M, Hao S, Mishra N, Shilton K, Burke J, Estrin D, Hansen M, Govindan R. Personal data vaults: a locus of control forpersonal data streams. in Proceedings of the 6th ACM International Conference on emerging NetworkingEXperiments andTechnologies (CoNEXT ’10), Philadelphia, PA, 30 November–3 December 2010; 1–12.

22. Chen H, Finin T, Joshi A. An ontology for context-aware pervasive computing environments. Knowledge EngineeringReview 2003; 18(3): 197–207.

23. Korpipää P, Mäntyjärvi J, Kela J, Keränen H, Malm E-J. Managing context information in mobile devices. IEEE PervasiveComputing 2003; 2(3): 42–51.

24. Wang L, Wakikawa R, Kuntz R, Vuyyury R, Zhang L. Data naming in vehicle-to-vehicle communications. in Proceedingsof the 1st Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN ’12), Orlando, FL, 30 March2012; 1–6.

25. Jacobson V, Braynard RL, Diebert T, Mahadevan P, Mosko M, Briggs NH, Barber S, Plass MF, Solis I, Uzun E, Lee B-J,Jang M-W, Byun D, Smetters DK, Thornton JD. Custodian-based information sharing. IEEE Communications Magazine2012; 50(7): 38–43.

AUTHORS’ BIOGRAPHIES

Sin-seok Seo is a Ph.D. candidate in the Department of Computer Science and Engineering at POSTECH,Pohang, Republic of Korea. He studied at University of Toronto, Toronto, Canada as an international visitinggraduate student from July 2012 to March 2013. He received a BSc in the Department of Computer Scienceand Engineering from Inha University, Incheon, Republic of Korea in 2008. His research interests includeSoftware-Defined Networking (SDN) management, data center network management, autonomic network man-agement, context-aware network and service management, and mobile device management.

Joon-Myung Kang is a Postdoctoral Fellow in the Department of Electrical and Computer Engineering, Universityof Toronto, ON, Canada. He received his BSc. and Ph.D. degrees in Computer Science and Engineering fromPOSTECH in 2005 and 2011, respectively. Prior to joining to POSTECH, he was a software engineer at AlticastCorporation from 2000 to 2004. He was a Postdoctoral Fellow at the Department of Computer Science andEngineering, POSTECH, Pohang, Republic of Korea from March 2011 to September 2011. His research interestsinclude software-defined networking, cloud computing management, and autonomic network management.

Alberto Leon-Garcia is Distinguished Professor in Electrical and Computer Engineering at the University ofToronto. He is a Fellow of the Institute of Electronics an Electrical Engineering “For contributions to multiplexingand switching of integrated services traffic”. He is also a Fellow of the American Association for the Advancementof Science and a Fellow of the Engineering Institute of Canada. He has received the 2006 Thomas Eadie Medalfrom the Royal Society of Canada and the 2010 IEEE Canada A. G. L. McNaughton Gold Medal for his contribu-tions to the area of communications. Professor Leon-Garcia is author of the textbooks: Probability and RandomProcesses for Electrical Engineering, and Communication Networks: Fundamental Concepts and Key Architecture.He is currently Scientific Director of the SAVI NSERC Strategic Network.


http://www.ccnx.org/wp-content/uploads/2012/08/3Udugama.pdf

http://www.ccnx.org/wp-content/uploads/2012/08/3Udugama.pdf


Yoonseon Han is a Ph. D. candidate in the Division of IT Convergence Engineering, POSTECH. He received hisB.Sc. degree from the Department of Computer Science and Engineering at POSTECH, Korea, in 2009. Hisresearch interests include Software-Defined Networking (SDN) management, data center traffic measurementand estimation, context-aware computing, and mobile device management.

James Won-Ki Hong is currently the Chief Technology Officer and Senior Executive Vice President for KT(Korea Telecom), the largest telecommunications company in Korea since March 2012, where he is responsiblefor leading the R&D effort of KT and its subsidiary companies. He is Chairman of National Intelligence Commu-nication Enterprise Association, and Chairman of ICT Standardization Committee in Korea. His interests includenetwork innovation, such as software-defined networking (SDN) and network function virtualization (NFV), cloudcomputing, mobile services, IPTV, ICT convergence technologies (e.g., Smart Home, Smart Energy, Healthcare),and next generation technologies such as big data analytics and intelligence. Before taking the role of CTO at KT,he had worked at POSTECH for 17 years as a professor including Head of Dept. of Computer Science and Engi-neering, Dean of Graduate School for Information Technology, Director of POSTECH Information Research Labs(PIRL) and Head of the Division of IT Convergence Engineering. He was also co-founder and CTO of Netstech, aPalo Alto, USA-based startup developing network integrated ultra-dense, blade servers from 2000 to 2002. Overthe past 20 years, James has been an active volunteer in various committees in IEEE, ComSoc, and KICS. Hehas served as Steering Committee Chair of IEEE NOMS, IM and APNOMS, as well as Chair of CNOM (ComSocCommittee on Network Operations and Management) and KNOM. He has also been serving as EiC of Wiley’sInternational Journal of Network Management (IJNM) and ComSoc Technology News (CTN) as well as an editorialmember of the IEEE Transactions on Network and Service Management (TNSM), Elsevier’s Journal of Network andSystems Management (JNSM) and Journal of Communications and Networks (JCN). James received his HBSc andMSc degrees in Computer Science from the University of Western Ontario, Canada in 1983 and 1985, respectively,and the Ph.D degree in Computer Science from the University of Waterloo, Canada in 1991.


user-centric context data collection and provision harnessing content-centric networking paradigm

Documents