Social-aware Opportunistic Routing for Delay-Tolerant Networks Yearly Report

SITI Technical Report SITI-TR-12-06 2012

Authors/Editors

Author Waldir Moreira

Affiliation SITI/Universidade Lusfona

Yearly Report 2011/2012

Social-aware Opportunistic Routing for Delay-Tolerant Networks

Waldir Aranha Moreira Junior

July 2012

Advisors: Prof. Dr. Paulo Mendes (SITI/ULHT) and Prof. Dr. Susana Sargento (IT/UA)

Contents 1 Introduction 2 Scientic Contributions 2.1 Classication of Opportunistic Routing Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 2.3 2.4 Applicability Analysis of DTNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Social Model for Opportunistic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Algorithms and Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 4 5 5 5 7 9 9 9 10 11 12 14

3 Proposed Achievements and Current Results 4 Deviations and Workplan Updates 4.1 4.2 Deviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workplan Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Scientic Milestones 6 Other Achievements 7 References 8 Annex

Abstract This yearly report corresponds to the activities performed in the year 2011/2012. It overviews the goals established towards the thesis preparation and the expected outcomes. Additionally, it shows the achievements during this year in terms of publications and submissions under review as well as what is expected for the upcoming year to conclude the work. A section is also dedicated to present the deviations from the original proposed work and updates. In the annex section, published works can be found.

1. Introduction With this work I propose to tackle routing problems in intermittently connected networks such as Delay Tolerant Networks, which are characterized by being highly dynamic, composed of mobile and static nodes connected by multiple time-varying links facing frequent partitions and high queueing delay. In this specic type of network, routing takes advantage of opportunistic contacts among nodes to exchange data since the regular assumption of existing at least an end-to-end path between source and destination is, in most cases, not applicable. Consequently, many solutions emerged employing routing strategies that exploit users social interaction and mobility patterns to create forwarding opportunities even when an end-to-end path is absent. Some of these approaches aim to exploit node mobility to achieve a fast delivery of data by ooding the network (e.g., Epidemic [26]), while others try to achieve similar results by controlling ooding based on: i) delivery probability optimizations (e.g., Spray and Wait [25]); ii) history of encounters (e.g., PROPHET [7]); iii) priority (e.g., MaxProp [3]); iv) future prediction (e.g., EBR [22]). A recent trend aims to consider not only node mobility patterns but also node social entanglement to increase the system stability. Such approaches apply the concept of communities formed by nodes and the social relationship between them (e.g., Bubble Rap [6]), by considering user mobility and interests (e.g., SocialCast [4]), and node popularity (e.g., PeopleRank [21]). This latest trend is based on the fact that social behavior takes into account human relationship characteristics such as contacts with other people, time spent with these people, and the level of relationship between people. And since computing devices are carried by humans, social-based forwarding decisions can consider peoples socially meaningful relationships where the relationship information come from aspects such as human mobility, interaction, and social structures. This information can be used to perform forwarding, because the topology created from human social behavior varies less than the one based on mobility [6]. Moreover, there are different solutions from which there is no clear understanding about what the most suitable solution may be. The reason for that is the lack of a taxonomy to identify common properties, and the lack of an objective framework to evaluate existing approaches. Based on such context, the main goals of this thesis are: to provide an objective comparison of the most representative proposals, based upon an objective classication and evaluation framework, and to devise a novel opportunistic routing solution (model, algorithms, and protocol) able to provide an efcient solution based on stable network graphs constructed based upon metrics that represent the social behavior of mobile nodes. This report is structured as following. Section 2 presents all the scientic contributions expected from this thesis work. Section 3 discusses the thesis activities along the expected outcomes, pointing out to the concluded and ongoing activities as well as the future ones. Section 4 presents the deviations from the proposed workplan and updates. And, nally, Section 5 presents an assessment of the overall thesis output based on a comparison of the proposed publications and achieved ones.

2. Scientic Contributions The analysis of related work in the eld of opportunistic routing for DTNs shows that proposals spanning the last ten years head towards a probabilistic approach where mobility is exploited taking advantage of the stochastic encounters that happen between nodes. In addition, social parameters (e.g., relationships, interests) have been used to aid in data forwarding since topology based in social aspects tend to be less volatile (i.e., vary less) than the ones based on mobility. From the considered proposals, it is clear that one recent trend for opportunistic routing solutions in DTNs is going towards the awareness about social parameters, being them only related to inter-meeting times or actually related to more complex social similarities. It was observed that social ties can devise different communities [5] and these communities can indeed aid in data forwarding. Such forwarding becomes even better if interests and tastes [4] of users are taken into account and if the social relationship of nodes (carried by people) is explicit [21], the proposal can reach very close to optimum results. Despite the investigation done in the last three years in the area of social-aware opportunistic routing for DTNs, there are still some questions that remain without an answer, namely related to the most suitable social model to be used, the efciency of the used routing algorithms, as well as the analysis of the impact of the devised routing solutions in our daily life. This chapter presents a briey description of the areas in which this thesis aims to contribute to the investigation done in the area of opportunistic routing for DTNs and to advance the state of the art in the eld of social-aware opportunistic routing proposals. 2.1. Classication of Opportunistic Routing Approaches When performing an analysis of the state of the art, it is clear the difculty in reaching an objective comparison due to the distinct nature of the different proposals. There are single forwarding approaches aiming to optimize the utilization of network resources, as well as replication-based approaches aiming to optimize delivery probability. On one hand, forwarding has the advantage of using network resources properly, but may end up taking too long to delivery messages. On the other hand, replication-based approaches present a message delivery probability that is, in almost every solution, very close to optimal, but with a high cost. Aiming to achieve a good balance between a high delivery probability and a low utilization of network resources, several proposals try to avoid ooding the network, by exploiting mobility of nodes, history of encounters, and social parameters. There are a few works that attempted to categorize DTN routing algorithms. However, they consider aspects (e.g., level of knowledge) that led to an unbalanced classication, assigning most solutions to a few set of categories, or to very specic classication branches (e.g., by considering information coding or methods to control movement of nodes), which do not represent a deployment scenario with high impact. Hence, one contribution of this thesis is the analysis of existing taxonomies regarding opportunistic routing, aiming to propose a routing taxonomy suitable for an easy classication and evaluation of current and future proposals. A brief analysis of the state of the art also shows that the performance evaluation considers different aspects (e.g., node number, mobility models) preventing a more reliable and objective evaluation. This is even more evident with proposals that were compared in scenarios totally different from the ones they were designed for. In this context, another contribution of this thesis is the development of a universal framework to allow a more consistent evaluation process, especially when comparisons between older and new approaches take place. Such universal evaluation framework must be done based on a stochastic analysis of the identied most relevant parameters used by most these current routing proposals.

2.2. Applicability Analysis of DTNs The opportunistic routing proposals, subject of this thesis, are suitable to Delay-Tolerant Networks (DTNs) that are intermittently connected networks where applications tolerate delays beyond conventional IP networks. DTNs may be useful for various scenarios including inter-space communication, mission-critical networks, data distribution in urban areas, and network connectivity in rural areas. Having reached a relative stability in what concerns its architecture, current DTN standardization focuses on the analysis of transmission end-to-end protocols, block formats, and abstract service description for the end-to-end exchange of messages. However, there is not a generalized consensus about the impact that a suitable routing strategy will have in the deployment of DTNs. Currently, there is a need to pursuit a well-balanced discussion upon the impact of routing in the deployment of DTNs. In this context, this thesis aims to analyze different applicability scenarios (e.g., dense and sparse networks) from a routing perspective, and a set of routing-related assumptions (e.g., efciency of social-based approaches when compared to mobility-based ones) to be taken into account when investigating DTN architecture, network model, and protocols. 2.3. Social Model for Opportunistic Routing The proposed applicability analysis of DTNs aims to provide already an initial idea about the efciency of social-based opportunistic routing when compared to mobility-based approaches. After reaching an understanding about the degree of stability that social-based routing solutions have, there is the need to model DTN graphs taking into account the need to consider the dynamic nature of communities and the most suitable social metrics. Among the social metrics, three groups will be considered: contact information (e.g., inter-contact time distribution, contact duration, and contact volume), interest information, and cooperation levels. As mentioned, one aspect that may have an important impact on the social graph is the process of creating and updating communities. Most of the prior-art uses either a simple node gathering algorithm (e.g., SocialCast) or a more detailed approach, by observing the number of contacts and their duration to determine the social ties between nodes (e.g., Bubble Rap). These are good approaches, but since these solutions deal with humans, the structure of these communities can change over time, and, so far, routing proposals work under the strong assumption that communities are static. In addition, it is still not clear what is the best number of contacts and their duration in order to a node be part of a community. The answer varies from individual to individual, and actually there are no exact answers. Another question relies on the usage of common interests to group nodes together. In what concerns the cooperation levels, they are important metrics since it should not be assumed that all nodes are always willing to share their constrained resources on the behalf of others. Moreover, trust should be applied especially to identify malicious nodes nearby (e.g., DoS attack) and avoid such paths for data exchange. The cooperation level between nodes may be related to the information being forwarded. So, this thesis will investigate the impact that the willingness of users to route information may have on the desirable social graphs. 2.4. Routing Algorithms and Protocol Based on the devised social model for opportunistic routing, this thesis aims to specify and validate a set of social-based routing algorithms to be used by a new opportunistic routing protocol. The proposed algorithms and protocol aim to provide low delivery delay while consuming low number of resources in disruptive scenarios with dense topologies. One of the major novelties of the proposed solutions is their interest-centric nature. Although most of the current proposals support only destination-based communications, the proposed protocol must be able to support also an information-centric 5

paradigm (supporting multi-point communications), since this seems to be the basic foundation of applications able to distribute information in challenged networks. Hence, the proposed solution will investigate the best balance between social aspects (e.g., creation of communities) and the interest of nodes in routable information. The investigation of the proposed algorithms will consider variations of the previously devised social graphs as well as variations on the replication strategy to keep good performance levels. Another aspect that will be investigated is the impact of randomness in the efciency of the proposed algorithms. This because it was proved that, even if social connection is fully available, performance does not approach optimal values [21]. This means that nodes with which people do not have much contact can still be a good relay of information. Another open question has to do with the awareness about available infrastructure and familiar strangers. Currently, all the proposals consider isolated DTNs, but in several environments such as a city, such awareness would bring extra benets to devise routing algorithms and protocols able to make use of infrastructure when it is available as well as familiar strangers, in order to increase the probability to reach a good performance level.

3. Proposed Achievements and Current Results The work developed in this PhD comprises different activities. This section presents these activities, stating whether they have been already concluded, are currently ongoing, or still to be done. Additionally, it provides the expected outcomes and proposed target publications along with achievements (i.e., published and under review works). Activity 1: Problem Space Denition and Related Work Analysis (March 15th, 2010 - June 15th, 2010) Expected achievements: Detail problem space containing at least a generic scenario, constrains, assumptions, requirements. Analyze related work describing accurately both the positive and the negative aspects of each of the approaches, for the mentioned problem space. Expected outcome: 1 survey paper (e.g., IEEE Survey&Tutorials). Status: Complete. Achievements: A taxonomy that includes the trend identied (i.e., based on social aspects). A Universal Evaluation Framework that species a set of experimental setups and performance evaluation metrics to provide designers with a fair assessment model for comparing opportunistic routing solutions. Outcomes: 1 technical report [14], which resulted in 1 conference paper (published in CRC 2010 [12]); 1 conference paper (published in IEEE LatinCom 2011 [18]); 1 tutorial accepted for presentation in IEEE LatinCom 2011 [13]; 1 journal paper (published in IEEE Latin America Transactions [19]); 1 book chapter on Routing in Opportunistic Networks to be published by Springer Verlag, USA, in early 2013. Activity 2: Design phase (September 1st, 2010 January 31st, 2011) Expected achievements: Debate on novel approaches. Analysis of the impact of routing in the deployment of DTNs over different scenarios as well as the identication of realistic assumptions and requirements. Model network graphs (e.g., Erdos-Reny, Scale-free, small world) considering the major incentives for cooperation, dynamic nature of communities and main social metrics, namely contact information, interest information, and cooperation levels (e.g., familiar strangers, strangers). Expected outcomes: 1 workshop publication (e.g., ACM CHANTS); 1 technical report; 1 informal Internet draft. Status: Complete. Achievements: Understanding of incentives for node cooperation to aid in forwarding. Development of two utility functions, namely Time-Evolving Contact Duration (TECD) and TECDi (deriving node importance). These utility functions are focused on contact duration (that represents an abstraction to map cooperation among nodes) and human daily behaviour [24]. Testing, debugging, and improvements of utility functions. Improvement analysis of K-clique community detection algorithm based on TECD. Outcomes: 1 technical report [16]; 1 conference paper (published in ADHOC-NOW 2012 [10]). Activity 3: Algorithm specication phase (February 1st, 2011 - July 31st, 2011) Expected achievements: Novel social-based algorithms suitable for multi-point communications, which will be validated based on simulations (e.g., ONE simulator) to prove their ability to maximize delivery rate with reduced delivery cost and delay. Such algorithms will be devised based on the investigation of the most suitable combination of social and interest metrics. The utilization of social metrics will require the investigation of social communities (e.g., inter-contact times, duration of contacts, volume of contacts) and how to update them over time. Of importance in this stage is the investigation of threshold between randomized and social-based forwardings. 7

 Expected outcomes: 2 international conference publications (e.g., ACM MobiHoc, IEEE ICC); 1 technical report; 1 informal Internet draft (update). Status: Ongoing. I managed to design a new routing proposal, dLife (version 1), based on the resulting functions of the previous activity. Now, I am currently working on a second version of the solution (dLife v2) considering information centricity and multi-point communications. Achievements: Development of a new opportunistic routing solution based on the daily routines of users, dLife v1 [9]. Outcomes: 1 workshop paper (published in IEEE WoWMoM AOC 2012 [20]). Activity 4: Protocol Implementation phase (August 1st, 2011 - January 31st, 2012) Expected achievements: Development of a social-based opportunistic routing protocol based on the algorithms devised in the previous phase, which will be validated based on simulations and a prototype. The validation of the protocol will consider the presence of available legacy infrastructure and other least-considered social levels (e.g., familiar strangers) in order to improve the performance of previously implemented algorithms and/or mechanisms. Moreover, the stability of the devise protocol will be compared with pure mobile-based approaches. Expected outcomes: 2 international conference publications (e.g., IEEE INFOCOM, ACM SIGCOMM); 1 technical report; 1 informal Internet draft (update). Status: Ongoing. Effort towards the implementation of dLife v1 in a real-world test-bed. This will be followed by the implementation of dLife v2 upon completion of activity 3. Achievements: Specication of dLife v1 as an Internet-Draft. Outcomes: Internet-Draft submission of rst version of dLife [17]. Activity 5: Validation/demonstration phase (February 1st, 2012 - June 30th, 2012) Expected achievements: Continuation of the protocol validation work, based on scenarios with heterogeneous wireless technologies (e.g., Wi-Fi, Bluetooth). Contribution to standardization of an opportunistic routing protocol for DTNs based on social metrics. Expected outcomes: 1 journal publication (e.g., IEEE/ACM TON, IEEE JSAC); 1 informal Internet draft (update); 1 Internet draft (protocol proposal); 1 thesis. Status: Beginning. A test-bed is being developed to test both versions of dLife. The next section presents the deviations from the original proposed workplan and updates.

4. Deviations and Workplan Updates As the work evolved, some updates needed to be done in the workplan. Thus in this section I present the deviations from the original workplan as well as the updates to keep the work on the right track. 4.1. Deviations

Informal Internet draft: As mentioned in the previous yearly report, this draft was proposed to rst appear in activity 2 (cf. Section 3). It was put on-hold since there was no clear interest in IRTF DTN research group for an Internet draft about a routing impact analysis on the deployment of DTNs. Thus, I prepared a IRTF DTNRG contribution in activity 4 based on dLife version 1 as part of since the current efforts of the DTNRG is towards new routing protocol solutions. This draft has been submitted to IRTF DTNRG and is currently under consideration on this research group. The book chapter mentioned as outcome in activity 1 has not yet been submitted. The rst plan for submission was in January 2012, however it has been changed by the editor to September of the current year. Activity 3 is still taking place as we want to have a second version of dLife, which will consider information centricity and multi-point communications. This activity reaches its conclusion with the design of dLife v2. Activities 4 and 5 are concurrently taking place and were delayed due to the efforts for having the dLife proposal accepted by the scientic community. For instance, the second Internet draft (protocol proposal) planned for activity 5 will result from the specication of the second version of dLife (dLife v2), being designed and implemented in activities 3 and 4. 4.2. Workplan Updates As mentioned in the previous yearly report, activity 2 lead us to spend more time understanding community dynamics. This consequently changed the focus of activity 3 to focus on community aspects and not on application issues (e.g., multi-point communications) and information centricity (cf. Subsection 2.4). Now, with what was learned regarding community dynamics, activity 3 goes back to looking at information centricity and multi-point communications. The next section summarizes the scientic milestones expected to be achieved with the development of this thesis work, and the achievements up to this moment.

5. Scientic Milestones This section provides a comparison between the proposed success indicators and current achievements so far as well as work under review and to be submitted. Additionally, we included an EXTRA column highlighting achievements which were not planned and happened during the course of this work. Note that the
Table 1: Success indicators, proposed targets, and achievements so far.

Here is the updated list of scientic milestones achieved thus far: Paper entitled Routing Metrics for Delay Tolerant Networks published in the CRC 2010 [12]. Technical report entitled Survey on Opportunistic Routing for Delay/Disruption Tolerant Networks. Tech. Rep. SITITR-11-02, SITI/ULHT, 2011 [14]. Paper entitled Assessment Model for Opportunistic Routing published in the IEEE LatinCom, 2011 [18]. Paper entitled Assessment Model for Opportunistic Routing published in IEEE Latin America Transactions 2012 [19]). ULOOP paper entitled Trust and Cooperation Incentives for Wireless User-Centric Environments published in the IADIS e-Society 2012 [1]. Paper entitled Opportunistic Routing Based on Daily Routines published in IEEE WoWMoM Workshop AOC 2012 [20]. Paper entitled Study on the Effect of Network Dynamics on Opportunistic Routing published in ADHOC-NOW 2012 [10]. Technical report entitled Social-aware Utility Functions for Opportunistic Routing. Tech. Rep. SITI-TR-XX-XX, SITI/ULHT, 2012 [16] ULOOP paper entitled Virtual Currency and Reputation-Based Cooperation Incentives in User-Centric Networks published in the IWCMC 2012 [2]. Book chapter on Routing in Opportunistic Networks to be published by Springer Verlag, USA (To be submitted on September 20th). Next section presents other achievements throughout this second year of work.

10

6. Other Achievements

Invited reviewer by TPC member for the ACM CoNEXT Student Workshop, September, 2011. Invited reviewer by TPC member for the 4th IEEE International Workshop on Future Multimedia Networking, September, 2011. Invited chair by TPC member for the technical session 8 - Network Performance and Modelling II of the IEEE 3rd LatinAmerican Conference on Communications 2011. The session took place in the conference on October 25th, 2011, in Belm, Brazil. Tutorial entitled Opportunistic Networking: Extending Internet Communications Through Spontaneous Networks accepted for presentation on the IEEE 3rd Latin-American Conference on Communications 2011 [13]. Presented in the conference on October 26th, 2011, in Belm, Brazil. Teaser topic presentation entitled Encouraging Cooperation Through Community Dynamics in the 6th API held at CISCO Portugal on November 29th, 2011 [11]. Collaboration in the DTN Amazon project that involves SITI/ULHT and Federal University of Par, January, 2012. Participation in the ULOOP project plenary to align with partners the work being done, March, 2012. Submission of a FCT Exploratory Project entitled ANAID: Afnity Networking Analysis for Information Dissemination, March, 2012. Poster presentation entitled Social-aware Routing for Opportunistic Networks in MAP-Tele Workshop, May, 2012 [15]. Teaser topic entitled A Management Framework for In-production Software Dened Network accepted for the 7th API held at SITI, Universidade Lusfona on June 22nd, 2012 [23]. Organizer of the 7th Think-Tank Meeting of the Approaches to Paradigms of a future Internet (API) on Software Dened Networking, 2012 [8]. TPC member for the IEEE Workshop on User-Centric Networking (U-NET), 2012.

11

7. References

[1] Carlos Ballester, Jean-Marc Seigneur, Waldir Moreira, Paulo Mendes, Linas Maknavicius, Alessandro Bogliolo, and Paolo di Francesco. Trust and cooperation incentives for wireless user-centric environments. In Proceedings of IADIS e-Society, Berlin, Germany, March, 2012. [2] Alessandro Bogliolo, Paolo Polidori, Alessandro Aldrini, Waldir Moreira, Paulo Mendes, Mursel Yildiz, Carlos Ballester, and Jean-Marc Seigneur. Virtual currency and reputation-based cooperation incentives in user-centric networks. In Proceedings of IWCMC, Limassol, Cyprus, August, 2012. [3] John Burgess, Brian Gallagher, David Jensen, and Brian Neil Levine. Maxprop: Routing for vehicle-based disruptiontolerant networks. In Proceedings of INFOCOM, Barcelona, Spain, April, 2006. [4] Paolo Costa, Cecilia Mascolo, Mirco Musolesi, and Gian Pietro Picco. Socially-aware routing for publish-subscribe in delay-tolerant mobile ad hoc networks. Selected Areas in Communications, IEEE Journal on, 26(5):748760, June, 2008. [5] Pan Hui. People are the network: experimental design and evaluation of social-based forwarding algorithms. Technical Report UCAM-CL-TR-713, University of Cambridge, Computer Laboratory, 2008. [6] Pan Hui, Jon Crowcroft, and Eiko Yoneki. Bubble rap: social-based forwarding in delay tolerant networks. In Proceedings of ACM MobiHoc, Hong Kong, China, May, 2008. [7] Anders Lindgren, Avri Doria, and Olov Schelen. Probabilistic routing in intermittently connected networks. In Petre Dini, Pascal Lorenz, and Jose de Souza, editors, Service Assurance with Partial and Intermittent Resources, volume 3126 of Lecture Notes in Computer Science, pages 239254. Springer Berlin / Heidelberg, 2004. [8] Waldir Moreira. Organization of the 7th think-tank meeting of the approaches to paradigms of a future internet (api). June, 2012. Further information: http://siti.ulusofona.pt/ api/. [9] Waldir Moreira. dlife: Opportunistic routing based on social daily routines. Software SITI-SW-11-06, Research Unit in Informatics Systems and Technologies (SITI), University Lusofona, June, 2011. [10] Waldir Moreira, Manuel de Souza, Paulo Mendes, and Susana Sargento. Study on the effect of network dynamics on opportunistic routing. In Proceedings of ADHOC-NOW, Belgrade, Serbia, July, 2012. [11] Waldir Moreira, Davidson Junior, Filipe Vieira, Ronedo Ferreira, Eduardo Cerqueira, and Christian Rothenberg. Encouraging cooperation through community dynamics. In 6th Think-Tank Meeting of the Approaches to Paradigms of a future Internet (API), Porto Salvo, Portugal, November, 2011. [12] Waldir Moreira and Paulo Mendes. Routing metrics for delay tolerant networks. In Proceedings of CRC, pages 217219, Braga, Portugal, November, 2010. [13] Waldir Moreira and Paulo Mendes. Opportunistic networking: Extending internet communications through spontaneous networks (tutorial). In IEEE LATINCOM, Belem, Brasil, October, 2011. [14] Waldir Moreira and Paulo Mendes. Survey on opportunistic routing for delay/disruption tolerant networks. Technical Report SITI-TR-11-02, Research Unit in Informatics Systems and Technologies (SITI), University Lusofona, February, 2011. [15] Waldir Moreira and Paulo Mendes. Social-aware routing for opportunistic networks. In MAP-Tele Workshop, Guimaraes, Portugal, May, 2012.

12

[16] Waldir Moreira and Paulo Mendes. Social-aware utility functions for opportunistic routing. Technical Report SITI-TRXX-XX, Research Unit in Informatics Systems and Technologies (SITI), University Lusofona, August, 2012. [17] Waldir Moreira, Paulo Mendes, Ronedo Ferreira, and Eduardo Cerqueira. dlife: Opportunistic routing based on social daily routines. Internet Draft, work in progress, July, 2012. [18] Waldir Moreira, Paulo Mendes, and Susana Sargento. Assessment model for opportunistic routing. In Proceedings of IEEE LATINCOM, Belem, Brasil, October, 2011. [19] Waldir Moreira, Paulo Mendes, and Susana Sargento. Assessment model for opportunistic routing. IEEE Latin America Transactions, 10(3), April, 2012. [20] Waldir Moreira, Paulo Mendes, and Susana Sargento. Opportunistic routing based on daily routines. In Proceedings of IEEE WoWMoM AOC, San Francisco, USA, June, 2012. [21] Abderrahmen Mtibaa, Martin May, Mostafa Ammar, and Christophe Diot. Peoplerank: Combining social and contact information for opportunistic forwarding. In Proceedings of INFOCOM, San Diego, USA, March, 2010. [22] Samuel Nelson, Mehedi Bakht, and Robin Kravets. Encounter-based routing in DTNs. In Proceedings of INFOCOM, Rio de Janeiro, Brazil, April, 2009. [23] Billy Pinheiro, Vagner Nascimento, Fernando Farias, Eduardo Cerqueira, Antonio Abelem, and Waldir Moreira. A management framework for in-production software dened network. In 7th Think-Tank Meeting of the Approaches to Paradigms of a future Internet (API), Lisboa, Portugal, June, 2012. [24] Manuel De Souza and Waldir Moreira. Time-evolving contact duration (tecd) utility function. Software SITI-SW-11-03, Research Unit in Informatics Systems and Technologies (SITI), University Lusofona, April, 2011. [25] Thrasyvoulos Spyropoulos, Konstantinos Psounis, and Cauligi S. Raghavendra. Spray and wait: an efcient routing scheme for intermittently connected mobile networks. In Proceedings of ACM SIGCOMM WDTN, Philadelphia, USA, August, 2005. [26] Amin Vahdat and David Becker. Epidemic routing for partially connected ad hoc networks. Technical Report CS-200006, Duke University, 2000.

13

8. Annex

14

ANNEX A - Paper entitled Assessment Model for Opportunistic Routing published and presented on the IEEE 3rd Latin-American Conference on Communications 2011.

20

Assessment Model for Opportunistic Routing

Waldir Moreira, and Paulo Mendes SITI*, University Lusfona, Lisbon, Portugal Email: {waldir.junior, paulo.mendes}@ulusofona.pt Susana Sargento IT, University of Aveiro, Aveiro, Portugal Email: susana@ua.pt

AbstractDue to the increased capabilities of mobile devices and through wireless opportunistic contacts, users can experience new ways to share and retrieve content anywhere and anytime, even in the presence of link intermittency. Due to the signicant number of available routing solutions, it is difcult to understand which one has the best performance, since all of them follow a different evaluation method. This paper proposes an assessment model, based on a new taxonomy, which comprises an evaluation guideline with performance metrics and experimental setup to aid designers in evaluating solutions through fair comparisons. Simulation results based on the proposed model revisit the performance results published by Epidemic, PROPHET, and BubbleRap, showing how they perform under the same set of metrics and scenario. Keywords-opportunistic routing; assessment model

I. I NTRODUCTION The increasing capability of portable devices allow users to quickly form networks by sharing resources (i.e., processing, storage) and connectivity. Such spontaneous networks are possible by taking advantage of opportunistic contacts among nodes that can carry and forward information on behalf of other nodes, allowing information to reach a given destination even in the presence of intermittent connectivity (resulting from node mobility, power-saving schemes, physical obstacles). Several routing proposals emerged taking advantage of devices capability to overcome intermittency. In such proposals, devices process and store data until another good intermediate node or destination is found, based on the storecarry-and-forward paradigm. Routing proposals range from approaches using node mobility to ood the network for fast delivery, up to approaches able of controlling such ooding based on encounter history, prioritization, and encounter prediction. In recent years, approaches based on social similarity metrics emerged making use of social relationships, interests, and popularity to improve opportunistic routing. This paper starts by proposing an assessment model, which we call Universal Evaluation Framework (UEF), comprising a set of parameters related to network density and trafc aiming to aid designers to carry out fair comparisons among proposals and effectively assess their performance.
*SITI/ULHT/COFAC: R&D Unit of Informatics Systems and Technologies (SITI), University Lusfona, Room T01, Campo Grande 376, 1749024, Lisbon, Portugal.

It is based on a classication model which identies common properties (i.e., routing strategy and metrics) among opportunistic routing prior-art, aiming to support an efcient development of new proposals. Then, we compare the performance of Epidemic [1], PROPHET [2], and BubbleRap [3] under the conditions specied in the UEF. This paper is organized as follows. Section II analyzes work related to existing routing strategy classications and evaluation models. The new classication and UEF are presented in Sections III and IV, respectively. In Section V, results from a fair assessment between Epidemic, PROPHET, and BubbleRap based on the proposed assessment model are discussed. Finally, Section VI concludes the paper. II. R ELATED W ORK Our motivation to propose an assessment model comes from the fact that opportunistic routing proposals do not consider neither a similar set of performance metrics nor comparable experimental scenarios. This results in unfair comparisons between proposals, since evaluation metrics and conditions may vary. In this section, we present different classications of routing strategies that helped us achieve our goal of proposing a UEF. A. Classication of Routing Strategies Different proposals found in the literature classify routing strategies, but few provide a way to somehow evaluate them. Jain et al. (2004) [4] classify proposals based on knowledge from network oracles or route computation and determination. A routing evaluation framework is provided considering the different knowledge oracles to evaluate the amount of knowledge each proposal requires in specic application scenarios. Zhang (2006) [5] provides a classication with two main categories, deterministic and stochastic, which also considers the type of knowledge used for routing. The main goal is to solely categorize routing solutions based on the information used to perform data exchange. Likewise Jain et al. and Zhang, DSouza and Jose (2010) [6] classify solutions considering the required knowledge. Proposals are divided into three major categories based on ooding, history, and, special devices. It is important to note that this taxonomy succeeds in including the new socialaware routing trend observed in the last three years. The most recent classication proposed by Spyropoulos et al. (2010) [7] groups opportunistic routing proposals according to the message exchange scheme they employ:

978-1-4673-0279-1/11/$26.00 2011 IEEE

forwarding, replication, and coding. Authors also identify different types of utility functions that can be applied to such schemes. Additionally, Disruption Tolerant Networks (DTN) are classied based on characteristics that have major impact on routing such as connectivity and mobility. Authors succeed in mapping routing solutions to the different DTN types, which allows them to evaluate proposals accordingly. We observe that the main goal of these classications is uniquely to identify the different families of routing solutions. Some of them [4], [7] provide evaluation principles that simply aid designers to identify the application requirements in order to propose the right algorithm. We, on the other hand, use our classication to identify common aspects among the analysed solutions to propose a fair way to assess routing performance independently of the amount of needed knowledge and application scenario. B. Evaluation models Regarding evaluation models, we highlight a proposal based on Evolving Graph theory to design and evaluate least cost routing protocols. Ferreira et al. (2010) [8] use a formalized metric (i.e., foremost) to determine journeys (i.e., future temporary connections between nodes that may provide a path over time) that quickly reach the destination. This model provides an algorithm that has good performance when connectivity patterns are known, and is used as a lower bound reference to compare MANET routing solutions. Still, it lacks a guideline of how performance metrics and experimental setups can be used. We, on the other hand, want to identify the different families of routing solutions according to their distinct goals and routing strategies, and to provide a set of experimental setups to aid in a fair evaluation of opportunistic routing solutions. III. C LASSIFICATION M ODEL Observing the opportunistic routing approaches present in the literature, it is clear the existence of different trends based on specic goals. Thus, there is the need for a well-balanced and updated taxonomy able to include trends identied over the last years, focusing solely on the branch that best reects opportunistic contacts (i.e., stochastic [5]). In this section, we briey describe this new taxonomy and direct the reader to a detailed version in our report [9]. The taxonomy in Fig. 1 considers the analysis of proposals (spanning a ten-year period) and evolved from a previous analysis done in [10]. It starts by identifying three major categories based on forwarding, ooding, and replication. From the considered proposals, 94% belong to the replicationbased category including those in the identied trend, social similarity, which is of great interest to our research and focus of our discussions. The forwarding-based category, also known as singlecopy forwarding, is quite interesting from the resource consumption viewpoint, as proposals are able to spare network and node resources. However, they suffer from high delay

Figure 1.

Taxonomy for opportunistic routing.

rates, which results in low delivery rate. Examples of this category are presented by Spyropoulos et al. (2008) [11]. Albeit being rather aggressive, ooding-based algorithms are capable of achieving high delivery rates, but with a high cost (i.e., resource consumption). The classical example of this category is the Epidemic [1] approach. In order to reduce resource waste, replication-based proposals aim at increasing delivery rate by adding extra message copies in the network in a controllable manner. Due to the different routing algorithms and metrics, replicationbased solutions are further divided based on encounters, resource usage or social similarities. In the encounter-based category, proposals consider the history of encounters with a specic destination to support opportunistic forwarding of messages. The frequency nodes met in the past, or the time elapsed since the last encounter with the destination is used to decide about next hops. PROPHET [2] falls into this sub-category. Proposals based on resource usage aim to avoid messages to be kept being forwarded in the network, occupying resources, by creating metrics that dene the age of message copies. They also take forwarding decisions that wisely use available resources (e.g., RAPID [12]). In the social similarity category, proposals follow more complex algorithms aiming at: i) avoiding ooding with high probability; and, ii) exploiting social behavior related to community detection, shared interest, and node popularity. Bubble Rap [3] is a good representative of this category. IV. U NIVERSAL E VALUATION F RAMEWORK Our study shows that evaluation methods used so far do not always consider a homogeneous set of parameters or comparable experimental setups, which endangers the veracity and fairness of conclusions. Thus, even with a stable taxonomy, there is the need to devise an evaluation model based on common performance metrics and experimental scenarios, avoiding future assessments considering irrelevant performance metrics and bias scenarios. To achieve such goal, we looked at seventeen proposals (2000/2010) that best represented the categories in our taxonomy to identify evaluation/comparison patterns. For a more detailed view of our ndings, refer to our report [9]. A. Performance Metrics Previously [10], we checked several metrics and observed the lack of a naming convention and the use of the same performance metric with different denitions. This different understanding surely inuences performance assessment.

Table I N ETWORK DENSITY AND T RAFFIC PARAMETERS .

Parameters Proposals UEF Area Density (Km/number of nodes) Span conference building up to city areas/100 to 150 0.45/50 (RWP), and 4.5/50 (CM) Infocom05/41 Hong-Kong/37 Cambridge/54 Infocomo6/98 Reality/97 Mobility Model/ Speed (m/s) Representing people and different transportation means Random Waypoint Mobility (0-20) and Community (10-30) Human traces (a) Network density Node Meeting/ Inter-meeting Time Exponentially or Power-law, if it can be determined Pairs of hosts come in contact periodically and randomly Inter-meeting time follows a power-law distribution Transmission Range (m) Minimum of 10 (Bluetooth) and maximum of 250 (Wi-Fi) 50 and 100 Beacon Control Every 100 ms Source/Dest Distribution Same subset throughout all evaluation study 45 / 44 (Random) and 2 / 1 (Comm.) 1/1 (b) Trafc # Generated Messages (Load) Load must be the same one message/sec (RWP), and 20mgs/sec 2mgs/5sec (CM) 1000 messages Message Size (Kb) 1 to 100 Message TTL 3 to 10 hops 3 and 11 hops Buffer Size 2MB (200 messages of 10 KB) 200 messages

PROPHET

BUBBLE RAP

Bluetooth

We observe that delivery rate, cost, and delay are the most used metrics. Thus, to establish a naming convention and homogeneous denition, these metrics are dened next. Delivery rate is dened as the number of messages delivered, per unit of time, out of the total number of messages created. This is an important metric, because it reects the proposal effectiveness. Proposals able to reach high delivery rates are classied as having good performance. However, there is always a cost associated to the delivery of each message. We dene cost as the number of replicas per delivered message . This number of replicas gives an idea of how much resources are consumed. Additionally, message utility is correlated to its TTL, and it is imperative to remove stale data from the network to avoid resource waste. Hence, it is important that messages arrive to their destination within useful time. So, we dene delay as the time required to deliver all the bytes encompassing a message. B. Experimental Scenario Another concern is the experimental setup in which no rules are followed as parameters vary in evaluations found in the literature. We observe that the most common performance assessment parameters considered among the seventeen analyzed proposals were the number of nodes and source-destination pairs, meeting times and time between meetings, area size, message size, network load, message TTL, buffer size, mobility model, node speed, transmission range, and beacon usage. We could observe that proposals really differ regarding the experimental scenario. Some proposals provide detailed information while others provide it only partially. We were also able to identify two main parameter classes: network density (network area, number of nodes, mobility model, transmission range and beacon control), and trafc (distribution of sources/destinations, load generation, message size, message TTL, and buffer size). Tables I-a and I-b show what UEF recommends along with what is used in PROPHET and BubbleRap. We limit our discussion to these proposals since both are benchmarks for comparison studies. The former is under standardization process in the DTN research group and best represents the encounter-based category, and the latter is a good example of a new trend based on social similarity. Thus, we start by giving an overview of what the UEF suggests for each main parameter class and highlight

what each proposal considered in their assessment study. Network density allows an understanding about behavior on sparse (sporadic contacts, observing delivery rate when delay is high) and dense (frequent contacts, assessing the ability to cope with randomness when choosing next hops) scenarios. Such sparseness may be tuned by conguring the number of nodes. In average, the number of nodes in the seventeen analyzed proposals lie between 100-150 (excluding extreme cases as FRESH [13]), which are the values proposed in UEF to dene network density. In addition, mobility models should consider different speed and pause time as nodes represent people and vehicles. These parameters do inuence contact and inter-contact times. We observe that some approaches considered these times as exponentially and power law distributions [12], [3], whereas others obtained them from datasets. We also analyze the transmission range and beacon usage. In what concerns the former, we propose ranges from 10-250 meters, since they should represent the devices capabilities. Yet, beacons should not be used very often, as battery needs to be spared. However, using it rarely may lead to losing good contact opportunities. Thus, beaconing at every 100 ms may provide sufcient network knowledge while saving energy. We point out that the usage of this parameter in the UEF requires further investigation to be validated. Concerning network density parameters (cf. Table I-a), PROPHET considers the same number of nodes (50) for different area densities and mobility models. This is a very interesting approach as the proposal is subject to scenarios with sporadic contacts/long delays (Random Waypoint) and frequent contacts/many forwarding opportunities (Community). Another good point is that this proposal is evaluated under a mobility model that attempts to mimic human behavior. It is imperative to consider transmission ranges that actually represent the different devices capabilities, and the authors also evaluated the proposal under different ranges. Despite considering different area densities and mobility models, the evaluation of PROPHET is done in homogeneous scenarios. This is not realistic as there are nodes moving according to different patterns which suggests that, for a better performance evaluation, the scenario must consider different mobility models simultaneously. Additionally, node speed must also comply with reality and should be

specied according to whomever/whatever is carrying the device. The same applies to transmission range that should suitably represent the capabilities of devices: 10-250 meters shall approximate the simulation to the real world as they can represent Bluetooth and 802.11b cards, for instance. As for BubbleRap, since its evaluation is fully based on human traces, authors succeed in having different area densities (from conference to city-wide areas). Although no mobility model is explicitly used, BubbleRap follows the human behavior found in traces, which also results in appropriate node meeting/inter-meeting times [12], [3]. The transmission range considered was that of Bluetooth, which represents the devices used for collecting the traces. When compared to PROPHET, BubbleRap stands out in terms of acceptable UEF network density parameters. However, its evaluation is done in a static manner, i.e., communities are formed and betweenness centrality is determined based on collected information. Our interest is to see how the proposal behaves in a dynamic scenario, which shall inuence the way centrality and communities are computed. Regarding trafc (cf. Table I-b), we observe that, at almost every proposal, the number of source-destination pairs was statically dened and randomly assigned. We see no problem in having this number statically dened, but we certainly agree that changing it during the same experiment or in different ones shall impose some challenges. However, this number should be the same and, most importantly, the pairs should remain the same (which cannot be assured with random choice) to guarantee similar conditions for assessment study. Load generation is a parameter that adds more variations to experiments. We observe proposals generating a message per second [1], [2], a number of messages uniformly distributed [3] as well as providing little to no information on the load used. We believe it must be carefully addressed and homogenized to guarantee fair comparisons. As applications generate different-sized messages, load must be considered as it reects network and node resource consumption. It should be tuned to represent the different applications that are expected in a opportunistic scenario (e.g., chat messages, email, le transfer). We observe that only few proposals provide information about this parameter (1 KB [1], [12] or between 10-100 KB [14]). Trafc levels in the network can be affected by message TTL. If the latter is too high, network and node resource consumption may increase. Otherwise, messages may not even reach destination. Observed TTL was dened as the number of hops [1], [2] or time units, and normally varied between 3-10 hops in average. Hui et al. [3] shows that only 5% of nodes have some level of relationship with the destination in the rst hop, thus we suggest starting evaluation with at least 3 hops (as interaction values improve around 35%), and varying it to observe the proposals behavior. We also observe how a proposal performance can be

inuenced by buffer size. This parameter reects how much of the device storage a user is willing to sacrice on behalf of others. Unlimited buffer is not realistic, whereas providing all space is acceptable in scenarios where nodes are there to serve others [12]. Thus, based on our observations of the seventeen routing proposals, we suggest to limit buffer to 200 messages (10KB each). From Table I-b we observe that PROPHET has a different setting for each of the mobility models employed. Message load varies with the mobility model, and authors evaluate the proposal considering different message TTL (TTL may vary according to the message content or application generating it). Normally, buffer space can be a constraint, since nodes may not be willing to share it all. So, considering limited buffer space is closer to the real world scenario, and PROPHET s authors succeed in that. Yet, related to these parameters, BubbleRap only provides information on the source/destination distribution and load, where it generates 1000 messages between all node pairs. This is actually the set of parameters that actually deviates the most in comparison studies. Normally, source/destination pairs are a subset of randomly chosen nodes. This inuences the evaluation assessment, as this set will vary as simulations are run. Thus, evaluation studies should consider the same subset of source/destination pairs and the number of generated messages must also remain the same. In both proposals, authors do not mention anything about the message size. This is an important parameter as real world applications generate messages with different sizes. Despite having the concern of sparing buffer, BubbleRap does not indicate what size was considered for evaluation. Although not explicitly stated, BubbleRap considers message TTL and suggests that a minimum of no less than 3, since most of the nodes rst met (1 and 2 hops) still belong to the community of the messages carrier. Thus, in order for the message to reach nodes from the same community as the messages destination, more hops should be considered. V. FAIR E VALUATION In this section we present the performance evaluation of Epidemic, PROPHET, and BubbleRap under the same conditions specied in the UEF. It is important to note that our goal is twofold: rst, to show the importance of a homogeneous evaluation while assessing routing proposals from categories as different as ooding-based, encounter-based, and based on social similarities; and second, to show how the usage of different parameter setups and performance metrics can result in assessment that is bias to some proposals. A. Evaluation settings and methodology Following the proposed UEF, our scenario has 150 nodes distributed in 17 groups (8 of people and 9 of vehicles). One vehicle group, with 10 nodes, follows the Shortest Path Map Based Movement mobility model [15] and represent

Figure 2.

Performance evaluation results.

police motorbike patrols. They move with speed between 710 m/s and have a waiting time between 100-300 seconds when arriving at the randomly chosen destination. The other vehicle groups represent buses routes. Each group is composed of 2 vehicles. They follow the Bus Movement mobility model [15] with speeds between 7-10 m/s and have waiting times between 10-30 seconds. Regarding people groups, they follow the Working Day Movement mobility model [15] with walking speeds ranging from 0.8-1.4 m/s. People may also use buses to move around. Each of these groups have different meeting spots, as well as ofces and home locations. People spend 8 hours at work and present 50% probability of having an evening activity after leaving work. In the ofce, nodes move around and have a pause time ranging from 1 minute to 4 hours. Evening activities can be done alone or in groups with a maximum of 3 people, and can last between 1 to 2 hours. Every node is equipped with a wireless interface with transmission speed of 11 Mbps and range of 100 meters. Trafc load is previously congured with established source/destination pairs, where approximately 500 messages are generated per day among the same subset of node pairs. Message size ranges from 1 to 100 kB and TTL is set at 24 hours. The buffer space is of 2 MB. These values comply with different applications, and the assumption about users limited willingness to share storage capacity. Simulations are run on Opportunistic Network Environment [15] and represent a 12-day interaction between nodes (with 2 days of warmup, which are not considered for the results). Each simulation is run ten times (with different random number generator seeds for the used movement models) in order to provide a 95% condence interval for the results. All the results are evaluated considering the average delivery probability, cost, and delay. B. Results Fig. 2 shows the performance metrics considered in the UEF (a, b, and c), as well as the ones used in the evaluation of PROPHET (c, d, and e) and BubbleRap (a and f).

When comparing Epidemic and PROPHET under the UEF scenario, it is still observed the same behavior reported by Lindgren et al. (2003) [2]: PROPHET has better performance by delivering over 860 more messages (Fig. 2d) with 32% less forwardings (Fig. 2e) than Epidemic. However, PROPHET average delay (Fig. 2c) is much higher (6661.3s) than the one of Epidemic, presenting a different behavior than the one reported by Lindgren et al., where PROPHET is able to deliver messages in less time. Generally speaking, the performance of PROPHET in the UEF scenario presents higher average delivery rate, forwarded messages, and average delay than the one reported in the original paper. It needed (roughly and based on the results presented in its original paper) far more forwardings (over 34 times) to deliver almost 2.6 more messages with a delay close to 10 times more. Regarding the UEF performance metrics, we still believe that the overhead (i.e., average cost) is quite too exhaustive for a small increase in delivery probability. The increase in cost (Fig. 2b) is explained by the message TTL (set at 24 hours), which allows messages to propagate (i.e., replicate) more in the system. This consequently contributes to the increase in the average delay (Fig. 2c) as messages are held for a wiser decision. In addition, it is expected that the number of delivered messages also increase due to messages being further replicated in the system. The results of PROPHET with the UEF show an example of a proposal that was shown to have suitable performance in the original paper, but end up with not so interesting results (e.g., more overhead) in a more heterogeneous scenario. Now, moving on to the performance comparison between PROPHET and BubbleRap under the UEF scenario. Here we consider the delivery success ratio (a.k.a., average delivery probability) and total cost as presented by Hui et al. (2008) [3]. We observe the same performance behavior, but like it happened between Epidemic and PROPHET, the difference in the gains are much more evident. Regarding the delivery success ratio (Fig. 2a), the differ-

ence is over 17 percentage points between these proposals for a 24-hour TTL (i.e., 1 day), whereas such difference is reported to be very subtle in BubbleRap original paper. As for the total cost, the gap is even bigger, going from ~40% in the original paper to ~70% with UEF. Thus, in terms of cost, BubbleRap has a very interesting behavior, with a higher delivery ratio than reported in the original paper. It is also observed that while the delivery success ratio of both solutions lay around 15% for a 24-hour TTL in the original paper, with UEF this success ratio goes up to 55% and 33% for PROPHET and BubbleRap, respectively. These results really show the burden (i.e., time spent) of solutions based on community formation and this is the main reason for the poor performance of BubbleRap with UEF. Although the protocol is given two days (i.e., warmup period) so it learns about possible communities, it is still not enough for the protocol to wisely determine the existing communities. These results show how important it is to consider a dynamic scenario. The performance of BubbleRap is assessed over static scenarios (based on human traces), i.e., rst communities are formed and centralities determined, then the proposal uses such information to deliver messages. Despite considering traces of human interaction, the proposal is not able to adapt when nodes interact to represent the inherent dynamism. Consequently, its performance is degraded. In what concerns the UEF performance metrics, we observe that the difference in terms of cost (Fig. 2b) between Epidemic, PROPHET, and BubbleRap is small. This is because UEF considers the number of replicas proposals require to perform a successful delivery. We believe this is a reasonable approach since nodes may be quite resource constrained, so replication decisions must be wisely taken. VI. C ONCLUSIONS The increased capability of devices allows users to experience new ways to exchange content through opportunistic contacts. However, this new form of communication must deal with link intermittency, which has given rise to different solutions that attempt to lessen such issue. Nevertheless, it is difcult to understand which one has the best performance as every one of them has a different evaluation method. Analyzing the last ten years, we observed different trends based on specic goals and with different opportunistic routing solutions. Thus, we analyzed different proposals according to the identied trends, collected information on their evaluation process, and found common properties (i.e., routing strategy and metrics). The result was a UEF which provides guidelines, based on a taxonomy including the new trend identied recently (i.e., social similarity), comprising a set of performance parameters and experimental setup to aid designers fairly assessing the performance of opportunistic routing solutions. To validate our principles, we simulate Epidemic, PROPHET, and BubbleRap under the same UEF conditions, and we are able to see that differences among the proposals are more evident with UEF.

We believe that we have reached our goal of providing a way for designers to classify their new solutions as well as fairly assessing them. As new proposals emerge, we will keep our taxonomy up-to-date with the latest trends identied in the eld of opportunistic networks. ACKNOWLEDGMENT Thanks are due to FCT for nancial support via PhD grant (SFRH/BD/62761/2009) to Waldir Moreira and UCR project (PTDC/EEA-TEL/103637/2008). R EFERENCES
[1] A. Vahdat and D. Becker, Epidemic routing for partially connected ad hoc networks, Tech. Rep. CS-200006, Duke University, April 2000. [2] A. Lindgren, A. Doria, and O. Scheln, Probabilistic routing in intermittently connected networks, SIGMOBILE Mob. Comput. Commun. Rev., vol. 7, no. 3, pp. 1920, July 2003. [3] P. Hui, J. Crowcroft, and E. Yoneki, Bubble rap: socialbased forwarding in delay tolerant networks, in Proc. of ACM MobiHoc, Hong Kong, China, May 2008. [4] S. Jain, K. Fall, and R. Patra, Routing in a delay tolerant network, in Proc. of ACM SIGCOMM, Portland, USA, August 2004. [5] Z. Zhang, Routing in intermittently connected mobile ad hoc networks and delay tolerant networks: Overview and challenges, IEEE Communications Surveys and Tutorials, vol. 8, no. 1-4, pp. 2437, January 2006. [6] R. J. DSouza and J. Jose, Routing approaches in delay tolerant networks: A survey, International Journal of Computer Applications, vol. 1, pp. 814, February 2010. [7] T. Spyropoulos, R. N. Rais, T. Turletti, K. Obraczka, and A. Vasilakos, Routing for disruption tolerant networks: taxonomy and design, Wirel. Netw., vol. 16, pp. 23492370, November 2010. [8] A. Ferreira, A. Goldman, and J. Monteiro, Performance evaluation of routing protocols for manets with known connectivity patterns using evolving graphs, Wirel. Netw., vol. 16, pp. 627640, April 2010. [9] W. Moreira and P. Mendes, Survey on opportunistic routing for delay tolerant networks, Tech. Rep. SITI-TR-11-02, SITI, University Lusofona, February 2011. [10] W. Moreira and P. Mendes, Routing metrics for delay tolerant networks, in Proc. of CRC, pp. 217219, Braga, Portugal, November 2010. [11] T. Spyropoulos, K. Psounis, and C. S. Raghavendra, Efcient routing in intermittently connected mobile networks: the single-copy case, IEEE/ACM Trans. Netw., vol. 16, no. 1, pp. 6376, February 2008. [12] A. Balasubramanian, B. Levine, and A. Venkataramani, Dtn routing as a resource allocation problem, in Proc. of SIGCOMM, Kyoto, Japan, August 2007. [13] H. Dubois-Ferriere, M. Grossglauser, and M. Vetterli, Age matters: efcient route discovery in mobile ad hoc networks using encounter ages, in Proc. of ACM MobiHoc, Annapolis, USA, June 2003. [14] S. Nelson, M. Bakht, and R. Kravets, Encounter-based routing in DTNs, in Proc. of INFOCOM, Rio de Janeiro, Brazil, April 2009. [15] A. Kernen, J. Ott, and T. Krkkinen, The one simulator for dtn protocol evaluation, in Proc. of SIMULTools, Rome, Italy, March 2009.

ANNEX B Tutorial entitled Opportunistic Networking: Extending Internet Communications Through Spontaneous Networks accepted for presentation on the IEEE 3rd Latin-American Conference on Communications 2011.

27

rtst tr t trt ts r ts trs

r rr P s rst s tr

rs r rs s t rss t ts s t ss t r t sts trs s t s tt rtts s trttt t t t rtts s s sts s t rst t ss st t ts tr stt sr sts

trs r rtr s stt s tt r t t t rtst tr tts s ttr s t trt t t s rsr sss t t rtst tr sts t st t t sts trs ttt

t t t rt r rtst trs s t t tt rtst tr t ts ttr s t t srt r sts tr rr ss trsts rttr rrs

tt rt
r rr P s rst s sr t rts sts s r s Prt

trt t t st
rs r rs s t rss t ts s t ss t rt sts trs r t rt rt ts rs st tt rstrtr s s ss st s tt rstrtr r sr ts s sts trs s t s tt rtts t t rt trttt t trs s s t t rst t s r rss s t sts st r t t rs rstr s tt st s r ts stt tr rss rs trttt tt s s rt t tr rtt tr rst t ss st t ts tr stt s r rtrsts t rt tr rttr srtrt trs sr s sts trs r rtr s stt s tt r t t t rtst tr tts s t t r tt rss r trttt tt t s rtst t r strts tt t srs s trt t ttrs s s rt srtrs rt rr rtts t t s st t rtst

tr sts r rt rts rr s tt tt s strtrs st ts srs t rrt s t trt t sr

s tt t rr r t t rtst tr sts rts t t trt

trsrtt rss r t rr t s t s t t t t rs ss s s s srts ssts s ttr s t trt t t s rsr sss t t rtst tr sts t st t t sts trs ttt t t t rt r rtst trs t sts trs s t tts r t rrrs t s s ttt s t t ss t t tt s strtrs s rtst tts s t t tt rtst tr t ts ttr s t t srt r sts tr rr ss trsts rttr rrs

Prrr t
rs

r t trs
r rr trr rrst strt s rs r tr t t rst tr tr s t t t rs P r r s strs r r t Pstrt Prr tr t rs r Pr P r t trt rttrs tr r t sttt r sts trs Prt Prt Prt rtt rt t tr tr t ss rt trs rt rts r ts t tr rrt s t s r t P tr Prr ts P t rs r s r t trt rttrs tr t rs s s s s r trsts r rss trs rtstrt rt P s sst rt rts r r t rst r tr tr r r t rst s P rts r r t rst r r s P st rs s st r t rst s rtt sr r rts ts s s ts tstt P t trs st t P P s t ts t r r s r t s rsrr t t rtr ts ts t sr tr t rst r r t s r srr t rs r t rt t trt rttrs tr r Prt rrt s t st rtr r t t rsr t rts sts s r st s rtr t trt rttrs tr sst Prssr t rst s s r t t t trtr t s r rsr trsts r sr rss trs rtst rt tr P s s r t st rts tts

t t

rtst trs
r rtrsts

Prst t ts tt sss tr s rtst t t rt t srs

s srt rt trs

tt t str trPtr trs t t s t ts rt rs Prst tr rtrsts s s s tr rts t t s srs

s ss

Prst rt s t s t rt
srt rts srs srs r t s sts tr sr tts r rts s srs t t sr rt trr

s rtst ss trt s

t r rtst trs

r t s

sss t rt ts ssts s r t r trs

tts rs

tr rt tssts
s rs

Prst t tr t st rss r tssts

tt trtrs

sss t rs ss tr s strtrs s s s stt t rt

tr rts

trsts rr

t trst srs s tts t rt rr

rttr rr

t t ts t rrt t r ts stts

ANNEX C - Paper entitled Assessment Model for Opportunistic Routing published on the IEEE Latin America Transactions 2012.

Assessment Model for Opportunistic Routing

W. Moreira, P. Mendes and S. Sargento
Abstract This paper proposes an assessment model, based on a new taxonomy, which comprises an evaluation guideline with performance metrics and experimental setup to aid designers in evaluating solutions through fair comparisons. Simulation results are provided based on the proposed model considering Epidemic, PROPHET, Bubble Rap, and Spray and Wait, and showing how they perform under the same set of metrics and scenario. KeywordsOpportunistic Routing, Assessment Model.

II. TRABALHOS RELACIONADOS Propostas de encaminhamento oportunista no consideram um conjunto similar de mtricas de desempenho nem cenrios experimentais comparveis. Isso resulta em comparaes injustas entre propostas, uma vez que as mtricas de avaliao e condies variam. Nesta seo apresentamos diferentes classificaes de estratgias de encaminhamento e modelo de avaliao relacionados com a nossa proposta, MAU. A. Classificao das Estratgias de Encaminhamento Existem diferentes classificaes de estratgias de encaminhamento oportunista [5] que as categorizam: i) com base em orculos de conhecimento da rede ou clculo e determinao de rota [6]; ii) considerando se o comportamento da rede e dos ns conhecido (i.e., determinstico) ou desconhecido e aleatrio (i.e., estocstico) [7]; iii) levando em conta o conhecimento necessrio sobre a rede e a estratgia de encaminhamento (i.e., inundao da rede, histrico de contatos e utilizao de dispositivos especiais) [8]; e, iv) de acordo com o esquema de troca de mensagens (i.e., encaminhamento de uma nica cpia, replicao e codificao), funes utilitrias e caractersticas (e.g, conectividade e mobilidade) que tm impacto no encaminhamento. A tendncia observada (i.e., encaminhamento baseado em similaridade social) nos ltimos anos mencionada, mas apenas como uma forma de utilizar dispositivos especiais [8] ou como mera funo utilitria [9]. Verifica-se que o principal objetivo destas classificaes de exclusivamente identificar as diferentes famlias de solues de encaminhamento. Algumas [6] [9] fornecem princpios de avaliao que apenas ajudam no desenvolvimento e identificao dos requisitos das aplicaes, a fim de propor o algoritmo correto. Por outro lado, a nossa classificao identifica aspectos comuns entre as propostas analisadas para propor uma maneira justa de avaliar o seu desempenho, independentemente da quantidade de conhecimento necessrio e cenrio de aplicao. B. Modelos de Avaliao Quanto aos modelos de avaliao, destaca-se uma proposta baseada na teoria de evoluo dos grafos para desenvolver e avaliar protocolos com menor custo de encaminhamento. Ferreira et al. [10] usam uma mtrica para determinar caminhos (i.e., ligaes temporrias entre os ns que forneam caminhos) que rapidamente chegam ao destino. Este modelo fornece um algoritmo que utilizado como referncia para comparar propostas de encaminhamento em redes adhoc mveis. Contudo, no discutido como as mtricas de desempenho e parmetros experimentais devem ser configurados. Por outro lado, neste artigo pretende-se

I. INTRODUO CAPACIDADE dos dispositivos portteis permite aos utilizadores formar facilmente redes para partilha de recursos (i.e., processamento) e de conectividade. Tais redes espontneas tiram vantagens dos contatos oportunistas entre os dispositivos dos utilizadores para armazenar e transmitir informao mesmo na presena de conectividade intermitente (resultante da mobilidade do utilizador, obstculos fsicos). Existem vrias propostas de encaminhamento que fazem uso da capacidade dos dispositivos para superar intermitncia nas comunicaes, onde os dispositivos armazenam dados at que um n intermedirio adequado, ou o prprio, destino seja encontrado com base no paradigma store-carry-forward. Estas propostas abrangem abordagens que consideram mobilidade do n para inundar a rede com varias cpias das mensagens para uma entrega rpida, at abordagens capazes de controlar o nmero de cpias com base no histrico e previso de contatos, por exemplo. Nos ltimos anos surgiram abordagens baseadas na similaridade social (e.g., relaes sociais, interesses) para melhorar o encaminhamento oportunstico. Este artigo prope um Modelo de Avaliao Universal (MAU) que tem um conjunto de parmetros relacionados com a densidade e trfego na rede, e baseado numa classificao que identifica propriedades comuns (i.e., estratgias e mtricas de encaminhamento) de entre propostas de encaminhamento oportunista, no sentido de ter um suporte no desenvolvimento de novas propostas. Tambm comparado o desempenho de propostas oportunistas nas condies especificadas no MAU. Este artigo est organizado da seguinte forma. A Seo II apresenta as classificaes de estratgias de encaminhamento e modelos de avaliao existentes. A proposta de classificao e o modelo de avaliao propostos so apresentados nas Sees III e IV, respectivamente. Na Seo V apresentada e discutida uma avaliao justa entre Epidemic [1], PROPHET [2], Bubble Rap [3], e Spray and Wait [4] baseado no modelo MAU. Finalmente, a Seo VI conclui o artigo.

W. Moreira, SITI, Universidade Lusfona, Lisboa, Portugal, waldir.junior@ulusofona.pt P. Mendes, SITI, Universidade Lusfona, Lisboa, Portugal, paulo.mendes@ulusofona.pt S. Sargento, IT, Universidade de Aveiro, Aveiro, Portugal, susana@ua.pt

identificar as diferentes famlias de propostas de acordo com os seus objetivos distintos e estratgias de encaminhamento, e para fornecer um conjunto de configuraes experimentais para auxiliar na avaliao justa de solues de encaminhamento oportunista. III. MODELO DE CLASSIFICAO Observando-se as abordagens de encaminhamento oportunista presentes na literatura, clara a existncia de diferentes tendncias com base em objetivos especficos. Assim, h a necessidade de uma taxonomia equilibrada e atualizada capaz de incluir as tendncias identificadas nos ltimos anos, com foco exclusivamente no ramo que melhor reflete contatos oportunistas (i.e., estocstico [7]). Esta seo descreve brevemente esta nova taxonomia (direciona-se o leitor para uma verso detalhada em [11]). A taxonomia na Fig. 1 considera a anlise de propostas anteriores e que evoluiu a partir de uma anlise prvia feita em [12]. So identificadas trs grandes categorias baseadas em encaminhamento de uma nica cpia, inundao de mensagens e replicao. Entre as propostas consideradas, 94% pertencem categoria de replicao incluindo a tendncia identificada, similaridade social, que de grande interesse para o nosso estudo e foco das discusses.

ocupando recursos) atravs de mtricas que definem tempo de vida para as cpias da mensagem. Estas propostas tambm so capazes de tomar decises de encaminhamento que utilizam eficientemente os recursos disponveis (e.g., RAPID [14]). Na categoria de similaridade social, as propostas tm algoritmos mais complexos que visam: i) evitar a inundao descontrolada de mensagens e, ii) explorar o comportamento social relacionado com a deteco da comunidade, interesses comuns, e a popularidade do n. O Bubble Rap [3] um bom representante desta categoria. IV. MODELO DE AVALIAO UNIVERSAL O estudo proposto neste artigo mostra que os mtodos de avaliao utilizados at agora nem sempre consideram um conjunto homogneo de parmetros ou configuraes experimentais comparveis, o que compromete a veracidade e imparcialidade das concluses. Mesmo com uma taxonomia estvel, h a necessidade de conceber um modelo de avaliao com base em mtricas de desempenho e cenrios experimentais comuns, evitando avaliaes com as mtricas de desempenho irrelevantes e cenrios tendenciosos. Assim, estudamos dezessete propostas (de 2000 a 2010) que melhor representam as categorias da nossa taxonomia para identificar padres de avaliao/comparao. Mais detalhes deste estudo encontram-se no documento [11]. A. Mtricas de Desempenho Num estudo anterior [12] observou a falta de uma conveno de nomenclatura e diversas definies para uma determinada mtrica. Este entendimento diferente certamente influencia a avaliao de desempenho. Observa-se tambm que a probabilidade de entrega, custo e latncia so as mtricas mais utilizadas. Sendo assim, elas so definidas para estabelecer uma conveno de nomenclatura. Probabilidade de entrega definida como o nmero de mensagens transmitidas em relao ao nmero total de mensagens criadas. Esta mtrica importante, pois reflete a eficcia proposta classificando-a como tendo bom desempenho. No entanto, h sempre um custo associado para a entrega das mensagens no que diz respeito ao nmero de cpias por mensagem entregue. Alm disso, a utilidade da mensagem correlacionada com o seu tempo de vida (TTL), e imperativo para remover dados antigos da rede a fim de evitar o desperdcio de recursos. Por isso, importante que as mensagens cheguem ao seu destino dentro do tempo til. Assim, define-se latncia como o tempo necessrio para entregar uma mensagem desde sua criao. B. Cenrio experimental Outro ponto importante a configurao experimental, onde no h regras definidas j que os parmetros variam nas avaliaes encontradas na literatura. Pudemos observar que as propostas realmente diferem quanto ao cenrio experimental. Algumas propostas fornecem informaes detalhadas, enquanto outras as fornecem apenas parcialmente.

Figura 1. Taxonomia para Encaminhamento Oportunista.

A categoria de encaminhamento de cpia nica bastante interessante, j que estas propostas so capazes de poupar recursos da rede e do n. No entanto, elas sofrem de uma elevada latncia, o que resulta em baixa probabilidade de entrega. Exemplos desta categoria so apresentados em [13]. Embora sendo bastante agressivos, os algoritmos baseados em inundao de mensagens atingem elevada probabilidade de entrega, mas com custo elevado (i.e., consumo de recursos). Um exemplo desta categoria o Epidemic [1]. A fim de reduzir o desperdcio de recursos, propostas baseadas na replicao visam aumentar a probabilidade de entrega atravs da adio controlada de cpias de mensagem na rede. Estas propostas so divididas com base nos contatos, uso de recursos ou similaridade social. Na categoria de propostas baseadas em contatos, considerado o histrico de contatos com o destino para dar suporte ao encaminhamento oportunista de mensagens. A frequncia de contatos com ns no passado, ou o tempo decorrido desde o ltimo contato com o destino usado para decidir quando encaminhar (e.g., PROPHET). As propostas baseadas na utilizao de recursos tentam evitar que as mensagens sejam constantemente replicadas (i.e.,

TABELA I PARMETROS DE DENSIDADE DA REDE E DE TRFEGO.

Parmetros Propostas
Densidade da rea (Km2/Nmero de ns) Cobrindo reas dentro de prdios at cidades/100 a 150

(a) Densidade da rede

Modelo de Mobilidade Velocidade (m/s) Representando pessoas e diferentes meios de transporte Mobilidade Random Waypoint (0-20) e baseado em Comunidade (10-30) Tempos de contato/ Inter-contato Exponencial ou lei de potencia, se puder ser determinado Ns entram em contato periodica e randomicamente Tempo de intercontato segue uma distribuio de lei de potencia Alcance de Transmisso (m) Mnimo de 10 (Bluetooth) e mximo de 250 (Wi-Fi) Emisso de beacon A cada 100 ms Distribuio de Fontes/Destinos Deve ser o mesmo durante toda a avaliao 45/44 (Random) e 2/1 (Com.) Nmero de Mensagens Geradas (Carga) Carga deve ser a mesma

(b) Trfego
Tamanho da Mensagem (Kb) TTL da Mensagem 3 a 10 saltos ou variao entre horas, dias e semanas Tamanho do Buffer 2MB (200 msgs de 10KB)

MAU

1 a 100

PROPHET

0.45/50 (RWP), e 4.5/50 (CM) Infocom05/41 Hong-Kong/37 Cambridge/54 Infocomo6/98 Reality/97

50 e 100

n/a

1 mensagem/seg (RWP), e 20 msgs/seg 2msgs/5seg (com.)

n/a

3 e 11 saltos

200 msgs

Bubble Rap

Traces reais

Bluetooth

n/a

1/1

1000 mensagens

n/a

2, 10 min, 1, 3, 6 horas 1, 2, 4 dias 1, 3 semanas

n/a

Tambm pudemos identificar duas classes principais de parmetros: de densidade de rede e de trfego. As Tabelas I-a e I-b mostram o que recomenda o MAU, juntamente com o que usado no PROPHET e Bubble Rap. Para mais informaes sobre Epidemic, Spray and Wait e outras propostas, recomenda-se a leitura do documento [11]. A densidade da rede permite entender o funcionamento das propostas em cenrios esparsos (contatos espordicos, observando-se a probabilidade de entrega quando a latncia alta) e densos (contatos frequentes, avaliando a capacidade de lidar com a aleatoriedade na hora do encaminhamento). A densidade pode ser ajustada atravs do nmero de ns, que dentre as propostas analisadas, fica entre 100-150 (excluindo casos extremos [15]), e so os valores considerados no MAU. Alm disso, os modelos de mobilidade devem considerar diferentes velocidades e tempo de pausa j que os ns representam pessoas e veculos. Estes parmetros tm impacto nos tempos de contato e intercontato. Observamos que algumas abordagens consideram estes tempos como distribuies exponenciais e de lei de potncia [14] [3], enquanto outras os obtm dos conjuntos de dados utilizados. Analisamos tambm o alcance de transmisso, onde propomos variar entre 10-250 metros, uma vez que se deve representar as capacidades de dispositivos. Quanto aos beacons, deve-se evitar o uso frequente j que a bateria precisa ser poupada. No entanto, usando-os raramente resulta em perda de boas oportunidades de contato. Assim, a emisso de beacons a cada 100 ms pode identificar potenciais contatos, enquanto economiza energia. Ressaltamos que este parmetro no MAU requer um estudo mais detalhado para ser validado. Em relao aos parmetros de densidade de rede (cf. Tabela I-a), o PROPHET considera o mesmo nmero de ns (50) para diferentes densidades, modelos de mobilidade (incluindo um modelo que tenta imitar o comportamento humano) e considera diferentes alcances de transmisso. Apesar de considerar diferentes densidades, modelos de mobilidade e alcances de transmisso, a avaliao do PROPHET feita em cenrios homogneos. Isto no realista, pois o cenrio real heterogneo onde h ns que se deslocam de acordo com padres e velocidade diferente e os dispositivos tm capacidades de transmisso especficas. Quanto ao Bubble Rap, que tem sua avaliao baseada em traces humanos, os autores conseguem ter densidades diferentes (reas cobrindo salas de conferncias at uma cidade). Embora no mencione sobre modelos de mobilidade,

o Bubble Rap segue o comportamento humano encontrado nos traces, o que tambm resulta em tempos de contato e intercontato adequados [14] [3]. O alcance de transmisso considerado foi o do Bluetooth, que representa os dispositivos utilizados na obteno dos traces. J o Spray and Wait tem a sua avaliao considerando diferentes alcances de transmisso e variando o nmero de ns, contudo utiliza apenas um modelo de mobilidade que est longe do encontrado no mundo real. Quando comparado ao PROPHET e Spray and Wait, o Bubble Rap destaca-se em termos de parmetros aceitveis referente densidade da rede proposta no MAU. No entanto, a sua avaliao feita de forma esttica, ou seja, as comunidades so formadas e as centralidades so determinadas com base em informaes que no so atualizadas. O nosso interesse ver como a proposta se comporta num cenrio dinmico, que influencia a forma com que a centralidade e as comunidades so calculadas. Quanto aos parmetros de trfego (cf. Tabela I-b), em quase todas as propostas, o nmero de pares fonte-destino foi definido estaticamente e estes foram distribudos aleatoriamente. No h problema em ter este nmero definido estaticamente, uma vez que mud-lo durante as experincias vai impor alguns desafios. No entanto, este nmero deve ser o mesmo e, mais importante, os pares devem permanecer os mesmos (o que no assegurado com a distribuio aleatria) para garantir condies semelhantes no estudo de avaliao. A carga gerada um parmetro que acrescenta mais variaes s experincias. Observamos propostas onde a carga corresponde a uma mensagem por segundo [1] [2], um nmero de mensagens distribudas uniformemente [3], bem como propostas que fornecem pouca ou nenhuma informao sobre a mesma. Acreditamos que a carga deva ser considerada cuidadosamente para garantir comparaes justas. Como os aplicativos geram mensagens de diferentes tamanhos, a carga deve ser ajustada para representar as aplicaes existentes num cenrio oportunista (e.g.,, mensagens de chat, transferncia de arquivos). Observamos que poucas propostas fornecem informaes sobre este parmetro (1 KB [1] [14] ou entre 10-100 KB [16]). O trfego na rede pode ser afetado pelo TTL da mensagem. Se o TTL muito longo, o consumo de recursos na rede e nos ns pode aumentar. Caso contrrio, as mensagens talvez nem alcancem o destino. Nas propostas estudadas o TTL foi definido como o nmero de saltos [1] [2] ou unidades de

tempo [4], e, normalmente varia entre 3-10 saltos em mdia. Hui et al. [3] mostra que apenas 5% dos ns tem algum nvel de relao com o destino no primeiro salto, assim, sugerimos pelo menos 3 saltos (j que os nveis de interao entre os ns melhora em cerca de 35%) com variao para observar o comportamento das propostas. No caso de se utilizar unidades de tempo, pudemos observar que um TTL em 24 horas e tambm infinito pode mostrar potenciais problemas (e.g., rpida exausto de buffer) com a proposta sendo avaliada. Observamos, tambm, como o desempenho da proposta pode ser influenciado pelo tamanho do buffer. Este parmetro reflete o quanto do armazenamento do seu dispositivo um utilizador est disposto a sacrificar pelos outros. O buffer ilimitado no realista, enquanto que fornecer todo o espao aceitvel em cenrios onde ns (e.g., nibus) devem servir aos outros [14]. Assim, com base nas nossas observaes das propostas, deve-se limitar o buffer em 200 mensagens (10KB). Da Tabela I-b, observamos que o PROPHET tem uma configurao diferente, onde a carga varia de acordo com o modelo de mobilidade, e so considerados diferentes valores de TTL. Normalmente, o buffer pode ser um problema, j que os utilizadores podem no estar dispostos a compartilh-lo. Assim, considerar um buffer limitado est mais perto do cenrio encontrado no mundo real, e uma opo dos autores do PROPHET. No entanto, em relao a estes parmetros, Bubble Rap s fornece informaes sobre os pares fonte-destino e de carga (1000 mensagens geradas entre todos os pares de ns e de tempo de vida das mensagens). O mesmo ocorre com o Spray and Wait, onde as mensagens so geradas seguindo uma distribuio uniforme para destinos escolhidos aleatoriamente. Os parmetros de trfego so aqueles que mais variam nos estudos de comparao. Normalmente, os pares fonte-destino so escolhidos aleatoriamente. Isto influencia a avaliao, j que este conjunto vai variar conforme as simulaes so realizadas. Assim, os estudos de avaliao devem considerar o mesmo subconjunto de pares fonte-destino, e o nmero de mensagens geradas tambm deve permanecer o mesmo. Nestas propostas, os autores no mencionam sobre o tamanho da mensagem. Este parmetro importante visto que as aplicaes geram mensagens com tamanhos diferentes. Apesar de tentar poupar o buffer, o Bubble Rap no indica o tamanho das mensagens que foi considerado na sua avaliao. O Bubble Rap, assim como o Spray and Wait, considera o TTL (expressos em nmero de saltos) das mensagens e sugere um valor mnimo no inferior a 3, j que a maioria dos ns encontrados nos primeiros saltos ainda pertencem comunidade do n que transporta a mensagem. No entanto, o TTL representado em unidades de tempo na sua avaliao. V. AVALIAO JUSTA Nesta seo apresentamos a avaliao de desempenho do Epidemic, PROPHET, Bubble Rap e Spray and Wait nas mesmas condies especificadas no MAU. importante notar que pretendemos mostrar a importncia de uma avaliao homognea ao avaliar propostas de encaminhamento de

categorias diferentes como as baseadas em inundao, contatos e similaridade social, e mostrar como o uso de diferentes configuraes de parmetros e mtricas de desempenho pode resultar numa avaliao que favorea algumas propostas. A. Configuraes de Avaliao e Metodologia O cenrio escolhido tem 150 ns distribudos em 8 grupos de pessoas e 9 grupos de veculos, onde um destes grupos representa patrulhas policiais e segue o modelo de mobilidade Shortest Path Map Based Movement [17] com velocidade entre 7-10 m/s e tempos de pausa entre 100-300 segundos. Os outros grupos de veculos representam nibus, onde cada grupo tem 2 veculos, e seguem o modelo de mobilidade Bus Movement [17] com velocidades entre 7-10 m/s e tempos de pausa entre 10-30 segundos. Os grupos de pessoas seguem o modelo de mobilidade Working DayMovement [17] com velocidades entre 0.8-1.4 m/s, mas podem usar os nibus para se deslocar. Cada um destes grupos tem diferentes pontos de encontro, escritrios e moradas. As pessoas passam 8 horas por dia no trabalho e tm 50% de probabilidade de terem uma atividade aps o trabalho. No escritrio, elas movimentam-se e tm tempos de pausa entre 1 minuto e 4 horas. As atividades aps o trabalho podem ser feitas a ss ou em grupos e duram entre 1 a 2 horas. Cada n tem uma interface de rede sem fios com velocidade de transmisso de 11 Mbps e alcance de 100 metros. O trfego estabelecido entre os mesmos pares fontedestino, onde cerca de 500 mensagens so geradas por dia. O tamanho das mensagens varia de 1 a 100 kB e o TTL varia de horas a semanas. O buffer de 2 MB. Estes valores representam as aplicaes diferentes e a disposio limitada do utilizador em compartilhar o seu espao de armazenamento. As simulaes so realizadas num Opportunistic Network Environment [17] e representam uma interao de 12 dias entre ns (com 2 dias de warm-up, que no so considerados para os resultados). Cada simulao executada dez vezes (com diferentes sementes geradoras de nmeros aleatrios para os modelos de mobilidade utilizados) a fim de proporcionar um intervalo de confiana de 95% para os resultados. Todos os resultados so avaliados considerando as mdias da probabilidade de entrega, do custo e da latncia. B. Resultados Neste artigo observamos o comportamento das propostas sob as mesmas condies e cenrios utilizados em [5], contudo, agora dando mais nfase ao TTL das mensagens, visto que h diferentes aplicaes em redes oportunistas que geram mensagens com vida til variada. A Fig. 2 apresenta os resultados obtidos para a probabilidade mdia de entrega. Ao comparar Epidemic e PROPHET no cenrio definido atravs do MAU, observa-se o mesmo comportamento relatado por Lindgren et al. [2]: PROPHET tem melhor desempenho, alcanando uma vantagem que chega at 17 pontos percentuais. Entretanto, para um TTL de uma hora, o Epidemic tem mais vantagem por inundar a rede rapidamente com cpias das

mensagens, o que aumenta a sua probabilidade de entrega. Porm, a proposta sofre com o aumento do TTL pois as mensagens passam mais tempo no sistema (i,e., a replicar-se) e, consequentemente, reduz a sua probabilidade de entrega, j que o buffer atinge o seu limite mais rapido.
Probabilidade Me dia de Entrega
1

tem menor custo. Tomar decises de encaminhamento com base em aspectos sociais acaba por diminuir o custo j que as cpias apenas sero criadas entre ns bem relacionados entre si. Contudo, no considerar o dinamismo dos relacionamentos sociais afeta negativamente este tipo de abordagem [18].
Custo Me dio
3000

0.8

2500

Nu mero de co pias

0.6

Epidemic PROPHET Bubble Rap Spray and Wait

Epidemic PROPHET Bubble Rap Spray and Wait

2000

1500

0.4

1000

0.2

500

0 1 hora 6 horas 24 horas 2 dias 4 dias 1 semana 3 semanas

0 1 hora 6 horas 24 horas 2 dias 4 dias 1 semana 3 semanas

TTL

TTL

Figura 2. Resultados de Probabilidade Mdia de Entrega.

Figura 3. Resultados de Custo Mdio.

No que concerne comparao de desempenho entre o PROPHET e o Bubble Rap no cenrio especificado com base no MAU, observamos trs pontos interessantes ao contrrio do que reportado no artigo original do Bubble Rap. Primeiro, a probabilidade de entrega comea a diminuir para os TTLs acima das 6 horas. Observa-se tambm que o Bubble Rap apresenta melhores taxas de entrega que o PROPHET para TTL maior ou igual a 2 dias. Alm disso, ambas propostas chegam prximo aos 60% de entrega apenas quando o TTL de 3 semanas, enquanto que no nosso cenrio o PROPHET ultrapassa (~65%) e o Bubble Rap se aproxima (~54%) desta marca com um TTL de 6 horas. Considera-se que este o efeito no s do buffer limitado, mas tambm da heterogeneidade no que concerne os modelos de mobilidade utilizados no cenrio. O Spray and Wait aquele que tem a melhor probabilidade de entrega no cenrio. Isto justifica-se pelo fato de o cenrio conter ns (i.e., nibus e patrulhas de polcia) que o cobrem quase que em toda a sua extenso. Como estes ns acabam por se deslocar muito no cenrio, aliado tambm ao alcance de transmisso (100 m), consequentemente aumenta-se muito a probabilidade das mensagens chegarem ao destino. A Fig. 3 apresenta os resultados relacionados com o custo mdio das propostas. Pode-se dizer que o Epidemic e Spray and Wait so os casos extremos no que concerne esta mtrica. O primeiro funciona com base na inundao descontrolada (i.e., cada n recebe uma cpia se ainda nao a tiver) e assim o faz para ter uma taxa elevada de entrega. O problema que o nvel de interao entre os ns aliado a um buffer limitado torna-se um grande inimigo deste tipo de abordagem. Em contra-partida, o Spray and Wait tem o nmero de cpias (L = 10) por mensagem limitado e o seu custo vai ser sempre baixo. Quanto ao PROPHET e Bubble Rap, a diferena entre eles permanece como no artigo original do Bubble Rap onde este

O PROPHET teve menor custo quando comparado com o Epidemic como reportado no seu artigo original. Entretanto, o seu custo muito maior (~34 vezes) para um TTL de 24 horas, por exemplo. A Fig. 4 apresenta a latncia mdia para mensagens entregues de cada proposta. Tanto o Epidemic como o Spray and Wait tm um comportamento similar no que concerne esta mtrica. O primeiro, ao inundar a rede com cpias, acaba por alcanar ns que logo estaro em contato com o destino. Alm disso, tambm contribui para o desempenho do Spray and Wait juntamente com o alcance de transmisso que, ao aumentar, diminui o tempo para as mensagens chegarem ao destino como reportado no seu artigo original.
Late ncia Me dia
70000

60000

50000

Epidemic PROPHET Bubble Rap Spray and Wait

Segundos

40000

30000

20000

10000

0 1 hora 6 horas 24 horas 2 dias 4 dias 1 semana 3 semanas

TTL

Figura 4. Resultados de Latncia Mdia.

O PROPHET e o Bubble Rap, por serem propostas mais elaboradas, demoram mais tempo para decidir quando encaminhar mensagens. Para alm disso, no caso do Bubble Rap, o fato de no considerar o dinamismo dos relacionamentos sociais faz com que as mensagens sejam

encaminhadas a ns que demoram a encontrar o destino, o que contribui para o aumento da sua latncia. VI. CONCLUSES A capacidade atual dos dispositivos portteis permite aos utilizadores experimentar novas formas de troca de informao por meio de contatos oportunistas. No entanto, esta nova forma de comunicao tem que lidar com a intermitncia destes contatos, o que deu origem a diferentes propostas que tentam diminuir este problema. Contudo, difcil identificar qual proposta apresenta melhor desempenho uma vez que cada uma delas tem um mtodo de avaliao diferente. Analisando as propostas dos ltimos dez anos, observaramse diferentes tendncias com base em objetivos especficos e com diferentes solues de encaminhamento oportunistas. Assim, neste artigo, analisamos propostas diferentes de acordo com as tendncias identificadas, as informaes colecionadas no seu processo de avaliao, e descobrimos propriedades comuns entre as vrias propostas (ou seja, estratgias e mtricas de encaminhamento). O resultado deste estudo um Modelo de Avaliao Universal (MAU) que fornece diretrizes, baseadas numa taxonomia, incluindo a nova tendncia identificada recentemente (i.e., a similaridade social), compreendendo um conjunto de parmetros de desempenho e configurao experimental para auxiliar a avaliao do desempenho de solues de encaminhamento oportunistas. Para validar os nossos princpios, simulamos as propostas Epidemic, PROPHET, Bubble Rap, e Spray and Wait sob as mesmas condies e pudemos verificar que as diferenas entre as propostas so mais evidentes no MAU. Acreditamos que atingimos o nosso objetivo de fornecer uma maneira para efetuar a classificao das solues novas de encaminhamento oportunista, bem como avali-las adequadamente. Como surgem novas propostas na literatura, esta taxonomia ser atualizada com as ltimas tendncias identificadas no contexto das redes oportunistas. AGRADECIMENTOS A FCT pelo apoio financeiro a Waldir Moreira (PhD grant SFRH/BD/62761/2009) e ao projeto UCR (PTDC/EEATEL/103637/2008). REFERNCIAS
[1] [2] A. Vahdat and D. Becker, Epidemic Routing for Partially Connected Ad Hoc Networks, Tech. Rep. CS-200006, Duke University, 2000. A. Lindgren, A. Doria, and O. Scheln, Probabilistic Routing in Intermittently Connected Networks, SIGMOBILE Mob. Comput. Commun. Rev., Vol. 7, No. 3, pp. 1920, 2003. P. Hui, J. Crowcroft, and E. Yoneki, Bubble Rap: Social-based Forwarding in Delay Tolerant Networks, Mobile Computing, IEEE Transactions on, Vol. 10, pp. 15761589, 2011. T. Spyropoulos, K. Psounis, and C. S. Raghavendra, Spray and Wait: An Efficient Routing Scheme for Intermittently Connected Mobile Networks, in Proc. of ACM SIGCOMM WDTN, pp. 252259, Philadelphia, USA, 2005. W. Moreira, P. Mendes, and S. Sargento, Assessment Model for Opportunistic Routing, in Proc. of IEEE LATINCOM, Belm, Brazil, 2011.

[6] [7]

[8]

[9]

[10]

[11]

[12] [13]

[14]

[15]

[16] [17] [18]

S. Jain, K. Fall, and R. Patra, Routing in a Delay Tolerant Network, in Proc. of ACM SIGCOMM, Portland, USA, August 2004. Z. Zhang, Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Tolerant Networks: Overview and Challenges, IEEE Communications Surveys and Tutorials, Vol. 8, No. 1-4, pp. 24 37, 2006. R. J. DSouza and J. Jose, Routing Approaches in Delay Tolerant Networks: A Survey, International Journal of Computer Applications, Vol. 1, pp. 814, 2010. T. Spyropoulos, R. N. Rais, T. Turletti, K. Obraczka, and A. Vasilakos, Routing for Disruption Tolerant Networks: Taxonomy and Design, Wirel. Netw., Vol. 16, pp. 23492370, 2010. A. Ferreira, A. Goldman, and J. Monteiro, Performance Evaluation of Routing Protocols for MANETs with Known Connectivity Patterns Using Evolving Graphs, Wirel. Netw., Vol. 16, pp. 627640, 2010. W. Moreira and P. Mendes, Survey on Opportunistic Routing for Delay/Disruption Tolerant Networks, Tech. Rep. SITI-TR-11-02, SITI, University Lusofona, 2011. W. Moreira and P. Mendes, Routing Metrics for Delay Tolerant Networks, in Proc. of CRC, pp. 217219, Braga, Portugal, 2010. T. Spyropoulos, K. Psounis, and C. S. Raghavendra, Efficient Routing in Intermittently Connected Mobile Networks: The Single-copy Case, IEEE/ACM Trans. Netw., Vol. 16, No. 1, pp. 6376, 2008. A. Balasubramanian, B. Levine, and A. Venkataramani, DTN Routing as a Resource Allocation Problem, in Proc. of SIGCOMM, Kyoto, Japan, 2007. H. Dubois-Ferriere, M. Grossglauser, and M. Vetterli, Age Matters: Efficient Route Discovery in Mobile Ad Hoc Networks Using Encounter Ages, in Proc. of ACM MobiHoc, Annapolis, USA, 2003. S. Nelson, M. Bakht, and R. Kravets, Encounter-based Routing in DTNs, in Proc. of INFOCOM, Rio de Janeiro, Brazil 2009. A. Kernen, J. Ott, and T. Krkkinen, The ONE Simulator for DTN Protocol Evaluation, in Proc. of SIMULTools, Rome, Italy, 2009. W. Moreira, P. Mendes, and S. Sargento, Opportunistic Routing Based on Daily Routines, in Proc. of IEEE WoWMoM Workshop AOC, San Francisco, USA, 2012. (TO APPEAR)

Waldir Moreira graduado (05) em Cincia da Computao pela Universidade da Amaznia, e obteve seu grau de mestre (08) em Cincia da Computao pela Universidade Federal do Par, em Belm, Brasil. Atualmente, aluno do MAP Doctoral Programme in Telecommunications na Universidade de Aveiro e membro do Internet Architectures and Networking Lab na unidade de investigao em Sistemas e Tecnologias Informticas da Universidade Lusfona. Seus interesses de pesquisa so encaminhamento oportunista e baseado em aspectos sociais em redes mesh, cooperativas, e tolerantes a atrasos/disrupes. Paulo Mendes graduado (93) em Engenharia Informtica pela Universidade de Coimbra, Mestre (98) em Engenharia Electrotcnica e de Computadores pela Universidade Tcnica de Lisboa, Ph.D. (03) em Engenharia Informtica pela Universidade de Coimbra. Atualmente, diretor cientfico para a inovao da unidade de investigao em Sistemas e Tecnologias Informticas da Universidade Lusfona, coordenador do Internet Architectures e Networking Lab, e Professor Associado da Universidade Lusfona. membro da ACM SIGCOMM e contribui para o IETF/IRTF. Os seus interesses cientficos so redes cooperativas, redes auto-organizativas sem fios e sistemas sensoriais cooperativos. Paulo Mendes tem mais de 60 artigos e 13 patentes. Susana Sargento graduada (97) em Engenharia Electrnica e de Telelcomunicaes pela Universidade de Aveiro, Ph.D. (03) em Engenharia Electrotcnica pela Universidade de Aveiro. Atualmente, Susana foi docente no Departamento de Cincias de Computadores da Universidade do Porto de 2002 a 2004, e encontra-se desde 2004 na Universidade de Aveiro e Instituto de Telecomunicaes. Durante os ltimos anos ela tem estado envolvida em vrios projetos nacionais e europeus, com responsabilidades de coordenao de vrias atividades, como exemplo FP6 IST-Daidalos. Est correntemente envolvida em vrios projetos Europeus FP7 (Euro-NF), nacionais, e da CMU|Portugal (DRIVE-IN com a Universidade de Carnegie Melon). membro do IEEE. Os seus interesses de investigao centram-se nas reas de redes heterogneas, infra-estruturadas, em malha e ad-hoc (foco em veicular).

[3]

[4]

[5]

ANNEX D - Paper entitled Opportunistic Routing Based on Daily Routines published and presented on the IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications 2012.

Opportunistic Routing Based on Daily Routines

Waldir Moreira, and Paulo Mendes
SITI, University Lusfona Lisbon, Portugal {waldir.junior, paulo.mendes}@ulusofona.pt

Susana Sargento
IT, University of Aveiro Aveiro, Portugal susana@ua.pt

AbstractOpportunistic routing is being investigated to enable the proliferation of low-cost wireless applications. A recent trend is looking at social structures, inferred from the social nature of human mobility, to bring messages close to a destination. To have a better picture of social structures, social-based opportunistic routing solutions should consider the dynamism of users behavior resulting from their daily routines. We address this challenge by presenting dLife, a routing algorithm able to capture the dynamics of the network represented by time-evolving social ties between pair of nodes. Experimental results based on synthetic mobility models and real human traces show that dLife has better delivery probability, latency, and cost than proposals based on social structures. Index Termssocial structures; network dynamics; daily routines; opportunistic routing

I. I NTRODUCTION The pervasive deployment of wireless personal devices is creating the opportunity for the development of novel applications. The exploitation of such applications with a good performance-cost tradeoff is possible by allowing devices to use free spectrum to exchange data whenever they are within wireless range. Since every contact is an opportunity to forward data, there is the need to develop routing algorithms able to bring messages close to a destination, with high probability, low delay and costs. Most of the proposed routing solutions focus on inter-contact times alone [1], while there is still signicant investigation to understand the nature of such statistics (e.g., power-law, behavior dependent on node context). Moreover, the major drawback of such approaches is the instability of the created proximity graphs [2], which changes with users mobility. A recent trend is investigating the impact that more stable social structures (inferred from the social nature of human mobility) have on opportunistic routing [2], [3]. Such social structures are created based on social similarity metrics that allow the identication of the centrality that nodes have in a cluster/community. This allows forwarders to use the identied hub nodes to increase the probability of delivering messages inside (local centrality) or outside (global centrality) a community, based on the assumption that the probability of nodes to meet each other is proportional to the strength of their social connection. A major limitation of approaches that identify social structures, such as communities, is the lack of consideration about the dynamics of networks, which refers to the evolving structure of the network itself, the making and braking of network
978-1-4673-1239-4/12/$31.00 c 2012 IEEE

ties: over a day a user meets different people at every moment. Thus, the users personal network changes, and so does the global structure of the social network to which he/she belongs. When considering dynamic social similarity, it is imperative to accurately represent the actual daily interaction among users: it has been shown [4] that social interactions extracted from proximity graphs must be mapped into a cleaner social connectivity representation (i.e., comprising only stable social contacts) to improve forwarding. This motivates us to investigate a routing solution able to capture network dynamics, represented by users daily life routine. We focus on the representation of daily routines, since routines can be used to identify future interaction among users sharing similar movement patterns, interests, and communities [5]. Existing proposals [6], [2], [3] succeed in identifying similarities (e.g., interests) among users, but their performance is affected as dynamism derived from users daily routines is not considered. To address this challenge, we propose dLife that uses timeevolving social structures to reect the different behavior that users have in different daily periods of time: dLife represents the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different period of times. It considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of users importance, based on its node degree and the social strength towards its neighbors, in different periods of time. In this paper, we show the performance gain of dLife against proposals that are only aware of social structures and node centrality metrics, e.g., Bubble Rap [2]. We also analyze the impact that centrality metrics have on routing, since by determining the relative importance of a node within the community such metrics create potential bottleneck points. For that, we created a community-based version of dLife, called dLifeComm, for a fair comparison with Bubble Rap. Results show that both versions of dLife manage to capture the dynamism of social daily behavior along with social interaction strength, resulting in improved delivery probability, cost, and latency. Our ndings also highlight the impact that centrality has on routing performance when comparing the performance of two community-based approaches (dLifeComm and Bubble Rap).

This paper is structured as follows. Section 2 briey analyses the related work. Section 3 presents TECD and TECDi utility functions along with the algorithms for both versions of dLife. Section 4 presents the evaluation methodology, setup, and results. In Section 5 the paper is concluded and future work is presented. II. R ELATED W ORK Most of the existing opportunistic routing solutions are based on some level of replication [7]. Among these proposals, emerge solutions based on different representations of social similarity: i) labeling users according to their social groups (e.g., Label [8]); ii) looking at the importance (i.e., popularity) of nodes (e.g., PeopleRank [9]); iii) combining the notion of community and centrality (e.g., SimBet [3] and Bubble Rap [2]); iv) considering interests that users have in common (e.g., SocialCast [6]). Such prior-art shows that social-based solutions are more stable than those which only consider node mobility. However, they do not consider the dynamism of users behavior (i.e., social daily routines) and use centrality metrics, which may create bottlenecks in the network. Moreover, such approaches assume that communities remain static after creation, which is not a realistic assumption. On the other hand, prior-art also shows that users have routines that can be used to derive future behavior [5]. It has been proven that mapping real social interactions to a clean (i.e., more stable) connectivity representation is rather useful to improve delivery [4]. With dLife, users daily routines are considered to quantify the time-evolving strength of social interactions and so to foresee more accurately future social contacts than with proximity graphs inferred directly from inter-contact times. III. T HE dLife A LGORITHM The major motivation to devise social-based opportunistic routing has to do with the higher stability that social similarity has in comparison to inter-contact times. However, the dynamism of users social behavior (extracted from daily routines) should be considered in order to guarantee a more realistic representation. This major aspect is missing from existing social-based routing solutions, such as Bubble Rap. Thus, we propose dLife that uses two novel utility functions: TECD to forward messages to nodes that have a stronger social relationship with the destination than the current carrier; with TECD each node computes the average of its contact duration with other nodes during the same set of daily time periods over consecutive days. Our assumption is that contact duration can provide more reliable information than contact history, or frequency when it comes to identifying the strength of social relationships. The reason for considering different daily time periods relates to the fact that users present different behavior during their daily routines [5]. If the carrier and encountered node have no social information towards the destination, forwarding takes place based on a second utility

function, TECDi, where the encountered node gets a message if it has greater importance than the carrier. A second version of dLife, dLifeComm, is designed to allow an easier comparison of solutions that are focused on the dynamics of the network (i.e., dLife, based on users daily routine) and solutions that are focused on the structure of network (i.e., Bubble Rap, based on node centrality). dLifeComm uses TECD and TECDi to exploit communities that arise from social interaction. Communities are detected based on the KClique algorithm [10], as occurs with Bubble Rap: TECD is used to forward within a community based on the social strength that the carrier and encountered nodes have towards the destination, and not their centrality; TECDi is used to forward data based on users importance outside a community. We start this section by explaining how K-Clique is used to detect social structures (i.e., communities) by Bubble Rap and dLifeComm. Then, we explain how to capture the dynamics of the network by computing TECD/TECDi. Finally, we show how to use TECD and TECDi to create the dLife and dLifeComm algorithms. A. Usage of Social Structures A social structure dened as a K-Clique community [10] is a union of all cliques (complete subgraphs of size k ) that can be reached from each other through a series of adjacent cliques, where cliques are adjacent if they share k 1 nodes. Both Bubble Rap and dLifeComm use the K-Clique algorithm to detect the social structure in a proximity graph. The main difference between them is that the former uses the detected structure to compute the centrality of nodes within and outside communities, lacking a representation of the different levels of social interaction that users have over different daily periods of time. On the other hand, dLifeComm considers continuously updated social information, computed based on TECD and TECDi, for forwarding over the detected social structure. That is, the xed communities detected are the same as in Bubble Rap, but the links considered for forwarding within and between communities change over time as they represent different levels of social strength in different time periods. This means that while Bubble Rap considers a xed social structure, dLifeComm is aware of its dynamics: the network is still a xed collection of linked individuals, but now users daily routines inuence the way links are used. Contrary to Bubble Rap and dLifeComm, dLife does not use any social network analysis algorithm, such as K-Clique, to detect a xed global social structure: dLife relies on TECD and TECDi utility functions to capture the dynamics of the network by identifying time-evolving social structures that reect the different interactions that users have over different daily periods of time. With dLife the static structure of traditional network analysis can be thought of as different snapshots taken during specic periods of time. B. Time-Evolving Contact Duration (TECD) TECD aims to capture the evolution of social interactions in the same daily period of time (hereafter called daily sample)

CD(a,d) CD(a,b) CD(a,c)

08:00 a.m.

CD(a,b) CD(a,b)
12:00 p.m.

CD(a,b) CD(a,c)
04:00 p.m.

CD(a,e) CD(a,f)
08:00 p.m. 12:00 a.m. 04:00 a.m.

CD(a,b) CD(a,c)
08:00 a.m.

Daily Sample

Ti D D B A C F E C F E A C F E B A C D B

W(a,b)i

B A C

B A C

Figure 1.

Contacts a user A has with a set of users x (CD(a,x) ) in different daily samples Ti .
t by the weight t+k-i , where the highest weight is associated to the average contact duration in the current daily sample, being it reduced in consecutive samples. i+t1

over consecutive days, by computing social strength based on the average duration of contacts. Fig. 1 shows how social interactions (from the point of view of user A) varies during a day. For instance, it illustrates a daily sample (8 pm - 12 am) over which the social strength of user A to users D, E , and F is much stronger (less intermittent line) than the strength to users B and C . Fig. 1 aims to show the dynamics of a social network over a one-day period, where users behavior in different daily samples lead to different social structures. As illustrated in Fig. 1, users social strength in a given daily sample depends on the average contact duration that they have in such time period: if user x has n contacts with user y in a daily sample Ti , having each contact k a certain duration (Contact Duration - CD (x, y )k ), at the end of Ti the Total Contact Time (T CT (x, y )i ) between them is given by Eq. 1.
n

T ECD = w (x, y )i =
k=i

t AD (x, y )k t+ki

(3)

C. TECD Importance (TECDi) TECDi aims to capture the Importance (I (x)i ) of any user x in a daily sample Ti , based on its social strength (TECD) towards each user that belongs to its neighbor set (N (x)) in that time interval, in addition to the importance of such neighbors. TECDi is based on the PeopleRank function [9]. However, TECDi considers the social strength between a user and its neighbors encountered within a specic Ti , while PeopleRank computes the importance considering all neighbors of x at any time. It is worth mentioning that the dumping factor (d) in TECDi has a similar meaning as in PeopleRank: to introduce some randomness while taking forwarding decisions. T ECDi = I (x)i = (1 d) + d
y N (x)

T CT (x, y )i =
k=1

CD (x, y )k

(1)

The Total Contact Time between users in the same daily sample over consecutive days can be used to estimate the average duration of their contacts for that specic daily sample [5]: the average duration of contacts between users x and y during a daily sample Ti in a day j (AD (x, y )ji ) is given by a cumulative moving average of their T CT in that daily sample (T CT (x, y )ji ) and the average duration of their contacts during the same daily sample Ti in the previous day (AD (x, y )(j 1)i ) as illustrated in Eq. 2. AD (x, y )ji = T CT (x, y )ji + (j 1)AD (x, y )(j 1)i (2) j

w (x, y )i

I (y )i (4) N ( x)

D. Distributed Algorithm dLife decides to replicate messages based on TECD/TECDi. If the encountered node has better relationship with the destination in the current daily sample, it receives messages copies. By having higher weight (i.e., high social relationship), there is a much greater chance that the encountered node will meet the destination in the future. If relationship to destination is unknown, replication happens only if the encountered node has higher importance than the carrier. dLifes operation happens as follows (cf. Alg. 1): when the CurrentN ode meets a N odei in a daily sample Tk , it gets a list of all neighbors of N odei in that daily sample and its weights towards them (N odei .WeightsToAllneighbors computed based on Eq. 3). Then, every M essagej in CurrentN odes buffer is replicated to N odei if the latters weight towards the destination (getWeightTo(Destinationj )) is greater than CurrentN odes weight towards the same destination. Otherwise, CurrentN ode receives N odei s importance, and messages are replicated if N odei is more important than the CurrentN ode in the current Tk .

The social strength between users in a specic daily sample may also provide some insight about their social strength in consecutive k samples in the same day, Ti+k . This is what we call Time Transitive Property. This property increases the probability of nodes being capable of transmitting large data chunks, since transmission can be resumed in the next daily sample with high probability. TECD (cf. Eq. 3) is able to capture the social strength (w (x, y )i ) between any pair of users x and y in a daily sample Ti based on the Average Duration (AD (x, y )i ) of contacts between them in such daily sample and in consecutive t 1 samples, where t represents the total number of daily samples. When k > t, the corresponding AD (x, y ) value refers to the daily sample k t. In Eq. 3 the time transitive property is given

Algorithm 1 Forwarding with dLife

begin foreach N odei encountered by CurrentN ode do receive(N odei .WeightsToAllneighbors) foreach M essagej buffer.(CurrentN ode) & / buffer(N odei ) do if (N odei .getWeightTo(Destinationj ) > CurrentN ode.getWeightTo(Destinationj )) then CurrentN ode.replicateTo(N odei , M essagej ) else receive(N odei .Importance) if (N odei .importance > CurrentN ode.importance) then CurrentN ode.replicateTo(N odei , M essagej ) end

A. Evaluation Methodology Performance analysis of dLife, dLifeComm, and Bubble Rap is done on the Opportunistic Network Environment (ONE). Each simulation, in both scenarios, is run ten times (with different random number generator seeds) to provide results with a 95% condence interval. All results are analyzed in terms of average delivery probability (i.e., ratio between the number of delivered messages and total number of created messages), average cost (i.e., number of replicas per delivered message), and average latency (i.e., time elapsed between message creation and delivery). B. Experimental Settings The heterogeneous simulation scenario is part of the Helsinki city and has 150 nodes distributed in 8 groups of people and 9 groups of vehicles. Nodes are equipped with a WiFi interface (11 Mbps/100 m). One vehicle group represents police patrols and follows the Shortest Path Map Based Movement where nodes randomly choose a destination point and take the shortest path to it. Their waiting times are between 100 and 300 seconds. The remaining groups represent buses, each composed of 2 vehicles following the Bus Movement and with waiting times between 10 and 30 seconds. Vehicles speeds range from 7 to 10 m/s. People follow the Working Day Movement with walking speeds ranging from 0.8 to 1.4 m/s, but can also use buses. Each group has different meeting spots, ofces, and home locations. People spend 8 hours at work and present 50% probability of having an evening activity after leaving work. In the ofce, nodes move around and have pause times ranging from 1 minute to 4 hours. Evening activities can be done alone or in a group, and can last between 1 and 2 hours. For the experiments based on real human traces, we use the Cambridge traces [11] between 36 nodes. Data was collected in different locations for two months while Cambridge University students moved performing their daily activities. Trafc load comes from a le previously generated with established source/destination pairs, where a total of 6000 messages are generated in each scenario. Message TTL values are set at 1, 2 and 4 days, as well as 1 and 3 weeks. Since we want a fair comparison against Bubble Rap, we choose the TTL values in which Bubble Rap has the best performance behavior in terms of delivery probability and cost [2], as well as TTL values that can represent the different applications that cope with opportunistic networks. Message size ranges from 1 to 100 kB. The buffer space is of 2 MB to create a realistic scenario, as users may not be willing to share all of the storage capacity of their devices. Message and buffer size comply with the universal evaluation framework that we have proposed [7] based on the evidence that prior-art on opportunistic routing follows completely different evaluation settings, making the assessment a challenging task. To assess the performance of dLifeComm and Bubble Rap, we consider K-Clique and cumulative window algorithms for community formation and node centrality computation as proposed by Hui et al. [2]. The parameter k (= 5) is chosen

As mentioned before, dLifeComm combines the notion of community, as Bubble Rap, and social strength for forwarding: when a user has a message to another user in a different community, it forwards the message towards the destinations community using TECDi. The assumption is that users with higher importance have higher probability to reach the destinations community faster. When the destinations community is reached, forwarding is done towards the destination, by replicating the message to users with higher social strength (TECD) towards the destination, and not higher centrality, as in Bubble Rap. The main goal is to avoid congestion points. dLifeComms operation is rather simple (cf. Alg. 2): when the CurrentN ode meets a N odei , it gets a list of all neighbors of N odei and its weights towards them (N odei .WeightsToAllneighbors computed based on Eq. 3) in the current daily sample Tk . If N odei belongs to the same community as the destination of M essagej , the message is replicated if the weight of N odei towards the destination is greater than CurrentN odes weight towards this destination. If N odei belongs to a different community, CurrentN ode receives N odei s importance, and messages are replicated if N odei s importance is greater than that of the CurrentN ode. As Bubble Rap, dLifeComm allows users - not in the destination community - to delete messages already delivered to such community, to avoid useless replications. It is worth noting that dLifeComms algorithm is different from that of Bubble Rap as it uses TECD/TECDi instead of local/global centralities for forwarding within/between communities. Algorithm 2 Forwarding with dLifeComm
begin foreach N odei encountered by CurrentN ode do receive(N odei .WeightsToAllneighbors) foreach M essagej buffer.(CurrentN ode) & / buffer(N odei ) do if (N odei .isInCommunityOf(Destinationj )) if (N odei .getWeightTo(Destinationj ) > CurrentN ode.getWeightTo(Destinationj )) then CurrentN ode.replicateTo(N odei , M essagej ) else receive(N odei .Importance) if (N odei .importance > CurrentN ode.importance) then CurrentN ode.replicateTo(N odei , M essagej ) end

IV. dLife E VALUATION This section starts by describing the evaluation methodology and experimental settings. Then, our considerations about the results obtained when comparing dLife with dLifeComm and Bubble Rap are presented considering two scenarios: one based on simulations built with different mobility patterns, and another based on real human traces.

based on simulations in which Bubble Rap has the best overall performance in terms of the considered evaluation metrics. As dLife considers daily samples (cf. Section III), our ndings (omitted due to limited space) show that 24 daily samples (i.e., each of one hour) brings dLife to its best. The reason is that the shorter the samples, the more rened the information on social strength and users importance is, since the social weight is updated more frequently. C. Experimental Results We start by providing some considerations about our ndings: the average number of contacts per hour is of approximately 920 in the heterogeneous scenario and of approximately 29 in the human traces. Moreover, contacts are more sporadic in the trace scenario than in the heterogeneous one, in which contact frequency is more homogeneous. We also notice that the average number of unique communities is higher in the heterogeneous scenario (~69) than in the trace scenario (~6.7). Furthermore, most of the created communities encompasses all the existing nodes (150 for the heterogeneous simulations, and 36 for trace). This means that independently of the level of contact homogeneity, nodes are still well connected.
Average Delivery Probability
0.9 0.8 0.7 0.9 0.8 0.7

Average Delivery Probability

0.5 0.4 0.3 0.2 1 day 2 days 4 days 1 week 3 weeks

0.6

0.6 0.5 0.4 0.3 0.2 1 day

Bubble Rap dLife Comm dLife

percentage points, respectively) than Bubble Rap, which shows a similar behavior as reported by Hui et al. [2], where delivery probability increases with TTL, since K-Clique creates an average of 6.7 communities encompassing almost all nodes in each one. Thus, a 2-day TTL is enough to reach a node in the destination community increasing the probability of delivery. However, since Bubble Rap relies on a central local node to deliver inside a community, and since there is still a probability that such node may not be well connected with the destination, the probability of delivery does not benet from a higher TTL. The good performance of both versions of dLife is due to network dynamics (from users daily routines). This allied to the network structure (i.e., communities), made dLifeComm outperform Bubble Rap, but still suffering with the community formation overhead; while by only considering such dynamics, dLife turns out to be the best proposal. We believe that the similar performance behavior of both proposals in the human trace scenario is due to the fact that very little communities are formed and most of the nodes belong to such communities, thus reducing the effect of the overhead seen in the heterogeneous scenario. Additionally, results suggest that the usage of centrality has a higher impact (i.e., negative) than the usage of community formation, as centrality creates bottlenecks: this can be easily seen when comparing dLifeComm (combining the notion of community and TECD/TECDi) and Bubble Rap (combining the notion of community and centrality).
Average Cost
1600 40

Average Cost Number of replicas

35 30 25 20 15 10 5 0 1 day 2 days 4 days 1 week 3 weeks

2 days 4 days 1 week 3 weeks

Number of replicas

1400 1200 1000 800 600 400 200 0 1 day 2 days 4 days 1 week 3 weeks
Bubble Rap dLife Comm dLife

TTL

TTL

(a) Heterogeneous scenario Figure 2.

(b) Cambridge traces

Average delivery probability

Figs. 2(a) and 2(b) show the average delivery probability: for the simulated heterogeneous scenario (cf. Fig. 2(a)), dLife and dLifeComm have a performance 39.5 and 31.2 percentage points better than Bubble Rap, respectively. The main reason for that is that Bubble Rap has to go through the process of forming communities to perform suitable forwarding. Since communities are not immediately available, Bubble Rap relies on node global centrality to increase the probability of reaching destinations. However, in this scenario, the centrality of nodes is very heterogeneous where a few nodes (~17%) have very high centrality and the remaining nodes have mid/low centrality. Since most of the messages are originated in nodes with mid/low centrality, this results in a increase in message replication as Bubble Rap replicates when meeting a node with higher centrality. Such behavior quickly exhausts buffer space, which worsens as TTL increases since messages are allowed to live longer in the system, having higher probability to be replicated. Both versions of dLife also experience buffer exhaustion as TTL increases, and dLifeComm is affected by the community formation. However, since replication occurs wisely due to dLifes capability of capturing the dynamism of nodes behavior, these effects are mitigated. With real traces (cf. Fig. 2(b)), dLife and dLifeComm still have better performance (reaching up to 31.5 and 31.3

TTL

TTL

(a) Heterogeneous scenario Figure 3.

(b) Cambridge traces Average cost

As for the average cost (cf. Figs. 3(a) and 3(b)). We observe in the simulated heterogeneous scenario (cf. Fig. 3(a)) that dLife and dLifeComm are cost effective. They produce up to 78% and 68% less replicas than Bubble Rap, respectively. This good behavior reects the wise forwarding decisions that both proposals are able to perform (based on TECD and TECDi). It is indeed an indication that dLife is able to derive a clearer social graph, based on edges with high social strength and vertices with higher importance. Regarding Bubble Rap, its cost is expected to increase with TTL: despite getting rid of a message when it reaches the destinations community, to avoid further replication, other replicas continue to be made by other carriers, which explains Bubble Raps higher cost. The real trace scenario (cf. Fig. 3(b)) still shows the lower cost of dLife and dLifeComm in relation to Bubble Rap (reaching up to 55% and 50.5% less, respectively). The cost reduction for Bubble Rap with a 4-day TTL is due to the sporadic nature of contacts in this scenario. This results in a lower average number of replicas created as there are only few nodes to receive such copies at the time of exchange.

Regarding the average latency (cf. Figs. 4(a) and 4(b)), in the heterogeneous scenario (cf. Fig. 4(a)), dLife and dLifeComm deliver messages with lower latency (48.3% and 46.1% less, respectively) than Bubble Rap. It is easily observed the advantage of taking wiser decisions by using dLife: messages are only forwarded in the presence of strong social links or highly important nodes in the current daily sample. Thus, by considering stronger social links with the destination or more important encountered nodes in specic daily samples, messages are delivered faster, since the probability of them coming in contact with the destination in the near future is higher. Bubble Rap does not capture such dynamism which leads it to create replicas that take more time to reach the destination due to the weaker social ties of the carrier with the destination. These results suggest that considering the dynamism of daily routines allows nodes to select the best forwarder in different daily samples, while centrality leads to the identication of a node that may be well connected in average for the complete duration of the experiment, but not in all daily samples.
Average Latency
50000 40000 50000 40000

Average Latency

bines the TECD and TECDi utility functions to derive, from users social daily routines, the social strength among users and their importance. Our ndings show that by incorporating the dynamism of users social daily behavior in opportunistic routing wiser forwarding decisions are performed, leading to better delivery probability, cost and latency than proposals based only on social structures, i.e., Bubble Rap. Moreover, by comparing Bubble Rap with dLifeComm, a solution that combines network structure (i.e., communities) with network dynamics (i.e., daily routines), we show that the usage of centrality has a higher impact (i.e., negative) in the system performance than the usage of detected communities. As future work, we plan to improve dLifes performance with the introduction of randomness: it has been shown that even with complete knowledge on the social relationship among users, delivery probability does not reach its maximum [9]. Additionally, we will extend dLife to have a point-tomultipoint behavior and test it with real traces encompassing large number of nodes (e.g., MIT Reality mining project). And nally to further investigate other variables besides contact duration, coming from proximity, conversational and online social networks, when assessing the impact that a better inference of social behavior may have on opportunistic routing. ACKNOWLEDGMENT To FCT for supporting UCR (PTDC/EEA-TEL/103637/2008) project and Mr. Moreiras PhD grant (SFRH/BD/62761/2009). R EFERENCES
[1] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott, Impact of human mobility on the design of opportunistic forwarding algorithms, in Proceedings of INFOCOM, (Barcelona, Spain), April, 2006. [2] P. Hui, J. Crowcroft, and E. Yoneki, Bubble rap: social-based forwarding in delay tolerant networks, Mobile Computing, IEEE Transactions on, vol. 10, pp. 15761589, November, 2011. [3] E. M. Daly and M. Haahr, Social network analysis for routing in disconnected delay-tolerant manets, in Proceedings of ACM MobiHoc, (Montreal, Canada), September, 2007. [4] T. Hossmann, T. Spyropoulos, and F. Legendre, Know thy neighbor: Towards optimal mapping of contacts to social graphs for dtn routing, in Proceedings of IEEE INFOCOM, (San Diego, USA), March, 2010. [5] N. Eagle and A. Pentland, Eigenbehaviors: identifying structure in routine, Behavioral Ecology and Sociobiology, vol. 63, pp. 10571066, May, 2009. [6] P. Costa, C. Mascolo, M. Musolesi, and G. P. Picco, Socially-aware routing for publish-subscribe in delay-tolerant mobile ad hoc networks, Selected Areas in Communications, IEEE Journal on, vol. 26, pp. 748 760, June, 2008. [7] W. Moreira, P. Mendes, and S. Sargento, Assessment model for opportunistic routing, in Proceedings of the IEEE LATINCOM, (Belem, Brazil), October, 2011. [8] P. Hui and J. Crowcroft, How small labels create big improvements, in Proceedings of IEEE PERCOM Workshops, (White Plains, USA), March, 2007. [9] A. Mtibaa, M. May, M. Ammar, and C. Diot, Peoplerank: Combining social and contact information for opportunistic forwarding, in Proceedings of INFOCOM, (San Diego, USA), March, 2010. [10] G. Palla, I. Derenyi, I. Farkas, and T. Vicsek, Uncovering the overlapping community structure of complex networks in nature and society, Nature, vol. 435, pp. 814818, June, 2005. [11] J. Scott, R. Gass, J. Crowcroft, P. Hui, C. Diot, and A. Chaintreau, CRAWDAD trace cambridge/haggle/imote/content (v. 2006-09-15). Downloaded from http://crawdad.cs.dartmouth.edu/cambridge/haggle/imote/content, 2006.

Seconds

30000 20000 10000 0

Seconds

30000 20000 10000 0

Bubble Rap dLife Comm dLife

1 day 2 days 4 days 1 week 3 weeks

1 day 2 days 4 days 1 week 3 weeks

TTL

TTL

(a) Heterogeneous scenario Figure 4.

(b) Cambridge traces Average latency

In the real trace scenario (cf. Fig. 4(b)), dLife and dLifeComm deliver messages faster (83.7% and 84.7% less, respectively) than Bubble Rap in comparison with the heterogeneous scenario. Despite the sporadic contacts of the real trace scenario, some nodes are still well connected and, since both versions of dLife are able to identify the best social connections (i.e., independently of the notion of community), messages are replicated to nodes which have the highest probability to meet destinations in the near future, decreasing the distance (i.e., hops) to reach the destination, which in turn reduces the delivery time. Bubble Rap also experiences a reduction in the distance to reach destinations, but its latency behavior remains almost the same in both scenarios. We believe this is due to the fact that most of the existing nodes in the studied scenarios belong to the formed communities, as earlier noted. Since these communities are almost the same for the duration of the experiments, Bubble Rap relies solely on node centrality, which does not capture the dynamism of users behavior, and thus messages need more time to reach destinations. Despite of considering community formation, dLifeComm is less affected since it also considers the node importance to propagate messages. V. C ONCLUSIONS AND F UTURE W ORK Since social information is quite useful to aid data forwarding in opportunistic networks, we introduce dLife, which com-

ANNEX E Internet-Draft submitted to IRTF DTNRG.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 1 of 36

DTN Research Group Internet-Draft Expires: January 8, 2013

W. Moreira P. Mendes SITI, Universidade Lusofona R. Ferreira E. Cerqueira ITEC, Universidade Federal do Para July 7, 2012

Opportunistic Routing based on Users Daily Life Routine draft-moreira-dlife-00 Abstract This document is written in the context of the Delay Tolerant Networking Research Group and will be presented for reviewing by that group. This document defines dLife, an opportunistic routing protocol that takes advantage of time-evolving social structures. dLife belongs to the family of social-aware opportunistic routing protocols for intermittently connected networks. dLife operates based on a representation of the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different period of times. It considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of user's importance, based on its node degree and the social strength towards its neighbors, in different periods of time. It is intended for use in wireless networks where there is no guarantee that a fully connected path between any source destination pair exists at any time, a scenario where traditional routing protocols are unable to deliver bundles. Such networks can be sparse mesh, in which case intermittent connectivity is due to lack of physical connections, or dense mesh, in which case intermittent connectivity may be due to high interference or shadowing. In any case, intermittent connectivity can also be due to the availability of devices (e.g., unavailable due to power saving rules). The document presents an architectural overview followed by the protocol specification. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 1] July 7, 2012

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current InternetDrafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on MONTH DAY, 2012. Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Page 2 of 36

Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 1.1. Applicability of the Protocol . . . . . . . . . . . . . 1.1.1. Protocol Stack . . . . . . . . . . . . . . . . . . 1.1.2. Applicability scenarios . . . . . . . . . . . . . . 1.1.2.1. Urban Areas Networks . . . . . . . . . . . . . 1.1.2.2. Mission-critical Networks . . . . . . . . . . . 1.2. Relation with the DTN Architecture and Networking Model 1.3. Differentiation to other Opportunistic Routing Proposal 1.4. Requirements notation . . . . . . . . . . . . . . . . . 2. Node Architecture . . . . . . . . . . . . . . . . . . . . . 2.1. dLife Components . . . . . . . . . . . . . . . . . . . 2.2. Routing Algorithm . . . . . . . . . . . . . . . . . . . 2.2.1. Time-Evolving Contact Duration (TECD) . . . . . . . 2.2.2. TECD Importance (TECDi) . . . . . . . . . . . . . . 2.3. Forwarding strategy . . . . . . . . . . . . . . . . . . 2.3.1. Basic Strategy . . . . . . . . . . . . . . . . . . 2.3.2. Prioritized Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 5 6 6 7 7 9 10 10 11 12 13 14 15 15 15

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 2] July 7, 2012

2.4. Interfaces . . . . . . . . . 2.4.1. Bundle Agent . . . . . . 2.4.2 Lower Layers . . . . . . . 3. Protocol Overview . . . . . . . . 3.1. Neighbor Sensing Phase . . . 3.2. Information Exchange Phase . 3.2.1. Operation in the presence 3.3. Bundle Reception Policies . . 3.3.1. Queueing policy . . . . . 3.3.2. Custody Policy . . . . . 3.3.3. Destination Policy . . . 4. Message Formats . . . . . . . . . 4.1. Header . . . . . . . . . . . 4.2. TLV Structure . . . . . . . . 4.3. TLVs . . . . . . . . . . . . 4.3.1. Hello TLV . . . . . . . . 4.3.2. ACK TLV . . . . . . . . . 4.3.3. Social TLV . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . of multiples neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

15 16 16 17 18 19 20 20 20 21 22 22 23 26 27 27 29 30

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
5. Detailed Operation . . . . . . 5.1. High Level State Tables . . 5.2. High Level Meta-Data Table 6. Security Considerations . . . . 7. Implementation Experience . . . 8. Deployment Experience . . . . . 9. References . . . . . . . . . . 9.1 Normative References . . . 9.2 Informative References . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 32 35 36 38 38 39 39 40 40

Page 3 of 36

Moreira, et al. Internet-Draft 1. Introduction

00 0C

Expires January 8, 2013 dLife

[Page 3] July 7, 2012

The pervasive deployment of wireless personal devices is creating the opportunity for the development of novel applications. The exploitation of such applications with a good performance-cost tradeoff is possible by allowing devices to use free spectrum to exchange data whenever they are within wireless range, specially in scenarios where it is difficult to find an end-to-end path between any pair of nodes at any moment. In such scenarios every contact is an opportunity to forward data. Hence, there is the need to develop networking solutions able to buffer messages at intermediate nodes for a longer time than normally occurs in the queues of conventional routers (cf. Delay- Tolerant Networking [RFC4838]), and routing algorithms able to bring such messages close to a destination, with high probability, low delay and costs. Most of the proposed routing solutions focus on inter-contact times alone [Chaintreau06], while there is still significant investigation to understand the nature of such statistics (e.g., power-law, behavior dependent on node context). Moreover, the major drawback of such approaches is the instability of the created proximity graphs [Hui11], which changes with users' mobility. A recent trend is investigating the impact that more stable social structures (inferred from the social nature of human mobility) have on opportunistic routing [Hui11], [Daly07]. Such social structures are created based on social similarity metrics that allow the identification of the centrality that nodes have in a cluster/community. This allows forwarders to use the identified hub

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
nodes to increase the probability of delivering messages inside (local centrality) or outside (global centrality) a community, based on the assumption that the probability of nodes to meet each other is proportional to the strength of their social connection. A major limitation of approaches that identify social structures, such as communities, is the lack of consideration about the dynamics of networks, which refers to the evolving structure of the network itself, the making and braking of network ties: over a day a user meets different people at every moment. Thus, the user's personal network changes, and so does the global structure of the social network to which he/she belongs. When considering dynamic social similarity, it is imperative to accurately represent the actual daily interaction among users: it has been shown [Hossmann10] that social interactions extracted from proximity graphs must be mapped into a cleaner social connectivity representation (i.e., comprising only stable social contacts) to improve forwarding. This motivates us to specify a routing protocol

Page 4 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 4] July 7, 2012

aware of the network dynamics, represented by users' daily life routine. We focus on the representation of daily routines, since routines can be used to identify future interaction among users sharing similar movement patterns, interests, and communities [Eagle09]. Existing proposals [Costa08], [Hui11], [Daly07] succeed in identifying similarities (e.g., interests) among users, but their performance is affected as dynamism derived from users' daily routines is not considered. To address this challenge, we propose dLife that uses time-evolving social structures to reflect the different behavior that users have in different daily periods of time: dLife represents the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different period of times. dLife considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of user's importance, based on its node degree and the social strength towards its neighbors, in different periods of time. 1.1. Applicability of the Protocol This section describes the applicability of the dLife protocol in terms of the networking protocol stack and in terms of the usage scenarios that are representative of the daily life experience of most people. The latter aims to check which are the communication challenges that can be mitigated by deploying a delay-tolerant routing protocol. The focus goes to scenarios involving missioncritical environments that represent sporadic situations that require a spontaneous and efficient exchange of information, as well as communications in urban environments, which can also benefit from the existence of a DTN. This document does not focus on scenarios such as space networks and rural area networks, since space networks rely on the usage of single links with extreme long delay, while most of the potential rural area

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
scenarios will require a store-and-carry system (ferry type) and not so much a store-carry-forward system. 1.1.1. Protocol Stack The dLife protocol is expected to interact with the Bundle Protocol agent for retrieving information about available bundles and for requesting bundles to be sent to another node (cf. section 2.4.1). It

Page 5 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 5] July 7, 2012

is expected that the associated bundle agents are then able to establish a link, over the TCP convergence layer [I-D.irtf-dtnrg-tcpclayer]) or the UDP convergence layer [I-D.irtf-dtnrg-udp-clayer]) to perform this bundle transfer. In what concerns information needed for the operation of dLife, dLife does not impose any requirements for data reliability transfer in order not to restrict its applicability. Hence, data exchange may take place over transport protocols that do not provide neither message segmentation or reliability, nor in order delivery. Hence, dLife provides itself the capability to segment protocol messages into submessages. Submessages are provided with sequence numbers, and this, together with the capability for positive acknowledgements allows dLife to operate over an unreliable protocol such as UDP or potentially directly over IP. Moreover, dLife expects to be able to use bidirectional links for information exchange; this allows information exchange to take place in both directions over the same link, avoiding the need to establish a second link for information exchange in the reverse direction. 1.1.2. Applicability scenarios The identified scenarios aim to illustrate the applicability of dLife in real scenarios. In technical terms, dLife aims to target networks where we may not find any end-to-end path between any pair of nodes at some moment in time. The lack of end-to-end path may be due to node mobility and availability (e.g., switching off radios), aspects that create connectivity patterns that are correlated with the daily habits of citizens. Human behavior patterns (often containing daily or weekly periodic activities) provide one example where dLife is expected to be applicable, independently of the type of personal device: it can be of explicit usage (e.g., smartphones) or of implicit usage (e.g., embedded devices). Scientific results [Moreira12a] [Moreira12b] show that dLife is able to benefit from the predictability of human behavior in daily periods of time even in the presence of few contacts. However, the behavior predictability can be estimated more accurately with a higher number of events. 1.1.2.1. Urban Areas Networks This seems to be the most challenging scenario to analyze the applicability of DTN employing dLife as the store-carry-forward routing protocol. A study of DTN routing for urban scenarios may bring a coherent understanding about the advantages and challenges of using a DTN system in the daily life of millions of people. A study

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
Moreira, et al. Internet-Draft
00 0C

Page 6 of 36

Expires January 8, 2013 dLife

[Page 6] July 7, 2012

of the applicability of DTN routing in urban scenarios may benefit from a good understanding of the per-person bit density (available capacity per second/hour/day) in a major metropolitan area. In a urban area there are several examples of networking scenario that can gain from the applicability of dLife, such as: Urban " dark" places due to high mobility (e.g., fast trains), indoors (e.g., subway systems, in-building) and outdoor (e.g., areas with closed APs, areas with significant interference); Off-load of cellular networks, since cellular operators do not like to have data traffic unrelated to services provided in their networks; The cost of cellular wireless data, which decreases the relation quality/price of cellular data communications; Networks of embedded objects, which will require delay-tolerant communications over short-distance wireless interfaces and not over cellular ones. 1.1.2.2. Mission-critical Networks At any point, natural catastrophes can happen and such type of network can be deployed in order to facilitate rescue and medical operations. Another type of situation that a mission-critical network may be formed is in hostile environment such as war scenarios. Independently of the scenario for its application, this type of networks must be readily available through any sort of Wi-Fi enabled equipment (PDAs, cell phones, laptops, APs) which are expected to cooperate with the aim of helping the dissemination of information. Information must reach the interested parties as quickly as possible to achieve fast results for the actions being taken. In mission-critical networks there are several examples of networking scenario that can gain from the applicability of dLife, such as: Disaster networks where no (maybe very few) infrastructure is available since it may have been destroyed; Military networks, where communications can be established using devices carried by soldiers as well as other military vehicles and easily deployed equipments. 1.2. Relation with the DTN Architecture and Networking Model The DTN architecture introduces the bundle protocol [RFC5050], which provides a way for applications to "bundle" an entire session, including both data and meta-data, into a single message, or bundle, that can be sent as a unit. The bundle protocol provides end-to-end addressing and acknowledgments. Hence, dLife is intended to provide routing services in a network environment that uses bundles as its data transfer mechanism, but could also be used in other intermittent environments. From a networking model perspective, a DTN is a network of self-

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 7] July 7, 2012

organizing wireless nodes connected by multiple time-varying links, and where end-to-end connectivity is intermittent. Even in urban scenarios, it is possible to face intermittent connectivity due to dark areas, such as inside buildings and metropolitan systems, as well as public areas with closed access points or even places overcrowded with wireless access points. Unavailability of wireless

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
connectivity can be also a result of power-constrained nodes that frequently shut down their wireless cards to save energy. From a conceptual point of view, a DTN consists of a node meeting schedule and workload. A node meeting schedule is a directed multigraph where each direct edge between two nodes represents a meeting opportunity between them, and it is annotated with a starting time of the meeting, the ending time of the meeting, if known, the size of the transfer opportunity (i.e., contact capacity), and the contact type. The workload is a set of messages. Each message can be represented by the source, destination, size, time of creation at the source, and priority. In dLife, a contact is defined by the tuple <starting time, end time, contact duration> and a message by the tuple <source, destination, size>. A DTN model encompasses the notion of type of contact or connectivity. In current networks, the connectivity of a link or path is generally given as a binary state (i.e., connected or disconnected). In DTNs, a richer set of connectivity options is required to make efficient routing decisions. Most importantly, links (and paths, by extension) may provide a scheduled, predicted or opportunistic communication. Scheduled contacts imply some a priori knowledge about adjacent nodes regarding future availability of links for message forwarding. Scheduled links are the most typical cases for today's Internet and satellite networks. Predicted contacts correspond to communication opportunities wherein the probability of knowing whether a link will be available at a future point in time is strictly above zero and below one. Such links are the result of observed behavior (e.g., a person may use its home Internet connection with significant probability for any given time period) being characterized using statistical estimation. Predicted links are only becoming of serious concern recently, namely in ad-hoc wireless networks where node mobility may be significant. In more challenging environments, such as mission-critical networks for instance, the future location of communicating entities may be neither known nor predictable. These types of contacts are known as opportunistic. Such opportunistic contacts are defined as a chance to forward messages towards a specific destination or a group of destinations. In such unpredictable scenario, it is important to take

Page 7 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 8] July 7, 2012

into account the time that a node must wait until it meets another node again (i.e., inter-contact time), the duration of these contacts (i.e., contact duration), and the quality of the contact in terms of the set of information that can be transferred (i.e., contact volume). Independently of the type of connectivity, a contact in a DTN is direction-specific. For example, a dial-up connection originating at a customer's home to an Internet Service Provider (ISP) may be scheduled from the point of view of the customer but unscheduled from the point of view of the ISP. In what concerns contacts, dLife assumes direction-specific opportunistic contacts (starting time, end time, contact duration) which occur with some probability in predefined daily time periods. Another concept that must be introduced is that of network behavior. As networks can be formed on-the-fly, their behavior can either be

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
deterministic or stochastic, depending on the type of used links. In this draft, we focus on dynamic scenarios where the behavior of the network is described in stochastic terms, based on users' mobility and social behavior. In a dynamic scenario, users move around carrying their personal devices, which opportunistically come into contact with each other, resulting in topology changes. 1.3. Differentiation to other Opportunistic Routing Proposal Due to intermittent connectivity, routing protocols based on the knowledge of end-to-end paths perform poorly, and numerous opportunistic routing algorithms have been proposed instead. Some opportunistic routing protocols use replicas of the same message to combat the inherent uncertainty of future communication opportunities between nodes. In order to carefully use the available resources and reach short delays, many protocols perform forwarding decisions using locally collected knowledge about node behavior to predict which nodes are likely to deliver a content or bring it closer to the destination. We previously identified [Moreira11] that most of the opportunistic routing prior-art considered the replication-based forwarding scheme, while only 15% were based on single-copy and flooding-based forwarding schemes. Among the replication based solutions, approximately 69% consider a contact-based approach (e.g., frequency of encounters) and 31% (the latest ones) investigate a new trend based on social similarity metrics (e.g., community detection). Contact-based proposals consider every contact among nodes to update the proximity graph and implement metrics such as the number of times nodes meet, contact frequency and the last time a contact occurs. Besides PROPHET [Lindgren04], the most cited replication-based

Page 8 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 9] July 7, 2012

proposal, other examples based on contact metric are Prediction [Song07], and Encounter -Based Routing [Nelson09]. Most of the existing opportunistic routing solutions are based on some level of replication. Among these proposals, emerge solutions based on different representations of social similarity: i) labeling users according to their social groups (e.g., Label [Hui07]); ii) looking at the importance (i.e., popularity) of nodes (e.g., PeopleRank [Mtibaa10]); iii) combining the notion of community and centrality (e.g., SimBet [Daly07] and Bubble Rap [Hui11]); iv) considering interests that users have in common (e.g., SocialCast [Costa08]). Such prior-art shows that social-based solutions are more stable than those which only consider node mobility. However, they do not consider the dynamism of users' behavior (i.e., social daily routines) and use centrality metrics, which may create bottlenecks in the network. Moreover, such approaches assume that communities remain static after creation, which is not a realistic assumption. On the other hand, prior-art also shows that users have routines that can be used to derive future behavior. It has been proven that mapping real social interactions to a clean (i.e., more stable) connectivity representation is rather useful to improve delivery. With dLife, users' daily routines are considered to quantify the time-evolving strength of social interactions and so to foresee more accurately future social contacts than with proximity graphs inferred directly from inter-contact times. 1.4. Requirements notation

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Node Architecture In this section we describe the architecture of a dLife node, which performs its routing decisions based on two utility functions: TECD to forward messages to nodes that have a stronger social relationship with the destination than the carrier; TECDi to forward messages to nodes that have a higher importance than the carrier. With TECD each node computes the average of its contact duration with other nodes during the same set of daily time periods over consecutive days. Our assumptions is that contact duration can provide more reliable information than contact history, or frequency when it comes to identifying the strength of social relationships. The reason for considering different daily time periods relates to the fact that users present different behavior during their daily

Page 9 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 10] July 7, 2012

routines. If the carrier and encountered node have no social information towards the destination, forwarding takes place based on a second utility function, TECDi. We start this section by describing the different components of the node architecture, followed by an explanation of how to route information based on the dynamics of the network that dLife is able to capture by computing TECD/TECDi. Finally, we describe the implemented forwarding strategy and the needed interfaces. 2.1. dLife Components In order to perform forwarding based on the social daily behavior of users, dLife comprises the following main computational elements: Social Information Gatherer (SIG) - responsible for: i) keeping track of the contact duration of each encounter between nodes; and, ii) obtaining the social weights and importance of encountered nodes (i.e., potential next forwarders). As dLife considers different daily samples, corresponding to different periods of time, it is imperative to keep track of nodes' contacts in each sample. Thus, the contact duration tracker maintains a list of the encountered nodes in every daily sample. Additionally, upon the need to replicate a bundle, SIG will obtain the social weight between the encountered node and nodes it has met as well as the importance of such node. Social Weighter (SW) - responsible for determining the social weight between nodes according to their social interaction throughout their daily routines. At the end of every daily sample, SW will interact with SIG to determine the total contact time nodes spent together and the average duration of contacts in order to compute the social weight between nodes. Importance Assigner (IA) - responsible for computing the importance of a node taking into account the importance of encountered nodes and its social weight to such nodes. At the end of every daily sample, IA will interact with SW and SIG in order to compute the importance of a node in the system.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
Social Information Repository (SIR) - responsible for storing a list with encountered nodes and contact duration to such nodes. At the end of every daily sample, SIR will also store social weights and importance of the encountered nodes computed by SW and IA. Additionally, SIR will temporarily store the social weight and importance of an encountered node when the need for replicating a bundle arises.

Page 10 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 11] July 7, 2012

Decision Maker (DM) - responsible for deciding whether replication should occur. DM will interact with SIR to obtain relevant information in order to take decisions. 2.2. Routing Algorithm The dLife protocol applies the social opportunistic contact paradigm to decider whether bundle replication is feasible. Its decision is based on social weight (w_(x,y)) towards the bundle's destination or on the importance (I(x)) of the encountered node (i.e., potential next forwarder) in the system. If the encountered node has better relationship with the bundle destination than the carrier in a given daily sample, it receives a bundle copy, since there is a much greater chance that the encountered node will meet the destination in the future. If relationship to the bundle destination is unknown, replication happens only if the encountered node has higher importance than the carrier. In order to compute the social weight between nodes and their importance, dLife uses parameters that are determined as nodes interact in the system. A brief explanation of the parameters is given below. CD_(x,y) Refers to the contact duration between nodes, i.e., time nodes spent in the range of one another, which would allow them to exchange information. Within a given daily sample, there could happen different contacts with varied lengths. TCT_(x,y) Refers to the total contact time between nodes within a given daily sample. It is given by the sum of all CD_(x,y) in that specific daily sample. AD_(x,y) Refers to the average duration of contacts for the same daily sample over different days. It is a Cumulative Moving Average (CMA) of the average duration, considering the TCT_(x,y) of the current daily sample and average duration in the same daily sample of the previous day, AD_(x,y)_old. w_(x,y) Refers to the social weight between nodes at a given daily sample. It reflects the level of social interaction among such nodes throughout their daily routines.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
Moreira, et al. Internet-Draft I_(x)
00 0C

Page 11 of 36

Expires January 8, 2013 dLife

[Page 12] July 7, 2012

Refers to the importance of a node in the system. The importance is influenced by how well a node is socially related to other important nodes. Refers to the neighbor set of a node x, which it encountered in the current daily sample.

N_(x)

dumping factor (d) Refers the level of randomness considered by the forwarding algorithm. daily sample (Ti) Refers to the time period in which the contact duration will be measured to determine social weight and node importance. As nodes interact, their CD_(x,y) is collected and then used to determine TCT_(x,y), AD_(x,y), w_(x,y), and I_(x) at the end of every daily sample. The more samples, the more refined the social weight and node importance will be. Thus, it is recommended the usage of twenty-four (24) daily samples representing each hour of the day. 2.2.1. Time-Evolving Contact Duration (TECD) The TECD utility function considers the duration of contacts (representing the intensity of social ties among users) and timeevolving interactions (reflecting users' habits over different daily samples). Regarding the notations used in the equations presented in this subsection: sumk(...) denotes summation for k from 1 to n; sumj(...) denotes summation for j from i to i+t-1; sumy denotes summation from all y belonging to N(x). Two nodes may have a social weight, w_(x,y), that depends on the average total contact duration they have in that same period of time over different days. Within a specific daily sample Ti, node x has n contacts with node y, having each contact k a certain contact duration, CD_(x,y). At the end of each daily sample, the total contact time, TCT_(x,y), between nodes x and y is given by the equation below where n is the total number of contacts between the two nodes. TCT_(x,y) = sumk(CD_(x,y)) The Total Contact Time between users in the same daily sample over consecutive days can be used to estimate the average duration of (1)

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 13] July 7, 2012

their contacts for that specific daily sample: the average duration of contacts between users x and y during a daily sample Ti in a day j, denoted by AD_(x,y) is given by a cumulative moving average of their TCT in that same daily sample, TCT_(x,y), and the average duration of their contacts during the same daily sample Ti on the

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
previous day, denoted by AD_(x,y)_old, as shown in the equation below. AD_(x,y) = (TCT_(x,y) + (j-1)*AD(x,y)_old)/j (2)

Page 12 of 36

The social strength between users in a specific daily sample Ti may also provide some insight about their social strength in consecutive k samples in the same day, i+k. This is what we call Time Transitive Property. This property increases the probability of nodes being capable of transmitting large data chunks, since transmission can be resumed in the next daily sample with high probability. TECD is able to capture the social strength w_(x,y) between any pair of users x and y in a daily sample Ti based on the average duration AD_(x,y) of contacts between them in such daily sample and in consecutive t-1 samples, where t represents the total number of daily samples. When k>t, the corresponding AD_(x,y) value refers to the daily sample k-t. In the equation below the time transitive property is given by the weight t/(t+k-i), where the highest weight is associated to the average contact duration in the current daily sample, being it reduced in consecutive samples. TECD = w_(x,y) = sumj(t/(t+k-i)*AD_(x,y)) 2.2.2. TECD Importance (TECDi) As social interaction may also be modeled to consider the node importance, TECDi computes the importance, I_(x), of a node x (cf. equation below), considering the weights of the edges between x and all the nodes y in its neighbor set, N_(x), at a specific daily sample Ti along with their importance. TECDi = I_(x) = (1-d)+d*sumy(w_(x,y) * I_(y) / N_(x)) (4) (3)

TECDi is based on the PeopleRank function. However, TECDi considers not only node importance, but also the strength of social ties between bundle holder and potential next hops. Another difference is that with TECDi the neighbor set of a node x only includes the nodes which have been in contact with node x within a specific daily sample Ti, whereas in PeopleRank the neighbor set of a node includes all the nodes that ever had a link to node x. Note that the dumping factor (d) in the formula is the same used in PeopleRank and represents the level of randomness considered by the forwarding algorithm.

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 14] July 7, 2012

2.3. Forwarding strategy Independently of application scenario, each node MUST employ a forwarding strategy. However, if the encountered node is the final destination of a bundle, the carrier SHOULD prioritize such bundles by employing the prioritized forwarding strategy, described below. We use the following notation in our descriptions below. Nodes A and B are the nodes that encounter each other, and the strategies are described as they would be applied by node A. 2.3.1. Basic Strategy Forward the bundle only if w_(B,D) > w_(A,D) or I_(B) > I_(A) When two nodes A and B meet in any daily sample Ti, node A gets from

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
node B the latest list of all neighbors of B, with the weights that B has towards each neighbor, as well as the importance of B. To avoid unwanted replication, node B also sends a list of the bundles it already carries (bundle identifier, plus EID of the destination) in addition to a second list of the BUNDLE_DELIVERED set of the latest delivered bundles, where BUNDLE_DELIVERED is a threshold configured accordingly with the node storage capacity. The information about the social weight, importance, bundle list, and acknowledged bundles, received from node B are referenced in node A as w_(B,x)_recv, I_(B)_recv, bundleList(IDn, destinationEIDx)_recv, and ackedBundleList(IDn, destinationEIDx)_recv, respectively. For every bundle that A carries in its buffer, and are neither carried by B nor previously acknowledged by B, node A sends a copy to B if B has already encountered the bundle's destination D and its weight in w_(B,D)_recv is greater than A's weight towards this same destination D. Otherwise, bundles are replicated if I_(B)_recv is greater than A's importance in the current daily sample Ti. Finally, node A will update its own ackedBundleList and discard bundles which have already been acknowledged as described in Section 3.3.3. 2.3.2. Prioritized Strategy Similar to the basic forwarding strategy, being the only difference the fact that prior to sending bundles, node A will first send those bundles that have node B has destination. 2.4. Interfaces This section provides a specification of the two major interfaces

Page 13 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 15] July 7, 2012

required for dLife operation: the interface between the dLife routing agent and the bundle agent, and the interface between dLife and the lower layers. 2.4.1. Bundle Agent The bundle protocol [RFC5050] introduces the concept of a "bundle agent" that manages the interface between applications and the "convergence layers" that provide the transport of bundles between nodes during communication opportunities. This draft extends the bundle agent with a routing agent that controls the actions of the bundle agent during an (opportunistic) communications opportunity. This section defines the interface to be implemented between the bundle agent and the dLife routing agent. The defined interface follows the general definition that was defined for the PRoPHET proposal. In this document we assume that functions in a complete bundle agent supporting dLife are distributed in such a way that reception and delivery of bundles are not carried out directly by the dLife module, being the bundles placed in a queue available and manage by the dLife agent. In this case this interface allows the dLife routing agent to be aware of the bundles placed at the node, and allows it to inform the bundle agent about the bundles to be sent to a neighbor node. Therefore, the bundle agent needs to provide the following interface/functionality to the routing agent:

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
Get Bundle List Returns a list of the stored bundles and their attributes to the routing agent. Send Bundle Makes the bundle agent send a specified bundle. Drop Bundle Advice Advises the bundle agent that a specified bundle may be dropped by the bundle agent if appropriate. 2.4.2 Lower Layers To accommodate dLife operation on different types of wireless technology, the lower layers SHOULD provide the following functionality and interfaces. Neighbor discovery and maintenance A dLife node needs to: i) know the identity of its neighbors; ii) when new neighbors appear; iii) when old neighbors disappear. Some wireless networking technologies might already contain mechanisms for detecting neighbors and maintaining state

Page 14 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 16] July 7, 2012

about them. Hence, neighbor discovery is not included as a part of dLife. The lower layers MUST provide the two functions listed below. New Neighbor Signals the dLife agent that a new node has become a neighbor (a node that is currently within communication range of the current node, based on the used wireless networking technology). At this point dLife should start the Neighbor Sensing procedure as mentioned in section 3.1. Neighbor Gone Signals the dLife agent that one of its neighbors has left. Local Address An address used by the underlying communication layer (e.g., an IP or MAC address) that identifies the address of the sender of the current bundle. This address and its format is dependent on the communication layer that is being used by the dLife layer. If the underlying networking technology does not support neighbor discovery and maintenance services, a simple neighbor discovery scheme using local broadcasts of beacon messages COULD be used, assuming that the underlying layer supports broadcast messages. The operation of the protocol is as follows: 1. Periodically a dLife node does a local broadcast of a beacon that contains its identity and address. 2. Upon reception of a beacon, the following can happen: o The sending node is already in the list of active neighbors. Update its entry in the list with the current time. At this point dLife should start the Neighbor Sensing procedure as mentioned in section 3.1. o The sending node is not in the list of active neighbors. Add the node to the list of active neighbors and record

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
the current time.

Page 15 of 36

3. If a beacon has not been received from a node in the list of active neighbors within a predefined time period, it should be assumed that this node is no longer a neighbor. The entry for this node should be removed from the list of active neighbors. 3. Protocol Overview

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 17] July 7, 2012

This section provides a description of the three operational phases of dLife, namely: neighbor sensing, information exchange, and bundle reception policies 3.1. Neighbor Sensing Phase The operation of dLife depends on how nodes interact, i.e., considering all the potential contact opportunities to exchange information. Thus, all nodes running dLife MUST employ a mechanism for neighbor discovery (cf. section 2.4.2) and neighbor sensing. If the underlying networking technology does not support neighbor discovery and maintenance services, a simple neighbor discovery scheme using local broadcasts of beacon messages CAN be activated during the Neighbor Sensing phase, assuming that the underlying layer supports broadcast messages. When a node (new or already met) is discovered, dLife performs the following operation: Start Contact Duration Counting dLife starts counting the contact duration for the purpose of later computing social weights and importance. Hello Procedure dLife sets up a link with the neighbor node through the Hello message exchange as described in Section 5.3. The Hello message exchange allows nodes to exchange information about their End Point Identifier (EID) and storage capacity. Once the link has been set up the protocol may continue to the Information Exchange Phase (cf. Section 3.2), where Hello SYN messages should be sent periodically to allow peering nodes to detect broken links. Stop Contact Duration Counting dLife stops counting the contact duration after detecting that the neighbor is gone, due to the lack of periodic Hello SYN messages. In order to make use of this time dependence, dLife maintains a list of recently encountered nodes identified by the Endpoint Identifier (EID), as described in section 5.2. Each entry of such list includes information that the node uses to update the status of the current communication session and to gather information about previous contacts. The size of this list is controlled, because due to low storage capacity of nodes, the information related to neighbors that are not in contact and towards which the current node has a social weight lower than a predefined threshold SOCIAL_DROP can be dropped

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 16 of 36

Moreira, et al. Internet-Draft from the list.

00 0C

Expires January 8, 2013 dLife

[Page 18] July 7, 2012

3.2. Information Exchange Phase The Information Exchange phase comprises the transfer of sets of two type of information between the connected nodes: o Social message o Social Acknowledgment message Each node running dLife is responsible for computing and updating their social weights towards previously encountered nodes as well as their own importance. Thus, in this phase, the Social message is expected to reflect the latest updates regarding both Social Weight Lists and Node Importance (SWLNI) information as well as include the lists of carried bundles (bundleList) by the peering node and of the latest delivered bundles (ackedBundleList). Upon a communication opportunity, one set of data must be sent in each direction as explained further in this section. Each set may be transferred in one or more messages. In case a set needs more than one message to be completely transferred, it may be partitioned by the higher layer above the dLife protocol engine. The specification of dLife provides a sub-message mechanism and retransmission that allows large messages specified by the higher level to be transmitted in smaller chunks. The first step in the Information Exchange Phase is for dLife to send one or more Social messages containing the SWLNI, bundleList and ackedBundleList information. This set of messages contains: i) a list with the Endpoint Identifiers (EIDs) of the nodes that the neighbor nodes have encountered so far and their respective weights towards these nodes; ii) the importance of the peering nodes; iii) a list with the identifiers of the carried bundles and respective destinations EIDs; and iv) a list with the BUNDLE_DELIVERED latest acknowledged bundles identifiers and respective destinations EIDs. Upon reception and acknowledgment of the complete set of these messages, nodes apply any of the forwarding strategies (see Section 2.3) to decide which of the stored bundles (cf. Get Bundle List on section 2.4.1) will be transferred to the peer. The bundles are built based on the exchanged SWLNI, bundleList and ackedBundleList information and the available storage capacity on the receiving peering node. The bundles to be send to the Bundle Agent (cf. Send Bundle on section 2.4.1) shall not exceed the peering node capacity if it were specified. The information to be passed to the Bundle Agent includes the number of bundles to be send, where each bundle has an ID to be used for acknowledging their receipt.

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 19] July 7, 2012

As the receiving node may have constraints regarding storage capacity, during the Hello phase neighbor nodes MUST inform the current node about their storage availability.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
3.2.1. Operation in the presence of multiples neighbors As a node may find itself in the range of more than one potential next forwarder, the neighbor sensing mechanism may establish multiple information exchanges with each of them. If these simultaneous contacts persist for some time, then the information exchange process will be periodically rerun for each contact according to the configured timer interval, which means that different Hello TLVs will be exchanged at different times. Based on the receipt time of these Hello TLVs at the sending node, it will establish the order for sending out the bundles, considering the storage capacity of the different neighbors. 3.3. Bundle Reception Policies 3.3.1. Queueing policy Because of limited buffer resources, bundles may need to be dropped at some nodes. Although dLife evaluation based on simulations have shown little consumption due to limiting replication based on social strength, a scheme MUST be used upon an exhaustion of buffer space. Hence, each node MUST operate a queueing policy that determines which bundles should be available for forwarding. This section defines a few basic queueing policies, inline with what was proposed for PRoPHET. However, nodes MAY use other policies if desired. If not chosen differently due to the characteristics of the deployment scenario, nodes SHOULD choose FIFO as the default queueing policy. FIFO Handle the queue in a First In First Out (FIFO) order. The bundle that was first entered into the queue is the first bundle to be dropped. The bundle that has been forwarded the largest number of times is the first to be dropped. For this effect, dLife keeps track of the number of times each bundle has been forwarded to other nodes.

Page 17 of 36

FLNT

STTL

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 20] July 7, 2012

The bundle that has shortest time-to-live is dropped first. As described in [RFC5050], each bundle has a timeout value specifying when it no longer is meaningful to its application and should be deleted. Since bundles with short remaining time to live will soon be dropped anyway, this policy decides to drop the bundle with the shortest remaining life time first. To successfully use a policy like this, there needs to be some form of time synchronization between nodes so that it is possible to know the exact lifetimes of bundles. DLSW The bundle that has a destination with low social weight is dropped first. A low social weight means that the carrier may not be the best forwarder to this bundle. However, such bundle can only be dropped if it was already forwarded for at least a

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
Minimum Bundle Forward (MBF) times, which is a minimum number of forwards that a bundle must have been forwarded before being dropped (if such a bundle exists). More than one queueing policy MAY be combined in an ordered set, where the first policy is used primarily, the second only being used if there is a need to tie-break between bundles given the same eviction priority by the primary policy, and so on. It is worth noting that obviously nodes MUST NOT drop bundles for which it has custody unless the lifetime expires. 3.3.2. Custody Policy The concept of custody transfer can be found in [RFC4838]. In general terms, the transmission of bundles with the Custody Transfer Requested option involves moving bundles "closer" (in terms of some routing metric) to their ultimate destination(s) with reliability. The nodes receiving these bundles along the way (and agreeing to accept the reliable delivery responsibility) are called "custodians". The movement of a bundle (and its delivery responsibility) from one node to another is called a "custody transfer". The reliability requirement that a custodian accepts can be instantiated in different ways: i) deleting the bundle after getting a confirmation of a successful custody transfer, which may require retransmissions over a reliable transport protocol, such as TCP. In this case a bundle has normally one custodian in a moment in time; ii) deleting the bundle only after getting an acknowledgment that the bundle was delivered to the destination. In this case a bundle can have more than one custodian, being the bundle replicated among custodians over a non-reliable transport protocol, such as UDP. dLife takes no responsibilities for making custody decisions. Such

Page 18 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 21] July 7, 2012

decisions should be made by a higher layer. However, dLife insures that custodian nodes do not drop bundles for which it has custody unless the lifetime expires, or an acknowledge message is received for that bundle. 3.3.3. Destination Policy When a bundle reaches its destination, a Bundle ACK for that bundle is issued. A Bundle ACK is a confirmation that a bundle has been delivered to its destination, being that information stored in the local bundle queue manageable by the routing agent. When nodes exchange Social message TLVs, bundles that have been ACKed are also listed. The node that receives this list updates its own list of ACKed bundles to be the union of its previous list and the received list. To prevent the list of ACKed bundles growing indefinitely, each Bundle ACK should have a timeout that MUST NOT be longer than the timeout of the bundle to which the ACK corresponds. When a node receives a Bundle ACK for a bundle it is carrying, it MUST delete that bundle from its queue, since the Bundle ACK indicates that a bundle has been delivered to its destination. Nodes MAY keep track of which nodes they have sent Bundle ACKs for certain bundles to, and MAY in that case refrain from sending multiple Bundle ACKs for the same bundle to the same node. 4. Message Formats

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
This section defines the message formats of the dLife routing protocol. In order to allow for variable length fields, many numeric fields are encoded as Self-Delimiting Numeric Values (SDNVs), defined in [RFC5050], as in PRoPHET. Since many of the fields are coded as SDNVs the size and alignment of fields indicated in many of the specification diagrams below are indicative rather than prescriptive. The basic message format shown in Figure 1 consists of a header (see Section 4.1) followed by a sequence of one or more Type-Length-Value components (TLVs) taken from the specifications in Section 4.2.

Page 19 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 22] July 7, 2012

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Header ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV 1 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | ~ . ~ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV n ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Basic message format 4.1. Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prot_Number | Version | Flags | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender | Receiver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| SubMessage Number | Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Body ~

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: dLife Message Header Prot_Number (Protocol Number) The DTN Routing Protocol Number encoded as 8 bit unsigned integer in network bit order. The value of this field is 0. The dLife header is organized in this way so that in principle dLife messages could be sent as the Protocol Data Unit of an IP packet if an IP protocol number was allocated for dLife. At present

Page 20 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 23] July 7, 2012

dLife is only specified to use UDP transport for dLife packets so that the protocol number serves only to identify the dLife protocol within DTN. Transmitting dLife packets directly as an IP protocol on a public IP network such as the Internet would generally not work well because middle boxes such as firewalls and NAT boxes would be unlikely to allow the protocol to pass through and the protocol does not provide any congestion control. However, it could be so used on opportunistic wireless networks, which is the goal of dLife. Version The Version of the dLife Protocol. Encoded as a four bit unsigned integer in network bit order. This document defines version 1. Flags Reserved field of 4 bits.

Res (Result) Since the exchange of dLife messages does not rely on the a reliable link (e.g., based on TCP), as a default behavior, the controller will acknowledge responses. Hence, dLife messages implement the result field that in a response message can have two values: "Success," and "Failure". The former indicates a success response that may be contained in a single message or the final message of a success response spanning multiple messages. The result field is encoded as a 4 bit unsigned integer in network bit order. The following values are currently defined: o Success: Result = 1 o Failure: Result = 2 o Code This field gives further information concerning the result in a response message. It is mostly used to pass an error code in a failure response, but can also be used to give further information in a success response message. In a request message, the code field is not used and is set to zero. If the Code field indicates that the ACK TLV is included in the message, further information on the successful or failure of the message will be found in the ACK TLV, which MUST be the first TLV after the header. The Code field is encoded as an 8 bit unsigned integer in network bit order. The following values are defined:

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 21 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 24] July 7, 2012

o Generic Response 0x00 o Submessage Received 0x01 o ACK TLV in message 0x02 The "generic response" and the "submessage receiver" values tell us that the success or failure indicated in the Result field is related to the all message or a submessage, respectively. Sender This field identifies the sender EID of the dLife message. It is used to detect when the link comes back up after going down or when the identity of the entity at the other end of the link changes. This number is guaranteed to be unique within the recent past. Messages sent after the Hello phase should use the sender's number. The Sender Instance is encoded as a 16 bit unsigned integer in network bit order. Receiver This field identifies the receiver EID of the dLife message. If the sender of the message does not know the current number of the receiver, this field MUST be set to zero. Messages sent after the Hello phase should use the receiver's number. The receiver number is encoded as a 16 bit unsigned integer in network bit order. Message Identifier Used to associate a message with its response message. This should be set in request messages to a value that is unique for the sending host within the recent past. Response messages contain the Message Identifier of the request they are responding to. The Message Identifier is a 32 bit pattern. S-flag If S is set (value 1) then the SubMessage Number field indicates the total number of SubMessage segments that compose the entire message. If it is not set (value 0) then the SubMessage Number field indicates the sequence number of this SubMessage segment within the whole message. The S field will only be set in the first sub-message of a sequence. SubMessage Number When a message is segmented because it exceeds the MTU of the link layer or otherwise, each segment will include a SubMessage Number to indicate its position. Alternatively, if it is the first sub-message in a sequence of sub-messages, the S flag will be set and this field will contain the total count of SubMessage segments. The SubMessage Number is encoded as a 15-bit unsigned integer in network bit order. The SubMessage number is

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 25] July 7, 2012

zerobased, i.e., for a message divided into n sub-messages, they are numbered from 0 to (n - 1). For a message that it is not divided into sub-messages the single message has the S-flag

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
cleared (0) and the SubMessage Number is set to 0 (zero). Length Length in octets of this message including headers and message body. If the message is fragmented, this field contains the length of this SubMessage. The Length is encoded as an SDNV. Message Body The Message Body consists of a sequence of one or more of the TLVs specified in Section 4.2. The protocol requires information about the link that the underlying communication layer MUST provide. This information is used in the Hello procedure. Since this information is available from the underlying layer, there is no need to carry it in dLife messages. The following values are defined to be provided by the underlying layer: Sender Local Address An address used by the underlying communication layer that identifies the sender address of the current message. This address must be unique among the nodes that can currently communicate. Receiver Local Address An address used by the underlying communication layer that identifies the receiver address of the current message. This address must be unique among the nodes that can currently communicate. 4.2. TLV Structure All TLVs have the following format, and can be nested. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Flags | TLV Length (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Page 22 of 36

Moreira, et al. Internet-Draft Figure 3: TLV Format Type

00 0C

Expires January 8, 2013 dLife

[Page 26] July 7, 2012

Specific TLVs are defined in Section 4.3. The TLV Type is encoded as an 8 bit unsigned integer in network bit order.

TLV Flags These are defined per TLV type. Any flags which are specified as reserved in specific TLVs SHOULD be transmitted as 0 and ignored on receipt. TLV Length Length of the TLV in octets, including the TLV header and any nested TLVs. Encoded as an SDNV.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
4.3. TLVs This section describes the various TLVs that can be used in dLife messages. 4.3.1. Hello TLV The Hello TLV is used to set up and maintain a link between two dLife nodes. Hello messages are the first TLVs exchanged between nodes when they are within range of communication and are used to inform neighbors about the EID and storage capacity of the node. The Hello sequence must be completed so other TLVs can be exchanged. Then, dLife nodes will store the information about each other capacities and acknowledge such action which signals that the communication has been established. If during the Hello procedure ACK is failed to be received, disconnection occurred and link should be assumed broken. Once a communication link is established between two dLife nodes, the Hello TLV will be sent once for each interval with the SYN function as defined in the interval timer. If a node experiences the lapse of Hello intervals without receiving a Hello TLV on a connection in the EXCHANGE state (cf. Section 5), the connection SHOULD be assumed broken.

Page 23 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 27] July 7, 2012

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV type=0xA0 |Flags| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID Length (SDNV) | Sender EID | Timer | Storage | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Hello TLV Format TLV Flags The TLV Flags field contains a three bit Hello Function (HF) number that specifies one of four functions for the Hello TLV. The encoding of the Hello Function is: o HEL: HF = 1 o SYN: HF = 2 o ACK: HF = 3 The HEL function is used by a node to send information needed for the dLife operation, namely the storage capacity of the node. The SYN function is used to inform both devices that the communication link is still up. The ACK function in used by a node to acknowledge the reception of an HEL Hello TLV.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
TLV Data EID Length The EID Length field is used to specify the length of the Sender EID field in octets. If the Endpoint Identifier (EID) has already been sent at least once in a message with the current Sender Instance, a node MAY choose to set this field to zero, omitting the Sender EID from the Hello TLV. The EID Length is encoded as an SDNV and the field is thus of variable length. Sender EID The Sender EID field specifies the DTN endpoint identifier (EID) of the sender that is to be used in updating routing information and making forwarding decisions. If a node has multiple EIDs, one should be chosen for dLife routing. This field is of variable length. Timer The Timer field is used to inform the receiver of the timer value used in the Hello processing of the sender. The timer specifies the nominal time between periodic Hello messages.

Page 24 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 28] July 7, 2012

It is a constant for the duration of a session. The timer field is specified in units of 100ms and is encoded as an SDNV. Storage This field indicated what is the node's storage capacity. Used to inform the potential senders of the node's limitations in terms of successful reception of bundles. This field is encoded as an SDNV. 4.3.2. ACK TLV This ACK TLV can be used by itself or nested in Hello TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV type=0xA0 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACK Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: ACK TLV Format TLV Flags The TLV Flags field carries an identifier for the ACK TLV type as an 8 bit unsigned integer encoded in network bit order. A range of values is available for private and experimental use in addition to the values defined here. The following ACK TLV types are defined: o Hello ACK 0x00 o Social Acknowledgement message 0x01 o Bundle ACK 0x02 o Reserved 0x03 - 0x7F o Private/Experimental Use 0x80 - 0xFF

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
TLV Data The contents and interpretation of the TLV Data field are specific to the type of ACK TLV. The TLV Data is defined as follows: Hello ACK Used when a node wants to break the connection due to the fact that the neighbor has a storage capacity lower that its threshold to send bundles. Social Acknowledgement message

Page 25 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 29] July 7, 2012

Report on the reception of Social messages (SWLNI, bundleList and ackedBundleList). Bundle ACK Provide positive or negative feedback regarding the receipt of bundles (e.g., reporting the identifier of the last bundle successfully received) as indicated on the Social TLVs. 4.3.3. Social TLV This TLV provides the SWLNI, bundleList and ackedBundleList information, i.e., a list of the nodes that the neighbor node has encountered up to that moment along with its social weight towards them, the importance of the neighbor node, as well as the lists containing bundles being carried by the peering nodes and acknowledgements for already delivered bundles (limited to the latest BUNDLE_DELIVERED number of bundles). This TLV allows dLife nodes to build the social bundles according to the forwarding strategies explained in Section 2.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV type=0xA0 | Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Importance Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SWLNI Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID n | SWL value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Carried Bundle Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Carried Bundle ID n | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acked Bundle Count (SDNV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acked Bundle ID n | Destination EID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Social message TLV Format TLV Flags The encoding of the Header flag field relates to the capabilities of the Source node sending the Social message.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 26 of 36

Moreira, et al. Internet-Draft Flag Flag Flag Flag Flag Flag Flag Flag 0: 1: 2: 3: 4: 5: 6: 7:
00 0C

Expires January 8, 2013 dLife More Social TLVs Reserved Reserved Reserved Reserved Reserved Reserved Reserved

[Page 30] July 7, 2012

The "More Social TLVs" flag is set to 1 if the Social message requires more TLVs to be sent in order to be fully transferred. This flag is set to 0 if this is the final TLV. TLV Data Importance Importance of the node sending the Social message SWLNI Count Number of entries regarding the SWLNI information in the TLV. Encoded as SDNV EID n String ID of the endpoint identifier of the destination for which this entry specifies the delivery predictability as predefined in a dictionary TLV. Encoded as SDNV. SWL value Social weight between peering node and that specific encountered node Carried Bundle Count Number of entries regarding the carried bundle information in the TLV. Encoded as SDNV Carried Bundle ID Identifiers of the bundles that the sender is currently carrying. Acked Bundle Count Number of entries regarding the acknowledged bundle information in the TLV. Encoded as SDNV Acked Bundle ID Identifiers of the bundles that the sender has received acknowledgements for. Destination EID

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 31] July 7, 2012

EID of the destination for a carried or acknowledged bundle.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
5. Detailed Operation This section provides more details on the operation of dLife, including state tables to help in implementing the protocol. As explained before dLife aims to release any assumption about the reliability of the transport protocol, and so positive acknowledgements would be necessary to signal successful delivery of (sub)messages. In this section the phrase "send a message" should be read as *successful* sending of a message, signaled by receipt of the appropriate "Success" response. Hence the state descriptions below do not explicitly mention positive acknowledgements, whether they are being sent or not. 5.1. High Level State Tables This section provides the high level state tables for the operation of dLife. The next section provides a more detailed view of each part of the protocol's operation. The following states are used in the state tables: SENSING This is the state all nodes start in. Nodes remain in this state until a new contact opportunity arises. Once a node has sensed the presence of a peer, it will start counting the duration of this contact and will trigger the Hello procedure by switching to the HELLO state. Since multiple contacts may happen, the node should also remain in the SENSING state in order to detect new contact opportunities. This could be handled by creating a new thread or process during the transition to the HELLO state that then takes care of the communication with the new neighbor while the parent remains in state SENSING waiting for additional neighbors to communicate. In this case when the neighbor is no longer available (described as 'disconnected' in the tables below), the thread or process created is destroyed. HELLO Nodes remain in the HELLO state from when a new neighbor is detected until the Hello procedure is completed, which occur after both nodes acknowledge the reception of Hello messages. Upon receiving a Hello message, the node stores the information about the peer capacity. Once the Hello procedure is done, the node starts the information exchange phase and transitions to

Page 27 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 32] July 7, 2012

the EXCHANGE state. If while in the HELLO state the node is notified that the neighbor is no longer in range, it returns to the SENSING state where it stops counting the contact duration and, if appropriate, MAY destroys any additional process or thread created to handle the neighbor. EXCHANGE With the communication link set, nodes enter the EXCHANGE state in which the information exchange is done. The node remains in this state as long as Information Exchange Phase TLVs (Social, Social Acknowledgment) are being received. If the node is notified that the neighbor is no longer in range before all information have been exchanged, the node returns to the SENSING state to await new neighbors and stops counting contact duration

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
for that specific peer. In the EXCHANGE state both nodes are able to update their social weight and node importance information using data from the neighbor peer. With dLife the exchange of information about social weight and node importance MAY be carried out independently but concurrently with the messages multiplexed on a single bidirectional link, or alternatively, the exchanges MAY be carried out partially or wholly sequentially if appropriate for the implementation. The information exchange process is explained in more detail in Section 3.2. When a Social TLV is received with a "More Social TLV" flag set to zero (i.e., no more bundles to send), the node starts the next_exchange timer. When this timer expires, the node reruns the information exchange if the neighbor is still connected. Otherwise, nodes switch to the SENSING state, where they stop counting contact duration and, if appropriate, MAY destroys any additional process or thread created to handle the neighbor. If the neighbor is still connected after the next_exchange timer expires, this new information exchange phase will have the effect of further increasing the probability of selecting this node as a forwarder. If there is more than one neighbor connected or other communication opportunities have happened since the previous information exchange occurred, then the changes resulting from these other encounters will be passed on the connected neighbor. The next_exchange timer is restarted once the information exchange has completed again. If one or more new bundles are received by this node while waiting for the next_exchange timer to expire and the TECD and TECDi metrics indicate that it would be appropriate to forward some or all of the bundles to the connected node, the bundles

Page 28 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 33] July 7, 2012

SHOULD be immediately transferred to the connected neighbor. State: SENSING +===================================================================+ | Condition | Action | New State | +==================+===============================+================+ | New Contact | Start counting duration | | | | Start Hello for new contact | HELLO | | | Keep sensing for new contacts | SENSING | +===================================================================+ State: HELLO +====================================================================+ | Condition | Action | New State | +======================+=================================+===========+ | Hello TLV rcvd | Store peer capacity | HELLO | +----------------------+---------------------------------+-----------+ | Hello procedure done | Start Information Exchange | EXCHANGE | +----------------------+---------------------------------+-----------+ | Disconnected | Stop contact duration count | SENSING | +====================================================================+ State: EXCHANGE +===================================================================+ | Condition | Action | New State |

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
+===================+===================================+===========+ | SWL/NI TLV rcvd | Create and send Social Bundle TLV | EXCHANGE | +-------------------+-----------------------------------+-----------+ | Disconnected | Stop contact duration count | SENSING | +-------------------+-----------------------------------+-----------+ | More Social TLV | | | | flag = 0 | Start next exchange timer | EXCHANGE | +-------------------+-----------------------------------+-----------+ | exchange timer | Check if peer is still connected | EXCHANGE | | expires +-----------------------------------+-----------+ | | Stop contact duration count | SENSING | +-------------------+-----------------------------------+-----------+ | New bundle | | EXCHANGE | +===================================================================+

Page 29 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 34] July 7, 2012

5.2. High Level Meta-Data Table During its operation, dLife makes use of metadata (cf. Figure 7) locally stored as a consequence of the the exchange of Social TLVs, Hello TLVs and local operations. The stored meta-data is used in the computation of social weight towards other nodes and its own importance as well as to identify itself (cf. Section 2.2). Metadata can be persistent or temporary: the former MUST be kept for longer times and the latter is replaced as a new daily sample starts. Persistent metadata includes the node's own EID, storage capacity (StoCap), importance (Imp), Average Duration (AD_peer) of contacts to peers, and social weight to peer (w_peer). Since nodes receive information from neighbors, they must also store the peer's EID (EID_peer), peer's storage capacity (StoCap_peer), the social weight list of that peer towards other nodes (SocList_peer), and the importance of that peer (Imp_peer). Additionally, nodes must keep track of number of times the bundles were forwarded (fwd_times) as to employ the queueing FLNT policy describe in section 3.3.1. The temporary metadata includes contact duration (CD_peer) and total contact time (TCT_peer) for a given peer. This two variables are needed since two nodes can be in contact more than once in the same daily sample, being CD used to count the duration of the active contact, and TCT used to add the time of all contacts in the same daily sample. In the SENSING state, each node must have its own EID and storage capacity ready for exchange in the case of a contact. When a contact is sensed, a node creates an entry for this potential peer (EID_peer) in meta-data table and start counting the duration of this contact (CD_peer). Note that the peer EID will only be known in the HELLO state. If the HELLO state is successfully concluded, the EID_peer is now known and new entries for the encountered peer are created (TCT_peer, AD_peer, w_peer, and StoCap_peer) in the meta-data table. When the EXCHANGE state starts, a node will receive from its peer its SocList_peer and Imp_peer, which must be stored for building the social bundles.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 30 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 35] July 7, 2012

+------------------------+ | EID_own | StoCap | Imp | +------------------------+ | +----------+---------+----------+---------+--------+ | EID_peer | CD_peer | TCT_peer | AD_peer | w_peer | +----------+---------+----------+---------+--------+ | | | | +-----+-----+-----+ +------+------+------+ | | CD1 | ... | CDn | | AD11 | ... | AD1i | | +-----+-----+-----+ +------+------+------+ | +-------------+--------------+----------+-----------+ | StoCap_peer | SocList_peer | Imp_peer | fwd_times | +-------------+--------------+----------+-----------+ Figure 7: Meta-data Information 6. Security Considerations Currently, dLife does not specify any special security measures. However, as a routing protocol for opportunistic networks, dLife may be a target for various attacks. Such attacks may not be problematic if all nodes in the network can be trusted and are working towards a common goal. If there is such a set of nodes, but there are also malicious nodes, consequent security problems can be solved by introducing an authentication mechanism when two nodes meet, for example using a Pretty Good Privacy (PGP) system. Thus, only nodes that are known to be members of the trusted group of nodes are allowed to participate in the dLife routing. This of course introduces the additional problem of key distribution, which is outof-scope of this document. Examples of possible vulnerabilities are: Black Hole Attack A malicious node sets its social weights for all destinations to a very high value. This has two effects, both causing messages to be drawn towards the black hole, instead of to its correct destination: i) depending on queueing policy, this might lead to premature dropping of the bundle; ii) the social weights reported by the malicious node will affect the computation of the node importance. This could place the malicious use as the center of any communication. In this case, a node should raise alert if the social

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 36] July 7, 2012

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
weights and node importance that it receives from a new neighbor is much higher than the cumulative moving average of the information received from all previous nodes. This situation can be handle by implementing a trustworthy authentication mechanism for pervasive computing, allowing a node to get extra confidence that a neighbor will handle social weights and node importance in a trustworthy manner. Identity Spoofing With identity spoofing, a malicious node claims to be someone else. This could be used to "steal" the data that should be going to a particular node. This will cause these bundles to be removed from the network, reducing the chance that they will reach their real destination. This can be prevented by using authentication between pervasive nodes. Bundle Store Overflow After encountering and receiving the social weights and node importance information from the victim, a malicious node may generate a large number of fake bundles to the destination for which the victim has the social weights. This will cause the victim to fill up its bundle storage, possibly at the expense of other, legitimate, bundles. This problem is transient as the messages will be removed when the victim meets the destination and delivers the messages. This attack can be prevented by requiring sending nodes to sign all bundles they originate. This will allow intermediate nodes to verify the integrity of the messages before accepting them. There are some typical vulnerabilities that are not potential problems with dLife such as: Fake ACKS In this typical situation a malicious node may issue fake ACKs for all bundles (or only bundles for a certain destination if the attack is targeted at a single node) carried by nodes it meets. The affected bundles will be deleted from the network, greatly reducing their probability of being delivered to the destination. This situation does not occur with dLife since a node can only send an ACK to bundles that the current carrier decided to forward to it (based on local forwarding policies) and not for bundles that the potential malicious node asked to

Page 31 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 37] July 7, 2012

be forwarded. 7. Implementation Experience The current implementation of dLife is written in Java for the version 1.4.1 of the Opportunistic Network Emulator (ONE), , named Dlife.java, which implements the RoutingDecisionEngine interface to be used with the DecisionEngineRouter class. The implementation contains all the major mechanisms described in this document to ensure proper protocol operation. There are however some parts that

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
are only specified, such as the queuing policies, and other that still need specification, such as the security considerations. The implementation considered nodes with limited storage resources (2 MB) and restricted communication: WiFi and Bluetooth. By running on ONE, the goal of this first implementation wast to enable dLife to be tested in different scalable large pervasive scenarios (some based on real traces such as the one from Cambridge University ) with other protocols: PRoPHET and Bubble Rap. The three key performance indicators that were studied were average message delay, probability of message delivery and protocol cost (number of duplicate messages in the network at the time of delivery). Experience and feedback from the implementers on early versions of the protocol have been incorporated into the current version. A second implementation of dLife is being done in C# using the Monodroid development environment, aiming to construct a modular design, since its inception, for operation over multiple platforms: Windows, Linux, Android and iOS. Among the most important classes being implemented we can mention: Bundle class, which represents the implementation of RFC 5050; BluetoothConvergenceLayer, which allows direct exchange of bundles through the Bluetooth interface without the need of a structured WiFi network; GenericRouting, a class-based routing that can be extended to represent a specific protocol; BundleSecurity, which constitutes the security layer implemented according to RFC 6257 Bundle security Protocol Specification. 8. Deployment Experience Since the beginning of 2012, a DTN test-bed is being created in the Amazon region for testing of DTN routing solutions, in the context of the DTN-Amazon project, having the University Lusofona and University Federal of Para as current partners. The test-bed has currently 10 devices (3 personal computers, 3 smartphones, 4 wireless routers) and will grow until 16 devices (5 wifi tablets, 5 smartphones, 2 personal computers and 4 wireless routers). In a later phase, the DTN package

Page 32 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 38] July 7, 2012

with routing functionality will be made available for download, allowing its deployment in personal devices from local citizens. In terms operating systems, the deployment is being tested with Linux Ubuntu 10.10 Maverick and Android 2.3.6 Gingerbread (kernel version 2.6.35.7) devices, as well as OpenWrt 10.03.1 wireless routers. The test-bed was initially used to test two different DTN implementations: IBR-DTN, organized in a modular form, with a focus on embedded systems for easy portability; DTN2, incorporating all components of the DTN architecture, divided into modules such as Convergence Layers Persistent Store, Bundle Router and more. Communication between the modules is based on IPC mechanism (Inter Process Communication). DTN2 also has some concern with the issue of multi-platform, although its organization is not as modular. The two DTN implementations were tested with two applications that were able to communicate based on two different routing protocols via WiFi interfaces configured in infrastructured mode: i) whisper chat application over PRoPHET (IBR-DTN test-bed); and the DTN-AMAZON Android security application for surveillance of university campus over Epidemic and PRoPHET routing (DTN2).

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
The DTN2 implementation was also used to analyze the behavior of a network environment with mobility, while the mules were carried by a vehicle to enable the exchange of information between two hosts, information that was also accessed by an application on a Smartphone at one of sides. There were also attempts to deliver the message at a speed of 60 km / h, the limit considered by the scientific community so that the communication Wi-Fi still works. Initial tests of the dLife implementation, as described in this document, will be made in a controlled test-bed with 4 Android devices using a text messaging application for operation testing, where each node sent messages alternating destinations. These tests aimed to analyze the performance of the dLife, when compared to behavior of epidemic and PROPHET, based on the following metrics: average message delay, probability of message delivery and the number of duplicate messages in the network at the time of delivery. 9. 9.1 References Normative References [Moreira12a] Moreira, W., Mendes, P., and Sargento, S., "Opportunistic Routing Based on Daily Routines," in Proceedings of the Sixth IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications (AOC 2012), (San Francisco, California, USA), June, 2012.

Page 33 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 39] July 7, 2012

[Moreira12b] Moreira, W., Souza, M., Mendes, P., and Sargento, S., "Study on the Effect of Network Dynamics on Opportunistic Routing" in Proceedings of the Eleventh International Conference on Ad-Hoc Networks and Wireless (AdHoc Now 2012), (Belgrade, Serbia), July, 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, April 2007. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. 9.2 Informative References [Chaintreau06] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott, "Impact of human mobility on the design of opportunistic forwarding algorithms," in Proceedings of INFOCOM, (Barcelona, Spain), April, 2006. [Costa08] P. Costa, C. Mascolo, M. Musolesi, and G. P. Picco, "Socially-aware routing for publish-subscribe in delaytolerant mobile ad hoc networks," Selected Areas in Communications, IEEE Journal on, vol. 26, pp. 748- 760, June, 2008. [Daly07] E. M. Daly and M. Haahr, "Social network analysis for routing in disconnected delay-tolerant manets," in Proceedings of ACM MobiHoc, (Montreal, Canada), September, 2007.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
[Eagle09] N. Eagle and A. Pentland, "Eigenbehaviors: identifying structure in routine," Behavioral Ecology and Sociobiology, vol. 63, pp. 1057-1066, May, 2009. [Hossmann10] T. Hossmann, T. Spyropoulos, and F. Legendre, "Know thy neighbor: Towards optimal mapping of contacts to social graphs for dtn routing," in Proceedings of IEEE INFOCOM, (San Diego, USA), March, 2010. [Hui07] P. Hui and J. Crowcroft, "How small labels create big improvements," in Proceedings of IEEE PERCOM Workshops, (White Plains, USA), March, 2007. [Hui11] P. Hui, J. Crowcroft, and E. Yoneki, "Bubble rap: social-

Page 34 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 40] July 7, 2012

based forward- ing in delay tolerant networks," Mobile Computing, IEEE Transactions on, vol. 10, pp. 1576-1589, November, 2011. [I-D.irtf-dtnrg-tcp-clayer] Demmer, M. and J. Ott, "Delay Tolerant Networking TCP Convergence Layer Protocol", draft-irtfdtnrg-tcp-clayer-02 (work in progress), November 2008. [I-D.irtf-dtnrg-udp-clayer] H. Kruse, S. Ostermann, "UDP Convergence Layers for the DTN Bundle and LTP Protocols", draft-irtfdtnrg-udp-clayer-00 (work in progress), November 2008. [Lindgren04] A. Lindgren, A. Doria, and O. Schelen, "Probabilistic routing in intermittently connected networks," in Service Assurance with Partial and Intermittent Resources, vol. 3126 of Lecture Notes in Computer Science, pp. 239--254, Springer Berlin / Heidelberg, 2004. [Lindgren06] Lindgren, A. and K. Phanse, "Evaluation of Queueing Policies and Forwarding Strategies for Routing in Intermittently Connected Networks", Proceedings of COMSWARE 2006 , January 2006. [Moreira11] W. Moreira and P. Mendes, "Survey on Opportunistic Routing for Delay/Disruption Tolerant Networks ," Tech. Rep. SITI-TR-11-02, SITI, University Lusofona, February 2011. [Moreira_12c] Waldir Moreira, Paulo Mendes, Susana Sargento, "Assessment Model for Opportunistic Routing", IEEE Latin America Transactions, Vol 10 Issue 3 April 2012 [Mtibaa10] A. Mtibaa, M. May, M. Ammar, and C. Diot, "Peoplerank: Combining social and contact information for opportunistic forwarding," in Proceedings of INFOCOM, (San Diego, USA), March, 2010. [Nelson09] S. Nelson, M. Bakht, and R. Kravets, "Encounter-based routing in DTNs," in Proceedings of INFOCOM, (Rio de Janeiro, Brazil), April, 2009. [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, May 2011.

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt
[Song07] L. Song and D. F. Kotz, "Evaluating opportunistic routing protocols with large realistic contact traces," in Proceedings of ACM MobiCom CHANTS, (Montreal, Canada),

Page 35 of 36

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 41] July 7, 2012

September, 2007. [Vahdat00] Vahdat, A. and D. Becker, "Epidemic Routing for Partially Connected Ad Hoc Networks", Duke University Technical Report CS-200006, April 2000..in 3 Authors' Addresses Waldir Moreira SITI, Universidade Lusofona Campo Grande, 376, Ed. U 1749-024 Lisboa Portugal Phone: Email: waldir.junior@ulusofona.pt URI: http://siti2.ulusofona.pt/~wjunior Paulo Mendes SITI, Universidade Lusofona Campo Grande, 376, Ed. U 1749-024 Lisboa Portugal Phone: Email: paulo.mendes@ulusofona.pt URI: http://siti2.ulusofona.pt/~pmendes Ronedo Ferreira ITEC, Universidade Federal do Para Rua Augusto Correa, 01, Guama 66075-110 Belem-PA Brasil Phone: Email: ronedo@aitinet.com URI: Eduardo Cerqueira ITEC, Universidade Federal do Para Rua Augusto Correa, 01, Guama 66075-110 Belem-PA Brasil Phone: Email: cerqueira@ufpa.br URI: http://www.gercom.ufpa.br/eduardo/

Moreira, et al. Internet-Draft

00 0C

Expires January 8, 2013 dLife

[Page 42] July 7, 2012

File: /media/data/personal/work/phdfts/draft-moreira-dlife-00.txt

Page 36 of 36

Moreira, et al.

Expires January 8, 2013

[Page 43]

ANNEX F - Paper entitled Study on the Effect of Network Dynamics on Opportunistic Routing published and presented on the International Conference on Ad-Hoc Networks and Wireless 2012.

Study on the Eect of Network Dynamics on Opportunistic Routing

Waldir Moreira1 , Manuel de Souza1 , Paulo Mendes1 , and Susana Sargento2
1

{waldir.junior,manuel.desouza,paulo.mendes}@ulusofona.pt
2

SITI, University Lusfona

susana@ua.pt

Instituto de Telecomunicaes, University of Aveiro

There has been an eort to employ social similarity inferred from user mobility patterns in opportunistic routing solutions to improve forwarding. However, the dynamics of the networks are still not fully considered when devising solutions based on social similarity metrics. To address this issue, we propose two utility functions which consider the daily life routines of users and the intensity of their social interactions to take forwarding decisions: Time-Evolving Contact Duration (TECD) that weights social interactions among nodes considering the duration of contacts; and TECD Importance (TECDi) which estimates the importance of nodes. We compare our utility functions against contactand social-based solutions, and we show that the use of daily life routines information (i.e., using TECD and TECDi ) has a positive eect on opportunistic routing.
Abstract.

daily routines; network dynamics; contact duration; social structures; opportunistic routing
Keywords:

Introduction

Most of the proposed opportunistic routing solutions are built based on intercontact times [1], despite the increasing need to fully understand the nature of such statistics. In addition, the resulting proximity graphs are rather instable [2] as they need to be created based on the users' mobility, which constantly changes. There is a current trend that employs the use of stable social structures (inferred from user mobility) in order to improve opportunistic routing [3]. These social structures are built based on social similarity metrics such as centrality which identies nodes that can increase the probability of message delivery given their popularity within the system. Such centrality is used to perform message delivery both inside and outside of a cluster/community under the assumption that users meet each other according to the social strength between them. However, the proposals which are based on the identication of social structures (e.g., communities) do not take into account the dynamics of networks, that is, the evolution of the network structure (the making and braking of network ties) since users meet other users in dierent moments during their daily

Study on the Eect of Network Dynamics on Opportunistic Routing

routines. So, the global structure of the users' social network changes as their personal networks change. When considering dynamic social similarity, Hossmann et al. [4] show that it is imperative to correctly map real node interactions (resulting from the mobility process) into a cleaner social representation (i.e., comprising only stable social contacts) to create proximity graphs based on the daily life routine of nodes to aid routing. This encourages us to study the eect that network dynamics have on opportunistic routing. Additionally, Eagle and Pentland [5] show that users have routines that can be used to identify future behavior and interaction with others with whom they share similar behavior and potentially share the same community. These studies suggest that opportunistic routing should mimic social behavior, and the creation of social structures should consider the oscillations of user behavior. To address this challenge, we propose the use of time-evolving social structures to reect the dierent behavior that users have in dierent daily periods of time. This is achieved through two novel utility functions: Time-Evolving Contact Duration (TECD) that weights social interactions based on the statistical contact duration that nodes have in the same daily period of time, over consecutive days; and TECD Importance (TECDi) which estimates the importance of nodes based on its node degree, and the social strength towards its neighbors, in dierent periods of time. To evaluate our approach, we compare opportunistic routing based on our utility functions against benchmark contact- and social-based proposals. Results show that capturing the dynamism of networks based on social daily behavior (by using TECD and TECDi, for instance) can improve routing performance in terms of delivery probability, cost and latency. This paper is structured as follows. Section 2 analyzes the most signicant opportunistic routing trends. In Section 3, the TECD and TECDi utility functions are presented along with an algorithm used to implement them. Section 4 presents the evaluation methodology, setup, and results. In Section 5 we conclude the paper and present directions for future work.

Related Work

We previously identied [3] that most of the opportunistic routing prior-art considered the replication-based forwarding scheme, while only 15% were based on single-copy and ooding-based forwarding schemes. Among the replicationbased solutions, approximately 69% consider a contact-based approach (e.g., frequency of encounters) and 31% (the latest ones) investigate a new trend based on social similarity metrics (e.g., community detection). Contact-based proposals consider every contact among nodes to update the proximity graph and implement metrics such as the number of times nodes meet, contact frequency and the last time a contact occurs. Besides PROPHET [6], the most cited replication-based proposal [3], other examples based on contact metric are Prediction [7], and Encounter -Based Routing [8].

Study on the Eect of Network Dynamics on Opportunistic Routing

Social-based proposals build proximity graphs based mostly on social similarity metrics such as inter-contact times, and therefore they can identify social structures such as communities in Bubble Rap [2], interest shared by nodes as in SocialCast [9], and node popularity (i.e., importance) as in PeopleRank [10]. On one hand, contact-based proposals can achieve acceptable performance, but with the complexity of updating proximity graphs according to node movements [2]. On the other hand, social-based proposals have shown routing improvements based on proximity graphs more stable than those created based on every contact. However, these proposals are complex when subject to form communities prior to routing [2], or are based on strong assumptions about nodes sharing the same interests spending most of the time co-located [9,10]. Independently of being based on contacts or social similarities, none of the analyzed approaches consider the daily life routine of people (i.e., the dynamics of network) carrying communicating devices, which certainly inuences their performance. Additionally, it has been shown that people's routines can be rather useful to determine future behavior [5], and that considering the dynamics of social ties (based on an analysis of contact duration) from dierent daily routines is important to achieve a correct mapping of real social interactions into a proximity graph with a clean (i.e., more stable) social representation able to aid data forwarding [4].

Our Approach

Forwarding based on social interactions has great potential as less volatile proximity graphs are created. However, existing approaches fail to consider the oscillations of social interactions, which are mostly inuenced by daily routines. We believe that the accuracy level of social interactions is mainly dependent on the statistical duration of contacts over dierent periods of time, since people have daily habits that lead to a periodic repetition of behavior [5]. Moreover, they will more accurately reect the real evolution of social ties than relying solely on the contact between nodes or well-dened social structures. This section starts by describing the TECD and TECDi utility functions. After that, we describe the algorithm that implements such utility functions.
3.1 Time-Evolving Contact Duration (TECD)

riod of time (hereafter called daily sample) over consecutive days, by computing social strength based on the average duration of contacts. Fig. 1 shows how social interactions (from the point of view of user A) vary during a day. For instance, it illustrates a daily sample (8 pm - 12 am) over which the social strength of user A to users D, E , and F is much stronger (less intermittent line) than the strength to users B and C . Fig. 1 aims to show the dynamics of a social network over a one-day period, where users' behavior in dierent daily samples lead to dierent social structures.

TECD aims to capture the evolution of social interactions in the same daily pe-

4
CD(a,b) CD(a,c)
08:00 a.m.

Study on the Eect of Network Dynamics on Opportunistic Routing

CD(a,d) CD(a,b) CD(a,b)
12:00 p.m. 04:00 p.m.

CD(a,b) CD(a,c)

CD(a,e) CD(a,f)
08:00 p.m. 12:00 a.m. 04:00 a.m.

CD(a,b) CD(a,c)
08:00 a.m.

Daily Sample

Ti D D B A C F E C F E A C F E B A C D B

W(a,b)i

B A C

B A C

Fig. 1.

Contacts of A with a set of nodes x (CD(a,x) ) in dierent daily samples Ti

As illustrated in Fig. 1, users' social strength in a given daily sample depends on the average contact duration that they have in such time period: if user x has n contacts with user y in a daily sample Ti , having each contact k a certain duration (Contact Duration - CD(x,y)k ), at the end of Ti the Total Contact Time (T CT(x,y)i ) between them is given by Eq. 1.
n

T CT(x,y)i =
k=1

CD(x,y)k

(1)

Each Ti represents a dierent daily sample in the routine of a person. Since a behavior pattern can be observed, we can consider that each daily sample represents a specic behavior at work/study place, home, or somewhere else (e.g., out of town, friends' houses). In [5] it is shown that people can have their future behaviors predicted by considering previous ones. Thus, we try to capture such behavior considering the time that nodes spend together (i.e., Total Connected Time ) in the same daily sample Ti along dierent days j . The Total Contact Time between users in the same daily sample over consecutive days can be used to estimate the average duration of their contacts for that specic daily sample [5]: the average duration of contacts between users x j and y during a daily sample Ti in a day j (AD( x,y )i ) is given by a cumulative moving average of their T CT in that daily sample (T CT(jx,y)i ) and the average duration of their contacts during the same daily sample Ti in the previous day (cf. Eq. 2)
j AD( x,y )i

j 1 T CT(jx,y)i + (j 1)AD( x,y )i

(2)

The social strength between users in a specic daily sample may also provide some insight about their social strength in consecutive k samples in the same day, Ti+k . This is what we call Time Transitive Property. This property increases the probability of nodes being capable of transmitting large data chunks, since transmission can be resumed in the next daily sample with high probability. The TECD utility function (cf. Eq. 3) is able to capture the social strength (w(x,y)i ) between any pair of users x and y in a daily sample Ti based on

Study on the Eect of Network Dynamics on Opportunistic Routing

the Average Duration (AD(x,y)i ) of contacts between them in such daily sample and in consecutive t 1 samples, where t represents the total number of daily samples. When k > t, the corresponding AD(x,y) value refers to the daily sample t k t. In Eq. 3 the time transitive property is given by the weight t+k-i , where the highest weight is associated to the average contact duration in the current daily sample, being it reduced in consecutive samples.
i+t1

T ECD = w(x,y)i =
k =i

t AD(x,y)k t+ki

(3)

3.2

TECD Importance (TECDi)

i , shown in Eq. 4, aims to capture the Importance (Ix ) of any user x in a daily sample Ti , based on its social strength (TECD ) towards each user that belongs to its neighbor set (Nx ) in that time interval, in addition to the importance of such neighbors.
TECDi

i T ECDi = Ix = (1 d) + d y Nx

w(x,y)i

i Iy Nx

(4)

TECDi is based on the PeopleRank function [10]. However, TECDi considers the social strength between a user and its neighbors encountered within a specic Ti , while PeopleRank computes the importance considering all neighbors of x at any time. It is worth mentioning that the dumping factor (d) in TECDi has a similar meaning as in PeopleRank: to introduce some randomness while taking forwarding decisions.

3.3

Distributed Algorithm

The operation of the algorithm is quite simple as shown in Algorithm 1. Its functionality is dierent according to the utility function being used, TECD or TECDi. In the former case, when the CurrentN ode meets a N odei in a daily sample Tk , it will get a list of all neighbors of N odei in that daily sample and its weights towards them, (N odei .WeightsToAllneighbors computed based on Eq. 3). Then, every M essagej in CurrentN ode's buer is replicated to N odei if the latter's weight towards the destination (getWeightTo(Destinationj )) is greater than CurrentN ode's weight towards the same destination. If TECDi is used, then when the CurrentN ode meets a N odei , the CurrentN ode obtains N odei 's importance and replication occurs if such importance is greater than or equal to that of the CurrentN ode.

6
Algorithm 1

Study on the Eect of Network Dynamics on Opportunistic Routing

begin foreach N odei encountered by if (T ECD being used) then

Forwarding with TECD and

CurrentN ode

TECDi

do

end

receive(N odei .WeightsToAllneighbors) foreach M essagej buer.(CurrentN ode) & / buer(N odei ) do if (N odei .getWeightTo(Destinationj ) > CurrentN ode.getWeightTo(Destinationj )) then CurrentN ode.replicateTo(N odei , M essagej ) else if (T ECDi being used) then receive(N odei .Importance) foreach M essagej buer.(CurrentN ode) & / buer(N odei ) do if (N odei .importance CurrentN ode.importance) then CurrentN ode.replicateTo(N odei , M essagej )

Performance Evaluation

This section presents the evaluation methodology, implementations and simulation settings, and the evaluation results which point out advantages and constraints of capturing the dynamics of the network, by using time-evolving contact duration and node importance in opportunistic routing. Results are analyzed in two stages: we start by the performance analysis between the TECD -based algorithm and contact-based approaches, PROPHET and Epidemic. Next, we analyze the performance of the TECDi -based algorithm against social-based approaches, Bubble Rap and Rank (a PeopleRank -like solution). For the sake of simplicity, we refer to our algorithm as TECD or TECDi hereafter.
4.1 Evaluation Methodology

Performance analysis is carried out on Opportunistic Network Environment (ONE) [11] simulator with simulations representing a 12-day interaction period between nodes. Each simulation is run ten times (with dierent random number generator seeds for the used movement models) to provide a 95% condence interval for the results. The metrics used to assess the performance of TECD and TECDi against the contact- and social-based benchmark solutions are the average delivery probability (i.e., ratio between the number of delivered messages and total number of created messages), average cost (i.e., number of replicas per delivered message), and average latency (i.e., time elapsed between message creation and delivery). Regarding the ONE simulator, the time step size is of 2 seconds [11], and simulations are performed in batch mode with 2 GB RAM dedicated memory.
4.2 Implementations and Simulation Settings

TECD and TECDi are compared with representatives of the identied contactand social-based approaches in Section 2. In what concerns contact-based solutions, PROPHET [6] and Epidemic [12] were chosen for being the most cited

Study on the Eect of Network Dynamics on Opportunistic Routing

proposals: the rst is widely recognized by the Delay Tolerant Networks (DTN) research community, and the second represents a solution that is merely interested in replicating messages in order to increase delivery. For the social-based approaches, Bubble Rap [2] and PeopleRank [10] were selected as representative of solutions based on social structures and node popularity notions. Regarding the implementations, ONE encompasses all benchmarks except Rank. Hence, we have implemented it considering the node degree and the importance of its neighbors to make it having a PeopleRank -like behavior in each time interval of a daily routine. Thus, instead of determining the overall importance of a node at each encounter, like PeopleRank does, Rank estimates the node importance at the end of every daily sample. It is worth noting that the dumping factor d of Rank, which is also used in TECDi, was set to 0.8, since it lies among the values where PeopleRank [10] showed the best success rates. Regarding Bubble Rap, we used it with K-clique and single window algorithms for community formation and node centrality computation [2]. We chose parameter k to be 5, since it results in the best overall performance for Bubble Rap in terms of delivery probability, cost and latency. Regarding the simulation settings, although not using real traces, we aim at creating a scenario close to the one found in people's daily activities. Such concern is also considered in the evaluation of considered benchmarks where community-based scenarios are devised and real world traces are used. The simulation scenario is part of the Helsinki city and has 150 nodes distributed in 8 groups of people and 9 groups of vehicles. One of the vehicle groups, with 10 nodes, follows the Shortest Path Map Based Movement, where they randomly choose a place and use the shortest path to reach it. These nodes represent police patrols equipped with Bluetooth (250 kbps in a 10 m range), with speed between 7 to 10 m/s and a pause time between 100 and 300 seconds. The other vehicle groups represent buses. Each group is composed of 2 vehicles, equipped with Bluetooth (250 kbps/10 m) and WiFi (11 Mbps/250 m), following the Bus Movement with speeds between 7 to 10 m/s and pause times between 10 and 30 seconds. Due to limitations of the Bubble Rap implementation, the bus group is equipped with only WiFi (11 Mbps/100 m) interface. The people groups follow the Working Day Movement with walking speeds between 0.8 and 1.4 m/s and may also use buses. Each group has dierent meeting spots, oces, and home locations. People spend 8 hours at work and present 50% probability of having an evening activity after work. In the oce, nodes move around and have a pause time between 1 min and 4 hours. Evening activities can be done alone or in group, and can last between 1 and 2 hours. The trac load corresponds to approximately 500 messages generated per day among a subset of preset node pairs, which results in 6000 considered for the performance assessment. TTL values were set at 24 hours and unlimited. With a 24-hour TTL, messages have a short time in the system and shall impact delivery probability, and unlimited TTL increases the cost as messages are allowed to be replicated for the duration of the simulations. This way the studied proposals are analyzed in two

Study on the Eect of Network Dynamics on Opportunistic Routing

extreme cases. Message size ranges from 1 kB to 100 kB. The buer space is of 2 MB. Message and buer size comply with the universal evaluation framework that we proposed previously [3] based on the evidence that opportunistic routing prior-art follow completely dierent evaluation settings, making assessment a challenging task.
4.3 Comparison against Contact-based Algorithms

As shown in Fig. 2(a), TECD has a gain of 16.17 percentage points over PROPHET (59.87% against 43.70%) and a gain of 23.77 percentage points over Epidemic (59.87% against 36.10%) for a 24-hour TTL. The average delivery probability gain of TECD with unlimited TTL increases to 18.41 percentage points over PROPHET (44.39% against 25.97%), and to 23.26 percentage points over Epidemic (44.39% against 21.13%). As TECD is able to reect the daily routine and intensity of social ties, it only forwards messages to nodes that actually increase the probability of reaching the destination (i.e., are well socially connected) even if the carrier needs to keep the message for a little longer. PROPHET 's performance is aected by the presence of nite loops (happening occasionally) that keep messages in the system for longer times, which in turn use transmission opportunities that would be needed to keep a good delivery probability of other messages. Epidemic 's performance is explained by an aggressive replication strategy, which quickly exhausts buer space, limited to 2 MB per node. Regarding the average cost, Fig. 2(c) shows that for the 24-hour TTL, TECD produces 57.37 replicas to perform a delivery against 272.35 of PROPHET and 454.12 of Epidemic. For unlimited TTL, TECD has a higher number of replicas (121.30), but it is still lower than the ones created by PROPHET (247.11), and almost 4.5 times smaller than the ones created by Epidemic (535.04). TECD presents a lower cost than PROPHET, since it wisely chooses the next best hop based on the social strength, avoiding a higher number of replicas (i.e., messages can be held in the carrier node for a longer time, while nding stronger social ties). Although the advantage of TECD decreases with unlimited TTL, this is acceptable since the cost is expected to increase as messages are allowed to live longer in the system. The cost reduction of PROPHET with unlimited TTL is related to the limited buer (i.e., 2 MB), which does not allow it to further replicate as long-lived messages quickly exhaust nodes' buer. As mentioned before, buer limitation is not an issue for TECD since it wisely chooses next hops, leading to lower replications and to lower buer occupancy. Regarding Epidemic, the trend is for the number of replicas to increase with TTL as messages take longer to expire: with unlimited TTL cost increases almost 18%. For the average latency, Fig. 2(e) shows that with a 24-hour TTL, TECD has a lower average latency than PROPHET (1672.82 s lower) and Epidemic (4173.53 s lower). This is due to the fact that TECD is able to deliver messages with a lower number of hops (3.23 against 3.66 of PROPHET and 11.10 of Epidemic ) and due to occasional nite loops that add delay in PROPHET. For unlimited TTL, TECD has slightly higher latency because nodes tend to hold

Study on the Eect of Network Dynamics on Opportunistic Routing

messages for longer time based on the expectation of having a better transmission opportunity in a later time interval.

Average Delivery Probability 1 0.8 0.6 % 0.4 0.2 0 24h TTL Unlimited % TECD PROPHET Epidemic 1 0.8 0.6 0.4 0.2 0

Average Delivery Probability TECD TECDi Rank Bubble Rap

24h TTL

Unlimited

(a) Average delivery probability of TECD, (b) Average delivery probability of TECD, PROPHET, and Epidemic TECDi, Rank and Bubble Rap
Average Cost 700 600 Number of replicas 500 400 300 200 100 0 24h TTL Unlimited Number of replicas 700 600 500 400 300 200 100 0 24h TTL Unlimited Average Cost

(c) Average cost of and Epidemic

90000 80000 70000 60000 Seconds 50000 40000 30000 20000 10000 0 24h

TECD, PROPHET, (d) Average cost of TECD, TECDi, Rank and Bubble Rap
Average Latency 90000 80000 70000 60000 Seconds 50000 40000 30000 20000 10000 0 Unlimited TTL 24h TTL Unlimited

Average Latency

(e) Average latency of TECD, PROPHET, (f) Average latency of and Epidemic Rank and Bubble Rap
Fig. 2.

TECD, TECDi,

Comparison results for the considered performance metrics

Fig. 2(e) also shows that

latency increases with TTL. This happens since

PROPHET

has similar behavior as reported in [6]:

PROPHET has no mechanism to

10

Study on the Eect of Network Dynamics on Opportunistic Routing

erase copies of messages that were already delivered, which occupy buer and use forwarding opportunities of undelivered messages. The same justication helps to explain the higher latency of TECD and Epidemic with unlimited TTL. The dierence in latency values with unlimited TTL for the three approaches is due to the fact that Epidemic puts much more messages in the system, which increases the probability of one message arriving rst to the destination. Nevertheless, the cost of this strategy is very high (cf. Fig. 2(c)). These rst results show that representing social interactions based on the average duration of contacts in time intervals dened based on people daily habits leads to an overall better performance than just using inter-contact time information such as time since last encounter and frequency of encounters. In summary, with a 24-hour TTL, TECD presents an average delivery probability 16% and 23% higher than PROPHET and Epidemic, producing almost 1 1 5 and 8 less replicas with a subtle gain in latency, respectively. With unlimited TTL, the advantage of using TECD in relation to PROPHET and Epidemic is still clear. Although TECD presents an average latency 6.29% and 31.79% higher than PROPHET and Epidemic, it presents an average delivery probability 18.41 and 23.26 percentage points higher, producing nearly 126 and 414 less replicas.
4.4 Comparison against Social-based Algorithms

considering social relationships as a complement to the importance of nodes (metric used by Rank ) for the identication of accurate social interactions; and, second, to analyze how an approach able to capture the network dynamics based on a time-evolving social-based solution behaves when compared to solutions that rely solely on the identication of social structures, as with Bubble Rap. In what concerns the average delivery probability (cf. Fig. 2(b)), TECD overcomes Rank and Bubble Rap in 22.84 and 29.26 percentage points, respectively, for a 24-hour TTL (59.87% against 37.03% and 30.61%, respectively). For unlimited TTL, all approaches present lower delivery probability (while keeping the same performance order), with the exception of Bubble Rap, which improves as TTL increases. It is also observed that TECDi has a gain of 6.06 percentage points over Rank for a 24-hour TTL (43.09% against 37.03%). This gain is higher than the one of Rank for a scenario with unlimited TTL (23.25% against 18.37%). Regarding Bubble Rap, TECDi has a gain of more than 12 percentage points for the 24-hour TTL case (43.09% against 30.61%), since Bubble Rap needs some time to create communities, which aects its delivery rate. However, for the unlimited TTL case, Bubble Rap overcomes TECDi by more than 9 percentage points, which was expected since it has now more time to form communities increasing the delivery capability as reported in Hui et al. Based on Fig. 2(b), our ndings show that, considering the strength of social ties in addition to the importance of nodes, it brings benets in terms of delivery

In this section, we analyze the performance of TECD and TECDi against Bubble Rap and Rank. The goal is two-fold: rst, to analyze the potential benets of

Study on the Eect of Network Dynamics on Opportunistic Routing

11

probability. With TECDi the importance of nodes is inuenced by the social strength they have with neighbors. This means for instance that a node, with a high set of weakly related neighbors, will have a lower importance with TECDi than with Rank. Moreover, next hops are selected among the important nodes that have a stronger social tie with the message carrier, which helps in the case where more than one contact is needed to transfer a message. In what concerns the average cost (cf. Fig. 2(d)), TECD achieves the lowest cost with 24-hour TTL when compared to Rank and Bubble Rap (57.37 replicas against 302.05 and 559.69, respectively) as it chooses the best next hop based on the social strength. The same behavior occurs with unlimited TTL as TECDi is able to reduce the number of potential next hops from the set of important neighbors (being more selective in relation to nodes with high degree but weak social ties with their neighbors). However, cost increases with TTL, since messages stay longer in the system and are subjected to more replication. Bubble Rap presents the highest costs independently of TTL, as replication occurs based on global centrality when communities are not yet fully formed, and nodes with higher global rank (i.e., those which move throughout the entire scenario like buses) are always receiving messages in an attempt to have them readily delivered. The decrease in cost of Bubble Rap with unlimited TTL is due to messages starting to exhaust buer in carrier nodes, which means less messages to be replicated. Regarding the average latency (cf. Fig. 2(f)), TECD manages to have the lowest latency (less 4598 s and 17476 s than Rank and Bubble Rap, respectively) whereas TECDi has a subtle higher latency (more 818.37 s) than Rank, but still has a lower latency (less 12059 s) than Bubble Rap with a 24-hour TTL. With unlimited TTL, TECD still has a lower latency (less 2752 s) than Rank, but a higher latency (more 13299 s) when compared to Bubble Rap, while TECDi has a higher latency than Rank and Bubble Rap (11492.86 s and 27545 s, respectively). Increase in latency of TECD is due to messages being held longer in attempt to nd better next hops. As for TECDi, messages are replicated based on node importance, and as they reach top-ranked nodes, they take more time to reach destination especially if those do not interact much outside their social groups. The high latency of Bubble Rap with 24-hour TTL is expected as messages are subject either to the formation of communities or to the fact that their holders must come in contact to higher popularity ranked nodes to perform forwarding, thus inuencing the overall latency experienced. As the number of delivered messages increased in the unlimited TTL case, so did its overall latency. When compared to TECD, both Rank and TECDi present a higher average latency, since nodes tend to hold messages longer, especially if the current node has a high importance factor. The impact of the importance factor also explains the higher latency of TECDi in relation to Rank, since the former also consider the social strength between nodes, in addiction to the importance of nodes. In summary, with a 24-hour TTL, TECD overcomes Rank and Bubble Rap in terms of delivery probability for more than 22.84 and 29.26 percentage points 1 1 and 10 less replicas with 13.58% and 51.63% lower larespectively, creating 5

12

Study on the Eect of Network Dynamics on Opportunistic Routing

tency. Yet, TECDi presents an average delivery probability of 6.06 and 12.47 percentage points higher than Rank and Bubble Rap respectively, producing almost 36 and 294 less replicas with a 2.12% higher latency than Rank and 30.7% lower latency than Bubble Rap. With unlimited TTL, TECD has still better performance in terms of delivery probability and cost than Rank and Bubble Rap, although its latency is 24.20% higher than Bubble Rap. In the case of TECDi, it brings more advantages than Rank, because although the former presents an average latency 16.18% higher than Rank, it has an average delivery probability 4.88 percentage points higher than Rank, producing 55 less replicas. With Bubble Rap, although it has a gain of 9 percentage points regarding delivery probability and a lower latency, TECDi manages to spare resources by creating almost 37% less replicas.
4.5 Scalability Analysis

We analyze the memory needed for computing TECD and TECDi. Considering a worst case scenario with k time slots and n nodes, where every node meets all other nodes in each Ti , we have:
 n (n 1) variables to store the starting time for every new connection.  n (n 1) variables to store T CT computations.  k n (n 1) variables to store AD computations.

If each variable has X bits, TECD 's needed resources is given by Eq. 5.
T ECDalloc = n (n 1) (k + 2) X bits

(5)

In our scenario we have 150 nodes, 6 time slots, and 64 bit double for storing, which results in 1.364 MB of total memory usage in the system, which means that in average each node needs up to 4 MB (including the 2 MB of buer space). To use TECDi, nodes need to store their importance and the importance of nodes they meet. Thus, the amount of needed resources is given by Eq. 6.
T EDCialloc = n2 X + T ECDalloc bits

(6)

Assuming the aforementioned worst case, TECDi needs a storage capacity of 1.536 MB, which means that in average a node needs to reserve the same 4 MB. In case of rather limited buer, a solution is to keep track of the best weights, eliminating those under a threshold. A conguration with pre-dened thresholds will be considered to investigate which is the most suitable value to be used.

Conclusions and Future Work

Prior art proved that social relationships are useful for data exchange in opportunistic networks. Thus, it is clear that solutions based on the structure of the network have much better performance than solutions based solely on contacts. However, we can also observe that the dynamics of the network (i.e., based

Study on the Eect of Network Dynamics on Opportunistic Routing

13

on daily routines) should also be addressed in order to improve even more opportunistic routing. Hence, we propose two utility functions which are based on the daily routine of people, and can transcribe movement patterns resulting from social ties into equivalent social weighted representations relevant for forwarding: Time-Evolving Contact Duration (TECD), where social interactions are weighted reecting the social daily routines of users, and TECD Importance, which includes the social strength between nodes and their importance. As presented in Sections 4.3 and 4.4, network dynamics can indeed improve the performance of opportunistic routing when compared to solutions based on the structure of the network and on node contact. TECD stands out amongst the contact- and social-based proposals and it even has advantages over TECDi : delivery probability gains up to 21.1 percentage points producing ~242 less replicas with a lower latency (~17.3%). This is due to the fact that TECD replicates messages based on the social strength among nodes (which is very reliable), while TECDi does it based on node importance. This dependency on node importance results in useless replications which increases TECDi 's cost contributing to its lower delivery probability and higher latency. Still TECDi has great potential (when compared to the remaining solutions) in improving forwarding, and this approach should be further investigated. This paper showed the advantages of using solutions based on the dynamics of the network for routing. We prove this by comparing a solution based on utility functions that are aware of users' daily routines against prior art. As future work, we aim to investigate a hybrid utilization, with TECD and TECDi, creating a new opportunistic routing proposal to forward messages. We also plan to netune both utility functions to improve delivery probability, cost and latency, and evaluate such proposals considering human traces to show its potential in real scenarios.

Acknowledgment
To FCT for nancial support to Waldir Moreira's PhD grant (SFRH/ BD/62761 /2009) and to the User-Centric Routing project (PTDC/EEA-TEL/103637/2008).

References
1. A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott, Impact of human mobility on the design of opportunistic forwarding algorithms, in Proceedings
of INFOCOM, (Barcelona, Spain), April, 2006.

2. P. Hui, J. Crowcroft, and E. Yoneki, Bubble rap: social-based forwarding in delay tolerant networks, Mobile Computing, IEEE Transactions on, vol. 10, pp. 1576 1589, November, 2011. 3. W. Moreira, P. Mendes, and S. Sargento, Assessment model for opportunistic routing, in Proceedings of the IEEE LATINCOM, (Belem, Brazil), October, 2011.

14

Study on the Eect of Network Dynamics on Opportunistic Routing

4. T. Hossmann, T. Spyropoulos, and F. Legendre, Know thy neighbor: Towards optimal mapping of contacts to social graphs for dtn routing, in Proceedings of
IEEE INFOCOM, (San Diego, USA), March, 2010.

5. N. Eagle and A. Pentland,  Eigenbehaviors: identifying structure in routine, Behavioral Ecology and Sociobiology, vol. 63, pp. 10571066, May, 2009.

6. A. Lindgren, A. Doria, and O. Schelen, Probabilistic routing in intermittently connected networks, in Service Assurance with Partial and Intermittent Resources, vol. 3126 of Lecture Notes in Computer Science, pp. 239254, Springer Berlin / Heidelberg, 2004. 7. L. Song and D. F. Kotz, Evaluating opportunistic routing protocols with large realistic contact traces, in Proceedings of ACM MobiCom CHANTS, (Montreal, Canada), September, 2007. 8. S. Nelson, M. Bakht, and R. Kravets, Encounter-based routing in DTNs, in Proceedings of INFOCOM, (Rio de Janeiro, Brazil), April, 2009.

9. P. Costa, C. Mascolo, M. Musolesi, and G. P. Picco, Socially-aware routing for publish-subscribe in delay-tolerant mobile ad hoc networks, Selected Areas in
Communications, IEEE Journal on, vol. 26, pp. 748760, June, 2008.

10. A. Mtibaa, M. May, M. Ammar, and C. Diot, Peoplerank: Combining social and contact information for opportunistic forwarding, in Proceedings of INFOCOM, (San Diego, USA), March, 2010. 11. A. Kernen, J. Ott, and T. Krkkinen, The one simulator for dtn protocol evaluation, in Proceedings of SIMULTools, (Rome, Italy), March, 2009. 12. A. Vahdat and D. Becker, Epidemic routing for partially connected ad hoc networks, Tech. Rep. CS-200006, Duke University, 2000.

ANNEX G - Technical Report Social-aware Utility Functions for Opportunistic Routin .

Social-aware Utility Functions for Opportunistic Routing

August 9, 2012

Technical Report

Waldir Aranha Moreira Junior (SITI/ULHT) Prof. Dr. Paulo Mendes (SITI/ULHT)

Executive Summary
This technical report describes in more detail the utility functions used in the dLife opportunistic routing solution [10, 9]: i) Time-Evolving Contact Duration (TECD); ii) TECD Importance (TECDi). The proposed utility functions are able to infer information about social relationship among users, allowing the dLife protocol to perform forwarding based on social graphs. The TECD utility function weighs the social relationship among nodes based on their interaction, and the TECDi utility function measures the importance of a node according to the weight of the links to its neighbours and their important . Additionally, this report presents the experiments done to evaluate the two utility functions as well as the roadmap to improve them. This work was done in the context of Waldir Moreiras PhD thesis entitled Social-aware Opportunistic Routing for Delay-Tolerant Networks and is being evaluated in the context of the DTN-Amazon project that SITI coordinates with the Federal University of Par in Brazil.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

Contents
1 Introduction 2 Related Work 3 Social-Aware Routing Utility functions 3.1 Time-Evolving Contact Duration (TECD) Utility Function . . . . . . . . . . . . . . . . . . . . . . . 3.2 TECD Importance (TECDi) Utility Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Performed Improvements 4.1 Incorporating TTL . . . . . . . . . . . . . . . . . . 4.2 Slope . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Average Duration Bug . . . . . . . . . . . . . . . . 4.4 Order of Average Duration for Weight Computation 4.5 Reset Day Count . . . . . . . . . . . . . . . . . . . 4.6 Daily Periods of Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 5 6

6 . 6 . 7 . 8 . 9 . 10 . 10

5 Community Detection 11 5.1 TECD-based solution as alternative to k-clique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6 Conclusions and Future Work References 12 13

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

1 Introduction
Since 2007 [11], we witnessed a great effort of incorporating social information into opportunistic routing to improve its performance. Different solutions have emerged [7, 3, 2, 13, 6] and it is easily seen how the use of social information increases the performance of opportunistic routing. Such social information is used to devise metrics which are then used to build social structures based on node afliation, communities, interests, and node popularity, for instance. However, these structures are based almost solely on inter-contact times [1], and the nature of such statistics still requires further understanding (e.g., power-law, behavior dependent on node context). Moreover, the resulting proximity graphs are mostly created considering user mobility, which makes such graphs instable and with increased overhead [6]. When considering social information, it is important to map real interaction (coming from node mobility) happening as users socialize among themselves into a clean social representation (i.e., with only stable social contacts), aiming to devise reliable proximity graphs capable of improving opportunistic routing [5]. Moreover, such users routines can provide insights of future interaction behavior among users sharing similar social behavior and potentially same communities and interests [4]. Thus, both studies suggest social behavior and its oscillations (i.e., dynamics) should be considered to build social structures. With this in mind, we designed two utility functions to capture the dynamism of user behavior in different periods of time: Time-Evolving Contact Duration (TECD) that weights social interactions based on the statistical contact duration that nodes have in the same daily period of time, over consecutive days; and TECD Importance (TECDi) which estimates the importance of nodes based on its node degree and the social strength towards its neighbors, in different periods of time. It is important to mention that our goal with this technical report is three-fold: i) First to explain how TECD and TECDi were designed; ii) Second, to present the performance improvement studies carried out; and, iii) Third to show the performed experimentations to check their applicabilities. This report is presented as follows. Section 2 briey presents the related work that helped us to develop the TECD and TECDi functions, which are explained in Section 3. Sections 4 and 5 explain what has been done to improve the performance of the two utility functions and what is their potential applicability . Finally, Section 6 concludes this technical report and presents future next steps.

2 Related Work
We carefully analyzed different proposals spanning a ten-year period (2000-2010) and observed that most of the opportunistic routing solutions consider the replication-based forwarding scheme, while only 15% are based either on single-copy or on ooding-based forwarding schemes [12] [11]. We could also note that approximately 69% of the replication-based proposals consider a contact-based approach (e.g., frequency of encounters) while 31% (the latest ones) employ a new trend based on social similarity metrics (e.g., community detection). Contact-based solutions build and update their proximity graphs based on the contacts among nodes, and consider metrics such as the number of times nodes meet, contact frequency and the last time a contact occurred. A few examples of such solutions are Protocol using History of Encounters and Transitivity (PROPHET) [8], Prediction [15], and Encounter -Based Routing [14]. Yet, social-based solutions have their proximity graphs determined by social similarity metrics such as intercontact times. Since we are very much interested in the social similarity branch, we focused on ve socialbased solutions in order to understand their functioning and how they handle social information to improve opportunistic routing. These solutions perform forwarding by: i) labeling users according to their social groups (e.g., Label [7]); ii) looking at the importance (i.e., popularity) of nodes (e.g., PeopleRank [13]); iii) combining the notion of community and centrality (e.g., SimBet [3] and Bubble Rap [6]); and, iv) considering interests that users have in common (e.g., SocialCast [2]). We could observe that contact-based solutions are able to achieve good performance levels, but with a high associated cost as updates to the proximity graph are triggered by node movements [6]. Additionally we note that, despite the stability of proximity graphs based on social information, social-based solutions suffer with the burden of forming communities [6] or are based on strong assumptions about nodes sharing the same interests spending most of the time co-located [2, 13]. After gathering enough knowledge about existing forwarding schemes (especially about the ones based on social aspects), we could see that such proposals were not considering the daily life routines of users, i.e., the dynamics of the network. We believe that network dynamics can certainly (and positively) inuence the performance of social-based solutions. It has been shown the importance of correctly capturing the real social interactions (i.e., what is happening in the users daily routine) and mapping them to a more stable proximity graph (i.e., with only relevant social representations) to improve forwarding [5]. Additionally, such routines can

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

CD(a,d) CD(a,b) CD(a,c)

08:00 a.m.

CD(a,b) CD(a,b)
12:00 p.m.

CD(a,b) CD(a,c)
04:00 p.m.

CD(a,e) CD(a,f)
08:00 p.m. 12:00 a.m. 04:00 a.m.

CD(a,b) CD(a,c)
08:00 a.m.

Daily Sample

Ti D D B A C F E C F E A C F E B A C D B

W(a,b)i

B A C

B A C

Figure 1: Contacts of node A with nodes x (CD (a, x)) in different time intervals Ti also provide insights about about future behavior, which is rather useful for taking better forwarding decisions [4]. With the acquired knowledge on the proposals and the importance of network dynamics to improve opportunistic routing, we devised two novel utility functions based on the contacts among users to weight their social relationships (TECD) and rank their importance (TECDi) in different periods of time.

3 Social-Aware Routing Utility functions

In this section, we present the devised utility functions. Since social information has shown its potential in improving routing [7, 3, 2, 13, 6], our functions were devised to capture the level of social relationship between nodes and measure their social importance in the system to improve routing. So, they can be used in separate or together according to the demands present in the scenario. For instance, if what matters is how well nodes are socially related, TECD can be used by itself. On the other hand, if identifying the most social important node in vicinity is the case, TECDi provides that. In this report, TECD and TECDi are evaluated in separate, but results also suggest a great potential when combining them.

3.1

Time-Evolving Contact Duration (TECD) Utility Function

TECD encompasses: i) the duration of contacts, representing the intensity of social ties among users; and, ii) time-evolving interactions, reecting users habits over different time periods (referred to as daily samples). Fig. 1 shows how the social interaction (from the point of view of node A) changes over time reecting daily routines. That is, for a period between 8 p.m. and midnight, the social interaction of node A is stronger with nodes D, E , and F than it is with nodes B and D, being the weight of the edges illustrated by the intermittency of the line. As illustrated in Fig. 1, two nodes may have a social weight w (x, y )i that depends on the average total contact duration they have in that same period of time over different days. Within a specic Ti , node x has n contacts with node y , having each contact k a certain Contact Duration (CD (x, y )k ). At the end of each Ti , the Total Connected Time (T CT (x, y )i ) between nodes x and y is given by Eq. 1.
n

T CT (x, y )i =
k=1

CD (x, y )k

(1)

Each Ti represents a different period of time in the daily routine of a person. Since a behavior pattern can be observed, we can consider that at each daily sample a specic social behavior is taking place at work/study place, home, or somewhere else (e.g., out of town, friends houses). In [4] it is shown that people can have their future behaviors predicted by considering previous ones. Thus, we try to capture such behaviors considering the time that nodes spend together (i.e., Total Connected Time) in the same daily samples Ti along different days j . Through a cumulative moving average (cf. Eq. 2), on day j , we determine the Average Duration (AD (x, y )ji ) of the Total Connected Time between nodes x and y at Ti by considering the current behavior (T CT (x, y )ji ) and the Average Duration in the same period of the previous day (AD (x, y )(j 1)i ). AD (x, y )ji = T CT (x, y )ji + (j 1) AD (x, y )(j 1)i j (2)

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

It is our belief that the social strength between nodes in a certain daily sample should also give some indication about the strength between such nodes in subsequent periods of time (which we call Time Transitive Property). For instance, the social strength of nodes between 8 a.m. and 12 p.m. should provide an expected strength between 12 p.m. and 4 p.m. For routing purposes, such time transitive property helps to select nodes that may provide good delivery probability over consecutive periods of time, where the complete message will be fully transmitted using the contacts expected to occur in consecutive periods. Hence, TECD (cf. Eq. 3) gives us the social weight between any pair of nodes, w (x, y )i . Such social weights are a function of the Average Duration of the Total Connected Time between nodes x and y in Ti (AD (x, y )i ) and in subsequents t 1 daily samples, being t dened by default as the number of congured samples. Thus, k evolves from the current daily sample i to the daily sample i + t 1 (e.g., from daily sample three, corresponding to 4 p.m. - 8 p.m. to daily sample two, corresponding to 12 p.m. - 4 p.m., as shown in Fig. 1). For values of k > t, the value of AD (x, y ) corresponds to the time slot k t. For instance, for a conguration with six daily samples, for k equals to 9, the value of AD (x, y ) corresponds to the third sample of the day, which means 4 p.m. - 8 p.m., as illustrated in Fig. 1. In Eq. 3, the time transitive property of TECD is t represented by t+k i giving more importance to the average duration of contacts in the current daily sample, and decreasing such importance in subsequent ones.
i+t1

T ECD = w (x, y )i =
k=i

t AD (x, y )k t+ki

(3)

3.2

TECD Importance (TECDi) Utility Function

As social interaction may also be modeled to consider the node importance, we propose a variation of TECD, called TECDi, to compute the Importance (I (x)i ) of a node x (cf. Eq. 4), considering the weights of the edges between x and all the nodes in its neighbor set (N (x)) at a specic Ti along with their importance. T ECDi = I (x)i = (1 d) + d
y N (x)

w (x, y )i

I (y )i N ( x)

(4)

TECDi is based on the PeopleRank function [13]. However, it is our understanding that the selection of next hops should consider not only their importance, but also the strength of social ties between message holder and potential next hops. Another difference is that with TECDi the neighbor set of a node x only includes the nodes which have been in contact with node x within a specic daily sample Ti , whereas in PeopleRank the neighbor set of a node includes all the nodes that ever had a link to node x. Note that the dumping factor (d) in the formula is the same used in PeopleRank and represents the level of randomness considered by the forwarding algorithm.

4 Performed Improvements
This section aims to report the improvements done to ensure that the proposed utility functions have satisfactory performance. These improvements consist in testing different aspects of the utility functions such as: i) the inclusion of message TTL while taking a forwarding decision; ii) the level of importance given to the average duration of contacts while determining the social weight; iii) the suitable number of daily samples. Additionally, some improvements result from code debbuging done in a Java implementation for the ONE simulator.

4.1

Incorporating TTL

Since we want to further explore the Time Transitive Property mentioned in Section 3, we try to consider the Time-To-Live (TTL) of the messages while determining the weight to a potential next forwarder. Thus, for this set of tests we adapt TECD in order to also take account the message TTL, which we refer to as TECD_TTL. Fig. 2 shows the results considering the average delivery probability, average cost, and average latency. In TECD_TTL, message TTL is checked for every message in order to determine how far (in terms of daily samples) it is still alive. Once this in known, the weights to a given destination are then determined considering only the daily samples the message is still useful.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

Average Delivery Probability

1 0.8 0.6

Average Cost
300

Average Latency
70000
TECD

Number of replicas

TECD TECD+TTL

250 200 150 100 50 0

TECD TECD+TTL

60000 TECD+TTL

Seconds
24h Unlimited

50000 40000 30000 20000 10000 0 24h Unlimited

%
0.4 0.2 0

24h

Unlimited

TTL

TTL

TTL

(a) Average Delivery Probability

(b) Average Cost

(c) Average Latency

Figure 2: Effect of message TTL on determining social weight Regarding the average delivery probability (cf. Fig. 2(a)), TECD_TTL has a gain of only 0.96 percentage points (60.84% against 59.87% of TECD) for a 24-hour TTL. Such gain reduces dramatically when message TTL is set to unlimited (TECD has performance over 18 percentage points over TECD_TTL). When it comes to average cost (cf. Fig. 2(b)), TECD_TTL creates 2.79 and 125.81 replicas more than TECD for 24-hour and unlimited TTL, respectively. Finally, in what concerns average latency (cf. Fig. 2(c)), TECD_TTL has an increase in terms of latency (439.73s) when compared to TECD for a 24-hour TTL. For the unlimited TTL case, the lower latency (4041.09s) of TECD_TTL is explained by the fact that the reported latency is in function of the delivery message which, for this case was much lower. In TECD_TTL, messages were able to spend less time in buffer (11156s) than with TECD (11379). We can see that considering the message TTL to determine link weights has only a slightly gain compared to our proposal (TECD) in terms of delivery probability. However this comes with an increase in the number of created replicas and latency. More replicas are created especially when TTL is close to expiring, since we expect to increase its delivery probability by forwarding messages as quickly as we can. This increase in latency is justied by the also increase in the number of created replicas since this extra few copies will also contribute to the overall latency.

4.2

Slope

As we can see in Eq. 3, it is given a level of importance to the average duration of contacts in the current daily sample which decreases in subsequent ones. We also studied what would be the best importance level to consider in our approach. We dened the following levels in which the social weight is given by: Level A: w =
6 21 AD

5 21 AD

4 21 AD

3 21 AD

2 21 AD

1 21 AD

6 6 6 Level B: w = 6 6 AD + 7 AD + 8 AD + 9 AD +

6 10 AD

6 11 AD

Level C: w = AD + 0.81AD + 0.62AD + 0.43AD + 0.24AD + 0.05AD Fig. 3 shows how the average duration of contacts should be impacted.

Figure 3: Different importance levels.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

Based on Fig. 3 we check the performance of each level when determining the social weight for the same performance evaluation metrics, namely average delivery probability, average cost, and average latency as shown in Fig. 4. For these experiments, we decided to vary even more the message TTL to observe the behavior of TECD with the different importance levels.
Average Delivery Probability
1
Level A Level B Level C

Average Cost
140
Level A Level B Level C

0.8

120

Number of replicas
1 5 10 24 36 48 96 192 384 768 Unlimited

100

0.6

80

0.4

60

40 0.2 20

10

24

36

48

96

192

384

768 Unlimited

TTL (hours)

TTL (hours)

(a) Average delivery probability for different levels

Average Latency
80000
Level A Level B Level C

(b) Average cost for different levels

70000

60000

50000

Seconds

40000

30000

20000

10000

10

24

36

48

96

192

384

768 Unlimited

TTL (hours)

(c) Average Latency for different levels

Figure 4: Effect of different levels when determining the social weight Regarding average delivery probability (cf. Fig. 4(a)), TECD with level B managed to have slightly better performance (percentage points) than with levels A and C. This performance of TECD with level B comes with a subtle increase in cost (as shown in Fig. 4(b)) especially when compared to its version with level A. Regarding latency (cf. Fig. 4(c)), TECD with level B had an increase in 45% of the cases (i.e., TTL at 10, 96, 384, 768, and unlimited). We could see that the results are statistically equivalent, and we chose to consider level B in our implementation of TECD. The reason is that with this level, TECD increases faster as well as decreases faster which is a good approach especially when penalizing the social weight between nodes to improve routing performance.

4.3

Average Duration Bug

During the debbuging phase in the ONE simulator, we found a bug in the calculation of Average Duration. This bug resulted in the wrong calculation of AD in situations where nodes did not meet for different and consecutive daily samples. As shown in Alg. 1, the computation of AD is done in two parts (lines 2 - 16 and lines 17 - 22). Since the rst implementation would only compute the AD for nodes only seen in that specic daily sample (line 5), this resulted in the non-recomputation of AD for nodes previously met.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

Algorithm 1 Prior to xing bug

1- private void updateAverageDuration(){ 2- long currentday=SlotTimeCheck.getDay(); 3- int currentslot = SlotTimeCheck.getcurrentslot(); 4- Map<DTNHost,Double> currentAverageDurationSlot=averageDurations.get(currentslot); 5- Set hostsinDelta = deltaT.keySet(); 6- Iterator<DTNHost> deltaTHostIterator= hostsinDelta.iterator(); 7- while(deltaTHostIterator.hasNext()){ 8DTNHost currenthost= deltaTHostIterator.next(); 9double oldAD=0; 10if(currentAverageDurationSlot.get(currenthost)==null){ 11oldAD=0; 12else 13oldAD=currentAverageDurationSlot.get(currenthost); 14double newAD = (deltaT.get(currenthost)+(currentday-1)*oldAD); 15currentAverageDurationSlot.put(currenthost,newAD); 16- } 17- Set<DTNHost> s = currentAverageDurationSlot.keySet(); 18- Iterator<DTNHost> iter=s.iterator(); 19- while(iter.hasNext()){ 20DTNHost dtnhost = iter.next(); 21double newvalue= currentAverageDurationSlot.get(dtnhost)/currentday; 22- } 23- }

In order to x this bug, we added a condition to update the AD for nodes that were not encountered in the current daily sample (lines 22 - 25) as shown in Alg. 2. Algorithm 2 After xing bug
1- private void updateAverageDuration(){ 2- long currentday=SlotTimeCheck.getDay(); 3- int currentslot = SlotTimeCheck.getcurrentslot(); 4- Map<DTNHost,Double> currentAverageDurationSlot=averageDurations.get(currentslot); 5- Set hostsinDelta = deltaT.keySet(); 6- Iterator<DTNHost> deltaTHostIterator= hostsinDelta.iterator(); 7- while(deltaTHostIterator.hasNext()){ 8DTNHost currenthost= deltaTHostIterator.next(); 9double oldAD=0; 10if(currentAverageDurationSlot.get(currenthost)==null){ 11oldAD=0; 12else 13oldAD=currentAverageDurationSlot.get(currenthost); 14double newAD = (deltaT.get(currenthost)+(currentday-1)*oldAD); 15currentAverageDurationSlot.put(currenthost,newAD); 16- } 17- Set<DTNHost> s = currentAverageDurationSlot.keySet(); 18- Iterator<DTNHost> iter=s.iterator(); 19- double newvalue=0.0; 20- while(iter.hasNext()){ 21DTNHost dtnhost = iter.next(); 22if(!hostsinDelta.contains(dtnhost)){ 23newvalue= (currentday-1)*currentAverageDurationSlot.get(dtnhost)/currentday; 24} 25else 26newvalue= currentAverageDurationSlot.get(dtnhost)/currentday; 27- } 28- }

With this changes, the AD computation problem was solved.

4.4

Order of Average Duration for Weight Computation

When determining the social weight, we consider the sum of different average durations as shown in Eq. 3. The order of the considered ADs is important, in order to capture the behavior pattern as noted in [4]. However, the rst implementation of TECD failed in the sense that it would consider the previous ADs (cf. Alg. 3) and not the following ones. Algorithm 3 Considering previous ADs
1- private void updateWeights(){ 2- ... 3- for(int i=numberofslots;i>0;i){ 4... 5slotindex=(slotindex-1); 6if(slotindex==-1){ 7slotindex=SlotTimeCheck.getnumberofslots()-1; 8- } 9- this.preds=nextweight; 10- }

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

By performing the changes shown in Alg. 4, we are able to achieve the correct computation for TECD that considers the current social behavior along with past ones in subsequent daily samples. Algorithm 4 Considering subsequent ADs
1- private void updateWeights(){ 2- ... 3- for(int i=numberofslots;i>0;i){ 4... 5slotindex=(slotindex+1); 6if(slotindex==24){ 7slotindex=0; 8- } 9- this.preds=nextweight; 10- }

4.5

Reset Day Count

In order to improve the data collecting process, we simulate the behavior of TECD and TECDi based on scripts. Since each run was performed one after the other, the rst implementation was not reseting the day count. Thus, the results would be collected in a different way when compared to the other simulated proposals. To avoid any biased simulations, we solved the problem by adding line 6 to the reset function of SimClock class of the simulator as shown in Alg. 5. Algorithm 5 Reset day count x
1- public class SimClock { 2- ... 3- /** * Resets the static elds of the class */ 4- public static void reset() { 5clockTime = 0; 6SlotTimeCheck.currentday=1; // Restart day count in case of running multiple runs 7- } 8- }

4.6

Daily Periods of Time

We also wanted to investigate the effect of length of the daily samples when determining the social weights. Thus, we considered 6, 8, 12, and 24 daily samples each with 4, 3, 2, and 1 hour of length.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

10

Average Delivery Probability

0.5
6 daily samples 8 daily samples 12 daily samples 24 daily samples

Average Cost
250
6 daily samples 8 daily samples 12 daily samples 24 daily samples

0.4

200

Number of replicas

0.3

150

0.2

100

0.1

50

1 day

2 days

4 days

1 week

3 weeks

1 day

2 days

4 days

1 week

3 weeks

TTL

TTL

(a) Average delivery probability for different daily samples

80000

(b) Average cost for different daily samples

Average Latency
6 daily samples 8 daily samples 12 daily samples 24 daily samples

70000

60000

50000

Seconds

40000

30000

20000

10000

1 day

2 days

4 days

1 week

3 weeks

TTL

(c) Average Latency for different daily samples

Figure 5: Effect of different daily samples when determining the social weight As it can be seen in Fig. 5, the performance improves as time slot length decreases and is rather stable in terms of average delivery probability and cost (cf Figs. 5(a) and 5(b)). However, this improvement comes with higher latency behavior as shown in Fig. 5(c) which results from the fact that now next forwarders are carefully chosen, and thus forwarding decisions take more time to taken. Still, we have chosen to consider the 24-daily sample conguration as it provided a much more stable behavior as the TTL increased, and a more rened view of the social weight and importance of nodes in the system.

5 Community Detection
We also try to nd other uses for the proposed utility functions, and since we are dealing with social similarity which also involves community formation, we decided to employ TECD when forming communities.

5.1

TECD-based solution as alternative to k-clique

An algorithm usually considered for community formation is k-clique: it is used by Bubble Rap [6], for instance. The idea is to create and alternative algorithm for community detection based on the TECD utility function, which is used to decide about including new nodes in the community considering the weights of nodes which are already part of the community. Additionally, if a node already in the community has a lower weight than the threshold (average/median of weights), it will be removed from the community. For instance, a node A is in a community with nodes B , C and D with social weights to them of 35, 30, and 40, respectively. Now node A encounters node E with some regularity. It will only include node E in his community: when its weight to E is greater than the average of its weights towards the nodes already in its community (w(A, E ) > average( w(A, B ), w(A, C ), w(A, D)); or when its weight to E is greater than the median of its weights towards the nodes already in its community (w(A, E ) > median( w(A, B ), w(A, C ), w(A, D));
Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012 11

Fig. 6 shows the performance of Bubble Rap with the original version of k-clique as well as its social weight based versions (Average and Median). It is worth mentioning that we dened k = 5 since it increased Bubble Raps performance. The only difference between the approaches are how nodes are added to a community. Message TTL was set at 24 hours for these experiments.
Average Delivery Probability
0.5
Original k-clique Average k-clique Median k-clique

Average Cost
500
Original k-clique Average k-clique Median k-clique

0.4

400

0.3

Number of replicas
0 0.2 0.4 0.6 0.8 1

300

%
0.2

200

0.1

100

0.2

0.4

0.6

0.8

Proposals

Proposals

(a) Average delivery probability for different k-clique approaches

80000

(b) Average cost for different k-clique approaches

Average Latency
Original k-clique Average k-clique Median k-clique

70000

60000

50000

Seconds

40000

30000

20000

10000

0.2

0.4

0.6

0.8

Proposals

(c) Average Latency for different k-clique approaches

Figure 6: Performance of Bubble Rap with different k-clique approaches The results showed a different conclusion from what was expected: we believed that the social weightbased versions of k-clique would result in communities comprising nodes with strong social connections. However, this resulted in many different close-knit groups with very low connection between them. The consequence was lower average delivery probability (cf. Fig. 6(a)) with higher latency (cf. Fig. 6(c)). Regarding cost (cf. Fig. 6(b)), the Average version produced the highest number of copies while the Median version produced the lowest. We believe the Average approach resulted in more nodes in the communities than Median, leading to higher number of replications.

6 Conclusions and Future Work

This technical report aims to provide further information about the investigation of the most suitable utility functions to support our proposal for an social-aware opportunistic routing protocol: dLife. The proposed utility functions are able to capture the network dynamics when determining the social weight (TECD) among nodes and the importance (TECDi) of these nodes in the system. By carefully analyzing our implementation we were also able to identify points to improve the overall performance of our functions: we xed a implementation bug regarding the average duration computation and changed the order for computing average duration to capture the behavior pattern as noted in [4]. Also, improved the weight calculation by guring out the importance level to best represent the time transitive property and studied the suitable number of daily samples that best captured the network dynamism. Additionally, we tried to nd another potential usage for TECD by incorporating it to k-clique community detection algorithm. The result of this work can be found in our paper [9] entitled Study on the Effect of Network Dynamics on Opportunistic Routing, where we show how important it is to consider the networks dynamics when attempting

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

12

to improve performance of opportunistic routing proposals. Thus, we present two routing algorithms based on TECD (which replicates only when encountered node has better weight to destination than the current message carrier) and TECDi (which replicates only if encountered node is more important than current carrier). Such algorithms are compared to contact-based (e.g., PROPHET [8] and Epidemic [16]) and social-based (e.g., Bubble Rap [6] and Rank that has similar behavior as PeopleRank [13]). As future work, we are developing a hybrid solution which will combine TECD and TECDi. As we could observe the potential of both utility functions working in separate [9], we want to further investigate such hybrid solution in the context of of social-based opportunistic routing.

ACKNOWLEDGMENT
Thanks are due to FCT for nancial support to UCR (PTDC/EEA-TEL/103637/2008) project and for PhD grant (SFRH/BD/62761/2009) to Waldir Moreira.

References
[1] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott. Impact of human mobility on the design of opportunistic forwarding algorithms. In Proceedings of INFOCOM, Barcelona, Spain, April, 2006. [2] Paolo Costa, Cecilia Mascolo, Mirco Musolesi, and Gian Pietro Picco. Socially-aware routing for publishsubscribe in delay-tolerant mobile ad hoc networks. Selected Areas in Communications, IEEE Journal on, 26(5):748760, June, 2008. [3] Elizabeth M. Daly and Mads Haahr. Social network analysis for routing in disconnected delay-tolerant manets. In Proceedings of ACM MobiHoc, Montreal, Canada, September, 2007. [4] Nathan Eagle and Alex Pentland. Eigenbehaviors: identifying structure in routine. Behavioral Ecology and Sociobiology, 63(7):10571066, May, 2009. [5] T. Hossmann, T. Spyropoulos, and F. Legendre. Know thy neighbor: Towards optimal mapping of contacts to social graphs for dtn routing. In Proceedings of IEEE INFOCOM, San Diego, USA, March, 2010. [6] P. Hui, J. Crowcroft, and E. Yoneki. Bubble rap: social-based forwarding in delay tolerant networks. Mobile Computing, IEEE Transactions on, 10(11):15761589, November, 2011. [7] Pan Hui and Jon Crowcroft. How small labels create big improvements. In Proceedings of IEEE PERCOM Workshops, White Plains, USA, March, 2007. [8] Anders Lindgren, Avri Doria, and Olov Schelen. Probabilistic routing in intermittently connected networks. In Service Assurance with Partial and Intermittent Resources, volume 3126 of Lecture Notes in Computer Science, pages 239254. Springer Berlin / Heidelberg, 2004. [9] Waldir Moreira, Manuel de Souza, Paulo Mendes, and Susana Sargento. Study on the effect of network dynamics on opportunistic routing. In Proceedings of AdHoc Now, Belgrade, Serbia, July, 2012. [10] Waldir Moreira, Manuel de Souza, Paulo Mendes, and Susana Sargento. Opportunistic routing based on daily routines. In Proceedings of IEEE WoWMoM Workshop AOC, San Francisco, USA, June, 2012. [11] Waldir Moreira and Paulo Mendes. Survey on opportunistic routing for delay/disruption tolerant networks. Technical Report SITI-TR-11-02, SITI, University Lusofona, February, 2011. [12] Waldir Moreira, Paulo Mendes, and Susana Sargento. Assessment model for opportunistic routing. In Proceedings of the IEEE LATINCOM, Belem, Brazil, October, 2011. [13] Abderrahmen Mtibaa, Martin May, Mostafa Ammar, and Christophe Diot. Peoplerank: Combining social and contact information for opportunistic forwarding. In Proceedings of INFOCOM, San Diego, USA, March, 2010. [14] Samuel Nelson, Mehedi Bakht, and Robin Kravets. Encounter-based routing in DTNs. In Proceedings of INFOCOM, Rio de Janeiro, Brazil, April, 2009. [15] Libo Song and David F. Kotz. Evaluating opportunistic routing protocols with large realistic contact traces. In Proceedings of ACM MobiCom CHANTS, Montreal, Canada, September, 2007. [16] Amin Vahdat and David Becker. Epidemic routing for partially connected ad hoc networks. Technical Report CS-200006, Duke University, 2000.

Social-aware Utility Functions for Opportunistic Routing - SITI-TR-XX-XX - August 9, 2012

13

ANNEX H Book chapter Social-aware Opportunistic Routing: The new trend to be published by Springer Verlag.

Part III: Routing in Opportunistic Networks Chapter on Social-aware Opportunistic Routing: The new trend Authors: Waldir Moreira, Paulo Mendes Abstract Since users move around based on social relationships and interests, the resulting movement patterns can represent how nodes are socially connected (i.e., nodes with strong social ties, nodes that meet occasionally by sharing the same working environment). This means that social interactions reflect personal relationships (e.g., family, friends, co-workers, passers-by) that may be translated into statistical contact opportunities within and between social groups over time. Such contact opportunities may be exploited to ensure good data dissemination and retrieval, even in the presence of intermittent connectivity. Thus, in the last years, a new trend based on social similarity emerged where social relationships, interests, and popularity are used to improve opportunistic routing. In this chapter the reader will learn about the different approaches related to social-aware opportunistic routing and how such solutions make use of social information derived from opportunistic contacts to improve data forwarding.